AIエージェント用CLIを自動生成「CLI-Anything」の仕組み

AI エージェントに実務のソフトウェアを操作させようとすると、たいていは同じ壁に当たります。画面キャプチャを読ませてクリック座標を指示する方式は、対象アプリの UI が少し変わるだけで動かなくなります。公式 API が用意されているソフトでも、公開されているのは機能の一部で、GUI でできることの半分も自動化できないケースが珍しくありません。

やりづらいのは、この問題が「どのソフトを対象にするか」で毎回振り出しに戻る点です。Blender には Blender の、LibreOffice には LibreOffice の事情があり、連携を自作すればソフトの数だけ実装と保守が増えていきます。一方で、どれか一つに絞って作り込んでも、次に別のソフトを対象にしたいという要望が来れば同じ作業を繰り返すことになります。結果として「どこから手をつけるべきか」の判断がつかないまま、検討が止まりがちです。

この状況に対して、「対象ソフトのソースコードを解析して、エージェントが扱える CLI を自動生成してしまう」というアプローチを採るプロジェクトが出てきました。それが、香港大学のデータインテリジェンス研究室（HKUDS）が公開している HKUDS/CLI-Anything です。スクリーンショットもクリック座標も使わず、構造化されたコマンドラインインターフェースをソフトごとに量産するという考え方を採っています。

ただし、自動生成という言葉から受ける印象と、前提として求められる条件の間にはギャップがあります。生成品質は使用するモデルに依存し、ソースコードが手に入らないソフトウェアでは適用範囲が大きく狭まります。採用を検討するなら、機能の魅力だけでなくこうした制約を先に把握しておく必要があります。

本記事では、CLI-Anything の 7 段階生成パイプライン・生成される CLI の設計・CLI-Hub による配布と発見・MCP サーバー方式や GUI 操作型エージェントとの違い・導入前に確認すべき制約を、GitHub 上の公開情報と公式ドキュメントをもとに整理します。動作検証やインストールは行っておらず、記述はすべて公開ドキュメントと GitHub API の取得値に紐づけています。

CLI-Anythingとは｜ソフトをAIエージェント操作可能にするOSS

CLI-Anything は、既存のソフトウェアを AI エージェントが扱える形に変換することを目的とした OSS です。リポジトリの説明文には「Making ALL Software Agent-Native」というキャッチコピーが掲げられており、README では「Today's Software Serves Humans. Tomorrow's Users will be Agents.（今日のソフトウェアは人間に奉仕している。明日のユーザーはエージェントになる）」という問題設定が示されています。

日本語のドキュメントも用意されているため、英語の README を読み進めるのが負担な場合は 公式日本語ドキュメント から入る選択肢もあります。

リポジトリの基本情報

GitHub API で取得した値は以下のとおりです（2026 年 10 月 11 日時点）。

スター数が 5 万を超える一方で、アーカイブフラグもフォークフラグも立っていない独立した本家リポジトリです。ライセンスは Apache-2.0 で、商用利用・改変・再配布が可能な条件になっています。この点の意味は、のちほど制約の節で改めて整理します。

3 層構成｜生成プラグイン・生成されたCLI・CLI-Hub

このプロジェクトが提供しているものは、一つのツールではなく 3 つのレイヤーに分かれています。初見で混乱しやすいポイントなので、先に役割分担を押さえておくと以降の内容が読みやすくなります。

つまり「自分で生成する」経路と「他者が生成したものを使う」経路の両方が用意されている構成です。検討の初手としては、対象にしたいソフトのハーネスが CLI-Hub に既にあるかを確認するのが無駄がありません。

なぜCLIなのか｜GUI自動化とAPI連携の限界

CLI-Anything が CLI という形式を選んでいる理由は、README の「The Agent-Software Gap」節で明示されています。既存の選択肢を「壊れやすい UI 自動化」「機能が限られた API」「機能が大きく欠落した簡易再実装」の 3 つに整理し、それぞれの限界を出発点に設計されています。

README が挙げる課題と対応は次のように対応づけられています。

