ローカルLLMは自社に必要か｜導入判断・費用・体制の実務ガイド【2026年9月版】

本記事の情報について: 本記事は2026年9月2日時点で確認した公開情報と、当社の生成AI・RAG開発の実務知見に基づいています。料金・ライセンス条件・ガイドラインの版数は更新が速いため、意思決定に用いる際は各出典の最新版をご確認ください。本文中の料金・法令解釈は一般的な整理であり、個別案件の法的助言ではありません。

「ローカルLLMを検討してほしい」と言われて調べ始めると、モデル名とツール名と必要VRAMの話ばかりが出てきます。ところが経営会議で実際に問われるのは、そもそも自社に必要なのか、いくらかかるのか、誰が運用するのか、そして何が残るリスクなのかという別の4つだからです。技術の比較記事をいくら読んでも、この4つの答えは出てきません。

本記事は、その4つに答えるための記事です。結論を先に言うと、ローカルLLMは「安くするための選択」ではなく「責任を外部から自社へ引き取る選択」です。 後述するとおり、クラウドLLMのAPI利用料とGPUを1基借り続けるコストが逆転するのは、公式価格で計算すると月30万回規模の問い合わせを超えたあたりです。社員100人が毎営業日20回使っても（月40,000回）、その7分の1に届きません。つまり多くの企業にとって、ローカルLLMを選ぶ理由はコストではなく、データの制約と、その裏返しである自社が負う義務の設計にあります。

製品選定をお探しの方へ：本記事は導入判断だけを扱います

本記事はローカルLLMの 導入判断 に射程を絞っています。モデルやツールの実名比較は扱いません。あなたの現在地に応じて、読むべき記事が変わります。

• どのモデル・どのツールを選ぶかを知りたい方（Llama／Qwen／Gemma／ELYZA-JPの違い、Ollama・LM Studio・vLLMの使い分け、規模別の必要VRAM）は、ローカルLLMおすすめ比較｜日本語・費用・選び方をご覧ください。製品選定はそちらに集約しています。
• そもそも自社に導入すべきかを判断したい方、費用と体制を経営層に説明する必要がある方、稟議とベンダー選定を控えている方は、このまま本記事をお読みください。

なお「社内LLM」「オンプレミスLLM」「プライベートLLM」といった呼び方も見かけますが、本記事ではいずれも自社が管理する環境でモデルを動かす形態として同じものを指しています。呼称の違いより、後述する「誰がどの責任を持つか」の違いのほうが実務では効きます。

この記事の要点

• ローカルLLMを選ぶ合理的な理由は、コスト削減ではなくデータの制約である。公式価格で試算すると、クラウドLLMとGPUを1基借り続けるコストが逆転するのは月約30万回の問い合わせ規模で、一般的な社内利用はそこに届かない
• 見積もりから抜けやすいのは、GPU本体ではなく電力・空調・冗長化・運用人件費・モデル更新の再評価・3年後の入れ替え原資である
• ローカルが必要な範囲は、AIに入力するデータを業務単位で棚卸しすると想定より狭い。機密性の高い処理だけを自社環境に置き、残りをクラウドLLMに任せる構成のほうが、総額は下がり品質は上がる
• 「ローカルなら安全」は成り立たない。個人情報保護委員会は、クラウド利用が「提供」に当たらない場合でも自ら安全管理措置を講じる必要があるとしており、環境を自社に移せば義務が消えるわけではない
• AI事業者ガイドラインで「AI提供者」に当たるかどうかを分けるのは、クラウドかローカルかではなくAIを組み込んだサービスとして提供しているかどうかである（同ガイドラインの定義）。自社の社内提供がこれに当たるかは当てはめの問題だが、ローカルではモデルの品質管理・更新・脆弱性対応まで自社に寄るため、提供者としての負担は実質的に重くなる
• オープンウェイトモデルのライセンスは「商用可か」ではなく「どう使うか」で変わる。代表的なライセンスには無保証（AS IS）と責任制限が、Llama 3.3コミュニティライセンスでは加えて第三者請求への補償義務が明記されているため、出力の誤りに対する契約上の受け皿は期待できない
• 体制の穴は必ず表面化する。役割が埋まらないまま始めたPoCは、精度ではなく運用で止まる
• 進め方の順序は「要件を文書で確定 → 借りたGPUで小さく検証 → 撤退条件を持って判断 → 役割に名前を入れて本番」。GPUを買うのは最後である

ローカルLLMとは何か：導入判断で問うべきこと

ローカルLLMとは、大規模言語モデルの本体（数十GBになるファイル）を自社が管理するPCやサーバーに置き、外部に送信せずに、AIが答えを出す処理まで自社内で完結させる利用形態です。ChatGPTやClaudeのようなクラウドLLMが、入力をクラウド事業者のサーバーへ送って処理するのに対し、ローカルLLMは処理そのものが自社の管理下で行われます。

本記事で「オープンウェイトモデル」と呼ぶのは、モデルの中身のファイルが公開されていて、自社の機械にダウンロードして動かせるものを指します。無料で入手できることと、無保証であることが同時に成り立つ形態です。この2つが同居している点が、後述するライセンスの章で効いてきます。

技術的な説明はここまでで十分です。経営判断として押さえるべきなのは、この違いが「どこにデータが行くか」だけでなく「誰が責任を負うか」も同時に変えているという点です。クラウドLLMを使うとき、モデルの品質管理・脆弱性対応・不具合の説明・新版の提供はクラウド事業者の仕事で、利用側に残るのは移行時期の判断にとどまります。ローカルLLMに移すと、それらは自社の仕事になります。データを外に出さずに済む代わりに、外部に任せていた運用と説明責任を自社が引き受けることになります。

この構造を理解すると、導入判断で問うべきことが自然に決まります。本記事は冒頭に挙げた4つの問いを、次の順で扱います。

そのうえで、進め方（調達・PoC・稟議）を後半で扱います。

なお、生成AIの業務活用そのものが初めてという段階であれば、ローカルかクラウドかを議論する前に、社内データを活用したAI導入の進め方で全体像を整理するほうが順序として確実です。

判断の出発点：ローカルLLMが「要る／要らない」を分ける4つの条件

ローカルLLMが必要になるのは、次の4条件のいずれかに実際に当てはまるときだけです。当てはまらない場合、クラウドLLMのほうが総合的に有利になることがほとんどです。

