オフラインvsクラウド判断軸

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

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

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

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

POINT

性能とコストだけを基準にするなら、選ぶべきはクラウド型の生成AIです。 2026年8月時点の公開ベンチマークでは、社内サーバー1台で動かせる規模のAIモデルとクラウド最上位モデルの間に、まだはっきりした差があります。費用も、少人数での利用ならクラウドが圧倒的に安く、オフラインが追いつくには相応の人数と年数が必要です。

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

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

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

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

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

※1.は、規程・契約書を実際に確認してからチェックしてください。まだ確認していない場合は、チェックの前に規程と主要な取引先との契約書を読み返すことから始めてください。それが判断の第一歩です。

チェック項目(当てはまるものにチェック)
0個クラウドで十分
まずはクラウド型の法人プランを、承認された形で正式に導入することをおすすめします。
1〜2個併用を検討
大半の業務はクラウドで進め、出せない情報を扱う業務だけをオフラインに切り出す形が合理的です。該当業務が月に数件程度なら、まずクラウドで運用して量を数えてから判断してください。
3個以上オフラインを本格検討
クラウドでは要件を満たせません。費用は後述の回収表で見当を(20人規模では費用面の正当化が難しめです)。

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

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

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

POINT

「オープンなAIモデルはクラウド最上位に近づいた」という話と「社内に置ける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です)、それでも半分ということです。

図1:Intelligence Index の比較(数字が大きいほど高性能)
クラウド最上位 63
オープン最上位※社内サーバー1台には載りません 60
社内1台に載る規模 30

※Artificial Analysis社「Intelligence Index」。数値は2026年8月15日時点。オープン最上位(Kimi K3)はデータ本体が1.56テラバイト規模のため、社内サーバー1台には載りません。「社内1台に載る規模」の数値はGemma 4 31Bのスコアです。棒の長さは最大値63を100%とした相対表示です。

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

ただし、スコアが半分だから業務が半分しかこなせない、という意味ではありません。社内文書を検索して要約する、議事録を整える、定型文を作るといった用途なら、スコア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年が損益の分かれ目

POINT

少人数・短期間ならクラウドが圧倒的に安く、人数と年数が増えるほどオフラインが追いついてきます。 ただし逆転までに必要な条件は、多くの方が想像するより厳しめです。

クラウド側の費用

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

オフライン側の費用

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

提供元・出典内容公表価格
インテック「ローカルLLM導入支援」(2026年1月発表)閉域ネットワーク内にGPUサーバー+LLM+RAGをパッケージ提供。最短1カ月で構築参考価格 500万円(税別)から
リコー「RICOH オンプレLLMスターターキット」(2025年4月発表)GPUサーバーに700億パラメータのLLMとDifyをプリインストール1,500万円から
業界メディアによる相場記事(2025年11月)エントリー構成〜エンタープライズ構成198万円(税抜)〜2,500万円以上

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

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

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

オフライン初期費用回収に必要な規模20人で使う場合50人で使う場合100人で使う場合
198万円(税抜)55人年約2.8年約1.1年約0.6年
500万円(税別)139人年約6.9年約2.8年約1.4年
1,500万円417人年約20.8年約8.3年約4.2年

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

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

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

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

POINT

オフラインを選ぶ理由になるのは、技術やコストの話ではなく、契約・規程・物理環境という「動かせない制約」がある場合です。裏付けが取れた範囲で、2つの条件と、あわせて確認すべき規制面の補足を挙げます。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

POINT

「クラウドAIに機密情報を入れてはいけない」という社内ルールを出すだけでは、守られない場合が多いことが複数の調査で示されています。

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

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

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

POINT

多くの企業にとっての現実解は併用です。業務の大半はクラウドで進め、外に出せない情報を扱う業務だけをオフラインに回すという形になります。

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

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

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

図2:情報の区分と、その行き先
A:外部に出しても問題ない情報
公開済みの資料、一般的な調べもの、社外向け文章の下書き
クラウド
B:社外秘だが、契約上クラウド利用が禁じられてはいない情報
一般的な社内資料、議事録、社内マニュアル
クラウド(規約確認のうえ)
C:契約・規程で外部送信が明確に制限されている情報
取引先から預かった図面・仕様、特定の顧客データなど
オフライン

※切り分けの軸は部署ではなく情報の区分です。Bを最初からオフラインに含めると、必要以上に大きな設備が必要になります。

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

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

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

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

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

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

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

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

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

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

よくある質問

Q1. オフラインにすれば、情報漏洩は起きなくなりますか

いいえ、そうとは言えません。

オフライン生成AIが防げるのは、「入力した情報が外部のサーバーに渡ること」です。従業員が回答をコピーして社外に持ち出すこと、サーバー自体への不正アクセス、そして権限のない社員が、閲覧できてはいけない社内文書をAI経由で読んでしまうことは防げません。

最後の一つは特に見落とされがちです。社内文書を検索できるようにする仕組み(RAGと呼ばれます)を入れると、これまで部署内に留まっていた文書が、AI経由で誰でも読める状態になり得ます。オフラインにしても、誰がどの情報にアクセスできるかの設計は必要です。

Q2. 社内サーバーに載る小さいモデルでも、実務で使えますか

用途によります。社内文書の検索・要約・定型文の下書きでは実用になる、というのが弊社の見立てです。

判断には、自社の実際の文書と実際の質問で試すことが唯一確実な方法です。

Q3. オープンモデルが今後クラウドに追いつくなら、今はクラウドで待つべきですか

「クラウドで待つ」という判断は、多くの場合で合理的です。

ただし、条件1・条件2に該当する場合(契約上出せない情報がある、閉域網で使う)は、待っていても状況は変わりません。

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

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

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

導入前の論点整理からご相談いただけます

弊社はオフライン生成AIの導入支援を行っていますが、多くの企業にとってはクラウド型で十分だと考えています。

ご相談をいただいた際も、まず御社の規程と契約、扱う情報の中身をうかがったうえで、「クラウドで足ります」「今の段階では投資に見合いません」という判断も含めてお伝えします。売れないほうの答えであっても、そちらが正しければそう申し上げます。

自社がどちらに当てはまるか判断がつかない、規程を読んでも解釈に迷う、といった段階でもかまいません。

ご相談・お問い合わせはこちら