「Geminiの判定力×ローカル隔離」で築く機密情報防衛。誤警報に疲弊しない二段パイプライン運用の設計論

---

はじめに：移り変わるモデルと、変わらない現場の「防衛線」

日本のビジネスシーンにおける文書判定タスク（敬語のねじれや過剰表現の是正、社外持ち出し禁止データの検出など）を検証していると、改めて実感することがあります。

それは、「日本語特有のハイコンテクストな文脈を、不要なアラート（誤警報 / False Positive）を抑えながら判定する能力」において、Geminiの文脈把握力には実用上非常に頼もしい場面があるという点です。

私が実際に検証を行った「Gemini 3.7 Flash」で感じた、深読みしすぎず、かといって表面的な単語一致だけで騒ぎ立てないバランス感覚は非常に印象的でした。なお、Gemini 3.7 Flashは2026年10月8日に非推奨（deprecated）となり、現在のGemini APIでは後継となるGemini 3.8 Flashへ自動的にルーティングされます。

しかし、AIモデルの世界は常に流動的です。昨日まで使えたお気に入りのモデルが世代交代で非推奨になったり、APIの仕様や課金体系が変わったりすることは日常茶飯事です。

そして現場には、より切実な問題が横たわっています。

「どれほど判定精度が優れていても、顧客の生データや社内機密をそのままクラウドAPIに投げるわけにはいかない」

このジレンマに対して、私たちは単一の万能モデルを探すのをやめました。現在運用している「外部通信を行わないローカル環境での前処理（秘匿化）」と「クラウドGeminiによる文脈判定」を分離した二段パイプラインこそが、現時点において実務上非常に有効に機能しているアプローチだと感じています。

本記事では、机上の空論ではなく、日々の実務と外部からのフィードバックに向き合いながら組み上げた「機密防衛と判定精度の両立を図る運用アーキテクチャ」の設計論を共有します。

---

1. 現場を疲弊させる「誤警報」と「セキュリティ」の二重苦

実務でLLMを使ったテキスト監査や情報保護システムを組む際、最初にぶつかる壁が「誤警報の嵐」と「情報漏洩への恐怖」です。

誤警報（過剰検知）が業務を止める

単語マッチングベースのフィルターや、文脈理解の浅い小型モデルを使うと、「念のため」「念書」「記念品」といった無害な単語まで「秘密情報」として検知してしまう傾向があります。
現場の担当者は毎日何十件もの誤警報を確認する羽目になり、やがて警告そのものを無視するようになります（アラート疲れ）。

クラウド全投げの危うさ

一方で、「最新の高性能クラウドLLMなら文脈を理解できるから」と、社内の生テキストをそのままAPIへリクエストするのは、ガバナンスの観点から推奨されません。
GoogleのGemini API（有料枠）ではプロンプトやレスポンスをモデル改善の学習に利用しない規定がありますが、不正利用・乱用検知を目的とした一定期間のログ保持などは行われます。API事業者の規約を盲信する前に、「そもそも社外のネットワークへ生の機密情報を送信しない」という防衛線が求められます。

ローカル完結の精度の壁

では「すべてをローカルLLMで動かせば安全か」というと、現場のPCや社内サーバーで動かす比較的小型のオープンモデルでは、今回の日本語ビジネス敬語や、複雑な文脈判定において、クラウドモデルと同等の精度を安定して得るのが難しいケースがありました。

この「安全性（ローカル）」と「高い判定精度（クラウド）」の板挟みを解消するために設計したのが、責務を切り分けた二段構造です。

---

2. 実践アーキテクチャ：ローカル秘匿化とクラウド判定の「二段パイプライン」

私たちが構築しているパイプラインは、「機密情報の仮名化」と「文章構造の判定」を別のレイヤーで行う構成をとっています。

ステップ①：ローカル環境での属性仮名化（第1層）

最初の関門は、外部通信を行わないローカル環境（LAN内）で完結させます。
ローカルLLMや正規表現ルールを組み合わせ、文章内に含まれる「具体的な個人名」「組織名」「金額」「アカウント情報」を検出します。

ここで重要な設計の工夫が、「単純な無機質記号（{{X}}）への置換を避け、品詞や属性ヒントを残した擬似エンティティ形式を採用すること」です。

【変換前（社内原本）】
田中専務、株式会社アルファとの来期ライセンス契約（年間1,200万円）について、
先方の山本部長から「競合他社には内密にしてほしい」と念を押されております。

【第1層通過後（Geminiへ送信するテキスト）】
[役員A]、[法人取引先A]との来期ライセンス契約（[金額:年間契約]）について、
先方の[部長B]から「競合他社には内密にしてほしい」と念を押されております。

単に {{TEXT_1}} と伏字にするのではなく、[法人取引先A] や [役員A] のように「文脈上の役割」を残すことで、Geminiが文法的な関係や敬語の方向性を解釈するための文脈を残しやすくなります。

対応表（マッピングテーブル）はローカル環境から外へ出さず、クラウド側には渡しません。

