Cloudflare MeshがAIエージェント向けプライベートネットワークを実現——Workers VPCバインディングとMCPの二層権限制御

背景：AIエージェントが「内部ネットワーク」に接触する必要が出てきた

2026年4月13〜17日にCloudflareが開催した Agents Week 2026 で、新サービス Cloudflare Mesh が正式発表された。

AIエージェントがプロダクションで実際に価値を発揮するには、プライベートデータベース・社内API・マルチクラウド上のサービスへのアクセスが必要だ。しかし従来の手段では課題が山積みだった。

従来の問題:
  ❌ トンネルを手動設定しないとプライベートネットに到達できない
  ❌ AWS・GCP間のVPN設定が複雑でエージェントとの統合が困難
  ❌ エージェントがどのサービスに何の操作をできるか制御する仕組みがない
  ❌ エージェントの全リクエストを監査するログ基盤がない

Cloudflare Meshとは何か

Cloudflare MeshはTunnel・WARP・Magic WANを統合した単一のプライベートネットワークファブリックとして機能する。ラップトップ・オフィスサーバー・AWS/GCPのクラウド環境、そしてCloudflare Workers上のAIエージェントをひとつの閉じたネットワークで接続する。

Cloudflare Meshのアーキテクチャ:

  [プライベートDB / 社内API / マルチクラウドサービス]
          ↕ プライベートIPルーティング（公開インターネット不使用）
  [Cloudflare Mesh（統合プライベートファブリック）]
          ↕ Workers VPCバインディング
  [Cloudflare Workers 上のAIエージェント]
          ↕ MCPサーバー（操作スコープ制御）
          ↕ Cloudflare Gateway（ログ・ネットワークポリシー）
  [ユーザー / オーケストレーター]

すべての通信はCloudflareのグローバルネットワークを経由し、外部からは不可視になる。

実際の設定方法

wrangler.tomlでWorkers VPCバインディングを設定

# wrangler.toml
name = "my-ai-agent"
compatibility_date = "2026-04-01"

[[workers_vpc]]
binding = "NETWORK"
network_id = "cf1:network"

network_id = "cf1:network" の1行で、アカウント内のすべてのトンネルとMeshノードに到達できる。サービスごとに個別バインディングを作る必要はない。

WorkerからプライベートサービスへアクセスするTypeScriptコード

interface Env {
  NETWORK: Fetcher;
}

export default {
  async fetch(request: Request, env: Env): Promise<Response> {
    // Meshネットワーク上のプライベートIPへ直接アクセス
    // このIPはインターネットから到達不能
    const dbResponse = await env.NETWORK.fetch(
      "http://10.0.0.42:8080/api/query",
      {
        method: "POST",
        body: JSON.stringify({ sql: "SELECT * FROM users LIMIT 10" }),
      }
    );

    const data = await dbResponse.json();
    return Response.json(data);
  },
} satisfies ExportedHandler<Env>;

Durable Objectsでも同じバインディングが使えるため、長期記憶を持つエージェントでもプライベートデータへのアクセスが可能だ。

二層権限制御の設計

Cloudflare Meshの権限制御は「ネットワーク層」と「操作層」の2段階に分かれている。

Layer 1: ネットワーク層（Cloudflare Gateway）
  役割: エージェントが「どこに」アクセスできるかを制御
  手段: IPアドレス・ポートのホワイトリスト
  監査: 全リクエストのログを自動取得
  失効: バインディングを削除すれば即アクセス遮断（Workerの再デプロイ不要）

Layer 2: 操作層（MCPサーバー）
  役割: エージェントが「何を」できるかを制御
  手段: 許可するツール・アクションをMCPサーバーで定義
  例: "DBへの読み取りは許可、書き込みは禁止"
      "特定のAPIエンドポイントのみ呼び出し可"

この分離により、「ネットワークに到達できる = 何でもできる」という状況を防げる。

現時点の制限と注意点

IPベースのルーティングのみ: ホスト名（例: postgres.internal）によるルーティングは未サポート（2026年4月現在）
パブリックベータ段階: 価格・SLAは正式GA時に変更される可能性がある
Meshは現在Workers VPC経由でのみアクセス可能: Cloudflare外のサービスから直接Meshに接続する方法は別途設定が必要

まとめ

Cloudflare MeshはAIエージェントをプロダクションの内部インフラに安全に接続するための、現時点では最も整備されたソリューションだ。特にCloudflare Workersベースのエージェントを使っている場合、wrangler.toml 1行の追加で既存の社内インフラへの接続が実現できる手軽さは大きい。Gateway（到達先の制御）とMCP（操作の制御）を分離する設計思想は、今後のAIエージェントセキュリティの標準パターンになる可能性がある。

S	公式ソース確認済み
A	成功実績多数・失敗例少数
B	賛否両論
C	動作未確認・セキュリティリスク高
Z	個人所感