AI Safetyとは何か：AIの危害を減らすための技術・評価・運用の総称

用語：AI Safety

一言でいうと：AI Safetyは、AIの誤作動・誤用・悪用・予期しない挙動による危害のリスクを、設計・評価・運用で減らす広い取り組みです。

分類：AIの評価・安全・倫理・ガバナンス

AI Safety（AI安全性）は、AIシステムが人や組織、社会、環境などに不合理な危害を与えるリスクを減らし、安全に設計・評価・運用するための研究と実務の広い領域です。自動運転や医療AIのような従来の安全工学に近い課題から、生成AIの有害出力、サイバー悪用、エージェントの自律行動、強力な汎用AIの将来リスクまで、対象範囲は文脈によって大きく変わります。^[1]^[4]

一言でいうと

AI Safetyは、「AIが何をできるか」だけでなく、「誤作動・誤用・予期しない利用・悪用・能力拡大によって、どんな害が起こり得るかを把握し、許容できる水準までリスクを下げる」ための取り組みです。

まず範囲を確認する

AI Safetyという語には単一の世界共通定義があるわけではありません。機械学習研究では、分布外データ、ロバスト性、異常検知、検証可能性、人間介入などを含む技術領域として使われてきました。近年は、一般目的AIやフロンティアAIの高度な能力がもたらすサイバー、バイオ、欺瞞、自律行動、制御喪失などのリスクを指す文脈も増えています。

2026年のInternational AI Safety Reportは、一般目的AIの能力とリスクに関する科学的知見を国際的に整理する枠組みとして、この語が非常に広い問題群を含むことを示しています。したがって「AI Safetyに取り組んでいる」という記述だけでは、何を対象にしているかは分かりません。

NISTで見る「安全」

NIST AI RMFでは、trustworthy AIの特性の一つとしてsafeを挙げています。安全なAIとは、定義された条件下で人命、健康、財産、環境を危険な状態に導かないことを中心に考え、責任ある設計・開発・導入、リスク情報の提供、実証的な事故情報、監視、人間介入、停止・変更可能性などを重視します。^[2]^[3]

ここから分かるのは、Safetyがモデル単体の性質ではないことです。同じモデルでも、医療診断の補助に使うのか、娯楽チャットに使うのか、外部ツールを操作できるエージェントとして使うのかで必要な安全策が変わります。

事故、誤用、悪用を分ける

安全評価では、少なくとも三つの経路を分けて考えると理解しやすくなります。一つ目は、意図せず誤作動するケースです。誤認識、ハルシネーション、脆弱な判断などが含まれます。二つ目は、利用者が想定外の使い方をして害が生じるケースです。三つ目は、悪意ある利用者がサイバー攻撃や詐欺などにAIを使うケースです。

対策も異なります。誤作動には性能評価、冗長化、監視、人間レビューが効くかもしれません。悪用にはアクセス制御、危険能力評価、利用ポリシー、ログ、検知、インシデント対応が必要です。すべてを「モデルを安全にする」で一括りにすると、責任分担が曖昧になります。

AI Alignmentとの違い

AI Alignmentは、AIの挙動や目的が人間の意図・価値・規範と合うようにする問題です。これはAI Safetyの重要な一部になり得ますが、Safety全体と同義ではありません。

たとえば、意図通りに動くロボットでもセンサー故障で事故を起こすかもしれません。これはalignmentというより安全工学やロバスト性の問題です。逆に、非常に高性能で故障しないAIでも、人間の意図を誤解して危険な目標を追えばalignment上の問題です。実務では両方を扱う必要があります。

AI Securityとの違い

Securityは、不正アクセス、データ改ざん、モデル盗難、敵対的攻撃など、攻撃者を想定した保護を強く扱います。Safetyはより広く、攻撃者がいなくても起こる事故や危険状態を含みます。ただし生成AIでは、prompt injectionやデータpoisoningのようにSecurityとSafetyが密接に重なる領域があります。

「安全性テスト」と書かれていたら、事故型の失敗だけか、攻撃者を想定したred teamingまで含むかを確認する必要があります。

どう評価するのか

AI Safety Evaluationでは、対象リスクを具体的な失敗モードに分解します。生成AIなら、有害な指示への応答、危険知識の提供、誤情報、過剰な自信、欺瞞的挙動、ツールの誤操作などです。ロボットなら、衝突、停止性能、環境変化への耐性、センサー故障時の挙動などが中心になります。

評価はベンチマークだけでなく、red teaming、シミュレーション、実環境テスト、継続監視、インシデント分析を組み合わせます。稀だが重大な事象では平均スコアが役に立たない場合があり、最悪ケースや発生確率、曝露量を考える必要があります。

「安全性能」と「安全な運用」は違う

