Claude Code全体の使い方は Claude Code完全ガイド2026：インストールから本番運用まで をご覧ください。
01 CLI-Anythingが解く「AIエージェント × プロ向けソフト」のギャップ
香港大学のデータサイエンスラボHKUDSが公開した CLI-Anything は、2026年5月時点でスター34.7k・フォーク3.4kを集めるOSSだ。プロジェクトのキャッチコピーは「Making ALL Software Agent-Native」。GIMP、Blender、LibreOffice、Audacityといったソースコード公開済みのプロ向けソフトを、AIエージェントが扱えるCLIへ自動変換する枠組みを提供する。
ここで解こうとしている問題は明確だ。Claude CodeやGitHub Copilot CLIなどのAIエージェントは、コードベース操作・シェルコマンド・WebAPIの呼び出しには長けている。しかしGIMPで画像合成をしたい、Blenderで3DレンダリングしたいといったGUI前提のソフトに踏み込むと、急に手段がなくなる。
選択肢は3つ。GUI自動化（座標クリックや画像認識）、各ソフト個別のAPI（Python拡張やJSONプロトコル）、そして簡略化されたOSS再実装だ。いずれも問題が大きい。GUI自動化は壊れやすく、APIは網羅性に欠ける。再実装は本物のレンダラーを失う。CLI-Anythingが目指すのは「本物のソフトウェアをそのまま、AIエージェント向けCLIで包む」という第4の道だ。
仕組みを単純化すると次のようになる。ユーザーがClaude Codeに/cli-anything ./gimpと命じると、CLI-Anythingは対象ソフトのソースコードを読み込み、7段階の自動分析・実装パイプラインを走らせる。最終的にcli-anything-gimpのような専用CLIコマンドがPATHに追加され、Claudeからcli-anything-gimp --json layers add ...のような構造化呼び出しができるようになる。
# Claude Codeに導入してGIMPをCLI化する最短コマンド
/plugin marketplace add HKUDS/CLI-Anything
/plugin install cli-anything
/cli-anything ./gimp
3行目を実行すると、ローカルにクローンしたGIMPリポジトリに対して分析→設計→実装→テスト計画→テスト記述→ドキュメント→公開の7フェーズが順に走る。完成するとpip install -e .でインストール可能なClickベースのPythonパッケージがagent-harness/配下に生成される。
- HKUDSが公開したスター34.7kのOSSで、プロ向けソフトをAIエージェント対応CLIに自動変換する
- GUI自動化や限定的APIに頼らず、本物のソフトを構造化CLIで包む第4の道を提案
- Claude Codeプラグインとして配布され、3行のスラッシュコマンドで導入完了
02 7フェーズ自動生成パイプライン — ソースコードからCLIまでの内部構造
CLI-Anythingの中核はHARNESS.mdと呼ばれる方法論ドキュメントに集約されている。これはClaude Codeに対するSOP（標準作業手順書）であり、対象ソフトに対してどの順番で何を分析・実装するかを規定する。HKUDSの記述によれば、これは「The methodology SOP — single source of truth」と位置付けられている。
パイプラインの7フェーズは次の通り。
- Phase 1 Analysis：対象リポジトリのソースをスキャンし、機能カテゴリと外部から触れるエンドポイントを洗い出す。
- Phase 2 Design：洗い出した機能をCLIのコマンドツリーへマッピングする。グループ・サブコマンド・オプションを設計する。
- Phase 3 Implementation：PythonのClickフレームワークでCLI本体を実装する。REPLモードとサブコマンドモードの両方を構築する。
- Phase 4 Test Planning：TEST.mdを生成し、ユニット・E2E・サブプロセス検証の3層でテスト方針を定義する。
- Phase 5 Test Writing：実際のテストコードをpytestで書く。本物のソフトを呼ぶE2Eテストも含む。
- Phase 6 Documentation：生成されたCLIの使用例・JSON出力例・既知の制約をドキュメントに反映する。
- Phase 7 Publishing：setup.pyとSKILL.mdを生成し、`pip install -e .`でPATHへ登録、エージェントが発見できる状態にする。
設計面で重要なのは、各フェーズの出力が次のフェーズの入力として明示的に消費される点だ。Phase 1で生成された分析メモを読まずにPhase 3で実装に飛ぶ、といった近道は許容されない。これによりClaudeが対象ソフトに対する理解を段階的に積み上げる構造が保たれる。
ソフトウェアごとの差異を吸収するためにHARNESS.mdが用意している抽象が「rendering gap」概念だ。GUIアプリケーションは多くの場合、画面上のエフェクトと最終出力（ファイルへのエクスポート）でレンダリング経路が異なる。フィルター適用、タイムコード精度、エクスポート時の色変換などが該当する。CLI-Anythingは「exit codeが0であってもファイル内容を検証する」という方針を徹底することで、見かけだけ成功するCLIを排除している。
(例: GIMP)"] --> P1["Phase 1
Analysis"] P1 --> P2["Phase 2
Design"] P2 --> P3["Phase 3
Implementation"] P3 --> P4["Phase 4
Test Plan"] P4 --> P5["Phase 5
Test Write"] P5 --> P6["Phase 6
Docs"] P6 --> P7["Phase 7
Publish"] P7 --> OUT["cli-anything-gimp
+ SKILL.md"]
エンジニアから見て新鮮なのは、このパイプラインの大部分がClaude Code自身によって自律的に駆動される点だ。CLI-Anythingプラグインがやっているのは「7フェーズの順序と各フェーズの目的をClaudeに教える」ことで、各フェーズの実装そのものは対象ソフトに応じてClaudeが書く。プラグイン側にハードコードされた変換コードは最小限に抑えられている。
- HARNESS.mdが7フェーズSOPを定義し、Analysis→Design→Implementation→Test→Docs→Publishの順に進む
- 各フェーズの出力が次の入力に明示的に消費され、近道を許さない構造で理解を積み上げる
- 「rendering gap」概念によりexit code依存を排除し、ファイル内容検証を必須化
03 38アプリ・2,280テスト — 対応ソフトウェアの全体像
2026年4月末時点でCLI-AnythingがCLI化した実績は38アプリケーション・2,280テスト・100%パス率に達している。テストの内訳はユニットテスト1,682本、E2Eテスト579本、Node.js連携テスト19本で、E2Eは本物のソフトを起動して結果ファイルを検証するため、CI実行時間は短くない。
カテゴリ別の代表例を整理すると次の表になる。テスト本数は対象ソフトのCLI表面積（コマンド数）にほぼ比例している。
| カテゴリ | ソフト名 | テスト数 | 特徴 |
|---|---|---|---|
| クリエイティブ | Blender | 208 | 3Dシーン操作・物理シミュ・Cyclesレンダリング |
| クリエイティブ | Inkscape | 202 | SVGベクター編集・パス変形・テキスト変換 |
| クリエイティブ | GIMP | 107 | レイヤー・選択・フィルター・エクスポート |
| クリエイティブ | Audacity | 161 | 波形編集・ノイズ除去・エンベロープ |
| 映像 | Kdenlive | 155 | NLEノンリニア編集・タイムライン操作 |
| 映像 | Shotcut | 154 | MLT XMLベース動画編集 |
| オフィス | LibreOffice | 158 | Writer/Calc/Impressの全モジュール対応 |
| 図解 | Draw.io | 138 | ノードグラフ・図形配置・スタイル指定 |
| AI/ML | Ollama | 98 | ローカルLLMのモデル管理・推論 |
| AI/ML | ComfyUI | 70 | ノードベース画像生成ワークフロー |
| ゲーム | s&box | 244 | Facepunch製ゲームエンジンの全API |
LibreOfficeの158テストは、Writer・Calc・Impress・Drawの全モジュールを横断的にカバーしている。動詞単位で分割するとdocument new / add-heading / add-paragraph / insert-table / export renderのようなコマンドが揃い、Claudeから自然言語経由で「四半期レポートを書いて」と頼むだけで、表題・段落・表・PDFエクスポートまで一気通貫で実行できる構造になっている。
s&boxの244テストはこのプロジェクトで最大の表面積を持つCLIだ。Facepunch Studios（Rust開発元）のゲームエンジンであるs&boxは、エンジンサイドのAPIが豊富で、エンティティ操作・物理・ライティング・UIの各層をすべてカバーしているため、テスト数が膨らんでいる。
ゲーム開発・映像編集・3DCG・オフィス・図解・LLM運用と、これだけ異質なソフトウェアを「同じCLI規約・同じREPL作法・同じJSON出力フォーマット」で揃えているのが、CLI-Anythingの最大の価値だ。Claude Codeから見ると、対象ソフトの内部実装の違いを意識せず、共通スキーマで命令を出せる。
CLI-Anythingは対象ソフトを「本物として呼ぶ」前提なので、対象ソフトのインストールとライセンス遵守はユーザー側の責任になる。商用ソフトをCLI化する場合は再配布制限・商用利用条項を必ず確認すること。CLI-Anything本体はApache 2.0だが、生成されたCLIが触る対象ソフトのライセンスは別軸の問題だ。
- 2026年4月末で38アプリ・2,280テスト・100%パス率、E2EはBenderやGIMPを本物として呼ぶ
- クリエイティブ・映像・オフィス・図解・AI/ML・ゲームと、異質なソフトを同じ規約で揃えている
- 対象ソフトのライセンスと再配布条件はユーザー側の責任、Apache 2.0は本体のみ
04 Claude Codeでのインストールと最初のCLI生成
実際に動かす手順を見ていく。Claude Code 2.x系（プラグイン機構が安定版になったバージョン）と、CLI化したい対象ソフトのソースコード（ローカルクローン）が手元にある前提で進める。
第一段階はマーケットプレイス登録とプラグインインストールだ。Claude Codeのチャット上から2行のスラッシュコマンドで完了する。
# 1. HKUDSのマーケットプレイスを登録
/plugin marketplace add HKUDS/CLI-Anything
# 2. cli-anythingプラグインをインストール
/plugin install cli-anything
インストールが終わると、Claude Codeのスキル一覧にcli-anythingが追加される。同時に補助コマンドも利用可能になる。利用頻度の高い4つを整理しておく。
| コマンド | 目的 |
|---|---|
/cli-anything <path> |
7フェーズすべてを実行し、ゼロから完全なCLIを生成 |
/cli-anything:refine <path> |
既存ハーネスの未カバー領域を拡張する |
/cli-anything:test <path> |
テストを再実行し、TEST.mdを更新する |
/cli-anything:validate <path> |
HARNESS.md規約への準拠を検証する |
第二段階は対象ソフトのソースコードを指定して生成を回すこと。たとえばGIMPをCLI化するなら、事前にGIMPのリポジトリをクローンし、そのパスをClaude Codeに渡す。
# 1. 対象ソフトをローカルにクローン
git clone https://github.com/GNOME/gimp.git ./gimp
# 2. Claude Codeのチャットから生成を開始
/cli-anything ./gimp
実行中、Claudeは作業ディレクトリ./gimp/agent-harness/配下に分析メモ、設計ドキュメント、Click実装、pytestスイート、SKILL.mdを順番に書き出していく。完了までには対象ソフトの規模に応じて十数分から1時間程度かかる。
第三段階は生成されたCLIのインストールと動作確認だ。agent-harness/配下にPythonパッケージとしてsetup.pyが生成されているので、開発インストールして即座に使える。
# 生成されたCLIをローカルインストール
cd gimp/agent-harness
pip install -e .
# 対話REPLモードで起動
cli-anything-gimp
# 単発コマンドモードで起動（エージェント連携向け）
cli-anything-gimp --json layers list
cli-anything-gimp --json filters blur --radius 8 --input photo.png --output blurred.png
--jsonフラグが重要で、これを付けると標準出力がJSONになり、エラーは構造化エラーオブジェクトとして返る。Claude CodeやGitHub Copilot CLIのようなエージェント側は、このJSONをパースして次のステップを判断する。テキスト出力モード（フラグなし）は人間向けで、色付き表とプログレスバー、エラー時の助言メッセージを表示する。
最初はGIMPやBlenderのような大きなソフトではなく、Mermaid（テスト10本）やDify Workflow（テスト11本）のように小規模なソフトでパイプラインを試すと、生成完了までが速く全体像を把握しやすい。生成物のディレクトリ構造、SKILL.mdの形、テスト実行の出力に慣れてから本命ソフトに進むのがおすすめだ。
- 導入は
/plugin marketplace addと/plugin install cli-anythingの2行で完了 - 主要4コマンド（cli-anything・refine・test・validate）が用途別に揃っている
- 生成後は
pip install -e .でPATHに登録、--jsonフラグでエージェント連携モードに切替
05 LibreOffice実例とBlender実例 — JSON出力でエージェント連携
具体的な使用感を見るため、READMEに掲載されている2つの定番例を読み解いていく。1つ目はLibreOfficeで構造化ドキュメントを作る例、2つ目はBlenderで3Dシーンを構築してレンダリングする例だ。どちらも本物のLibreOffice／Blenderを背後で起動し、最終的に有効なファイル形式（ODF・PNG）を出力する。
LibreOfficeの実例は次の3コマンドで構成される。
# 1. 新規Writerドキュメントを作成
cli-anything-libreoffice document new -o report.json --type writer
# 2. レベル1の見出しを追加
cli-anything-libreoffice --project report.json writer add-heading -t "Q1 Report" --level 1
# 3. PDFにエクスポート
cli-anything-libreoffice --project report.json export render output.pdf -p pdf
最初の行でプロジェクトファイルreport.jsonを作るのが特徴だ。CLI-Anythingが採用しているのは「中間状態をJSONで保持し、最後にレンダラーへ流す」パターン。これによりClaudeから複数ステップで段階的に編集する操作が、エージェント側でべき等に扱える。--projectフラグでJSONプロジェクトファイルを渡し、コマンドが状態を更新していく。
2行目のadd-headingでは、Writerのスタイル体系（Heading 1〜6）に対応するレベル指定が可能で、Q1 ReportというH1見出しが追加される。続けてadd-paragraph、insert-table、insert-imageなどを並べることで本格的なドキュメントを構築できる。
3行目のエクスポートで本物のLibreOfficeがheadlessモードで起動し、JSON状態をODFに変換、その後LibreOfficeのPDFエクスポート機構を経由してPDFが書き出される。「JSON状態 → ODF → PDF」という2段階変換になっているが、これはWordやMarkdownからの単純変換ではなく、本物のLibreOfficeレイアウトエンジンを通すためにとられた構造だ。
Blenderの実例はREPLモードで進行する。cli-anything-blenderと入力するとプロンプトが起動し、対話的にシーンを構築する。
$ cli-anything-blender
blender> scene new --name ProductShot
blender> object add-mesh --type cube --location 0 0 1
blender> render execute --output render.png --engine CYCLES
scene newで新規シーンを作成し、object add-meshで立方体を高さ1mの位置に配置、render executeでCyclesレンダラーを起動してrender.pngに書き出す。エンジンとしてCYCLESを指定すると、Blender本体がインストールされているマシンならGPUレイトレーシングが走る。EEVEEに切り替えればリアルタイムレンダラーが使われる。
REPLモードが提供する価値は「セッション状態の保持」だ。Blenderのシーンはコマンド間で常駐し、変数として保持される。シングルショットコマンドだと毎回シーンファイルを読み書きする必要があるが、REPL中はメモリ上のシーンを直接操作できる。複数オブジェクトを段階的に配置・調整するワークフローでは、REPLの方が圧倒的に速い。
Claudeから自動操作するときは、対話モードではなく単発コマンドモードを使う。READMEには明記されていないが、--jsonフラグと組み合わせた次のような呼び出しが標準パターンだ。
# Claudeから自動制御するときのBlender呼び出し
cli-anything-blender --json scene new --name ProductShot
cli-anything-blender --json object add-mesh --type cube --location 0 0 1
cli-anything-blender --json render execute --output render.png --engine CYCLES
各呼び出しが独立して動くため、内部でBlenderプロセスを毎回起動するオーバーヘッドが発生する。シーン規模が大きい場合は、Claudeが.blendファイルとして中間状態を保存し、次の呼び出しでロードし直す設計を取ることが多い。
- LibreOffice例はJSONプロジェクトファイルで状態を保持し、最後に本物のLibreOfficeでPDFを書き出す
- Blender例はREPLモードでセッション状態を保ち、対話操作と単発操作の両方を提供する
- Claudeから自動操作する際は
--jsonフラグで構造化出力を受け取り、次の判断に渡す
06 SKILL.md・HARNESS.md・CLI-Hub — エコシステムを支える3つの仕組み
CLI-Anythingが「単発のCLI集」を超えてエコシステムになっている理由は、3つのドキュメント／レジストリの仕組みにある。SKILL.md、HARNESS.md、そしてCLI-Hubだ。
第一にSKILL.md。各CLIにはskills/cli-anything-<software>/SKILL.mdという規約パスでスキル定義が同梱される。YAMLフロントマターでスキル名・適用条件・利用例を宣言し、本文にコマンドグループの説明・JSON出力例・エラーハンドリングのガイダンスを書く。これはAnthropic Claude Skillsの規約に準拠しており、Claude Codeから自動的に発見・読み込みされる。
SKILL.mdの典型構造は次のようになる。
---
name: cli-anything-gimp
description: GIMPで画像のレイヤー操作・フィルター適用・エクスポートを行う場合に使う
---
# GIMP CLI
このCLIは本物のGIMPを呼び出して画像処理を実行する。
## 主要コマンドグループ
- `layers`: レイヤーの追加・削除・順序変更
- `filters`: ガウスぼかし、エッジ強調、色補正
- `export`: PNG/JPEG/WebPへの書き出し
## JSON出力例
```json
{"status": "success", "layer_id": "layer-2", "name": "Background"}
第二に<span class="marker-green">**HARNESS.md**</span>。これは「How to build a CLI for any software（任意のソフトに対するCLIの作り方）」という方法論ドキュメントで、Phase 1〜7の各フェーズで踏むべき手順・避けるべき罠を体系化している。新規ソフトをCLI化したいときも、Claudeはこのドキュメントに沿って自律的に作業する。
HARNESS.mdが規定している重要な原則は、たとえば次のようなものがある。
<div class="box-tip">
<strong>HARNESS.md主要原則の抜粋</strong>
<ul>
<li>レンダリングはモック禁止、本物のソフトを使う（Authentic Software Integration）</li>
<li>GUIエフェクトはエクスポート時にも適用される前提でフィルター変換を扱う</li>
<li>タイムコード精度（フレーム/秒のドリフト）はCLI実装時に必ず明示する</li>
<li>出力検証はexit codeに依存しない、ファイル内容そのものをチェックする</li>
<li>ステートフルREPLとサブコマンドモードの両方を提供する</li>
</ul>
</div>
第三に<span class="marker-pink">**CLI-Hub**</span>。これは2026年4月15日にv0.2.0が公開されたパッケージマネージャで、`pip install cli-anything-hub`でインストールできる。Claude Codeからは「ハブ」というメタスキルとして呼び出され、利用可能なCLI-Anythingハーネスをブラウズ・検索・インストール・更新できる。
```bash
# CLI-Hubのインストール
pip install cli-anything-hub
# 利用可能なハーネス一覧を表示
cli-anything-hub list
# 特定のソフト向けCLIをインストール
cli-anything-hub install blender
cli-anything-hub install ollama
CLI-Hubは内部に2つのレジストリを持つ。HKUDS公式のcli-anything-registryと、コミュニティが投稿できるpublic_registry.jsonだ。後者はpip・npm・brewといった複数のインストールソースに対応していて、サードパーティの開発者が自前のCLI実装をハブに登録できる。「Claude Code側から見ると、対象ソフト名を指定するだけでCLI実装が手に入る」という体験がCLI-Hubで実現する。
3つの仕組みの関係を整理すると、HARNESS.mdが「作り方」、SKILL.mdが「呼び方」、CLI-Hubが「配り方」を担当している。生成・記述・流通の3層が分離されているため、新しい対象ソフトを追加するときも、既存ソフトを修正するときも、影響範囲が小さい。
- SKILL.mdはClaude Codeから自動発見されるスキル定義で、CLI使用条件と出力例を含む
- HARNESS.mdは7フェーズの方法論SOPで、新規対象ソフトへの拡張をClaudeが自律遂行できる
- CLI-Hubは2026年4月v0.2.0公開のパッケージマネージャで、コミュニティ投稿も受け入れる
07 設計思想「Zero Compromise」と運用上の注意
CLI-Anythingが他の類似プロジェクトと一線を画している部分が「Zero Compromise Dependencies」という設計原則だ。READMEで明示されているのは「本物のソフトが利用できないときはテストが失敗する。優雅に劣化しない（Real software is mandatory; tests fail when backends unavailable）」という方針。これはエンジニアリング上の判断としては保守的に見えるが、AIエージェントが本番運用する際の信頼性を担保するための強い選択だ。
優雅な劣化を許すと何が起きるか。たとえばBlenderがインストールされていない環境でrender executeを呼ぶと、フォールバックでダミー画像を出力するような実装も技術的には可能だ。しかしダミー出力を本物の出力と区別できなければ、エージェントは虚偽の成功を信じて次のステップへ進む。最終的な成果物に致命的な不一致が混入する。CLI-Anythingはこのリスクを排除するため、依存ソフトが欠けたときは明示的に失敗する設計を選んでいる。
設計原則は他にも次のようなものがある。
本物のソフトをそのまま呼ぶ"] ROOT --> B["2. Flexible Interaction Models
REPL + サブコマンドの両立"] ROOT --> C["3. Consistent User Experience
全CLIで共通の規約"] ROOT --> D["4. Agent-Native Design
--jsonフラグで構造化出力"] ROOT --> E["5. Zero Compromise Dependencies
劣化させずに失敗する"]
運用上の注意点として、エンジニアが事前に把握しておくべきトピックを3つ挙げる。
第一に対象ソフトのインストールサイズと起動時間。Blender本体は2GB前後、LibreOfficeは1.5GB前後、Krita・Inkscape・GIMPもそれぞれ数百MBある。GitHub ActionsやCloud Buildのような共有CI環境でCLI-Anything生成CLIを動かそうとすると、依存セットアップだけで5〜10分かかる。CIで使うならbase imageに対象ソフトを焼き込む方が現実的だ。
第二にライセンスの取り扱い。CLI-Anything本体はApache 2.0だが、生成されたCLIが触る対象ソフトは別ライセンスだ。GIMPはGPL v3、LibreOfficeはMPL v2、Blenderは2026年現在GPL v3互換だが、商用ソフト（Adobe製品、Autodesk製品など）にCLI-Anythingを適用すると配布段階で問題になる。基本的にOSS対象ソフトに留めるのが安全だ。
第三にコマンド表面積の管理。s&boxの244テストやBlenderの208テストが示すように、対象ソフトが大きいと生成CLIのコマンド数も膨らむ。Claudeに自由に使わせるとコマンド選定で迷子になりやすい。実運用ではユースケースを絞り、SKILL.mdのdescription欄に「このCLIはレポートPDF生成用」のように利用文脈を明示しておくと、Claudeの選択ミスが減る。
CLI-Anythingが向いているケースと向いていないケースを最後に表で整理しておく。
| ケース | 向き不向き | 理由 |
|---|---|---|
| Claude CodeでGIMP/Blenderを動かしたい | 向く | 専用CLIとSKILL.mdが揃う |
| 自社プロダクトをエージェント対応させたい | 向く | パイプラインを自社リポジトリに適用可能 |
| 商用ソフト（Photoshop等）を操作したい | 向かない | ライセンス上の制約と配布制限 |
| GUIに依存する操作のみ自動化したい | 向かない | CLI化できない領域は対象外 |
| 簡単な画像処理だけしたい | 向かない | ImageMagickやPillowで十分 |
CLI-Anythingリポジトリ は2026年5月時点で活発に更新されており、4月だけでQGIS・Uni-Mol Tools・Obsidian・Zotero・n8nといった新規CLIが続々と追加されている。AIエージェント全体の動向については AIエージェントフレームワーク徹底比較2026 も参考になる。スキル設計の基本については Claude Skillsを徹底解説、Claude Code開発者の設計思想に踏み込みたい場合は Claude Codeアーキテクチャ・ブループリント を併読すると、本記事の内容が縦に繋がる。
- Zero Compromise Dependenciesは「劣化させずに失敗する」原則で、エージェント運用の信頼性を担保
- 5つの設計原則は本物のソフト統合・REPL/サブコマンド両立・共通UX・JSON出力・劣化禁止
- CIサイズ・対象ソフトライセンス・コマンド表面積の3点が実運用での主要な注意項目
関連記事
- Claude Code完全ガイド2026：インストールから本番運用まで
- Claude Skillsを徹底解説
- Claude Codeアーキテクチャ・ブループリント
- AIエージェントフレームワーク徹底比較2026
