はじめに：AI アプリケーションを本番環境に出すまでの道のりで、API 中継サービスは多くの開発者にとって避けて通れない関門です。ところが、中継サービスの公式サイトに並ぶ「99.9% 高速・安定」「専用の高同時実行チャネル」といった宣伝文句を信じて実際に接続してみると、想像以上に闇が深いことに気づくかもしれません。今回は、私たちのチームが「勘で手当たり次第に買う」段階から「自動監視の仕組みを構築する」段階に至るまでの苦い経験を振り返りつつ、支払いや接続の前に中継サービスの実態を見極めるためのテストの枠組みを、すべて公開します。
1. AI 中継サービスで味わった苦い失敗の数々
正直に言うと、今日この多面的なテスト体系をまとめられたのは、最初から私たちが賢かったからではまったくありません。実際のお金、本番環境での障害、そしてユーザーからの苦情という代償を払って、ようやくたどり着いたものです。
1. 落とし穴その 1：「偽の 200 OK」と「こっそり途中切断」
自動評価を始めたばかりの頃、私たちの発想はとても素朴なものでした。Python のスクリプトを書いて 5 分ごとに中継サービスへ POST リクエストを送り、HTTP 200 のステータスコードとテキストが返ってくれば黙ってチェックを付け、サービスはなかなか安定していると考えていたのです。
ところが、本番環境にエージェントをデプロイして 2 日もたたないうちに、サポート窓口に問い合わせが殺到しました。「AI の回答が途中でぷつりと止まる」「生成された内容のロジックが完全に破綻している」といった声が、あちこちから寄せられたのです。
ログを調べてみて、正直あきれました。一部の中継サービスは、上流のアカウントプールの枯渇（429 のレート制限や 401 の認証失効など）、ゲートウェイのタイムアウト（504）、ノードのクラッシュを隠すために、HTTP プロトコルのレイヤーではそのまま 200 OK を返していたのです。さらに悪質なことに、ストリーミング（SSE）の転送途中で裏側から data: [DONE] をこっそり差し込んで強制的に終了させたり、JSON の中にもっともらしく {"error": "rate limit exceeded"} を入れてモデルの回答に見せかけたりしていました。ステータスコードしか見ていなかった当初の「素朴な」監視は、この「偽の 200 応答」に完全に手玉に取られていたわけです。
2. 落とし穴その 2：夜間の「幽霊のような停滞」と跳ね上がる TTFT
痛い目を見たあと、私たちはすぐに改善に取りかかり、24 時間体制の定期監視を追加しました。日中に計測すると平均応答時間は 2 秒前後で、数字の上ではとてもきれいでした。ところが、夜間のピーク時間帯になると、本番システムの呼び出しタイムアウト率とユーザーの離脱率がロケットのように跳ね上がったのです。
あとでわかったのですが、ほとんどの中継サービスのバックエンドには、公式への直通チャネルなどそもそも存在しませんでした。米国リージョンのアカウントプールや複数地域のプロキシノードを寄せ集めてつないでいるだけだったのです。北米の業務時間帯や中国国内の夜間ピークになって同時実行数が増えると、完全に処理が追いつかなくなります。最もひどかったのは、回答全体の生成にかかる総時間は相変わらず 4 秒前後に見えるのに、最初のトークンが出るまでの時間（TTFT）にまる 12 秒もかかっていたケースでした。フロントエンドで空白の入力欄を前に十数秒も待たされては、たまったものではありません。ほとんどのユーザーはとっくにしびれを切らして、ページを閉じていました。
この 2 つの障害で、私たちは完全に目が覚めました。一度 Ping を打つ、リクエストを 2 本ほど送ってみる、といった程度の確認は、複雑な AI プロトコルとストリーミング転送の前では、ただの自己欺瞞にすぎないのです。
2. 「盲信」から「厳重な防御」へ：テスト体系の 3 段階の進化
中継サービス事業者のマーケティングの大言壮語に振り回されないよう、私たちの評価方法は 3 つの段階を経てきました。
1.0 時代：手探りの試用と勘（経験主義）
- 方法：Web UI で手動でプロンプトをいくつか送って試したり、10 回リクエストを送るスクリプトを書いたりして、速度が速いか、回答の質が高いかを確かめていました。
- 限界：テストのサンプルが小さすぎて偶然に大きく左右され、完全に運任せです。本番環境で高い同時実行数や突発的な切断に遭遇すると、すぐに問題が露呈します。
2.0 時代：同時実行と HTTP ステータスコードの監視（大まかな監視）
- 方法：Postman と Locust で同時実行の負荷テストを行い、HTTP ステータスコードの分布、平均応答時間、成功率を見るようになりました。
- 限界：見えるのは最も外側の「ゲートウェイ」の挙動だけです。ストリームの途中切断、偽装されたエラー、トークン出力のカクつきといった、奥に隠れた問題はまったく捉えられません。
3.0 時代：ストリーミングの状態機械と他業界からの知見（精密な観測）
自前の監視指標が行き詰まっていた頃、私たちは高頻度取引（HFT）と CDN 運用の分野で働く周さんに話を聞きに行きました。
周さんは私たちの悩みを聞くと、核心をずばりと指摘しました。「AI API 中継サービスを普通の Web API と同じようにテストしている時点で、最初から発想がずれている。あれは本質的に、長時間接続と高い同時実行性を持つネットワークの中間ノードなんだよ」
周さんによれば、AI の SSE ストリーミングは、下層のトポロジーやパケットロスへの敏感さという点で、音声・映像のリアルタイム通信（WebRTC/RTMP）や証券の相場配信とよく似ているそうです。従来の Web の計測ロジックをそのまま当てはめるのではなく、高頻度取引で「Tick-to-Trade レイテンシ」を測る考え方や、CDN で「最初のフレームの読み込み」を測るときの、経路を分解する考え方を取り入れるべきだというのです。
この話に刺激を受けて、私たちは従来の監視ロジックを根本から作り直しました。複数地域に分散したプローブを構築し、ネットワーク接続の確立、TLS ハンドシェイク、最初のトークンの到着、トークンのスループット、SSE パケットの解析をすべて切り分けたうえで、統計的な手法で平滑化しています。これが、現在私たちが使っている自動テストの基準です。
3. 主要なテスト指標：本番環境の体験を左右する 3 つの軸
周さんの考え方と私たち自身の失敗をもとに、現在 API 中継サービスを評価するときは、次の 3 つの主要な軸からなる複数指標のマトリクスを必ず確認しています。
┌── TTFT（最初のトークンまでの時間）-> ユーザーが感じる「待ち時間」
┌── レイテンシ ──┼── TPS（生成速度）-> 「タイプライター」表示の滑らかさ
│ └── P95/P99 レイテンシ -> 最悪ケースとピーク時の挙動
│
テスト指標 ──┼── 信頼性 ──┬── パース成功率 -> 偽の 200 応答や不正な形式のレスポンスを除外
│ └── Retry-to-Success -> 指数バックオフ再試行の耐障害性
│
└── ストリーム品質 ──┬── ストリーム中断率 -> 「話の途中で切れる」かどうかを判定
└── トークンジッター -> 出力中のカクつきを評価1. レイテンシ：「待ち」と「生成」を分けて見る
- TTFT (Time to First Token)：HTTP リクエストを送信してから、最初の SSE パケットを受信するまでのミリ秒数です。周さんの言う「最初のフレームまでの時間」にあたり、待っている間のユーザーの不安を直接左右します。本番環境での必須条件は TTFT < 1.5 秒です。
- TPS (Tokens per Second)：最初のトークンが出たあとの継続的な生成速度（生成トークン数 / 継続時間）です。TPS が低すぎると、フロントエンドの「タイプライター」表示が途切れ途切れになってしまいます。
- P95 / P99 レイテンシ：見栄えのよい「算術平均」に惑わされてはいけません。私たちが見るのは、95 パーセンタイルと 99 パーセンタイルの応答時間だけです。ピーク時、長いコンテキスト、チャネルの混雑時に中継サービスが見せる「本当の惨状」は、P95 / P99 の前ではすぐに正体を現します。
2. 信頼性：「見せかけの成功」を見抜く
- パース成功率 (Parse Success)：リクエストは
200を返すだけでは不十分です。返ってきたデータパケットが公式 SDK で正しくパースでき、完全な JSON 構造を含んでいなければなりません。中継サービスが独自に差し込んだエラーメッセージが混ざることは、絶対に許されません。 - 再試行成功率 (Retry-to-Success Rate)：本番環境の指数バックオフによる再試行を模擬し、中継サービスが 429 や 5xx をたまたま返したあと、3 回以内の再試行でバックアップチャネルに切り替えて素早く復旧できるかを確認します。
3. ストリーム品質：「サイレント障害」を捕まえる
- ストリーム中断率 (Stream Interruption)：公式に定められた終了マーカー
data: [DONE]を受け取る前に、TCP 接続が途中で切れたり、応答のないまま沈黙したりする割合です。 - トークンジッター (Inter-Token Jitter)：音声・映像伝送の「ネットワークジッター」の概念をそのまま借りたもので、隣り合う 2 つの SSE パケットの到着時間差の標準偏差を計算します。ジッターが高すぎる場合は、中継サービスのバックエンドのチャネル負荷が非常に不安定か、何層ものプロキシバッファ（Buffering）をこっそり重ねていることを示しています。
4. 理論と業界の参考資料：独りよがりにしない
テストデータをより客観的で説得力のあるものにするため、評価ロジックを組み立てる際には、業界で定番の運用・統計の基準をいくつか参考にしました。
1. Google SRE の 4 つのゴールデンシグナル（The Four Golden Signals）
Google の SRE（サイトリライアビリティエンジニアリング）は、4 つのゴールデンシグナルとして レイテンシ、トラフィック、エラー、飽和度（Latency、Traffic、Errors、Saturation）を挙げています。プローブの計測ポイントを設計する際には、中継サービスをまったく信頼できない外部サービスとして扱い、すべてのアラートをこの 4 つのゴールデンシグナルに沿って設定しています。
2. OpenTelemetry の観測標準と W3C の SSE 仕様
ストリーミングのレスポンスについては、OpenTelemetry の長時間接続トレースの計測規約と W3C の Server-Sent Events プロトコルを参考にし、プロトコルの下層で全過程を計測しています。TCP ハンドシェイク、TLS ネゴシエーション、ヘッダーの受信、最初のデータチャンク（First Data Chunk）の出力から、[DONE] シグナルまでをすべて記録します。
3. Wilson スコア区間（Wilson Score Interval）
中継サービスを安定性で順位付けするとき、単純な「成功数 ÷ 総試行数」をそのまま使うのは、実はかなり不公平です。たとえば、10 回テストして 10 回とも成功したサービス（成功率 100%）が、10,000 回中 9,900 回成功したサービス（成功率 99%）より統計的に信頼できるとは限りません。
小さなサンプルによる偏りを解消するため、私たちは Wilson スコア区間の下限を評価の根拠として採用しています。
Score = (p̂ + z²/(2n) - z × √(p̂(1-p̂)/n + z²/(4n²))) / (1 + z²/n)（p̂ は実際に観測された成功率、n はサンプルの総数、z は 95% 信頼水準における正規分布の分位点です）
このアルゴリズムを導入してからは、サンプルが少ない、またはテスト期間が短い中継サービスは自動的に減点されるため、ランキングの信頼性が大きく高まりました。
5. 自動監視のアーキテクチャ：プローブの仕組み
実際のアーキテクチャでは、1 台のマシンでスクリプトを回すやり方をやめ、複数のノードが連携するプローブシステムを構築しました。
[複数地域のプローブ（AWS 米国西部 / GCP 東アジア / 欧州）]
│
├──> [定期・バースト同時リクエスト生成] ──> [中継サービスの API プロキシ層] ──> [上流 API / アカウントプール]
│ │
└──< [SSE パーサーと状態機械] <─────────────────┘
│
├──> [TimescaleDB / Prometheus（マイクロ秒単位の指標を保存）]
└──> [信頼区間スコアと異常の自動原因分類エンジン]1. 分散プローブの配置
AWS の米国西部、GCP の東アジア（香港 / 東京）、欧州のノードに軽量なプローブを配置しています。複数の地域から同時にリクエストを送ることで、レイテンシやエラーの原因が中継サービス自身のプロキシノードの詰まりなのか、OpenAI / Anthropic の公式サービスの変動なのかを、一目で切り分けられます。
2. 低レイヤーの Socket 状態機械
プローブはリクエストを送ると、Socket の状態機械を起動してフレームごとに計測します。
CONNECTING：リクエストの送信時刻 t0 を記録します。FIRST_BYTE：最初の SSE チャンクを受信し、TTFT = t1 - t0 を記録します。STREAMING：チャンクの到着間隔、TPS、ジッター（Jitter）をリアルタイムで計算します。COMPLETED：データパケットが完全に終了しているか、[DONE]マーカーがあるか、JSON 構造が正しいかを検証します。
3. 異常の自動原因分類
プローブが異常なエラーを検知すると、原因分類エンジンが自動的に分類します。
- ゲートウェイの停止：
502 Bad Gateway/504 Gateway Timeoutが返る ──> 中継サービス自身の Nginx / Envoy ノードが落ちたと判定します。 - アカウントプールの枯渇：
429 Too Many Requests/401 Unauthorizedが返る ──> 中継サービスの下流の同時実行制御が不十分か、上流のキーの残高が尽きたと判定します。 - ミドルウェアの不具合：
200 OKが返るものの、転送の途中で切断されるかパースに失敗する ──> 中継サービスが独自に実装した課金 / プロンプトフィルタリングのミドルウェアが、バッファオーバーフローでクラッシュしたと判定します。
6. 選定の本音と、落とし穴を避けるためのまとめ
これから中継サービスを探すなら、次の 3 つの鉄則をぜひ覚えておいてください。
- 1 回のテストを信じない：必ず昼夜をまたいで最低 3～7 日間の連続サンプリングを行い、特に夜間ピーク（21:00～01:00）の P95 レイテンシと成功率を重点的に確認してください。
- テストでは必ずストリーミング（Stream）を有効にする：非ストリーミングのリクエストは、うわべを取り繕うのが非常に得意です。最初のトークンまでの遅延、ミドルウェアのバッファによる停滞、途中でのストリーム切断といった大きな落とし穴を、すべて覆い隠してしまいます。
- うまい話には裏がある：あり得ないほど安い中継サービスの裏側には、共有アカウントプールや質の悪いプロキシノードがあることが多く、低価格のオープンモデルを Opus や GPT-4o に偽装していることさえあります。
