見出し画像

CloudflareはAIエージェントの仕事場を作り始めた。2026年8月の発表で見えた開発と運用の新しい基盤

南翔伍 / AIコンパニオンとSNSの間くらいの「Jams」開発中

Cloudflareの2026年7月後半から8月上旬の発表を順番に追うと、少し奇妙な感覚になります。

CI、ローカルのデバッグ、AIエージェントの監視、ファイル操作、コンテナ、Python連携、TCP通信、モデルの量子化、利用料金の可視化、さらにはAIが将来使う財布まで、話題があまりにも広いからです。個別の機能だけを追うと、「Cloudflareがまた開発者向け機能を増やした」という理解で終わりかねません。

機能名を一つずつ暗記する必要はありません。発表を一つの流れとして見ると、別の姿が見えてきます。

Cloudflareが整えようとしているのは、AIモデルそのものではありません。AIがコードやファイルを扱い、長い仕事を途中で止めず、必要なときに人間へ確認し、失敗を調べ、組織のルールを守り、費用を管理しながら本番で働くための「仕事場」です。

これは、AIが賢くなる話よりも、企業がAIへ仕事を任せられる条件が整い始めたという話です。

同時に、注意も必要です。今回紹介されたものには、すぐ使える機能だけでなく、ベータ、申請制のPrivate Beta、初期検証向けのEarly Preview、将来構想、Cloudflare社内の運用事例が混在しています。全部が完成済みで、今すぐ誰でも本番投入できるわけではありません。

この記事では、2026年7月後半から8月5日までに確認できたCloudflare公式ブログ、Developer Docs、Changelogをもとに、何が利用可能で、何がまだ試験段階なのかを分けます。そのうえで、非技術者にも分かる言葉で、何ができるようになったのか、これまでの何がつらかったのか、どの企業が使うと効果を出しやすいのか、どう導入すべきかまで整理します。


今回の発表はAIモデルの追加ではなく仕事の基盤づくりだった

生成AIの話題は、どうしてもモデル性能へ引っ張られます。どのモデルが最も賢いのか、何文字まで読めるのか、コード生成の精度はどれくらいか。もちろん、それらは重要です。

ただし、現場の仕事はモデルへ質問して回答を受け取った時点では終わりません。

たとえば、AIに不具合の修正を任せるなら、少なくとも次の工程が必要です。

  • 対象のコードを取得する

  • 問題を同じ条件で再現する

  • ログや実行履歴から原因を絞る

  • 変更してよい範囲を守る

  • 修正後にテストする

  • 人間が確認できる形で差分を残す

  • 承認された場合だけ本番へ反映する

  • 失敗したら前の状態へ戻す

  • 何をしたか後から説明できるようにする

  • 使った計算資源と費用を把握する

強いモデルが一つあっても、この工程は自動的には成立しません。モデルの周囲に、作業環境、保存場所、権限、状態管理、テスト、監視、承認、復旧、費用管理が必要です。

Cloudflareの今回の発表は、この周囲の仕組みの空白を一つずつ埋めようとしています。

コードを登録して検査するCI WorkflowsとArtifacts。Workerを本番に近い条件で試す`createTestHarness()`。実行中に何が起きたかを見るLocal Tracing。本番のAIエージェントの判断やツール利用を追うAgent Tracing。AIがファイルやコマンドを扱うCloudflare Computer。長い処理を状態付きで進めるAgents、Durable Objects、Workflows。重い処理を隔離して実行するContainers。組織の規程をAIレビューへ接続する設計。利用料金を確認するBillable UsageとBudget Alerts。そして将来、AIが定められた予算内で支払うためのWalletsです。

個々の機能は別々でも、向いている方向はそろっています。

Cloudflareは、Webサイトを速く安全に配信する会社という従来の認識から、アプリやAIエージェントを作り、動かし、観測し、統制する基盤へ射程を広げています。Cloudflare自身も現在、アプリ、エージェント、従業員向け環境を一つのプラットフォームで扱う方向を前面に出しています。

ここから導ける中心的な見方は、次の通りです。

AI時代の競争力は、最も強いモデルを持つことだけでは決まらない。モデルを安全に働かせ、失敗を発見し、止め、直し、費用を管理できる環境を持つことが重要になる。

AIエージェントの周囲に必要な情報、ツール、状態、権限、検証、観測、回復手段をどう設計するかは、こちらの記事で詳しく整理しています。

まず提供状態を分けないと判断を誤る

今回の発表を読むとき、最も重要なのは機能名を覚えることではありません。「今使えるのか」を正しく分けることです。

Cloudflareの発表には、少なくとも七つの状態があります。

通常のアカウントで利用できるもの

Local Tracing、Python Workers RPC、Workers向けの統合テスト機能である`createTestHarness()`、Budget Alerts、AIモデルのカタログなどは、公式Docsに利用手順があり、現在の開発や運用へ組み込みやすい機能です。

ただし、利用可能であることと、無条件で本番へ入れてよいことは同じではありません。たとえばトレースには機密情報が含まれる可能性があり、予算アラートは支出を止める機能ではありません。利用可能な機能でも、設定と運用条件を確認する必要があります。

ベータとして利用できるもの

Cloudflare Agentsの新しい統合体験やAgent Tracingはベータです。試せる一方、仕様、料金、画面、保存期間などが変わる可能性があります。

Agent Tracingの専用Docsでは、ベータ中は無料で、2026年10月1日以降はWorkers Observabilityのイベントとして課金すると説明されています。一般的なTracingページに古い記述が残る場合があるため、導入直前にはAgent専用ページを優先して確認すべきです。

申請や招待が必要なもの

Cloudflare Artifactsを中心にしたCI Workflowsの一部、受信TCP、gRPCなどはPrivate Betaです。発表記事にコード例があっても、自分のアカウントでそのまま有効になるとは限りません。

特にCI Workflowsは、ライブラリの発表と、基盤になるArtifactsの提供状態を分けて読む必要があります。プレビュー環境、段階的なデプロイ、より簡単なモノレポ対応などは、今後の計画として示されたものです。

初期検証向けのもの

Cloudflare ComputerはEarly Previewです。AIへファイルやコマンドを扱わせる重要な基盤ですが、重要な顧客データや本番操作を無人で任せる段階ではありません。

最初は合成データ、読み取り専用、隔離環境、短時間の処理から試すのが妥当です。

将来に向けた入口だけが提供されたもの

Cloudflare Walletsは、現時点ではWallet handleの確保が中心です。入金、保管、AIによる支払い、受け取りなどは、将来提供する方向として説明されています。

「CloudflareでAIがもう自由に買い物できる」と理解するのは誤りです。現在できることと、将来構想を分ける必要があります。

製品ではなく実践事例として読むもの

AstroのIssue TriageとEngineering Standards Enforcementは、非常に参考になるものの、完成したSaaSを契約する話ではありません。

Astroの事例は、複数のAIへ再現、診断、検証、修正を分担させる運用設計です。Engineering Standards Enforcementは、Cloudflare社内の規程を構造化し、AIレビューへつなぐ方法です。価値は「購入できる機能」ではなく、自社へ応用できる設計思想にあります。

製品ではなく全体設計やイベントとして読むもの

Agent Development Lifecycleは、AI時代の開発をどう組み直すかという全体設計です。Cloudflare Connect 2026は2026年10月19日から21日に予定されているイベントで、製品リリースではありません。Developer Docsのトップページも、更新を追う入口であって新機能ではありません。

この区分を最初に行うだけで、ニュースの読み違いがかなり減ります。導入判断も一気に正確になります。

ニュースを見て「すごそうだから導入する」のではなく、利用状態、データの機密性、失敗時の影響、代替手段、撤退条件を確認する。新しいAI基盤ほど、この順序が重要です。

開発の速さより検証と復旧の速さを上げる

Cloudflareが今回強化した第一の領域は、コードを作ってから安全に公開するまでの流れです。

CI Workflowsは検査と公開の工程をコードで持てる

CIは、コードを変更したときにテストやビルドを自動で行う仕組みです。たとえば開発者がコードを登録すると、文法上の問題を調べ、型を確認し、テストを行い、問題がなければ公開するところまで自動化します。

CloudflareのCI Workflowsは、この流れをTypeScriptとCloudflare Workflowsで表現します。

