社内でChatGPTを試してみて「これを使ったシステムを作れば業務が効率化できる」と感じた方は多いでしょう。顧客対応のチャットボット、社内FAQの自動応答、契約書のレビュー補助——LLMを活用したシステムには多様な可能性があります。
いざ開発会社に問い合わせてみると、「RAGにしますか、それともファインチューニングにしますか？」「プロンプトの管理責任はどちらになりますか？」「API費用の上限設定はどうしますか？」といった質問が飛んできます。通常のシステム開発では聞かれなかった言葉ばかりで、どう答えればよいか途方に暮れてしまいます。
LLMシステムの発注が難しいのは、従来のシステム開発の常識が通じない部分が多いからです。仕様を決めれば動作が確定する通常開発と異なり、LLMには「同じ入力でも出力が変わる」という本質的な特性があります。この違いを理解していないまま発注を進めると、完成後に「想定と違う」「費用がどんどん増える」といったトラブルに直面しかねません。
本記事では、LLMシステム発注の前に理解しておくべきこと、そして開発会社との打ち合わせで確認すべき10の質問を整理します。技術の詳細よりも「発注者として何を把握すべきか」に焦点を当てて解説しますので、LLM特有のリスクと費用構造を理解し、安心して発注判断を進めるための参考にしてください。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
LLM活用システムとは——通常のシステム開発と何が違うのか
LLMシステムの発注を検討する前に、まず「通常のシステム開発と何が根本的に違うのか」を理解することが重要です。
確定的なシステム vs 確率的なAI出力
通常のシステム開発では、「ボタンAを押すと処理Bが実行され、結果Cが返る」という確定的な動作が基本です。仕様書通りに実装されれば、同じ操作をすれば必ず同じ結果が得られます。品質の評価基準も比較的明確です。
LLMシステムは根本的に異なります。LLM（大規模言語モデル）は確率的な生成を行うため、同じ質問を10回投げかけても、微妙に異なる10通りの回答が返ってくる可能性があります。これはバグではなく、言語モデルの本質的な仕組みです。
この特性は「品質の評価・保証」に直接影響します。通常のシステムなら「仕様通りに動くか否か」でテストできますが、LLMシステムでは「回答の品質が十分か」を判断する基準の設計自体が必要になります。発注者は「どのくらいの精度を目標とするか」を開発前に決める必要があります。
外部APIへの依存と自社コントロールの範囲
多くのLLMシステムは、OpenAI・Google・Anthropicなどが提供するAPIを利用して構築されます。これは、システムの中核となる「AIの頭脳」が自社サーバーではなく外部サービス上にあることを意味します。
外部APIへの依存にはいくつかのリスクが伴います。まず費用の変動リスクです。APIの利用量に応じて課金される仕組みのため、ユーザー数が増えれば費用も増えます。次にモデルの変更リスクです。APIプロバイダーがモデルをアップデートすると、システムの動作が変わる可能性があります。さらに、サービス停止・価格改定があった場合に影響を受けます。
これらは通常のシステム開発では意識する必要がなかったリスクです。発注時に「外部依存のリスクをどう管理するか」を確認しておく必要があります。
LLM特有の3つのリスクを理解する
LLMシステムには、通常のシステム開発にはないリスクが存在します。発注前に理解しておくべき代表的な3つのリスクを解説します。
ハルシネーション——AIは「それらしい嘘」をつく
ハルシネーション（幻覚）とは、LLMが事実と異なる内容を、あたかも正確な情報であるかのように自信を持って出力する現象です。「ChatGPTに質問したら存在しない法律条文を引用された」「存在しない企業名が回答に含まれていた」といった事例が実際に報告されています。
ハルシネーションが起きる根本的な原因は、LLMが「次の単語として確率的に最もありそうなものを生成する」仕組みにあります。正確性の確認よりも「それらしさ」が優先されることがあるのです。
最新のモデルでは、GPT-4oやClaude 3シリーズなどで誤り率が数パーセント以下に改善されています。しかし、ゼロにはなりません。特に医療・法律・金融などの専門分野では、誤情報が深刻なリスクをもたらします。
発注者として理解しておくべきことは、「ハルシネーション対策をシステム設計に組み込む必要がある」という点です。RAGの導入、出力の検証フローの設計、人間によるレビュープロセスの位置づけなど、対策の方針を開発会社と事前に確認することが重要です。
API費用の変動リスク——トークン課金の仕組みと対策
LLM APIはトークン（文字や単語の単位）に基づいて課金される仕組みです。GPT-4o（2025年時点）の場合、入力100万トークンあたり約2.5ドル、出力100万トークンあたり約10ドルです（OpenAI 料金ページ）。
小規模な利用では低コストですが、ユーザー数や処理量が増えると費用が急増します。例えば、月間1万件のユーザー問い合わせに対応するシステムで、1件あたり平均2,000トークン（入出力合計）を使用した場合、月間2,000万トークンとなり、費用は月数万円程度になります。しかし、プロンプトが長くなったり、コンテキストを多く渡すような設計にするとトークン数が大幅に増加し、予算を超過するリスクがあります。
対策として、トークン数の上限設定、キャッシュ機能の活用、軽量モデルとの使い分けなどが有効です。発注時に「費用の上限設定はどうするか」「トークン数の最適化はどう行うか」を確認することをお勧めします。
データ漏洩・プロンプトインジェクションのリスク
社内の機密情報（顧客データ・社内マニュアル・契約書など）をLLMに参照させる場合、データ漏洩のリスクを考慮する必要があります。
特に注意が必要なのがプロンプトインジェクションです。これは悪意のあるユーザーが特別な入力を行うことで、システムのセキュリティ設定を迂回したり、本来見せてはいけない情報を引き出そうとする攻撃手法です。OWASP（Webセキュリティの国際標準を定める組織）は、プロンプトインジェクションをLLMアプリケーションの最重要セキュリティリスクとして位置づけています（OWASP LLM Top 10）。
また、外部のAPIサービスに機密情報を送信することで、情報がAPIプロバイダーのサーバーに送られます。開発会社が利用するAPIの利用規約でデータの扱いがどうなっているかを確認することも重要です。
発注前に確認すべき10の質問
開発会社との打ち合わせで、以下の10の質問を確認することをお勧めします。各質問に「なぜ確認するか」の背景と「チェックポイント」を添えています。
品質・精度に関する確認
Q1. ハルシネーション対策としてどのような設計をしますか？
背景: ハルシネーションをゼロにすることはできません。どのレベルを許容するかの基準と、対策の方針を確認します。
チェックポイント: 「RAGで情報ソースを限定する」「出力に参照元情報を付記する」「人間によるレビューフローを設ける」など、具体的な対策が示されるかを確認します。「最新モデルを使うので問題ない」だけの回答は不十分です。
Q2. 精度の目標値はどのように設定・測定しますか？
背景: 「精度はどのくらいですか？」という質問に対して曖昧な回答しか得られない場合、品質管理が不十分な可能性があります。
チェックポイント: 本番環境と同じ条件でのテスト計画、精度評価の指標（正答率・不適切回答率など）の設定方針、テスト用データの準備方法を確認します。
Q3. 本番運用後に精度が低下した場合、どのような対応フローがありますか？
背景: LLMシステムは、社内データや運用環境の変化によって精度が変動する可能性があります。
チェックポイント: 監視の仕組み、精度低下の検知方法、改善対応の体制と費用感が説明されるかを確認します。
コスト・費用構造に関する確認
Q4. API費用はどのように試算されていますか？
背景: 見積もりに初期開発費用は含まれていても、API費用（ランニングコスト）の試算が不明確なケースがあります。
チェックポイント: 月間の想定クエリ数、1クエリあたりの平均トークン数、APIの単価に基づく月額費用の試算が示されるかを確認します。「使ってみないと分からない」という回答の場合は、少なくとも最悪ケースのシナリオを求めましょう。
Q5. API費用に上限設定の仕組みはありますか？
背景: 想定外のトラフィック増加や悪意のある大量アクセスにより、API費用が突発的に増加するリスクがあります。
チェックポイント: 月額上限の設定方法、上限到達時の動作（システム停止か制限か）、アラート通知の仕組みが確認できるかを確認します。
Q6. 保守・運用費用の内訳を教えてください
背景: LLMシステムには、通常のシステム保守に加え、プロンプトの調整、モデルの更新対応、精度改善などの継続的なコストが発生します。
チェックポイント: 月次・年次の保守費用の内訳、プロンプト調整の費用感（都度対応か定額か）、モデルアップデート時の対応費用の見積もり方を確認します。
セキュリティ・運用に関する確認
Q7. 社内データをAPIに送信する際のデータ保護対策はどうなっていますか？
背景: LLMに社内の機密情報を参照させる場合、そのデータがAPIプロバイダーのサーバーに送信されます。
チェックポイント: 利用するAPIのデータ保護ポリシー（学習への利用可否）、機密情報のマスキング・除去の仕組み、エンタープライズプランの利用可否（データ学習に使われないオプションがあるか）を確認します。
Q8. プロンプトインジェクション攻撃への対策はありますか？
背景: 悪意あるユーザーによるプロンプトインジェクション攻撃のリスクは、一般公開するシステムでは特に重要です。
チェックポイント: 入力値のバリデーション設計、システムプロンプトでの制約設定、権限制御の仕組みが説明されるかを確認します。社内向けの限定公開システムであっても最低限の対策は必要です。
Q9. AIの回答と業務上の最終責任の関係をどう整理しますか？
背景: AIの回答に誤りがあった場合、誰が責任を負うかを事前に整理しておく必要があります。JDLAが公開している「生成AI開発契約ガイドライン」では、AIの出力を業務に使用する際の責任分界点の明確化が推奨されています。
チェックポイント: 回答の最終確認が人間のフローに組み込まれているか、AIの出力は「参考情報」として位置づけられているかを確認します。
Q10. APIプロバイダーやモデルが変更・廃止された場合の対応方針はありますか？
背景: AIサービスの市場は変化が速く、現在利用しているAPIが将来的に変更・廃止される可能性があります。GPT-3.5が廃止されたように、モデルの廃止は実際に起きています。
チェックポイント: 特定のAPIに強く依存しない設計方針（抽象化レイヤーの設計）、代替APIへの移行計画の有無を確認します。
LLM開発の費用構造を知る——API費用と開発費用の内訳
LLMシステムの費用は「初期開発費用」と「ランニングコスト（継続費用）」の2つに大別されます。見積もりを正確に評価するために、両者の内訳を理解しておきましょう。
初期開発費用の内訳
初期開発費用は、主に以下の項目から構成されます。
- 要件定義・設計費用: システムの目的・精度目標・ユーザーシナリオの整理。LLMシステムでは特に「どのような質問に答えるか」「どの情報ソースを参照させるか」の設計が重要
- プロンプト設計費用: AIの動作方針を指示するシステムプロンプトの設計と最適化。テストと調整を繰り返す工程で、費用と時間がかかる
- データ整備費用: RAGを採用する場合、社内ドキュメントの整形・分類・ベクトルデータベースへの登録が必要
- システム実装費用: APIとの連携、UI/UX設計、既存システムとの統合
- テスト費用: 精度評価のためのテストデータ準備と評価実施
ランニングコストの内訳
ランニングコストは、主に以下の項目から構成されます。
- API利用費用: 最も変動しやすいコスト。利用量に応じて増減する
- インフラ費用: クラウドサーバー、ベクトルデータベースなどの基盤
- 保守・改善費用: プロンプトの調整、精度改善、バグ修正
- モデル更新対応費用: APIプロバイダーのモデル変更に伴う調整作業
PoC → 本番導入のコストフェーズ
多くのLLMシステム導入は段階的に進めることが推奨されます。
PoC（概念実証）フェーズ: 月50〜250万円程度の費用でシステムの有効性を検証。精度目標を達成できるか、費用対効果が見合うかを確認します。
本番導入フェーズ: PoCの結果を踏まえて本格開発。数百万円〜数千万円規模になることが多く、対応範囲・精度要件・セキュリティ要件によって大きく変動します（LLM導入の費用相場とコスト内訳）。
いきなり大規模な本番開発から始めるのではなく、PoCで仮説を検証してから本格投資するアプローチが、リスクを抑えた進め方です。
RAGとファインチューニング——発注者が押さえるべき違いと選択基準
開発会社との打ち合わせで必ず話題になる「RAG」と「ファインチューニング」について、発注者として判断に必要な最低限の知識を整理します。
RAGとは——外部データを参照させる仕組み
RAG（Retrieval-Augmented Generation：検索拡張生成）は、LLMが回答を生成する際に、あらかじめ用意したデータベース（社内マニュアル・FAQ・製品情報など）を検索して参照する仕組みです。
例えるなら「オープンブックテスト」のようなものです。AIが回答する際に「このドキュメントを見ながら答えてよい」という設定にすることで、AIが自分の知識だけで答えるよりも正確性が上がり、ハルシネーションの抑制にも効果的です。
RAGの特徴は、参照するデータベースをいつでも更新・追加できることです。新しい製品情報が追加された場合も、データベースを更新するだけでシステムに反映されます。
ファインチューニングとは——モデルを追加学習させる手法
ファインチューニングは、既存のLLMモデルに対して自社のデータで追加学習を行い、特定の用途・スタイルに特化させる手法です。モデル自体のパラメータを変更するため、一度学習させると特定の分野での精度が大幅に向上します。
「特定の業界用語を正確に扱いたい」「自社特有の文体・トーンで一貫した回答をしたい」といったケースに有効ですが、追加学習に相応のコストと時間がかかります。
判断基準の比較表
比較項目 | RAG | ファインチューニング |
|---|---|---|
初期コスト | 低〜中（データ整備が主なコスト） | 高（学習コストが発生） |
情報の更新 | 容易（データベースを更新するだけ） | 再学習が必要（コスト・時間がかかる） |
ハルシネーション対策 | 効果的（ソース情報を参照） | 学習データ品質に依存 |
向いているケース | 社内FAQシステム、ドキュメント検索、製品情報問い合わせ | 特定業界の専門用語処理、独自トーンの一貫維持 |
発注者に必要な準備 | 参照させるドキュメントの整理・整形 | 高品質な学習データの準備（数百〜数千件） |
多くの企業向けLLMシステムでは、最初にRAGを採用することが推奨されます。費用を抑えつつ、情報の更新も容易だからです。特定の精度向上が必要になった段階でファインチューニングを検討するアプローチが現実的です（RAGとファインチューニングの違い詳細解説）。
まとめ——LLMシステム発注で失敗しないために
本記事で解説した内容を「発注前チェックリスト」としてまとめます。
通常のシステム開発との違いを理解する
- LLMは確率的な生成を行うため、同じ入力でも出力が変わる
- 外部APIへの依存により、費用変動・モデル変更のリスクが生じる
- 品質の評価基準（精度目標）を発注者自身が定める必要がある
LLM特有の3つのリスクを把握する
- ハルシネーション: 対策の設計（RAG・レビューフロー）を確認する
- API費用の変動: トークン課金の試算と上限設定の仕組みを確認する
- データ漏洩・プロンプトインジェクション: セキュリティ設計を事前確認する
開発会社への10の確認質問を活用する
- ハルシネーション対策の具体的な設計は？
- 精度の目標値と測定方法は？
- 本番後の精度低下時の対応フローは？
- API費用の試算根拠は？
- API費用の上限設定の仕組みは？
- 保守・運用費用の内訳は？
- 社内データのAPIへの送信に関するデータ保護対策は？
- プロンプトインジェクション攻撃への対策は？
- AIの回答と業務責任の整理方針は？
- APIプロバイダー変更・廃止時の対応方針は？
LLMシステムは通常のシステム開発よりも不確実性が高い分野ですが、発注前に基礎知識とリスクを理解し、適切な確認を行えば失敗リスクを大幅に下げられます。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
