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

Azure SQL Databaseのシステム開発は、発注形態と契約を決め、RFPで業務要件と品質条件を整理してから委託先を選ぶ流れで進みます。

契約と責任範囲を具体的に定め、移行と運用まで検証しておくと、予算超過や移行リスクを抑えやすくなります。

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

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

Azure SQL Databaseの発注前の全体像

Azure SQL Databaseの発注では、業務の変更、アプリとDBの設計、既存データの移行を扱います。稼働後の監視と改善も、同じプロジェクトの範囲に含まれます。そこで、自社と委託先の役割を先に分けておくと、見積漏れや責任の押し付け合いを防ぎやすくなります。

マネージドサービスの発注範囲の確認

Microsoftが担う部分と委託先が設計する部分は、作業の種類によって分かれます。見積の前に、どの作業がどちらに入るかを次の区分で確かめておきます。

• Microsoft側：OS修正、標準バックアップ、高可用性の土台
• 個別設計：アプリ、テーブル、インデックス、SQLチューニング
• 運用設定：権限、ネットワーク、監視ルール

Azure SQL Databaseでは、OSのセットアップやデータベースサーバーの修正プログラム適用をMicrosoftに任せられます。そのため、オンプレミスのSQL Serverに比べて、運用の負担を抑えやすいサービスです。

ただし、業務アプリやテーブル設計、権限、監視ルールまで自動で完成するわけではありません。PaaSだからといって安くなるとは限らないため、誰が設計と検証を受け持つかを見積書で確認します。

Azure SQL Databaseと移行先候補の比較

既存環境の機能や設定を踏まえて、移行先ごとに何が合うかを委託先に説明してもらいます。

• Azure SQL Database：新規WebシステムやAPIに適しやすい
• Managed Instance：既存SQL Serverの機能を広く使う場合の候補
• SQL Server on Azure VM：OSやインスタンス設定を維持したい場合の候補

Azure SQL Databaseはデータベース単位のPaaSです。運用を軽くしやすい反面、SQL Agentなどを使えない場合があります。

見積を比べるときは、Azure SQL Databaseを前提にした案だけでなく、代替案と採用しない理由も確認します。

Azure SQL Databaseの発注形態の選び方

発注形態は、社内の業務知識、既存システムへの理解、運用体制に加えて、プロジェクトを管理できる人材の有無を踏まえて決めます。

基本は、要件定義の段階で社内に責任者を置き、必要な領域を外部へ委託する形です。なお、業務判断と受入判定の責任は、委託しても社内に残ります。

企画から運用まで一括で外注する方法

社内の担当者が少なく、新規事業や基幹刷新を短期間で進める場合には、一括委託が選択肢になります。

• 委託範囲：企画支援、要件定義、設計、開発、移行、運用保守
• 利点：窓口を一本化し、アプリ会社とクラウド会社の調整を減らす
• 事前準備：業務課題と対象範囲を社内で合意する

要件が曖昧なまま発注すると、委託先の得意な構成に寄ったり、追加開発が増えたりするおそれがあります。

丸投げのように見える発注でも、業務要件の判断や受入判定までは委託先に任せられません。

要件定義や開発工程だけを部分的に外注する方法

社内にプロダクト責任者やインフラ担当者がいる場合は、専門工程を分けて委託できます。

• 委託例：要件定義、Azure設計、アプリ開発、データ移行、運用設計
• 分担例：社内が業務設計とデータ定義、外部がDB設計と性能検証
• 契約前の確認：成果物と引き継ぎ方法を決める

専門性の高い作業だけを外部へ依頼できるのが、この方法の特徴です。ただし、工程の境界が曖昧だと、障害原因の切り分けが難しくなります。

そこで、引き継ぐのは接続情報やSQL、IaCです。設計書やテスト結果も含め、引き継ぎ先は契約前に定めておきます。

内製と外注を組み合わせる方法

長期に使うシステムでは、業務知識やデータモデルを社内に残す方法が現実的です。

• 社内で担う領域：業務知識、データモデル、優先順位、受入テスト
• 外部へ頼む領域：初期設計、難しい移行、性能改善、セキュリティレビュー
• 社内で担う運用：マスタ管理や軽微な改修

