PasteGuard｜LLMに送るプロンプトからPIIとAPIキーを自動マスクするプロキシ

この記事ではセキュリティに特化して解説します。AIセキュリティ全般は サプライチェーンセキュリティ完全ガイド2026｜攻撃手法・防御ツール・実践チェックリスト をご覧ください。

PasteGuardとは何か：ローカル実行のLLMプライバシープロキシ

PasteGuard は2026年1月に公開されたOSS（Apache 2.0、現在v0.3.5、606スター）で、開発元はsgasser氏。コアコンセプトは “AI gets the context. Not your secrets.”（AIには文脈を、機密は渡さない）の一行で表現されている。

技術スタックは Bun + Hono（TypeScript）+ Microsoft Presidio + SQLite。Dockerコンテナ1つで起動し、ローカルポート3000にOpenAI互換・Anthropic互換のエンドポイントを立てる。アプリケーション側で base_url を https://api.openai.com/v1 から http://localhost:3000/openai/v1 に切り替えるだけで、間にマスキング層が挟まる。

# 起動はDockerコンテナ1つ
docker run --rm -p 3000:3000 ghcr.io/sgasser/pasteguard:en

ポイントは「PasteGuard自体が外部にデータを送らない」点だ。Presidioも検出処理もすべて自分のマシン・自社サーバ内で完結し、ログもローカルSQLiteに保存される。クラウド型のDLP SaaSと違い、機密データがいったん第三者のクラウドに流れることがない。

何を検出するのか：PII 11種・シークレット 9種

PasteGuardが扱うのは大きく2系統に分かれる。

個人情報（PII）：Presidioベースで11種・24言語対応

検出はMicrosoft Presidioが担当する。PresidioはspaCyのNERモデル＋正規表現＋コンテキストワード検査の組み合わせで、各検出に 0.0〜1.0の信頼度スコア を付ける。PasteGuardのデフォルト閾値は score_threshold: 0.7。0.7未満は誤検知リスクが高いと判断して通過させる設計だ。

言語対応は24言語。Dockerイメージはサイズと精度のバランスで分割されており、:en が英語専用、:eu が独仏伊蘭ポーランド・スペイン・ポルトガル・ルーマニア対応の欧州版。日本語を含む他言語は別途カスタムビルドかPresidioサーバを直接構成する形で対応する。

シークレット：正規表現＋コンテキスト判定で9種

秘密鍵2種だけがデフォルト有効で、他はオプトイン。「秘密鍵は誤検知のしようがないからオン、APIキーや環境変数は文脈次第で誤判定が出るからオフ」 という慎重な設計思想だ。

マスクの仕組み：プレースホルダ置換と復元の双方向フロー

PasteGuardのマスクモードがどう動くかを順に追う。

プレースホルダの形式は [[TYPE_NUMBER]]（例：[[PERSON_1]]、[[EMAIL_ADDRESS_2]]）。同一テキスト内に同じ値が複数回出てきても番号は再利用され、「同じ人物が同じ番号」として参照されるため、LLMは指示文の意味的整合性を失わない。

ストリーミング応答にも対応していて、PasteGuardは応答チャンクをバッファリングしながらプレースホルダ境界（[[ と ]]）を検出し、マッピングテーブルを引いてリアルタイムに復元する。ユーザー側からは普通のストリーミングとして見える。

マスクモードとルートモード：2つの守り方

PasteGuardには思想が異なる2モードがある。

マスクモード（デフォルト）: 常にOpenAI/Anthropicに渡すが、機密はプレースホルダに置換する。クラウドLLMの賢さを使いたい・ローカルGPUがない・大半のリクエストに機密が含まれない場合に向く。

ルートモード: PIIが含まれていたらリクエスト全体をローカルLLM（Ollama・vLLM・llama.cpp・LocalAI）に流す。PIIがゼロのリクエストだけクラウドに送る。「センシティブなデータは絶対に外に出したくないが、すべてローカルでやるのは性能的に無理」という条件下で使う。

「学習防止」の本質：PasteGuardが守れる範囲と守れない範囲

ユーザーが最も気にするのが「自社データがLLMの学習に使われないか」という点だが、ここは整理が必要だ。

LLMプロバイダ側の学習ポリシー（2026年4月時点）

つまり 「商用APIをきちんと使っている限り、学習防止は契約レベルで既に保証されている」 のが現状だ。PasteGuardの役割は契約に依存しない技術的補強であり、次の3つの場面で意味を持つ。

1. 学習に使う可能性があるサービス（無料ChatGPT・AI Studio・サードパーティ製ラッパー） に流す前に機密を抜く
2. API利用規約が将来変更されるリスクに対する技術的ヘッジ
3. プロバイダのログ保持・人手レビューポリシー（規約上、不正利用調査のため一時保管されるケース）に機密が乗らないようにする

