Cloudflare Workers時代のAIゲートウェイ監視設計: レイテンシとコストを同時に見る

エッジでプロンプトを受け、ポリシー適用し、複数モデルへ振り分けてストリーミング応答する――このAIゲートウェイ構成は急速に一般化しています。一方で、従来API監視のままでは運用がすぐ破綻します。

理由は単純で、AIリクエストは「多段・ストリーミング・トークン課金」の3要素を持つためです。件数とp95だけでは、遅延悪化やコスト急増の原因が読めません。

まず押さえるべき観測項目

• モデルプロバイダとモデルバージョン
• 入出力トークン量
• ストリーミング継続時間
• RAG/ツール呼び出しの分岐回数
• ポリシー判定結果（許可・遮断・再試行）
• ユーザー再試行の発生

これらを1つのトレースに結び付けるのが最優先です。

4レイヤー監視モデル

レイヤー1: エッジ入口メタデータ

Worker入口でテナント、ルート、リージョン、SLAクラスを必ず付与します。

レイヤー2: オーケストレーションSpan

• プロンプト整形
• セーフティフィルタ
• 検索/取得
• モデル呼び出し
• 応答後処理

を分割計測し、どの段で遅いかを即判定可能にします。

レイヤー3: プロバイダ課金データ

入出力トークン、再試行回数、タイムアウト状態をSpan属性として残し、遅延と費用を同時分析できる形にします。

レイヤー4: 体験品質シグナル

• 途中切断
• 回答品質フィードバック
• ツール失敗露出
• セッション内リトライ

を紐付けることで、技術指標とUX指標の分断を防ぎます。

エンドポイント単位ではなくフェーズ単位で遅延予算を持つ

同じp95でもボトルネックは違います。フェーズ別に予算を置くべきです。

• 認証・ポリシー: 30-80ms
• 取得・文脈整形: 100-300ms
• first token: 200-1200ms
• stream完了: タスク依存

この分解がないと、改善対象の特定に時間を浪費します。

実験を止めないコスト統制

• テナント別ソフト上限
• 予算逼迫時のモデル自動ダウングレード
• 低価値長文入力の整形・圧縮
• 反復文脈のキャッシュ/要約化

全面的な制限ではなく、価値密度に応じた制御が重要です。

インシデント時の即答質問

1. 問題は特定プロバイダか、基盤全体か
2. 遅延・品質・ポリシーのどれが主因か
3. どのテナント/ルートで同時悪化しているか
4. 再試行が成功率を上げずに費用だけ増やしていないか

これに数分で答えられないなら、計測設計をやり直すべきです。

90日導入ロードマップ

• 1-15日: トレーススキーマと必須タグ統一
• 16-30日: Worker内部Spanとトークン計測実装
• 31-60日: テナント別費用ダッシュボード/アラート
• 61-90日: 品質シグナルを結合して改善ループ化

AIゲートウェイは「つながれば動く」領域ではありません。観測設計まで含めて初めて運用可能になります。エッジ実装の勝敗は、コード量よりも可視化の粒度で決まります。