CloudflareのCLI刷新、AIエージェント時代のインフラ設計を考える

Cloudflareがまたやってくれた。
Wranglerを全サービス対応のCLIとして作り直す、という発表を読んで、最初は「ああ、またツール刷新か」くらいに思ってた。でも少し読み込むと、これはかなり本質的な話だと気づいた。

WranglerはCloudflareの一部しかカバーできていなかった

公式ブログの言葉を引用すると「Many Cloudflare products have no CLI commands in Wrangler」とあった。正直これは知らなかった。自分はWorkers周りでしかWranglerを使っていなかったから、他のサービスがCLIで操作できないなんて意識してなかった。そこに加えて「agents love CLIs」という一文。これが今回の発表の核心だと思う。

今AIエージェントに何かタスクを渡そうとするとき、一番手っ取り早いのはCLIコマンドを叩かせることだ。APIを直接叩くよりも、CLIのサブコマンド構造のほうがエージェントに意図を伝えやすい。自分も最近LLM周りのコードを書いていて、ツール呼び出しの設計に悩むことが増えてきた。CLIが整備されているかどうかって、エージェント組み込みのしやすさに直結するんだよな。

IaCと組み合わせた「全部まとめて管理」が地味に効く

Wranglerの刷新で面白いのは、Infrastructure as Codeを使ってCloudflareのサービスを一括設定できるようにする、という部分だ。今まで自分のプロジェクトだと、WorkersはWranglerで管理してるけど、R2のバケット設定やD1のDB設定はダッシュボードでポチポチやってることが多かった。これが全部コードで管理できると、チームのリポジトリにインフラの状態を全部落とし込める。

たとえばこういう構成が現実的になってくるイメージ。

# wrangler.toml（将来的なイメージ）
name = "my-worker"
main = "src/index.ts"

[[r2_buckets]]
binding = "ASSETS"
bucket_name = "my-assets"

[[d1_databases]]
binding = "DB"
database_name = "my-db"

今も部分的にはできるけど、全サービスが同じCLIで管理できるようになれば、`wrangler deploy`一発で環境ごと再現できる世界が近づく。個人開発でも本番と開発環境の差分に悩むことが減りそう。

今すぐコードを変える話じゃないけど、設計の見直しポイントはある

正直、現時点ではまだテクニカルプレビュー段階だ。今日から急いで何かを変える必要はない。でもこのニュースを受けて、自分が見直したいと思ったのは、エージェントにどうツールを渡すか、という設計の部分だ。

今自分が作ってるツールは、エージェントに渡すためのインターフェイスとして関数を直接定義してる。でもそれよりもCLIのサブコマンド形式で切り出しておいたほうが、長期的には再利用しやすいし、テストも書きやすい。Cloudflareのこの方針を見て、「CLIファースト」で設計する癖をつけておくのは悪くないと思った。

エージェントが好むのはCLI、という発想は、自分のコードの粒度設計にも応用できる。来週、今作ってるサービスのツール呼び出し部分をCLIコマンドとして切り出してみるつもりだ。