想定される流れは、コードの取得、依存ライブラリの準備、lint、型検査、テスト、ビルド、条件付きデプロイです。Workflowsを使うため、長い処理で一部が失敗した場合の再試行や、途中からの再開を組み込みやすくなります。

AIによる修正も提案されています。ただし、ここは誤解しやすい点です。

AIがCIの失敗を勝手に成功扱いへ変えるわけではありません。AIは失敗ログとコードを調べ、別ブランチへ修正を作れます。元のCI実行は失敗として残り、人間または別の検証工程が変更を確認します。安全性の中心は、AIの自動修正ではなく、元の証拠を残し、変更を分離し、承認前に本番へ入れないことです。

現時点では基盤のArtifactsがPrivate Betaであり、すべての企業がすぐ同じ構成を使えるわけではありません。一般的な数個のリポジトリを管理するだけなら、GitHub Actionsなどの既存CIで十分な場合も多いでしょう。

CI Workflowsが特に向くのは、Cloudflare上で多数の顧客コードを扱うサービス、顧客ごとに隔離したビルドが必要な環境、AIがコードを生成して検査と公開まで行うサービスです。

createTestHarnessは本番に近い条件でWorkerを試せる

`createTestHarness()`は、Wranglerから使える統合テスト用のAPIです。統合テストとは、一つの関数だけでなく、複数のWorkerやデータ保存先、イベントのつながりをまとめて確認するテストです。

この機能は、一つまたは複数のWorkerをローカルの一つのサーバーで動かし、リクエスト、定期実行、各種イベント、bindings、ローカルストレージ、ログをテストから扱えるようにします。

非技術者向けに言えば、部品だけを机の上で確認するのではなく、実際の受付、担当部署、倉庫、記録簿までつないだ模擬業務を動かせるようになる機能です。

外部APIを実際には呼ばずに応答を再現したり、テスト前にD1やKVへデータを入れたり、複数Worker間のルートを確認したりできます。AIがコードを書く時代には、「書けたか」ではなく「期待した条件で動いたか」を機械的に確認するための重要な部品になります。

Local Tracingは推測ではなく実行記録から直せる

Local Tracingは、`wrangler dev`や`vite dev`でローカル実行したWorkerについて、処理の流れをOpenTelemetry形式で記録します。OpenTelemetryとは、アプリの処理時間、呼び出し、エラーなどを共通形式で観測する仕組みです。

確認できるのは、どのリクエストが来たか、どの処理が動いたか、外部APIへ何を送ったか、D1、KV、R2、Durable Objects、Queuesへどうアクセスしたか、どこで失敗したか、どれくらい時間がかかったか、といった内容です。

従来のデバッグでは、開発者やAIが原因を予想し、ログを追加し、もう一度実行していました。Local Tracingでは、実際に起きた流れを先に見られます。

これは、症状だけを聞いて病気を推測する状態から、検査結果を見ながら原因を絞る状態へ近づく変化です。

AIコーディングエージェントがLocal Explorer APIへ接続すれば、AI自身がトレースを読み、失敗した処理を探せます。ただし、AIへ「直して」とだけ頼むのではなく、再現、該当するtraceの提示、原因の説明、修正、同じ条件での再検証までを一つの完了条件にする必要があります。

AIにコードを書かせるだけでは開発が速くならない理由と、検証、レビュー、復旧を含むSoftware Factoryの設計は、こちらの記事で詳しく整理されています。

AIに作業机と隔離された実行環境を渡す

第二の領域は、AIが実際にファイルやコードを扱う場所です。

AIは文章を返すだけなら、チャット画面の中で仕事が完了します。しかし、リポジトリを調べ、ファイルを書き換え、コマンドを実行し、PDFや画像を生成し、テストするには作業環境が必要です。

Cloudflare ComputerはAI向けの共通作業環境を目指す

Cloudflare ComputerはEarly Previewとして公開された`@cloudflare/computer`というオープンソースのパッケージです。

AIエージェントへ、ファイルの読み書き、編集、一覧、コマンド実行、コードの試行、必要に応じたLinux Containerの利用、作業状態の保存を共通の形で提供します。

ここで重要なのは、名称がContainerではなくComputerであることです。

AIにとって必要なのは、「この種類のコンテナを起動する」という難しいインフラ操作ではありません。必要なのは、ファイルがあり、コマンドが使え、軽い処理と重い処理を必要に応じて切り替えられる仕事机です。

Cloudflare Computerは、軽い処理をWorkersのisolateで行い、OS依存の処理や重い計算が必要な場合にContainerへ切り替える構想を持っています。ファイルはDurable ObjectsとSQLiteを基盤にしたWorkspaceへ保存し、ContainerにはFUSEを使ってマウントする設計が示されています。

ただし、Cloudflareが示した「コンテナが必要な処理を10パーセント未満へ抑えたい」という記述は目標です。現在のあらゆる仕事で10パーセント未満になるという保証ではありません。

Containersは重い処理を隔離する

Containersは、一般的なLinux環境や専用ソフトが必要な処理に向きます。

画像変換、動画処理、ブラウザ操作、独自バイナリの利用、長時間のビルド、複雑な依存関係を持つコード実行などは、軽量なWorkerだけでは扱いにくい場合があります。そこで、必要な処理だけをContainerへ渡します。

重要なのは、AIへコンテナを渡しただけで安全になるわけではないことです。

実行可能なコマンド、外部接続先、CPU、メモリ、実行時間、ディスク容量、同時実行数、secretへのアクセス、顧客ごとの隔離、作業ファイルの保存期間、終了後の削除、監査ログを決める必要があります。

AIが自由にコマンドを実行できる環境は、便利さと同じ大きさの危険を持ちます。最初の実証実験では、合成データ、外部送信なし、読み取り中心、短い時間、明確な終了条件を置くべきです。

Python Workers RPCは言語の境界を小さくする

Python Workers RPCは、Pythonで書いたWorkerとJavaScriptやTypeScriptのWorkerを、RPCで呼び合いやすくする機能です。RPCとは、別の場所にある関数を、手元の関数のように呼び出す仕組みです。

これにより、既存のPython資産をすべてJavaScriptへ書き直さずに済む可能性があります。

たとえば、データ分析、機械学習、文書処理はPythonで作り、Web APIやユーザー向けの入口はTypeScriptで作るといった分担ができます。組織内に複数言語の資産がある場合、言語統一よりも接続方法を整える方が速いことがあります。

ただし、言語をまたいだ呼び出しには、型、エラー、タイムアウト、再実行、互換性、デプロイ順序の管理が必要です。簡単につながることと、長期運用しやすいことは別です。

受信TCPとgRPCは対応できるシステムを広げる

Cloudflareは受信TCP、ソケットの受け渡し、gRPC対応をPrivate Betaとして発表しました。

HTTPだけでなく、独自プロトコル、データベース接続、ゲーム、IoT、既存の企業システムなどへ接続できる範囲が広がります。Workersだけの経路は主にunaryとserver streaming、双方向のgRPCはContainer経路が中心です。

ここは魅力的ですが、すべてPrivate Betaです。一般提供済みの機能として設計を固定するのは早いでしょう。

長い仕事には会話履歴ではなく正式な状態が必要になる

AIエージェントが数分で終わる一回の作業なら、会話の中に情報を置くだけでも動くかもしれません。

しかし、数時間、数日、複数人の承認、外部システムへの操作を含む仕事では、会話履歴だけに頼れません。

途中で処理が止まったとき、どこまで終わったのか。何を待っているのか。どの版のファイルが正式なのか。承認済みなのか。再実行すると二重送信にならないか。こうした情報は、AIの記憶ではなくシステムの状態として持つ必要があります。

Durable Objectsは担当者ごとの専用デスクに近い

Durable Objectsは、特定のIDに対応する状態と処理を一か所へまとめるCloudflareの仕組みです。

非技術者向けに言えば、案件ごと、顧客ごと、AIエージェントごとに専用デスクを作り、そのデスクに現在の状態と必要なデータを置くイメージです。

同じ案件に対する処理を順番に扱いやすく、WebSocketなどのリアルタイム通信とも相性があります。AIエージェントの会話、タスク、承認待ち、進捗などを管理する基盤になります。

Workflowsは長い業務の手順と再開地点を持つ

Workflowsは、複数の工程を順番に進め、失敗時の再試行や途中再開を扱う仕組みです。

「顧客資料を集める」「不足を確認する」「レポートを作る」「人間へ確認を依頼する」「承認後に送る」という仕事を一つの長い処理として持てます。

