「検証環境が壊れている組織は『素振り』すらできない」 フロンティアAIの脅威に“正しくおびえる”方法：開発現場や経営層はどう向き合うべき？ 専門家に聞いた

AIを悪用したサイバー攻撃がスケール可能となる中、AIを悪用して企業のシステムを侵害したというケースが顕在化している。防御側もAIを活用すべきであることに論をまたないが、AIを生かそうにも、多くの組織は「試す前」の段階に課題を抱えているという。今すぐ見直すべき現場の弱点、経営層に必要な2つの「意識改革」とは何か。

[石川俊明，＠IT]

　米政府の輸出管理指令に伴う「Claude Fable 5／Mythos 5」の公開停止は、企業に新たなAI利用のリスクを突きつけた（参考記事）。一方で、サイバーセキュリティの最前線において本当に恐れるべきことは、フロンティアAIの能力に限らない。すでに広く流通している既存モデルでも、ビジネスを脅かすサイバー攻撃がスケール可能になっているという現実だ。

　「多くの開発現場では、防御にAIを試す以前の段階でつまずいている」

　こう警鐘を鳴らすのが、GMO Flatt Securityの米内貴志氏（取締役副社長Co-CTO〈最高技術責任者〉）だ。攻撃側がAIをサイバー攻撃に実戦投入することがすでに進行しつつあるといっても過言ではない今、普通の組織はAIを悪用したサイバー攻撃から自組織を守るために、何をどう見直すべきなのか。同氏に明日からできる対策のポイントを聞いた（※取材は6月下旬〈Fable 5／Mythos 5の再公開前〉に実施）。

フロンティアAIが“武器”と同等の扱いに

――「Claude Fable 5」や「Mythos 5」が米政府の輸出管理指令によって一時公開停止となった動きは、大きな衝撃を与えました。一連の動きをどのように受け止めていますか。

GMO Flatt Security 取締役副社長Co-CTO 米内貴志氏

米内氏　AIが一国の輸出規制の対象になったということは、フロンティアAIがある種の「武器」や「核兵器」と同等の扱いを帯びるようになったという歴史的な転換点だと捉えています。

　ただ、セキュリティの現場にいる人間として率直に申し上げると、今回の公開停止は少し「やり過ぎではないか」という懐疑的な見方もしています。Fable 5のようなフロンティアAIを規制したところで、一般流通している既存モデルでも、十分に高度なサイバー攻撃を実行できる能力が備わっているためです。

　一般企業には、今回の公開停止による直接的な悪影響はそれほど大きくなかったと考えています。問題は、金融や医療といった極めてミッションクリティカルかつ「国家系アクター」から粘着質に狙われやすい重要インフラ組織です。

　サイバーセキュリティという文脈でのAIモデルの進化がもたらす本質は「重箱の隅を突けるようになること」にあります。既存モデルでも一般的な脆弱（ぜいじゃく）性を突くことは十分に可能ですが、国家から狙われるような重要インフラを守るためには、その「重箱の隅」に潜む高度な隙まで先回りして防御側が投資し、検証しておく必要がありました。

　しかし、そのための「武器」が米国政府の判断で一時的に使えなくなってしまった。これは米国以外の国の重要インフラ組織にとって、非常に厳しい防衛上のビハインドになったと感じています。特定ベンダーや特定一国のAIモデルに依存するビジネスリスクが明確になりました。

　ベンダーに輸出規制をかけられたら、利用組織側はどうしようもありません。今後は「学習は米国で行われても、最悪の事態に備えて手元にウェイト（データ）があり、国内リージョンで推論を継続できるオープンウェイトモデル（「DeepSeek」「Qwen」など）」も視野に入れた、マルチモデル戦略への転換が不可欠になると実感しています。

企業を侵害するのに「最先端の知性」は不要　AIを悪用した攻撃はスケール可能なフェーズに

