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

Azure Functionsのシステム開発を発注・外注するなら、Functionsの実装費だけでなく、要件定義、周辺Azureサービス、セキュリティ、監視、障害時の再処理まで含めた総額と責任分界を決めることが重要です。

「サーバーレスなので安く作れるはずです」「Azureに詳しい会社なら任せられます」と考えて発注すると、後からデータベースやログ、ネットワークの費用が増えたり、納品後に自社で運用できなかったりします。この記事では、Azure Functionsを使う業務システムの発注形態、RFPと要件整理、契約、費用相場、委託先の選び方、見積書の比較方法を、2026年時点の情報を踏まえて解説します。

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

Azure Functionsのシステムを発注する前に知っておきたい全体像

Azure Functionsは、HTTPリクエスト、タイマー、ファイルの保存、メッセージ受信などをきっかけにコードを実行するサーバーレスの実行基盤です。実際の業務システムではFunctions単体で完結せず、Azure Storage、Azure SQL、Cosmos DB、Service Bus、Event Grid、API Management、Key Vault、Application Insightsなどを組み合わせます。

見積依頼の際に「Functionsを10個作ってください」とだけ伝えても、業務システムの規模は決まりません。同じ10個でも、単純な定時集計と、認証付きの受注API、キューによる非同期処理、基幹システム連携、失敗時の再処理を備えた仕組みでは、設計・テスト・運用の工数が大きく違います。関数の数ではなく、業務イベント、データの流れ、ピーク時の件数、許容遅延、障害時の扱いで要件を表現します。

アクセスや処理量が時間帯によって変わるAPI、ファイル投入を契機にした処理、定時バッチ、キューを使う連携、IoTイベントの受信などはFunctionsと相性が良いです。一方、常時接続が必要な処理、巨大なデータを長時間扱う処理、OSを細かく制御する処理、複雑な状態を一つのアプリケーションで持ち続ける処理は、App Service、Container Apps、AKS、VMなどが適する場合があります。

発注先には「Functionsを使うこと」だけでなく、「なぜApp ServiceやLogic AppsではなくFunctionsなのか」も説明してもらいます。Microsoft Learnのベストプラクティスでも、ホスティングプランは性能、信頼性、コスト、仮想ネットワークなどに影響すると説明されています（出典：Microsoft Learn「Azure Functions best practices」、2026年確認）。採用技術の妥当性をレビューできる会社を選ぶことが、発注後の手戻りを減らします。

Azure Functionsの発注形態はどれを選べばよいですか？

結論から言うと、業務と技術の整理が済んでいない企業は、要件定義から運用までを一気通貫で依頼する方式が進めやすいです。要件が固まっていて自社に技術責任者がいる場合は、設計・開発だけを請負で依頼できます。将来の内製化を重視する場合は、伴走型の準委任や内製化支援を組み合わせる方法が適しています。

業務部門と情報システム部門の間で要件が整理されていない場合は、コンサルティング、要件定義、アーキテクチャ設計、開発、テスト、リリース、保守を同じ会社に依頼する方法があります。窓口を一本化でき、Functionsとデータベース、認証、監視の設計を一つの責任範囲で管理できます。ただし、すべてを任せきりにすると、見積の前提やソースコードの所有権が不透明になりやすいため、成果物とレビュー会を契約書に明記します。

画面一覧、API一覧、データ項目、非機能要件、外部連携仕様がある程度固まっているなら、設計・開発・テストの範囲を請負契約で発注できます。納品物と受入条件を定めやすい反面、発注後に「やはりService Busを追加したい」「認証方式を変更したい」となると、追加費用や納期変更が発生します。請負を選ぶ場合は、変更管理の手順と、要件の曖昧さが残る項目を別途整理しておきます。

コールドスタート、処理時間、ピーク時の同時実行、重複メッセージ、外部API停止時の再試行などが読めない場合は、本番開発の前に小さなPoCを依頼します。代表的な正常系だけでなく、タイムアウトや障害時の挙動を確認し、Functionsを採用するか、別サービスに切り替えるかを判断します。PoCの成果物として、動くコードだけでなく、測定結果、残課題、概算費用、本番化の条件を受け取ることが大切です。

また、自社の担当者がAzureを学びながら開発会社と進める準委任型では、定例会、コードレビュー、IaCの説明、運用訓練を組み込みます。短期的な開発速度だけでなく、契約終了後に自社が障害対応と小さな改修を行えるかを発注形態の評価軸にします。

RFPと要件整理では何を決めておくべきですか？

RFPは「Azure Functionsで作る」という技術指示書ではなく、実現したい業務と満たすべき条件を候補会社へ同じ前提で伝える文書です。候補会社によって構成や費用が変わるため、業務要件と非機能要件を分け、提案書に含めてほしい項目も指定します。

