AI対AIのサイバー攻防とは？少人数チームの防御策と30日計画

AI対AIのサイバー攻防とは、攻撃者がAIエージェントで探索や侵入を進め、防御側もAIで検知・調査を支援する状況です。少人数の運用チームが優先するのは、侵入を防ぐ、被害を広げない、異常に気づいて復旧するという3つの備えです。

AIは複数の作業を続けて実行できますが、能力や成功率は対象と与えた権限で変わります。「AIを導入すれば守れる」と考える前に、公開資産、修正の優先順位、管理者権限、通知先、復旧手順を確認します。

本記事は、日本とタイで少人数のチームを率いる情報システム担当者・開発責任者に向けて、公表された攻撃事例と当社の検証を整理し、最初の30日で進める対策と、防御AIに任せる範囲を示します。30日計画は着手順の例です。進行中の侵害や悪用が確認された重大な弱点には、その場で対応します。

AIエージェントは、ツールを使って対象を調べ、結果を読み、次の操作を選ぶ作業を繰り返せます。 攻撃者がこの仕組みを悪用すると、弱点の探索や侵入後の調査が自動化されます。

ただし、教材での成功、公表された侵入事例、実際の自社環境での成功は、それぞれ条件が違います。以下では、何を確認した記録なのかを分けて読みます。

当社がペネトレーションテストの検証に使うARTEXは、AIエージェントがツールを操作して対象を調べ、結果を報告する基盤です。公開済みの検証記事では、GLMと組み合わせ、自作のPHPアプリに意図的に用意した2種類の弱点について、サーバー上での実行を確認したと報告しています。

RCEは、外部からサーバー上でコードを実行できる状態です。試験は管理下のローカル環境で行い、アプリの内部コードを読ませず、HTTP通信から調べています。2つ目では具体的な弱点の場所を伝えていませんが、対象と調べる目標は指定しているため、「一切ヒントなし」の試験ではありません。

元記事のDB計測では、タスク作成から検出結果の登録まで、コマンド注入は104秒、アップロード経由は305秒かかりました。各教材1回ずつの成功例です。アプリの準備、環境設定、人による確認、後片付けは含みません。平均的な攻略時間、未知の弱点の発見率、実システムでの成功率を表すものではありません。PHP本体の脆弱性「PHP2Shell」を再現した試験とも区別しています。

本記事の編集では、元記事の報告内容との整合を確認しました。通信の生ログやDBの元タイムスタンプは独立に再取得しておらず、攻撃の再実行や修正後の比較試験も行っていません。ここから読み取れるのは、条件を整えた教材では、探索から実行確認までが数分で進む場合があるという点です。

Anthropicは、同社が中国の国家支援集団と高い確信を持って評価した攻撃者がClaude Codeを悪用し、約30組織への侵入を試み、少数の事例で成功したと報告しています。

同社の推定では、AIが作戦の作業の80〜90%を担い、人の介入は作戦ごとに4〜6か所の重要な判断点で必要でした。この割合は、当該作戦の作業分担についての推定であり、攻撃の成功率でも、あらゆる攻撃が同じ割合で自動化できるという評価でもありません。

AIが担ったのは、対象の調査、弱点の検証、侵入後の認証情報やデータの整理などです。一方、存在しない認証情報を報告したり、公開情報を秘密情報として扱ったりする誤りもありました。Anthropicの公表資料

防御側が押さえるべきなのは、自動化で処理量が増えることと、結果に誤りが混ざることの両方です。人の介入が残るから攻撃を軽視できるわけではなく、AIの報告だけで侵害や安全を断定することもできません。

事例を防御の設計に置き換えると、次の3点を優先できます。これは本記事の推奨です。

1. 公開資産を把握する。 自社が把握していない入口にも、攻撃者はアクセスできます。
2. 人が気づく前の被害を抑える。 教材では分単位で処理が進んだため、通知後の手作業だけに頼らず、入力制限や権限分離を先に設けます。
3. 既知の弱点と認証の不備を放置しない。 AI固有の対策に加えて、修正適用と本人確認を続けます。

MandiantのM-Trends 2026は、同社が世界で調査した侵害で、最初の侵入経路は脆弱性の悪用が32%、電話を使うフィッシングが11%だったと報告しています。これは同社の調査対象の内訳で、AI攻撃だけの統計ではありません。M-Trends 2026

