第07章 本番投入のセキュリティ実践

この章の位置づけ — 「動くもの」を「本番に耐えるもの」へ

第 6 章で DLP・ガードレール・fail-closed の骨格を説明しました。本章は、社内 RAG や複数部署展開など 本番投入で法務・監査から指摘されやすい 4 点 を、実装担当が迷わないよう噛み砕いて整理します。

本番前にクリアする 4 つの柱

[利用者] → ①マスキング → [ゲートウェイ] → [モデル]
                ↓
            ②監査ログ（誰・何・いつ・どのモデル・いくら）
                ↓
[RAG 検索] → ③権限フィルタ → ④出力チェック → [利用者 / 下流システム]

① PII マスキング — ルールと AI の併用

PII（Personally Identifiable Information） = 個人を特定できる情報（氏名、電話、マイナンバーなど）。

なぜ正規表現だけでは足りないか

おすすめの考え方（ハイブリッド）

Phase 1 ではルール中心、Phase 2 で Presidio 等の外部 DLP 連携を検討（第 12 章）。閾値（何点以上でマスクするか）は、200 件程度の手動チェックで業務に合う線を探すのが現実的です。

ファイルも忘れない

Excel・PowerPoint も社内文書の半分近くを占めます。取り込みパイプラインの上流でテキスト化してからマスキングします。名刺写真・ホワイトボードは「取り込まない」とルールで決めるのも有効です。

② 監査ログ — 答えるべき 5 つの問い

監査・法務から「どこまで残すの？」と聞かれたとき、次の 5 つに答えられれば足りることが多いです。

プロンプト全文は残す？（第 4 章との整合）

prompt_hash と retrieved_doc_ids があれば、「あの回答は何を根拠にしていたか」は多くの場合追えます（第 14 章 EU AI Act とも整合）。

保持期間は一律にしない

「全部 7 年」はコストが跳ね上がることがあります。文書分類ごとに法務・情シス・財務で合意してから決めます（第 14 章）。

③ 権限分離 — RAG は「検索の時点」で切る

LLM に渡す前にモデルは内容を読んでしまうため、ベクター DB 検索時に権限フィルタが必要です。

チャンク単位の権限（ACL）

各文書の断片（チャンク）に「誰が見られるか」のラベルを付けます。

例: ["role:sales", "tenant:acme", "clearance:general"]

検索時に、ログインしている人の属性と一致するチャンクだけ返します。第 4 章の「データ過剰取得」リスクへの直接的な対策です。

よくある落とし穴

④ 出力ガードレール — 形の決まった答えは検証する

AI に JSON やチケット情報を返させ、それを kintone や Salesforce に流す場合、たまに壊れた形式が返ってきます（100 回に 2〜3 回程度は想定）。

対策の流れ（やさしい説明）

1. 欲しい形を決める（例: タイトル 60 字以内、優先度は low/mid/high だけ）
2. プログラムでチェック（Pydantic 等のスキーマ検証）
3. ダメなら AI に直しを依頼（reask、最大 2 回程度）
4. それでもダメなら人の確認へ

実測では 2 回のやり直しで大半が直る、という報告が多いです。最初から「たまに失敗する」前提で設計すると慌てません。

専有ホスティング — 全部オンプレにしなくていい

「全部自社サーバーに」は経営の安心感はあるが、必ずしも必要ではありません。次の 3 つの軸 で分けると話が進みます。

KEEL の Phase 1 はクラウド API + ゲートウェイが現実的です。機密度の高い RAG は Phase 2 で Azure OpenAI Private や自社推論のハイブリッドを検討（第 8 章・第 5 章）。

本番切替前のチェックリスト（要約）

• [ ] PII: ルール +（Phase 2）NER の評価サンプル実施
• [ ] 監査: 5 つの問いに答えられるログスキーマ
• [ ] RAG: チャンク ACL と ingest パイプラインのテスト
• [ ] 出力: 下流連携がある場合はスキーマ検証 + reask
• [ ] ホスティング: 機密度別のルーティング方針が文書化されている
• [ ] 負荷: マスキングの遅延を並列数で確認（ワーカーごとのモデル読み込みに注意）

既存章へのマップ

次に読む章

v1.7 補強 — RAG / Agent 本番化の追加ゲート

本番投入前のレビューでは、通常の DLP だけでなく、RAG と Agent の データ境界を明示する。特に、間接プロンプトインジェクションは「利用者が入力した文章」ではなく、AI が取得した外部コンテンツから発火するため、検索・取得・出力の各段階で止める。

v1.10 — プロンプト以外の露出経路（ツール・DB 結果）

自分がプロンプトに書いた覚えがなくても、エージェントの実行結果が次の推論のために事業者へ送信されます。ローカルの会話履歴（トランスクリプト）にも残ります。

*出典: 開発現場のAIセキュリティを見直す（nenene01 / Zenn）*

本番 DB 調査の例

-- NG: 結果に氏名・メールが載り、そのままコンテキストへ
SELECT * FROM customers WHERE customer_id = 12345;

-- OK: 状態カラムだけ — 個人情報は載らない
SELECT customer_id, status, withdrawn_at FROM customers WHERE customer_id = 12345;

線を引く場所は「クエリを任せるか」ではなく 「結果に個人情報カラムが載るか」 です。

本番 DB 調査 — 強い順 4 段階

エージェント専用シークレット・DB ユーザー

アプリ本体用とエージェント用の認証情報を分離します（should、本番 DB 接続時は推奨）。

*出典: 開発現場のAIセキュリティを見直す（nenene01 / Zenn）*

Azure では Key Vault の別シークレット + Entra ID アプリ登録を分ける。AWS 案件では Secrets Manager + 専用 IAM ロール（第 8 章付録）。