――貴社では「AIペネトレーションテスト機能」の実装において「Fable 5」の採用を見送り、既存の「Opus 4.8」モデルを選択されたとのことですが、既存モデルで十分に実戦に耐え得ると判断された理由をお聞かせいただけますか。

　私のX（旧Twitter）でも発信しましたが、結論から言うと「通常のシステム侵害は大抵もっとシンプルで、これ以上の知性は不要」だからです。

　攻撃者が好んで狙うのは、再現条件が緩やかで影響範囲が広い脆弱性や、VPN（仮想プライベートネットワーク）機器をはじめとする設定の不備です。「特定組織の特定システムだけを狙う独自の複雑な脆弱性」を狙うのは、標的型攻撃の特殊なケースを除けば、攻撃者にとっても探すコストが見合いません。

　Anthropicが公開しているClaudeのシステムカードによると、既知の脆弱性に対するエクスプロイト（悪用）成功率は、Claude Opus 4.8の段階で約7割に達しています。Mythos 5は同結果が9割で、その差は2割です。実社会で企業がサイバー攻撃に遭うポイントの多くは、すでにOpus 4.8がカバーしている7割の範囲に収まっていると考えるべきです。

Claude Opus 4.8／Mythos Preview／Mythos 5におけるFirefoxエクスプロイト開発の成功率　Opus 4.8の段階で、何らかの成果（any-success）を得る割合はすでに約7割（68.8%）に達している。最新のMythos 5ではその割合が9割（90.0%）に達している（Anthropicのシステムカードより引用）

――Opus 4.8レベルのAIを利用して攻撃を仕掛ける場合、そうした設定ミスやシステムの脆弱性はどれくらいの時間で見抜かれてしまうものなのでしょうか。

　インターネット越しに自律的なAIエージェントを走らせた場合、システムの規模にもよりますが、不備が存在していれば「およそ1時間」で見つけてしまいます。

　これまでは、スキルの高いホワイトハッカーが人間技で丸1〜2日かけて見つけられるかどうかという状況でした。それがわずか1時間に圧縮され、しかも攻撃者側はAIを兵隊のように何十体、何百体と並列で同時に走らせてスケールできるようになった。ここに攻撃側と防御側の圧倒的な非対称性があります。

GMO Flatt SecurityではAIを活用して複数のペネトレーションテストを並列実行しているという（画面はデモ）（提供：GMO Flatt Security）

――以前の世代のモデル（「Sonnet 3.5」など）と、Opus 4.8水準のモデルでは、何が違うのでしょうか。

米内氏　「ゴールの達成能力」（逆算能力）が劇的に変わりました。

　「クラウドサービスのこのトークンを盗み出せ」「システムから機密データを引っこ抜け」という大ざっぱな高次のゴールを渡したとき、Opus 4.8水準のエージェントは自律的にキルチェーン（攻撃プロセス）を組み立てます。ターゲット環境で動いているものを自ら識別し、検索して脆弱性を見つけ、最初の侵入ポイントからシステムを2つ3つと経由して、最後まで粘り強く攻撃を完遂する能力がすでにあります。

　以前の世代のモデルでは途中で諦めたり、1個試してダメならスタックしたりすることが多かったものの、Opus 4.8水準のモデルは「長く自律的に考えること」が得意です。このスケール感を持った知性が攻撃者の手元にあるという事実こそ、われわれが今最も危機感を持つべき事態です。

「検証環境が壊れている組織は“素振り”すらできない」　開発現場の弱点と対策

――防御側である開発組織も、AIを使って自社の「あら探し」をして備えるべきだと提言されています。明日から取り組むとしたら、何をどう見直すべきですか。

米内氏　まずお伝えしたいのは「プロンプトの『秘伝のタレ』（工夫）を模索するのは、もうやめましょう」ということです。

　よく「AIに精度の高いコードレビューをさせるための効果的なプロンプトのコツを教えてほしい」と聞かれますが、プロンプトエンジニアリングはもはや不要です。

