こんにちは。弁護士の浅見隆行です。
米Anthropic社が2026年4月7日に発表した新型AI「Claude Mythos（クロード・ミュトス）」をめぐり、日本政府と金融機関の対応が急ピッチで進んでいます。
Mythosは、ソフトウェアの脆弱性を発見・悪用する能力が従来のAIを大きく上回るとされ、Anthropic社自身が一般公開を取りやめた、これまでにないモデルです。
4月24日には片山さつき金融担当相、日銀の植田和男総裁、3メガバンクの頭取らによる緊急官民連携会議が金融庁で開かれました。
5月14日には金融分野の官民作業部会が立ち上がっています。
5月18日には政府の関係省庁会議で、対策パッケージ「Project YATA-Shield」が取りまとめられました。
対象は、金融、情報通信、医療、電力、ガス、化学、クレジット、石油、航空、空港、鉄道、水道、物流、港湾、政府・行政サービスの15分野です。
体裁としては相当のスピードで整いつつあります。
その一方で、現場の実装には越えるのが容易ではないハードルがいくつも残っているのが実情です。
今回は、Claude Mythos対策の実装を阻む3つのハードルと、それぞれに対する実現可能な対応策を整理してみます。
ハードル①：自社システムの実態の可視化という、終わりのない地道な作業
把握できていない「自社システムの中身」
経営層も金融庁も、レガシーシステムと多重委託に問題があることは認識しています。
問題は、認識していることと、自社システムの中身を正確に把握できていることは、別の話だという点にあります。
レガシーシステムのどこに古いコードが残存しているか、多重委託の何階層下のベンダーが何を触っているか、自社ソフトの依存ライブラリはどこまで広がっているか。経営層も担当役員も、ここを正確に答えられる組織はそう多くないはずです。
正確に把握するためには自社システムの実態を可視化する棚卸しが必要です。
棚卸しは一度やれば終わりという作業ではありません。
新サービスのリリース、システムの更改、委託先の入れ替わりによって、自社システムの実態は日々変化しています。
こうした変化に追従して棚卸しを継続し続けられる組織だけが、Mythosのような自律的探索能力を持つAIに対して、防御の起点を持てる気がします。
既存の監査と取締役会報告に組み込む
対策としては、三つの方向が現実的だと思います。
一つ目は、既存の内部監査・システム監査の項目に「ベンダー単位での管理範囲マップの整備状況」を組み込むことです。
新規プロジェクトとして立ち上げるよりも、既存の業務に組み込んだ方が継続しやすくなるはずです。
二つ目は、四半期に一度、棚卸しの進捗を取締役会に報告する仕組みを作ることです。
経営層が「対応済み」と錯覚しないためには、進捗が継続的に経営のアジェンダに上り続ける状態を作る必要があります。
三つ目は、金融機関の場合、金融庁が2024年10月に公表した金融分野におけるサイバーセキュリティに関するガイドラインの点検作業と接続させることです。
同ガイドラインはサードパーティリスク管理を独立した節として位置づけており、棚卸しはここに直結します。
ハードル②：多重委託の中で「誰が直すのか」が決まらない
全銀ネット障害に学ぶ「真因特定にかかる時間」
仮にMythosのようなAIが脆弱性を瞬時に指摘したとしても、そこから先がまた別の壁です。
脆弱性が見つかったコード領域を、契約上、誰が直す責任を負うのか。
その契約は今も有効か。
書いた人間は今も社内にいるか。
こうした責任の所在確認だけで、相当の時間と労力がかかります。
実例として、2023年10月に発生した全国銀行データ通信システム（全銀システム）の障害を挙げます。
全銀ネットとNTTデータは、中継コンピューターの更改に伴ってOSを32ビットから64ビットへ変更した際、メモリの確保領域に不足が生じたと公表しています。仕向け・被仕向けの処理を合わせて、約566万件の振込が遅延しました。
全銀ネットとNTTデータはそれぞれ金融庁から報告徴求命令を受け、11月30日付で報告書を提出しました。
稼働開始から50年間、大規模障害がなかった全銀システムでも、不具合の真因特定までに約2か月かかったことになります。
責任あるベンダーが原因究明に全力を傾けても、これだけの時間が必要だったのです。
Mythosが探し当てるのは、もっと深い階層のコード領域です。何度かの再委託を経て、誰が書いたか分からなくなった、便宜上「孤児コード」と呼ぶべき領域だと推察します。
そうなると、現在の保守ベンダーに「Mythosが見つけた脆弱性を直してください」と頼んでも、「保守契約の範囲外（保守の対象に含まれていない。新規開発・追加開発に該当する）」「調査・作業に何人月必要」「弊社は当時の設計に関与していない」という回答が返ってくることが想定されます。
ベンダー資産マップと責任範囲の明文化から始める
対策としては、ベンダー資産マップの作成とベンダーごとの責任の範囲を明文化する作業が出発点になります。
ベンダー資産マップとは、どのコード、どのシステム、どのデータを、どのベンダーのどの契約に基づいて誰が管理しているかを一覧化したものです。
これを年1回更新し、ベンダー入れ替わり時には差分を必ず反映するルールを委託先管理規程の中に組み込みます。
そのうえで、主要ベンダーごとに責任の範囲を文書化したうえで合意し、緊急時の初動責任者をベンダー横断で事前指定しておくことが、実装の現場で時間を稼ぐ手段になります。
ベンダー側にしてみても、「うちはどこまでやるのか」が事前に決まっている方が動きやすいはずです。
ハードル③：契約改定のスピードという、見落とされがちな制約
LINEヤフーの行政指導が示した契約更新の遅さ
このハードルは、これまでの二つに比べて見落とされがちな問題です。
攻撃側はAIで秒単位の判断を回せる時代になりました。
これに対して、防御側は契約のリーガルチェックに時間がかかります。
実例として、LINEヤフーが2023年11月に公表した個人情報漏えい問題があります。
総務省は2024年3月5日付および4月16日付で、LINEヤフーに対して二度にわたる行政指導を行いました。
委託先管理の抜本的な見直し、親会社等を含むグループ全体でのセキュリティガバナンスの本質的な見直しなどが求められています。
LINEヤフーの事例が示すのは、いったん事が起きてから委託先管理を見直し始めても、相当の時間がかかってしまうという現実です。
攻撃側のスピードに、契約や規程の見直しがそもそも追いつかない、ということです。
緊急時のサイバー対応条項を主要ベンダーの契約に新たに入れ込もうとすると、契約相手との交渉、社内の法務確認、稟議、捺印という工程を、ベンダーごとに一件ずつ踏むことになります。
主要ベンダーが10社あれば、これだけで数か月単位の作業計画になります。
緊急時サイバー対応の覚書を法務主導で差し入れる
対策として、主要ベンダーに「緊急時サイバー対応覚書」を一括で差し入れる取り組みを、法務主導の年間プロジェクトとして立ち上げることが現実的だと思います。
主要ベンダーから順に、緊急時の協力義務、情報共有の範囲、調査受入れ義務、責任範囲の確認といった項目を盛り込んだ覚書を取り交わしていきます。
すべての契約を最初から書き換えるのではなく、覚書という形で差し入れることで、既存契約を温存しつつ緊急時の対応条項だけを上書きできます。
合わせて、フレームワーク契約と個別の作業指示書（SOW）方式に切り替え、緊急時の作業発注リードタイムを短縮することも検討に値します。
サイバー保険の補償範囲を、特にAI攻撃由来のインシデントについて更新確認しておくことも、見落とされがちな実務作業の一つです。
取締役会についても、サイバー緊急対応に関する意思決定権限の一部を執行側に事前委任しておく決議をしておけば、緊急時に取締役会の招集を待つことなく動ける態勢が整います。
おわりに
今回のMythosをめぐる動きで強く感じるのは、政府も金融庁もメガバンクも、問題自体は認識しているし、必要な手順も理解しているということです。
それでもなお、現場の実装には相応の時間とハードルがあるのが現実です。
経営層が踏まえておくべき点は、指針対応や作業部会への参加とは別軸で、自社実態の棚卸し、ベンダー資産マップの整備、緊急時サイバー対応覚書の差し入れという三つの実務作業を、並行して進めていくことだと思います。
全部を一度に進めるのは現実的ではありませんが、優先順位を付けて1年スパンで進めれば、十分に手の届く範囲にあるテーマです。
指針の体裁が整うことを「対応完了」と錯覚しない。
見えている課題でも、実装には相応の時間と手数が要るという現実を踏まえて、地道な作業計画を粛々と進める。
Mythosが浮き彫りにしたのは、この地味な姿勢の重要性だと思います。
企業の不祥事対応や第三者委員会のセカンドオピニオン等のご相談は、アサミ経営法律事務所お問い合わせフォームよりご連絡ください。
