LLM開発とは？4つの手法と費用相場・進め方・開発会社の選び方まで解説

LLM開発という言葉は、ゼロからモデルを作ることと、既存モデルを使って業務システムを作ることの両方を指して使われています。この2つは必要な予算も体制もまったく異なるため、区別しないまま検討を始めると話が噛み合いません。

実際、自社専用のモデルを一から学習させる必要がある企業はごく一部です。多くの業務課題は、既存モデルに自社データを参照させる構成で解決できます。判断を誤ると、不要な投資に踏み込むことになります。

本記事では、LLM開発の4つの手法を整理したうえで、実現できること、手法別の費用相場、開発の進め方、依頼先の選び方までを一続きで解説します。

確認したいポイント	結論	詳細
LLM開発とは何を指す？	モデル開発と活用システム開発	モデル自体を学習させる領域と、既存モデルを使って業務システムを構築する領域に分かれます。
自社でモデルを作る必要はある？	多くの企業はRAG構成で足りる	自社データを参照させる仕組みとプロンプト設計で、目的を満たせるケースが大半を占めます。
費用はどのくらいかかる？	手法により数十万〜数千万円	RAG中心なら数百万円規模、ファインチューニングを伴うと数千万円規模まで上がる傾向があります。
失敗しやすい原因は？	精度評価と運用設計の不足	合格基準を決めずに開発を始め、誤出力への対処を用意しないまま本番に進むことが主な要因です。

この記事でわかること

• LLM開発が指す2つの領域と、自社に必要なのがどちらかを見分ける基準
• フルスクラッチからRAGまで4つの開発手法の違いと、業務課題に応じた使い分け
• 手法別・工程別に整理した費用相場と、見落とされやすい運用コストの中身
• 課題定義から運用改善までの6ステップと、PoC段階で決めておくべき評価基準
• 内製と外注の判断基準、および開発会社を比較するときに確認すべき項目

▼ AI開発・AI導入支援のサービス資料をご用意しています 支援範囲、進め方、体制、想定スケジュールをまとめた資料です。社内での検討材料としてご活用ください。 ＞＞ 資料請求はこちら

LLM開発とは？企業が取り組む2つの領域

LLM開発の検討でまず必要なのは、言葉の範囲を揃えることです。同じ「LLM開発」でも、指している内容によって費用が100倍以上変わります。

ここでは、2つの領域の違い、生成AIとの関係、そして国内の開発動向を整理します。

モデル自体の開発と、活用システムの開発

LLM開発は、大きく2つの領域に分かれます。1つはLLMそのものを学習させる領域、もう1つは既存のLLMを使って業務システムを構築する領域です。前者は学習フェーズ、後者は推論フェーズとも呼ばれます。

モデル自体の開発には、大量の学習データ、高性能なGPU、専門人材が必要になります。国内で取り組んでいるのは、研究機関や一部の大手企業に限られるのが実情です。

一方、企業が業務改善を目的に検討するLLM開発のほとんどは後者です。ChatGPTやClaudeなどのAPIを使い、自社のデータや業務フローに合わせた仕組みを構築する取り組みを指します。

検討の入り口で必要なのは、自社の目的がどちらに該当するかの見極めです。業務効率化が目的であれば、モデルを作る必要はほぼありません。

生成AIとLLMの関係を整理する

LLMは、大量のテキストを学習し、言語の理解と生成を行うモデルです。生成AIという大きな枠のなかで、テキストを扱う部分を担っているのがLLMという関係になります。

画像生成や音声合成、動画生成は、それぞれ別の技術が担っています。ChatGPTの応答やClaudeによる文書要約はLLMの領域ですが、画像生成は異なるモデルが処理しています。

この区別は、要件定義の段階で重要になります。扱いたいデータがテキストなのか、画像や音声も含むのかによって、選ぶべき技術と構成が変わるためです。

国内では基盤モデル開発への公的支援も進んでいる

