LangChainのシステムを発注・外注するときは、業務の目的とKPIを決め、RFPで条件をそろえてから、PoCの評価を経て本番へ進めます。この順に進めると、安全な運用につながります。全体像はLangChainのシステム開発の完全ガイドでも確認できます。
▼全体ガイドの記事
・LangChainのシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
LangChainシステム発注前の整理項目
発注する側は、LangChainで何ができるかよりも、自社の業務をどの品質で変えたいのかを、先に整理しておく必要があります。
社内規程の検索と、顧客情報を使った見積作成・承認・基幹登録では、必要な設計もテストも異なります。さらに、どこまでを誰が受け持つかという責任分界も変わります。
業務課題とKPIの設定
導入後の効果を測るため、改善したいことを数値で表せる業務KPIに置き換えます。
- 回答時間：問い合わせの一次回答にかかる時間を短くする
- 検索時間：担当者が社内規程を探す時間の削減
- 確認漏れ：申請内容の確認漏れの減少
回答率だけを目標にすると、根拠のない回答や、拒否すべき質問への回答まで増えるおそれがあります。
そのため、評価軸には根拠提示率と拒否率を含めます。応答時間や1件当たりの費用も、評価の対象にします。
対象業務は、最初から全社へ広げず、1部門・1データソース・1利用シナリオに絞っておくと、結果の良し悪しを判断できます。
機密度が低く、読み取り中心で、失敗時に人が確認できる業務は、PoCの候補になります。一方で、送金や契約締結、顧客への自動送信では、初期の段階から承認と監査ログを要件に含めます。
LangChain・RAG・LangGraphの役割分担
基盤ごとに役割が違うため、要件では、検索、処理の状態管理、評価と監視のどこに各基盤を使うかを切り分けます。
- LangChain：プロンプト、モデル接続、RAG、ツール呼び出し、構造化出力を組み合わせるアプリケーション層
- RAG：社内文書を検索し、回答の根拠をLLMへ渡す仕組み
- LangGraph：状態を持つ処理や条件分岐、再試行、人の承認を組み込む場合の候補
- LangSmith：トレース、評価データセット、プロンプト検証、品質・遅延・コストの監視
文書検索が中心であれば、RAGを軸に要件を組み立てます。そうすると、過剰なエージェント開発を避けられます。
委託先には、この役割分担に沿って、LangChainで実装する処理、LangGraphで管理する状態、LangSmithまたは代替基盤に残すログと評価を、提案書に記載してもらいます。
LangChainの発注形態の選び方
発注形態は、クラウド型、OSSを自社環境に組み込む形態、段階的な外注の3つに分けて考えます。
LangChainは、LLMや業務APIなどを組み合わせて使う開発基盤です。そのため、形態は機密性と内製化方針を見たうえで、既存システムと運用責任から選びます。
クラウドサービスを組み合わせる形態
クラウド型で見積を取る場合は、初期設定に加えて、データの保存場所とネットワーク境界も確認しておきます。
- サービス構成：Amazon Bedrock、Azure、Google CloudなどとLangChainを組み合わせた構成
- 設定と統制：IAM、ログ保存、ネットワーク境界を含めた設定
- 課金管理：従量課金の上限と、利用量別の試算の提示
クラウド型は、短期間で検証しやすく、モデルや検索基盤も交換しやすいという特徴があります。
AWSは、LangChainをBedrockやKendraなどと組み合わせた構成を紹介しています。SageMakerやLLMを含むこの構成は、企業データを活用する例です。
紹介の出典は、AWS「LangChainとは何ですか?」で、2026年8月に確認されています。
利用が増えると費用が上がる可能性があるため、見積の前提には月間質問数やピーク時の同時実行数を置きます。1回答当たりの呼び出し回数や埋め込み更新頻度も、前提に加えます。
月額は、低負荷・通常・繁忙の3パターンで試算してもらいます。
国外保管が許容されない場合は、リージョンや閉域接続、セルフホストの有無も確認します。
OSSを自社環境で運用する形態
機密情報を外部に送りにくい場合や、認証とデータ基盤を細かく制御したい場合に、この形態を検討します。
- 配置先：自社クラウド、閉域環境、オンプレミス
- 継続運用：更新、脆弱性対応、モデル接続、監視、バックアップ、障害復旧
- 納品対象：ソースコード、プロンプト、評価データ、ベクトルDB設定、IaC、運用手順
自由度が高い一方で、運用は発注側か委託先が継続して担う必要があります。
モデルやベンダーのAPIに処理を固定しすぎると、価格改定や仕様変更のたびに再開発が必要になります。そこで、モデル接続部を交換可能にする設計を、RFPで指定します。
PoCと本番を分ける段階的な発注形態
初回発注では、企画・要件整理、技術検証、MVP開発、本番開発、保守を一括で契約せず、段階に分けて発注します。
- 最初の契約：対象データで回答品質と費用を測る
- 本番契約：認証、権限、監査ログ、SLA、運用移管を含める
- 終了条件：継続・中止・再設計の判断基準を合意する
PoCの成果を見てから本番範囲を決めると、不要なエージェント機能を先に作るリスクを減らせます。
終了条件には、評価用質問100件に対する根拠提示率や拒否率を使えます。目標応答時間や月額利用料の試算誤差なども、基準にできます。そのうえで、検証結果と評価データを次の発注に引き継ぎます。
LangChainシステムの発注・外注の進め方
まず社内で目的と前提をそろえ、RFPを渡してから、提案と見積を同じ条件で比べます。
本番で使える品質かを見極めるには、技術デモ以外の材料が必要です。そこで、発注側にも委託先へ質問できる体制を用意します。特に、データと権限の扱いや、評価と運用の方法を問える人が必要です。
RFPの材料となる業務・データの整理
RFPに書く条件は、各社が同じ前提で見積を出せるよう、次の項目で整理します。
- 業務：対象業務、利用者、利用シーン、現行フロー、時間やミスの課題
- データ：文書の種類、件数、更新頻度、最新版の判定方法、部門別の閲覧権限
- 連携と制約：既存API、認証方式、許容するデータ保管場所
文書は件数だけでなく、PDFや表、画像などの割合も記します。スキャン文書も含めます。
RFPに書ききれない条件は、確定事項、希望事項、提案事項に分けておきます。そうすれば、各社が異なる前提で安い見積を出す事態を避けられます。
例えば、個人情報を国外へ保管しないことは確定事項で、回答時間は目標値、ベクトルDBやモデルの種類は提案事項です。
PoCの評価データによる判定
PoCでは、委託先が用意した都合のよい質問に加えて、実際の問い合わせや過去の失敗例を匿名化し、評価データにします。
- 期待回答：質問ごとの回答と、引用が必要な根拠
- 回答制約：答えてはいけない条件と許容する表現の幅
- 品質確認：根拠の正しさ、文書の新しさ、権限外情報の有無
正解率だけで評価を終えず、回答の裏付けまで見ておく必要があります。
業務APIは、読み取りと更新を分けたうえで、更新の前に人の承認を置く構成から始めます。
ツールの引数はスキーマで検証し、権限のない利用者には、ツールそのものを表示しません。PoCの段階でも、プロンプトインジェクションや機密情報の漏えい、過剰な自律実行をテストします。
本番移行と運用移管の条件
本番移行の前に、アクセス制御や運用機能、納品物の条件を定めておきます。
- 本番要件：SSO、ロール別権限、テナント分離、監査ログ
- 運用要件：バックアップ、障害通知、コスト上限、ログ保存期間、回帰テスト
- 納品物：構成図、API仕様、プロンプト、評価データ、テスト結果、IaC、監視と障害対応手順
LangGraphをLangSmithへデプロイする場合、公式資料はGitHub連携とCLIによる方法を案内しています（出典: LangChain公式「Deploy on Cloud」、2026年8月確認）。
これらを使う場合は、まずリポジトリ権限とシークレット管理を決めます。そのうえで、環境変数と承認済みリリースの手順を定めます。
納品物には、データ削除の手順とライセンス一覧も含めます。
担当者が退職しても運用が続く状態を、完成条件に置きます。
運用後の問い合わせ窓口や改善提案、モデルとライブラリの更新担当は、契約前に決めておきます。
契約形態とLangChainシステムの費用相場
LangChain単体の日本向け受託開発価格を網羅した公的な統計は、確認できません。
そこで、以下の金額は、NotebookLMの業務システム一般の相場、人月単価、工程配分に基づいて算出しています。LLMやRAGに加え、評価とセキュリティの追加工数を加味した、2025〜2026年時点の編集用推定です。
この金額は、同じ条件で複数社に見積を依頼するための初期目安として使います。特定の金額を約束するものではありません。
要件定義・PoC・開発の契約形態の使い分け
工程ごとに、成果物や要件の確定度に合う契約形態を選びます。
- 準委任：要件が固まっていない企画や要件定義、調査・整理・助言
- 請負：完成する成果物と受入条件を定義できる設計・実装
- 段階契約：要件整理・PoC、確定したMVP実装、保守・改善を分ける
LLMの回答品質は、データやモデルの変更で左右されます。そのため、「正解率100％」のように制御しきれない結果を、完成条件にしないよう注意します。
IPAのアジャイル開発向けモデル契約書は、機能や優先順位が変わる開発について、準委任を前提にしています。
IPAは、要件定義の契約基本形を準委任とする考え方や、確定度に応じた多段階の契約を示しています（出典: IPA「情報システム・モデル取引・契約書（アジャイル開発版）」「ユーザのための要件定義ガイド」、2026年8月確認）。
規模別の初期費用レンジ
初期費用と期間は、システム規模や機能範囲に応じた推定レンジで見ておきます。
- 技術検証・小規模PoC：300万〜800万円、1〜3か月
- 社内文書RAG・FAQ：800万〜2,000万円、3〜6か月程度
- CRM・基幹連携エージェント：2,000万〜5,000万円、6〜12か月程度
- 全社向け基盤：5,000万〜1.5億円以上、12か月以上の可能性
技術検証は、1つのデータソースとモデル、基本画面、評価用データを想定しています。
社内文書RAGの場合は、取り込みと権限別の検索、引用表示を含みます。なお、SSOや管理画面、評価も含めます。
CRM連携では、複数ツールと承認フローが必要です。加えて、監査ログと負荷試験も必要になります。
全社基盤は、複数の業務やモデルを扱う想定です。閉域またはハイブリッドの基盤を組み、LLMOpsやSLAまで整備する想定です。
各規模の金額は、いずれも案件範囲から算出した推定です。
LangChainのライセンス価格ではありません。
一般的な業務システムの人月単価は、PMが90万〜150万円、SEが65万〜110万円です（出典: NotebookLM「業務システム全般_15」Q&A、2026年）。
PGは50万〜90万円、テスターは45万〜80万円程度が目安です（出典: NotebookLM「業務システム全般_15」Q&A、2026年）。
LangChain案件では、画面やAPIに加えて、プロンプトや検索精度も必要です。さらに、評価データやガードレール、モデル変更時の回帰テストも必要になります。このため、単純なチャット画面より費用が高くなりやすいです。
月額費用と保守費用の内訳
ランニング費用は、利用基盤や保守作業を含めて見積もります。
- 利用料：LLM入出力トークン、埋め込み、ベクトルDB、アプリ基盤
- 基盤費：ストレージ、ネットワーク、監視、バックアップ
- 保守：更新、脆弱性対応、評価、障害・問い合わせ対応
小規模なら月10万〜50万円、中規模なら月50万〜200万円が目安です。
常時稼働で大量の文書や高頻度のエージェント処理を行う場合は、月200万円を超えることもあり得ます。なお、これは編集用の推定です。
利用者数だけでなく、質問数やピーク時の同時実行数を前提に置きます。文書の更新頻度や1回当たりのツール数も、前提に入れます。
LangSmith公式料金ページでは、Developerは1席無料で月5,000ベーストレースまでです。Plusは1席39ドルで月10,000ベーストレースまでです。Enterpriseは個別見積と案内されています。
表示例はLangChain Compute Unitが1単位1.50ドル、Storage Unitが1単位1.00ドルです（出典: LangChain公式「Plans and Pricing」、2026年8月確認）。これはLangSmithの料金で、LLMやクラウド、開発会社の保守費とは別に計上します。
保守費用は、一般的な業務システムでは初期開発費の年15〜25％が目安とされます。
LangChainでは、保守の範囲を細かく定義します。対象には、プロンプト変更や検索インデックス更新、評価データによる回帰テストが入ります。そのうえで、月額に含む範囲を契約書に記載します。
LangChainの委託先の選び方と見積比較
委託先は、利用経験だけでなく、業務要件を定義し、本番運用まで担えるかで選びます。
公開事例を見るときは、生成AI全般の事例と、LangChainやLangGraphを使った事例を分けて考えます。検索評価や業務APIの権限設計まで確かめるには、技術キーワードの一覧より、事例の中身を見る必要があります。
業務と成果物で見る実績
候補会社には、今回の業務に近い実績の有無と、担当体制や再委託の範囲を確認します。
- 近い業務：社内文書検索、営業支援、問い合わせ対応、在庫・申請連携
- 成果物と評価：可能であれば匿名化された構成図、評価方法、回答品質の測定項目、リリース後の改善方法
- 体制と責任：担当者、再委託先、情報アクセス、事故時の責任分界
数字だけの効果を聞くより、使ったデータやモデル、人の承認箇所を聞くほうが、実現性を比べやすくなります。
体制では、PM、業務要件、LangChain・LangGraphの実装を担う人が誰かを確認します。加えて、データと検索、クラウドとセキュリティ、運用を誰が担うかも見ます。
再委託がある場合は、会社名と担当範囲を明らかにします。情報へのアクセスと事故時の責任も、確かめます。また、提案時の責任者が本番まで関わるかも見ておきます。
同じ前提と内訳でそろえた見積の比較
見積は総額だけでなく、範囲や成果物、期間をそろえて比べます。さらに、体制や前提、除外項目も、同じ基準にそろえます。
- 開発内訳：要件定義、データ整備、RAG、プロンプト、画面・API
- 品質・運用内訳：認証、権限、テスト、評価、リリース、運用移管
- 外部利用料：LLM、埋め込み、ベクトルDB、クラウド、監視、LangSmith
作業は、行単位に分けてもらいます。PoCと本番の費用がまとめて書かれている場合は、どこまでを検証できるのかを確かめます。
月間質問数が1,000件、1万件、10万件の場合の費用を質問します。なお、モデル変更時の差額、ログ保存期間、為替変動の扱いも聞きます。
従量課金に上限通知や自動停止がない場合は、本番前に予算管理の方法を追加します。
契約書で定めるデータ・知財・責任分界
契約では、データや知財の扱いと、リスク対応の責任範囲を決めておきます。生成AIの出力を、そのまま成果物として扱わないためです。
- データ管理：入力データ、学習利用、ログ、個人情報、第三者送信、削除
- 知的財産：著作権、プロンプト、評価データ、チューニング結果、ソースコード
- 責任分界：脆弱性対応、事故報告、IaCと運用手順の所有権・利用権
経済産業省のAI事業者ガイドラインは、2026年3月31日に第1.2版が掲載されています（出典: 経済産業省・IPA・AISI「AI事業者ガイドライン検討会」、2026年）。
同ガイドラインを踏まえ、リスク管理や透明性を実務に落とします。プライバシーとセキュリティ、説明責任についても、実務へ落とし込みます。そのうえで、アクセス制御や承認ログ、評価記録を定め、インシデント対応の手順も決めます。
OWASPは複数のリスクを挙げています（出典: OWASP「Top 10 for LLM Applications 2025」、2025年）。その対象には、プロンプトインジェクションや機密漏えい、不適切な出力処理があります。ほかにも、サプライチェーンや過剰なエージェンシー、無制限消費が挙げられます。
委託先には、各リスクのテストケースと、失敗時の制限や人への引き継ぎ方法を回答してもらいます。
LangChainの外注での失敗防止策
失敗につながりやすいのは、デモだけを見て本番を発注すること、OSSを無料と考えること、人の印象だけで品質を測ることです。
PoCで動いた構成が、本番に必要な認証・権限・監査・障害対応まで備えているとは限りません。そのため、契約前に失敗時の動作と運用責任も確かめます。
ハルシネーション対策の設計と記録
RAGでも、検索対象が古い場合や、文書の分割が不適切な場合、質問の根拠が不足する場合には、誤答が起きます。
- 回答制御：答えられない場合に拒否する条件と根拠の引用
- 文書管理：更新検知と評価データの再実行
- 品質目標：対象業務ごとに許容範囲を定める
委託先には、「RAGなので正確」という説明に頼らず、上記の対策を設計してもらいます。
品質が下がったときに原因を追えるよう、質問や検索結果、プロンプト版を記録します。さらに、モデル名とツール呼び出しを残します。回答と利用者評価も記録します。
記録では、個人情報や機密情報に配慮します。
評価データが納品されない場合、モデルやベンダーを変えたときに、品質を比べられません。
モデル変更と運用費増加への備え
モデル変更と運用費の増加に備えて、運用条件を次のとおり整理します。
- 更新影響：モデルや関連ライブラリの更新で出力形式や料金、コンテキスト長が変わる可能性と、品質や月額費用への影響
- 変更対応：更新情報の確認、検証環境での回帰テスト、ロールバック、緊急時の固定バージョン運用を、開発会社とどこまで行うかの取り決め
- 費用要因：質問数のほか、長文書の参照、モデル・ツールの連続呼び出し、長期ログ保存が運用費を押し上げる
- 費用管理：モデルの使い分け、キャッシュ、検索対象の絞り込み、トークン上限、予算アラート、自動停止を設計し、月額上限と業務影響を管理します。
内製化と引き継ぎの条件
外注しても、業務の正解や優先順位を決める責任は自社に残ります。
- 意思決定者：業務、情報システム、セキュリティ、法務・コンプライアンスの各部門
- 進行管理：定例会議、課題管理、変更承認の方法
- 引き継ぎ：移管回数、マニュアル、レビュー、研修、管理者権限
委託先に任せきりにすると、完成後に使われないシステムや、現場のルールに合わない回答が残るおそれがあります。
契約書には、開発環境の再現方法と、委託終了時のデータ返却・削除も記載します。
移管条件を決めておくと、将来の委託先変更や内製化を選べるうえ、長期コストも管理できます。
LangChainのシステム発注でよくある質問
発注時の費用・契約・委託先・運用に関する疑問を、判断に使える形で答えます。
LangChainのシステム開発はどの会社に発注すればよいですか？
業務要件とデータ整備を説明できる会社を選びます。認証や権限、評価まで説明できるかを確かめ、クラウドや保守についても見ます。
近い業務実績と担当体制を、同じRFPで比べます。そのうえで、評価方法と納品物、再委託の範囲を見ます。
モデル変更時に、誰がどこまで責任を負うかも確かめます。
LangChainのシステム発注費用は無料になりますか？
LangChainはOSSですが、システム全体が無料になるわけではありません。設計や実装、テストに費用がかかるほか、次の費用も必要です。
- LLMのAPI・埋め込み・ベクトルDB：利用にかかる費用
- クラウド・監視・保守：運用に必要な費用
技術検証は300万〜800万円、社内文書RAGは800万〜2,000万円、業務API連携は2,000万〜5,000万円が初期目安です。ただし、実際の金額は要件と利用量から見積もります。
要件が決まっていなくてもLangChain開発を発注できますか？
発注は可能ですが、本番開発を一括で依頼せず、企画・要件整理や技術検証を、準委任か段階契約で依頼します。
まず、対象業務と利用データ、評価用の質問を整理します。次に成功条件を定め、PoC後に本番範囲を決めます。
要件が未確定のまま固定価格を求めると、追加費用や仕様変更が起きやすくなります。
LangChainとLangGraphはどちらを発注要件にすべきですか？
読み取り中心の検索や一問一答なら、LangChainとRAGを中心に検討します。一方で、状態管理や条件分岐、再試行が必要な場合は、LangGraphが候補になります。ツールの利用や人の承認を含む場合も、LangGraphを候補に入れます。
製品名を先に決めず、業務フローと安全要件をRFPに書きます。その後、採用する理由と代替案を提案してもらいます。
まとめ
発注時は、業務KPIと対象データ、RAGかエージェントかの判断を決めます。そのうえで、権限と承認、評価を定め、本番運用と納品物も含めてRFPにまとめます。
同じ前提で複数社の提案と見積を比べ、技術だけでなく、業務で安全に使えるかを確かめます。
発注前に確認する要点
費用の推定レンジは、PoCが300万〜800万円、社内文書RAGが800万〜2,000万円、業務API連携が2,000万〜5,000万円です。
金額は、データ量や連携数、セキュリティで調整します。さらに、評価や利用量、保守も金額を左右します。
契約では、要件定義・検証を準委任とし、完成条件を定義できる開発は請負にします。改善・保守は、準委任を検討します。
次に作るべき資料のRFP
対象業務と利用者、データ、現行課題を、1枚にまとめます。加えて、成功指標やセキュリティ制約、発注範囲も書き込みます。
RFPには、PoCの評価方法と本番移行の条件を加えます。また、納品するものは、ソースコードや評価データ、IaCとします。
保守とモデル変更の責任分界も、RFPに加えます。安全に使い続けられるかを基準に、委託先を選びます。
▼全体ガイドの記事
・LangChainのシステム開発の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。