3点目が見落とされがちだ。OpenAIやAnthropicは規約上、不正利用調査のためAPIリクエストを最大30〜90日程度保持する。学習には使われなくとも、その期間内にプロバイダのインフラに自社データが残る点はガバナンス上の論点になる。PasteGuardを通せばその期間に保持されるのもプレースホルダだけになるのが本質的な価値だ。

マスク精度の現実的な期待値

公式ドキュメントには明示的な精度指標は載っていないが、ベースとなるPresidioの公開ベンチマークから次のように推測できる。

• 英語のPERSON・EMAIL・CREDIT_CARDなど構造的に明確な検出 → F1 0.85〜0.95水準
• 日本語人名（カタカナ・漢字混在）→ Presidioの日本語spaCyモデル次第で大きく変動。閾値0.7のままだと誤検知・検出漏れが目立つ
• ENV_SECRET・CONNECTION_STRING系 → 正規表現主導なので高精度（ほぼ漏れない）

他のDLP（Data Loss Prevention）ツールとの違い

「LLMに送るデータを守る」という課題に対しては、複数のレイヤーで複数の製品が存在する。PasteGuardの位置づけを比較表で整理する。

PasteGuardが選ばれる理由は明確だ。

• OSSで自社環境完結：データが第三者クラウドを経由しない
• LLM API互換：base_url変更だけで導入できる（アプリ改修ゼロ）
• コーディング支援に対応：Claude Code・Cursor・Copilot・Windsurfの前段に直接挟める

逆に Purviewのような企業全体DLPの代替にはならない。Outlookで送る添付ファイル、Slackメッセージ、SharePoint上のドキュメントなどはカバー範囲外。「組織のデータ移動全体を統制する」必要がある場合、PurviewとPasteGuardは併存させる関係になる。

企業導入シナリオ4パターン

実際の組織でどう入れるかを4つのパターンで整理する。

パターン1：開発者個人のローカル環境（最小構成）

エンジニア各自のローカルマシンでDockerコンテナを起動し、Claude CodeやCursorのbase_urlを切り替える。

# 起動
docker run -d -p 3000:3000 -v $HOME/.pasteguard:/data \
  --name pasteguard ghcr.io/sgasser/pasteguard:en

# Claude Codeの利用例
ANTHROPIC_BASE_URL=http://localhost:3000/anthropic claude

導入の摩擦が最も低い。新人エンジニアでも30分で稼働させられる。組織レベルでの統制はないが「使う人が使う」段階での導入として有効。

パターン2：チーム共有プロキシ（中規模構成）

開発チーム1つに対してEC2やKubernetes Pod上にPasteGuardを1つ立て、全員がそれを向く。社内DNS（例：pasteguard.dev.internal）でアクセスを統一する。

# Kubernetes Deploymentの最小例
apiVersion: apps/v1
kind: Deployment
metadata:
  name: pasteguard
spec:
  replicas: 2
  selector:
    matchLabels:
      app: pasteguard
  template:
    metadata:
      labels:
        app: pasteguard
    spec:
      containers:
      - name: pasteguard
        image: ghcr.io/sgasser/pasteguard:eu
        ports:
        - containerPort: 3000
        env:
        - name: PASTEGUARD_LANGUAGES
          value: "en,ja"

ダッシュボードで「誰がいつ何をマスクしたか」を集中管理できる利点がある。一方で集中点が単一障害点（SPOF）になるためHA構成は前提。

パターン3：規制業界・医療・法務（ルートモード必須構成）

PIIが含まれるリクエストは絶対に外部に出せない業界では、ルートモードを使ってローカルLLM（社内Ollama・vLLM・llama.cpp）に振り分ける。クラウドLLMには「PIIゼロのコード補完・公開資料の要約」のみ流す。

判断フローは下記のようになる。

パターン4：API統合（自社プロダクトに組み込む）

自社プロダクトがバックエンドからOpenAI APIを呼んでいる場合、PasteGuardをサイドカー（同一PodやECSタスク内）として配置し、アプリのSDK設定だけ書き換える。

# 既存
client = OpenAI()

# PasteGuard経由
client = OpenAI(base_url="http://localhost:3000/openai/v1")

エンドユーザーから受け取る入力（カスタマーサポートのチャット内容、契約書のテキスト等）に含まれるPIIを、自社が責任を持ってマスクしてからLLMに渡せる。ユーザーへの「PIIは外部AIに渡しません」という説明と整合性が取れるのが大きい。

制限事項と「向いてない」ケース

PasteGuardの守備範囲は明確だが、以下の使い方には向いていない。

