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

Azure App Serviceのシステム開発を発注・外注するなら、App Serviceの構築だけでなく、業務要件、Azure SQLなどの周辺サービス、データ移行、監視、リリース後の保守までを一つの計画として委託することが重要です。

この記事では、Azure App Serviceを使った業務システムの発注形態、RFPと要件整理の進め方、契約形態、費用相場、委託先の選び方、見積書の比較ポイントを解説します。初めてAzureを使う企業でも、何を決めてから開発会社へ相談すればよいか判断できるように、実務で見落としやすい論点まで整理します。

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

Azure App Serviceのシステムを外注する前に知る全体像

Azure App Serviceは、WebアプリケーションやREST APIを動かすフルマネージドのPaaSです。サーバーOSやミドルウェアのパッチ適用、ロードバランサーなどの基盤運用をAzure側へ寄せられるため、開発会社は業務ロジック、画面、データ、認証、連携、運用設計に集中できます。

Azure App Serviceを契約すれば業務システムが完成するわけではありません。利用者の画面やAPIはApp Serviceに配置しますが、データはAzure SQL DatabaseやPostgreSQL、ファイルはBlob Storage、認証はMicrosoft Entra ID、秘密情報はKey Vault、ログと性能監視はApplication InsightsやAzure Monitorを組み合わせる構成が一般的です。定期処理をWebJobsやAzure Functions、外部サービスとの連携をLogic AppsやService Busに分けることもあります。

そのため、見積書に「App Service環境構築一式」とだけ書かれている場合は注意が必要です。実際に確認すべきなのは、業務アプリの機能、データベース、バックアップ、ネットワーク、認証、監視、デプロイ、移行、問い合わせ対応がどこまで含まれるかです。発注側がこの責任範囲を把握しないまま進めると、後から追加費用が発生しやすくなります。

発注前に予算を三つへ分けると、比較がしやすくなります。一つ目は要件定義、設計、開発、テスト、移行などの初期開発費です。二つ目はApp Serviceプラン、データベース、ストレージ、ログ、通信、バックアップなどのAzure月額費です。三つ目は障害対応、脆弱性対応、Azure料金の見直し、機能追加、利用者サポートなどの保守・改善費です。

「PaaSなのでサーバー費が安い」という理解だけで発注すると、周辺リソースや運用工数を見落とします。Microsoftの公式説明でも、App Serviceの料金はAzure請求額の一部にすぎず、サブスクリプション上の他のリソースにも課金されると案内されています。出典はMicrosoft Learn「App Serviceのコストの計画と管理」（2026年8月確認）です。

Azure App Serviceの発注形態はどれを選びますか？

発注形態は、業務要件が固まっているか、社内にプロジェクトを管理できる人材がいるか、納期と予算をどこまで固定したいかで選びます。すべての会社に同じ契約が合うわけではなく、要件の不確実性と発注側の関与度を基準に判断することが大切です。

請負契約は、受託会社が合意した成果物を完成させ、発注側が検収する形です。画面一覧、機能一覧、性能、対応ブラウザ、連携仕様、移行対象、納品物、受入条件を決められる案件では、予算と納期を管理しやすくなります。新規の社内申請システムや、機能が比較的定型化した業務アプリなどが候補です。

ただし、契約後に「現場から新しい要望が出た」「旧システムのデータが想定より汚れていた」といった事態が起こると、変更管理が必要です。請負だから追加費用が一切出ないのではなく、当初の仕様外を変更要求として扱うルールを契約書とプロジェクト運営に入れておきます。

準委任契約や時間単価型の契約は、稼働時間や体制に応じて業務を委託し、要件定義や優先順位を調整しながら進める方式です。既存.NETシステムの調査、段階的なモダナイズ、業務部門との対話が多いプロジェクトでは、最初からすべての仕様を固定しにくいため適しています。

一方で、作業量が増え続けると予算が膨らむため、月ごとの上限工数、担当者、成果物、レビュー方法、報告内容を決めます。「何時間働いたか」だけでなく、要件一覧、設計書、ソースコード、テスト結果、課題表など、何が残る契約なのかを確認することが重要です。

Azureに詳しいか分からない段階で本開発を一括発注する場合は、最初に要件定義や技術検証だけを発注する方法があります。認証方式、既存データとの接続、ピーク時の性能、Private Endpointの可否、旧.NET資産の移行難易度を小さな検証で確認し、その結果を本開発のRFPへ反映します。

