この記事ではセキュリティに特化して解説します。AIセキュリティ全般は サプライチェーン攻撃とは|手口・防御ツール比較・npm 12の新機構まで実践解説 をご覧ください。

結論:PasteGuardは「LLMに渡すデータの最後の砦」として実用レベルにある
ローカルで動くプロキシとしてOpenAI・Anthropic API互換の口を立て、Microsoft Presidio基盤で30種類以上の機密データを検出してマスク・復元する。OSSなので外部にデータを送らず、Apache 2.0で商用利用も可。ただし「LLMの学習に使われない」ことを完全保証する魔法ではなく、プロバイダ契約と組み合わせて初めて意味がある。本記事では仕組み・精度・他DLPとの違い・企業導入の判断軸まで整理する。

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 に切り替えるだけで、間にマスキング層が挟まる。

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

WHAT IT REPLACES何を代替するか

LLMに渡す前に機密だけをプレースホルダに置換する

LLM APIへ直接送信

アプリ → OpenAI / Anthropic

  • PIIとAPIキーがそのまま外へ出る
  • プロバイダ側に生データが残りうる

PasteGuard経由

アプリ → localhost:3000 → LLM

  • [[PERSON_1]] のような置換後だけが外へ
  • 応答のプレースホルダは元の値に復元
出典: PasteGuard 公式ドキュメント(Mask Mode)
30秒でわかる
・LLM APIの前に置くローカルプロキシ。PIIとシークレットを置換して送り、応答で元に戻す
・導入は base_url の変更だけ。Claude Code・Cursorにも挟める
・検出漏れは起こりうる。日本語人名は事前検証が必須
「ローカルで動く」ことの意味
PasteGuardは「自社のデータが第三者の検査クラウドに送られない」という意味でローカルだが、ユーザーがOpenAIやAnthropicに送りたいリクエストはマスク後に必ず外部に出ていく。完全にデータを外に出したくない場合は、後述のルートモードでローカルLLMに振るか、最初から自前ホスティングのモデルを使う必要がある。

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

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

個人情報(PII):Presidioベースで11種・24言語対応

カテゴリ 検出対象 デフォルト
PERSON 人名(姓名) ✅
EMAIL_ADDRESS メールアドレス ✅
PHONE_NUMBER 電話番号(国際フォーマット) ✅
CREDIT_CARD クレジットカード番号 ✅
IBAN_CODE 国際銀行口座番号 ✅
IP_ADDRESS IPv4/IPv6 ✅
LOCATION 住所・地名 ✅
US_SSN 米国社会保障番号 任意
US_PASSPORT 米国旅券番号 任意
CRYPTO 暗号通貨ウォレットアドレス 任意
URL 内部URL含むURL全般 任意

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

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

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

種別 パターン デフォルト
OPENSSH_PRIVATE_KEY -----BEGIN OPENSSH PRIVATE KEY----- ✅
PEM_PRIVATE_KEY -----BEGIN RSA PRIVATE KEY----- 等 ✅
API_KEY_SK sk-... / sk_...(OpenAI、Stripe、Anthropic) 任意
API_KEY_AWS AKIA...(20文字) 任意
API_KEY_GITHUB ghp_/gho_/ghu_/ghs_/ghr_(40文字+) 任意
JWT_TOKEN eyJ... で始まる3セグメントBase64 任意
BEARER_TOKEN Bearer ...(40文字+) 任意
ENV_PASSWORD / ENV_SECRET DB_PASSWORD=... / JWT_SECRET=... 等 任意
CONNECTION_STRING postgres://、mongodb:// 等 任意

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

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

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

OpenAI/AnthropicAPIPresidio(PII検出)PasteGuard(localhost:3000)アプリ/ClaudeCodeOpenAI/AnthropicAPIPresidio(PII検出)PasteGuard(localhost:3000)アプリ/ClaudeCode"Dr. Sarah Chen([email protected])のレポートを書いて"テキストを送信PERSON: Sarah ChenEMAIL: [email protected](信頼度0.95/0.99)マッピング保存PERSON_1=Sarah ChenEMAIL_ADDRESS_1=sarah@..."Dr. [[PERSON_1]]([[EMAIL_ADDRESS_1]])のレポートを書いて""[[PERSON_1]]様へのレポート([[EMAIL_ADDRESS_1]]宛送付)..."応答内のプレースホル-ダを復元"Sarah Chen様へのレポート([email protected]宛送付)..."

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

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

意味を保ちながら機密だけ消す、という発想
単純な伏字(****)と違い、PasteGuardは「Aさん([[PERSON_1]])とBさん([[PERSON_2]])の関係性を分析して」のように構造を保ったまま渡せる。LLMはプレースホルダを「未知の固有名詞」として処理し、答えはそのまま返ってきて、ユーザー側で復元される。これが従来のDLP(ブロックするか通すかの二択)とLLM特化プロキシの最大の差だ。

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

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

TWO MODES2つの守り方

クラウドの性能か、機密を外に出さないかでモードを選ぶ

マスクモード

  • 常にクラウドLLMへ送る
  • 機密はプレースホルダ化
  • 必要なのはプロキシのみ

ルートモード

  • PIIありはローカルLLMへ
  • PIIなしだけクラウドへ
  • ローカルGPUが要る

PIIを外に出せるか

出典: PasteGuard 公式ドキュメント(Mask Mode / Route Mode)。どちらも検出漏れは素通りする

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

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

