AIが変える攻撃の組み立て方：車両セキュリティで今確認すべきこと

個別の脆弱性から攻撃経路全体へ、AIの能力進展を踏まえて問い直す多層防御の設計

このブログのポイント

• AIはエクスプロイトチェーン構築と概念実証コード（PoC）の自律生成・検証ループを実行できる段階に達しつつあり、個別の脆弱性対処だけでは攻撃経路を閉じ切れない可能性が高まっています
• 多層防御は層の数ではなく、遮断点の独立性で評価することが重要です。複数の制御が同じ前提を共有していると、一点が崩れた時に連動してまとめて機能しなくなります
• 攻撃経路検証は実機テストがなくても、設計書やTARA（脅威分析・リスク評価）・証跡資料の机上評価を行うことから開始でき、設計・実装・運用・証跡それぞれの不足を区別して洗い出すことができます

AIの進化は単発の脆弱性を発見する段階を超え、複数の要素を組み合わせながら攻撃経路全体を自律的に探索する能力の実用化へと近づいています。多層防御、最小権限、ネットワーク分離、暗号化、署名検証、監視といった基本的な対策は引き続き重要ですが、今後は対策の存在だけでなく、それぞれの対策が攻撃経路上で独立した遮断点として本当に機能しているか、すなわち、ある層が迂回・誤設定・無効化されても他の層が危険な状態遷移を確実に止められる設計になっているかどうかが、これまで以上に重視されていきます。

本ブログでは、車両サイバーセキュリティの観点から、AI時代の攻撃経路と遮断点をどう点検すべきかを整理します。

フロンティア AI が示した「攻撃経路探索」の進展

英国AI Security Institute（AISI）は、2026年4月にClaude Mythos PreviewおよびOpenAI GPT-5.5のサイバー能力評価を公開しました。AISIは、CTF（Capture The Flag）形式のタスクに加え、複数のホスト、サービス、脆弱性を含むサイバーレンジを用いて、長い攻撃チェーンをAIエージェントがどこまで自律的に進められるかを評価しています。

評価の結果、Claude Mythos Previewは「The Last Ones（TLO）」と呼ばれる32ステップの企業ネットワーク攻撃シミュレーションを10回中3回で完走しました。続くGPT-5.5の評価では、同じTLOを10回中2回で完走し、AISIは同モデルを自機関が評価した中で最も強力なサイバータスク対応モデルの一つと位置づけています。

こうした評価結果に加え、Cloudflareが自社の50以上のリポジトリにフロンティアモデルを適用した調査報告（2026年5月公表）からは、防御側にとって注目すべき二つの能力変化が読み取れます。

• エクスプロイトチェーンの構築：個別には低深刻度として扱われてきた複数の脆弱性を組み合わせ、動作する単一のエクスプロイトへと推論することができます。バックログに埋もれて見えにくくなっていた低深刻度のバグが、連鎖することで高深刻度の攻撃手段へ変わりうることを、実コードへの適用が裏付けています。
• PoC（概念実証コード）生成ループ：バグの発見にとどまらず、PoC コードを自律的に記述・コンパイル・実行し、失敗を読み取って仮説を修正し、再試行するループを回すことができます。バグの存在を確認してから実際に到達可能な脆弱性へ橋渡しをするまでを、モデルが単独で完結できる段階に近づきつつあります。

ただし、これらの結果だけで「AIが現実の堅牢な環境をそのまま自律的に突破できる」と解釈するのは適切ではありません。AISI自身も、評価環境には能動的な防御者、実運用の防御ツール、アラート発生に対するペナルティなどが不足しており、十分に防御された環境に対する成功可能性は判断できないと説明しています。

AIエージェントの挙動をどう捉えるか

防御側がまず押さえるべきなのは、AIエージェントが「計画→試行→観察→再計画」という反復ループで動く点です。単発の回答を生成する存在としてではなく、失敗要因を取り込みながら探索方針を更新し続けるシステムとして捉える必要があります。

