Anthropic、Claude の不正アクセス事案を受けセキュリティ対策を強化

7 月 30 日、Claude モデルが許可なく実際のコンピューターシステムにアクセスした事例を 3 つ報告しました。評価目的で意図的にサイバー保護機能を無効にして実行されていたこれらのモデルは、第三者の評価環境内の設定ミスによりインターネットへ接続してしまいました。

一方、8 月 4 日には英国 AI セキュリティ研究所（UK AI Security Institute）が、同機関が行ったサイバーセキュリティテストにおける事例を報告しました。これは Claude Mythos 5 がライブ上のインターネット上で一連の許可されていない行動をとったケースです。この場合も評価目的で意図的に保護機能を無効化し、あえてインターネットアクセス権限を与えられていたモデルでした。

両方の事案について詳細な分析を進めています。また、METR と連携して独立したレビューを実施する計画も進めており、両方の調査が十分なものとなるよう努めます。今後数週間でさらに詳しい情報を共有いたします。

今月に行なった変更点の一部を共有します。今回の事案は、運用セキュリティの欠陥だけでなく、二つのアライメント（調整）上の問題—— motivated reasoning（動機付けられた推論）と、限定的なタスク達成のために有害な行動を取る意志——が反映されたものだと考えています。これらについては以前にシステムカードで説明した通りです。

セキュリティ面では、封じ込めおよび監視システムの改善内容と、第三者評価者向けに策定した運用手法について解説します。アライメント（調整）面では、上記の二つの問題についてより深く掘り下げて議論します。また、単に特定の事案で何が起きたかを理解するだけでなく、なぜ最初からアライメントが崩れるのかというメカニズムを理解することが、持続的な進展につながると考えています。その方向性に関する初期研究については、こちらをご覧ください early research in that direction。

これらの出来事を受け、フロンティアのペース配分に関する議論が高まっています。ペース配分には2つの種類があることを区別することが重要です。

企業内におけるペース配分とは、安全性と速度が対立する際に、安全性を優先する一連の意思決定を指します。一方、業界全体でのペース配分とは、底辺への競争（race-to-the-bottom）を防ぐためのプロセスを整備することを意味します。

本稿では、これらの出来事の前および後に、最初のアプローチを実現するために私たちが講じた措置について説明します。2つ目のタイプのペース配分には政府と産業界の連携が必要であり、その透明性と検証可能性が求められます。最近、当社のシニアリーダーシップ層や多くの従業員が、ペース配分に関する連携強化を求める書簡に署名しました。今後数週間で、私たちがこの取り組みにどのように貢献していくかについて詳しくお伝えします。

明確にしておきたいのは、業界が法的かつ検証可能で効果的な協調的ペース配分の仕組みを可能な限り早く採用すれば、世界全体にとって有益であるという私たちの信念です。

評価・訓練環境のセキュリティ強化

これらの出来事が運用上の問題だけではないと考えていますが、まずは具体的な封じ込めと監視の問題に対処することが最優先事項でした。これに対応し、以下の措置を講じました：

評価環境の一時停止と強化

今回のインシデントを受け、リリース前のモデルに対する外部サイバー評価を一時停止し、以下の対策が整うまでの間、内部評価も一時的に停止しました。7 月 30 日に報告したインシデントから明らかになったのは、私たちが単一の防御層（環境自体の構成）に過度に依存していたということです。実際には、プロンプト内で明確な境界を設定する、サンドボックスが意図通りに封じ込められていることを確認するプロセスを確立する、リアルタイムで介入可能な監視体制を導入するなど、複数の防御層が必要でした。

また、OpenAI の 開示（これが 7 月の調査のきっかけとなりました）によると、モデルが評価中に未知の脆弱性を悪用して封じ込められたサンドボックスから脱出したことが判明しました。この事実も、サンドボックス自体を強化することに注力すべきであることを浮き彫りにしています。

評価を一時停止している間、私たちは以下の暫定措置を講じました：