条件1: 外部に送信できないデータを、実際にAIへ入力する必要がある

ここで重要なのは「機密データを持っている」ではなく「そのデータをAIに入力しないと目的が達成できない」かどうかです。多くの検討は、この2つを混同したところから始まります。たとえば設計図面を扱う製造業でも、AIにやらせたいのが議事録要約や社内規程の検索であれば、図面をAIに入力する必要はありません。入力するデータを業務単位で棚卸しすると、ローカルが必要な範囲は想定よりずっと狭いことが分かります。この棚卸しは「全部をローカルにしない」の章で表にします。

条件2: 契約や業法上、データの所在や取扱いに明示的な制約がある

顧客との秘密保持契約に再委託先の制限がある、業界の自主規制でデータの国外移転が制限されている、官公庁案件の仕様書で国内保管が求められている、といったケースです。これは自社の判断ではなく相手方との約束なので、技術的にクラウドが安全かどうかとは無関係に効いてきます。契約書を確認せずに「クラウドでも大丈夫なはず」と進めると、後から覆ります。

条件3: ネットワークが使えない、または不安定な環境で動かす必要がある

工場のクローズドネットワーク、船舶、地下設備、災害時の縮退運用などです。この条件は誤魔化しが効かないため、当てはまる場合はローカル一択になります。

条件4: 特定ベンダーへの依存そのものを避けたい経営判断がある

価格改定・提供終了・仕様変更の影響を受けたくない、モデルのバージョンを自社の都合で固定したい、という要求です。ただしこれは、後述するとおり運用負担と引き換えになります。「依存を避ける」は無料ではありません。

逆に、この理由で検討しているなら立ち止まってください

• 「APIの従量課金が高そうだから」 → 後述の費用試算のとおり、多くの企業規模では逆転しません
• 「クラウドは学習に使われそうで不安だから」 → クラウド事業者の利用規約とオプトアウト設定の確認が先です。事業者向けプランでは入力データを学習に使わない旨を明示している事業者もあるため、自社が契約する（あるいは契約中の）プランの規約で個別に確認してください
• 「セキュリティ部門が生成AIを止めているから」 → 止まっている理由が「クラウドだから」なのか「ルールが無いから」なのかで打ち手が変わります。後者であれば生成AI利用ガイドラインの作り方から着手するほうが早く進みます

4条件のいずれにも当てはまらないのにローカル化を進めると、コストと運用負担だけが増えて、得られるものが「安心感」しか残らないという結果になりがちです。

全部をローカルにしない：データ別に置き場所を決める

「判断の出発点」で挙げた4条件に当てはまったとして、次に決めるのは「どこまでをローカルにするか」です。ここで「機密情報を扱う会社だから全業務をローカルで」と一括りにすると、費用も運用負担も跳ね上がり、しかも大半の業務にとっては過剰な構成になります。

実務で有効なのは、業務ではなく扱うデータ単位で置き場所を決めるやり方です。同じ部署の業務でも、扱うデータによって答えが変わります。

この表を自社の業務に当てはめると、多くの場合ローカルが必須なのは全体の一部だと分かります。そのうえで構成を決めます。

設計の勘所は「データを動かすのではなく、処理を分ける」ことです。機密データを扱う処理だけを自社環境のモデルに担当させ、それ以外はクラウドLLMに任せます。利用者から見れば1つの社内AIですが、裏側では入力の性質によって処理先が切り替わる、という構成です。

この構成には3つの利点があります。第一に、高価なGPUを必要とする処理量が小さくなるため、ハードウェア規模を抑えられます。第二に、品質の高いモデルが使える範囲が広がること。ローカルで動かせるモデルはハードウェアの制約から選択肢が限られますが、制約のない業務ではクラウドの最新モデルを使えます。第三に、段階的に始められる点です。まずクラウドで全社に展開して使い方を定着させ、機密領域だけを後からローカルへ切り出す——この順序が取れます。

一方で注意点もあります。どのデータがどちらへ行くかを、利用者が意識せずに間違える経路を作らないことです。「クラウド側の窓口に機密文書を貼り付けられてしまう」構成にすると、分離した意味がなくなります。入力の振り分けを利用者の判断に委ねるのではなく、業務ごとに入口を分ける、あるいはシステム側で判定する設計にしてください。この振り分けルールは、利用ガイドラインと一体で決める必要があります。

なお、ローカル側に置く処理でも、必ずしも大型モデルが要るとは限りません。分類・タグ付け・定型的な抽出といった処理は小型モデルで十分なことが多く、その場合は必要なハードウェアが大きく下がります。用途に対してモデルが過大になっていないかは、小規模言語モデル（SLM）業務活用ガイドの観点で見直す価値があります。

クラウドLLMとローカルLLMの費用は、どこで逆転するのか

ここが最も誤解の多い論点です。「一度環境を作ればAPI料金はゼロ」という説明をよく見かけますが、GPUを動かし続けるコストはゼロではありません。公開されている公式価格を使って、実際に逆転点を計算してみます。

試算の前提（すべて明示します）

計算

1回あたりのクラウドLLM費用は、入力 4,000×$1÷1,000,000 ＝ $0.004 と、出力 500×$5÷1,000,000 ＝ $0.0025 を足して、$0.0065（約1円）です。月40,000回なら $260（約39,000円）にしかなりません。

一方、GPUを1基、月間フルに動かし続けると $2.6990×24時間×30日 ＝ $1,943.28（約29万円）です。ここから逆転点が出ます。

$1,943.28 ÷ $0.0065 ＝ 月およそ299,000回

つまり、月30万回近く問い合わせて、ようやくGPU 1基を借り続けるコストと並びます。 社員100人に割り戻すと、1人あたり1営業日150回です。これは業務として現実的な水準ではありません。先ほどの想定利用量（月40,000回）は、逆転点の7分の1程度にすぎません。

この計算から読み取るべきこと

第一に、コスト削減はローカルLLMを正当化する理由になりにくいということです。逆転するのは、社内の問い合わせ用途ではなく、大量のバッチ処理（数百万件の文書分類、全文の自動タグ付けなど）を継続的に回す場合です。自社の用途がそちらでないなら、費用面ではクラウドが有利なままです。

