harm-anticipation

危害の予測

危害の予測とは、AI 製品がどのように危害を引き起こす可能性があるかを、実際に引き起こす前に体系的に検討することです。事後対応の危機管理ではなく、予防的な設計です。

この作業は華やかさに欠け、簡単に省略されがちです。適切に行えば、具体的で検証可能な緩和策が生まれます。おざなりに行えば、誰も読まない文書ができあがります。

AI による危害のカテゴリー

• 直接的な危害：AI が危害をもたらす内容を出力します。危険な助言、差別的なコンテンツ、プライバシー侵害などです。
• 助長される危害：AI の出力自体は無害であっても、AI がユーザーによる有害な行為を支援します。
• 創発的な危害：個々の出力によるものではなく、規模や相互作用の影響から有害なパターンが生まれます。
• 不作為による危害：AI が行動すべきときに行動しません。危機的状況に気づかない、エスカレーションしないなどです。
• 侵食による危害：依存、スキルの低下、操作、信頼の侵食など、徐々に生じる悪影響です。

体系的な予測

次の 5 つの観点から、それぞれの危害カテゴリーを検討します。

1. 誰が危害を受ける可能性がありますか？ ユーザー、ユーザーが関わる人々、脆弱な集団、社会全体。
2. どのような危害を受ける可能性がありますか？ 身体的、精神的、経済的、評判、プライバシー、自律性。
3. 発生可能性はどのくらいですか？ よくあるユースケースか、例外的なケースか、敵対的な攻撃か。
4. 深刻度はどのくらいですか？ 不便か、苦痛か、取り返しのつかない損害か。
5. 検出可能性はどのくらいですか？ すぐに明らかになるか、微妙で遅れて現れるか。

悪用シナリオ

敵対者の視点で考えます。

• 誰かがこの機能を意図的に悪用するとしたら、どのようにしますか？
• 有害な出力を引き出す最も簡単な方法は何ですか？
• これを利用して、操作、欺瞞、強制を行うことはできますか？
• ユーザーが意図について嘘をついたらどうなりますか？
• 自動化して大規模に実行したら、どうなりますか？

意図しない結果

二次的な影響を考えます。

• 数百万人のユーザーが利用したら、どうなりますか？
• ユーザーがこれに依存することで、どのようなスキルを失いますか？
• 不公平な優位性や不利益が生まれる可能性はありますか？
• どのような力関係が変化しますか？
• 以前はできなかったことで、何ができるようになりますか？ 良い面も悪い面も考えます。

判断ルール

• 深刻度だけでなく、頻度 × 深刻度で評価します。 累積的な影響では、ほとんどの場合、よく起きる中程度の危害のほうが、まれな壊滅的危害より大きくなります。チームは慢性的に、まれな壊滅的危害を過大評価し、頻発する中程度の危害を過小評価します。
• 各危害には反証可能なテストが必要です。 「AI がユーザータイプ Y に X を行った場合、システムは Z を行うべきです。」テストを書けないなら、危害を十分に正確に定義できていません。緩和策を講じる前に、定義を見直してください。
• 機能する範囲で、最も低いレイヤーで緩和します。 出力をフィルタリングするより、プロンプトを制約するほうが効果的です。プロンプトを制約するより、機能の範囲を限定するほうが効果的です。機能の範囲を限定するより、機能を作らないほうが効果的です。
• 規模が拡大するたびに、予測をやり直します。 ユーザー数が 1k の場合と 100k の場合、さらに 10M の場合では、危害が異なります。同じチェックリストでも、規模ごとに答えは異なります。
• 脆弱なユーザーを基準に最低水準を定め、上限にはしません。 最も不利な立場のユーザーにも十分に役立つなら、ほかのユーザーにも役立ちます。平均的なユーザー向けに設計し、例外ケースには後から対処するというやり方は適切ではありません。
• 検討段階では、元に戻せる緩和策を優先します。 早い段階で変更を難しくしてしまうと、前提を見直すことをためらうようになります。

アンチパターン