そのうえで「Why CLI?」として挙げられているのは、構造化されていて連結できること、依存が少なく環境を問わないこと、--help が自動的にドキュメントになること、Claude Code のようなエージェントが既に日常的に CLI 経由でワークフローを実行している実績があること、JSON 出力でパース処理が不要なこと、挙動が決定的で予測しやすいことの 6 点です。

この 6 点を、エージェント側の視点で具体的に言い換えると 3 つの性質に落ちます。第一に、--help を叩けば「このソフトで何ができるか」をエージェント自身が発見できます。第二に、--json を付けて出力を受け取れば、人間向けの整形テキストからデータを抜き出す処理が不要になります。第三に、座標やウィンドウ位置に依存しないため、UI レイアウトの変更で壊れる経路が最初から存在しません。

この思想については、著者らによる技術レポート CLI-Anything: Towards Agent-Native Computer Use（arXiv:2606.03854、2026 年 6 月投稿）でも論じられています。視覚的な GUI 経由のエージェントはスクリーンショットの解釈と座標クリックに依存するため UI 変更で壊れやすく、視覚情報から計算処理への変換の過程で情報が失われる、という問題設定が示されています。これに対して、既存アプリを「構造化コマンド・明示的な状態表現・決定的なフィードバック」を備えた CLI ハーネスに変換するという方針が提案されています。

重要なのは、ここが単なる実装上の都合ではなく前提の違いだという点です。画面を見て操作する方式と、構造化インターフェースを経由する方式では、「何が壊れやすさの原因になるか」の所在そのものが変わります。この違いを押さえておくと、のちほどの類似 OSS との比較が機能表の読み比べではなく、採用方針の選択として読めるようになります。

AIエージェント用CLIを自動生成する7段階パイプライン

CLI-Anything の中核は、対象ソフトのパスまたはリポジトリを渡すだけで CLI 一式を生成するパイプラインです。README の「Build a CLI in One Command」節では、/cli-anything <software-path-or-repo> という 1 コマンドで以下の 7 フェーズが順に実行されると説明されています。

7フェーズの内訳

1. Analyze — ソースコードを走査し、GUI 操作を内部 API にマッピングする
2. Design — コマンド群・状態モデル・出力形式を設計する
3. Implement — Click ベースの CLI を実装する（REPL / JSON 出力 / undo・redo 付き）
4. Plan Tests — TEST.md にユニットテストと E2E テストの計画を作成する
5. Write Tests — テストスイートを実装する
6. Document — 結果を TEST.md に反映する
7. Publish — setup.py を生成し、PATH にインストールできる状態にする

このうち Phase 6.5 に相当する処理として、skill_generator.py が SKILL.md を自動生成します。Click のデコレータ・setup.py・README からメタデータを抽出し、エージェントが「このハーネスで何ができるか」を読み取れる形式で出力する仕組みです。生成方法論そのものは HARNESS.md（方法論SOP） に標準作業手順としてまとめられており、導入手順は QUICKSTART.md で確認できます。

導入と実行のコマンド例

README では、Claude Code のプラグインとして導入する手順が次のように示されています。

/plugin marketplace add HKUDS/CLI-Anything
/plugin install cli-anything
/cli-anything ./gimp

出典: HKUDS/CLI-Anything（GitHub）

マーケットプレイスにリポジトリを登録し、プラグインをインストールしたうえで、対象ソフトのディレクトリを渡すという流れです。生成対象としてはローカルのパスだけでなく、GitHub リポジトリを指定する形も README 上でサポートされています。

refineによる反復｜1回で完結しない前提

ここが採用判断で最も重要な点です。CLI-Anything は 1 回のコマンド実行で対象ソフトの全機能を網羅するツールとして設計されているわけではありません。README には補助コマンドとして /cli-anything:refine が用意されており、既存のハーネスとソースコードのギャップを分析して未実装の機能を追加していく、インクリメンタルかつ非破壊な操作として説明されています。複数回の実行が可能です。

