Power Appsで申請フォームを内製する方法｜限界と使い分け

Power Appsを使えば、追加ライセンス費用をかけずに申請フォームを内製できる——この可能性に気づいた情シス・総務担当者も少なくないでしょう。すでにMicrosoft 365を契約している企業であれば、Power Apps・Power Automate・SharePointを組み合わせることで、休暇申請や備品利用申請といった定型業務の電子化を自社で完結できます。ただし「内製できる範囲」と「専用サービスに任せるべき範囲」の見極めを誤ると、作ったはいいが誰もメンテできない「野良アプリ」や、承認は電子化できても後工程が手作業のまま残る中途半端な自動化に陥ります。本記事では、Power Appsによる申請フォーム内製の具体的な手順と、内製化が持つ限界、そして専用ワークフローサービスとの使い分け基準を整理します。

Power Appsで申請フォームを内製するとは？基本を理解する

Power Appsによる内製化とは、SharePointをデータベース代わりに、Power Appsを入力画面、Power Automateを承認・通知の自動化エンジンとして組み合わせ、申請から承認までの一連の流れを自社で構築することを指します。この三つのサービスはMicrosoft 365のライセンスに標準で含まれているケースが多く、追加費用ゼロで着手できる点が最大の特徴です。

Power Apps・Power Automate・SharePointの役割分担

役割は明確に分かれています。SharePointリストは申請データを保存する「台帳」、Power Appsは申請者が入力する「フォーム画面」、Power Automateは申請内容をトリガーに承認者へ通知を飛ばしたり、承認・却下の結果をステータスとして書き戻したりする「自動化エンジン」です。この三層構造を理解せずに着手すると、どこに何を実装すべきか迷い、手戻りが発生しやすくなります。

なぜ今「申請フォームの内製化」が注目されているのか

注目される最大の理由は、Microsoft 365契約済み企業にとって追加コストがほぼゼロで始められる点にあります。外部ワークフローツールの選定・契約プロセスを経ずに、情シスや総務が自ら検証を始められる手軽さが支持されています。

ただし「追加費用ゼロ」が成り立つのは、標準コネクタの範囲内だけです。Microsoftのライセンス解説は、はっきりこう書いています。

Users with the free plan or one of the Microsoft 365 license plans can only access standard connectors, but most of the other license plans and trials provide access to premium connectors.

標準コネクタはExcel・Outlook・SharePointなどMicrosoft 365の中のデータ、プレミアムコネクタはその外（DocuSign、Zendesk、Jiraなど）という区分です。会計システムや基幹システムにつなぐ時点で、たいていプレミアム側に出ます。

ライセンスが誰に要るかは、トリガーで変わる

見落としやすい点をもうひとつ。プレミアムコネクタを使うフローでライセンスが必要になる人が、起動のしかたで変わります。

フローの種類	ライセンスの判定
自動フロー・スケジュールフロー	フローの所有者のライセンスで動く
インスタントフロー（ボタン起動など）	実行するユーザーのライセンスが要る

承認フローで効いてきます。承認者がボタンを押して動かす作りにすると、承認者全員ぶんのライセンスが必要になり得ます。設計段階でトリガーの種類を決めておいてください。

内製化で対応できる申請業務の具体例

内製化が特に機能しやすいのは、承認段階数が少なく、承認後の処理がシンプルな業務です。具体的には休暇申請、入館申請、備品利用申請、会議室利用申請などが該当します。一方で、申請後に発注・支払・仕訳といった後工程が発生する経費精算や購買申請は、内製だけでは完結しにくい領域である点は後述します。

Power Appsで申請フォームを作る手順【実践ガイド】

Power Appsでの申請フォーム構築は、データ設計→画面作成→フロー実装という3ステップで進めるのが基本です。この順序を守らないと、後からフィールド追加や承認分岐の修正が発生し、作り直しのコストが増大します。

STEP1：SharePointリストで申請データの受け皿を設計する

最初に申請項目（申請者名、申請日、金額、理由、承認ステータスなど）をSharePointリストの列として定義します。この段階で承認ステータス列（申請中／承認済／却下）を必ず用意しておくことが、後続のPower Automateでの分岐処理を簡潔にするポイントです。

