DocsDigest
一覧へLanguage: EN
OpenAICloudflare2026/04/20 13:00

The AI engineering stack we built internally — on the platform we ship

要点だけを先に読めるように短く再構成したセクションです。

元記事
OpenAIClaude

Quick Digest

要約

要点だけを先に読めるように短く再構成したセクションです。

openaijamodel: gpt-5-mini-2025-08-07

社内で構築したAIエンジニアリングスタック — 提供中のプラットフォーム上で

ai-gatewayworkers-aimcpproxy-workerzero-trustconfig-as-codesandbox

Key Points

  • 同一プラットフォームで運用
  • Workers AIでコスト削減
  • proxy Workerでアクセス統制

Summary

Cloudflareが社内で11ヶ月かけて構築したAIエンジニアリングスタックは、我々が外部に提供している同じプラットフォーム上で動作します。コアはCloudflare Access（Zero Trust）→ proxy Worker → AI Gateway → Workers AI／外部モデルの経路で、config-as-code・OAuth・匿名化トラッキング・Zero Data Retention（ZDR）などのガバナンスを組み込み、3,600人超の利用と急増する開発生産性を支えています（最近30日: 約47.95Mリクエスト、AI Gateway経由241Bトークン、Workers AI処理約51Bトークン）。

Key Points

  • アーキテクチャ要点
    • 単一のproxy Workerを制御点にしてOpenCodeクライアントを自動設定（opencode auth login ...）。
    • 認証はCloudflare Access／cloudflaredでJWTを発行、Workerで検証してAI Gatewayへ転送。
    • Workerはクライアント上にAPIキーを置かずにサーバー側で鍵を注入し、ヘッダを書き換えてフォワード。
  • ガバナンスと運用
    • モデルカタログはWorkerのcronで定期取得しWorkers KVにキャッシュ、デフォルトでZDRを付与。
    • ユーザーメールはD1＋KVキャッシュで匿名UUIDにマッピングし、プロバイダには匿名IDのみ送信（コスト追跡を維持）。
    • エージェント／コマンドはMarkdown+YAMLフロントマターで管理し、ビルドで単一JSONに合成（config-as-code）。
  • プラットフォーム機能と製品化
    • Workers AIを同一ネットワーク上で運用し、レイテンシとコストを最適化（Kimi K2.5採用例、推定で商用モデルより大幅コスト削減）。
    • MCP Server Portalで13台以上のMCPサーバを統合、182+ツールを一つのOAuth/Accessフローで管理（McpAgent、workers-oauth-provider利用）。
    • Code ModeとSandbox SDKでエージェント生成コードの隔離実行を実現（Sandbox SDKはGA）。
  • 実運用インパクト（短く）
    • 4週間ローリングのMR数が約5,600→8,700超に上昇。Agent利用はR&Dで93%到達。運用規模と品質担保の両立が可能。

Recommendations for engineers

  • 小規模でもproxy Workerパターンを採用して認可・課金・モデルルーティングを中央管理する。
  • 機密データ流出リスクにはZDRとサーバー側鍵注入、匿名化トラッキングを標準化する。
  • エージェント定義はMarkdown+YAMLで管理しCIでコンパイル・バリデーションして自動配布する。
  • 同一ネットワーク内推論（Workers AI等）を検討してコストとレイテンシの最適化を図る。

Full Translation

翻訳

原文の流れを保ったまま読める翻訳セクションです。

openaijamodel: gpt-5-mini-2025-08-07

社内で構築したAIエンジニアリングスタック — 当社が提供するプラットフォーム上で

2026-04-20 — Ayush Thakur, Scott Roe-Meschke, Rajesh Bhatia — 14 min read

概要

過去30日間で、CloudflareのR&D組織の93%が、当社のプラットフォーム上に構築したインフラで動くAIコーディングツールを利用しました。11か月前、AIを本当にエンジニアリングスタックに統合するための大規模プロジェクトに着手しました。内部MCPサーバー、アクセス層、エージェントを有用にするためのAIツール群を構築する必要があり、社内のエンジニアを横断的に集めてiMARS（Internal MCP Agent/Server Rollout Squad）というタイガーチームを編成しました。持続的な作業はDev Productivityチームに引き継がれ、CI/CD、ビルドシステム、自動化などの内部ツールの多くも同チームが運用しています。

