個人personal

「ALL Software をエージェントネイティブに」を疑う：CLI-Anything を開けて読んでみた

朝、 HKUDS/CLI-Anything の日本語READMEを開いて、見出しを二度読みした。

CLI-Anything: Making ALL Software Agent-Native

「全ソフトウェアをエージェントネイティブに」。あらゆるGUIアプリに、AIエージェントが手を入れられる薄いガワを被せて回せる、という主張に読める。スターは34,000を超えていて、フォークも3,000を超える。香港大学のデータサイエンス系研究室（HKUDS）名義で、LightRAGなどの実績もあるアカウントだから、頭ごなしに「怪しい」とは言いにくい。

ただ、見出しに「ALL」が乗っているOSSはだいたい「ALL」ではない、という肌感だけは持っていた。中を開けてみる。

1. 何をするツールかを、見出しでなく仕組みで読む

READMEの中ほどに、7段階のパイプラインが書いてある。

  1. ソースコードをスキャンしてGUI操作を裏のAPIにマッピング
  2. コマンド体系と状態モデルを設計
  3. Click ベースのCLI（--json 出力対応）を実装
  4. テスト戦略を起こす
  5. ユニット／E2Eテストを書く
  6. テスト結果をドキュメント化
  7. PIPインストール可能なPythonパッケージに固める

ここで「ソースコードをスキャン」と書いてある時点で、対象は ソース公開済みのソフト に絞られる。さらに「実際のアプリケーションを呼び出してレンダリングする」とも明記されていて、生成されるCLIは画面操作の自動化ではなく、そのアプリがもともと持っているスクリプトAPIに薄いガワを被せる 構造だと分かる。

具体例もはっきり書かれている。

対象裏で叩いているもの
GIMPPillow + GEGL / Script-Fu
Blenderbpy（Python API）
LibreOfficeODF生成 + ヘッドレスPDF出力
AudacityPythonの波形処理 + sox

裏側のAPIが既にあるから、その上に --help と --json と REPL とアンドゥが付いた Click CLI を載せる、という話に読める。技術的には穏当だし、面白い。問題は「ALL Software」と看板を出していることだ。

2. 「ALL」が成り立たない前提条件を数える

READMEを読み込むと、前提が一気に絞られていく。

  • ソースコードが公開されていること
  • 対象アプリがマシンにインストールされていること
  • ソフトが何らかのスクリプトAPIをすでに持っていること
  • フロンティアモデル（Claude Opus 4.6級）が手元で使えること
  • 1回で網羅できない場合は /refine で反復前提

ここで素朴に質問を投げる。Photoshop に効くか。Excel に効くか。AutoCAD に効くか。SAP に効くか。全部「効かない」。ソースが閉じている時点で1段目のパイプラインが回らない。READMEに並んでいる対応ソフトを数えると、 GIMP・Blender・Inkscape・Audacity・LibreOffice・OBS・Kdenlive・Shotcut・Draw.io・Zoom・AnyGen・Nsight Graphics で12個前後。世の中の業務ソフトの大半は、そもそも入口に立てない。

つまり正しい肩書きは「ALL Software をエージェントネイティブに」ではなく、「スクリプトAPIを持つ一部のOSS GUIアプリに、AI で CLI ガワを自動生成するツール」だ。前者と後者では、できることの範囲が二桁違う。

3. スター数の伸びが説明できない

スターと作成日を並べる。

  • 作成: 2026-03-08
  • 5月時点のスター: 34,464
  • フォーク: 3,375

2ヶ月で34,000は、本当にこの内容で集まる数ではない。LightRAG はじめHKUDSの他リポジトリも見たけれど、ここまでの初速はついていない。READMEの完成度が高いのも引っかかる。最初のコミットからこの粒度のドキュメントが出てくるとき、裏でマーケティングのチームが回っているか、Xや微博のAI系インフルエンサーに大量に共有されたか、あるいはスター買いか、のどれかの可能性が立つ。どれだとしても、スター数を品質の代理指標として使ってはいけない信号として読む。

4. AIインフルエンサーの紹介を一次資料として読まない

ここから自分への戒め。

X や YouTube の AI 系発信者は、新しいツールを「全部のソフトに効く」「次世代の標準」と言い切ってバズらせる仕事をしている。彼らは検証しないし、検証する時間もないし、検証してもバズらないから検証しない。タイトルが派手で、デモが派手で、スターが派手なリポジトリは、紹介動画が回りやすい順に並んでいる。

そこに釣られないために、自分用のチェック手順を言語化しておく。

  1. 見出しの主語と修飾語を疑う。 "ALL" "Anything" "Universal" "Any" が乗っていたら、まずREADMEで前提を数える。前提を5つ以上挙げられたら看板はだいたい嘘。
  2. 「何が裏で動いているのか」をREADMEから抜き出す。CLI-Anything なら「実際のアプリのスクリプトAPIを叩く」と書いてある。ここが書かれていない、もしくは曖昧なツールは、デモ動画だけで判断しない。
  3. 対象リストの個数を数える。「ALL」と書きつつ、対応ソフトを書き出すと12個、というギャップは「ALL」ではない。
  4. 作成日とスター数を並べる。2ヶ月で5桁スターは、内容ではなくチャネルが効いている可能性が高い。
  5. 作者の他リポジトリと比較する。同じ作者の他リポジトリと同じ初速か、それを大幅に超えているか。超えているなら何がブーストしたかを考える。
  6. Issueを開く。中身の濃いIssueが少なく、★だけ多いリポジトリは、使われているより共有されているだけのことが多い。

CLI-Anything に関して言えば、技術的なアイディアは面白いし、Click CLI を AI で量産するという発想は応用が利く。ただ、「ALL Software」の看板ごと飲み込むと、後で「あれ、Photoshop には効かないんですか」と恥をかく。看板を割引いて読めば、ちゃんと使い所のあるツールだ。

5. 税理士・会計士視点での投影

業務ソフトでこの構造を応用しようとすると、対象になるのは「ヘッドレスCLIや公式API、スクリプト機能を持ったツール」に限られる。

  • freee／マネーフォワード → 公式API があるので、ガワ生成より直接叩いた方が早い
  • Microsoft 365（Excel・Word・Outlook） → Graph API／PowerShell モジュール経由なら自動化可能
  • JDL・弥生・勘定奉行などの会計パッケージ → スクリプトAPIが乏しく、画面自動化（pyautogui／RPA）に逃げざるを得ない
  • TKCのFX2／FX4クラウド → 同上

「CLIを自動生成してエージェントに渡す」発想がそのまま効くのは Microsoft 365 のような土俵で、業界専用パッケージは別の戦い方になる。ここを混ぜないことが、自分の業務に持ち込むときの最初の整理になる。

結び

派手な見出しのリポジトリに出会ったとき、自分がやるべきは「凄そうかどうか」を判定することではなく、「前提を数える」ことだ。前提を5つ書き出した瞬間に、看板の半分は剥がれる。残った半分が、本当に使えるツールかどうかを決める。

AIインフルエンサーは前提を数えない。自分は数える側に回る。