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

Azure App Serviceのシステム開発は、業務と要件を整理し、発注形態を選んでから、契約と見積を比べる流れで進めます。

RFPや責任分界まで決めておくと、追加費用や運用の抜けを抑えられます。全体像はAzure App Serviceのシステム開発の完全ガイドもご覧ください。

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

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

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

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

App Serviceの位置づけは実行基盤

業務システムとして完成させるには、App Serviceだけでなく周辺サービスを組み合わせる構成が一般的です。次のように、役割ごとにサービスを分けて使います。

• 画面・API：Azure App Serviceに配置
• データ・ファイル：Azure SQL Database、PostgreSQL、Blob Storage
• 認証・秘密情報：Microsoft Entra IDとKey Vault
• 監視：Application InsightsやAzure Monitor
• 定期処理・外部連携：WebJobs、Functions、Logic Apps、Service Busへ分ける場合があります。

見積書に「App Service環境構築一式」とだけあれば、業務アプリの機能やデータベースがどこまで含まれるかを確かめます。

また、バックアップやネットワーク、認証の責任範囲も確認対象です。範囲を把握しないまま進めると、追加費用が発生しがちです。

予算の分け方：開発費・Azure月額・保守改善費

発注前に予算を三つに分けておくと、見積を比べやすくなります。

• 初期開発費：要件定義、設計、開発、テスト、移行など
• Azure月額費：App Serviceプラン、DB、ストレージ、ログ、通信、バックアップなど
• 保守・改善費：障害・脆弱性対応、料金見直し、機能追加、利用者サポートなど

「PaaSなのでサーバー費は安い」と考えると、周辺リソースや運用工数を見落とします。

Microsoft Learnによると、App Serviceの料金はAzureの請求額の一部で、ほかのリソースにも課金されます（出典：Microsoft Learn「App Serviceのコストの計画と管理」、2026年8月確認）。

Azure App Serviceの発注形態の選び方

発注形態は、要件の確定度、社内で管理できる人材、納期と予算を固定したい度合いで選びます。要件の不確実性と、発注側がどこまで関わるかで判断します。

一括請負の適した案件

請負契約は、合意した成果物を受託会社が完成させ、発注側が検収する形です。完成条件を明確にできる案件に向いていて、画面や連携、検収の条件を事前に決められるかが目安になります。

• 画面・機能：一覧、性能、対応ブラウザを定義できる
• 連携・移行：連携仕様と移行対象の範囲
• 検収・納品：納品物と受入条件への合意

新規の社内申請システムや、機能が比較的定型化した業務アプリが候補になります。

契約後に新しい要望が出たり、旧システムのデータが想定より汚れていたりすると、変更を管理する必要が出てきます。ただし、請負でも仕様外の変更には追加費用が生じる場合があります。

契約書とプロジェクト運営には、当初の仕様外の要望を変更要求として扱うルールを入れておきます。

準委任・時間単価型の適した案件

準委任や時間単価型は、稼働時間や体制に応じて業務を委託し、要件や優先順位を調整しながら進める方式です。既存.NETシステムの調査や段階的なモダナイズに適しています。

業務部門との対話が多く、最初から仕様を固定しにくいプロジェクトも候補になります。ただし、作業量が増え続けると予算が膨らむため、月ごとの上限工数と担当者を定めます。成果物、レビュー方法、報告内容も決めておきます。

作業時間だけでなく、何が成果物として残る契約なのかを確認します。要件一覧や設計書、ソースコードのほか、テスト結果や課題表も残るかを確かめます。

要件定義・PoCと本開発を分ける段階発注

Azureの適性が分からない段階では、要件定義や技術検証を先に発注できます。たとえば、小規模な検証で次の論点を確かめます。

• 接続・認証：認証方式と既存データとの接続。
• 性能・ネットワーク：ピーク時の性能とPrivate Endpointの可否。
• 移行難易度：旧.NET資産を移行できるか。

検証結果は、本開発のRFPに反映します。また、PoCの成功後に同じ会社へ本開発を頼む条件は、固定しないでおきます。

検証成果物の所有権と設計情報の引き渡しを、事前に確認します。他社が引き継げる形式かどうかや、PoC費用を本開発費に充てる条件も確かめます。

Azure App Serviceの発注・外注の進め方