ここ数十日の内部でのagent的AI利用を示す数値は以下の通りです。

  • 3,683人の社内ユーザーがAIコーディングツールを積極的に使用（従業員約6,100人中、会社全体で60%、R&Dで93%）
  • 47.95 million AI requests
  • 295チームがagent的AIツールとコーディングアシスタントを利用
  • 20.18 million AI Gateway requests/月
  • 241.37 billion tokens がAI Gateway経由でルーティング
  • 51.83 billion tokens がWorkers AIで処理

内部の開発速度への影響は明白で、マージリクエストの四半期ごとの増加がこれほど大きかったことはありません。AIツールの採用が増えるにつれて、4週間ローリング平均は約5,600/週から8,700超/週まで上昇しました。3月23日の週は10,952に達し、Q4のベースラインのほぼ2倍になりました。

MCPサーバーが出発点でしたが、チームはさらに踏み込む必要があるとすぐに認識しました：標準をどうコード化するか、コードレビューをどう行うか、エンジニアのオンボーディングや数千のリポジトリに変更をどう伝播させるか、などです。本投稿では過去11か月の詳細と、我々が最終的にたどり着いた構成を三幕で解説します。

今回公開するのはAgents Weekの締めくくりとしてです。社内で構築したAIエンジニアリングスタックは、まさに今週我々が出荷・強化している製品上で動作しています。

アーキテクチャ（概観）

エンジニア向けツール層（OpenCode、Windsurf、その他MCP互換クライアント）には、オープンソースやサードパーティのコーディングアシスタントツールが含まれます。各層はCloudflareの製品やツールに対応しています。

我々が構築したもの

  • Zero Trust認証で構築
    • Cloudflare Access
  • 中央化されたLLMルーティング、コスト追跡、BYOK、Zero Data Retention制御
    • AI Gateway
  • プラットフォーム上での推論（オープンウェイトモデル）
    • Workers AI
  • 単一OAuthでのMCP Server Portal
    • Workers + Access
  • AI Code ReviewerのCI統合
    • Workers + AI Gateway
  • エージェント生成コードのサンドボックス実行（Code Mode）
    • Dynamic Workers
  • ステートフルで長時間動作するエージェントセッション
    • Agents SDK（McpAgent、Durable Objects）
  • クローン、ビルド、テストのための分離環境
    • Sandbox SDK — Agents WeekでGA
  • 耐久的なマルチステップワークフロー
    • Workflows — Agents Week中に10倍にスケール
  • 16K+ エンティティのナレッジグラフ
    • Backstage (OSS)

注：Backstage以外は内部専用インフラではなく、上記はすべて出荷中の製品です。多くはAgents Week中に大幅な更新を受けました。

我々は以下の3幕で詳述します：

  1. プラットフォーム層 — 認証、ルーティング、推論の仕組み（AI Gateway、Workers AI、MCP Portal、Code Mode）
  2. ナレッジ層 — エージェントが我々のシステムを理解する方法（Backstage、AGENTS.md）
  3. 実行（強制）層 — 大規模に品質を維持する仕組み（AI Code Reviewer、Engineering Codex）

第1幕：プラットフォーム層

AI Gatewayがセキュリティと開発者体験をどう改善したか

3,600人以上の社内ユーザーが毎日AIコーディングツールを使う環境では、多数のクライアント、ユースケース、ロールに渡るアクセスと可視化の問題を解く必要があります。すべてはCloudflare Accessから始まります。Accessは認証とZero Trustポリシーの適用を担います。認証後、すべてのLLMリクエストはAI Gatewayを経由します。これにより、プロバイダキーの一元管理、コスト追跡、データ保持ポリシー管理が可能になります。

OpenCodeのAI Gateway概要：

  • 688.46k requests/day
  • 10.57B tokens/day
  • 4つのプロバイダへ単一のエンドポイント経由でルーティング

AI Gatewayの分析はモデルプロバイダ間での月次利用分布を示します。過去1か月の内部リクエストの内訳は以下の通りです。

ProviderRequests/monthShare
Frontier Labs (OpenAI, Anthropic, Google)13.38M91.16%
Workers AI1.3M8.84%