AIによる攻撃の増加率を、この数字から求めることはできません。実務では、AIへの備えと、修正・認証・復旧という基本対策を同じ運用の中で進めます。

侵入防止、被害拡大の抑制、検知と復旧を重ねます。 どれか1つで安全を保証することはできませんが、入口の対策が破られても、権限や通信の制限で影響を抑え、記録を使って対応できます。

以下は教材の弱点と公的な防御指針を踏まえた実装・運用の例です。ARTEXの試験で、この3段階すべての効果を実測したわけではありません。

まずは、アプリの実装とサーバー設定の両方を点検します。外部から来る入力を危険な処理へ渡さないことが出発点です。

OWASPは、OSコマンドを直接呼ばず、ライブラリやAPIで代替する方法を優先しています。呼び出しが必要な場合も、引数の分離だけで入力が安全になるわけではなく、コマンドと引数の検証を組み合わせます。OSコマンドインジェクションへの防御指針

アップロードでは、利用者が送るContent-Typeだけを信用せず、拡張子・内容・保存先・アクセス権限を合わせて点検します。拒否する拡張子を並べるだけでは、別形式やサーバー設定の影響を取りこぼします。ファイルアップロードの防御指針

防御策を設定したことと、期待どおりに機能することは別です。修正した担当者と確認者を記録し、問題の入力を使う確認と正常な機能の確認を対にして残します。

実際の悪用、自社からの到達可能性、奪われる権限、業務への影響を組み合わせて決めます。 深刻度の点数だけを並べても、自社がどこから被害を受けやすいかは分かりません。

CISAのKEV（Known Exploited Vulnerabilities）は、悪用が確認された脆弱性のカタログです。CISAの公式データと説明で確認できます。ただし、KEVに載っていないことは安全の証明にならず、自作アプリの弱点がすべて掲載されるものでもありません。

次の表は、少人数チームで使うための判断例です。公的な修正期限や、一律の法的義務を示す表ではありません。

担当者は、製品名だけでなく、版や設定が影響条件に合うかを確認します。KEVの照合結果だけで、実際に侵害されたとは判断しません。逆に、まだ侵害の証拠がないから修正不要とも判断しません。

期限内に直せない場合は、理由、暫定策、残るリスク、再確認日を記録し、業務責任者が承認します。通知先と判断者まで決めておくと、夜間や休日に「誰も止める判断をしない」状態を避けられます。

侵入後の備えは、攻撃者が使える権限、認証情報、通信経路を減らすことです。少人数でも、まず次の範囲から確認できます。

• アプリの実行ユーザーを管理者にせず、その業務に必要な権限に絞る。
• 認証情報は用途ごとに分け、使っていない鍵やアカウントを失効する。
• サーバーから外部への通信は、必要な宛先と用途を把握して制限する。
• 管理者に多要素認証を設定し、認証の再設定や権限追加にも本人確認を設ける。

多要素認証を入れた後も、ヘルプデスクへの電話依頼などから設定を変えられる経路を確認します。依頼者が指定した連絡先だけを使わず、登録済みの別経路で確認する手順を決めます。

検知では、ログを保存するだけでなく、次のような事象を監視候補にします。環境によって正常な動作もあるため、単独で侵害と決めつけず、許可された作業かを照合します。

1. Webアプリのプロセスが、想定外のシェルや子プロセスを起動した。
2. アップロード先に、想定外の実行形式や設定ファイルが作られた。
3. 管理者が追加された、または重要な権限が変更された。
4. 普段と違う宛先への通信や、大量のデータ送信が発生した。

通知には、対象、時刻、観測した事実、確認先を付けます。検知ルールを作ったら、担当者に通知が届き、不在時の代替担当へ引き継げるところまで試します。監視のない時間帯は、外部サービスの利用も含めて対応方法を決めます。

ログの保存期間は、調査に必要な期間、契約、個人データの扱い、費用を合わせて決めます。M-Trends 2026の調査対象では、侵入から発見までの中央値は14日でしたが、これは必要な保存日数を14日とする根拠にはなりません。端末・認証・クラウドの記録を時刻で照合できるようにし、侵入された環境から削除されにくい場所にも保管します。