第二に、この試算はローカル側に有利すぎるという点です。上の$1,943（約29万円）は借りたGPUの利用料だけで、後述する運用人件費・冗長化・モデル更新の工数を一切含んでいません。自社でハードウェアを購入する場合は調達費と電力・空調も乗ります。実際の逆転点は月30万回よりさらに高くなります。

なお、条件1（外部に送信できないデータ）や条件3（ネットワーク非接続）が理由でローカルを検討している場合、本番運用では借りる構成が要件を満たしません。比較対象は購入構成になり、金額は次章の総保有コスト（TCO）で扱います。条件2は制約の内容によります。国内保管や国外移転の制限が要件であれば国内リージョンのクラウドGPUで足りることもありますが、再委託先の制限が理由であればリージョンの選択では解決しません。契約・業法・業界の自主規制・仕様書の文言で判断してください。なおPoC段階はいずれの条件でも別です。 検証はダミーデータや匿名化データで代替できることが多く、その場合は借りたGPUで足ります（「GPUは買うのか、借りるのか」で扱います）。

第三に、モデルの選び方でクラウド側はさらに安くなることです。上の試算は比較的安価なモデルを使っていますが、用途に応じてより小さいモデルを選ぶ、まとめて処理できる業務は非同期のバッチ処理に回す（クラウド事業者によっては半額程度になります）、同じ前提文を繰り返し送る場合はキャッシュ機能を使う、といった手段でさらに下げられます。ローカル側には、こうした料金メニューとしての打ち手がありません。単価を下げるにはモデルを軽量化する、小型モデルに置き換えるといった構成変更が要り、それ自体が検証工数を生みます。

したがって、費用を軸に議論するなら結論は明快です。ローカルLLMは安くするための手段ではありません。 「判断の出発点」で挙げた条件に当てはまるから選ぶのであって、その場合のコストは「制約を満たすために払う対価」として説明するのが、稟議では正確であり、かつ通りやすい説明です。

総保有コスト（TCO）：3年で出ていく7つの費目

前章の試算は、GPUを借りた場合の単純な比較でした。自社でハードウェアを持つ判断をする場合、見積書に出てくるGPU本体の金額だけを見ていると、3年後に想定の2倍近くかかっていた、という事態になります。費用の大半は初期投資ではなく、稼働してから毎月出ていくからです。

以下の7費目を順に見ます。1を除く6つは、当社が相談を受ける段階の見積もりで抜けていることが多いものです。

1. GPU本体と、それを載せるサーバー。 見積書の主役です。ここは各社見落としません。ただし後述するライセンスの章で触れるとおり、業務用のGPUと個人向けGPUではライセンス上の扱いが違うため、単純な価格比較は危険です。あわせて、ハードウェアの保守契約を何年分付けるかもここで決まります。故障時に何日で復旧するかは保守の等級で変わり、費目4の冗長化をどこまでやるかと表裏の関係にあります。

2. 電力。 そして、見積書にはまず載りません。GPUサーバーは24時間動き続けます。仮にGPUと筐体を合わせて700W（あくまで試算用の想定値です）とすると、0.7kW × 24時間 × 365日 ＝ 年間6,132kWh。公益社団法人全国家庭電気製品公正取引協議会が示す電力料金の目安単価31円／kWh（税込。令和4年7月22日改定、2026年9月2日確認）で換算すると年間約19万円です。なおこの目安単価は家庭用の指標であり、法人の高圧契約では単価が変わります。実際の金額は自社の契約で確認してください。重要なのは金額の精度ではなく、この費目が見積書に1行も無いことが多いという点です。

3. 空調と設置環境。 GPUサーバーが消費した電力はほぼ全部が熱になります。既存のサーバールームに余裕がなければ、空調の増強かラックの追加が必要です。事務室の隅に置いて済ませようとして、夏場に熱で落ちるというのは実際に起きます。

4. 冗長化と予備機。 ここが最も影響の大きい費目です。GPUが1基しかない構成は、そのGPUが故障した瞬間に業務が止まります。クラウドLLMならクラウド事業者が可用性を担保しますが、自社環境では自社の責任です。業務に組み込むなら実質的にGPUは2基以上必要になり、ハードウェア費用は単純に倍になります。「PoCでは1基で足りた」からといって本番も1基で足りるわけではない、というのは見積もりの段階で伝えておくべき点です。

5. 運用人件費。 モデルの起動監視、ディスク容量の管理、障害時の一次対応、利用状況の把握。専任である必要はありませんが、担当が決まっていないと誰もやりません。仮に情シス担当者の工数を月10%分使うとしても、年間では相応の金額になります。この費目を「既存メンバーでやる」として金額ゼロで見積もると、後で必ず破綻します。

6. モデル更新と、そのたびの再評価。 クラウドとの差が時間とともに開くのは、この費目です。オープンウェイトのモデルは数か月単位で新版が出ます。更新するかどうかを判断し、更新するなら自社の業務データで出力品質を再検証し、劣化していないことを確認してから切り替える必要があります。クラウドLLMではクラウド事業者がモデルの改善を続けますが、ローカルでは更新しない限り性能は公開時点のまま止まります。1年放置すれば、その1年分だけ競合との差が開く、ということです。この継続的な評価・監視をどう仕組み化するかはLLMOps実践ガイドで扱っています。

7. 陳腐化と入れ替え。 GPUは3〜5年で世代交代します。購入した資産は償却が終わる前に性能面で見劣りし始めます。3年後に同じ判断をもう一度することになる、という前提で初期投資額を決める必要があります。

3年で見るときのチェック表

稟議に出す前に、次の表が全部埋まっているかを確認してください。空欄がある見積もりは、その分だけ後から出てきます。

「ローカルなら安全」は成り立たない：オンプレミスでも残る6つのリスク

ローカルLLM導入の動機はほぼ必ずセキュリティです。ところが、環境を自社に移しても消えないリスクが相当量残ります。ここを説明せずに稟議を通すと、後で「安全だと聞いていた」という話になります。以下の6つは、導入判断の段階で経営層に伝えておくべきものです。

リスク1: プロンプト経由の情報流出は、ローカルでも起きる