/cli-anything:refine ./gimp
/cli-anything:refine ./gimp "I want more CLIs on image batch processing and filters"

出典: HKUDS/CLI-Anything（GitHub）

2 行目のように自然言語で方向性を指定すれば、特定領域のカバレッジを優先的に広げる使い方もできます。ほかに :test と :validate という補助コマンドも用意されています。

つまり実務上の運用モデルは「1 コマンドで終わる」ではなく「生成してから refine を回して仕上げる」です。この性質は後述する公式の制約事項とも一致しており、導入コストを見積もる際は初回生成だけでなく反復のコストを織り込む必要があります。

HARNESS.mdが記録する落とし穴

HARNESS.md には、ハーネス生成の過程で得られた知見が「Critical Lessons」として蓄積されています。CLI-Anything を使わず自前で連携を実装する場合にも効く内容なので、比較検討の材料として目を通す価値があります。

いずれも「生成された CLI が本当に動いているか」を確認する難しさに関わる項目です。エージェント連携において、コマンドが成功を返したのに期待した成果物が得られていないという失敗は検知しづらく、ここに明示的な検証を組み込む設計思想が読み取れます。

生成されるCLIの設計｜JSON出力・REPL・実ソフト呼び出し

生成される CLI がどう設計されているかは、「生成物をプロダクションで使えるか」の判断に直結します。README では Core Design Principles として 5 項目が掲げられています。

設計原則5項目

最後の原則は特徴的です。一般的なツールであれば依存が見つからない場合に機能を縮退させて動かし続ける設計を採ることが多いのですが、CLI-Anything は逆に明確に失敗させる方針を取っています。「実アプリを呼ばずに近似的な結果を返す」ことを設計上許さないという意思表示で、第一の原則と対応しています。

このほか、セッション状態の永続化と undo / redo、pip install -e . のみで cli-anything-<software> という実行ファイルが PATH に載るゼロコンフィグ構成、cli_anything.* 名前空間によるパッケージ衝突の回避が README 上で挙げられています。

エージェントから見た使い勝手

生成された CLI の利用手順は、README で次のように示されています。

cd gimp/agent-harness && pip install -e .
cli-anything-gimp --help
cli-anything-gimp --json layer add -n "Background" --type solid --color "#1a1a2e"

出典: HKUDS/CLI-Anything（GitHub）

エージェント側の動作としては、which で実行可能ファイルの存在を確認し、--help で利用可能なコマンド体系を把握し、--json を付けて構造化された結果を受け取る、という流れになります。この 3 つが揃っていれば、ハーネスごとに固有の統合コードを書く必要は原則として生じません。ソフトが増えても、エージェント側の扱い方は同じ型に収まります。

テストの4層構造と集計値の読み方

README の「Test Results」節では、テストが 4 層に分かれていることが説明されています。ユニットテスト、ネイティブなファイル生成を確認する E2E、実バックエンドを呼び出して出力を検証する E2E、そして CLI をサブプロセスとして実行するテストです。出力検証の具体例としては、LibreOffice から PDF を生成した場合の %PDF- マジックバイト確認、Blender でのレンダリング PNG の生成確認が挙げられています。

件数については注意が必要です。README のテスト集計ブロックでは合計 2,464 件が pass（pass rate 100%）とされ、30 ハーネス分の内訳（blender 208 件、inkscape 202 件、audacity 161 件、libreoffice 158 件、kdenlive 155 件など）が記載されています。ただし README 冒頭のバッジは「2,461」、Pain Point 表と末尾のフッターは「2,280+ tests」「18 major applications」と記載されており、README 内で数値が揃っていません。本記事では出典を集計ブロックに限定して記載していますが、正確な件数を根拠にしたい場合は公式リポジトリの最新状態を確認することをおすすめします。

テストの件数そのものより、実バックエンドを呼び出して出力を検証する層が設けられている点が、生成物の信頼性を判断する材料になります。先に触れた「exit code 0 を信用しない」という方針が、テスト構造のレベルまで反映されている形です。

