CLIの復権：Cloudflareが「すべてをコマンドラインで」と決断した本当の理由
CLIの復権：Cloudflareが「すべてをコマンドラインで」と決断した本当の理由
AIエージェントはGUIをクリックしない。ならば、マウス操作を前提に設計された今の開発者ツールは、AI時代を生き残れるのか。
はじめに
2026年4月、Cloudflareが静かながら象徴的な発表を行った。100以上の製品と約3,000のHTTP APIを持つこの企業が、プラットフォーム全体を統括する単一のコマンドラインインターフェース（CLI）を公開したのだ。名称はシンプルにcf。インストールはnpx cfの一行で済む。
表向きには、便利な開発者ツールの新作に過ぎないように見える。しかし、Cloudflareが公式ブログで明かしたリリースの背景を読むと、話は変わってくる。彼らはこう語る。「AIエージェントがAPIの主要な利用者になりつつある」。つまりcf CLIは人間の開発者のためでもあるが、根本的にはAIエージェントがCloudflareを操作できるように設計されたインターフェースなのだ。
この宣言は、単なる製品リリースを超えた意味を持つ。2010年代を通じてGUIとWebダッシュボードが開発者ツールの標準となって以来、なぜ今になって主要プラットフォームが再びCLIへ回帰しているのか——その問いを否応なく突きつける。そして答えは、想像以上に構造的なところにある。
CLIは本当に復活しているのか：数字で見るルネサンス
感覚的に感じる以上に、CLIツールの復活はすでにデータで裏付けられている。
Stack Overflowが毎年実施する開発者調査によると、業務時間の半分以上をターミナルで過ごすプロフェッショナル開発者の割合は、2023年の62%から2025年には78%へと増加した。2年間で16ポイントの上昇だ。これは単に「CLIが好きな開発者が増えた」という嗜好の変化ではない。開発ワークフロー全体がターミナル中心へと再編されているという構造的なシグナルである。
さらに劇的な証拠はGitHubから来ている。OSS Insightの分析データによれば、2026年第1四半期（Q1 2026）だけで、既存ソフトウェアをCLIインターフェースでラップすることを目的とした主要なオープンソースリポジトリが6つ立て続けに公開された。そしてこの6つが、わずか90日で合計13万以上のGitHubスターを獲得した。
具体的な数字を見ると、さらに驚かされる。
| リポジトリ | スター数 | 期間 | 日次スター | フォーク率 |
|---|---|---|---|---|
| CLI-Anything | 25,219 | 23日 | 1,096/日 | 8.96% |
| agent-browser | 25,812 | 79日 | 327/日 | 6.06% |
| Google Workspace CLI | 23,219 | 29日 | 801/日 | 4.90% |
| opencli | 9,236 | 17日 | 543/日 | 8.37% |
「興味があったのでスターを押した」だけではないことは、フォーク率が物語っている。CLI-Anythingのフォーク率は8.96%だ。スターを押した100人のうち約9人が実際にリポジトリを自分の手元にコピーして持ち帰った計算になる。オープンソース生態系においてこのレベルのフォーク率は、「眺めた」ではなく「実際に使った、あるいは改造した」に近い意味を持つ。
この時期は偶然ではない。2025年後半からAIコーディングエージェントが実際の開発現場に本格投入され始めたタイミングと正確に重なる。AIがツールを「使い始めた」ことで、ツールのインターフェースが何であるかという問題が、突然重要になったのだ。
Cloudflareだけではない。同じ時期、GoogleはGoogle Workspace全体を統括するCLIを公開し、29日間で23,000スターを集めた。Vercel CEOのギジェルモ・ラウチは2026年4月、AIエージェント由来の売上急増を背景にIPO準備が整ったことを示唆しており、Vercel CLIはそのエージェント統合の中核として機能している。開発者ツール業界全体が、一つの方向へ動いている。
なぜ今、なぜCLIなのか：エージェントとインターフェースの根本問題
この現象を理解するには、まずAIエージェントがソフトウェアをどのように「使う」のかを把握する必要がある。
人間の開発者はWebダッシュボードにアクセスし、メニューを探し、ボタンをクリックし、フォームを埋める。この過程で人間の視覚認識・文脈理解・マウス操作能力が不可欠に介在する。GUIはその能力を前提として設計されている。
AIエージェントは違う。エージェントはテキストを受け取り、テキストを返す形で動作する。画面を「見る」ことが不可能ではないにしても（スクリーンショットベースのエージェントも存在する）、その方式は遅く、不安定で、トークンコストが大きい。一方CLIは、エージェントが最も得意とする方式——テキストコマンドをそのまま実行——に完全に合致する。cf r2 bucket list --jsonというコマンドをエージェントが直接実行すれば、結果は構造化されたJSONで返ってくる。パースが容易で、次のステップへの受け渡しも簡単だ。エラーハンドリングも予測可能である。
Cloudflare CLIの設計原則が示すもの
Cloudflare CLIの三つの設計原則は、この文脈で読むと単なるUXガイドラインではなく、エージェントフレンドリーな設計宣言として読める。
第一に、一貫性（consistency）。「あるコマンドがinfoを使い、別のコマンドがgetを使えば、エージェントは一貫性を期待するがゆえにミスを犯す」——これをCloudflareはスキーマレベルで強制する。すべてのコマンドで--jsonは常にサポートされる。強制実行フラグは--forceのみだ。この一貫性は人間にも便利だが、エージェントにとっては事実上の必須条件である。予測不可能なインターフェースの上に、信頼できる自動化は構築できないからだ。
第二に、ローカル・リモート対称性（local-remote symmetry）。Cloudflare CLIは--localフラグ一つで、同じコマンドがリモートのCloudflareインフラではなくローカル開発環境で動作するように切り替わる。cf kv get mykeyがリモートのKVストアを参照するなら、cf kv get mykey --localはローカル開発サーバーのKVストアを参照する。コマンド体系が同一なので、エージェントは環境（開発/本番）に応じて別のインターフェースを学習する必要がない。この設計により、エージェントが開発・テスト・デプロイのサイクル全体を自律的に処理できるようになる。
第三に、単一ソースのコード生成（single-source codegen）。おそらく最も興味深い点だ。CloudflareはこのCLIを、TypeScriptベースの単一スキーマから、CLIコマンド・API SDK・Terraformプロバイダー・そしてMCP（Model Context Protocol）サーバーを同時に自動生成するように設計した。MCPはAIエージェントが外部サービスと通信するために使う標準プロトコルだ。つまり、CLIを作ることが即ちAIエージェント統合インターフェースを作ることと等しくなる構造である。インターフェースを一度定義すれば、人間の開発者向けCLIとエージェント向けMCPサーバーが同時に生成される。
この三原則を総合すると、Cloudflareが単に開発者の利便性のためにCLIを作ったのではないことが明確になる。彼らは今後、APIの主要な利用者が人間ではなくエージェントになることを前提に、それに見合ったインターフェースを先制的に構築しているのだ。
GUIのパラドックス：使いやすいほど自動化が難しい
ここで一つの逆説的な事実が浮かび上がる。GUIは人間に直感的であるために、無数の暗黙的な文脈（視覚的階層、カラーコーディング、ホバー状態、アニメーションフィードバック）に依存している。この暗黙的文脈こそが、自動化を困難にする要因だ。スクリーンリーダーがWebサイトを読み取るのが難しいのと同様に、AIエージェントがGUIを通じてソフトウェアを制御することは根本的に非効率である。
一方、CLIのテキストベースのインターフェースは「制約」のように見えるが、その制約こそが自動化親和性の源泉だ。入力がテキストで出力がテキストであれば、エージェントがパイプラインに割り込むのは容易だ。シェルスクリプトが数十年間生き残ってきた理由がここにあり、AIエージェントはその生態系をさらに一段階拡張するものだ。
開発者と企業が受け取るべき示唆
このトレンドが実際に加速するなら、開発者と企業の双方に具体的な含意がある。
開発者の視点：ターミナルスキルが再び核心技術として浮上しつつある。2010年代半ば以降「すべてをGUIで」という流れの中でCLIの習熟度が相対的に軽視されてきたとすれば、今後は逆転する可能性が高い。特にAIエージェントと協働する開発者であれば、自分が作るツールやシステムがエージェントフレンドリーかどうかを最初から考慮する必要がある。「この機能はCLIから呼び出せるか」「出力はJSONか」「エラーコードは一貫しているか」——これらの問いが設計チェックリストに加わるべき時が来ている。
プラットフォーム/SaaS企業の視点：Cloudflareの動きは、SaaS企業に明確なシグナルを送っている。Webダッシュボードをどれだけ美しく作り込んでも、AIエージェントが扱えない機能は、エージェント時代において事実上存在しない機能になる。特に開発者を主要顧客とするB2D（Business to Developer）SaaSであれば、CLIとAPIインターフェースの品質と一貫性が競争力の直接的な要因となる。「エージェントが使えるか」が新たな製品評価基準として定着しつつある。
インフラ/クラウド企業の視点：CLI-firstの設計は、単にエージェントサポートにとどまらず、自動化パイプライン全体との統合を容易にする。CI/CD、IaC（Infrastructure as Code）、監視スクリプトなど、テキストベースの自動化が標準であるDevOps環境において、CLIはすでに「自動化フレンドリー」だ。AIエージェントはその生態系をさらに拡張する。Terraform、Ansible、kubectlのようにCLIが業界標準となったツールに共通するのは、明確な入出力インターフェースと構造化されたエラー処理だ。Cloudflareが目指す方向がまさにそこにある。
ただし、現実的な注意点も一つある。CLIの一貫性と予測可能性がエージェントに有利だとしても、GUIが不要になるという意味ではない。複雑な設定を初めて探索する場合、視覚的フィードバックが必要な場合、チームの非エンジニアが使う場面では、依然としてGUIのほうが適している。Cloudflare CLI自身も「Local Explorer」というWeb UIベースの探索ツールを併せて提供している。このトレンドは「CLI対GUI」というゼロサムの競争ではなく、**「CLIが第一級市民として復権する」**という変化だ。
おわりに
Cloudflare CLIのリリースは、便利な開発者ツールが一つ増えた話ではなく、AIエージェント時代がインターフェース設計にどのような変化を求めているかを示すケーススタディである。
ターミナルを使う開発者の割合が62%から78%へ増加し、AIエージェント向けCLIプロジェクトが90日で13万スターを集める現実は、CLIの復活が単なる懐古趣味ではないことを示している。これは自動化・AI統合・予測可能なインターフェースへの需要が生み出した、構造的な動きだ。
歴史的に見て、インターフェースの主流は常に最も強力なユーザーの必要に応じて進化してきた。1970〜80年代は専門オペレーターが主役だったからCLIが支配した。90年代以降、一般消費者がコンピューティングの中心になるとGUIが標準となった。そして今、ソフトウェアの主要な消費者にAIエージェントが加わることで、再びCLIの時代が訪れようとしている。
Cloudflareが投げかけた問いは、結局これに尽きる。「あなたのサービスは、AIエージェントが使えるか？」
まだ答えを用意していないプラットフォームにとって、この問いがますます居心地悪く聞こえる日は、そう遠くない。
出典：