エージェント型AIとは、単に質問へ回答するだけでなく、複数のツールや業務手順をまたいで計画を立て、行動できるシステムを指します。そのため評価では、回答の正確さだけでなく、次のような点も確認する必要があります。

• システムに何を実行する権限があるか
• 曖昧な指示や危険な指示をどう扱うか
• 想定外の行動を技術的に止められるか
• 人間による監督や介入が機能するか

また、多言語評価も重要です。プロンプトや悪意のある意図が異なる言語、表現、文化的文脈で示された場合、同じ安全策が一貫して働くとは限りません。今回のMOUが発表しているのは評価手法と研究の協力であり、特定モデルの配備ではありません。

2. 知識とガバナンスの共有

両者は、情報、ベストプラクティス、ガバナンスの枠組みを共有する方針です。これにより、技術的なテスト結果を実際の運用判断につなげることが期待されます。

たとえば、どのリスクを検証するのか、どの水準を合格とするのか、誰がモデルへアクセスできるのか、重大な弱点が見つかった場合に誰が何をするのか、といった論点です。

これは、モデルの性能をベンチマークだけで測る考え方とは異なります。ベンチマークで高得点を取ったモデルでも、アクセス権限、監視、脆弱性の開示、人間による監督体制が不十分なら、行政サービスや重要インフラで安全に使えるとは限りません。

3. フロンティアモデルへの「信頼できるアクセス」

MOUの3つ目の焦点は、フロンティアモデルへ安全にアクセスするための政策を検討することです。高い能力を持つモデルを、正当な安全性検証や有用な研究のために利用できるようにしつつ、その能力とリスクに見合う対策なしに広く開放することは避ける――という考え方です。

つまり、今回の協力は次のような多層的な安全策を志向しています。

1. AIシステムを検証する
2. 検証で得た知見を共有する
3. 必要に応じてアクセスを制限する
4. ガバナンスによって責任の所在を明確にする
5. 脆弱性の開示や修正を進める

Claude Mythosは関係するのか

Anthropicの未公開モデル「Claude Mythos Preview」は、フロンティアAIが持つ二面性を示す事例です。Anthropicによると、同社と約50のProject Glasswingパートナーは、この限定モデルを使い、社会や産業を支える重要ソフトウェアから1万件を超える高・重大度の脆弱性を発見しました。

Anthropicはさらに、Mythosが主要なOSやウェブブラウザーで、ゼロデイ脆弱性を含む弱点の特定と悪用が可能だったと報告しています。

この能力は、防御側にとっては大きな意味を持ちます。攻撃者に悪用される前に欠陥を見つけ、修正できる可能性があるためです。一方で、モデルが広く公開されたり、管理が不十分だったりすれば、脆弱性の発見から攻撃までの時間を短縮する危険もあります。

そのためAnthropicは、Mythosを一般公開せず、Project Glasswingを通じて限られたパートナーだけにアクセスを認めました。

ただし、現時点で確認できる情報は、Claude Mythosが6月12日のシンガポール・マイクロソフトMOUを直接引き起こした、あるいは締結を促したとは示していません。Mythosは、構造化された評価、アクセス管理、ガバナンスの枠組みがなぜ重要になっているのかを示す具体例として位置づけるのが適切です。

安全対策は現場でどう機能するのか

限定アクセスそのものが管理策になる

Project Glasswingの限定アクセスは、リスク管理の一環です。高リスクの能力を誰でも使える状態にせず、一定のパートナーに絞って防御目的の検証を行います。これにより、モデルの能力を調べながら、悪用される範囲を抑えられます。

もちろん、限定アクセスだけで十分な安全性が確保されるわけではありません。利用者の審査、利用状況の監視、安全な環境での取り扱い、責任ある開示が必要です。それでも、能力とリスクに応じてアクセスを管理するという、MOUの「信頼できるアクセス」の考え方を具体的に示しています。

脆弱性の発見後には修正が必要

脆弱性を見つけることは出発点にすぎません。シンガポールのサイバーセキュリティー庁（CSA）は、組織に対し、重大度が高い脆弱性へのパッチ適用、すべてのインターフェースやゲートウェイでの多要素認証、不要なアクセス権限の見直しなどを推奨しています。

こうした措置は、企業が原因を調査し修正するまでの間に、攻撃者が弱点を悪用できる可能性を下げるものです。

一方、Mythosが発見した約1万件の脆弱性の多くが、すでに修正されたと広く説明するのは慎重であるべきです。後続の評価では、保守担当者への開示が1,596件あった一方、修正されたのは97件だったと報告されています。

