OpenAI + Cloudflare AI Gateway チュートリアル（2026）：本番 AI Agent をより安全に運用する方法

まず結論

2026 年に OpenAI ベースの agent を本番に近づけたいなら、最短ルートは「まず大きな agent プラットフォームを構築する」ことではない。こうだ：

既存の OpenAI アプリロジックをそのまま維持する。
OpenAI リクエストの前に Cloudflare AI Gateway を配置する。
ワークフローを拡張する前に、ログ、分析、レート制限、リトライ、フォールバックを追加する。
gateway 層が動いてから、レイテンシに敏感な部分やエッジ寄りの部分を Cloudflare Workers や Workers AI に移す。

OpenAI が 2026 年 4 月 13 日に GPT-5.4 を含むモデルを Cloudflare Agent Cloud に拡張すると発表した後、この方針の裏付けはさらに強まった。多くのチームにとって重要なのは提携の見出しではなく、Cloudflare のドキュメントで再現可能なパスがすでに公開されていること。OpenAI トラフィックを Cloudflare の gateway 層に通し、Cloudflare のランタイムは明確に役立つ場所だけ追加する。

2026-04-14 時点で、agent スタック全体を作り直さずに observability と制御を得る最も素直な方法はこれだ。

このチュートリアルの対象

すでに OpenAI API を使っているか、狭いスコープの本番 agent を計画しているチーム向け。たとえば：

カスタマーサポートのトリアージ
社内レポートの自動生成
フォームやチケットの分類
境界の明確なコーディングやコンテンツワークフロー
ログ、制限、ロールバック機能が必要な agent バックエンド

ChatGPT で手動プロンプトを試している段階で、agent が何をすべきかまだ分からない場合は、この記事は最適な出発点ではない。agent の全体像を先に把握したい場合は AI Agent 実践ガイド（2026）を参照。

なぜ今このトピックが重要か

ニューストリガーは明確だ。

2026 年 4 月 13 日、OpenAI はエンタープライズが Cloudflare Agent Cloud 内で OpenAI モデルを使った agent をデプロイできると発表し、Codex harness が Cloudflare Sandboxes で GA になったこと、Workers AI サポートが次のステップであることを述べた。発表が重要なのは、エッジデプロイと agent 運用が一歩近づいたからだ。

すでに OpenAI アプリがあるなら、最初に見るべきなのは曖昧な「agent cloud」概念ではなく、今日コピーできるパスだ。

Cloudflare の公開ドキュメントはすでに 2 つのコンポーネントでそのパスを示している：

コンポーネント	何をするか	なぜ先に使うべきか
AI Gateway	AI リクエストの前に分析・ログ・キャッシュ・レート制限・リトライ・モデルフォールバックを追加	アプリを書き直さず制御を強化できる
Workers / Workers AI	Cloudflare ネットワーク上でアプリロジックとモデル推論を実行	ユーザーに近い場所で動かすべき部分が分かってから

本チュートリアルは AI Gateway から始める。プラットフォーム全体の移行からではない。

OpenAI + Cloudflare が適するケース

以下のうち少なくとも 2 つが必要なら、この構成が適している：

リクエスト量、トークン、エラーを一箇所で確認する場所
ユーザーとモデル呼び出しの間のレート制限
本番トラフィックのリトライまたはフォールバック動作
複数の OpenAI エンドポイントを低負荷で標準化する方法
将来のエッジ実行への道筋

ワークフローが日々変わっている、agent の成功基準が安定していない、どのプロンプトやツールを運用化すべきか分からない場合は、今はスキップ。

Cloudflare のレイヤーで得られるもの

Cloudflare AI Gateway のドキュメントは提供機能を具体的に記載している。2026-04-14 時点で、以下の本番向け制御がドキュメントに直接記載されている：

リクエスト、トークン、コストの分析
リクエストとエラーのログ
キャッシュ
レート制限
リクエストリトライとモデルフォールバック
OpenAI を含む複数プロバイダーのサポート

Cloudflare のドキュメントでは AI Gateway は無料プランを含む全 Cloudflare プランで利用可能と明記されている。有料プランなしでも AI トラフィックのログと制御を始められる。Workers AI は別製品として Free・Paid 両プランで利用可能とされ、Cloudflare ネットワーク上でのサーバーレスモデル推論を提供する。