　自社独自のチェックリストやISMS（情報セキュリティマネジメントシステム）のルールを長々とプロンプトに落とし込もうとする組織が多い印象ですが、これはむしろ逆効果です。日本のISMSのルールは「人間と会社の契約関係」に引っ張られ過ぎている部分があり、AIにとっては不要な制約になりがちです。

　現在の優れたモデルに対しては、Anthropicの公式ガイドにも記載されているような、「大ざっぱなゴール設定」――つまり「このコードベースの設定の中で、悪用できるリスクを探して」と丸投げする方が、圧倒的にノイズ（誤検知）も減り、高い正確性でリスクを見抜いてくれます。

ペネトレーションテスト後に自動生成された報告書の画面（デモ）　AIに大ざっぱなゴール設定を与えると、自律的にターゲット環境を探索して「システム構成図」をマッピングし、発見した脆弱性や再現方法までまとめるという。攻撃者側も同様のことが実行可能なフェーズに入っていることになる（提供：GMO Flatt Security）

　手元のサブスク型AIに、そのまま「これ大丈夫？」と聞いてみるだけの「素振り」から始めるだけでも十分です。

　プロンプトよりも、開発組織が明日から見直すべき致命的なボトルネックが他にあります。それが、本番同様に正しく動作する検証環境（ステージング環境）を、いつでも検証できる状態で維持できているかどうかという点です。

――検証環境の維持、ですか。

米内氏　弊社が人間による脆弱性診断サービスをクライアントに提供する中でも、われわれが価値を発揮し切れなくなる最大の原因は「検証用の環境がバグっていて動かない」「本番とバージョンがズレている」という、テスト環境の不備です。

　どんなに優れたAIエージェントに「あら探し」（ペネトレーションテスト）をさせようとしても、動かないソースコードや本番環境と異なるコードを見せるだけでは意味がありません。

　しかし多くの組織では、ビジネスサイドの締め切りに追われ、リリース直前のギリギリのタイミングまで開発環境をガチャガチャと触っていて、結果として検証環境が全く安定していないケースも多いのです。

　AI時代の開発プロセスにおいて、人間の役割は「自分でコードを書くこと」から、「AIが作った成果物が安全に動くかどうかを検証する環境（ハーネス）を整えること」へとシフトしていきます。

　本番環境を誤って破壊しないようネットワークや権限を絞り込んだ「強力な試験環境」を即座に、安定して立ち上げられるインフラ基盤。これがない組織は、AIを使った防御の「素振り」すら難しく、スタートラインに立てないのです。

――AIエージェントを自社で安全に実行させるための「ハーネス」（※）は、どう設計するのがポイントになるでしょうか。　※：AIモデルを取り囲む実行環境や、AIに渡すツール群〈API〉の制御レイヤー

米内氏　 結論から言うと、「モデルに自由をさせてあげること」と「ゴール設定を明確にすること」です。そうしたハーネスを作ってあげることが重要だと思っています。逆に言うと「検証してはいけない環境に対するアクセス」をモデルに渡すのは、それはそれでビジネスリスクなわけです。単純に本番環境を間違えて攻撃してしまうこともありますし、モデルを監督できない状態でプロンプトインジェクションをされた場合、突然あちこちを攻撃し始めるリスクがあります。

　AIエージェントがどう暴走しても、物理的・ネットワーク的に検証用のステージング環境以外には一切アクセスできないように権限を絞り込んでおくことが重要です。「ここなら最悪落ちても事業に影響はない」と断言できるセキュアな隔離環境（サンドボックス）を構築し、AIに与えるAPIキーの権限を最小限に絞り、監視とレートリミットをかける。この境界線をシステム的に引くことこそが、防御側エンジニアの役割です。