この挙動の枠組みは、LLM研究におけるReAct（推論と行動の交互進行）、Tree of Thoughts（複数経路の並列探索・比較）、Reflexion（失敗を次の試行に反映）として整理されています。現状のフロンティアモデルにも限界はありますが、こうした発想に基づくエージェント化が進むほど、仮説生成・条件確認・反証・再計画を繰り返しながら到達可能な経路を絞り込む能力は高まっていきます。

そのため、現時点でAIが複雑な環境をそのまま自律的に探索できるわけではないとしても、防御側は将来の能力向上を見据えて準備しておく必要があります。

今後AIが見つけやすくなる死角

AIエージェントの探索能力が高まると、ゼロデイ脆弱性だけでなく、設計、実装、運用、証跡の間に生じるズレや隙間も探索対象になっていきます。人間による検証では時間や粒度の制約から取りこぼされることがありますが、現状のモデルがこれらを実環境で完全に探索できるわけではありません。ただし能力が進化すれば、フロンティアモデルに限らずオープンウェイトモデルを含む幅広いAIによって、こうした見落とし領域がより速く、より広く洗い出される可能性があります。

既存の評価手法は脅威や対象を起点に個々のコンポーネントや機能を深く評価するうえでは有効です。一方で、複数の制御をまたいで連鎖する攻撃経路全体を体系的に確認するところまでは手が届きにくく、構造上の抜け落ちも生じやすくなります。こうした死角は、脆弱性を「点」として見る評価設計の限界から生まれます。

AI時代の防御で重視すべき「点」から「線」への見方

AIの能力が高まるにつれ、個々の脆弱性を「点」として見るだけでは追いつかなくなる可能性があります。背景には大きく2つの理由があります。

ゼロデイ対応だけでは追いつかなくなる可能性がある

AIによる脆弱性発見の自動化が進めば、ゼロデイ脆弱性が従来よりも速く発見され、悪用される可能性があります。電子制御ユニット（ECU）のような長寿命製品では、発見されたすべての脆弱性を迅速にパッチで塞ぐことには現実的な限界があります。

個別修正だけでは攻撃経路を閉じ切れない

AIが攻撃経路の探索能力を高めると、ある脆弱性を修正しても別の弱点、設定不備、運用上の例外、過剰な権限を組み合わせた経路が見つかる可能性があります。個別の修正だけで経路全体を遮断できるとは限りません。

Cloudflareの同報告でも、個別には低深刻度でバックログに埋もれていた複数のバグが、連鎖によって高深刻度のエクスプロイトに変わったことが確認されています。チェーンを構成した各バグ単体では優先度が低くまだパッチが当たっていない状態でも、組み合わせることで攻撃が成立しました。これは、個別の脆弱性スコアによる優先度付けだけでは攻撃経路を閉じ切れないことを示す、防御側にとって重要な事例です。

こうした理由から、個々の脆弱性が修正済みかどうかだけを見ていても不十分で、それらが連鎖して重要資産や安全上重要な状態へ到達する「線」を形成するかどうかまで確認する必要があります。だからこそ、ある脆弱性が残っていたり悪用されたりした場合でも、攻撃経路上に遮断点を設けて連鎖を止められる設計が重要になります。

表1. 脅威評価の視点：従来とAI時代の比較

多層防御を「層の数」ではなく「独立性」で見る

攻撃経路上で各状態遷移をそこで拒否する役割を担う制御が、遮断点です。遮断点を攻撃経路上に配置すること自体は正しい方向性ですが、数があることと独立性を確保することは別の問題です。多層防御が存在することと、それが独立して機能していることは同じではありません。

たとえば、次のような経路を考えます。

一見すると、複数の層に防御機能が配置されているように見えますが、これらの遮断点が同じバックエンド設定や広すぎるトークンスコープといった共通の前提に依存していれば、その前提が崩れた時に複数の層が同時に弱体化するおそれがあります。

堅牢な多層防御とは、ある層が誤設定、迂回、無効化された場合でも、別の層が独立した判断根拠で拒否できる状態です。制御の数を増やすだけでなく、制御間の依存関係を理解したうえで、単一の前提が崩れても複数の防御が同時に失効しない設計が求められます。

