クラウドLLMとローカルLLMの使い分け — 通常業務と機密業務を分ける

ローカルLLMとは何かで整理したとおり、クラウドLLMとローカルLLMにはそれぞれ譲れない強みがあります。クラウドの賢さ、ローカルの「出ない」性質。では実務では、どう組み合わせればよいのか。結論を先に言えば、仕分けの基準は「その仕事で扱うデータが、外部送信できるか」の1点です。この1点をどう設計へ落とすかを扱います。

「全部どちらか」はどちらも破綻する

まず、単純な方針がなぜうまくいかないかを確認します。

全部クラウドLLMにすると、外部送信できない機密の扱いが残ります。規約と契約を整えても「送信自体が不可」の情報はなくならず、結局「この情報はAIに入れるな」という運用ルールに頼ることになります。そのルールは、便利さの前で破られやすくなります。

全部ローカルLLMにすると、今度は賢さが足りません。最新のクラウドAIを体験した社員にとって、すべての業務をローカルLLMの水準で行うのは生産性の放棄に感じられます。すると今度は「個人でこっそりクラウドAIを使う」というシャドーAIが生まれます。

どちらの破綻も原因は同じです。性質の違う仕事を、ひとつの環境に押し込んでいることです。

仕分けの基準は「データ」だけ

使い分けというと「業務の種類で分ける」と考えがちですが、基準はもっと単純です。

その仕事で扱うデータは、外部に送信してよいか。

ポイントは、仕分けの単位が「人」でも「部署」でもなく仕事（扱うデータ）であることです。同じ開発者が、午前は通常業務でクラウドAIを使い、午後は機密業務でローカルLLMを使う。これが自然な姿です。なお「どのデータが機密か」の線引き自体が曖昧な場合は、先にデータ分類を整える必要があります（AIに渡してよい情報をどう決めるか）。

ルールによる使い分けは、なぜ破られるか

ここまでの仕分けは、多くの企業がすでに「利用ガイドライン」として持っています。問題は、それが同じ環境の中での使い分けになっていることです。

同じPCの中に、機密ファイルとクラウドAIへの接続が同居している限り、使い分けはその瞬間ごとの人の判断に委ねられます。

• 「このファイル、機密だけど一部だけなら貼ってもいいか」（今回だけの例外）
• 「機密かどうか微妙だから、まあクラウドでいいか」（グレーの倒し方が便利側）
• 「急ぎだから後で消せばいいか」（時間圧力）

悪意はどこにもありません。しかし判断の回数だけ事故の機会があり、起きた持ち出しは取り消せません。

構造で分ける — 環境そのものを2つにする

設計の要点は、使い分けの判断を人から環境に移すことです。

• 機密データが置いてある環境には、クラウドAIへの経路がない
• クラウドAIが使える環境には、機密データが置けない

この2つが構造として成立していれば、社員は「どちらのAIを使うべきか」を悩む必要がなくなります。機密の仕事はその部屋に入って行い、そこではローカルLLMしか動かない。通常の仕事はクラウドAIの部屋で行い、そこに機密はそもそも存在しない。判断の回数が減るほど、使い分けは崩れにくくなります。

逆に言えば、使い分けガイドラインを作る際は「この使い分けは何で担保されるのか（人の注意か、構造か）」を必ず問うてください。紙の上で完璧な使い分けほど、現場では静かに崩れます。なお機密側の環境を実際に回すための運用（申請・承認・持ち出し管理）は、機密作業用AI環境の運用ルールで扱っています。

まとめ

• 「全部クラウド」は機密の扱いが残り、「全部ローカル」は賢さで行き詰まる。答えは使い分け
• 仕分け基準は業務種別ではなく扱うデータが外部送信できるかの1点
• 単位は人や部署ではなく仕事。同じ人が両方を行き来するのが自然
• 同一環境内での使い分けは人の判断頼みになり崩れやすい。環境そのものを分けて構造で支える

使い分けの判断を人から環境へ移す、という設計をそのまま製品にしたのが2つのルームという作りです。Hoko（矛）は、通常業務向けのクラウドAI環境（通常ルーム）と、機密業務向けのローカルLLM環境（機密ルーム）を分けて提供するAIエージェント実行アプライアンスで、部屋の行き来はできても、機密データとクラウドへの経路が同じ部屋に同居しない構造になっています。