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

Azure Synapse Analyticsのシステムを発注・外注するなら、製品を導入するだけでなく、データの目的、連携範囲、品質、権限、運用までをRFPと契約に落とし込むことが重要です。Synapseはデータを集約して分析する基盤であり、業務画面だけを作る一般的なシステム開発とは、見積もりの考え方が異なります。

この記事では、Azure Synapse Analyticsのシステムを発注する際の形態の選び方、RFP・要件整理、契約形態、費用相場、委託先の選定、見積比較のポイントを順番に解説します。小規模なPoCから全社データ基盤まで、どこまでを外注し、どこからを自社で担うべきか判断できるように整理します。

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

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

Azure Synapse Analyticsの発注全体像

Azure Synapse Analyticsは、企業のデータウェアハウス、データレイク、ビッグデータ処理、データ統合をAzure上で組み合わせる分析サービスです。Microsoft Learnでは、Synapse SQL、Apache Spark、Pipelines、データ分析機能を一つの開発体験にまとめ、Power BIなどのAzureサービスと連携できるサービスとして説明されています(出典:Microsoft Learn「What is Azure Synapse Analytics?」、2024年更新)。

Synapseは業務画面ではなく分析基盤です

発注時に最初に確認したいのは、Synapseを「何をするシステム」と定義するかです。販売管理や在庫管理の入力画面を直接置き換える製品ではなく、基幹システム、ERP、CRM、SaaS、Excel、IoTなどに分散したデータを集め、分析しやすい形に整え、Power BIなどへ提供する基盤と考えると整理しやすくなります。

そのため、発注の成果物はワークスペースだけではありません。データソース一覧、データモデル、取り込みパイプライン、SQLやSparkの処理、権限設計、監視、復旧手順、利用部門向けの説明資料まで含めて初めて業務で使える状態になります。KPIの定義や名寄せのルールを自社で決めないまま開発会社へ任せると、技術的に動いても部門ごとに数字が違う状態が残ります。

実際の導入事例として、Microsoftの顧客事例では、株式会社クラレがSAP ERPなどのデータをAzure Data Factory、Azure Data Lake Storage Gen2、Azure Synapse Analytics、Power BIで連携し、4種類のデータモデルを約700名へ提供しています。採用前のPoCでは、データモデルの開発リードタイム、アクセス制御、多様なデータソースへの対応、データカタログの追加という4項目を検証しており、発注時の評価項目を具体化する参考になります(出典:Microsoft Customer Stories「Azure Synapse AnalyticsとPower BIでデータ活用基盤を確立」、2024年3月公開)。

専用SQL・サーバーレスSQL・Sparkを目的で選びます

定型的な集計を安定した性能で実行したい場合は専用SQLプール、利用頻度が不定期でデータレイクを直接探索したい場合はサーバーレスSQLプール、大量データの加工や機械学習を行う場合はApache Sparkが候補になります。専用SQLは計算資源を確保して性能を予測しやすく、サーバーレスSQLはクエリで処理したデータ量を基準に使い始めやすいという違いがあります。

発注先には、単に「Synapseを構築してください」と伝えず、たとえば「毎朝6時までに販売・在庫データを更新し、営業部門が商品別粗利を確認する」「個人情報を含むデータは役職別に見せ分ける」といった利用目的を伝えます。目的が具体的であれば、どのコンポーネントを採用するか、どの性能を検証するか、何を見積もるかが明確になります。

Azure Synapse Analyticsの発注形態はどれを選ぶべきですか?

Azure Synapse Analyticsの発注形態

結論として、目的と不確実性が大きく異なるため、すべてを一つの契約形態で発注する必要はありません。要件が固まっていない段階は準委任や小規模な調査契約、成果物と受入条件が明確になった本開発は請負、運用開始後は保守・運用契約へ分ける方式が現実的です。

PoC・アセスメントは小さく外注します