段階発注では、PoCが成功したら必ず同じ会社へ本開発を頼まなければならない、という条件にしないことも大切です。検証成果物の所有権、設計情報の引き渡し、他社が引き継げる形式、PoC費用を本開発費へ充当する条件を事前に確認すると、選択肢を残したままリスクを下げられます。

Azure App Serviceの発注・外注はどの順番で進めますか？

発注プロセスでは、技術の話を先に決めるより、業務上の目的と非機能要件を先にそろえます。その後にApp Serviceを中心とした構成、開発体制、移行方法、運用分担を決めると、Azureを使うこと自体が目的になるのを防げます。

最初に、誰が、いつ、何のためにシステムを使うかを整理します。利用者数、部門と権限、申請や承認の流れ、入力と出力、帳票、外部API、メール通知、データの保存年限、個人情報の有無を一覧にします。現行システムがある場合は、画面一覧、データ項目、バッチ、連携先、障害履歴、運用担当者も集めます。

特に移行案件では、「移すデータの件数」だけでなく、重複、欠損、コード体系の違い、日付形式、添付ファイル、過去データの保存義務を確認します。データクレンジングを発注範囲から外すと、開発が終わっても移行できない事態が起こるため、サンプルデータを使った移行検証を初期計画に入れます。

構成案では、画面とAPIをApp Service、データをAzure SQL Database、ファイルをBlob Storage、ID管理をMicrosoft Entra ID、秘密情報をKey Vault、監視をApplication Insightsとするように、各サービスの責務を明確にします。定期処理やキュー処理をFunctionsやWebJobsへ切り出すか、外部連携にLogic AppsやService Busを使うかも、処理量と運用体制を見ながら決めます。

個人情報や社内基幹情報を扱うなら、HTTPS専用、TLSの最低バージョン、RBAC、マネージドID、Key Vault、アクセス制限、バックアップ、ログ保存期間、アラート、復旧手順を要件に書きます。App Serviceの標準公開エンドポイントを使うのか、Private EndpointとVNetを組み合わせるのかは、ネットワーク図と通信方向を確認して決めます。

設計と開発では、開発環境、検証環境、本番環境を分離し、BicepやTerraformなどのIaCとGitHub ActionsやAzure DevOpsなどのCI/CDを使うかを決めます。デプロイスロットを用いた段階リリース、切り戻し、バックアップからの復元、負荷試験、障害通知までを本番前に確認します。Microsoft Learnでも、App Serviceのデプロイではソース、ビルドパイプライン、デプロイ方式を分けて考えることが示されています。出典はMicrosoft Learn「Deployment best practices」（2026年8月確認）です。

受入条件には、機能テストの合格だけでなく、応答時間、同時利用者数、エラー時の表示、権限の組み合わせ、データ移行件数、復旧時間、ログの確認方法を含めます。リリース後に誰がアラートを受け、誰がAzureの設定を変更し、どの範囲を月額保守で対応するかを決めてから検収します。

RFPと要件整理では何を発注先へ伝えますか？

RFPは、開発会社へ同じ条件で提案と見積を求めるための資料です。分厚い仕様書を最初から作る必要はありませんが、目的、対象業務、現行課題、想定利用者、希望時期、予算の考え方、必須要件、提案してほしい項目をそろえると、見積の前提がそろいます。

目的には「紙の申請を減らす」「承認状況を可視化する」「既存.NETシステムを段階的に移行する」のように、導入後の成果を書きます。範囲には対象部門、対象拠点、対象業務、対象データ、外部連携を記載します。非機能では可用性、性能、同時接続、RTO、RPO、バックアップ、監査ログ、個人情報、利用地域、サポート時間を伝えます。

さらに、納品物をソースコード、画面・API仕様書、データ定義書、インフラ構成図、IaC、テスト仕様書、移行結果、運用手順書、教育資料まで具体化します。ソースコードと設計書を誰が保管し、契約終了時に何を返却し、第三者が引き継げるかは、RFPの段階で質問に入れておくべき項目です。