• 画像・音声・PDF添付: PasteGuardはテキストプロンプトに対して動作する。画像内のOCRテキストや音声の文字起こしは対象外
• マルチモーダルAPI（ビジョン系）: GPT-4o・Claude 4の画像入力に含まれる顔・看板・書類は検出できない
• エージェントのツールコール出力: LLMが返したツール呼び出し（function calling）の引数に含まれるデータは、復元処理の対象だが、ツール側の処理結果は当然PasteGuard外
• 日本語人名の高精度検出: Presidio日本語モデルの限界。社内辞書ベースのカスタムRecognizerが必要
• ファイルアップロード型のChatGPT利用: ブラウザ拡張機能ではChatGPTのテキスト入力をマスクするが、ファイル添付は対象外

Gemini APIキーが不正利用される仕組みと防止策 でも書いたとおり、漏れたAPIキーは数時間で悪用される。PasteGuardはAPIキー漏洩防止と相性が良く、.env ファイルや認証ヘッダがそのままプロンプトに混入するパターンを正規表現で確実に止められる。

設定ファイルの構造：閾値・対象エンティティを調整する

config.example.yaml の主要部分は以下のようになっている。本番運用では score_threshold の調整と、有効化するエンティティのオプトイン判断が肝になる。

mode: mask  # または route

pii_detection:
  presidio_url: ${PRESIDIO_URL:-http://localhost:5002}
  languages: ${PASTEGUARD_LANGUAGES:-en}
  score_threshold: 0.7  # ← 検出感度。0.5に下げると過検知が増える
  entities:
    - PERSON
    - EMAIL_ADDRESS
    - PHONE_NUMBER
    - CREDIT_CARD
    - IBAN_CODE
    - IP_ADDRESS
    - LOCATION

secrets_detection:
  enabled: true
  action: mask
  entities:
    - OPENSSH_PRIVATE_KEY
    - PEM_PRIVATE_KEY
    # 必要に応じて API_KEY_SK / API_KEY_AWS / API_KEY_GITHUB を追加

logging:
  database: ./data/pasteguard.db
  retention_days: 30
  log_content: false        # ← 元データはログに残さない
  log_masked_content: true  # マスク後の内容のみ記録

ログ設計では log_content: false がデフォルトな点が重要だ。マスク前の生データを保存しない設計になっており、PasteGuard自体を侵害されても元データが奪われない。漏洩リスクを増やさないためのゼロトラスト的設計だ。

検証チェックリスト：本番投入前にやっておきたいこと

• 自社の典型プロンプト100件を流して、PII検出率を測定（漏れ＝検出漏れの数を把握）
• 日本語人名・社内ID等が検出されない場合、Presidioのカスタム辞書を追加
• score_threshold を0.5〜0.8の範囲で調整し、誤検知率と検出漏れのトレードオフを確認
• シークレット検出で API_KEY_SK API_KEY_AWS API_KEY_GITHUB をオプトインで有効化
• ストリーミング応答でプレースホルダ復元が正しく動くかe2eテストを実施
• ダッシュボード（/dashboard）の認証を本番では必ず有効化
• PasteGuard自体のアップデート手順（イメージタグ・コンテナ再起動）を社内手順化
• 月1回、検出ログをサンプリングして「検出されるべきだったが漏れたPII」がないか目視レビュー

OpenClawのセキュリティリスクとAIエージェントの安全な使い方 で扱ったエージェントの権限制御と組み合わせると、「データの流出」と「データの破壊」両方をカバーできる構成になる。

結論：PasteGuardをいつ導入すべきか

判断軸はシンプルだ。

導入を強く推奨：

• 開発者がClaude CodeやCursorで社内コード・顧客データを扱う組織
• ChatGPT無料版やAI Studioを業務利用しているスタートアップ
• 規制業界（医療・金融・法務）でローカルLLM併用を進めたい組織

過剰なケース：

• 既にエンタープライズDLP（Purview等）を入れていて、LLM特化の必要がない大企業
• ローカルLLMだけで完結している（外部APIを一切使わない）組織

自前実装より速い： PresidioとExpress/FastAPIで似たプロキシを書くと、最低でも開発に1週間〜数週間かかる。PasteGuardはそれを1コマンドで提供し、ダッシュボード・ストリーミング対応・複数プロバイダ対応まで含めて完成している。スター606・v0.3.5まで開発が進んでおり、CI付き・Apache 2.0なので業務利用の敷居も低い。

参照ソース

• sgasser/pasteguard — GitHubリポジトリ
• PasteGuard 公式ドキュメント
• PasteGuard Mask Mode
• PasteGuard Route Mode
• PasteGuard PII Detection
• PasteGuard Secrets Detection
• PasteGuard config.example.yaml
• Microsoft Presidio — PII detection and de-identification SDK
• Show HN: PasteGuard – Self-hosted privacy proxy for LLMs
• OpenAI Business Terms（学習利用ポリシー）
• Anthropic Commercial Terms of Service