モデル自体の開発について、国内では公的な支援が行われています。経済産業省とNEDOは2024年2月から、国内企業の生成AI開発力強化を目的とした「GENIAC」というプロジェクトを推進しています。

同プロジェクトでは、基盤モデル開発に必要なGPUなどの計算資源の提供、参加企業間の知見共有、データ利活用に向けた支援が行われています。1サイクル目には10社が参画しました。

国が計算資源の確保を支援する枠組みが必要とされている事実そのものが、モデル開発の負担の大きさを示しています。一般企業が単独で取り組む領域ではないという判断材料になります。

出典：経済産業省「競争力ある生成AI基盤モデルの開発（GENIAC）」　https://www.meti.go.jp/policy/mono_info_service/geniac/index.html

LLM開発の4つの手法と選び方

既存モデルを活用する場合でも、自社データをどう反映させるかによって手法が分かれます。費用も期間も手法によって大きく変わるため、ここでの選択が予算を左右します。

ここでは代表的な4つの手法を、負担の大きい順に整理します。

手法1：フルスクラッチ開発

モデルの構造設計から事前学習までを一から行う方法です。学習に使うデータ、計算資源、期間のいずれも大規模になり、費用は数億円規模からとなります。

この手法を選ぶ理由になるのは、既存モデルでは扱えない特殊な言語や領域を対象とする場合、あるいはモデルそのものを事業の中核に据える場合に限られます。

一般的な業務効率化を目的とする企業が選ぶ手法ではありません。GENIACのような公的支援の対象になっていること自体が、投資規模の大きさを表しています。

手法2：継続事前学習

既存の公開モデルに対し、自社の大量のテキストデータで追加の学習を行う方法です。業界特有の用語や表現をモデル自体に覚えさせたい場合に選ばれます。

フルスクラッチより負担は小さくなりますが、それでも数千万円規模の投資と、GPU環境の確保が必要になります。学習に使えるテキストが十分に蓄積されていることが前提です。

医療、法務、金融など、専門用語の比重が高い領域で検討されることがあります。ただし後述するRAGで代替できるケースも多く、着手前の比較検討が欠かせません。

手法3：ファインチューニング

既存モデルに対し、目的の業務に沿った入力と出力の組み合わせを学習させ、応答の傾向を調整する方法です。回答の形式や口調を安定させたい場合に効果があります。

近年はLoRAなど、一部のパラメータのみを更新する手法が普及し、必要な計算資源は以前より抑えられるようになりました。それでも費用は数百万円から数千万円の範囲になります。

注意したいのは、ファインチューニングは知識を追加する手段としては効率が良くないという点です。最新情報や社内文書を参照させたい場合は、次のRAGのほうが適しています。

手法4：RAGとプロンプト設計

RAG（検索拡張生成）は、質問に対して社内文書などを検索し、その内容を根拠として回答を生成させる構成です。モデル自体は変更せず、参照する情報を外から与える点が特徴です。

文書を更新すれば回答も更新されるため、社内規程やマニュアルのように内容が変わる情報を扱う用途に向いています。回答の根拠を提示できることも、業務利用では大きな利点です。

費用はRAGの規模によりますが、数百万円規模から構築できます。企業のLLM活用のうち、実際にはこの構成で目的を満たせるケースが大半を占めます。

4つの手法をどう使い分けるか

判断の起点は、解決したい課題の性質です。社内の情報を正確に引き出したいならRAG、応答の形式を揃えたいならファインチューニングという切り分けが基本になります。

実務では、両者を組み合わせる構成も一般的です。RAGで根拠となる情報を渡しつつ、出力形式をファインチューニングで整えるという使い方になります。

継続事前学習やフルスクラッチを検討するのは、この2つで要件を満たせないと確認できてからです。先に軽い手法で検証し、不足があれば重い手法へ移る順序が費用面では合理的です。

関連記事：システム開発のAI活用とは？工程別の使いどころ・ツール・進め方と注意点を解説

