相次ぐ不正アクセスは、AIで何が変わったのか？
「AIが攻撃してくるなら、従来の対策は役に立たないのではないか」。
そんな疑問を抱く経営者もいるでしょう。しかし、AIという言葉だけで対策を選ぶと、実際に開いている入口から注意がそれてしまいます。
2026年10月15日、JPCERT/CC（JPCERTコーディネーションセンター）は一連の不正アクセスに関する調査を公表し、攻撃者がAIを使って既知の脆弱性の探索やAPI（システム同士が情報や機能をやり取りする窓口）経由の攻撃を行っていたことを確認したと説明しました。AIの悪用を、単なる未来の想定として扱う段階ではありません。
それでも、ここから、すべての被害がAIによって起きたとも、人の判断が不要な攻撃が一般化したとも言えません。AIが攻撃のどの作業を変えたかと、何の不備が侵入を許したかは、別々に確かめる必要があります。
「AI関与」は、一つの意味ではない
攻撃者によるAIの使い方には、文章の作成、公開情報の整理、アプリの解析、侵入を試みる作業の支援などがあります。これらはすべてAIの利用ですが、自社の防御にとっての意味は同じではありません。
経営への報告では、関与あり・なしの二択にするより、何が観測されたかを記す方がよいでしょう。攻撃に使われた環境から痕跡を確認したのか、被害企業の調査で確認したのか、報道や攻撃者の主張なのでしょうか。主語を補うだけで、過剰な断定を防げます。
今回のJPCERT/CCの発表は、攻撃インフラの調査を通じた説明です。そこから、特定企業の漏えいをAIに帰属させるには、その事案についての追加の根拠が必要になります。企業名を並べた一覧に、一括でAI攻撃と見出しを付けるべきではありません。
この区別は、言葉の厳密さだけの問題ではありません。攻撃方法を誤って理解すれば、製品を追加して安心する一方、修正されていないAPIや管理用の接続が残るかもしれません。原因の認識が、対応の順序を決めるからです。
速くなるのは攻撃の作業、残るのは自社の弱点
AIは、攻撃の準備や分析を支援し得ます。NICT（情報通信研究機構）も公開アプリを手がかりとするサーバー攻撃への注意喚起で、AIによって解析や脆弱性探索が効率化され、より多くのシステムに及ぶ可能性を指摘しています。
ここから私たちが導く実務上の示唆は、攻撃の速さを推測することより、自社が不備を把握し、直すまでの時間を確認することです。相手の能力を正確に測れなくても、公開したままの管理機能や、持ち主のわからない資格情報（IDやパスワード、接続用の鍵など）を減らす判断はできます。
例えば、新しい接続先を開いた日と、資産台帳へ登録した日が離れているとします。その間は、設定の点検や監視の責任者が不明確かもしれません。AIが関与した攻撃かを見極める前から、改善できる空白があります。
もう一つの空白は、修正の判断をした日と、修正が反映された日との間にあります。外部への公開範囲、扱う情報、暫定的な制限の可否を見ず、次の定例作業まで待つ運用でよいのかを確認しておくことが大切です。すべてを即日更新するという一律の答えではなく、優先順位を決める条件を持つことが必要です。
新しい攻撃名より、残っていた管理対象を読む
JPCERT/CCの10月8日公開、9日更新の注意喚起は、一般利用者向けのアプリに加え、社内の分析ツールや従業員向けの管理システムにも点検が必要だと説明しています。また、すべての事案で同じ手法が使われたわけではないとしています。
ここで経営が確認すべきなのは、危険な技術名の暗記ではありません。社内向けと呼んでいるものも含め、外部から到達できるシステムが管理対象に入っているかという点です。利用者を限定したつもりでも、ネットワーク上の入口まで限定されているとは限りません。
以下は、対応の違いを考えるための架空の会議場面です。セキュリティ部門がAI攻撃への備えとして新しい監視製品を提案します。開発責任者が、旧版の管理APIも監視の一覧に含まれるかを尋ねると、担当部門がすぐには答えられません。
そのときは、製品の導入可否と並行して、旧APIの稼働状況と所有者を確認する必要があります。製品がどれだけ高機能でも、対象として把握されていない経路の管理まで自動的に完成するわけではありません。実際に使われている接続先へ目を向けると、明日着手する作業が具体化します。
防ぐ側も、点検の周期を設計し直す
AIで攻撃の探索が効率化するなら、防御の側は何を速めるべきでしょうか。私たちは、監視の処理速度に加えて、業務の変更を把握し、管理の仕組みを見直すまでの間隔も重要だと考えています。
顧客向けの機能を追加したり、外部サービスと接続したり、問い合わせ対応に使うデータを増やしたりしたとき、その変更がセキュリティ部門へ伝わるまでに、どれだけ時間がかかるでしょうか。実際の接続が先にでき、審査や台帳の更新が後追いになっていれば、確認できない期間が生まれます。
変更のすべてを長い会議にかけると、現場は回りません。だから、データの追加、権限の拡張、外部送信先の追加など、評価が必要になる変化を決めておきます。変更者がその条件を確認し、該当するものを担当者へ渡す方が、毎回の個別相談より運用しやすくなります。
AIは、この作業を補助する道具にもなり得ます。例えば、設計書と台帳の差分を候補として抽出する用途です。ただし、候補がないことを未管理の経路がない証明にはしません。確認対象を絞る補助と、正式な判定の責任を分けておく必要があります。
攻撃者のAI利用と、自社のAI接続を分ける
ここでもう一つ、対策の混同を避ける必要があります。攻撃者がAIを使う問題と、自社がAIエージェント（情報の取得やツールの操作を行うAI）を導入する問題は、重なることはあっても同じではありません。
前者では、AIを使って探索や試行を行う相手から、既存のシステムや情報を守ります。後者では、AIが顧客の文章を読み、データを取得し、ツールを実行する仕組みそのものを管理します。必要な担当者も、評価する証拠も変わります。
既存の会員APIに過大な権限があれば、人の操作からも、AI経由でも問題が起こり得ます。逆にAPIの権限が適切でも、AIが扱う文書やツールの設計について追加の確認が必要な場合があります。どちらか一方だけ点検すれば済むという構造ではありません。
McKinseyの公開論考も、エージェントの導入に合わせ、ID・アクセス管理や第三者リスク管理を見直すことを挙げています。私たちはこの考え方を、既存の統制を活用しながら、新しく増えた実行経路を評価する進め方として捉えます。
会議で分けて決めたい、三つの対応
先ほどの架空の会議に戻ります。AI対策という一つの議題を、三つに分けてみると、予算の使い道も明確になります。
第一に、今ある入口の不備を塞ぐ対応です。管理対象の確認、資格情報の管理、認可の点検など、すでに必要な作業を特定します。AIの関与を確認できないことを、対応を待つ理由にしません。
第二に、不備を見つけてから対応するまでの時間を縮める対応です。誰が連絡を受け、いつまでに影響を判断し、暫定制限と恒久修正をどう分けるかを決めます。最新製品を購入しても、その後の担当と期限が不明なら、ここは改善しません。
第三に、自社のAIエージェントを通じたアクセスを確認する対応です。どの利用者の依頼を、どのIDで、どのツールへ渡すかを描き、業務の責任者と開発担当者が確かめます。回答の正しさに加えて、実行したことの妥当性を見ます。
三つを分ければ、監視製品を買うかどうかだけで議論が終わらなくなります。担当、対象、期限、確認する証拠を、それぞれの対応に置けるからです。
速い修正と、安全な変更を両立できるか
攻撃の探索が速くなるなら、とにかく変更を急げばよいのでしょうか。ここにも別の判断があります。顧客向けシステムを変更してサービスを止めれば、別の業務被害が生まれ得ます。対応の速さだけを指標にすると、試験や復旧の準備が省かれるおそれがあります。
そこで、恒久修正を待つ間に何を制限できるかを分けて考えます。使われていない接続を閉じる、不要な操作を一時的に止める、対象を限定するなど、構成と業務に応じて選べる措置を担当者が検討します。どれも一般的な候補であり、適用の可否は現物の確認が必要です。
先ほどの、旧APIの管理状況が不明だった会議の例なら、まず利用中の処理と担当者を確認します。使われている理由がわかれば、止める影響を見積もれます。必要な経路なら、暫定制限と修正の順番を決め、変更後の正常な処理と拒否すべき処理を確かめます。急ぐことと、判断を省くことを同一にしません。
また、AIを使えば点検も自動化できるという提案では、処理時間の短縮だけでなく、見落としたときに何が残るかを確認しておきましょう。AIが候補を抽出した後、誰が重要度を判定するのか。誤って対象外にしたものを、どう発見するのか。この二点を確かめます。人の確認をすべて外してもよいという根拠にはなりません。
経営にとっては、この一連の時間を分けて報告してもらう方が役立ちます。発見まで、影響判断まで、暫定制限まで、恒久修正と確認までのどこで止まるかが見えれば、増員すべき役割や改善すべき承認も具体的になります。速さを一つの数字にまとめず、遅れを生む箇所へ投資します。
攻撃者側の生産性向上に向き合うなら、防御側も単に忙しくなるだけでは続きません。対象の把握、優先順位、変更、確認の流れを整え、その中で自動化の有効な場所を選びます。これが、AIという名前の対策を増やすこととは異なる経営上の取り組みになります。
AIの能力を推測するより、自社の対応時間を測る
AIの悪用がどこまで進むかには不確実性があります。しかし、自社の公開資産を更新する周期、変更を検知するまでの時間、修正完了を確認する手順は、調べれば見えます。
今週一つだけ確認するなら、直近で追加された外部接続を選んでみてください。申請、実装、台帳登録、権限審査、監視開始の時点を並べます。順番のずれが見つかれば、関係する担当者と埋め方を決めます。それは相手がAIを使っていても、人が作業していても価値のある改善になります。
AIが攻撃に使われているという事実を軽く見る必要はありません。同時に、AIだから防げないという受け止め方に陥らないことも大切です。変わった作業と、残った弱点を分けて読むことが、対策の精度を上げます。
参考情報
公表情報の確認基準日：2026年10月22日。架空の会議は一般的な判断場面の例であり、実在企業のやり取りではありません。
AILのサービス・プロダクトについて
AILでは、人材育成、実践知の蓄積・活用、導入に向けたコンサルティング、プロダクトの提供を通じて、企業のAI活用を支援しています。自社の課題に合った支援を、サービス紹介ページでご覧いただけます。
AI Librariumについて
本記事は、AI Librarium（アイブリウム）株式会社が発信しています。
AILは、専門家の知見や判断基準を、実務で使えるAI Skillとして届け、研修やコンサルティングを通じて企業の業務変革を支援します。その実践で得られた成果や課題を、AI Skillの改善と人材育成に活かし、次の変革につなげていくことを目指しています。