これはプロジェクトに防御上の価値がなかったという意味ではありません。しかし、「発見」「開示」「修正」は別の段階です。AI安全には、リスクの特定、責任ある開示、修正の優先順位付け、修正が終わるまでの露出低減を一体で進める仕組みが求められます。

マイクロソフトの役割と、MOUが確認していないこと

マイクロソフトは、フロンティアモデルの開発、企業向けインフラ、AIシステムへのアクセスを評価・管理する運用面で経験を持っています。今回のMOUの対象は、しかしながら単一のマイクロソフト製モデルに限定されていません。主眼は、フロンティアモデル全般を対象とする安全性評価と信頼できるアクセスの方法です。

提供された資料からは、マイクロソフト独自のMAIモデル、Azure AI Foundryを介したOpenAIやAnthropicのモデルへのアクセス、英国AI安全保障研究所や米国のAI標準・イノベーションセンターとの類似協定が、今回のシンガポール・マイクロソフトMOUの正式な内容であるとは確認できません。

したがって、これらを今回の合意に含まれる具体的な約束として扱うべきではありません。

目指すのは「信頼できるAIエコシステム」

今回の協力の意義は、単にAIをテストすることではありません。技術評価とアクセス管理、サイバーセキュリティー、政策設計を一つの安全の連鎖として考える点にあります。

• 評価する：高度なAIやエージェント型AIを、多言語環境も含めて検証する
• 共有する：技術的な発見、ガバナンスの実務、テストの教訓を交換する
• 管理する：リスクの高いモデルへのアクセスを能力に応じて制御する
• 対応する：脆弱性の開示、パッチ適用、多要素認証、権限管理を行う
• 制度化する：重要な環境で、いつ、どのような条件でフロンティアAIを使えるかを定める

このMOUだけでフロンティアAIの安全性が保証されるわけではありません。Claude Mythosが示したようなリスクも、合意によって解消されるわけではありません。

それでも、先端モデルの能力が高いことと、実際に利用する準備が整っていることを同一視しないための枠組みとして、今回の協力は意味を持ちます。安全で、堅牢で、信頼性があり、責任の所在が明確なAIエコシステムを構築するには、モデルの性能だけでなく、検証、アクセス、監視、修正、政策を一続きのプロセスとして設計する必要があります。

エージェント型AIとは、単に質問へ回答するだけでなく、複数のツールや業務手順をまたいで計画を立て、行動できるシステムを指します。そのため評価では、回答の正確さだけでなく、次のような点も確認する必要があります。

• システムに何を実行する権限があるか
• 曖昧な指示や危険な指示をどう扱うか
• 想定外の行動を技術的に止められるか
• 人間による監督や介入が機能するか

また、多言語評価も重要です。プロンプトや悪意のある意図が異なる言語、表現、文化的文脈で示された場合、同じ安全策が一貫して働くとは限りません。今回のMOUが発表しているのは評価手法と研究の協力であり、特定モデルの配備ではありません。

2. 知識とガバナンスの共有

両者は、情報、ベストプラクティス、ガバナンスの枠組みを共有する方針です。これにより、技術的なテスト結果を実際の運用判断につなげることが期待されます。

たとえば、どのリスクを検証するのか、どの水準を合格とするのか、誰がモデルへアクセスできるのか、重大な弱点が見つかった場合に誰が何をするのか、といった論点です。

これは、モデルの性能をベンチマークだけで測る考え方とは異なります。ベンチマークで高得点を取ったモデルでも、アクセス権限、監視、脆弱性の開示、人間による監督体制が不十分なら、行政サービスや重要インフラで安全に使えるとは限りません。

3. フロンティアモデルへの「信頼できるアクセス」

MOUの3つ目の焦点は、フロンティアモデルへ安全にアクセスするための政策を検討することです。高い能力を持つモデルを、正当な安全性検証や有用な研究のために利用できるようにしつつ、その能力とリスクに見合う対策なしに広く開放することは避ける――という考え方です。

つまり、今回の協力は次のような多層的な安全策を志向しています。

1. AIシステムを検証する
2. 検証で得た知見を共有する
3. 必要に応じてアクセスを制限する
4. ガバナンスによって責任の所在を明確にする
5. 脆弱性の開示や修正を進める

Claude Mythosは関係するのか

Anthropicの未公開モデル「Claude Mythos Preview」は、フロンティアAIが持つ二面性を示す事例です。Anthropicによると、同社と約50のProject Glasswingパートナーは、この限定モデルを使い、社会や産業を支える重要ソフトウェアから1万件を超える高・重大度の脆弱性を発見しました。

