相談する

Azure Synapse Analyticsのシステム開発の発注/外注/依頼/委託方法について

Azure Synapse Analyticsのシステム開発は、目的とデータを整理することから始まり、要件をそろえてPoCで確かめたうえで、開発と運用へ進む流れで発注します。

この流れで進めると、業務で使える分析基盤につながります。

▼全体ガイドの記事
・Azure Synapse Analyticsのシステム開発の完全ガイド

・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。

Azure Synapse Analyticsのシステムを発注する前に知るべき全体像

Synapseを中心に、データウェアハウス、データレイク、Power BIを示した注釈図
分析基盤がデータの集約から業務利用までをつなぎます。

Azure Synapse Analyticsは、企業のデータウェアハウスとデータレイクをAzure上で扱う分析サービスです。ビッグデータ処理やデータ統合も、Azure上で組み合わせて行えます。

Microsoft Learnでは、Synapse SQL、Apache Spark、Pipelinesのほか、データ分析機能を紹介しています。同資料では、これらを一つの開発体験にまとめたと説明されています。

Synapseは、Power BIなどのAzureサービスとも連携できると、Microsoft Learn「What is Azure Synapse Analytics?」（2024年更新）は説明しています。

Synapseの位置づけと業務画面との違い

発注時には、Synapseで実現することを先に定めます。Synapseは、販売管理や在庫管理の入力画面を置き換える製品ではありません。

Synapseは、基幹システムやERP、CRMのデータを集めて分析向けに整え、Power BIなどへ渡す基盤です。SaaS、Excel、IoTなどのデータも、対象になります。

  • 分析基盤の成果物：ワークスペース、データソース一覧、データモデル
  • データ処理：パイプライン、SQLやSparkの処理
  • 業務利用の準備：権限設計、監視、復旧手順、利用部門向け資料

KPIや名寄せのルールは自社で決めておかないと、技術的に動いても部門ごとに数字が異なる状態が残ります。

株式会社クラレは、SAP ERPなどのデータをAzure Data FactoryとAzure Data Lake Storage Gen2へ連携しました。さらに、Azure Synapse AnalyticsとPower BIを組み合わせ、4種類のデータモデルを約700名へ提供しています。

採用前のPoCでは、データモデルの開発リードタイムとアクセス制御を検証しました。また、多様なデータソースへの対応と、データカタログの追加も検証しました（出典：Microsoft Customer Stories「Azure Synapse AnalyticsとPower BIでデータ活用基盤を確立」、2024年3月公開）。

目的別の専用SQL・サーバーレスSQL・Sparkの選び方

処理の内容に合わせてコンポーネントを選ぶと、見積もりと性能検証の範囲が明確になります。

  • 専用SQLプール：定型集計を安定した性能で実行したい場合
  • サーバーレスSQLプール：不定期にデータレイクを直接探索する場合
  • Apache Spark：大量データの加工や機械学習を行う場合

専用SQLは計算資源を確保し、性能を予測しやすい方式です。一方、サーバーレスSQLは、クエリの処理量を基準に使い始められます。

発注先には、利用目的を具体的に伝えます。たとえば、毎朝6時までの販売・在庫更新や、役職別の個人情報表示などです。目的が具体的なら、採用する機能、検証する性能、見積もる作業を決めやすくなります。

Azure Synapse Analyticsの発注形態の選び方

目的と不確実性は異なるため、すべてを一つの契約形態で発注する必要はありません。

要件が未確定なら準委任や小規模な調査で進め、本開発は請負、運用後は保守・運用契約へ分けるのが現実的です。

PoC・アセスメントの小規模な外注

データ品質や性能が不明なら、全社基盤の前にPoCを行います。範囲は、1〜3個のデータソースと1つのKPIに絞ります。

実データをサーバーレスSQLで探索し、取り込みを1本動かしてPower BIを試作します。必要なデータ量や更新時間、権限を確かめられるほか、クエリ処理量も確認できます。

発注書には仮説と終了条件を記し、「分析できること」だけでは終わらせず、合否を判定できる基準を設けます。基準は、データの更新や照合、個人情報の扱い、利用量の4つの観点から定めます。

  • 更新時刻：午前6時までのデータ更新
  • 照合結果：売上と在庫の突合差異の一覧化
  • 個人情報の保護：一般利用者からの情報の非表示
  • 利用量の計測：1日あたりのAzure利用量の把握

PoC後に本開発へ進まない場合に備え、成果物の引き渡しも開始前に決めておきます。

構想から運用までの一括外注