では、実際の車載システムにおいてどのような制御が遮断点として機能しうるか、またその独立性が崩れるとはどういうことかを、公開されている分析事例で見ていきます。

遮断点の実装例：脆弱性があっても悪用を困難にする多層対策

公開されている車載インフォテインメントシステムのセキュリティ分析では、次のような多層的な遮断点の実装が報告されています。これらは、個々の脆弱性が残っていたとしても攻撃の到達可能範囲を制限し、エクスプロイトの難易度を高めることを目的とした対策です。

① 攻撃対象領域（アタックサーフェス）の制限・アプリケーション権限の分離

表2. アタックサーフェス制限・アプリ権限分離の遮断点一覧

② 脆弱性悪用の困難化

• カーネル：最新化、ハードニング、ASLR（メモリアドレスのランダム化）、KASLR（カーネルアドレスのランダム化）
• バイナリ：PIEビルド（位置独立実行可能ファイル）、スタッククッキー、メモリセーフ言語の採用、クリティカルなサービスでのダイナミックアロケーション非使用
• ライブラリ：最新化・バックポートフィックス、Libcのヒープ管理ハードニング

③ その他の防御層

• OTA（Over The Air：無線通信によるソフトウェア更新）の暗号化チャネル経由によるパッチ配信
• イーサネットとCAN（Controller Area Network：車載ネットワーク規格）の多層分離・フィルタリング
• ユーザーデータパーティションの暗号化（HSMによる鍵管理）、セキュアブート

これらは脆弱性をゼロにするための対策ではなく、脆弱性が悪用されるまでの難易度を高め、影響範囲を狭めるための多層設計です。

ただし、こうした多層対策も遮断点の独立性が保たれていなければ機能しません。同じ分析では、あるネットワーク管理サービスの権限設定が複数の遮断点にまたがる共通前提となっており、その前提が崩れると複数の層が連動して弱体化する構造が示されていました。

Kafel・AppArmor・IPTablesという三つの遮断点が、同じサービスの権限設定という一つの前提を共有していたため、その前提が崩れると複数の層が連動して機能しなくなりました。対策が存在することと、対策が独立して機能することは同じではありません。個別の実装だけでなく遮断点間の依存関係まで設計段階から確認しておくことの重要性がこの事例からわかります。

こうした依存関係を可視化する手段が、攻撃経路検証です。

攻撃経路を検証する

攻撃経路検証では、重要資産に至るまでの論理的な状態遷移を明示し、その経路上に配置された多層防御が、どこで、何の根拠に基づいて攻撃連鎖を遮断できるかを確認します。

たとえば「Cloud APIから診断権限を取得し、TCU経由でECUに届く経路」を整理するとすれば、各ステップで、この遷移がどの成立条件を前提としているのか、どの遮断点がその前提を検証しているのかを確認することになります。

遮断点は、単一の機能とは限りません。認証、認可、車両状態検証、署名検証、Gatewayポリシー、ECU側受理条件など複数の制御が重なって一つの関門を構成する場合もあります。ただし、それらが同じ前提を共有しているのであれば独立した遮断点としては機能しません。なお、監視と監査ログは遮断そのものではなく、遮断判断の妥当性を検証し追跡可能にするための証跡として位置づけられます。

実際に評価で確認すべきポイントは次の３点です。

• その対策が攻撃経路上のどの状態遷移を止めるのか
• その対策はどの前提に依存しているのか
• 他の経路でも同じ前提に依存していないか

攻撃経路検証は、必ずしも実機テストから始める必要はありません。電気・電子（E/E）アーキテクチャ図、TARA（脅威分析・リスク評価）、認証・認可仕様、Gatewayポリシー、過去のペネトレーションテスト結果、VSOC（Vehicle Security Operations Center：車両セキュリティ運用センター）ログといった既存の設計・証跡資料を攻撃経路上に並べて読む机上評価からでも、どこに何の不足があるかを４種類に区別して可視化することができます。

