「機密情報を扱うので、クラウドの生成AIは使えない」

そう考えてオフライン生成AI（ローカルLLM）を調べ始めると、200万円前後から数千万円という金額が並びます。決して小さい買い物ではありません。ただ、その前に確かめておきたいことがあります。そもそも、自社は本当にオフラインである必要があるのか、という点です。

本記事では公開ベンチマークと公表価格をそのまま並べたうえで、それでもオフラインを選ぶ理由になる条件を整理します。読み終えたときに「うちはクラウドで十分だった」と分かるのであれば、この記事は役目を果たしたことになります。

結論：オフラインを選ぶ理由は2つだけ

それでもオフラインを検討すべきなのは、次の2つのどちらかが実際に存在する場合に限られます。

1. クラウドに出せない情報がある … 取引先との契約や社内規程で、外部のサーバーに送信してはいけないと定められた情報を、AIに扱わせたい
2. クラウドにつながらない環境がある … 工場や施設内など、セキュリティ方針でインターネットから切り離されたネットワークの中でAIを使いたい

逆に言えば、「なんとなく不安だから」という理由だけでは、オフラインを選ぶ根拠として弱いということです。その不安の多くは、クラウド側の設定と契約の確認で解消できる範囲にあります。

30秒診断：当てはまるものにチェックを入れてください

以下の4項目のうち、自社に当てはまるものを選んでください。チェックの数を目安に、下の3つの区分で判定します（4.だけは例外で、当てはまる場合は数に関係なくオフラインの本格検討です）。チェックは画面上で印を付けるためのもので、当サイトへの送信・記録は行いません。

※4.に当てはまる場合は、個数に関係なく【オフラインを本格検討】です。クラウド型は通信経路がないため使えません。

人数と年数は方式の判定には使いません。目安として、50人以上・3年以上の利用なら初期費用を回収しやすくなります（詳細は「費用」の回収表）。医療・金融・公共など規制のある業種は、所管ガイドラインの最新版もあわせて確認してください。

精度：社内に置けるAIは、クラウド最上位の半分

オフライン生成AI（ローカルLLM）とは、AIモデルのデータ本体を自社サーバーに置き、社内ネットワークの中だけで動かす形です。中身（重みと呼ばれるデータ）が公開された「オープンモデル」を使って構築するため、その精度は「今どんなオープンモデルが手に入るか」と「自社の機械にどのサイズまで載るか」の両方で決まります。

数字で見ると、差は縮んでいる

AIモデルの性能を横並びで比べる公開指標に、Artificial Analysis社の「Intelligence Index」があります。複数の試験問題セットの成績をまとめた総合スコアで、数字が大きいほど高性能です。

2026年8月15日時点で、クラウド最上位のClaude Opus 5（最上位設定）が63。これに対し、オープンモデルの最上位グループはKimi K3（Moonshot AI）とQwen3.8（Alibaba）で、Kimi K3のスコアは60。DeepSeek V4 ProやGLM-5.2がそれを追う構図です。クラウド最上位とオープン首位の差は、すでにこの程度まで縮まっています。

しかし「社内に置けるか」で話が変わります

問題は、これら上位のオープンモデルが、一般的な企業のサーバー1台にはまったく載らないという点です。首位のKimi K3はパラメータ数（AIモデルの規模を示す数値）が2兆8,000億。「量子化」というデータ圧縮を済ませた配布形態でも、データ本体だけで1.56テラバイトあります。一般的な企業が最初に導入する1台のサーバー構成で扱える量ではなく、「まず1台入れてみよう」と考えるクラスでは手が届きません。

社内サーバー1台に載るサイズの実力

Googleが2026年4月に公開した「Gemma 4 31B」は、パラメータ数307億のオープンモデル（Apache 2.0ライセンス）です。このクラスなら、GPUを積んだ1台のサーバーで動かせます。そのIntelligence Indexは30（じっくり考えてから答える「思考モード」での値）。クラウド最上位の63に対して、およそ半分です。同サイズ帯では優秀な部類であり（同じ規模のオープンモデルの中央値は9です）、それでも半分ということです。

この数字をどう受け取るべきか

ただし、スコアが半分だから業務が半分しかこなせない、という意味ではありません。社内文書を検索して要約する、議事録を整える、定型文を作るといった用途なら、スコア30でも実用になる、というのが弊社の見立てです。差がはっきり出るのは、複雑な調べもの、長文の論理的な組み立て、プログラミングといった領域です。

また、ベンチマークの順位は毎月のように入れ替わります（本記事のスコアは2026年8月15日時点）。ですから精度の判断は、公開スコアだけでなく自社の実際の業務データで試して確かめるしかありません。

実際に使うモデルはどう選んでいるか（弊社の現場から）

