ローカルLLMの企業導入で、最初に決めること

クラウドAIが規程で止まっている場合、ローカルLLMは選択肢になります。ただし「全部を閉域にする」のは現実的ではありません。この記事では、扱うデータごとに分けるための基準と、導入の進め方を整理します。ローカルLLMそのものの仕組みには深く立ち入らず、社内の合意形成に必要な論点に絞ります。

なぜクラウドAIが止められるのか

現場から「ChatGPTを使わせてほしい」と言われ、規程上その場で許可できない。この状態の背景には、性質の異なる3つの問題が混ざっています。社内の議論が止まる原因の多くは、この3つを分けずに「セキュリティが心配」とまとめて扱っていることにあります。

1. 社外送信の禁止

社内規程が「業務データを外部サービスへ送信してはならない」と定めている場合、問題になるのは送信先の信頼性ではなく、データが自社の管理下を出るという事実そのものです。この条文が根拠になっているときは、提供事業者がどれだけ強固な管理を行っていても、条文の要件は満たせません。

2. 学習利用への懸念

「入力した情報がAIの学習に使われるのではないか」という懸念です。これは1とは別の問題で、多くの場合は契約形態の選択で回避できます。API経由の利用では、入力データをモデルの学習に使わない構成を選べる提供形態があります。契約条件は事業者と契約種別によって異なるため、利用規約と契約書の該当条項を一次情報で確認してください。

3. 監査・説明責任

誰がどのデータをAIに入力し、どんな出力を業務に使ったのかを説明できないことへの懸念です。これはクラウドかローカルかで自動的に解決する問題ではありません。ログの取得と保管、権限の設計を自社で決める必要があります。

この3つを分けると、議論の進め方が変わります。2だけが論点なら契約形態の見直しで足り、3だけが論点なら運用設計の問題です。ローカルLLMが本当に必要になるのは、1が規程として明文化されている場合です。ローカルLLMの仕組みや動かし方そのものについては、ローカルLLMとは何か・Gemma 4でできることを解説した記事で整理しています。

ローカルLLMで解決すること、しないこと

導入検討で最初にずれるのが期待値です。ローカルLLMにすると解決する問題と、そのまま残る問題を先に確認します。

権限管理は自社の仕事になる

クラウドのサービスを使う場合、利用者管理や監査ログは提供機能として用意されていることが多くあります。閉域環境に自分たちで構築する場合、それらは設計項目です。誰がどの文書を参照できるのか、退職者のアクセスをいつ止めるのか、ログをどこに何年保管するのか。ここを後回しにすると、監査で指摘を受けるのは導入から半年以上あとになります。

出力の質は自動的には上がらない

閉域で動かすモデルは、クラウドで提供される上位モデルより小さい構成になることが一般的です。要約や分類のように用途が定まった処理では実用になりますが、長い文脈の推論や複雑な指示の解釈では差が出ます。「社内の機密文書を扱うのだから、より正確であってほしい」という期待と逆方向に働く点は、導入前に共有しておく必要があります。

データを分ける基準

全社のあらゆる業務データを閉域で扱おうとすると、費用も運用負荷も現実的な水準を超えます。実務では、扱うデータごとに置き場所を分けます。判断の軸は3つです。

軸1：社外に出しても良いか（規程の問題）

自社の規程・契約・業法で、外部送信が禁じられているかどうか。顧客との取引基本契約で「再委託先を含め外部へ提供しない」と定めた情報や、個人情報のうち第三者提供に該当し得るものはここに当たります。判断は担当者の感覚ではなく、条文に当てて行います。

軸2：出たとして損害があるか（リスクの問題）

規程で明示されていない情報については、外に出た場合に実害があるかで判断します。未公開の価格表、設計情報、人事評価、係争中の案件に関する記録などは、規程に書かれていなくても閉域側に寄せる判断が妥当です。

軸3：どれくらいの頻度で使うか（コストの問題）

固定費で動くローカル環境は、使う量が多いほど1件あたりのコストが下がります。逆に、月に数回しか使わない用途のために専用環境を用意すると、単価は跳ね上がります。機密度が高くても利用頻度が極端に低い業務は、閉域環境を作るのではなく、そもそもAIを使わない判断も含めて検討します。

この3つを重ねると、置き場所は次のように整理できます。

この表を自社の業務名で埋めたものが、社内説明の土台になります。「クラウドかローカルか」を全社一律で決めるのではなく、業務単位で置き場所を決めたと説明できる状態が目標です。

導入の選択肢は3つある

閉域といっても、いきなり自社サーバを用意する必要はありません。現実には3つの選択肢があります。

「自社管理下」の定義を先に読む

実務上いちばん効くのが2行目です。社内規程が禁じているのが「不特定の外部サービスへの送信」であり、「自社が管理する環境での処理」は許容されている場合、クラウド事業者のプライベートな専用環境で要件を満たせることがあります。この場合、機器の調達も保守要員も不要になり、必要なときに構成を変えられます。規程の条文を読み、法務・セキュリティ部門と定義を確認するところから始めるのが近道です。

検証は用途を1つに絞る