社内に、Azureとデータモデリングに加えて、ネットワークやセキュリティ、BIを横断できる人材がいない場合は、一括で支援できる会社が候補になります。

支援範囲は、構想から運用設計までを確認します。たとえば、要件定義や設計、開発、移行などが含まれます。一方で、業務KPIの定義、データ確認の責任者、利用部門の受入は自社に残します。

提案を比べる際は、ワークスペース以外の作業が含まれるかを表にして確認します。含まれない作業が多いと、後から追加費用が発生しやすくなります。表で比べるのは、データ整備から定着支援までの4つの作業です。

  • データ整備：データカタログとマスタ統合
  • 分析と権限：Power BIレポートとEntra IDの権限
  • 基盤運用：Private Link、監視、障害対応
  • 定着支援：FinOps、利用者研修、運用引き継ぎ

自社と委託先の役割分担

内製と外注を組み合わせる場合は、業務知識と技術専門性の担当を分けます。

  • 自社：業務知識、データの意味、要件定義、受入
  • 委託先：アーキテクチャ、実装、セキュリティ

自社が要件と受入を担い、委託先がパイプラインやSQLを実装すれば、完成後も社内に判断力が残ります。一方で、委託先だけでデータ定義や業務ルールを決めると、担当者の交代後に運用できない可能性があります。

また、週次の設計・データ品質・費用レビューを契約上の会議体にします。成果物を自社環境へ移管する条件も、契約に記載します。移管の対象は、設計書やSQL、ノートブックのほか、パイプライン定義やIaCです。

ポイント

要件がまだ確定していないならPoCや準委任で確かめ、確定した工程は請負、運用後は保守契約へ分けます。一括で任せる範囲は、自社が担う業務知識の量で決めます。

RFPと要件整理で発注先に伝えるべき項目

RFPで確認する業務目的・データ、性能・セキュリティ・運用、成果物と受入条件を並べたチェックリスト
項目をそろえると、提案内容を同じ条件で見比べられます。

RFPは、業務成果と制約条件を発注先と共有するための文書です。製品名や構築範囲だけを示すと、各社の見積金額や提案を比べにくくなります。

発注側は、データ品質や性能、運用の想定をそろえ、同じ資料を複数社へ渡します。

RFPに明記する業務目的・利用者・データソース

RFPでは、まず業務で何を改善するかを示し、そのうえで利用者、データ、機密情報の条件を具体的に書きます。

  • 業務目的：改善する意思決定とKPIを1〜2個に絞る
  • 利用者：部門、人数、同時利用、レポート、更新頻度、許容遅延、業務時間帯
  • データ：接続先、接続方式、量と増加量、更新頻度、保持期間、主キー、欠損・重複、所有者
  • 機密情報：対象項目、利用目的、閲覧者、保存期間、マスキング、国外移転、データ所在地

改善する意思決定の例には、営業会議の集計時間、在庫の欠品率、製造ラインの異常検知などがあります。

接続先には、SQL ServerやERP、CRMのほか、販売管理、ファイル、SaaSなどがあります。また、機密情報の条件は情報セキュリティ部門と確認します。

性能・セキュリティ・運用条件の数値化

非機能要件は後から費用が増えやすいため、可能な範囲で数値化しておきます。「速く」「安全に」「止まらない」といった表現のままでは、見積を比べる基準になりません。

  • 性能条件：更新完了時刻、画面表示時間、同時実行数
  • データ・復旧条件：月間データ量、復旧目標、バックアップ保持期間
  • 運用時間：稼働時間、監視時間、問い合わせ受付時間

セキュリティでは、Entra IDのグループ権限、Managed Identity、保存時と通信時の暗号化を確認します。

そのほか、Private LinkやManaged Virtual Network、監査ログを対象にします。データ持ち出し制御や、Purviewのカタログ、リネージュも対象です。

要件をSynapseの設定で実現するか、Azureの別サービスや運用手順で補うかを、委託先に説明してもらいます。

成果物と受入条件の事前決定

RFPには、納品を求める成果物を記載します。候補は、要件定義書や設計書、データモデルです。辞書や接続定義も、あわせて記載します。

実装物として、パイプラインやSQL、Sparkノートブックを明記します。テスト仕様や権限一覧、監視設計も対象です。運用手順やIaC、利用者マニュアルも、RFPに含めます。

ソースコードや設計書の所有権・利用権と、契約終了時のデータ返却は、法務と確認します。削除証明や第三者ライセンスも、確認対象です。

