Azure Functionsのシステム開発は、業務要件と非機能要件を整理し、どこまでを誰が受け持つかを決めてから発注するのが基本の流れです。同じ前提で見積もりを比べると、納品後の行き違いを抑えられます。
▼全体ガイドの記事
・Azure Functionsのシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
Azure Functionsのシステムを発注する前に知っておきたい全体像
Azure Functionsは、HTTPリクエストやタイマーをきっかけにコードを実行するサーバーレス基盤です。ファイル保存やメッセージ受信も、実行のきっかけになります。
業務システムは単体で完結しないため、周辺サービスも組み合わせます。Azure Storage、Azure SQL、Cosmos DBのほか、Service BusやEvent Gridも使います。さらに、API Management、Key Vault、Application Insightsも加わります。
周辺サービスまで含めた発注範囲
見積依頼で「Functionsを10個」とだけ伝えても、業務システムの規模は決まりません。同じ10個でも、定時集計と受注APIでは、設計・テスト・運用の工数が違ってきます。
認証付きAPIやキューによる非同期処理、基幹システム連携を備えると、工数はさらに増えます。そこで、関数数ではなく、業務イベント、データの流れ、ピーク件数で要件を決めます。許容遅延や障害時の扱いも、要件に含めます。
イベント駆動や短時間処理に向くFunctionsと他サービスの比較検討
採用技術は、Functionsが向く処理と、別サービスが適する処理の両方を踏まえて判断します。
- Functionsに向く処理：変動するAPI、ファイル処理、定時バッチ、キュー連携、IoTイベント受信
- 他サービスも検討する処理：常時接続、長時間の巨大データ処理、OS制御、複雑な状態管理
後者には、App ServiceやContainer Appsが適する場合があります。さらに、AKSやVMも適する場合があります。
Microsoft Learnは、ホスティングプランが性能や信頼性、コストに影響すると説明しています（出典：Microsoft Learn「Azure Functions best practices」、2026年確認）。仮想ネットワークへの影響もあります。
発注先には、App ServiceやLogic Appsとの比較を踏まえ、Functionsを選ぶ理由も説明してもらいます。また、技術をレビューできる会社を選ぶと、発注後の手戻りを減らせます。
Azure Functionsの発注形態の選び方
業務と技術の整理が済んでいない場合は、要件定義から運用までを一括で依頼すると進めやすいです。一方で、要件が固まり、技術責任者もいるのであれば、設計・開発だけを請負で依頼できます。
内製化を重視する場合は、伴走型の準委任と内製化支援を組み合わせます。
企画から運用までを一括で外注する方式
業務部門と情報システム部門で要件が未整理なら、コンサルティングから保守までの工程を、同じ会社へ依頼できます。窓口を一本化できるため、Functionsの開発から監視までを、一つの責任範囲で管理できます。
一方で、すべてを任せると、見積の前提やソースコードの所有権が不透明になりやすいです。そのため、納品物とレビュー会を契約書に明記します。
設計・開発だけを請負で発注する方式
画面・API一覧とデータ項目が固まり、非機能要件と外部連携仕様も決まっていれば、設計から開発、テストまでを請負で発注できます。また、納品物と受入条件を定めやすい方式です。
発注後にService Busの追加や認証方式の変更が生じると、追加費用や納期変更につながります。そのため、発注側と開発会社は変更管理の手順を決め、曖昧な要件は別途整理しておきます。
PoCや伴走支援から始める方式
コールドスタートや処理時間、ピーク時の同時実行が読めない場合は、本番開発の前に小さなPoCを依頼します。さらに、重複メッセージや外部API停止時の再試行が読めない場合も、PoCで確認します。
PoCでは、正常系に加えてタイムアウトや障害時の挙動を確認し、Functionsの採用か別サービスへの切替かを判断します。PoCの納品物には、動くコードと測定結果を含めます。加えて、残課題や概算費用、本番化の条件も含めます。
準委任型で自社担当者が学びながら進める場合は、定例会やコードレビューを組み込みます。IaCの説明や運用訓練も、計画に入れます。また、契約後に自社で障害対応や小規模改修ができるかも評価します。
RFPと要件整理で決めておく事項
RFPは、実現したい業務と満たす条件を候補会社へ同じ前提で伝える文書です。業務要件と非機能要件を分けて書き、提案書に含める項目も指定します。
業務イベントとデータの流れの書き方
「誰が、何をしたとき、どのデータをどこへ送り、何分以内にどうするか」を書きます。たとえば受注登録なら、販売画面からAPIを呼び、Functionsが入力を検証してAzure SQLへ登録します。
業務イベントを受けた処理は、次の3点をRFPに書いておくと、見積の前提がそろいます。
- 処理の流れ：Service Busで請求処理へ通知し、失敗時の再試行回数、デッドレターへ送る条件、再処理の担当者も決める
- 負荷の想定：1日・1時間・ピーク1分あたりの件数、1件あたりの容量、同時利用者数、外部APIの応答時間
- データの期限：保存期間と削除条件。条件がないと見積の前提に幅が出て、後から金額が変わりやすくなる
非機能要件と運用条件の数値目標
非機能要件は、可用性から保守性までをできるだけ数値で表します。たとえば、平日9時から18時のAPIを95パーセンタイルで2秒以内にする条件があります。
障害から4時間以内の復旧や、直近15分以内のデータ損失も条件に設定できます。さらに、ログの180日保存や、個人情報を含むログを出力しない条件も設定できます。
- 可用性・性能：復旧時間、データ損失、応答時間を数値で定める
- セキュリティ：認証方式と、個人情報を含むログの扱い
- 運用・監視：保存期間と、条件から必要になるAzureサービス
Functionsのプランは要件に合わせて選びます。Application InsightsやLog Analyticsの要否も、条件から決めます。APIMやPrivate Endpointの要否も、条件に照らして判断します。
認証では、匿名のHTTPエンドポイントを前提にせず、Microsoft Entra ID、API Management、アプリケーション認証を比較します。
本番公開APIでは、Functionsのアクセスキーだけで認証・認可を満たせない場合があります。Microsoft Learnは、公開クライアントからの呼び出しについて、追加策の検討を案内しています（出典：Microsoft Learn「Work with access keys in Azure Functions」、2026年確認）。
追加策には、アプリケーション認証やAPI Management、仮想ネットワークなどがあります。
RFPに明記する納品物とアカウントの所有者
納品物、アカウントの所有者とアクセス権、秘密情報の扱いをRFPに明記します。
- 開発・運用資料：リポジトリ、IaC、環境変数、構成図、API・テスト仕様、運用手順
- 運用情報：再処理手順、監視・アラート、第三者ライブラリ一覧
- 所有権：環境別のサブスクリプションなどの所有者と、終了後のアクセス権
- アカウント：原則として発注者が契約主体となるAzureサブスクリプションを用意し、開発会社には必要な権限だけを付与
- シークレット：Key Vaultなどで管理し、接続文字列をコードやIaCに保存しない
BicepやTerraformなどのIaCは、Azureリソースをコードで管理する資料として納品物に含めます。また、開発会社のAzureアカウントに本番環境を置くと、契約終了時の移管が難しくなります。
請負と準委任の契約形態の使い分け
完成機能と受入条件が決まった部分は、請負契約が適しています。一方で、要件を探りながら設計する部分や、技術検証、内製化支援は、準委任契約のほうが進めやすいです。
Azure Functions案件では、全工程を一つの契約にせず、分けて結ぶ方法もあります。たとえば、要件定義とPoCは準委任、開発と受入は請負、保守は準委任にします。
請負契約の完成条件と変更ルール
見積書では、対象Functionや外部システム、テスト範囲を完成条件と結び付けます。性能・セキュリティ条件や納品物、検収方法も、完成条件として結び付けます。
「Azure構築一式」や「サーバーレス開発一式」と書かれていると、完成条件を判断できません。また、仕様やAzureプランの変更、発注者側のデータ提供遅延が起きた場合の扱いも、契約前に確認します。
準委任契約での体制と作業時間、成果の管理
準委任では、専門家の作業時間や役務を依頼し、要件の変化に合わせて設計・開発を進めます。
- 作業成果：月ごとの作業報告に加えて、決定事項、未解決課題、コードレビュー結果、テスト結果、次月の計画を残す
- 意思決定：週次の意思決定者と承認期限を決め、判断の先送りによる作業の長期化を防ぐ
- 個人情報：監督、アクセス権、ログ、再委託、事故連絡、終了後の削除を契約化
個人情報保護委員会のガイドラインや注意喚起も確認します。そのうえで、Azureの機能を使っても法的責任が移るわけではないことを、双方で共有します。
Azure Functionsのシステム開発費用と月額料金の相場
Azure Functionsの受託開発には、全国共通の標準価格はありません。ここに示すのは、業務システム全般の規模別相場と、Functionsでサーバー構築を簡素化できる場合をもとにした、編集部の推定です。
開発費は、会社の体制や要件定義、既存連携によって変わります。さらに、セキュリティやテスト、運用設計の範囲によっても変わります。この相場は予算計画の初期レンジとして使い、最終判断は個別見積で行います。
規模別の開発費の幅（80万円〜5,000万円以上）
規模別の費用と期間は、編集部の推定です。特定の企業の価格を保証するものではありません。
- PoC・小規模自動化：80万円〜250万円程度、期間は2〜6週間が一つの目安
- 小規模業務API：300万円〜800万円程度、期間は2〜4か月程度
- 中規模システム：800万円〜2,000万円程度、期間は4〜8か月程度
- エンタープライズ案件：2,000万円〜5,000万円以上になることがあります
PoCや小さな自動化の場合は、前述の費用と期間が目安です。対象には、1〜5個程度のFunctionやHTTP・Timer・Blobトリガーを含みます。加えて、簡易データベースや最低限のログも対象です。
小規模業務APIでは、前述の費用と期間を見込みます。対象には、認証、5〜15個程度のFunction、Azure SQLまたはCosmos DBを含みます。さらに、外部APIやCI/CD、テストも対象になります。
中規模システムでは、前述の費用と期間が目安です。対象には、Durable FunctionsやService Busのほか、複数の業務フローを含みます。さらに、権限や監視、データ移行、冗長化までが対象になります。
エンタープライズ案件では、APIMやPrivate Endpointを含む場合があります。オンプレミスや基幹連携、監査ログを含むこともあります。さらに、災害対策や24時間運用設計が加わることもあります。
この費用は、リサーチノートの人月単価と業務システム全般の相場から算出した推定です。
Azureの利用料の内訳（Functions実行分と周辺サービス）
Azure利用料は、Functions実行分と周辺サービスに分けて見積もります。
- 実行料金：実行数、時間、メモリ、ホスティングプランで変動
- Flex Consumption：有料の従量課金サブスクリプションでは、月100,000 GB秒と250,000回の実行を含む
- 周辺費用：常時利用可能なインスタンス、Storage、DB、メッセージング、監視とAPI管理、ネットワーク
価格ページは、512MBの関数を1秒ずつ月300万回実行する例を示しています。さらに、無料枠を差し引いた実行リソース量も計算しています（出典：Microsoft Azure「Azure Functionsの価格」、2026年確認）。
周辺には、Azure SQLやCosmos DB、Service Busも必要です。Application InsightsやLog Analyticsのほか、API ManagementやPrivate Linkの費用も加わります。また、ネットワーク転送費もシステム全体の利用料に含めます。
見積書では、Azure利用料と受託会社の保守費を分けて示してもらいます。想定トラフィックや為替、無料枠の前提を確認します。上限アラートの前提も、あわせて確かめます。
保守費の目安（初期開発費の15〜25パーセント程度）
保守費の目安、サービス範囲、既存プランからの移行予定を分けて確認します。
- 費用目安：初期開発費の年15〜25パーセント程度、または月15万円〜80万円程度
- 対象作業：ランタイム・依存ライブラリの更新、脆弱性対応、ログ保管とアラート確認、再処理、料金監視、軽微な改修
- 移行時期：既存のLinux Consumptionプランは2028年9月30日以降にホスティング終了
24時間監視や駆け付けには、別の体制と費用が必要です。2026年時点では、新規の動的ワークロードでFlex Consumptionを第一候補とする場面が増えています。
移行では、新しいFunction Appを作成し、検証後に切り替えます（出典：Microsoft Learn「Migrate Consumption plan apps to Flex Consumption in Azure Functions」、2026年確認）。また、既存システムは、移行費用と停止時間も見積もります。
Azure Functionsの委託先の選び方
「Azureに対応できる」と示すだけの会社より、業務システムを設計・運用し、障害から復旧できる会社を選びます。公開事例は参考になりますが、事例を公開できない業界もあります。また、提案時の質問と設計レビューで実力を見極めます。
技術力と業務理解の評価
技術力と業務理解を同じ重みで見ます。具体的な設計説明や、近い領域の経験を確かめます。
- 技術：トリガー、状態管理、冪等性、再試行とデッドレター、同時実行、CI/CDとIaC
- 業務：受発注、在庫、請求、顧客、製造、医療など近い領域
- 情報管理：匿名化、権限分離、監査ログ、委託先管理の提案力
技術の確認項目には、HTTPやTimer、Blobのトリガーがあります。さらに、QueueやService Bus、Event Gridのトリガーも含まれます。Durable Functionsの状態管理やコールドスタートも確認します。
障害時の二重登録を防ぎ、処理途中から安全に再開する設計を説明できるかを見ます。医療・個人情報を扱う場合は、必要な対策の提案力も確かめます。
日本マイクロシステムズのIoTプラットフォームや、メタテクノの医療クラウドシステム開発など、Functionsを含む公開情報を確認します。担当範囲と現在の体制も聞きます。
契約前に確認する運用体制と引き継ぎ方法
運用時の対応範囲と、発注者が引き継いで再現できる体制を、契約前に確認します。
- 障害対応：リリース後の問い合わせ回答時間、夜間の一次対応、Azure・アプリ障害の切り分け、再処理の承認者
- 監視・復旧：ログ・相関ID、アラート指標、復旧手順と担当者
- 引き継ぎ資料：コードとIaC、設定、依存関係、テストデータ、デプロイ・戻し方、運用日程
受託会社の担当者しかデプロイできない状態は、納品後の事業継続リスクです。そのため、最終月の説明会だけでなく、発注者が自社サブスクリプションへ検証デプロイする場を設けます。
Azure Functionsの見積書の比べ方
見積書は、安さだけでなく、同じ前提で比べられる形に整えます。作業範囲と前提、除外項目は、候補会社ごとに同じ書式で並べます。成果物や体制、日程も、同じ項目で比べます。受入条件や保守範囲、Azure利用料も横並びにします。
工程・機能・人月の内訳の有無
工程と工数の内訳をそろえ、実装本数以外の作業も比べます。
- 工程：要件・設計・開発・連携・認証・ネットワーク・IaC・CI/CD・テスト・移行・運用
- 工数：担当職種、工数、単価、期間を工程別に明記
- Functionsの作業：接続・変換・エラー・再実行・認証・ログ・テストデータ
関数数が少なくても、基幹連携やセキュリティ設計があれば費用は高くなります。また、極端に安い場合は、非機能要件や運用設計が除外されていないかを確認します。
前提条件と除外項目の確認と総額の比較
除外範囲とAzure利用料の前提をはっきりさせ、見積もりの総額を比べます。
- 除外例：API仕様提供、データ移行、Azureアカウント、負荷試験、平日日中以外の保守
- 試算条件：月間実行数、平均実行時間、メモリ、同時実行、データ転送、ログ保存期間とDB容量
- 月額シナリオ：下限・標準・ピークの試算と予算超過時の通知設定
候補会社へ同じ質問を送り、項目を「含む」「含まない」「別途」に分けます。無料枠や単価は、プラン、リージョン、契約形態で変わります。
見積取得時点の公式価格を基準にします。Azure費用が実費のみの場合も、三つのシナリオを出してもらいます。
発注後の追加費用につながるサイン
聞き取りの内容と、費用・運用条件の説明に不足がないかを確認します。
- 要件確認不足：Function数だけで即日見積もりし、ピークや再処理を聞かない
- 費用根拠不足：「サーバーレスなので安い」とだけ説明し、変更可能性を扱わない
- 運用説明不足：認証、権限、ログ期間、アラート条件を具体的に示さない
ピーク件数や障害時の再処理を聞かない場合、後から設計変更になる可能性があります。「セキュリティはAzure標準」「監視はログを確認」とだけ説明する場合は、具体的な方式や条件を求めます。
候補会社には、同じ想定ケースでのエラー再処理デモや、IaCによる検証環境の再構築、ログから処理を追跡する方法を示してもらいます。無償提案では、すべてを作り込んでもらわず、設計の考え方と前提を比べます。必要なら、有償のアーキテクチャレビューやPoCに進むと、双方に無理がありません。
よくある質問
Azure Functionsの発注では、技術選定から運用までを一緒に考えます。発注前によくある質問に、順に答えます。
Azure Functionsなら開発費も月額料金も必ず安くなりますか？
必ず安くなるとは限りません。短時間のイベント処理やアクセス変動が大きい場合、使った分だけ支払う構成が有利になりやすいです。
DBやメッセージング、ログの費用も加わります。さらに、ネットワークや認証、監視の費用もかかります。再処理設計やセキュリティを含めるほど開発費が増えるため、初期費用と5年間のTCO（総所有コスト）を分けて比較します。
Azure Functionsの実績が少ない会社にも発注できますか？
発注できますが、近い業務領域やAzureサービスを扱った設計力を確認します。公開事例がなければ、匿名化した構成例やエラー処理、認証の説明を求めます。監視やIaC、引き継ぎの進め方も確認します。
必要に応じて、小規模なPoCから始めます。Functionsの経験だけでなく、自社業務と運用責任を理解できるかで判断します。
発注前に自社で準備しておく資料は何ですか？
業務フローや現行構成、画面・帳票一覧を準備します。加えて、外部連携先やデータ項目、月間・ピーク件数も用意します。
利用者と権限、個人情報の有無を整理します。希望納期と予算、運用体制も用意します。
すべて揃っていなくても、未確定事項として明記すれば問題ありません。候補会社には、検証方法と決定時期も提案してもらいます。
まとめ
発注では、Functionの本数ではなく、業務イベントやデータ、ピーク負荷を要件にします。そのうえで、障害時の再処理やセキュリティ、監視を決めておきます。運用体制も、契約前に確かめます。
技術選定では、App Service、Logic Apps、Container Appsなどと比べて、Functionsを使う理由を確認します。
要件が曖昧なら、要件定義やPoCから始めます。確定した範囲は請負で、継続改善や内製化支援は準委任で依頼します。
RFPには、納品物やIaC、ソースコードを記載します。さらに、Azureアカウントや受入条件、保守範囲を記載し、どこまでを誰が受け持つかも明らかにします。
見積では、初期開発費とAzure実行料金を分けて示してもらいます。周辺サービスや保守費も含め、複数社を同じ前提で比べます。業務理解とAzureの設計・運用力があり、契約終了後も自社で管理できる状態を作れるパートナーを選びます。
▼全体ガイドの記事
・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を創業。