第6章 ガバナンス / 想定学習時間:30〜40分 / 最終確認:2026年8月

6-4. 問題のある出力の緩和策(有害コンテンツ対策)

🎯 この節の学習目標

1. 「問題のある出力」を分類する

LLMの出力は確率的であり、望ましくない内容が生成されるリスクを常に持ちます。対策を考える前に、まず「何が問題になり得るか」を分類して整理します。リスクの種類によって、効く緩和策が異なるからです。

リスクの分類内容
有害・攻撃的内容暴力的・差別的・違法行為を助長する内容の生成チャットボットが侮辱的な表現や危険な行為の手順を出力する
バイアス・差別学習データに含まれる偏見が出力に反映される採用支援ツールが特定の属性を不当に低く評価する表現を生成する
誤情報(ハルシネーション)事実に基づかない内容をもっともらしく生成する存在しない製品仕様や規程条文を引用して回答する
機密漏えい本来出すべきでない機密情報・個人情報が出力に含まれるRAGの検索結果経由で他部門の機密文書の内容が回答に混入する
不適切な助言専門資格が必要な領域(医療・法律・金融)で、責任を持てない助言をする症状を聞いて診断や投薬を断定する、特定の投資を推奨する

2. 緩和の6つの層

プロンプトインジェクション対策(6-2)と同じく、有害出力対策も単一の仕組みでは完結せず、複数の層を重ねるのが原則です。設計の引き出しとして、次の6層を覚えてください。

対策主に効くリスク
① モデル選定安全性のためのアラインメント(調整)済みモデルを選ぶ。instruct/chat系のモデルは有害要求を拒否するよう訓練されている有害内容・不適切な助言の第一の砦
② システムプロンプトの安全指示役割・トピックの限定、「医療・法律の断定的助言はしない」「不明な場合は分からないと答える」等の明示不適切な助言、トピック逸脱
③ セーフティフィルタ/ガードレールモデルLlama Guard のような安全性分類モデルや、Unity AI Gateway(旧 Mosaic AI Gateway) のセーフティ(ガードレール)機能で入力・出力を検査し、有害と判定されたらブロックする有害内容・攻撃的内容(入出力の両方)
④ RAGによる根拠付け検証済みの社内文書を根拠として回答させ、「文書にない内容は答えない」と指示するハルシネーション(誤情報)の低減
⑤ human-in-the-loop高リスクな出力は自動でユーザーに出さず、人間の確認・承認を挟む(例:回答草案を担当者が編集して送信)すべてのリスクに対する最後の砦。高リスク用途で必須
⑥ フィードバックと継続的モニタリングユーザーからのフィードバック機構(役に立った/問題がある)と、推論テーブル・品質モニタリング(第5章)による問題出力の検知すり抜けた問題の発見と、対策の継続的改善

①〜③は「出力される前に防ぐ」層、④は「そもそも間違いにくくする」層、⑤⑥は「出た後に人間と運用で受け止める」層です。試験では、シナリオ(どのリスクが問題になっているか)に対して最も適切な層を選ばせる問題が想定されるため、リスクと層の対応を意識して覚えましょう。

💼 例:リスクごとの「最初に効く一手」

📝 試験のポイント

ハルシネーション対策として最も試験で問われやすいのはRAGによる根拠付け(grounding)です。「モデルが事実でない回答をする」というシナリオでは、temperature調整やモデルの大型化よりも、検証済みデータソースに基づかせるRAGが正解の軸になります。また、有害コンテンツの入出力チェックには Llama Guard のようなガードレールモデルや Unity AI Gateway のセーフティ機能が対応する、という機能名の対応付けも押さえてください。

3. 用途のリスクレベルに応じた濃淡

すべてのアプリに最大限の対策を課すと、コストとレイテンシが増え、過剰なブロック(false positive)でユーザー体験も損なわれます。用途のリスクレベルに応じて対策の濃淡を設計するのが実務的な考え方です。

用途リスクレベル対策の目安
社内の開発者向け補助ツール低:利用者が限定され、出力を鵜呑みにしない前提を作りやすい①②を基本に、⑥で問題を把握
社内の一般従業員向けQAボット中:誤情報が業務判断に影響し得る①〜④+⑥。根拠の引用元を表示して検証可能にする
一般公開のカスタマーボット高:不特定多数が入力し、出力が企業の公式見解として受け取られる①〜⑥をフル適用。トピック外の質問は拒否する設計に
医療・法律・金融の助言に関わる用途最高:誤りが人の健康・財産に直結①〜⑥に加えて⑤の人間承認を必須化。免責の明示、専門家への誘導

4. インシデント対応:記録→分析→改善のループ

