本文へ移動
Harch AI Lab AI Learning & Research Mediapowered by Artiql Inc.

セーフティケース(Safety Case)とは・意味、由来・論証の型・事例

最終確認日:2026年10月31日

セーフティケースとは?

セーフティケース(Safety Case)とは、あるシステムが特定の用途や環境で安全だと言える理由を、証拠を添えて筋道立てて示す論証のこと。この定義は英国の国防省の規格 Defence Standard 00-56 のもので、英国の AI Security Institute(AISI。2025年2月までの名前は AI Safety Institute)が引いている。

AISI はAIについて、AIシステムが特定の学習や利用の場面で安全だとする構造化された論証という意味で使う(※1)。

日本語の用例には OpenAI の発表があり、「セーフティケース」と書いて「リスクについての包括的かつ体系的な、証拠に基づく論証」と説明している(※2)。

セーフティケースは、AI企業の安全の方針(safety framework)とは役割が違う。AISI によると、方針は複数のシステムに当てはまる組織全体の考え方や原則を示す。セーフティケースは個々のシステムを分析し、そのシステムが方針の条件を満たすかを確かめる助けになる(※3)。

セーフティケースの由来と広まった経緯

セーフティケースは、AIのために生まれた手法ではない。AISI によると、自動車、民間航空、防衛、原子力、石油化学、鉄道、医療の各産業で使われている(※4)。英国には海上の石油・ガスの操業を対象に、この語を名前に含む規則がある。2015年7月19日に施行された規則は、一定の経過措置のもとで、沖合の水域について2005年の規則に置き換わった(※5)。

英国の Health and Safety Executive(HSE)によると、2005年の規則は、Piper Alpha の事故の公開調査で Cullen 卿が出した中心の勧告を実施するものだ。この勧告は、沖合の施設の事業者や所有者にセーフティケースを作らせ、HSE の受理を求めるものだった(※19)。

高度なAIに当てはめる議論の例として、Clymer 氏らは2024年3月の論文で、開発者がセーフティケースをどう作れるかを検討した(※6)。

AISI は同年8月、2つの開発企業が能力の高いモデルへの備えの中でセーフティケースを取り上げていると指摘した。Anthropic の方針案の「affirmative cases」と、Google DeepMind の「safety case with red team validation」だ(※1)。

OpenAI は2026年7月、社内のサイバーセキュリティの評価中のモデルが、インターネットからの隔離の仕組みをくぐり抜けたと公表した。同社は10月の書簡で、取り組む改革を示したものとして、9月28日の投稿「Towards safety cases for frontier AI training」を挙げている(※7)。

セーフティケースの論証の型と組み立て方

Clymer 氏らは、安全だと示す論証を4つの種類に分けて論じた(※6)。

  • 能力がない:AIシステムに破局を起こす能力がまったくないと示す。
  • 制御できる:十分に強い制御の措置があると示す。
  • 信頼できる:害を及ぼす能力があっても、信頼できると示す。
  • 助言役に委ねる:AIシステムがはるかに強力になった場合に、信頼できるAIの助言役の判断に従う。

組み立て方の例には、AISI が Centre for the Governance of AI と共同で書いた論文のひな形がある(※4)。Goemans 氏らのこの論文は、大きな主張を段階的に細かい主張へ分け、それぞれに証拠を付ける。書き方には Claims Arguments Evidence(主張・論証・証拠)という枠組みを使う(※8)。

AISI は、証拠の種類をいくつか見込んでいる。実験や数学などに基づく論証、十分な動機を持つレッドチーム(攻撃役)が安全策を破れなかったという結果、利用の場面や社内の組織についての証拠などだ(※1)。完全なセーフティケースは数百ページに及ぶこともありうると、Anthropic のブログは述べている(※9)。

能力しきい値に近づくほど「能力がない」論証の確信は下がるはず

能力しきい値は、AIの能力についての境目を指す。Anthropic は2024年の方針で、「Capability Thresholds」を、そこに達すると当時の基本の水準より強い安全策が要る具体的な能力としていた(※18)。Google DeepMind の「Critical Capability Levels」(CCL)は、対策がなければ深刻な害のリスクが高まるおそれのある能力の水準を指す(※11)。

AISI の考えでは、能力が十分に低いシステムなら「能力がない」という論証が有力な根拠になる。ただし、評価の結果がしきい値に近づくほど、この論証への確信は下がるはずだという。能力の高いシステムには、より複雑な論証が要るとしている(※4)。

セーフティケースに関する主な出来事・ニュース

セーフティケースに関する事例・研究

OpenAI は強化学習を続ける前に安全の文書を求めるべきとする

