Skip to main content

簡潔な回答

GPTモデルがプロバイダーの利用ポリシーに違反するリクエストを受け取った場合、エラーは返されません。APIはHTTP 200で応答し、finish_reasonstopとなり、コンテンツには「I can’t help with that…」のようにモデル自身によって記述された拒絶文が含まれます。 このレスポンスにはエラーコードはなく、拒絶のカテゴリや重大度もありません。通常の回答とまったく同じ構造を持ち、通常通りに課金されます。ステータスコードとfinish_reasonだけを見ても、リクエストが拒絶されたかどうかを判別することはできません。

拒否レスポンスボディ

以下は、/v1/chat/completions からの実際の非ストリーミングの拒否レスポンスです(内容は中立的な例に置き換えられています):

カテゴリが存在しない理由

ポリシーに違反するリクエストに対して、OpenAI chat APIはエラーを返す代わりに、モデルに回答しない判断をさせます。どのカテゴリに抵触したか(例えば成人向けコンテンツ、過激な暴力、自傷行為など)は通知されず、深刻度も提供されません。 これはエラーとは異なります。エラーの場合は200以外のステータスとerrorオブジェクトが返されます。一方、拒否の場合は、単に求めていた内容ではないコンテンツを含む呼び出し成功となります。

翻訳と構造化出力

バッチ翻訳や抽出タスクでは、通常、JSON 配列などの固定フォーマットをモデルに要求します。バッチが拒絶をトリガーした場合、モデルは平文の文章を返すため、JSON としてパースすると Unrecognized token 'I'Expecting value のようなエラーで失敗します。 これは API のフォーマットの問題ではありません。 そのバッチのコンテンツが拒絶されたためです。同じバッチを変更せずに再試行しても、通常は同じ結果になります。
APIYI では、非ストリーミングリクエストに対してコンテンツセーフティの自動フェイルオーバーを有効にしています。prompt または生成された出力のいずれかで、ある公式ルートがコンテンツフィルターをトリガーした場合、リクエストは別の公式ルートで自動的に再試行されるため、お客様側での再試行は不要です。フェイルオーバー後は大半のリクエストが通常の結果を返しますが、モデル自体によって拒絶されるリクエストもごくわずかに存在し、それが本ページで説明しているケースです。

検知と対処の方法

1

まず出力フォーマットを検証する

JSONを要求した場合はJSONとしてパースし、固定数の項目を要求した場合は項目数を確認します。フォーマットが一致しない場合は、その呼び出しを「結果なし」として扱い、そのコンテンツを出力として使用しないでください。
2

次に拒否であるか確認する

フォーマットが一致しない場合は、コンテンツがI can'tSorryなどで始まる短い文であるかどうかを確認します。そうである場合、モデルがフォーマットから外れたというよりは、ほぼ確実に拒否です。
3

変更を加えずに再試行しない

同じコンテンツを変更せずに再試行しても、ほとんどの場合同じ拒否が発生し、試行ごとに課金されます。
4

バッチを分割して特定の項目を特定する

失敗したバッチをより小さなバッチに分割して再送信し、どの項目が拒否を引き起こしているかを特定します。通常、残りの項目は正常に完了します。拒否を引き起こした項目については、言い回しを調整して再試行してください。
5

失敗事例をアーカイブし、モデルの切り替えを判断する

失敗事例(入力、リクエスト時刻、リクエストID、返却されたコンテンツ)の社内アーカイブを保持し、どのようなコンテンツに拒否が集中しているかを確認した上で、別のモデルでそのコンテンツを再試行するかどうかを検討します。
「失敗事例のアーカイブ → 分析 → 別のモデルでの再試行」を標準プロセスにすることをお勧めします。拒否は特定の種類のコンテンツに集中する傾向があるため、アーカイブを作成することでパターンを把握しやすくなります。これにより、繰り返しの手動調査の手間が省け、同じコンテンツに対して何度も課金されるのを防ぐことができます。
以下は最小限の例です。JSONを検証し、一致しないものをローカルの失敗ログに記録します。

ストリーミングリクエスト

ストリーミングレスポンスが開始されると、別のルートへ切り替えることはできなくなるため、コンテンツセーフティの自動フェイルオーバーは非ストリーミングリクエストにのみ適用されます。ストリーミングでは、以下が発生する可能性があります。
  • 最後のイベントで finish_reasoncontent_filter に設定された短い拒絶応答、または
  • コンテンツの一部がすでに配信され、finish_reason: "content_filter" で終了するケース。
1 tokenずつ表示する必要がないバッチ翻訳などのタスクでは、非ストリーミング呼び出しをお勧めします。

よくある質問

はい。拒絶は呼び出しとしては成功しており、実際の入力および出力 tokens に基づいて課金されるため、同じコンテンツで繰り返し再試行することは避けてください。
いいえ。拒絶はプロバイダーの利用規約に基づいてモデルによって判断されます。APIYI 側で無効にしたり、その厳格さを調整したりすることはできません。
モデルの判断にはある程度のランダム性があり、異なる公式ルート間でもフィルタリングがわずかに異なるため、ボーダーライン上のコンテンツはある時は通過し、別の時には拒絶されることがあります。利用規約に明確に違反しているコンテンツは、一貫して拒絶されます。
OpenAI の chat API はカテゴリを返しません。ワークフローでカテゴリが必要な場合は、リクエストを送信する前にご自身でコンテンツを分類するか、アーカイブされた失敗事例を手動で仕分けてください。

関連ドキュメント

レスポンス処理

ストリーミングおよび非ストリーミングレスポンスに対応する統一的なパース手法

コンテンツの安全性とコンプライアンスはどのように確保されていますか?

プラットフォームのコンテンツ安全性とコンプライアンスポリシー