2026年10月9日、IPA（情報処理推進機構）が「不正アクセスによる漏えい等の事案を踏まえ、速やかに実施すべき対策等について」という注意喚起を出しました。金融機関や通信事業者で、大量の個人情報を扱うサービスに侵入され、データが持ち出される事案が続いている、という内容です。同じ月に、AIエージェントを使って100社を超える企業サイトに侵入した事件の報道と、別のAIエージェント群が27社に侵入してカード情報60万件超を持ち出したという報告が並びました。

この記事で書きたいのは、侵入を防ぐ話ではありません。侵入されたあとの話です。入られた日に、何件を失うか。それは運ではなく、データの持ち方の設計で決まる、というのが当社の見方です。読者は、自社の顧客情報や社員情報をクラウドのサービスや自社のシステムで持っている会社の経営者と、情報システムの担当者です。

結論を先に書きます。

  1. 侵入を前提にします。 2026年10月に報じられた事例には、既知の脆弱性の悪用と、アカウントの侵害が含まれます。このうち2つの報告では、AIエージェントによる攻撃の自動化が確認され、AI利用料が対象1社あたり数十ドルの例や、侵入の成功例では1日未満で到達したケースが報告されています。入られないことだけに賭ける設計は、もう成り立ちません
  2. 持ち出される量は、5つの設計で決まります。 持たない、分ける、量に上限を置く、暗号化と鍵を分ける、大量の読み出しを検知して止める。何を持ち、どの鍵を分け、どこに線を引くかは自社で決めることで、設定できる範囲は使っているサービスで確かめます
  3. AIエージェントを使う会社には、6つ目があります。 エージェントに渡す道具を、読める範囲と量で決める。指示で止めるのではなく、最初から持たせない設計です

2026年10月に報じられた事例

まず、事実を並べます。当社が元の資料と報道で確認したもので、確認日は2026年10月30日です。発生した時期と報じられた時期は分けて書きます。

2026年10月に報じられた不正アクセスの事例5件を、起点、攻撃に要した時間と発見までの時間、確認された被害の3つで並べた表

事例 起点 攻撃に要した時間・発見まで 確認された被害
米国防総省の人事データセンター（ITmedia NEWS・2026年10月9日） ファイル共有システムの脆弱性 攻撃に要した時間は不明。2025年10月から2026年7月16日まで、約9か月間アクセスされていた 300万人余りの社会保障番号・氏名・生年月日などが不正に閲覧された。暗号化されていないサーバーにあった
AIエージェント群による27社への侵入（週刊アスキー・2026年10月5日。発生は2026年9月10日から15日） 既知の脆弱性を3種類のAIエージェントが自動で探索 侵入まで1日未満、場合によって数時間。発見までの時間は不明 2社から60万件超のカード情報。19サイトにカード窃取スクリプト
AIエージェントによる100社超への侵入（TNW・2026年10月19日。発生は2026年9月25日から） 各サイトの弱点をAIエージェントが探索。侵入経路は対象ごとに異なる 成功した攻撃は平均23時間弱。発見までの時間は不明 持ち出された量は未確認。Webシェルが設置され、長期的なアクセスの維持が目的とみられる
Google広告の代理店アカウント（ITmedia NEWS・2026年10月7日。発生は2026年10月5日） 管理業務に使っていたGoogleアカウント1つ。パスキーとセキュリティキーを設定していた。侵入経路は未特定 不正なユーザーの追加から13分で把握 配下のすべての顧客アカウントが被害の対象となり、顧客アカウントからカジノ広告が配信された
AIコーディングツールOpenCode（TechCrunch・2026年10月19日） ユーザーがAPIキーを保存するオンラインの管理画面の古いシステム 攻撃の試行は48時間続いた。発見までの時間は不明 管理画面の利用者の1.4%のAPIキー。1,000ドルを超える不正請求も

5件には、既知の脆弱性の悪用と、アカウントの侵害が含まれます。IPAの注意喚起も、公表された事例から「外部公開アプリケーションやアカウントの侵害が起点と見られる」と書いています。Google広告の事例のように、侵入経路が特定できていないものもあります。

