不正アクセスが増え続ける時代で、AIを使いつつ情報を守るために何ができるか

私は毎日、Claude CodeとCodexというAIエージェントに、資料づくりから社内の仕組みの開発まで任せています。
処理量の多いタスクは、手元のPCで動くGemmaというモデルで回しています。

私は、以前自身のコラムで書いた「AIエージェントの禁止リスト」をもとに、AIに渡してよい情報の範囲を決め、ルールを守るための仕組みを今年の初春頃から少しずつ整えてきました。

当時、AIが動く環境を整えていたときから、今後増えていくだろうなと心配していたことがあります。

まさに、最近よくニュースで見かける「情報漏えい」です。

今回は、報じられているニュースと統計を踏まえ、私が実践している情報漏えいや誤操作への対策を紹介しようと思います。

最後に、AIを使っている人がやるべき「年末年始の休暇前にやること」もまとめました。
ぜひ読んでいってください。

▶ 組織のAI活用で気をつけるポイントを相談する

2026年秋。AIツールの認証情報を狙う攻撃まで出てきた。

2026年10月15日、ソースネクストは、会員情報を取得する仕組み（API）が不正に使われ、最大2,251万9,960件の会員情報が漏えいしたおそれがあると発表しました。
対象の情報には、氏名・住所・電話番号・生年月日・パスワードなどが含まれます（出典: @IT）。

同年10月7日には、IDCフロンティアのクラウド基盤がランサムウェアの攻撃を受け、影響は495の企業・自治体に広がっています（出典: ITmediaエンタープライズ）。

10月20日、NECはシステムの開発・保守を委託している企業への攻撃について発表しました。
同社の発表によると、攻撃者は、盗んだ正規のアカウントを使って顧客のシステムに侵入したとされています（出典: ITmedia NEWS）。

上記は最近のニュースではありますが、直接AIが狙われた事例ではありません。
しかし、AIそのものが情報漏えいの原因になった事例も報告されるようになってきています。

2026年9月。RIZAPの社員が、会社の管理外にある生成AIのサービスに、健康保険組合の加入者210名分のデータをアップロードしていたことが公表されています。
アップロードしたデータには、保険証の記号番号や生年月日、病名まで含まれていました。
発覚のきっかけは社員の自己申告でした（出典: ROCKET BOYS）。

10月21日には、AIのモデルにつなぐための部品として広く使われているLiteLLMに、情報を盗む不正なコードが混ざったバージョンが公開されました。
このバージョンを導入した環境では、Pythonを起動するだけで不正なコードが動きます。
その不正なコードは、ブラウザに保存したパスワード、SSHの秘密キー、クラウドの認証情報に加えて、Claude CodeやCursorといったAIツールの認証情報まで外部に送信するものでした。
（出典: LiteLLM公式の告知、GIGAZINE）。

10月15日には、Symantecが「Aoki」という情報窃取マルウェアを報告しています。
このマルウェアが狙うのは、Claude・Codex・Cursor・Gemini・GitHub Copilotなどの認証情報とログイン状態を保持するセッションファイルです（出典: Symantec）。

こういった状況に対して、公的機関も注意を促しています。

今年1月に公表されたIPAの「情報セキュリティ10大脅威2026」では、組織の脅威1位がランサムウェア、2位が委託先などを狙う攻撃でした。
そして2026年、3位に初めて「AIの利用をめぐるサイバーリスク」が入りました（出典: IPA）。

個人情報保護委員会も10月7日に注意喚起を出し、持っているデータが本当に必要かを確かめて、要らないものは消すよう求めています（出典: 個人情報保護委員会）。

懸念していた「気づかないうちに漏れる事故」が多発している。

私は以前のコラムで、人のミスは画面の警告や周囲の指摘で気づけることが多い一方、AIの誤操作は気づかないうちに進むことがある、と書きました。

AIは静かに動きます。
間違ったファイルを参照しても、間違った内容を出力しても、間違った操作を実行しても、机の上では何も起きません。

関連記事：AIの事故は、たぶん静かに進みます

その翌週の記事では、社員が個人で作ったAIの仕組みについて、次のように予測しました。

放っておくと、これから2つの形で「静かに死ぬ」事故が増えてくると、予測しています。

