ハクソク

世界を動かす技術を、日本語で。

Cloudflare全体のためのCLIの構築

27日前原文(blog.cloudflare.com)

概要

  • Cloudflareは100以上の製品と約3,000のHTTP API操作を提供
  • エージェントによるAPI利用が増加し、CLIの需要が高まる現状
  • Wrangler CLIを全Cloudflare製品対応に向けて再構築中
  • TypeScriptベースの新スキーマ導入で一貫性と拡張性を確保
  • Local Explorerなどローカル開発を強化する新機能も提供開始

Cloudflare全製品対応Wrangler CLIの進化

  • Cloudflare は100以上の製品と約 3,000のHTTP API操作 を展開
  • 開発者やエージェントがAPIを利用し、アプリやプラットフォームをCloudflare上で構築・設定・分析
  • すべてのCloudflare製品をCLI・SDK・Terraform・APIドキュメント等、あらゆるインターフェースで利用可能にする目標
  • 特にCLI（ Wrangler）未対応製品が多く、エージェントからのCLIニーズが高い現状
  • 次世代Wrangler CLIのテクニカルプレビューを公開、 npx cf または npm install -g cf で試用可能
  • 現時点では一部製品のみコマンド提供、今後全API対応予定
  • 様々なインターフェース生成を自動化する新システムを開発、製品開発の高速化に対応

TypeScriptスキーマによる一貫性と拡張性

  • 従来の OpenAPIスキーマ ではCLIやローカル開発、Agent Skills等の複雑な要件に対応困難
  • TypeScript ベースの新スキーマを導入し、CLIコマンド・引数・コンテキストを統一的に定義
  • 独自スキーマにより、将来的な新インターフェースやOpenAPIスキーマ生成にも柔軟対応
  • スキーマ層でコマンド命名規則やオプション（例: get のみ使用、 --force のみ採用等）を強制
  • CLI・SDK・REST API間での命名一貫性とユーザー体験向上

ローカル開発強化：Local Explorer

  • 新機能 Local Explorer をWrangler・Cloudflare Viteプラグインでベータ公開
  • KV、R2、D1、Durable Objects、Workflows等のローカルリソースを直感的に可視化・操作
  • Miniflare によるローカルエミュレーション環境で、本番と同等のAPI利用が可能
  • ローカルデータの確認やスキーマ検証、テストデータ投入、リセット操作が容易
  • /cdn-cgi/explorer/api でローカルAPIエンドポイント提供、OpenAPI仕様にも対応
  • CLIコマンドで --local フラグを付与すれば、ローカルAPIへ自動切替

今後への期待とフィードバック募集

  • Wrangler CLIの進化に向け、開発者・エージェントからのフィードバックを積極募集
  • ダッシュボードで数クリック必要な操作を一行CLI化する要望や、wrangler.jsoncで設定したい項目の意見も歓迎
  • Cloudflare Developers Discord で要望受付中、今後もアップデート予定
  • Cloudflareは企業ネットワーク保護、アプリ高速化、DDoS対策、Zero Trust推進など幅広い機能を提供
  • 詳細やキャリア情報は公式サイト・採用ページ参照

Hackerたちの意見

Cloudflare全体のCLIについての希望や夢を教えて！ Wrangler CLIがローカル開発中に必要なAPIトークンの権限を事前に表示してくれるといいな。そうすれば、デプロイする前に何を準備すればいいかが分かるからね。さらに、cf permissions checkみたいなコマンドがあって、APIキーで何が足りないか、不要な権限は何かを教えてくれたら最高だね。

└

こういうドクターコマンドはいつもいいよね！もっとサービスにあればいいのに。

└

これには賛成だな。すごく役立つと思う。前に指が太くてミスしたことがあったから、これがあれば助かったのに。

今日はnpx cfを実行することで技術プレビューを試せるよ。もしくは、npm install -g cfでグローバルにインストールもできる。いくつか明らかな質問があるんだけど、オープンソースなの？（npmjsの方はリポジトリを指してないし）。それと、一般的に単一のバイナリとして提供されるのか、nodejsのツールが必要なくなるのかも気になる。もしそうなら、最近取得したBunや他の製品/アプローチを使うの？

└

私もリポジトリは見つからないけど、パッケージはMITライセンスでソースマップも含まれてるから、すぐに公開されると思うよ。

素晴らしい投稿で、インスピレーションをもらいます！ TypeSpec https://typespec.io/が言及されてないのは驚きだな。これはTypeScriptに似たスキーマ言語で、「もしOpenAPIが良かったら」という感じで説明してるんだ。彼らはそれを考慮したけど、自分たちで作る方がシンプルで柔軟だと判断したのかな。BYOのコストはエージェントのおかげでかなり下がったしね。

└