データ品質や性能が不明な場合は、いきなり全社基盤を発注せず、1〜3個のデータソースと1つのKPIに絞ったPoCから始めます。サーバーレスSQLで実データを探索し、取り込みを1本動かし、Power BIの試作を作ると、必要なデータ量、更新時間、権限の難しさ、クエリ処理量を確認できます。

PoCの発注書には、検証する仮説と終了条件を記載します。「分析できること」だけでは不十分で、「午前6時までに更新できる」「売上と在庫の突合差異を一覧化できる」「個人情報を一般利用者から見えなくできる」「1日あたりのAzure利用量を計測できる」といった判定基準が必要です。PoC終了後に本開発へ進まない場合の成果物の引き渡しも、最初に決めておきます。

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

社内にAzure、データモデリング、ネットワーク、セキュリティ、BIを横断して設計できる人材がいない場合は、構想・要件定義・設計・開発・移行・運用設計までを一括で支援できる会社を選びます。ただし一括発注でも、業務KPIの定義、データの正しさを確認する責任者、利用部門の受入は自社に残す必要があります。

一括外注の提案を比較するときは、「ワークスペースを作る」以外の範囲を確認します。データカタログ、マスタ統合、Power BIのレポート、Entra IDの権限、Private Link、監視、障害対応、FinOps、利用者研修、運用引き継ぎが含まれるかを表にして確認してください。含まれない作業が多いと、後から追加費用が発生しやすくなります。

自社と委託先の役割を分けます

内製と外注を組み合わせる場合は、自社が業務知識とデータの意味、委託先がアーキテクチャ、実装、セキュリティの専門知識を担う分け方が基本です。自社が要件と受入を担当し、委託先がパイプラインやSQLを実装する方式なら、完成後も社内に判断力が残ります。

反対に、委託先だけでデータ定義や業務ルールを決めると、担当者が変わったときに運用できなくなる可能性があります。週次の設計レビュー、データ品質レビュー、費用レビューを契約上の会議体にし、設計書・SQL・ノートブック・パイプライン定義・IaCを自社環境へ移管する条件も記載します。

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

Azure Synapse AnalyticsのRFPと要件整理

RFPは機能の注文書ではなく、達成したい業務成果と制約条件を共有する文書です。Synapseの製品名や構築範囲だけを書いても、会社ごとに想定するデータ品質、性能、運用が違うため、見積金額と提案内容を比較できません。以下の項目を最低限そろえて、同じ資料を複数社へ渡します。

業務目的・利用者・データソースを明記します

最初に、改善したい意思決定とKPIを1〜2個に絞って書きます。たとえば、営業会議の集計時間を短縮する、在庫の欠品率を把握する、製造ラインの異常を早く検知するなどです。利用者の部門、人数、同時利用の想定、必要なレポート、更新頻度、許容する遅延、業務時間帯も具体化します。

データソースは、SQL Server、ERP、CRM、販売管理、ファイル、SaaSなどを一覧にし、接続方式、データ量、増加量、更新頻度、保持期間、主キー、欠損や重複の状況、データ所有者を記載します。個人情報や機密情報が含まれる場合は、項目、利用目的、閲覧者、保存期間、マスキングの要否、国外移転やデータ所在地の条件まで情報セキュリティ部門と確認します。

性能・セキュリティ・運用条件を数値化します

非機能要件は、後から費用が増えやすい部分です。更新完了時刻、画面表示の目標時間、同時実行数、月間データ量、障害時の復旧目標、バックアップの保持期間、稼働時間、監視時間、問い合わせ受付時間を可能な範囲で数値化します。「速く」「安全に」「止まらない」といった表現だけでは、見積比較の基準になりません。

セキュリティでは、Microsoft Entra IDのグループベース権限、Managed Identity、保存時・通信時の暗号化、Private Link、Managed Virtual Network、監査ログ、データ持ち出し制御、Purviewなどのカタログ・リネージュを確認します。委託先には、どの要件をSynapseの設定で実現し、どの要件をAzureの別サービスや運用手順で補うのか説明してもらいます。

成果物と受入条件を先に決めます

