1. 開発のペースを落とせば、安全性を確かめられるのか2026年9月12日、米Anthropic社のダリオ・アモデイCEOは「We Must Pace the Frontier」と題する論考を公表し、最先端の汎用AIであるフロンティアAIの能力向上のペースを調整するよう呼び掛けた（※1）。OpenAIのサム・アルトマンCEOも、開発のペースを調整する必要性に賛同を表明したと報じられている（※2）。提言の背景には、AIが人間の意図や制約から逸脱する事案への危機感がある。アモデイ氏は、OpenAIの内部評価でAIエージェント群が指示されていない対象への攻撃に及んだHugging Faceの事案を挙げ、程度は異なるものの、Anthropicを含む業界各社でも類似の事案が起きていると指摘した。加えて、AIが次世代のAI開発を担う「再帰的自己改善」によって能力向上が加速し、人間の理解や制御が追い付かなくなることを懸念している。安全対策への投資を増やすだけでは、この加速に対応し切れないという認識が、開発のペースそのものを調整する提言につながった（※1）。アモデイ氏の提言で重要なのは、開発競争のスピードを緩めること自体が目的ではないという点だ。確保した時間を、AIを人間の意図に沿って動かすための研究や安全対策の改善に充て、第三者がその取り組みを検証できるようにする。その第一歩として、第三者評価者に従業員に近い継続的アクセスを与え、完成したモデルだけでなく、訓練工程や安全対策の実施状況まで検証する構想を示した（※1）。では、時間を確保し、評価者が開発過程に立ち入れるようになれば、安全性を十分に検証できるのだろうか。ここには、開発の速度や検証に使える時間だけでは答えの出ない問いがある。何を試し、どのような証拠がそろえば、実際の利用環境でもリスクを受容できると判断してよいのか。本稿では、安全工学の観点から、テストの結果を安全性の保証へつなぐ際の構造的な難しさを整理する。その上で、AIを利用する日本企業が、供給の継続性と自社の防御をどう設計すべきかを考える。2. 他産業の安全性保証から何を学べるか安全性をどのような根拠で判断するかという課題には、航空や医薬などの産業が長く向き合ってきた。1954年のコメット旅客機の事故は、機体の疲労破壊をどう予測し、試験で捉えるかを問い直す契機となった（※3）。サリドマイドによる薬害は、医薬品の試験で何を確認すべきかという問題を突き付け、米国では1962年の法改正による安全性と有効性に関する審査制度の強化につながった（※4）。これらの産業でも、事故が絶対に起きないことが証明できているわけではない（実際に事故はまだ起き続けている）。ここでいう安全性の保証とは、想定する危険や使用条件を特定し、リスク軽減措置を講じた上で、残るリスクを受容可能と判断する根拠を示すことである。そのための方法の一つが「セーフティケース」だ。安全に関する具体的な主張と証拠、それらを結ぶ論証を、第三者が吟味できる形にまとめる。前提条件や残る不確実性を明示することも欠かせない。英国AI Security Institute（AISI）は、他の産業で安全性保証のために使われている「セーフティケース」のフロンティアAIへの適用を研究する一方、評価結果の一般化や論証への確信度などに未解決の課題があると説明している（※5）。こうした安全性保証の考え方はAIにも参考になるが、他産業の方法をそのまま適用できるわけではない。特に難しいのは、試験範囲を定めること、評価時の振る舞いを実運用へ一般化すること、内部の仕組みから安全性を検証することである。3. なぜAIでは保証の根拠を作りにくいのか（1）試験範囲の外に、未知の攻撃が残るAIモデルへの攻撃は、依頼の組み立て方、言語、文字の符号化、テキスト・画像・音声の組み合わせによって変化する。利用者や攻撃者も、モデルの応答を見ながら手法を変える。何を試せば十分なのかという、試験範囲そのものを定めにくい。危険な入力や出力を検知する分類器が、未知の攻撃にも有効な場合はある。しかし、既知の攻撃を防いだ成績だけでは、未知の攻撃に対する有効性までは示せない。攻撃者の視点で弱点を探すレッドチームによって確認済みの範囲は広がるが、その外側に何が残るかという問いは続く。（2）同じモデルでも、評価時と運用時で振る舞いが変わる同じモデルでも、振る舞いは一定ではない。重みが固定されていても、会話の履歴や蓄積された記憶、外部情報によって行動は変わる。これは、利用のたびに重みが更新されることとは異なる（※6）。さらに、モデルが「これは評価である」と推測し、振る舞いを変える問題もある。研究では、特定のモデルとベンチマークにおいて、評価中だと示す発言が有害な依頼への拒否を増やす例が報告されている。実運用での危険な行動を直接証明するものではないが、試験での安全な振る舞いを、そのまま一般化できない理由になる（※7）。企業の運用では、外部ツールや自社データが接続され、エージェントに権限が与えられる。安全性は構成全体に依存するため、モデルの版を揃えるだけでは不十分である。モデルや記憶、接続先の変更が、従来の評価にどう影響するかを確かめ直す必要がある。（3）内部へのアクセスがあっても、安全性を読み解けるとは限らない独立評価には情報開示が重要だが、それだけでは埋まらない難しさがある。学習によって形成された内部の仕組みは、開発企業自身にも十分には解明されていない。訓練工程やモデルの重みを確認できても、危険な行動の発生条件を直接読み取れるわけではない（※8）。内部解析で問題を発見できる場合はある。しかし、未発見を、問題がない根拠としてどこまで扱えるかは別である。評価者の独立性だけでなく、その検証方法が何を見つけられ、何を見逃し得るかが問われる。冒頭で触れた第三者評価者の継続的アクセスは、開発過程の検証へ踏み込む提案である※1。ただし、これは方針の表明であり、実施成果の報告ではない。アクセスの拡大は検証の条件を改善するが、それによって安全性をどこまで裏付けられるかは、検証手法そのものにも依存する。4. 企業は何に備えるべきか日本企業には、大きく二つの対応が求められる。一つ目は、政府や提供企業によるモデルの提供停止措置等に対応できる体制整備である。本稿では、個々の出力の誤りよりも、AIの高度な能力がもたらす大規模な危害（高度なサイバー攻撃や生物兵器開発への悪用、人間の意図や制約から逸脱したAIの行動等）に焦点を当ててきたが、利用企業自身がこうした能力を使わなくても、政府や提供企業の安全性判断が変われば、依存するモデルへのアクセスが制限され得る。実際、2026年6月には、米政府が輸出管理の権限に基づいてAnthropicのFable 5とMythos 5へのアクセス制限を命じ、同社は両モデルの提供を全顧客向けに一時停止した（※9）。今後も同様の介入が起きる可能性があるというのが、筆者の見立てである。提供停止に備え、業務のAI依存をモデル名だけでなく、能力と権限まで分解して把握する。どの業務工程が高度なAIモデル（特に高度なサイバーセキュリティやバイオ関連の能力があるモデル）に依存し、エージェントがどのシステムへアクセスしているのか。全面停止に加え、特定能力の制限や利用条件の変更も想定し、どの工程が止まり、後続の業務にどう影響するかを確認する必要がある。代替モデルへの切替後も業務が成立するか、あらかじめ確かめておく。接続先を変更できても、同じエージェントが同じ仕事を遂行できるとは限らない。能力やツールの扱い方が変われば、与える権限や自動実行の範囲も見直す必要がある。処理範囲を絞る、一部を人へ戻すといった縮小運転も含め、実際の業務で切替を試しておく。代替先には、中国系を含むオープンウェイトモデル、すなわち学習済みの重みを入手して運用できるモデルも考えられる。自社や国内事業者の管理下で運用すれば、米国企業のAPI提供停止への依存を減らせる。ただし、国内運用でも、計算基盤や運用事業者への依存、安全対策の負担は残る。必要な業務能力、ライセンス条件、運用体制に加え、中国系モデルでは経済安全保障や取引先の調達方針との整合も検討事項になる。供給を自ら管理しやすくなることは、モデルが持つ大規模な危害のリスクが小さくなることを意味しない。二つ目は、モデルの安全性評価だけに依存しない、自社側の多層防御である。未知の攻撃が残り、評価時と運用時の振る舞いも異なり得る。内部解析にも限界がある以上、モデルが危険な指示を常に拒否することは前提にできない。防御が破られても、自社のデータやシステムへの被害を抑える構成が必要になる。外部文書の指示でエージェントを誘導するプロンプトインジェクションへの対策は、その一例だ。個々の攻撃が直ちにシステミックリスクになるわけではないが、広い権限による被害の拡大を自社側で抑える。エージェント専用の権限を業務に必要な範囲へ絞り、コード実行環境を隔離する。外部への送信先や利用可能な操作は、モデルへの指示だけでなく、接続先システムやネットワーク側でも制限する。重要データの送信や本番環境の変更は、実行前に宛先・対象・権限を検査し、リスクに応じて別系統の承認を求める※10、11。承認後に送信先や実行内容が変更された場合は、再承認を必要とする。エージェント自身には承認や制限の解除をさせない。企業独自の検知ルールや分類器を加えることも選択肢になる。ただし、検知には見逃しがあるため、モデルとは独立した権限制御と組み合わせる。許可された操作も悪用され得ることを踏まえ、アクセス先、送信可能なデータ、処理量などを制限する。操作ログを残し、異常時には権限を取り消して停止できるようにする。導入時やモデル切替時には、実データを使わない検証環境で攻撃を含む試験を行い、実際に制限が働くか確かめる。これらは完全な防御の証明ではなく、失敗が被害につながる経路を減らすための対策である（※10、11）。5. おわりに開発のペースを調整して得た時間を、安全性の根拠を積み上げることに使えるか。それが「Pace the Frontier」を考える上での核心である。テスト結果だけから、用途や環境を問わない安全性を保証することはできない。それでも、主張の範囲と前提を明確にし、第三者が継続的に検証することで、判断の根拠を厚くすることはできる。AIエージェントを事業に組み込む企業にとって、高度なAI能力へのアクセスは、常に同じ条件で使える固定的な前提ではない。どの能力に依存し、その利用が制限されたときに何を継続できるのか。そして、モデル側の防御が破られても、自社システム側でどこまで被害を抑えられるのか。安全性をめぐる不確実性を、事業継続と多層防御の設計に織り込むことが必要である。（※1） Dario Amodei, “We Must Pace the Frontier”（2026年9月、9月12日公表）。第三者評価者の継続的アクセスは同論考で示された方針。https://darioamodei.com/post/we-must-pace-the-frontier（※2） NBC Chicago, “Sam Altman backs Anthropic CEO’s call to slow down global AI race”（2026年9月12日の投稿を引用する報道）。賛同の表明であり、具体的な減速幅や実施方法の合意を示すものではない。https://www.nbcchicago.com/news/national-international/anthropic-ceo-calls-for-slowing-ai-race/3988090/（※3） FAA, “De Havilland DH-106 Comet 1.” https://www.faa.gov/lessons_learned/transport_airplane/accidents/G-ALYV（※4） FDA, “A Brief History of the Center for Drug Evaluation and Research.” https://www.fda.gov/about-fda/fda-history-exhibits/brief-history-center-drug-evaluation-and-research（※5） UK AI Security Institute, “How can safety cases be used to help with frontier AI safety?” https://www.aisi.gov.uk/blog/how-can-safety-cases-be-used-to-help-with-frontier-ai-safety（※6） Google Research, “Learning without training: The implicit dynamics of in-context learning.” 文脈内学習は、推論時に重みを更新せずに生じ得る適応を指す。https://research.google/pubs/learning-without-training-the-implicit-dynamics-of-in-context-learning/（※7） Santiago Aranguri and Joseph Bloom（Goodfire／UK AISI）, “Verbalized Eval Awareness Inflates Measured Safety”（2026年5月4日）。複数モデルでの関連に加え、Kimi K2.5／Fortressで評価への気付きを示す発言に介入し、拒否率への影響を検証。実運用との直接比較ではない。https://www.goodfire.com/research/verbalized-eval-awareness-inflates-measured-safety（※8） Anthropic, “Interpretability Research”; “AuditBench: Evaluating Alignment Auditing Techniques on Models with Hidden Behaviors”（後者は2026年3月10日）。AuditBenchは隠れた振る舞いを意図的に学習させたモデルによる監査手法の研究であり、実運用モデルの危険性を直接示すものではない。https://www.anthropic.com/research/team/interpretability https://alignment.anthropic.com/2026/auditbench/（※9） Anthropic, “Statement on the US government directive to suspend access to Fable 5 and Mythos 5”（2026年6月12日）。措置の内容と脆弱性の評価は同社の説明に基づく。https://www.anthropic.com/news/fable-mythos-access（※10） UK National Cyber Security Centre, “Prompt injection is not SQL injection (it may be worse).” https://www.ncsc.gov.uk/blog-post/prompt-injection-is-not-sql-injection（※11） Anthropic, “Mitigate jailbreaks and prompt injections”; “How we contain Claude across products.” 多層防御の対策は、これらの資料を踏まえた企業システムへの実装上の提案。https://platform.claude.com/docs/en/test-and-evaluate/strengthen-guardrails/mitigate-jailbreaks https://www.anthropic.com/engineering/how-we-contain-claude本稿は公開情報や執筆者の専門的知見に基づいた一般的な分析・見解を提供するものです。本稿に記載の見解は執筆担当者の個人的見解であり、当社または当社のクライアントの見解ではありません。