Azure OpenAIのシステム開発は、業務課題とKPIの整理からPoCを経て本番運用へ進むと、要件と責任を明確にできます。RFPや委託先の比較も、この流れの中で行います。
各段階で決めた条件は次の段階に引き継がれるため、前の段階を飛ばすと、要件や責任の食い違いが後から表面化します。
▼全体ガイドの記事
・Azure OpenAIのシステム開発の完全ガイド
AIシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「AIシステム開発の完全ガイドブック」で詳しく解説しています。
Azure OpenAIのシステムを発注・外注する全体像
Azure OpenAIのシステムは、Azure上のモデルを業務アプリに組み込み、自社データや業務フローと接続する仕組みです。
この仕組みは、Azure AI Searchなどの検索基盤やMicrosoft Entra IDによる認証を含み、業務データ連携、監査ログ、継続評価も備えた業務システムです。
外注費の多くはモデル自体ではなく、要件定義、データ整備、検索、既存システム連携にかかります。また、セキュリティ、テスト、運用設計も費用に含まれます。
発注する対象は業務システム全体
発注時は、技術名よりも、誰のどの業務をどう変えるかを整理します。
- 社内規程検索：利用者画面や認証から、文書取込、検索、出典表示、権限フィルター、利用ログまでを含めます。
- CRM・ワークフロー更新：AIエージェントのAPI連携に加えて、実行権限、二重送信防止、人の承認、失敗時の戻し方まで含めます。
CRMやワークフローを更新する機能は、参照だけの社内検索より設計の確認項目が多くなります。
発注前に決める成功条件と責任分界
成功条件には、回答の正しさに加えて、業務効果や安全性も数値で定めます。
- 業務効果：問い合わせ対応時間の削減率（％）。
- 回答品質：回答に表示する根拠の件数。
- 安全性：権限外の文書を返さない条件。
- 性能と費用：回答時間と月額上限。
また、誤回答の最終確認者やAzure料金の管理者は、契約前に決めておきます。文書の更新者、障害時の一次対応会社、モデル変更の承認者を分けておくと、納品後の認識違いを防げます。
Azure OpenAIの発注形態
初めて導入する企業には、企画・PoCと本番開発を分けて進める方法が適しています。
社内にAzureの人材がいる場合は技術支援型、業務整理から任せたい場合は一気通貫型が候補になります。
対象業務が定型化しているなら、マネージドサービス型も検討します。
課題と実現性を見極めたい場合のPoC・企画支援型
PoCでは、代表的な質問や文書を使い、実現性と現場での受容性を検証します。さらに、権限のない文書を参照しないかも確認します。
- 回答評価：回答の精度と出典表示。
- 安全性：権限の扱いと、拒否すべき質問への対応。
- 利用条件：応答時間、利用量、現場での受容性。
正解率だけでなく、実務で必要な条件も評価します。
代表質問は100〜300件程度を用意します。そのうえで、評価データ、構成案、概算費用、本番移行条件を成果物として残しておくと、次の開発会社を選ぶときに役立ちます。
業務整理から運用まで任せたい場合の一気通貫型
一気通貫型は、企画から保守までを一つの委託先にまとめる方法です。
- 委託範囲：要件定義、Azure基盤、アプリ、データ連携。
- 品質と定着：セキュリティ、テスト、教育、保守。
- 納品物：設計書、ソースコード、Infrastructure as Code、評価用質問セット。
発注窓口を一本化しやすい利点がある一方で、任せきりにすると、データの意味や評価方法が社内に残らないリスクがあります。そのため、運用手順書と管理者教育も納品物に含めて、内製化の範囲を契約で決めます。
自社で運用したい場合の技術支援・内製化伴走型
AzureやMicrosoft 365を利用し、社内に開発担当者がいる企業は、一部の専門作業を外注できます。
- 設計レビュー：アーキテクチャとセキュリティの確認。
- 評価設計：RAGの評価方法の整備。
- 難所の支援：難易度の高い連携部分への支援。
将来のモデル変更に対応しやすい一方で、要件整理と進行管理は社内で担う必要があります。そのうえで、発注書に月次レビューの回数、対応時間、成果物、ナレッジ移管の方法を記載します。
Azure OpenAIのシステムを発注・外注する進め方
発注は、目的設定、現状整理、PoC、本番要件定義、設計・開発の順に進めます。その後は、受入テスト、限定公開、全社展開へ進みます。
精度や費用はデータ品質と利用量に左右されるため、初期の段階で仕様を固定しにくいのが特徴です。
最初に決める業務課題とKPI
初回の打ち合わせでは、対象業務と利用者、現在の手順を整理し、課題と改善目標を言葉にします。
- 社内FAQ：問い合わせ件数と回答作成時間。
- 文書処理：1件あたりの処理時間と転記ミス。
- 営業支援：提案準備時間と採用率。
効果指標に加えて、誤回答率や権限逸脱を許容しない安全指標も置きます。測定指標を先に決めておくと、開発会社の提案を比べやすくなります。
データ・権限・既存システムの洗い出し
RAGでは、SharePoint、ファイルサーバー、Blob Storage、SQL、CRMなどにある正本データを洗い出します。
- 文書管理：所有者、更新頻度、廃棄ルール。
- 情報区分：個人情報や機密情報の区分。
- 閲覧権限：利用者ごとの参照範囲。
権限が不明なままでは、検索の精度より先に情報漏えいの危険が生じます。
情報漏えいを防ぐため、発注側は認証基盤、ネットワーク、API、マスターデータの管理者も一覧にして、開発会社へ渡すデータと渡さないデータを決めます。
PoCから本番へ移る条件の事前合意
PoCは、デモで終えるのではなく、本番投資の判断材料を作るために行います。
- 品質と根拠：代表質問への回答品質と根拠。
- 利用条件：権限、回答時間、トークン量、月間利用量。
- 安全性：拒否すべき質問への応答。
同じテストセットを使って、正解率やP95応答時間などの移行条件を定めます。そのうえで、権限外の文書を返さないことや、月額を予算上限内に収めることも条件に加えます。
条件を満たせなければ、改善か対象の縮小を選びます。
RFP・要件整理に書く内容
RFPでは、技術用語より業務目的と対象範囲を具体化し、前提、成果物、評価方法も書き込みます。候補会社に同じ情報を渡しておくと、開発範囲と金額の差を比べられます。
業務要件に書く利用者・対象業務・成果指標
「社内問い合わせに答える」とだけ書いても、対象部署や質問、参照文書が分かりません。
- 利用条件：利用者の役割、想定質問、利用回数。
- 業務範囲：対応業務、必須の根拠、利用チャネル。
- 有人対応：回答の承認者と、有人への切替条件。
利用回数は1日・1か月の単位で示すと、候補会社が同じ条件で見積もれます。
日本郵政では、Azure OpenAI Serviceの活用ポータルで半年に70以上のミニアプリが作られました（出典：Microsoft Customer Stories「日本郵政」、2025年）。これは基盤と現場の用途を結び付けた例です。自社では、効果を測れる一つか二つの業務から始めます。
機能要件の検索・生成・連携・管理機能
機能要件は、利用者が使う機能と管理機能に分けて整理します。
- 利用者機能：画面、会話履歴、検索、回答、出典表示。
- 文書管理：登録、更新・削除、フィードバック、通知。
- 業務連携：管理画面と業務APIの連携。
RAGでは、文書の分割方法、キーワード・ベクトル・ハイブリッドの検索方式、再ランキング、権限フィルターを確認します。
Microsoft Learnでは、agentic retrievalを、複雑な質問を複数の検索に分解する方式として案内しています。また、構造化された結果には根拠や実行情報が含まれます（出典：Microsoft Learn「RAG and Generative AI」、2026年）。
採用する場合は、従来型RAGとの差や追加のコンポーネント、利用量に応じた課金を提案書で確認します。
非機能要件の安全性・性能・運用性
非機能要件は見積もりと品質を左右するため、条件を具体的に書きます。
- 安全性：処理地域、暗号化、Private Endpoint、Entra ID、ロール別権限、Key Vault。
- 運用性：監査ログ、保存期間、バックアップ、復旧時間。
- 性能と費用：同時接続数、応答時間、月額上限、コストアラート。
脆弱性診断やプロンプトインジェクション対策も、要件に含めます。
Microsoftによると、Azure Direct Modelsのプロンプト、出力、埋め込みなどは、他の顧客やモデル提供者に利用可能にしません。さらに、許可や指示なしに、データを基盤モデルの学習に使わないとしています。
GlobalやDataZoneでは処理場所が変わるため、機密要件に応じて方式を指定します（出典：Microsoft Learn「Azure Direct Modelsのデータ、プライバシー、セキュリティ」、2026年）。
Azure OpenAIのシステム開発で選ぶ契約形態
契約は、要件の固まり具合や変更の多さ、成果物、発注側の管理能力で選びます。PoCと本番では不確実性が異なるため、工程ごとに分けると安全です。
成果物と受入条件を固定できる工程の請負契約
請負契約は、完成物、納期、検収条件を明確にできる工程に適しています。
- 対象：本番アプリの基本機能、画面、API、インフラ。
- 成果物：テスト報告書などの納品物。
- 検収：質問セット、合格基準、修正回数、保証範囲。
回答精度は、「保証する」と書くだけでなく、指定データでの評価方法を決めて契約に書きます。対象外の質問やモデル更新時の扱いも、契約で明確にします。
要件整理・PoC・改善型の工程の準委任契約
準委任契約は、専門家の作業や支援を依頼する形で、要件定義や検証に向いています。
- 企画と設計：要件定義やアーキテクチャ検討。
- 検証と改善：PoC、評価、内製化支援。
- 作業管理：担当者、会議体、作業時間、成果物。
月次の成果物と報告内容は、契約の段階で明確にしておきます。
データや利用者の反応を見ながら仮説を修正していく案件では、使いやすい契約です。そのうえで、週次の課題一覧、意思決定ログ、検証結果、次工程の判断を残します。
PoC・本番・保守を分けるリスク管理
企画・PoC、本番開発、保守・運用を段階ごとに契約する構成は、使いやすい方法です。
- 第一段階では、準委任で企画とPoCを行います。
- 第二段階では、請負またはアジャイル型で本番開発を進めます。
- 第三段階では、保守・運用の契約を結びます。
PoCの終了時には、評価結果と本番見積もりを再確認できます。
保守契約には、窓口や対応時間、障害優先度、更新対応、コスト監視を含めます。そのほか、文書更新や脆弱性対応、月次報告、終了時のデータ返却・削除も決めておきます。
Azure OpenAIのシステム開発費用相場と内訳
開発費は、PoCか社内RAG本番か、CRMやERP連携まで含むかによって目安が大きく変わります。
連携範囲が広い案件ほど、初期費用の幅も大きくなります。要件やデータ量、利用者数、可用性、既存環境によって変わるため、予算の初期の目安として使います。
規模別の初期開発費の目安
初期費用の推定レンジは、規模や連携範囲で変わります。
- 小規模PoC：1用途、少量文書、10〜50人、チャット中心の構成で、300万〜700万円程度です。
- 社内RAG本番：数百〜数千文書などを含み、700万〜1,500万円程度です。
- 業務連携案件：CRM・ERP連携などを含み、1,500万〜5,000万円以上になる可能性があります。
社内RAG本番の費用には、複数部門の権限連携、評価画面、監視、文書更新が含まれます。業務連携では、複数権限や監査、高可用性、既存データの移行も費用に影響します。
いずれも本記事のリサーチノートに基づく推定で、Azure公式価格ではありません。人月単価と各工程の工数から見た推定レンジです。
Azure料金と保守費を含む月額の目安
月額運用費は、規模と運用条件によって変わります。
- 小規模PoC：5万〜20万円程度です。
- 社内RAG本番：20万〜80万円程度です。
- 業務システム連携または高負荷運用：80万〜300万円程度です。
月額には、モデル利用料のほか、検索、実行基盤、DB、保存、ログ、監視を含めます。ネットワークやバックアップ、サポートも運用費に加えます。
保守委託費は、初期開発費の年15〜25％程度が目安です。ただし、保守の範囲によって変わります。
見積書の工程別比較
見積もりを工程別に分けておくと、価格差の理由を確認できます。
- 要件とデータ：要件定義、業務整理、データクレンジング、文書分割。
- 開発と評価：Azure基盤、アプリ・API、RAG、認証、テスト。
- 導入後：教育と保守。
「AI開発一式」とだけ書かれていると、価格の理由が分からないため、人月と成果物を確認します。
リサーチノートでは、人月単価の例としてPMが90万〜150万円、SEが65万〜110万円とされています。PGは50万〜90万円、大手SIerは150万〜200万円程度と整理されています。
単価は会社や役割、契約条件で異なるため、工程別の人月と成果物も見ます。
Azure Standardは入力・出力トークンの従量課金です。一方、ProvisionedはPTUでスループットを確保します。また、Batch APIはGlobal Standard価格から50％割引で、24時間以内に処理を返します。
Global、Data Zone、Regionalでは、性能とデータ処理の境界が異なります。価格は契約や購入日、為替で変わるため、利用量の前提と試算日を記載します（出典：Microsoft Azure「Azure OpenAI Serviceの価格」、2026年8月確認）。
Azure OpenAIの委託先選定と見積比較のポイント
委託先は、知名度やモデル数よりも、業務要件を本番品質に落とし込めるかで選びます。
3社以上に同じRFPを渡し、質問と見積もりの前提をそろえると、価格差を説明できます。
類似業務の本番実績と担当範囲
Azure OpenAIの経験に加えて、実際の本番業務と運用体制を聞きます。
- 案件の条件：業界、業務、利用人数、扱うデータ。
- 品質と運用：権限設計、評価、公開後の運用者。
- 担当範囲：提案会社の作業と納品範囲の区分。
担当がプロンプトだけなのか、データや基盤、アプリ、セキュリティまで含むのかを見ます。
社内RAGと更新系エージェントは、別の経験になります。そのため、案件に近い事例を確認します。
見積比較の前提・除外項目・成果物
見積もりは費用だけでなく、作業条件と納品範囲をそろえて比べます。
- 費用と工程：作業、工数、単価、期間、利用料。
- 成果と保守：納品物、受入条件、保守範囲。
- 前提と除外：発注者の作業と対象外の範囲。
文書のタグ付けや重複削除を発注者が担うかどうかは、金額に影響します。Azure環境やネットワークの用意、テストデータの提供については、誰が行うかも確認します。
モデル利用料が別途かどうかも確認します。非機能要件やテストが抜けた場合は、後から追加費用が生じます。
提案会での評価・安全性・引き継ぎの質問
提案会では、評価方法と安全対策、運用後の引き継ぎについて質問します。
- 評価：質問データの作成者と出典表示。
- 安全性：権限フィルターを実施する層と攻撃検知。
- 変更と障害：回帰テスト、費用監視、人への切替。
コードやIaC、設計書、テスト結果、プロンプト、評価データの納品についても尋ねます。さらに、運用手順書や再委託先、契約終了時のデータ返却・削除も確認します。
特に、自社運用を支援する姿勢は、長期費用と内製化の成否に関わります。
外注後の本番運用の決めごと
リリース後も、文書や質問、モデル、Azureサービスの仕様は変わっていきます。そのため、評価、監視、改善も運用業務として発注します。
回答品質とコストの継続監視
代表質問の評価データを定期的に実行して、結果を改善に役立てます。利用者の低評価や有人対応への切替も、改善の手がかりとして集めます。
- 回答品質：正確性、根拠性、関連性、拒否の適切さ。
- 安全性：権限遵守と応答時間。
- コスト：利用量とエラーの監視、予算警告の設定。
集めた情報は、原因が文書、検索、プロンプト、モデルのどこにあるかで分けて見ます。そのうえで、入力・出力トークン、検索回数、ストレージ、ログ、利用者数も監視します。
agentic retrievalなどを導入する場合は、精度だけでなく、費用と処理時間も比べます。
人の承認とモデル変更の手続き
損失につながる処理は、AIの自動実行だけに任せず、人の承認を設けます。
- 対象業務：顧客情報、契約、発注、審査、在庫変更。
- 役割分担：提案、確認、承認、実行、監査ログの担当。
- 変更管理：回帰テスト、承認者、復旧方法。
失敗したときに人が取り消せる仕組みも作ります。
経済産業省のAI事業者ガイドライン第1.2版も参照します。個人情報、著作権、説明責任、セキュリティ、再委託については、社内規程と契約に反映します。
よくある質問（FAQ）
費用や契約は要件によって変わるため、ここでの回答は判断の軸として使い、実際の見積もりは同じ条件でそろえます。
Azure OpenAIのシステム開発を外注するといくらかかりますか？
初期開発費は、規模と連携範囲によって次のように分かれます。
- 小規模PoC：300万〜700万円程度です。
- 社内RAG本番：700万〜1,500万円程度です。
- 業務連携案件：1,500万〜5,000万円以上が推定レンジです。
Azure料金、データ、認証、テスト、保守で変わるため、利用料と運用費を分けます。発注者側の作業範囲も別に見積もります。
RFPがなくてもAzure OpenAIの開発会社へ相談できますか？
相談はできます。相談の前に、対象業務、利用者、データの所在、課題、希望時期、予算帯を整理しておきます。
RFPは、最初から完璧でなくても構いません。PoCの目的や評価条件を相談しながら作れます。
複数社に相談するときは、同じ情報と質問を渡して、提案範囲をそろえます。
Azure OpenAIなら自社データがモデル学習に使われませんか？
Microsoftは、Azure Direct Modelsの対象データを説明しています。対象には、プロンプト、出力、埋め込み、トレーニングデータが含まれます。さらに、これらのデータを他の顧客やモデル提供者に利用可能にしないと説明しています。
- 学習利用：許可や指示なしに、基盤モデルの学習に使わないとされています。
- 処理条件：API種類、ステートフルAPI、乱用監視、Global・DataZone・Regionalによる違い。
RFPには、処理地域、保持期間、ログ、権限、削除方法を書きます。そのうえで、契約と公式文書で確認します。
PoCだけ外注して本番開発は別会社に依頼できますか？
依頼はできます。その場合は、PoCの契約で、次の工程に渡せる成果物を決めておきます。
- 引き継ぎ資料：評価データ、質問、構成図、プロンプト。
- 移行情報：ソース、設定、費用実績、課題、移行基準。
特定ベンダーでしか使えない環境や、再利用できない成果物になっていないかを確認します。
アカウントとデータを発注者が所有しておくと、将来の委託先変更に備えられます。
まとめ
発注時は、業務課題とデータ、権限を整理したうえで、評価、セキュリティ、運用を要件に含めます。
初回はPoCと本番を分けて、代表質問と移行条件を決めてから、投資の範囲を広げます。
発注前の確認ポイント
発注前の確認事項は、要件、契約、運用の3つに分けて見ると、整理しやすくなります。
- 要件：対象業務とKPI、利用者、権限、正本データと更新方法。
- 契約：PoC評価、処理地域、月額上限、受入条件、納品物。
- 運用：保守SLA、モデル変更、データ返却。
見積もりは工程ごとに、要件定義、データ整備、基盤、アプリ、RAGの費用を示してもらいます。認証、テスト、教育、保守の費用も、別の項目に分けてもらいます。そのうえで、各社の前提と除外項目をそろえて比較します。
最初の一歩はRFPのたたき台作り
まず一つの業務を選び、利用者、困っている時間、参照データ、理想の回答を書き出します。
- 業務情報：利用者、困っている時間、参照データ。
- 目標と制約：理想の回答、守る権限、測定する効果。
Azure、RAG、業務連携、セキュリティ、運用を説明できる会社に相談します。
同じ条件で複数社を比べたうえで、安全に使われ、改善を続けられる業務システムを目指します。
▼全体ガイドの記事
・Azure OpenAIのシステム開発の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・AIシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。