▼ AI開発・AI導入支援のサービス資料をご用意しています 支援範囲、進め方、体制、想定スケジュールをまとめた資料です。社内での検討材料としてご活用ください。 ＞＞ 資料請求はこちら

LLM開発で実現できること

手法の次に確認したいのが、実際にどのような業務が対象になるかです。LLMが得意とするのは、文章の理解と生成を伴う工程に限られます。

ここでは、導入が進んでいる4つの領域を取り上げます。

社内ナレッジ検索と問い合わせ対応

社内規程、業務マニュアル、過去の提案書といった文書を横断して検索し、質問に回答する仕組みです。RAG構成の代表的な用途であり、導入の第一歩として選ばれることが多い領域です。

既存の文書資産をそのまま活用できるため、新たにデータを収集する必要がありません。文書がある程度整理されていれば、比較的短期間で構築できます。

効果が出やすいのは、問い合わせが特定の担当者に集中している組織です。回答の根拠となる文書を提示できるため、利用者が内容を確認しながら使えます。

文書の要約・分類・チェック

契約書のレビュー、報告書の要約、問い合わせ内容の分類といった処理は、LLMの得意分野です。大量の文書を一定の基準で判定する作業を、人が全文を読む前に絞り込めます。

契約書であれば、必要な条項の有無や自社基準との差異を確認し、担当者が注視すべき箇所を提示します。最終判断は人が行う前提で、確認工数を削減する使い方です。

分類処理では、問い合わせを内容ごとに振り分けたり、優先度を付けたりする用途があります。ルールベースでは対応しきれない表現のゆらぎにも対応できます。

顧客対応の自動化

顧客からの問い合わせに対し、自社のFAQや商品情報を参照して回答する仕組みです。従来型のチャットボットと異なり、登録していない言い回しでも意図を読み取って応答できます。

24時間の対応が可能になるため、営業時間外の問い合わせを取りこぼさなくなります。定型的な質問がAIで完結すれば、有人対応は複雑な相談に集中できます。

設計上の要点は、回答範囲の限定とエスカレーションの仕組みです。確信度が低い場合に有人へ引き継ぐ経路を用意しないと、誤回答が顧客に届くリスクが残ります。

業務システムと連携するAIエージェント

LLMに外部のシステムを操作させる構成も広がっています。問い合わせ内容を理解したうえで、在庫システムを照会し、結果を踏まえて回答を作るといった一連の処理が可能です。

この構成では、LLMが判断し、既存システムが実際の処理を担います。基幹システムを作り替えることなく、対話による操作を追加できる点が実務上の利点です。

一方で、実行できる操作の範囲を明確に区切る設計が不可欠になります。更新や削除を伴う操作については、人の承認を挟む工程を必ず残します。

LLM開発が向かない業務

実現できることと同じくらい重要なのが、向かない業務を知っておくことです。手順が完全に決まっている転記作業は、LLMより従来の自動化のほうが速く確実です。

数値計算そのものもLLMの得意分野ではありません。集計や計算はプログラムやデータベースに任せ、LLMは結果を読み取って説明する役割に限定するほうが精度は安定します。

また、誤りが一切許されない判定業務も慎重な検討が必要です。人の確認工程を省けない前提であれば、削減できる工数がどの程度かを先に見積もっておく必要があります。

LLMが力を発揮するのは、表現にゆらぎがあり、文脈の理解を伴う工程です。この特性に合う業務を選べているかが、投資判断の分かれ目になります。

LLM開発の費用相場

費用は手法によって大きく変わります。同じ「LLM開発」という依頼でも、構成次第で数百万円にも数千万円にもなるため、相場という言葉だけでは判断できません。

ここでは、手法別の目安、工程ごとの内訳、運用コストの3点に分けて整理します。なお、実際の金額は要件と規模によって変動するため、あくまで目安として扱ってください。

手法別の費用の目安

プロンプト設計とAPI活用が中心の構成であれば、数十万円から数百万円の範囲で構築できます。既存のツールを組み合わせる形になるため、期間も短く済みます。