STEP2：Power Appsで申請フォーム画面を作成する

SharePointリストを接続したキャンバスアプリを作成し、入力フォームと一覧画面をノーコードで組み立てます。入力規則（必須項目、数値範囲チェック）をこの段階で設定しておくと、後工程での不正データ混入を防げます。

STEP3：Power Automateで承認通知・多段階承認フローを組み込む

申請データの新規作成をトリガーに、承認者へTeamsやメールで通知を飛ばし、承認・却下の結果をSharePointリストに書き戻すフローを構築します。金額に応じて承認者を分岐させる多段階承認も、条件分岐アクションで実装可能です。この承認フロー設計の具体的な画面操作はMicrosoft 365で承認フローを作る方法【画面付き】で詳しく解説しているので、実装時に参照してください。

内製化のメリットと、見落としがちな限界

内製化の価値はコストとスピードにありますが、承認後の業務処理までは自動化できないという明確な限界があります。この限界を認識せずに導入すると、「申請は電子化されたのに、結局Excelで仕訳転記している」という状態に陥ります。

メリット：コスト削減・現場主導のスピード開発・業務理解者が直接作れる強み

外部ベンダーへの発注・要件定義のやり取りが不要なため、現場の業務理解者が仕様変更をその場で反映できます。小規模な承認フローであれば、数日〜数週間で本番運用に乗せられるスピード感が最大の利点です。

限界①：承認後の「発注・支払・仕訳」までは自動化できない

Power Automateの標準機能では、承認完了後の会計システムへの仕訳連携や、発注書の自動発行、証憑のOCR読み取りといった処理までは対応しきれません。これらを実現するにはPremiumコネクタの追加費用や、会計システム側のAPI連携開発が別途必要になります。経費精算領域での自動化範囲と注意点はPower Automateで経費精算を自動化する方法と注意点で詳しく整理しています。

この「承認と後工程の分断」は内製に限った話ではありません。発注・検収・請求をどう突き合わせるかという論点そのものは、三点照合とはに整理しています。

限界②：属人化・野良アプリ化・退職時の引き継ぎ問題

作成者が異動・退職すると、フローの中身を誰も理解できなくなるリスクがあります。また、承認フローが途中で止まる、通知が届かないといったトラブルも内製アプリでは頻発しがちで、原因の切り分けには一定の知識が必要です。この点はPower Automateの承認フローが止まる原因10選で原因別に整理しているため、運用開始前に目を通しておくと保守負荷を減らせます。

内製 vs 専用ワークフローサービス、どちらを選ぶべきか

結論として、申請件数が少なく承認後の処理が単純な業務は内製、後工程に発注・支払・証憑管理が絡む業務は専用サービスという住み分けが現実的です。両者を同じ基準で比較すると判断を誤ります。

内製が向いているケース

承認段階が1〜2段階で、申請後の処理が「承認済みフラグを立てるだけ」で完結する業務（備品利用申請、入館申請など）は内製で十分対応できます。

専用サービスが向いているケース

経費精算や購買申請のように、承認後に仕訳連携・証憑保管・支払処理が発生する業務では、これらを標準機能として備えた専用サービスの方が開発・保守コストを抑えられます。プレミアムコネクタのライセンスを人数分買い足す判断と、専用サービスを入れる判断は、同じ土俵で比べることになります。

比較判断チェックリスト

判断の目安は3点です。

確認すること	専用サービスに寄る条件
承認後に何が続くか	会計・在庫システムとの連携が必要
使うコネクタ	プレミアムコネクタが要る（人数ぶんのライセンス費用が乗る）
保守の体制	作成者が異動・退職した後にメンテできる人がいない

件数そのものは判断軸になりません。 月に数件でも、承認後に仕訳連携が必要なら内製では止まります。逆に件数が多くても、承認済みフラグを立てて終わる業務なら内製で回ります。

Power Apps申請フォーム内製を成功させるポイント

内製化を失敗させないための核心は、作る前にガバナンスと引き継ぎルールを決めておくことです。作ってから整備しようとすると、既に野良アプリ化が進行していることが多いためです。

ガバナンス・CoE体制の整え方

誰がどの業務でアプリを作ってよいか、承認・公開前に情シスがレビューするかといったルールを事前に定めます。

