リスク通信:「フロンティアAI時代のリスク対策 ~Claude Mythos PreviewとAIMS、そしてSCS★3・★4への接続~」

リスク通信59号
RISK REPORT 第59号

リスク通信:「フロンティアAI時代のリスク対策 ~Claude Mythos PreviewとAIMS、そしてSCS★3・★4への接続~」

※今号には生成AIによって作成された後に筆者が編集した文章が含まれます。
2026年6月発行

1.はじめに

2026年春以降、AIをめぐるリスク環境はさらに一段階変わったように見受けられます。米Anthropic社が公表した「Claude Mythos Preview」(同社の呼称に基づく)に代表されるフロンティアAIは、ソフトウェアの脆弱性を大量に発見する能力を示すとともに、同じような能力が攻撃者側に渡った場合には、脆弱性発見から悪用までの時間を大きく短縮し得ることも示しました。予てから言われてきたように、「AIは守る側の道具であると同時に、攻める側の道具にもなり得る」の現実性が更にはっきりしたものになったと言えます。しかも、その変化は「新しい対策を導入」という対策ではなく、むしろ、資産管理、脆弱性管理、アクセス制御、ログ監視、インシデント対応、バックアップ、委託先管理といった従来の対策を、リスクベースで絞り込み、より速く、より確実に実行することを求めています。

そこで今号では、Claude Mythos PreviewをはじめとするフロンティアAIがもたらす脅威を事例とともに紹介したうえで、その対策を行う上での考えを整理します。そして、そのための仕組みとしてISO/IEC 42001に準拠して構築されるAI Management System(AIMS)を紹介し、最後に、第58号を踏まえて、SCS認定★3・★4取得にAIMSの要素をどのように組み合わせるかを具体的に説明します。

2.Claude Mythos Previewに代表されるフロンティアAI

ここでいうフロンティアAIとは、現時点での最先端付近の能力を持つAIモデルを指します。単に会話が自然である、文章が上手である、というだけではありません。複雑なコードを理解し、複数の手順を組み合わせ、外部ツールを使い、試行錯誤を通じて目的を達成する能力が高まっている点が重要です。

Anthropic社は2026年4月にProject Glasswingを公表し、Claude Mythos Previewを用いて、世界中で利用されている重要ソフトウェアの脆弱性を防御側が先に発見・修正できるようにする取り組みを開始しました。同社の発表では、AWS、Apple、Broadcom、Cisco、CrowdStrike、Google、JPMorganChase、Linux Foundation、Microsoft、NVIDIA、Palo Alto Networksなどがローンチパートナーとして挙げられています。さらに、追加で40を超える重要ソフトウェア基盤の構築・保守組織にもアクセスを拡張したとされています。

また、2026年5月22日に公表された初期報告では、約50のパートナーとともにClaude Mythos Previewを利用した結果、重要ソフトウェアにおいて1万件を超える重大な深刻度の脆弱性を発見したとされています。従来、ソフトウェアセキュリティの制約は「どれだけ早く新しい脆弱性を見つけられるか」でした。しかし、AIによる発見速度が上がると、制約は「見つかった大量の脆弱性をどれだけ早く検証し、開示し、修正できるか」に移ります。

英国AI Security Institute(以下「英AISI」)も、Claude Mythos Previewのサイバーセキュリティ能力を評価し、従来モデルよりも一段高い能力を示したと公表しています。特に、制御された評価環境において、脆弱なネットワークに対する多段階攻撃を実行し、脆弱性を自律的に発見・悪用できることが観察されたとされています。ここで重要なのは、「AIがただ答えを出す」段階から、「AIが手順を組み立て、ツールを使い、攻撃や防御の作業を進める」段階へ進みつつあることです。

Claude Mythos Previewは、現時点で一般に広く公開されているわけではありません。Anthropic社自身も、限定提供の研究プレビューとして扱い、リスク評価や内部監視、セキュリティ管理策を公表しています。この点は過度な不安を避けるためにも押さえておく必要があります。しかし同時に、同社が限定提供として慎重に扱っていること自体が、同等水準の能力を持つAIが広く利用可能になった場合の影響の大きさを示しているとも言えます。