まず「誰が、何をしたとき、どのデータを、どこへ送り、何分以内に、どの状態にするか」を書きます。たとえば受注登録では、販売画面からAPIを呼び出し、Functionsが入力を検証してAzure SQLへ登録し、Service Busで請求処理へ通知します。請求処理が失敗した場合は、何回再試行し、どの条件でデッドレターへ送り、誰が再処理するかまで決めます。

RFPには、1日・1時間・ピーク1分あたりの件数、1件あたりのデータ容量、同時利用者数、外部APIの応答時間、保存期間、削除条件も入れます。これらがないと、開発会社は安全側に余裕を見込むか、低めの前提で見積もるしかなく、後で金額が動きやすくなります。

可用性、性能、セキュリティ、拡張性、保守性を、できるだけ数値で表します。たとえば「平日9時から18時のAPIは95パーセンタイルで2秒以内」「障害から4時間以内に復旧」「データ損失は直近15分以内」「ログを180日保存」「個人情報を含むログを出力しない」といった条件です。Functionsのプラン選択や、Application Insights、Log Analytics、APIM、Private Endpointの要否は、これらの条件から決めます。

認証は匿名のHTTPエンドポイントを前提にせず、Microsoft Entra ID、API Management、アプリケーション認証などを比較します。Azure Functionsのアクセスキーだけでは、本番の公開APIに必要な認証・認可をすべて満たせない場合があります。Microsoft Learnでも、公開クライアントから呼び出す場合は、アプリケーション認証、API Management、仮想ネットワークなど追加のセキュリティ対策を検討するよう案内されています（出典：Microsoft Learn「Work with access keys in Azure Functions」、2026年確認）。

納品物はFunctionのソースコードだけでは不十分です。リポジトリ、BicepやTerraformなどのIaC、環境変数一覧、Azureリソース構成図、API仕様、テスト仕様書、運用手順書、障害時の再処理手順、監視とアラートの設定、第三者ライブラリ一覧まで指定します。開発・検証・本番のサブスクリプションやリソースグループを誰が所有し、退職や契約終了後に誰がアクセスできるかも決めます。

特に、開発会社のAzureアカウントに本番環境を置く形は、契約終了時の移管が難しくなります。原則として発注者が契約主体となるAzureサブスクリプションを用意し、開発会社には必要な権限だけを付与します。シークレットはKey Vaultなどで管理し、ソースコードやIaCに接続文字列を保存しないことを受入条件に含めます。

契約形態は請負と準委任のどちらが適していますか？

要件が固まり、完成させる機能と受入条件を定義できる部分は請負契約が適しています。要件を探索しながら専門家と設計する部分、技術検証や内製化支援の部分は準委任契約が進めやすいです。Azure Functions案件では、最初から全工程を一つの契約にせず、要件定義・PoCを準委任、開発と受入を請負、保守を準委任と分ける方法も有効です。

請負契約の見積書には、対象となるFunction、外部システム、テスト範囲、性能条件、セキュリティ条件、納品物、検収方法を対応付けます。「Azure構築一式」「サーバーレス開発一式」だけでは、どこまでが完成なのか判断できません。仕様変更、Azureサービスのプラン変更、発注者側のデータ提供遅延が起きたときの扱いも、契約前に確認します。

準委任では、専門家の作業時間や役務を依頼し、要件の変化に合わせて設計・開発を進めます。月ごとの作業報告だけでなく、決定事項、未解決課題、コードレビュー結果、テスト結果、次月の計画を成果物として残します。発注者が判断を先送りすると作業が長期化しやすいため、週次の意思決定者と承認期限を決めておきます。

個人情報を扱うシステムでは、委託先の監督、アクセス権、ログ、再委託、事故時の連絡、契約終了後のデータ削除を契約条項に入れます。個人情報保護委員会のガイドラインや注意喚起も確認し、Azureの機能だけで法的な責任が移るわけではないことを発注者と受託者の双方で共有します。

Azure Functionsのシステム開発費用と月額料金の相場

Azure Functionsの受託開発に全国共通の標準価格はありません。以下は、業務システム全般の規模別相場と、Functionsでサーバー構築の一部を簡素化できるケースをもとにした編集部推定です。会社の体制、要件定義の有無、既存システムとの連携、セキュリティ、テスト、運用設計によって変わるため、予算計画の初期レンジとして使い、最終判断は個別見積で行います。

PoCや小さな自動化で、1〜5個程度のFunction、HTTP・Timer・Blobトリガー、簡易データベース、最低限のログを組み合わせる場合は、80万円〜250万円程度、期間は2〜6週間が一つの目安です。認証、5〜15個程度のFunction、Azure SQLまたはCosmos DB、外部API、CI/CD、テストを含む小規模業務APIや連携システムでは、300万円〜800万円程度、期間は2〜4か月程度を見込みます。