5件のうち2件では、攻撃側の自動化が確認されています。週刊アスキーが伝えたGambit Securityの報告では、脆弱性を探す「Strix」、侵入を進める「Cairn」、全体を管理する「Hermes」という3種類のAIエージェントに、「脆弱性レポートを見てから始めて」「管理画面に入って」という短い指示を与え、101件のスキャンに使ったAI利用料は1社あたり平均25.46ドルでした。記事は、これが攻撃の総コストではないと注意を添えています。TNWが伝えたNorForgeの報告では、オープンソースのエージェント基盤Cairnの上で、2026年9月25日から1,200を超えるサイトへ侵入が試みられ、100社超で成功しています。研究者のSnorre Fagerland氏はReutersに、トークン費用は約5,000ドル、成功1件あたり約50ドルと概算しました。NorForgeがこの活動を見つけたのは、攻撃者が使っていたCairnの管理画面がインターネットに公開されたままになっていたからです。

攻撃の自動化で変わるのは、多数の候補を、人手をかけずに調べ続けられることです。NorForgeの報告では、対象は米国・カナダ・日本・オーストラリアのオンラインショップで、アクセス規模でも選ばれていました。対象を選ばないわけではありません。それでも、企業の規模だけを理由に、自社は対象外だとは判断できなくなりました。ここが、2026年に設計を考え直す理由です。

「入れない」は必要条件でしかない

IPAの注意喚起の前半は、「速やかに行うべき点検」と「速やかに取り組むべき対策」です。外部公開アプリケーションのログの確認、利用している外部サービスの洗い出し、未適用のパッチ、作った覚えのないアカウントの確認。多要素認証の強化、アカウントへの権限付与の見直し、API連携の管理、ログの取得内容と保持期間。これらは、入れないための対策で、全部やるべきことです。当社も、この一覧を自社の点検表に取り込みました。

それでも、当社がこの記事で「入れない」を主題にしないのは、上の5件が教えているからです。パスキーとセキュリティキーを設定していたアカウントが乗っ取られ、侵入経路は特定できていません。9か月間、不正なアクセスに気づかなかった組織があります。入れないための対策は、必要条件です。十分条件ではありません。

IPAの注意喚起には、入れないための対策のあとに、もう1つの柱があります。「保有データの再点検」です。原文の言葉を引くと、「不要な情報は持たない、という基本原則」のもとで、保有する情報資産を必要最小限にする。対策の節では、データを持つこと自体の是非の再検討、保管場所の再検討、データアクセスのログ、データの暗号化、を挙げています。

当社の読み方では、この柱が「入られたあと」の設計です。注意喚起の中では短い記述ですが、当社はここを5つに分けて、自社の決まりにしています。

5つの設計

持ち出させない5つの設計を5段で示した図。持たない、分ける、量に上限を置く、暗号化と鍵を分ける、大量の読み出しを検知して止める

1. 持たない

集めない、消す、の2つです。

集めないは、申込フォームや会員登録で、使う予定のない項目を取らないこと。生年月日、住所、勤務先。あとで使うかもしれない、で取った項目は、持ち出された日に、使わなかった項目として失われます。消すは、使い終わったデータを残さないこと。退職した社員の情報、終了した案件の顧客情報、キャンペーンの応募者一覧。持っていなければ、持ち出されません。

当社の決まりは2つあります。名簿は社外に出さない。個人のデータは、公開しているコードやファイルと同じ場所に置かず、データベースの中だけに持つ。どちらも、何を持つかを先に決めて、持たないものを増やさない形です。

自社でできることは、持っているデータの一覧を1枚にすることです。何を、どこに、何件、誰のために。この一覧は、IPAが言う「保有する情報資産を正確に把握」そのものです。一覧ができると、消してよいものが見えてきます。

2. 分ける

1か所に全件を置かない。1つの鍵で全件に届かせない。この2つです。