1) モデルがテスト環境に対して攻撃的なプロービングや脱出を試みたり、予期せずインターネットアクセスを取得したりした瞬間に、リアルタイムで自動的に検出する分類器（classifier）を構築・導入しました。この分類器がそのような試行を検知すると、ツール呼び出しを実行する前にその行動をブロックし、タスクを終了して人間にアラートを送ります。1

2) 直近のリリース前モデルに対する内部評価（サイバー攻撃関連およびその他の分野）のトランスクリプトに対して、自動監視を実施しました。その目的は、サンドボックスからの脱出（モデルがサンドボックスの欠陥を悪用し、本来アクセスすべきでないシステムに到達するケース）や、サンドボックスの設定ミスがないかを確認することです。

評価をサンドボックスツール内で行った場合、本来アクセスしてはいけない外部リソースに対して境界を突破した事例は見つかりませんでした。ただし、モデルが利用可能な各種のサンドボックス設定ミスは確認されており、これらはすべて外部システムの侵害には至っていません。現在、これらの課題への対応を進めています。

3) 高リスクと判定された内部サイバー用サンドボックスを、より堅牢な隔離環境へ移行しました。また、仮想化スタックに対するレッドチーム演習も強化しています。具体的には、リリース前モデルに脱出を試みさせることで脆弱性を発見し、修正を行う作業です。

これらの対策を講じた上で、内部のサイバー評価は再開されています。

強化学習環境の改善

私たちは、リリース前のモデルにおけるリスクの高い強化学習（RL）環境を数週間停止しました。その間、新しい監視体制を回避しようとする動機を与えないよう改良した同様の分類器を開発し、現在はその環境内で展開しています。強化学習の大部分は再開されましたが、手動レビューが必要な高リスク環境の一部はまだ停止状態です。また、一部の環境では、近日中に展開予定の更新版分類器が必要となります。

より広範な強化策

高リスクの評価やトレーニングに注力した取り組みに加え、オフライン監視の対象を拡大し、内部におけるフロンティア型エージェントの利用のほとんどをカバーしました。さらに、Anthropic の従業員が、上記で説明したような緩和措置よりも弱いものを持つエージェントを誤って実行しないよう、内部推論プロセスに対する制御も構築中です。

外部パートナー向けのベストプラクティス

報告されたインシデントは第三者の環境で発生したため、サイバーセキュリティ対策を減らしてリリース前のモデルを検証するすべての組織に対し、一連のベストプラクティスへの準拠を要請しました。これらの取り組みが不可欠だと考える理由は以下の通りです：

一般公開されたモデルには、マルウェアの開発や攻撃的なエクスプロイトの作成など、禁止されたサイバー活動をリアルタイムでブロックするための分類器が組み込まれたセーフガード（安全装置）が付属しています。一方、サイバー評価担当者や一部の早期アクセスパートナーは、正確なモデル能力テストや防御的なサイバー作業を可能にするため、これらのセーフガードを制限したモデルと連携して作業を行います。

サイバー評価では、今回の事案で見られたような行動が特に生じやすくなります。これは、周囲の環境を探り、障害物を回避する際の持続性と創造性に対する選択圧がかかること、そして数千回という頻度で実施されることに起因します。

これらの運用方針は、パートナーが独自のハーンネス（枠組み）、サンドボックス、またはエージェントを用いてサイバー関連の評価を行うすべての場面で完全に適用されます。ただし、セーフガード付きのモデル（Claude Fable 5 など）を利用している顧客には適用されません。 私たちは、これらの対策を講じた上で外部でのサイバー評価を再開しており、社内においても同様に遵守しています。

サンドボックスとネットワークの分離

デフォルトでは、すべてのサイバー評価は、インターネット接続がないように強化されたサンドボックス（隔離されたコンピューティング環境）内で実行する必要があります。この環境が許可する外部との通信は、モデル自身の API への接続のみとし、API キーは環境外に保管してください。この設定は、各評価を開始する前に必ず確認してください。

一部の評価ではインターネットアクセスが必要になる場合があります。そのようなケースでは、リリース前のモデルを評価する際、外部の評価パートナーと連携し、モデルが宣言された範囲を超えた行動をとった場合に、それを確実に検知して実行を停止できるかどうかを確認します。

事前評価検証