モデルが高い安全評価スコアを持っていても、アクセス権限を過剰に与えれば危険になります。逆に、モデル能力に弱点があっても、サンドボックス、人間承認、権限制限、レート制限、監視を組み合わせればリスクを下げられる場合があります。

このためAI Safetyは、モデルの事前学習や安全チューニングだけではなく、システム設計、デプロイ、運用、ガバナンスまで含むライフサイクル問題として読むのが適切です。

実例：AIエージェント

社内AIエージェントにメール送信とファイル削除の権限を与えるとします。モデル単体の有害発言率が低くても、誤った指示解釈で重要ファイルを削除したり、外部文書に埋め込まれたprompt injectionに従ったりする可能性があります。

安全設計では、削除は確認必須、外部コンテンツの命令は低権限、操作ログを保存、重要操作はロールバック可能、異常時には停止できる、といったシステム側の対策が必要です。これは「モデルに危険なことを言わせない」だけでは解決できません。

元の文脈に戻ったときの読み方

企業が「最先端のAI Safety」を掲げている場合、まず対象リスクを探します。有害コンテンツだけか、サイバーやバイオの危険能力、エージェント行動、データ保護まで含むか。次に、評価だけなのか、実際のリリース判断に結びつく基準があるかを見ます。

論文で「safe model」と書かれていても、特定ベンチマークで良いだけかもしれません。どの環境条件、どの利用者、どの失敗モードを対象にしたかを確認し、範囲外の安全性を推論しないことが重要です。

リスクは「能力×曝露×制御」で考える

同じモデル能力でも、危険な機能にアクセスできなければリスクは小さくできます。逆に、中程度の能力でも数百万人へ自動配信され、外部システムを操作し、監視がなければ影響は大きくなります。AI Safetyを読むときは、モデル能力だけでなく、誰が使えるか、どんな権限があるか、どれくらいの規模で展開されるかを見ます。

この観点は「ベンチマーク上の危険能力が低いから安全」「危険能力が少しあるから即危険」といった二値判断を避ける助けになります。安全対策は能力を下げるだけでなく、アクセス制御、権限分離、監視、レート制限、サンドボックスなど曝露を減らす方法もあります。

評価の限界と残余リスク

安全ベンチマークは既知の失敗を測るには有用ですが、未知の失敗を完全には捕捉できません。AIシステムは組み合わせ方で新しい挙動を示すため、モデル単体で合格しても、ツール接続後に新たなリスクが生まれることがあります。長時間タスクや複数エージェントでは、短いテストでは見えない累積的な失敗もあります。

そのためSafetyは「試験に合格したので完了」ではなく、リリース後の監視、インシデント共有、再評価、ロールバックを含む継続活動になります。安全指標には不確実性があること自体を認識し、重大リスクでは安全余裕を設ける考え方が必要です。

利益とのバランス

安全対策は厳しいほど良いわけではありません。過剰な拒否は医療情報へのアクセスや創作活動を妨げ、偏った安全フィルターは特定集団に不利益を与えることがあります。Safety Evaluationでは、害を減らす指標だけでなく、有用性、公平性、アクセス性とのトレードオフを確認することが重要です。

Safety Caseという考え方

高リスク工学では、安全であるという主張を、証拠と論理で構造化するSafety Caseの考え方があります。AIでも、単一ベンチマークではなく、「どの危害を想定し、どの管理策があり、どの評価結果で十分と判断したか」を証拠としてまとめる発想が有用です。

たとえば医療AIなら、性能試験、サブグループ評価、故障時挙動、臨床ワークフロー、人間監督、サイバー対策、更新管理を別々に検証します。各証拠がどのリスクを減らすかを紐付けることで、「安全性スコア一つ」で議論するより透明になります。

Capability EvaluationとSafety Evaluationの関係

危険な能力がどれだけあるかを測るCapability Evaluationは、Safetyの一部として重要です。しかし「できる」ことと「実際に害を起こす」ことの間には、意図、アクセス、権限、利用頻度などがあります。能力評価だけで実害確率を直接推定しないことが重要です。

反対に、現時点で能力が低くても、モデル更新で急に変わる可能性があります。能力閾値をトリガーに追加の安全評価やアクセス制限を実施する設計が使われます。

Human Factors

AI Safetyは人間の使い方にも左右されます。AIの自信ある口調で過信が起こる、警告が多すぎて無視される、承認フローが形骸化する、といったhuman factorsは技術評価だけでは見えません。Automation Biasや過度な依存は、システム全体の安全性を左右します。

UIで不確実性をどう表示するか、重要判断で人間に何を確認させるか、警告疲れをどう避けるかもSafety設計です。

インシデントから学ぶ

