オンプレLLMの構築手順2026。要件定義から機材・推論エンジン・UI・RAG・認証・運用までの7工程と、工程ごとの判断基準

「オンプレでLLMを構築したい」という相談で最初に出てくる質問は、ほぼ決まっています。何を買えばいいのか、どのモデルを使うのか、いくらかかるのか、誰が面倒を見るのか。この4つは別々の問いに見えて、実際には1本の工程表の上に並んでいます。順番を間違えると、買った機材にモデルが載らない、モデルは動いたが社内文書が読めない、動いたが誰もログインできない、という手戻りが起きます。

本記事では、オンプレLLMの構築を7つの工程に分け、各工程で「決めること」「成果物」「関わる人」「やり直しが高くつく順番」を整理します。個々の工程の詳しい手順は既存の記事に委ね、ここでは全体像と工程間の依存関係に集中します。閉域・独立システムとしてのローカルLLMを検討している情報システム部門や、稟議を書く推進担当者を読者に想定しています。

この記事の要点

オンプレLLMの構築は「要件定義 → 機材 → 推論エンジン → モデル選定 → UIとRAG → 認証・権限・ログ → 運用」の7工程で、前の工程の判断が後の工程の選択肢を決めます

やり直しが最も高くつくのは、要件が決まる前に機材を買うことと、評価セットを作る前にモデルを選ぶことです。この2つの順番さえ守れば、他の工程は後から直せます

費用はミニ検証約30万円、PoC 300〜500万円、本番構築約1,500万円が目安で、大半はライセンスではなく設計・構築・検証の人件費です。Mac 1台構成なら50〜150万円の範囲に収まります

工程6（認証・権限・ログ）と工程7（運用）は「動いた後の話」に見えて、構築前に設計しないと本番に進めない工程です

外注と内製の分担は工程ごとに変えられます。評価セットとデータの用意を社内で持つと、費用と評価の質の両方に効きます

オンプレLLMとは。ローカルLLM・クラウド専用環境との言葉の違い

「オンプレLLM」「ローカルLLM」「社内LLM」は、ほぼ同じものを指して使われます。厳密に分けるなら、オンプレミスは「自社が管理する設備に置く」というデータの所在の話で、ローカルLLMは「推論を自社の環境で動かす」という処理の所在の話です。本記事では両方を満たす構成、つまり推論もデータも社内に置く構成を「オンプレLLM」と呼びます。

混同されやすいのが、クラウド事業者が提供する専用環境や閉域接続です。Azure OpenAIの閉域接続は通信経路を閉じますが、処理と保存はMicrosoftのジオグラフィ内で行われます。「外に出さない」をどこまで満たすかは『Azure OpenAIの閉域接続とローカルLLM』で5点比較しています。本記事が扱うのは、その比較で「ローカルでないと満たせない」と判定された場合に進む構築手順です。

7工程の全体表

工程	決めること	成果物	主に関わる人	詳しく扱う記事
1. 要件定義	対象業務、データ区分、閉域の段階、合格ライン	要件書、評価セットの設計、稟議書	推進担当、業務部門、情シス、法務	『生成AIをオフラインで使う2026』、『ローカルLLM PoCの稟議書テンプレート』
2. 機材	Mac 1台かGPUサーバーか、メモリ容量、設置場所と電源	機材構成、設置条件、調達計画	情シス、総務、推進担当	『ローカルLLMを社内サーバーとして置く前に確認する10項目』、『ローカルLLM機材をレンタルして検証する2026』
3. 推論エンジン	Ollama／llama.cppかvLLMか、同時利用数	推論サーバーの構成、API仕様	情シス、構築ベンダー	『vLLMとは』、『試作はOllama、本番はvLLM』
4. モデル選定	国産オンプレLLMかオープンモデルか、サイズと量子化	ミニ検証の評価レポート、採用モデル	推進担当、業務部門の評価者	『国産オンプレLLM比較2026』、『日本語で使えるローカルLLMおすすめ2026』
5. UIとRAG	チャットUI、文書の取り込み範囲、検索構成	UIの設定、RAGパイプライン、取り込み台帳	情シス、構築ベンダー、文書の所管部門	『社内文書RAGの作り方2026』
6. 認証・権限・ログ	ログイン方式、部門別の閲覧範囲、記録項目と保存期間	権限設計書、ログ設計書	情シス、法務・監査	『Open WebUIの認証・SSO・権限設計』、『ローカルLLMは本当に安全か』
7. 運用	担当者、更新周期、保守の範囲、障害時の手順	運用手順書、保守契約、運用カレンダー	運用担当、保守ベンダー	『導入したローカルLLM、誰が維持するのか』、『閉域ローカルLLMの運用手順書』

