AI攻撃かどうかを待たない——日韓の侵害報道から作る「防御速度票」

AIがサイバー攻撃に使われたのか。企業がこの問いへの確答を待っている間にも、公開APIは探索され、弱い認証は試され、漏れた認証情報は別のサービスへ転用されます。攻撃者が人間かAIエージェントかは重要な調査対象ですが、初動の停止条件までその答えに依存させるべきではありません。

2026年10月、日本では情報漏えいの公表が相次ぎ、セキュリティ企業や専門家が、公開WebシステムやAPIの不備を広く探る動きへ注意を促しました。韓国では複数の銀行への侵害を巡り、当局がAI利用の兆候を調べています。報道された件数、原因、被害範囲には調査中の部分があります。それでも両国の事例から共通して読み取れるのは、攻撃の正体を完全に説明する速度より、露出を見つけ、証拠を残し、権限を絞り、業務を戻す速度が経営課題になったことです。

以前の記事では、外部者からAIへの侵入とAIから外部環境への越境を分ける四つの事故台帳を整理しました。また、AI生成コードを本番へ出す前に通す四つの品質関門も提案しました。今回は事故が始まった後へ焦点を移し、発見から復旧までの時間を一枚で扱う「防御速度票」へ落とし込みます。

結論——攻撃者の正体より先に、八つの時計を動かします

AI時代の防御は、AI製品を買うことから始まりません。次の八つの時計を決め、どこで待ち時間が生まれたかを毎回記録することから始まります。

時計	始点	終点	先に決めること
露出発見	公開・変更	資産台帳への反映	公開API、管理画面、委託先、保有データ
異常検知	最初の異常	担当者への通知	404、403、503、正常応答の急増、権限変更
証拠保全	通知	ログの退避完了	保存先、保存期間、時刻同期、担当者
封じ込め	事故宣言	認証・経路・機能の制限	止められる単位、代替手段、承認者
影響確定	調査開始	対象期間・データ・利用者の確定	確定と暫定の表示方法
業務縮退	停止判断	最低限業務の再開	手作業、別経路、優先顧客、処理上限
復旧	修正開始	再侵入試験を通過	秘密情報の交換、設定差分、監視強化
通知・救済	影響確定	対象者への案内と支援開始	連絡先、更新頻度、本人が取れる行動

この表の目的は、すべてを最短にすることではありません。ログを消して急いで再起動すれば、封じ込めは速く見えても原因と影響範囲を追えなくなります。反対に、完全な調査報告を待ってサービスを開けたままにすれば、証拠は増えても被害が広がります。各時計の間にある依存関係を見えるようにし、速くする工程と、意図的に止まる工程を分けます。

日本の相次ぐ漏えいは「公表件数」と「発生件数」を分けて読む必要があります

ITmedia AI＋による大手ベンダー四社への取材では、国内の攻撃が増えているかについて見解が分かれました。増加を感じる回答がある一方、最近公表された事故が最近発生したとは限らず、公表件数だけでは傾向を判断しにくいとの指摘もあります。九月以降の報告が多く見えても、七月や八月の侵害が含まれ、同じ基盤の影響を受けた企業が個別に公表している可能性があります。

ここで「AI攻撃が急増した」と一足飛びに結論づけると、防御の優先順位を誤ります。必要なのは、発生日、発見日、公表日を別々に持つことです。さらに、最初の侵入、横展開、データ取得、外部持ち出しも分けます。同じ一件でも時計は複数あり、公表日だけを基準にすると、検知の遅れや委託先からの連絡待ちが隠れます。

同記事では、脆弱性公表から悪用までが短くなったとのベンダー見解や、AI利用の痕跡を公表情報から確認できないとの慎重な見解も紹介されています。したがって企業は、「AIが使われた」と断定する欄と、「AI利用を前提に急ぐ」欄を分けるべきです。前者は証拠の問題で、後者は時間設計の問題です。

81事案の多くで手法を分類できない事実を、待つ理由にしません

専門家三人の分析を報じたITmedia AI＋の記事では、七月以降の81事案のうち、既知脆弱性、管理画面の認証、個別サイトやAPIの不備という分類に必要な説明が不足した事案が65件とされました。これは、65件が高度な未知攻撃だったという意味ではありません。公開情報だけでは手法を分けられないという意味です。

