Azure Functionsのシステム開発は、業務イベント、データ、障害時の責任を先に決めたうえで、要件整理から定着までの6段階で進みます。
各段階で発注側が何を決めておけばよいかを、システム構成、開発工程、費用相場、見積もりの順に見ていきます。
▼全体ガイドの記事
・Azure Functionsのシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
Azure Functionsのシステム開発における全体像
Azure Functionsは、HTTPリクエスト、タイマー、ファイル保存、メッセージ、IoTイベントを受けてコードを実行する基盤です。
業務システムでは、Functionsだけでなく、Azure StorageやService Busなども組み合わせます。構成要素には、Event GridやAzure SQL、Cosmos DB、API Managementも含まれます。さらに、Key VaultやApplication Insightsも使います。
Azure Functionsのシステムの概要
Azure Functionsのシステムとは、Functionsを業務処理の実行基盤に使うシステムです。
- API：受注などのリクエストの受け付け
- バッチ・データ連携：定時集計や基幹システム間の処理
- 通知・ワークフロー：メールやTeams通知、承認処理
- IoT・ファイル処理：データ受信、CSVや画像の自動処理
たとえば、受注APIからService Busへ送り、Functionsが在庫確認と請求連携を行う構成もあります。
処理の結果はAzure SQLに保存できます。
複数の処理や再試行、状態管理、外部イベント待ちには、Durable Functionsを使えます。ただし、常時接続が必要なアプリや、OSを細かく制御する処理まで、Functionsに集める必要はありません。
Functionsが向くシステムと向かないシステム
処理量の増減が大きく、イベントを受けて短時間に処理する業務は、Functionsに向きます。Azure連携とも相性がよく、注文補助API、定期バッチ、キュー処理、ファイル変換に使えます。また、閑散時間には資源を縮小でき、処理量の変動にも対応しやすくなります。
業務の中心が次の性質なら、他の実行基盤も比べます。
- 長時間・常時稼働：App Serviceや仮想マシンが候補になります。
- 重いバッチ・複雑な状態：Container AppsやAKSを比べます。
- 標準連携で足りる業務：Logic AppsやPower Automateの検討
Functionsで作ると、コードと保守範囲が増える場合があります。
基盤の選定では、処理時間や同時実行数、ネットワーク要件のほか、運用担当者の技術力を基準にします。
Azure Functionsのシステム開発の進め方・6フェーズ
開発は6フェーズで進みます。要件整理から始め、方式選定と設計開発、テスト、稼働を経て、定着へ進みます。
各フェーズでは、成果物、意思決定者、完了条件を先に決めておきます。
未決の事項を次の工程へ持ち越さないことで、追加費用を抑えやすくなります。
フェーズ1：要件整理と業務イベント・KPIの決定
最初に決めるのは業務課題と成果で、Functionsの利用は、そのあとに考えます。
- 処理時間：受注登録から請求までの時間
- 失敗率：CSV取込などの失敗の割合
- 遅延・削減数：通知の許容遅延と、問い合わせの削減数
導入後に測れるKPIは2〜4個に絞ります。
利用者と業務担当者、管理者、障害時の責任者も洗い出します。
現在と理想の業務フローを並べて、どこが変わるかを一覧にします。確認するのは、イベントの発生元、1日とピーク時の件数、1件あたりのデータ量です。
許容遅延や再処理、個人情報の扱いは、この段階で決めます。保管期間やRTO・RPO、月額予算も、あわせて整理します。
HTTP APIなら認証と応答時間、キューなら重複やデッドレターの扱いを定義します。タイマー処理なら、実行漏れと再実行の方法も決めておきます。業務シナリオを要件定義書に記しておくと、見積もりを比べる際の基準がそろいます。
フェーズ2：Functionsと周辺サービスの選定
Functionsのプランだけでなく、データベースや認証なども含めて、一つの構成図で比べます。
- HTTP API：API ManagementやEntra IDの検討
- 非同期処理：候補はService Bus
- ファイル処理：候補はBlob Storage
- 監視・秘密情報：Application InsightsとKey Vaultを使います
業務イベントと各サービスの対応を決めたうえで、データの流れを設計します。
2026年時点の新規案件では、Flex Consumptionを第一候補として検討します。メモリサイズを選べ、オンデマンド実行とAlways Readyを分けて設計できます。このため、従来のConsumptionよりネットワークやスケーリングの選択肢が広くなります。
Linux Consumptionは2025年9月30日以降、新機能が追加されていません。
Microsoft Learnでは、ホスティング終了予定を2028年9月30日としています（出典: Microsoft Learn「Migrate Consumption plan apps to Flex Consumption in Azure Functions」、2026年8月確認）。
既存アプリは、新しいFunction Appを作成して再デプロイする前提です。そのため、移行期間と検証環境を確保しておく必要があります。
フェーズ3：関数の責務・データ・セキュリティの設計開発
関数を分ける際は、一つの責務に含める処理の範囲を決めます。たとえば、受注受付、在庫照会、請求依頼を別々の関数に分けます。結果通知も含め、Service Busなどで疎結合にします。
関数を分けると、失敗した箇所だけを再処理でき、変更の範囲も切り分けられます。一方で、関数を分けすぎると管理が複雑になります。理由は、Function App単位でデプロイや設定を行うためです。スケーリングや権限も、同じ単位で決まります。
重複実行を想定して、冪等性キーや処理済みテーブルを設けます。たとえば、受注番号を一意キーにすると、再配信時の二重請求を防げます。
外部APIのタイムアウトや部分成功、順序逆転への対応を設計書に記載します。そのうえで、手動再実行も含め、再試行回数とデッドレターからの復旧手順を決めます。
Microsoftは関数をステートレスかつ冪等にし、一時障害にリトライを使う方法を推奨しています（出典: Microsoft Learn「Best practices for reliable Azure Functions」、2026年8月確認）。
HTTPエンドポイントを匿名で公開するのは避け、要件に応じて認証やネットワーク制御を組み合わせます。
- 認証・権限：Microsoft Entra ID、Managed Identity、RBAC。
- 秘密情報・通信：Key Vault、Private Endpoint、VNet、WAF。
- 保護・記録：暗号化と監査ログ。
ログには、個人情報やパスワード、アクセストークンを出力しないようにします。
BicepやTerraformなどのIaCとCI/CDは、初期開発の段階から含めます。そのうえで、開発、検証、本番のサブスクリプションやリソースを分けておきます。
フェーズ4：正常系だけでなく失敗・負荷・復旧のテスト
テストは段階ごとに分けて行います。まず単体と結合で確かめ、次に受入や運用リハーサルへ進みます。
HTTP APIでは、認証や入力検証を確かめます。さらに、タイムアウト、同時リクエスト、応答形式も見ます。
キューやイベント処理では、重複や順序逆転、メッセージ破損をわざと発生させます。あわせて、外部APIの停止や処理途中の再起動、デッドレターへの移送も試します。
負荷試験では、平均値だけでなく、ピーク時の同時実行数や処理遅延も見ます。
- 実行状態：スロットリング、DB接続数、キュー滞留数。
- 応答時間：コールドスタートと処理遅延。
- 障害対応：トレース、アラート到達、復旧可否。
コールドスタートが許容時間を超えるなら、Flex ConsumptionのAlways ReadyやPremiumを比べます。また、処理の分割や依存ライブラリの軽量化も検討します。
Application Insightsでトレースを追い、アラートが担当者に届くかも試します。
Microsoftの指針は、同サービスでのログ収集と冪等性設計を推奨しています（出典: Microsoft Learn「Azure Functions Error Handling and Retry Guidance」、2026年8月確認）。
フェーズ5：小規模公開から本稼働への移行
本稼働へ移る前には、公開の範囲から引き継ぎまでを確認します。
- リリース準備：手順と切り戻し条件、バックアップ、監視、連絡網、障害告知、権限
- 限定公開：社内や一部顧客から始め、処理時間と失敗率、問い合わせ、手動再処理件数を見て範囲を広げる
- デプロイ管理：Function App単位で変更関数と影響業務を整理し、単位を大きくしすぎない
- 稼働判定：ログでの原因追跡、再処理権限、Azure料金の異常検知
- 引き継ぎ：ソースコード、IaC、設定一覧、テスト結果、運用手順、障害連絡先
Azureアカウントとリソースを発注者が所有しておくと、ベンダーを交代する際のリスクを抑えられます。
フェーズ6：KPI・コスト・運用改善による定着
稼働後は、実行回数と実行時間、メモリ使用量、失敗率を定期的に確認します。さらに、再試行数と外部APIの遅延、キュー滞留、月額料金も追います。
Functionsは使った分だけ安くなるとは限りません。料金には、Storageやデータベース、Service Busが影響します。加えて、Application InsightsやLog Analyticsも費用の一部になります。
特に、API ManagementやPrivate Link、通信費も料金を左右します。処理量が増えたとき、どのサービスの費用が増えるかは、ダッシュボードで見えるようにします。
事業KPIは、要件整理で決めた指標を月次で振り返ります。
- 応答・連携：APIの所要時間と連携の成功率
- 業務処理：請求完了までの時間と、手作業の削減時間
再発防止のため、相関IDと業務キー、処理状況、再処理者と日時を記録しておきます。
ランタイムや依存ライブラリ、脆弱性対応、Azureサービスの仕様の更新も、保守計画に入れます。
Azure Functionsのシステム開発費用と料金相場
費用は、受託開発費とAzure利用料に分けて考えます。
Functions単体の国内の公的な標準価格は少ないため、示す金額は編集部による推定です。推定には、業務システムの相場と人月単価に加えて、Functionsでインフラの構築量を抑えられる場合も踏まえています。
要件や連携先、非機能要件で金額は変わるため、幅で見る必要があります。
規模別の開発費と期間の目安
構成規模に応じて、開発費と期間の目安は次のように変わります。
- PoC・小規模自動化：80万〜250万円、2〜6週間。
- 小規模業務API・連携：300万〜800万円、2〜4か月。
- 中規模システム：800万〜2,000万円、4〜8か月程度。
- エンタープライズ連携：2,000万〜5,000万円以上、6〜12か月以上。
PoCの目安は、1〜5関数で、HTTP・Timer・Blob、簡易DB、最低限のログを含みます。
小規模業務APIは、認証、5〜15関数、Azure SQLまたはCosmos DBを含みます。外部APIは1〜3本を想定し、CI/CDとテストまで含める場合の目安です。
中規模の場合は、Durable FunctionsやService Busを使う複数の業務フローに加え、権限と監視、データ移行、冗長化を含みます。
エンタープライズ連携では、API ManagementやPrivate Endpoint、オンプレミスや基幹との連携を含みます。監査ログや災害対策、24時間運用の設計も、必要になる場合があります。
ここでの金額は、人月単価と業務システム規模別の相場をもとにした推定で、正式な見積もりとは異なります。
Azureの実行料金と周辺サービスの総額の試算
Flex Consumptionには、有料の従量課金サブスクリプション向けの無料提供があります。
- 実行時間：月100,000GB秒相当。
- 実行回数：月25万回相当。
Functionsは、メモリ量、実行時間、実行回数で課金されます。
地域、契約、プランで単価は変わります（出典: Microsoft Azure「Azure Functionsの価格」、2026年8月確認）。
無料枠だけを見て月額無料と判断せず、Azure料金計算ツールで全体を試算します。
試算例は、月1,000万回、1回1秒、メモリ512MBの場合で、実行部分は約500万GB秒です。超過分の単価を0.000026米ドル／GB秒、1米ドルを150円と仮定すると、実行分は約130米ドルです。
円換算では約2万円／月になります。ただし、これは単価を仮定したモデルケースです。
この試算には、Storageやデータベース、Service Busは含みません。Application InsightsやLog Analyticsも、試算の対象外です。
API ManagementやPrivate Linkの費用、通信量、Always Readyの常時稼働分は、この試算に入れていません。
保守運用費と監視・再処理・更新の範囲
保守運用費は、初期開発費の年15〜25％、または月15万〜80万円程度が業務システム全般の目安です。
Functions案件では、保守作業をどこまで含めるかで、費用が大きく変わります。
見積もりでは、保守範囲と契約条件を分けて確認します。担当者と総保有コストも、あわせて見ておきます。
- 保守作業：ランタイム更新、脆弱性対応、ログ保管とアラート確認、再処理、コスト監視、軽微な改修
- 契約条件：夜間休日対応、復旧目標、月次レポートの有無。
- 責任分担：ログ確認、失敗データの再処理、一次受付の担当者。
- 3年間のTCO：Azure利用料、保守費、運用工数、将来の移行費。
初期開発費だけでなく、TCOで比べることで、方式選定の判断を誤りにくくなります。
Azure Functionsのシステム開発で見積もりを取るポイント
見積もりは、関数や連携の範囲と、テスト、運用の範囲を分けて確認します。「Azure構築一式」のように一行でまとめた金額では、作業内容を比べにくいからです。
発注前に要件をすべて決めておかなくても、進められます。未確定の事項と、金額が増減する条件は、見積書に残しておきます。
業務シナリオと非機能要件の提示
RFPには、業務イベントと入力データ、処理結果を記載します。利用者や連携先も書いておきます。さらに、1日平均とピーク時の件数、処理期限、エラー時の扱いも示します。
CSV取込では、次の4つの条件まで具体化します。
- ファイル規模：最大行数の上限
- 再送：同じファイルを再送した場合の扱い。
- 一部失敗：失敗行の通知方法。
- 再処理期間：何日後まで実行できるか。
非機能要件には、同時実行数、最大処理時間、コールドスタートの許容を含めます。SLAやRTO・RPO、ログ保存期間と監査要件、データ保管地域も整理します。加えて、個人情報の有無と月額予算も明記します。
個人情報を扱う場合は、認証・認可とアクセス制御、委託先の監督を確認します。漏えい時の対応や、ログへの個人情報の出力禁止については、法務・情報システム部門と詰めておきます。
見積書の作業項目と納品物の内訳
見積書では、作業項目ごとに分けて、各項目の前提を記載してもらいます。
- 設計・実装：要件定義、アーキテクチャ設計、Function App作成、関数実装。
- 基盤・連携：データベース、メッセージング、認証認可、ネットワーク。
- 運用・リリース：監視、CI/CD、IaC、データ移行、テスト、操作説明。
対象環境と関数数、連携先、担当者も明示します。工数や前提条件、除外事項も、あわせて記載します。
納品物は、ソースコードに加えて、次の3種類をそろえてもらいます。
- 設計資産：リポジトリ、IaC、環境変数、権限設計、API仕様、データモデル。
- 品質・運用：テスト仕様書と結果、監視ダッシュボード、アラート、再処理、バックアップと復旧手順。
- 引き継ぎ：運用マニュアル、Azure契約とリソースの所有権。
特に、IaCがないと、環境の再構築やベンダー交代のたびに、追加費用が発生しやすくなります。
複数社の同条件での比較とPoCの成果確認
開発会社は認定や導入社数だけでなく、FunctionsやDurable Functionsの実装経験、業務理解も比べます。また、セキュリティ、運用体制、見積の透明性も同じ質問票で確認します。
「サーバーレスなので安い」という説明だけでなく、採用理由も聞きます。
App ServiceやContainer Appsを選ばない理由、障害時の再処理、ピーク料金上限も確認します。PoCを行う場合は、正常系に加えて、負荷や障害からの復旧を評価します。
- 障害・負荷：ピーク負荷、外部API停止、重複、タイムアウト、権限エラー。
- 復旧・追跡：デッドレターの戻し方、ログの追い方。
- 運用・費用：環境再構築と月額料金の試算。
Function Appの所有者と、ソースコードやIaCの受け渡しを、事前に確かめておきます。なお、Azure料金アラートの設定と、リリース後に担う運用時間も確かめます。
Azure Functionsのシステム開発でよくある質問
Functionsは小さく始めやすい一方、周辺サービスや運用設計を省くと本番で問題が出やすい基盤です。
費用、方式、移行について、発注前に出やすい質問を取り上げます。
Azure Functionsならシステム開発費用は安くなりますか？
運用費が下がる可能性はありますが、開発費とAzure料金は分けて比べます。
- 運用費：アクセスの増減があり、短時間の処理が中心なら、常時インフラを避けられる場合がある。
- 開発費：要件と連携範囲、認証、DB・外部連携、テスト、監視、IaCの有無で変わる。
- Azure料金：Functions以外のサービスも含め、初期費用と3年間のTCOで比べる。
Azure FunctionsとApp Serviceはどちらがよいですか？
処理の特性と運用条件を比べ、どちらが要件に合うかをPoCで判断します。
- Functions：イベント起点の短時間処理、非同期連携、定期実行、急な負荷変動。
- App Service：常時稼働するWebアプリ、長時間処理、安定応答、既存Web構造。
- 比較条件：処理の性質、必要なスケール、チームの経験、ネットワーク要件。
既存のLinux Consumptionはいつまでに移行すべきですか？
Linux Consumptionの終了予定を踏まえ、対象アプリを一覧にして洗い出し、移行を準備します。
- 新機能の追加停止：2025年9月30日から。
- v3ランタイムのアプリ：2026年9月30日以降に停止する案内。
- ホスティング終了：2028年9月30日。
- 移行方法：既存Function Appを変換せず、新規作成して再デプロイする。
- 検証：接続先、シークレット、監視、ロールバックの確認。
開発会社への相談前に何を準備すればよいですか？
相談の前に、業務や運用の条件を一枚にまとめておくと、各社の提案の前提がそろいます。
- 業務情報：フロー、対象ユーザー、処理件数、ピーク時間、連携先。
- データ・費用：データ項目、個人情報の有無、希望時期、予算、既存Azure環境。
- 運用条件：失敗時の再処理、許容遅延、ログ保存期間、RTO・RPO。
- 所有者：ソースコードとAzureアカウントの所有者。
要件が曖昧なら、要件整理と小規模PoCを分けて発注する方法もあります。
Azure Functionsのシステム開発の進め方まとめ
開発を6フェーズで進めると、技術の選定を業務成果に結び付けやすくなります。そのためには、業務イベントとデータ、処理期限を先に定義しておきます。再処理やセキュリティ、運用者も、あわせて決めます。
Functionsを使うこと自体を目的にせず、業務成果に照らして採用を決めます。
発注前に確認する5つの要点
発注前には、業務要件と方式を確かめたうえで、テストや総額、所有権も見ておきます。
- 業務成果：イベントとKPIを明確にする。
- 方式選定：候補の比較と、Functionsを採用する理由の確認。
- 品質確認：冪等性、再試行、デッドレター、コールドスタート、ピーク負荷の検証。
- 費用：DB、ログ、通信、メッセージングを含めたTCO。
- 所有と責任：コード、IaC、Azure資産、運用の分担を契約で定める。
小規模な検証と運用まで含めた段階導入
代表的なAPIや連携をPoCで確かめてから、本開発へ段階的に進みます。
- 検証：正常系に加え、障害、負荷、復旧、料金の確認。
- 方式・移行：2026年時点ではFlex Consumptionを候補とし、Linux Consumptionの終了予定を確かめる。
- 発注比較：要件と見積もりの粒度をそろえ、各社の提案を比べる。
- 運用：稼働後の体制を整え、使われ続けるシステムにつなげる。
▼全体ガイドの記事
・Azure Functionsのシステム開発の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。