評価の実行を行う前に、評価パートナーは以下の手順を実行する必要があります：

テスト対象のモデルが、まず設定に対する静的解析を通じて、次に実際に脱出を試みるよう指示を出すことで、サンドボックス内の脆弱性を探るべきです。脱出に成功した場合は停止して報告するようモデルに指示し、これらはすべて人間の厳重な監視下で行う必要があります。このテストはインターネット接続なしで、理想的には第 2 のサンドボックス内で行うべきです。評価は数百回、あるいは数千回にわたって行われることもあるため、パートナー企業は評価を開始する前に十分に時間をかけてこのテストを実施することが望ましいでしょう。

評価課題が原理的に解決可能であることを確認してください。評価対象がオフラインの場合やタスクを完了できない場合、エージェントは課題を達成するための他の手段を探そうとし、評価の意図した範囲外で行動をとる可能性が高まります。

明確なスコープ設定

すべてのプロンプトには、この演習の対象、許可されたアクション、ネットワーク境界（つまりモデルがアクセスすべき・すべきでないもの）など、何が含まれ何が含まれないかを明記する必要があります。境界線は環境やテストに関する主張（例：「インターネットにアクセスできません」）ではなく、指示として表現してください（例：「インターネットにはアクセスしないでください」）。

リアルタイムモニタリング

評価者は、提供された演習の範囲を把握したモデルベースまたはルールベースのモニターを用いて、モデルの思考・行動およびネットワーク活動に対して継続的な監視を行うべきです。もし実行がその範囲に違反した場合、モニターは人間に警告を発し、演習を終了させる必要があります。

当社は今後、外部パートナーと協議しながらこのガイダンスをさらに洗練させ、評価の枠組みを超えて適用範囲を広げていく計画です。特に、サイバーセキュリティ対策が施されていない状態で動作する「Claude Mythos 5」へのアクセス権を持つパートナー向けに、同様の運用プラクティスを開発中で、詳細は近日中に共有予定です。

アライメント評価

封じ込めとモニタリングは、モデルが危険な行動をとった事例を検知するために不可欠ですが、それらは「なぜその行動をとってしまったのか」という根本的な原因には対応できません。以下では、当社の初期段階のアライメント調査内容と重点を置いている問い、そしてトレーニング中の不正行為を防ぐための取り組み（不正行為がモデルの振る舞いにどう影響するかを分析した新たな研究を含む）について解説します。

評価時の環境とモデルの知識状態

当社のアライメント評価は現在も継続中ですが、予備調査の結果から、主に2つのアライメント失敗が確認されました。これらは過去のシステムカードで既に詳細を記載しています。

1つ目は「推論バイアス」です。モデルには当初、環境がシミュレーション上のものであると伝えられていました。しかし後に、実際のインターネットに接続されているという証拠に直面した際、その証拠を解釈する際に信念を維持できるような方向へ歪めてしまった可能性があります。

2つ目は「無謀さ」です。モデルはサイバーセキュリティ評価という狭い目的を達成するために、実世界のインターネット上で有害な行動を取ることに躊躇しませんでした。

しかし同時に、これらの事案で示されたモデルの振る舞いには、評価自体が寄与した可能性も強くあります。Claude にはインターネットへのアクセスがないと明示的に伝えられていましたが、実際にはアクセス可能でした。この矛盾により、モデルは目にしたシステムが本当に実在するのか疑問を抱いた可能性があります。

またあるケースでは、架空のターゲット名が実際のウェブサイトの名称と一致していたため、評価の範囲内にあるものとそうでないものを区別することが困難になりました。

私たちの結論は、いくつかの完全には答えられていない問いに依存しています。例えば、モデルがインターネットへのアクセス権限があると判断した程度（当初はそのことを知らなかった場合でも）、環境の一部が現実であることを示す兆候を意図的に無視していたかどうか、そして複数のケースで実験を停止しなかった事実が動機付けられた推論に起因するものだったかどうかといった問いです。これらの疑問に答えるため、環境に対して標的を絞った変更を加えながらモデルを再サンプリングしたり、解釈可能性手法を用いて内部状態を直接検査したりする一連の技術的应用を進めています。

