Column

「機密データをChatGPTに送れない」問題を解決する新しいアプローチ

外部LLM APIを業務に使いたいけどGDPRや個人情報保護法が怖い。SharedRequestはその障壁を、プロンプトを分散・匿名化するバッチ処理で乗り越えようとする。精度は20%向上、コストは5分の1という結果が出た。

2026 / 06 / 05 5 分で読める English version →

複数のプロンプトが混合されてクラウドに送られ、安全に結果が返ってくる流れを抽象的に表現した図

こんにちは。Affectosphere Group の井下です。

「ChatGPT や Claude を業務に使いたいが、機密情報や個人情報が含まれるデータを送ることができない」という問題、現場では頻繁に聞きます。

金融機関なら顧客情報、医療機関なら患者データ、法律事務所なら依頼人の秘密情報。GDPR や個人情報保護法の観点から、外部クラウドの LLM API にそのまま投げることができない。でも、そこにこそ AI が最も効果を発揮できる業務がある。

この「使いたいけど送れない」というジレンマに対して、2026 年 6 月に公開された研究（Peihua Mai, Xuanrong Gao, Youlong Ding, Xianglong Du, Wei Liu, Yan Pang ら、arXiv:2606.05004）が実装可能な解を提示しています。差分プライバシー手法との比較で 20% 以上の精度向上と、最大 5 倍のコスト削減を同時に達成した、というのが主な結果です。なお、この研究は ACL 2026 のメイン会議に採択されており、信頼性の高い知見です。

今日の 3 点

SharedRequest は、元プロンプトとノイズプロンプトを混合バッチ処理することで、外部 LLM に送るデータから機密情報を特定できなくする。
従来の差分プライバシー手法より 20% 以上精度が高く、クエリコストは最大 5 分の 1。
モデルのパラメータへのアクセス不要。つまり OpenAI、Anthropic、Google など任意の API に対して適用できる。

① SharedRequest の仕組みを直感的に理解する

技術的な詳細に入る前に、基本的なアイデアを直感的に理解しておきます。

普通に外部 LLM API を使う場合、「このユーザーの医療記録を要約してください：[記録本文]」というプロンプトをそのまま送ります。クラウド側のサーバーには、誰の何のデータかが完全に見える状態です。

SharedRequest が取るアプローチは、このプロンプトを「一つだけ送らない」というものです。

実際のプロンプトと、似た構造だが機密性のないノイズプロンプトを複数まとめてバッチとして送ります。「どれが本物のリクエストで、どれがノイズか」がサーバー側からわからないようにする。受け取った複数の応答の中から、対応するものを選択して利用します。

ポイントは「バッチレベルでの匿名化」です。個々のプロンプトを難読化するのではなく、複数のリクエストをグループとして処理することでプライバシーを確保する発想です。

セマンティックに類似した命令をグループ化して推論コストを分散させることもできるため、バッチ処理が精度を落とさずコストを下げることにつながります。

② 「差分プライバシー」との比較でなぜ優れているか

プライバシー保護の既存手法として最も研究が進んでいるのが「差分プライバシー（Differential Privacy）」です。データにノイズを加えることで、個人を特定できなくする手法です。

ただ、差分プライバシーには本質的なトレードオフがあります。プライバシーを強く保護しようとすると、ノイズが大きくなって精度が落ちる。精度を保とうとすると、プライバシー保護が弱くなる。

SharedRequest は、この「精度とプライバシーのトレードオフ」を別の軸から回避しています。プロンプトの内容を直接難読化するのではなく、「どれが本物か」をバッチの中に隠す。情報の質を落とさずに、帰属性（attribution）を消す、という考え方です。

差分プライバシーベースラインとの比較で 20% 以上の精度向上というのは、このアプローチの差が数値として現れた結果です。

③ 企業がこれをどう使えるか

「モデル非依存（model-agnostic）」「パラメータアクセス不要」というのが、実装面での最大の強みです。

社内に独自の LLM を構築せず、外部 API を使いたい企業にとっての最大の障壁は「API に送ることへの法的リスク」でした。SharedRequest のようなミドルウェア層を既存システムと外部 API の間に挟み込むことで、この障壁を技術的に解決できます。

具体的なシーンを考えます。

法律事務所の契約書レビュー自動化が一例です。依頼人名・案件詳細が含まれる契約書をそのまま外部 LLM に送ることは現行では難しい。SharedRequest を経由することで、プロンプト上の帰属情報を希薄化しながら、実質的な契約書レビューの精度は維持する、という運用が考えられます。DPO（個人情報保護責任者）への説明資料として、「バッチ匿名化の仕組みを経由している」という記録も残せます。

医療分野では、電子カルテのサマリー生成での活用があります。患者氏名・生年月日・診察記録を含む入力をそのまま外部 API に送ることは HIPAA・個人情報保護法上のリスクになります。SharedRequest の匿名化レイヤーを通すことで、医師のサマリー作成補助ツールとして外部 LLM を活用できるようになる可能性があります。

金融機関での顧客対応ログ分析も同様です。顧客 ID・取引履歴・相談内容が含まれるログを AI で分析することは、CX 改善に高い価値があります。でも個人情報の観点からそのまま外部に送れない。匿名化バッチ処理層を挟むことで、実用化への道が開けます。

コスト面も無視できません。最大 5 倍のクエリコスト削減は、大量の API コールが発生する業務では相当な差になります。プライバシー対応のコストを払いながら、実際の API コストは下がる、という逆転の発想です。

普及への課題と現実解

正直なところ、SharedRequest をそのままプロダクション環境に導入できるかというと、まだ実装の整備が必要な段階です。

ただ、考え方の方向性は重要です。「外部 LLM API を使えない」という制約の多くは、「プロンプトに機密情報がそのまま入っている」という設計の問題から来ています。どんな形であれ、プロンプトの匿名化・分散化というレイヤーを設計に組み込む発想は、GDPR 対応の実務でも今後の標準になっていく可能性があります。

今すぐできることとして、外部 LLM API 利用の設計で「どのデータがプロンプトに入るか」を明示的に設計書に記す、という習慣があります。個人を特定できる情報（PII）を自動でマスクするプリプロセスを入れるだけで、法的リスクを大きく下げられます。SharedRequest はそのさらに先の発想です。

では！

参考論文

Peihua Mai, Xuanrong Gao, Youlong Ding, Xianglong Du, Wei Liu, Yan Pang (2026). SharedRequest: Privacy-Preserving Model-Agnostic Inference for Large Language Models. ACL 2026.

※ 本記事は一部 AI により執筆されており、間違った情報が含まれる恐れがあります。