現時点ではFrontierモデルが複雑なagent的コーディング作業の大部分を担っていますが、Workers AIも既に重要な役割を果たしており、agent的エンジニアリングワークロードにおけるシェアは増加しています。

Workers AIの活用が増えている理由

Workers AIはCloudflareのサーバーレスAI推論プラットフォームで、グローバルネットワーク上のGPUでオープンソースモデルを実行します。フロンティアモデルに比べてコストが大幅に改善されることに加え、推論がWorkers、Durable Objects、ストレージと同一ネットワーク上で完結する利点があります。これにより、クロスクラウドの往復による遅延、ネットワークの不安定さ、追加のネットワーク設定を避けられます。

過去1か月のWorkers AI利用：

  • 51.47B input tokens
  • 361.12M output tokens

Kimi K2.5は2026年3月にWorkers AIでローンチされたフロンティア規模のオープンソースモデルで、256kのコンテキストウィンドウ、ツールコーリング、構造化出力をサポートします。我々のKimi K2.5ローンチ記事で述べたように、セキュリティエージェントはKimi上で1日あたり70億トークン超を処理しており、同等の中位商用モデルでの推定コストは年間約$2.4Mですが、Workers AIでは77%安価に運用できます。

セキュリティ以外にも、CIパイプラインでのドキュメントレビュー、数千リポジトリにまたがるAGENTS.mdコンテキストファイルの生成、そしてレイテンシが最重要の軽量推論タスクにWorkers AIを利用しています。オープンソースモデルが改善を続けるにつれて、Workers AIで処理する内部ワークロードの割合は増える見込みです。

初期にうまくやれたこと：単一のプロキシWorker経由のルーティング

クライアントをAI Gatewayへ直接接続することも可能で初期セットアップは簡単でしたが、最初から一つのWorkerをプロキシにすることで、後からユーザーごとの帰属付け、モデルカタログ管理、権限執行をクライアント設定を触らずに追加できる利点がありました。以下で述べるブートストラップ段階のすべての機能は、その単一のチョークポイントがあったからこそ可能になりました。プロキシパターンは直接接続では持てないコントロールプレーンを提供し、将来的に追加のコーディングアシスタントツールを導入しても同じWorkerとディスカバリエンドポイントで処理できます。

仕組み：一つのURLで全てを構成

全体のセットアップは次の一つのコマンドで始まります：

opencode auth login https://opencode.internal.domain

このコマンドはプロバイダ、モデル、MCPサーバー、エージェント、コマンド、権限を構成する一連の処理をトリガーし、ユーザーが設定ファイルを直接触る必要はありません。

ステップ1：認証要件のディスカバリ

OpenCodeは https://opencode.internal.domain/.well-known/opencode のようなURLから設定を取得します。このディスカバリエンドポイントはWorkerによって提供され、レスポンスにはOpenCodeに対する認証方法を示す auth ブロックと、プロバイダ、MCPサーバー、エージェント、コマンド、デフォルト権限を含む config ブロックがあります。例：

{
  "auth": {
    "command": ["cloudflared", "access", "login", "..."],
    "env": "TOKEN"
  },
  "config": {
    "provider": { "..." },
    "mcp": { "..." },
    "agent": { "..." },
    "command": { "..." },
    "permission": { "..." }
  }
}

ステップ2：Cloudflare Accessによる認証

OpenCodeは認証コマンドを実行し、ユーザーはCloudflareで普段使っているSSOを通じて認証します。cloudflaredは署名済みJWTを返します。OpenCodeはそれをローカルに保存し、以降のすべてのプロバイダリクエストに自動で付与します。

ステップ3：OpenCodeへのconfigのマージ

提供されるconfigは組織全体の共有デフォルトですが、ローカルの設定が常に優先されます。ユーザーはデフォルトモデルをオーバーライドしたり、独自のエージェントを追加したり、プロジェクトやユーザースコープの権限を調整したりできます（他の人に影響を与えずに）。

プロキシWorkerの内部動作