では、社内サーバーで実際に動かすモデルには何を選ぶのか。弊社が検証や提案の際にまず候補へ挙げることが多いのは、Googleの「Gemma」シリーズです。理由は3つあります。第一に、公式に「140以上の言語でネイティブに訓練」と明記されており、弊社でも日本語の社内文書向け用途で実用的に使えていること（体感ベースです）。第二に、OSI承認の標準的なオープンソースライセンスであるApache 2.0で公開されており、改変・商用利用がしやすいこと。第三に、小型モデルから31Bクラスまで複数のサイズが公式に用意されており、サーバーの規模に合わせて選べることです。Googleの公式発表（2026年4月のGemma 4公開時）では累計ダウンロードは4億回を超えており、事例やノウハウ・周辺ツールが集まりやすいことも実務では効きます。

オープンモデルの先駆けだったMetaの「Llama」は、弊社が把握する限り直近版は2025年4月のLlama 4にとどまっており（2026年8月時点）、最近の弊社の検証・情報収集の範囲では、選ぶ場面が減っています。なおMetaからは2026年8月に、エージェント用途向けをうたうオープンウェイトの新モデル「Muse Glimmer」（300億パラメータ・Apache 2.0）が公開されており、この「1台に載るクラス」の選択肢は今後も入れ替わりが続くとみられます。

なお、「社内文書を検索して要約する」用途で31Bクラスが実用になるのには、仕組み上の理由があります。この使い方（RAG＝検索拡張生成と呼ばれます）では、回答の材料は検索で取り出した社内文書の側にあり、AIモデルの役割は「渡された文書を読んで、まとめる」ことに絞られるためです。モデル自身の知識量や推論力が問われる調べもの型の使い方に比べて、モデル規模への要求は軽くなります。

ただし、モデルの賢さと「何人で快適に使えるか」は別の問題です。同時に使う人数や応答速度の要件によって必要なサーバー構成は変わりますし、同じ規模帯でも内部方式によって速度は大きく違います。そのため弊社では、導入プロジェクトの工程の一つとしてモデルの選定・検証を組み込み、お客様の実データで複数のモデルを比較してから決めています。開発元の国やライセンスが調達要件になる場合は、それらも選定条件に加えます。なお、ひとくちに「1台」と言っても、搭載するGPUによって価格には大きな幅があります。具体的な金額は、次の費用の章で見ていきます。

費用：50人・3年が損益の分かれ目

クラウド側の費用

Anthropic社のClaude Teamプランは、公式価格ページで「年払いで1席あたり月額20ドル、月払いなら25ドル」と表示されています（2026年8月14日確認）。Google Workspaceの日本向け公式価格ページでは、Business Standardが1ユーザーあたり月額1,600円、Business Plusが2,500円で、いずれもGeminiのAI機能が料金内に含まれます。初期費用はほぼゼロで、すぐに使い始められます。

オフライン側の費用

一方、オフライン生成AIは機械の購入から始まります。実際に公表されている価格は次のとおりです。

※いずれも各社発表時点の公表価格です。含まれる範囲（機器・構築・保守など）は各社で異なり、同一仕様での比較ではありません。最新の価格は各社にご確認ください。

どこで逆転するのかを計算してみます

クラウドの費用を仮に1人あたり月額3,000円（年間36,000円）と置いて、オフラインの初期費用を何人年で回収できるかを計算しました。

読み取れることは、20人規模でオフラインを費用面から正当化するのは、かなり難しいということ。最小構成でも約2.8年、500万円構成なら約7年かかります。

しかも、この計算はオフライン側に有利すぎます。（電気代・保守・人件費・ハードウェア更新などの運用費を含めていないため。クラウド側は月額料金の中で機能や性能の向上を受け取れます）

つまりコストは、オフラインを選ぶ理由ではなく、オフラインを選ばざるを得なくなったときに、その負担を受け入れられるかを確認する材料と考えるのが実態に合っています。

それでもオフラインが必要になる2つの条件

条件1：契約や社内規程で、外部送信が制限された情報がある

代表的なのがこのパターンです。

• 取引先とのNDA（秘密保持契約）で、「第三者のサーバーに保存・送信しない」と定められた図面や仕様書がある
• 発注元の情報セキュリティ基準で、外部クラウドサービスの利用に事前承認や監査が求められている
• 自社の情報管理規程で、特定区分の情報を社外システムで扱うことを禁じている

重要なのは、これは業界の一般論ではなく、会社ごと・契約ごとに異なるという点です。同じ製造業でも、A社は問題なくクラウドを使え、B社は取引先の基準で使えない、ということが普通に起こります。

ですから判断の第一歩は、AIの検討ではなく、自社の規程と主要な取引先との契約書を実際に読み返すことです。「制限されている情報が具体的に存在する」と確認できて初めて、オフラインが選択肢に入ります。

条件2：そもそもインターネットにつながらない環境で使う