技術より先に、業務上の目的と非機能要件をそろえます。その後に、App Serviceを中心とした構成と開発体制を決めます。移行方法と運用分担も続けて決めると、Azure導入そのものが目的になるのを防げます。

業務と現行システムの洗い出し

業務と現行システムは、次の観点ごとに一覧にしておきます。

• 業務・利用者：誰がいつ何のために使うか、利用者数、部門・権限。
• 業務データ：申請承認の流れ、入出力、帳票、API・通知、保存年限と個人情報。
• 現行システム：画面、データ項目、バッチ、連携先、障害履歴、運用担当者。
• 移行データ：件数、重複、欠損、コード・日付形式、添付、過去データの保存義務。
• 移行検証：サンプルデータを使う検証を初期計画に含める。

データクレンジングを発注範囲から外すと、開発を終えても移行できない事態が起こり得ます。

アプリ・データ・認証・運用の責務の分担

構成案では、各サービスの責務を次のように分けます。

• アプリ・データ：画面とAPIはApp Service、データはAzure SQL Database。
• ファイル・ID・秘密情報：Blob Storage、Microsoft Entra ID、Key Vault。
• 監視・定期処理：Application Insightsで監視し、FunctionsやWebJobsへ分ける。
• 外部連携：Logic AppsやService Busの利用を処理量と運用体制から決める。

個人情報や社内基幹情報を扱うなら、HTTPS専用とTLSの最低バージョンを要件に入れます。RBACやマネージドIDも、要件として定めます。

Key Vault、アクセス制限、バックアップを要件に書きます。ログ保存期間、アラート、復旧手順は、障害に備えて要件に入れます。

標準の公開エンドポイントにするか、Private EndpointとVNetの組み合わせにするかは、ネットワーク図と通信方向を確認して決めます。

開発・テスト・リリース・運用移管の受入条件

開発・検証・本番の環境を分け、IaCとCI/CDを使うかを決めます。

1. IaCはBicepやTerraform、CI/CDはGitHub ActionsやAzure DevOpsなどから選びます。
2. 本番前に、デプロイスロットの段階リリースや切り戻し、バックアップ復元、負荷試験、障害通知を試しておきます。
3. 受入条件には、応答時間や同時利用者数、エラー表示、権限を含めます。移行件数、復旧時間、ログ確認方法も、受入条件に入れます。
4. アラート受信者、Azure設定の変更担当、月額保守の範囲を決めてから検収します。

Microsoft Learnは、App Serviceのデプロイでソース、ビルドパイプライン、デプロイ方式を分けて考えるよう示しています（出典：Microsoft Learn「Deployment best practices」、2026年8月確認）。

RFPと要件整理で伝える内容

RFPは、同じ条件で提案と見積を開発会社に求めるための資料です。

最初から分厚い仕様書を作らなくても、目的、対象業務、現行課題、想定利用者を示せます。希望時期と予算の考え方、必須要件、提案項目も加えると、前提を合わせやすくなります。

RFPに書く目的・範囲・非機能・納品物

RFPには、目的と範囲を具体的に書きます。

• 目的：「紙の申請を減らす」「承認状況を見えるようにする」「既存.NETを段階移行する」など。
• 対象範囲：部門、拠点、業務、データ、外部連携。
• 非機能要件：可用性、性能、同時接続、RTO、RPO、バックアップの条件。監査ログ、個人情報、利用地域、サポート時間も含めます。
• 納品物：ソースコード、画面・API仕様、データ定義、構成図、IaC。テスト仕様、移行結果、運用手順、教育資料も含めます。

ソースコードと設計書の保管者、契約終了時の返却物、第三者が引き継げる形式も、RFPで質問します。

Azure固有の質問による回答の差

Azure固有の提案は、構成、プラン共有、ネットワークの前提をそろえて比べます。

• App Service条件：プラン、台数、リージョン、OS。ランタイム、コンテナー、スロット数も含めます。
• 周辺サービス条件：DB性能、データ転送、ログ保存、バックアップ。
• プラン共有：FreeやSharedを検証用にするか、本番をBasic以上にするか。
• 接続方式：VNet統合は送信、Private Endpointは受信通信のためかを確認する。

複数アプリでプランを共有するとコストを抑えられます。ただし、負荷や障害の影響範囲は共通になるため、その理由も説明してもらいます。

Microsoftの公式情報では、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年時点の予算検討用の幅です。

この数値は、要件が確定する前の初期目安として使います。公式見積とは別に考えます。