ローカルLLMが防ぐのは「入力が外部の事業者に送信されること」だけです。社内の誰かが、権限のない情報をAI経由で引き出してしまう経路は塞がれません。 たとえば人事評価の文書を取り込んだ社内RAGに、一般社員が「自分の評価はどう書かれているか」と尋ねれば答えてしまいます。外部に出ていないというだけで、社内での不適切な閲覧は成立します。さらに、取り込んだ文書自体に悪意ある指示が埋め込まれていた場合、AIがそれを命令として実行してしまう攻撃（プロンプトインジェクション）は、環境がどこにあっても成立します。この攻撃の仕組みと対策はAIプロンプトインジェクション対策で詳しく扱っています。

リスク2: モデルと推論基盤そのものが、供給網のリスクを持つ

公開されているモデルファイルや実行ツールは、外部から取得して自社環境に持ち込むものです。取得元が正規かどうか、改ざんされていないか、実行ツールに既知の脆弱性がないかは、自社で確認し続ける必要があります。クラウドLLMではクラウド事業者が担っていた部分が、そのまま自社の宿題になります。「外部と通信しないから安全」ではなく、「最初にモデルを外部から持ち込んでいる」という事実を見落とさないでください。

リスク3: ログとプロンプト履歴の管理が、新しい機密の塊になる

ローカルLLMを業務で使うと、誰が何を尋ねたかの履歴が自社サーバーに蓄積します。この履歴には、元の文書以上に機微な情報が含まれることがあります。保存期間、アクセス権限、削除手順を決めていないと、情報を守るために作った仕組みが、新しい漏えい対象を生むことになります。運用ルールの整備は生成AI利用ガイドラインの作り方を参照してください。

リスク4: RAGの権限設計を誤ると、横断参照事故が起きる

社内文書をまとめて検索対象にすると、部署をまたいだ情報が1つの回答に混ざります。「経理部の資料は経理部だけが見られる」という既存のアクセス制御は、文書を1か所に集めた時点で無効になりがちです。元の権限体系をRAG側でどう再現するかは設計の問題であり、ローカルにしたから解決するものではありません。 設計の考え方はRAG構築ガイドで整理しています。

リスク5: 出力の誤りに対する責任が、完全に自社に残る

代表的なオープンウェイトモデルのライセンスには、無保証と責任制限が明記されています。クラウドLLMであればクラウド事業者との契約条件のなかで議論できますが、自社で動かしているモデルの出力が原因で損害が出ても、契約上の受け皿は期待できません。 これは技術的なリスクではなく、契約上のリスクです。具体的な条項は「商用ライセンス」の章で扱います。

リスク6: 法律上の義務は、環境を移しても軽くならない

ローカル化で消えるのは「外部の事業者にデータを渡すこと」に紐づく論点だけです。個人情報保護法上の安全管理措置、業種によっては業法上の記録・保存義務、顧客との秘密保持契約の遵守は、環境がどこにあっても残ります。しかもクラウドではクラウド事業者側が担っていた基盤レベルの暗号化・アクセス制御・監査ログの実装まで自社の作業になるため、これらの義務の量は変わらないまま、それを果たすための作業量だけが増えます。条文で確認する場合は、次章「法務とガバナンス」で個人情報保護委員会のFAQを引いています。

法務とガバナンス：ローカル化で自社が背負う役割が増える

導入判断の会議で法務・監査部門から出る論点を、あらかじめ整理しておきます。ここを詰めずに進めると、稟議の最終段階で差し戻されます。

「クラウドだから個人情報保護法に触れる」は正確ではない

まず前提の誤りを正しておきます。クラウドLLMを使うこと自体が、ただちに個人情報の第三者提供にあたるわけではありません。個人情報保護委員会のFAQ Q7-53（2026年9月2日確認）は、判断基準を次のように示しています。第三者提供や委託に該当するかどうかは「保存している電子データに個人データが含まれているかどうかではなく、クラウドサービスを提供する事業者において個人データを取り扱うこととなっているのかどうかが判断の基準となります」。そして、当該クラウド事業者が当該個人データを取り扱わないこととなっている場合には「個人データを提供したことにはならないため、『本人の同意』を得る必要はありません」としています。

その要件についても具体的に触れられており、「契約条項によって当該外部事業者がサーバに保存された個人データを取り扱わない旨が定められており、適切にアクセス制御を行っている場合等」が挙げられています。つまり契約と権限設計の問題であって、クラウドという形態そのものが否定されているわけではありません。

一方で、同委員会のFAQ Q7-54（2026年9月2日確認）は、その裏側を明示しています。クラウドサービスの利用が法第27条の「提供」に該当しない場合、法第25条に基づく委託先の監督義務は課されないものの、「クラウドサービスを利用する事業者は、自ら果たすべき安全管理措置の一環として、適切な安全管理措置を講じる必要があります」。ここで求められている安全管理措置は、環境をオンプレミスに移したからといって不要になるものではなく、むしろ自社が全面的に担う対象になります。

この2つのFAQを並べると構図がはっきりします。クラウドだから違法になるのでもなく、オンプレミスだから義務が消えるのでもありません。 法令を根拠にローカルLLMを選ぶなら、根拠にできるのは個人情報保護法一般ではなく、業法・契約・自社ポリシーの具体的な条項です。

AI事業者ガイドラインでは、自社の「役割」が変わりうる

総務省と経済産業省は「AI事業者ガイドライン（第1.2版）」を2026年3月31日に公表しています（2026年9月2日確認）。これは細かな行為義務を課す規制ではなく、非拘束的なソフトローとして自主的な取組を促す枠組みです。背景として、「人工知能関連技術の研究開発及び活用の推進に関する法律」（令和7年法律第53号）が2025年6月に公布、同年9月に全面施行されたことが同ガイドラインに記されています。

このガイドラインは、AIに関わる主体をAI開発者・AI提供者・AI利用者の3つに分けて、それぞれに期待される事項を示しています。同ガイドラインは、これらの主体について「事業者（又は各者内の部門）を想定しており、AIの活用方法によっては同一の事業者が…複数を兼ねる場合もある」としています。ここが導入判断に直結します。

