Nullstead

Cloudflare

AI Gatewayで「LLM請求こわい問題」を潰す：Cloudflare Agents Week 2026を踏まえた個人開発ランブック

Cloudflare Agents Week 2026の公開情報とAI Gateway公式ドキュメントをもとに、個人開発でAI機能を安全に回すための実践設計を解説。コスト管理、リトライ・フォールバック、MCPガバナンスまでを一気通貫で整理します。

約10分

AI機能を個人開発に組み込むと、最初に来る感情はだいたい「便利！」です。次に来るのは「請求書、いくらになるんですか？」です。はい、現実はいつも2ターン目で重くなります。

2026年4月のCloudflare Agents Weekでは、Cloudflareが内部運用として AI Gateway経由で2,000万リクエスト、2,410億トークン を処理したことを公開しました。規模感がすごいのはもちろんですが、個人開発者にとって重要なのは「この規模を回すために、どんな制御面を先に作っているか」です。

この記事では、私が個人開発のAI機能を設計するときに使う考え方として、Cloudflare AI Gatewayの公式ドキュメントとAgents Weekの情報を土台に、次の3点をまとめます。

  • コスト暴走を止める設計
  • 失敗時に止まらない設計
  • ガバナンス（シャドーMCP検知含む）を後付けしない設計

派手な最適化より、まず「死なない配管」を作る話です。地味ですが、ここが強いと開発が続きます。

なぜ今AI Gatewayなのか：観測→制御→再現の順で整える

Cloudflare AI Gatewayの説明はシンプルで、要するに「AIアプリの観測と制御の集約点」です。分析、ログ、キャッシュ、レート制限、リトライ、フォールバックを1か所で持てます。

ここで大事なのは、機能の数ではなく順番です。私のおすすめは以下です。

  1. 観測（Analytics/Logging）
  2. 制御（Rate limit/Caching）
  3. 回復（Retry/Fallback）

いきなり「モデル最適化」や「プロンプト職人芸」に行きたくなるのですが、先に配管を作らないと、改善しているのか悪化しているのか測れません。測れない改善は、だいたい宗教になります。※宗教が悪いとは言っていませんが、請求書は信仰で減りません。

※ フォールバック: 主系が失敗したときに、別モデル・別プロバイダーへ自動切り替えする仕組みです。

まず作る最小構成：1 Gateway + 2モデル + 明示的な失敗条件

私なら、最初は欲張らず次の構成にします。

  • Gatewayは1つ（機能単位で分けすぎない）
  • Primaryモデル1つ + Fallbackモデル1つ
  • タイムアウト、リトライ回数、バックオフ方式を明示
  • すべてのリクエストにメタデータを付与（機能名、ユーザー種別、実行元）

CloudflareのRequest handlingドキュメントでは、リトライは最大5回、遅延やバックオフ（constant/linear/exponential）を設定できます。さらにUniversal Endpointでは、リトライ後にフォールバックへ進めます。

以下は、最小構成の考え方をそのまま形にした例です（動作未検証。公式仕様に沿ったサンプル構成です）。

curl 'https://gateway.ai.cloudflare.com/v1/{account_id}/{gateway_id}' \
  --header 'Content-Type: application/json' \
  --data '[
    {
      "provider": "workers-ai",
      "endpoint": "@cf/meta/llama-3.1-8b-instruct",
      "headers": {
        "Authorization": "Bearer {cloudflare_token}",
        "Content-Type": "application/json"
      },
      "config": {
        "requestTimeout": 2500,
        "maxAttempts": 3,
        "retryDelay": 800,
        "backoff": "exponential"
      },
      "query": {
        "messages": [
          {"role": "system", "content": "You are a concise assistant."},
          {"role": "user", "content": "要点を3つで説明して"}
        ]
      }
    },
    {
      "provider": "openai",
      "endpoint": "chat/completions",
      "headers": {
        "Authorization": "Bearer {openai_token}",
        "Content-Type": "application/json"
      },
      "query": {
        "model": "gpt-4o-mini",
        "messages": [
          {"role": "user", "content": "要点を3つで説明して"}
        ]
      }
    }
  ]'

このとき、レスポンスヘッダー cf-aig-step を必ずログ保存します。

  • 0: Primary成功
  • 1以上: フォールバック発火

ここを見ないと、「最近遅い気がする」の原因がモデル劣化なのか、実は裏で毎回フォールバックしているのか判別できません。体感デバッグ卒業の第一歩です。

FinOps設計：コストを「最終請求」ではなく「途中経過」で見る

AIコスト運用でありがちな事故は、月末にしか異常検知できないことです。AI GatewayのAnalytics/Loggingを使うなら、最低でも日次で次を見ます。

  • リクエスト数
  • トークン量
  • 失敗率
  • フォールバック率（cf-aig-step >= 1）
  • キャッシュヒット率