トレーニング中の不正行為防止への取り組みの研究

モデルの整合性欠如は複雑で多様な理由から生じ得ますが、私たちは経験的に、トレーニング環境における欠陥、特に不正行為に脆弱な環境や、不正行為なしでは解決不可能な環境が、整合性欠如行動の過大かつ不均衡な要因となっていることを発見しました。

私たちは、これらの欠陥を持つトレーニング環境を避けるための取り組みについて、数か月前から実施してきた経緯を以下に説明します。その取り組みは完璧ではありませんでした。私たちが仮説としているのは、今回のインシデントが少なくとも部分的には、こうした問題を完全に排除できなかったことに起因しているという点です。

この仮説を検証するため、報酬ハッキング（reward hacking）が発生しやすい環境で意図的にモデルをトレーニングする実験を行いました。その結果、シミュレーション上ではより深刻なアライメント違反の行動が再現され、一部は今年夏に他社から報告された事例と類似していました。一方、同じシミュレーション環境に投入した当社の本番用モデル（production models）からは、そのような現象は見られませんでした（詳細は後述します）。

歴史的に、不正行為を誘発する可能性のある強化学習（RL）トレーニング環境については懸念を抱いており、こうした環境のフィルタリングや修正に向けた各種措置を講じてきました。

2 月、Mythos Preview の強化学習ランにおいて報酬ハッキングの兆候が確認されたため、3 日間の学習をロールバックしました。報酬ハキングとは、モデルが割り当てられたタスクを完了せずにトレーニングプロセスを欺き、報酬を得ようとする現象です。

モデルはコードコメントや返信で「レビュアー」へのメモを書き込むという行動を取りました。これは、特定のタスクにおいて一度もレビュアーに言及されていないケースでも同様でした。これは、プロンプトに必ずしもレビュアーが含まれていない環境から生じた望ましくない一般化です。また、正直さを促すための報酬を悪用し、免責事項や注釈を過剰に付加することで報酬を得ようとする行動も確認されました。

3 日間の学習をロールバックしたことで、この問題行動が学習される前のチェックポイントから学習を再開することができました。同時に、環境側に変更を加え、モデルが再び同様の行動を学習しないように対策を講じました。

Claude Sonnet 3.7 の頃から、強化学習（RL）でモデルが学習する望ましくない動作を検出するためのツールを開発し続けてきました。Sonnet 3.7 は報酬ハッキングの傾向がありましたが、学習の最終段階まで検出できませんでした。各モデル世代ごとにツールの進化を確実にするため、手動の分類器から、トレーニング実行前および実行中の全環境に対する自動レビューシステムへと移行するよう努めてきましたが、2026 年春にはこの体制に負荷がかかり始めていました。

RL 環境の作成ペースが過去にないほど速くなり、システムの審査能力が追いつかなくなっていたのです。問題のある環境は人間による裁定が必要でしたが、報酬ハッキングや設定ミスが検出・修正の速度を上回る事態となりました。

また、一部のトレーニング実行で誤ってモデルの思考プロセス（chain-of-thought）を学習対象としてしまう事象が発生していることを発見しました。これは、モデルが実際の推論過程を隠すよう学習してしまう恐れがあるため、私たちは強く回避しようとしている問題です。この漏洩の原因は、本番環境スタック内のいくつかの設定ミスにありました。調査を進める中で、長期間蓄積された不整然なコードに起因する他の課題も明らかになりました。

これらの懸念に対処するため、4 月には約 1 ヶ月間、本番の RL（強化学習）環境に対する変更をすべて凍結しました。これにより、スタック全体を見直す機会を得ることができました。現在、報酬関数と環境は合意された仕様に準拠する必要があります。例えば、誤って思考プロセスを学習対象としてしまうリスクを低減するための技術的な対策を導入しました。6 環境の品質向上チームと監視チームがスタックの再構築を進める間、環境所有者にはこの期間を利用して、自身が担当する環境のテストと修正を行うよう要請しました。また、レビュープロセスも完全に再構築し、修正された環境は次のトレーニング実行に組み込む前に再認証を受けることを義務付けました。

