TokenLab Request Console：1つのダッシュボードでAI APIコールをデバッグ

AI API呼び出しの失敗は、明確に通知されることがほとんどありません。ステータスコードやエラー文字列が表示される程度で、サポートチャネルに問い合わせても「リクエストIDは何ですか？」と聞かれるのが関の山です。手元にIDがなければ、調査は始まる前に停滞してしまいます。

TokenLab Request Consoleは、そのギャップを埋めるために存在します。モデル、キー、キャッシュ状態、課金状態、タイミング、そして編集済みのペイロードプレビューといったリクエストレベルの詳細を1つのダッシュボードビューに集約します。これにより、「この呼び出しが失敗した」から「その理由はこれだ」という結論まで、3つの異なる場所からログをかき集めることなく到達できます。

この記事では、コンソールで何が表示されるのか、何かが壊れたときに最初に確認すべきこと、そしてコストレベルのレポートが必要なチーム向けに、どのように使用量エクスポートと組み合わせて活用できるかを解説します。

主なポイント

• Request Consoleは、TokenLab APIダッシュボード内のリクエストレベルのデバッグ用インターフェースであり、請求レポートではありません。
• すべてのリクエストには直接検索可能なIDがあり、URLのrequestIdを使用して特定のリクエストにディープリンクできます。
• コンソールには、最近のリクエストのルーティング、課金状態、キャッシュ状態、モデル/キーのコンテキスト、および編集済みのペイロードプレビューが表示されます。
• アクセス権は組織にスコープされ、ダッシュボードのメンバーシップ権限によって管理されます。チームメンバーは自身のロールで許可された内容のみを閲覧できます。
• 単一のインシデントのデバッグにはコンソールを使用し、期間全体にわたるバッチコストの確認には使用量エクスポートを使用してください。

Request Consoleとは

これはTokenLabダッシュボードのAPIセクション内、https://tokenlab.sh/en/dashboard/api?tab=requestConsoleからアクセスできます。その構築の前提は、「リクエストが失敗したとき、最も迅速な修正は、エラーメッセージのみに基づく推測ではなく、その完全なコンテキストを目の前に置くことから生まれる」という点です。

ダッシュボードのコピーでは、コンソールを「最近のリクエストのインスペクター」と説明しており、ルーティング、課金、リクエスト/レスポンスボディ、モデルベンダーのコンテキストをカバーしています。実際には、いくつかの作業セクションに分かれています。

リストビュー： 最近のリクエストのフィルタリング可能なテーブルです。特定のリクエストIDがまだない場合、失敗した呼び出しや異常な呼び出しをスキャンするためにここから始めます。

インスペクターパネル： リクエストを選択すると、どのモデルが処理したか、どのAPIキーが使用されたか、キャッシュがヒットしたか、最終的なステータスはどうだったかという詳細がインスペクターに表示されます。

エラーコンテキスト： リクエストが失敗した場合、コンソールはその特定の呼び出しに関連付けられたエラー情報を表示するため、別のエラーログと照らし合わせる必要はありません。

ルートおよび課金状態： リクエストがどのようにルーティングされ、課金済み、保留中、返金済み、失敗のいずれであるかを表示します。これらは、顧客から「そのエラーに対して課金されたのか？」と聞かれたときに最も重要な4つの状態です。

ペイロードプレビュー： リクエストおよびレスポンスのボディは、利用可能な場合に編集済みのプレビューとして表示されます。これにより、ボディ内の生の機密情報を公開することなく、形状や構造を確認できます。

モデルベンダーおよびモデルキーのコンテキスト： どのプロバイダーのどの特定のモデルが呼び出しを処理したかを表示します。1つの統合の背後で複数のモデルを実行しており、正しいモデルが呼び出されたことを確認する必要がある場合に役立ちます。

これらを利用するために、APIの上に独自のログパイプラインを構築する必要はありません。組織ごとに表示され、ダッシュボードのメンバーシップ権限でフィルタリングされるため、適切なアクセス権を持つチームメンバーは、あなたと同じリクエストデータを閲覧できます。

最初に確認すべきこと

API呼び出しが失敗したときには、確認すべき自然な順序があります。リクエストが正しいエンドポイントに到達したかを確認する前に「モデルがダウンしているのか？」と考えるのは時間の無駄です。

5つのフィールドによるトリアージ

確認項目	わかること
リクエストID	類似した呼び出しではなく、問題の正確な呼び出しを確認できる
ステータス	課金済み、保留中、返金済み、失敗のいずれか。コストの問題か技術的な問題かを判断できる
モデル	実際にリクエストを処理したモデル（複数モデルをルーティングしている場合に有用）
キャッシュ状態	プロンプトキャッシュのヒット/ミスがコストやレイテンシに影響したかどうか
キーソース	どのAPIキーが使用されたか。複数のキーや環境が統合を共有している場合に有用