CloudflareのPricing/Limits情報では、AI Gatewayのコア機能（分析・キャッシュ・レート制限）は無料提供、Persistent logsはプラン別の保存上限があります。例えばFreeはアカウント全体で100,000ログ、PaidはGatewayごとに10,000,000ログです。保存戦略を先に決めないと、必要なときに証拠が消えている、という悲劇が起きます。

私が先に決める運用ルール

  1. ログ保存の優先順位を決める
    • 全量保存する機能
    • サンプリングで十分な機能
  2. 機能ごとに予算上限を持つ
    • 例: 記事要約は1日X円、サポート返信は1日Y円
  3. 異常の定義を数値で持つ
    • 例: フォールバック率20%超で通知

「気合いで節約」は継続しません。ルール化すると、人間のやる気に依存しなくなります。

信頼性設計：レート制限とリトライはセットで考える

レート制限を入れると保護はできますが、きつすぎると自分で自分をDoSします。逆にリトライだけ増やすと、障害時に雪崩リクエストを起こします。なので、以下をセットで決めます。

  • 入り口: レート制限（過負荷を防ぐ）
  • 中間: タイムアウト（待ちすぎ防止）
  • 出口: リトライ + フォールバック（回復）

Cloudflare AI Gatewayはこの3点を同一レイヤーで持てるのが強みです。アプリ側に個別実装してもよいですが、言語やサービスが増えると設定が分散し、いつの間にか「Aサービスだけ3年前の設定」みたいな化石が生まれます。化石はロマンですが、本番には不要です。

実運用では、次の順で段階的に開けるのが安全です。

  1. タイムアウト短め + リトライ少なめ
  2. 失敗率を見ながら調整
  3. 最後にフォールバック先の品質とコストを微調整

ガバナンス設計：MCP時代の「便利だけど怖い」を減らす

Agents Week関連のCloudflareブログでは、MCP運用の実務として次の論点が強調されています。

  • ローカル乱立ではなくリモートMCPを中央管理
  • Accessを使った認証・認可
  • MCP server portalsで発見性と統制を両立
  • Gateway/DLPでShadow MCPを検知

ここでの学びは明確です。AIを速くする前に、接続先を把握する。これだけで事故の種類がかなり減ります。

※ Shadow MCP: 管理者が把握していない非公式MCPサーバー利用を指します。便利でも、認可や監査が抜けやすいのが問題です。

またCode Modeの話は、個人開発にも効きます。Cloudflareの事例では、巨大APIを大量ツールとして露出せず、search() と execute() の少数ツールに集約してコンテキスト使用量を圧縮しています。要は「道具を増やす」ではなく「道具箱を賢くする」発想です。

私はこの考え方を、個人開発では次のように使います。

  • MCPツールをむやみに増やさない
  • よく使う操作は抽象化した少数ツールへ寄せる
  • ツール追加時は「誰が」「何を」「どこまで」実行できるかを先に定義

AIに自由を与えるなら、境界線も同時に与える。ここを省略すると、だいたい深夜に自分が泣きます。

導入チェックリスト：これだけやれば事故率はかなり下がる

最後に、私が導入時に見るチェック項目を置いておきます。

  • AI Gatewayを経由しない直叩き経路が残っていない
  • 主要機能に requestTimeout が設定されている
  • maxAttempts と backoff の方針が統一されている
  • フォールバック先の品質要件（速度・コスト・出力傾向）を定義済み
  • cf-aig-step を保存し、フォールバック率を可視化している
  • ログ保存上限に達したときの挙動（削除/停止）を決めている
  • レート制限違反時のユーザー向けメッセージを準備している
  • MCP連携先を台帳化し、不要なものを定期棚卸ししている

このチェックは地味ですが、AI機能の炎上はたいてい地味な未設定から始まります。華麗なプロンプトより、地味なチェックリスト。夢はないですが、効果はあります。

まとめ：個人開発のAI運用は「賢さ」より「壊れにくさ」

2026年のAI開発は、モデル性能だけで勝負する段階を過ぎました。実装が速い人は増え、差は運用に出ます。とくに個人開発は、障害対応・コスト管理・セキュリティ判断を1人で抱えがちです。

だからこそ私は、次の順番を推します。

  1. 観測を作る
  2. 制御を作る
  3. 回復を作る
  4. その後で最適化する

AI Gatewayのような制御面を先に置いておくと、モデルやプロバイダーを入れ替えても、運用の背骨は残ります。背骨があると、機能追加が怖くなくなります。

「速く作る」は才能でできることがありますが、「壊れにくく回す」は設計でしか作れません。ここに投資すると、あとでちゃんと回収できます。請求書の精神ダメージも、だいぶ減ります。

参考リンク

Tags #Cloudflare #AI Gateway #FinOps #MCP #個人開発 #自動化
← 記事一覧に戻る ページの先頭へ ↑