各工程の結果を保存し、同じ工程を安全に再実行できるようにしておけば、最初からやり直す必要が減ります。AIエージェントに必要なのは、何でも一気に完了する能力ではなく、止まっても壊れず、正しい地点から再開できる能力です。

Agentsはモデルと状態とツールを一つの実行単位へまとめる

Cloudflare Agentsは、AIモデル、会話、状態、ツール、スケジュール、リアルタイム通信などを組み合わせるための枠組みです。

今回の発表では、Agent Tracingと専用ダッシュボードが大きく強化されました。これは、エージェントを作るだけでなく、運用中に何をしたかを見る方向へ重点が移っていることを示します。

Agent Development Lifecycleは開発全体を作り直す考え方

Agent Development Lifecycleは単独製品ではありません。

Cloudflareは、従来のソフトウェア開発の流れである計画、設計、実装、テスト、公開、保守、廃止を、AIエージェントが継続的に参加する前提で見直しています。

AIがコードを書く速度は上がりました。しかし、レビュー、テスト、公開判断、運用、障害対応、廃止は同じ速さでは進みません。実装だけが速くなると、後工程に未確認の変更が積み上がります。

そのため、Cloudflareは次の性質を持つ「software factory」を重視しています。

  • 人間の画面操作だけでなくAPIやコードから動かせる

  • 同時に多数の仕事を処理できる

  • 同じ条件を再現できる

  • 更新や障害を起点に動ける

  • 変更を途中状態にせず、戻せる

  • 役割ごとに権限を制限できる

  • 実行結果から評価と改善を続けられる

これは「AIがソフトウェアを全部自動で作る」という意味ではありません。

依頼、作成、検証、承認、公開、監視、改善、廃止までを、証拠と権限を持った一つの運用システムへするという考え方です。Cloudflare自身も、多くの組織はまだこの状態に到達していないと述べています。

AIを自律化する前に証拠を残せるようにする

AIエージェントの導入で本当に危険なのは、失敗そのものではありません。

何が起きたか分からず、同じ条件を再現できず、誰も説明できない状態です。

Cloudflareの発表で特に重要なのは、AIの自律性よりも観測と証拠に重点が置かれていることです。

Agent TracingはAI固有の行動を追う

通常のサーバー監視では、リクエストが成功したか、エラーが出たか、処理時間がどれくらいかを見ます。

しかし、AIエージェントはHTTP上では成功していても、仕事として失敗することがあります。

間違ったツールを選んだ。同じ処理を繰り返した。不要なモデル呼び出しを続けた。人間承認待ちのまま止まった。サブエージェントへ誤った前提を渡した。形式は正しいが内容が間違っていた。

Agent Tracingでは、エージェントの起動、セッション、run、モデル呼び出し、入出力トークン、ツール利用、人間承認、サブエージェント、エラー、所要時間、Workers側の処理を一つの流れとして追えます。

Session Replayは、過去のセッションを時系列で見直す機能です。同じ外部操作やモデル推論をもう一度実行する機能ではありません。

記録を増やせば安全になるわけではない

トレースには大きな注意点があります。

会話、ツール引数、検索結果、顧客データを保存すれば、障害調査には役立ちます。一方で、氏名、住所、メール、医療情報、契約、決済情報、APIキー、OAuth token、非公開データが残る危険があります。

Thinkや`wrapAISDK()`ではメッセージやツール内容を既定で保存しない一方、Flueは設定が異なります。利用するフレームワークごとに既定値を確認しなければなりません。

記録前に決めるべきなのは、何を保存するかだけではありません。

  • 保存しない情報

  • マスキングする項目

  • 閲覧できる人

  • 保存期間

  • 顧客ごとの分離

  • 障害調査へ使う条件

  • 評価データへ二次利用する条件

  • 削除方法

ログが多いことと、監査できることは同じではありません。業務ID、ユーザー、実行、モデル、ツール、結果、承認を対応づけられて初めて、後から説明できます。

料金も観測設計の一部になる

Agent Tracingはベータ中無料ですが、2026年10月1日以降はWorkers Observabilityのイベントとして計算される予定です。

Freeプランは一日20万イベントと3日保持、Paidプランは月2,000万イベントを含み、超過は100万イベント当たり0.60米ドル、保持は7日と説明されています。

ここから重要な実務課題が生まれます。

細かいspanを大量に出せば、調査しやすくなる一方、イベント数と費用が増えます。逆に記録を減らしすぎれば、障害時に原因が分かりません。どの工程をどの粒度で記録するかは、技術設定ではなく、リスクと費用を調整する経営判断です。

AIへ仕事を任せられるかを、能力だけでなく目的、評価、停止、回復、責任から考える必要があります。こちらの記事では、人間が保持すべき判断の境界を整理しています。

複数のAIへ役割を分けるときは引き継ぎを成果物にする

AstroのIssue Triage事例は、AIエージェントを実務へ入れるうえで非常に参考になります。

Astroは、未解決Issueが200件を超える状態から、発表時点で約30件まで減らしました。タイトルから「ゼロになった」と受け取りやすいのですが、発表時点でゼロを達成したわけではありません。Cloudflareは翌月中にゼロへ到達できる見込みと説明しています。

重要なのは数字だけではなく、処理の分け方です。

一つのAIへ全部任せなかった

Issue対応は、次の工程へ分けられました。

  • Reproduceで問題を再現する

  • Diagnoseでログやコードから原因を調べる

  • Verifyで本当にバグか、仕様通りかを確認する

  • Fixでテストと修正を作る

  • Previewで報告者が試せる版を出す

  • Reporter verificationで報告者の確認を待つ

  • 確認後にPull Requestを作る

一つのAIに「このバグを直して」と頼むと、本当はバグでなくても修正を作る方向へ誘導されます。

再現、診断、仕様確認、修正を分けると、それぞれの工程で証拠を確認できます。必ず複数モデルが必要という意味ではありません。役割、入力、完了条件、引き継ぎを分けることが重要です。

report.mdがAI同士の引き継ぎ書になった

各エージェントは、調査結果を`report.md`へ残します。

次の担当AIは、前のAIの長い会話をそのまま読むのではなく、確認した事実、再現手順、原因候補、未解決点をまとめた成果物を受け取ります。

これは人間の仕事でも同じです。口頭の申し送りだけでは、判断の根拠が消えます。AIエージェント同士の連携では、会話履歴よりも、構造化された引き継ぎ成果物が重要になります。

GitHubのラベルが状態管理になった

大規模な独自データベースを先に作るのではなく、Issueのラベルとコメントを状態機械として使いました。

調査が必要、調査中、修正候補あり、利用者確認待ち、修正確認済みといった状態を既存のGitHub上に残します。

これにより、人間もAIも現在地を確認でき、途中で処理が止まっても履歴から再開できます。

公開された`triagebot-action`は、若く発展中の参照実装です。完成済みの汎用サービスではありません。導入するなら、自社のIssue形式、テスト環境、権限、プレビュー方法、確認者に合わせて調整する必要があります。

この設計は技術サポート以外にも使える

この考え方は、バグ修正だけに限りません。

カスタマーサポートの技術調査、社内ITヘルプデスク、データ品質異常、申請書の不足確認、契約条項の一次確認、記事の事実確認など、証拠を集め、判断し、成果物を作り、人間が確認する仕事へ応用できます。

ただし、再現手段、成功条件、状態、確認者が曖昧な仕事では機能しにくくなります。

組織のルールは長い文書のままAIへ渡さない

Engineering Standards Enforcementの事例は、AIガバナンスを「禁止事項の一覧」で終わらせない方法を示しています。

ここでいうCloudflare Codexは、OpenAI Codexではありません。Cloudflare社内の設計原則、API規則、セキュリティ要件などを管理する規程体系です。

規程が散らばるとAIも人間も守れない

企業のルールは、Wiki、過去の設計書、各リポジトリ、Slack、個人の経験、古いRFCへ散らばりがちです。

その状態では、どれが現在有効なのか、推奨なのか必須なのか、どの領域へ適用されるのか、例外は誰が承認するのかが分かりません。

AIに全資料を読ませても、矛盾した古いルールを同時に参照する可能性があります。

Cloudflareは、規程へ管理責任者、RFC番号、対象領域、SHOULDとMUST、ApprovedとEnforced、安定した識別子、元文書、更新履歴を持たせています。

