Moderation を別APIの前処理で終わらせる時代が終わりつつある

要点

要点まとめ

OpenAI は、有害かもしれない内容を『生成後に別工程で止める』より、生成と近い場所で判断する運用へ寄せている。
重要なのは、危険ならあとで消すことではなく、表示前、保存前、外部送信前に止めやすくなった点だ。
単純な yes/no 判定だけでは足りず、どの種類の危険か、どの程度強いかを見て、自社ポリシーや人手レビューに結びつける必要がある。
実装上は、OpenAI の主要な生成 API の返り値の中に、安全判定も一緒に受け取れるようになった。

読解

何が変わったのか

今回の guide が実務的に大きいのは、moderation を standalone classifier の説明だけで終わらせていないことです。Responses API と Chat Completions API では、生成リクエストに top-level の `moderation` を渡すと、入力側と出力側の moderation result が同じ response に含まれる構成が示されています。つまり moderation は『前段の別工程』だけでなく、『生成と一緒に返ってくる判定情報』になっています。

日本の文脈

なぜ重要か

日本の開発者にとって重要なのは、moderation が safety 用の飾りではなく、アプリの順序制御そのものに関わる点です。生成文を画面に出してから消す設計、tool を呼んでから危険性を見る設計、保存してから後で審査する設計は、小さな PoC では通っても本番で事故になります。inline moderation が使えるようになっても、どのカテゴリを止めるか、どの閾値で人手確認へ送るか、streaming UI をどう遅延させるかは自分で決める必要があります。

技術ポイント

技術的ポイント

`moderation` は生成リクエストの top-level object として渡せ、Responses API では `response.moderation.input` と `response.moderation.output` に結果が返る。
`flagged` は第一段の判断には使えるが、それだけで自動ブロックを決めると粗すぎる。`categories`、`category_scores`、`category_applied_input_types` まで見て制御順序を決める必要がある。
`omni-moderation-latest` は text と image を扱えるが audio は対象外である。音声アプリで安全判定したい場合、音声そのものを moderation していると誤解しないほうがよい。
tool calling 時の moderation は、会話 content に現れた tool-call arguments や tool outputs は見るが、tool name、tool description、tool schema、response-format schema は見ない。
streaming では moderation score が partial output delta と一緒には来ず、全文生成後に返る。即時表示 UI は順序事故を起こしやすい。

用語

英日キーワード

英語	日本語	補足
moderation	モデレーション / 有害性判定	危険な入力や出力を分類し、表示・保存・実行前の制御に使う仕組み。単体 API より制御順序の部品として重要。
flagged	フラグ判定	危険の可能性があると見なした first-pass 判定。単独では粗く、カテゴリ別制御や人手確認の起点として使う。
category_scores	カテゴリ別スコア	各危険カテゴリへのモデル信頼度。アプリ側の policy 閾値設計と定期再較正が必要になる。
category_applied_input_types	判定対象の入力種別	そのカテゴリ判定が text 由来か image 由来かを示す情報。modalities 混在時の運用判断に使う。
inline moderation	生成同梱モデレーション	生成 response の中に moderation 結果も含める運用。表示前や送信前で止める順序設計に向く。
tool-call arguments	ツール呼び出し引数	モデルが tool に渡そうとする入力。会話 content に現れる範囲は moderation 対象になりうる。

試す

試すなら

今の実装で『生成後に moderation』『表示後に moderation』『保存後に moderation』になっている箇所を洗い出す。
まずは 1 つの高リスク経路だけで inline moderation を試し、表示前、外部送信前、tool 実行前のどこで止めるかを明文化する。
`flagged` だけで終わらず、どのカテゴリは即遮断、どのカテゴリは human review、どのカテゴリは監査ログのみかを表にする。
streaming UI を使っているなら、partial token 表示と moderation 返却の時間差で危険文が先に露出しないかを replay で確認する。

注意

注意点

guide ページ上に公開日は見当たらなかった。公開時期や初出日が必要なら changelog や docs 履歴の別確認が要る。
moderation score は policy signal であり、自動的な正解ラベルではない。refusal 文でも harmful topic に触れていれば flag が立つ場合がある。
tool schema や response schema は moderation の対象外なので、危険な tool 設計や広すぎる schema を moderation に丸投げできない。
model 更新で `category_scores` の分布が変わる可能性がある。閾値運用は定期再較正が前提になる。