LLM開発の進め方【2026年版】ソフトウェア連携・RAG・API料金を解説

はじめに

LLM開発には、大規模言語モデル自体を学習させる取り組みと、既存モデルを業務システムへ組み込む取り組みがあります。問い合わせ対応や社内検索を改善したい企業では、まず後者を検討すると、必要なデータや運用体制を具体化しやすくなります。独自モデルの研究開発を始めなくても、APIを通じて文章の生成・要約・分類を試せます。

ソフトウェア開発との連携も、コードを書かせることだけに限りません。仕様書の下書き、変更内容の説明、テスト観点の抽出、障害記録の検索など、開発者が情報を探し整理する工程を支援できます。一方で、生成された内容が正しいとは限らず、確認工数やAPI費用が増える場合もあります。

導入を判断するときは、モデルの名前だけでなく、誰のどの作業を改善するのか、何を外部へ送信できるのか、誤りが出たときに誰が止めるのかを先に整理します。社内文書を参照するRAGと、モデルの応答傾向を変える追加学習では、準備するデータも更新方法も異なります。

この記事では、2026年9月24日に確認した公式情報をもとに、技術スタック、API料金、モデル選定、開発手順、セキュリティを解説します。開発チームでの活用例とBubble・Difyを使う際の判断軸も取り上げます。小規模なPoCから始める場合にも、本番移行で必要になる権限管理や監視まで見通せるよう、方式と運用の両面から検討しましょう。

LLM開発で作れるものと業務用途

LLMは、文章で表現された曖昧な依頼を整理し、候補や説明を返す用途に使えます。従来のルール型処理で条件を網羅しにくい業務でも試せますが、計算や確定的なデータ更新は通常のプログラムに任せる方が検証しやすい場合があります。自然言語処理と確定処理の境界を決めることが設計の出発点です。

用途	実装する機能	人が確認する内容
社内FAQ・ナレッジ検索	規程や障害記録を検索して根拠付き回答	文書の有効性、閲覧権限
問い合わせ支援	質問分類、回答案、担当部署への振り分け	契約条件、例外対応
文書生成	議事録、仕様書、報告書の下書き	事実、抜け漏れ、公開可否
開発支援	コード説明、レビュー補助、テスト案	動作、脆弱性、既存仕様との整合
対話型の業務操作	検索条件の作成、レポート生成、API実行	対象範囲、操作権限、実行承認

たとえば新しい担当者が「このAPIのエラーは以前どう直したか」と質問した場合、過去の障害記録と手順書を探し、該当箇所を示す仕組みを作れます。回答だけを表示すると根拠を追えないため、資料名、更新日、参照箇所も見せます。ナレッジ継承の効果は、回答の自然さより必要な情報へ到達できるかで評価します。

対話型UIでは、「先月と今月の売上を比較して」という依頼を検索条件へ変換し、集計自体はデータベースで行う構成が考えられます。対象部署や期間が曖昧なら聞き返し、集計結果を示してから表示形式を調整します。LLMに数値を推測させず、取得したデータと生成した説明を区別することが大切です。

こうした用途でも、AIの提案を直す時間が従来の作業時間を上回れば導入効果は出ません。対象業務を絞り、作業時間、修正回数、利用継続率を導入前後で測ります。任せる範囲の整理には、生成AI開発の限界と人が担う工程も参考になります。

LLM連携における技術スタックと選び方

技術スタックは、モデルをどこで動かすかと、業務データをどう接続するかに分けて考えます。API、自己ホスト、ハイブリッドは主に配置と運用責任の違いです。RAGや追加学習はデータを活用する方式であり、どちらか一方の分類だけで全体構成は決まりません。

配置方式	主な利点	運用上の負担・判断軸
クラウド型LLM API	推論基盤を自社構築せず検証できる	従量料金、送信可能データ、レート制限、提供終了
公開モデルの自己ホスト	配置先や処理経路を自社で制御しやすい	GPU・メモリ、ライセンス、更新、障害対応
ハイブリッド	データの機密性や処理ごとに配置を分けられる	境界での送信制御、監視の統合、運用の複雑化