受入条件は、業務で使えるかを基準に定め、テストで判定できる形にします。たとえば、指定件数を取り込めるか、集計が既存の帳票と一致するか、権限外の利用者に個人情報が見えないかといった形で書きます。

  • 取込件数：指定した件数のデータを取り込める
  • 集計精度：集計結果が既存帳票と一致する
  • 閲覧権限：権限外の利用者は個人情報を閲覧できない
  • 復旧・費用確認：障害復旧と月次利用量の確認ができる

ポイント

RFPでは、業務目的や利用者、データ、機密情報を具体的に書き、性能や運用の条件は数値で示します。成果物と受入条件も事前に決め、業務で使えるかをテストで判定できる形にしておくと、提案を同じ基準で比べられます。

契約形態と外注時の責任範囲を決める方法

開発には、要件が変わりやすい上流工程と、成果物を確定しやすい実装工程があります。そのため、工程ごとに契約を見直すと、双方の責任を分けて考えられます。

契約書に加えて、作業範囲や前提条件を別紙で明確にします。変更管理や検収方法も、別紙に書き込みます。

準委任契約の使いどころ（調査・設計・伴走）

準委任は、作業時間や専門家の役務を受ける契約で、調査や設計などに適しています。

  • 上流工程：現状調査、要件定義、アーキテクチャ検討
  • 検証・定着：PoC、内製化支援

データ品質の調査前で作業量が見えない場合や、Fabric、Databricks、Synapseを比べる場合に使いやすい形態です。

準委任であっても、成果に対する責任を軽く見てはいけません。成果として定義するのは、月次の成果報告や設計判断の記録です。

さらに、検証結果や次工程の判断材料も、成果に含めます。担当者の稼働時間だけを管理する契約は避けます。

請負契約は成果物と受入条件を固めてから使う場面

請負は、合意した成果物を完成させて検収を受ける形態です。範囲と受入条件が明確なら、予算と納期を管理しやすくなります。

  • 開発成果物：データモデル、パイプライン、レポート
  • 検証・運用成果物：テスト結果、運用手順

発注者のデータ提供の遅れや、要件追加、接続先仕様の変更が起きた場合に備えて、扱いも定めておきます。

「システム一式」という書き方では、受入の判断ができません。受入項目は、対象データや提供時期、品質に分けます。処理時間と権限も、個別に分けて書きます。

追加要件の単価や変更承認者、納期延長の条件は、契約書や変更管理票に含めます。

保守運用契約とAzure利用料の分離記載

運用契約では、対応する業務と時間を定めたうえで、費用の内訳を分けて記載します。

  • 障害対応：監視、アラート検知、一次切り分け
  • 定期運用：データ再処理、権限申請、コストレポート、月次レビュー
  • 受付条件：問い合わせ時間と目標応答時間

Azure利用料やPower BIなどのライセンス、委託先の保守費は、ひと月の請求にまとめられる場合でも内訳を分けます。

企画の目安として、業務システムの保守費は初期開発費の年15〜25％程度が参考になります（出典：NotebookLMリサーチノート「Azure Synapse Analyticsのシステム」、2026年）。

費用は、24時間監視や休日対応の有無で変わります。さらに、データ追加やセキュリティ対応、レポート改修の有無でも変わります。割合だけでなく、内容とサービスレベルで見積もります。

ポイント

契約を選ぶ目安は、成果物と受入条件が決まっているかどうかです。決まっていなければ準委任、決まっていれば請負を使い、作業範囲や変更管理、検収方法は別紙で明確にします。

Azure Synapse Analyticsの発注・外注費用相場

初期開発費の企画用推定レンジを、小規模PoCから全社DWHまでの3規模で比較した棒グラフ
対象規模が大きくなるほど、想定レンジも上がります。

受託開発費には、Azure利用料だけでなく人件費も含まれます。人件費の対象は、調査、データ設計、接続です。

さらに、品質改善やテスト、移行の作業があります。BI、セキュリティ、運用設計の作業も、人件費に含まれます。

Synapse単体の国内受託費を網羅する公的統計は確認できません。そこで、データ活用案件と業務システムの工数をもとにした、2026年時点の企画用推定レンジを示します。ただし、これは確定見積ではありません。

規模別の初期開発費レンジ

企画段階の初期開発費は、規模によって幅があります。金額の目安は、いずれも推定レンジです。

  • 小規模PoC・部門分析：100万〜500万円程度
  • 部門横断の実用基盤：500万〜2,000万円程度
  • 複数基幹システムの全社DWH：2,000万〜1億円以上

