Power Appsは、Microsoft 365に含まれるノーコード・ローコードのアプリ開発ツールです。プログラミングの専門知識がなくても、画面をドラッグ＆ドロップで組み立てるだけで、稟議書・経費精算・休暇申請といった社内の承認申請をアプリ化できます。紙やExcelファイルのメールでの回覧で運用している承認フローは、押印待ちや誰の手元で止まっているかわからないといった問題を抱えがちですが、Power Appsで申請アプリを作れば、申請から承認までの状況をリアルタイムで可視化できます。
本記事では、Power Appsで承認申請アプリを作る具体的な手順、料金プラン、AppSheet・kintoneとの違い、導入時の注意点を解説します。
Power Appsで作る承認申請アプリとは
Power Appsの承認申請アプリは、申請フォーム（金額・内容・希望日等の入力画面）と、承認者向けの一覧画面（承認・却下ボタン付き）をセットで作成する構成が基本です。申請データはSharePointリストやExcelのテーブル、あるいはDataverseというMicrosoft純正のデータベースに保存され、Power Automateと組み合わせることで、申請が来たら承認者にTeamsやメールで自動通知する、といった仕組みも追加できます。
紙・Excel運用との違い
紙の稟議書やExcelのメール添付での回覧運用では、「誰の手元で止まっているか」「差し戻された理由は何か」といった情報が個人の記憶や別のメールスレッドに散らばりがちです。Power Appsで作るアプリでは、申請のステータスと履歴がひとつの画面に集約されるため、総務・経理担当が状況確認のためだけに関係者へ問い合わせる手間を減らせます。
承認ルート設計の基本的な考え方
承認申請アプリを設計する際は、まず「誰が」「いくらまで」「どの順番で」承認するのかを紙に書き出して整理することが出発点になります。金額によって承認者が変わる場合（例：5万円未満は課長決裁、5万円以上は部長決裁）は、条件分岐のロジックをPower Automate側に持たせる設計にすると、後から金額の基準を変更する際もアプリ本体を作り直さずに済みます。まずは単純な1段階承認から着手し、運用しながら複数段階の承認ルートへ拡張していくのが、ノーコード開発では定石です。
承認申請アプリの作り方（Step1〜6）
Step1：紙やExcelで運用している現在の承認フロー（申請項目・承認ルート）を書き出して整理する
Step2：申請データの保存先をSharePointリストかExcelのテーブルとして用意する
Step3：Power Appsの「データから作成」機能で、保存先に接続した基本の入力アプリを自動生成する
Step4：申請一覧画面に承認・却下ボタンを追加し、ステータス（申請中・承認済・却下）が切り替わるようにする
Step5：Power Automateと連携し、申請が提出されたら承認者にTeamsで通知が届くフローを追加する
Step6：一部の部署で試験運用し、入力項目や承認ルートの過不足を確認してから全社展開する
料金プラン
| プラン | 月額目安（税別） | 特徴 |
|---|---|---|
| Power Apps（従量課金プラン） | Microsoft 365 Business系プランに含まれる場合あり | SharePoint・Excelを保存先にする分にはコストを抑えやすい |
| Power Apps プレミアム（ユーザーあたり） | 2,000円台〜 | Dataverse等の高度な機能を利用可能 |
| Power Apps プレミアム（アプリあたり） | 500円台〜 | 特定のアプリだけ利用させたい場合に割安 |
AppSheet・kintoneとの比較
| 比較軸 | Power Apps | AppSheet | kintone |
|---|---|---|---|
| 相性の良い環境 | Microsoft 365中心の職場 | Google Workspace中心の職場 | 特定の基盤に依存しない |
| 承認フローの組みやすさ | Power Automateとの連携で柔軟 | やや簡易的 | 標準機能で比較的組みやすい |
| データベースの持ち方 | SharePoint／Excel／Dataverse | Googleスプレッドシート等 | kintone専用データベース |
活用事例
建設業のお客様（従業員35名規模）：現場経費の立替精算をPower Appsでアプリ化。紙の精算書をなくし、スマートフォンからレシートを撮影して申請できるようにしたことで、経理担当の入力作業が大幅に減りました。
製造業のお客様（従業員50名規模）：稟議書の承認フローをPower Appsに置き換え。従来は紙の稟議書が上長の机に置かれたまま止まることがありましたが、アプリ化後は承認待ちの申請が一覧で見える化され、滞留が減少しました。
卸売業のお客様（従業員18名規模）：休暇申請アプリをPower Appsで内製化。総務担当が個別にExcel台帳へ転記する作業がなくなり、申請から承認までの時間が短縮されました。あわせて有給休暇の残日数を自動計算する機能も加えたことで、労務管理担当の問い合わせ対応の手間も減っています。
デメリット・注意点
複雑な承認ルートは設計に時間がかかる
金額に応じて承認者が変わる、複数部署の合議が必要になるといった複雑な承認ルートは、ノーコードとはいえ設計・テストに相応の時間がかかります。まずはシンプルな1段階承認から始めるのが現実的です。
Microsoft 365のライセンス体系がわかりにくい
無料の範囲でできること、追加ライセンスが必要になる機能の境界がわかりにくく、想定外の追加費用が発生することがあります。導入前にライセンス条件を必ず確認しましょう。特に、複数のアプリを組み合わせて使う場合や、Dataverseを使った本格的なデータベース連携を行う場合は、ユーザー数×プレミアムライセンスの費用が想定より膨らむことがあるため、試験導入の段階で見積もりを取っておくと安心です。
作成者が退職すると保守できなくなるリスクがある
ノーコードツールは特定の担当者が属人的に作り込んでしまいがちです。仕様書やアプリの構成をドキュメント化し、複数人がメンテナンスできる状態を保つ必要があります。作成担当を1人に固定せず、簡単な修正であれば別のメンバーでも対応できるよう、社内で軽い勉強会を行っておくと安心です。
スマートフォンでの操作性はアプリ設計に依存する
Power Appsはスマートフォンでも動作しますが、画面レイアウトをパソコン向けにそのまま作ると、外出先からの申請がしづらくなります。現場作業員が主な利用者になる場合は、最初からスマートフォン向けのレイアウトで設計することが重要です。
よくある失敗パターンと対策
失敗パターン1：最初から全社の複雑な承認フローを再現しようとする→ 対策：まず1つの部署・1つの申請種別（例：経費精算のみ）に絞って試験運用し、成功パターンを横展開する。
失敗パターン2：紙の運用とアプリの運用が並行して残ってしまう→ 対策：切り替え日を決め、旧来の紙・Excelでの申請は受け付けないと社内周知する。
失敗パターン3：現場のITリテラシーを考慮せず操作が複雑になる→ 対策：入力項目を必要最小限に絞り、選択式（プルダウン・チェックボックス）を多用して、文字入力の負担を減らす設計にする。高齢の従業員が多い現場では、リリース前に実際に操作してもらうテストを必ず挟み、つまずいた箇所を洗い出してから本格運用に移ることが失敗を防ぐ近道です。
当協会が中小企業のペーパーレス化を支援する中でも、稟議・経費精算のような繰り返し発生する申請業務は、最初にアプリ化の効果を実感してもらいやすい領域だと感じています。特に「毎月同じフォーマットの紙を大量に処理している」業務ほど、アプリ化による時間削減効果が数字として見えやすく、社内の理解も得やすい傾向があります。詳しくは当協会のDX支援サイトもご覧ください。
まとめ
Power Appsを使えば、紙やExcelで滞りがちだった承認申請を、追加のシステム開発費用をかけずにアプリ化できます。最初から完璧な仕組みを目指すのではなく、シンプルな承認フローから試験導入し、社内の反応を見ながら段階的に広げていくことが定着のポイントです。効果を実感した部署から自然に横展開が進むケースが多いため、最初の1本を丁寧に作り込むことが、その後の内製化のスピードを左右します。