RAGを構築する場合は、文書の前処理、検索基盤の構築、精度調整が加わり、数百万円から1,000万円程度が一つの目安になります。対象文書の量と種類によって幅が出ます。

ファインチューニングや継続事前学習を伴う場合は、500万円から3,000万円程度まで上がります。GPU環境の確保と学習データの整備が費用の中心です。

フルスクラッチ開発は数億円規模となり、一般的な企業の業務改善では選択肢に入りません。まずは軽い手法で要件を満たせるかを確認する順序が現実的です。

工程ごとの費用の内訳

LLM開発は、要件定義、データ整備、開発、評価、実装、運用という流れで進みます。見積もりから漏れやすいのが、要件定義とデータ整備の工数です。

特にデータ整備は負担が大きくなりがちです。文書の形式が揃っていない、スキャン画像のまま保存されている、更新されていない情報が混在しているといった状態では、前処理に相当な工数がかかります。

評価工程も見落とされやすい部分です。精度を測るためのテストデータを作成し、業務担当者が出力を確認する作業には、開発側だけでなく発注側の工数も発生します。

運用にかかるランニングコスト

LLM開発では、初期費用と同程度に運用コストの見通しが重要です。APIの利用料は処理したトークン量に応じて発生するため、利用者が増えれば費用も比例して増えます。

モデルによって単価が異なるため、用途ごとに使い分ける設計が費用管理の要点になります。すべての処理を高性能モデルで行う必要はありません。

このほか、クラウドインフラの費用、精度の監視と改善の工数、文書更新に伴う再処理の手間が継続的に発生します。年間の総額で試算しておく必要があります。

費用を抑えるための考え方

最も効果が大きいのは、対象業務を絞ることです。全社的な仕組みを最初から作ろうとすると、要件が膨らみ費用も期間も跳ね上がります。

次に有効なのが、既存の仕組みを活かす判断です。ゼロから構築せず、利用中のツールの機能で足りる部分は置き換えないという線引きが費用を抑えます。

また、精度目標を過剰に設定しないことも重要です。人が確認する工程を残す前提であれば、完璧な精度は必要ありません。目標値の設定が費用に直結します。

関連記事：AIでシステム運用を自動化する方法｜AIOpsの仕組みと導入手順・注意点を解説

▼ AI開発の進め方を、自社の課題に沿って整理しませんか 「どの業務から着手すべきか」「自社のデータで実現できるか」といった段階からご相談いただけます。無理な提案は行いません。 ＞＞ 相談予約はこちら

LLM開発の進め方6ステップ

手法と費用の見通しが立ったら、次は進め方です。LLM開発の成否は、コーディングよりも前の工程で大きく決まります。

ここでは、課題定義から運用改善までの流れを6段階で解説します。

ステップ1：課題の定義と対象業務の選定

最初に決めるのは、どの業務の何を改善するかです。「LLMを導入する」ではなく「問い合わせ一次対応の工数を月40時間削減する」まで具体化しておくと、後の判断がぶれません。

対象業務を選ぶ際は、発生頻度と誤りの影響度を見ます。頻度が高く、誤っても人が確認して修正できる業務が、最初の対象として適しています。

この段階で、LLM以外の手段で解決できないかも検討します。手順の見直しや既存ツールの設定変更で済む課題であれば、そちらのほうが早く確実です。

ステップ2：データの確認と整備

対象業務が決まったら、必要なデータが使える状態にあるかを確認します。文書の所在、形式、更新状況、アクセス権限を洗い出します。

RAGを構成する場合、参照する文書の品質がそのまま回答の品質になります。古い情報や矛盾する記述が混在していれば、AIはそれをそのまま返します。

この工程では、文書の棚卸しと整理が必要になることが多くあります。開発工数ではなく発注側の作業として発生する部分であり、スケジュールに織り込んでおく必要があります。

ステップ3：手法とモデルの選定

要件が固まった段階で、前述の4手法から適したものを選びます。知識を参照させたいのか、応答形式を揃えたいのかという目的の違いが判断軸になります。