Approved段階では違反を指摘しても原則ブロックせず、Enforced段階でMUST違反をブロックできます。新しい規程を即日全面強制せず、警告、誤検知の確認、移行、強制という順序を取る設計です。

長文を短い構造へ変換する

60件を超えるRFC全文を毎回AIへ渡すのではなく、SHOULDとMUSTをJSONへ抽出し、対象領域を絞ってAI reviewerへ渡します。

AIはまず短い構造化ルールを読み、必要な場合だけ元文書へ戻ります。

これは、長文を単に要約することとは違います。ルールの所有者、強さ、対象、根拠、版を失わずに、AIが判定に使える単位へ変換しています。

公表値は効果の参考であって他社の保証ではない

Cloudflareは、AI code reviewerが約4か月で約23万件の違反を指摘し、約1万6,000件で承認を保留したと説明しています。Spec reviewerは2026年5月初め以降、約600件のユニークなopen specに対して3,200回超実行されました。

大きな数字ですが、Cloudflare社内の運用結果です。他社が同じルール数やレビュー方法を導入すれば、同じ効果が出るという保証ではありません。

確認すべきなのは指摘数ではなく、真の問題を見つけた割合、誤検知、修正までの時間、開発者の負担、重大事故の減少です。

非技術部門でも同じ構造を使える

営業提案の必須項目、広告表現、個人情報の取扱い、採用面接の評価基準、契約締結の承認条件、センシティブ領域の記事表現、AIによる送信や削除の承認規程にも応用できます。

導入順は、正式な規程を一つに決め、所有者を割り当て、MUSTとSHOULDを分け、対象と例外を明記し、最初は警告だけで運用し、誤検知を測り、安定したMUSTだけ強制する流れが妥当です。

AIコードレビューのルールを増やすだけでなく、正式な規程、適用範囲、テスト、例外、改善まで設計する方法は、こちらの記事で詳しく整理されています。

費用を見えるようにしてからAIに予算を渡す

AIエージェントが本番で長く動くようになると、品質だけでなく費用の管理が重要になります。

モデル呼び出し、Workerの実行、Container、ストレージ、キュー、トレースなど、複数の費用が一つの業務へ積み重なります。最終的な月額だけを見ても、どの機能、顧客、エージェント、工程が費用を生んだのか分かりません。

Billable Usageは利用料金を業務へ結びつける入口になる

Cloudflareは、Billable UsageのダッシュボードとAPIを通じて、使用量と費用を確認する機能を強化しています。

ここには注意点があります。公式ブログとAPI Docsの表記に不整合が見られます。ブログは`/billable-usage`を紹介し、日次更新の使用量と費用データを説明しています。一方、API DocsにはAlphaやRestrictedの表示、`/billable/usage`を含む複数の記述、費用項目が空になる可能性の説明があります。

実装時はブログ記事のコードをそのまま信じず、現在のAPI Docs、実際のアカウントで使えるendpoint、返却値を確認すべきです。

Billable Usageダッシュボードは、主にPay-as-you-goアカウントの使用量ベース費用を扱います。固定の月額プラン料金は含まれない場合があります。Enterprise契約も同じ条件ではありません。

Budget Alertsは通知であって停止装置ではない

対象となるPay-as-you-goアカウントでは、2026年7月20日から既定の10米ドル予算アラートが順次作成されています。

累積の使用量ベース費用がしきい値へ達するとメールが届きます。ただし、これは情報通知です。利用を止めず、上限を強制しません。

さらに、前日の利用を一日一回処理するため、リアルタイムではありません。急激な暴走を止める用途には不足します。

本番のAIエージェントには、Budget Alertsとは別に次の制御が必要です。

  • 一回の実行で使える最大金額

  • 最大モデル呼び出し回数

  • 最大トークン

  • 最大実行時間

  • 最大再試行回数

  • 同時実行数

  • 顧客ごとの月次上限

  • 異常時の停止

  • 人間承認が必要な高額処理

通知と制御を分けることが重要です。

Walletsは将来のAI向け支払い基盤を目指す

Cloudflare Walletsは、AIエージェントが将来、サービスへ支払い、受け取り、予算を持つための構想です。

現在の中心機能はWallet handleの確保です。Cloudflareは、将来のAccount wallet、Virtual wallet、安定したデジタル通貨による支払い、役割や予算の制限、エージェントのアイデンティティとの接続を説明しています。

x402は、HTTPの402 Payment Requiredを使い、APIやデジタルサービスの利用時に機械同士で支払い条件を交換する考え方です。

ここから、AIが必要なデータ、API、計算資源を自分で購入する世界が想像できます。しかし、現時点でその決済機能が一般提供されたわけではありません。

また、AIへ財布を持たせる前に、誰の代理なのか、何を買えるのか、一回と一日の上限、受取先の確認、返金、争議、会計、税務、不正検知、秘密鍵の保護を決める必要があります。

Cloudflareの動きを時系列で見ると、かなり筋の通った順序になっていることが分かります。

最初にBillable Usageで費用を見えるようにし、Budget Alertsで通知し、将来Walletsで支払い能力を与える。つまり、観測できないAIへ予算を渡すのではなく、利用状況を把握できる基盤の後に経済的な権限を広げようとしています。

モデルの数より選び方と推論基盤が重要になる

CloudflareのAI Modelsページでは、確認時点で214モデルが表示されています。

ただし、これはすべてCloudflareが同じ条件で直接ホストするWorkers AIモデルという意味ではありません。第三者提供モデルも含まれ、価格、提供地域、データ保持、入力形式、性能、利用条件は同一ではありません。

モデル数の多さをそのまま価値と考えるのは危険です。

企業に必要なのは、仕事の工程ごとに必要な能力を定義し、速度、費用、精度、ツール利用、データ条件、障害時の代替を見ながら選べることです。

Smaller Faster Safer ModelsはCloudflare内部の推論改善

Cloudflareは、Kimi K2.6とGLM 5.2を例に、推論基盤を小さく、速く、安全にする技術を説明しました。

利用者が管理画面でスイッチを入れる新製品ではありません。Cloudflare内部の推論効率と安全性を改善する取り組みです。

主な技術は三つです。

一つ目はKV cacheの量子化です。KV cacheは、長い文章を処理するときに過去の計算結果を再利用するための一時的な記憶です。精度を保ちながら小さな形式へ圧縮すると、同じGPUメモリでより長い文脈や多くの同時処理を扱えます。

Kimi K2.6では、BF16からFP8へ変えることで、一つのGPUで扱える文脈量が約68万6,000トークンから約137万トークンへ増えたと説明されています。これは一つの回答が必ず二倍速くなるという意味ではなく、高い同時実行時の全体処理量が増える話です。

二つ目は重みの圧縮です。GLM 5.2ではFP8からINT4へ圧縮し、約705GBから421GBへ約40パーセント縮小しました。生成時のdecodeは改善する一方、入力を読むprefillは遅くなる場合があり、すべての条件で速くなるわけではありません。評価結果は元モデルとの差が約0.8ポイント以内と説明されています。

三つ目はキャッシュの完全性確認です。保存したモデル重みやKV cacheが壊れていないかを検査し、誤った計算を防ぎます。Cloudflareは1パーセント未満のオーバーヘッドで実装したと説明しています。

この発表から読み取るべきなのは、「モデルが小さくなったから顧客価格がすぐ下がる」ということではありません。原価低下と販売価格は別です。

より重要なのは、AIサービスの品質がモデルのベンチマークだけでなく、メモリ管理、同時実行、キャッシュ、データ完全性、ルーティングによって決まることです。

Cloudflareの狙いは薄いAIと厚い仕事環境にある

ここからは、ここまでの公式発表をつないだときに見えてくる解釈です。

Cloudflareが作ろうとしているものは、特定のAIモデルへ依存した巨大な一枚岩ではありません。モデルは仕事に応じて入れ替えられ、その周囲にある仕事環境をCloudflare側で厚くする構造です。

言い換えると、AIそのものは薄く差し替え可能にし、状態、ツール、ファイル、実行環境、監視、権限、規程、費用管理を厚く持つ方向です。

この構造には三つの意味があります。

モデルの進化を受け取りやすい

AIモデルは短期間で変わります。特定モデルのAPIや癖を業務全体へ埋め込むと、変更時の影響が大きくなります。

