Cloudflareで作るエッジAI：Workers AI、AI Gateway、Agentの責任境界

エッジに近いことと、状態を安全に持てることは別だ

CloudflareをAIアプリに使う時、まず速さの話から始めたくなる。Workers AIは推論をWorkersと統合する入口、AI Gatewayは複数provider呼び出しの観測・制御を考える入口、Agentsは状態を持つ対話や作業を考える入口になる。しかし、低い待ち時間は正しい権限、正しい会話状態、正しい請求を自動では作らない。

1. 1browser
2. 2Worker auth/rate limit
3. 3model or gateway

1. 1会話状態
2. 2durable state
3. 3利用者別の権限境界

1. 1tool call
2. 2validator/allowlist
3. 3外部API

1. 1trace/usage
2. 2上限・異常検知
3. 3運用者

エッジWorkerは短い認証、入力検査、キャッシュ可能な検索、ストリーミング中継に向く。ただしLLMの応答は利用者・時刻・会話で変わるため、通常のHTMLと同じ感覚で共有cacheへ置くと他人の回答を見せる危険がある。cache keyに何を含めるかを設計し、個人データや認証済み回答は原則共有cacheしない。秘密情報はWorkerのsecretとして管理し、browserやclient bundleへ出さない。

gatewayは監査の入口で、業務権限の代わりではない

AI Gatewayを使うと、provider別の失敗、遅延、使用量を一つの経路で観察しやすくなる。だがgatewayに送る前に、アプリが利用者権限、入力サイズ、機能別の予算を判定する。ログを残す場合も、prompt全文・添付・認証情報を無条件に保存しない。request ID、モデル、token、終了理由、匿名化した評価ラベルから始め、本文保存は必要性と保持期間を決めてからにする。

別のproviderやmodelへの自動フォールバックを実装しない。上流の失敗は明示的なエラーとして返し、依存するtool実行を止める。設定するproviderの変更は、品質・データ処理・費用を評価した別のデプロイ判断として行う。429に対するretryも回数、backoff、総予算を固定する。呼び出し失敗を再帰的に再試行するコードは、障害時に自分で負荷を増やす。

stateful agentは会話ログではない

AgentsやDurable Object的な状態を使う時、状態には会話履歴、ジョブ進捗、ツール結果、利用者設定を何でも入れたくなる。だが状態は削除、移行、共有、障害復旧の対象でもある。会話履歴と長期記憶を分け、根拠URL・取得時刻・利用者IDを持たない要約を作らない。利用者が会話を消した時に何を消すか、再接続でどこまで復元するかを先に決める。

1. 1message
2. 2conversation ID + user ID
3. 3state load

1. 1必要な根拠だけ検索
2. 2response stream
3. 3event保存

1. 1削除要求
2. 2state/index/log保持規則
3. 3実行記録

toolを呼ぶagentでは、入力WebページやPDFに書かれた命令をsystem instructionと同格にしない。取得物はデータである。tool名をallowlistし、JSON schemaを検査し、対象resourceへのACLを独立に確認する。書き込みは人の確認を挟み、read-only toolと別のcredentialにする。MCPなどの接続方式は便利でも、接続先が読むファイル・送るデータ・持つtokenを減らす設計が必要だ。

実習：エッジAIの受け入れ試験

1. 未認証、別利用者、過大入力、長い会話、同時送信で、同じ状態や回答が混ざらないか試す。
2. providerの成功、429、timeout、stream切断、gateway障害を注入し、画面が再送・待機・失敗を区別するか確認する。
3. 一日・利用者・機能ごとの上限を設定し、上限到達時はモデル呼び出し前に止まることを確認する。
4. toolの想定外引数、権限外ID、prompt injection文字列を渡し、操作されず監査に残ることを確認する。
5. cold start、p50/p95待ち時間、token、cache hitを同じ作業で測る。速い一回だけを性能値にしない。

Cloudflareの価値は、近い場所で小さな制御を組み合わせられる点にある。そこにstateとAIを足す時は、境界を薄くするのではなく、認証・状態・外部操作を明確に分ける。そうすれば速さが事故の速さにならない。

具体例：個人学習ノートの要約

利用者が自分のノートを要約する機能なら、Workerはログイン済みの利用者IDを確認し、その利用者のnote IDだけを読み取る。要約結果を共有cacheへ入れず、利用者ID・note revision・model revisionを含むprivateな記録として保存する。ノート更新後に古い要約を見せないため、revisionを比較する。生成が失敗しても元ノートを上書きせず、最後に成功した要約と失敗時刻を分けて表示する。

Agentが「関連リンクを探す」場合も、最初はread-onlyの検索結果を下書きにする。リンクをブックマークへ保存するtoolは別の確認操作にし、外部ページに書かれたプロンプトを信用しない。利用者が削除を押した時は、会話state、保存した要約、検索index、運用ログをどこまで消すかを明示する。edgeへ近づけても、削除と同意の責任は近くならない。

障害時は、stateを失ったように見せて新しい会話を始めない。最後に確定したrevision、再開できるjob、再実行が必要なjobを区別して表示する。利用者が同じノートを二度要約しても、本文hashが同じなら同じ結果を再利用できるかを検討する。ただし、モデル更新後の再生成は別revisionとして残す。

2024〜2026年の変化: エッジ配置はエージェント権限と交わる

2024年のエッジAI議論は主に近接性と推論統合に集中していました。2026年には、アプリケーションがツール、保存状態、自律リトライも公開します。Cloudflareの2026-09-29のセキュリティ枠組みは、AI機能がコード、トラフィック、資格情報にまたがる攻撃面を増やすことを考えるきっかけです。これはCloudflare自身の方針説明であり、Workerやゲートウェイが初期状態で安全だという証明ではありません。

各ルートには3行の脅威モデルを使います。主体（認証済みユーザーまたはサービス）、データ／操作（読取・変更できるもの）、実行権限（Worker、Durable Object、下流API）です。モデル呼び出し前に3つすべてを束縛し、モデルが提案したツール引数の後にも再検証します。ストリーミング出力では、起動前にキャンセルと切断時の挙動を定義します。リクエストの権限が消えたら上流作業を止め、終端状態を記録し、繰返しリクエストを冪等にします。推論前に計測し、ゲートウェイトレースはトラフィックを観測しても権限決定にしてはいけません。

2026-09-24 の自己ホスト文書をエージェントが読むことについての r/selfhosted 議論はコミュニティ経験に限られる。検索traceと最小権限の文書アクセスを試すことは示唆するが、Cloudflare製品の挙動を検証するものではない。

Cloudflareの2024年4月のPython Workers発表は、Python codeをJavaScriptと同じWorker binding modelへ入れた。制約は消えない。bindingが依然としてrequestの到達先を決める。agent routeではbindingごとにdeny fixtureを1件実行し、toolやmodelを足す前にtraceを宣言したroute-to-authority mapと比べる。