どれだけ層を重ねても、問題のある出力をゼロにはできません。だからこそ「問題が起きたときに検知し、学び、仕組みを改善する」運用ループをあらかじめ設計しておきます。

  1. 記録:エンドポイントの推論テーブル(inference table)にリクエストとレスポンスを自動記録する(5-5)。ユーザーからの通報・フィードバックも収集する。
  2. 検知・原因分析:記録された入出力から問題ケースを特定し、「なぜ防げなかったか」を分析する(プロンプトの穴か、ガードレールの閾値か、ソース文書の問題か)。
  3. 改善:分析結果をシステムプロンプトの修正、ガードレール設定の調整、ソース文書の修正、評価データセットへの追加(再発防止のテスト化)に反映する。

このループは第5章の評価・モニタリングと第6章のガバナンスが交わる場所です。「問題出力への対応体制がある」こと自体が、組織としてのAIガバナンスの重要な構成要素になります。

✅ この節のまとめ

練習問題

問1. 社内規程QAボットが、実際には存在しない規程の条文を引用して回答してしまう問題が報告された。この問題への対策として最も適切なのはどれか。

  1. より大きなパラメータ数のモデルに変更する
  2. 検証済みの規程文書を検索して根拠として渡すRAG構成にし、文書にない内容は回答しないよう指示する
  3. max_tokens を増やして回答を長くする
  4. 回答の語調をより丁寧にするようプロンプトを修正する
解答と解説を見る

正解:B

事実に基づかない回答(ハルシネーション)への最も直接的な対策は、検証済みデータソースへの根拠付け(grounding)、すなわちRAGです。Aのモデル大型化はハルシネーションを多少減らすことはあっても、社内規程という固有の知識を持たない問題は解決しません。Cのmax_tokensは出力長の設定であり事実性とは無関係、Dの語調変更も同様に無関係です。

問2. 一般公開するチャットボットで、ユーザーの入力とモデルの出力の両方に対して有害コンテンツのチェックを行いたい。この目的に適した手段はどれか。

  1. Llama Guard のような安全性分類モデルや Unity AI Gateway のセーフティ機能を入出力に適用する
  2. MLflow のモデルレジストリにモデルを登録する
  3. 埋め込みモデルをより高次元のものに変更する
  4. チャンクサイズを小さくする
解答と解説を見る

正解:A

有害コンテンツの入出力チェックには、コンテンツの安全性を分類する専用のガードレールモデル(Llama Guard 等)や、エンドポイントに設定できる Unity AI Gateway のセーフティ(ガードレール)機能が対応します。Bのモデルレジストリはバージョン・権限管理の仕組みであり、コンテンツ検査は行いません。CとDはRAGの検索品質に関わる設定であり、有害コンテンツ対策ではありません。

問3. 医療機関が、患者からの問い合わせに対する回答文案を生成するシステムを導入する。誤った医療情報が患者に届くリスクを最小化する設計として最も適切なのはどれか。

  1. 生成された回答を患者へ自動送信し、事後にサンプリングでチェックする
  2. 生成された回答文案を、必ず医療従事者が確認・承認してから患者に送信するhuman-in-the-loop構成にする
  3. temperature を 0 にすれば誤情報は発生しないので、自動送信で問題ない
  4. 回答の冒頭に「これはAIの回答です」と表示すれば、内容の確認は不要である
解答と解説を見る

正解:B

誤りが健康被害に直結し得る最高リスクの用途では、人間の専門家による確認・承認(human-in-the-loop)を必須にするのが原則です。Aの事後チェックでは誤情報が届いた後になり手遅れです。Cは誤解で、temperature=0 は出力を決定的にするだけで、内容が正しいことは保証しません。Dの免責表示は透明性として有用ですが、誤情報が届くこと自体を防がないため、確認の代替にはなりません。

問4. 運用中の生成AIアプリで、問題のある出力が発生した際に原因分析と再発防止を行える体制を作りたい。最初に整備すべきものはどれか。

  1. 推論テーブルによるリクエスト・レスポンスの記録と、ユーザーからのフィードバック収集の仕組み
  2. より高速なGPUインスタンス
  3. モデルの重みの定期的なバックアップ
  4. プロンプトのA/Bテスト基盤(記録の仕組みは不要)
解答と解説を見る

正解:A

インシデント対応ループ(記録→原因分析→改善)の出発点は記録です。推論テーブルで入出力を残し、フィードバック機構で問題の通報を受け取れなければ、何が起きたかの分析自体ができません。Bは性能の話で無関係、Cは再現性の担保には役立ちますが問題出力の分析には直結しません。DのA/Bテストは改善段階では有用ですが、記録がなければ何を改善すべきかが分からないため、「最初に整備すべきもの」としては誤りです。