Cloudflareをテックにかなり寄せて解説してみた

2026年8月15日2026年8月17日

はじめに

社内でAIエージェントを動かそうとして、権限の設計で止まっていないでしょうか。エージェントに読み取りだけをさせるなら許せる。書き込みまで任せてよいのか。社内のどこまでを見せてよいのか。この線引きが決まらないまま、検証だけが長引いていないでしょうか。

止まる理由ははっきりしています。危険な操作を禁止リストで止めるだけでは、業務利用に必要な安全性を説明できないからです。 AIコーディングエージェントの実行環境のセキュリティを体系化した2026年7月の調査は、2023年から2026年の39本の研究を集計し、実運用の拒否リストのうち69%から98%は回避できたと報告しています。同じ調査は、現実的な指示を与えた場合、攻撃を受けていなくてもエージェントの行動の最大17.1%が想定範囲の外に出るとも述べています。

補足: この調査は単著のプレプリントで、査読を経ていません。既存研究の集計であり、69%から98%という幅は集計元の評価ごとの違いです。個別の環境に当てはまる値ではなく、桁を掴む用途で読んでください。

つまり、禁止する項目を書き足すだけでは、回避手法の増え方に追いつきません。エージェントは、渡していない権限を使えない。この形に設計を変える必要があります。

本記事では、その設計をCloudflareの上で組む方法を扱います。Workers、Durable Objects、Agents SDK、Sandbox SDK、そして2026年8月4日に公開されたCloudflare OSまでを、どの用途に向くか、どこから別の基盤が必要かも含めて整理します。3章は手元での実機検証、ほかの章は公式ドキュメントと論文に根拠を置いています（検証環境は記事末尾）。

きっかけは仕様の変更です。MCP（Model Context Protocol、AIがツールを呼び出すための共通仕様）は2026年7月28日の改訂で、プロトコルの中核がステートレスになりました。その結果、状態を持たないMCPサーバーなら、セッション保存用の基盤なしにWorker 1本で動かせます。 3章では、読み取り専用のMCPサーバーを手元で1本立てた結果をコードとあわせて示します。

以前の記事「【セキュリティ】プロンプトインジェクションの対策方法を徹底解説する」では、入力に指示を混ぜ込む攻撃を検知で防ぎきるのは難しいと書きました。本記事はその続きにあたります。検知ではなく、権限の渡し方で解決する方法を扱います。

ノーコードソリューションズ

【セキュリティ】プロンプトインジェクションの対策方法を徹底解説する | ノーコードソリューションズはじめに：なぜ今、プロンプトインジェクション対策が急務なのか「社内にDifyでAIチャットボットを導入したが、セキュリティは大丈夫だろうか？」この不安を抱える情シス…

1. Cloudflareとは何か｜CDNからAIエージェントの実行基盤へ

1-1. 配信網の上でコードが動くようになった

Cloudflareは元々、Webサイトの前段でコンテンツを配信し、攻撃を止めるための会社です。この配信網の上で利用者のコードを動かせるようにしたものがWorkersで、V8 isolate（Chromeが採用している、JavaScriptを軽量に隔離して動かす仕組み）を使い、リクエストを受けた地点でそのコードを実行します。コンテナを立ち上げて特定の地域で動かす従来の関数実行とは、ここが違います。

差は実測に出ています。2026年4月に公開された比較研究は、7つのサーバーレス基盤を世界20地域から3,816万5,688回呼び出しました。応答時間の中央値はCloudflare Workersが7ミリ秒。地域を固定する第一世代の基盤も、近い地点から温まった状態で呼べば約40ミリ秒まで縮まり、AWS Lambdaのコールドスタートは270ミリ秒から295ミリ秒でした。

差の一部は実行方式、残りは利用者から実行地域までの距離で生じます。エージェントではモデルの推論時間のほうが長いため、7ミリ秒という数字だけで基盤を選ぶべきではありません。効果が出るのは、ツール呼び出しやゲートウェイのように、1回の依頼で短い通信を何度も繰り返す部分です。

補足: 測定期間は2025年11月13日から2026年1月5日で、期間中の一時的な性能変動も報告されています。恒久的な順位ではなく、この期間の実測として扱ってください。

1-2. なぜAIエージェントの基盤として名前が挙がるのか

AIエージェントは1回のやり取りで終わりません。依頼を受け、ツールを呼び、結果を見て次の手を決め、人の承認を待ち、また続きを実行します。この途中経過を、基盤の側でどこかに保持する必要があります。

