Cloudflare Mesh×Workers VPCで作る、AIエージェントの安全なプライベート接続運用
CloudflareがCloudflare Meshを公開し、Workers VPC経由でAIエージェントにプライベート接続を与えられる流れが見えたことで、論点は「つながるか」から「安全に運用できるか」へ移りました。PoCでは動いていたエージェントが、本番で止まる原因はモデル精度よりネットワークと権限制御であることが増えています。
本記事は、社内APIやデータベースをエージェントに触らせるときに必要な設計を、実装観点で整理します。
いま詰まりやすいポイント
現場で多い課題は次の3つです。
- 社内システムをインターネット公開せずに接続したい
- セキュリティ監査で「誰が・なぜ・どこまで実行したか」を説明したい
- エージェント暴走時に、影響範囲を即時に閉じたい
この条件を満たさないまま自動化を進めると、便利さと引き換えに統制を失います。
推奨アーキテクチャ
実運用しやすい最小構成は以下です。
- Workers: リクエスト整形、ポリシー評価、ツール選択
- Durable Objects: セッション状態、短命トークンの管理
- Workers VPC: 社内API/DBへのプライベート経路
- Cloudflare Mesh: ユーザー・エージェント・サービスの信頼関係定義
- 監査基盤: ツール実行履歴、拒否理由、承認経路の記録
重要なのは、ネットワークを「IPの許可」ではなく「主体と目的の許可」で扱うことです。
主体を分離して権限を設計する
同一の「エージェント権限」で全部を通すと、事故時の説明責任が崩れます。最低でも以下を分けます。
- Human Principal: 実行を起点した人
- Agent Principal: 実際に処理したエージェント
- Tool Principal: 呼び出された社内サービス
各ツール呼び出しに、
(human_id, agent_id, workflow_id, tool_id, policy_version, expiry)
のような文脈付き短命トークンを使うと、漏えい時の再利用リスクを大幅に下げられます。
ポリシーは4層で定義する
- 接続ポリシー: 到達可能なVPC先
- データポリシー: 参照可能なデータ分類
- 操作ポリシー: read / summarize / write / execute
- 予算ポリシー: 呼び出し回数、実行時間、推論コスト上限
拒否時は「失敗」で終わらせず、approval_required などの構造化ステータスを返し、運用画面で次アクションを明示すると現場が回ります。
影響範囲を狭める実装パターン
- ワークフロー単位で資格情報を発行（共有キー禁止）
- 高リスクツールは読み取り専用から開始
- 外向き通信はallowlistで固定
- ツールの再帰呼び出し深度を制限
- 同一実行で「重要書き込み領域」を複数持たせない
例えば、請求データ更新と本番デプロイを同じエージェント権限にまとめるのは避けるべきです。
監査の見える化
監査で本当に効くログは次です。
- ポリシー判定（許可/拒否、ルールID）
- ワークフローごとのツール呼び出しグラフ
- 人間からエージェントへの委譲チェーン
- マスキング・変換イベント
- リトライ理由（タイムアウト、権限、スキーマ不一致）
運用KPIとしては、
- 安全完了率（統制違反なしで完了した割合）
- 封じ込めMTTR（異常検知からトークン無効化までの時間）
を置くと、SREとセキュリティが同じ指標で改善できます。
30日導入ロードマップ
- 1週目: 既存ツールを機密度で棚卸し
- 2週目: 高機密系を読み取り専用でMesh経路に移行
- 3週目: 承認付き書き込みを段階導入
- 4週目: 漏えい想定の演習と手順修正
最初から完全自律を狙うより、封じ込め能力を先に作る方が、導入速度も結果的に速くなります。
まとめ
AIエージェントの本番運用は、モデル選定よりも「権限境界」と「封じ込め速度」で勝負が決まります。Cloudflare MeshとWorkers VPCは、その境界を設計しやすくする土台です。短命ID、明示ポリシー、監査可能性の3点を先に固めれば、現場で止まらない自動化へ進めます。
