Cloudflare、全製品を横断する統合CLIを構築
(blog.cloudflare.com)- Cloudflareは、100以上の製品と約3,000のHTTP APIを単一の**統合CLI（
cf）**として提供するため、次世代Wranglerを再構築中であり、現在テクニカルプレビューをnpx cfで利用可能 - 従来のOpenAPIスキーマだけでは、CLIコマンド、Workersバインディング、エージェントスキルなど多様なインターフェースを表現できないため、TypeScriptベースの新しいスキーマシステムを導入
- エージェントがCLIの主要な利用者となる流れに合わせ、
get/--force/--jsonなどのコマンド一貫性ルールとガードレールをスキーマレベルで強制 - ローカル開発時にシミュレートされたリソースを簡単に探索できるLocal Explorer機能をオープンベータとして公開し、KV、R2、D1などのローカルデータを直接確認可能
- Cloudflare全体のAPIをCLIとローカル環境で同じAPI形態で一貫して提供することで、エージェントと開発者の両方に最適化された開発体験を目指す
CloudflareのAPI規模とエージェント中心への転換
- Cloudflareは100以上の製品と約3,000のHTTP APIオペレーションを保有
- エージェントがAPIの主要な利用者として台頭しており、開発者はコーディングエージェントを通じてアプリケーション、エージェント、プラットフォームをCloudflare上に構築・デプロイしている
- Cloudflareの全APIは、1,000トークン未満の単一Code Mode MCPサーバーとして提供されているが、CLIコマンド、Workersバインディング、SDK、設定ファイル、Terraform、開発者ドキュメント、Agent Skillsなど、さらに多くのインターフェースをカバーする必要がある
- 既存のWrangler CLIには多くのCloudflare製品のCLIコマンドが欠けており、エージェントはCLIを好む傾向がある
次世代Wrangler CLIの再構築
- Wrangler CLIをCloudflare全体のためのCLIとして再構築し、すべての製品向けコマンドを提供するとともに、infrastructure-as-code方式による統合設定を可能にする
- テクニカルプレビューは
npx cfまたはnpm install -g cfで導入可能 - 現時点では一部製品のみをサポートしているが、内部ではCloudflare API全体の表面をサポートするバージョンをテスト中
- 各製品ごとのコマンドを、エージェントと人間の両方にとって使いやすい出力になるよう見直し・調整している
- 今後数か月をかけて、既存Wranglerの強みと統合していく予定
TypeScriptベースのスキーマとコード生成パイプライン
- 従来はOpenAPIスキーマを基に、API SDK、Terraformプロバイダー、Code Mode MCPサーバーを自動生成していた
- CLI、Workersバインディング、
wrangler.jsonc設定、Agent Skills、ダッシュボード、ドキュメント更新は依然として手動プロセスで進められており、エラーが起きやすく拡張不可能だった - OpenAPIスキーマはREST APIしか記述できないため、ローカル開発とAPIリクエストを組み合わせるインタラクティブなCLIコマンドや、RPCベースのWorkersバインディング、Agent Skillsやドキュメントまで表現できなかった
- Cloudflare社内でTypeScriptを共通言語として使っている点に着目し、Cap n' Web、Code Mode、WorkersプラットフォームのRPCシステムなどで、TypeScriptによるAPI表現の方が効果的であることを確認
- 新しいTypeScriptスキーマを導入し、API、CLIコマンドと引数、インターフェース生成に必要なあらゆるコンテキストを定義
- TypeScript型にコンベンション、Lint、ガードレールを適用した形式
- 独自フォーマットのため、必要なあらゆるインターフェースを柔軟にサポートしつつ、OpenAPIスキーマ生成も可能
エージェントとCLIの一貫性、およびコンテキストエンジニアリング
- エージェントはCLIの一貫性を期待しており、あるコマンドが
infoを使い別のコマンドがgetを使うと、存在しないコマンドを呼び出してしまう問題が起きる - 数百〜数千人のエンジニアを抱える大規模組織では、レビューだけで一貫性を維持するのはスイスチーズモデルのように穴が生じるのが避けられない
- CLI層だけで一貫性を強制すると、CLI、REST API、SDKの間で命名が食い違う問題をむしろ悪化させる
- スキーマレベルでルールとガードレールを適用し、常に
get（決してinfoではない）、常に--force（決して--skip-confirmationsではない）、常に--json（決して--formatではない）を、すべてのコマンドで一貫してサポート - Wrangler CLIは、ローカルのシミュレーションリソースとリモートリソースの両方で動作する特殊な構造を持つ
- D1データベース、R2ストレージバケット、KVネームスペースなどがローカル／リモートの両方に対応
- エージェントはリモートのデータベースを変更しているつもりでも、実際にはローカルデータベースにレコードを追加してしまう混乱が起こりうる
- 一貫したデフォルト値と、ローカル／リモートの別を明確に示す出力により、エージェントへ明示的なガイドを提供
Local Explorer — ローカルでもリモートと同じようにリソースを探索
- Local Explorerをオープンベータとして公開。Wrangler CLIとCloudflare Viteプラグインの両方で利用可能
- ローカル開発時に、Workerが使うシミュレーションリソースを直接探索可能：KV、R2、D1、Durable Objects、Workflows
- Cloudflare APIやダッシュボードでできるのと同じ操作を、完全なローカル環境で同じAPI構造のまま実行可能
- Cloudflareは長年にわたり完全なローカル開発に投資しており、D1のようなホスト型サーバーレスデータベースも、追加設定や別ツールなしでバインディング経由で完全にローカル実行できる
- Miniflare（ローカル開発プラットフォームエミュレーター）が本番と同じAPIを提供し、ローカルSQLiteデータベースを使用
- ネットワークアクセスなしで高速にテストを書いて実行でき、オフラインでも動作する
- これまではローカルにどんなデータが保存されているか確認するには、
.wrangler/stateディレクトリをリバースエンジニアリングするか、サードパーティーツールを導入する必要があった - Wrangler CLIまたはCloudflare Viteプラグインでアプリを起動すると、Local Explorerを開くプロンプトが表示され、キーボードショートカット
eでアクセスできる- 現在のWorkerに接続されたバインディングと、そのデータを確認できるローカルインターフェースを提供
- エージェントを使ったビルド時に、エージェントがデータをどう扱っているか把握するのに有用で、スキーマ検証、テストレコードのシード、
DROP TABLEによる初期化などが可能 - ローカルデータだけを変更するCloudflare APIのミラーを提供し、ローカルリソースへリモートと同じAPIでアクセス可能
- ローカルとリモートでAPI形態が同じなので、CLIで
--localフラグを渡すとローカルミラーAPIへのリクエストに切り替わり、そのまま動作する
- ローカルとリモートでAPI形態が同じなので、CLIで
- ローカルAPIは
/cdn-cgi/explorer/apiパスで利用でき、エージェントはこのアドレス経由でOpenAPI仕様を発見し、ローカルリソースを管理可能
フィードバック募集と今後の計画
- 次世代CLIのテクニカルプレビューは
npx cfまたはnpm install -g cfで利用可能 - 現在のテクニカルプレビューの機能だけでなく、Cloudflareプラットフォーム全体向けCLIに何を望むかについてフィードバックを募集
- ダッシュボードでは何度もクリックが必要だが、1行のCLIコマンドで実行したい作業
wrangler.jsoncで設定したい項目（例：DNSレコード、キャッシュルール）- エージェントが詰まる箇所と、CLIで提供してほしいコマンド
- Cloudflare Developers Discordでフィードバックを受け付けている
2件のコメント
FTSテーブルを設定してあるD1データベースをエクスポートしようとすると発生するエラーも、一緒に直してくれるといいですね。
wranglerを使うときに一番不便なんです。Hacker Newsの意見
Wrangler CLIがローカル開発中に必要なAPIトークン権限を事前に表示してくれるとよい
デプロイ前にどの権限が必要かを明確に把握でき、
cf permissions checkのようなコマンドで不足または不要な権限を確認できれば理想的GraphQLはHATEOAS原則によく従っているので、LLMがAPIを探索するのに有利だ
ドキュメントのバージョン不一致で起きる問題よりも、API自体が自ら機能を表現する構造のほうがはるかによいと考える
リソースグループ単位の権限制御を先に追加してほしい
今はzone（ドメイン）ベースの権限しかなく、zoneに属さないworkerのようなリソースは、低い権限でもコードが差し替えられたり削除されたりしうる
GitHub Enterpriseのようにsuper account + sub account構造をサポートしてくれるとさらによい。例: ACME Corp / ACME Corp (Prod)
素晴らしい記事で刺激を受けた。ただ、TypeSpec に触れられていないのは意外だった
TypeScriptスタイルのスキーマ言語で、「OpenAPIが本当にうまく作られていたらこういう感じ」と説明されることが多い
おそらく独自実装のほうがよりシンプルで柔軟だと判断したのだろう。最近はagentのおかげでBYOコストもかなり下がっている
ただ最近は aep.dev スタイルのAPIを好んでいる。一貫したパターンのおかげでaepcliをそのまま使ったり自作したりしやすい
Terraformも別途providerなしでそのまま動く
最近のAI agent中心のCLI-first設計は興味深い
自分たちも開発者ツールを作るとき、CLIとAPIを先に作り、ダッシュボードは後から付けた
上で言及されている
cf permissions checkのアイデアは特によいagentはCLIの利用は得意だが、エラー原因の診断は苦手だ。
「scope X が不足、
cf token add --scope Xを実行」のような明確なエラーメッセージのほうがはるかに重要だnpx cfでテクニカルプレビューをすぐ試せるとのことだが、いくつか気になる点があるオープンソースなのか、そしてNode.jsなしで単一バイナリ形式として提供する予定があるのか知りたい。
もしかすると最近買収したBunのようなものを活用できるのだろうか？
長期トークンは避けてほしい。
その代わり、CLIで短寿命の制限付きトークンを簡単に作成でき、ファイルで管理したり自動更新したりできるとよい
別の方法としてはproxyモードを設け、特定のドメインやバケットにのみアクセス権限を委任する構造も悪くないと思う
皮肉なことに、AI agent時代の到来で再びCLI中心の開発に戻りつつある
Cloudflareのキャッシュを消すたびにWeb UIで何段階もクリックしなければならないが、単にOpenClaw agentに命令するだけで済めばよい
Wranglerの認証方式はOAuth（フル権限）とダッシュボードで手動作成した静的トークンの2種類しかない
しかし、人間とAI agentで異なる権限境界が必要な場合には適していない
CLIから直接scopedでshort-livedなトークンを作成できるとよい
GitHub issue #13042でも議論されている。
トークンはリソースタイプだけでなく、リソースIDとアクション単位で細分化されるべきだ
4月1日にCloudflareがEmDashをx402対応とともに公開したが、今はCLIに注力しているようだ
Cloudflareは人間ではないagentを主要ユーザーとする開発者エコシステムを静かに再構築しているように見える
TypeScriptスキーマでAPI、CLIコマンド、引数、コンテキストを定義したとのことだが、
なぜそのツールやフレームワークがここで紹介されていないのか気になる
もしかすると上で言及されたTypeSpecと似た構造なのだろうか