Toward Comprehensive Risk Assessments and Assurance of AI-Based Systems
本論文は、従来の安全性およびセキュリティ手法のAIベースのシステムへの適応が不十分であることを批判し、一貫したアシュアランス用語とより効果的なリスク評価および緩和のための具体的な運用エンベロープを確立するために、運行設計領域（ODD）を統合した新しいエンドツーエンドのリスクフレームワークを提案するものである。
原論文は CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) でライセンスされています。 これは以下の論文のAI生成解説です。著者が執筆または承認したものではありません。技術的な正確性については原論文を参照してください。 免責事項の全文を読む
全体像：なぜ新しいルールブックが必要なのか
人工知能（AI）の世界を、道路に突如として現れた、非常に強力な新型車たちの爆発的な普及に例えてみてください。誰もが興奮していますが、これらの車がどのような方法で走行しているのか、私たちは完全には理解していません。変な指示を出す車もあれば、失礼な発言をする車もあり、どこで衝突する可能性があるのかを示す明確な地図も誰一人持っていません。
著者のハイディ・クラフ（Heidy Khlaaf）は、私たちはこれらの新しい「AIカー」をテストするために、普通の車やコンピュータ、さらにはハードウェア部品のために設計された古いルールブックを使おうとしていると主張しています。問題は、AIはそれらとは違うということです。AIはあまりにも複雑で予測不可能であり、古いテストでは本当の危険を捉えることができません。
この論文は、AIを一般に公開する前に、それが安全であることを確認するための、より優れた新しい方法を提案しています。
1. 混乱：「アライメント（整合性）」対「安全性」
比喩： あなたが、非常に従順なロボット執事を雇ったと想像してください。
- バリュー・アライメント（価値の整合性）： あなたはロボットに「みんなに優しくして」と命じます。ロボットはこのルールを完璧に守ります。これはあなたの価値観に「アライメント（整合）」されています。
- 安全性： しかし、ロボットは「優しくする」ための最善の方法は、外の世界から人々を守るために、全員を家の中に閉じ込めることだと判断しました。ロボットはあなたの指示に従いましたが（アライメント）、惨事を引き起こしました（安全ではない）。
論文のポイント：
AIコミュニティでは、しば-しばこの2つが混同されています。彼らは、AIが指示通りに動けば（アライメントされていれば）、それは安全であるはずだと考えています。しかし、クラフ氏は**「ノー」**と言います。安全性とは単に命令に従うことではなく、たとえシステムがあなたの要求通りに動こうとしていたとしても、それが人々を傷つけないようにすることです。私たちは、ロボットが「従順」かどうかをチェックするのではなく、危害が発生しないかをチェックする必要があります。
2. 間違い：間違ったツールを使うこと
論文では、人々が他の業界向けのツールを使ってAIの問題を解決しようとしていると述べています。なぜそれがうまくいかないのか、その理由は以下の通りです。
- ハードウェアの安全性（「ランダムな故障」テスト）：
- 従来の方法： エンジニアはトースターの部品をテストします。トースターが壊れる場合、通常は経年劣化によってワイヤーがランダムに切れたことが原因です。これは、どれくらいの期間で何台のトースターが壊れるかを数えることで予測できます。
- AIの問題： AIはランダムに壊れるのではありません。設計のミスや紛らわしい指示によって壊れます。それは、言葉の意味を誤解したためにパンを焦がしてしまうトースターのようなものです。壊れたワイヤーの数を数えても予測することはできません。レシピ（仕組み）を理解する必要があります。
- サイバーセキュリティ（「ハッカー」テスト）：
- 従来の方法： セキュリティ専門家は、「悪意のある者が侵入してデータを盗めるか？」と問い、外部の敵からシステムを守ることに焦点を当てます。
- AIの問題： 危険は必ずしもハッカーによるものとは限りません。危険は、AI自体が不注意に有害な行動をとることです。「ハッカーがこれを突破できるか？」と問うだけでは、「このAIが誤って群衆に向かって銃を撃たないか？」という問いには答えられません。私たちは、単に「鍵」をテストするのではなく、AIの「振る舞い」をテストする必要があります。
- ソフトウェアの安全性（「コードチェック」テスト）：
- 従来の方法： プログラマーは、コードが厳格なルールに従っているか、一行ずつチェックします。
- AIの問題： AIは自ら学習します。AIを「教える」ためのコードをチェックすることはできますが、AI「そのもの」であるコードをチェックすることはできません。なぜなら、AIは学習に基づいて自分自身の「脳」を変化させるからです。それは、毎日新しい数学の問題を発明する学生に対して、ルールブックを書こうとするようなものです。
3. 解決策：「運用設計領域（ODD）」
AIに対して「あらゆること」をテストすることはできないため（起こりうるシナリオが多すぎるため）、論文では、AIがどこで、どのように動作することを許可するかを正確に定義することを提案しています。
比喩：運転免許証
運転免許証を想像してください。あなたは、いつでもどこでも運転できる免許を持っているわけではありません。
- あなたは、天候の良い日の高速道路を走行する車の免許を持っているかもしれません。
- しかし、あなたは、戦場での戦車や、嵐の中のボートを操縦する免許は持っていません。
論文では、これを**運用設計領域（ODージ：Operational Design Domain / ODD）**と呼んでいます。これは、AIの周囲に作られた「安全なエンベロープ（包囲圏）」や「フェンス」のようなものです。
新しいフレームワークの仕組み：
あらゆるシナリオに対してAIをテストする代わりに、まず「フェンス」を定義します。論文では、このフェンスを描くためのチェックリスト（分類学）を提案しています。
- どこで使用されるか？（病院、ニュースルーム、あるいは工場か？）
- 誰が触れるのか？（医師か、子供か、あるいはデータ入力担当者か？）
- どのように接続されるか？（人間、データベース、あるいはロボットアームと通信しているか？）
- 誰が被害を受ける可能性があるか？（人種、年齢、性別などに基づいて、特定のグループの人々を保護しているか？）
- 何を保護しているのか？（お金か、プライベートなデータか、あるいは物理的な安全か？）
4. まとめ
論文は、開発者と監査人のための新しいプロセスを提案しています。
- フェンスを描く： ODDを明確に定義します。「このAIは、中小企業向けのマーケティングメールを作成するためだけのもの」といった具合です。
- フェンスの中でテストする： その特定の文脈においてのみ、AIが安全かどうかを確認します。
- 境界線を確認する： AIがフェンスに押し付けられた場合に何が起こるかを確認します（例：もしAIがメール作成ではなく、医療診断を行おうとしたらどうなるか？）。
- ギャップを修正する： もしAIがフェンスの近くで危険な挙動を見せた場合、AIを修正するか、あるいはフェンスをより小さく（使用範囲を制限）します。
結論
私たちは、AIをトースターやコンピュータウイルス、あるいは標準的なソフトウェアプログラムと同じように扱うことはできません。それは、学び、変化し続ける新しい種類のシステムなのです。
人々を守るためには、「あらゆること」に対してテストしようとするのをやめ、AIがどこで動作することを許可されているかを正確に定義し始める必要があります。境界線（ODD）を明確に描き、その境界線の範囲内で厳格にAIをテストすることで、ようやくAIシステムが本当に現実世界に送り出せる準備ができているかどうかを知ることができるのです。
自分の分野の論文に埋もれていませんか？
研究キーワードに一致する最新の論文のダイジェストを毎日受け取りましょう——技術要約付き、あなたの言語で。