3.フロンティアAIがもたらす脅威

フロンティアAIがもたらす脅威は、従来のサイバー攻撃とはまったく別物というより、従来の攻撃の速度、規模、精度を引き上げるものとして捉えるのが適切です。攻撃者の作業能力が急に増える、と言った方が実務上は分かりやすいかもしれません。主な脅威を整理すると次のようになります。

脅威事例・状況実務上の意味
脆弱性発見・悪用の高速化Claude Mythos Previewは、実際のオープンソースコードや重要ソフトウェアに対して多数の脆弱性候補を発見し、悪用可能性の検証にも高い能力を示したと報告されています。資産台帳、SBOM、脆弱性情報収集、パッチ適用、暫定緩和策、例外管理を「見つけたら対応」ではなく「重要資産から先に潰す」形に変える必要があります。
攻撃手順の自動化・多段階化英AISIは、制御された環境において、多段階攻撃の実行や脆弱性の自律的な発見・悪用を観察したと公表しています。侵入前提の防御、最小権限、ネットワーク分離、EDR・SIEM、出口通信制御、認証情報保護、復旧手順がより重要になります。
エージェント利用時の権限誤用AIエージェントがファイル、ブラウザ、開発環境、クラウドAPIなどに接続されると、プロンプトインジェクションや誤指示によって想定外の操作が行われる可能性があります。エージェントだけで止めるのではなく、サンドボックス、外部送信制限、秘密情報の分離、承認フロー、操作ログ、実行権限の固定化で環境側を制御します。
ビジネスメール詐欺・なりすましの高度化Project Glasswingの初期報告では、パートナー銀行において、顧客メール侵害と偽電話を組み合わせた150万ドルの不正送金を防ぐ用途にも有効だった例が紹介されています。これは裏返せば、攻撃側の手口もAIで高度化し得るということです。送金・口座変更・緊急依頼に対する折返し確認、複数人承認、音声・映像を過信しない手順、教育訓練、ログ確認を徹底します。
誤出力・バイアス・過信高性能なAIほど、出力が自然で説得力を持つため、誤りや偏りに気づきにくくなります。前号以前で紹介した生成AIの誤出力リスクは、より大きな業務影響を持つようになります。Human in the Loop、出力検証、利用目的の限定、重要判断での二重確認、記録保存、モデル変更時の再評価が必要です。

これらを一言でまとめると、「AIによって攻撃者の探索能力と試行回数が増える」ということです。攻撃者が一人で数日かけて行っていた調査や試行を、AIが短時間で大量に実行できるようになると、防御側の遅れはそのまま被害に直結します。特に、インターネット公開資産、VPN、リモートアクセス、クラウド管理画面、SaaSの権限設定、公開リポジトリ、委託先接続などは、AI支援攻撃の最初の探索対象になりやすいと考えるべきです。

一方で、AIは防御側にも大きな力を与えます。脆弱性の発見、設定不備の確認、ログ分析、コードレビュー、教育コンテンツ作成、インシデント初動整理などでは、すでに防御側の能力を引き上げる道具として使われ始めています。従って、重要なのは「AIを使うか使わないか」ではなく、「AIをどの範囲で、どの権限で、どの証跡を残して使うか」です。

4.対策:「従来の対策をリスクベースで絞り込んで早くやる」が本質

では、そのようなAIがもたらすサイバーセキュリティリスクへの対策はどのように行うべきなのでしょうか。それは、「新しい対策の導入」ではなく、むしろ、従来の対策を、リスクベースで絞り込み、より速く、より確実に実行することです。つまり、「従来の対策をリスクベースで絞り込んで早くやる」ことが本質と言えます。

無論、AI固有の対策は確かに存在します。たとえば、AI利用台帳、AIリスク評価、AI影響評価、プロンプト・出力ログ、AIエージェントのツール権限制御、モデル変更時の再評価、RAGに投入するデータの管理、AI利用に関する委託先管理などです。しかし、これらはまったく新しい対策ではありません。従来の資産管理、アクセス制御、ログ管理、変更管理、委託先管理、教育、インシデント対応を、AI利用に合わせて拡張したものです。すなわち、「従来の対策」の範囲を出るものではありません。

