3つの心配が「外に出せない」の一言に混ざっています
生成AIの導入相談で最も多く出るのが「うちのデータは外に出せない」という言葉です。ただ、この一言の中身を聞いていくと、たいてい別々の心配が混ざっています。
- 入力した内容が、事業者のモデルの学習に使われるのではないか
- 入力した内容が、事業者のサーバーにログとして残るのではないか
- そのデータが国外のサーバーに保存されるのではないか
この3つは、確認する相手も、対処の方法も違います。混ぜたまま「だからローカルLLMで」と進むと、必要のない制約を自分に課すことになります。逆に、3つのうち1つしか確認せずにクラウドAPIを使い始めると、後から契約や監査で止まります。順に切り分けます。
学習に使われるかは、既定と契約で確かめられます
まず1つ目です。主要な事業者のAPIは、既定で入力を学習に使わないと公式に明示しています。
OpenAIは開発者向けドキュメントで、2023年3月1日以降、APIへ送られたデータは、明示的にオプトインしない限りモデルの学習や改善に使わないと述べています(OpenAI「Your data」)。Anthropicもプライバシーセンターで、Anthropic APIを含む商用製品の入出力を、既定ではモデルの学習に使わないとしています(Anthropic「Is my data used for model training?」)。
つまり「APIに入れる=学習データになる」という前提は、既定の挙動としては正しくありません。ここを確認せずにローカル前提で設計を始めると、選択肢を自分で狭めることになります。
IPAも、AI利用者向けの資料で「クラウドAIに営業秘密は教えない」と注意しつつ、サービス規約や利用時の設定を確認すれば、ユーザー入力を保存やAIの学習対象から除外できると案内しています(IPA「AI利用者のためのセキュリティ豆知識」)。確認する対象は、技術ではなく規約と設定です。
学習に使わないことと、保持しないことは別です
2つ目の心配は、学習利用とは別に確認が要ります。学習に使わないとしても、データが即座に消えるわけではありません。
OpenAIは、不正利用の監視のためAPIの入出力を最大30日間保持すると述べています。ゼロデータ保持(ZDR)や監視ログの変更は用意されていますが、いずれもOpenAIの事前承認と追加要件の受諾が前提です(OpenAI「Your data」)。Anthropicも、APIの入出力を受領・生成から30日以内に自動削除するとしたうえで、自動化された安全性システムが違反の疑いを検知した場合は、入出力を最大2年間保持しうるとしています(Anthropic「How long do you store my organization’s data?」)。ZDRの取り決めがある場合でも、法令上の要求や安全性システムによる検知があれば保持されうる点は、Anthropicの技術ドキュメントにも明記されています(Anthropic「API and data retention」)。
3つ目の保存国も、別に確認します。OpenAIは日本を含む地域別のデータレジデンシーを提供していますが、米国以外の地域を使うには不正利用監視の制御について承認を受け、保持に関する追加契約を締結する必要があるとしています。加えて、対象モデルの地域処理には10%の価格上乗せが適用されます(OpenAI「Your data」 / OpenAI 価格ページ)。
整理すると、確認すべきは「学習に使うか」「どれだけ保持するか」「どこに保存するか」の3層で、それぞれ既定値・申請の要否・費用が違います。社内で「外に出せない」と言われたとき、この3層のどれを指しているのかを先に特定してください。
個人データは「相手が取り扱うか」で扱いが変わります
個人情報を含む場合は、法令側の整理が加わります。
個人情報保護委員会は2023年6月の注意喚起で、生成AIサービスに個人情報を含むプロンプトを入力する場合、利用目的の達成に必要な範囲内であることを十分に確認し、かつ当該事業者が個人データを機械学習に利用しないこと等を十分に確認するよう求めています(個人情報保護委員会「生成AIサービスの利用に関する注意喚起等」)。前節の確認は、実務上の慎重さではなく、公的機関が求めている手順です。
クラウド全般の整理も参考になります。同委員会のQ&Aは、クラウドサービスの利用が第三者提供や委託に当たるかどうかを、保存データに個人データが含まれるかではなく、サービス提供事業者が個人データを取り扱うこととなっているかで判断するとしています。契約条項で取り扱わない旨が定められ、適切にアクセス制御が行われている場合が、取り扱わない例として挙げられています(Q&A Q7-53)。該当しない場合でも、自ら果たすべき安全管理措置は必要です(Q&A Q7-54)。外国のサーバーに保存する場合は、その国の制度を把握したうえで必要な措置を講じる必要があります(Q&A Q12-3)。
なお、これらのQ&Aはクラウドサービス一般についての整理で、生成AIサービスを名指しで扱ったものではありません。自社の案件に当てはめる際は、法務と一緒に判断してください。経済産業省・総務省のAI事業者ガイドライン(第1.2版)も、利用者の責務として、機密情報や個人情報をAIサービスへ不適切に入力しないよう注意を払うことを挙げています。
手元に落とすと、失われる能力には順序があります
3層を確認してもなお外に出せない範囲は残ります。規制、顧客との契約、社内規程のいずれかで縛られている場合です。その範囲をローカルLLMへ落とすことになりますが、ここで見落とされやすいのが「小さくすると何が落ちるのか」です。
量子化でモデルを圧縮すると、能力は一様に落ちるのではなく、順序をもって落ちます。Llama-3.1-8BをGPTQで量子化した評価では、知識を選ぶ問題(MMLU)が FP16 の 63.42% から 4bit で 61.44%、3bit で 49.11%、2bit で 24.18% へ推移するのに対し、算術と多段推論を要する問題(GSM8K)は 56.79% から 51.33%、10.16%、0.99% と、はるかに早く消えます(arXiv:2604.19884)。同じビット幅でも、知識想起がまだ半分残っている時点で、計算はすでに機能していません。
同研究は、4bitと2bitを量的な差ではなく質的に異なる2つの故障として区別しています。4bitは計算パターンが保たれたまま誤差が蓄積する劣化(Signal Degradation)で、正解の候補は多くの場合まだ上位に残ります。2bitは主要な部品が機能しなくなる崩壊(Computation Collapse)で、正解の順位が数千位まで落ち、出力が高頻度の単語へ崩れます。訓練を伴わない補正は前者には効くが後者には効かない、というのが同研究の結論です。
実務の目安も一次情報にあります。推論特化モデルを対象にした評価では、W8A8 または W4A16 の量子化であれば精度をほぼ落とさずに済む一方、それより低いビット幅は重大な精度低下のリスクを伴うと報告されています(arXiv:2504.04823)。4bit量子化の実測を公開しているモデルカードでも、GSM8K や HumanEval はほぼ元のまま、一方で多段推論を問う MuSR は 83.2% まで落ちるという内訳が示されています(RedHatAI Llama-3.1-8B-Instruct-quantized.w4a16)。
日本語と長い推論は、簡単なテストでは崩れが見えません
もう一つ、日本企業には効く報告があります。多言語での量子化の影響を調べた研究は、日本語について、自動評価タスクの平均では 1.7% の低下だったものが、現実的なプロンプトに対する人手評価では 16.0% の低下として現れたとしています(arXiv:2407.03211)。同研究は、非ラテン文字の言語ほど影響を受けやすいとも述べています。自動評価の数字だけを見て「ほとんど落ちていない」と判断すると、実際の使用感と食い違います。
崩れが見えにくいのは言語だけではありません。低ビット量子化のモデルを公開している事業者は、自社のモデルカードで、2bit相当のビルドが知識問題では 88.93 を維持しながら、競技数学やコード生成の評価では 57.5 や 56.4 まで落ちると示し、カジュアルなテストではこの崩壊を見逃す、と明記しています(PrismML Ternary-Bonsai-27B モデルカード。数値は事業者の自己申告で、第三者による再現は確認していません)。知識を尋ねる質問で試すと合格に見え、長い推論を要する実業務で崩れる、ということです。
導入前の確認は、一般的なベンチマークではなく、自社の実際のタスクで行ってください。とくに社内文書の要約や検索のように、知識想起が中心の用途は小さいモデルでも成立しやすく、見積計算や条件分岐の多い判断を任せる用途は、同じモデルでも先に崩れます。
線引きはデータの機微さではなく、タスクで引きます
ここまでを踏まえると、実際の設計は次の順で決まります。
- 「外に出せない」の中身を、学習利用・保持・保存国の3層に分ける。契約と設定で外せるものを外す。
- 個人データを含む場合は、相手が個人データを取り扱う立場になるかを法務と確認する。
- それでも残った範囲だけを、手元で動かす対象にする。
- その範囲のタスクが、知識想起中心か、多段の推論や計算を含むかで、必要なモデルの規模と量子化の下限を決める。
- 決めたら、自社の実タスクで評価する。一般的なベンチマークの数字では判断しない。
機微なデータを扱う処理を手元に置き、難易度の高い処理をクラウドへ回す組み合わせは、ローカルLLMの記事でも触れたとおり現実的な選択です。その際、手元に置いた側の運用費と体制、クラウドへ渡す側の権限とデータの境界は、どちらも設計に含めてください。ローカルに置いたから安全、という話ではありません。
vnodでは、業務システムへAIを組み込むとき、モデルの選定より先にこの線引きから入ります。外に出せない範囲が本当はどこまでなのかを契約と法令の側から確定させると、手元に抱える範囲は当初の想定より小さくなることが多く、その分だけ性能とコストの選択肢が広がります。データの制約でAI活用を止めている段階のご相談は、お問い合わせからお聞かせください。