工程の入出力、完了条件、ツール、権限、評価を固定し、その役割を満たすモデルを選べるようにすれば、新しいモデルへ入れ替えやすくなります。

Cloudflareの214モデルというカタログも、数の多さより、同じ仕事環境から複数のモデルへ接続できる価値の方が重要です。

失敗をモデルの責任だけにしなくて済む

AIが間違えたとき、原因はモデル性能だけとは限りません。

必要な情報がなかった。古い規程を参照した。ツールの説明が曖昧だった。権限が広すぎた。途中状態が失われた。テストがなかった。承認を飛ばした。費用上限がなかった。

仕事環境を分解して持つと、どこを直すべきか判断できます。これはAIを責めるためではなく、改善可能な設計要素へ問題を戻すためです。

Cloudflareの既存資産とつながる

Cloudflareはもともと、世界中のネットワーク、セキュリティ、サーバーレス実行、ストレージ、リアルタイム通信を持っています。

AIエージェントが外部サービスへ接続し、ユーザーの近くで動き、多数の短い処理と一部の重い処理を組み合わせるほど、これらの資産が効いてきます。

Cloudflare Computer、Agents、Workflows、Containers、R2、D1、KV、Queues、Tracingをまとめる方向は、既存の強みをAI時代の仕事環境へ翻訳する戦略と考えられます。

ただし、これはCloudflareだけが実現できる唯一の形ではありません。AWS、Google Cloud、Microsoft Azure、Vercel、各種Agent基盤、独自Kubernetes構成でも似た要素は作れます。

Cloudflareの優位性は、エッジに近い実行、ネットワーク、セキュリティ、開発者向け部品を一つの環境へ寄せられることです。一方、既存の企業システム、データ基盤、GPU要件、地域要件によっては別のクラウドが適する場合もあります。

使いどころは証拠を作れる業務から選ぶ

AIエージェントの実証実験でよくある失敗は、最初から「何でもできるAI社員」を作ろうとすることです。

仕事の範囲が広く、成功条件が曖昧で、正解データがなく、権限だけが大きい。これでは、どれだけ高性能なモデルを使っても評価できません。

Cloudflareの今回の基盤と相性がよいのは、入力、工程、証拠、完了条件が比較的明確な仕事です。

不具合の再現と一次調査

GitHub Issueを読み、対象版を準備し、問題を再現し、ログを取り、原因候補をまとめる仕事です。

最初は修正やマージまで任せず、再現結果と調査報告を作るところへ限定できます。Local Tracing、Computer、Containers、Workflows、Agent Tracingを小さく組み合わせやすい用途です。

顧客向けレポートの作成

顧客ごとのデータを集め、決められた指標を計算し、説明文とファイルを作り、人間の確認後に送る仕事です。

入力元、計算、テンプレート、承認、送信を分けやすく、費用も顧客単位で測れます。作成は自動化しても、外部送信は承認後に限定できます。

規程に沿ったレビュー

コード、仕様書、営業提案、記事、申請書が、組織のMUSTとSHOULDを満たしているか確認する仕事です。

最初は警告のみとし、誤検知を測ります。安定した必須項目だけをブロックへ移します。Engineering Standards Enforcementの考え方を応用しやすい領域です。

定型的なデータ処理とファイル生成

CSVの検査、画像変換、PDF作成、ファイル名の整理、データの形式変換などです。

正しい結果をテストしやすく、ComputerとContainersの役割分担を検証できます。外部への書き込みを避ければ、失敗時の影響も限定できます。

まだ向かない仕事

一方、次の条件が強い仕事は初期導入に向きません。

  • 正解を人間も説明できない

  • 成功条件が感覚だけ

  • 例外が多く標準手順がない

  • 一度の誤りが生命、法的権利、大きな資金へ直結する

  • 本番データを使わないと試せない

  • 人間の確認者がいない

  • ロールバックできない

  • 正式な入力元が決まっていない

  • 費用を業務単位で測れない

AIができるかではなく、失敗を限定し、証拠を残し、改善できるかで選ぶべきです。

導入は観測から始めて段階的に権限を広げる

Cloudflareの新機能を一度に全部導入する必要はありません。

むしろ、最初の90日では機能数を絞り、一つの業務で「観測できる」「再現できる」「安全に止められる」を確認する方がよいでしょう。

最初の30日は人間の仕事を記録する

対象業務を一つ選びます。

頻度が高く、入力と完了条件があり、失敗を戻せる仕事が適しています。担当者が実際に行っている手順、判断、例外、使うデータ、作る成果物を記録します。

この段階では、AIへ書き込み権限を与えません。

Local Tracing、既存ログ、テストを整え、どの情報があれば原因を調べられるかを確認します。費用の基準値も取ります。

完了条件は「AIが動いた」ではなく、同じ入力から同じ種類の証拠が残り、人間が結果を再現できることです。

次の30日は読み取りと下書きを任せる

AIへ、情報収集、分類、原因候補の整理、下書き、テスト案の作成を任せます。

外部送信、削除、公開、本番変更は許可しません。Computerを使う場合も隔離環境と合成データから始めます。

Agent Tracingで、モデル呼び出し、ツール利用、失敗、再試行、停止地点を確認します。誤りを結果だけでなく原因別に分類します。

情報不足、ツール選択、規程違反、状態欠落、モデル性能、テスト不足など、改善可能な単位へ分けます。

最後の30日は限定的な書き込みを試す

十分なテストと監査ができた工程だけ、限定的な書き込みへ進めます。

対象を一つの環境、一つの顧客、一つのデータ種別へ限定し、実行前の人間承認を残します。一回の費用、実行時間、再試行、同時実行数に上限を置きます。

失敗したときのロールバックと手動復旧を実際に試します。復旧手順が文書にあるだけでは不十分です。

90日後に見るべきなのは、自動化率ではありません。

  • 業務完了率

  • 人間が修正した割合

  • 誤りの種類

  • 調査に必要な時間

  • 一件当たり費用

  • 承認待ち時間

  • 再試行回数

  • ロールバック成功率

  • 顧客や担当者への影響

  • 継続する価値があるか

この結果から、続ける、範囲を変える、停止するを判断します。

AI開発、運用、ガバナンスの実務記事は、こちらのマガジンにまとめられています。個別機能ではなく、設計と運用の流れを続けて確認したい場合に役立ちます。

導入前に経営側が決めるべきこと

Cloudflareの機能選定をエンジニアだけへ任せると、技術的には動くものの、業務上の責任が曖昧なシステムになりかねません。

経営者、事業責任者、業務責任者が先に決めるべき項目があります。

何を成果とするか

処理件数や自動化率だけでは不十分です。

顧客への回答時間が短くなるのか、調査品質が上がるのか、開発者の待ち時間が減るのか、事故が減るのか。業務の価値へ接続した指標が必要です。

どこまでAIへ任せるか

読み取り、下書き、提案、限定書き込み、本番実行を分けます。

削除、公開、送信、課金、契約、権限変更など、外部への影響が大きい操作は、最初から自動化しません。

誰が承認し責任を持つか

「人間が確認する」だけでは足りません。

承認者、代理承認者、回答期限、確認する情報、判断基準、拒否時の処理、停止方法を決めます。承認待ちが長くなれば、AIが速くても業務全体は速くなりません。

何を記録し何を保存しないか

障害調査へ必要な証拠と、保存してはいけないデータを分けます。

機密情報や個人情報を含むトレースを無期限に残すべきではありません。保持期間、閲覧権限、削除、マスキングを決めます。

費用の上限をどう強制するか

Budget Alertsは通知です。

実行ごとの上限、顧客ごとの上限、モデル切り替え、異常停止、同時実行制限をアプリ側で持つ必要があります。将来Walletsを使う場合も、財布を渡す前に予算規程を作るべきです。

失敗したらどう戻すか

ロールバックできない操作は、自動化の最後に回します。

復旧担当者、手動手順、必要な権限、データのバックアップ、二重実行の防止、顧客への連絡を準備します。

いつ撤退するか

PoCは成功条件だけでなく、停止条件を持つ必要があります。

誤りが許容値を超える、費用が人手より高い、確認負担が減らない、データの扱いが要件を満たさない、復旧できない。こうした条件に達した場合は、機能追加で延命せず、対象業務や設計を見直します。

企業でAI導入を研修だけで終わらせず、業務設計、権限、評価、開発、改善運用まで進めたい場合は、こちらの記事で支援内容を確認できます。