その1つが、機密情報や認証情報が、本人の知らないうちに漏れるという事故です。

個人で動かすAIハックには、しばしば認証情報や顧客の機密データが、ベタ書きで載っていることがあります。本人は「自分しか触らないから」と思って書いています。

ルールがない状態で個人ハックが社内に広がっていくと、こういうサイレントインシデントが、これから次々と顕在化してくると思ってます。

関連記事：個人のAIハックは、これから2つの形で「静かに死にます」

RIZAPの事例も、社員本人が申告しなければ、会社は加入者データのアップロードに気づけなかったはずです。
AIツールの認証情報を盗む攻撃も、利用者のPCに保存されたキーを狙っています。
漏えいの経路は違っても、本人や会社が気づかないうちに情報が外部へ渡るという懸念は共通しています。

ここで念のため記載しておきますが、私がここでお伝えしたいのは、自分の予測が当たったと言いたいわけではありません。
今年の春頃に「今後起きるだろう」と懸念していた事故が、1年も経たないうちにすでにニュースで、しかも多数報じられるようになっているということです。

件数で見ると人的ミスが多いが、大規模な情報漏えいはシステムの小さなミスが狙われている。

ニュースだけ並べて記載すると印象で語ってしまうので、統計も確かめました。

個人情報を扱う事業者などが令和7年度に個人情報保護委員会へ直接報告した漏えい等の事案は、13,345件ありました。
原因別では、誤交付・誤送付・紛失といった人的ミスが約80%を占め、不正アクセスは約10%です（出典: 個人情報保護委員会 令和7年度年次報告）。

一方、上場企業とその子会社を対象とした調査では、2025年に公表された漏えい・紛失事故180件のうち、64.4%をウイルス感染・不正アクセスが占めました。

100万人以上の個人情報が漏れる大規模な事故も、不正アクセスが中心です。
2026年は10月5日の時点で、100万人以上の情報が漏えいした事故が、すでに10件発生しています（出典: 東京商工リサーチ2025年、同2026年10月）。

不正アクセスの手口は、高度な技術を使うものばかりではありません。

警察庁によると、2025年のランサムウェア被害では、社外から社内ネットワークにつなぐVPN機器と、遠隔でPCを操作するリモートデスクトップが、侵入口の80%超を占めていると報告しています。

手口について、次のように書いています。

攻撃者は、未修正のぜい弱性、漏えいした認証情報や簡易なパスワード、設定不備等を悪用して組織のネットワークへ侵入する

（出典: 警察庁 令和7年におけるサイバー空間をめぐる脅威の情勢等について）

そして、2026年もランサムウェアの被害報告は増えつづけています。
2026年上半期のランサムウェアの被害報告は123件で、半期として過去最多を記録しています。

国内での情報漏えい届出件数では人的ミスが多いですが、大規模な漏えいでは、修正されていない機器の脆弱性や盗まれたパスワードが悪用されていることがわかります。

取引先や利用中のツールを経由した漏えいも増えています。
その多くは、機器の更新や認証情報の管理といった基本的な対策で防げるものだと考えています。

▶ 組織のAI活用で気をつけるポイントを相談する

AIを使うほど、情報漏えいや誤操作が起きる経路が増える。

私は、AIの業務利用で情報漏えいや誤操作が起きる経路を、次の3つに分けて考えています。

1. 人がうっかりAIに情報を入力する
   社員が顧客名簿や履歴書をそのままチャットに貼り付けたり、会社の管理外のAIに資料をアップロードしたりする

2. AIツールや委託先が攻撃を受ける
   AIの部品やツールに不正なコードが混入したり、PCに保存した認証情報が盗まれたりする

3. AIが送信や書き換えを実行してしまう
   AIエージェントが、メールの送信や本番環境のデータの書き換えを、人の確認なしに実行する

1つめは情報を入力する人、2つめは利用するツールや委託先、3つめはAIに与える権限の問題です。

AIを使う業務が広がるほど、情報を入力する人や接続するツールが増え、AIに任せる操作も多くなります。それだけ漏えいする機会も増えてしまうということです。