まずはリクエストIDから始めてください。クライアント側のログ、サポートチケット、またはエラーレポートからIDを持っている場合は、以下のディープリンクパターンを使用します：

https://tokenlab.sh/en/dashboard/api?tab=requestConsole&requestId=<request_id>

これにより、リストビューをスキップして、問題のリクエストのインスペクターが直接開きます。誰かがIDを渡して「ここで何が起きたのか」と尋ねてきたときに最も速いパスです。

リクエストIDがまだない場合は、コンソールのフィルターを使用して、モデル、期間、プロンプトキャッシュ状態、キーソース、ステータスで絞り込むことができます。一般的なパターンとして、「失敗」ステータスで過去1時間以内に絞り込み、ユーザーが問い合わせている特定の呼び出しをリストからスキャンします。

ステータスフィールドの正しい読み方

4つの状態（課金済み、保留中、返金済み、失敗）は、それぞれ異なる疑問に答えます：

• 課金済み： 呼び出しが完了し、クレジットが消費されたことを意味します。ユーザーがエラーを報告しているにもかかわらずリクエストが「課金済み」と表示されている場合、成功したレスポンスの後にクライアント側で失敗が発生した可能性を示唆するため、別途フラグを立てる価値があります。
• 保留中： リクエストが処理中または決済待ちであることを意味します。早急に失敗と判断しないでください。
• 返金済み： TokenLabが課金を取り消したことを意味します。通常、プロバイダー側またはルーティング側の障害に関連しています。
• 失敗： 呼び出しが正常に完了せず、課金されなかったことを意味します。

エスカレーションの前にこれらのどれが適用されるかを知っておくことで、サポートとのやり取りを減らすことができます。

モデルとキャッシュ状態の確認

Claude Sonnet 5、DeepSeek V4 Pro、Gemini 3.5 Flashのようなモデルに対して共有統合経由でリクエストを実行している場合、コンソールが期待通りのモデルを表示しているか確認する価値があります。設定ミスのあるクライアント、古い環境変数、またはルーティングのオーバーライドにより、クライアント側に明らかなエラーを表示することなく、トラフィックが間違ったモデルに送信されることがあります。

キャッシュ状態は、コストとレイテンシの2つの理由で重要です。ヒットを期待していたのにキャッシュミスが発生した場合、通常はプロンプトのプレフィックスが（タイムスタンプ、並べ替えられたフィールド、余分な空白文字など）微妙に変更されたことを意味します。コンソールのキャッシュ状態フィルターを使用すると、ヒットしたリクエストとミスしたリクエストを並べて比較できます。

使用量エクスポートとの連携

Request Consoleと使用量エクスポートは異なる問題を解決します。間違ったツールを使わないよう、その境界線を明確にしておくことが重要です。

コンソールは単一リクエストの調査用に構築されています。1つの呼び出し、1つのエラー、1つの課金に関する疑問をインスペクターパネルで解決します。特定のリクエストが失敗し、今すぐその理由を知る必要があるときに開くものです。

使用量エクスポートは集計レビュー用に構築されています。期間全体の支出、モデルやキーごとの内訳など、財務担当者に提出したり、月次の照合に使用したりするレポートです。「先週、DeepSeek V4 Proにいくら使ったか」という疑問に答える場合は、コンソールではなくエクスポートの出番です。そのワークフローについては、TokenLabダッシュボードの使用量エクスポートガイドを参照してください。

要するに、インシデントにはコンソール、合計値にはエクスポートです。一部のチームはこれらを順番に使用します。エクスポートで集計支出の異常を発見し、コンソールでその原因となった特定のリクエストを掘り下げるという流れです。

実践的なデバッグルーチン

アドホックなデバッグは、プレッシャーの下では推測ゲームに陥ります。再現可能なルーチンを持つことで、インシデントの長期化を防ぐことができます。

チェックリスト：リクエストが失敗したとき

