AI API呼び出しの失敗は、明確に通知されることがほとんどありません。ステータスコードやエラー文字列が返される程度で、サポートチャネルに問い合わせても「リクエストIDは何ですか？」と聞かれるのが関の山です。手元にIDがなければ、調査は始まる前に停滞してしまいます。私たちは、リクエストレベルの詳細を1つのダッシュボードビューに集約することでこのギャップを埋めるべく、TokenLab Request Consoleを構築しました。モデル、キー、キャッシュ状態、課金状態、タイミング、および編集済みのペイロードプレビューが表示されます。私たちのパイプラインでは、リクエストIDを最初の検索キーとして扱います。
主なポイント
- TokenLab Request Consoleは、課金レポートではなく、TokenLab APIダッシュボード内のリクエストレベルのデバッグ用インターフェースです。
- すべてのリクエストには検索可能なIDがあります。URLに
requestIdを含めることで、特定のリクエストに直接リンクできます。 - コンソールには、最近のリクエストのルーティング、課金状態、キャッシュ状態、モデル/キーのコンテキスト、および編集済みのペイロードプレビューが表示されます。
- アクセス権は組織単位でスコープされ、ダッシュボードのメンバーシップ権限によって管理されます。チームメンバーは自身のロールで許可された範囲の内容を閲覧できます。
- 単一のインシデントのデバッグにはコンソールを使用してください。期間を指定したバッチコストの確認には、使用量エクスポートを使用してください。
TokenLab Request Consoleとは
この機能には、TokenLabダッシュボードのAPIセクション内にある /dashboard/api?tab=requestConsole からアクセスできます。APIダッシュボード自体は /dashboard/api にあります。コンソールは「リクエストが失敗したとき、最も迅速な修正は、エラーメッセージだけで推測するのではなく、その完全なコンテキストを目の前に置くことである」という前提に基づいて構築されています。
ダッシュボードの記述では、コンソールを最近のリクエストのインスペクターとして位置づけており、ルーティング、課金、リクエスト/レスポンスボディ、モデルベンダーのコンテキストをカバーしています。機能は以下のセクションに分かれています。
リストビュー： 最近のリクエストのフィルタリング可能なテーブルです。特定のIDがまだ手元にない場合は、ここから開始します。失敗した呼び出しや異常な呼び出しをスキャンします。
インスペクターパネル： リクエストを選択すると、どのモデルが処理したか、どのAPIキーが使用されたか、キャッシュにヒットしたか、最終的なステータスはどうだったかという詳細情報が表示されます。
エラーコンテキスト： リクエストが失敗した場合、その特定の呼び出しに関連付けられたエラー情報が表示されます。別のエラーログと照らし合わせる必要はありません。
ルートおよび課金状態： リクエストがどのようにルーティングされ、課金済み、保留中、返金済み、失敗のいずれであるかが表示されます。顧客から「そのエラーに対して課金されましたか？」と聞かれた際に最も重要な4つの状態です。
ペイロードプレビュー： リクエストおよびレスポンスのボディが、可能な場合に編集済みのプレビューとして表示されます。ボディ内の生の機密情報を公開することなく、形状や構造を確認できます。
モデルベンダーおよびモデルキーのコンテキスト： どのプロバイダーのどのモデルが呼び出しを処理したかを示します。1つの統合環境の背後で複数のモデルを実行しており、正しいモデルが呼び出されたかを確認する必要がある場合に便利です。
これらを利用するために、APIの上に独自のログパイプラインを構築する必要はありません。組織ごとに表示され、ダッシュボードのメンバーシップ権限でフィルタリングされるため、適切なアクセス権を持つチームメンバーは同じリクエストデータを閲覧できます。
最初に確認すべきこと
API呼び出しが失敗したときには、確認すべき自然な順序があります。リクエストが正しいエンドポイントに到達したかを確認する前に「モデルがダウンしているか」を疑うのは時間の無駄です。
5つのフィールドによるトリアージ
| チェック項目 | 確認できる内容 |
|---|---|
| Request ID | 類似した呼び出しではなく、問題の特定の呼び出しを確認していることを保証する |
| Status | 課金済み、保留中、返金済み、失敗 — コストの問題か技術的な問題かを判断する |
| Model | 実際にリクエストを処理したモデル（複数モデルをルーティングしている場合に有用） |
| Cache state | プロンプトキャッシュのヒット/ミスがコストやレイテンシに影響したかどうか |
| Key source | どのAPIキーが使用されたか（複数のキーや環境で統合を共有している場合に有用） |
まずはリクエストIDから始めてください。クライアント側のログ、サポートチケット、またはエラーレポートからIDを入手している場合は、以下のディープリンクパターンを使用します：
/dashboard/api?tab=requestConsole&requestId=%3Crequest_id>
これにより、リストビューをスキップして、対象のリクエストを直接インスペクターで開くことができます。誰かからIDを渡されて「ここで何が起きたのか」と聞かれた際に最も速い方法です。
リクエストIDがまだない場合は、コンソールのフィルターを使用して、モデル、期間、プロンプトキャッシュ状態、キーソース、ステータスで絞り込むことができます。例えば、リクエストが失敗した場合は、過去1時間以内の「失敗」ステータスでフィルタリングし、ユーザーが問い合わせている特定の呼び出しをリストからスキャンします。
ステータスフィールドの正しい読み方
4つの状態（課金済み、保留中、返金済み、失敗）は、それぞれ異なる疑問に答えます：
- 課金済み (Billed)： 呼び出しが完了し、クレジットが消費されたことを意味します。ユーザーがエラーを報告しているにもかかわらずリクエストが「課金済み」と表示されている場合は、別途フラグを立てる価値があります。これは、成功したレスポンスの後にクライアント側で失敗が発生したことを示唆しています。
- 保留中 (Pending)： リクエストが実行中、または決済待ちであることを意味します。これを早急に失敗と判断しないでください。
- 返金済み (Refunded)： TokenLabが課金を取り消したことを意味します。通常、プロバイダー側またはルーティング側の失敗に関連しています。
- 失敗 (Failed)： 呼び出しが正常に完了せず、課金もされなかったことを意味します。
エスカレーションの前にこれらが適用されるかどうかを知っておくことで、サポートとのやり取りを減らすことができます。
モデルとキャッシュ状態の確認
Claude Sonnet 5、DeepSeek V4 Pro、Gemini 3.5 Flashのようなモデルに対して共有統合を通じてリクエストを実行している場合、コンソールが期待通りのモデルを表示しているか確認してください。設定ミスのあるクライアント、古い環境変数、またはルーティングのオーバーライドにより、クライアント側に明らかなエラーが出ることなく、トラフィックが誤ったモデルに送信される可能性があります。
キャッシュ状態は、コストとレイテンシの2つの理由で重要です。期待していたヒットではなくキャッシュミスが発生している場合、通常はプロンプトのプレフィックスが（わずかであっても）変更されたことを意味します。タイムスタンプ、並べ替えられたフィールド、または余分な空白文字がないか確認してください。コンソールのキャッシュ状態フィルターを使用すると、ヒットしたリクエストとミスしたリクエストを並べて比較できます。
TokenLab Request Consoleと使用量エクスポートの連携
Request Consoleと使用量エクスポートは異なる問題を解決するため、その境界を明確にすることが役立ちます。コンソールは単一リクエストの調査（1つの呼び出し、1つのエラー、1つの課金の疑問）のために構築されており、インスペクターパネルで即座に回答が得られます。特定のリクエストが失敗し、その理由を今すぐ知る必要があるときに開くものです。
使用量エクスポートは集計レビューのために構築されています。期間ごとの支出、モデルやキーごとの内訳など、財務担当者に提出したり、月次の照合に使用したりするレポート用です。「先週DeepSeek V4 Proにいくら使ったか」を知りたい場合は、コンソールではなくエクスポートの出番です。そのワークフローについては、TokenLabダッシュボードの使用量エクスポートガイドを参照してください。
要約すると、インシデントにはコンソールを、合計値にはエクスポートを使用してください。一部のチームでは両方を順に使用しています。エクスポートで集計支出の異常を見つけ、コンソールでその原因となった特定のリクエストを深掘りするという流れです。
実践的なデバッグルーチン
アドホックなデバッグは、プレッシャーの下では推測ゲームになりがちです。反復可能なルーチンを持つことで、インシデントの長期化を防ぐことができます。
チェックリスト：リクエストが失敗したとき
- リクエストIDを取得する。 クライアントログ、エラーレスポンス、またはユーザーレポートから入手します。現時点でリクエストIDをログに記録していない場合は、今すぐ始めてください。これは最も高速な検索キーです。
- ディープリンクでコンソールを開く。
requestIdクエリパラメータを使用して、インスペクターに直接ジャンプします。 - 最初にステータスフィールドを確認する。 課金済み、保留中、返金済み、失敗のどれか。これが調査の枠組みを決定します。
- 実際にリクエストを処理したモデルを確認する。 送信したと想定していたものと比較します。
- キャッシュ状態を確認する。 期待していたヒットではなくミスが発生している場合、予期しないレイテンシやコストの原因を説明できる可能性があります。
- キーソースを確認する。 特にステージング環境と本番環境のセットアップにおいて、正しいAPIキーと環境が使用されているかを確認します。
- エラーコンテキストとルート情報を読む。 通常、ここで根本原因が明らかになります。
- 編集済みのペイロードプレビューを確認する。 リクエストの形状がクライアントが送信したものと一致しているか確認します。不正なパラメータは、他の場所よりも先にここで見つかることがよくあります。
- 必要に応じてAPIリファレンスと照らし合わせる。
https://docs.tokenlab.sh/api-reference/chat/create-completionにあるTokenLabチャット補完APIリファレンスには、期待されるリクエストとレスポンスの形状が記載されています。ペイロードがクライアント側で不正に形成されていないかを確認するために使用してください。 - 単発ではなくパターンである場合は、使用量エクスポートに切り替える。 1つの失敗したリクエストはコンソールの問題です。1時間に10回失敗した場合は、エクスポートして集計を確認する価値のあるパターンです。
この順序（ID、ステータス、モデル、キャッシュ、キー、エラー、ペイロード）に従うことで、失敗の原因を説明するフィールドを見逃すことを防げます。
FAQ
リクエストIDなしで失敗したリクエストを見つけるには？
TokenLab Request Consoleのリストビューフィルターを使用してください。モデル、期間、プロンプトキャッシュ状態、キーソース、ステータスで絞り込みます。例えば、過去1時間以内の「失敗」ステータスでフィルタリングし、ユーザーが問い合わせている呼び出しをスキャンします。見つけたらインスペクターを開き、将来のログのためにリクエストIDをコピーしてください。
クライアントがエラーを報告しているのに、リクエストが「課金済み」と表示されるのはなぜですか？
「課金済み」は、呼び出しが完了し、クレジットが消費されたことを意味します。ユーザーがエラーを報告しているにもかかわらずリクエストが「課金済み」と表示されている場合、成功したレスポンスの後にクライアント側で失敗が発生した可能性が高いです。これは失敗や返金されたリクエストとは異なる修正パスを指すため、個別にフラグを立ててください。
インスペクターでキャッシュミスは何を意味しますか？
キャッシュミスは、リクエストがプロンプトキャッシュにヒットしなかったことを意味します。これはコストとレイテンシに関わります。期待していたヒットではなくミスが発生している場合、通常はプロンプトのプレフィックスが（わずかであっても）変更されたことを意味します。タイムスタンプ、並べ替えられたフィールド、または余分な空白文字がないか確認してください。
リクエストリンクをチームメイトと共有できますか？
はい、ダッシュボードのメンバーシップ権限が許可されていれば可能です。リクエストデータは組織単位でスコープされています。ディープリンク形式 /dashboard/api?tab=requestConsole&requestId=<request_id> を使用してインスペクターを直接開いてください。チームメイトは自身のロールで許可された範囲の内容を閲覧できます。
コンソールから使用量エクスポートに切り替えるべきタイミングは？
問題が単発ではなくパターンである場合に切り替えてください。1つの失敗したリクエストはコンソールの問題です。1時間に10回失敗した場合は、エクスポートして集計を確認する価値のあるパターンです。期間ごとの支出、モデルやキーごとの内訳、月次の照合にはエクスポートを使用してください。
ソースと鮮度
- TokenLab Request Console —
/dashboard/api?tab=requestConsole— 2026-07-09確認 - TokenLab Chat Completions API reference —
https://docs.tokenlab.sh/api-reference/chat/create-completion— 2026-07-09確認 - TokenLab Dashboard Usage Exports —
/blog/tokenlab-dashboard-usage-exports— 2026-07-09確認 - TokenLab public model directory —
/models— 2026-07-09確認 - TokenLab API key dashboard —
/dashboard/api— 2026-07-09確認
参照されたモデルの例（Claude Sonnet 5、DeepSeek V4 Pro、Gemini 3.5 Flash）は、2026-09-19時点の現在のモデルSSOTを反映しています。このコンソールノートのソーススナップショットは2026-07-09に確認されたもので、ソース内の元のモデルSSOT日付は2026-07-07でした。
次のステップ
現在、クライアント側のログをgrepしたり、別の課金ダッシュボードと照らし合わせたりしてAI APIの失敗をデバッグしている場合、Request Consoleはそのループから1つのステップを削除します。コンソールは /dashboard/api?tab=requestConsole にあります。APIキーダッシュボードは tokenlab.sh/dashboard/api にあります。チャット補完のリクエスト/レスポンスの形状は https://docs.tokenlab.sh/api-reference/chat/create-completion に文書化されています。集計支出の確認には 使用量エクスポート を使用してください。モデルの価格やコンテキストウィンドウの詳細については、モデルディレクトリ を参照してください。コンソールを開き、最近の失敗したリクエストをIDで特定してください。
出典
価格確認日 2026-07-09
- TokenLab Request Console2026-07-09 時点で確認
- TokenLab Chat Completions API2026-07-09 時点で確認
- TokenLab Usage Exports2026-07-09 時点で確認
- TokenLab model directory2026-07-09 時点で確認
