機密データをAIに扱わせたい — ローカルLLMという選択肢と、その限界
「この顧客リストの整形、AIにやらせたら一瞬なのに」——現場のこの感覚は正しいです。生成AIが最も役に立つのは、定型的で量が多く、間違えたくない仕事。そして企業の中でその条件に当てはまる仕事は、たいてい機密データのすぐ隣にあります。AIに任せたい仕事ほどクラウドに出せない、という矛盾をどう解くか。「ローカルLLM」という選択肢を、仕組みから正直な限界まで整理します。
なぜ機密データとクラウドAIは相性が悪いのか
クラウドAIへの入力は、社外への送信です。送信先・保持期間・学習利用の有無はサービスや契約プランごとに異なり、利用する個々のサービスについて規約と契約条件を確認する必要があります(この論点の整理は姉妹製品サイトの記事「LLMに入力した情報はどこへ行く?」に詳しくまとめています)。
確認の結果「法人契約なら学習利用されない」と分かったとしても、話はそこで終わりません。
- 規程・契約の壁 — 顧客との秘密保持契約や業界の規程が「外部サーバーへの送信」自体を許さないケースがあります。学習利用の有無以前の問題です。
- 確認コストの壁 — サービスもプランも規約も頻繁に変わります。「現時点で大丈夫」を維持し続ける運用負荷は小さくありません。
- 既成事実の壁 — 禁止しても、便利さに負けた持ち出しは静かに起きます。個人アカウントの生成AIに顧客情報が貼り付けられた時点で、取り消す手段はありません。
3つ目が最も厄介です。人は便利な方を選ぶので、「機密はAIに入れるな」というルールは、機密を扱う社員からAIを取り上げるか、ルール破りを生むかの二択になりがちです。
選択肢の整理 — 禁止・法人プラン・ローカルLLM
機密データと生成AIの両立には、大きく3つの選択肢があります。
| 選択肢 | データの行き先 | 賢さ | 主な課題 |
|---|---|---|---|
| 利用禁止 | 出ない(建前) | — | シャドーAI化。実際には「出ていないことを確認できない」 |
| クラウドAIの法人プラン | 事業者のサーバー(契約で保護) | 最高水準 | 規約・契約の継続的な確認。「送信自体が不可」な機密には使えない |
| ローカルLLM | 出ない(構造) | 中位 | 賢さの限界。GPU等の設備と運用の手間 |
どれか1つを選ぶ問題ではない、というのが本記事の結論ですが、まずローカルLLMがどういうものかを押さえます。
ローカルLLMとは何か
ローカルLLMとは、自社の管理下にあるハードウェアの上で動かす大規模言語モデルです。公開されているオープンなモデルを自社のサーバー(多くはGPU搭載機)に載せ、社内ネットワークの中だけで推論させます。
クラウドAIとの本質的な違いは1点に集約されます。入力したデータが、自社の箱から出ないことです。
- 規約の変更を追いかけ続ける必要がありません。そもそも外部事業者にデータを渡していないからです。
- 「送信自体が不可」という最も厳しい機密区分にも適用できます。
- 「出ていないこと」を、契約や信頼ではなくネットワーク構成という事実で説明できます。監査への答え方が変わります。
ローカルLLMの正直な限界
良いことばかりではありません。導入判断の前に、限界を正面から見ておくべきです。
賢さは最新のクラウドAIに及ばない
これが最大の限界です。オープンモデルは年々向上していますが、その時点での最先端のクラウドAIと比べれば、推論の深さ・正確さで見劣りします。「クラウドAIで体験した賢さ」を期待してローカルLLMに同じ仕事をさせると、落胆することになります。
重要なのは、何を優先するかを最初に決めておくことです。機密データの処理では「賢さより、出ないこと」を優先する。この割り切りができないなら、ローカルLLMは向きません。
設備と運用の負荷
実用的な速度でモデルを動かすにはGPU等の計算資源が必要で、モデルの選定・更新・性能評価も自社の仕事になります。「置けば終わり」ではなく、面倒を見る対象が一つ増えると考えるべきです。
環境がばらばらになりやすい
意外に見落とされるのがこの点です。各自のPCでローカルLLMを動かし始めると、モデルもバージョンも管理状態もばらばらになり、「ローカルだから安全」のはずが誰も全体を把握していない状態になります。ローカルLLMこそ、共有の実行環境に集約して管理する価値があります。
「場所で分ける」という設計
ここまでを踏まえると、現実的な答えは「全部クラウド」でも「全部ローカル」でもありません。
- 機密に触れない仕事(一般的なコード、公開情報のリサーチ、文章の下書き)は、クラウドAIの法人プランで最高水準の賢さを使う。
- 機密に触れる仕事(顧客データ、設計情報、社外秘文書)は、ローカルLLMで「出ない」ことを最優先する。
この使い分け自体は、多くの企業がルールとして既に考えています。問題は、分け方を人の注意力に委ねると守られないことです。同じ環境の中に機密ファイルとクラウドAIへの接続が同居していれば、「うっかり」や「今回だけ」はいつか起きます。
だから設計の焦点は、ルールではなく場所に移ります。機密データを置ける場所にはクラウドへの経路が無く、クラウドAIを使える場所には機密データが無い。そういう構造を最初から作ってしまえば、社員は迷う必要がなく、管理者は確認する必要がありません。
まとめ
- AIに任せたい仕事ほど機密に近い。禁止ルールはシャドーAIを生みやすい
- ローカルLLMは「データが出ない」ことを契約ではなく構造で実現できる
- ただし賢さは最新のクラウドAIに及ばない。「賢さより出ないこと」の割り切りが前提
- 各自のPCでばらばらに動かすと管理不能になる。共有の実行環境への集約を
- 現実解は「場所で分ける」。機密はローカルLLM、通常業務はクラウドAIの使い分けを、人の注意ではなく構造で強制する
2つのルームは、この「場所で分ける」設計をそのまま製品にした構成です。Hoko(矛)というAIエージェント実行アプライアンスでは、機密ルームが箱内のローカルLLMだけで完結し、通常ルームでは本物のクラウドAIを使えます。
AIツールを、組織に配る実行基盤を検討しませんか。
Hoko(矛)は、Claude Code / Codex CLI / ローカルLLM などのAIツールを、社員ごとの管理されたAIワークスペースとして提供する実行基盤です。デモ実演、PoC、導入形態の相談を受け付けています。