また、「早くやる」とは、全部を雑に急ぐことではありません。フロンティアAI時代には、全社全項目を均等に少しずつ進めるやり方では間に合いません。重要業務、重要情報、外部公開資産、攻撃されると停止影響が大きいシステム、取引先と直接つながるシステム、AIに権限を与えている業務を先に特定し、そこから対策を深く実装する必要があります。つまり、「行うべき対策をリスクベースで絞り込むことで、早くやる」ことです。

具体的な対策の順番は次のようになります。

1.何を守るのかを決める:重要情報、重要業務、公開資産、クラウド、SaaS、取引先接続などにおけるAI利用シーンを棚卸し。

2.どこが危ないのかを決める:AIで攻撃・誤用・情報漏えい・判断誤りが起きた場合の影響を評価。

3.どこから対応するかを決める:事業影響、攻撃可能性、外部露出、取引先要請、復旧困難性などを基準に優先順位付け。

4.証跡を残して実行:台帳、ログ、設定画面、教育記録、訓練記録、是正記録を残す。

5.見直す:AIモデル、利用業務、委託先、攻撃手法は変化するため、年次ではなく必要に応じて見直す。

そして、早く、確実に行うには、行う対策を絞り込むことに加えて、一連の対策を組織立てて行う仕組みが必要です。その候補として、次に紹介するAIMSが有用になります。

5.AIMSとは

AIMSとは、AI Management Systemの略であり、AIの開発、提供、利用に伴うリスクと機会を組織として管理するためのマネジメントシステムです。ISO/IEC 42001は、組織におけるAIMSの確立、実施、維持、継続的改善に関する要求事項を定めた国際規格です。ISOは、同規格を、AIに関する世界初のマネジメントシステム規格と位置付けています。

経済産業省も、ISO/IEC 42001について、AIシステムを開発、提供、利用する組織を対象とし、リスクベースアプローチに基づいて必要なリスク管理体制を整備するための要求事項を定めたものとして紹介しています。また、AIの真正性、説明責任、信頼性、公平性、個人のプライバシー、学習データや機械学習といったAI固有の要素を考慮している点を説明しています。

AIMSは、AIを使うための許可証ではありません。また、AI製品を導入すれば自動的にできるものでもありません。むしろ、「自社はどのAIを、どの目的で、どのデータと権限を与えて使い、どのリスクを許容し、どのリスクは低減し、誰が見直すのか」を決める仕組みです。

AIMSの要素実施内容
AI利用範囲・台帳どの部門が、どのAIサービス・モデル・エージェントを、どの業務で使っているかを一覧化します。シャドーAIの把握も含みます。
AI方針・責任体制AI利用の原則、禁止事項、承認ルール、責任者、経営層への報告経路を定めます。
AIリスク評価・影響評価情報漏えい、誤出力、差別・バイアス、著作権、セキュリティ、業務停止、委託先依存などを評価します。
AIリスク対応計画入力禁止情報、HITL、ログ保存、ツール権限制御、モデル変更時の再評価、外部送信制限などを計画化します。
AIライフサイクル管理AIの導入、設定、運用、監視、変更、停止、廃止までを管理します。
委託先・提供者管理AIサービス提供者、クラウド、RAG基盤、開発委託先について、契約、データ利用、ログ、再委託、障害時対応を確認します。
継続的改善AI利用実績、インシデント、監査結果、利用者からのフィードバックを踏まえて改善します。

AIMS認証の取得まで目指すか否かは各組織の判断ですが、少なくとも上記の要素を抽出して実行することには、直ちに効果をもたらす実務的な意味があります。

6.AIMSは既存のセキュリティ対策と組み合わせて使う

AIMSを導入する際に避けるべきなのは、「AI専用の別管理」を作ってしまうことです。AIリスクは、情報セキュリティ、個人情報保護、知的財産、品質、法務、内部統制、BCP、委託先管理と密接に関係しています。AIだけを別の台帳、別の会議、別の承認ルートで管理すると、かえって現場の負担が増え、見落としも生じやすくなります。