• 設計不足：遮断点が経路上に存在しない
• 実装不足：遮断点は設計されているが実装されていないか、実装が仕様を満たしていない
• 運用不足：遮断点は実装されているが、設定・例外・運用手順によって意図せず無効化されている
• 証跡不足：遮断が機能したかどうかを事後に確認できない

守るべきは特定モデルではなく、攻撃経路を止める設計

特定のモデル名だけを追いかけても、備えとしては足りません。フロンティアモデルをはじめ、オープンウェイトモデルを含む幅広いAIが、長いサイバータスク、コード理解、ツール利用、探索、再計画の能力を着実に伸ばしています。

この潮流が進めば、ゼロデイ脆弱性の発見・悪用サイクルが短縮されるだけでなく、状態遷移ロジックの穴、制御間の依存関係、例外運用、過剰な権限、証跡の不足までをより効率的に探索されるようになる可能性があります。

Cloudflareは同報告の中で、CVE公開から数時間以内にパッチを本番投入するSLA（Service Level Agreement：サービス品質目標）を設けるチームが増えていると指摘しています。ただし投入の速度だけでは十分でなく、パッチを急ぐあまりリグレッションテストを省略すれば、修正したバグよりも深刻な問題を別の場所に持ち込む可能性があります。バグが存在していても攻撃者がそこに到達しにくい設計になっているか、コードの一部に欠陥があってもそれが他の部分への侵入口にならない設計になっているか。この視点は本ブログで述べてきた遮断点の独立性と同じところから来ており、速度と設計の両方を同時に問い直すことが求められます。

攻撃経路を明示し、状態遷移の成立条件を確認し、遮断点の独立性を検証する。こうして見えてきた結果を、TARA、CSMS（Cybersecurity Management System：サイバーセキュリティ管理システム）、SUMS（Software Update Management System：ソフトウェア更新管理システム）、VSOC、PSIRT（Product Security Incident Response Team：製品セキュリティインシデント対応チーム）の運用につないでいくことが、AIによる長い攻撃チェーンの探索能力が高まる中で車両サイバーセキュリティを実効的に保つための一歩になります。

まとめ

表3. まとめ：AI時代の車両セキュリティで重視すべきポイント

関連リソース

VicOne ペネトレーションテストサービス「xScope」・脆弱性診断サービス — 車載システム、ECU、コネクテッドサービス、OTA、クラウド、モバイルアプリの評価

VicOne 次世代VSOCプラットフォーム「xNexus」 — 車両・フリートのサイバーセキュリティ監視とインシデント対応支援

出典

• 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)
• UK AI Security Institute, "Our evaluation of OpenAI's GPT-5.5 cyber capabilities"
  (https://www.aisi.gov.uk/blog/our-evaluation-of-openais-gpt-5-5-cyber-capabilities)
• OpenAI, "Scaling Trusted Access for Cyber with GPT-5.5 and GPT-5.5-Cyber"
  (https://openai.com/index/gpt-5-5-with-trusted-access-for-cyber/)
• Yao et al., "ReAct: Synergizing Reasoning and Acting in Language Models"
  (https://arxiv.org/abs/2210.03629)
• Yao et al., "Tree of Thoughts: Deliberate Problem Solving with Large Language Models"
  (https://arxiv.org/abs/2305.10601)
• Shinn et al., "Reflexion: Language Agents with Verbal Reinforcement Learning"
  (https://arxiv.org/abs/2303.11366)
• NIST, "Mapping Evidence Graphs to Attack Graphs"
  (https://www.nist.gov/publications/mapping-evidence-graphs-attack-graphs)
• Synacktiv, "IVI Security Analysis — Pwn2Own 2022" (SSTIC 2023)
  (https://www.synacktiv.com/sites/default/files/2023-06/tesla_sstic.pdf)
• Cloudflare, "Project Glasswing: what Mythos showed us" (2026-05-18)
  (https://blog.cloudflare.com/cyber-frontier-models/)