自社が「AI提供者」に当たるかどうかを分けるのは、クラウドかローカルかではありません。 同ガイドラインの定義では、AI提供者とは「AIシステムをアプリケーション、製品、既存のシステム、ビジネスプロセス等に組み込んだサービスとしてAI利用者、場合によっては業務外利用者に提供する事業者」です。先に引いた「同一の事業者が…複数を兼ねる場合もある」との整理に照らせば、クラウドLLMのAPIの上に社内向けチャットボットを内製して各部門へ提供している会社も、提供者を兼ねると読めます。ここを「ローカルにすると提供者になる」と理解すると、判断を誤ります。

そのうえで、ローカル化は提供者としての負担を実質的に重くします。 ガイドラインが提供者に挙げている事項には、利用者への適正利用の注意喚起、AIシステムの動作状況・不具合の原因・対応状況やインシデント事例の情報提供、システムを更新した場合の更新内容とその理由の情報提供、サービス規約やプライバシーポリシーの文書化などが含まれます。クラウドLLMを使っている限り、モデル自体の品質改善と脆弱性対応はクラウド事業者側で行われ、自社はその結果を社内へ伝え、移行時期を決める立場にとどまります。ところが自社でモデルを動かすと、更新するかどうかの判断も、更新後に品質が落ちていないかの検証も、脆弱性への対応も自社の作業になります。さらにモデルに追加学習を施せば、モデルの学習・検証を担う「AI開発者」としての事項も視野に入ります。

つまり、ローカル化で変わるのは役割の名前ではなく、その役割を果たすために実際に必要な作業量です。この作業量の増加は、「総保有コスト（TCO）」で挙げた「運用人件費」「モデル更新と再評価」の中身そのものです。

なお同ガイドラインは、こうした取組を進めるうえで経営層の責任が大きく、リーダーシップの発揮が重要であるとし、AIガバナンスの構築を単なるコストではなく、中長期的な発展を志向した先行投資として捉えるよう促しています。ローカルLLMの導入を情シス部門の技術案件として扱うと、この視点が抜け落ちます。全社的なAIガバナンスの組み立て方はAIガバナンス体制の作り方で扱っています。

また、経済産業省の同ガイドライン掲載ページでは、本編とは別に「チェックリスト（別添7）」「ワークシート（別添7）」が公開されています（2026年9月2日確認）。自社の体制を点検する出発点として、まずこれを埋めてみるのが現実的です。

商用ライセンスは「使えるか」ではなく「どう使うか」で変わる

「このモデルは商用利用できますか」という問いは、実務では答えが1つに定まりません。同じモデルでも、使い方によって発生する義務が変わるからです。モデルごとのライセンス種別の一覧はローカルLLMおすすめ比較にまとめてあるため、ここでは法務レビューに出す前に自社で整理しておくべき観点を扱います。

まず、自社の利用形態を4つに切り分ける

法務に相談する前に、次のどれに当たるかを確定させてください。ここが曖昧なまま相談すると、法務はいちばん厳しい前提で回答せざるを得ず、話が止まります。

多くの企業の導入検討はAです。Aであれば論点はかなり少なくなります。にもかかわらず、CやDを前提にした議論をして止まっている、というケースをよく見かけます。

Llama系を例に、具体的に何が求められるか

代表例として、Meta社のLlama 3.3のコミュニティライセンス（Meta公式サイトで公開されているLlama 3.3コミュニティライセンス。2026年9月2日に条文を確認）を見ておきます。よく知られているのは「月間アクティブユーザー7億以下なら商用利用可」という点ですが、条文を読むと実務上重要なのはむしろ他の部分です。

• 利用規模の条件には判定時点がある。 「月間アクティブユーザー7億人超」は常時監視を求める条項ではありません。Llama 3.3の公開日（条文冒頭に「December 6, 2024」と明記）時点で、ライセンシーもしくはその関連会社が提供する、またはそれらのために提供される製品・サービスの、前暦月の月間アクティブユーザーが7億人を超えていた場合に、Metaへ別途ライセンスを求める必要があり、許諾されるまでは本契約上の権利を行使できない、という構成です。大半の日本企業には無関係であり、ここで議論を止める必要はありません。
• 配布または提供する場合は表示義務がある。 条文は2つの義務を分けています。ひとつは、Llama素材（その派生物、またはそれらを含む製品・サービス）を渡す場合にライセンスの写しを添えること。もうひとつは、関連するウェブサイト・ユーザーインターフェース・ブログ・about ページ・製品ドキュメントのいずれかに「Built with Llama」を目立つように表示することです。後者は「配布または提供（make available）」に係るため、モデル自体を配布しない外部提供でも及びうる点に注意してください。
• 派生モデルには命名の条件がある。 Llama素材やその出力を使って別のAIモデルを作成・学習・追加学習（ファインチューニング）し、それを配布・提供する場合、そのモデル名の先頭に「Llama」を含めることが求められます。自社ブランドの製品名を付けようとしていた場合、ここで設計変更が必要になります。
• 通知文の保持義務がある。 配布するすべての複製物に、所定の帰属表示を「Notice」テキストファイルとして含めて保持することが求められます。
• 利用ポリシーが参照により組み込まれている。 別途定められた Acceptable Use Policy が、参照によってライセンス契約に取り込まれています。ライセンス本文だけを読んで判断すると、この部分を見落とします。

Llama 3.3コミュニティライセンスで稟議に効く4つの論点：無保証・責任制限・補償義務・契約終了

そして、経営判断として重いのが次の4つの論点です。いずれもLlama 3.3コミュニティライセンスの条文に明記されています。

無保証（第3条）: Llama素材およびそこから得られる出力・結果が「AS IS」で提供され、権原・非侵害・商品性・特定目的適合性を含むいかなる保証も否認されること、そしてその適切性の判断と使用に伴うリスクの負担は利用者側にあることが定められています。ただし条文は「UNLESS REQUIRED BY APPLICABLE LAW（適用される法令が要求する場合を除き）」という留保から始まっており、強行法規まで排除するものではありません。

責任制限（第4条）: Metaおよびその関連会社が、逸失利益および間接損害・特別損害・結果的損害・付随的損害・懲罰的損害等について責任を負わないことが定められています。責任制限の対象がこれらに限定されている点は、法務レビューで正確に伝えてください。