　現在のフロンティアAIモデルに対して「わが社を安全にして」という広過ぎる目標を渡すのは荷が重過ぎます。「新しい脆弱性情報が出たときに、自社のシステム構成に影響があるかどうかを確認して」「この新しいコードにセキュリティの穴がないかどうか、ステージング環境をハックして確かめて」というように、エージェントの役割（ゴール）を明確に、タスクを小分けにして渡してあげることも、ハーネスの設計において非常に重要です。

経営層が変えるべき2つの意識

――現場がどれだけ危機感を持ったとしても、最終的な意思決定は経営層に委ねられます。ITリーダーや経営層は、置かれている現在の状況にどう向き合うべきでしょうか。

米内氏　経営者目線でお話しすると、現場がどれだけ危機感を持っても、経営層が2つの「意識改革」を推進しなければ、明日から脆弱性を探したところで組織の防御は必ず行き詰まります。

　1つ目は、「AIコストに対する考え方」の刷新です。

　Opus 4.8水準のモデルやフロンティアAIをワークフローに組み込んでフル回転させると、当然相応のコストがかかります。これを従来の「通信費」や「ツールのサブスク代」の枠内で捉えていては、サイバー防御におけるAI活用は困難です。

　これからは「優秀なセキュリティエンジニアを1人採用・外注する代わりに、AIエージェントの稼働費として年間1000万円の予算を投じる」というような、「人的資本」（労働力）としての予算の組み換えを経営層が決断する必要があります。

　2つ目は、「システム障害（可用性）に対する文化」の変革です。

　AIによって、自組織の致命的な脆弱性が1時間で見つかったとします。しかし、「システムを絶対に止めてはいけない」「パッチを当てていいのは週末のこの時間枠だけ」「ベンダーに見積もりを取るから対応は数カ月後」という従来の運用ルールに縛られている間に、AIで能力をスケールさせた攻撃者に侵害されてしまいかねません。

　これまでお茶を濁してきた、「日本のど真ん中の層の組織」が今、最も危ないのです。莫大な予算もなく、かといって商店街の八百屋さんのように攻撃対象から外れているわけでもない。目的を持った攻撃者のAIが無限に巡回する世界で、ツケが回ってこようとしています。

　「IT資産を守ることは、事業を1秒も止めないことと同義、あるいはそれ以上に最優先事項である」という経営スタンスをトップダウンで示し、即座に修正パッチをデプロイできる体制を作る。ゲームのルールが変わった以上、経営層はその覚悟を持たなければなりません。

　まずはAIに手元のソースコードを投げてみる素振りからでも構いません。攻撃者がAIを完全に手なずけて攻撃を仕掛けてくる前に、AIを組織の武器として組み込む一歩を、今すぐ踏み出していただきたいと思います。

　この1年のAIの進化に関しては、SFじみた報道がどうしてもあると思います。それに対して「言い過ぎだ」という人もいれば、「すごい怖いな」と感じている人もいる。人間の感情が揺れ動いているタイミングだと思います。私としては、あまり怖がるべき事象ではないと思っています。

　普通にエンジニアリングをしている人が、普通に今までのセキュリティプラクティス（ログを取る、監視する、保護されていないエンドポイントを減らすなど）をやっていただく分には、十分だと思います。焦らず、腐らずでセキュリティをやっていきましょう。

　とはいえ、欲を言えば、できるだけ早い段階で、AIをセキュリティに使えるような体制は整えていただきたいです。これは経営層からのトップダウンでないと、ボトムアップでは難しい気がします。その点、私どもも「AI for Security」（セキュリティにAIを使う）という文脈で、製品に限らず情報発信を続けています。さまざまな情報をキャッチアップしていただきつつ、いずれにせよ今からでも動いていただきたいなというのが、私の願いです。

---

　「本当はやるべきだったけれど、リソースを理由に後回しにしてきた」――。そうした組織にこそ、今、避けて通れない転換点が訪れている。フロンティアAIという新たな波を、事業の“足元”を再点検する契機にしたい。