工程は番号順に進めますが、工程6と7の設計は工程1の時点で着手します。理由は後述の依存関係の章で説明します。

工程1: 要件定義。対象業務・データ区分・閉域の段階を決める

要件定義で決めるのは3つです。どの業務に使うか、その業務で扱うデータはどの区分か、そして「閉域」をどの段階まで求めるかです。

対象業務は1つに絞ります。社内文書の検索、議事録の要約、翻訳、問い合わせの分類のうち、現状の工数が数字で言えるものを選びます。全社の汎用チャットから入ると、効果が測れず、工程4の評価セットも作れません。進め方の全体は『社内向け生成AI導入の手順2026』のStep1〜3に沿います。

データ区分は、公開情報・社内一般・個人情報・機密・社外送信禁止の5段で整理します。この区分が、クラウドの法人契約で足りるのか、オンプレが要るのかを決めます。判断基準は『生成AIの情報漏洩対策2026』にまとめています。

閉域の段階は、完全閉域（エアギャップ）、ネットワーク分離（社内LANのみ）、スタンドアロン（1台完結）の3つから選びます。どれを選ぶかで、工程2の機材、工程5のモデル持ち込み手順、工程7の更新方法が変わります。3段階の違いと向く組織は『生成AIをオフラインで使う2026』を参照してください。

要件定義の成果物には、評価セットの設計を含めます。対象業務の実データから30〜50件を抜き出し、期待する出力（正解データ）を業務担当者が作ります。これが工程4のモデル選定と、工程7の更新判断の基準になります。稟議に載せる項目は『ローカルLLM PoCの稟議書テンプレート』の7項目に揃えます。

工程2: 機材。Mac 1台かGPUサーバーかは、同時利用数とモデルサイズで決まる

機材の選択肢は大きく2つです。Apple Siliconの統合メモリを使うMac 1台構成と、NVIDIA GPUを載せたサーバーまたはワークステーション構成です。どちらが向くかは、同時に使う人数と動かしたいモデルのサイズで決まります。

構成	向く規模	向く用途	費用の目安	注意点
Mac 1台（Mac mini／Mac Studio）	1人〜数十人	社内文書検索、要約、下書き、翻訳	PoC 50万円〜、部門導入150万円〜	多人数の同時利用には帯域が足りなくなる。常時稼働の設定が要る
GPUワークステーション	部門規模	同時利用、長文RAG、コード補助	機材150万〜400万円程度（TCO記事の範囲）	1000W級電源、発熱と騒音、設置場所
GPUサーバー（冗長化込み）	全社	全社チャット、API連携、複数モデル	本番構築約1,500万円	専任または保守契約が前提

機材を買う前に確認すべき10項目（電源、熱、騒音、ネットワーク、電気代、担当者など）は『ローカルLLMを社内サーバーとして置く前に確認する10項目』に、Mac Studioを共有サーバーにする場合の注意は『Mac Studioを社内AIサーバーにする2026』にまとめています。予算別に何が動くかは『予算別ローカルLLM PC 2026』が目安になります。

買う前に借りて確かめる選択肢もあります。貸出機材をオフィスに2週間設置して「置けるか」を判定する実現性検証（30万円〜・税別・機材貸出料込み）は、機材の購入判断を後ろにずらせます。借りる場合の機材の選び方と返却時のデータ消去は『ローカルLLM機材をレンタルして検証する2026』を参照してください。

工程3: 推論エンジン。検証はOllama、本番はvLLMが基本線

推論エンジンは、モデルを読み込んでAPIとして応答を返すソフトウェアです。選択肢はOllama（内部はllama.cpp）とvLLMの2つに絞って考えて差し支えありません。

観点	Ollama／llama.cpp	vLLM
向く段階	検証、1人〜数人の利用、Mac	本番、同時利用、GPUサーバー
モデル形式	GGUF（量子化済み）	Hugging Face形式が中心
同時利用	順番に処理する傾向	バッチ処理で同時リクエストに強い
動く機材	Mac、CPUのみ、小さなGPU	NVIDIA GPUが前提
運用の手間	少ない	認証・監視・モデル更新の設計が要る

1人で使うときの速さはOllamaでも十分で、差が出るのは同時アクセスからです。Ollamaを卒業するサインは「同時5人超、APIでの組み込み、応答待ちの苦情、GPU使用率が上がらない」の4つで、詳しくは『試作はOllama、本番はvLLM』に、vLLMそのものの仕組みは『vLLMとは』にまとめています。