第三者請求への補償義務と、訴訟提起によるライセンス終了（第5条c項）: これが日本企業の稟議で最も見落とされる条項です。前段では、Llama素材やその出力が、自社が保有またはライセンスしうる知的財産権その他の権利を侵害するとして、Metaまたは他の主体に対して訴訟その他の手続を提起した場合（訴訟内での反訴・交差請求を含む）、その提訴日をもって本契約上のライセンスが終了すると定められています。知的財産部門を持つ企業では、補償義務と並んで確認しておきたい条項です。そして後段が補償義務にあたります。利用者側が、Llama素材の使用・配布に起因または関連する第三者からの請求について、Metaを補償し免責することが定められています。つまり自社が守られる側ではなく、守る側に立ちます。

契約終了と準拠法（第6条・第7条）: 利用者が条件に違反した場合、Metaは本契約を終了できます。そして本契約が終了した場合、利用者はLlama素材を削除し使用を停止しなければなりません。なお前項のとおり、契約の終了とは別に、訴訟提起によってライセンスだけが終了する経路もあります。しかも無保証・責任制限・準拠法の各条項は終了後も存続し、準拠法はカリフォルニア州法、専属管轄は同州の裁判所です。使えなくなった後も、無保証・責任制限と米国での管轄だけが残る、という構成です。

これが実務上意味するのは単純です。出力の誤りによる損害は、モデル提供者に対しては契約上転嫁できません。 無保証（第3条）で品質の保証がなく、責任制限（第4条）で賠償の範囲も絞られているためです。 クラウドLLMを事業者との契約のもとで使う場合、サービスレベルや責任分担は契約書で議論できます。Llamaのようなコミュニティライセンスのモデルを自社で動かす場合、条件を交渉する余地がなく、争うとしても管轄は米国です。

したがって稟議には、「無保証のソフトウェアを業務基幹に組み込む」という前提を明記し、出力の誤りを人間が検証する工程を業務フローのどこに置くかをセットで示す必要があります。この一文があるかどうかで、監査部門の反応は大きく変わります。

ハードウェア側にもライセンス条項がある

見落とされやすい論点をもう1つ挙げます。コストを抑えるために個人向けの高性能GPUをサーバーに載せる構成が検討されることがありますが、NVIDIAのGeForceソフトウェアライセンス第8項には次の条項があります（2026年9月2日に公式ページで確認）。

You agree that GeForce or Titan SOFTWARE: (i) is licensed for use only on GeForce or Titan hardware products you own, and (ii) is not licensed for datacenter deployment.

GeForceおよびTitanのソフトウェアは、自社が所有するGeForce／Titanハードウェア上での使用に限ってライセンスされ、データセンターへの配備にはライセンスされていないという趣旨です。ここで注意すべき点が3つあります。制限の対象がハードウェアそのものではなくソフトウェア（ドライバ）であること、「データセンター配備」の範囲がこの条項では定義されていないこと、そして「you own」とあるためリースやレンタルのGPUでは別途確認が要ることです。自社サーバールームでの業務利用がこれに当たるかは、条項の文面だけでは判断できません。

したがって本記事としては「違法だ」とも「問題ない」とも申し上げません。申し上げるべきは、この条項の存在を知らずに調達を決めてはいけないということです。個人向けGPUでの構成を検討している場合は、想定する設置形態と用途を明示したうえで法務またはNVIDIAの販売パートナーに確認してください。データセンター向け製品を選べばこの論点自体が発生しません。価格差だけで比較すると、この確認コストが見えなくなります。

体制：役割が埋まらない導入は必ず止まる

ローカルLLMの導入が頓挫する原因は、精度不足よりも体制の穴であることのほうが多い、というのが実務での実感です。PoCは情シスの担当者が1人で回せてしまうため、体制の問題は本番直前まで表面化しません。

必要になる5つの役割

専任5名が必要という意味ではありません。兼務でよいので、名前が入っているかを確認してください。空欄の役割は、誰もやらないという意味です。

このうちとりわけ抜けやすいのがモデル評価担当です。インフラ運用は情シスが自然に担いますが、「新しいモデルが出たとき、自社の業務で本当に良くなったかを測る」仕事は担当が決まりません。結果として、導入時に選んだモデルが何年もそのまま使われます。「総保有コスト（TCO）」で挙げた費目6のとおり、これはクラウドLLMとの差が時間とともに開いていくことを意味します。

内製化は「最初から」ではなく「順番に」

内製化を目標に置くのは正しい方向ですが、最初から全部を自社でやろうとすると立ち上がりません。実務では次の順序が現実的です。

1. 使い方を内製化する。 どの業務にどう使うかを自社で決められる状態にする。ここが最も価値が高く、最も外注しにくい部分です
2. データ整備を内製化する。 RAGに入れる文書の選定・更新・権限設定を自社で回せるようにする。業務理解が必要なため、外部に任せ続けると品質が上がりません
3. 運用監視を内製化する。 稼働監視と一次対応を自社に移す
4. 基盤（インフラ）の構築・更新を内製化する。 最後です。頻度が低く専門性が高いため、ここは外部と組み続ける判断も十分に合理的です

この4つの順序は、先の5役割と一部が対応します。順序1・2が業務オーナーとデータ管理者、順序3がインフラ運用に当たります。順序4に対応する役割は、5つのなかにありません。 外部に任せても成立しやすいのは順序3・4、任せると品質が上がらないのは順序1・2です。残るモデル評価担当とガバナンス担当は、どの順序にも乗らない横断役割で、だからこそ担当が決まらないまま放置されます。

多くの企業は逆順、つまり「まず基盤を自社で作る」から始めようとして、1と2が空白のまま止まります。基盤があっても使い方が決まっていなければ、稼働率の低いGPUが残るだけです。

GPUは買うのか、借りるのか

ここからは進め方です。まず調達から扱います。

必要VRAM（モデルを載せるのに要るGPU側のメモリ量で、機械の値段をほぼ直接決めます）の規模別の目安はローカルLLMおすすめ比較にまとめています。ここでは調達の意思決定に絞ります。

いきなり購入を検討するケースが多いのですが、調達の選択肢は「借りる」「買う」の2つしかありません。