小規模な社内Webシステムの初期費用の目安：300万〜800万円

小規模な社内Webシステムの見積では、費用、機能範囲、変動要因を分けて確認します。

• 初期費用・期間：300万〜800万円程度、2〜4か月程度。
• 基本機能：ログイン、権限、CRUD、簡単な申請。Azure SQL、CI/CD、基本監視も含みます。
• Azure月額：1万〜8万円程度から。環境数、DB性能、ログ、バックアップ、通信量で変わります。
• 工数の変動要因：本番・検証環境の分離、シングルサインオン、帳票、ファイル添付。

必須の運用とセキュリティは残したうえで、初回リリースの範囲を分けます。

ワークフロー・連携・移行を含む場合：800万〜3,000万円程度

中規模システムは、複数部門のワークフローや権限、帳票を含みます。さらに、外部APIや通知、移行、監視、運用設計も含みます。

初期費用は800万〜3,000万円程度、期間は4〜9か月程度が目安です。

Azureなどの月額は5万〜30万円程度から検討しますが、可用性や監査ログ、Private Endpoint、WAF、バックアップ世代数によって上振れします。

• 移行範囲：「移行一式」はテーブル数、件数、添付、検証回数、利用部門の確認作業に分けます。
• 移行費用：ツール、データ整備、リハーサル、並行稼働、切り戻し計画を含めます。

基幹連携・厳格な分離を含む場合：3,000万円〜1億5,000万円以上

大規模案件では、基幹連携や旧.NET移行を含む場合があります。

複数リージョンや冗長化、Private Endpointも対象になります。厳格な監査や複数環境、24時間監視も対象に含まれます。

• 初期費用・期間：3,000万〜1億5,000万円以上、9〜18か月以上となる可能性があります。
• Azure月額：20万〜150万円以上。DB、ネットワーク、ログ、セキュリティ、バックアップも試算します。
• App Service料金：SKUと台数で計算し、一つのプランで複数アプリをホストできます。
• Windows料金：B1 54.75ドル/月、B2 109.50ドル/月、B3 219ドル/月（NotebookLM確認、2026年8月）。
• 保守・改善費：初期費用の年15〜20%程度を置く考え方。

料金は、リージョン、為替、税、割引、台数、周辺サービスによって変わります。そのため、契約前にMicrosoft Azureの最新料金ページと料金計算ツールで再計算します。

この目安はNotebookLMの一般的な業務システム相場に基づく考え方です。たとえば、初期費用が3,000万円なら、年450万〜600万円程度が予算の仮置きです。

保守費は、24時間監視やSLA、追加改修、問い合わせ件数、料金最適化の有無で変わります。月額保守の範囲と、別作業の単価を分けて提示してもらいます。

委託先の選定と見積比較の観点

委託先は、業務要件の定義から移行、運用の引き継ぎまで担えるかで比べます。Azureの資格やロゴは、その確認の材料として見ます。業務フロー整理や移行経験、障害時の運用体制が不足すると、発注後に別の会社が必要になる場合があります。

類似案件の構成・移行・運用実績

会社名や導入社数よりも、自社に近い条件の実績を確認します。

• アプリ・DB：App ServiceとAzure SQLの利用経験。
• ID・秘密情報：Entra IDとKey Vaultの構成経験。
• ネットワーク・監視：Private Endpoint、Application Insightsの経験。
• 移行・運用：移行件数、旧.NET移行の課題、監視・改善担当者。
• チーム・再委託：担当の役割と稼働時期、作業会社、責任者。

PMやアーキテクト、業務設計者の役割と稼働時期を提示してもらいます。アプリ開発やインフラ、テスト、保守の担当についても示してもらいます。

提案を担当する人と、開発・運用を担当する人が同じかどうかも確かめます。

見積の内訳：工程・人日・単価・Azure利用料

見積は総額だけでなく、次の内訳を同じ条件で比べます。

• 工程：要件定義、基本・詳細設計、製造、テスト。移行、導入、教育、運用設計も含めます。
• 工数・単価：担当ロール、人日、単価、期間、前提条件。
• 費用区分：初期費用、Azure利用料、保守費、追加改修費。
• Azure構成：リージョン、OS、SKU、台数、稼働時間、DB・ストレージ規模。
• 運用条件：ログ期間、通信量、バックアップ世代、監視対象。

