AI エージェントに画面を見させるのは、もうやめよう——CLI-Anything がすべてのソフトにコマンドラインを与える

AI エージェントがデスクトップソフトを操作しようとするのを見ていると、独特の絶望感が湧いてくる。スクリーンショットを撮り、メニューの位置を推測し、クリックする。外れる。またスクショを撮る。20 秒後、スライダーは 2 ピクセル動いて、何も学んでいない。

香港大学データ知能研究室（HKUDS）の CLI-Anything は、そのアプローチ全体が間違っているという主張だ。エージェントに画面を見ることを教えるな。ソフトにコマンドラインを持たせて、エージェントにタイプさせろ。

売り文句は一行で済む。すべてのソフトを agent-native に。仕組みのほうは地味だが、もっと面白い——ソースを持っているアプリなら何であれ、コマンドを一つ向ければ、7 段階のパイプラインが構造化された CLI ラッパーを生成する。テスト、ドキュメント、そして pip で入るパッケージまで揃った状態で。

7 つのステージ

パイプラインはコーディングエージェントの中で動く。/cli-anything <source path or repo> で呼び出す。分析：ソースを走査し、GUI 操作を API 呼び出しに対応づける。設計：コマンドのグループ分け、状態モデル、出力フォーマットを決める。実装：Click ベースの CLI を組み、REPL、JSON 出力、undo/redo を載せる。テスト計画：テスト計画を TEST.md に書く。テスト実装：スイートを実装する。ドキュメント：結果を同じファイルに書き戻す。公開：setup.py を作り、コマンドを PATH に載せる。

さらにステージ 6.5 があり、SKILL.md を生成する。これで出来上がった CLI は、人間が配線しなくてもエージェントからスキルとして見つけてもらえる。加えて /cli-anything:refine コマンドがあり、ギャップ分析をしてカバレッジを少しずつ広げていく。

命名はわざと硬くしてある。コマンドは cli_anything.<software> 名前空間の下、パッケージ名は cli-anything-<software>。退屈な慣習こそがツールを組み合わせ可能にするのであって、このプロジェクトは明らかに、そうしたラッパーが何百個も存在する世界を想定している。

おもちゃの再実装ではなく、本物のバックエンド

これを週末プロジェクトと分かつ細部はここだ。ラッパーは実際のソフトを動かす。LibreOffice は本物の PDF を吐き、Blender は本物の 3D シーンをレンダリングし、GIMP は GIMP が画像に対してやることをやる。もう一つの道——アプリの挙動の一部を Python で再実装する——でできるのは、再実装が飛ばした機能が必要になるまでは動いているように見える何か、だ。

コストは、アプリをインストールしておく必要があること。利点は、出力が人間のオペレーターが作ったものと見分けがつかないこと。同じエンジンが作っているのだから。

どのコマンドも、求められれば JSON を返す。これが「エージェントがパースできる CLI」と「エージェントが目を細めて読むしかない CLI」の違いになる。対話作業用の状態を持つ REPL、スクリプト用の素のサブコマンド、そして永続的なプロジェクト状態と undo/redo も揃っている。

カバーしている範囲

守備範囲は意図的に広い。読んでいると、みんなが自動化しようとして失敗してきたソフトの一覧のようだ。クリエイティブ系は GIMP、Blender、Kdenlive。オフィス文書は LibreOffice。3D とゲームは Godot と s&box。科学技術系は QGIS と FreeCAD。AI 側は ComfyUI と Ollama。デバッグは LLDB、RenderDoc、Nsight。

画像を扱う人なら、ComfyUI のところで一度立ち止まる価値がある。ComfyUI にはすでに API がある。ただしそれはグラフ API だ——ノード、配線、そしてスキーマがインストール済みのカスタムノード次第で変わる JSON blob。意図レベルのコマンドを出し、状態モデルと JSON 出力が定義された CLI ラッパーは、誰かのワークフローファイルをリバースエンジニアリングせずに画像パイプラインを回したいエージェントに、まさに必要なものだ。

テストについての主張