借りる（クラウドGPU） は、検証段階では圧倒的に有利です。費用試算で用いたGPU構成（GPUメモリ48GB・1基）をオンデマンドで借りる場合、1日8時間だけ検証に使えば月$648（約9.7万円）で、しかも使わない月はゼロにできます。なお費用試算は月20営業日を基準にしていますが、この$648は1日8時間×月30日で計算した値です。検証を営業日だけに限れば月$432（約6.5万円）まで下がります。購入すると、使えないと分かった後もGPUの償却だけが続きます。 「外部に出せないデータ」が理由の場合でも、PoC段階ではダミーデータや匿名化したデータで検証できることが多く、その間はクラウドGPUで十分です。

買う（オンプレミス） は、条件が確定してから選ぶものです。データを物理的に自社の外へ出せないことが契約や業法で確定していて、かつ利用が定常的に見込める場合に初めて経済的な合理性が出ます。

なお、買うか借りるかを決める前に効くのが、「全部をローカルにしない」の章で扱った処理の分け方です。そこで分けた処理量が、そのまま調達規模を決めます。台数と機種は、ローカルに残す処理量を決めてから逆算してください。

調達リードタイムを工程表に入れる

GPUサーバーは発注してすぐ届くとは限りません。構成によっては数週間から数か月かかります。「4月から使い始める」という計画を立てる場合、逆算して調達の意思決定がいつまでに必要かを工程表に入れておかないと、プロジェクトの遅延がすべて調達待ちで説明されることになります。クラウドGPUなら即日使えるという差は、スケジュールリスクの観点でも大きい要素です。

PoCから本番へ：各段階で「進んでよい」と判断する基準

段階を踏むこと自体は広く知られていますが、実務で効くのは次に進んでよいかを判定する基準を先に決めておくことです。基準がないPoCは「まあ動いたので本番へ」となり、本番で問題が噴出します。逆に、撤退の基準を決めていないPoCは終わりません。 生成AIのPoC設計の一般論は生成AIのPoC支援でも扱っています。

段階0: 要件確定（着手の可否）

• 「判断の出発点」の4条件のうち、どれに当てはまるかが文書で特定できている
• AIに入力するデータの範囲が、業務単位で棚卸しされている
• 「クラウドでは駄目な理由」が、契約書・業法・自社ポリシーの条項として示せる

進んではいけない合図: 「機密情報があるから」以上の説明ができない状態。この段階で止めれば、費用はほとんどかかりません。

段階1: PoC（限定検証）

目的は「安く早く、使えないと分かること」です。成功を証明する場ではありません。

• 対象業務を1つに絞る。複数を同時に検証すると原因が切り分けられません
• 文書は限定範囲。全社文書を入れないでください
• 環境は借りたGPUで構いません。この段階で購入しない
• 評価は事前に決めた基準で行う。 「なんとなく良さそう」は評価ではありません

進んでよい基準の例:

• 対象業務で、人が確認する前提の出力品質に達している
• 同じ入力を候補のローカルモデルとクラウドLLMの両方に通し、自社の担当者が出力を見比べた。 この工程は1日で終わり、判断の精度が大きく上がります。差が小さければローカルで問題ありませんし、差が大きければ、その差を許容してでもローカルにする理由があるのかを議論できます
• 現場の担当者が「これなら使う」と言っている
• 想定した処理時間に収まっている

撤退してよい基準の例: 出力の確認にかかる時間が、元の作業時間を上回る／必要な文書が電子化されておらず整備コストが投資額を超える／現場が使う動機を持たない。ここで撤退することは失敗ではなく、いちばん安く得られた結論です。

段階2: 本番設計

• 同時利用者数と処理量の実測値が出ている（PoCの利用ログから）
• 冗長構成の要否を決めている。1基構成で止まったときの業務影響が許容できるか
• ログの保存期間・アクセス権限・削除手順を決めている
• 障害時の連絡経路と一次対応者が決まっている
• 「体制」の章の5役割に名前が入っている
• ハードウェアを購入する場合、調達リードタイムを工程表に織り込んでいる

進んではいけない合図: 運用担当が決まっていない。ここが空欄のまま本番稼働すると、数か月後に誰も面倒を見ていない状態になります。

段階3: 運用と改善

• 利用状況を定期的に見ている（使われていない機能は畳む）
• モデル更新の要否を判断する頻度と担当が決まっている
• 出力品質の劣化に気づく仕組みがある

この段階で初めて、内製化の範囲を広げる判断ができます。

ローカルLLM導入でよくある失敗パターン

当社が相談を受ける段階で、すでに発生していることの多いものを挙げます。いずれも技術ではなく意思決定の問題です。

1. 目的が「ローカルLLMを導入すること」になっている。 経営から「AIで何かやれ」と言われ、セキュリティ部門が「クラウドは駄目」と言い、結果として手段が目的化します。この場合、稼働はしても効果が測れません。必ず「どの業務の、どの作業を、どれだけ減らすか」を先に決めてください。

2. クラウドLLMとの品質差を、自社の業務データで測らないまま決める。 一般的なベンチマークの順位や記事の評価だけを見て採用を決めると、自社の文書との相性という、最終的な使い勝手を決める要素が検証されません。「PoCから本番へ」の段階1に挙げた「同じ入力を両方に通して見比べる」工程を飛ばすと、稼働後に「クラウドのほうが賢い」という声が現場から上がり、せっかくの投資が使われなくなります。

3. 導入後の担当を決めずに終わる。 構築ベンダーが去った後、モデルも文書も更新されなくなり、半年後には「精度が落ちた」という声が上がります。ところが実際にはモデルが古いのではなく、参照している文書が古いことがほとんどです。原因はモデルの劣化ではなく、データ管理者の不在です。「体制」の章の5役割のうち、この1つが空欄だっただけで起きます。

このほか、本記事で各章に書いた次の3点も、そのまま失敗パターンです。詳細は該当章をご覧ください。

ベンダーへ送る10の確認質問

見積もりを取る際、次の質問への回答を求めてください。回答の具体性で力量が分かります。

1. 提示のGPU構成が故障した場合、業務はどれくらい止まりますか。予備機は見積もりに含まれていますか
2. 電力と空調の増強費用は、この見積もりに含まれていますか。含まれない場合、想定額はいくらですか
3. モデルの新版が出た場合、更新作業は保守範囲に含まれますか。含まれる場合、年何回までですか
4. 更新後に出力品質が落ちていないことは、誰がどう検証しますか
5. 採用するモデルのライセンス種別と、当社の利用形態（社内利用のみ／外部提供）で発生する義務を書面でご提示ください
6. 提案のGPUは、当社の設置形態でライセンス上の制約がありませんか
7. RAGに取り込む文書の権限は、既存のアクセス制御をどう反映しますか
8. 利用ログの保存場所・保存期間・アクセス権限はどうなりますか
9. 稼働後の監視は、どこまでが御社の範囲で、どこからが当社の作業ですか
10. 契約終了後、モデルとデータは当社の環境に残りますか。運用を引き継ぐために必要な資料は何ですか

