OpenAIの生成APIに安全判定が同居、Moderation更新の意味｜2026年6月9日版
OpenAIは2026年6月4日、Responses APIとChat Completions APIの生成リクエストで、入力と出力のModeration結果を同じレスポンス内で受け取れるようにした。これまで別リクエストで組み込むことが多かった安全判定を、生成処理の戻り値として扱える変更だ。
ポイントは、モデルが返した文章をそのまま表示する前に、アプリ側がflagged、カテゴリ、スコアを見て処理を分けやすくなること。チャットボット、社内検索、教育向けAI、自治体・医療・金融の問い合わせ対応など、ユーザー投稿と生成文の両方を扱うサービスでは実装上の意味が大きい。
- OpenAI APIで、生成とModeration結果を1回の生成リクエストで取得できるようになった
- 対象はResponses APIとChat Completions API
- 入力だけでなく、生成された出力にもModeration結果が付く
- ChatGPT側では同日にLockdown Modeも全ログインユーザー向けに案内され、プロンプトインジェクション対策が前面に出た
今日の重要ニュース早見表
| 重要度 | 分野 | 要点 | 日本の読者への影響 |
|---|---|---|---|
| 高 | API・安全設計 | 生成リクエストに`moderation`オブジェクトを渡すと、入力と出力のModeration結果を同時に取得できる | AIアプリの表示前チェック、監査ログ、人手確認キューを組みやすくなる |
| 中 | ChatGPT・セキュリティ | Lockdown Modeが全アカウント種別とワークスペースで利用可能と案内された | 機密情報を扱うチームは、外部接続を絞る運用を選びやすくなる |
| 中 | プロダクト運用 | Memory更新も同日案内され、ChatGPTが古い記憶や矛盾した記憶を減らす方向に調整された | 個人化の利便性と、記憶内容の確認・管理をセットで見る必要がある |
生成とModerationが同じレスポンスに入る
今回の中心は、OpenAI APIの安全判定がアプリの通常フローに近づいた点だ。
何が起きたか
OpenAIのリリースノートでは、2026年6月4日付で「Responses API」と「Chat Completions API」にModerationスコアを追加したと説明されている。開発者は生成リクエストにmoderationオブジェクトを渡し、omni-moderation-latestなどのModerationモデルを指定する。
OpenAIのドキュメントでは、Responses APIの戻り値として次のような構造を読む例が示されている。
response.moderation.inputresponse.moderation.outputflaggedcategoriescategory_scores
つまり、ユーザー入力が危険かどうかだけでなく、モデルが生成した回答そのものがアプリの方針に合うかも同じ生成結果の中で確認できる。
なぜ重要か
従来の実装では、生成前に入力をModeration APIへ投げ、生成後に出力をもう一度チェックする構成が一般的だった。安全性を重視すればするほど、API呼び出し、失敗時の分岐、ログ設計、レイテンシ管理が増える。
今回の変更で、少なくともOpenAI APIを使うアプリでは次の処理をまとめやすくなる。
- 入力が危険な場合は生成結果を表示しない
- 出力だけが危険判定になった場合は人手確認に回す
- カテゴリ別スコアを監査ログに残す
- 複数候補を生成した場合、候補ごとに表示可否を分ける
ただし、OpenAIはModeration結果を「自動ブロックの絶対条件」としてではなく、アプリ側のポリシー判断に使う信号として扱うよう説明している。ここは実務上かなり重要だ。たとえば有害行為を拒否する安全な回答でも、文中に危険な内容への言及があればフラグが立つことがある。
開発者はどこを変えるべきか
導入時に見るべき場所は、モデル選定よりも処理順序だ。
表示前チェックを標準ルートに入れる
生成結果を受け取ってすぐ画面に出すアプリでは、Moderation結果を読む処理を表示直前に入れる必要がある。特に、社内文書検索や顧客対応AIのように外部データを参照するサービスでは、入力と出力の両方を見る設計が向く。
実装上は、次のような分岐を用意したい。
flagged: falseなら通常表示- 特定カテゴリが
trueならマスク、要約、再生成、人手確認のいずれかに分岐 category_scoresは監査・チューニング用に保存するが、しきい値は継続的に見直す- Moderationステップが失敗した場合は、安全側に倒すか、限定表示にする
OpenAIのドキュメントでは、Moderationに失敗した場合、スコアの代わりにエラーが入る可能性にも触れている。ここを想定しないと、「安全判定が取れないのに通常表示する」抜け道ができる。
ストリーミング時はタイミングに注意
もう一つの注意点はストリーミングだ。OpenAIの説明では、ストリーミングの場合、Moderationスコアは生成済みの全出力が利用可能になった後に届き、途中の差分には含まれない。
リアルタイム表示をしているチャットUIでは、この仕様がそのまま設計課題になる。
- 途中表示を許すのか
- 最終判定が来るまでプレースホルダーにするのか
- 危険判定時に表示済みの文をどう扱うのか
ユーザー体験だけで決めると危ない。教育、医療、金融、未成年向けサービスでは、最終判定前の部分表示を抑える判断も現実的になる。
ここがポイント: 今回の更新は「安全性が自動で完成する」変更ではない。生成結果とModeration結果を同じ場所で受け取り、アプリ側が表示・記録・再生成・人手確認を決めやすくする変更だ。
Lockdown Modeは外部接続を絞る対策
同じ6月4日の更新では、ChatGPTのLockdown Modeも目立つ。これはAPIのModerationとは別の層の対策だ。
何が制限されるか
OpenAIのヘルプによると、Lockdown Modeはプロンプトインジェクションによるデータ流出リスクを下げるため、Webや外部サービスに接続する機能を制限する。対象として挙げられているのは、ライブWebブラウジング、Deep Research、Agent Mode、Canvasのネットワークアクセス、ファイルダウンロードなどだ。
ただし、Lockdown Modeはプロンプトインジェクションそのものを消す機能ではない。OpenAIも、悪意ある指示がキャッシュされたWebコンテンツやアップロードファイルに含まれる可能性を説明している。
API側のModerationとの違い
この2つは守る場所が違う。
- APIのModeration更新: 入力と出力の内容を分類し、アプリ側の判断材料にする
- Lockdown Mode: ChatGPTが外部へ通信してデータを出す経路を狭める
社内で生成AIを使う場合、片方だけでは足りない。たとえば、チャットボットが危険な出力を出さないようにするにはModerationが必要だ。一方で、AIエージェントが外部ツールへ機密情報を送る経路を抑えるには、接続先や権限の制御が必要になる。
日本の読者が見るべきポイント
今回の更新は、国内でAI機能を組み込む企業にもそのまま関係する。
開発者
OpenAI APIを使う開発者は、Moderationを「後付けの別処理」ではなく、生成処理の戻り値として扱えるようになった。ログ、UI、再生成、アラートの設計を同じレスポンス構造に寄せられる。
まず確認したいのは次の3点だ。
- 既存アプリがResponses APIかChat Completions APIのどちらを使っているか
- 出力Moderationを表示前に読めるUI設計になっているか
category_scoresに依存したしきい値を固定しすぎていないか
企業利用者
企業側では、AI導入の稟議や運用ルールで「モデルが安全だから大丈夫」と書くだけでは弱い。今回のようなAPI機能を使い、入力、出力、外部接続、ログをどう管理するかを決める必要がある。
特に、問い合わせ対応、社内ナレッジ検索、営業支援、教育コンテンツ生成では、生成文を表示する前のチェックが業務品質に直結する。
一般ユーザー
一般ユーザーにとっては、Lockdown Modeの意味が分かりやすい。機密性の高い文書や社内情報を扱う場面では、便利な外部接続機能をあえて絞る選択肢がある。
ただし、Lockdown Modeをオンにしても、会話の学習利用やメモリ設定が自動で変わるわけではない。OpenAIのヘルプでも、データコントロールは別に管理する必要があると説明されている。
継続ウォッチ
次に見るべき論点は、機能そのものよりも運用側にある。
- OpenAI以外の主要APIが、生成結果と安全判定をどこまで同一レスポンス化するか
category_scoresを使った企業ごとのしきい値設計が、監査や法務レビューでどう扱われるか- ストリーミングUIで、最終Moderation前の途中表示をどこまで許すか
- Lockdown ModeとApps、MCP、コネクタの権限管理が、企業ワークスペースでどのように定着するか
今日のまとめ
OpenAIの6月4日更新で見えた流れは、モデル性能の競争ではなく、生成AIを実サービスに組み込むための安全レイヤーの実装競争だ。
生成APIにModeration結果が同居すれば、アプリ開発者は危険判定、監査ログ、人手確認を通常の生成フローに入れやすくなる。一方で、判定をどう使うか、エラー時にどう止めるか、ストリーミング表示をどう制御するかはアプリ側の責任として残る。
次に確認すべきは、実装例ではなく運用ルールだ。とくに企業のAI導入では、「どのカテゴリなら止めるか」「誰が例外を承認するか」「外部接続を許す業務はどれか」を、APIの設定と同じ粒度で決める必要がある。