大規模な既存DWH移行やリアルタイム処理を含む場合、1億円を超える可能性があります。複数リージョンや厳格な監査、機械学習を含む場合も、1億円を超える可能性があります（出典：NotebookLMリサーチノート、業務システムの規模別費用整理、2026年）。

費用は、データソース数や履歴、名寄せによって変わります。Power BIの帳票数や個人情報、性能要件も影響します。移行対象やテスト範囲も関係します。

「データクレンジング一式」「帳票対応一式」とある場合は、対象件数と作業内容を分けてもらいます。

構成と稼働量によるAzure利用料

Azure利用料の企画用の目安は、規模と構成によって月額が変わります。これはMicrosoftの固定月額ではなく、推定レンジです。

  • 小規模PoC：月1万〜30万円程度
  • 部門横断の実用基盤：月10万〜100万円程度
  • 全社規模：月50万〜500万円程度

この推定は、SQLやSpark、ADLS Gen2などを組み合わせた場合の目安です。Pipelinesやネットワーク、監視、BIを組み合わせた構成も、対象になります。

サーバーレスSQLは、クエリで処理したデータ量で費用が変わります。専用SQLプールは計算資源、Sparkはノードの稼働時間が費用に影響します。

ストレージは保存量、Pipelinesは実行回数や統合ランタイムなどで、費用が変わります。さらに、料金はリージョンや契約、為替、割引によっても変わります。

RFPには、月間データ量やクエリ回数を記載します。稼働時間と同時実行数も書き込み、Azure Pricing Calculatorと実測で確認します。

見積段階でのFinOpsの組み込み

費用を抑えるには、使わない計算資源を止め、処理量を監視したうえで、クエリとデータ配置を見直せる設計にする必要があります。

  • 計算資源の停止：専用SQLプールの一時停止・再開、Sparkの自動停止
  • データ処理の効率化：履歴保存期間、パーティション、ワークロード分離
  • 容量の最適化：予約容量を比べ、運用設計に反映

あわせて、委託先には、月次の利用料レポートに何を載せるかも確認します。

ワークスペースや環境、部門、処理ごとに見られると、予算超過の原因を追いやすくなります。開発会社の保守費とAzure請求額は分けて、どちらが増えたかを判断できる見積と運用体制にします。

ポイント

企画段階の金額は、規模ごとの推定レンジとして見ます。見積書では、Azure利用料と人件費、保守費の内訳を分け、対象件数と作業内容を確かめます。

委託先の選定と見積比較で確認するポイント

開発会社は、Azureの構築経験だけでなく、業務データを使える状態にする力で比較します。

ただし、公開事例があっても、自社と同じデータ量や接続先、セキュリティ条件とは限りません。

類似案件では、担当範囲やデータ品質の改善方法を具体的に質問します。運用体制や担当者の経験も、聞いておきます。

Synapse以外の実装・運用経験

提案チームが持つ連携技術と、業務KPIをデータモデルにする経験を確認します。

  • データ・分析基盤：ADLS Gen2、Data FactoryまたはPipelines、Power BI
  • 認証・開発運用：Entra ID、ネットワーク、監視、IaC、CI/CD
  • 周辺サービス：データカタログ、必要に応じてDatabricksやMicrosoft Fabric

Synapseの構築実績に加え、特にデータ品質と権限を運用できる実績が重要です。

Microsoft Learnには、Synapse SQLとSparkをFabricへ移行するガイダンスがあります。データやパイプラインについても、Fabricへ移すためのガイダンスがあります（出典：Microsoft Learn「Microsoft Fabric migration overview」、2026年4月更新）。

新規採用は、将来の移行をそのまま意味しません。SQLやノートブックの再利用性、データ形式、認証、ロックイン回避策について、提案に含まれているかを確認します。

見積書の作業範囲・前提・除外項目の比較

総額の安さだけで決めず、作業範囲と前提、除外項目を工程ごとに比べます。

  • 比較条件：工数、単価、期間、担当ロール、成果物
  • 作業範囲：要件定義、アセスメント、構成、ネットワーク、接続、変換
  • 開発・運用：品質・性能テスト、権限、BI、移行、教育、運用設計

PMは月90万〜150万円、SEは月65万〜110万円程度という企画目安もあります。この単価は、スキルや契約、地域、業界知識によって変わります（出典：NotebookLMリサーチノート、業務システムの人月単価整理、2026年）。

データクレンジングや過去データ移行の範囲を確認します。Power BIのレポート数や、Azure利用料、ライセンスの包含も確かめます。

