Power Platform で社内の問い合わせ・申請を仕組み化するとき、ツールではなく「進め方」をどう設計するかの話
社内の経費申請が、いまだに紙とハンコで回っている。
ヘルプデスクへの問い合わせが、特定の人の Outlook に溜まり続けている。
休暇申請の集計のために、毎月末、誰かが Excel を手で突き合わせている。
これらをデジタル化したい、という相談は、Microsoft 365 を導入した組織なら必ず出てくる。
そして、その多くが、Power Apps や Power Automate という「ツールの話」から始まる。
ところが、社内デジタル化の成否を分けるのは、ツールの選定ではない。進め方の設計だ。同じ Power Platform を使っても、定着する組織と頓挫する組織がある。その差は機能の差ではなく、最初にどう設計したかの差にある。
ここでは、手段としての Power Apps / Automate / BI の操作手順は扱わない。扱うのは、社内の申請・問い合わせ業務をデジタル化するとき、働く人が「失敗しないために」どこで判断を間違えやすいか、という判断軸だ。
1. ツールを選ぶ前に、ひとつだけ確認しておきたいこと
仮に、いま手元にある「紙の経費申請」と「Outlook に溜まる問い合わせ」を、何も設計せずにそのままツールに載せ替えたとする。
起きやすいのは、次の二つだ。
ひとつ目は、作った人にしか分からないツールが、ひとつ増えること。最初は便利に動く。だが、作った担当者が異動・退職した瞬間、誰も中身を把握していない申請フローが本番で回り続ける。修正もできず、止めることもできず、ただ動いている。これは「デジタル化が進んだ」のではなく、属人化の形が紙からアプリに変わっただけだ。集計の手作業が消えた代わりに、保守できない資産がひとつ増えている。
ふたつ目は、最初は問題なかった設計が、データが溜まった頃に壊れること。後で §3 で具体的な数字を挙げるが、SharePoint リストを安易にデータ置き場にすると、件数が一定の閾値を超えた時点で一覧の挙動が変わる。運用 1 年目は快適でも、2〜3 年分のデータが溜まった頃に、ある日突然「申請一覧が全部は出てこない」事態になる。そのとき作った人がもういなければ、原因の特定から始めることになる。
どちらも、ツールの機能不足が原因ではない。進め方を設計しなかったことが原因だ。
逆に言えば、この二つは設計段階でほぼ回避できる。本記事の残りは、その設計の判断軸を順番に整理していく。
2. デジタル化は、なぜこれほど進まないのか
まず、自分の組織がどの位置にいるのかを、公的データで確認しておきたい。「うちだけ遅れている」という焦りも、「もう手遅れだ」という諦めも、たいてい数字を見ると不要になる。
総務省「令和 7 年版情報通信白書」によると、大企業の約 25%、中小企業の約 70% が、デジタル化を「未実施」と回答している。半数以上の中小企業は、まだ着手すらしていない段階にある。
一方で、市場は着実に動いている。ITR の調査では、国内のローコード/ノーコード開発市場は 2023 年度実績で 812 億 2,000 万円（前年度比 14.5% 増）、2023〜2028 年度の年平均成長率（CAGR）は 12.3% で、2028 年度には 1.8 倍規模になると見込まれている。IDC Japan のノーコード開発市場の集計でも、2023 年の 1,225 億円から 2028 年に 2,701 億円（CAGR 17.1%）への拡大が予測されている。
つまり、構図はこうだ。市場は二桁成長で伸びているのに、現場の過半数はまだ動いていない。これは「乗り遅れた」という話ではない。むしろ、いま着手する組織が、まだ大多数の側にいられる、という話だ。
IPA「DX 動向 2024」（調査対象 1,013 社）でも、成果が出ている割合が高い領域として「アナログ・物理データのデジタル化」「業務効率化による生産性向上」が挙げられている。派手な新規事業ではなく、申請・問い合わせのような地味な定型業務こそ、デジタル化の効果が素直に出る領域だということだ。
ここで一点、釘を刺しておきたい。市場が伸びているからといって、「とにかく早く、大きく入れる」のは別の話だ。データが示すのは「効果の出る領域がはっきりしている」ことであって、「急いで全社展開すべき」ではない。むしろ、急いだ組織ほど躓く。その理由を、次に見ていく。
出典：総務省「令和 7 年版情報通信白書」、ITR プレスリリース（2025-02-06）、IDC Japan（2024-11-25）、IPA「DX 動向 2024」（2024-06-27）
3. 「では、まず全社で標準化すればいいのか」
ここで、よくある判断が出てくる。
「どうせやるなら、最初から全社共通の仕組みにしよう。部署ごとにバラバラに作られると、後で統合が大変だ」
筋は通っている。だが、社内デジタル化が頓挫する典型的なパターンが、まさにこれだ。全社一括導入である。
全社の申請業務をいちどに棚卸しし、関係部署すべての要件を集め、合意を取り、完璧な共通基盤を設計してから一斉展開する——という進め方は、立派に見えて、最も失敗確率が高い。要件定義の段階で部署間の調整に半年かかり、その間に現場の関心は冷め、ようやく動き出す頃には最初の要望を出した担当者が異動している。途中で一度でも止まれば、「やっぱりデジタル化は難しい」という空気だけが残る。
Microsoft 公式の「Power Platform Adoption Guidance」（2025 年改訂版）も、いきなりの全社展開ではなく、「インスピレーション → エクスプロレーション → エクスパンション」という段階的な進め方を明示している。小さく試して（PoC）、効果を確認してから広げる、という順番だ。公式が推奨しているのは「大きく完璧に」ではなく「小さく確実に」のほうである。
理由は単純で、申請・問い合わせ業務は部署ごとに事情が違いすぎる。経費申請と休暇申請と備品購入では、承認者も例外処理も別物だ。これを一枚岩の共通基盤に押し込もうとすると、どの部署にとっても少しずつ使いにくいものができあがる。
判断軸はこうだ。まず、いちばん困っている一業務を、一部署で動かす。 全社共通化は、現場で実際に回るパターンが見えてから考えればいい。順序を逆にした組織が頓挫している。
4. 「だったら、追加ライセンスを買えば解決するのか」
スモールスタートの方針が決まると、次に必ず突き当たるのが、ライセンスの問題だ。
「Power Apps とか Power Automate って、結局いくらかかるんですか。追加で買わないと使えないんですよね」
ここは、はっきり数字で押さえておきたい。Microsoft 365 を導入済みなら、追加ライセンスなしで使える範囲が、想像よりずっと広い。
Microsoft Learn の公式情報によれば、Microsoft 365 に付帯する「Power Apps for Microsoft 365」では、次のことが追加費用なしでできる。
- キャンバスアプリの作成・実行・共有
- Microsoft 365 内のデータ（SharePoint、Outlook、Teams など）への接続
- 標準コネクタの利用
- モバイル・ブラウザでの実行
一方で、付帯ライセンスではできないことも明確に決まっている。
- プレミアムコネクタ・カスタムコネクタの利用
- オンプレミスのデータベースへの接続
- Dataverse をデータ基盤として単独利用すること
つまり境界はこうだ。社内の SharePoint や Outlook、Teams にあるデータを使う申請・問い合わせ業務なら、標準ライセンスの範囲でかなりのことができる。 外部の業務システムや基幹データベースに直接つなぎに行く段階で、初めてプレミアム（Power Apps Premium は 2026 年時点で 1 ユーザー月額 $20）が必要になる。
Power Automate の実行回数にも上限がある。Microsoft 365 付帯プランの API リクエスト上限は 1 日あたり 10,000 件（移行期間中の数値）で、これがプレミアムでは桁が変わる。申請・ヘルプデスク用途（年間で数百〜数千件規模）なら、標準枠で十分に収まる水準だ。
判断軸はこうだ。最初からプレミアムを前提にしない。 まず標準ライセンスの範囲で困っている業務を動かし、「標準では超えられない壁」に実際にぶつかってから、その壁を越えるためだけにプレミアムを検討する。先に予算を確保しようとして稟議が止まるより、標準枠で動くものを見せてから投資判断を仰ぐほうが、はるかに通りやすい。
なお、ライセンスの仕様は更新が速い。実際、2026 年 1 月以降は per app SKU の新規販売が終了し、2026 年 11 月以降はプレミアムに付帯していた AI Builder クレジットが廃止予定だ。だからこそ、本記事の数字も鵜呑みにせず、判断の直前に公式ページで最新値を確認してほしい（出典は §11）。
出典：Microsoft Learn「Licensing overview for Microsoft Power Platform」（2025-06-17）、「Limits of automated, scheduled, and instant flows」（2026-03-24）
5. 「では、小さく作れば、それで安全なのか」
スモールスタートで、標準ライセンスの範囲で作る。ここまで来ると、安心しそうになる。
だが、もうひとつ落とし穴がある。小さく作ったものが、データの蓄積で後から壊れるケースだ。§1 のふたつ目で触れた問題が、ここで具体的な数字になる。
社内の申請データを置く先として、多くの場合 SharePoint リストが選ばれる。手軽で、追加コストがなく、最初は快適に動く。問題は、SharePoint リストには公式の制限値があることだ。
Microsoft Support の公式情報によれば、SharePoint Online のリストには 1 ビューあたり 5,000 件という閾値がある（変更不可）。リスト自体は約 3,000 万件まで格納できるが、ひとつの一覧で一度に扱えるのは 5,000 件まで、ということだ。これを超える取得をかけると、HTTP 429 や 503 といったエラーが返り、一覧が正しく表示されなくなる可能性がある。
加えて、Power Apps から SharePoint を扱うときには「委任（デリゲーション）」の制限があり、委任できないクエリでは最大 2,000 件しか取得できない。Power Automate 側の「Get items」でページネーションを有効にすれば最大 10 万件まで扱えるが、これは設計時に意識していないと効いてこない。
ここで大事なのは、過度に怖がらないことだ。申請・ヘルプデスク用途で年間に数百〜数千件のペースなら、5,000 件の閾値は短中期では問題になりにくい。 怖いのは、無自覚に何年も同じリストへ溜め続け、ある日閾値を越えて初めて気づくパターンのほうだ。
判断軸はこうだ。「いま動くか」ではなく「3 年後も動くか」で設計する。 具体的には、年度や種別でデータを分ける運用ルールを最初に決めておく、インデックスとフィルタービューを設定しておく、件数の伸びを定期的に確認する。どれも初期に決めれば数十分の作業で、後から作り直すより圧倒的に安い。
小さく作ること自体は正しい。だが「小さく作る」と「将来を考えずに作る」は別物だ。後者を避けるのが、ここでの設計だ。
出典：Microsoft Support「List View Threshold for large lists and libraries」、Microsoft Learn「SharePoint connector reference」
6. なぜ、社内ツールは「野良」だらけになるのか
ここまでは個々の判断軸の話だった。最後に、もう一段引いて、構造の話をしておきたい。
社内デジタル化を進めると、ほぼ必ず通る道がある。**「野良アプリ」**の増殖だ。誰かが善意で作った申請アプリ、退職者が残したフロー、どの部署が管理しているのか分からないツールが、テナント内に静かに増えていく。
これは、作った個人を責める話ではない。むしろ逆だ。現場の人が自分で業務を改善しようと動いた、その結果として生まれるものだ。問題は個人の側ではなく、それを管理する仕組みが置かれていない構造の側にある。
ローコード/ノーコードは「誰でも作れる」ことが価値だ。だが裏返せば、「誰が何を作ったか、誰も把握していない」状態を生みやすい。構造として整合を欠いているのは、ここだ。組織は「現場で自由に作っていい」と旗を振りながら、「何が作られているか可視化する仕組み」を同時に用意していないことが多い。アクセルだけ踏んで、ハンドルもブレーキも付けていない車を配って、事故を個人の不注意のせいにする——そういう構図になりやすい。
Microsoft は、この問題の実在を公式に認めている。CoE(Center of Excellence) Starter Kit という無料のガバナンスツールセットを公式に提供し、テナント内のアプリ・フロー・コネクタを可視化して野良アプリを検出・管理できるようにしている。公式が「ガバナンスと可視性の確立に役立ってきた」と表現していること自体が、野良アプリ問題が普遍的に起きている証左だ。
ガバナンス側の公式推奨は、大きく三つに整理できる。
ひとつは、環境の分離。Default（個人の学習用）/ Sandbox（開発・テスト用）/ Production（本番用）の 3 層に分け、本番と実験を混在させない。これだけで「誰かが試しに作ったものが、いつの間にか本番で使われている」事態を構造的に防げる。
ふたつは、DLP(データ損失防止)ポリシー。コネクタを Business / Non-Business / Blocked に分類し、機密データが外部サービスへ流れる経路を最初から塞いでおく。テナント全体でも環境単位でも設定できる。
みっつは、可視化の常設。CoE Starter Kit でテナント内の資産を棚卸しし、「誰が・何を・どこで」作っているかを継続的に把握する。
見過ごされやすいのは、これらが「全社展開してから慌てて入れるもの」だと思われていることだ。順序が逆だ。ガバナンスの枠組みは、最初の一業務を動かす前に、軽くでいいから置いておく。後から全社の野良アプリを棚卸しするコストに比べれば、最初に環境を 3 層に分けておくコストは、ほとんど無視できる。
構造の話を、ここで達観として畳んでおく。野良アプリが増えるのは、現場が無能だからでも、ツールが悪いからでもない。自由に作れる道具を配るなら、同時に把握する仕組みを置く——それだけのことが、置かれていないだけだ。そして、その仕組みは公式が無料で用意している。あとは、最初に置くか、問題が起きてから置くか、順序の選択が残っているにすぎない。
出典：Microsoft Learn「Power Platform CoE Starter Kit overview」（2026-04-21）、「Implement a data policy strategy」（2025-09-02）、「Power Platform 2025 release wave 1 - Governance」（2026-01-29）
7. 数字で見ると、どこに効果が出るのか
ここまで定性的な判断軸を整理してきた。最後に、効果の規模を数字で押さえておく。ただし、ここは透明性のために順序を分けて書く。公的に裏付けられる数字と、著者の試算にすぎない数字を、はっきり区別する。
7-1. 公的に裏付けられる効果（一次データ）
まず、引用できる一次データから。Forrester Consulting が Microsoft の委託で実施した「Total Economic Impact™ of Microsoft Power Automate」(2024) では、次の結果が報告されている。
- 3 年間の ROI：248%、投資回収期間は 6 ヶ月未満
- 高インパクトな自動化活用で、従業員 1 人あたり年間 200 時間の削減
- Power Automate と Power Apps を併用した場合、年間 450 時間の削減、自動化に関与する社員比率は 25% から 66% へ
- ある製薬企業では、72 本の自動化により年間 11,000 時間を削減
これは RPA・自動化全般のインパクトを測ったもので、申請業務に限定した数値ではない。だが、自動化を「正しい進め方で」入れたときに、年単位・人単位でどの程度の時間が戻ってくるかの一次的な目安にはなる。
7-2. 著者試算：申請業務に当てはめると（参考値）
ここからは、上の一次データを申請業務という具体に引き寄せるための、著者の試算である。公的統計ではなく、読者が自分の組織で照合するためのモデルとして読んでほしい。数字は組織の規模・申請件数に応じて当然変わる。
| 業務 | 試算前提（著者モデル） | 想定削減（試算） |
|---|---|---|
| 申請〜承認のリードタイム | 紙・メール回覧の往復を自動ルーティングに置換 | 短縮（公式公表値なし・組織依存） |
| 月末の集計・突き合わせ | Excel 手作業を自動集計に置換 | 工数削減（公式公表値なし・組織依存） |
| 問い合わせの取りこぼし | 個人 Outlook をフォーム＋台帳に置換 | 抜け漏れの低減（定量化困難） |
| 初回 PoC の立ち上げ | 一業務・一部署のスモールスタート | 数週間規模（公式工数なし・試算） |
重要な注記：業界の二次情報には「承認処理時間 50〜75% 削減」「集計工数 月 20 時間削減」「4 週間で PoC」といった数字が出回っている。だが、これらは申請業務に限定した一次ソースで直接裏付けられるものではない。本記事ではこれらを断定しない。確実に言えるのは、Forrester の 3 年 ROI 248% / 年 200 時間削減 という一次データと、「正しい進め方なら回収は早い」という方向性までだ。
7-3. この数字の使い方
数字の役割は、稟議を通すための盾ではない。「やる価値があるか」を自分の組織の数字で見積もるための物差しだ。Forrester の一次データを上限の参考に置き、自分の組織の申請件数と手作業時間を当てはめて、現実的な期待値を自分で出す。他社事例の派手な削減率をそのまま掲げるより、控えめでも自分の数字で語れるほうが、現場でも経営層でも信頼される。
注：§7-2 の表は公的統計ではなく、著者が公開情報と一般的な業務像をもとに作成した試算である。一次データは §7-1 の Forrester TEI 2024 のみ。
8. 選択肢
ここまでの判断軸を踏まえると、進め方は概ね 3 つの軸で整理できる。どれにも光と影があり、どれが正解ということはない。組織の状況で選ぶものだ。
選択肢 A：スモールスタートで始める
光：失敗のコストが小さい。一業務・一部署なら、うまくいかなくても損失は限定的で、動くものを早く見せられる。公式の推奨もこちらだ。
影：部署ごとに最適化が進むと、後で全社統合する際に手戻りが出る。「小さく始めたものを、いつ・どう束ねるか」を最初から意識しておかないと、結局は野良アプリの一群を自分で生むことになる。スモールスタートは「始めやすい」が「広げやすい」とは限らない。
選択肢 B：内製化するか、外注するか
内製化の光：現場の事情を知っている人が作るので、要件のズレが少なく、改修も速い。ノウハウが組織に残る。
内製化の影：作った人に依存する。その人が抜けた瞬間、保守できる人がいなくなる。属人化のリスクは内製のほうが高い。
外注の光：専門家が設計するので、ガバナンスや将来の拡張を最初から織り込める。立ち上げが速い。
外注の影：コストがかかり、改修のたびに依頼が要る。中身が手元のブラックボックスになり、結局「自分たちで触れないツール」がひとつ増える危険がある。
実務では「外注で土台を作り、運用と小改修は内製で回す」といった折衷が現実的なことが多い。どちらか一方に振り切る前に、「3 年後に誰がこれを保守しているか」を先に決めるのがよい。
選択肢 C：標準ライセンスで粘るか、プレミアムに投資するか
標準ライセンスで粘る光：追加コストゼロで、Microsoft 365 内のデータなら相当のことができる。投資判断を後ろに倒せる。
標準ライセンスで粘る影：外部システム連携やオンプレ接続、大量データ処理といった壁にぶつかると、回避策が複雑になり、かえって保守しづらいものができることがある。
プレミアム投資の光：制限が外れ、設計の自由度が上がる。素直な構成にできる。
プレミアム投資の影：ユーザー単位の継続コストが乗る。しかもライセンス体系は更新が速く（§4 のとおり SKU 廃止・特典変更が現に起きている）、前提が変わるリスクを抱える。
判断の順序は一貫している。標準で動くものをまず作り、標準では越えられない壁に実際にぶつかってから、その壁のためだけにプレミアムを検討する。 先に予算ありきで始めない。
9. 最後に
社内の申請・問い合わせをデジタル化する、というのは、新しいツールを導入することだと思われがちだ。だが、ここまで見てきたとおり、成否を分けたのは一度もツールの性能ではなかった。
全社一括で完璧を狙って頓挫するか、一業務から小さく確実に動かすか。
標準ライセンスの範囲を見極めるか、最初から予算で身動きが取れなくなるか。
データが溜まった 3 年後を想像して設計するか、いま動くことだけを見て後で壊すか。
自由に作れる道具に、把握する仕組みを添えるか、添えないか。
どれも、機能ではなく進め方の判断だ。そして、これらの判断軸は Power Platform のバージョンが変わっても、製品が別物に置き換わっても、ほとんど変わらない。
ツールは半年ごとに仕様が変わる。本記事の数字も、次の更新で書き換わるだろう。けれど、小さく始め、境界を見極め、将来を見越し、把握できる形にしておく——この設計の順序だけは、変わらずに残る。
派手な成功事例を真似することよりも、自分の組織の地味な一業務を、失敗しない順序で確実に動かすこと。それが、結果として最も速い。
10. 関連リソース
本記事は「進め方の設計」という土台の話に絞った。個々のツールの操作手順や内部設計は、以下の関連記事で扱う。
10-1. 標準ライセンスの限界を具体的に知る
§4 で触れた標準枠と上限値を、Power Automate に絞って実務的に整理している。
→ 関連記事：Power Automate 無料枠・標準枠の限界
10-2. Power Automate か、Logic Apps か
社内業務を超えて本格的な自動化に踏み込むとき、どちらを選ぶかの判断軸。
→ 関連記事：Power Automate と Logic Apps の使い分け
10-3. 壊れにくいフローの作り方
§5 で触れた「3 年後も動く設計」を、フローの疎結合という観点から具体化している。
→ 関連記事：Power Automate のフローを疎結合で設計する
10-4. このスキルを、働き方の選択肢につなげる
社内でローコード開発を担えるスキルは、組織の中だけでなく、働き方の選択肢そのものを広げる。その出口を考えるときの、機能ではなく運用品質で選ぶ判断軸。