RFPには、要件定義書、基本設計書、データモデル、データ辞書、接続定義、パイプライン、SQL、Sparkノートブック、テスト仕様書、権限一覧、監視設計、運用手順、IaC、利用者マニュアルなど、納品を求める成果物を記載します。ソースコードや設計書の所有権・利用権、契約終了時のデータ返却、削除証明、第三者ライセンスの扱いも、発注前に法務と確認します。

受入条件は「納品されたか」ではなく、「業務で使えるか」で定義します。指定したデータ件数を取り込めること、集計結果が既存帳票と一致すること、設定した権限以外では個人情報を閲覧できないこと、障害から手順どおり復旧できること、月次のAzure利用量を確認できることなど、テストで判定できる条件にします。

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

Azure Synapse Analyticsの契約形態

Azure Synapse Analyticsの開発では、要件が変わりやすい上流工程と、成果物を確定しやすい実装工程が混在します。契約形態を工程ごとに見直すと、発注者と委託先の責任を分けやすくなります。契約書だけでなく、作業範囲、前提条件、変更管理、検収方法を別紙で明確にします。

準委任契約は調査・設計・伴走に向きます

準委任契約は、作業時間や専門家の役務を受ける契約として、現状調査、要件定義、アーキテクチャ検討、PoC、内製化支援に向いています。データ品質を調査してみないと作業量が分からない場合や、Fabric、Databricks、Synapseの比較をしながら方針を決める場合に使いやすい契約形態です。

一方で、準委任だから成果に責任がないと考えてはいけません。月次の成果報告、設計判断の記録、検証結果、次工程の判断材料を成果として定義し、担当者の稼働時間だけを管理する契約にしないことが重要です。

請負契約は成果物と受入条件を固めてから使います

請負契約は、合意した成果物を完成させ、検収を受ける開発に向いています。データモデル、パイプライン、レポート、テスト結果、運用手順などの範囲と受入条件が明確なら、予算と納期を管理しやすくなります。ただし、発注者側のデータ提供が遅れた場合、要件が追加された場合、接続先の仕様が変わった場合の扱いは別に定めます。

「Azure Synapse Analyticsのシステム一式」のような曖昧な成果物名だけで請負契約を結ぶのは避けます。どのデータを、いつまでに、どの品質で、どの処理時間で、どの権限により提供するのかを受入項目へ分解してください。追加要件の単価、変更承認者、納期延長の条件も、契約書や変更管理票に組み込みます。

保守運用契約はAzure利用料と分けて記載します

運用契約では、監視対象、アラートの検知、一次切り分け、障害対応、データ再処理、権限申請、コストレポート、月次レビュー、問い合わせ時間、目標応答時間を定めます。Azureのサービス利用料、Power BIなどのライセンス、委託先の保守費を一つの月額にまとめる場合も、内訳を分けて記載してもらいます。

保守費は、リサーチノートで整理されている業務システムの一般的な企画目安として、初期開発費の年15〜25%程度が一つの参考レンジになります(出典:NotebookLMリサーチノート「Azure Synapse Analyticsのシステム」、2026年)。ただし、24時間監視、休日対応、データ追加、セキュリティ対応、レポート改修を含めるかで大きく変わるため、割合だけで決めず、サービスレベルと作業内容で見積もります。

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

Azure Synapse Analyticsの費用相場

Azure Synapse Analyticsの受託開発費には、Azure利用料だけでなく、現状調査、データ設計、接続開発、品質改善、テスト、移行、BI、セキュリティ、運用設計の人件費が含まれます。Synapse単体の国内受託開発費を網羅した公的統計は確認できないため、以下はデータ活用案件と業務システムの一般的な工数をもとにした、2026年時点の企画用推定レンジです。確定見積ではありません。

初期開発費は規模別のレンジで考えます

小規模なPoCや部門分析は100万〜500万円程度、部門横断の実用基盤は500万〜2,000万円程度、複数の基幹システムをつなぐ全社DWHは2,000万〜1億円以上が企画段階の目安です。大規模な既存DWH移行、リアルタイム処理、複数リージョン、厳格な監査、機械学習まで含める場合は、1億円を超える可能性もあります(出典:NotebookLMリサーチノート、業務システムの規模別費用整理、2026年)。

