監視とトラブルシュート
リクエストが失敗したときに、原因となった認証情報と処理段階を特定します。
4つの監視メニュー§
Modern管理画面の監視メニューは4つに分かれ、それぞれ役割があります：
- 健康——現在どの認証情報が使用可能で、どれに問題があるか
- 使用量とコスト——どれだけのトークンを使ったか、いくらかかったか
- リクエストログ——各リクエストの詳細な記録
- ルーティングチェック—— 指定された条件で、ゲートウェイがどのように選択するかを見る
健康§
「健全性」タブには現在の各Group、各認証情報の利用可能な状態と、注意が必要な問題の一覧が表示されます。
認証情報のステータスの意味：
- 使用可能——通常のローテーションに参加
- クールダウン中 — アップストリームのレート制限またはエラー後に一時的にスキップされ、クールダウン終了時に自動復帰します。
- ブラックリスト済み — 連続失敗がしきい値を超えると自動的に除外されます。APIキーのGroupは検証間隔に従って確認され、成功すると復帰します。サブスクリプション認証情報はこの自動復帰経路を使用しません。
- 停用済み——手動でオフにしたもので、ローテーションには参加しません
クールダウンとブラックリストの条件、復帰方法はスケジューリングの仕組みを参照してください。
問題のある認証情報は1つの一覧にまとまるため、Groupを1つずつ確認する必要はありません。
リクエストログ§
すべてのリクエストが記録され、時刻、Group、モデル、状態で絞り込めます。1件を開くと、使用した認証情報、プロトコル変換、リトライ回数、アップストリーム応答を確認できます。
トラブルシューティングに最も役立つフィールド：
- ルーティングID — このリクエストが実際に通ったGroupと認証情報を確認できます。
- プロトコル変換 — クライアントとアップストリームのプロトコルが異なる場合、ここで変換過程を確認できます。
- エラー情報——秘匿化・長さ制限された要約を、エラーコード、発生元、範囲、該当ルールと合わせて判断します
項目とエラーコードは エラーと復旧、ログ保持日数は 実行時設定 を参照してください。
モデルの整合性は、上流に送ったモデルと上流の応答で報告されたモデルを、クライアント向けの別名に書き換える前に比較します。対話応答がモデルを報告しない場合は unknown です。同じ試行内で一度不一致があれば、後の一致値では上書きされません。ルーティング、再試行、料金計算は変わらず、過去のログも書き換えられません。
ストリーミング・非ストリーミングのチャットは「出力 token ÷ リクエスト総時間」で平均出力速度を表示します。待機、再試行、認証情報の切り替え、推論時間を含み、純粋な生成速度ではありません。使用量や所要時間が取得できない場合は表示しません。
ストリーミングの初回応答は、上流の最初の空でない SSE data 行または WebSocket メッセージを受信した時点です。メタデータのみの場合もあり、最初の文字が表示される時間とは異なります。0 または欠損値は画面で利用不可と表示されます。
クライアント IP で完全一致検索できます。一覧の IP 列は既定で非表示ですが、列設定から有効にできます。過去のログには IP を補完せず、マスキング付きエクスポートではアドレスを匿名化します。
Classic と Modern のリクエストログ・使用量ページでは、更新操作の横で自動更新を選べます。既定はオフで、5・10・30・60 秒から選択します。両ページ・両画面で現在のブラウザーの設定を共有し、移動や再読み込み後も保持します。端末間の設定共有ではありません。
自動更新はフィルター、ページ位置、スクロール位置、開いている詳細、グラフの選択を保持し、相対時間範囲はリクエストごとに進みます。バックグラウンドのタブでは停止し、表示時に再開します。処理中はその回をスキップします。失敗時は直前の結果と古いデータの警告を保持し、最大 5 分間隔で再試行します。
アクセスキーの「リクエスト内容を記録」が有効な場合、個別ログの詳細で元の本文を閲覧・コピーできます。記録対象はデコード済みの受信内容で、パラメーター上書き・リクエスト秘匿化・プロトコル変換より前です。Responses WebSocket は各ターンのリクエストフレームを記録します。上流へのリクエスト、上流の応答、ヘッダーは記録しません。
有効な UTF-8 JSON は 256 KiB 以下ならそのまま保存します。超える場合は文字列値だけを切り詰め、JSON 構造を保持します。非 JSON、切り詰め後も大きすぎる本文、書き込み待ち容量を超えた本文は、状態と元のサイズだけを保存します。過去のログや記録がオフだったリクエストは後から補完しません。
管理者と、そのリクエストを送信したキーで認証されたセッションは記録済みの元の本文を閲覧できます。Modern の秘匿化ログ出力は本文を除外しますが、詳細からコピーした内容が秘匿化されるわけではありません。共有前に確認してください。本文はログの保持期間に従って削除され、記録を無効にしても履歴は消去されません。
ルーティングチェック§
これはトラブルシューティングの最速のエントリーポイントです。AccessKeyとモデル名を入力すると、ルーティング可否、候補Group、利用可能な認証情報数、または失敗理由を確認できます。
典型的な用途：
- 「モデルが存在しないと表示される理由」 — チェッカーで、このキーが利用できるGroupにモデルが公開されているか確認できます。
- 「利用可能な認証情報がない理由」 — 候補Groupごとに認証情報の総数と現在利用可能数を確認します。
- 「新しいGroupを追加したが反映されていない」——AccessKeyがそのGroupに付与されているか確認
実際のリクエストを送らずに、候補Groupと利用可能な認証情報を確認できます。
使用量とコスト§
リクエスト量、成否傾向、キャッシュヒット率、トークン分類、コスト見積もりを表示し、Group、モデル、AccessKeyなどの軸で分布を確認できます。
トークン分類はコストに直接影響します：
- 非キャッシュ入力——通常課金される入力トークン
- キャッシュ読み取り——キャッシュにヒットした部分、通常はキャッシュ非対応よりもはるかに安い
- キャッシュ書き込み——キャッシュ作成のコスト。サービスプロバイダによっては別途課金されることがある
- 出力——モデルが生成したトークンで、通常最も高価です
そのためキャッシュヒット率が高いのは良いことです。同じリクエスト量でも、キャッシュヒット率が上がればコストは大きく下がります。
コストはアップストリームのトークン使用量、モデル価格、GroupとAccessKeyの価格倍率から見積もり、運用分析とキャパシティ計画に使います。この値はプロバイダーの請求額とは一致せず、財務照合にも使えません。既知の差異には、アップストリームが使用量を返さないリクエスト、価格データのないモデル、過去に遡って適用されない価格変更があります。
データの完全性§
「使用量」タブには「品質」指標があります。これはサービス品質ではなく、統計データそのものがどれだけ完全かを測定します：
| 指標 | 意味 | 影響 |
|---|---|---|
| 使用量データなし | アップストリームがトークン使用量を返しません | これらのリクエストは統計とコストに含まれません |
| 使用量の一部欠落 | 一部の項目しか返されていません | コストが実際よりも低めです。 |
| コスト未設定 | 使用量はあるが、このモデルには価格データがありません | コストには計上されず、使用量は引き続き集計されます |
| 一部の料金設定 | 一部のトークン種別にしか価格がありません | コストが低すぎます。 |
これらの値が大きい場合はコスト見積もりの信頼性が低下しています。「未設定」は通常、モデル価格が未同期であることを示します。モデル管理を参照してください。
トラブルシューティング順序§
問題が起きたら次の順序で確認します。通常は2～3手順で原因を特定できます：
- まず健全性を確認します——認証情報がすべてクールダウン中かブラックリストか？ その場合は問題はアップストリームまたはキー自体にあります
- ルーティングチェックを再度行います——候補Groupと利用可能な認証情報があるかを確認します。通らない場合は直接の原因を確認できます。
- 最後にリクエストログを開く——失敗したリクエストのエラーコードと秘匿化された要約を確認します
特定の認証情報が失効していると疑われる場合は、より直接的な方法があります。Group の認証情報ページでその認証情報に 接続テスト を実行すれば、実際のリクエストで即座に確認できます。詳しくは Groupとチャネル を参照してください。
健全性が正常で、ルート検査にも候補 Group と利用可能な認証情報があるのに失敗する場合は、クォータ、モデル停止、地域制限などアップストリーム側の可能性があります。ログのエラーコードと安全な要約が次の手掛かりになります。