Cloudflare Workers AI大型モデル時代の設計: エッジAIエージェント基盤の実務

何が変わったのか

CloudflareがWorkers AIで大型モデル対応を前面に出したことで、エッジは単なるCDN最適化の場ではなく、AIエージェント実行基盤として評価される段階に入りました。ここで重要なのは、モデル性能比較ではなく、運用可能なアーキテクチャに落とせるかです。

最初に決めるべき設計論点

まず推論配置を決めます。

• すべてエッジで処理
• 中央集約リージョンで処理
• エッジは制御、重い推論は中央（ハイブリッド）

実務ではハイブリッドが最も現実的です。初回応答は速く、重処理はコスト予測しやすくなります。

基本構成の推奨

Workers AI採用時は、次の責務分離が有効です。

• Workers: オーケストレーション
• Durable Objects: セッション状態
• Queues: 非同期ツール実行
• R2/KV: 参照データ・ポリシー断片
• 集約ログ基盤: 監査・追跡

この構成で「速さ」と「検証可能性」を両立できます。

SLOを1本化しない

エージェント基盤でSLOを一つにすると失敗します。最低でも分離してください。

• First token latency（対話体験）
• End-to-end latency（業務完了時間）
• ポリシー判定遅延（統制品質）

どれか一つだけ改善すると、別軸で事故が起きます。

コスト管理の勘所

トークン課金だけでは運用コストを見誤ります。実際は再試行やツール呼び出しの増幅が効きます。

必要な制御:

• テナント別上限
• タスク難易度に応じたモデルルーティング
• コンテキスト圧縮の閾値
• 参照キャッシュの有効期限設計

セキュリティ境界

エッジAIで必須なのは次の3境界です。

1. セッション間の実行分離
2. ツール実行権限の最小化
3. モデル投入前のコンテキスト浄化

とくにツール呼び出しは「出力機能」ではなく「権限行使」として扱うべきです。

監査可能性を最初から組み込む

後付けで監査を足すと破綻します。最初から次を保存します。

• リクエストごとのモデルバージョン
• ポリシー判定ログ
• ツール引数と結果
• 例外承認者と理由

これがないと、インシデント後の再発防止策が作れません。

導入の段階設計

推奨は3段階です。

• 第1段階: 読み取り専用の社内支援ボット
• 第2段階: 書き込みを限定した開発支援
• 第3段階: 承認付き業務自動化

各段階でblast radiusを明示し、戻し手順を事前定義します。

まとめ

Workers AIの大型モデル対応は、エッジ活用を再定義するチャンスです。性能だけを見るのではなく、制御プレーン、監査可能性、運用SLOまで含めて設計できるチームが、最終的に安定して成果を出します。