多くのチームにとって AI Gateway が最初の運用レイヤー。Workers AI は次段階のデプロイ判断だ。

最速の安全なセットアップ

ステップ 1：境界の明確な agent タスクから始める

汎用の自律 agent から始めてはいけない。

入力・出力・失敗条件が明確なタスクを 1 つ選ぶ。良い例：

サポートチケットを固定 JSON schema に要約
セールスリードを 3 つのルーティングバケットに分類
構造化メモから社内週報を作成
会議の議事録からアクションアイテムを抽出

期待する出力を 1 段落で説明できないなら、まだ本番制御を入れる段階ではない。

ステップ 2：既存の OpenAI 呼び出しの前に AI Gateway を配置

Cloudflare の OpenAI provider ドキュメントがコアの変更を示している：通常の OpenAI base URL を Cloudflare gateway URL に差し替える。

元の呼び出し先：

https://api.openai.com/v1

以下に変更：

https://gateway.ai.cloudflare.com/v1/{account_id}/{gateway_id}/openai

1 行の変更でリクエストは Cloudflare の制御レイヤーを通るようになる。

ステップ 3：アプリロジックはシンプルに

key-in-request パターン（OpenAI API キーが gateway 経由で転送される）を使った最小限の Node サンプル：

import OpenAI from "openai";

const client = new OpenAI({
  apiKey: process.env.OPENAI_API_KEY,
  baseURL: "https://gateway.ai.cloudflare.com/v1/{account_id}/{gateway_id}/openai",
});

// OpenAI の新しい Responses API (client.responses.create) を使用
// 旧版の Chat Completions API (client.chat.completions.create) ではない
const response = await client.responses.create({
  model: "gpt-5.1",
  input: [
    {
      role: "user",
      content: "Summarize this ticket and return priority, owner, and next action.",
    },
  ],
});

Cloudflare の stored-key（BYOK）や統合課金パス（Cloudflare がキーを保管し、Cloudflare API トークンで認証）を使いたい場合は、Cloudflare ドキュメントの「Stored Keys」タブに詳細がある。ポイントは同じ：既存の OpenAI SDK を使い、ルーティング層だけ差し替える。

ステップ 4：制御を 1 つずつ追加

プラットフォームの全機能を一度にオンにしない。

最も安全なロールアウト順：

ログ
分析
レート制限
リトライ
フォールバック
キャッシュ（レスポンスの再利用が安全な場合のみ）

この順番は、過剰なインフラで不良プロンプトの問題を隠すリスクを減らす。

ステップ 5：エッジ移行は後回し

OpenAI の発表は Agent Cloud を Cloudflare のエッジスタック全体に結びつけ、Cloudflare のドキュメントも Workers AI をネットワーク上のモデルランタイム層と位置づけている。

しかしすべての agent が初日からエッジに全面移行すべきだということではない。

より良いルール：

既存のバックエンドが安定しているなら、オーケストレーションはそのまま残す
リクエストルーティングと制御をまず AI Gateway に移す
レイテンシに敏感な部分やグローバル分散が必要な部分だけ後で Workers / Workers AI に移す

デバッグしやすく、ロールバックもしやすい。

実用的な入門ユースケース：サポートトリアージ Agent

すぐに運用化する価値のあるワークフローが 1 つ欲しいなら、サポートトリアージは良い候補だ。

なぜうまくいくか

入力が標準化しやすい
出力を schema に制約できる
失敗の検査が容易
レート制限とログがすぐ役立つ
トラフィックスパイク時にリトライとフォールバックが有用

コピー可能な prompt

You are a support triage assistant.
Return valid JSON with exactly these fields:
- issue_type
- urgency
- customer_impact
- next_action
- escalation_needed

Classify conservatively.
If the ticket is ambiguous, say so in next_action instead of guessing.

出力例

{
  "issue_type": "billing",
  "urgency": "medium",
  "customer_impact": "single account blocked from invoice download",
  "next_action": "send billing support response template and verify account status",
  "escalation_needed": false
}