今すぐ試すならLocal Tracingから始める

今回の発表群から一つだけ選ぶなら、最も導入しやすく、失敗時の影響が小さく、他の機能へつながるのはLocal Tracingです。

理由は単純です。

AIへ大きな権限を渡す前に、現在のアプリがどう動き、どこで失敗し、何を記録できるかを理解できるからです。

最新版のWranglerまたはCloudflare Vite pluginを使い、ローカル環境でWorkerを動かします。Local Explorerを開き、D1、KV、R2、Queues、Durable Objects、外部APIの処理を確認します。

次に、既知の不具合を一つ再現します。

AIコーディングエージェントへは、単に修正を依頼せず、次の完了条件を渡します。

  • 修正前に同じ問題を再現する

  • 該当するtraceと失敗した処理を示す

  • 推測と確認済み事実を分ける

  • 変更するファイルを限定する

  • 修正後に同じ入力で再実行する

  • テスト結果とtraceで改善を確認する

  • 新しい不具合がないか確認する

これが安定してから、`createTestHarness()`で複数Workerやデータ保存先を含む統合テストへ進みます。

その後に、Agent Tracing、Workflows、Computer、Containersを必要な範囲で追加します。機能を先に集めるのではなく、業務上の不足へ一つずつ対応させる順序です。

今後確認すべき発表と不確実性

2026年8月5日時点では、いくつかの重要な不確実性が残っています。

ArtifactsとCI Workflowsが一般提供へ進む時期。受信TCPとgRPCのPrivate Betaがどのプランと地域へ広がるか。Cloudflare Computerの安定性、料金、隔離モデル。Agent Tracingの課金開始後の実コスト。Billable Usage APIのDocs表記の整理。Walletsの実際の入金、支払い、会計、本人確認、責任分界。214モデルの増減と各モデルの保持条件です。

Cloudflare Connect 2026は10月19日から21日に予定されています。今回の一連の構想が、どこまで一般提供と統合体験へ進むかを見る機会になります。

ただし、イベントを待たないと何もできないわけではありません。

今できるのは、Local Tracingと統合テストを入れ、業務状態を明確にし、予算通知を設定し、AIへ渡す権限を読み取りから段階的に広げることです。

将来機能を前提に大規模な設計を固定するより、現在利用できる部品で小さな実証実験を行い、一般提供へ合わせて差し替えられる構造を作る方が安全です。

非技術者はCloudflareをAI社員の会社として考えると分かりやすい

ここまでで機能名が多すぎて頭が混乱してきたら、一つの会社にたとえると整理しやすくなります。

Workersは、世界各地で小さな仕事を高速に処理する事務所です。短いAPI処理、認証、データの整形、AIモデルの呼び出しなどを、利用者に近い場所で実行します。

Containersは、専用ソフトや重い処理を動かせる業務用PCです。一般的なLinux環境、複雑な依存関係、長いビルド、画像や動画の処理が必要なときに使います。

Durable Objectsは、案件や担当AIごとの専用デスクです。デスクには、現在の会話、作業状況、接続中の利用者、処理待ちの情報を置けます。同じ案件の処理を一か所で順番に扱いやすくなります。

Workflowsは、業務手順書と進行管理を組み合わせたものです。どの工程が終わり、どこで失敗し、次に何をするかを持ちます。途中で止まっても、保存した地点から再開できます。

R2はファイル倉庫です。入力資料、生成したレポート、ビルド成果物、画像、バックアップなどを保存できます。D1は表形式の業務データベース、KVは設定や小さな情報を素早く読む棚、Queuesは仕事を順番待ちに入れる受付です。

Workers AIとAI Modelsは、AI社員が使う頭脳の候補です。仕事ごとに必要なモデルを選べます。

Agents SDKは、AI社員の会話、ツール、状態、人間とのやり取りをまとめる仕事の枠組みです。

Cloudflare Computerは、AI社員がファイルを開き、編集し、コマンドを実行する作業机です。必要な場合だけContainersという業務用PCへ処理を渡します。

Local Tracingは、研修中のAI社員の作業記録です。開発環境で何をしたかを確認します。Agent Tracingは本番配属後の監査記録です。どの顧客案件で、どのモデルが、どのツールを使い、何を待ち、どこで失敗したかを追います。

ArtifactsとCIは、コードを保管し、検査し、公開する製造ラインです。

Billable Usageは部門やサービスの利用料金台帳、Budget Alertsは予算超過が近いことを知らせる通知です。Walletsは、将来AI社員へ用途と上限を定めた財布を持たせる構想です。

このたとえで分かるのは、AI社員を雇うことと、会社として仕事を任せられることが別だという点です。

頭脳だけを用意しても、机、資料、手順、権限、上司の承認、監査、経費管理がなければ、組織では働けません。Cloudflareが整えているのは、この会社側の仕組みです。

同時に、これらはワンクリックで完成する一つの製品ではありません。各部品をどう組み合わせるかは利用企業が設計します。業務の理解が浅いまま機能をつなげると、複雑で高価な仕組みだけが残る可能性があります。

7月後半の更新も同じ方向を補強していた

8月3日と4日の大型発表だけを見ると、急にAIエージェント基盤が現れたように見えます。しかし、7月後半のChangelogも同じ方向を補強しています。

Budget Alertsは費用を後から知る状態を減らす

対象となるPay-as-you-goアカウントでは、既定の10米ドルアラートが順次有効になります。

これは小さな変更に見えますが、AIエージェントの利用では重要です。モデル呼び出しやContainer実行が自動化されると、人間が毎回ボタンを押さないため、費用増加に気づきにくくなります。

ただし、前述の通りアラートは停止装置ではありません。日次処理のため通知には遅れがあり、固定月額料金も対象外です。アラートを設置したことで費用管理が完了したと考えてはいけません。

Devin Outpostsは外部の開発AIをCloudflare上で隔離する

Devin Outpostsでは、Devinの各セッションをCloudflare Containersに支えられた個別のsandboxで実行できます。

ここでの価値は、特定の開発AIがCloudflare製になったことではありません。外部のAIエージェントを、Cloudflareの隔離された実行環境へ持ち込めることです。

将来、企業は一つのAI製品だけを使うのではなく、調査、開発、デザイン、サポートなどで異なるエージェントを使う可能性があります。そのとき、エージェントごとに別のインフラを作るのではなく、共通の実行、ネットワーク、ログ、費用、権限の基盤へ載せられる価値が高まります。

ただし、sandboxがあるから安全だと断定できません。接続先、secret、ファイル、保持期間、本番環境への経路は別に制御する必要があります。

MCPとCode Modeはツールの接続方法を改善する

MCPは、AIが外部のツールやデータへ接続するための共通方式です。Code Modeは、AIが多数の細かいツール呼び出しを繰り返す代わりに、コードとして処理をまとめる発想です。

ツールが増えると、AIは大量の説明文を読み、どのツールを使うか選ばなければなりません。呼び出し回数が増えれば、待ち時間、費用、途中失敗も増えます。

Code Modeで複数の操作を安全なコードへまとめられれば、複雑なデータ処理や連続操作を効率化できる可能性があります。

一方で、コードとしてまとめるほど、一回の実行で起きる副作用が大きくなる場合があります。許可するAPI、実行時間、出力、外部通信、失敗時の扱いを明確にする必要があります。

AI SDKの更新はエージェントを部品として組み込みやすくする

AI SDK周辺の更新は、モデル呼び出し、ツール利用、ストリーミング、構造化出力、エージェント的な処理をアプリへ組み込みやすくします。

重要なのはSDKの版番号そのものではありません。モデル、UI、ツール、状態、監視を別々の部品として扱い、変更しやすくすることです。

新しいSDKへ追随するだけで品質が上がるわけではありません。版を上げた後に、ツール選択、出力形式、トークン量、トレース、エラー処理、利用料金が変わっていないかを再評価する必要があります。

7月後半から8月上旬の更新をつなぐと、Cloudflareの方針は一貫しています。

外部のAIもCloudflare上で動かす。ツール接続を標準化する。実行を隔離する。テストする。追跡する。費用を可視化する。特定の一社製モデルではなく、AIエージェントを動かす共通環境を取りにいく動きです。

複数機能を組み合わせると初めて業務になる

個別機能を理解しても、実際の業務へどう組み合わせるかは分かりにくいかもしれません。ここでは四つの構成例を考えます。