クラウド型の生成AIは、事業者のサーバーと通信して動きます。したがって、セキュリティ方針で外部ネットワークから物理的に切り離された環境（閉域網・エアギャップ環境）では、そのままでは利用できません。 技術的な優劣ではなく、通信経路が存在しないという単純な事実です。工場の制御系ネットワークや、外部接続を遮断した施設内システムがこれにあたります。

補足：所管省庁のガイドラインは「禁止」ではなく「確認事項」を課すもの

ここは誤解が多いところなので、正確にお伝えします。個人情報保護委員会は、2023年6月2日付の「生成AIサービスの利用に関する注意喚起等」で、本人の同意なく個人データを含むプロンプトを入力し、それが回答の出力以外の目的で扱われる場合は個人情報保護法違反となる可能性があるとしたうえで、企業に対して次のように述べています。

（前略）このようなプロンプトの入力を行う場合には、当該生成AI サービスを提供する事業者が、当該個人データを機械学習に利用しないこと等を十分に確認すること。

つまりこれは「クラウド生成AIを使うな」という内容ではありません。 入力したデータが学習に使われないことを「十分に確認すること」を求めるものです。学習に利用しない条件はプランや設定によって異なるため、自社が契約するプランの規約に当たってください。

業種によっては所管省庁が別途ガイドラインを定めています（医療・金融・公共など）。該当する業種の方は最新版を必ず確認してください。

逆に、オフラインを選ぶ理由にならないもの

次の理由だけでオフラインを選ぶのは、費用に見合わない可能性が高いです。

• 「クラウドはなんとなく不安」 … 契約・設定・権限管理で対処可
• 「情報漏洩を絶対に防ぎたい」 … 内部からの持ち出しは残る
• 「コストを下げたい」 … 20人規模では回収に数年
• 「最新のAIを自社のものにしたい」 … 社内のモデルは自動更新されず

「機密情報は入力しない」ルールだけでは守りきれない

PagerDuty社の調査（日米英豪の大手企業勤務の非IT職1,250名・2026年4月）では、66%が、社内ルール上は許可されていないと認識しながら業務でAIツールを使ったことがあると回答。国内でもガートナージャパンの調査（2026年6月発表）で73%の企業がシャドーAIを管理できていない状態とされています。

第一の対処は「承認された、使ってよいAI環境を正式に用意すること」です。オフライン生成AIが効くのは、そのうえで残る「そもそもクラウドに出せない情報」の部分です。順序を逆にして、シャドーAI対策としていきなり数百万円の設備を入れると、コストに見合わない結果になりがちです。

現実解は「併用」：出せない情報だけを切り出す

切り分けの軸は「業務」ではなく「情報」

よくある失敗が、「営業部はクラウド、開発部はオフライン」といった部署単位の切り分けです。同じ部署でも外に出せる情報と出せない情報が混ざっているため、これはうまくいきません。正しい軸は情報の区分です。

ステップ1：情報を3つに分ける

ステップ2：AとBはクラウドに寄せる

Bは、法人向けプランで「入力データを学習に使わない」ことを契約・規約で確認したうえでクラウドを使う、という判断が成り立ちます。

ステップ3：Cの量を数える

Cに該当する業務が月にどれくらい発生しているかを実際に数えます。月に数件しかないなら、そもそもAI化の効果自体が小さい可能性があります。日常的に発生しているなら、投資が正当化されます。

ステップ4：Cの範囲だけで構成を決める

オフライン側の規模は、「全社員が使う」ではなく「Cを扱う人が何人か」で決めます。ここを絞れるかどうかで、費用は数百万円単位で変わります。

併用のデメリットも申し上げます

併用は万能ではありません。利用者は2つの環境を使い分けることになり、「この資料はどちらに入れるのか」という判断を現場の一人ひとりに求めることになります。切り分け基準の文書化と周知、クラウド契約と社内サーバーの二重管理も発生します。

それでも、「全部オフラインにする」よりは現実的です。全部オフラインにすると、精度の低いモデルで全業務をこなすことになり、結果として使われなくなるリスクが高まります。

なお、切り分けの方針が固まり実際に導入を決めた後の進め方（構成の選び方、社内ルールの決め方、導入までの期間）は、オフライン生成AI（ローカルLLM）導入前に押さえる基本知識・選び方・社内ルールで解説しています。

よくある質問

まとめ：次にやること4つ

1. 自社の情報管理規程と、主要な取引先との契約書を読み返す … 「外部送信が制限された情報」が本当に存在するかを確認します
2. 法人向けクラウドプランを正式に契約して使い始める … シャドーAIを止め、AIで何ができて何ができないかを社内で体感します
3. 「クラウドではできなかった業務」を3カ月記録する … オフラインが本当に必要な業務の量が数字で見えてきます
4. その量を根拠に、オフラインの必要性と規模を判断する

この順番なら、仮にオフラインを導入する場合でも構成と規模の精度が上がります。何より、「導入したが使われなかった」という最悪の結末を避けられます。