OpenAI は2026年9月、最先端のモデルの強化学習を続ける前に、体系立った安全の文書を求めるべきだとの考えを示した。強化学習は、報酬を手がかりにモデルのふるまいを学ばせる方法だ。同社にとってセーフティケースはこの文書の理想の水準で、目指す目標という位置づけにとどまる(※2)。

技術の面では、モデルのアライメント(開発者の意図に沿わせること)の学習、封じ込め、監視の3つを扱うべきだとした。運用の面の例には、別のチームが反対意見を書く、複数の経営幹部がそれぞれ実行を拒否できる、監査役に十分なアクセスを与える、対処できていないリスクを列挙する、などを挙げている。これらは推奨で、社内で導入を進めている段階だと同社は書いている(※2)。

OpenAI は10月の2つの発表で、safety cases に組み込んだものを説明している。1つは計算資源を多く投じるレッドチームの試験で、今後の最先端のモデルの強化学習の学習と評価に向けた safety cases の中心の一部だという。もう1つは監視で、最先端のモデルの学習の安全性を評価する safety cases の一部だという(※12、※13)。

OpenAI はセーフティケースの第三者評価をカリフォルニア州に提言

OpenAI は2026年10月20日付のカリフォルニア州知事への書簡で、開発企業が学習と利用について証拠に基づくセーフティケースを用意することを勧めた。同社の案では、資格のある第三者がその証拠を調べ、前提を試し、不足を指摘する。同社は、州政府と米国国立標準技術研究所(NIST)などが共通の基準を探ることも勧めている(※7)。

Anthropic は Claude Opus 4.6 の妨害リスク報告書を公表

Anthropic は2026年2月10日の更新で、当時の方針の決まりを説明した。モデルが AI R&D-4 という能力しきい値を超えると、最も差し迫り関連の深いミスアライメントのリスクとその対策を説明する「affirmative case」を作る必要があった。

同社はこの時点で、Claude Opus 4.6 はこのしきい値を超えていないと判定した。ただ、超えていないと確信を持って言うことが難しくなってきたとして、妨害(サボタージュ)のリスクの報告書を公表した。同社は2026年2月24日に方針を全面的に書き直した(※10)。

7月8日に施行した今の版(3.4)では、変更履歴を除く本文に「affirmative case」も「AI R&D-4」も出てこない。影響の大きい場面(high-stakes settings)でのミスアライメントのリスクは、3〜6か月ごとに公表するリスク報告書などで扱うとしている(※20)。

Google DeepMind は CCL に達すると公開前に safety case を点検

Google DeepMind は2025年9月の発表で、関係するCCLに達すると外部への公開の前に safety case の点検を行うと説明した。リスクが管理できる水準まで下がったことを示す詳しい分析を伴う。機械学習の研究開発のCCLについては、大規模な社内の利用にも広げるという(※11)。

Phuong 氏らは Scheming の前提になる能力を測る評価を提案

Phuong 氏らは2025年の論文で、Scheming(AIが開発者の意図と異なる目標を隠して追うこと)の前提になると同氏らが考える能力を測る、16の評価を示した。これらの評価に成功しないモデルは、実際の利用で Scheming による深刻な害をほぼ確実に起こせない、という論証に使うという。当時の最先端のモデルを試したところ、懸念される水準を示すものはなかった(※14)。

Barrett 氏らは DeepMind のセーフティケースを外部から点検

Barrett 氏らは2026年の論文で、Phuong 氏らの論文を Google DeepMind の Scheming についてのセーフティケースとして外部から点検した。Phuong 氏らの論文に「深刻な害」の定義がないことや、人による悪用と組み合わさった場合が範囲に入るのか不明確なことなどを挙げている。

Gemini 2.5 の公開の判断に使われたのか研究の成果物なのかも、Barrett 氏らには読み取れなかったという(※15)。

Apollo Research は Scheming の論証に要る最低4つの主張を提示

OpenAI と Scheming の検出や低減で協力した Apollo Research は2026年10月、Scheming についてのセーフティケースには最低でも4つの主張が要るとした(※16)。

  • 学習中に Scheming を促していない。
  • 厳しい評価とレッドチームの試験から、モデルに Scheming の傾向がないとうかがえる。
  • 社内での利用中に Scheming が試みられたことがない。
  • Scheming につながる推論があれば検知できる。

同社によれば、これらは必要な条件で、十分ではない。監視や制御の措置なども要る(※16)。

セーフティケースの英語での言い方