むしろ、AIMSは既存のセキュリティ対策に組み込むことで効果と効率が増します。たとえば、既にクラウド台帳があるなら、そこにAIサービス利用の有無、学習利用の可否、保存されるログ、外部送信されるデータ、委託先の所在地、管理者を追加します。既にインシデント対応手順があるなら、そこにAIの誤出力、機密情報の入力、プロンプトインジェクション、エージェントの誤操作、AIサービス障害を追加します。既に委託先管理があるなら、AIサービス提供者のデータ利用条件や監査可能性を確認項目に加えます。

ここで有効なのが、第58号で述べた「証跡台帳」の拡張です。SCS用の証跡台帳に、AI利用台帳、AIリスク評価、AI利用規程、AI教育記録、AIログ、モデル・サービス変更履歴、AIインシデント記録、AIサービス提供者確認記録を紐づければ、SCS取得準備とAIMS整備を別々に進める必要がありません。

AIMS認証の取得まで進む場合には、ISO/IEC 42001の要求事項に沿って、AIMSの適用範囲、方針、リスク評価、内部監査、マネジメントレビューなどを整えることになります。しかし、そこまで至らない場合でも、AIMSの必要要素を抽出して実行することで、SCS認定取得と並行して、AIリスクへの実効的な対策を進めることができます。

7.SCS★3・★4取得にAIMSをどう組み合わせるか

第58号で整理したように、SCS★3は専門家確認付き自己評価であり、取得希望組織が自己評価を行い、セキュリティ専門家の確認・助言・署名、経営層の自己適合宣誓を経て、事務局への提出・台帳登録へ進みます。★4は第三者評価に加えて技術検証が明示されており、文書確認だけでなく、実地審査、設定、ログ、技術的実装を説明できる状態が必要です。また、評価対象は適用範囲の中からサンプリングされる想定であるため、特定のシステムだけをきれいに整えるのでは不十分です。

この前提にAIMSを組み合わせる場合、最初に行うべきことは、SCSの適用範囲とAI利用範囲を重ねることです。たとえば、SCSの適用範囲に含まれる部門、クラウド、SaaS、社内システム、外部公開資産、取引先接続について、「AIを利用しているか」「AIにどのデータを入力しているか」「AIがどのシステムへアクセスできるか」「AI出力がどの業務判断に使われるか」を確認します。

従って、★3と★4では、AIMSの使い方を少し変えるのが現実的です。

★3で組み合わせるAIMS要素実施方法SCS上の意味
AI利用台帳の作成部門、利用AI、利用目的、入力データ、出力利用先、管理者、契約形態を一覧化します。SCSの適用範囲・資産台帳・クラウド/SaaS一覧の補助証跡として使います。
AI利用ルール機密情報、個人情報、取引先情報、未公開コード、認証情報を入力しない、又は承認制にするなどのルールを定めます。情報保護、教育、規程整備の証跡になります。専門家確認時に「AI利用を放置していない」ことを示せます。
AIリスク評価AI利用ごとに、情報漏えい、誤出力、著作権、業務影響、委託先依存、セキュリティ影響を評価します。要求事項対応表の優先順位、例外承認、是正計画の根拠になります。
経営層説明資料AI利用の範囲、重大リスク、未対応事項、是正期限、残リスクをまとめます。★3の経営層自己適合宣誓の前提資料になります。
教育・訓練記録AI利用禁止事項、出力確認、なりすまし・BEC、プロンプトインジェクションの基礎を教育します。従業員教育、インシデント対応訓練、是正記録として証跡化できます。

★3では、AIMSの目的を「AI利用の把握と説明可能性の確保」に置くことをお勧めします。専門家が確認し、経営層が宣誓する以上、少なくとも「どのAIを、どの業務で、どの情報とともに使っているか分からない」という状態は避ける必要があります。逆に、AI利用台帳、AIリスク評価、入力ルール、教育記録、是正計画があれば、SCSの証跡台帳にAIの観点を追加するだけで、かなり説明しやすくなります。