このレンジは、データソース数、データの履歴、名寄せの難しさ、Power BIの帳票数、個人情報の扱い、性能要件、移行対象、テスト範囲で変動します。見積書に「データクレンジング一式」「帳票対応一式」とだけ書かれている場合は、対象件数と作業内容を分解してもらいます。

Azure利用料は構成と稼働量で変わります

Azure利用料の企画用目安は、小規模PoCで月1万〜30万円程度、部門横断の実用基盤で月10万〜100万円程度、全社規模で月50万〜500万円程度です。これはSQL、Spark、ADLS Gen2、Pipelines、ネットワーク、監視、BIなどを組み合わせた場合の推定レンジであり、Microsoftの固定月額を示すものではありません。

サーバーレスSQLはクエリで処理したデータ量、専用SQLプールは計算資源の稼働時間、Sparkはノードの稼働時間、ストレージは保存量、Pipelinesは実行回数や統合ランタイムなどで費用が変わります。Microsoftの料金ページはリージョン、契約、為替、割引の影響を受けるため、RFPには月間データ量、クエリ回数、稼働時間、同時実行数を記載し、Azure Pricing Calculatorと実測で確認します。

見積段階からFinOpsを組み込みます

コストを抑えるには、安いサービスを選ぶだけでなく、使わない計算資源を止め、処理量を監視し、クエリやデータ配置を改善する設計が必要です。専用SQLプールの一時停止・再開、Sparkの自動停止、不要な履歴の保存期間、パーティション設計、ワークロード分離、予約容量の比較などを、運用設計の成果物に含めます。

委託先には、月次の利用料レポートに何を載せるかも確認します。ワークスペース別、環境別、部門別、処理別に見られると、予算超過の原因を追いやすくなります。開発会社の保守費とAzure請求額を分け、どちらが増えたのか判断できる見積・運用体制にしてください。

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

Azure Synapse Analyticsの委託先選定

開発会社は、Azureの構築経験だけでなく、業務データを使える状態にする力で比較します。公開事例があっても、自社と同じデータ量・接続先・セキュリティ条件とは限りません。提案時には類似案件の担当範囲、データ品質の改善方法、運用体制、担当者の経験を具体的に質問します。

Synapse以外の実装・運用経験を確認します

確認する技術領域は、Synapseだけでは足りません。ADLS Gen2、Data FactoryまたはPipelines、Power BI、Entra ID、ネットワーク、監視、IaC、CI/CD、データカタログ、必要に応じてDatabricksやMicrosoft Fabricまで含めて、提案チームの経験を確認します。Synapseを作った実績より、業務KPIをデータモデルへ落とし、品質と権限を運用できる実績が重要です。

2026年時点では、Microsoft LearnにSynapseの専用SQLプール、Spark、データとパイプラインをFabricへ移行するガイダンスが整理されています。新規発注でSynapseを採用する場合も、将来の移行を意味するわけではありませんが、SQLやノートブックの再利用性、データ形式、認証方式、ロックイン回避策を提案できる会社を選ぶと、製品ロードマップの変化に対応しやすくなります(出典:Microsoft Learn「Microsoft Fabric migration overview」、2026年4月更新)。

見積書は作業範囲・前提・除外項目を横並びにします

見積比較では、総額の安さだけで決めないことが重要です。要件定義、データアセスメント、アーキテクチャ、ネットワーク、接続、データ変換、品質テスト、性能テスト、権限、BI、移行、教育、運用設計の各項目について、工数、単価、期間、担当ロール、成果物を並べます。PMは月90万〜150万円、SEは月65万〜110万円程度という一般的な企画目安もありますが、スキル、契約、地域、業界知識で変わるため、単価だけで優劣を判断しません(出典:NotebookLMリサーチノート、業務システムの人月単価整理、2026年)。