Google広告の代理店アカウントの事故は、この設計の話だと当社は読んでいます。顧客の広告アカウントをまとめて管理するアカウントが1つ乗っ取られ、配下のすべての顧客アカウントが被害の対象になり、顧客アカウントから不正な広告が配信されました。そのアカウントに管理者権限のユーザーが3件追加されたのが14時02分、翌分には自社の権限が取り消され、14時35分から47分の間に顧客アカウントが外部の管理アカウントへつなぎ替えられています。1つの資格情報が、全顧客に届く構造でした。

これは広告代理店だけの話ではありません。会計のSaaS、顧客管理のSaaS、ファイル共有。1つの管理用のアカウントが、すべての顧客、すべての社員、すべての取引先の情報に届く設計は、どの会社にもあります。

自社でできることは、鍵の到達範囲の表を作ることです。縦に、自社で使っている管理用のアカウントとAPIキー。横に、持っているデータの一覧（設計1で作ったもの）。それぞれの鍵が、どのデータの全件に届くかに印を付けます。全件に届く鍵が何本あるかを数え、用途ごとに分けられないかを考えます。顧客対応の担当者が使う鍵は、担当している顧客の分だけ。集計用の鍵は、個人を特定する項目を含まない形で。

OpenCodeの事故では、ユーザーがAIサービスのAPIキーを預けていた管理画面が侵入され、預けていたキーで不正な利用が発生しました。預けたキーが、そのサービスに必要な範囲より広い権限を持っていれば、その分が失われます。この話は漏れたAPIキーを誰が止めるかで、鍵を守る4つの層として書きました。

3. 量に上限を置く

1回の要求で返す件数、一定期間に読める量、書き出しの承認。この3つに上限を置きます。3つは役目が違います。

侵入者が欲しいのは全件です。1回の問い合わせで全件が返るシステムは、侵入された瞬間に全件を失います。1回に返す件数に上限があれば、一括で取ることはできなくなり、全件を取るには何千回、何万回の要求が要ります。ただし、1回の上限だけでは、繰り返せば累積で全件に届きます。累積を抑えるには、1日や1時間あたりの取得量にも上限を置き、超えたら要求そのものを拒否する仕組みが要ります。1回の上限は一括取得を止め、期間の上限は累積を止める、という分担です。

当社の例を書きます。当社のデータベースには、1回の要求で返す行数の上限と、1日の読み取り量を見張る仕組みがあります。もともとは費用のために置いた上限です。データベースの読み取りが課金の単位なので、1回の要求で何万行も読む問い合わせを許すと、費用が跳ねます。この上限は、一括の持ち出しを止める上限でもあります。費用を抑えるために決めた数字が、そのまま、1回の要求で失う量の上限になっていました。1日の読み取り量のほうは通知で、取得を拒否する仕組みではないので、通知が来たあとの確認と停止の手順を別に決めています。

自社でできることは、全件の書き出しを人の承認にすることです。SaaSには、一覧をCSVで書き出す機能を持つものがあります。この機能を誰が使えるかを決め、使える人を絞り、使ったら記録が残るようにします。書き出しを禁じる必要はありません。書き出す人と回数が平常の値として分かっていれば、それと違う書き出しが見えます。設定できる範囲はサービスと契約プランで違うので、先に確かめます。

4. 暗号化と鍵を分ける

米国防総省の人事データセンターの事例は、暗号化されていないサーバーに個人情報があり、権限のないユーザーがファイルにアクセスできる状態が9か月続いた、と報じられています。平文の全件は、持ち出された瞬間に全件が価値になります。

暗号化は、復号できない相手に暗号文が渡ったときの悪用を抑える設計です。ここで確かめるのは、保存時に暗号化しているかだけではありません。誰が復号を要求できるか、侵入されたアカウントから平文を取得できるか、までです。保存時に暗号化していても、読み取りのたびに自動で復号する仕組みなら、読み取りの権限を奪った侵入者は平文を手にします。鍵を別の場所に置き、鍵へのアクセスを別の権限で守って、初めて設計になります。