原因の空欄は、対策の空欄にしてはいけません。手法が未確定でも、自社が公開しているWebシステム、モバイルアプリ、API、管理画面、委託先連携、保持する個人情報は洗い出せます。同じIPからの大量アクセス、404や403の急増、存在しない機能の探索、通常より極端に多い200応答は確認できます。正常応答が多いから安全とは限らず、攻撃者が見つけた有効な経路を反復している可能性もあります。

最初の判断単位は「AI攻撃か」ではなく、「通常から外れた探索と取得が続いているか」です。AI利用の証拠がなくても、異常な速度や範囲を観測した時点で、ログ保全、認証情報の交換、経路制限、関係者招集を開始できます。

韓国の銀行侵害は、強い主張と確定情報を分けて扱います

韓国の事例では、AIエージェントが使われた可能性が大きく報じられました。NBC Newsが配信した報道によると、韓国大統領は一部の銀行侵害でAI利用の兆候が現れたと述べ、警察が捜査を始めました。一方、その時点では使われたAIツールの詳細や被害全体は公表されていませんでした。

その後のThe Recordの報道は、少なくとも七つの金融機関、少なくとも6万8000人の個人情報、33のIPアドレスという当局や現地報道に基づく数字を伝えています。ただし、IPアドレスが複数国にまたがることは、実行者の国籍や指揮系統をそのまま示しません。経由地、侵害済み端末、クラウド基盤が混ざるためです。

企業内の事故票でも、同じ証拠境界を守ります。「AI利用の疑い」「特定ツールの痕跡」「人間の指示者」「侵入経路」「取得されたデータ」を別の欄にします。強い見出しをそのまま根本原因へ転記せず、各項目に確認時刻と根拠を付けます。これにより、後から当初の見立てが変わっても、停止や通知の判断まで無効になりません。

AIは攻撃の魔法ではなく、探索と反復の単価を下げます

AI利用を巡る議論では、未知の脆弱性を自動発見する万能攻撃者が想像されがちです。しかし、日本の専門家分析は、現時点で一連の事案にゼロデイ悪用を確認したとはしていません。目立つのは、公開面を広く調べ、既知の弱点、弱い認証、個別実装の不備を探し、成功した方法を別の対象へ繰り返す動きです。

AIが変えるのは、必ずしも一回の攻撃の高度さではありません。候補URLを集める、応答差を比べる、エラーから次の入力を作る、別の対象へ手順を移すといった反復の費用です。攻撃一回当たりの単価が下がれば、以前は見逃された小規模サイトや古いAPIも探索対象になります。

この変化に対し、防御側が高度なAIだけで対抗しようとすると、基本対策が遅れます。公開不要な機能を閉じる、管理画面を外部から見えなくする、多要素認証を入れる、秘密情報を定期交換する、不要データを消す、委託終了後のデータ破棄を確かめる。これらは地味ですが、探索が成功へ変わる経路を減らします。

防御AIには「発見」と「決定」の間に境界を置きます

防御側でもAIは役立ちます。大量のコードや設定を調べ、類似するアラートをまとめ、脆弱性と資産の重要度を照合し、優先順位の候補を出せます。ITmediaの取材では、脅威モデル作成を数週間から数時間へ短縮したという日立の検証や、診断作業が短い例では数日になったというアクセンチュアの説明が紹介されています。これらは各社が示した事例であり、すべての環境で同じ短縮を保証する数字ではありません。

AIへ任せやすいのは、候補の収集、重複の整理、既知パターンとの照合、過去ログの要約です。任せきりにしにくいのは、顧客データを含むサービスの停止、法令や契約に基づく通知、証拠の廃棄につながる操作、復旧版の承認です。特に自動封じ込めは、速さと誤停止の両方を測ります。

そこで、AIの提案には三つの出口を用意します。低リスクな観測追加は自動実行します。認証の失効や通信制限は、事前に定義した条件で承認者へ送ります。データ削除や全面停止は、影響範囲と代替経路を確認してから決めます。AIの精度だけでなく、提案から承認までの時間、誤停止から戻る時間も防御速度票へ記録します。

「止める」と「続ける」をサービス単位より細かくします

事故時に全停止か通常運転かの二択しかなければ、経営は停止をためらいます。顧客向け画面は読み取り専用にする、ファイル出力を止める、新規登録を止める、管理者操作を社内ネットワークへ限定する、決済だけ別経路へ逃がすなど、機能ごとの縮退が必要です。

縮退の粒度は平時に設計します。コア業務、停止できる機能、手動代替、許容件数、担当者、復旧順序を決めます。バックアップも、存在するだけでは不十分です。侵害前の時点へ戻せるか、同じ認証情報を再利用していないか、復元先へ攻撃経路を持ち込まないかを試します。