Mac 1台構成では、本番でもOllamaやllama.cppを使い続ける構成が一般的です。vLLMが要るのは工程2でGPUサーバーを選んだ場合、と覚えておけば判断は難しくありません。

工程4: モデル選定。評価セットで決め、カタログで決めない

モデル選定は、工程1で作った評価セットに候補モデルを通し、業務担当者が採点して決めます。ベンチマークの順位やパラメータ数で決めると、自社の文書では精度が出ないことが珍しくありません。

候補は2系統です。国産オンプレLLM（tsuzumi、PLaMo、cotomi、Takane、Sarashina）と、オープンウェイトの日本語対応モデルです。国産モデルは調達要件やサポート、日本語の扱いで選ばれ、価格を公開しているのはPLaMo 3.0 Primeのみで他社は個別見積もりが基本です。比較と選定フローは『国産オンプレLLM比較2026』に、オープンモデルのVRAM別の現実解は『日本語で使えるローカルLLMおすすめ2026』にあります。

選定の実務は、自社データでのモデル選定ミニ検証（約30万円・2週間）として切り出せます。精度・速度・同時利用・運用負荷の4軸で測る評価シートと合否ラインの決め方は『ローカルLLM PoCの評価シート』を使ってください。

量子化のレベルは、工程2の機材のメモリ容量で上限が決まります。機材を先に買って「載るモデルから選ぶ」順番になると、業務に合うモデルが候補に入らないことがあります。評価セットでの採点が先、機材の確定はその後です。

工程5: UIとRAG。精度はLLMではなく文書パースと検索で決まる

UIは、Open WebUIのようなチャットUIを社内に立てるのが標準です。利用者は自分のPCのブラウザから社内LANでアクセスします。Windows中心の会社でも、サーバー役がMacであれば利用側はブラウザだけで済みます。

RAG（社内文書を検索して回答に使う仕組み）は、オンプレLLMの価値の大半を担う部分です。精度が出ない原因はLLM本体ではなく、文書のパース失敗と検索の外れが大半です。日本語向けの標準構成は「パース → 埋め込み → 検索（ベクトル＋キーワードのハイブリッド） → リランク」の4段で、個人〜小規模ならOllama＋AnythingLLMで半日、部門展開ならvLLM＋ハイブリッド検索＋リランカーが目安です。詳細は『社内文書RAGの作り方2026』にまとめています。

工程5で決めておくべきなのは、取り込む文書の範囲と所管です。「ファイルサーバーを全部入れる」と決めると、工程6の権限設計が破綻します。取り込む文書ごとに所管部門と閲覧範囲を台帳にしておくと、工程6で部門グループへの権限付与がそのまま使えます。

Excel・CSVのような表データは、RAGでは扱いにくく、方式を分ける必要があります。『ローカルLLMでExcel・CSVを分析する2026』で3つの方式を比較しています。

工程6: 認証・権限・ログ。「社内だから認証なし」は最大の穴

オンプレに置いただけでは安全になりません。推論サーバーの露出、誰でも全文書を検索できる状態、入力の記録が残らない状態は、クラウドを使わなくても残るリスクです。閉域でも残る7つのリスクは『ローカルLLMは本当に安全か』で整理しています。

工程6で決めるのは3点です。

認証: ローカルのメール／パスワード、SSO（Entra ID、Google、汎用OIDC）、LDAPのどれでログインさせるか。閉域の段階によって、IdPへの経路だけ開けるか、LDAPで社内に閉じるかが変わります
権限: ナレッジ・モデル・ツールを既定で非公開にし、部門グループへ閲覧権限を付与する設計。権限は加算型で「禁止」が無いことを前提に設計します
ログ: 誰が何を入力したかを、どの項目で、どれだけの期間、誰が見られる形で残すか。残らないのも残りすぎるのも問題です

Open WebUIでの具体的な設定手順は『Open WebUIの認証・SSO・権限設計』に、ログ設計の表は残るリスクの記事にあります。社内の利用規程と整合させる必要があるため、『社内生成AI利用規程のひな形2026』の条項と対応づけておきます。

工程7: 運用。構築前に担当者と更新周期を決める

運用は「動いた後の話」ではなく、稟議の段階で決めておかないと本番に進めない工程です。運用担当者が決まっていないローカルLLMは、作った人が異動した時点で止まります。運用タスクの一覧と月あたりの工数目安（平常月1〜2人日、更新月3〜5人日）は『導入したローカルLLM、誰が維持するのか』に、四半期で回す手順書の形は『閉域ローカルLLMの運用手順書』にまとめています。