自社でできることは、2つです。1つは、使っているSaaSやクラウドのストレージについて、保存時の暗号化の有無と、鍵を誰が持つかを確かめること。サービス提供者が鍵を持つ形で足りる業務と、自社で鍵を持つ必要がある業務を分けます。もう1つは、社内のPCやファイルサーバーにある個人情報の一覧を、暗号化されていない状態で置かないこと。Excelの顧客一覧がダウンロードフォルダーに残っている、という状態が、いちばん平文に近い状態です。

5. 大量の読み出しを検知して止める

9か月間の不正なアクセスを早く見つけるには、監視の条件と、見つけたあとの対応の手順が要ります。

検知には、平常の値が要ります。1日に何件読まれるか、誰が書き出すか、どの時間帯に問い合わせが来るか。平常の値を知っていれば、桁が違う読み出しが見えます。知らなければ、何が異常かが決められません。IPAの注意喚起も、点検の手順の中で、ログイン失敗の量やログイン元、ログイン時間を「平時と比較する」ことを求めています。比較するには、平時の記録が要ります。

当社の例では、費用管理のために置いた1日の読み取り量の監視を、不審な大量取得を調べるきっかけとしても使っています。通知が来るだけでは取得は止まらないので、通知のあとに誰が確かめ、どう止めるかの手順を決めてあります。

自社でできることは、月に1回、読み出しの量と書き出しの記録を見ることに加えて、桁が違う読み出しのような大きな異常は、その場で通知が来るようにすることです。SaaSの監査ログ、クラウドのアクセスログ、データベースの読み取り量。月に1回は、先月と比べて桁が変わっていないかを見ます。平常の量に紛れる取得は、この見方では見つかりません。それを補うのが、設計2と設計3です。

5つの設計で、侵入者が届く件数はどう減るか

5つを別々に読むと、どれも地味に見えます。並べると、1つの図になります。

5つの設計を通ると、侵入者が届く件数がどこで減るかを上から下へ示した図。保有する全件、1つの鍵で届く範囲、1回の要求で返る件数、検知が止めるまでの量、鍵なしで読める平文の順に狭まる

いちばん上が、自社が持っている全件です。設計1の「持たない」で、ここが小さくなります。次が、乗っ取られた1つの鍵で届く範囲です。設計2の「分ける」で、全件ではなく一部になります。次が、1回の要求で返る件数と、期間あたりの取得量です。設計3の「上限」で、一括では取れず、繰り返しても期間の上限で拒否されます。次が、異常に気づいて止めるまでに読まれる量です。設計5の「検知」と停止の手順で、ここを短くします。最後が、持ち出されたデータのうち、鍵なしで読める平文です。設計4の「暗号化」で、復号できない相手には使えない形になります。

どこか1つで止まれば十分、という設計ではありません。5つは、それぞれ別の失敗に備えています。鍵を分けても、分けた鍵が全部盗まれることはあります。上限を置いても、上限の範囲で長く読まれることはあります。検知の線の下に紛れる取得もあります。だから5つを重ねます。1つの対策が破られた日に失う量を、次の対策が決める、という順番です。

AIエージェントを使う会社の6つ目

ここまでの5つは、AIと関係なく成り立つ設計です。AIエージェントを業務で使い始めた会社には、6つ目が要ります。

エージェントに渡す道具を、読める範囲と量で決める。 指示で止めるのではなく、最初から持たせない設計です。

PwCコンサルティングの村上純一氏が2026年6月に書いた「AIエージェントの基本構造と論点整理」は、会話型のAIとエージェントの違いを6つ挙げています。当社の読み方で要約すると、行動範囲（API呼び出しやデータベース操作を実行し、元に戻しにくい）、ツール利用（個々のツールが安全でも、組み合わせで権限の拡大や情報漏洩が起こりうる）、メモリ（蓄積した誤りが再利用される）、人間の関与（複数のエージェントが連携し、責任の所在が分散する）、ID特性（エージェントが独立したIDでアクセスする）、リスクの性質（実世界に直接、不可逆に及ぶ）です。同じコラムは、自律レベル4以上では、人を中心にした従来の管理の考え方ではカバーしきれない、と書き、認証・認可・アクセス制御・監査を集約する「ID・ガバナンス」の層を、エージェントの行動範囲と権限を決める要に置いています。

