Power Appsの発注は、業務と要件を整理し、契約と範囲を決めたうえで、PoC、本番化、展開の順に進めると、追加費用や作り直しを抑えやすくなります。
発注形態から運用まで、発注側が決めておくことを順に取り上げます。全体像は完全ガイドにもまとめています。
▼全体ガイドの記事
・Microsoft Power Appsのシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
Microsoft Power Appsのシステムを発注する前に知るべき全体像
Power Appsは、画面を作るだけのツールではなく、業務プロセス全体をアプリ化する基盤です。入力、承認、通知、データ管理、集計、既存システムとの連携を組み合わせて作ります。
発注側は、「アプリを1本作る」と考えず、どの業務を誰がどのデータとルールで処理するかを委託範囲として決めます。
キャンバスアプリとモデル駆動型アプリの使い分け
画面の自由度を重視する現場入力、点検、日報、申請には、キャンバスアプリが向いています。また、SharePoint、Excel、SQL Server、Salesforce、Dataverseなど複数のデータソースにも接続できます。
一方、顧客、案件、設備、問い合わせなどの関係データを一元管理する場合は、モデル駆動型アプリが候補になります。Dataverseのテーブル、フォーム、ビュー、ダッシュボードを中心に構成します。
Power Automate・Dataverse・Power BIを含むシステム範囲
承認、差し戻し、期限通知、定期集計が必要な場合は、Power Automateを組み合わせます。
データの正本をDataverseに置くか、既存の基幹データを正本としてSQLやAPIに接続するかで、設計と費用が変わります。
Power BIで経営指標を見られるようにする場合は、集計の定義、更新頻度、閲覧権限を先に決めます。「Power Apps開発」とだけ書かれた発注書や見積書であれば、周辺機能が含まれるかを確認します。
Power Appsの発注形態の選び方
完成条件が明確なら請負型、検証しながら進めるなら準委任型、知識移転も重視するなら伴走型が候補になります。
なお、企画やPoCを準委任型で進め、本番化を請負型とする組み合わせも有効です。要件の不確実性と社内体制を見て、発注形態を選びます。
企画から運用までの一括外注
社内にPower Platformの担当者がいない場合は、ヒアリングと要件定義から保守までを一括で依頼できます。その中で、画面やDataverseの設計、開発を委託先に任せられます。テストや移行、教育も、同じ範囲に含められます。
窓口が一本化され、初回発注を進めやすくなります。一方で、範囲が広いほど一式の境界が曖昧になりやすいため、追加開発の単価と保守対象を契約書に明記します。
PoC外注と内製化支援の組み合わせ
全社システムを一度に作らず、申請、点検、営業報告など一つの業務を選び、2〜6週間程度のPoCを外注します。
PoCでは、入力項目、承認経路、検索性、スマートフォン操作、権限を検証し、その結果を本番要件に反映します。
社内担当者がPoC中に画面の修正や運用管理を学んでおくと、納品後にベンダーへ依存しすぎるリスクを下げられます。
Power Appsとプロコードの組み合わせ
現場入力や申請画面はPower Appsで作り、複雑な計算、大量データ処理、外部公開API、リアルタイム連携はAzureや既存システム側で実装する構成もあります。
すべてをPower Appsに詰め込むと、性能や保守性で不利になることがあります。
発注側は、委託先にPower Appsのみの案と、APIやAzureを併用する案の両方を出してもらい、将来の利用者数とデータ量も踏まえて選びます。
RFPと要件整理の準備範囲
RFPは完成設計書ではなく、各社が同じ前提で提案と見積もりを作るための依頼書です。業務目的、対象範囲、利用者、現行業務、期限、予算の考え方を整理し、未確定の事項は「提案を求める事項」として残します。
細部が未確定でも判断材料を揃えておけば、会社ごとの提案力やリスクの見立てを比較できます。
業務目的と現行フローの整理
まず、システム化する対象より先に、改善したいことを言葉にします。「申請を電子化する」だけでなく、承認までの営業日短縮や入力漏れ削減など、目的を具体的に書きます。
発注側は、現行のExcel、紙、メール、既存システムを業務フローに並べ、入力者、承認者、閲覧者、データの保管場所、例外処理を確認します。
RFPに載せる機能・データ・非機能の3層
RFPでは、提案会社が同じ条件で見積もれるよう、要件を機能、データ、非機能に分けて記載します。
- 機能要件：ログイン、入力、検索、承認、差し戻し、通知、帳票、ダッシュボード。
- データ要件：テーブル、項目、必須条件、重複ルール、移行件数、データの正本。
- 非機能要件：利用者数、同時利用、応答時間、スマートフォン対応、可用性、バックアップ、監査ログ、障害連絡。
発注側は、Power Appsの種類、接続先、プレミアムコネクタやオンプレミスデータゲートウェイの要否、環境分離も明示します。
未決定の事項は、候補と選定理由を提案書に求めます。環境の分け方については、Microsoft LearnのALM資料が、開発、テスト、本番などに環境を分け、Solutionsで構成要素を移送する考え方を示しています。
完成条件と受け入れテストの決め方
画面が完成しただけで「使える状態」と判断すると、納品時に認識が食い違います。そこで、業務シナリオ単位で受け入れ条件を決めます。
申請、承認、差し戻し後の再申請、権限のない人への非表示、所定件数と形式での移行を確認します。
発注側は、性能、エラー表示、通知の到達、監査ログ、バックアップからの復旧も、可能な範囲で確認方法を定めておきます。
Power Apps開発の契約形態と使い分け
契約形態は費用だけでなく、要件変更、成果物の責任、発注者の参加度、知的財産や保守の範囲を左右します。初期段階と本番開発では不確実性が異なるため、工程ごとに適した契約を検討します。
法務、情報システム部門、現場責任者が、見積書だけでなく契約書と個別仕様書も確認します。
要件定義やPoCに向く準委任型
準委任型は、作業時間や体制に対して対価を支払う契約です。業務ヒアリング、現行分析、試作、技術検証、内製化支援など、作業しながら要件を具体化する工程に向きます。
発注者も業務担当者を出し、週次で優先順位と課題を決めます。ただし、成果物の完成を一括で保証する契約ではありません。
発注側は、月ごとの作業内容、稼働時間、会議体、報告方法、未消化作業の扱いを契約に記載します。
仕様と受け入れ条件が固まった開発の請負型
請負型は、合意した成果物を納期までに完成させる契約です。画面、データモデル、連携仕様、テスト計画、操作マニュアルが固まった本番開発が対象になります。
契約後の項目追加や承認ルートの変更は、追加見積もりや納期変更につながる場合があります。そこで、変更管理、軽微変更の定義、追加作業の単価、検収期間、瑕疵や不具合の対応を先に決めておきます。
成果物の権利とベンダー変更時の引き継ぎ
契約書や見積もりでは、権利と引き継ぎの条件を確認します。
- アプリ資産：ソースコード、Solution、フロー、API仕様。
- 設計・管理資産：テーブル定義、環境変数、接続参照、権限設計、テスト記録。
- 利用権と管理範囲：アプリや設計書の利用権、自社環境で管理できる範囲。
- 引き渡し条件：退職や異動時の管理者変更、設定情報の引き渡し、再委託条件。
- 継続運用：外注終了後も運用できるよう、引き継ぎ期間と資料形式を見積もりに含めます。
Microsoft Power Appsのシステム開発費用相場
Power Appsの開発委託費に、公式の一律定価はありません。ここで示す金額は、業務システムの相場とローコードによる工数短縮をもとにした推定レンジです。
費用は画面数だけでなく、移行、連携、権限、テスト、教育、進行管理の範囲で変わります。そのため、レンジのどの位置にあたるかを、提案会社に説明してもらいます。
開発委託費は小規模50万〜150万円程度から始まる規模別の目安
提案会社には、開発や運用のどこまでを見積もりに含めるかを明記してもらいます。規模ごとの目安を、小さいものから順に挙げます。
- 小規模PoC
- 実用アプリ
- 部門システム
- 全社展開
申請、日報、点検など1業務のアプリで、SharePointやExcelへ接続し、基本的な権限と通知を設定する場合は、50万〜150万円程度が目安です。
30〜200人程度を想定し、Dataverse、複数画面、承認フロー、Power BIを含む場合は、150万〜500万円程度が目安です。
複数アプリ、SQLやAPI連携、データ移行、ロール設計を伴う場合は、300万〜800万円程度まで広がります（出典: NotebookLMリサーチノート「Microsoft Power Appsのシステム」、2026年作成）。
全社へ広げる場合は、複数環境、ALM、DLPが必要になります。さらに、CoE、全社教育、基幹連携、運用監視まで含むと、800万〜2,000万円以上になる可能性があります。これらは業務システム相場とPower Appsの構成要素から算出した推定で、個別見積もりではありません。
費用が高い場合は、機能を削るより先に、移行や連携を段階化できるかを検討します。
ライセンスと容量費の試算
開発会社への委託費とは別に、Power Appsの利用ライセンスやDataverseの追加容量が発生することがあります。
Power Automate、Power BI、AI Builder、Azure、ゲートウェイでも費用がかかる場合があります。
ライセンスの見積もりでは、地域差や契約条件、利用規模、容量を分けて確認します。
- 価格例
- 日本向け価格：年契約と月契約の料金。
- 容量費：Dataverseの基本容量と追加容量。
- 中長期の利用量：利用者数、データ、ログ、フロー実行量。
米国向けのPremiumは、年払いで1ユーザーあたり月20米ドルです。2,000席以上のプランは月12米ドルと表示されています。ただし、同ページはPremium価格が国・地域や契約条件で変わると案内しています。
日本では販売パートナーから最新条件を取得します（出典: Microsoft「Power Apps licensing and pricing」、2026年8月確認）。
NTT東日本が公開する2025年4月以降の料金表では、Power Apps Premiumの年間契約は税込で月3,462円です。
月契約は月3,957円です。同じ料金表で100人が利用するときの参考値は、月34万6,200円〜39万5,700円程度です。年では415万円前後〜475万円前後の参考レンジになります（出典: NTT東日本「2025年4月以降のMicrosoft料金表」、2025年）。
実際の契約、既存のMicrosoft 365契約、利用者区分、為替、販売条件によって変動します。そのため、この記事の金額を発注額として断定せず、開発費とは分けて比較見積もりを依頼します。
Microsoft公式価格ページでは、PremiumにDataverseの基本容量が含まれます。一方で、追加のデータベース容量は別のアドオンで、データ件数や添付ファイルが増えると、容量費が上がる可能性があります。
利用者数だけでなく、テーブル件数、ファイル容量、ログ保存期間、フローの実行量を確認します。そのうえで、3年程度の計画で試算すると、初年度だけ安い見積もりを避けやすくなります。
保守費の目安は初期開発費の15〜25％程度
保守・運用費は、初期開発費の年15〜25％程度を一つの目安にできます（出典: NotebookLMリサーチノート「Microsoft Power Appsのシステム」、2026年作成）。
問い合わせ受付だけか、障害対応、月次改善、Power Platformの設定変更、ライセンス管理、監査、ユーザー教育まで含むかで、範囲が大きく変わります。
発注側は、月額固定の保守、時間制の追加対応、緊急対応の単価を分けて提示してもらいます。
Power Appsの委託先選定と見積比較のポイント
資格や実績数だけでなく、要件、データモデル、権限、既存システムとの境界、運用の設計力を確認します。また、提案の分かりやすさ、リスク説明、担当者の経験、発注側の作業も比べます。
要件定義から保守までの対応範囲
提案会社には、工程ごとの担当範囲と成果物を示してもらいます。
- 設計・開発：要件定義、基本・詳細設計、開発、テスト。
- 導入：データ移行、教育、リリース。
- 運用：保守、障害時対応、運用引き継ぎ。
Dataverse設計やSharePoint移行は、画面制作の実績とは別に、設計の経験を確認して判断します。
SQLやAPI連携、オンプレミスゲートウェイ、Power Automateの失敗時の処理、Power BIの権限も確認が必要です。
実際に担当するリーダーや設計者が、提案説明に参加するかも確認します。
見積書の工程・工数・前提条件の比べ方
各社の見積もりは、総額で並べる前に、共通の項目へ分けて比べます。
- 作業費：要件定義、設計、画面・フロー開発、連携、移行、テスト、教育、管理、PM、保守。
- 工数と体制：工程別工数・単価、外注や再委託の有無。
- サービス費：ライセンス、Azure、コネクタ、容量、環境構築。
比較表には、まず利用者数、アプリ数、画面数を記載します。さらに、データ件数、連携本数、移行対象も入れます。納期、発注者の作業、レビュー回数も、同じ表に記載します。
たとえば、最安の会社が移行や受け入れテストを含めていない場合、後から追加費用が発生します。
一方で、高い見積もりでも、予備費や教育、運用設計を含む場合があります。金額差の理由を説明できる会社を評価します。
リスクを先回りして説明できる会社の見極め
制約や追加費用を説明せず、「何でも短期間で作れる」と約束する提案には注意します。
データソースの制限、委任の問題、同時利用数、API仕様、ライセンス変更、権限の複雑さ、運用担当者の不足について、リスクと対策を提案書に求めます。
できないことを明確にし、代替案や段階導入を示す会社であれば、本番運用までの姿勢を判断しやすくなります。
外注後のガバナンスと運用の設計
Power Appsは現場でアプリを作りやすい一方、管理しないとアプリやフローが増え、作成者が異動すると保守できなくなるおそれがあります。
外注案件と市民開発の両方を見据えて、ルールを設けます。環境、データ、コネクタの扱いや、権限と命名の決まりを定めます。公開と廃止のルールも用意します。
委託先には、納品時の設定だけでなく、社内で続けて管理する手順も成果物に含めてもらいます。
Entra ID・Dataverse・DLPによる権限とデータ持ち出しの管理
Power Platformを安全に運用するため、発注時に確認する観点を整理します。
- アクセス制御
- データ持ち出し防止
- 委託先からの提出物
Microsoft Learnの「Security in Microsoft Dataverse」は、利用者ごとの権限の与え方を示しています。
Entra ID認証、環境の境界、アプリ共有、Dataverseのセキュリティロール、コネクタ権限を組み合わせて設計します。特に、個人情報や機密情報を扱う場合は、アプリ共有だけで安心せず、テーブル、行、列ごとに閲覧、登録、変更、削除できる人を確認します。
DLPポリシーでは、コネクタを業務データ用、業務データを扱わないもの、利用禁止のものに分類します。メールや外部ストレージへの流出、カスタムコネクタの接続先も確認します。
監査ログや利用状況の確認者を決めます。そのうえで、契約前に委託先からセキュリティチェックリスト、権限一覧、DLP設定案、監査・障害時の連絡手順を提出してもらいます。
環境分離・ALM・教育の納品条件
納品後に担当者が変わっても運用できるよう、成果物に含める内容を整理します。
- 変更管理
- 本番データの保護
- 教育・引き継ぎ
開発、検証、本番の環境を分けたうえで、SolutionsやPower Platform Pipelinesなどを使い、開発から本番へ変更を移します。
Microsoft LearnのALM資料は、開発者が本番環境を直接変更せず、ソース管理や自動化を活用して、信頼性とリリース品質を高める考え方を説明しています。小規模なアプリでも、開発中に本番のデータへ直接手を加えない運用を設計します。
操作マニュアルを配るだけでは足りないため、利用者の操作と業務管理者のマスタ更新に分けて教育します。社内開発者には修正の方法を、管理者には環境・権限・監査について教えます。
最後に、アプリ一覧、所有者、接続情報の管理、障害の切り分け、バックアップ、廃止判断、問い合わせ先を引き継ぎます。
全社展開の事例から見る発注・外注の進め方
大規模に展開する場合は、対象業務、経営層の理解、開発者の育成、ガバナンスが成果を左右します。
外部へ委託する工程と社内で担う工程を分け、全社利用の管理体制も計画します。事例からは、短期開発を目的にせず、管理体制まで計画することの大切さが分かります。
スズキの約18,000ライセンスとガバナンスの組み合わせ
事例の規模、全社展開を支えた仕組み、自社への取り入れ方に分けて見ます。
- 事例の規模：ライセンスとアプリ展開の広がり。
- 推進要素：技術以外の体制や管理の工夫。
- 自社への適用：一律に真似せず、段階的に計画する進め方。
Microsoft Customer Storiesが2025年1月に公開した事例です。スズキは本社全従業員分として約18,000のPower Apps Premiumライセンスを購入しました。
600名以上の開発者コミュニティが参加し、10か月間で約1,500のアプリが作られたと紹介されています（出典: Microsoft Customer Stories「スズキが約18,000名分のPower Apps Premiumを購入し全社展開」、2025年）。
この事例では、経営層の体験、エバンジェリスト育成、開発アプリをIT部門から見える場所へ集約する運用も行われています。
自社では、スズキと同じ方法をそのまま当てはめず、対象の部門と業務を絞ります。そのうえで、作成者の育成、アプリの棚卸しと一覧化、公開の基準を段階的に整えます。さらに、委託先には研修、レビュー、ガバナンス設計、運用引き継ぎを求め、アプリが増えた後の統制に備えます。
PoC・本番化・展開の3段階での発注
段階ごとに検証内容を分け、継続・修正・中止の判断基準を置きます。
- PoC：実現可能性と使いやすさを確認し、全機能を作り込みません。
- 本番化：データ構造、権限、テスト、移行、環境分離、障害対応を固めます。
- 全社展開：部門別テンプレート、教育、アプリ審査、ライセンス、監視、保守体制を整えます。
段階化により初期投資を抑えられ、学習結果を次の発注に反映できます。
よくある質問
外注を考えると、費用、期間、内製化、ライセンス、既存データの接続について疑問が出てきます。発注前に確認したい3つの質問に、順に答えます。
Power Appsのシステム開発は無料で外注できますか？
本番運用まで無料で外注することはできません。ただし、開発・テスト向けの無料Developer Planはあります。
本番利用者のライセンス、Dataverse容量、外部連携、開発会社の設計・開発・テスト・運用支援には、費用がかかります。
無料枠は技術検証に使い、本番化の総額はライセンスと委託費を分けて試算します。
ExcelやSharePointのデータをPower Appsへ移行できますか？
移行はできますが、そのまま取り込めるとは限りません。重複、表記ゆれ、空欄、同時編集の履歴、個人情報の扱いを整理します。
移行対象と除外対象を決めます。単純な台帳はSharePoint、関係データや細かな権限・監査が必要ならDataverseが候補です。
また、既存の基幹システムが正本ならSQLやAPI連携を選ぶなど、データの役割に合わせます。
Power Appsの開発会社は何社から相見積もりを取るべきですか？
説明や質疑にかかる社内の工数は、会社を増やしすぎると膨らみます。そのため、比較できるRFPを用意して、2〜4社程度へ相談する方法が現実的です。
各社へ、同じ業務範囲、利用者数、連携条件、納期、受け入れ条件を渡します。
工程別の費用、前提、追加費用、保守、担当体制、リスクを同じ様式で提出してもらい、価格だけでなく説明の具体性と引き継ぎやすさも比べます。
まとめ
業務システム全体での発注範囲
発注時は、画面の価格だけで比べず、業務目的やデータの正本、権限を範囲に含めます。連携、テスト、ライセンス、保守まで含めて比べます。
要件が未確定なら準委任型でPoCを行い、仕様と完成条件が明確な部分は請負型とします。工程ごとに契約を使い分けると、変更リスクを管理しやすくなります。
費用と運用の両面での見積もり比較
発注前の比較は、費用と運用の両面から進めます。費用には幅が出やすいため、各社に共通の見積条件を示して提案を揃えます。運用支援の提案まで含むかも、あわせて確認します。
- 費用幅：PoCは50万〜150万円程度、全社展開は800万〜2,000万円以上。ライセンス・容量費は別途の場合があります。
- 比較条件：利用者数、データ量、連携、権限、環境分離、受け入れ条件を揃え、2〜4社から工程別見積もりを取ります。
- 選定基準：前提とリスクを説明し、教育や運用引き継ぎも提案できる会社。
▼全体ガイドの記事
・Microsoft Power Appsのシステム開発の完全ガイド
▼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を創業。