GitHub Issueを調査して修正候補を出す

開始点は新しいIssueです。

WorkerがWebhookを受け、Workflowsを開始します。対象リポジトリとIssueの情報を取得し、ComputerのWorkspaceへ展開します。軽い検索やファイル操作はWorker側で行い、依存関係のインストールやテストはContainerへ渡します。

最初のエージェントは問題を再現し、結果を成果物として保存します。次のエージェントはLocal Tracingやテストログを読み、原因候補をまとめます。別の工程で仕様と既存テストを確認し、本当にバグかを判定します。

修正が妥当な場合だけ別ブランチへ変更を作り、CIで型検査、テスト、ビルドを行います。人間へ差分、再現手順、テスト結果、リスクを提示し、承認後にPull Requestを作ります。

Agent Tracingは、どのモデルが何を調べ、どのツールを使い、どこで再試行したかを記録します。Billable Usageと独自の業務IDを結びつければ、一件のIssue対応にかかった費用を見積もれます。

この構成の成否は、修正数ではなく、再現率、誤修正率、人間の確認時間、再発率で測ります。

顧客ごとの月次レポートを作る

月初のスケジュールを起点にWorkflowを開始します。

D1から対象顧客と設定を読み、外部APIからデータを集め、R2へ原データを保存します。Python Workerで集計や統計処理を行い、TypeScriptのWorkerでレポートの構成とWeb表示を作れます。

AIは数値の異常を説明し、前月との差を文章化します。ただし、数値計算そのものを文章生成モデルへ任せず、コードで計算した値を正式な結果とします。

ComputerでPDFや画像を生成し、R2へ版付きで保存します。人間が内容を確認し、承認後に送信します。

顧客ごとにDurable Objectを使えば、設定、過去レポート、承認状態、再生成回数をまとめやすくなります。

この業務では、個人情報のマスキング、顧客間の隔離、送信前承認、誤送信時の対応が重要です。

組織規程に沿って仕様書をレビューする

正式な規程を一つ決め、MUSTとSHOULDを構造化します。各ルールには所有者、対象領域、根拠文書、適用開始日、例外条件を持たせます。

新しい仕様書が登録されたら、対象領域に関係するルールだけをAIへ渡します。AIは違反候補と根拠を示し、元規程への参照を付けます。

最初は警告として出し、人間が正誤を判定します。誤検知が少なく、判断が安定したMUSTだけを公開や承認のブロック条件へ移します。

規程が変更された場合は、過去のレビュー結果を新しい規程で再評価するか、適用日を分けます。

この構成では、AIの文章力より規程の管理が重要です。古い文書、矛盾、所有者不明のルールを整理せずにAIへ渡すと、指摘数だけが増えます。

将来AIが外部サービスを購入する

現時点では将来構想ですが、Walletsとx402を組み合わせると、AIが必要なAPIやデータへ支払う流れが考えられます。

エージェントが必要なサービスを見つけ、価格と利用条件を取得します。予算、許可された販売者、データ用途、上限を確認し、条件内ならVirtual walletで支払います。高額または初回の購入は人間承認へ回します。

購入したデータや成果物の出所、ライセンス、支払い、利用した案件を記録します。返金やサービス未提供時の処理も必要です。

この構成で本当に難しいのは決済APIではありません。代理権、会計、税務、不正、契約、知的財産、責任分界です。技術的に支払えるようになっても、企業利用には別の制度設計が必要です。

各機能を採用するかは不足している能力から決める

新機能を見つけると、何に使えるかを先に考えがちです。実務では逆の順序がよいでしょう。

現在の業務で不足している能力を特定し、その不足を埋める機能だけを選びます。

CI Workflowsを検討するのは、既存CIで大量のリポジトリ、顧客別ビルド、長い再開可能な工程を扱えない場合です。数個のリポジトリでGitHub Actionsが安定しているなら、置き換える理由は弱いでしょう。

Local Tracingを使うのは、原因調査が推測と追加ログに依存している場合です。現在のログで十分に原因を特定できるなら、導入効果は限定されます。

Agent Tracingを使うのは、AIが複数回の判断とツール操作を行い、最終結果だけでは原因が分からない場合です。一回の文章生成だけなら、通常のログで足りる可能性があります。

Cloudflare Computerを使うのは、AIがファイルとコマンドを扱う必要がある場合です。単純なAPI呼び出しだけなら、Computerを追加すると複雑性が増えます。

Containersを使うのは、OS依存、重い計算、専用バイナリが必要な場合です。軽い処理をすべてContainerへ入れると、起動、費用、運用の負担が増えます。

Durable Objectsを使うのは、顧客や案件ごとに一貫した状態とリアルタイム処理が必要な場合です。単純な読み取り中心のデータなら、D1やKVで十分な場合があります。

Workflowsを使うのは、長い工程、待機、再試行、途中再開が必要な場合です。数秒で終わる一つの処理を無理にWorkflowへすると、構成が分かりにくくなります。

Python RPCを使うのは、既存のPython資産とWorkerの入口を接続する価値がある場合です。チームが一つの言語で十分に開発できるなら、言語を増やす必要はありません。

受信TCPとgRPCを待つのは、HTTP以外の既存システムをCloudflareへ接続する明確な必要がある場合です。Private Betaのため、代替経路も残します。

Billable Usage APIを使うのは、顧客、機能、エージェントごとの費用配賦や自動監視が必要な場合です。月額全体だけで十分なら、ダッシュボードで足りるでしょう。

Walletsを待つのは、AIによる機械間決済が事業上必要な場合です。将来性だけを理由に現在の決済設計を変更するべきではありません。

採用判断の基本は、機能の新しさではなく、現在のボトルネック、導入費用、失敗時の影響、既存手段との差です。

本番運用で最低限確認する実務項目

Cloudflare上でAIエージェントを本番運用する場合、技術構成だけでなく運用の穴を確認する必要があります。

入力と正式な情報源

AIが参照するデータの正式な出所を決めます。

複数のWiki、古い文書、個人メモが混在する場合、更新日と所有者を持たせます。検索で見つかった情報が正式とは限りません。

完了条件

「良いレポートを作る」「不具合を直す」のような曖昧な条件を避けます。

必要なファイル、必須項目、テスト、承認、保存先、外部送信の有無を定義します。

権限

読み取り、下書き、限定書き込み、本番操作を分けます。

一つのtokenへ全権限を与えず、工程ごとに必要な権限だけを渡します。secretの閲覧、ログへの露出、ローテーションも確認します。

隔離

顧客、案件、実行ごとにファイル、状態、ログを分離します。

前の顧客のデータが次の実行へ残らないことをテストします。ContainerやWorkspaceの終了後に何が残るかも確認します。

再実行と二重処理

同じ処理が再試行されても、二重送信、二重請求、重複登録が起きないようにします。

処理ごとの一意なID、完了状態、冪等性を持たせます。冪等性とは、同じ操作を複数回実行しても結果が一度分に保たれる性質です。

監視

エラー率だけでなく、業務完了率、ツール失敗率、承認待ち、再試行、トークン、費用、修正率を見ます。

AIの最終回答が返ったことを成功としません。

プライバシー

トレースへ保存する内容を最小化します。

入力と出力をすべて保存する前に、個人情報、契約、健康、決済、認証情報が含まれないか確認します。保管場所、閲覧者、保存期間、削除要求への対応を決めます。

変更管理

モデル、プロンプト、ツール、規程、SDK、Cloudflare機能の変更を記録します。

一つの変更で品質、速度、費用、トレース量が同時に変わる可能性があります。変更前後を同じ評価データで比較します。

障害対応

停止方法、切り戻し、手動運用への切り替え、顧客連絡を準備します。

担当者が不在でも実行できるようにし、定期的に復旧訓練を行います。

費用管理

一実行、一顧客、一日、一月の上限を持たせます。

予算アラートだけに頼らず、アプリ側で回数、時間、同時実行、モデル、Container利用を制御します。

評価

正解データ、過去事例、失敗例、境界条件を使い、モデルやルールを変更したときに回帰テストします。

成功事例だけでなく、拒否すべき依頼、情報不足、外部障害、誤った入力を含めます。

これまでのクラウド基盤と何が違うのか

ここまで読むと、「既存のクラウドにもコンテナ、ワークフロー、ログ、予算管理はあるのではないか」と感じるかもしれません。その通りです。個々の部品はCloudflareだけの発明ではありません。