特に比較したいのは、データクレンジング、過去データ移行、Power BIのレポート数、Azure利用料、ライセンス、テストデータ作成、セキュリティ審査、稼働後の保守が含まれているかです。前提条件が「データは整備済み」「接続先仕様は確定済み」「利用部門が検証する」となっている場合、その前提を自社で満たせるか確認します。

提案面談で失敗パターンへの対応を聞きます

面談では、データ品質が悪かった案件、更新時間を満たせなかった案件、Azure利用料が予算を超えた案件、担当者が交代した案件について、どのように立て直したかを尋ねます。成功事例だけでなく、失敗時のエスカレーション、追加費用、役割分担、再発防止策まで説明できる会社は、運用を現実的に見ている可能性があります。

また、実際に参加するPM、データアーキテクト、Azureエンジニア、BI担当、運用担当を確認します。提案時の責任者と実装時の担当者が異なる場合は、引き継ぎ方法とレビュー体制を聞きます。再委託の有無、海外拠点の利用、個人情報へのアクセス範囲も、委託先選定の重要な確認項目です。

よくある質問

Azure Synapse Analyticsの発注に関するよくある質問

Azure Synapse Analyticsの発注では、製品選定、契約、費用、運用を同時に検討する必要があります。ここでは、外注前に特に質問されやすいポイントへ簡潔に回答します。

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

1〜3個のデータソースと1つのKPIに絞る小規模PoCなら、企画用の推定レンジとして100万〜500万円程度が目安です。ただし、データ品質調査、接続先の難しさ、Power BIの試作数、セキュリティ検証を含めるかで変わるため、金額ではなく検証範囲と終了条件をそろえて見積もります。

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

一律に移行すべきとはいえません。既存Synapseの安定稼働、現在のSQL・Spark・パイプライン資産、Power BIとの連携、セキュリティ要件、費用、移行工数を比較して判断します。新規発注でも、将来Fabricへ移行する場合に再利用できるデータ形式・コード・権限設計を提案へ含めてもらうと、選択肢を残せます。

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

自動的に得られるとは限りません。設計書、SQL、ノートブック、パイプライン定義、IaC、テストコード、データ辞書、運用手順の納品範囲、著作権・利用権、改修権、第三者ライセンス、契約終了時の返却条件を契約で確認します。自社で継続運用するなら、ソースの引き渡しと管理者権限、担当者への説明を受入条件に含めます。

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

Azureの構築経験だけでは判断できません。Synapse、ADLS、Pipelines、Power BI、データモデリング、品質管理、権限、監視、費用最適化を組み合わせて、業務で使える状態まで支援できるか確認します。類似するデータソース数、更新頻度、セキュリティ条件を持つ事例と、実際の担当体制を見せてもらうことが有効です。

まとめ

Azure Synapse Analyticsの発注外注まとめ

Azure Synapse Analyticsのシステムを発注・外注するときは、Synapseの構築費だけでなく、データの意味をそろえる作業、接続、品質、権限、移行、BI、運用、Azure利用料までを一つの全体像として整理します。要件が不確かな段階はPoCや準委任で検証し、成果物と受入条件が定まった工程は請負、稼働後は保守運用へ分けると、責任範囲を明確にしやすくなります。

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

最後に、RFPと見積書で、対象データ、KPI、利用者、更新頻度、性能、個人情報、接続先、月間予算、移行対象、成果物、検収、保守、再委託、契約終了時のデータ返却を確認します。専用SQL、サーバーレスSQL、Sparkを選んだ理由と、利用量をどう測定し、予算超過をどう防ぐかも質問してください。

委託先と一緒に業務で使える状態を作ります

Azure Synapse Analyticsは、データを集めるだけで業務改善が実現するサービスではありません。業務部門が使うKPI、正しいデータ、適切な権限、継続できる運用をそろえて初めて価値が出ます。価格の安さだけでなく、要件整理から移行、内製化、FinOps、将来のFabricとの比較まで伴走できる委託先を選ぶことが、発注後の手戻りを減らすポイントです。

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

会社紹介

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

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

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

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

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

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