Azure App Serviceのプラン、インスタンス数、リージョン、OS、ランタイム、コンテナー、データベースの性能、データ転送、ログ保存、バックアップ、スロット数を提案書に書かせます。FreeやSharedを検証用に使うのか、本番はBasic以上の専用コンピュートにするのかも確認します。複数アプリを一つのApp Serviceプランで共有する場合は、コストを抑えられる一方で、負荷や障害の影響範囲が同じになるため、その理由を説明してもらいます。

社内ネットワークやオンプレミスから接続する場合は、VNet統合が送信通信のためなのか、Private Endpointが受信通信のためなのかを分けて確認します。Microsoft公式情報でも、VNet統合とPrivate Endpointは役割が異なり、Private Endpointを使う場合はパブリックネットワークアクセスを無効化する設計が検討されます。出典はMicrosoft Learn「ネットワーク機能」（2026年8月確認）です。

良い提案書は、App Serviceを使う理由だけでなく、Azure VM、Container Apps、Functions、AKS、App Service Environmentを比較し、採用しない理由も説明します。たとえば、一般的なWeb業務アプリならApp Service、OS依存や特殊なドライバが強いならVM、非常に大規模でネットワーク完全分離が必要ならASEを検討するというように、要件と選択肢を対応させます。

また、データ移行の難しさ、旧システムとの並行稼働、性能不足、Azure料金の増加、属人化、再委託、障害時の連絡遅延などをリスク表で示しているか確認します。リスクが書かれていない提案は安心に見えても、実行段階で問題が初めて発見される可能性があります。

契約形態と責任分界はどこまで決めますか？

Azureのシステム開発では、開発会社、Azure、発注企業、社内の利用部門が関係します。クラウド障害ならMicrosoft、アプリの不具合なら開発会社、要件変更なら発注側というように、原因によって対応主体が変わるため、契約書だけでなく責任分界表に落とすことが有効です。

請負なら、成果物の定義、検収期間、瑕疵への対応、納期、遅延時の扱い、仕様変更の見積手順を決めます。準委任なら、業務範囲、稼働時間、報告義務、作業場所、プロジェクト管理、成果物の扱い、契約更新、終了時の引き継ぎを決めます。どちらでも、Azureの利用料は開発費に含むのか、発注企業のテナントへ直接請求するのかを明確にします。

検収の基準が「問題なく使えること」だけだと、担当者によって判断が変わります。画面ごとの受入条件、処理時間、エラー処理、権限、ログ、復旧テスト、移行結果、運用手順書の受領までを確認項目にします。

個人情報を扱うシステムでは、Azureのセキュリティ機能だけでなく、発注企業と委託先の管理体制を確認します。アクセス権限、ログ確認、秘密保持、事故時の報告期限、脆弱性対応、バックアップ、データ返却・削除、再委託先、国外での取扱い、監査への協力を契約と運用手順に反映します。個人情報保護委員会のガイドラインでも、委託先の選定、契約、取扱状況の把握など、委託元による監督が重要になります。出典は個人情報保護委員会「個人情報保護法ガイドライン（通則編）」（2026年8月確認）です。

開発会社が別の会社へ運用や開発を再委託する場合は、再委託の承認条件、再委託先の管理責任、データへアクセスできる範囲を確認します。発注時に会社名だけでなく、実際に作業するチームの経験と権限設計を確認することが大切です。

可能であれば、Azureサブスクリプションやリソースグループは発注企業が所有し、開発会社には必要なRBAC権限だけを付与します。開発会社のアカウントだけで本番環境を管理すると、契約終了時や担当者交代時にアクセスできなくなるおそれがあります。リポジトリ、CI/CD、ドメイン、証明書、監視通知も誰が管理するかを決めます。

運用移管では、構成図と手順書を受け取るだけでなく、発注側の担当者が実際にデプロイ、ロールバック、ログ確認、バックアップ復元、権限変更を行う演習を実施します。引き継ぎ完了の条件を契約上の成果物とし、属人化を残したまま保守契約だけ更新する状態を避けます。

Azure App Serviceのシステム開発費用相場はいくらですか？

Azure App Serviceを使った業務システムの費用は、アプリの規模、業務の複雑さ、データ移行、外部連携、セキュリティ、可用性、運用時間で大きく変わります。以下は、NotebookLMの業務システム相場とApp Service固有の構成要素を組み合わせた、2025〜2026年時点の予算検討用レンジです。公式見積ではなく、要件確定前の初期目安として利用します。