重要なのは、最速復旧を競わないことです。原因が未確定でも最低限業務を安全な別経路で続け、証拠を保全した環境と、顧客対応を続ける環境を分けます。復旧時刻だけでなく、再発なく一定期間運転できた時刻を完了として残します。

日本企業向けの「防御速度票」

一枚の票には、少なくとも次の九欄を置きます。

1. 守る業務と止めてはならない最低機能
2. 公開資産と保有データ、委託先、最終更新日
3. 最初の異常時刻と検知根拠
4. 保存したログ、時刻範囲、保管責任者
5. 制限した認証、通信、API、機能
6. 暫定影響範囲と確定影響範囲
7. 縮退経路、処理上限、利用者への案内
8. 修正、秘密情報交換、再侵入試験、復旧承認
9. AI利用の疑い、確認済みの痕跡、未確定事項

九番目の「AI」は最後に置きます。重要でないからではなく、一番目から八番目の行動を止めないためです。AI利用の帰属が後で変わっても、資産台帳、ログ保全、封じ込め、縮退、復旧は再利用できます。

各欄には担当部署名だけでなく、一人の決定者と代行者を置きます。「情報システム部」「委託先」のような組織名だけでは、休日や深夜に時計が止まります。連絡が取れない場合に次へ移る時間も決めます。

30日で始めるなら、公開API一つを対象にします

最初から全社のサイバーBCPを完成させようとすると、棚卸しだけで止まります。最初の30日は、顧客情報へ到達し得る公開API一つを選びます。

第一週は、入口、認証、接続先、ログ、保持データ、委託先を図にします。存在しないエンドポイントへの探索、失敗応答の急増、成功応答の異常増加を観測できる状態にします。

第二週は、読み取り専用化、認証失効、特定経路の遮断を試します。本番を突然止めるのではなく、演習環境と限定時間で、誰が承認し、何分で戻せるかを測ります。

第三週は、ログを別の保管先へ退避し、影響範囲を暫定表示する練習をします。確定前の数字には時刻と根拠を付け、更新時に以前の数字を消さず、履歴を残します。

第四週は、担当者を入れ替えて同じ演習を行います。開発者や特定ベンダーがいなくても、別担当が縮退、証拠保全、復旧を進められるかを見ます。失敗した工程は、担当者の注意力ではなく、権限、手順、連絡先、復旧材料の不足として直します。

見るべき七つの指標

防御AIの導入率やアラート件数だけでは、事故対応の強さは測れません。次の七つを並べます。

• 公開資産が台帳へ載るまでの時間
• 最初の異常から担当者通知までの時間
• 通知から証拠保全までの時間
• 通知から最初の封じ込めまでの時間
• 縮退業務が始まるまでの時間
• 修正版が再侵入試験を通るまでの時間
• 対象者へ取れる行動を案内するまでの時間

平均だけでなく、最も遅かった一件と理由を見ます。深夜、休日、委託先待ち、承認者不在、ログ不足といった構造的な遅れが、平均値では隠れるためです。同時に、誤検知による停止件数、戻すまでの時間、見逃し後に発見した件数も守る指標として持ちます。速さだけを評価すると、現場は根拠の薄い遮断を増やしてしまいます。

主な出典

• 相次ぐ情報漏えいと攻撃・防御側のAI活用に関するベンダー取材（ITmedia AI＋）
• 国内81事案の分類と専門家が示した点検項目（ITmedia AI＋）
• 韓国当局が調べる銀行侵害とAI利用の兆候（NBC News）
• 韓国の金融機関侵害に関する当局・現地報道の整理（The Record）

結論——次の事故会議では「AIだったか」より「どの時計が止まったか」を聞きます

AIが攻撃へ使われる可能性は、もはや無視できません。しかし、AI利用を断定できるログがないことと、初動を始められないことは別です。公開資産を減らし、異常を観測し、証拠を残し、権限を絞り、最低限業務へ縮退し、利用者へ取れる行動を伝える。この順序は、攻撃者が人間でもAIエージェントでも変わりません。

日本企業が今週決めるべきなのは、最新の防御モデル名より、最初の異常から何分で誰が何を止め、どのログを残し、どの業務を別経路で続けるかです。あなたの組織では、八つの時計のうち、担当者や承認者をまだ書けないものはどれでしょうか。次の事故が始まる前に、その一つだけでも動かしておくことが、AI時代の現実的な防御になります。