Anthropicはさらに、Mythosが主要なOSやウェブブラウザーで、ゼロデイ脆弱性を含む弱点の特定と悪用が可能だったと報告しています。

この能力は、防御側にとっては大きな意味を持ちます。攻撃者に悪用される前に欠陥を見つけ、修正できる可能性があるためです。一方で、モデルが広く公開されたり、管理が不十分だったりすれば、脆弱性の発見から攻撃までの時間を短縮する危険もあります。

そのためAnthropicは、Mythosを一般公開せず、Project Glasswingを通じて限られたパートナーだけにアクセスを認めました。

ただし、現時点で確認できる情報は、Claude Mythosが6月12日のシンガポール・マイクロソフトMOUを直接引き起こした、あるいは締結を促したとは示していません。Mythosは、構造化された評価、アクセス管理、ガバナンスの枠組みがなぜ重要になっているのかを示す具体例として位置づけるのが適切です。

安全対策は現場でどう機能するのか

限定アクセスそのものが管理策になる

Project Glasswingの限定アクセスは、リスク管理の一環です。高リスクの能力を誰でも使える状態にせず、一定のパートナーに絞って防御目的の検証を行います。これにより、モデルの能力を調べながら、悪用される範囲を抑えられます。

もちろん、限定アクセスだけで十分な安全性が確保されるわけではありません。利用者の審査、利用状況の監視、安全な環境での取り扱い、責任ある開示が必要です。それでも、能力とリスクに応じてアクセスを管理するという、MOUの「信頼できるアクセス」の考え方を具体的に示しています。

脆弱性の発見後には修正が必要

脆弱性を見つけることは出発点にすぎません。シンガポールのサイバーセキュリティー庁（CSA）は、組織に対し、重大度が高い脆弱性へのパッチ適用、すべてのインターフェースやゲートウェイでの多要素認証、不要なアクセス権限の見直しなどを推奨しています。

こうした措置は、企業が原因を調査し修正するまでの間に、攻撃者が弱点を悪用できる可能性を下げるものです。

一方、Mythosが発見した約1万件の脆弱性の多くが、すでに修正されたと広く説明するのは慎重であるべきです。後続の評価では、保守担当者への開示が1,596件あった一方、修正されたのは97件だったと報告されています。

これはプロジェクトに防御上の価値がなかったという意味ではありません。しかし、「発見」「開示」「修正」は別の段階です。AI安全には、リスクの特定、責任ある開示、修正の優先順位付け、修正が終わるまでの露出低減を一体で進める仕組みが求められます。

マイクロソフトの役割と、MOUが確認していないこと

マイクロソフトは、フロンティアモデルの開発、企業向けインフラ、AIシステムへのアクセスを評価・管理する運用面で経験を持っています。今回のMOUの対象は、しかしながら単一のマイクロソフト製モデルに限定されていません。主眼は、フロンティアモデル全般を対象とする安全性評価と信頼できるアクセスの方法です。

提供された資料からは、マイクロソフト独自のMAIモデル、Azure AI Foundryを介したOpenAIやAnthropicのモデルへのアクセス、英国AI安全保障研究所や米国のAI標準・イノベーションセンターとの類似協定が、今回のシンガポール・マイクロソフトMOUの正式な内容であるとは確認できません。

したがって、これらを今回の合意に含まれる具体的な約束として扱うべきではありません。

目指すのは「信頼できるAIエコシステム」

今回の協力の意義は、単にAIをテストすることではありません。技術評価とアクセス管理、サイバーセキュリティー、政策設計を一つの安全の連鎖として考える点にあります。

• 評価する：高度なAIやエージェント型AIを、多言語環境も含めて検証する
• 共有する：技術的な発見、ガバナンスの実務、テストの教訓を交換する
• 管理する：リスクの高いモデルへのアクセスを能力に応じて制御する
• 対応する：脆弱性の開示、パッチ適用、多要素認証、権限管理を行う
• 制度化する：重要な環境で、いつ、どのような条件でフロンティアAIを使えるかを定める

このMOUだけでフロンティアAIの安全性が保証されるわけではありません。Claude Mythosが示したようなリスクも、合意によって解消されるわけではありません。

それでも、先端モデルの能力が高いことと、実際に利用する準備が整っていることを同一視しないための枠組みとして、今回の協力は意味を持ちます。安全で、堅牢で、信頼性があり、責任の所在が明確なAIエコシステムを構築するには、モデルの性能だけでなく、検証、アクセス、監視、修正、政策を一続きのプロセスとして設計する必要があります。