人によるAIの使い方や、AIツールを狙う攻撃の影響は調査にも表れています。
漏えいを経験した約600の組織を調べたIBMの2026年の調査では、43%が会社の管理外のAI（シャドーAI）が関わるセキュリティ事故を経験していました。
前年の調査でこの割合は20%なので、1年で2倍以上になっています。

また、AIのモデルやアプリが攻撃されて漏えいした組織のうち、92%はAIを利用できる人や操作を制限する「アクセス制御」を導入していませんでした（出典: IBM Cost of a Data Breach Report 2026）。

私が実践している4つの対策。

私の環境では、人による誤入力を防ぐために、入力ルールと自動検査を組み合わせています。
ツールを経由する漏えいには自動検査と定期点検で備え、AIによる送信や書き換えには人の確認を入れています。

以下で、それぞれの対策を説明します。

AIに渡さないものをあらかじめ決めておく

私の基本ルールは、個人情報と認証情報を、原則としてAIに渡さないことです。
ClaudeやCodex、ブラウザで使うAIサービスだけでなく、手元のPCで動くGemmaにも適用しています。

個人情報についてだけ、後で説明する例外を1つ設けています。

AIに渡さない個人情報には、氏名・連絡先・住所・生年月日・口座番号のほか、健康や家族の事情、履歴書や名刺に記載された情報も含めています。

認証情報は、パスワード・APIキー・トークン・秘密キーが対象です。
私はサーバー名やユーザー名も、AIに渡さない情報として扱っています。

逆に、案件の資料や議事録といった業務資料は、AIに読ませてよいことにしています。
すべての資料を禁止すると、AIを仕事に使えなくなるからです。

資料に個人情報が含まれている場合は、その部分を伏せたコピーを用意してからAIに読ませます。

以前の「AIエージェントの禁止リスト」の記事でも、同じ考え方を書きました。

APIキー、トークン、認証情報、顧客の個人情報。
この手のものは、AIのコンテキストにそもそも入れない、というのも例外なしのルールにしています。

関連記事：会社でAIエージェントを動かす前に、書いておきたい「禁止リスト」の話

例外として、名簿の整理など、個人情報を伏せると作業が成り立たない場合に限り、手元のPCで動くAIにだけ個人情報を渡します。

パスワードやAPIキーは、この例外でも渡しません。
ローカルのAIを取り上げたコラムでは、こう書きました。

手元で動く処理は、外にデータが出ません。

関連記事：AIの利用料を気にしなくなった代わりに、PCのメモリを心配しています

ただし、手元のAIが作成した結果ファイルには、個人情報がそのまま残ります。
そのファイルをClaudeやCodexに読ませると、個人情報をクラウドに送ることになります。

そういった場合、私は結果ファイルをクラウドのAIには読ませず、プログラムで件数などを集計し、個人情報を含まない集計結果だけを使うようにしています。

自動検査で読み取りや送信を止める

禁止リストの記事には、こうも書きました。

人間の注意力に頼った漏えい対策は、結局のところ漏れます。

ルールを決めても、人は急いでいると守りきれないことがあります。
AIも作業の途中で、認証情報が入ったファイルを開こうとします。

そこで私は、情報をAIに渡す前や、AIが読み取り・送信を実行する前に、内容を自動検査する仕組みを設けています。

検査するのは、私がAIに送る文章、AIが開こうとするファイル、AIが実行しようとするコマンド、外部のAIサービスや検索サービスに送る文章です。

検査の仕組みがメールアドレス・電話番号・マイナンバー・カード番号・口座番号や、各社のAPIキーに一致する文字列のパターンを検出すると、読み取りや送信などの操作を止めます。

認証情報が入ったファイルは、ファイル名でも判定して開かせないようにしています。
検査に失敗した場合も、操作を止めます。

操作を止めても、作業を続けられる場合はあります。
AIは個人情報などの中身を表示しない処理に切り替え、件数を数えるといった方法で作業を続けます。

コードの変更を記録する直前にも、APIキーなどの認証情報が混ざっていないかを自動検査しています。

また、各プロジェクトには、コードを共有する保管庫に登録してはいけないファイルの一覧を用意しています。
設定ファイルの名前だけでなく、バックアップやコピーによく使われるファイル名のパターンも登録しています。

設定ファイルに書かれたパスワードやAPIキーそのものは、AIとの会話画面に表示しません。
必要なときは、私がAIを介さずにファイルを開いて確認します。