Cloudflareはこの保持先としてDurable Objectsを用意しています。処理と保存領域（組み込みのSQLite）に加えて、複数の接続をまとめる調整の役割を1つにした仕組みで、使われていない間は休眠し、必要になると起き上がります。

Agents SDKでは、エージェントの1セッションがDurable Object 1つに対応します。 公式ドキュメントは、各セッションが永続的なID、ローカルのSQLストレージ、リアルタイム接続、スケジュール実行、復旧可能な実行を持つと説明しています。状態を別のデータベースへ外に出す必要がありません。

2. Cloudflareでできること

2-1. 部品ごとの役割と、無料で使える範囲

エージェント基盤の中心部品を、推論、状態、ツール、隔離、認証の5つに整理します。Cloudflareはこの5つをそれぞれ別の製品として提供しています。稟議で最初に聞かれる費用を、役割と一緒に並べます。 監査ログ、人の承認、秘密情報の更新、障害時の復旧は、この5つとは別に設計が必要です。

部品	役割	無料で使える範囲	有料の単価
Workers AI	推論	1日あたり10,000 Neurons	1,000 Neuronsあたり $0.011
Durable Objects	状態の保持	1日あたり10万リクエスト、13,000 GB秒、行の読み取り500万、行の書き込み10万、保存5GB	100万リクエストあたり $0.15、100万GB秒あたり $12.50
Workers	ツールやMCPサーバーの実行	1日あたり10万リクエスト、1リクエストあたりCPU時間10ミリ秒	月額最低 $5。月1,000万リクエストとCPU時間3,000万ミリ秒を含む
Sandbox SDK	隔離されたコード実行	無料枠なし	Workers Paidプランが必要
Cloudflare Access	利用者の認証と到達制御	Zero Trustの無料プランで50ユーザーまで	Pay-as-you-goは1ユーザー月額 $7（年払い）

補足: Neuronsは、Workers AIの利用量を表すCloudflare独自の単位です。モデルごとに換算率が違います。

無料プランでは、SQLiteをストレージバックエンドにしたDurable Objectsだけを使えます。Cloudflare Accessは50ユーザーまで無料なので、検証や部門単位の試験導入なら、追加費用なしで認証を前段に置けます。 ただしAccessが決めるのは、誰がMCPサーバーへ到達できるかまでです。ツール単位・操作単位の認可は別に実装します（3-7で扱います）。

無料プランの日次上限は協定世界時の午前0時にリセットされ、利用量が上限を超えた時点で操作が失敗します。業務で常用するなら、上限超過をエラーとして扱う設計と監視を用意したうえで、有料プランを前提にしてください。 1回の実行に使えるCPU時間は既定30秒、設定により最大5分です。長い処理を1回のWorkerへ詰め込まず、WorkflowsやQueuesでの分割を検討してください。なお、外部モデルの利用料、ログの長期保管、SIEMへの転送、開発・運用工数は表の金額に含まれません。

2-2. Workers AIの費用を実額に直す

Neuronsのままでは判断できないので、実際の金額に直します。公式の料金表によると、Llama 3.2 1Bは入力100万トークンあたり2,457 Neurons、出力100万トークンあたり18,252 Neuronsです。1,000 Neuronsあたり $0.011 なので、次の計算になります。

入力100万トークン：2,457 ÷ 1,000 × $0.011 = 約 $0.027
出力100万トークン：18,252 ÷ 1,000 × $0.011 = 約 $0.20

1日10,000 Neuronsの無料枠は、このモデルの入力だけに使うなら約407万トークン、出力だけなら約55万トークンに相当します。社内の問い合わせ対応のような用途なら、無料枠の中で試作できる規模です。

ただしLlama 3.1 70Bは、100万トークンあたり入力26,668 Neurons、出力204,805 Neuronsで、10倍以上になります。モデルの選択がそのまま費用の桁を決めます。

2-3. モデル呼び出しを集約するならAI Gatewayを挟む

Workers AIはCloudflareの配信網の上で動くモデルを使います。ClaudeやGPTのような外部モデルを使う場合も、Workers AIを使う場合も、呼び出しをAI Gatewayへ集約できます。AI Gatewayは、モデルごとの費用と利用量の追跡、ログ、キャッシュ、呼び出し方針を1か所にまとめる層です。

Cloudflare自身が社内の基盤を組んだときの記録に、この構成を選んだ理由が書かれています。