ログイン、権限、CRUD、簡単な申請、Azure SQL、CI/CD、基本的な監視を含む小規模な社内Webシステムなら、初期開発・構築費は300万〜800万円程度、期間は2〜4か月程度が予算検討の目安です。Azureの月額運用費は、1環境か複数環境か、データベースの性能、ログ保存、バックアップ、通信量で変わりますが、1万〜8万円程度から検討するケースがあります。

このレンジでも、本番用と検証用の環境を分けるか、シングルサインオンを使うか、帳票やファイル添付があるかで工数は増えます。機能を削るだけでなく、必須の運用とセキュリティを残したうえで、初回リリースの範囲を分けることが大切です。

複数部門のワークフロー、細かな権限、帳票、外部API、メール通知、データ移行、監視、運用設計まで含む中規模の業務システムでは、初期費用は800万〜3,000万円程度、期間は4〜9か月程度が目安になります。Azure等の月額運用費は5万〜30万円程度から検討しますが、可用性、監査ログ、Private Endpoint、WAF、バックアップ世代数で上振れします。

旧システムの移行では、移行ツールの作成、データクレンジング、リハーサル、並行稼働、切り戻し計画を費用に含めます。見積書で「データ移行一式」となっている場合は、対象テーブル数、件数、添付ファイル、検証回数、利用部門の確認作業まで分解して確認します。

基幹システム連携、旧.NET資産の移行、複数リージョンや冗長化、Private Endpoint、厳格な監査、複数環境、24時間監視まで含む場合は、初期費用3,000万〜1億5,000万円以上、期間9〜18か月以上となる可能性があります。Azureの月額運用費も20万〜150万円以上のレンジを見込み、App Serviceだけでなく、データベース、ネットワーク、ログ、セキュリティ製品、バックアップを合わせて試算します。

Microsoftの料金ページでは、App Serviceの価格はプランのSKUとインスタンス数を軸に計算され、複数アプリを一つのプランでホストできると説明されています。NotebookLMのリサーチノートが2026年8月に確認した表示では、WindowsのB1が月額54.75米ドル、B2が109.50米ドル、B3が219米ドルでした。ただし、リージョン、為替、税、割引、インスタンス数、周辺サービスで変動するため、契約前はMicrosoft Azureの最新料金ページと料金計算ツールで再計算します。

保守・改善費は、NotebookLMの一般的な業務システム相場では初期費用の年15〜20%程度を置く考え方があります。たとえば初期開発費が3,000万円なら、年450万〜600万円程度が一つの予算仮置きになりますが、24時間監視、SLA、追加改修、問い合わせ件数、Azure料金の最適化を含むかで大きく変わります。固定額ではなく、月額保守の範囲と別途作業の単価を分けて提示してもらいます。

委託先の選定と見積比較では何を確認しますか？

委託先は、Azureの資格やロゴだけで判断せず、業務要件定義から移行、運用引き継ぎまで担当できるかで比較します。App Serviceを使える会社でも、業務フローを整理できない、データ移行を経験していない、障害時の運用体制がない場合は、発注後に別会社が必要になることがあります。

実績確認では、会社名や導入社数ではなく、自社と似た条件を質問します。App Service、Azure SQL、Entra ID、Key Vault、Private Endpoint、Application Insightsを実際に使ったか、データ移行は何件程度か、旧.NETからの移行でどの課題があったか、リリース後の監視と改善を誰が担当したかを確認します。

提案時の担当者と開発・運用担当者が同じかも重要です。プロジェクトマネージャー、アーキテクト、業務設計者、アプリ開発者、インフラ担当、テスト担当、保守担当の役割と稼働時期を提示してもらいます。再委託がある場合は、作業会社と責任者を明示してもらいます。

見積比較では、総額が安い会社をすぐに選びません。要件定義、基本設計、詳細設計、製造、テスト、移行、導入、教育、運用設計を工程ごとに分け、担当ロール、人日、単価、期間、前提条件を確認します。初期費用とAzure利用料、保守費、追加改修費を分けてもらうと、安いように見せるための費用の付け替えを見つけやすくなります。

