Claude CodeやCursorなどAIコーディングツールにログファイルやDBダンプを読み込ませて調査を頼む場面は珍しくありません。しかし、そのファイルにユーザーの氏名やメールアドレス、認証トークンが混ざったままモデルに渡されているケースが見過ごされがちです。エージェント型のAIツールを日常的に使っている開発者・SRE・QA担当者に向けて、この落とし穴を整理します。
特にMCP（Model Context Protocol、AIツールが外部システムのデータやツールに接続するための標準規格）経由でDBやファイルストレージに直接アクセスできる構成では、影響範囲がさらに広がります。何が起きているのか、なぜ起きるのか、自分の環境が該当するかを順番に確認していきます。
何が起きるか：ログや添付ファイル経由でPIIがモデルに流れ込む
AIコーディングツールにエラー調査を依頼するとき、開発者は本番ログやスタックトレースをそのまま貼り付けがちです。
このログには、ユーザーのメールアドレス、電話番号、アカウントID、時には認証情報（APIキーやセッショントークン）が含まれていることがあります。
PII（Personally Identifiable Information、個人を特定できる情報）は名前やメールアドレスだけではありません。デバイス識別子や行動履歴の一部もPIIに含まれ得ると整理されています。
クラウド型のAIサービスにこれらを送信すると、そのデータは会話履歴としてベンダー側に一時的または長期的に保持されます。
さらに厄介なのは、MCPサーバーを通じてAIエージェントがDBやSaaSに直接クエリを投げられる構成です。この場合、開発者が「貼り付けた」意識すらないまま、機微情報がモデルのコンテキストに読み込まれます。
なぜ起きるか：設計段階でデータのライフサイクルが定義されていない
根本原因は、AIツール導入時に「どのデータをどこまで見せてよいか」が決まっていないことです。
データには本来、収集・分類・検証・処理・保管・利用・共有・保持・削除という一連のライフサイクルがあります。各段階でセキュリティとプライバシーの管理策を置くのが本来の設計です。
ところが多くの現場では、AIツールの導入は「便利だから使ってみる」という形で先行し、このライフサイクル設計が後回しになります。
さらに、データ分類（Public・Internal・Confidential・Restrictedのような区分でデータの機微度を分ける手法）が組織に存在しない場合、どのログが「渡してよいもの」でどれが「渡してはいけないもの」かを判断する基準自体がありません。
もう一つの原因は、Privacy by Design（設計段階からプライバシー保護を組み込む考え方）の不在です。この考え方の核心は「いつか使うかもしれないから」という理由でデータを収集・保持しないことにあります。
AIツールに渡すログやファイルも同じで、「調査に必要な最小限の情報」に絞る発想がなければ、必要以上の個人情報がまとめてモデルに流れ込みます。これはデータ最小化（data minimization）と呼ばれる原則の欠如そのものです。
自分のプロジェクトが該当するか確認する
次の観点で、自分のプロジェクトやチームの運用を点検してみてください。
- AIツールにログを貼り付ける際、氏名・メール・電話番号・トークンをマスキングする手順がドキュメント化されているか
- MCPサーバー経由でDBやオブジェクトストレージにAIエージェントが接続できる設定になっていないか（設定ファイルの
mcp.jsonや.claude/settings.json、Cursorのmcp_configなどを確認） - 利用しているAIツールの設定で「会話履歴をモデル学習に使うか」のオプションがどうなっているか（ChatGPTやClaudeの管理コンソールにあるデータ利用設定）
- 社内にデータ資産の棚卸し（データインベントリ）があり、どのログにPIIが含まれるか把握できているか
- ログ出力自体に個人情報をそのまま出す実装になっていないか（アプリケーションコード側のログ出力処理）
上記のうち2つ以上が「わからない」「決まっていない」場合、AIツール経由でのPII漏えいリスクは高いと考えたほうがよさそうです。
実際に確認する際は、まずリポジトリ内でgrep -r "mcp" .claude/ .cursor/ 2>/dev/nullのようなコマンドで、MCP関連の設定ファイルがどこにあるか洗い出すところから始めるとよいでしょう。
# MCP設定ファイルの所在を確認する例
grep -rl "mcpServers" . --include="*.json" 2>/dev/null設定ファイルが見つかったら、そこに列挙されているサーバーがどのDBやAPIに接続する権限を持っているかを一つずつ確認します。
対策の手順
1. データ分類を最低限3段階で作る
Public・Internal・Restrictedのような簡易な3段階でよいので、扱うデータを分類してください。
認証情報や個人の連絡先はRestricted扱いとし、AIツールへの入力対象から明確に外します。
2. ログ出力側でマスキングを先に行う
AIツールに渡す前段階、つまりアプリケーションのログ出力処理そのものでPIIをマスキングする仕組みを入れます。
たとえばメールアドレスをu***@example.comのように一部伏せる、認証トークンは末尾4文字のみ残す、といった加工を、ログ出力ライブラリのフィルタ機能で実装します。
3. MCP経由の権限を最小化する
MCPサーバーに与えるDBの接続権限は、読み取り専用かつ必要なテーブル・カラムに限定します。
本番DBの全テーブルにフルアクセスできるMCP設定は避け、PIIを含むカラムはビュー（VIEW）で除外したうえで接続させる方法が現実的です。
4. クラウド型AIツールのデータ利用設定を確認する
ChatGPT・Claude・Geminiなど各サービスの管理コンソールで、入力データをモデル学習に使うかどうかの設定を確認してください。
組織利用の場合はEnterprise/Team向けプランでこのオプションがデフォルトで無効になっていることが多いですが、個人契約のまま業務利用しているケースでは有効になっている場合があります。
5. 削除・保持期間のポリシーを明文化する
AIツールとの会話履歴やアップロードしたファイルについて、どのくらいの期間保持し、いつ削除するかを社内ルールとして文書化します。
ユーザーが同意を撤回した場合にどう対応するかも、あわせて決めておく必要があります。
導入前に確認すること
AIコーディングツールの利便性は、コンテキストに渡せる情報量の多さと表裏一体です。
渡す情報が多いほど便利になる一方で、PIIや認証情報が混入するリスクも比例して高まります。
最低限、次の3点は今日から確認できます。
- MCP設定ファイルを
grepで洗い出し、DBやAPIへの接続権限を棚卸しする - ログ出力処理にPIIマスキングのフィルタが入っているか確認する
- 利用中のAIツールの管理画面でデータ学習利用のオプションを確認する
完璧な仕組みを一度に作る必要はありません。まずは自分のチームが使っているMCP設定とログ出力の2箇所から点検してみてください。