1. リクエストIDを取得する。 クライアントログ、エラーレスポンス、またはユーザーレポートから取得します。現在リクエストIDをログに記録していない場合は、今すぐ始めてください。最も速い検索キーになります。
2. ディープリンクでコンソールを開く。 requestIdクエリパラメータを使用して、インスペクターに直接ジャンプします。
3. 最初にステータスフィールドを確認する。 課金済み、保留中、返金済み、失敗のどれかを確認し、調査の方向性を決めます。
4. 実際にリクエストを処理したモデルを確認する。 送信したと想定していたモデルと比較します。
5. キャッシュ状態を確認する。 期待していたヒットに対してキャッシュミスが発生している場合、予期しないレイテンシやコストの原因を説明できます。
6. キーソースを確認する。 特にステージング環境と本番環境の設定において、正しいAPIキーと環境が使用されているかを確認します。
7. エラーコンテキストとルート情報を読む。 ここで実際の根本原因が明らかになることがほとんどです。
8. 編集済みのペイロードプレビューを確認する。 リクエストの形状がクライアントの送信内容と一致しているか確認します。不正なパラメータは、他の場所よりも先にここで見つかることが多いです。
9. 必要に応じてAPIリファレンスと照らし合わせる。 TokenLabのChat Completions APIリファレンスには、期待されるリクエストとレスポンスの形状が記載されており、クライアント側でペイロードが不正だったかどうかを確認するのに役立ちます。
10. 単発ではなくパターンであれば、使用量エクスポートに切り替える。 1つの失敗したリクエストはコンソールの問題です。1時間で10回失敗した場合は、エクスポートして集計を確認すべきパターンです。

ID、ステータス、モデル、キャッシュ、キー、エラー、ペイロードという順序で確認することで、失敗の原因を説明するフィールドを見逃すことを防げます。

次のステップ

現在、クライアント側のログをgrepしたり、別の課金ダッシュボードと照らし合わせたりしてAI APIの失敗をデバッグしている場合、Request Consoleはそのループからステップを1つ減らします。まずは最近の失敗したリクエストを見つけて、直接開いてみてください。

• コンソールを開き、IDでリクエストを検索する：https://tokenlab.sh/en/dashboard/api?tab=requestConsole
• tokenlab.sh/en/dashboard/apiでTokenLab APIキーを作成し、独自のコンソールやスクリプトからリクエストを開始する。
• ペイロードが不正である疑いがある場合は、Chat Completionsのリクエスト/レスポンス形状を確認する：https://docs.tokenlab.sh/api-reference/chat/create-completion
• 集計支出の確認には、コンソールではなく使用量エクスポートを使用する：https://tokenlab.sh/en/blog/tokenlab-dashboard-usage-exports
• 切り替え前にコストや機能を比較する場合は、モデルディレクトリで現在の価格とコンテキストウィンドウの詳細を確認する：https://tokenlab.sh/en/models

FAQ

TokenLab Request Consoleとは何ですか？ TokenLab APIダッシュボード内のリクエストレベルのデバッグビューです。ルーティング、課金状態、キャッシュ状態、モデルとキーのコンテキスト、および最近のリクエストの編集済みペイロードプレビューを、組織のスコープ内で表示します。

リクエストIDでリクエストを調査できますか？ はい。ディープリンク形式 /dashboard/api?tab=requestConsole&requestId=<request_id> を使用して特定のリクエストのインスペクターを直接開くか、リストビューからリクエストIDで検索してください。

コンソールは使用量エクスポートに代わるものですか？ いいえ。コンソールは個々のリクエスト（1つの失敗、1つの課金に関する疑問）を調査するためのものです。使用量エクスポートは、期間全体の集計支出を確認するためのものです。エクスポートで掘り下げるべきパターンが見つかったときに、両方を組み合わせて使用してください。

AI APIリクエストが失敗したときに最初に確認すべきことは何ですか？ リクエストIDから始めて、正しい呼び出しであることを確認し、次にステータスフィールド（課金済み、保留中、返金済み、失敗）、実際に処理したモデル、キャッシュ状態を確認してください。そこから、エラーコンテキストとペイロードプレビューを確認すれば、根本原因が明らかになるはずです。

ソースと鮮度

• TokenLab Request Console — https://tokenlab.sh/en/dashboard/api?tab=requestConsole — 2026-07-09確認
• TokenLab Chat Completions APIリファレンス — https://docs.tokenlab.sh/api-reference/chat/create-completion — 2026-07-09確認
• TokenLabダッシュボード使用量エクスポート — https://tokenlab.sh/en/blog/tokenlab-dashboard-usage-exports — 2026-07-09確認
• TokenLab公開モデルディレクトリ — https://tokenlab.sh/en/models — 2026-07-09確認

参照されているモデル例（Claude Sonnet 5、DeepSeek V4 Pro、Gemini 3.5 Flash）は、2026-07-07時点のモデルSSOTを反映しています。現在の正確な価格と可用性については、ルーティングを決定する前に上記のモデルディレクトリのリンクを確認してください。