見積書には、Azure料金の算定条件として、リージョン、OS、SKU、インスタンス数、稼働時間、データベースのサイズ、ストレージ量、ログ保存期間、通信量、バックアップ世代、監視対象を記載してもらいます。公式料金は改定や為替の影響を受けるため、月額を固定値ではなく、前提と上限額で示す方法も有効です。

価格比較では、要件定義の深さ、脆弱性対応、監視時間、障害の一次切り分け、復旧目標、問い合わせ受付、定例会、Azure料金の最適化、改善提案を同じ条件で比べます。安い見積が、監視や移行リハーサルを含んでいないだけの場合もあるため、含まれない作業を明示してもらいます。

特に本番リリース後の運用では、アラートを誰が受け、何分以内に確認し、どの条件でエスカレーションし、Microsoftへの問い合わせを誰が行うかを確認します。発注側にAzure管理者がいないなら、運用教育と権限設計を見積へ含めます。3社以上へ同じRFPを渡し、提案内容と金額の差を質問で埋めると、単純な総額比較より納得して選定できます。

Azure App Serviceのシステム発注でよくある質問

ここでは、発注前に特に質問されやすい内容へ回答します。Azureの料金や機能は更新されるため、最終的な契約条件とサービス仕様は、見積時点のMicrosoft公式情報で確認します。

本番の業務システムでは、FreeやSharedを前提にしないことをおすすめします。Microsoftのコスト管理情報では、FreeとSharedには返金制度のあるSLAが設定されていないと説明されており、これらは開発・検証用の選択肢として扱うのが基本です（出典: Microsoft Learn「App Serviceのコストの計画と管理」、2026年8月確認）。本番は可用性、性能、バックアップ、監視、セキュリティ要件に応じてBasic以上やStandard、Premiumを比較します。

性能やメモリ、インスタンス数、リージョン、送信元IPの要件を確認してから選びます。Premium v4は高速なプロセッサ、NVMeローカルストレージ、メモリ最適化オプションを提供しますが、安定した送信IPアドレスがないため、必要ならNAT Gatewayを組み合わせます。また、利用可能なリージョンや可用性ゾーンは構成によって異なるため、価格だけで既存アプリを移行せず、負荷試験とネットワーク確認を行います。出典はMicrosoft Learn「Premium v4レベルの構成」（2026年8月確認）です。

必須かどうかは、利用者、接続元、公開範囲、社内ネットワーク、監査要件、データの機微性、WAFやVPNとの組み合わせで判断します。Private Endpointを使えば、プライベートネットワーク内のクライアントからAzure Private Link経由でApp Serviceへ接続でき、パブリックネットワークアクセスを無効にする設計も可能です。ただし、DNS、受信と送信の通信、VNet統合、監視、運用手順を含めて設計する必要があります。

要件が同じ条件で比較できるなら、3社以上へ相見積もりを依頼するのが現実的です。会社数を増やしすぎると質疑応答と提案評価に時間がかかるため、Azure実績、業務理解、移行経験、運用体制を確認して候補を絞ります。総額だけでなく、工程別工数、Azure利用料、保守範囲、追加改修単価、納品物、再委託、引き継ぎ条件までそろえて比較します。

まとめ

Azure App Serviceのシステムを発注・外注するときは、App Serviceの料金や構築作業だけで判断せず、業務要件、データ、認証、ネットワーク、監視、移行、保守まで含めて委託範囲を定義します。発注形態は、要件が固まった範囲を請負にし、調整が多い範囲を準委任にするなど、プロジェクトの不確実性に合わせて選びます。

まず、目的、対象業務、利用者、データ、外部連携、希望時期、非機能要件、移行範囲、運用体制を一枚にまとめます。次に、開発費、Azure月額、保守・改善費を分け、予算の前提を明らかにします。その資料を使って3社以上へRFPを渡し、工程別見積、Azure料金の条件、納品物、契約形態、セキュリティ、引き継ぎを同じ軸で比較します。

App Serviceが適しているか迷う場合も、最初からプランを決める必要はありません。App Service、Functions、VM、Container Apps、ASEなどを、業務の性質、性能、セキュリティ、運用負荷、将来の拡張性で比較し、必要なら要件定義やPoCから発注します。発注側が業務の判断を担い、委託先が設計と実装の根拠を説明できる体制を作ることが、Azure App Serviceのシステム開発を成功させる近道です。

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

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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