クライアントをAI Gatewayに直接つなぐこともできたが、Workerを挟んだことで、クライアント側の設定に一切触れずに、後からユーザー単位の帰属、モデルカタログの管理、権限の適用を追加できた。

2-4. 隔離が必要になる場面

エージェントにコードを書かせて実行させる場合は、Sandbox SDKを使います。サンドボックスはそれぞれ独立したコンテナで動き、完全なLinux環境（シェル、ファイルシステム、バックグラウンドプロセス）を提供します。

実行環境では、許可した機能と接続先だけを使える状態にします。コード内の禁止語を増やすのではなく、ファイル、ネットワーク、秘密情報の境界をエージェントの外側で強制する考え方です。

ただし制約が2つあります。Workers Paidプランが必要で、無料では試せません。 また安定版は @cloudflare/sandbox で、次のメジャーリリースである Sandbox SDK 1.0 は @cloudflare/sandbox@next のプレビュー扱いです。1.0を前提に設計すると、正式公開までに変更が入る可能性があります。

補足: メモリ、vCPU、ディスクの具体的な数値は、公式ドキュメントがContainersの制限ページを参照するよう案内しています。設計時はそちらを確認してください。

2-5. Cloudflareが向く用途と、向かない用途

Cloudflareを使うかどうかは、製品数ではなく、エージェントと社内システムの間に制御点を置きたいかで判断します。

判断	向いている状況	理由
向く	社内外から呼ばれるリモートMCPサーバーを公開したい	Workers、Access、MCP Server Portalsを同じ経路に置ける
向く	多数のエージェントセッションが待機と再開を繰り返す	Durable ObjectsがID、状態、接続、スケジュールをまとめて持てる
向く	複数のモデル事業者を使い分け、利用者別に費用を追いたい	WorkerとAI Gatewayを共通の制御点にできる
向く	AIが生成したコードを実行する	Sandbox SDKやDynamic Workersで実行環境を隔離できる
慎重に判断	データと社内APIがAWS、Azure、Google Cloudの閉域内に集約されている	クラウドをまたぐ認証、通信、障害対応の運用が増える
慎重に判断	GPU学習や大規模バッチ処理が中心である	Cloudflareの強みはモデル学習基盤より、リクエスト処理と制御層にある
待つ選択もある	完成済みの汎用AIワークスペースをすぐ本番導入したい	Cloudflare OSはEarly accessで、運用手順に未整備な部分がある

Cloudflareは、既存のデータ基盤をすべて移す先というより、利用者・モデル・ツール・社内システムの間をつなぎ、認証・記録・権限を強制する制御層として使うと強みが出ます。既存クラウドのデータを動かさず、入口だけWorkersにする構成も選べます。

3. 実践例｜MCPサーバーをWorker 1本で立てる

3-1. 完成すると何ができるか

この章の手順を実行すると、次の状態になります。

社内の在庫を品番で引くツールが、MCPサーバーとして動く
プロトコルのセッションを保持する基盤なしに、Worker 1本だけで応答が返る
AIクライアントから見えるツールの一覧と、実際の呼び出し結果を手元で確認できる

必要なのはNode.jsとnpmだけで、Cloudflareのアカウントがなくてもローカルで確認できます。この例は状態を持たない読み取り専用ツールです。書き込みや利用者ごとの状態が必要なMCPサーバーには、認証、承認、Durable ObjectsやWorkflowsを追加してください。

3-2. 2026年7月28日の改訂で何が変わったか

先に、なぜWorker 1本で足りるようになったのかを説明します。

MCPプロジェクトの公式ブログ（2026年7月28日、David Soria Parra、Den Delimarsky）は、改訂の内容を次のように説明しています。

項目	旧仕様	2026-07-28 仕様
接続開始のやり取り	`initialize` と `initialized` が必須	廃止
セッションの識別	`Mcp-Session-Id` ヘッダー	廃止
必要な情報の運び方	セッションに保持	リクエストごとに全部運ぶ
必要な基盤	セッションを保持できるサーバー	Workerだけで足りる
通信の方式	HTTP+SSE の旧トランスポートも利用可	非推奨

表に挙げたもの以外に、Roots（クライアント側のファイル領域をサーバーに知らせる仕組み）、Sampling（サーバーからクライアント側のモデルを呼ぶ仕組み）、Logging、動的クライアント登録も非推奨になりました。逆に、途中で利用者の入力や承認が必要な処理向けに、Multi Round-Trip Requests（MRTR）が追加されています。移行するなら、廃止・非推奨の機能を使っていないか、接続するクライアントが2026-07-28仕様に対応しているかを先に確認してください。

