フォースネット株式会社の製品サイトです
Column

機密データをAIに扱わせたい — ローカルLLMという選択肢と、その限界

ローカルLLMと機密データ #ローカルLLM#機密データ#生成AI

「この顧客リストの整形、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、導入形態の相談を受け付けています。