クラウド型では、Google Cloud、Azure、AWSなどの基盤やモデル提供者のAPIを比較します。自前のGPU管理を減らせる一方、外部障害や呼び出し上限の影響を受けます。単価だけで選ばず、必要な地域で利用できるか、データ保持条件が合うか、ピーク時の処理量を満たすかを確認します。

Hugging Faceなどで配布されるモデルを自社環境に置く場合は、公開されていることと自由に商用利用できることを同一視しないでください。ライセンスとモデルの利用条件を個別に確認します。必要なメモリはモデル規模、量子化、入力長、同時実行数で変わるため、「この容量があれば十分」と一律には決められません。

自己ホストでは、GPUの取得費以外に、推論サーバーの保守、アクセス制御、監視、バックアップ、障害時の担当者が必要です。利用量が少ない段階では設備の稼働率が低くなることもあります。クラウドとの比較では、月額請求だけでなく運用担当の工数まで含めた総費用を見ます。

ハイブリッド構成の例として、社内で文書を検索し、送信可能な部分だけを外部APIへ渡す方式があります。ただし、検索基盤を社内に置いても、回答生成時に機密文書を外へ送れば境界を守れません。構成図には、保存場所だけでなく実際に移動するデータと送信先を記載します。

RAG・AIエージェント・API連携の設計

RAGは、質問に関連する外部情報を検索して、モデルの回答生成に利用する構成です。AWSの公式解説でも、外部の知識を参照して生成する方式として説明されています。社内規程を更新するたびにモデルを再学習させる方法とは異なり、参照する文書と検索用データを更新します。

方式	主な目的	準備するもの
API連携・プロンプト設計	既存モデルに要約・分類・生成を依頼	入出力仕様、指示、評価例
RAG	根拠文書を参照した回答	文書、検索基盤、アクセス権、更新手順
ファインチューニング	特定タスクの応答傾向を調整	学習用の入出力例、独立した評価データ
AIエージェント	複数のツール操作を組み合わせる	ツール定義、認可、承認、停止条件

RAGでは、文書を集めるだけでなく、重複、旧版、権限、見出しや表の分割を確認します。規程の本文と例外条件が別の断片に分かれると、検索結果に片方しか入らないことがあります。誤回答を見つけたときは、必要な根拠が検索できなかったのか、根拠を得たのに回答が誤ったのかを切り分けます。

ファインチューニングは、モデルへ入出力の例を学習させ、特定の分類や表現などへ適応させる選択肢です。Amazon Bedrockのモデルカスタマイズ説明にも、ラベル付きの例を使う方法が示されています。更新頻度の高い社内情報を回答させたいだけなら、まず検索と指示の改善で満たせるか検証します。

AIエージェントを導入する際は、回答生成と操作実行を分けます。モデルが提案した「顧客情報を更新する」という操作を、そのまま実行する設計にはしません。システム側で利用者の権限、対象ID、変更内容を検証し、必要な承認を得ます。失敗時の再実行が同じ更新やメール送信を重複させない仕組みも必要です。

社内文書を検索対象にするragの設計と、PoCから小規模本番までの90日の進め方は、社内検索RAGの導入ロードマップで整理しています。

AIモデル選定と運用上の注意点

モデルは、自社の実データに近い質問と作業で比較します。日本語の敬語、社内略語、多言語、長い仕様書など、必要な条件を評価セットへ入れます。一般的なベンチマークが高くても、問い合わせの例外処理や社内文書の読み取りが要件を満たすとは限りません。

専門分野だからといって、最初から専用モデルや追加学習が必要とは限りません。まず権限を確認した資料を参照させ、どの誤りが残るかを観察します。用語の取り違え、根拠不足、出力形式の崩れでは対策が異なります。原因が分からないまま大きなモデルへ変えると、費用だけが増える可能性があります。