復旧では、バックアップの取得成功だけを確認して終えず、業務に必要なデータを戻し、アプリが動くところまで試します。バックアップの管理権限を通常の運用権限と分離し、復旧にかかった時間と戻せた時点を記録します。侵害が疑われる場合は、原因や認証情報を確認せずに同じ状態へ戻すと、再侵入につながるおそれがあります。

最初の30日は、資産把握、修正、検知、復旧を1週間ごとに進める計画例にします。 緊急の問題は週の区切りを待たずに対応します。多要素認証の欠落や復旧不能が分かった場合も、計画を前倒しします。

担当が同じ人でも、作業する役割と、残るリスクを承認する役割を分けます。少人数で確認者を置けない場合は、経営層や保守委託先を含めて判断の経路を決めます。「担当者の注意で防ぐ」という完了条件にはしません。

作業台帳は、少なくとも「対象、問題、担当、期限、完了の証拠、残るリスク、例外の承認者、次の確認日」を持たせます。侵入の兆候がある案件を、通常の更新待ちの一覧に埋めないことも大切です。

30日後は、一覧の件数を増やすより、抜けが減ったかを見ます。公開資産の担当不明件数、期限を過ぎた重大事項、通知試験の失敗、復旧試験で戻せなかった範囲を記録すると、次に使う時間を決めやすくなります。

AIによる情報整理は、この作業と並行して試せます。ただし、資産一覧の更新や緊急連絡までAIの判断だけに任せないことが前提です。

拠点ごとの連絡先に加え、全体で隔離・再開・対外連絡を判断する人を決めます。 日本とタイの時差は2時間です。両拠点の夜間・休日を含め、第一連絡先、代替担当、保守委託先への連絡方法を一覧にします。

たとえば、日本の担当者が異常を発見しても、タイ拠点で動くシステムの停止権限がなければ、連絡だけで時間を使ってしまいます。停止できる人、停止を承認する人、顧客への連絡を決める人を先に確認し、不在時の引継ぎ先も決めます。

連絡を受けた人が調査を始められるよう、最初の報告には次を含めます。

• 発見した時刻とタイムゾーン、分かる範囲の発生時刻。
• 対象のシステム、観測した異常、影響が疑われる業務。
• すでに実施した隔離・停止などの操作と、その担当者。
• 元のログや証拠の保管先、まだ確認できていない事項。

日タイの担当者でログを照合するときは、時刻の表記をそろえます。日本時間、タイ時間、UTCが混ざったままでは、操作の前後関係を取り違えるおそれがあります。個人データや認証情報を、広い連絡グループへそのまま貼らない運用も決めます。

漏えいが疑われる場合は、技術調査と並行して法務・個人データ保護の担当者へ引き継ぎます。誰に何をいつ報告するかを事前に相談し、調査の完了を待たずに連絡できるよう訓練します。通知の要否や期限について、この手順だけで判断せず、担当者が適用される法令・規則を確認します。

タイの制度を確認する際は、PDPAとAI活用のチェックリストを入口に、公的資料と専門家の確認へ進めます。この記事では、チームが技術的な対応と引継ぎを始められる状態を完了条件にします。

防御AIは、アラートの一次調査、影響する資産の洗い出し、承認した環境での点検から試します。 初期導入では、AIが根拠付きの候補を出し、人が対応を決める形にすると、誤りと確認の負担を測れます。

導入時期は日数で固定せず、扱うデータと権限を制限できるかで判断します。

導入先は、「AIを使える仕事」ではなく、人が読み切れない通知や、影響確認に時間がかかる作業から選びます。

初期導入で修正の自動適用、権限の変更、対外通知まで行わせると、誤りの影響が大きくなります。実行権限を与えず、承認後に既存の運用手順で実施する設計から始めます。

たとえば「このサーバーは安全です」という要約だけでは、担当者は確認できません。「どのログを、どの時間帯・条件で確認し、何が見つかり、何を確認できなかったか」を出させます。AIが引用したログ行や資産情報に戻れることを、採用する出力の条件にします。

効果は、同じ種類の案件で、調査にかかった時間、修正までの時間、見逃し、人による確認時間を比較します。AIの処理時間が短くても、誤りの確認に余計な時間がかかれば、チーム全体の負担は減りません。導入前に評価対象と中止条件を決め、小さな範囲で判断します。