事前評価で想定できなかった失敗は、運用後のインシデントから学ぶ必要があります。重要なのは個別事故を隠すことではなく、原因分析、影響範囲の把握、是正、再発防止、必要な情報共有につなげることです。

成熟したSafety運用では、near missも記録します。重大事故にならなかった失敗の兆候を蓄積すると、将来のリスク管理に役立ちます。これはAI Governanceとも密接に接続します。

リスク評価の基本形

安全リスクを整理するときは、hazard（危険源）、exposure（人や資産がさらされる条件）、consequence（起こり得る害）、control（抑制策）を分けると考えやすくなります。AIでは「危険能力がある」こと自体をhazardとし、それが実際に外部ツールや重要データへ接続されるかをexposureとして考えられます。

この分解により、モデル能力の議論と配備条件の議論を混同しにくくなります。同じモデルでも、研究サンドボックスと本番の自律エージェントではリスクが違います。

Safety Evaluationの独立性

開発チーム自身のテストだけでは、期待する挙動に寄った評価になりやすいため、独立したred teamや外部評価が重要になる場合があります。特に重大なリスクでは、評価手法や閾値を事前に定め、結果を見てから都合よく基準を変えないことが重要です。

ただし第三者評価も万能ではありません。評価者がアクセスできるモデル機能、システム設定、ログが限定されていれば、本番リスクを完全には再現できません。独立性と環境忠実度の両方を確認します。

Defense in Depthで一つの防御に依存しない

AI Safetyでは、単一の安全フィルターがすべての失敗を止めると考えない方が安全です。モデルの学習段階で危険行動を減らし、入力・出力フィルターで既知パターンを検出し、ツール権限を最小化し、高影響操作には人間承認を置き、ログ監視で異常を検知する、といった複数層を組み合わせます。ある層を突破されても次の層で被害を抑える設計です。

層が増えるほど安全とは限りません。複数の仕組みが同じ弱点に依存していれば共通原因で同時に失敗します。また、複雑すぎる統制は運用者が迂回する誘因になります。各防御が何を防ぎ、どの失敗を残すのかを明示し、独立性と運用可能性を確認します。

インシデントから評価項目を更新する

運用後に事故やnear missが起きたら、個別対応で終わらせず、再現テストへ変換することが重要です。たとえば特定のprompt injectionで機密情報へアクセスしかけたなら、そのパターンを回帰テストへ追加し、類似の攻撃にも一般化して点検します。実世界の失敗を評価セットへ戻すことで、Safety Evaluationは時間とともに実態へ近づきます。

同時に、事故件数だけを安全性の尺度にしない注意も必要です。利用者数が増えれば件数は増えますし、報告制度が改善すると一時的に件数が増えることもあります。曝露量、重大度、検知までの時間、再発率などを合わせて見る方が実態を捉えやすくなります。

残余リスクを明示する

すべての対策を入れてもリスクはゼロにはなりません。導入判断では、対策後に何が残るか、どの程度まで組織が受容するかを明記します。重大度が高く不確実性も大きい場合は、段階的リリース、利用者制限、停止条件などで曝露を抑える方法があります。

安全主張を読むときも、「安全です」ではなく、対象リスク、評価条件、残余リスク、運用上の制約が説明されているかを見る方が有用です。

次に起こりやすい誤解

「AI Safety＝AGIの人類滅亡リスクだけ」という理解も、「AI Safety＝有害発言フィルターだけ」という理解も狭すぎます。実際には、現在のシステム事故から将来の高影響リスクまで複数の研究伝統が同じ言葉の下に存在します。

また、安全対策があるから「安全が保証された」と考えるのも危険です。安全は文脈依存で、残余リスクを管理する概念です。

確認チェックリスト

その文脈でAI Safetyが何を含むか
モデル単体か、システム全体か
誤作動・誤用・悪用のどれを評価しているか
高頻度の小さな害と低頻度の重大害をどう扱うか
Red teamingや実環境テストがあるか
人間介入、停止、権限制限、ログなど運用対策があるか
モデル更新後に再評価するか
AlignmentやSecurityと混同していないか
安全評価結果が実際のリリース判断や運用制限に接続しているか

AI Safetyは「安全というラベル」ではなく、危害の可能性を具体化し、評価し、設計と運用で継続的に下げていくプロセスです。

注・出典

AI協働制作について

本記事は、著者が独自に設計した指示、参照資料、出典確認規則、著作権確認および監査工程を組み込んだChatGPT等の生成AIを、情報収集の補助、資料整理、構成検討、草稿作成、文章校正および監査補助に使用して制作しました。記事の対象範囲、情報源の採否、構成、解釈および最終表現は著者が判断し、最終稿を承認しています。著者は、本記事の正確性、独自性、引用、著作権処理および公開内容について責任を負います。制作工程の詳細はAI協働制作方針をご覧ください。