CLI-AnythingであらゆるソフトウェアをAIエージェント対応にする
AIエージェントがコードを書いたりファイルを操作したりするのは当たり前になった。でもGIMPで画像を編集したり、Blenderで3Dレンダリングしたり、LibreOfficeでPDFを生成したりといった「GUIソフトウェアの操作」は、まだエージェントにとって鬼門だった。
香港大学のHKUDS研究グループが公開したCLI-Anythingは、この問題に対するアプローチとしてかなり筋がいい。ソフトウェアのソースコードを食わせると、AIエージェントが使えるCLIハーネスを自動生成する。公開から約10日でGitHub Star 19,000超。
何が問題だったのか
AIエージェントがGUIソフトウェアを操作する方法はこれまでいくつかあったが、どれも課題を抱えていた。
- スクリーンショット＋クリック（GUI自動化）: UIが変わると壊れる。遅い。不安定
- 限定的なAPI: ソフトウェアの機能の一部しかカバーしない
- 再実装: ソフトウェアの機能を別途コードで書き直す。機能の90%が抜け落ちる
CLI-Anythingの発想は「CLIはLLMと相性がいい」という点にある。テキストベースで構造化されていて、--helpで自己記述的、JSON出力でパース不要、パイプで合成可能。
7フェーズの自動生成パイプライン
CLI-Anythingの中核は、ソースコードからCLIを自動生成する7段階のパイプライン。
graph TD
A[Phase 1: Analyze<br/>ソースコード解析] --> B[Phase 2: Design<br/>コマンド設計]
B --> C[Phase 3: Implement<br/>Click CLIの実装]
C --> D[Phase 4: Plan Tests<br/>テスト計画]
D --> E[Phase 5: Write Tests<br/>テスト実装]
E --> F[Phase 6: Document<br/>ドキュメント生成]
F --> G[Phase 7: Publish<br/>pip installで配布]- Analyze — ソースコードをスキャンし、GUIアクションとAPIのマッピングを作成
- Design — コマンドグループ、状態モデル、出力フォーマットを設計
- Implement — PythonのClickフレームワークでCLIを構築。REPL、JSON出力、Undo/Redoを含む
- Plan Tests — ユニットテストとE2Eテストの計画を作成
- Write Tests — テストスイートを実装
- Document — テスト結果でドキュメントを更新
- Publish —
setup.pyを生成し、pip install -e .でPATHにインストール
さらにPhase 6.5としてSKILL.md生成が追加されている。生成されたCLIのClickデコレータやsetup.pyからメタデータを抽出し、AIエージェントが自動発見できるスキル定義ファイルを同梱する。
対応ソフトウェアとテスト結果
16のアプリケーションでCLIハーネスが生成・テストされている。
| ソフトウェア | 分野 | バックエンド | テスト数 |
|---|---|---|---|
| GIMP | 画像編集 | Pillow + GEGL/Script-Fu | 107 |
| Blender | 3Dモデリング | bpy (Python scripting) | 208 |
| Inkscape | ベクタグラフィックス | SVG/XML直接操作 | 202 |
| Audacity | 音声編集 | Python wave + sox | 161 |
| LibreOffice | オフィススイート | ODF生成 + headless LO | 158 |
| OBS Studio | 配信・録画 | JSON scene + obs-websocket | 153 |
| Kdenlive | 動画編集 | MLT XML + melt | 155 |
| Shotcut | 動画編集 | MLT XML + melt | 154 |
| Draw.io | 作図 | mxGraph XML + draw.io CLI | 138 |
| Mubu | ナレッジ管理 | ローカルデータ + sync logs | 96 |
| ComfyUI | AI画像生成 | ComfyUI REST API | 70 |
| AnyGen | AIコンテンツ生成 | AnyGen REST API | 50 |
| AdGuardHome | ネットワーク | AdGuardHome API | 36 |
| Zoom | ビデオ会議 | Zoom REST API (OAuth2) | 22 |
| Mermaid | 作図 | mermaid.ink renderer | 10 |
合計1,720テスト、全通過。ユニットテスト1,247 + E2Eテスト473という内訳。
注目すべきは「本物のソフトウェアを呼び出してテストしている」点。LibreOfficeのテストではheadlessモードで実際にPDFを生成し、%PDF-マジックバイトを検証している。Blenderでは実際にレンダリングしてPNG出力を確認する。モックではなく実バックエンドでの検証。
使い方
Claude Codeのプラグインとして使う場合は3ステップ。
# マーケットプレイスを追加
/plugin marketplace add HKUDS/CLI-Anything
# プラグインをインストール
/plugin install cli-anything
# CLIを生成（GIMPの例）
/cli-anything:cli-anything ./gimp生成されたCLIはこう使う。
# インストール
cd gimp/agent-harness && pip install -e .
# ヘルプ表示
cli-anything-gimp --help
# プロジェクト作成
cli-anything-gimp project new --width 1920 --height 1080 -o poster.json
# レイヤー追加
cli-anything-gimp --project poster.json layer add -n "Background" --type solid --color "#1a1a2e"
# JSON出力（エージェント向け）
cli-anything-gimp --json document info --project poster.jsonClaude Code以外にも、OpenCode、OpenClaw、Codex、Qodercli、Gooseに対応している。
設計の特徴
いくつか設計判断で面白い点がある。
デュアルモード動作: すべてのCLIがサブコマンド形式（スクリプト・パイプライン向け）とREPLモード（対話的操作向け）の両方で動く。コマンドを引数なしで実行するとREPLに入る。
--jsonフラグの統一: すべてのコマンドに--jsonフラグがあり、エージェントが構造化データを受け取れる。人間向けにはテーブル形式で表示。
本物のバックエンドへの委譲: CLIが生成するのはプロジェクトファイル（ODF、MLT XML、SVGなど）で、レンダリングは本物のソフトウェアに委譲する。LibreOfficeのPDF生成、Blenderの3Dレンダリング、Audacityの音声処理はすべて実ソフトウェアが担当する。「簡易版の再実装」ではなく「本物へのCLIブリッジ」。
ReplSkin: 統一的なREPLインターフェース。すべての生成CLIが同じ操作感を提供する。ブランドバナー、コマンド履歴、プログレス表示、Undo/Redo。
refineコマンドでカバレッジ拡大
初回生成後に/cli-anything:refineでギャップ分析を実行し、不足しているコマンドを追加できる。
# 全体的なギャップ分析
/cli-anything:refine ./gimp
# 特定機能に焦点を当てる
/cli-anything:refine ./gimp "バッチ処理とフィルター"各実行はインクリメンタルで非破壊的。何度でも実行してカバレッジを広げられる。
GUI自動化との比較
Computer Use（スクリーンショット＋クリック）のようなGUIエージェントとの違いを整理する。
| 観点 | GUI自動化 | CLI-Anything |
|---|---|---|
| 速度 | スクリーンショット取得・解析で遅い | コマンド実行で即座 |
| 安定性 | UI変更で壊れる | CLI APIは安定 |
| 機能カバレッジ | 画面に見えるものだけ | バックエンドAPIの全機能 |
| 構造化出力 | ピクセルから推測 | JSON出力 |
| 前提条件 | ディスプレイが必要 | ヘッドレスで動作 |
ただしCLI-Anythingにも制約はある。ソースコードが読める状態でないと使えない。コンパイル済みバイナリしかない場合はデコンパイルが必要で、品質が大幅に落ちる。また、生成されたCLIの品質はソースコードの構造やAPIの整備具合に依存する。
自分のアプリにも使えるのか
「ソースコードが必要」と聞くと、公開されているOSSだけが対象のように聞こえるが、実際はそうではない。CLI-Anythingがソースコードに対してやっているのはLLMによる静的解析で、Phase 1でバックエンドエンジンの特定、データモデルのフォーマット把握、GUI操作とAPIのマッピングを行っている。つまりソースコードが「読める」状態であればよく、OSSかどうかは関係ない。
ローカルにソースコードがあれば、自作アプリでもプライベートリポジトリのコードでもそのまま使える。
# ローカルパスを指定
/cli-anything:cli-anything ./my-private-app
# GitHubリポジトリURLも指定可能（アクセス権があれば）
/cli-anything https://github.com/your-org/your-repoGitHubに上がっている自分のリポジトリならURLを直接渡せる。プライベートリポジトリの場合はgit/ghの認証が通っていればいける。ローカルにcloneして渡しても同じ。
ただし生成されるCLIの品質は、コードベースの構造次第で大きく変わる。
- APIが明確に分離されているアプリ — Pythonのモジュール構成が整理されている、REST APIがある、スクリプティングインターフェースがあるなど。これらは高品質なCLIが生成される
- 構造化されたデータモデルを持つアプリ — JSON、XML、SVGなどを扱うアプリは解析しやすい。バイナリフォーマットだけのアプリはハードルが上がる
- ドキュメントやREADMEが整備されているアプリ — LLMが機能を理解する手がかりになる。ドキュメントがないとLLMが機能を網羅できないケースがある
要するに、ソースコードの「公開・非公開」ではなく「LLMが読んで理解できるか」が実質的な条件。自分のアプリでも、APIがある程度整理されていてソースが読める状態なら十分に動く。逆にGitHubで公開されているOSSでも、コードがスパゲッティだったりドキュメントがなかったりすれば品質は落ちる。
なお、生成されたCLIが実行時に呼び出すのは本物のアプリケーションバックエンドなので、対象ソフトウェアがマシンにインストールされていて動作する状態である必要がある。ソースコードが読めてもアプリ自体が動かなければCLIも動かない。