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

過去30日間で、CloudflareのR&D組織の93%が、自社プラットフォーム上に構築したインフラによって駆動されるAIコーディングツールを使用しました。 11ヶ月前、私たちは大規模なプロジェクトに取り組みました：本格的にAIをエンジニアリングスタック（engineering stack）に統合することです。Cloudflareでエージェント（agents）が有用となるために必要な内部MCPサーバー、アクセスレイヤー（access layer）、AIツールリングを構築する必要がありました。私たちは社内のエンジニアを集め、「iMARS（Internal MCP Agent/Server Rollout Squad）」というタスクフォースを結成しました。この継続的な作業は、CI/CD、ビルドシステム（build systems）、自動化を含む内部ツールリングの多くを管理するDev Productivityチームに引き継がれました。 過去30日間の自社エージェント型AI（agentic AI）の使用状況を表すいくつかの数字を以下に示します： 約6,100人の全従業員のうち、3,683人がAIコーディングツールをアクティブに使用（社内全体で60%、R&D部門で93%） 4,795万回のAIリクエスト 現在295のチームがエージェント型AIツールおよびコーディングアシスタントを活用しています。 月間2,018万回のAI Gatewayリクエスト AI Gatewayを介してルーティングされた2,413億700万トークン Workers AIで処理された5,183億トークン 社内における開発者ビロシティ（developer velocity）への影響は明確です：四半期ごとのマージリクエストの増加率をこれほど見たことはかつてありません。 ![image](https://cf-assets.www.cloudflare.com/zkvhlag99gkb/3lMKwBTT3m7DDmS4BnoNhB/9002104b9c6c09cf72f4052d71e22363/BLOG-3270_2.png) AIツールリングの採用が拡大するにつれて、4週間のローリング平均（rolling average）は週約5,600件から8,700件超に上昇しました。3月23日付の週は10,952件を記録し、第4四半期のベースラインのほぼ2倍に達しました。 MCPサーバーが起点でしたが、チームはすぐにさらに踏み込む必要があることに気づきました：標準をコード化する方法、コードレビューの仕組み、エンジニアのオンボーディングプロセス、そして数千のリポジトリにわたる変更の伝播方法を再考する必要があります。 この記事では、過去11ヶ月間でそれがどのようなものだったか、そして最終的にどこに辿り着いたかを深く掘り下げています。今週出荷・強化している製品と同じ基盤上で内部のAIエンジニアリングスタックが稼働しているため、Agents Weekを締めくくるために現在公開するものです。 ## The architecture at a glance エンジニア向けツールレイヤー（OpenCode、Windsurf、およびその他のMCP互換クライアント）には、オープンソースおよびサードパーティのコーディングアシスタントツールが含まれます。 ![image](https://cf-assets.www.cloudflare.com/zkvhlag99gkb/2oZJhdVNbW05lJaSnN3hds/21c5427f275ba908388333884530f455/image8.png) 各レイヤーは、当社が使用するCloudflare製品またはツールにマッピングされます： 構築したもの 使用技術 ゼロトラスト認証（Zero Trust authentication） Cloudflare Access 集中型LLMルーティング、コスト追跡、BYOK（Bring Your Own Key）、ゼロデータ保持制御 AI Gateway オープンウェイトモデルによるプラットフォーム内推論（On-platform inference with open-weight models） Workers AI シングルOAuthを備えたMCPサーバーポータル（MCP Server Portal with single OAuth） Workers + Access AIコードレビュアーCI統合（AI Code Reviewer CI integration） Workers + AI Gateway エージェント生成コードのサンドボックス実行（Code Mode） Dynamic Workers ステートフルで長時間実行されるエージェントセッション（Stateful, long-running agent sessions） エージェントSDK（Agents SDK）（McpAgent、Durable Objects） クローン作成、ビルド、テストのための分離環境 Sandbox SDK — エージェントウィークよりGA（General Availability） 耐久性のあるマルチステップワークフロー Workflows — エージェントウィーク中に10倍にスケール 16,000以上のエンティティ・ナレッジグラフ Backstage (OSS) これらのいずれも社内限定のインフラストラクチャではありません。上記にリストされているもの（Backstageを除く）はすべて出荷対象の製品であり、その多くがエージェントウィーク中に大幅なアップデートを受けました。 これを3つの章（アクト）に分けて解説します。 The platform layer — 認証、ルーティング、推論の仕組み（AI Gateway, Workers AI, MCP Portal, Code Mode） The knowledge layer — エージェントが当社のシステムをどのように理解するか（Backstage, AGENTS.md） The enforcement layer — 大規模な環境でいかに高品質を維持するか（AI Code Reviewer, Engineering Codex） Act 1: The platform layer How AI Gateway helped us stay secure and improve the developer experience 毎日3,600人以上の社内ユーザーがAIコーディングツールを利用している場合、多くのクライアント、ユースケース、役割にわたるアクセスと可視性の問題を解決する必要があります。 すべての基盤となるのはCloudflare Accessであり、これはすべての認証とゼロトラストポリシー（zero-trust policy）の適用を処理します。認証が完了すると、すべてのLLM（大規模言語モデル）リクエストはAI Gatewayを経由してルーティングされます。これにより、プロバイダーキーの管理、コスト追跡、データ保持ポリシーを一元化できます。 ![image](https://cf-assets.www.cloudflare.com/zkvhlag99gkb/5zorZ21OXIbNg7VACGzwZX/e1b35951622bab6ae7ca9fa9b8a5c844/BLOG-3270_4.png) The OpenCode AI Gateway overview: 688.46k requests per day, 10.57B tokens per day, routing to four providers through one endpoint. AI Gatewayの分析データは、月次使用量がモデルプロバイダー間でどのように分散されているかを示しています。過去1ヶ月の社内リクエスト量は以下の通りです。 Provider Requests/month Share Frontier Labs (OpenAI, Anthropic, Google) 13.38M 91.16% Workers AI 1.3M 8.84% Frontierモデル（Frontier models）は現在、複雑なエージェント型コーディング作業（agentic coding work）の大部分を担っていますが、Workers AIもすでにその構成の重要な部分を占めており、エージェント型エンジニアリングワークロードの増加するシェアを処理しています。 How we increasingly leverage Workers AI Workers AIは、CloudflareのサーバーレスAI推論プラットフォーム（serverless AI inference platform）であり、グローバルネットワーク上のGPUでオープンソースモデルを実行します。Frontierモデルと比較して大幅なコスト改善があるだけでなく、重要な利点は推論がWorkers、Durable Objects、ストレージと同じネットワーク上に留まることです。クラウド間を跨ぐホップ処理が必要ないため、レイテンシの増加やネットワークの不安定性、管理すべき追加のネットワーク設定を回避できます。 ![image](https://cf-assets.www.cloudflare.com/zkvhlag99gkb/2WFqiZSL1RGbD2O7gOPDfR/2edc8c69fdea89fef76e600cb3ee5384/BLOG-3270_5.png) Workers AI usage in the last month: 51.47B input tokens, 361.12M output tokens. 2026年3月にWorkers AI上でリリースされたKimi K2.5は、256kコンテキストウィンドウ（context window）、ツール呼び出し（tool calling）、構造化出力（structured outputs）を備えたフロンティア規模のオープンソースモデルです。Kimi K2.5のリリース記事で述べた通り、当社のセキュリティエージェント（security agent）はKimi上で1日あたり70億トークン以上を処理しています。この処理量をミッドティアの独自モデル（proprietary model）で実行した場合、年間約240万ドルのコストが見込まれます。しかしWorkers AI上では、そのコストが77%安くなります。 セキュリティ用途に加え、当社はWorkers AIをCIパイプライン（CI pipeline）内のドキュメントレビューや、数千のリポジトリにわたるAGENTS.mdコンテキストファイルの生成、そしてモデルの最大性能よりも同じネットワーク内でのレイテンシ（same-network latency）が重要となる軽量推論タスク（lightweight inference tasks）に使用しています。 オープンソースモデルが継続的に改善されるにつれ、当社の内部ワークロード（internal workloads）のより大きな割合をWorkers AIが処理すると見込んでいます。 当初から正しく実装できたことの1つ：初日から単一のプロキシWorker（proxy Worker）経由でルーティングすること。当初はクライアントがAI Gatewayに直接接続する方がセットアップは簡単だったかもしれません。しかし、Workerを介して一元化したことで、後からクライアント設定を一切変更することなく、ユーザーごとのアトリビューション（per-user attribution）、モデルカタログ管理、権限の適用（permission enforcement）を追加できました。以下のブートストラップセクションで説明されているすべての機能は、この単一ボトルネック（choke point）が存在したからこそ実現しています。プロキシパターンは、直接接続では得られないコントロールプレーン（control plane）を提供し、後から追加のコーディングアシスタントツールを接続した場合でも、同じWorkerとディスカバリーエンドポイント（discovery endpoint）がそれらを処理します。 仕組み：1つのURLで全てを構成 全体のセットアップは、1つのコマンドから始まります。 opencode auth login https://opencode.internal.domain そのコマンドは、ユーザーが設定ファイルを一切操作することなく、プロバイダー、モデル、MCPサーバー（MCP servers）、エージェント、コマンド、権限を構成する一連の処理をトリガーします。 ![image](https://cf-assets.www.cloudflare.com/zkvhlag99gkb/3sK7wVF3QbeNJ0rjLBabXh/05b9098197b7a3d084e6d860ed22b169/BLOG-3270_6.png) ステップ1：認証要件の発見。OpenCodeは https://opencode.internal.domain/.well-known/opencode などのURLから設定を取得します。 このディスカバリーエンドポイント（discovery endpoint）はWorkerによって提供され、レスポンスにはOpenCodeの認証方法を指示するauthブロックと、プロバイダー、MCPサーバー（MCP servers）、エージェント、コマンド、デフォルト権限を含むconfigブロックが含まれます。 { "auth": { "command": ["cloudflared", "access", "login", "..."], "env": "TOKEN" }, "config": { "provider": { "..." }, "mcp": { "..." }, "agent": { "..." }, "command": { "..." }, "permission": { "..." } } } ステップ2：Cloudflare Access経由の認証。OpenCodeは認証コマンドを実行し、ユーザーはCloudflareでの他のすべての操作に使用するのと同じSSO（Single Sign-On）を介して認証を行います。cloudflaredは署名付きJWT（JSON Web Token）を返します。OpenCodeはこれをローカルに保存し、後続のプロバイダーリクエストのすべてに自動的に付与します。 ステップ3：設定がOpenCodeにマージされます。提供される設定は組織全体の共有デフォルトですが、ローカル設定が常に優先されます。ユーザーは他の人に影響を与えることなく、デフォルトモデルを上書きしたり、独自のエージェントを追加したり、プロジェクトおよびユーザースコープの権限を調整したりできます。 プロキシワーカー（Worker）の内部。このワーカーは単純なHonoアプリケーション（Hono App）で、以下の3つのことを実行します： 共有設定の提供。この設定はデプロイ時に構造化されたソースファイルからコンパイルされ、ワーカーのオリジン用の`{baseURL}`のようなプレースホルダー値を含みます。リクエスト発生時、ワーカーはこれらを書き換えるため、すべてのプロバイダーリクエストはモデルプロバイダーに直接ではなくワーカーを経由してルーティングされます。各プロバイダーにはパスプレフィックス（`/anthropic`、`/openai`、`/google-ai-studio/v1beta`、Workers AI用の`/compat`）が割り当てられ、ワーカーはこれを対応するAI Gateway（AI Gateway）ルートに転送します。 AI Gatewayへのリクエストのプロキシ。OpenCodeが`POST /anthropic/v1/messages`のようなリクエストを送信すると、ワーカーはCloudflare Access JWTを検証し、転送前にヘッダーを書き換えます： ``` 削除対象: authorization, cf-access-token, host 追加: cf-aig-authorization: Bearer cf-aig-metadata: {"userId": ""} ``` リクエストはAI Gatewayに送信され、適切なプロバイダーへルーティングされます。レスポンスはゼロバッファリングでそのまま通過します。クライアント設定の`apiKey`フィールドが空なのは、ワーカーがサーバーサイドで実際のキーを注入するためです。ユーザーの端末にはAPIキーが存在しません。 モデルカタログの最新維持。毎時間のcronトリガーがmodels.devから現在のOpenAIモデルリストを取得し、Workers KVストレージ（Workers KV）にキャッシュして、ゼロデータ保持（Zero Data Retention / ZDR）のために各モデルに`store: false`を注入します。新しいモデルは、設定の再デプロイなしでZDRが自動的に適用されます。 匿名ユーザーの追跡。JWT検証後、ワーカーは永続ストレージにD1データベース（D1）、読み取りキャッシュにKVを使用して、ユーザーのメールアドレスをUUIDに変換します。AI Gatewayが確認できるのはcf-aig-metadata内の匿名UUIDのみで、メールアドレスは決して表示されません。これにより、モデルプロバイダーやGatewayログにユーザーの身元を晒すことなく、ユーザーごとのコスト追跡と使用状況分析が可能になります。 コードとしての設定（Config-as-code）。エージェントとコマンドはYAML frontmatter付きのmarkdownファイルとして作成されます。ビルドスクリプトがこれらをOpenCode JSONスキーマに対して検証された単一のJSON設定にコンパイルします。新しいセッションは常に最新バージョンを自動的に取得します。 全体のアーキテクチャはシンプルで、開発者プラットフォームを使用して誰でも簡単にデプロイできます：プロキシワーカー、Cloudflare Access、AI Gateway、そしてすべてを自動的に設定するクライアントアクセス可能なディスカバリーエンドポイントです。ユーザーはコマンドを1つ実行するだけで完了します。手動で設定すべきものはなく、ラップトップにAPIキーを配置する必要もMCPサーバー接続を手動でセットアップする必要もありません。エージェントツールへの変更と、3,000人以上の開発者のコーディング環境に提供される内容の更新は、wrangler deployを実行するだけですぐに反映されます。 MCPサーバーポータル（MCP Server Portal）：1つのOAuth、複数のMCPツール 別の記事で、エンタープライズ規模でのMCP（Model Context Protocol）ガバナンスにおける当社の完全なアプローチについて説明しました。そこでは、MCP Server Portals、Cloudflare Access、Code Modeをどのように組み合わせて使用しているかについても触れています。以下は、社内で作成したものの簡易版です。 ![image](https://cf-assets.www.cloudflare.com/zkvhlag99gkb/36gUHwTs8CzZeS03l9yno1/42953a6dc2ac944f4dbe31e3ae51570e/BLOG-3270_7.png) 社内ポータルは、Backstage、GitLab、Jira、Sentry、Elasticsearch、Prometheus、Google Workspace、社内Release Managerなど、13の本番環境用MCPサーバーを統合し、182以上のツールを公開しています。これによりアクセスが一元化され、すべてのプロセスが簡素化されました。その結果、すべてのツールへのアクセスを管理するエンドポイントは1つ、Cloudflare Accessのフローも1つというシンプルな構成が実現しています。 各MCPサーバーは同じ基盤の上に構築されています。Agents SDK由来のMcpAgent、OAuth用のworkers-oauth-provider、アイデンティティ管理用のCloudflare Accessです。全体は単一のmonorepo（モノレポ）に収められており、共有の認証インフラストラクチャ、Bazelビルド（Bazel builds）、CI/CDパイプライン（CI/CD pipelines）、Backstage登録用のcatalog-info.yamlを共有しています。新しいサーバーを追加する際は、既存のものをコピーしてラップするAPIを変更するだけです。仕組みの詳細や背後にあるセキュリティアーキテクチャについては、エンタープライズMCPリファレンスアーキテクチャをご覧ください。 Code Mode at the portal layer MCPはAIエージェントとツールを接続するための適切なプロトコルですが、実用的な問題があります。それは、モデルが作業を開始する前に、すべてのツール定義がcontext window tokens（コンテキストウィンドウトークン）を消費してしまう点です。MCPサーバーとツールの数が増えるにつれてtoken overhead（トークンオーバーヘッド）も増大し、スケールする本番環境ではこれが実際のコストとなります。Code Modeは現在注目されている解決策です。すべてのtool schema（ツールスキーマ）を事前に読み込むのではなく、モデルがcodeを通じてツールを検出し、呼び出す方式です。 当社のGitLab MCPサーバーは当初、34の個別ツール（get_merge_request、list_pipelines、get_file_contentなど）を公開していました。これら34のtool schemas（ツールスキーマ）は、リクエストごとに約15,000トークンのcontext window（コンテキストウィンドウ）を消費していました。200Kのcontext windowにおいて、これは質問をする前に予算の7.5%を消費する計算になります。すべてのリクエスト、すべてのエンジニア、毎日このように積み重なるため、無視できないコストとなります。 MCP Server Portalsは現在、Code Mode proxying（Code Modeプロキシ）をサポートしており、これによりサーバーごとに個別に対応するのではなく、中央でこの問題を解決できます。クライアントにすべてのupstream tool definition（アップストリームツール定義）を公開する代わりに、ポータルはそれらを2つのportal-level tools（ポータルレベルのツール）に集約しています。それがportal_codemode_searchとportal_codemode_executeです。 ![image](https://cf-assets.www.cloudflare.com/zkvhlag99gkb/7jQa4HPmrOaOhUojZCJQ8q/4e81201065a50dd67c07e257b725e8b8/BLOG-3270_8.png) ポータルレイヤーでこれを行うことの利点は、クリーンにスケールできる点です。Code Modeがない場合、新しいMCPサーバーを追加するたびにすべてのリクエストにschema overhead（スキーマオーバーヘッド）が追加されます。ポータルレベルのCode Modeを採用すれば、ポータルの背後に接続するサーバーが増えいても、クライアントが確認できるツールは依然として2つのままです。つまり、context bloat（コンテキストの肥大化）が抑えられ、token cost（トークンコスト）が削減され、全体としてよりクリーンなアーキテクチャが実現します。 Act 2: The knowledge layer Backstage: そのすべてを支えるナレッジグラフ iMARSチームが実際に有用なMCPサーバー（Model Context Protocol Server）を構築する前に、私たちはより根本的な問題を解決する必要がありました。それは、サービスやインフラストラクチャに関する構造化データです。エージェントには、コードベース外のコンテキストを理解する必要があります。具体的には、どのリソースのオーナーが誰か、サービス間の依存関係はどうか、ドキュメントはどこに保管されているのか、そして各サービスがどのデータベースと通信しているのかといった情報です。 サービスカタログとして、Spotifyによって当初開発されたオープンソースの内部開発者ポータル「Backstage」を運用しています。これはセルフホスティングされています（念のため、Cloudflareの製品上ではありません）が、以下のような情報を追跡しています。 2,055のサービス、167のライブラリ、122のパッケージ スキーマ定義付きの228のAPI 45のドメインに跨る544のシステム（プロダクト） 1,302のデータベース、277のClickHouseテーブル、173のクラスター オーナーシップマッピングが設定された375のチームと6,389人のユーザー サービスが依存するデータベース、Kafkaトピック、クラウドリソースを結ぶ依存関係グラフ Backstage MCPサーバー（13のツール）はMCPポータルを通じて利用可能であり、エージェントはコーディングセッションを離れることなく、サービスのオーナー確認、依存関係のチェック、関連するAPI仕様書の検索、Tech Insightsスコアの取得を行うことができます。 この構造化データがなければ、エージェントは盲目で作業することになります。眼前のコードを読むことはできますが、その周囲のシステム全体を見渡すことができないからです。このカタログは、個々のリポジトリをエンジニアリング組織のつながったマップに変換します。 AGENTS.md：数千のリポジトリをAI対応へ準備する ロールアウト初期、私たちは同じ失敗パターン（failure mode）を繰り返し目にしていました。コーディングエージェントが妥当そうに見える変更を生成するものの、結局はリポジトリに対して誤っていたのです。通常の問題はローカルコンテキストでした。モデルが正しいテストコマンドやチームの現在の規約、あるいはコードベースのどの部分がアクセス不可領域なのかを知っていなかったためです。これがAGENTS.mdへの取り組みを後押ししました。各リポジトリに配置される短く構造化されたファイルで、コーディングエージェントに対してコードベースの実際の動作を伝え、チームにそのコンテキストを明示させるものです。 AGENTS.mdの例 GitLabインスタンス全体でAGENTS.mdファイルを生成するシステムを構築しました。これらのファイルはモデルのコンテキストウィンドウに直接配置されるため、短くかつ情報密度の高い（high-signal）状態を維持したかったのです。典型的なファイルは以下のようになります。 ``` # AGENTS.md ## Repository - Runtime: cloudflare workers - Test command: `pnpm test` - Lint command: `pnpm lint` ## How to navigate this codebase - All cloudflare workers are in src/workers/, one file per worker - MCP server definitions are in src/mcp/, each tool in a separate file - Tests mirror source: src/foo.ts -> tests/foo.test.ts ## Conventions - Testing: use Vitest with `@cloudflare/vitest-pool-workers` (Codex: RFC 021, RFC 042) - API patterns: Follow internal REST conventions (Codex: API-REST-01) ``` ## 境界線 - `gen/`内の生成ファイルは編集しない - `config/`を更新せずに新しいバックグラウンドジョブ（background jobs）を導入しない ## 依存関係 - 依存先: auth-service, config-service - 被依存先: api-gateway, dashboard エージェントがこのファイルを読み込む際、リポジトリ（repository）をゼロから推測する必要はありません。コードベースの構成方法、従うべき規約、適用されるEngineering Codex（エンジニアリングコデックス）のルールを把握しています。 大規模な生成方法 ジェネレーターパイプラインは、Backstageサービスカタログ（Backstage service catalog）からエンティティメタデータ（entity metadata：所有権、依存関係、システム間関係）を取得し、リポジトリ構造を分析して言語、ビルドシステム（build system）、テストフレームワーク（test framework）、ディレクトリレイアウト（directory layout）を検出します。その後、検出したスタックを関連するEngineering Codex（エンジニアリングコデックス）の基準にマッピングします。高性能なモデルが構造化ドキュメントを生成し、システムは所有チームがレビューして推敲できるようマージリクエスト（merge request）をオープンします。 現在までに約3,900のリポジトリ（repositories）をこの方法で処理しました。最初のパスは必ずしも完璧ではなく、特にポリグロットリポジトリ（polyglot repos：複数言語を混在させたリポジトリ）や特殊なビルド環境の場合にはそうでしたが、それでもそのベースラインはエージェントにすべてをゼロから推測させるよりもはるかに優れていました。 最初のマージリクエスト（merge request）はブートストラップ問題（bootstrap problem）を解決しましたが、これらのファイルを最新に保つことも同様に重要でした。古いAGENTS.mdは、ファイルがない状態よりも悪影響を及ぼす可能性があります。私たちはAIコードレビュアー（AI Code Reviewer）でこのループを閉じました。これはリポジトリの変更がAGENTS.mdの更新を示唆している場合にフラグを立てることができます。 アクト3：適用レイヤー（enforcement layer） AIコードレビュアー（AI Code Reviewer） Cloudflareのすべてのマージリクエスト（MR）にはAIコードレビューが適用されます。統合は簡単です：チームはパイプラインに単一のCIコンポーネント（CI component）を追加するだけで、それ以降すべてのMRが自動的にレビューされます。 GitLabのセルフホスティングソリューション（self-hosted solution）をCI/CDプラットフォーム（CI/CD platform）として使用しています。レビュアーは、チームがパイプラインに組み込むGitLab CIコンポーネントとして実装されています。MR（merge request）がオープンまたは更新されると、CIジョブはマルチエージェントレビューコーディネーター（multi-agent review coordinator）を起動してOpenCodeを実行します。コーディネーターはリスクティア（risk tier：trivial、lite、full）でMRを分類し、専門的なレビューエージェントに委任します：コード品質、セキュリティ、コデックス準拠、ドキュメント、パフォーマンス、リリース影響です。各エージェントはモデルアクセスのためにAIゲートウェイ（AI Gateway）に接続し、中央リポジトリからEngineering Codexルールを取得し、コードベースのコンテキストとしてリポジトリのAGENTS.mdを読み取ります。結果は

背景や根拠まで確認しますか？

関連記事

調べる

選ぶ

サイト