内製比率を高める場合は、技術力に加えて、説明やドキュメントの分かりやすさも選定条件にします。教育と伴走支援の力も、あわせて見極めます。

RFPと要件整理で決めておく事項

RFPは、複数社から同じ条件で提案と見積を受け取るための基準になります。画面仕様をすべて決めていなくても、作成できます。

RFPでは、まず対象業務と利用者、扱うデータの範囲を明記します。連携先と品質条件は、提案者がそろった前提で見積もれるように書きます。納期と予算上限、社内体制も書き込みます。

性能や可用性、バックアップの条件は、要件として書き込みます。ネットワーク、認証、監査の条件も、RFPに含めます。

業務要件とデータ要件の書き分け

業務要件には、誰がいつ何を判断するかを書きます。登録機能だけでなく、承認者や例外処理も洗い出します。

• 業務の流れ：締め時間、キャンセル、在庫引当、請求連携、例外処理
• データ定義：顧客、商品、契約、注文などの項目と必須条件
• データ管理：重複ルール、保存期間、削除条件

Excelや紙、部門別マスタの中身を洗い出さずに移行すると、データ品質の問題は残ったままになります。

非機能要件の数字と条件による表現

提案を比べられるよう、「速い」「止まらない」「安全」といった表現を、性能や復旧の条件として具体化します。

• 性能：平常・ピーク時の利用者数、毎分登録数、応答時間
• バッチ：夜間処理の完了時刻
• 障害対応：RTO（復旧目標時間）、RPO（復旧時点目標）
• 復旧条件：保持期間、切替方法、訓練頻度

高可用性が必要だからといってBusiness Criticalを選ぶ前に、まず停止による損失と必要な復旧水準を合意します。

RFPに含めるセキュリティと委託先管理

個人情報や機密情報を扱う場合は、認証と権限、ネットワークの要件を定めます。暗号化や監査、バックアップの要件も、あわせて書きます。

• 認証と権限：Microsoft Entra ID、最小権限のロール
• 接続と保護：Private Link、ネットワーク制御、暗号化
• データ管理：監査ログ、バックアップ、開発環境のマスキング

ガイドラインでは、委託先の取扱状況を定期監査することが望ましいとされています。また、再委託先の業務内容や取扱方法を、事前報告または承認の対象にすることも望ましいとされています（出典：個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」、2026年確認）。

Azureを利用するだけでは、法令対応は完了しません。そのため、法令への対応は、Azureの設定に加えて、契約と設計にも反映させます。対象には、アクセス範囲やログ保存先、事故報告期限、データの返却と削除などが含まれます。

Azure SQL Databaseのシステム開発で選ぶ契約形態

契約形態は、完成範囲、要件変更の見込み、社内の進捗・品質管理力で選びます。

契約書の名称より、中身の条件が安全性を左右します。成果物と検収条件、変更手続きを具体化します。障害対応や知的財産、再委託、データ管理の条件も、契約に書き込みます。

請負契約の完成物と検収条件

請負契約は、合意した成果物を完成させ、発注者が検収する場合に向いています。

• 対象例：要件と納品範囲が固まった画面、API、DB
• 移行関連：移行ツール、テスト仕様書
• 検収条件：機能、性能、セキュリティ、移行結果、文書

SKUやネットワーク構成をまだ検証中の案件では、完成条件が曖昧になりやすいです。そのため、未達のときの修正方法も決めておきます。

準委任契約が伴走支援や検証に向く工程

準委任契約は、専門家の稼働や作業支援を依頼する工程に向いています。

• 利用工程：要件定義、移行評価、性能調査、運用改善
• 支援形態：技術顧問など、単一成果物で測りにくい作業
• 定義事項：会議体、担当者、月間稼働時間、報告、優先順位、作業記録

準委任では、時間を確保すること自体が成果ではありません。発注者にも、意思決定とレビューの責任があります。

要件定義は準委任、開発は請負の組み合わせ

検証段階と開発段階で契約を分ける方法もあります。

