Amazon Bedrockのシステムを発注するときは、業務課題とKPI、データと権限を整理し、PoCで評価してから本番開発へ進みます。この順序が、現場で使える仕組みにつながります。
発注形態から委託先の選定まで、各段階で決めることを順に見ていきます。全体像は、Amazon Bedrockのシステム開発の完全ガイドもご覧ください。
▼全体ガイドの記事
・Amazon Bedrockのシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
Amazon Bedrockのシステムを外注する前の全体像
Amazon Bedrockを中心にしたシステムは、モデル、データ、アプリケーション、権限と安全性、運用の五つの層で構成されます。API接続だけを見た見積もりでは、データ整備や既存システム連携が抜ける可能性があります。
Bedrock本体以外に必要な構成要素
社内文書検索では、S3などの保存先とKnowledge Basesなどの検索基盤が要ります。さらに、回答画面と認証、ログ、更新処理も必要です。
CRMやSFAと連携する場合は、顧客や商談の情報を取り込むAPIが要ります。利用者ごとのアクセス制御やCRMへの書き戻しも必要になります。加えて、失敗したときに人が確認する手順も要ります。
Agents for Amazon Bedrockで案件更新やチケット起票を自動化する場合は、AIに実行権限を与えることになります。そのため、承認フローと監査ログも要件に含めます。
営業・CRM・MAで外注しやすい活用範囲
営業・CRM・MAでは、次のような業務を外注の対象として検討できます。
- ナレッジ検索：社内情報の検索
- 商談要約：商談記録や電話内容の要約
- 次回アクション：商談後の対応候補の抽出
- 問い合わせ対応：問い合わせへの一次回答
- 文書作成支援：提案書やフォローメールの下書き
最初から営業全体の自律化を目指すより、資料検索や商談後の入力で何分減らすかを先に決めておく方が、PoCの合否を判断しやすくなります。
AWS公式の中外製薬の事例では、Amazon Bedrockを中心とする生成AIアシスタントを2か月で開発し、約6,000人が利用しています。また、NTT西日本の営業支援AIボットは、Knowledge Basesで回答の根拠となるマニュアルページを示し、解決しない質問はヘルプデスクへつなぎます。
各社の基盤や体制は異なります。そのため、事例の納期や費用を、そのまま自社に当てはめないようにします。
Amazon Bedrockのシステムに適した発注形態
要件が曖昧な段階では、準委任型の企画やPoCから始めるのが現実的です。仕様と受入条件が固まったら、請負型の本番開発へ移ります。発注形態を要件の確かさに合わせて切り替えると、次のような流れになります。
- 要件が曖昧な段階で、準委任型の企画とPoCを行う
- 仕様と受入条件を整理する
- 条件が固まった部分から、請負型の本番開発へ移る
一括請負では、AIの回答品質やデータの不確実性が価格や納期に織り込まれます。その結果、発注側と委託先の双方が動きにくくなる場合があります。
企画から運用まで一括で外注するケース
AWSや生成AI、業務設計の担当者が社内に少なく、課題整理から本番運用まで任せたい場合は、一括での外注が選択肢になります。企画や要件定義、設計から始めて、開発、テスト、教育、保守までを依頼します。
窓口が一つになるため、どこまでを誰が受け持つかを整理しやすくなります。CRM連携やセキュリティ対策も、後付けになりにくい点が利点です。ただし、業務の優先順位を決める責任者がいないと、仕様が広がりがちです。
PoCだけを専門会社へ依頼するケース
ユースケースの価値や回答品質を確かめるには、対象を1業務、1データソース、少人数に絞ったPoCを依頼するのが適しています。
成果物には、動く画面に加えて、評価に使う質問と正解例を含めます。回答根拠と拒否すべき質問、応答時間、1回あたりの推定費用も入れておきます。
別の会社に本番開発を頼む可能性があるなら、プロンプトや評価データ、データ加工仕様、ソースコードの扱いを、事前に契約で決めておきます。
内製を支援会社に補完してもらうケース
AWSアカウントや開発者が社内にいる場合は、一部の作業だけを外部へ頼めます。たとえば、アーキテクチャレビューやRAG評価、セキュリティ設計、難しいCRM連携です。
ノウハウが社内に残るため、モデルの切り替えやプロンプトの改善も社内で進められます。
社内担当者の稼働は、ゼロにはなりません。そのため、データ整備や評価、現場ヒアリング、問い合わせ対応を、誰が担うのかを明記しておきます。
発注前に行う要件整理とRFPの作り方
RFPは、各社が同じ条件で提案と見積もりを出すための比較基準です。「誰の、どの業務を、どのデータで、どの状態まで改善するか」を、具体的に書き出します。
目的・対象業務・KPIの設定
目的は、業務の言葉で示しておきます。「生成AIを導入する」と書くだけでは、何を改善するのかが伝わりません。たとえば、製品資料を探す時間の短縮、商談後の記録作成の効率化、問い合わせ一次回答の増加のように表します。
KPIは、検索から回答までの時間や根拠提示率、正答率などから選びます。特に、AIの回答品質だけを合格条件にすると、現場が使わないシステムでも成功扱いになってしまいます。
試験ユーザーの週1回以上の利用割合、根拠がない回答を人へ切り替える機能、誤回答を修正する時間も、KPIに含めます。そうすると、本番運用を見据えて評価できます。
データ・権限・連携要件の洗い出し
データや権限、連携の条件を各社の提案で同じ前提にそろえるため、RFPには、データ、作業分担、連携先、AIの操作範囲を具体的に書き込みます。
- データ項目：種類と保存場所、更新頻度、容量と形式、アクセス権と保存期間
- 整備分担：マスタ整理を発注者が担うか、委託先がデータクレンジングまで行うかの分担
- 連携対象：SalesforceなどのCRMやSFA、MA、Microsoft 365、社内ファイルサーバー、基幹システムの一覧
- 連携条件：APIの有無、更新の方向と頻度、障害時の再送条件
- AI操作：Agentが実行できる操作と、人が承認する操作の区別
たとえば、営業資料は旧版を除外し、顧客情報は部署の外へ表示しないようにします。また、退職者のアクセス削除や、商談情報の個人情報・機密情報のマスキングも示します。
評価・セキュリティ・成果物の明文化
評価用には、実際の質問と正解例を最低限そろえておきます。そのうえで、評価・セキュリティ・納品物の条件をRFPに記載します。
- 評価基準：質問と正解例で測る正確性、根拠性、拒否性能、個人情報露出、応答時間、費用
- アクセス保護：IAM最小権限、MFA、TLS、KMS暗号化、VPC・PrivateLinkの利用可否
- 監査と安全：CloudTrail、ログの個人情報防止、Guardrails、バックアップ、事故時の連絡時間
- 納品物：構成図とデータ加工仕様、プロンプト、評価・テスト結果、運用・障害時手順、AWS請求の負担、モデル変更時の再評価条件
AWS公式ドキュメントでは、転送中のTLS 1.2やKMSによる暗号化の対象が説明されています。加えて、サービスの設定とは別に、アプリケーション側のアクセス制御も設計します。
AWSのRAG評価やLLM-as-a-Judgeは、評価用モデルの推論にも料金がかかる場合があります。そのため、試験回数と予算もRFPに含めます。
契約形態と発注範囲の決め方
全工程を同じ契約形態にする必要はありません。不確実性が高い工程と、成果物や受入条件を定められる工程を分けると、追加費用や責任の押し付けを抑えられます。
準委任契約が向く工程
企画や現状調査、データの洗い出しには、準委任契約が向いています。技術検証やモデル比較、PoCも、準委任に向く工程です。
回答品質やデータの扱いやすさは、検証してみないと分かりません。そのため、稼働を時間や月単位で定め、作業内容と会議体、成果物も決めておきます。
ただし、準委任であっても、成果物は必要です。報告書と評価結果、課題一覧、次工程の提案などを、納品物として明記します。
請負契約が向く工程
本番画面や定義済みのAPI連携、認証、データ取り込みは、仕様と受入条件が固まっていれば、請負契約を検討できます。
完成条件を「AIが必ず正解する」とするのは、現実的ではありません。そこで、評価データでの正答率と根拠提示率、エラー表示、性能を、受入の判定基準として具体的に決めます。セキュリティテストや受入確認の手順も、あらかじめ定めておきます。
契約書で確認する責任分界
契約書では、どこまでを誰が受け持つかを、次の5項目で明記します。
- データ：発注者が提供する分と、委託先が整備する分の区別
- 費用：AWS利用料、サードパーティーの検索基盤費、モデル料金、監視費、保守費の支払者
- 権利：プロンプトと評価データの著作権、生成物の利用範囲、コード納品、再委託の扱い
- 情報管理：秘密や個人情報の扱い、終了時のデータ削除
- モデル変更：廃止・値上げ・性能変更時の評価者、追加費用、切替時期
あらかじめ決めておけば、運用後の予想外の負担を減らせます。
Amazon Bedrockのシステム開発費用と料金相場
開発会社への初期費用とAWS利用料は、分けて比較します。「AI導入費」とひとまとめにすると、本番運用費やデータ整備費が抜けても気づきにくくなります。
開発会社へ支払う費用の目安
一律の公式相場は公開されていません。次に示す金額は、営業・CRM・MAの相場情報と、生成AI・RAG開発の工程から組み立てた推定値で、特定企業の提示価格ではありません。
- PoC：1ユースケース、少量データ、最小限の画面による技術検証・簡易チャットで、100万〜500万円程度
- MVP：認証、データ取り込み、検索、回答画面、基本ログ、評価を含む社内文書検索で、500万〜1,500万円程度
- 本番開発：CRM・SFA・MA連携、権限分離、承認、監査ログ、運用設計、テストを含み、1,500万〜5,000万円程度
- 全社展開：複数拠点、基幹連携、閉域網まで含む全社規模の場合は、5,000万円〜1.5億円以上の可能性
PoCの推定額は、AWS利用料やデータ整備、セキュリティ、評価回数の扱いによって変わります。全体の金額は、要件やデータ量、連携数で大きく変わります。さらに、セキュリティ水準と発注者側の分担によっても左右されます。
一般的なCRM・MAでは、初期開発費の10〜20％を年間の保守・改善費とする考え方もあります。Bedrockでは、モデル評価やプロンプト改善、ナレッジ更新も加わるため、保守の範囲を分けて見積もります。
AWS利用料の見方と試算方法
AWS利用料は複数の要因で変わるため、料金と使用量の前提をそろえて試算します。
- モデル利用料：モデル、入出力トークン数、処理方式、リージョンによって決まる料金
- 周辺サービス費：Knowledge Bases、検索基盤、S3、Lambda、ログなどの料金
AWS公式料金ページには、モデル別の入出力単価や各サービスの料金が掲載されています。ただし、2026年8月時点では、一部モデルのプロモーション価格も案内されています。
価格は変わるため、候補モデルと想定リクエスト数で再計算します。たとえば、入力100万トークンあたり3ドル、出力100万トークンあたり15ドルと仮定します。
月10万回、1回あたり入力1,000・出力500トークンなら、入力1億は300ドル、出力5,000万は750ドルです。モデル部分は合計1,050ドルです。
ただし、検索や保存、ネットワークに加えて、監視や為替も含んでいません。AWS公式料金ページでも、モデル以外のサービス料金は別途発生すると説明されています。
AWSは2026年6月にManaged Knowledge Baseを発表し、RAGパイプラインのインフラ管理を抽象化する方向を示しました。工数を下げられる可能性はありますが、料金や対応リージョンに加え、データ適合性と権限設計も導入前に確かめます。
提案書では、従来構成と新機能を比べ、初期費用だけでなく3年間の総保有コストで判断します。
見落としやすいデータ整備・運用費
見積もりでは、データ整備費と継続運用費を分けて確認します。
- データ整備：重複削除や表記統一、旧資料の廃棄、PDF分割やメタデータ付与、個人情報のマスキング、権限連携
- 継続運用：ナレッジ更新や誤回答の確認、問い合わせ対応、モデルとプロンプトの再評価、AWS費用の監視、障害対応、利用分析
根拠のある回答にするには、Excelを一度S3に置くだけでなく、正本とするファイルと更新の承認者を決めておきます。
PoCの100万〜500万円に加え、本番後の月額費用と年次改善の上限も確認します。
委託先の選定と見積比較で確認するポイント
委託先は、AWS資格や生成AIの知名度より、営業・CRM・MAの業務理解とBedrockの実装を見ます。さらに、データと権限の設計、本番運用、引き継ぎまで確認します。同じRFPを使って、複数社を比べます。
Bedrockの利用有無だけで決めない実績の判断
事例では、利用者数やデータの種類、既存システムを聞きます。加えて、評価方法と本番後の運用期間も確認します。営業支援であれば、CRM権限の継承や根拠リンク、有人対応への接続も見ておきます。
会社の規模だけで選ぶと、合わない場合があります。全社展開や厳格なガバナンス、複数拠点の統合には、大手が合いやすい一方で、AWS環境の改善や小さなPoCには、専門会社が合う場合もあります。
公開情報からわかる得意領域と、自社案件への適合性は、分けて考えます。
見積書の同条件での比べ方
工程は、企画や要件定義、データ整備に分けてもらいます。さらに、画面やAPI、インフラ、評価を、それぞれの工程として示してもらいます。そのうえで、セキュリティ、教育、保守も別に記載してもらいます。
「AI機能一式」のような見積もりでは、作業量や成果物を比べにくいため、内訳を質問します。AWS利用料や外部サービス費、発注者側の作業もそろえます。また、交通費と追加変更の単価も、同じ前提で書いてもらいます。
費用は、データ整理状況やCRM APIの有無で変わります。加えて、利用者が50人か1,000人か、月間1万回か10万回かでも変わります。最安値の提案が、発注者側の大量作業を前提にしていないかも確認します。
候補会社へ必ず質問する項目
初回面談では、類似案件でPoCから本番まで何を担当したかを聞きます。RAG評価データの作り方や利用者別権限の制御場所、個人情報をログに残さない方法も確かめます。
モデル変更時の再評価担当、設計書やプロンプトの納品範囲、評価データとソースコードの扱いを確認します。さらに、AWS請求と月額保守の担当者も、あらかじめ聞いておきます。
「高精度にできます」や「最新AIで自動化できます」といった説明だけで判断しないよう注意します。良い委託先は、誤回答の条件や使えないデータを説明します。人的確認や追加費用の条件も、あわせて示してくれます。
Amazon Bedrockの外注で起きやすい失敗と対策
技術面の不具合に加えて、運用や契約の問題でも失敗は起きます。現場で使われない、根拠が不明、データ更新が止まるといった問題のほか、予算超過や委託先を変えられない問題も起こります。そのため、発注時にリスクと運用責任を契約に落とし込みます。
現場を置き去りにした導入
経営層が機能を先に決めて、営業担当者の入力や検索の場面を聞かないままだと、現場はExcelや個人メモに戻ってしまうことがあります。
発注前には、代表ユーザーへの聞き取りや試作画面の確認を行い、利用場面と入力項目、回答の見せ方を確かめておきます。さらに、リリース後は、利用率と未解決の質問を確認し、改善計画に反映します。
データ整備の責任者の不在
正確なRAGには、資料を整える作業が欠かせません。資料をS3に置いただけでは、古い資料や重複文書、権限の分からないファイル、表記の揺れた商品名が混ざって、検索結果も不安定になります。
部門ごとにデータオーナーを置き、正本と更新頻度、公開範囲、廃棄基準を決めます。ただし、委託先が作業を支援しても、業務上の正しさを判断する責任は発注者に残ります。
機能の増やしすぎによる費用超過
提供Q&Aには、過剰なカスタマイズによって当初2,000万円の想定が4,200万円に膨らんだ例があります。
Bedrockでも、検索や要約、CRM更新を一度に入れると、連携やテスト、権限設計が増えます。さらに、レコメンドやAgent、複数モデル対応まで加えると、負担はいっそう膨らみます。
まず優先度の高い1業務に絞り、追加機能はKPIと利用状況を見て判断します。
個人情報と権限の後回し
個人情報と権限の管理では、データの扱いとアクセス制御を発注前に定めておきます。
- 顧客名や連絡先、商談履歴、音声、担当者評価が、個人情報や機密情報に当たる可能性
- 入力データの学習利用や保持期間、処理リージョン、再委託先のアクセスに対する、法務・セキュリティ担当のレビュー
- 扱うデータや再委託、削除方法、事故時の連絡を含む契約条項
- 文書や検索結果のメタデータ、CRM取得項目、Agentの操作ごとの権限制御
- Guardrailsと元データの権限およびアプリケーション認可の組み合わせ、人が最終確認できる導線
よくある質問
費用や納期は要件によって変わります。ここに挙げる数字は判断の起点として使い、RFPと候補会社の見積もりで確定させます。
Amazon BedrockのPoC外注費はいくらですか？
1ユースケース、少量データ、最小限の画面による技術検証・簡易チャットは、100万〜500万円程度が推定レンジです。これは、リサーチノートの類似システム情報と一般的な工程から算出した目安です。
金額は、AWS利用料やデータ整備、セキュリティ要件、評価回数を含むかどうかで変わります。
RAGとファインチューニングはどちらを発注すべきですか？
営業資料や社内規程のように更新が多い知識を参照するなら、まずRAGを検証するのが一般的です。根拠資料を更新しやすく、権限や検索対象も管理しやすいからです。
文体や定型出力のように、RAGで解決しない課題が見えてから、ファインチューニングの費用と効果を比べます。
顧客情報をAmazon Bedrockに入力しても安全ですか？
顧客情報を入力する場合は、Bedrockの利用だけでなく、設計と運用で安全性を確保します。
まず、AWSのデータ保護・暗号化仕様を確認します。そのうえで、入力の最小化やIAM、KMSを組み合わせます。さらに、通信保護とログ管理、権限分離を加え、Guardrailsと人的確認も組み合わせます。
加えて、個人情報保護法と社内規程の観点でレビューします。委託先のデータ取扱いと再委託、削除、事故時の連絡は、契約に含めます。
本番稼働まで何か月かかりますか？
PoCは1〜3か月、データ連携と評価を含むMVPは3〜6か月、本番導入は6〜12か月が推定目安です。
AWS公式には、2か月で約6,000人向けに開発した事例があります。ただし、既存基盤と専任体制が整った企業の例です。自社では、データ整理や法務審査、現場テスト、教育の期間も加えて考えます。
Amazon Bedrockに詳しい会社はどう選べばよいですか？
AWS・Bedrockの実績に加えて、営業・CRM・MAの業務理解を確認します。さらに、システム連携やRAG評価、セキュリティを確かめます。加えて、PoCから本番への移行、保守、内製化支援も見ておきます。
同じRFPを渡し、作業範囲と前提、AWS利用料をそろえて見積もってもらいます。また、成果物や発注者の負担、モデル変更時の責任も、同じ条件で比べます。
まとめ
発注時は、モデル選びより先に、解決する業務とKPIを整理します。そのうえで、利用データと権限、評価方法、運用担当を決めておきます。
要件が曖昧な段階は準委任型の調査やPoCに、条件が固まった部分は請負型の本番開発に分けると、どこまでを誰が受け持つかを整理しやすくなります。
発注成功のためにRFPへ入れる項目
RFPには、目的とKPI、対象ユーザー、データソースを記載します。さらに、更新頻度や権限、個人情報、連携先も書き込みます。
想定利用量と評価質問、SLAも含めます。予算や日程、発注者側の作業も必要です。納品物と保守範囲も、あわせて明記します。
見積もりを、初期開発とAWS利用料、データ整備、保守・改善費に分けてもらいます。そうすると、提案の安さだけでなく、導入から運用までの総費用を比べられます。
最初の一歩は小さな業務課題の言語化
全社向けのAgentをいきなり発注するより、資料検索や商談要約、問い合わせ一次回答など、効果を測りやすい一業務から始めます。
委託先には、誤回答やデータ不足、権限漏れを説明してもらいます。さらに、追加費用や運用負担も示してもらいます。自社に合う発注形態と委託先を選ぶことが、現場で使われるシステムにつながります。
▼全体ガイドの記事
・Amazon Bedrockのシステム開発の完全ガイド
▼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を創業。