新しく Mcp-Method と Mcp-Name というHTTPヘッダーが加わりました。途中のゲートウェイやファイアウォールが、本文のJSONを解析せずにMCPの通信を識別して振り分けられます。社内で通信を絞りたい場合の判断材料になります。Mcp-Method は全リクエストで必須、Mcp-Name は tools/call、resources/read、prompts/get で必須です。 クライアント側で付け忘れると、本文の method と食い違っているというエラーが返ります。

3-3. プロジェクトを作る

作業用のフォルダを作り、必要なパッケージを入れます。

# 作業フォルダを作って移動する
mkdir mcp-worker && cd mcp-worker
# package.json を作る
npm init -y
# ローカル実行とデプロイに使うコマンドラインツール
npm install --save-dev wrangler
# MCPサーバー本体、Cloudflareのエージェント用ライブラリ、入力の型を宣言するライブラリ
npm install @modelcontextprotocol/server agents zod

Workerの設定ファイルを作ります。

// wrangler.jsonc
{
  // Worker の名前。デプロイ時のサブドメインにもなる
  "name": "shanai-mcp",
  // エントリポイント
  "main": "src/index.js",
  // 互換性の基準日。Node.js 互換の挙動もこの日付で決まる
  "compatibility_date": "2026-08-01",
  // npm の一部パッケージが Node.js の標準モジュールを参照するため有効にする
  "compatibility_flags": ["nodejs_compat"]
}

nodejs_compat は忘れやすい設定です。テストの実行環境がこの設定を自動で補うことがあり、テストは通るのに nodejs_compat がWorkerの設定に入っていない状態が起きます。設定ファイル側に入っているかを目視で確認してください。

3-4. MCPサーバーを書く

src/index.js を作ります。ここでは、品番から在庫数と保管場所を返すツールを1つ登録します。

import { McpServer } from "@modelcontextprotocol/server";
import { createMcpHandler } from "agents/mcp/server";
import { z } from "zod";

// 社内の在庫を引くための仮のデータ。実運用では D1 や社内 API への問い合わせに置き換える
const STOCK = {
  "A-100": { name: "ステンレス六角ボルト M8", qty: 420, location: "第1倉庫" },
  "A-200": { name: "ステンレス六角ナット M8", qty: 88, location: "第1倉庫" },
  "B-310": { name: "ゴムパッキン 30mm", qty: 0, location: "第2倉庫" },
};

function createServer() {
  // サーバーの名前とバージョン。クライアント側の一覧に表示される
  const server = new McpServer({
    name: "shanai-mcp",
    version: "1.0.0",
  });

  // ツールを1つ登録する。第1引数がツール名、第2引数が定義、第3引数が本体
  server.registerTool(
    "lookup_stock",
    {
      description: "品番から在庫数と保管場所を返す",
      // 入力の形。ここで型を宣言しておくとクライアント側に伝わる
      inputSchema: { code: z.string() },
    },
    async ({ code }) => {
      const hit = STOCK[code];
      // 見つからない場合も content を返す。例外を投げるとクライアント側で扱いにくい
      if (!hit) {
        return { content: [{ type: "text", text: `品番 ${code} は登録されていません` }] };
      }
      return {
        content: [
          {
            type: "text",
            text: `${hit.name}／在庫 ${hit.qty} 個／保管場所 ${hit.location}`,
          },
        ],
      };
    },
  );

  return server;
}

export default {
  // リクエストごとに createServer が呼ばれる。セッションを保持しないので状態は持たない
  fetch(request, env, ctx) {
    return createMcpHandler(createServer)(request, env, ctx);
  },
};

STOCK は説明のための仮のデータです。このWorkerを実際の社内システムに繋ぐ場合は、この定数をD1（Cloudflareのデータベース）への問い合わせや、社内APIの呼び出しに置き換える骨子として読んでください。

ローカルで起動します。

# ローカルの実行環境で Worker を立ち上げる
npx wrangler dev --port 8787 --local

3-5. 動作を確認する

まずツールの一覧を取得します。_meta には、2026-07-28仕様で必須になったプロトコル版とクライアント能力を入れます。clientInfo は推奨項目で、表示やログに使う自己申告の情報です。認証や認可の判断には使わないでください。

次の内容を tools-list.json として保存します。

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/list",
  "params": {
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": { "name": "curl-test", "version": "1.0.0" },
      "io.modelcontextprotocol/clientCapabilities": {}
    }
  }
}