3行目は、判断材料を作るための段階です。オープンウェイトのモデルを使い、1つの業務に絞って実際の文書で試します。ここで見るのは、出力の質が業務に足りるか、待ち時間が許容できるか、現場が使い続けられるかの3点です。検証環境と本番提供では、権限・ログ・可用性の設計が変わるため、そのまま本番に移行できる前提では組みません。

モデルの選定では、モデル名の新しさではなく次の3点を見ます。商用利用の可否を含むライセンス条件、日本語での実際の出力品質、必要なVRAMの目安です。いずれもモデルごとに異なり、提供元の公式ページと利用規約で確認する必要があります。閉域構成で実際に動かしているものの例としては、端末内で処理するローカルAI議事録の構成が参考になります。

費用の考え方

クラウドとローカルは、金額の大小より先に費用の形が違います。ここを説明できないと、社内稟議で「結局どちらが安いのか」に答えられません。

使う量が少ないうちはクラウドが安く、ある点を超えると逆転します。その分岐点がどこかは用途によって違うので、試算するしかありません。試算に必要なのは、対象業務の月間処理件数、1件あたりの入力と出力の分量、求める応答速度の3つです。この3つが出せない段階で機器の見積りを取っても、比較にはなりません。

ローカル側で見落とされやすいのが運用の人手です。モデルの入れ替え、障害時の切り分け、利用状況の確認、権限の棚卸し。これらは機器費用と違って毎月かかり、社内の担当者が兼任で抱えると、導入の半年後に止まる原因になります。

導入したあとに起きること

導入判断の前に、運用が始まってから起きることを共有しておきます。ここを先に伝えておくと、あとで「聞いていない」が起きません。

モデルの更新は自動では起きない

クラウドのサービスは提供側がモデルを更新しますが、閉域環境では入れ替えるのは自社です。誰がいつ評価し、いつ切り替えるのかを決めていないと、導入時のモデルのまま数年動き続けます。年に1回は評価する、といった頻度を運用ルールに書いておきます。

「思ったより遅い」と言われる

閉域環境の応答速度は、用意した計算資源と同時利用者数で決まります。クラウドのチャットに慣れた利用者は、数秒の差を遅いと感じます。検証の段階で実測値を出し、どの程度の待ち時間になるかを先に共有しておくと、評価が安定します。

用途を絞らないと使われなくなる

「何にでも使えるAIを入れました」という伝え方をすると、利用者は何に使えばよいか分からず、数週間で使われなくなります。最初に用途を1つか2つに絞り、その業務で成果が出てから広げるほうが定着します。

権限設計の後回しは必ず戻ってくる

検証のときは参加者が数人なので、全員が全文書を見られる構成でも問題が起きません。全社に広げた段階で、部門をまたいだ参照が起きます。設計をやり直すことになる前に、対象範囲を広げる時点で権限の設計を入れます。

向いていないケース

次の条件に当てはまる場合、ローカルLLMの導入は勧めません。

• 利用頻度が低い。固定費が見合いません。月数回の用途であれば、閉域環境を作るより運用でカバーするほうが安くなります。
• 最新の性能が必要。長い文脈の推論や複雑な指示の解釈では、クラウドの上位モデルとの差がすぐには縮まりません。
• 運用できる人が社内にいない、かつ外部にも頼めない。構築より運用のほうが長く続きます。
• 要件が「なんとなく不安」で、規程になっていない。この場合は、導入より先に規程を決めるほうが早く進みます。

最後の1つが最も多いケースです。規程に書かれていない不安を前提に閉域環境を作ると、作ったあとで「結局どこまで入れていいのか」が決まらず、使われないまま残ります。扱ってよい情報の範囲を先に文書化すれば、クラウドの利用範囲も同時に広がります。

検討の進め方

技術の検討から入らず、社内手続きから始めます。

1. 扱いたいデータを書き出し、規程のどの条文に当たるかを確かめる。業務名とデータ種別で一覧にします。
2. クラウドの専用環境で満たせないかを先に検討する。「自社管理下」の定義を法務・セキュリティ部門と確認します。
3. 満たせないなら、用途を1つに絞って検証する。実際の文書で、出力の質と待ち時間を測ります。
4. 待ち時間・出力の質を実測し、現場に触らせる。担当者の評価だけで判断しません。
5. 運用体制を決めてから広げる。更新・権限・ログの担当を決めます。

1と2で終わる企業も少なくありません。それは失敗ではなく、閉域構成の費用と運用負荷を負わずに済んだという結果です。

まとめ

「クラウドかローカルか」は二択ではありません。扱うデータごとに分けるのが現実解です。社外送信の禁止・学習利用への懸念・監査への対応を切り分け、業務単位で置き場所を決めれば、規程を守りながら使える範囲は今より広がります。

カトルセでは、閉域環境を前提にした生成AI開発も、クラウドを使った構成も両方を手がけています。どちらが合うかを含めて、初回60分で整理します。閉域構成とクラウド構成をそれぞれどんな業務で使い分けたかは、ローカルLLM・RAG・議事録自動化のAI開発事例で公開しています。

※ 本記事の内容は2026年9月時点の情報にもとづいています。モデルのライセンス条件、クラウド各社の学習利用ポリシー、機器の価格帯はいずれも変動します。判断の際は提供元の公式ページと利用規約をご確認ください。