当社の運用に当てはめると、こうなります。当社には、記事の原稿と図版を無人で作るエージェントがあります。このエージェントは、原稿を書くフォルダーには書き込めますが、git の操作も、SNSへの投稿も、公開の操作もできません。それらの道具を、最初から渡していないからです。指示に「投稿しないでください」と書く方法もありますが、指示は読み違えや、外部から混ぜ込まれた文で迂回されることがあります。道具を渡さないほうが確かです。ただし、専用の道具を渡さないだけでは足りません。汎用のコマンド実行や外部との通信ができて、投稿先の認証情報に届くなら、同じ操作は別の経路でできてしまいます。実行できる範囲、通信してよい先、認証情報へのアクセスの3つを合わせて決めます。

もう1つ、読める量です。エージェントに社内のデータベースを読ませるとき、何件まで返すかを、エージェントの設計ではなく、データベース側の権限で決めます。これは設計3と同じ考え方で、エージェントが乗っ取られても、乗っ取られたエージェントが読める量は変わりません。

Cairnの事件で、NorForgeが見つけたのは、攻撃者が使っていた管理画面がインターネットに公開されたままになっていたことでした。管理画面のデータからは数百件の認証情報やAPIキーが見つかり、検証した11%が有効だったと報じられています。攻撃対象から得たとみられる認証情報が、攻撃者の管理画面に露出していて、被害がさらに広がる状態でした。エージェントに渡した鍵や、エージェントが集めた鍵が、管理画面の公開1つで外に出る。これはエージェントを使う側の全員にあてはまる話です。

エージェントをどこで動かすかはAIエージェントを安全に動かすサンドボックスの選び方に、Windowsで触れる範囲をOS側で決める仕組みはMicrosoft Execution Containersの記事に書きました。Copilotに社内データを読ませる前に権限を見直す手順はMicrosoft 365 Copilotのデータ権限の記事にあります。

自社で書く順番

5つの設計を自社に落とすとき、当社は次の順で進めます。製品を買う前に、紙で決める順番です。

自社で持ち出させない設計を書く順番を、経営者、情シス、担当者の3つのレーンで示した図。持っているデータの一覧、鍵の到達範囲の表、上限と書き出しの承認、平常の値と警戒の線、経営者が決める、の順に進む

持っているデータの一覧を作る。 担当者が、何を、どこに、何件、誰のために持っているかを書きます。SaaSごと、ファイルサーバーのフォルダーごと、Excelの一覧ごと。ここで、持っていること自体を知らなかったデータが出てきます。それが、最初に消す候補です。

鍵の到達範囲の表を作る。 情報システムの担当者が、管理用のアカウントとAPIキーを縦に、データの一覧を横に置き、全件に届く鍵に印を付けます。印の数が、侵入された日に全件を失う経路の数です。

上限と書き出しの承認を決める。 1回の要求で返す件数、1日の読み取り量、CSVの書き出しを使える人。業務が止まらない値を、使っている人と一緒に決めます。上限は、きつければ業務が止まり、緩ければ意味がありません。

平常の値を記録し、警戒の線を引く。 1か月分の読み出しの量と書き出しの記録を取り、先月と比べる線を決めます。記録を集めている間も、桁が違う読み出しのような大きな異常には暫定の線を引いておき、実績に合わせて調整します。線と一緒に、通知が来たら誰が確かめ、どう止めるかの手順を決めます。

経営者が決める。 何を持たないか、どの鍵を分けるか、どこに線を引くか。IPAの注意喚起は、経営者が自らのリーダーシップのもとで対策を進めることを求めています。当社も同じ考えで、この5つは情報システムの担当者が1人で決められることではなく、業務を変える判断だからです。