★4で組み合わせるAIMS要素実施方法SCS上の意味
AIエージェント権限制御AIが実行できるツール、アクセス可能なフォルダ、クラウド権限、外部通信先を制限します。★4の技術検証で、最小権限、外部送信制御、認証情報保護を示す証跡になります。
AI利用ログ・監視プロンプト、出力、ツール実行、API利用、管理者操作、例外承認を記録し、必要に応じてSIEM等へ連携します。文書だけでなく実装・運用を示せます。インシデント時の追跡性も高まります。
AIシステムの技術テストプロンプトインジェクション、情報漏えい、誤出力、権限逸脱、RAG汚染、モデル変更時影響をテストします。★4の実地審査・技術検証に向けた模擬評価として使えます。
AIサービス提供者評価データ利用、保存期間、再学習利用、ログ、所在地、再委託、障害時対応、脆弱性開示を確認します。サプライチェーン管理、委託先管理、クラウド/SaaS管理の証跡になります。
AI停止・代替手順AIサービス障害、誤動作、利用停止時に業務を継続する手順を整えます。BCP・復旧体制の補強になります。AI依存による業務停止リスクを低減します。

★4では、AIMSの目的を「技術的実装と運用実態を見せられる状態」に置く必要があります。特に、AIエージェントにクラウド、開発環境、ファイル、メール、チケット管理、ブラウザ操作などの権限を与える場合、AIは単なる文章生成ツールではなく、業務システムに接続された実行主体になります。この場合、AI利用の是非だけでなく、AIが何をでき、何をできず、何を実行したかを説明できることが重要です。

Anthropic社のエンジニアリング記事でも、ユーザー自身が直接入力した悪意ある指示に対しては、モデル層の防御だけでは検知が難しい場合があり、外部送信制御やファイルシステム境界など環境側の防御が重要である旨が説明されています。これは、SCS★4の技術検証を意識する企業にとっても重要な示唆です。AIの安全性を「モデルが賢く拒否してくれる」ことだけに依存せず、ネットワーク、権限、秘密情報、ログ、承認という従来型の管理策で包む必要があります。

8.AIMSを使ったSCS★3・★4並行準備のロードマップ

前節に続いて、SCS認定取得準備とAIMS整備を並行して進めるロードマップを示します。なお、AIMS認証取得を前提にしない場合でも、この順番で進めることで、AIリスクへの対策とSCS取得準備を一体化できます。

段階実施事項到達状態
第1段階:棚卸しSCS適用範囲、資産台帳、クラウド/SaaS一覧、取引先接続、AI利用台帳を作成・統合する。「何を守るか」「どこでAIを使うか」が見える状態にする。
第2段階:方針・ルールAI利用方針、入力禁止情報、承認が必要な利用、AIエージェント権限、ログ保存方針を定める。★3の専門家確認と経営層宣誓に耐える最低限のルールを作る。
第3段階:リスク評価AI利用ごとのリスク評価を行い、重要業務・重要情報・高権限AIを優先する。SCS要求事項対応表の優先順位付けと是正期限を決める。
第4段階:技術実装アクセス制御、MFA、ログ、DLP、外部送信制限、サンドボックス、秘密情報分離、バックアップを整える。★4の技術検証を見据え、設定・ログ・画面証跡を残す。
第5段階:レビュー・改善専門家レビュー、模擬審査、AI利用監査、インシデント訓練を実施する。指摘事項を是正し、証跡台帳を更新する。
第6段階:申請・継続運用公式様式や評価ガイドに合わせて自己評価票、証跡台帳、経営層資料を更新する。SCS登録後も、AI利用の変更・追加に応じて継続的に見直す。

このロードマップの勘所は、AIMSを「後から追加するAI対応」ではなく、SCSの準備段階から組み込むことです。SCSの評価対象にAIそのものが明示的に含まれていない場合であっても、AIが社内の情報、クラウド、SaaS、業務判断、取引先対応に関わっているなら、評価時に説明を求められる可能性は十分にあります。特に★4を目指す場合、AIエージェントの権限、ログ、外部通信、データ保護は、技術検証の対象になり得ると考えて準備しておくべきです。

