このコンテンツは自動機械翻訳サービスによる翻訳版であり、皆さまの便宜のために提供しています。原本の英語版と異なる誤り、省略、解釈の微妙な違いが含まれる場合があります。ご不明な点がある場合は、英語版原本をご確認ください。
過去30日間で、Cloudflareの研究開発組織の93%が、当社が独自のプラットフォーム上に構築したインフラストラクチャで稼働するAIコーディングツールを使用しています。
11か月前、当社はAIを真のエンジニアリングスタックに組み込むというプロジェクトに着手しました。エージェントがCloudflareで有用であるために必要な、内部MCPサーバー、アクセスレイヤー、AIツールを構築する必要がありました。全社のエンジニアを集め、「iMARS（社内MCPエージェント/サーバーロールアウトスクワッド）」と呼ばれるチームを編成しました。この持続的な作業の原因となったのは、CI/CD、ビルドシステム、自動化を含む社内ツールの多くを所有する開発プロダクティビティチームです。
以下は、過去30日間のエージェンティックAIの利用を把握する数値です：
AIコーディングツールを積極的に利用している社内ユーザーは3,683名（全社比60%、研究開発部門比93%）、総従業員約6,100名のうち
4795万件のAIリクエスト
295チームが現在、エージェンティックAIツールとコーディングアシスタントを活用しています。
2,018万件月間AI Gatewayリクエスト
2,413.7億トークンがAI Gatewayを経由
Workers AIで518億3000万トークンを処理
開発者ベロシティへの影響は明らかで、マージリクエストがこの程度で前四半期比で増加したことはありません。
AIツールの導入が拡大するにつれて、4週間の移動平均は週あたり約5,600件から8,700件超に上昇しました。3月23日の週は10,952件と、第4四半期のベースラインほぼ2倍の数字となりました。
MCPサーバーが出発点でしたが、当社のチームはすぐにさらなる進展が必要だと気付きました。標準のコーディング方法、コードのレビュー方法、エンジニアのオンボード方法、変更が数千のリポジトリに伝達される方法などを再考する必要がありました。
この記事では、過去11か月の間に何が起こったか、そして最終的にどこに至ったのかを深く掘り下げます。今、エージェントウィークの締めくくりとして、これを公開します。当社が社内で構築したAIエンジニアリングスタックは、今週当社が出荷し強化するものと同じ製品で実行しているからです。
エンジニア向けのツール層（OpenCode、Windsurf、その他のMCP互換クライアント）には、オープンソースとサードパーティ製のコーディング支援ツールの両方が含まれます。
各レイヤーは、使用するCloudflare製品やツールに対応します。
これらは、社内専用のインフラストラクチャではありません。上記のすべて（Backstage以外）は出荷製品であり、その多くはエージェントウィーク中に大幅なアップデートが行われました。
3編に分けて説明します：
プラットフォーム層 — 認証、ルーティング、推論の仕組み（AI Gateway、Workers AI、MCPポータル、コードモード）
ナレッジレイヤー — エージェントが当社のシステムをどのように理解しているか（Backstage、AGENTS.md）
適用層 — 大規模に高品質を維持する方法（AI Code Reviewer、Engineer Codex）
AI Gatewayが安全の確保と開発者体験の向上に役立ったこと
1日あたり3,600人以上の内部ユーザーがAIコーディングツールを使用している場合、多くのクライアント、ユースケース、ロールにわたるアクセスと可視性を確保する必要があります。
すべては、すべての認証とゼロトラストポリシーの適用を処理するCloudflare Accessから始まります。認証されると、すべてのLLMリクエストはAI Gatewayを経由します。これにより、プロバイダーキー、コスト追跡、データ保持ポリシーを一元管理できるようになります。
OpenCode AI Gatewayの概要：1日あたり68万8460万件のリクエスト、1日あたり105億7000万件のトークン、1つのエンドポイントを介して4つのプロバイダーにルーティングされています。
AI Gatewayの分析は、毎月の使用量がモデルプロバイダー間でどのように分布しているかを示します。先月の内部リクエスト量の内訳は次の通りです。
プロバイダー | リクエスト/月 | 共有 |
|---|
Frontier Labs（OpenAI、Anthropic、Google） | 1,338万人 | 91.16% |
Workers AI | 130万 | 8.84% |
フロンティアモデルは、複雑なエージェンティックコーディング作業の大部分を処理していますが、Workers AIはすでに混在環境の重要な部分を占めており、ますますエージェンティックエンジニアリングワークロードの割合が増えています。
Workers AIは、CloudflareのサーバーレスAI推論プラットフォームで、当社グローバルネットワーク上のGPUでオープンソースモデルを実行します。フロンティアモデルと比較して大幅なコスト改善に加え、推論がWorkers、Durable Objects、ストレージと同じネットワーク上に留まるという主な利点があります。クラウド間のホップに対処する必要はなく、これに起因する遅延やネットワークの脆弱性、追加のネットワーキング設定の管理が必要になります。
先月のWorkers AI利用状況：入力トークン5147億件、出力トークン3億6100万件
Kimi K2.5は、2026年3月にWorkers AI上でリリースされた、256kのコンテキストウィンドウ、ツール呼び出し、構造化出力を備えたフロンティア規模のオープンソースモデルです。Kimi K2.5ローンチ投稿で述べたように、Kimiでは1日あたり70億以上のトークンを処理するセキュリティエージェントがあります。これは、中堅層の独自モデルでは、年間240万ドルと推定されます。しかし、Workers AIなら77%も安くなります。
セキュリティ以外にも、CIパイプラインでのドキュメントレビュー、何千ものリポジトリにわたるAGENTS.mdコンテキストファイルの生成、および同一ネットワークの遅延がモデルのピーク性能よりも重要な軽量な推論タスクにもWorkers AIが使用されています。
オープンソースモデルが改善され続ける中で、Workers AIが社内のワークロードの割合を増大させることが期待されます。
ひとつのプロキシWorkerを早期に経由することで、初日から単一のプロキシWorkerを経由するルーティングが可能になりました。クライアントをAI Gatewayに直接接続させることもでき、最初は簡単にセットアップできたでしょう。しかし、Workerで集約するということは、クライアント設定に触れることなく、ユーザーごとの属性、モデルカタログの管理、および権限の適用を後で追加できることを意味します。以下のブートストラップセクションで説明されている機能はすべて、単一のチョークポイントがあるので存在します。プロキシパターンは、直接接続にはないコントロールプレーンを提供し、後で追加のコーディング支援ツールを接続した場合も、同じWorkerとディスカバリーエンドポイントがそれを処理します。
セットアップ全体は、1つのコマンドから始まります。
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に統合されます。提供される設定は、組織全体で共有されるデフォルトですが、ローカル設定が常に優先されます。ユーザーは、他のユーザーに影響を与えることなく、デフォルトモデルをオーバーライドしたり、独自のエージェントを追加したり、プロジェクトやユーザースコープの設定を調整したりすることができます。
プロキシWorker内。Workerは、3つのことを行うシンプルなHonoアプリです。
共有設定を提供します。設定は、デプロイ時に構造化されたソースファイルからコンパイルされ、Workerのオリジンの{baseURL}のようなプレースホルダー値が含まれます。リクエスト時に、Workerはこれらを置き換えるため、すべてのプロバイダーリクエストはモデルプロバイダーに直接ではなく、Workerを経由してルーティングされます。各プロバイダーには、Workerが対応するAI Gatewayルートに転送するパスプレフィックス（/anthropic, /openai, /google-ai-studio/v1beta, /compat for Workers AI）が与えられます。
AI Gatewayにリクエストをプロキシします。OpenCodeがPOST /anthropic/v1/messagesのようなリクエストを送信すると、WorkerはCloudflare Access JWTを検証し、転送前にヘッダーを書き換えます。
Stripped: authorization, cf-access-token, host
Added: cf-aig-authorization: Bearer <API_KEY>
cf-aig-metadata: {"userId": "<anonymous-uuid>"}
リクエストはAI Gatewayに送られ、AI Gatewayは適切なプロバイダーにルーティングします。レスポンスはバッファリングせずに直接通過します。Workerがサーバー側の実際のキーを挿入するため、クライアント設定のapiKeyフィールドは空です。ユーザーマシンにはAPIキーが存在しません。
モデルカタログの新鮮さを保ちます。毎時Cronトリガーは、models.devから現在のOpenAIモデルのリストを取得し、Workers KVにキャッシュし、ゼロデータ保持のため、すべてのモデルにstore: falseを挿入します。新規モデルは、設定の再デプロイなしに、ZDRを自動的に取得します。
匿名ユーザーの追跡。JWT検証後、WorkerはユーザーのメールをUUIDにマッピングし、永続ストレージとしてD1を使用し、KVを読み取りキャッシュとしてマッピングします。AI Gatewayが見るのは、cf-aig-metadataの匿名UUIDのみで、メールは見えません。これにより、モデルプロバイダーやGatewayログにIDを公開することなく、ユーザーごとのコスト追跡と使用状況の分析が可能になります。
コードとしての設定。エージェントとコマンドは、YAMLフロントマッターを使用してマークダウンファイルとして作成されます。ビルドスクリプトは、OpenCode JSONスキーマに照らし合わせて検証された、単一のJSON設定にコンパイルします。新規セッションはそれぞれ自動的に最新バージョンを取得します。
全体的なアーキテクチャは、プロキシのWorker、Cloudflare Access、AI Gateway、およびすべてを自動的に設定するクライアントにアクセス可能なディスカバリーエンドポイントなど、当社の開発者向けプラットフォームを使用すれば、誰でもシンプルで簡単にデプロイすることができます。ユーザーは1つのコマンドを実行するだけで完了します。手動で設定する必要はなく、ノートパソコンのAPIキーやMCPサーバー接続を手動でセットアップする必要もありません。エージェントツールの変更や、3,000人以上のユーザーがコーディング環境で利用するものを更新するのも、Wranglerデプロイするだけです。
エンタープライズ規模でMCPを管理するための完全なアプローチについては、別の記事で説明しています。これには、MCPサーバーポータル、Cloudflare Access、Code Modeを組み合わせて使用する方法が含まれます。以下は、当社社内で構築したものの一例です。
当社の内部ポータルは、13の本番MCPサーバーを集約し、Backstage、GitLab、Jira、Sentry、Elasticsearch、Prometheus、Google Workspace、社内リリースマネージャーなどの182以上のツールを公開しています。これにより、アクセスが統合され、すべてが簡素化され、1つのエンドポイントと1つのCloudflare Accessフローがすべてのツールへのアクセスを管理します。
各MCPサーバーは、同じ基盤（Agents SDKのMcpAgent、OAuth用のworkers-oauth-provider、ID用のCloudflare Access）上に構築されています。すべてが、共有認証インフラストラクチャ、Bazelビルド、CI/CDパイプライン、およびBackstage登録用のcatalog-info.yamlを持つ単一のモノレポジトリ内にあります。新しいサーバーの追加はたいてい、既存のサーバーをコピーして、ラップするAPIを変更することです。この仕組みとそれを支えるセキュリティアーキテクチャについては、当社のエンタープライズMCPレファレンスアーキテクチャをご覧ください。
MCPはAIエージェントとツールをつなぐための適切なプロトコルですが、現実的な問題があります。すべてのツール定義が、モデルが動作を始める前にコンテキストウィンドウのトークンを消費するということです。MCPサーバーやツールの数が増えるにつれて、トークンのオーバーヘッドも増加し、大規模になると、それは現実的なコストになります。コードモードは新たな解決策として浮上しています。すべてのツールスキーマを事前に読み込むのではなく、モデルはコードを通してツールを発見し、呼びます。
当社のGitLab MCPサーバーはもともと、34の個別ツール(get_merge_request、list_pipelines、get_file_contentなど)を公開していました。これら34個のツールスキーマは、1リクエストあたりコンテキストウィンドウのおよそ15,000トークンを消費しました。20万件のコンテキストウィンドウで、これは質問する前に使われた予算の7.5%に相当します。すべてのリクエスト、あらゆるエンジニア、毎日積み上がりました。
MCPサーバーポータルは、コードモードプロキシをサポートするようになりました。これにより、その問題をサーバーごとにではなく、集中的に解決できるようになりました。すべてのアップストリームツール定義をクライアントに公開するのではなく、ポータルはそれらを2つのポータルレベルツールに集約します。portal_codemode_searchとportal_codemode_execute。
ポータルレイヤーでこれを行う良い点は、きれいにスケーリングできることです。コードモードを使用しない場合、新しいMCPサーバーはすべてのリクエストにスキーマオーバーヘッドがさらに追加されます。ポータルレベルのコードモードでは、ポータルの背後にあるサーバーをさらに接続しても、クライアントに表示されるツールは2つだけです。つまり、コンテキストの肥大化を抑え、トークンコストを削減し、アーキテクチャ全体をすっきりさせることができるのです。
iMARSチームは、実際に有用なMCPサーバーを構築する前に、より根本的な問題を解決する必要がありました。当社のサービスとインフラストラクチャに関する構造化されたデータです。エージェントは、誰が何を所有しているか、サービスがどのように相互依存しているか、ドキュメントが存在するか、サービスが通信しているデータベースなど、コードベースの外側のコンテキストを理解する必要があります。
当社は、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向けに数千のリポジトリを準備
ロールアウトの初期段階では、同じ障害モードが続いています。コーディングエージェントは、もっともらしく見える変更を作成するものの、リポジトリとしてはまだ間違っているのです。通常、問題はローカルコンテキストでした。モデルは適切なテストコマンド、チームの現在の慣行、コードベースのどの部分がオフリミットであるかを把握していませんでした。これにより、AGENTS.mdが採用されました。これは、各リポジトリの短い構造化されたファイルで、コーディングエージェントにコードベースが実際にどのように機能するかを伝え、チームがそのコンテキストを明示化するように強制します。
GitLabインスタンス全体でAGENTS.mdファイルを生成するシステムを構築しました。これらのファイルはモデルのコンテキストウィンドウに直接位置するため、短く、高シグナルの状態に保つ必要がありました。典型的なファイルは次のようになります：
# 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)
## Boundaries
- Do not edit generated files in `gen/`
- Do not introduce new background jobs without updating `config/`
## Dependencies
- Depends on: auth-service, config-service
- Depended on by: api-gateway, dashboard
エージェントがこのファイルを読み込む際、リポジトリをゼロから推測する必要はありません。コードベースがどのように整理され、どのような規則に従うべきか、どのようなエンジニアリングコードのルールが適用されるかを把握しています。
ジェネレーターパイプラインは、Backpageサービスカタログからエンティティのメタデータ（所有権、依存関係、システム関係）を抽出し、リポジトリ構造を分析して言語、ビルドシステム、テストフレームワーク、ディレクトリレイアウトを検出し、検出されたスタックを関連するエンジニアリングCodex標準にマッピングします。次に、有能なモデルが構造化された文書を生成し、システムはマージリクエストを開き、所有チームがレビューして修正できるようにします。
これまでに、約3,900件のリポジトリをこの方法で処理しました。最初のパスは、特にPolyglotリポジトリや異常なビルドセットアップでは常に完璧とは言えませんでした。しかし、このベースラインでも、エージェントにすべてをゼロから推測するよりもはるかに優れた方法でした。
最初のマージリクエストはブートストラップの問題を解決しましたが、これらのファイルを最新の状態に保つことは同じくらい重要でした。古いAGENTS.mdは、ファイルがないよりも悪いことがあります。このループはAI Code Reviewerで閉じ、リポジトリが変更された場合にAGENTS.mdの更新が必要であることを示唆することができます。
CloudflareのすべてのマージリクエストはAIコードレビューを受けます。統合は簡単です。チームはパイプラインにCIコンポーネントを1つ追加すれば、そこからすべてのMRが自動的にレビューされます。
GitLabのセルフホスト型ソリューションをCI/CDプラットフォームとして使っています。レビュー担当者は、GitLabのCIコンポーネントとして実装され、チームがパイプラインに含めます。MRがオープンまたは更新されると、CIジョブはマルチエージェントレビューコーディネーターを使用してOpenCodeを実行します。コーディネーターは、MRをリスクレベル（トリニアル、ライト、またはフル）で分類し、コード品質、セキュリティ、コーデックコンプライアンス、ドキュメント、パフォーマンス、リリースへの影響を、専門のレビューエージェントに委任します。各エージェントはAI Gatewayに接続してモデルにアクセスし、中央リポジトリからEngineer Codexルールをプルし、リポジトリのAGENTS.mdを読み込んでコードベースコンテキストを取得します。結果は構造化されたMRコメントとして投稿されます。
別のWorkersベースの設定サービスが、レビュー担当エージェントごとに集中管理されたモデル選択を処理するため、CIテンプレートを変更することなくモデルを移行できます。レビュープロセス自体はCIランナーで実行され、実行ごとにステートレスです。
出力フォーマットを正しく理解するのに時間を費やしたのです。レビューはカテゴリー（セキュリティ、コード品質、パフォーマンス）に分類されているため、エンジニアは大量の文書を読むのではなく、ヘッダーを確認することができます。各発見事項には、重大度レベル（重大、重要、提案、または任意の有効期限）があり、注意が必要で、情報的なものであるのかを即座に明確にすることができます。
レビュー担当者は反復を通じてコンテキストを維持します。以前のレビューラウンドでフラグを立て、それ以降に修正された場合は、同じ問題を再度提起するのではなく、そのことを認識します。また、検出結果がエンジニアリングコーデックのルールに対応する場合は、特定のルールIDが引用され、AIの提案を組織の基準への参照に変えてしまいます。
Workers AIは、レビュー担当者のトラフィックの約15%を処理します。主にドキュメントレビュータスク向けであり、Kim K2.5はフロンティアモデルのコストの数分の一で優れたパフォーマンスを発揮します。Opus 4.6やGPT 5.4のようなモデルでは、推論能力が最も重要になる、セキュリティに敏感でアーキテクチャ的に複雑なレビューを処理します。
過去30日間：
このブログ記事と一緒に、レビュー担当者の内部アーキテクチャ（モデル間のルーティング方法、マルチエージェントオーケストレーション、当社が開発したコスト最適化戦略など）を解説する詳細な技術ブログ記事も公開します。
エンジニアリング規範：エージェントのスキルとしてのエンジニアリング基準
エンジニアリングコーデックは、Cloudflareの新しい社内標準システムであり、私たちのコアエンジニアリング基準が組み込まれています。私たちは、複数段階のAI抽出プロセスを経て、一連のコーデックルール（「Xが必要なら、Yを使ってください。YまたはZを使用している場合は、Xを実行する必要があります。」）と、プログレッシブデプロイを使用したエージェントスキル、およびマークダウンファイル間のネストされた階層情報ディレクトリとリンクを使用する必要があります。
このスキルは、エンジニアが「Rustサービスのエラーをどう処理すべきか？」ようなプロンプトで構築する際に、ローカルで使用することが可能です。または「このTypeScriptコードを確認してコンプライアンスを確保する」Cloudflareのネットワークファイアウォールチームは、マルチエージェントコンセンサスプロセスを使用してrampartdを監査しました。すべての要件が「準拠」、「部分」、または「非準拠」のスコアで決定され、特定の違反の詳細と修復ステップが削減され、以前は何週間も手作業を行っていたものが、構造化された反復可能なプロセスに移行しました。
レビュー時に、AI Code Reviewerは、フィードバックで特定のCodeexルールに言及します。
AIコードレビュー：コーデックRFC違反を示す、分類された調査結果（この場合はコードコンプライアンス）を表示
これらの記事は、いずれも単独では特に目新しいものではありません。多くの企業がサービスカタログを実行し、船のレビューボットを運用したり、エンジニアリング基準を公開したりしています。違いは回線にあります。エージェントがBackstageからコンテキストを引き出し、編集しているリポジトリのAGENTS.mdを読み込んで同じツールチェーンでCodexルールに照らしてレビューできる場合、通常、最初の草稿は出荷に十分近いものとなります。6か月前はそうではありませんでした。
この取り組みを開始してから93%の研究開発が導入されるまで、1年未満でした。
全社導入（2026年2月5日～4月15日）：
指標 | 価値 |
|---|
アクティブユーザー | 3,683件（会社の60%） |
R&Dチームの採用 | 93% |
AIメッセージ | 4795万人 |
AIアクティビティを持つチーム | 295 |
OpenCodeメッセージ | 2708万人 |
Winndsurfメッセージ | 43万4900 |
AI Gateway（過去30日、合計）：
指標 | 価値 |
|---|
リクエスト | 2018万人 |
トークン | 241370億 |
Workers AI（過去30日間）：
指標 | 価値 |
|---|
入力トークン | 510億4700万 |
出力トークン | 3億6,112万人 |
次の社内エンジニアリングスタックの進化には、バックグラウンドエージェントが含まれます。バックグラウンドエージェントは、ローカルで利用可能な同じツール（MCPポータル、git、テストランサム）を使ってオンデマンドで起動でき、完全にクラウド上で動作するエージェントです。アーキテクチャは、Durable ObjectsとAgents SDKを使用してオーケストレーションを行い、ジョブがリポジトリのクローン、依存関係のインストール、テストの実行などの完全な開発環境を必要とする場合、サンドボックスコンテナに委任します。Sandbox SDKはエージェントウィーク中に一般公開されました。
Agents Week中に、Agents SDKにネイティブに組み込まれた、長期実行エージェントは、これまで回避策が必要だった永続的なセッションの問題を解決します。SDKは、エージェントが大規模なレポジトリのクローン、完全なテストスイートの実行、障害発生時の反復、および単一セッションでMRを開くことができるよう、長期間にわたって実行するセッションを退避させることなくサポートするようになりました。
これは、コードの書き方だけでなく、コードのレビュー方法、標準の適用方法、変更を数千のリポジトリに安全に送信する方法について再考するための11か月に及ぶ取り組みです。すべてのレイヤーは、お客様が使用している同じ製品上で実行されます。
Agents Weekは、必要なものすべてを公開しました。プラットフォームはこちらです。
npx create-cloudflare@latest --template cloudflare/agents-starter
これにより、エージェントを開始することができます。以下の図は、成長する準備ができた場合の全体的なアーキテクチャで、最上位のツール層（チャットボット、Web UI、CLI、ブラウザ拡張機能）、中央のエージェントSDKがセッション状態とオーケストレーション、そしてCloudflareサービスを示しています下記から呼び出すことができます。
ドキュメンテーション: エージェントSDK · サンドボックスSDK · AI Gateway · Workers AI · Workflows · コードモード · Cloudflare上のMCP
Repos: cloudflare/agents · cloudflare/sandbox-sdk · cloudflare/mcp-server-cloudflare · cloudflare/skills
CloudflareにおけるAIの活用方法の詳細については、AIコードレビューのプロセスに関する記事をご覧ください。そして、エージェントウィーク中にお届けしたすべてのものをご覧ください。
構築されたものについてぜひお聞かせください。Discord、X、Blueskyで私たちを見つけてください。
Ayush T期限、AGENTS.mdシステムとOpenCodeインフラ用のAI Gateway統合を構築した。Scott RoemeschkeはCloudflareの開発者プロダクティビティチームのエンジニアリングマネージャーであり、Rajesh BhatiaはCloudflareの生産性プラットフォーム機能を主導しています。この投稿は、Devtoolsチーム全体での共同作業であり、iMARS（社内MCPエージェント/サーバーロールアウトスクワッド）のトラッキングチームを通じて全社的なボランティアの協力を得ました。