注意点

入れないための対策を捨てないでください。 この記事は「入られたあと」を主題にしましたが、IPAの点検と対策の一覧は、先にやることです。パッチ、多要素認証、不要なアカウントの削除、公開範囲の見直し。入られる回数を減らした上で、入られた日に失う量を決めます。

暗号化は、鍵をどこに置くかまで含めて設計です。 暗号化済み、と書かれたサービスを使っていても、鍵を持つのが誰かで、守られ方は変わります。自社で確かめるのは、暗号化しているかではなく、誰が鍵を持ち、鍵なしで読める人が誰かです。

上限は、業務を見てから決めてください。 全件の書き出しが毎月の業務に組み込まれている会社で、書き出しを禁じると、業務が止まるか、別の経路で全件が持ち出されます。禁じるのではなく、承認と記録を付けます。

検知の線は、平常の値に合わせて調整します。 平常の値を知らずに引いた線は、通知が多すぎて見なくなるか、少なすぎて役に立ちません。最初は大きな異常だけを拾う暫定の線にし、1か月の記録を見てから細かくします。通知は停止ではないので、通知のあとの手順まで決めて初めて検知になります。

AIエージェントの指示は、設計の代わりになりません。 「社外に送らないで」「全件を読まないで」という指示は、読み違えや、外部から混ぜ込まれた文で迂回されることがあります。送る道具を渡さない、通信先と認証情報へのアクセスを限る、読める量を権限で決める、のほうが確かです。

KOIYALの見解

当社は、インハウス経営（AIを活用し、自社で業務を改善し、自社で仕組みをつくる経営）を支援する会社です。セキュリティの話を、その文脈で書いています。

自社で仕組みをつくる会社は、自社でデータを持ちます。外注していた仕事を自社でできるようになるほど、顧客の情報、社員の情報、取引の記録が、自社のシステムに集まります。これは、インハウス経営の成果であると同時に、入られた日に失う量が増える、ということでもあります。だから当社は、仕組みをつくる支援の中に、持たない、分ける、上限を置く、暗号化する、検知する、の5つを最初から入れます。あとから足すと、業務を変えることになるからです。

もう1つ。5つの設計は、決めることと、設定することに分かれます。決めることは、製品を買わなくても始められます。持っているデータの一覧と、鍵の到達範囲の表は、紙とExcelで作れます。設定することは、使っているサービスと契約プランで、できる範囲が違います。取得の上限、書き出しの承認、監査ログの取得が設定できるかを確かめ、できなければ追加の実装か、専門家への相談を考えます。セキュリティは専門家に任せるもの、と考えている会社ほど、決めることのほうを自社で持ってほしいと当社は思っています。専門家に頼むのは、脆弱性の診断と、侵入されたときの調査と、設定できない部分の実装です。何を持ち、何を持たないかを決めるのは、自社の仕事です。

読者の会社が自社でできるようになることを1つ挙げるなら、鍵の到達範囲の表を自社で書き、更新し続けることです。新しいSaaSを契約するたび、新しいAPIキーを発行するたび、表に1行足す。この1行が、1つの鍵で全件に届く経路を、増やさないための決まりになります。

次の行動

  1. 持っているデータの一覧を、SaaSごと、フォルダーごとに1枚書く。何を、どこに、何件、誰のために
  2. 管理用のアカウントとAPIキーを縦に、データの一覧を横に置いて、全件に届く鍵に印を付ける
  3. 先月の読み出しの量と、CSVの書き出しの記録を1回見る。平常の値を知るところから

3つが終わったら、その表を持って相談してください。AIコンサルティングの初回の打ち合わせでは、鍵の到達範囲の表を一緒に読み、どの鍵から分けるか、どこに上限を置くかを、業務を止めない形で決めます。お問い合わせの本文に、使っているSaaSの名前と、全件に届く鍵の本数を書いていただければ、初回の前に当社で5つの設計の仮置きをお持ちします。

参考