AIとの会話は外部に記録が残るため、認証情報を表示した時点で、外部に渡したのと同じだと考えています。

送信や削除は人が実行する

本番環境の顧客データなどは、個人情報を伏せたものだけをAIが見ても良いことにしています。
また、AIがデータを勝手に書き換えないよう、許可する操作は読み取りだけにしています。

データを書き換えるときは、AIに対象・件数・影響範囲・元に戻す方法を提示させ、私が確認してから進めます。

メールやチャット、契約に関する送信は、AIが下書きと確認画面まで用意し、最後の送信ボタンは私が押します。
データを削除するときも、AIには確認画面までを用意させ、私が実行します。

強制的な上書きや全件削除など、元に戻せない操作は、AIが実行できないように設定しました。
外部サービスとの連携でも、AIには読み取りと検索だけをあらかじめ許可し、書き込みや送信の前には毎回、私に確認を求めるようにしています。

Googleのデータに接続するときは、AI専用のアカウントでアクセスするようにしています。
AI専用アカウントで操作できるのは、そのアカウントに共有したフォルダだけ。
私が使っているアカウント権限を、AIが使うことはできません。

AIが作成した成果物は、別のAIのレビューを経ないと記録できないようにしています。
レビューの対象には、コードだけでなく実行計画も含めています。

同じAIが作成とレビューを担当すると、同じ前提で判断し、誤りを見落とすおそれがあるからです。

レビューを担当するAIから「このままでは動作しない」と指摘された箇所は、その場で修正し、事故につながる可能性を指摘された場合は、私が修正するかどうかを判断し、その理由を記録してから進めています。

定期点検で異常を見つける

異常を見つけるための監視や点検については、以前のコラムでこう書きました。

観測は、事故を防ぎません。
観測は、事故が起きていることに気づける状態を作るだけです。

私は毎週1回、認証情報を保存したファイルのアクセス権限、GitHubでコードを保管するリポジトリの公開設定、キーの有効性、レビュー機能の動作を自動点検しています。
異常を検出したときだけ通知を受け取り、通知文には認証情報そのものを載せないようにしています。

APIキーなどの有効期限は、台帳で管理しています。発行時にしか期限が表示されないキーは、その場で期限を記録し、期限が切れる前に警告が出るようにしました。自動検査で操作を止めたときも、日時・理由・検出した場所だけを記録し、検出した個人情報や認証情報そのものは残しません。

▶ 組織のAI活用で気をつけるポイントを相談する

とはいえ、守りのバランスも大事。

手元のAIに個人情報を渡すときは、最初は実行のたびに確認の画面を出していました。
ところが、確認の画面が時間切れで閉じて、処理が何も進まないまま終わることが何度か続きました。

そこで、手元のPCで動くAIに個人情報を渡す場合に限り、毎回の確認をやめました。
確認を厳しくしすぎると、必要な作業まで止まってしまいます。
確認が必要な操作と不要な操作をあらかじめ分けるほうが、ルールを守りながら仕事を続けられます。

ただし、自動検査にも限界があります。
氏名や病歴などの個人情報は、文字列のパターンだけでは判別しきれません。
検査で見つけられない情報もあるため、AIに渡さない情報をルールとして決めておく必要があります。

また、利用者が意図的に検査を避ければ、情報を送れてしまう場合もあります。
この仕組みは、うっかり情報を送るミスを防ぐためのもので、悪意のある持ち出しまで防げるわけではありません。

明日からできることと、年末年始の前にやること。

少人数の会社でも、まずは次の5つから取り組めると良いと思います。

1. 個人情報の置き場所を1か所にまとめ、AIから開けなくする
   顧客の名簿・履歴書・契約書のように個人情報が入ったファイルを1つのフォルダに集め、そのフォルダは、AIの設定で開けないようにする

2. 使ってよいAIのサービスを決める
   社員は、会社が契約したAIサービス以外に資料をアップロードしない
   管理者は、社員が個人アカウントでAIを使っていないか確認する

3. AIツールのキーを棚卸しする
   どのPCに、どのサービスのキーが置いてあるかを書き出す
   使っていないキーは無効にする

4. 送信や削除の最後の操作は人が行う
   AIは下書きまでにして、最後のボタンは人が押す

