DocsDigest
Back to listLanguage: JA
OpenAICloudflareApr 20, 2026, 1:00 PM

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

A condensed section focused on the key takeaways first.

Original Post
OpenAIClaude

Quick Digest

Summary

A condensed section focused on the key takeaways first.

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

AI engineering stack built on the platform we ship

ai-gatewayworkers-aimcpopencodeproxy-workerzero-trust

Key Points

  • 93% of R&D uses internal AI tools
  • Single-proxy Worker centralizes routing and control
  • Workers AI provides cheaper, same-network inference

Summary

Cloudflare’s engineering teams built an internal AI engineering stack on top of the same products they ship. Over eleven months the iMARS/tiger-team and Dev Productivity integrated authentication, routing, inference, and agent tooling so thousands of engineers can use AI coding assistants with centralized governance and low friction. The setup uses Cloudflare Access, a single proxy Worker + AI Gateway, Workers AI inference, MCP Server Portals, sandboxed Code Mode, and knowledge/enforcement layers (Backstage, AGENTS.md, AI Code Reviewer).

Key Points

  • Adoption & scale
    • ~3,683 active internal AI users (≈93% of R&D), 295 teams, ~47.95M AI requests in 30 days; tokens: ~241B routed through AI Gateway and ~51B processed on Workers AI.
    • Merge-request velocity rose: 4-week rolling average from ~5.6k/week to >8.7k/week; peak week ~10.9k.
  • Platform architecture
    • Single discovery endpoint + proxy Worker pattern (opencode auth login → /.well-known/opencode) configures providers, MCP servers, agents, commands, and permissions with one command; no API keys on developer machines.
    • Proxy Worker (Hono) responsibilities: serve compiled config, proxy requests to AI Gateway, inject server-side provider keys, refresh model catalog hourly, and map emails → anonymous UUIDs (D1 + KV) for per-user attribution without exposing identities.
    • Centralized routing through AI Gateway enables provider key management, cost tracking, BYOK, and Zero Data Retention controls.
  • Workers AI & model strategy
    • Workers AI runs open models on the edge (same network as Workers/Durable Objects), reducing latency and cost for many internal workloads.
    • Example: Kimi K2.5 (256k context) and a security agent processing billions of tokens daily — estimated 77% cost savings vs a proprietary mid-tier model.
  • MCP & tooling governance
    • MCP Server Portal aggregates 13 production MCP servers and 182+ tools behind one OAuth / Access flow; servers use McpAgent + workers-oauth-provider and live in a monorepo with shared CI/CD.
    • Config-as-code: agents/commands authored as markdown + YAML frontmatter, compiled to a single JSON schema; updates propagate automatically on deploy.
  • Safety and enforcement
    • Sandboxed execution (Code Mode), Durable multi-step workflows, Agents SDK, and AI Code Reviewer integrated into CI enforce quality and isolation at scale.

Practical takeaways for engineers

  • Use the single Opencode command to bootstrap auth and tooling; you won’t need local API keys or manual MCP config.
  • Rely on the proxy Worker + AI Gateway for centralized policy, per-user cost visibility (anonymous), and model catalog controls (ZDR enforced).
  • Prefer Workers AI for low-latency, cost-sensitive workloads and for workloads that benefit from same-network inference (CI checks, documentation review, agent tasks).
  • Keep agents and commands as config-as-code (Markdown + YAML) to make updates reproducible and instantly available across the org.

Full Translation

Translations

A translation section that keeps the flow of the original article.

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エージェントとツールを接続するための適切なプロトコルですが、実務上の問題があります：すべてのツールは