CLI-Hubで既存のCLIを探す｜対応エージェントと前提条件

自分で生成する前に、対象にしたいソフトのハーネスが既に公開されていないかを確認できるのが CLI-Hub です。人間が使うコマンドラインツールと、エージェント自身に探させるメタスキルの 2 つの経路が用意されています。

cli-hubのサブコマンド

README では、インストールから起動までの流れが次のように示されています。

pip install cli-anything-hub
cli-hub list
cli-hub search image
cli-hub install gimp
cli-hub launch gimp

出典: HKUDS/CLI-Anything（GitHub）

このほか info / update / uninstall が用意されており、一覧表示・検索・詳細確認・インストール・更新・削除・起動という一通りの操作がコマンドラインで完結します。パッケージ名は cli-anything-hub、コマンド名は cli-hub と異なるため、ドキュメントを読む際は混同しないよう注意してください。

エージェント自身に探させるメタスキル

エージェント側から CLI-Hub を扱うための仕組みとして、メタスキルが公開されています。

npx skills add HKUDS/CLI-Anything --skill cli-hub-meta-skill -g -y

出典: CLI-Hub 公式サイト

これを導入すると、エージェント自身がレジストリを検索して必要なハーネスを見つけ、インストールするという動き方が可能になります。README では、OpenClaw・Nanobot・Claude Code・Codex・Reasonix・Antigravity といった SKILL 互換のエージェントが対応先として挙げられています。

公式サイトにはもう一つ「Matrices」という概念があり、これは意図（intent）を提供元の CLI に対応付けた capability bundle として説明されています。カードを裏返すと機能一覧を確認でき、マトリクスに含まれるツールだけにカタログを絞り込めます。やりたいことから逆引きしてハーネスを探す導線です。

なお、公式サイトのトップに表示される「CLIs Available」「Categories」のカウンタは取得時点では数値が表示されていなかったため、本記事では登録 CLI の件数には触れません。実際の掲載数は CLI-Hub 公式サイト で直接確認してください。

対応エージェントと成熟度ラベルの読み方

ハーネスを生成する側のプラットフォームとしては、Claude Code・Cursor・Pi・OpenClaw・OpenCode・Codex・Hermes・Reasonix・Qodercli・GitHub Copilot CLI が README に列挙されています。ただし、見出しに Experimental や Community のラベルが付いているものがあり、OpenCode・Goose・Codex・Hermes・Reasonix は Experimental 系、Qodercli・OpenClaw・GitHub Copilot CLI は Community として記載されています。

一方で Production 相当を明示するラベルは Claude Code などに付いておらず、ラベル体系は README 内で統一されていません。したがって、自分が使っているエージェントでの対応状況は、ラベルの有無だけで判断せず README の該当セクションを直接確認するのが確実です。

もう一つ、見落としやすい前提があります。CLI-Hub で配布されているハーネスは、GIMP・Blender・LibreOffice といった実アプリのバックエンドを呼び出す設計です。README にも注意書きがあるとおり、ハーネスをインストールしただけでは動かず、上流のアプリケーション本体を別途インストールする必要があります。評価環境を用意する際は、この依存関係を見積もりに含めておく必要があります。

レジストリへのハーネス追加は CONTRIBUTING.md に沿った PR 経由で行う形です。配布手順の詳細は PUBLISHING.md にまとめられています。公式サイトには、公開されている CLI の権利は各ソフトウェアの所有者に帰属し、CLI-Hub は発見とインストールの支援のみを行うという立場が明記されています。

類似OSSとの違い｜MCPサーバー・GUI操作エージェントとの比較

「エージェントにソフトを操作させる」という目的に対しては、CLI-Anything 以外にも複数のアプローチが存在します。以下は GitHub API で取得した類似リポジトリの属性値です（2026 年 10 月 11 日時点）。

この 4 つは、機能の優劣ではなくレイヤーと前提の違いとして整理するのが実用的です。