Durable Functions、Service Bus、複数の業務フロー、権限、監視、データ移行、冗長化まで含む中規模システムでは、800万円〜2,000万円程度、期間は4〜8か月程度が目安です。APIM、Private Endpoint、オンプレミスや基幹システムとの連携、監査ログ、災害対策、24時間運用設計を含むエンタープライズ案件では、2,000万円〜5,000万円以上になることがあります。これらはリサーチノートにある人月単価と業務システム全般の相場から算出した推定レンジで、特定企業の価格を保証するものではありません。

Azure Functionsの月額料金は、実行回数、実行時間、メモリ、選んだホスティングプランで変わります。Flex Consumptionには、有料の従量課金サブスクリプションを対象に、月100,000 GB秒と250,000回の実行が含まれます。Microsoftの価格ページでは、512MBの関数を1秒ずつ月300万回実行する例が示され、無料枠を差し引いた実行リソース量を計算しています（出典：Microsoft Azure「Azure Functionsの価格」、2026年確認）。

ただし、利用者が支払うシステム全体の料金はFunctionsだけではありません。常時利用可能なインスタンス、Storage、Azure SQLやCosmos DB、Service Bus、Application InsightsとLog Analytics、API Management、Private Link、ネットワーク転送などが加わります。見積書では「Azure利用料の試算」と「受託会社の保守費」を分け、想定トラフィックと為替の前提、無料枠の扱い、上限アラートの設定を確認します。

保守・運用費は、初期開発費の年15〜25パーセント程度、または月15万円〜80万円程度という一般的な目安があります。Functions案件では、ランタイムと依存ライブラリの更新、脆弱性対応、ログの保管、アラート確認、失敗メッセージの再処理、Azure料金の監視、軽微な改修をどこまで含むかで変わります。24時間監視や障害時の駆け付けを求める場合は、別の体制と費用になります。

2026年時点では、新規の動的なワークロードにFlex Consumptionを第一候補として検討する場面が増えています。Microsoft Learnでは、既存のLinux Consumptionプランについて、2028年9月30日以降はホスティングが終了し、移行では新しいFunction Appを作成して検証後に切り替える手順が案内されています（出典：Microsoft Learn「Migrate Consumption plan apps to Flex Consumption in Azure Functions」、2026年確認）。既存システムを引き継ぐ場合は、移行費用と停止時間まで見積に含めます。

Azure Functionsの委託先はどのように選べばよいですか？

委託先は「Azureに対応できます」という営業文句ではなく、Functionsを含む業務システムを設計し、運用し、障害から復旧できるかで選びます。公開事例にFunctionsの記載があれば参考になりますが、事例が公開できない業界もあるため、提案時の質問と設計レビューで実力を見極めます。

確認したい技術項目は、HTTP、Timer、Blob、Queue、Service Bus、Event Gridなどのトリガー、Durable Functionsの状態管理、冪等性、リトライ、デッドレター、コールドスタート、同時実行、CI/CD、IaCです。単にコードが書けるだけでなく、障害時に同じ注文が二重登録されない設計や、処理途中から安全に再開する設計を説明できるかを見ます。

業務理解では、受発注、在庫、請求、顧客、製造、医療など、自社に近いデータや規制を扱った経験を確認します。たとえば医療情報や個人情報を扱う場合は、匿名化、権限分離、監査ログ、委託先管理を提案に反映できる会社が必要です。日本マイクロシステムズのIoTプラットフォーム事例や、メタテクノの医療クラウドシステム開発のように、Azure Functionsを含む具体的な公開情報がある場合は、担当範囲と現在の体制まで聞きます。

「リリース後の問い合わせは何時間以内に返るか」「夜間障害は誰が一次対応するか」「Azure障害とアプリ障害をどう切り分けるか」「障害ログと相関IDをどこで確認するか」「再処理の承認者は誰か」を質問します。Application Insightsを導入するだけでなく、どのメトリクスにアラートを出し、誰がどの手順で復旧するかまで定めている会社を選びます。

引き継ぎでは、ソースコード、IaC、環境設定、依存関係、テストデータ、デプロイ手順、ロールバック手順、運用カレンダーを受け取ります。受託会社の担当者しかデプロイできない状態は、納品後の事業継続リスクになります。最終月に説明会を一度行うだけでなく、発注者が自分のサブスクリプションへ検証デプロイする場を設けます。

Azure Functionsの見積書を比較するときのポイント