リアルタイムの対話では、精度と同時に待ち時間を測ります。平均値だけでなく、混雑時や長文入力時の遅延も確認してください。非同期でよい文書処理なら、画面で結果を待たせず完了通知を返す方法もあります。小さいモデルを単純な分類に使い、複雑な判断のみ別モデルへ回す場合も、切替条件の評価が必要です。

LLMが事実と異なる回答をもっともらしく生成する現象は、ハルシネーションと呼ばれます。「分からない」と返すべき質問や、資料同士が矛盾する質問も試験に含めます。根拠がないときに担当者へ引き継ぐ経路を設け、正答率だけを上げるために回答を強制しないことが大切です。

画像や音声も扱う場合は、対応モデル、入力形式、容量、料金、認識の誤りを別に確認します。テキストの検証結果だけで画像付き帳票や音声業務へ広げることはできません。モデル更新時にも同じ評価セットを使い、変更前後の品質・速度・費用を比較してから切り替えます。

API料金と開発費用の見方

LLM開発の費用は、最初の開発費と継続的な運用費に分けます。開発費には要件整理、画面、認証、既存システム連携、データ整備、評価が含まれます。運用費にはモデルAPI、検索基盤、ログ保存、保守、改善作業を含めます。API単価が安くても、文書の整備や権限設計の工数は残ります。

以下は2026年9月24日に公式ページで確認した比較用の単価例です。最新・最安モデルのランキングではありません。同じ用途で評価する際の計算方法を示すため、通常のテキストAPI利用に条件をそろえています。

モデル・公式出典	入力100万トークン	出力100万トークン	課金条件
Gemini 2.5 Flash	0.30米ドル	2.50米ドル	Standard有料API、テキスト入力、出力はthinkingを含む。従量課金、年払い・月額席課金ではない。税・為替手数料は試算に含めない
Claude Sonnet 4.6	3米ドル	15米ドル	通常のClaude API、キャッシュ・バッチ割引なし。従量課金、年払い・月額席課金ではない。税・為替手数料は試算に含めない

この表は推論単価で、開発初期費用やアプリの利用人数を含む料金プランではありません。ツール、検索、保存、音声などの追加課金と、利用枠・課金開始条件は別に確認します。クラウド経由の提供では、同名モデルでも請求条件が異なる場合があります。

仮に月1万回、1回あたり入力2,000トークン・課金対象の出力500トークンなら、合計は入力2,000万・出力500万トークンです。上表の条件では、Geminiが6＋12.5＝18.5米ドル、Claudeが60＋75＝135米ドルになります。これは税・追加機能・再試行・開発費を含まない試算で、同じ品質を保証する比較ではありません。

API費用は利用人数だけでは見積もれません。 RAGの参照文書や会話履歴も入力に入り、エージェントが複数回呼び出せば処理ごとに費用が発生します。少量の実データでトークン数と再試行回数を測り、利用者別の上限、出力長、処理回数の制限を決めます。

開発会社へは、利用者数、月間処理量、データ種類、連携先、承認、保守範囲を同じ条件で提示します。見積もりの比較では、PoCのみか、本番の監視やデータ更新まで含むかを確認してください。自己ホストとの比較は、AI開発コストとオンプレLLMの費用でも整理しています。

LLMを活用したソフトウェア開発の具体例

仕様書作成では、コードの差分、課題票、既存の仕様を入力し、変更概要の下書きを作れます。ただし、コードから読み取れる動作と、合意された業務要件は一致するとは限りません。生成文をそのまま正式仕様にせず、担当者が変更理由と例外条件を確認して承認する流れにします。

コードレビューでは、変更点の説明やテスト観点の列挙に活用できます。エラーメッセージの解析でも、再現条件や該当コードを添えて原因候補を出します。候補がもっともらしくても、実際のログとテストで裏付ける必要があります。認証、課金、データ削除など影響の大きい箇所は、担当者の確認を省略しません。