10番目は特に重要です。内製化を目標に置くなら、引き継ぎ可能な形で作られているかを最初に確認してください。 後から要求しても、そのように作られていなければ応えられません。ベンダー選定全般の観点はRAG開発の外注先選びでも整理しています。

導入判断チェックリスト（そのまま稟議資料に転用できます）

ここまでの内容を、意思決定の前に確認できる形にまとめます。空欄が残る項目は、そこが後で問題になる箇所です。埋まらない項目があれば、該当する章に戻って論点を確認してください。

このA〜Eは、そのまま稟議書の構成に使えます。冒頭の4つの問いはA（必要性）・B（費用）・C（リスク）・D（体制）に対応し、Eが進め方です。このうち稟議で真っ先に問われるのはAとC——なぜクラウドでは駄目なのかと、それでも安全にならない範囲です。Cを書くと通りにくくなると思われがちですが、実際は逆で、リスクと撤退条件が書かれている稟議のほうが、意思決定者にとっては承認しやすいという傾向があります。

A. 必要性の確認（ここが最重要）

• AIに入力するデータを、業務単位で棚卸しした
• 「外部に出せないデータを、実際にAIへ入力する必要がある」と言い切れる業務を特定した
• クラウドが使えない根拠を、契約条項・業法・自社ポリシーのいずれかで示せる
• クラウドLLM側の利用規約と、入力データの学習利用に関する設定を確認した
• 匿名化・仮名化でクラウド利用に切り替えられないかを検討した
• ローカルが必須な範囲と、そうでない範囲を分けた

B. 費用（3年で見る）

• クラウドLLMを使った場合の月額を、自社の想定利用量で試算した
• ローカル構成の費用を3年総額で出した
• 電力・空調の費用が見積もりに含まれている
• 冗長構成（予備機）の費用が含まれている
• 運用担当の工数を金額に換算して含めた
• モデル更新と再評価の工数を含めた
• 3年後の入れ替え原資を織り込んだ

C. リスクと法務

• 「ローカルにしても残るリスク」を経営層に説明した
• RAGに取り込む文書の権限設計を決めた（既存のアクセス制御をどう反映するか）
• 利用ログの保存場所・保存期間・アクセス権限・削除手順を決めた
• 採用候補モデルのライセンスを、自社の利用形態（社内利用のみ／外部提供／再配布／派生モデル配布）と突き合わせた
• 無保証・責任制限（および採用ライセンスに補償義務がある場合はそれも）を前提に、人が出力を検証する工程を業務フローに組み込んだ
• 調達予定のGPUに、設置形態上のライセンス制約がないか確認した
• AI事業者ガイドラインで自社がどの主体に当たるかを整理した

D. 体制

• 業務オーナーが決まっている
• データ管理者が決まっている
• インフラ運用の一次対応者が決まっている
• モデル評価の担当と、評価の頻度が決まっている
• ガバナンス担当と相談窓口が決まっている
• 障害時に業務が止まる時間の許容範囲を、業務側と合意した

E. 進め方

• PoCの対象業務を1つに絞った
• 同じ入力を候補のローカルモデルとクラウドLLMの両方に通し、自社の担当者が出力を見比べた
• PoCの「進んでよい基準」を文書化した
• PoCの「撤退してよい基準」を文書化した
• PoC段階ではハードウェアを購入しない方針を確認した
• 調達リードタイムを工程表に織り込んだ
• 契約終了後の引き継ぎ範囲をベンダーと合意した

A項目が埋まらないまま B以降を進めないでください。 必要性が特定できていない状態で費用と体制の議論を始めると、「導入すること」自体が目的化します。逆に、A項目が明確に埋まるのであれば、ローカルLLMは自社にとって正しい投資です。

よくある質問（FAQ）

まとめ：ローカルLLMは「責任を引き取る」意思決定

本記事の要点をあらためて整理します。

ローカルLLMを選ぶ合理的な理由は、外部に出せないデータを実際にAIへ入力する必要があるかどうかに集約されます。コスト削減は理由になりにくく、公式価格で計算すると多くの企業規模ではクラウドLLMのほうが安いままです。そして環境を自社に移しても、安全になるわけではありません。安全にする義務が自社に移るだけです。AI事業者ガイドラインの整理で言えば、AIを組み込んだサービスとして社内に提供する時点で自社は「AI提供者」を兼ねると読めますが、ローカルではモデルの更新判断・品質検証・脆弱性対応まで自社の作業になるため、果たすべき負担が実際に重くなります。

加えて、代表的なオープンウェイトモデルのライセンスには無保証と責任制限が、採用するライセンスによっては第三者請求への補償義務が付いてきます。出力を人が検証する工程を業務フローのどこに置くかを、稟議と同時に決めてください。

この構造を理解したうえで、それでも必要だという結論になるなら、ローカルLLMは正しい選択です。その場合に守るべき順序は明快です。要件を文書で確定させ、借りたGPUで小さく検証し、撤退条件を持って進み、5つの役割に名前を入れてから本番へ移す。 GPUを買うのは最後です。

そして、費用の議論を始める前に一度確認してほしいことがあります。AIに入力したいデータを業務単位で棚卸しすると、本当にローカルが必要な範囲は想定よりずっと狭いことがほとんどです。 その場合、機密性の高い一部の処理だけを自社環境に置き、残りはクラウドLLMに任せる構成のほうが、総額は下がり、品質は上がり、運用負担も軽くなります。

関連として、モデルとツールの実名比較はローカルLLMおすすめ比較｜日本語・費用・選び方、小型モデルを業務に組み込む観点は小規模言語モデル（SLM）業務活用ガイド、社内データの活用設計は社内データを活用したAI導入の進め方にまとめています。要件整理・PoC設計・体制づくりのご相談は無料相談はこちらから、支援内容は/servicesをご覧ください。