エラーコードリファレンス

エラーレスポンスには通常、HTTPステータスとレスポンス本文のプログラムエラーコードが含まれます。アプリケーションは最初にHTTPステータスを判断し、次に実際に返されたtype、code、messageを読み取ります。プロトコルや上流によってフィールドが異なる場合があります。

現象から問題を調査する場合は、先にエラーとトラブルシューティングを参照してください。このページはエラーの意味を調べるためのものであり、個別Endpointのレスポンス説明に代わるものではありません。

HTTPステータス

一般的なエラー形式

OpenAI互換インターフェースは通常、errorオブジェクトにエラー情報を格納します。

{
  "error": {
    "message": "リクエストが失敗した具体的な理由",
    "type": "invalid_request_error",
    "param": "model",
    "code": "model_not_found"
  }
}

一部のプラットフォームタスクインターフェースは、codeとmessageを直接返します。

{
  "code": "task_not_exist",
  "message": "指定したタスクIDは存在しません"
}

すべてのインターフェースが同じエラー形式を持つと仮定しないでください。解析前に対応するAPI Referenceを確認し、存在しない可能性がある任意フィールドを安全に処理してください。

非同期タスクのエラーコード

Midjourneyタスク

タスク送信成功の例：

{
  "code": 1,
  "description": "送信に成功しました",
  "result": "TASK_ID"
}

タスク待機中の例：

{
  "code": 22,
  "description": "キューで待機中です。前に2件のタスクがあります"
}

プラットフォームタスク

プラットフォームのプログラムエラーコード

クライアント側の処理原則

1. HTTPステータス、プログラムエラーコード、機密情報を除いたメッセージ、Request IDを同時に記録します。
2. 400、401、403は原因を先に修正し、同じ内容のまま自動再試行しません。
3. 404ではパスとリソースIDを確認し、非同期リソースでは所属アカウントも確認します。
4. 429、502、503、504では回数を限定したバックオフ再試行を使用できます。
5. タスク作成など副作用を伴うリクエストは、再送信前に元のリクエストが有効になっていないかを確認します。
6. エラーメッセージの全文をプログラム分岐に使用せず、安定したHTTPステータスとcodeを優先します。

追跡情報の保存方法はRequest IDを、より詳しい調査と再試行の推奨事項はエラーとトラブルシューティングを参照してください。