呼び出します。

# ツールの一覧を取得する
curl -s -X POST http://127.0.0.1:8787/mcp \
  -H "MCP-Protocol-Version: 2026-07-28" \
  -H "Mcp-Method: tools/list" \
  -H "Content-Type: application/json" \
  -d @tools-list.json

返ってきた応答です。

{
  "result": {
    "tools": [
      {
        "name": "lookup_stock",
        "description": "品番から在庫数と保管場所を返す",
        "inputSchema": {
          "type": "object",
          "$schema": "https://json-schema.org/draft/2020-12/schema",
          "properties": { "code": { "type": "string" } },
          "required": ["code"]
        }
      }
    ],
    "resultType": "complete",
    "ttlMs": 0,
    "cacheScope": "private",
    "_meta": {
      "io.modelcontextprotocol/serverInfo": { "name": "shanai-mcp", "version": "1.0.0" }
    }
  },
  "jsonrpc": "2.0",
  "id": 1
}

ttlMs と cacheScope は改訂で加わった項目で、応答をどれだけキャッシュしてよいかをクライアントに伝えます。ここでは ttlMs が0、cacheScope が private なので、キャッシュせずに扱う指示になります。

次にツールを呼び出します。ヘッダーに Mcp-Name を足し、本文の params に name と arguments を入れます。_meta は一覧のときと同じ内容です。

tools-call.json（貼り付け用）

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/call",
  "params": {
    "name": "lookup_stock",
    "arguments": { "code": "A-200" },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": { "name": "curl-test", "version": "1.0.0" },
      "io.modelcontextprotocol/clientCapabilities": {}
    }
  }
}

# 品番 A-200 の在庫を引く
curl -s -X POST http://127.0.0.1:8787/mcp \
  -H "MCP-Protocol-Version: 2026-07-28" \
  -H "Mcp-Method: tools/call" \
  -H "Mcp-Name: lookup_stock" \
  -H "Content-Type: application/json" \
  -d @tools-call.json

返ってきた応答です。

{
  "result": {
    "content": [
      { "type": "text", "text": "ステンレス六角ナット M8／在庫 88 個／保管場所 第1倉庫" }
    ],
    "resultType": "complete",
    "_meta": {
      "io.modelcontextprotocol/serverInfo": { "name": "shanai-mcp", "version": "1.0.0" }
    }
  },
  "jsonrpc": "2.0",
  "id": 2
}

注目したいのは、こちらから initialize を一度も呼んでいないことです。 旧仕様では接続の開始時にやり取りが必要でしたが、ここでは最初のリクエストがそのままツールの一覧を返しています。同じリクエストを続けて投げても、毎回同じ応答が返ります。

サーバー側が状態を持たないので、リクエストを複数のWorkerに散らしても結果は変わりません。ただしこれは仕様から導かれる帰結であり、ここで確認したのはローカルの1台だけです。分散した環境での挙動までは確かめていません。

3-6. 旧仕様からの移行でつまずきやすい点

_meta を入れずに呼び出すと、次のエラーが返ります。実際に手元で再現した応答です。

{
  "jsonrpc": "2.0",
  "error": {
    "code": -32602,
    "message": "Invalid params: the MCP-Protocol-Version header names protocol revision 2026-07-28, but the request is missing the required per-request envelope key(s): _meta",
    "data": { "envelope": { "missing": ["_meta"] } }
  },
  "id": 1
}

セッションを廃止した代わりに、プロトコルのバージョンとクライアントの能力を毎回のリクエストが運ぶ形になりました。旧仕様のサンプルをそのまま持ってくると、呼び出しがここで止まります。 _meta の中のキーは io.modelcontextprotocol/ で始まる名前空間付きの形式です。

つまずく点はもう1つあります。Mcp-Method ヘッダーを付けずに送ると、別のエラーになります。

{
  "jsonrpc": "2.0",
  "error": {
    "code": -32020,
    "message": "Bad Request: the request headers and body disagree: the body names method tools/list but the required Mcp-Method header is absent",
    "data": { "mismatch": { "header": "(missing)", "body": "the body names method tools/list but the required Mcp-Method header is absent" } }
  },
  "id": 1
}

このヘッダーは、途中の機器が振り分けに使うためだけのものではなく、サーバー側が必須として扱います。 本文とヘッダーの両方に操作名を書く形になるので、片方だけ変えると食い違いで弾かれます。ツールを増やすときの取りこぼしに注意してください。

3-7. 公開する前に決めておくこと