• 契約の分け方：準委任で要件定義・技術検証、仕様確定後は請負で開発・移行
• 先行検証：互換性、データ品質、ピーク性能、停止時間
• 次工程の条件：成果物、判断基準、次の見積への反映
• 引き継ぎ：設計情報の引き継ぎ先を定め、契約変更後も責任範囲をつなぐ

Azure SQL Databaseのシステム発注費用と相場

費用は、Azure利用料と開発・移行・保守の委託費を分けて考えます。Azure料金は、リージョン、vCoreまたはDTU、サービスレベルで変わります。稼働時間も料金を左右します。

さらに、ストレージやバックアップ、予約の条件も料金に影響します。ライセンス条件も、見積の前提として確かめます。

MicrosoftのAzure SQL Database料金ページは、構成を入力して確認する方式です。次の金額は、2026年時点の料金体系とリサーチノートの一般的な業務システム相場をもとにした概算で、正式な金額ではありません。提案を比べるためのレンジとして利用し、確定した金額とは分けて考えます。

Azure利用料の月額は数万円から数百万円以上までの幅

利用料の幅は、環境数や可用性、データ量で変わり、バックアップなどの構成も影響します。小規模な本番構成では、DB本体にアプリ実行基盤やストレージを加えて考えます。

• 小規模本番：月額5万〜20万円程度の構成例
• 中規模・複数環境・外部連携：月額20万〜80万円程度
• 高可用性・セカンダリ・大容量データ・長期バックアップ・複数リージョン：月額80万〜300万円以上のケース

上の一覧の金額は、固定したSKUの相場ではなく、構成を検討するためのレンジです。為替やリージョン、割引で変動するため、見積には前提も書いてもらいます。

開発環境やPoCでは、自動一時停止や無料オファーで計算料金を抑えられる場合があります。サーバーレスは計算量を秒単位で課金します（出典：Microsoft Learn「Serverless compute tier for Azure SQL Database」、2026年7月更新）。そのため、停止中は計算料金がかからず、ストレージ料金のみになります。

再開の遅れが許容できない常時稼働のシステムには向かない場合があり、接続エラーに備えたリトライ処理も必要です。無料枠や自動停止を設定する場合も、予算アラートと利用状況の確認を組み合わせます。

PoCから大規模刷新までの開発委託費

委託費は、業務の規模や移行・運用の条件で変わります。Azure利用料とは別の費用です。

• PoC・移行評価：100万〜300万円程度
• 小規模業務システム：500万〜1,500万円程度
• 中規模の販売・在庫・顧客管理：1,500万〜5,000万円程度
• 基幹刷新：5,000万円から数億円以上の場合もある

多数の拠点や複雑な既存データを扱うと、委託費は高くなります。段階移行や災害対策、24時間運用を加えると、さらに膨らむ場合があります。

ここでの金額は、Azure利用料ではなく、業務の整理や設計、開発の委託費です。テストや移行、導入支援も、この委託費に含めて考えます。

費用配分の目安は、要件定義10〜15%、基本設計15〜20%、詳細設計10〜15%です。開発は30〜40%、結合・総合テストは15〜20%、移行・導入は5〜10%程度とする考え方もあります。

この比率は、工数や単価を保証する数字ではありません。見積では、人日と単価、範囲の根拠を確認します。前提と除外、Azure実費、保守費の根拠も求めます。

初期費用とランニングコストの合算

見積もりの価格だけでなく、含まれる作業と利用期間中の費用を比べます。

• 別料金になりうる作業：要件定義、データ整備、移行訓練、監視設定、障害対応、Azure料金設計
• 高額見積に含まれる場合：24時間監視、冗長化、復旧訓練、手厚い保守
• 合算する費用：開発、Azure、保守、改修、ライセンス、教育、人件費

3年程度の利用を想定して総額を見ます。品質や復旧条件を削るときは、優先順位を合意したうえで調整します。

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

委託先は、資格や会社規模だけでなく、業務要件をデータ設計と運用へ落とし込めるかで評価します。

同じRFPを渡し、提案の内容と質問、リスクの指摘を比べます。見積の透明性やデータ品質、現場の利用定着も確認します。

特に、既存データの品質や業務の例外を理解していないと、稼働後に問題が起きることがあります。