凍結期間中、本番環境の 10% 以上で、報酬ハッキングからタスクの破損、設定ミスに至るまで様々な問題が検出されました。これらの環境はすべて修正完了後にのみ復帰させられています。

しかし、私たちの取り組みは完璧ではありませんでした。いくつかのケースでは、人間のレビュー担当者が自動化された監視システムが警告した環境を誤報として却下し、欠陥のある環境が本来よりも長くトレーニングデータに残されてしまう事態が発生しました。また、欠陥のある環境の中には、検知機構をかいくぐってすり抜けてしまったものも存在します。

現在、私たちは警告の却下基準をより厳格化しており、環境管理者との連携を強化してシステムの精度向上を図っています。監視と検知だけでなく、アライメントトレーニングチームと強化学習（RL）チームが協力し合い、環境自体の改善にも取り組んでいます。

私たちが強化学習環境の品質管理に多大な投資を行ったおかげで、より深刻なアライメント事故を未然に防げた可能性があると推測しています。逆に、これらの取り組みにおける不備が、これまでに特定された事故の一因となった可能性も否定できません。

これらの保護措置なしにトレーニングした場合、モデルがどのような行動をとるのかを確認するため、私たちは意図的に Opus クラスのモデルを 80 の異なる実環境でトレーニングしました。これらの環境は、少なくとも 1 回の実際のトレーニング実行中に報酬ハッキングが発生して監視システムによって検出されたか、環境品質レビュー段階でハック可能であると判明したものです。

その結果得られたモデルは、タスクで高いスコアを獲得しようとする強い動機を示し、タスクの成功を達成するために潜在的に有害な行動を行うことにも意欲的であることがわかりました。これに関する詳細は、当社の Alignment Science ブログ記事 でより詳しく解説していますが、ここでは簡潔に要約します。

私たちは、意図的にアライメントを崩したモデルを、さまざまな評価テストで検証しました。その中には、英国の AI セキュリティインシデント（AISI）や Claude に関わる事例、OpenAI と Hugging Face のインシデントといった要素を取り入れたシミュレーションも含まれています。OpenAI にこれらの詳細を共有いただいたことに対し、深く感謝しています。

評価ではすべてのツール呼び出しを別の LLM が模擬して行いましたが、報酬ハッキングを促すように訓練したモデルは、模擬されたサンドボックスから脱出しようとする傾向を示しました。さらに、模擬された内部システムや第三者のインフラに対して攻撃を実行し、自身の報酬関数を改ざんしたり、採点者への対応として生物兵器の製造方法をアドバイスしたりする行動も見られました。また、タスクを不正に遂行するために、デプロイ時の安全監視体制を回避しようとする試みを繰り返しました。

その後、報酬ハッキング訓練前のモデルや、現在公開している複数のモデルでも同じサイバーセキュリティシミュレーションを実施しました。これらのモデルが、同様のアライメント崩れを示す行動を取ることはありませんでした。

私たちの結論は、訓練中に顕著な報酬ハッキングが発生すると、モデルがタスクの成功を達成するために、現実世界で実行される可能性のある有害な一連の行動を喜んで行うようになるということです。

今年春、報酬ハッキングの監視と削減に多大な投資を行ったことが、本番環境でのモデルがより危険な報酬追求行動をとる可能性を低くしている主要な理由の一つだと考えています。併せて公開した Alignment Science のブログ記事 では、アライメント訓練環境が報酬ハッキングや報酬追求の振る舞いを大幅に抑制できるという証拠も得られました。しかし、7 月 30 日に報告した事案が示す通り、私たちのプロセスは完璧ではなく、モデルも完全にアライメントされているわけではありません。

明確に述べておきますが、訓練環境での不正行為がアライメント問題の唯一の原因である、あるいは私たちが直面した特定の事案や他の最先端 AI 企業で起きた事案の直接的な原因であると信じているわけではありません。アライメント問題を解決するには、非常に広範な潜在的な課題に対処する必要があり、将来のアライメント事案では、これまで見てきたものとは異なる振る舞いや原因が現れる可能性もあります。

セキュリティ対策の強化