費用を分けて見ると、安く見せるための付け替えを見つけやすくなります。

公式料金は改定や為替で変わるため、月額は前提と上限額で示してもらう方法もあります。

セキュリティ・サポート・引き継ぎの条件

価格と合わせて、次のセキュリティとサポートの条件を比べます。

• 保守：要件定義の深さ、脆弱性対応、監視時間、一次切り分け、復旧目標。
• 相談・改善：問い合わせ受付、定例会、料金最適化、改善提案。
• 運用対応：アラート受信者、確認までの時間、エスカレーション、Microsoftへの問い合わせ担当。
• 発注側支援：Azure管理者がいない場合の運用教育と権限設計。

安い見積では、監視や移行リハーサルが含まれない場合があります。そのため、対象外の作業を明示してもらいます。

3社以上へ同じRFPを渡し、提案と金額の差を質問で埋めると、総額だけで比べるより納得して選べます。

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

発注前によくある質問に答えます。料金や機能は更新されるため、契約条件と仕様は見積の時点のMicrosoft公式情報で確かめます。

FreeやSharedのApp Serviceを本番システムに使えますか？

本番の業務システムでは、FreeやSharedを前提にしないことをおすすめします。その根拠として、Microsoftのコスト管理情報では、両プランに返金制度のあるSLAは設定されていないとされ、開発・検証用が基本とされています（出典：Microsoft Learn「App Serviceのコストの計画と管理」、2026年8月確認）。

本番は、可用性や性能、バックアップ、監視、セキュリティの要件に応じて、Basic以上やStandard、Premiumを比べます。

2026年時点でPremium v4を選ぶべきですか？

性能、メモリ、インスタンス数、リージョン、送信元IP要件を確認して選びます。Premium v4は、高速プロセッサやNVMeローカルストレージ、メモリ最適化オプションを提供します。

安定した送信IPアドレスがないため、必要に応じてNAT Gatewayを組み合わせます。利用可能なリージョンや可用性ゾーンは構成によって違うため、価格を見たうえで、負荷試験とネットワーク確認を行います（出典：Microsoft Learn「Premium v4レベルの構成」、2026年8月確認）。

個人情報を扱うならPrivate Endpointは必須ですか？

必須かどうかは、利用者や接続元、公開範囲、社内ネットワークを見て判断します。監査要件やデータの機微性、WAFやVPNとの組み合わせも、判断の材料になります。

Private Endpointでは、プライベートネットワーク内のクライアントが、Azure Private Link経由で接続できます。また、パブリックネットワークアクセスを無効にする設計も可能です。

DNSや受信・送信通信、VNet統合、監視、運用手順も設計します。

何社に相見積もりを依頼すればよいですか？

同じ要件で比べられるなら、3社以上へ依頼するのが現実的です。会社数を増やしすぎると、質疑と評価に時間がかかるため、Azure実績や業務理解、移行経験、運用体制を確かめて絞り込みます。

総額だけでなく、工程別の工数とAzure利用料、保守範囲を同じ条件でそろえて比べます。追加改修単価や納品物、再委託、引き継ぎ条件も、並べて見ます。

まとめ

発注時は、App Service料金や構築作業だけでなく、業務要件やデータ、認証、ネットワークまで委託範囲を定めます。監視、移行、保守も範囲に含めます。

要件が固まった範囲は請負、調整の多い範囲は準委任にするなど、不確実性に合わせて使い分けます。

発注前に用意する一枚の要件資料と三つの予算

目的、対象業務、利用者、データ、外部連携を一枚にまとめます。希望時期、非機能要件、移行範囲、運用体制も書き込みます。開発費、Azure月額、保守・改善費を分けて、予算の前提を示します。

資料を使って3社以上へRFPを渡し、工程別の見積やAzure料金の条件、納品物、契約形態、セキュリティ、引き継ぎを、同じ条件で比べます。

技術選定より先に相談する業務と責任分界

App Serviceが適しているか迷う場合も、最初にプランを決めなくて構いません。候補としては、App Service、Functions、VM、Container Apps、ASEがあります。

• 業務：システムの性質に合うか。
• 性能・セキュリティ：必要な性能と保護要件を満たすか。
• 運用・拡張性：運用負荷と将来の拡張性を確かめる。

必要なら、要件定義やPoCから発注します。発注側は業務の判断を担い、委託先は設計と実装の根拠を説明できる体制を整えます。

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

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