AIが読むログ、コード、メールには、攻撃者が書き込める内容が含まれます。そこに埋められた指示でAIの判断や操作が誘導される問題が、プロンプトインジェクションです。

Google GTIGは、TeamPCP（UNC6780）に関連するマルウェアに、AIセキュリティスキャナの解析失敗や省略を狙った文章が埋め込まれていたと報告しています。これは攻撃者の狙いについての分析であり、すべてのスキャナで検知回避が成功したという実証ではありません。GTIGの報告

OWASPは、プロンプトインジェクションに確実な防止方法があるかは不明とし、最小権限、人の承認、外部入力の分離などを組み合わせる対策を示しています。OWASPの整理

導入時には、次の5つを確認します。

1. 元データと処理範囲を残す。 AIに渡した件数、処理した件数、対象期間をプログラム側で照合し、省略や失敗を見つけます。件数が合っても内容が正しいとは限らないため、抜き取り確認も行います。
2. 権限をAIの外で制御する。 実行できる操作と対象を、アプリや認可の仕組みで制限します。指示文で禁止するだけでは権限制限になりません。
3. 読む範囲と送信先を制限する。 認証情報や不要な個人データを渡さず、外部AIサービスへの送信条件を確認します。読み取り専用でも、情報を持ち出せる経路は点検します。
4. 外部入力を指示と分離する。 ログやメールを未信頼のデータとして渡し、含まれる命令を業務指示として扱わせない設計を試験します。区別して渡すだけで完全に防げるとは評価しません。
5. 失敗時の動作と人への引継ぎを決める。 根拠不足、形式不正、タイムアウトでは未処理を残し、人へ回します。自動で「異常なし」や「対応完了」にしません。

許可した試験データに紛らわしい命令文を入れた場合も、送信先や権限の制限を越えないか、異常な記録が要約から落ちないかを確認します。誤った完了判定、許可外の操作・送信が見つかった場合は、自動処理を止め、人の確認へ戻す基準を先に決めます。

ARTEXの元記事にも、操作を審査するモデルの応答形式の不備で、審査がタイムアウトした記録があります。発見能力と、審査が正常に働くことは別々に確認する必要があります。

AIの必要性、点検する範囲、最初の着手を確認します。

自社システムでも、利用規約や委託契約を確認し、対象・時間帯・許可する操作・中止条件を承認した範囲で実施します。まず隔離した検証環境を使い、共有基盤や外部サービスへ試験が広がらないよう制限します。配置したファイルの削除・環境の初期化まで計画し、AIの報告は通信や出力の記録と照合します。

AIの導入が必須とは言えません。まず公開資産の把握、修正、権限制限、通知、復旧を整えます。人が通知を読み切れない、影響確認に時間がかかる場合は、防御AIを根拠付きの調査補助として試し、見逃しと確認工数も含めて効果を判断します。

最初の1週間は、次の4点を確認します。

1. 公開資産と担当者を一覧にする。
2. 悪用が確認された脆弱性への該当を確認する。
3. 管理者の多要素認証と、緊急時の連絡先を確認する。
4. バックアップから必要なデータを戻せるか試す。

未解決の問題には担当・期限・暫定策を付けます。進行中の侵害が疑われる場合は、この改善計画より事故対応を優先してください。

少人数チームの備えは、侵入防止、被害拡大の抑制、検知と復旧を組み合わせることです。AIが使われるかどうかにかかわらず、公開された弱点、過剰な権限、届かない通知、戻せないバックアップを減らします。

最初の行動は、公開資産の一覧を開き、担当不明の対象と、悪用が確認された脆弱性への該当を確認することです。問題ごとに担当・期限・完了の証拠を付け、修正できない場合の暫定策と承認者まで決めます。30日計画は、その運用を一巡させるために使います。

防御AIは、元の記録へ戻れる調査補助から始めます。入力、権限、送信先を制限し、誤りや処理失敗を見える状態にして、対応完了や重要な変更の判断は人が持ちます。導入の効果は、速さと見逃し、確認の負担を合わせて測ってください。

実験の条件はARTEX×GLMによるRCE検証、ツールの仕組みはStrix・Cairn・Hermesの解説、関連リスクの全体像はAIサイバーセキュリティの最新動向で確認できます。