閉域の段階が高いほど、モデル更新と脆弱性修正を「外から持ち込む」手順が要ります。オンライン側で取得してハッシュ照合し、持ち込み台帳に記録して閉域内で切り替える流れは、工程1で決めた閉域の段階に応じて設計します。

運用体制は内製・ベンダー保守・運用委託の3パターンがあり、保守費用は構築費の10〜15%／年、月額数万〜数十万円が目安です。中小企業で1台構成を回す場合の現実的な体制は『中小企業のローカルLLM2026』で扱っています。

工程間の依存関係。やり直しが高くつく順番

7工程のうち、前後関係を守らないと高くつくものが2つあります。

やり直しの原因	何が起きるか	守る順番
要件が決まる前に機材を買う	同時利用数に帯域が足りない、業務に合うモデルが載らない、置き場所と電源で詰む	工程1 → 工程2。買う前に借りて判定する
評価セットを作る前にモデルを選ぶ	自社文書で精度が出ず、モデルを替えても判断基準がない	工程1の評価セット → 工程4。ミニ検証で採点してから確定する
文書の範囲を決める前にRAGを組む	権限設計が後から破綻し、取り込み直しになる	工程5の取り込み台帳 → 工程6
運用担当を決めずに本番構築する	更新が止まり、放置された推論サーバーが脆弱点になる	工程7の担当と周期を工程1の稟議に含める

逆に、推論エンジン（工程3）とUI（工程5）は、後からの差し替えが比較的安く済みます。OllamaからvLLMへの移行はOpenAI互換APIのため接続先の差し替え程度で済むことが多く、UIも設定の移行で対応できます。「最初から完璧な構成」を目指すより、要件・評価セット・運用担当の3つを先に固め、エンジンとUIは段階的に上げる進め方が現実的です。

PoC後に頓挫する生成AIプロジェクトは少なくとも30%とGartnerが予測しています。頓挫の原因の多くは技術ではなく、この順番の崩れです。

規模別の標準スケジュールと費用の幅

想定	構成	工程1〜2	工程3〜5	工程6〜7と本番	本番開始までの合計	費用の幅
士業・専門サービス（10〜30名）	Mac 1台	1〜2ヶ月（稟議含む）	2週間〜1ヶ月（PoC）	1〜3ヶ月	3〜6ヶ月	50〜150万円
製造業・中堅企業（100〜300名）	ミニ検証→PoC→GPU本番	1〜2ヶ月	2週間＋1〜2ヶ月	3〜6ヶ月	6〜12ヶ月	30万円→300〜500万円→約1,500万円
金融・医療など規制業種	要件整理と設計を含むPoCから	2〜3ヶ月	3〜6ヶ月	6ヶ月〜	12ヶ月〜	PoC段階から500万円超も

費用の大半はライセンスではなく人件費で、ソフトウェアはvLLMやOpen WebUIなどのOSSが中心です。生成AI開発全般のPoCは公開例で150〜500万円・1〜2ヶ月が中心で、オンプレではGPU機材の扱いが費用を左右します。フェーズごとの内訳と見積書の読み方は『ローカルLLM導入費用の相場2026』、3年の総額とクラウドとの損益分岐は『オンプレLLMは本当に安いのか』を参照してください。

外注と内製の分担。評価セットとデータは社内が持つ

7工程すべてを外注する必要はありません。費用と評価の質の両方に効くのは、評価セットと文書の用意を社内で持つことです。

工程	社内で持つと良いもの	外注に向くもの
1. 要件定義	対象業務の選定、現状の工数、評価セットと正解データ、データ区分	閉域の段階の設計、稟議材料の整理
2. 機材	設置場所・電源・ネットワークの条件、情シス承認	機種選定、調達、設置
3. 推論エンジン	同時利用数の見込み	構成、チューニング、API設計
4. モデル選定	採点（業務担当者3人）	候補の準備、評価の実施、レポート
5. UIとRAG	取り込む文書の範囲と所管の台帳	パース・検索・リランクの構成
6. 認証・権限・ログ	部門と閲覧範囲の定義、規程との整合	IdP連携、権限とログの実装
7. 運用	運用担当者の任命、更新判断	保守、脆弱性対応、障害一次対応