英語の言い方 意味 使っている主体
safety case システムが安全だとする、証拠に基づく論証 AISI、OpenAI など(※1、※17)
safety case sketch 特定の安全策について、論証と証拠の見込みを描いた下書き AISI(※1)
safety case template 個々のシステムに合わせて埋められる大まかな論証 AISI(※3)
affirmative safety case / affirmative case 特定の環境での提供が安全だとする構造化された論証。Anthropic が2024年の文書と2026年2月の方針の説明で使った Anthropic(※9、※10)
inability argument システムの能力が足りず、許容できないリスクにならないとする論証 AISI(※4)
safety case review Google DeepMind が公開の前などに行う点検 Google DeepMind(※11)

セーフティケースの限界と読むときの注意

セーフティケースがあっても、安全が証明されたとは限らない。AISI は2025年2月の時点で、最先端のAIシステムが安全だという頑健な論証の書き方はまだ分からず、完全で正しいセーフティケースはまだ書けないと述べていた(※3)。

OpenAI も2026年9月、航空や原子力と同じ厳密さにする難しさを認めている(※2)。Apollo Research は2026年10月、開発企業はまだ4つの主張のすべてには自信を持てないと書いた(※16)。

書き手の偏りも論点になる。開発企業が自分で書くと、確証バイアスや利害の対立が論証の質に影響することがある。Barrett 氏らは、外部の点検がその対処に役立つとしている(※15)。

セーフティケースの結論は、定義のうえで特定の用途や環境に限られる。たとえば OpenAI の指針は強化学習の学習を対象にしたもので、社内外への提供にはさらに広い検討が要るという(※2)。

「スケッチ」や「ひな形」と呼ばれるものは、実際の判断に使われた文書とは限らない。Anthropic のスケッチは約束や計画ではないと断っている(※9)。AISI も、ひな形を概念の実証と位置づけている(※4)。各社の安全の文書を読むときは、どの用途の話か、下書きか実際の判断に使ったものか、誰が確かめたのかを見ると、読み違えを減らせるだろう。

セーフティケースに関連する用語

  • Scheming(スキーミング):AIが開発者の意図しない目標を、本当の目的や能力を隠しながら追うこと。
  • 封じ込め:AIモデルやAIエージェントが届く範囲を外側の仕組みで区切り、意図しない動きの影響を外に及ぼさない安全対策。
  • ミスアライメント:AIのふるまいが、開発者や利用者の意図、またはAIに求められる行動の指針からずれること。

セーフティケースに関する出典

※1 AI Security Institute「Safety cases at AISI」(2024年8月23日)
※2 OpenAI「フロンティア AI のトレーニングに向けたセーフティケースの構築へ」(2026年9月28日)
※3 AI Security Institute「How can safety cases be used to help with frontier AI safety?」(2025年2月10日)
※4 AI Security Institute「Safety case template for ‘inability’ arguments」(2024年11月14日)
※5 Health and Safety Executive「The Offshore Installations (Offshore Safety Directive)(Safety Case etc) Regulations 2015. Guidance on Regulations」(2015年12月22日)
※6 Joshua Clymer 氏ら「Safety Cases: How to Justify the Safety of Advanced AI Systems」(2024年3月15日、arXiv)
※7 OpenAI「Recommendations under Sept. 18, 2026 Executive Order」(2026年10月20日)
※8 Arthur Goemans 氏ら「Safety case template for frontier AI: A cyber inability argument」(2024年11月12日、arXiv)
※9 Anthropic「Three Sketches of ASL-4 Safety Case Components」(2024年11月、Alignment Science Blog)
※10 Anthropic「Anthropic’s Responsible Scaling Policy」(2026年8月14日更新)
※11 Google DeepMind「Strengthening our Frontier Safety Framework」(2025年9月22日、2026年4月17日更新)
※12 OpenAI「Securing our frontier model training environment」(2026年10月23日)
※13 OpenAI「フロンティアモデルのミスアライメントを検知する仕組み」(2026年10月29日)
※14 Mary Phuong 氏ら「Evaluating Frontier Models for Stealth and Situational Awareness」(2025年5月2日、arXiv)
※15 Stephen Barrett 氏ら「Lessons from External Review of DeepMind’s Scheming Inability Safety Case」(2026年4月23日、arXiv)
※16 Apollo Research「Towards embedded evaluations for scheming propensities」(2026年10月1日)
※17 OpenAI「Towards safety cases for frontier AI training」(2026年9月28日)
※18 Anthropic「Announcing our updated Responsible Scaling Policy」(2024年10月15日)
※19 Health and Safety Executive「A guide to the Offshore Installations (Safety Case) Regulations 2005. Guidance on Regulations」(2006年、第3版)
※20 Anthropic「Responsible Scaling Policy Version 3.4」(2026年7月8日施行)

セーフティケースに関連する記事