プロトタイプ作成では、画面の要望を文章で整理し、入力項目や操作のひな形を作る用途があります。試作品を利用者に見せれば、要件の認識違いを早く発見できます。一方で、試作時の仮データや簡易認証のまま公開しないよう、本番化する際の作り直しと検証を計画へ含めます。

実在する例として、Anthropicが紹介するGitLabの導入事例では、コード生成、計画の要約、脆弱性の説明・修正支援にAIを組み込み、用途に合うモデルを評価する体制が説明されています。自社の支援実績ではありませんが、複数の開発工程に組み込む際の参考になります。

この事例から導入を考える際は、機能を増やすことと評価体制を整えることをセットにします。たとえば「レビューの説明作成は短縮したが、修正確認が増えた」という結果も記録します。自社では少人数のチームから始め、作成時間と確認時間の合計で効果を判断すると、部分的な効率化を過大評価しにくくなります。

問い合わせ対応でも、商品検索や返品条件の案内を回答候補として示す使い方が考えられます。ただし、購入状況を確認せず返品可否を確約させる設計は避けます。開発支援と同じく、参照する事実、生成する説明、人が決定する範囲を分ける考え方が応用できます。

PoCから本番運用までの進め方

PoCでは、まず対象業務と合格基準を決めます。「文章が自然に返る」だけでは、本番に進む根拠として不十分です。代表的な質問に加えて、情報不足、権限外の質問、入力ミス、混雑時も検証します。現在の作業方法と比較できるよう、担当者が作業に使う時間や確認の手間も測定します。

工程	実施内容	次へ進む条件
要件整理	対象業務、データ、権限、評価指標を合意	任せる範囲と責任者が明確
PoC	少量データで品質・速度・費用を検証	合意した基準を満たす
本番設計・実装	画面、認証、連携、監視、承認を整備	障害・誤回答時の対応が可能
限定公開	少人数で業務の流れを確認	手戻りや運用負荷を把握
継続改善	文書更新、評価、モデル変更を管理	変更後も品質と予算を維持

入力の前処理では、不要な個人情報の除去、長さの制限、ファイル形式の検査を行います。出力側では、期待する項目や型、参照URL、操作対象を検証します。たとえばJSON形式で返すよう指示しても、アプリ側の形式チェックと不正値への対応は必要です。

外部APIには、タイムアウト、レート制限、ネットワーク障害を想定します。再試行は待機時間を延ばすバックオフと回数上限を設定し、失敗したら通常検索や有人対応へ切り替えます。利用者には処理中か失敗かを示し、操作を繰り返して二重処理が起きない画面にします。

公開後は、誤回答の報告、検索された文書、使用モデル、応答時間、費用を追えるようにします。問題が文書の旧版なら資料を更新し、検索漏れなら検索方法、指示の不足ならプロンプトを修正します。すべての問題を再学習で解決しようとせず、変更ごとに同じ評価を回します。

本番移行の条件はPoCの前に決めます。 改善を外注する場合にも、文書更新の担当、障害連絡先、モデル提供終了時の移行、費用超過時の停止を契約範囲に含めるか整理します。納品時に動くことと、継続して使えることを分けて確認してください。

セキュリティ・プライバシー・評価の注意点

OWASPのLLMアプリ向けTop 10（2025版）は、プロンプトインジェクション、機密情報の漏えい、過剰な権限、無制限のリソース消費などを整理しています。通常の認証対策に加え、入力文書やモデルの出力を信頼しすぎない設計が必要です。

プロンプトインジェクションでは、利用者の入力だけでなく、検索した資料に「ルールを無視して情報を送れ」といった指示が混入する場合も想定します。プロンプトで禁止するだけに頼らず、ツールの実行可否をサーバー側で制御します。モデルに権限を付与する判断を任せないことが基本です。