外部に委託する場合、検証と本番で契約を分ける段階投資が基本です。JDLAの生成AI開発契約ガイドラインには秘密保持・アセスメント・導入検証・開発の各段階に対応した契約ひな形が付属しており、段階ごとに契約する考え方と整合します。支援会社の選び方は『ローカルLLM導入支援会社の選び方2026』を参照してください。

構築前チェックリスト

まとめ

オンプレLLMの構築は要件定義・機材・推論エンジン・モデル選定・UIとRAG・認証権限ログ・運用の7工程で、前の判断が後の選択肢を決めます
やり直しが高くつくのは、要件前の機材購入と、評価セット前のモデル選定の2つです。この順番を守れば、エンジンとUIは後から上げられます
費用はミニ検証約30万円、PoC 300〜500万円、本番約1,500万円が目安で、Mac 1台構成なら50〜150万円です。大半は人件費です
認証・権限・ログと運用は、構築後ではなく稟議の段階で設計します。社内に置いただけでは安全になりません
評価セットと文書の用意を社内で持ち、検証と本番で契約を分けると、費用と評価の質の両方が改善します

よくある質問

Q. オンプレLLMとローカルLLMは何が違いますか？

ほぼ同じものを指します。厳密には、オンプレミスはデータと設備を自社が管理する場所に置くという所在の話で、ローカルLLMは推論を自社環境で動かすという処理の話です。本記事では両方を満たす構成を扱います。クラウド事業者の閉域接続は通信経路を閉じるだけで処理は事業者側で行われるため、別物として扱います。

Q. 最初に何から手をつければよいですか？

対象業務を1つに絞り、その業務の実データから評価セット30〜50件と正解データを作ることです。機材やモデルの検討はその後です。評価セットがあれば、モデル選定も本番後の更新判断も同じ基準で行えます。

Q. 機材は最初に買うべきですか？

要件と評価セットが固まる前には買わないことを勧めます。同時利用数とモデルサイズで必要な機材が変わり、設置場所や電源で詰むこともあります。貸出機材を2週間設置して判定する実現性検証（30万円〜・税別・機材貸出料込み）を使えば、購入判断を後ろにずらせます。

Q. 構築にはどのくらいの期間がかかりますか？

Mac 1台の構成で3〜6ヶ月、ミニ検証からGPU本番まで進む中堅企業で6〜12ヶ月、規制業種では12ヶ月以上が目安です。期間の多くは機材の調達と社内の承認に使われ、技術的な構築作業そのものは一部です。

Q. 推論エンジンはOllamaとvLLMのどちらにすべきですか？

検証と1人〜数人の利用、Mac構成ならOllamaです。GPUサーバーで同時利用が増える本番ではvLLMが基本です。OpenAI互換APIのため、OllamaからvLLMへの移行は接続先の差し替え程度で済むことが多く、最初から決め切る必要はありません。

Q. 社内に置けばセキュリティ対策は不要になりますか？

なりません。推論サーバーの露出、権限のない全文書検索、入力記録の欠落、モデル供給網の改ざん、更新停止は、社内に置いても残ります。認証・権限・ログの設計と、更新を回す運用体制を構築前に決めておく必要があります。

主な参考資料: 生成AI受託開発の費用相場2026（renue）、Gartnerの生成AIプロジェクト頓挫予測（Intelligent CIO）、OWASP Top 10 for LLM Applications、JDLA 生成AI開発契約ガイドライン

TodoONadaでは、オンプレLLMの構築を要件定義から運用設計まで7工程で支援しています。機材を買う前に貸出機材をオフィスに設置して2週間で判定する社内設置の実現性検証（30万円〜・税別・機材貸出料込み）、自社データでモデルを決めるミニ検証（約30万円・2週間）、対象業務で効果を確かめる業務PoC（一般構成30万円〜・1〜2ヶ月）を段階ごとに承っています。「どの工程から着手すべきか」「評価セットの作り方」の相談だけでも歓迎します。

この記事に関連するサービス

TodoONada株式会社では、機密データを外部に出さないローカルLLMの導入支援を行っています。

ローカルLLM導入支援 — GPUサーバーでの本格構成。モデル選定からRAG構築・運用まで
Macで始める社内専用AI導入支援 — Mac 1台から始める社内専用AI。PoCから部門導入まで対応
ローカルLLM 社内設置の実現性検証（機材貸出） — 機材を買う前に、DGX SparkやMacを貴社オフィスに2週間設置して「置けるか」を判定。機材のみの短期貸出も対応

導入・開発のご相談はお問い合わせからお気軽にどうぞ。検討段階のご相談も歓迎です。