Azure SQLと業務システムの実績の確認

実績の説明では、サービスレベルや負荷、データ量の条件を聞きます。移行と運用の条件も確かめます。

• 新規開発：要件定義から本番運用までの担当実績
• 既存移行：互換性、停止時間、文字コード、照合順序
• 個別機能：ストアドプロシージャ、ジョブ、外部連携の扱い

可能であれば、担当予定者に匿名化した設計例やテスト計画を説明してもらい、営業担当の話と照らし合わせます。

見積書の同じ単位での比較

各社の工程名をそろえ、作業範囲と月額費用の内訳を比べます。

• 工程：要件定義、設計、アプリ、Azure基盤、移行、テスト
• 付帯費：教育、保守、Azure実費
• 確認項目：成果物、担当、期間、工数、前提、除外事項
• 月額費用：DB、アプリ、監視、ログ、バックアップ、転送

「一式」と書かれた項目には、作業内容と上限を質問します。相見積もりは、価格を競わせるためだけでなく、提案の抜けを確かめるためにも使います。

金額差の理由を聞き、そのうえで選びます。たとえば、移行リハーサルを2回含む提案と、本番切替だけの提案では、条件が異なります。

差分を明らかにしたうえで、必要な品質と予算を選ぶと、追加請求を減らせます。

提案前後に委託先へ聞くべき質問

質問への回答が具体的で、リスクを隠さない会社は比べやすくなります。

• 構成：DB、Managed Instance、SQL VMの比較と選定理由
• 性能・移行：サービスレベルの変更条件、ピーク検証、停止時間、切戻し
• 運用：RTO・RPO、復元訓練、一次回答、休日対応
• 引き継ぎ：IaC、SQL、設計・テスト・運用文書、管理者権限
• 契約終了：再委託先、データ返却、削除の方法

発注後の開発・移行・運用を失敗させない進め方

発注後は、要件定義から運用引き継ぎまでを一つの計画で管理します。設計や開発、テスト、移行、受入も、同じ計画の中で追います。

DB設定だけを先に進めず、業務データと利用者の作業を基準に完了条件を確認します。発注者側の作業も、計画に含めます。

意思決定が遅れると、委託先の作業が止まり、納期前に変更が集中することがあります。

Microsoftの2026年3月の事例では、銀行向けソフトウェア企業Temenosを紹介しています。同社はAzure SQL Database HyperscaleとAzure Kubernetes Serviceを使い、テラバイト級のデータを扱うクラウドネイティブ基盤を構築しています。さらに、50社を超える顧客の移行を進め、600社への展開も準備しています。

出典：Microsoft Customer Stories

Temenos unveils future-ready banking powered by Azure SQL Database Hyperscale。2026年の事例です。

この事例は成果を保証しません。大規模案件では、SKUだけでなく段階移行と可用性も一体で発注します。更新方式や運用体制も、同じ発注の中で扱います。

移行の互換性評価とリハーサル

既存のSQL Serverから移行する場合は、機能と負荷を調べ、切替手順を段階的に試します。

1. スキーマ、テーブル、索引、ビュー、プロシージャ、ジョブ、権限、外部接続を一覧にする
2. 非対応機能や書き換えが必要な処理を特定する
3. ピーク時のSQL、ロック、バッチ、同時更新を再現し性能を測る
4. バックアップ後、テスト移行、差分確認、接続、業務テストを行う
5. 本番リハーサル、切替、ロールバックを順に実施する

停止時間は、技術面だけでなく、業務側の入力締めや確認時間も含めて設計します。

運用に組み込む監視・バックアップ・コスト管理

本番稼働後は、性能や接続、バックアップを監視し、通知先と対応手順を定めます。Query StoreやAzure Monitorでは、クエリ性能、CPU、ストレージを確認します。接続や失敗、バックアップの状況も、確認の対象です。

2025年以降、ベクトル型・関数やJSONネイティブ型は、GAまたは提供対象になっています。改ざん耐性を考慮した長期バックアップや、Microsoft Entraのサーバープリンシパルも対象です。