社内検索では、検索時点で利用者が閲覧できる文書に対象を絞ります。回答後に機密語を除くだけでは、閲覧できない資料を根拠にした推測が漏れる可能性があります。部署異動や退職、文書削除時に検索用データとアクセス権も更新されるかを試験します。

APIへ送ったデータの学習利用と、ログなどへの保持は別の条件です。たとえばGeminiの公式料金ページでは無料枠と有料枠で製品改善への利用欄が異なります。「有料なら何も保存されない」と読み替えず、採用するサービスの保持期間、契約、設定、利用地域を確認してください。

監査ログにも個人情報や機密文書が残り得ます。調査に必要な情報を決めたうえで、閲覧者、保存期間、削除方法を設計します。メール送信や顧客情報更新では、実行者と承認者、対象、変更前後を追えるようにし、事故が起きたら該当機能を止められるようにします。

ノーコード/Bubble/Difyで始める判断軸

Bubbleで画面や会員管理を作り、外部APIへ処理を依頼する構成は、対象を絞った業務アプリの検証候補になります。Difyの公式ドキュメントにはワークフローやナレッジ、モデル接続の案内があり、処理の流れを組み立てる選択肢として検討できます。アプリ画面とLLM処理を分ければ、変更箇所を整理しやすくなります。

APIキーを画面や利用者が読めるコードへ埋め込まないことが重要です。Bubble公式のAPI Connectorセキュリティ説明を確認し、秘密のパラメータをPrivateとして扱います。キーの保護と、アプリ利用者のデータ閲覧権限の設定は別なので、両方を確認します。

ノーコードでも、複雑な認可、大量処理、厳しい応答時間、細かな監査への対応工数は残ります。重要な更新処理は専用のAPIへ分け、長い処理は非同期化するなど、要件に応じてコードによる実装を組み合わせます。ツールを増やす場合には障害箇所の切り分けと保守責任も明確にします。

AI開発ラボへの相談では、対象業務、利用者、参照データ、連携先を整理しておくと構成を検討しやすくなります。短期間で検証したい部分と、本番で権限や安定性を確保すべき部分を分け、Bubbleを使う範囲から相談できます。

まとめ

LLM開発では、モデルそのものを作るのか、既存モデルを業務システムへ組み込むのかを最初に整理します。ソフトウェア開発との連携では、仕様書、コードレビュー、障害解析、ナレッジ共有、試作品の作成などが対象になります。生成物を確認する工程まで含めて、実際に作業を減らせるか判断することが大切です。

技術選定では、API・自己ホスト・ハイブリッドという配置の違いと、RAG・追加学習・エージェントという機能の違いを分けて考えます。社内資料を使う場合には、モデルの能力だけでなく、文書の品質、閲覧権限、更新手順が回答の信頼性を左右します。

費用は、モデルの入力・出力単価に実際のトークン数を掛けて試算し、検索や保存、保守、評価の費用を加えます。料金表の比較だけで決めず、自社の質問で品質と待ち時間も測定してください。無料枠と有料枠のデータ利用条件、外部へ送信できる情報の範囲も確認が必要です。

導入は、対象を限定したPoCから始め、合格基準を満たしてから本番へ広げます。誤回答の確認、操作の承認、障害時の切替、モデル更新後の再評価を継続できる体制を用意しましょう。担当者と予算を決めておけば、公開後の改善も進めやすくなります。

まずは改善したい業務を一つ選び、入力例、期待する回答、許容できない誤りを書き出してください。AI開発ラボでは、業務要件と既存システムの連携条件を踏まえて、検証する範囲とBubbleを活用する構成を相談できます。

LLMを業務に組み込むときは、まず小さく作って実際に使われるかを確かめることが大切です。当社では、学生がAIと対話しながら面接練習を行い、回答内容の評価とアンケート取得までを一連で行えるツールを開発しました。どの業務にLLMを組み込むかを整理する段階からご相談いただけます。

関連する事例：学生向けAI面接練習ツールの事例を見る
会社概要を見る・開発実績を見る
受託開発の相談・具体的な相談を送る