安い見積書を選ぶのではなく、同じ前提で比較できる見積書に整えてから判断します。見積金額だけでなく、作業範囲、前提、除外項目、成果物、体制、スケジュール、受入条件、保守範囲、Azure利用料の試算を横並びにします。

要件定義、基本設計、詳細設計、Function開発、データベース、外部連携、認証、ネットワーク、IaC、CI/CD、単体テスト、結合テスト、負荷テスト、移行、リリース、運用設計を分けて記載してもらいます。各工程の担当職種、工数、単価、期間が分かれば、会社ごとに工程の含み方が違う問題を発見できます。

特にFunctionsでは、実装本数だけでなく、トリガーの種類、外部接続数、データ変換の複雑さ、エラー処理、再実行、認証、ログ、テストデータの準備が工数を左右します。見積書の関数数が少なくても、基幹連携やセキュリティの設計を含むなら高くなるのが自然です。逆に開発費が極端に低い場合は、非機能要件や運用設計が除外されていないか確認します。

見積書に「発注者がAPI仕様を提供する」「本番データ移行は対象外」「Azureアカウントは発注者が準備する」「負荷試験は別途」「平日日中のみ保守」と書かれていれば、除外項目として一覧化します。候補会社に同じ質問を送り、含む・含まない・別途の三つに整理すると比較しやすくなります。

Azure利用料は、月間実行数、平均実行時間、メモリ、同時実行、データ転送、ログ保存期間、DB容量を使って試算します。Microsoftの価格ページに掲載される無料枠や単価は、プラン、リージョン、契約形態で変わるため、見積取得時点の公式価格を基準にします。見積書に「Azure費用は実費」とだけある場合は、月額の下限・標準・ピークの三つのシナリオを出してもらい、予算超過時の通知設定も含めます。

要件の聞き取りが短く、Functionsの本数だけで即日見積を出す会社には注意します。ピーク件数や障害時の再処理を聞かずに「サーバーレスなので安い」と説明する場合、後から設計変更が発生する可能性があります。「セキュリティはAzure標準です」「監視はログを確認できます」だけで、認証方式、権限、ログの保存期間、アラート条件を説明しない場合も、提案の深さを確認します。

候補会社には、同じ想定ケースでエラーを再処理するデモ、IaCで検証環境を再構築する手順、ログから処理を追跡する方法を示してもらいます。すべての提案を無償で作り込んでもらうのではなく、初期提案では設計の考え方と前提を比較し、必要なら有償のアーキテクチャレビューやPoCへ進むと、発注者と委託先の双方に無理がありません。

よくある質問

Azure Functionsの発注では、技術選定、費用、契約、運用を一緒に考える必要があります。ここでは、発注前によく寄せられる質問に直接回答します。

必ず安くなるとは限りません。短時間のイベント処理や変動の大きいアクセスでは、使った分だけ支払う構成が有利になりやすい一方、DB、メッセージング、ログ、ネットワーク、認証、監視の費用が加わります。開発費も、運用しやすい再処理設計やセキュリティを含めるほど増えるため、初期費用と5年間のTCOを分けて比較します。

発注できますが、同じ業務領域やAzureサービスを扱った設計力を確認します。公開事例がない場合は、匿名化した構成例、エラー処理、認証、監視、IaC、引き継ぎの説明を求め、必要に応じて小規模なPoCから始めます。Functionsの経験だけでなく、自社の業務と運用責任を理解できるかで判断します。

業務フロー、現行システム構成、画面や帳票の一覧、外部連携先、データ項目、月間・ピーク件数、利用者と権限、個人情報の有無、希望納期、予算、運用体制を準備します。すべてが揃っていなくても、未確定事項として明記すれば問題ありません。候補会社には、未確定事項をどう検証し、いつまでに決めるかも提案してもらいます。

まとめ

Azure Functionsのシステムを発注・外注するときは、Functionsのコード本数ではなく、業務イベント、データ、ピーク負荷、障害時の再処理、セキュリティ、監視、運用体制まで含めて要件を整理します。技術選定では、App Service、Logic Apps、Container Appsなどとの比較を行い、Functionsを使う理由を説明できる状態にします。

発注形態は、要件が曖昧なら要件定義やPoCから始め、固まった範囲を請負、継続的な改善や内製化支援を準委任で依頼する方法が現実的です。RFPには、成果物、IaC、ソースコード、Azureアカウント、受入条件、保守範囲、責任分界を記載します。見積は初期開発費、Azureの実行料金、周辺サービス、保守費を分け、複数社を同じ前提で比較します。

最終的には、最安の委託先ではなく、業務理解とAzureの設計・運用力を持ち、契約終了後も自社で管理できる状態を作れるパートナーを選ぶことが、Azure Functionsのシステム開発を成功させる近道です。

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

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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