MCP サーバー方式（modelcontextprotocol/servers） は、ツールとエージェントをつなぐプロトコルを標準化するアプローチです。サーバー実装は基本的に人間（またはベンダー）が書き、認証・権限・動的なツール探索が規格として整備されています。対して CLI-Anything は、ソフトごとのハーネスを自動で量産することに主眼があります。両者はレイヤーが異なるため排他ではなく、CLI ハーネスを MCP サーバーから呼び出すような構成も概念上は成立します。選択の軸は「接続の統制を標準化したいのか」「対象ソフトのカバレッジを広げたいのか」です。

browser-use は対象が Web アプリに限定されます。ブラウザ操作を介してエージェントがタスクを実行する方式で、SaaS や社内 Web システムが対象なら有力な選択肢になりますが、Blender や LibreOffice のようなデスクトップアプリのレンダリングパイプラインには踏み込みません。対象が Web の内側に収まるかどうかが分岐点です。

microsoft/OmniParser は、スクリーンショットを解析して純粋な視覚ベースの GUI エージェントを成立させる方向性です。CLI-Anything が明確に否定している「スクリーンショット＋クリック」側の代表例であり、対比に使いやすい存在です。ただし視覚ベースにはソースコードが不要という利点があり、バイナリ配布のみのソフトや社内の既製アプリを対象にする場合はこちらが現実的な選択になります。ライセンスが CC-BY-4.0 である点も、ソフトウェアとして組み込む際の条件が他と異なります。

判断軸として整理すると、次のようになります。対象ソフトのソースコードが入手できるなら CLI-Anything の前提を満たします。入手できないなら視覚ベースの方式を検討する必要があります。対象が Web アプリに収まるならブラウザ操作型が素直です。認証・権限の統制を規格として揃えたいなら MCP が整備されています。

なお、ここで挙げた数値はいずれも 2026 年 10 月 11 日時点の GitHub API 取得値です。性能・成功率・トークン消費量といった実行時の優劣については本記事では比較していません。それぞれの内部実装の詳細も、公式ドキュメントで確認できる範囲を超えては扱っていません。

導入前に確認したい制約とメンテナンス状況

CLI-Anything を検討する際、機能説明より先に目を通しておきたいのが README の Limitations です。公式が明記している制約は 3 点あります。

公式が明記している3つの制約

強力な基盤モデルを要求する。 7 段階パイプラインは frontier クラスのモデルに依存します。README では例として Claude Opus 4.6・Claude Sonnet 4.6・GPT-5.4 が挙げられており、弱いモデルでは不完全・不正確な CLI が生成され、手直しが大量に発生するとされています。コストを抑えるために小型モデルで回すという運用は、公式の想定から外れます。

ソースコードの可用性に依存する。 パイプラインの第一段階がソースコード解析である以上、ソースが入手できることが前提になります。逆コンパイルが必要なバイナリ配布のみのソフトウェアでは、品質とカバレッジが大きく劣化すると README に明記されています。社内の既製ツールや商用デスクトップアプリを対象に考えている場合、ここで適用可否が分かれます。

反復的な refine が必要な場合がある。 1 回の /cli-anything では全機能を網羅できないことがあり、/refine の複数回実行が必要になるとされています。先に触れた「生成してから仕上げる」という運用モデルは、制約として公式に認められているものです。

この 3 点は、裏を返せば適用条件の整理にもなります。ソースコードが入手でき、frontier クラスのモデルを使える環境があり、反復のコストを許容できるなら、前提は満たせます。

ライセンスと権利関係

ライセンスは Apache-2.0 です。商用利用・改変・再配布が可能で、社内利用に関する条件のハードルは低く抑えられています。特許条項を含むライセンスであるため、企業での採用検討時に法務確認が通りやすい類型でもあります。

一方で、CLI-Hub に掲載されている個々の CLI については、権利が各ソフトウェアの所有者に帰属すると公式サイトに明記されています。CLI-Anything 本体のライセンスと、配布されているハーネスが対象とする上流ソフトウェアのライセンスは別物です。上流アプリ本体のインストールが必要になる構造上、上流側のライセンス条件も確認対象に入ります。