• プレモーテムの形骸化：危害を予測する文書を成果物として作成し、その後二度と開かないことです。文書は成果物ですが、価値をもたらすのは実践です。
• 最悪のケースだけを考える：壊滅的な危害だけに注目することです。中程度の頻度で中程度の深刻度の危害が対処されないまま積み重なり、実際の製品の問題として表面化します。
• 敵対者だけを想定する：悪意ある行為者を予測する一方で、予期しない状況にいる善意のユーザーによる危害を見落とすことです（自殺予防相談窓口で善意から応対する人や、親切心から法的助言をする人など）。
• チェックリストによる緩和：危害を継続的な設計上の制約ではなく、チェックを付ける項目として扱うことです。ひとたびチェックを付けると、実際には対処できていなくても、その危害は「対応済み」とされます。
• 責任の外部化：「ユーザーは利用規約に同意したので、こちらは責任を問われない」という考え方です。責任を回避することと危害を減らすことは同じではありません。ユーザーは依然として被害を受け、会社が保護されるだけです。
• 単一の軸だけで考える：危害のカテゴリーを一つだけ想定し、カテゴリー間の交差で生じるものを見落とすことです。「バイアスもプライバシーも確認した」としても、バイアスとプライバシーが交差する部分には、それ自体の失敗モードがあります。
• 楽観的すぎる緩和策：ユーザーが気づく、ユーザーが報告する、AI が検知するといった前提に依存する緩和策を書くことです。緩和策に機能するセンサーが必要なら、そのセンサーが実際に機能するか監査してください。

これを使わない場合

• 日常的な UX 上の小さな不満（読み込みの遅さ、ぎこちない文言など）には、代わりに failure-taxonomy または user-satisfaction-signals を使ってください。危害の予測が対象とするのは摩擦ではなく、結果です。
• 純粋な技術的信頼性（レイテンシ、稼働時間）には、それらは SRE の領域です。危害の予測は、その上に位置する製品レベルのレイヤーです。
• レッドチーミングの代わりとしては使わないでください。予測は計画する活動であり、レッドチーミングは探りを入れる活動です。どちらか一方ではなく、両方が必要です。
• リリース時に一度きりの監査としては使わないでください。危害を発見できる予測とは、継続的に行うものであり、特に重要な変更のたびに行うものです。

関連項目

• trust-calibration — 過剰な信頼そのものが危害のカテゴリーです。信頼を適切に調整することは、最も効果的な緩和策の一つです。
• escalation-design — 多くの危害は、一人で対応しないことで緩和されます。予測によってきっかけを明らかにし、エスカレーションによってその場に対応します。
• bias-detection-design — バイアスは専用の検出手法を持つ危害のカテゴリーです。ここでバイアスのリスクを特定したら、そのスキルを使ってください。
• value-specification — 危害の予測によって制約が明らかになり、価値の仕様によって、それらが衝突したときに優先順位を決めます。
• guardrail-design — 予測によって要件が定まり、guardrail-design によってそれを実現します。

設計成果物

• 害の予測マトリクス
• 誤用シナリオのカタログ
• プレモーテム分析文書
• 製品機能のリスク重大度ヒートマップ
• 害ごとの合格／不合格テストを含む緩和策の追跡ログ

具体例 — AI メンタルヘルス支援チャットボットの害の予測マトリクスの一行：

フィールド	値
シナリオ	深刻な危機状態にあるユーザー（自殺念慮を示す表現）が助言を求める。
害のカテゴリ	不作為による害＋直接的な害。
被害を受ける人	ユーザーとその扶養家族。
発生の仕方	AI が危機状態を認識せずに一般的な助言を提供し、ユーザーが緊急の支援を求めるのを遅らせる。
発生可能性	中 — 危機状態にあるユーザーは利用者の少数ですが、やり取りの重要度は極めて高くなります。
深刻度	壊滅的で、取り返しがつきません。
検出可能性	やり取り単位では低い（明らかに不適切な出力がないため）。事後的には中程度（インシデント後のレビュー）。
緩和策	ユーザー入力に対する危機表現の分類器。検出時は、AI の応答をハードコードされた危機相談窓口の案内文に置き換え、人間のカウンセラーへ温かく引き継ぎます。反証可能なテスト：危機を示す表現として記録された30パターンを含むレッドチームのプロンプトを使用し、100％が上書きを発動しなければなりません。
緩和策の強度	出力フィルタリングより下位のレイヤー — 出力をスクラブするのではなく、応答全体を置き換えます。
再予測のタイミング	ユーザー数が10倍に増加したとき、モデルのバージョンが変わったとき、対応言語を拡大したとき。

緩和策にはテストがあります。テストはモデルを更新するたびに実行されます。これにより、害の予測は文書上のものではなく、生きた制約になります。

責任ある AI の導入に関する研究（AI の説明責任のギャップを埋めることに関する Raji らの研究、言語モデルのリスク分類に関する Weidinger らの研究）と、認知心理学におけるプレモーテム手法（先見的回顧に関する Klein の研究）を基にしています。