Cloudflare Agents Weekを実装設計へ落とす, 企業向けエージェント基盤リファレンス

Cloudflare Agents Weekの発表群は, 単発機能の追加ではなく, エージェント運用に必要な層を一気に揃えた点に価値があります。Agent Memory, AI Search, Artifacts, AI Gateway, Workers AI, Agent Readiness scoreまで含めると, 企業が本番展開するための骨格が見えてきます。

重要なのは, これを「新機能の寄せ集め」で終わらせず, 役割分担された設計に落とすことです。

何が揃ったのか

実装目線では次の構成です。

AI Gateway: モデルルーティング, 可観測性, ポリシー適用
Workers AI: 推論実行基盤
Agent Memory: 会話・タスク継続の状態管理
AI Search: 根拠ドキュメント探索
Artifacts: Git互換の成果物管理
Agent Readiness: エージェント向けWeb品質の測定

この組み合わせにより, 推論だけでなく「状態」「根拠」「実行」「監査」を一つの運用モデルで扱えるようになります。

MemoryとSearchを混ぜない

初期導入でよくある失敗は, メモリと知識検索を同じストアで処理することです。これを分離しないと, 監査・再現・削除ポリシーが衝突します。

Memory: セッション文脈, 嗜好, 一時状態。TTLや忘却を前提に設計。
Search: 根拠文書, マニュアル, 仕様。再現性と版管理を優先。

Memoryは動的, Searchは証跡。この原則を守るだけで障害解析が大幅に楽になります。

企業向けコントロールプレーン

レイヤー1, リクエスト統制

地域/コスト/機密区分に応じたモデルルーティング
入出力ログのマスキング
レート制御と濫用防止

レイヤー2, 認知サービス

推論エンドポイント
検索オーケストレーション
メモリAPI（保持期間・削除規約付き）

レイヤー3, 実行安全

ツール呼び出しポリシー判定
破壊的操作の確認フロー
サイドエフェクトを伴う処理のシミュレーション

レイヤー4, 観測と経済性

トークン/遅延/失敗率ダッシュボード
ユースケース別コスト配賦
エラーバジェット運用

この構造があれば, モデル差し替えが発生しても制御面は崩れません。

Agent Readinessを軽視しない

Readiness scoreは見た目には診断機能ですが, 実際は機械アクセス時代の情報設計KPIです。

正規URLへの統一
廃止ページのリダイレクト整備
FAQ/手順書の機械可読性向上

これらは検索流入だけでなく, サポート削減や社内ナレッジ再利用率に直結します。

SRE観点の必須ルール

長時間エージェントでは, 再試行で副作用が増幅しやすい。最低限, 次を標準化します。

状態変更APIに冪等キー
チェックポイントと再実行安全な状態遷移
1タスクあたりのステップ数上限と時間上限
ツール実行タイムラインの可視化

「失敗したときに同じ結果で復旧できるか」が運用品質の境界です。

セキュリティと監査

本番適用前に以下を固定します。

メモリ書き込み前のデータ分類判定
検索対象ドメインの許可リスト
Artifactsの署名/由来検証
テナント分離試験

ドキュメントだけの統制では意味がなく, 実行時に機械強制される必要があります。

90日導入ロードマップ

1〜30日: 観測基盤と最小ポリシーを整備
31〜60日: Memory/Search分離, 冪等実行を導入
61〜90日: 事業KPI連携, コストSLO運用, Readiness改善ループ

まとめ

Agents Weekで見えた本質は, モデル性能競争よりもライフサイクル統制の重要性です。

Gateway, Memory, Search, Execution Safetyの責任境界を先に決めた組織は, 将来のモデル更新を「運用変更」で吸収できます。逆に境界が曖昧な組織は, 小さな機能追加でも本番障害を起こしやすくなります。