更新状況とロードマップの見方

メンテナンス状況の読み方には一つ注意点があります。README の News セクションの記載は 2026 年 5 月 30 日までで止まっていますが、GitHub API の pushed_at は 2026 年 9 月 22 日です。約 4 ヶ月の乖離があるため、「活発に更新されているか」を判断する根拠としては API の pushed_at を見るのが正確です。News の最終日付だけを見て更新が止まっていると判断すると、実態とずれます。

ロードマップには未完了の項目が残っています。アプリカテゴリの拡充（CAD / DAW / IDE / EDA / 科学計算）、エージェントのタスク完遂率ベンチマーク、社内・独自ソフト向けのコミュニティハーネス、Claude Code 以外のエージェントフレームワークとの統合、クローズドソース・Web サービスの API パッケージングが挙げられています。完了済みとされているのは SKILL.md の自動生成です。

ここから読み取れるのは、ベンチマークが未完了である点です。生成品質の定量評価や他手法との成功率比較は公開ドキュメントに明記がありません。採用を検討する場合、品質の見極めは自分の対象ソフトを題材に評価する工程が必要になります。

まとめ｜CLI-Anythingの採用を検討すべきケース

CLI-Anything は、対象ソフトのソースコードを解析してエージェント向けの CLI ハーネスを自動生成する OSS です。スクリーンショットとクリック座標に依存しない構造化インターフェースを、ソフトごとに量産するというアプローチを採っています。生成される CLI には --json 出力・REPL・undo/redo・実バックエンド呼び出しの検証テストが備わり、CLI-Hub という配布レジストリを通じて他者が生成したハーネスを探すこともできます。

検討する価値があるのは、次のような状況です。ソースコードが入手できるデスクトップアプリや OSS をエージェントに操作させたい場合。GUI 自動化の保守コストに限界を感じている場合。あるいは、まず既存のハーネスが CLI-Hub にあるかを確認したい場合です。ライセンスは Apache-2.0 で、社内利用の条件面のハードルは低く抑えられています。

一方で、別手段を含めて比較すべき状況もはっきりしています。対象がバイナリ配布のみのソフトウェアであれば、ソースコード解析を前提とするパイプラインの適用範囲から外れます。frontier クラスのモデルを使えない環境では、生成品質が公式の想定水準に届きません。認証・権限の統制を規格として標準化したいのであれば、MCP サーバー方式のほうが整備が進んでいます。対象が Web アプリに収まるなら、ブラウザ操作型のアプローチが素直です。

そして、押さえておきたいのは「1 コマンドで完結するツール」ではないという点です。refine を複数回回して仕上げる運用が公式の制約として明記されており、生成品質のベンチマークもロードマップ上は未完了です。導入コストを見積もる際は、初回生成だけでなく反復と検証の工数を織り込む必要があります。

次の一手としては、公式日本語ドキュメント で全体像を押さえたうえで、HARNESS.md（方法論SOP） の Critical Lessons に目を通すのが効率的です。ここに書かれている落とし穴は、CLI-Anything を使うかどうかにかかわらず、エージェントにソフトを操作させる仕組みを自作する場合にも当てはまります。並行して CLI-Hub 公式サイト で対象ソフトのハーネスが既に公開されていないかを確認すれば、自分で生成する必要があるかどうかの判断が早く付きます。

関連情報

AI エージェントを前提とした業務自動化の設計や、OSS を組み込んだシステム構成の技術選定をご検討中の方は、お問い合わせフォーム からご相談ください。要件の整理段階からご相談いただけます。

参考リンク

• HKUDS/CLI-Anything（GitHub）
• 公式日本語ドキュメント（README_JA.md）
• HARNESS.md（方法論SOP）
• QUICKSTART.md
• PUBLISHING.md
• CONTRIBUTING.md
• CLI-Hub 公式サイト
• CLI-Anything: Towards Agent-Native Computer Use（arXiv:2606.…
• modelcontextprotocol/servers
• browser-use/browser-use
• microsoft/OmniParser