出典はMicrosoft Learn「What’s new? – Azure SQL Database」です。確認時点は2026年8月です。

新機能を採用する場合は、GAかプレビューかを確認します。リージョンやアプリ互換性、担当者の習熟度も見ておきます。確認した内容は、RFPや変更管理に反映します。

• 費用：月次請求確認、予算アラート、開発環境の停止を定例化
• 保護：バックアップ保持、権限の見直し、復元訓練
• 品質：脆弱性対応、SQL改善、データ確認

DBの管理負担は減っても、データの正確性、SQLの品質、権限の妥当性は、自動では保証されません。また、業務上の復旧判断は、自社と委託先の共同責任です。

保守契約には、監視の対象と対応時間、月次報告を明記します。性能改善や追加改修、障害の切り分け範囲も、契約に書き込みます。

よくある質問

料金や移行、契約、運用では、同じ質問が繰り返し出ます。発注前に確かめたい疑問を取り上げ、それぞれに結論を先に示します。

Azure SQL Databaseのシステム開発費の目安

システム規模ごとの開発委託費は、次のレンジが目安です。

• 小規模業務システム：500万〜1,500万円程度
• 中規模システム：1,500万〜5,000万円程度
• PoC・移行評価：100万〜300万円程度
• 大規模基幹刷新：5,000万円から数億円以上の場合がある

Azure利用料は別に、月額5万〜300万円以上まで構成によって変わります。開発費とクラウドの実費は分けて考えます。相場は、画面数や連携数、データ量で動きます。移行の難易度や可用性の条件でも、変わります。

サーバーレスの料金面の効果と条件

サーバーレスが安くなるかは、利用状況と環境ごとの適性で決まります。

• 断続的なアクセス：停止中の計算料金を抑えられる
• 常時高負荷：プロビジョニング済みが適する場合がある
• 応答と接続：再開遅延と接続リトライを考慮する
• 試算条件：利用パターン、最小・最大vCore、応答時間、ストレージ、バックアップ
• 判断単位：開発・検証環境と本番環境を分ける

既存SQL ServerからAzure SQL Databaseへの移行の進め方

移行は可能ですが、互換性評価とリハーサルは省けません。そのうえで、移行の経験がある会社を選び、移行後の性能と運用も責任範囲に含めます。

1. ストアドプロシージャ、ジョブ、照合順序、外部接続、権限、バッチ、ピーク負荷を確認する
2. テスト環境でデータ件数と業務結果を比較する
3. 本番停止時間、差分反映、切戻し条件、利用者への周知を決める

Azure SQL Databaseに強い開発会社の選び方

選び方は、Azure構築やSQL Server移行の実績、業務要件定義力、セキュリティと運用体制で判断します。提案の場では、サービスレベルの理由や想定負荷、停止時間を質問します。RTO・RPOや除外、成果物、保守時間も確かめます。

資格だけでなく、担当予定者が業務とデータを理解し、リスクを具体的に説明できるか確認します。

まとめ

発注前に業務範囲と品質条件を定めておくことが、成功の土台になります。そのうえで、移行や検証、運用、引き継ぎまで提案を受けます。

発注前に社内で決める事項

Azure利用料と委託費は分けて捉え、要件定義や移行を含めた総額で判断します。セキュリティ、監視、保守も、この総額に含めて考えます。

発注形態は、社内の業務知識と運用体制に応じて、一括、部分委託、内製との組み合わせから選びます。

RFPには、利用者数やピーク負荷、RTO・RPOを書きます。そのほかに、バックアップや認証、監査、再委託、成果物も含めます。

委託先と見積を比べるときの結論

比べるときは、最安値だけで決めるのではなく、提案の前提や引き継ぎ条件をそろえて確認します。

• 見積条件：前提、除外、移行リハーサル、検収
• 運用・契約：障害対応、契約後の引き継ぎ
• 新機能への備え：要件、データ品質、運用能力を先に整える
• 見極め方：根拠ある相見積もりと段階検証でリスクを抑える

2026年には、Azure SQL Databaseで選べる機能が広がっています。AI検索やJSON、Microsoft Entra、バックアップ保護、可用性の選択肢が含まれます。

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

▼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を創業。