リポジトリが報告しているのは約 2,461 のテスト。1,732 がユニット、579 がエンドツーエンド、19 が Node.js で、通過率 100% と称している。E2E 層は本物のバックエンドに対して走る。ここではそれが唯一意味のある E2E だ。LibreOffice が PDF を出さなくなればテストは落ちる。エージェントが壊れたファイルを 40 個生成する前に気づける。

「100%」は保証ではなくスナップショットとして受け取ったほうがいい。生成されたテストスイートには、生成器の前提をそのまま埋め込んでしまう悪い癖がある。とはいえ 4 層構造——ユニット、ネイティブ E2E、実バックエンド E2E、CLI サブプロセス——は正しい形をしている。

正直に書かれた限界

README に列挙されている。これは良い兆候だ。

フロンティアモデルに依存する。Claude Opus 4.6 か Sonnet 4.6、GPT-5.4、そのクラス。弱いモデルだと CLI は不完全か、そもそも間違っていて、大量の手作業修正が要る。つまりこのツールの有用性は、あなたが持っているかどうかわからないサブスクリプションに紐づいている。

ソースコードに依存する。パイプラインはソースを解析する。手元にコンパイル済みバイナリしかなければ、品質とカバレッジは急落する。これが商用ソフトの大半を静かに排除してしまう。そして人が実際に自動化したいソフトの大半は、まさにそれだ。

1 回の実行で全部をカバーできることはまずない。ハーネスを実運用レベルにするには、/refine を何度も回す覚悟が要る。CLI によっては上流アプリのインストールが前提になる。プラットフォームごとの成熟度もばらばらで、Goose、OpenCode、Codex、Hermes、Reasonix は experimental 扱い。Windows ユーザーは bash と cygpath の互換性問題にも出くわす。

誰も聞きたがらない保守の話

生成されたラッパーはコミットメントだ。cli-anything-libreoffice を採用した瞬間、エージェントとアプリの間に層が一枚増え、その層は LibreOffice が文書モデルを変えても、Blender がオペレーターの名前を変えても、動き続けなければならない。

実際には 3 つの意味がある。生成したハーネスは他人のものに依存せず自分のリポジトリに置くこと。そうすればパッチを当てられる。基礎となるアプリをアップグレードしたらパイプラインを再実行し、結果を diff すること。そして TEST.md を契約として扱うこと——エージェントが壊れたファイルを 40 個作る前に破綻に気づけるのは、テストのおかげだけだ。

経済性が成り立つのは、再生成が安いからだ。ここが本当の洞察である。ラッパーは永遠に完璧である必要はない。生み出したものが、もう一度生み出せるのだから。従来の SDK が維持費のかかる理由は、人間が書いているからだ。これはそうではない。

CLI-Hub という賭け

コミュニティ製ラッパーを探してインストールするためのパッケージマネージャー、cli-anything-hub がある。ここがこのプロジェクトで最も伸びしろがあり、最もリスクが明白な部分だ。生成された CLI のハブは、あなたの権限で動き、あなたのファイルに触るコードのハブでもある。

有用なエコシステムになるか、サプライチェーン事故の事例になるかは、プロジェクトがレビューを公開作業の一部と見なすかどうかに完全にかかっている。今のところ答えは「半分」だ。テストは生成され、ドキュメントも生成され、レビューはコミュニティがやる分だけ。

リポジトリの外でこれが意味するもの

この 2 年間、computer use は業界で最も好かれるデモであり、最も作られない製品だった。デモが動くのは、誰かがタスクを丁寧にスクリプト化したからだ。製品が失速するのは、ピクセル単位の制御がどうにもならないほど脆く、その脆さが決して消えないからだ。

CLI-Anything は別の分業を提案する。エージェントを人間らしくするのではなく、ソフトを機械らしくする。ソースツリーを持つアプリはすべて生成インターフェースの候補になり、そのインターフェースはスクリーンショットループには決してできない形でテストできる。

トレードオフは現実だ。生成された CLI は、それを書いたモデルと同じだけしか良くならない。上流アプリが変われば、誰かがラッパーの面倒を見なければならない。それでも方向は正しい。cli-anything-blender render --scene scene.blend --out frame.png と打って決定的な出力を得るエージェントは、ビューポートを適当にクリックして祈るエージェントより、根本的に有用なことをしている。