ステップ②：Geminiによる文脈判定（第2層）

送信データから固有の実体情報を最小化した上で、クラウドAPIへリクエストします。

私の検証環境では、単純なキーワードマッチングと比較して、Geminiのように文脈全体を捉えられるモデルに判定させた場合、「念を押されております」の「念」に引っかかるような不要なアラートが大幅に減る傾向が確認できました。

【構造化出力による判定プロンプトの設計】

なお、モデルの早とちりや判定のブレを抑えるためには、「判定結果」だけをいきなり出力させるのではなく、判定理由や根拠を構造化して出力させる設計が非常に有効です。

あなたは企業のコンプライアンス監査担当です。
入力テキストを監査し、以下のJSON形式で出力してください。

{
  "summary": "発言者と相手の関係性および文脈の要約（80字以内）",
  "category": "SAFE | REVIEW | ALERT",
  "reason": "その判定を下した客観的な根拠",
  "evidence": "根拠となった該当箇所（引用）"
}

※ 通常の社内業務連絡や定型的な挨拶、正当な業務上の依頼は「SAFE」として扱い、
真に社外持ち出し禁止条項に抵触する恐れがある場合のみ「ALERT」と判定してください。

判定理由や根拠箇所を構造化して出させることで、軽量なFlash系モデルであっても出力の一貫性を検証しやすくなります。

ステップ③：手元での復元と「人間の最終承認」

Geminiから返ってきた監査レポートはローカル環境に戻され、手元のメモリ内でのみ元の固有名詞に再紐付けされます。

そして最も重要なのは、「AIに勝手な送信や削除の最終執行をさせない」という安全弁です。AIはあくまで「下準備と論点の洗い出し」に徹し、判定結果を確認した人間の担当者が「承認」を行って初めて実アクションが実行されます。

---

3. 「外部からのフィードバック」と向き合う運用のリアル

どれほど綺麗な設計図を描いても、運用を始めれば予期せぬ壁に直面します。特にチューニングを重ねたのが「外部からのフィードバック」への適応です。

1. 「過剰マスキング」による文脈破壊

初期のローカルマスキングルールを厳しくしすぎた際、一般的なビジネス用語までプレースホルダー化してしまい、Gemini側で係り受けが破綻して判定精度が落ちるという問題に直面しました。
「何でもかんでも伏字にする」のではなく、「機密の対象（人名・企業名・固有ID・金額）を絞り込み、文脈を繋ぐ動詞や助詞は生かす」という境界の調整が不可欠でした。

2. モデル変更への耐性（ポータビリティ）

「あのモデルが一番使いやすかった」と過去のバージョンに固執しても、APIのライフサイクルは待ってくれません。
しかし、この二段構造にしておけば、クラウド側のモデルがGemini 3.7から3.8、あるいは将来の新しいモデルへ切り替わったとしても、プロンプトの出力フォーマットを微調整するだけでシステム全体がそのまま動き続けます。

外部のフィードバックを受けながら、ローカル側の抽出ルールとクラウド側の判定プロンプトを個別に微調整できる柔軟性こそが、長期的な運用コストを低く抑えてくれます。

---

4. 最適な運用環境を構築するための「3つの設計原則」

もし皆さんが自社やチームで同様の仕組みを構築されるなら、以下の3つの原則を意識してみてください。

1. 「機密データ」をクラウド側のポリシーだけに委ねない
   「クラウドAPIに『この中から機密情報を探して消して』と頼む」のは本末転倒です。送信した時点でデータは境界を越えています。機密の境界線は、必ず手元のローカルで自らの手で引かなければなりません。
2. モデルに依存せず「パイプライン」を育てる
   単一モデルの性能に過度に依存したシステムは脆いです。「ローカル前処理 ➔ クラウド判定 ➔ 人間承認」というパイプライン側に知見を蓄積することで、将来登場する新モデルも即座に組み込める資産になります。
3. 誤警報対策は「検知規定」だけでなく「除外規定」も設計する
   誤検知を減らす鍵は、「検知したいもの」を増やすことだけでなく、「検知してはならない無害なパターン（業務連絡、慣用句など）」を除外規定として設計に組み込むことです。これによってシステム全体の判定安定感が増します。

---

まとめ：神モデルを探す旅を終え、「自分の道具」を持つ

AIの進化スピードは凄まじく、次々と新しいベンチマークやモデルが登場します。「どのモデルが最強か」という議論に目を奪われがちですが、実務の現場で本当に必要なのは「どんなモデルが来ても、安全かつ安定して成果を出せる頑丈な仕組み」です。

ローカル環境の確実な前処理で盾を構え、クラウドモデルの優れた言語処理能力を判定の矛として活用する。

この役割分担を一度確立してしまえば、日々のモデルの入れ替わりに一喜一憂することなく、落ち着いて目の前の業務改善に集中できるようになります。自社にとっての「最適な運用環境」とは、外から与えられるものではなく、現場の規律と道具の組み合わせによって自らの手で築き上げるものなのだと感じています。