TypeSpec大好き！ OpenAPIを書くのが本当に楽になるのに同意するよ。でも、できるだけhttps://aep.devスタイルのAPIを使うようにしてる（時々TypeSpecで書かれてることもあるけど）。一貫性があるから、あらかじめ用意されたaepcliを使ったり、自分で簡単に書いたりできるんだ。すべてが一貫したパターンの「リソース」として振る舞うからね。それに、Terraformもそのままで使えるし、プロバイダーを書く必要もないんだ。

└

OpenAPIのどの部分を修正するの？

皮肉なことに、AIエージェントの登場で、GUIウェブページの「チェックボックスエンジニアリング」からCLIツールに戻ってる気がする。新しいバージョンのアセットをアップロードするたびに、Cloudflareでキャッシュをクリアするのにいろいろクリックしなきゃいけないんだ。オープンクローエージェントにメッセージを送ってやってもらえたらいいのに。

└

OpenClawなんて使う必要ある？CLIコマンドを直接呼び出せばいいじゃん。それがCLIの意味だし。

新しいTypeScriptスキーマを導入して、API、CLIコマンド、引数、インターフェースを生成するために必要なコンテキストの全範囲を定義できるようにしました。このスキーマ形式は、「ただの」TypeScriptの型のセットで、規約やリンティング、ガードレールを使って一貫性を確保しています。でも、なんでこのツール/フレームワークがここで紹介されてないのか混乱してる。これは何で、どうやって機能するの？ 誰かが投稿したTypeSpecツールに似てるの？

最近、LLMにgcloud CLIを使ってGCPでサービスをデプロイしてもらったんだけど、GCPダッシュボードに一度も行かずに済んだ。まるで魔法みたいだったよ。

Cloudflare全体のCLIについての希望や夢を教えてください。 初印象: -hと--helpは、もっと情報を提供する短い形式と少ない情報を提供する長い形式の基準に従うべきだと思う。今のアプローチだと、-hと--helpはコマンドリストを表示して、--help-fullフラグを指し示すだけなんだよね。--help-fullの出力は、-hで期待する内容を提供しているように見える。これをもっと良くする必要がある。ユーザーやコーディングエージェントが機能の使い方を理解するためにウェブサイトやドキュメントを読む必要がないくらいの情報を提供すべきだよ。デフォルトでは、補完が実際のコマンドリストと比べて壊れてる - つまり、dnsがリストに表示されなかった。cf start -hを実行したら、補完をインストールするように促された（これは変だった、だって補完はすでにインストールされてたから）。でも、-hは決してインタラクティブなことをしてはいけない。CLIの一部は他の部分と非常に異なるように見える（例えば、cf domains -hはcf dns -hとは全然違う）。色や色の無さ、オプションなど。

└

この慣習は聞いたことがないな。使ったことのあるすべてのgetoptスタイルのCLIツールは、オプションが短い形式でも長い形式でも同じ動作をするよ。

└

CLIのフラグのショートバージョンは、ロングバージョンと違うものにしないでほしい。ショートバージョンはその場で打つためのもので、ロングバージョンはスクリプト用だから、出力は同じにすべきだよ。詳しいドキュメントはmanやinfoに載せておけばいい。

Cloudflare全体のCLIについての希望や夢を教えてください。 長期間有効なトークンはなし、もしくはそれを避けるための非常にシンプルな設定が欲しい。一つのオプションは、狭い範囲で非常に短命なトークンをファイルに作成する簡単なツール、そしてもしかしたらそのファイルをライブで更新する方法（バインドマウントできるように）もあればいいな。もう一つのオプションは、スコープを狭めることができるプロキシモード。ホストに設定して、コンテナに特定のドメインやバケットへのアクセスを与えたいとき、ホストCLIにプロキシになってもらって、その関連する権限のサブセットをプロキシされたクライアントに与えるように頼むんだ。それでコンテナを接続する。

エージェントは、適切な権限を持ったAPIトークンさえあれば、CloudFlareでのすべてのことをすでに理解できるみたい。APIの使い方を理解するのは十分賢いんだ。でも、問題はAPIトークンを手動で作成しなきゃいけなくて、彼らが必要とするかもしれないすべての権限を基本的に追加しなきゃいけないこと。もっとスムーズに権限を管理できる方法があれば、彼らが頻繁に必要なことを許可を求めずにできるようにできるし、たまにしか必要ないアクションを承認するのも簡単になると思う。どの権限がどのカテゴリに入るかを事前に推測する必要もなくなるし。

AIエージェントが必要とするからCLIファーストデザインのトレンドは面白いね。開発者ツールを作るときも同じところにたどり着いたよ。CLIとAPIが最初で、エージェントが実際に使うものだからね。ダッシュボードはその後に来た。トップコメントのcf permissions checkのアイデアは素晴らしいと思う。一つ気づいたのは、エージェントはCLIを使うのは意外と得意だけど、コマンドが失敗した理由を診断するのはめちゃくちゃ苦手ってこと。明確なエラーメッセージと具体的な修正方法（「スコープXが足りないから、cf token add --scope Xを実行して」）の方が、エージェントの使いやすさには、ハッピーパスよりもずっと重要だよ。