WorkerはシンプルなHonoアプリで、主に次の3つを行います：

  • 共有設定を配信
    • 設定はデプロイ時に構造化ソースファイルからコンパイルされ、{baseURL}のようなプレースホルダを含みます。リクエスト時にWorkerがこれらを置換し、すべてのプロバイダリクエストが直接ではなくWorker経由でルーティングされるようにします。各プロバイダはパスプレフィックス（/anthropic, /openai, /google-ai-studio/v1beta, /compat（Workers AI）など）を持ち、Workerは対応するAI Gatewayルートにフォワードします。
  • AI Gatewayへのプロキシ
    • OpenCodeが POST /anthropic/v1/messages のようなリクエストを送ると、WorkerはCloudflare AccessのJWTを検証し、ヘッダーを書き換えてフォワードします。
      • 削除されるヘッダー：authorization, cf-access-token, host
      • 追加されるヘッダー：cf-aig-authorization: Bearer <API_KEY>、cf-aig-metadata: {"userId": "<anonymous-uuid>"}
    • リクエストはAI Gatewayへ行き、適切なプロバイダへルーティングされます。レスポンスはバッファリングせずにそのまま返されます。クライアント設定の apiKey フィールドは空のままで、Workerがサーバー側で実際のキーを注入します。ユーザー端末にAPIキーは存在しません。
  • モデルカタログを常に最新に維持
    • 時間ベースのcronトリガーが models.dev から現在のOpenAIモデルリストを取得し、Workers KVにキャッシュし、すべてのモデルに store: false を注入してZero Data Retention（ZDR）を適用します。新しいモデルは設定の再デプロイなしに自動的にZDRになります。
  • 匿名ユーザートラッキング
    • JWT検証後、WorkerはユーザーのメールをD1にマッピングしてUUIDを生成し、KVを読み取りキャッシュとして使います。AI Gatewayが見るのは常に cf-aig-metadata 内の匿名UUIDであり、メールは公開されません。これにより、モデルプロバイダやGatewayログに身元を晒すことなくユーザー単位のコスト追跡と使用分析が可能になります。
  • Config-as-code
    • エージェントとコマンドはYAML frontmatterを含むMarkdownファイルとして作成されます。ビルドスクリプトがそれらを単一のJSON設定にコンパイルし、OpenCode JSONスキーマで検証します。新しいセッションは自動的に最新バージョンを取得します。

全体としてのアーキテクチャはシンプルで、我々のデベロッパープラットフォーム上で誰でもデプロイ可能です：プロキシWorker、Cloudflare Access、AI Gateway、そしてクライアントがアクセス可能なディスカバリエンドポイント。ユーザーは一つのコマンドを実行すれば完了します。ラップトップに手動で設定することは何もなく、APIキーも、MCPサーバー接続の手動セットアップも不要です。3,000人以上のエンジニアのコーディング環境を変更したり、agent的ツールを更新するのは、wranglerのデプロイ一回で済みます。

MCP Server Portal：単一OAuthで複数のMCPツールを管理

エンタープライズ規模でのMCPガバナンスに関する我々のアプローチは別投稿で詳述していますが、内部ではMCP Server Portals、Cloudflare Access、Code Modeを組み合わせて運用しています。簡潔に言うと、内部ポータルは13の本番MCPサーバーを集約し、Backstage、GitLab、Jira、Sentry、Elasticsearch、Prometheus、Google Workspace、内部のRelease Managerなどを含む182以上のツールを公開しています。これによりアクセスが統一され、各ツールへのアクセスは1つのエンドポイントと1つのCloudflare Accessフローで統制されます。

各MCPサーバーは共通の基盤上に構築されています：Agents SDKの McpAgent、OAuthの workers-oauth-provider、そしてアイデンティティのためのCloudflare Access。すべては単一のモノレポに格納され、共通の認証基盤、Bazelビルド、CI/CDパイプライン、Backstage登録用の catalog-info.yaml を共有しています。新しいサーバーを追加する作業は、既存サーバーをコピーしてラップするAPIを変えるだけ、という程度の手間です。詳細とセキュリティアーキテクチャについては我々のエンタープライズMCPリファレンスアーキテクチャを参照してください。

ポータル層でのCode Mode

MCPはAIエージェントとツールを接続するための適切なプロトコルですが、実務上の問題があります：すべてのツールは