連載: AIに仕事を奪われる不安から始めるハーネス作成入門
第19回 ← 前回（第18回）: MCPサーバーの単体テスト・結合テスト観点を作る
はじめに：AIに機密情報を渡してしまう不安
AIエージェントを業務で使うとき、最も気になるリスクのひとつが機密情報の漏洩です。プロンプトに顧客情報や社内パスワードを含めてしまうと、それが外部のAPIサーバーに送信される可能性があります。
SE経験者であれば、この問題に対する考え方を既に持っています。情報分類、アクセス制御、データマスキング——これらのセキュリティ知識は、AIハーネス設計にそのまま活かせます。
本記事では、LLMに機密情報を渡すリスクを体系的に整理し、ハーネスでどう防御するかを示します。
機密情報がLLMに渡る経路
AIエージェントのワークフローの中で、機密情報がLLMに渡る経路は主に4つあります。
| 経路 | 具体例 | リスクレベル |
|---|---|---|
| プロンプト直接入力 | ユーザーがパスワードを貼り付け | 高 |
| RAGコンテキスト | 検索結果に個人情報が含まれる | 高 |
| MCPツール応答 | 外部ツールが機密データを返す | 中 |
| ログ記録 | プロンプト全文がログに残る | 中 |
この表からわかるように、リスクは「プロンプト」だけでなく、RAGやMCPツール、ログなど複数の経路に存在します。
情報分類マトリクス：SE経験を活かす
SEが業務システムで行う情報分類の考え方を、AIハーネスに適用します。
| 情報レベル | 説明 | AIハーネスでの扱い | 具体例 |
|---|---|---|---|
| 機密 | 漏洩時の影響大 | LLMに渡してはいけない | パスワード、秘密鍵、個人情報 |
| 社内限定 | 社外に出すべきでない | マスク後に渡すか、ローカルLLMを使用 | 社内規程、顧客情報、売上データ |
| 公開可 | 公開しても問題ない | そのまま渡せる | 公開ドキュメント、OSSコード |
この分類は、従来システムの「情報セキュリティポリシー」と同じ考え方です。
機密情報漏洩リスク一覧（成果物）
以下が、AIハーネスにおける機密情報漏洩リスクの一覧です。
| # | リスク | 経路 | 影響度 | 発生確率 | 対策 |
|---|---|---|---|---|---|
| 1 | プロンプトにパスワード含む | 直接入力 | 致命的 | 中 | 入力バリデーション |
| 2 | 個人情報がRAG経由で混入 | RAG | 重大 | 高 | ナレッジ登録時のフィルタ |
| 3 | APIキーがプロンプトに混入 | 直接入力 | 致命的 | 低 | 環境変数で管理 |
| 4 | 社内データが外部APIに送信 | API通信 | 重大 | 中 | ローカルLLMまたはマスキング |
| 5 | ログに機密情報が残る | ログ記録 | 中 | 高 | ログ出力前のマスク処理 |
| 6 | MCPツールが機密データを返却 | MCP | 中 | 中 | ツール応答のフィルタリング |
| 7 | モデル応答に機密情報が含まれる | 出力 | 中 | 低 | 出力バリデーション |
ハーネスでの防御層設計
リスク一覧を踏まえ、ハーネスに組み込む防御層を設計します。SEの「多層防御（Defense in Depth）」の考え方をそのまま適用します。
| 防御層 | 対象 | 実装方法 | SE業務での対応 |
|---|---|---|---|
| 入力フィルタ | プロンプト | 正規表現で機密パターンを検出 | 入力バリデーション |
| マスキング | プロンプト/コンテキスト | 機密値をプレースホルダーに置換 | データマスキング |
| 通信制御 | API呼び出し | ローカルLLMと外部APIの使い分け | ネットワーク制御 |
| 出力検証 | モデル応答 | 応答から機密情報を検出・除去 | 出力フィルタ |
| ログ保護 | ログファイル | ログ出力前にマスク処理 | ログのアクセス制御 |
入力フィルタの設計
最初の防御層として、プロンプトに機密情報が含まれていないかをチェックする入力フィルタを設計します。
検出すべきパターンの例：
| パターン | 検出方法 | 対応 |
|---|---|---|
| メールアドレス | 正規表現 | マスクまたは警告 |
| 電話番号 | 正規表現 | マスクまたは警告 |
| クレジットカード番号 | Luhnアルゴリズム | ブロック（即座に停止） |
| APIキー | プレフィックスマッチング | ブロック |
| パスワードらしき文字列 | エントロピー分析 | 警告 |
マスキングの基本設計
マスキングとは、機密情報をプレースホルダーに置き換えてからLLMに渡し、応答後に復元するアプローチです。
マスキングの流れ:
1. 入力: "田中太郎様のAPIキーはsk-abc123です"
2. マスク: "{{NAME_1}}様のAPIキーは{{API_KEY_1}}です"
3. LLMに送信: マスク済みテキスト
4. LLM応答: "{{NAME_1}}のAPIキーは..."
5. 復元: "田中太郎のAPIキーは..."
マスキングの判断基準
| 情報種別 | マスキング方法 | 復元可否 |
|---|---|---|
| 個人名 | プレースホルダー置換 | 可能 |
| メールアドレス | プレースホルダー置換 | 可能 |
| パスワード | 完全削除 | 不可（復元不要） |
| APIキー | 完全削除 | 不可（復元不要） |
| 住所 | 一般化（都道府県まで） | 部分復元 |
ローカルLLMと外部APIの使い分け
機密情報のレベルに応じて、LLMの利用先を使い分ける判断基準を示します。
| 情報レベル | 推奨LLM | 理由 |
|---|---|---|
| 機密 | ローカルLLMのみ | データが外部に出ない |
| 社内限定 | ローカルLLM推奨 | リスクを最小化 |
| 公開可 | 外部APIも可 | コスト・品質で判断 |
ただし、ローカルLLMには品質やコストのトレードオフがあります。正解は一つではなく、プロジェクトの要件に応じて判断してください。
ハーネス実装上のチェックポイント
実装時に確認すべきチェックポイントを整理します。
| チェック項目 | 確認内容 | 対応時期 |
|---|---|---|
| プロンプトフィルタ | 機密パターン検出が動作するか | 実装時 |
| マスキング処理 | 復元マッピングが正しいか | 実装時 |
| ログ保護 | ログに機密情報が残らないか | テスト時 |
| 通信経路 | 機密データが外部APIに送信されないか | テスト時 |
| エラー時 | エラーメッセージに機密情報が含まれないか | テスト時 |
SE経験からのマッピング
この分野は、SE経験者が最も強みを発揮できる領域のひとつです。
| SEのセキュリティ経験 | AIハーネスでの活用 |
|---|---|
| 入力バリデーション | プロンプトフィルタの設計 |
| データマスキング | LLM送信前の機密情報置換 |
| アクセス制御 | 情報レベルに応じたLLMの使い分け |
| 監査ログ | 機密情報アクセスの記録 |
| インシデント対応 | 機密情報漏洩時の対応フロー |
よくある懸念と判断基準
「マスキングするとLLMの品質が下がるのでは？」
場合によっては品質が低下する可能性があります。ただし、「田中太郎」を「{{NAME_1}}」に置き換えても、多くのタスク（コードレビュー、設計相談など）では品質への影響は限定的です。セキュリティと品質のトレードオフをタスクごとに判断してください。
「100%の検出は無理では？」
その通りです。多層防御の考え方と同じく、単一の対策で100%を目指すのではなく、複数の層でリスクを低減するアプローチが現実的です。
まとめ
- 機密情報がLLMに渡る経路はプロンプトだけでなく、RAG・MCP・ログにも存在
- 情報分類・マスキング・多層防御は、SEのセキュリティ知識が直接活かせる
- リスク一覧表を基に、ハーネスの各層に防御策を組み込む
- 100%の安全はないが、多層防御でリスクを管理可能なレベルにする
次回予告：プロンプト投入前のマスキング・復元フローを設計する
第20回では、今回整理したマスキングの基本設計を具体的な実装フローに落とし込みます。
具体的には以下の内容を扱います。
- マスキング・復元フローの詳細設計
- Pythonでのマスキングユーティリティ実装
- マスキングルールの設定ファイル設計
- テストケースの作成
「リスクは整理できたけど、実際にコードでどう実現するの？」という疑問に答える実装回です。ぜひお楽しみに。
連載: AIに仕事を奪われる不安から始めるハーネス作成入門
次回（第20回）: プロンプト投入前のマスキング・復元フローを設計する