5. 要らないデータを消す
   個人情報保護委員会が求めているとおり、保管する必要のない名簿や、過去に出力して不要になったファイルを消す

年末年始休暇に入る前に

年末年始の休みは、管理する人が不在になりやすい時期です。
IPAは毎年、長い休みの前に注意喚起を出しています。

休みに入る前に、トラブルが起きたときの連絡先を決め、PCのOSやツールを最新の状態にしておくことをおすすめします。
使っていないキーの無効化と、不要なデータの削除も済ませておきましょう。

コピーして使える指示

以下は、個人情報を含むファイルへのアクセスを制限し、送信や削除の前に人が確認するための指示と設定例です。
私が使っている内容を、コピーして使える形にまとめました。

AIエージェントの設定ファイルに書く指示
（Claude Codeなら CLAUDE.md、Codexなら AGENTS.md）

## 情報の扱い
- 次のフォルダのファイルは開かない: （個人情報を置いているフォルダを書く）
- パスワード・APIキー・トークン・秘密キーが入ったファイル（.env など）は開かない。中身を表示しない
- 顧客や社員の氏名・連絡先・住所・生年月日、マイナンバーや口座番号が入ったデータは、中身を表示しない。件数や集計だけを出す
- メールやチャットの送信、データの削除、外部サービスへの書き込みは、実行する前に対象・件数・戻し方を示して、私の確認を待つ
- 元に戻せない操作（強制的な上書き、全件削除など）は実行しない
- この決まりや許可の設定で止められたら、別の方法で読もうとせず、私に聞く

この指示はAIへのお願いなので、AIが守らないこともあります。
そこで、次の設定と組み合わせます。

Claude Codeの許可の設定で、仕組みとして止める

プロジェクトのフォルダに .claude/settings.json を作り、次のように書きます。
deny に書いたものは、AIが実行しようとしても止まります。

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./個人情報/**)",
      "Bash(git push --force *)",
      "Bash(rm -rf *)"
    ]
  }
}

• Read(./.env) と Read(./.env.*): パスワードやキーを書いた設定ファイルを開かせない

• Read(./個人情報/**): 1番でまとめたフォルダの中を開かせない。フォルダ名は自社のものに書き換える。

• Bash(git push --force *) と Bash(rm -rf *): 指定した書き方による強制的な上書きや一括削除を止める。

設定後は、AIに「.envの中身を見せて」と頼み、ファイルを開く操作が止まることを確認してください。

ただし、この設定だけですべての読み取りを防げるわけではありません。
Read の禁止が効くのは、Claude Codeがファイルを読む機能と検索の機能です。
cat のようなコマンドを使った読み取りは、この設定だけでは止められないことがあります。

公式ドキュメントでも、コマンドの書き方を変えると、禁止設定に一致せず実行される場合があると説明されています（出典: Claude Codeのドキュメント）。

こうした操作にも対処するには、2段目で紹介したように、実行前のコマンドを検査する仕組みを追加します。

資料から個人情報を見つけたり伏せたりするプロンプトは、あえて載せていません。
その処理をAIに頼むために、先に個人情報を渡すことになってしまうからです。

▶ 組織のAI活用で気をつけるポイントを相談する

AIを安全に使い続けるために、渡さない情報と人が行う操作を決める。

私は、情報漏えいのリスクがあるからといって、AIの利用をやめる必要はないと思っています。

AIに渡さない情報と、人が確認して実行する操作を先に決めれば、個人情報や認証情報の誤送信、意図しないデータの書き換えや削除を防げる場面は増えます。

Deflagでは、業務にAIを導入するための設計から実装までお手伝いしています。
AIに渡してよい情報の範囲や運用ルールから相談したい方は、Deflag公式サイトのお問い合わせフォームか、下記のX・LinkedInからご連絡ください。

今回紹介した自動検査の考え方や、AIに渡さない情報の一覧もお見せできます。

Deflagをもっと知りたい方へ

🌐 コーポレートサイト → https://deflag.net
𝕏 X（Twitter） → https://x.com/nakamae__deflag
📝 note → https://note.com/nakamae_deflag
💼 LinkedIn → https://www.linkedin.com/in/shuta-nakamae-18392828a