反対に言えば、SCSの準備をAIMS整備の機会として使うこともできます。SCSのために資産台帳を整えるなら、AI利用も同時に棚卸しする。SCSのためにインシデント手順を整えるなら、AIインシデントも含める。SCSのために委託先管理を整えるなら、AIサービス提供者も含める。このようにすれば、AIMS認証取得に至らない段階でも、AIリスク対策の実効性は大きく高まります。

10.おわりに

今号では、Claude Mythos PreviewをはじめとするフロンティアAIがもたらす脅威を紹介し、その対策を整理した上で、その手段としてAIMSを紹介して、SCS認定取得と組み合わせる方法を提案しました。

重要なのは、AIに対して過度に恐れることでも、逆に万能視することでもありません。AIは、攻撃者の能力を高めると同時に、防御側の能力も高めます。ただし、防御側がその恩恵を受けるには、自社の資産、データ、業務、権限、委託先、ログを把握し、重要なところから対策を実装する必要があります。

AIMSは、そのための有効な整理軸になります。ISO/IEC 42001に準拠したAIMSを正式に構築し、認証取得を目指すことも一つの選択肢です。しかし、そこまで進まなくても、AI利用台帳、AIリスク評価、AI利用方針、権限制御、ログ、委託先管理、教育、インシデント対応といった必要要素を抽出して実行することには大きな意味があります。

そして、それらの要素は、SCS認定★3・★4取得準備とも自然に接続できます。第58号で述べたように、SCS取得では、要求事項を満たすだけでなく、専門家、評価機関、経営層、事務局、取引先に説明できる証跡が重要になります。AIMSの要素をSCS証跡台帳に組み込めば、AIリスク対策とSCS取得準備を同時に進めることができます。

フロンティアAIの登場は、サイバーセキュリティ対策を「いつかやるもの」から「今、優先順位を決めて実行するもの」へ変えつつあります。新しい流行語に振り回されず、しかし変化の速度を侮らず、従来の対策をAI時代に合わせて再設計し、リスクベースで絞り込んで早く実行すること。それが、現時点で最も堅実で、最も実務的な対応だと考えます。

最後までお読みいただき、ありがとうございました。

参考記事・文献

Anthropic「Project Glasswing」 https://www.anthropic.com/project/glasswing

Anthropic「Project Glasswing: An initial update」 https://www.anthropic.com/research/glasswing-initial-update

Anthropic Frontier Red Team「Assessing Claude Mythos Preview’s cybersecurity capabilities」 https://red.anthropic.com/2026/mythos-preview/

Anthropic「Alignment Risk Update: Claude Mythos Preview」 https://www.anthropic.com/claude-mythos-preview-risk-report

UK AI Security Institute「Our evaluation of Claude Mythos Preview’s cyber capabilities」 https://www.aisi.gov.uk/blog/our-evaluation-of-claude-mythos-previews-cyber-capabilities

Anthropic「How we contain Claude across products」 https://www.anthropic.com/engineering/how-we-contain-claude

ISO「ISO/IEC 42001:2023 - AI management systems」 https://www.iso.org/standard/42001

経済産業省「AIマネジメントシステムの国際規格が発行されました」 https://www.meti.go.jp/press/2023/01/20240115001/20240115001.html

IPA「サプライチェーン強化に向けたセキュリティ対策評価制度(SCS評価制度)」 https://www.ipa.go.jp/security/scs/index.html

IPA「SCS評価制度の詳細情報」 https://www.ipa.go.jp/security/scs/details.html

経済産業省「サプライチェーン強化に向けたセキュリティ対策評価制度に関する制度構築方針」 https://www.meti.go.jp/press/2025/03/20260327001/20260327001.html

当リスク通信 第58号「SCS評価制度の詳細情報と不適切勧誘への対応 ~第57号からの更新差分と、正しい認定取得の進め方~」

当リスク通信 第45号「生成AIに関連するリスクと対策 ~最新の事例と考察を元に~」 2025年3月31日

当リスク通信 第44号「DeepSeekショック分析 ~DeepSeekとデータ漏洩から見る生成AIを使うリスクと対策~」 2025年3月2日

―以上―

投稿者プロフィール

サイバーレジリエンス
サイバーレジリエンス