ここまでで動くMCPサーバーができました。ただし、このコードには認証が一切ありません。このまま社外に公開してはいけません。認証と操作単位の認可を先に設計してから、社内システムへ接続してください。 本記事では認証の実装までは扱わないので、方針だけを示します。

繋ぎ先を絞る理由を数字で示した研究があります。DSN 2026に採択されたこの研究は、6つのレジストリから67,057個のMCPサーバーを集めて分析しました。査読を通っている点で、本記事が引用しているほかの2本の論文より格が上です。

脆弱性を持つサーバーが合計833個
第三者がリダイレクト先を乗っ取れる状態のアカウントが304件、メンテナを乗っ取れる状態のアカウントが212件
サーバー名の前後に文字を足して本物に似せた登録（接辞スクワッティング）が408グループ。そのうち80.6%は、元のサーバーとは別の開発者が管理している

npmのパッケージ名を1文字変えて偽装する手口と同じ構図です。公開されているMCPサーバーをそのまま社内のAIクライアントに繋ぐと、気づかないうちに、この408グループのどれかへ繋いでしまう可能性があります。

補足: この測定は2025年6月末から7月初旬に行われたもので、MCPの仕様が2026年7月28日に大きく変わる前の状態です。現在の数字ではありません。

対処は3層に分けます。1層目は、Cloudflare Accessを前段に置き、社内のIDでログインした利用者だけがMCPサーバーに到達できるようにすること。2層目は、WorkerやGatekeeperで利用者、対象データ、操作ごとの認可を行うこと。3層目は、接続先をMCP Server Portalへ集約し、利用できるサーバーとツールを管理者が絞り、呼び出しを記録することです。

MCP Server Portalは、複数のリモートMCPサーバーを1つのHTTPエンドポイントにまとめ、認証、ツールの選択、操作ログを一括で扱えます。ただし接続先の直接URLに利用者が到達できるままなら、Portalは迂回されます。集約しただけで統制できたと判断せず、元のMCPサーバー側もAccessで保護してください。

MCPを業務で使う際の全体的な注意点は「MCPの限界とは？企業AI本番運用の壁とセキュリティをDifyで突破」に、業務で使えるMCPサーバーの選び方は「業務で本当に使えるClaude MCPサーバー厳選10選」にまとめています。

ノーコードソリューションズ

MCPの限界とは？企業AI本番運用の壁とセキュリティをDifyで突破 | ノーコードソリューションズはじめに：なぜ「PoCは動いたのに本番に進めない」のか 2024年11月にAnthropicが公開したMCP（Model Context Protocol）は、わずか1年あまりでAIエコシステム全体の標準仕…

ノーコードソリューションズ

業務で本当に使えるClaude MCPサーバー厳選10選 | ノーコードソリューションズはじめにマーケはClaudeをNotionに、開発はGitHub Copilotを社内DBに、営業は別のAIをSalesforceに ― 気づけば部門ごとにAIとSaaS連携が独立して乱立し、情シスが全体像を…

4. 応用例｜Cloudflare OSとGatekeeperによる権限の絞り方

4-1. Cloudflare自身が社内で動かしている構成

権限の設計に入る前に、実際に動いている規模を見ます。Cloudflareは2026年4月20日、自社のエンジニアリング向けAI基盤を自社の製品だけで組んだ記録を公開しました。ベンダーの導入事例ではなく自社の運用報告です。使われているのは、AI Gateway、Workers AI、Access、WorkersとDurable Objects、Agents SDK、Sandbox SDK、Workflows、MCP Server Portalsで、30日間の数字が公開されています。

指標	数値
アクティブユーザー	3,683人（全社の60%、研究開発部門の93%）
AIリクエスト総数	4,795万件
処理トークン	2,413億7,000万
エージェントツールを使っているチーム	295チーム

用途は、すべてのマージリクエストに対する多エージェントのコードレビュー、セキュリティ分析、約3,900リポジトリへの AGENTS.md の生成、CIでの文書レビューです。

技術的に参考になる報告が1つあります。GitLabのMCPサーバーは34個のツールを公開しており、その定義だけで1リクエストあたり約15,000トークンを占めていました。ツールを集約する層でCode Mode（モデルにツールを直接呼ばせず、コードを書かせて実行する方式）を採用したところ、この34個を2個のツールに畳めたとCloudflareは報告しています。

ここまでの数値は、あくまでこのエンジニアリング向け基盤のものです。次に扱うCloudflare OSは別に公開されたソフトウェアなので、この4,795万件や3,683人をCloudflare OSの運用実績として読まないでください。