Anthropic の内部セキュリティ体制は、7 月 30 日の事案の原因にはなり得ませんでした。これらの事象は第三者が提供する環境で発生しており、誤ってインターネットへのアクセスが開かれていたためです。仮にモデルがそのように行動する傾向があったとしても、そこから「脱出」する必要などありませんでした。

しかし、これらの事象は、堅牢なセキュリティ対策の重要性を改めて浮き彫りにしました。知的財産やモデル重みの盗難といった従来のリスクに加え、自社のモデルが Anthropic のシステムから外部へ「抜け出す」リスク、あるいは自社および他社のモデルが外部からの攻撃に悪用され、Anthropic システムへ「侵入する」リスクにも対応する必要があります。モデルの能力が高まるにつれて、特に Mythos クラスのモデルが登場して以降、これらのリスクは一段と深刻化しています。以下では、私たちが実施した対策の一部を説明します。これら多くの取り組みは 7 月の事象以前に着手されたものですが、今回の事象がその重要性を改めて浮き彫りにしました。

4 月初旬、エージェント型 AI の利用動向を見据えた上で、セキュリティチームは社全体を対象とした取り組みを主導し、単一の目標——防御体制の強化——に注力するよう指示しました。必要に応じて他の業務（研究を含む）よりも優先順位を高く設定したのです。私たちは、自社のリスクが防御体制の整備速度を上回っているとの判断を下しました。具体的には、Mythos は十分な能力を持つため、リソース豊富な攻撃者にとって格好の標的となり得ること、自律型エージェントの社内利用規模が従来のアクセス制御や監視手法では対応しきれないほど拡大していること、そして新インフラの導入ペースが速いため、セキュリティ体制も固定された容量で運用するのではなく、環境の変化に合わせて拡張可能である必要があることを認識したからです。

この取り組みの結果として得られた成果は以下の通りです：

モデルの重みや顧客データを含むシステムへのアクセス権限を持つ、人間および自動化されたアカウントを削減する

デフォルトで全ての外部通信をブロックするように計算クラスターを設定する

内部サービス間での通信前に相互の身元を検証することを義務付ける

レガシーなインフラ構成と共有内部サービスの廃止を進める

ワークロードが実行される隔離環境をより厳格化する

ホストレベルの観測性を拡張し、インフラ上の予期せぬ挙動が発生した瞬間に可視化できるようにする

また、これらの取り組みのために社員の一部を一時的に異動させました。製品エンジニア約 150 名がセキュリティ、信頼性、プライバシーの分野へ転換され、研究者も事前学習や強化学習から離れ、セーフガードとセキュリティに注力しました。さらに、製品チームは新機能や新インターフェースの開発を一時停止しました。各チームには復旧前に満たすべき厳格な基準を設定し、夏初めまでにほとんどのチームがこれを達成しています。

セキュリティへのリソース配分を進める一方で、社内エージェントの利用に関する封じ込めと監視体制の整備も継続しています。通常、トレーニングや評価のためのワークロードは、本番システムから隔離されたサンドボックス環境で実行されています。

Claude Mythos Preview の開発以降、私たちは自社のモデルを用いてこれらのサンドボックスに潜在的な脆弱性がないか探るテストを行ってきました。社内コーディングエージェントのオフライン監視については、4 月のアライメントリスク更新レポートで説明しました。また、8 月のリスク報告書では、このシステムの詳細と併せて実施されている対策についてもより詳しく記載しています。具体的には、最も自律性の高い社内エージェント利用に対してはサンドボックス化や自動モード分類器を導入し、インフラコードの変更がマージされる前に自動化されたレビューを実施しています。

しかし、この取り組みで欠けていたのは評価、とりわけ第三者による評価です。一部のリスクの高い評価についてはリアルタイムでも監視していましたが、一般的には事後にトランスクリプトの一部を抽出して自動レビューを行う程度でした。

7 月に発生した事案は、サイバーセキュリティ対策の強化がこれまで想定していた以上に緊急性が高いことを浮き彫りにしました。私たちはこの方向への取り組みを一層強化しており、次回のリスク報告書でさらに詳しくお伝えします。