ドキュメント化と引き継ぎルールの整備

フローの処理内容、承認者設定、エラー時の対処手順を文書化し、作成者以外でも保守できる状態を維持します。

スモールスタートから段階的に拡張する設計思想

最初から全申請業務を網羅しようとせず、1業務ずつ検証・本番投入を繰り返す方が、手戻りを最小化できます。

よくある質問（FAQ）

Power Appsで申請フォームを作るのに追加費用はかかりますか？

いいえ、標準コネクタの範囲内であれば、既存のMicrosoft 365ライセンスに含まれるPower Apps/Power Automateの機能だけで構築可能です。ただしPremiumコネクタや外部システム連携を使う場合は、ユーザーあたり追加のPremiumライセンス契約が必要になります（具体的な金額は契約プランにより異なるため、導入前にMicrosoftの料金体系を確認してください）。

Power Appsで作った申請アプリは誰でもメンテナンスできますか？

いいえ、ノーコードとはいえフローの構造理解には一定の学習が必要です。作成者以外が保守できるよう、設定内容や分岐条件をドキュメント化しておくことが前提になります。

Power Appsの内製化だけで経費精算・購買申請の自動化は完結しますか？

いいえ、承認までは自動化できますが、発注・支払・仕訳といった後工程は標準機能だけでは対応しきれません。これらを含めて自動化したい場合は、専用のワークフローサービスとの併用を検討する必要があります。

Power Appsと既製のワークフローシステム（1Approvalなど）はどちらが自社に向いていますか？

これは業務の複雑さで判断します。承認後の処理がシンプルな社内申請は内製、会計・証憑管理との連携が必要な業務は専用サービスが向いています。両方を併用し、業務ごとに使い分ける企業も少なくありません。

1Approvalでの実現方法

1Approvalは、いま使っている承認ワークフロー（Microsoft 365、Teams、Google Workspace、kintone）の上で、承認が降りた時点で発注や手配まで完了させる仕組みです。

Power Appsの内製との関係はこうです。

	内製で止まるところ	1Approvalの扱い
承認後の発注	標準コネクタの外になりやすい	承認後に発注・手配まで進む
立替精算	フロー自体は作れるが工程は残る	法人一括請求にまとまる
申請の入口	業務ごとにアプリが増える	入口が1つになる

• 承認と発注の間が消える — 承認後に注文し直す工程がなくなります
• 申請の入口が1つになる — 何をどこで買うかに関わらず同じ場所から申請できます
• 既存の承認基盤をそのまま使う — 承認フローを置き換えません

Power Appsを置き換える製品ではありません。 内製で作った申請フォームはそのまま使いながら、承認後に残る工程をなくす方向です。

まとめ：内製化の第一歩として、まず着手すべきこと

Power Appsによる申請フォーム内製は、追加コストをかけずに業務電子化を進められる現実的な選択肢です。まずは備品利用申請や入館申請といった影響範囲の小さい業務から着手し、運用してみて保守負荷やニーズを見極めるのが安全なロードマップです。

「追加費用ゼロ」は標準コネクタの範囲に限られます。 Microsoftは、無料プランとMicrosoft 365のライセンスでは標準コネクタしか使えないと明記しています。会計システムなど外部につなぐ時点でプレミアム側に出るため、そこが内製の実質的な境界線になります。

もうひとつ、ライセンスが要る人はトリガーで変わります。 自動・スケジュールフローは所有者のライセンス、インスタントフローは実行するユーザーのライセンスです。承認者がボタンで動かす作りは、人数ぶんの費用になり得ます。

まず自社の承認フローが外部システムにつなぐ必要があるかを確認してください。 つながないなら内製で十分です。つなぐなら、そこが判断の分かれ目になります。

主な参照先

• Power Automate licensing FAQ（Microsoft Learn）
• Deep dive on specific licenses（Microsoft Learn）
• Power Apps Licensing and Pricing（Microsoft）
• Power Platform Licensing Guidance（Microsoft）

※本記事は2026年11月時点で確認した公開情報をもとに整理したものです。ライセンスの条件と料金は改定されるため、契約前にMicrosoftの最新のライセンスガイドでご確認ください。本記事は一般的な情報提供であり、個別の契約に関する助言ではありません。