4-2. 権限ゼロから始めるという設計

2026年8月4日、CloudflareはCloudflare OSを公開しました。Cloudflare OSは、Workersの上に構築されたエージェント向けのワークスペースで、文書の作成、アプリの構築、自社のデータに接続したエージェントの実行を扱います。ライセンスはApache-2.0で、プレスリリースは数千人の従業員が日常的に使っていると述べています。4-1のエンジニアリング向け基盤とは対象と構成が異なるため、分けて扱います。

設計の中心にあるのがGatekeeperです。公開されているリポジトリは、Gatekeeperを権限オブジェクト方式（公式の表記では capability ベース）のアクセス制御と説明し、強化されたMCPサーバーのようなものだと述べています。仕組みは次のとおりです。

外部リソースごとに別々のWorkerを立てる。 1つのGatekeeperが1つの社内システムを担当する
権限モデルはアクセス制御リストではなく、権限そのものを渡す形。必要なリソースだけを、設定で明示的にエージェントへ引き合わせる
エージェントやGadgetが行った操作を記録し、後から確認できるようにする
人間による承認を組み込める。 ここは作りが独特で、承認待ちで止めるのではなく、結果を手元で模擬してエージェントには先へ進ませ、実際の操作は後で人がまとめて承認する
Gadget（隔離された個人用アプリのインスタンス）は、明示的な許可がない限りインターネットへの接続を切った状態で動く

3つ目は便利さと引き換えの部分でもあります。模擬した結果を前提にエージェントが進むので、承認が下りなかったときに後続の作業が無駄になります。 承認を挟む箇所は、やり直しの費用が小さいところから決めてください。

プレスリリースは、権限の初期状態をこう説明しています。

AIエージェントは既定で権限ゼロから始まり、特定のタスクに必要なものだけアクセスを与えられる。

4-3. Gatekeeperの設計を研究と照らし合わせる

Gatekeeperの発想は、Cloudflare独自のものではありません。プロンプトインジェクションに対するエージェントの設計を扱った2025年6月の論文（Luca Beurer-Kellnerほか14名）が、1年以上前に同じ結論に到達しています。この論文はarXivのプレプリントで、査読付き会場の記載はありません。置かれている原則は明快です。

LLMエージェントがひとたび信頼できない入力を取り込んだら、その入力が結果を伴う行動を引き起こすことが不可能になるよう制約しなければならない。

検知して止めるのではなく、信頼できない入力が結果を伴う行動に届かないよう、設計の段階で経路を断つという立場です。論文はそのための設計を6つ挙げています。この6つとCloudflareの機能を並べた次の表は、本記事による対応付けです。 論文もCloudflareも、この対応を示してはいません。

設計	何を制約するか	Cloudflareで近いもの（本記事の対応付け）
Action-Selector	ツールの出力をエージェントに戻さない	出力を戻さない単純なツールをWorkerで実装する
Plan-Then-Execute	先に計画を確定させ、ツールの出力が行動の選択に影響しないようにする	Workflowsで手順を先に定義する
LLM Map-Reduce	隔離したサブエージェントに分散し、影響が波及しないようにする	処理を分割し、Durable ObjectやSandboxで1件ずつ隔離して動かす
Dual LLM	権限を持つLLMは信頼できないデータを処理しない	Gatekeeperが認証情報を保持し、エージェントには渡さない
Code-Then-Execute	ツールを呼ぶプログラムを書かせ、それを実行する	Code Modeで生成したコードをサンドボックスで動かす
Context-Minimization	信頼できない入力を後段の処理から外す	直接対応する機能は無い（自分で組む必要がある）

対応の強さには差があります。Dual LLMとCode-Then-Executeの2つは、Cloudflareが説明する仕組みが論文の定義と重なります。ただしCloudflareがこの名前を使っているわけではありません。残る4つはさらに緩く、本記事の読み取りです。とくにContext-Minimizationには対応する機能がありません。 4-1で挙げたツール定義の圧縮は、コンテキストが肥大する問題への対処であって、信頼できない入力を後段から外すこととは別の話です。混同すると、対策したつもりで穴が残ります。

論文は、それぞれに実用性の低下が伴うことも明記しています。Action-Selectorを採ると、事前に定義したコマンドの設計に作業が寄り、LLMのあいまいな検索の利点をほぼ失います。Context-Minimizationを採ると、エージェントが直前の発話に反応できなくなります。安全性を高める制約には、使える機能や応答性を下げる代償があります。