あわせてモデルも選定します。処理速度、精度、利用料金、日本語への対応、データの取り扱い方針といった条件を比較します。

機密性の高い情報を扱う場合は、データが外部に送信されない構成を検討します。自社環境内でモデルを動かす選択肢もありますが、その分インフラ費用は上がります。

ステップ4：PoCと精度評価

限定的な範囲で試作し、実際の業務データで精度を検証します。開始前に合格基準を決めておかないと、検証結果の解釈が分かれて意思決定が止まります。

評価では、正答率だけでなく誤答の傾向を見ます。どのような質問で誤るのか、誤った場合に業務上どの程度の影響があるのかを整理します。

あわせて、処理速度、想定外の入力への挙動、既存システムとの接続可否も確認します。本番運用で問題になる要素を、この段階で洗い出しておきます。

ステップ5：本番実装とシステム連携

基準を満たしたら本番環境の構築に進みます。既存システムとの連携、利用画面の開発、権限管理、ログ取得といった要素が中心になります。

あわせて必要なのが、利用ルールの整備と社内への周知です。入力してよい情報の範囲、出力を確認すべき場面、判断に迷ったときの相談先を明文化します。

業務手順書の更新も忘れてはならない工程です。AIを使う工程が手順に組み込まれていないと、担当者が変わったときに元のやり方に戻ってしまいます。

ステップ6：運用と継続的な改善

運用開始後は、利用状況と精度を定期的に確認します。LLMを使った仕組みは、参照する文書や業務内容の変化に応じて調整が必要になります。

回答できなかった質問を集計し、参照文書を追加する。誤答が多い領域を特定し、プロンプトや検索の設定を調整する。こうした改善が運用の中心作業です。

利用率が伸びない場合、原因は精度ではなく操作性や業務フローにあることが多くあります。現場の声を聞き取り、使われ方を確認することが重要です。

LLM開発でつまずきやすいポイント

LLMを使った開発には、従来のシステム開発とは異なる注意点があります。出力が毎回同じにならないという性質が、設計と運用の前提を変えるためです。

ここでは、事前に想定しておきたい4つの論点を整理します。

誤った出力への対処を決めていない

LLMは、事実と異なる内容をもっともらしく生成することがあります。この性質は完全には解消できないため、起きる前提で運用を設計する必要があります。

対処の基本は、根拠となる文書を提示させること、回答範囲を限定すること、人が確認する工程を残すことの3点です。RAG構成が選ばれる理由もここにあります。

業務によっては、誤りの影響が大きく人の確認を省けない場合もあります。その場合でも、確認の対象を絞り込めるだけで工数削減の効果は得られます。

精度の評価方法が定まっていない

従来のシステムは、動くか動かないかで判定できました。LLMを使った仕組みは、どの水準に達したら実用と見なすかを人が決める必要があります。

評価には、実際の業務で発生する質問を集めたテストデータが必要です。開発側が用意した想定質問だけでは、本番での挙動を予測できません。

また、誤検知と見逃しのどちらが業務上より深刻かを整理しておきます。この優先順位が定まれば、調整の方針も確認体制も決まります。

機密情報の取り扱いが整理されていない

外部のAPIを利用する構成では、入力した内容が事業者側に送信されます。データが学習に使われない設定になっているか、保存期間はどうかを契約前に確認する必要があります。

総務省の調査でも、生成AI導入における懸念として社内情報の漏えいリスクが上位に挙がっています。導入が止まる理由の多くは、この確認が済んでいないことにあります。

機密性が特に高い業務では、自社環境内でモデルを動かす構成も選択肢になります。ただしGPUの確保と運用の負担が発生するため、対象業務を絞った判断が必要です。

出典：総務省「令和7年版 情報通信白書」企業におけるAI利用の現状　https://www.soumu.go.jp/johotsusintokei/whitepaper/ja/r07/html/nd112220.html

運用コストが想定を超える