今回の変化は、AIエージェント向けの開発、実行、状態、観測、統制を、Cloudflareのグローバルネットワーク上で一続きにしようとしている点にあります。

従来の一般的な構成では、Webの入口はCDN、APIはサーバーレス、長い処理は別のジョブ基盤、状態はデータベース、コード実行はコンテナ、AIモデルは外部API、ログは監視サービス、費用はクラウド請求画面というように、複数の製品へ分かれます。

これは悪いことではありません。成熟した製品を用途ごとに選べる利点があります。一方、AIエージェントの一回の仕事を追うために、複数サービスのID、ログ、権限、費用を対応づける必要があります。

Cloudflareは、Workerを入口にし、Durable Objectsで状態を持ち、Workflowsで長い工程を進め、ComputerとContainersで作業し、R2やD1へ保存し、Agent Tracingで追跡する流れを一つの開発者体験へ寄せています。

この統合がうまく進めば、少人数のチームでもAIエージェントの基盤を作りやすくなる可能性があります。特に、世界中の利用者へ低遅延で提供したいサービス、WebSocketを使うリアルタイムサービス、顧客ごとに状態を持つAI、Cloudflare Workersをすでに使っている企業と相性があります。

反対に、次の場合はCloudflareへ寄せる合理性が弱い可能性があります。

既存システムが特定クラウドのデータベース、認証、分析、GPUへ深く依存している。大規模な学習処理や特殊なGPU構成が中心である。社内ネットワークと既存の監視基盤を変えにくい。地域、契約、データ所在の条件がCloudflareの提供形態と合わない。チームがCloudflareの各部品を運用する知識を持っていない。

比較で見るべきなのは、機能の数ではありません。

一つの業務を作るために必要なサービス数、障害時に追う画面の数、権限モデルの数、データ移動、運用担当者の負担、既存資産との接続、撤退時の移行可能性です。

Cloudflareを採用する場合も、業務ロジックとモデル選択をCloudflare固有の実装へ埋め込みすぎない方がよいでしょう。入力と出力、状態、評価、ツール契約を明確にし、必要なら別基盤へ移せる境界を持たせます。

発表を読んだ時点での推奨判断

2026年8月5日時点の判断を、用途ごとにまとめます。

すでにCloudflare Workersを開発しているチームは、Local Tracingと`createTestHarness()`を優先して試す価値があります。既存の開発手順へ追加しやすく、本番権限を広げずに検証品質を上げられるためです。

AIエージェントを本番運用しているチームは、Agent Tracingのベータを限定環境で検証できます。ただし、保存内容、イベント数、10月以降の料金を先に確認します。

Python資産とWorkersを接続したいチームは、Python Workers RPCを小さなサービスで試せます。呼び出し契約、エラー、タイムアウトを明文化します。

ファイルやコマンドを扱うAIを作りたいチームは、Cloudflare Computerを合成データのPoCで検証できます。Early Previewであるため、本番の顧客データと強い権限は避けます。

多数のリポジトリや顧客別のCIをCloudflare上へ統合したい企業は、ArtifactsのPrivate Betaへ申請する価値があります。一般的な開発チームは、既存CIとの優位差が出るまで待っても問題ありません。

HTTP以外の通信をCloudflareへ持ち込みたい企業は、受信TCPとgRPCのPrivate Betaへ参加条件を問い合わせられます。一般提供を前提にした本番計画は避けます。

Cloudflare Walletsは、現時点では将来の事業機会として観察する段階です。handleの確保には意味があっても、決済機能を前提に売上計画や会計設計を固定するのは早いでしょう。

Engineering Standards EnforcementとAstro Issue Triageは、製品導入ではなく運用設計の参考として、今すぐ応用できます。正式な情報源、役割分担、状態、証拠、人間確認という考え方は、Cloudflareを使わない企業にも有効です。

結局のところ、今すぐ全体を採用する必要はありません。

利用可能な観測とテストから始め、限定した業務で状態と権限を設計し、ベータ機能は代替手段を残して試す。将来構想は事業機会として追うが、現在の機能として扱わない。これが現時点で最も現実的な判断です。

用語を日常語で整理する

最後に、今回登場した言葉を簡単に整理します。

Workerは、Cloudflareの世界中の実行環境で動く小さなプログラムです。Webへの入口、API、認証、データ処理などに使います。

isolateは、Workerを軽く素早く分離して動かす仕組みです。一般的な仮想マシンやContainerより起動が軽い一方、利用できるOS機能は異なります。

Containerは、Linux環境とアプリをまとめて隔離して動かす仕組みです。専用ソフトや重い処理に向きます。

Durable Objectは、特定のIDに対応する状態と処理をまとめる仕組みです。顧客、会話、部屋、案件ごとの専用デスクとして考えられます。

Workflowは、長い仕事の工程、再試行、待機、途中再開を管理する仕組みです。

Agentは、目標に沿ってモデルが情報を調べ、ツールを使い、複数回の判断を行う実行単位です。自動で動くことだけを意味しません。

RPCは、別のプログラムにある関数を手元の関数のように呼び出す方法です。

MCPは、AIが外部のツールやデータへ接続するための共通方式です。接続できることと、その操作が業務上許可されることは別です。

CIは、コード変更時に検査、テスト、ビルドなどを自動で行う仕組みです。

Artifactは、コード、ビルド結果、レポート、画像など、保存や版管理を行う成果物です。

Traceは、一つの処理がどのサービスや関数を通ったかを追う記録です。細かな区間をspanと呼びます。

OpenTelemetryは、トレース、指標、ログを共通形式で扱うための標準的な仕組みです。

量子化は、モデルや一時記憶の数値を小さな形式で表し、メモリや計算を減らす技術です。小さくするほど、精度や速度への影響を評価する必要があります。

KV cacheは、長い文章を生成するときに過去の計算結果を再利用する一時記憶です。

prefillは入力を最初に読む処理、decodeは回答を一語ずつ生成する処理です。片方が速くなっても、全体が必ず速くなるとは限りません。

Private Betaは、申請や招待を受けた利用者だけが試せる段階です。

Early Previewは、方向性や初期実装を検証する早い段階です。重要業務の安定運用を保証する表現ではありません。

x402は、HTTPの支払い要求を使い、機械同士でデジタルサービスの料金をやり取りする仕組みです。

用語を覚えることが目的ではありません。どの言葉も、仕事のどの不足を埋める部品なのかを理解することが重要です。

Cloudflareが示したのはAIの自律化より運用可能性だった

今回の発表を一言でまとめるなら、CloudflareはAIエージェントを「賢いチャット」から「運用できる業務主体」へ近づける周辺基盤を作っています。

コードを検査する。作業環境を与える。長い仕事の状態を持つ。実行を追跡する。組織の規程を守らせる。費用を見えるようにする。将来は予算付きの支払い権限を与える。

この順序は妥当です。

AIにできることが増えるほど、企業が先に強くすべきなのは自律性ではありません。観測、検証、権限、承認、復旧、費用管理です。

最も強いモデルを導入しても、仕事の正式な基準がなく、完了条件が曖昧で、テストがなく、ログが追えず、誰も止められないなら、本番では使えません。

反対に、モデルが完璧でなくても、狭い業務で、入力と出力を定義し、必要な情報を渡し、権限を限定し、証拠を残し、人間が確認し、失敗時に戻せるなら、現実の価値を生み出せます。

Cloudflareの2026年8月の発表が示したのは、AIの未来を派手に語ることよりも、その未来を現場で運用するための地味で重要な部品がそろい始めたことです。

企業が取るべき最初の一歩は、AIへ大きな仕事を任せることではありません。

一つの小さな業務を選び、実行を見えるようにし、同じ条件で再現し、失敗しても戻せる状態を作ることです。そこから初めて、AIエージェントはデモではなく、責任を持って改善できる仕事の仕組みに変わります。

出典・参考資料

いいなと思ったら応援しよう！

南翔伍 / AIコンパニオンとSNSの間くらいの「Jams」開発中 社会問題×マーケティングが好き / ㍿小さな一歩（前澤ファンド出資先）で養育費の未払い問題にビジネスでトライ→㍿SHIRO創業。社会問題の発見→要因分析→ビジネス考案→実行に必要な資本整備→実行・改善のサイクルが最短で回り社会問題が解決されつづけるインフラを創る。

この記事は noteマネー にピックアップされました

noteマネーのバナー