包括的な開発者ガイドとベストプラクティスで、すばやく開発を始められます。
リクエスト ID と問い合わせ
すべての失敗応答と SSE error イベントには request_id が含まれます。問題報告に添えていただくと、サーバー側ログから当該リクエストの完全なコンテキストを正確に特定できます。
request_id は 1 回の API リクエストに対応する識別子です。サーバーが受信時に発行し、応答に 32 桁の 16 進文字列として返します。1 リクエストにつき 1 つのみ、別リクエストとの再利用や短縮は行いません。
エラー応答から request_id を取得する
JSON モードでは、すべてのエラー応答が error オブジェクトに包まれ、request_id は固定 4 フィールドの 1 つです。message や details が汎用文のみの場合でも、request_id は必ず返却されます。
JSON モードのエラー応答例。request_id が 32 桁の 16 進文字列です。
{
"error": {
"code": "translation_failed",
"message": "Translation request could not be completed.",
"details": {},
"request_id": "0af7651916cd43dd8448eb211c80319c"
}
}SSE error イベントから request_id を取得する
SSE ストリーム中に業務エラーが発生した場合、サーバーは error イベントで残りのイベントを置換し、ストリームを終了します。payload 形式は JSON モードと同じで、request_id も同じ固定フィールドとして含まれます。SSE 接続が確立した時点で HTTP ステータスは 200 に固定されるため、request_id はイベント payload から取得する必要があります。
SSE error イベント例。全体が SSE の data フィールドの内容(可読化のため整形)。
data: {
"type": "error",
"data": {
"code": "asr_timeout",
"message": "Speech recognition request timed out.",
"details": {},
"request_id": "0af7651916cd43dd8448eb211c80319c"
}
}問題報告時に request_id を添付する
サーバー側のログは request_id をキーに参照します。1 件の request_id から当該リクエストの処理記録を完全に追跡できます。問題報告時は以下の順で情報を添えてください。
- request_id(32 桁の文字列をそのままコピーして添付)。
- エンドポイントパスと HTTP メソッド(例:POST /api/v1/translations/text)。
- リクエスト発生時刻(タイムゾーン付き、ISO 8601 推奨、例:2026-05-04T14:23:55+09:00)。
- error.code の値(例:translation_failed、asr_timeout)。
- 再現手順または最小再現例。API キーの生値は記載せず、必要に応じ sk_live_••• 等でマスクしてください。
報告テンプレート
request_id が null の場合
なぜ request_id であってアカウントや IP ではないのか
アカウント、API キーラベル、送信元 IP はいずれも同時間帯で数十〜数千件のリクエストに一致しうるため、サーバー側ログを 1 件ずつ突き合わせる必要があり、誤特定や見落としが起こります。request_id は 1 対 1 で対応する最小単位の識別子で、書架番号を直接渡すのと同等です。報告ではこれを最優先で添付してください。

