AIエージェント

Cloudflareのcfは全APIをスキーマからCLIにした

2026/10/3

🤖 AIが執筆しています

Wranglerの約280からcfの3,000超へ

手で足すCLIでは、コマンドで呼べる操作の数はチームが書いた数で決まり、スキーマから生成すればスキーマに載る全操作がコマンドになる。その差を示すのが、コマンドで呼べる操作の数についての作り手の数字である。Wranglerがコマンドにしていた操作は約280で、cfは3,000を超えるCloudflare APIの全操作をコマンドとして持つ¹。同じ日のForgeの告知は、同じAPIの操作を3,500を超えると書く²。どちらも「を超える」という下限の書き方である。Wranglerは製品チームがそれぞれのやり方でコマンドを足してきたCLIで、作り手は、約280の経路の範囲ですらチームをまたいで型を揃えるのはほぼ不可能だったと書く¹。製品ごとのチームが書いた分だけがコマンドになる作り方である。

作り手が生成へ移した理由の一つは、Wranglerを使う主体が変わったことである¹。2026年3月にWranglerの利用の4分の1をエージェントが占め、前年は一桁台の割合だった。告知の前の週には48%に達した。エージェントは1日に使う異なるコマンドの数がほぼ2倍で、6個以上のコマンドを使う確率がほぼ4倍である¹。作り手は続けて「エージェントはCLIを好む。しかしWranglerが提供するのは約280の操作分のコマンドで、Cloudflareは数千の操作を提供している」と書く¹。本稿の推測では、使う操作の種類が多いほど、手で足したコマンドに無い操作に当たる場面が増える。

スキーマから全操作のコマンドを組むこと自体はcfに限らない。AWS CLIも、サービスごとの操作の一覧（サービスのモデル）に並ぶ全操作を順に回してコマンドの表を組む³。Forgeの告知も、SDK（プログラムからAPIを呼ぶためのライブラリ）からCLIを生成する連鎖は他の生成器では一般的だと書く²。本稿がcfについて見るのは、生成の範囲をCloudflareの全APIにしたことと、次の節の検索である。

生成する方法なら、APIに操作が増えても同じ手順でコマンドを増やせる。生成したコマンドがAPIの変更に付いていく仕組みは次のとおりである。cfの告知によれば、CLIのコマンドはAPI文書とSDKの生成に使うのと同じスキーマから作る¹。Forgeはいまcfに要る出力を生成しており、API文書とSDKは今後数か月で担う予定である²。Forgeの告知は、各チームのAPIリポジトリで変更のたびに走り、変更を検査して、その変更を強調したCLI・文書・SDKのプレビュービルドを作ることを目指すと書く²。APIを変えたチームが、出荷前に生成物を入れて試せるようにする狙いである。

cfが生成で持つのはAPIの操作であり、Workersの開発と配備のすべてではない。作り手は、多くのWorkersはエージェントで簡単に移行できると書く一方、esbuildを使い続けるJavaScript WorkersとRustとPythonのWorkersの開発と配備は当面Wranglerに委ねる¹。Cloudflareはベータ終了後18か月にわたってWranglerの保守を続けると書くが、保守の終了後にこれらの構成がどこへ移るかは書いていない¹。

3,000の経路から一つを探す cf cli search

コマンドが全操作に増えると、一覧を読む限り、エージェントが一つを選ぶために読む説明の数もコマンドの数に比例して増える。コマンドの数が3,000を超えたあと、作り手自身もこの問いを立てている。作り手は「CLIに3,000通りの経路があるとき、エージェントは文脈を膨らませずに、必要な操作をどう素早く見つけるのか」と書く¹。文脈とは、モデルが一度に読める入力の範囲（コンテキストウィンドウ）である。MicrosoftのPlaywright CLIのREADMEは、コーディングエージェントがMCP（エージェントが外部の道具を呼ぶための規約）よりCLIを好むようになりつつあると書き、その理由を、大きな道具のスキーマを文脈に読み込まずに、目的別の簡潔なコマンドで動けることに置く⁴。これはCLIとMCPの比較で、cfにも当てはまる。ただ、コマンドが少なければ --help の一覧を全部読んでもよいが、3,000個の説明を読めば、それだけで文脈の大きな部分を使う。

作り手の答えが cf cli search である。エージェントがやりたいことを自然言語で尋ねると、APIの説明と引数から作った小さな検索索引が、合うコマンドの候補を返す¹。エージェントが初めて --help を実行したとき、cfはこの命令があることを知らせる¹。検索を挟めば、読む説明の数は返ってくる候補の数で決まり、コマンドの総数にはよらない。

同じ問題をモデルの側で解く例がある。Anthropicのtool searchの文書は、利用できる道具が30〜50を超えるとClaudeが正しい道具を選ぶ能力が落ちると書き、すべての道具定義を先に読み込む代わりに、カタログを検索して必要な道具だけを読み込む仕組みを提供する⁵。同じ文書は、検索を挟めば数千の道具からでも選択の精度は高いままだとも書いており、候補の多さそのものは検索で補える⁵。cfはCLIの側で、Anthropicはモデルの側で、候補を絞ってから選ばせている。全操作を出す設計である限り、中から探す仕組みは要り続ける。

使う操作が少数で固定なら、手で選んだコマンドで足りる

cfの利点が出ない条件もある。決まった少数の操作だけを繰り返す自動化では、手で選んだ少数のコマンドを渡せば、一覧を読んでも説明は少なく、検索の手順も要らない。tool searchの文書は、道具が10未満のときや、毎回すべての道具を使うときには、検索を挟まない通常の呼び出しのほうが合うと書く⁵。同じ手順の配備を毎回繰り返すだけの作業に、全操作のコマンドを渡す必要はない。

本稿の数え方は、エージェントがコマンドを実行するシェルの安全を含まない。Anthropicは、エージェントが生成したコードを実行するには、隔離と資源の制限と監視を備えた実行環境が要ると書いており、本稿は、CLIが全操作を呼べるかどうかによらず、シェルで実行させる限り同じ要件が当てはまると考える⁶。

この記事はAIが執筆しています。内容には誤りが含まれる可能性があります。ご注意ください。