全社展開したあとに、API費用が想定を大きく超えるというケースがあります。利用量に応じた課金であるため、使われるほど費用が増える構造を理解しておく必要があります。

対策として、処理内容に応じたモデルの使い分け、入力する文書量の最適化、利用量の上限設定を初期段階から設計に含めます。

部署ごとの利用状況を把握できる仕組みも重要です。可視化されていないと、費用が膨らんだときに原因を特定できません。

関連記事：AI開発ツールとは？2つの種類と主要ツール比較・選び方6つの基準を解説

▼ AI開発の進め方を、自社の課題に沿って整理しませんか 「どの業務から着手すべきか」「自社のデータで実現できるか」といった段階からご相談いただけます。無理な提案は行いません。 ＞＞ 相談予約はこちら

内製と外注の判断基準・開発会社の選び方

最後に、体制の判断について整理します。すべてを内製すると人材確保が壁になり、すべてを外注すると社内に知見が残りません。

ここでは、内製と外注の向き不向き、そして依頼先を比較する際の確認項目を解説します。

内製に向くケース・外注に向くケース

内製が向くのは、社内にエンジニアがおり、対象業務を長期的に改善し続ける前提がある場合です。継続的な調整が必要な技術であるため、社内で回せる体制の価値は大きいといえます。

外注が向くのは、初めての取り組みで判断材料が不足している場合、あるいは立ち上げを急ぐ場合です。他社での実装経験があれば、つまずきやすい箇所を先回りできます。

現実的な分担は、業務課題の整理とデータの提供を自社が担い、実装を外部が担う形です。業務を理解しているのは自社側であり、その知識は外部に委譲できません。

開発会社を比較するときの確認項目

確認したいのは、同種の業務での実装経験、対応できる手法の範囲、データの取り扱い方針の3点です。RAGしか扱えない、あるいは特定のモデルにしか対応していない場合、選択肢が狭まります。

実績を見る際は、件数ではなく内容を確認します。どのような課題をどう解決したのか、精度をどう評価したのか、運用でどんな調整が発生したのかを説明できるかが判断材料です。

初回の打ち合わせでの質問内容も参考になります。技術の話から入る相手より、業務の流れや判断基準を細かく確認してくる相手のほうが、実態に合う設計を期待できます。

契約前に確認しておきたい支援範囲

見積もりを比較するときは、金額の前に作業範囲を揃えます。要件定義から運用支援まで含む見積もりと、実装のみの見積もりを金額だけで比べても意味がありません。

特に確認したいのが、データ整備をどちらが担うか、精度評価をどう行うか、納品後の調整がどこまで含まれるかという点です。ここが曖昧だと、後から追加費用が発生します。

運用フェーズの支援内容も契約前に明確にします。精度監視、参照文書の更新、モデルの切り替え対応をどこまで担うのか、その頻度と費用を確認しておきます。

まとめ：軽い手法から検証し、必要な範囲だけ重くする

LLM開発は、モデル自体を作る領域と、既存モデルで業務システムを構築する領域に分かれます。業務改善を目的とする企業にとって必要なのは、ほぼ後者です。

手法はフルスクラッチ、継続事前学習、ファインチューニング、RAGの4つに整理でき、費用は数十万円規模から数億円規模まで幅があります。多くの業務課題は、RAGとプロンプト設計の組み合わせで解決できます。

進め方で重要なのは、課題を具体化すること、データの状態を先に確認すること、そしてPoCの前に合格基準を決めておくことです。この3点を飛ばした案件が、検証で止まる典型的なパターンになります。

運用面では、誤出力への対処、精度の評価方法、機密情報の取り扱い、利用量に応じたコストの4点を設計に含めます。軽い手法で検証し、必要と確認できた範囲だけ投資を重くしていく順序が、費用対効果の面では最も確実です。

▼ AI開発の進め方を、自社の課題に沿って整理しませんか 「どの業務から着手すべきか」「自社のデータで実現できるか」といった段階からご相談いただけます。無理な提案は行いません。 ＞＞ 相談予約はこちら