比較軸 マスクモード ルートモード
機密の所在 プレースホルダ化してクラウドへ 機密ありはローカル完結
クラウドLLM性能 フル活用 PIIなしリクエストのみ
必要インフラ プロキシのみ プロキシ + ローカルGPU
失敗時の影響 検出漏れ=機密がそのまま外へ 検出漏れ=機密がそのまま外へ
推奨用途 一般的なAI活用 規制業界・医療・法務
どちらのモードも「検出が完璧」が前提
Presidioの信頼度閾値を下回るPII(カタカナ氏名の表記揺れ、社内独自IDフォーマット等)は素通りする。「PasteGuardを入れたから100%安全」ではなく「数百件中数件残るかもしれないリスクを許容できる範囲まで下げる仕組み」と理解する必要がある。

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

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

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

サービス デフォルトでの学習利用 備考
OpenAI API(有料) 使わない API経由は学習対象外(OpenAI公式)
Anthropic API 使わない 商用APIは学習対象外(Anthropic公式)
ChatGPT 無料/Plus 使う(オプトアウト可) 設定からオフ可能
ChatGPT Enterprise/Team 使わない 契約条項で明記
Google Gemini API 一部利用 プランで異なる
Google AI Studio 使う 評価・改善に使われる旨明記

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

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

3点目が見落とされがちだ。学習に使われなくても、規約上は不正利用調査などのためにリクエストが一定期間保持されうる(期間は各社の規約で確認)。PasteGuardを通せば保持されるのもプレースホルダだけになるのが本質的な価値だ。

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

公式ドキュメントには明示的な精度指標が見当たらない。構造が明確なもの(EMAIL・CREDIT_CARD、秘密鍵やENV系の正規表現)は拾いやすく、日本語人名(カタカナ・漢字混在)はPresidioの日本語spaCyモデル次第で、閾値0.7のままだと検出漏れが出やすい。ガードレール系製品の攻撃検出精度を自社評価する場合と同じく、公称値でなく自社プロンプトで測る。

日本語環境では検出精度の事前検証が必須
Presidioのデフォルトspacyモデル(ja_core_news_lg等)の人名認識は、英語ほど高くない。本番投入前に自社の典型的なプロンプト100件を流して検出率を測り、必要なら社内辞書を追加するか閾値を0.5前後に下げる運用が現実的。誤検知(過剰マスク)は受け入れ可能だが、検出漏れは情報漏洩そのものになる。

他のDLP(Data Loss Prevention)ツールとの違い

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

製品 カテゴリ カバー範囲 デプロイ 価格帯
PasteGuard LLM APIプロキシ LLM API/コーディングAI 自社ホスト(Docker) OSS(無料)
Microsoft Purview エンタープライズDLP M365・SaaS・エンドポイント クラウド 月額数千円〜/ユーザー
Nightfall AI クラウドDLP SaaS・GitHub・Slack・LLM クラウド エンタープライズ商談
Lakera Guard LLMガードレール LLMアプリ(プロンプト注入対策中心) クラウド/オンプレ 商用
Skyflow LLM Privacy Vault PIIヴォールト LLM API前段 SaaS 商用
自社実装 + Presidio 自前DLP 任意(要実装) 任意 開発工数

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

選び方の判断軸:「どこから漏れるか」を起点に逆算する
LLMに流れるルートが脆弱なら → PasteGuard。社員がDropboxやSlackから外部に流すルートが脆弱なら → Purview/Nightfall。PasteGuardは「LLM APIに特化することで導入の軽さと網羅性を交換した」プロダクトであり、自社のリスクシナリオが「開発者がClaude CodeやCursorに社内コードを丸ごと渡す」型に集中しているなら、極めて費用対効果が高い選択になる。

企業導入シナリオ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上ではPodのenvで PASTEGUARD_LANGUAGES を指定する。

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

パターン3:規制業界・医療・法務(ルートモード必須構成)

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

クラウドLLMには「PIIゼロのコード補完・公開資料の要約」だけが流れ、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(ビジョン系): 画像入力に含まれる顔・看板・書類は検出できない
  • 日本語人名の高精度検出: Presidio日本語モデルの限界。社内辞書ベースのカスタムRecognizerが必要
  • ファイルアップロード型のChatGPT利用: ブラウザ拡張機能ではChatGPTのテキスト入力をマスクするが、ファイル添付は対象外
「保険」と理解して導入する
PasteGuardは「あったほうが確実に安全」だが、これだけで「LLMにあらゆるデータを安心して流せる」わけではない。機密データを大量に含むリポジトリ全体をAIに渡すような根本的に危険な運用は、PasteGuardの有無にかかわらず避けるべき。あくまで「最後の砦」だ。

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自体を侵害されても元データが奪われない。漏洩リスクを増やさないためのゼロトラスト的設計だ。

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

BEFORE PRODUCTION投入前の確認

本番前に3つ確かめる

  1. 1.自社プロンプトで検出率を測る

    日本語人名・社内IDは特に漏れやすい

  2. 2.score_threshold を調整する

    0.5〜0.8で誤検知と漏れのバランスを見る

  3. 3.シークレットのオプトイン

    APIキー・AWS・GitHub系は既定でオフ

出典: 本文の検証チェックリスト
  • 自社の典型プロンプト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で似たプロキシを書く代わりに、PasteGuardはダッシュボード・ストリーミング対応・複数プロバイダ対応を1コンテナで提供する。v0.3.5・Apache 2.0で、試す敷居は低い。

参照ソース