人の承認を挟む設計の具体的な組み方は「Human-in-the-Loopの概念をDifyに落とし込み、AIの暴走を防ぐ安全設計を構築する」で扱っています。

ノーコードソリューションズ

Human-in-the-Loopの概念をDifyに落とし込み、AIの暴走を防ぐ安全設計を構築する | ノーコードソリューショ… はじめに LLMの自動化を進める中で、「AIが勝手に間違った顧客対応をしたらどうしよう…」「重要な決裁をAI任せにするのは怖い」と不安に感じたことはありませんか？本記事…

4-4. 論文が示した限界

同じ論文は、汎用のエージェントが意味のある確かな安全の保証を与えられるとは考えにくい、と述べています。断定ではなく著者らの見立てです。理由は、防御を積み増しても経験則の域を出ず、そのぶん脆いままだという点にあります。推奨されているのは、用途を絞ったエージェントを個別に設計することです。

これは実務の判断に直結します。全社員に同じ権限を持つ汎用エージェントを1つ配るだけでは、安全性を説明する材料が不足します。 利用者の役割と業務ごとに触れる範囲を決め、その範囲だけを渡します。画面上は1つのエージェントでも、裏側の権限と実行経路は分けられます。Gatekeeperを外部サービスごとに立てる構成は、この考え方を実装したものと読めます。

機密情報をAIコーディングツールに渡す際の判断基準は「Claude Code・Codexに機密情報を入れて大丈夫？情シスのためのセキュリティ設計ガイド」にまとめています。

ノーコードソリューションズ

Claude Code・Codexに機密情報を入れて大丈夫？情シスのためのセキュリティ設計ガイド | ノーコードソリュ… はじめに現場のエンジニアが Claude Code や OpenAI Codex を使い始め、生産性は確かに上がっている。けれども情シスの立場では気が気でない、というのが本音ではないでし…

4-5. 今の時点で本番に載せられるか

Cloudflare OSは公開されたばかりです。デプロイできることと、本番運用の準備が整っていることは分けて判断してください。 公式のリポジトリが次の状態を明記しています。

状態はEarly access。開発が活発に進んでいる
v2は完全な書き直し。公式が、v2は非常に高機能だがまだ粗い部分が多く残っていると記載している
単体の workerd サーバーへの本番デプロイ手順は未公開（COMING SOON）
Cloudflareアカウントへデプロイする導線と、構成を変更するためのstarterリポジトリは公開済み

現時点での現実的な選択肢は3つです。Gatekeeperの設計思想だけを自社のWorkerへ取り入れる、Cloudflareアカウントへ検証用にデプロイする、starterリポジトリを基に自社要件へ変更する。後ろの2つを本番へ進めるなら、認証情報の失効と更新の手順、操作ログの保管と監視、承認を拒否したときに後続処理を取り消す方法、障害時にエージェントを止めて接続を一括で無効化する方法を先に決めてください。これらを運用設計として説明できない段階では、検証用途に留めます。

5. まとめと結論

Cloudflareの強みは、AIモデルそのものより制御層です。 利用者、モデル、MCP、社内システムの間にWorkers、Access、AI Gateway、Gatekeeperを置き、認証・記録・権限を1つの経路で強制できます
禁止リストだけでは守れません。 査読前のサーベイの集計値ですが、実運用の拒否リストのうち69%から98%は回避でき、攻撃を受けていなくてもエージェントの行動の最大17.1%が想定範囲の外に出ると報告されています。渡していない権限を使えない形へ設計を変えてください
状態を持たないMCPサーバーはWorker 1本で立ちます。 2026年7月28日の改訂でプロトコルのセッションが廃止され、initialize を呼ばずに動きます。ただし _meta と標準ヘッダーが毎回必要で、業務上の状態はDurable Objectsなどで別に保持します
Accessだけで認可は完了しません。 Accessで到達できる利用者を絞り、WorkerやGatekeeperで対象データと操作を絞り、MCP Server Portalで接続先とログを集約します
認証情報はエージェントに渡さないでください。 Gatekeeperのように、認証情報を持つ側と信頼できないデータを扱う側を分けます。ただし研究との対応には強弱があり、Cloudflareの機能だけで全パターンを満たせるわけではありません
Cloudflare OSはEarly accessです。 アカウントへのデプロイ手段は公開済みですが、単体の workerd へ本番配備する手順は未公開です。運用・監査・復旧を説明できるまでは検証用途に留めます