テストデータ作成、セキュリティ審査、稼働後の保守も、比較の対象です。「データ整備済み」などの前提は、自社で満たせるかを確認します。

提案面談での失敗パターンへの対応

面談では、問題が起きた案件の立て直し方を尋ねます。品質、性能、費用、体制の4つの場面で、過去にどう対応したかを確かめます。

  • 品質問題：データ品質が悪かった案件
  • 性能問題：更新時間を満たせなかった案件
  • 費用超過：Azure利用料が予算を超えた案件
  • 体制変更：担当者が交代した案件

成功事例だけでなく、失敗時の対応も具体的に説明できる会社は、運用を現実的に見ている可能性があります。そのうえで、エスカレーションや追加費用の扱いを確認します。

役割分担と再発防止策も、聞いておきます。参加するPMやデータアーキテクト、Azureエンジニアを確認し、BI・運用担当も含めます。提案者と実装者が異なる場合は、引き継ぎ方法も聞きます。

再委託や海外拠点の利用、個人情報へのアクセス範囲も、確認項目です。

ポイント

委託先は、Azureの構築経験より、業務データを使える状態にする力で比べます。見積は、作業範囲、前提、除外項目を横に並べ、含まれない作業がないかを確かめます。

よくある質問

Azure Synapse Analyticsの発注では、製品の選定から契約、費用、運用までを同時に検討します。

Azure Synapse AnalyticsのPoCを外注する費用はいくらですか？

1〜3個のデータソースと1つのKPIに絞る小規模PoCは、企画用推定で100万〜500万円程度が目安です。

費用は、データ品質の調査や接続先の難しさで変わります。Power BIの試作数やセキュリティ検証も、費用に影響します。金額だけでなく、検証範囲と終了条件をそろえて見積もります。

SynapseではなくMicrosoft Fabricへ移行したほうがよいですか？

一律に移行すべきとはいえません。既存Synapseの安定稼働、SQL・Spark・パイプライン資産、Power BI連携を比べて判断します。

セキュリティ要件や費用、移行工数も比較対象です。将来の移行に備える場合は、再利用できるデータ形式、コード、権限設計を提案に含めます。

開発費を払えばSQLやパイプラインの権利も得られますか？

自動的に得られるとは限りません。権利の範囲は、契約と納品範囲で決まります。

  • 納品範囲：設計書やSQL、ノートブックに加え、パイプラインやIaC、テストコード、データ辞書、運用手順が含まれるかを確かめる
  • 利用と改修：著作権や利用権、改修権を契約で確認する
  • 第三者ライセンスと返却：契約終了時の返却条件とあわせて、契約書に明記する
  • 継続運用：自社で運用を続けるなら、ソースの引き渡しや管理者権限、担当者への説明を受入条件に含める

Azureに詳しい会社ならSynapseの発注先にできますか？

Synapseの発注先は、Azureの構築経験に加えて、組み合わせた実装経験で判断します。SynapseやADLS、Pipelinesを組み合わせる経験を確認します。Power BIやデータモデリングの経験も確かめます。

品質管理から権限、監視、費用最適化まで、支援できるかも見ます。類似するデータソース数や更新頻度、セキュリティ条件の事例と、担当体制を確認します。

まとめ

発注時は、Synapseの構築費だけでなく、データの意味や接続、品質を整理します。権限や移行に加えて、BI、運用、Azure利用料も、あわせて確認します。

不確かな要件はPoCや準委任で検証します。成果物と受入条件が決まった工程は請負、稼働後は保守運用へ分けると、責任範囲を明確にできます。

発注前に確認する最終チェック

発注範囲と運用条件を見落とさないよう、要件、契約・体制、技術・費用の3つの観点で、発注前に見直しておきます。

  • 要件：対象データ、KPI、利用者、更新頻度、性能、個人情報、接続先、月間予算、移行対象
  • 契約・体制：成果物、検収、保守、再委託、契約終了時のデータ返却
  • 技術・費用：専用SQL・サーバーレスSQL・Sparkの選定理由、利用量の測定方法、予算超過への対策

委託先と進める、業務で使える状態づくり

業務改善につなげるには、KPIと正しいデータを押さえたうえで、適切な権限や継続できる運用をそろえる必要があります。

価格の安さだけでなく、要件整理から移行、内製化まで伴走できる委託先を選ぶと、発注後の手戻りを減らせます。FinOpsや将来のFabric比較についても、支援できるかをあわせて確かめておきます。

▼全体ガイドの記事
・Azure Synapse Analyticsのシステム開発の完全ガイド

▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。