【InfoPathの終焉】Power Appsへの移行で失敗するパターンと、確実な再設計戦略 ― M365では救えない“フォームアプリ”をどう再生するか ―
InfoPathが終わりを迎えた理由と、いま企業が直面している現実
2003年の登場以来、InfoPathは「フォーム中心の業務」を支えてきました。
営業日報、技術支援依頼、経費申請──どの企業にも、InfoPathで構築された業務フォームが数十、数百と存在しています。
しかし、 Microsoftは2014年にInfoPathの開発終了を正式発表し、2026年のサポート終了をもって完全に姿を消します。
その結果、SharePoint Server上で動いていた数多くの業務アプリが、移行も延命もできない“中間層の空白”に取り残されつつあります。
企業は「M365（SharePoint Online）へ移行すれば解決」と考えがちですが、実際はそう簡単ではありません。
Power Appsに置き換えたものの「動かない」「遅い」「保守できない」といった声が相次いでいます。
Power Appsへの移行で多くの企業がつまずく理由
「Power Appsにすれば全部置き換えられる」という誤解
確かに、Power AppsはMicrosoftが公式に推奨するフォーム移行先です。
しかし、InfoPathが持っていたXMLベースの柔軟構造や複雑な分岐・繰り返し構造は、Power Appsでは再現が極めて難しいのです。
InfoPathの代表的機能 | Power Appsでの対応 | 対応に必要な設計変更 |
|---|---|---|
繰り返しテーブル（子テーブル） | ギャラリー構成で再現可だが制御が複雑 | フォーム構成を全面的に変更 |
条件分岐ビュー（入力内容で画面切替） | 制御式で再現可能だが保守困難 | 数式・ロジックの複雑化 |
XMLデータ接続 | 非対応（JSON形式へ変換が必要） | データスキーマ再設計 |
複数データソース統合 | API経由で接続可だが応答遅延あり | 外部接続管理が煩雑 |
外部公開フォーム | M365認証制限により不可 | ゲストライセンス購入が必要 |
つまり、フォームをそのまま移すことが「移行」ではなく「再開発」になるのです。
Power Appsではなぜ限界があるのか
① InfoPathのデータ構造との“思想的ギャップ”
InfoPathはXML（階層構造）を前提に設計されていました。
一方、Power AppsはSharePointリスト（フラット構造）がベース。
階層的な繰り返しテーブルや条件依存ビューを作ると、構造が破綻します。
② 複雑な承認ロジックがPower Automateでは再現困難
Power Automateは単純な直列承認には向いていますが、条件分岐が多い業務フローには対応しきれません。
特に「複数条件＋並列承認＋差戻し」が絡むと、保守コストが跳ね上がります。
③ コストとライセンス構造の複雑化
Power Appsは「ユーザー単位＋実行数」で課金されるため、利用頻度が高いワークフローではTCOが予測不能になります。
InfoPath時代のように“無制限利用”ができず、結果的に使われなくなるフォームが増えるのです。
④ 外部アクセス・ゲスト連携の壁
M365環境では、外部の販売パートナーや協力会社がフォームを利用する場合、
「ゲストアカウント登録＋追加ライセンス」が必要。
InfoPathのように“社外公開フォーム”を簡単に作ることはできません。
アーキテクチャ比較：SharePoint Online 単独 vs PRMONE 連携
パターンA（単独）
- 長所：導入の手軽さ／社内コラボに近い体験
- 限界：大量ゲストの棚卸し・権限ドリフト・業務WFの表現力
パターンB（ハイブリッド）
- 長所：マルチテナント権限（パートナー毎に完全隔離）／業務ワークフロー／一元監査／安定した費用構造
- 留意：最初に“業務単位の設計”が必要（=運用は楽になる）
PRMONEで外部公開を“業務として”成立させる要点
①マルチテナント権限制御
- 代理店/顧客単位で“見える世界”を論理分離。誤閲覧を構造的に排除。
- 案件・契約・チケット単位のきめ細かいスコープをGUIで設定。
② 外部アカウントのライフサイクル管理
- 企業契約/窓口単位で一括招待・一括失効。失効期限や自動化ルールを組み合わせ、“残アカ”を作らない。
- IdPはSAML/OIDCで自社or相手先IdPに接続、あるいはPRMONE内IDで運用も可。
③ 業務ワークフローの表現力
- 申請→審査→差戻し→再申請→確定、並列レビューやSLA管理までGUIで定義。
- 条件分岐・アサインメントはルールテーブルで管理し、担当変更もデータ更新のみ。
④ 監査・証跡の一元化
- 認証・閲覧・承認の全イベントをプラットフォームで集約。監査部門にそのまま渡せる粒度。
⑤ M365との賢い連携
- 文書はSharePoint Onlineに正本保管、PRMONEからGraph APIで参照/書き込み。
- 「業務＝PRMONE」「保管＝M365」の役割分担で情報統制を維持。
コスト設計：スケール時に“読める”ことが正義
観点 | M365単独 | M365 × PRMONE |
|---|---|---|
アカウント | ゲスト招待が分散しやすい | パートナー単位に一元管理 |
運用 | 権限ドリフト是正が定常化 | 初期設計後は定常運用が軽い |
月次コスト | 利用増で変動が読みにくい | ユーザー/組織ベースで安定的 |
業務WF | Power Automateで分岐拡大 | PRMONEでルール管理 |
監査 | 分散ログを収集 | 統合ログで即提出可 |
【ポイント】
大量の外部ユーザーが増減するB2Bシナリオでは、「人数×操作」で膨らむコストより、構造で抑え込む発想が効く。
ガバナンス設計パターン（実装の型）
- ポリシー分離：社外向けは“別ドメイン/別レイヤー”で運用（PRMONE）、社内はM365で標準化。
- ゼロトラスト前提：最小権限＋短期トークン、相手先ドメイン単位でブロック/許可。
- ロール＆スコープ：役割（申請者/承認者/閲覧）×スコープ（代理店/案件/顧客）で権限をモデル化。
- 監査の自動化：入退場・アクセス・承認を自動レポート（月次/四半期）。
- ライフサイクル連携：契約更新／終了に連動して自動失効。相手先IdPと連携時はB2BでSSO。
事例イメージ（共通パターンの再現）
代理店見積・契約ポータル
- 代理店はPRMONEで案件登録→技術/法務の並列レビュー→承認完了で契約書をSPへ正本保管。
- 代理店組織の人事入替は企業単位のアカウント棚卸しで一括反映。
- 監査はPRMONEの統合ログをそのまま提出（誰が・何を・いつ承認/閲覧したか）。
フェアな立場からの提言（Power Apps Advanced パートナーとして）
当社は Microsoft 認定 Power Apps Advanced パートナー であり、Power Platformの導入・統制も数多く支援しています。
その経験から、次のように整理します。
- M365単独：社内中心／小規模な外部共有は迅速・低コスト。
- M365 × PRMONE：大規模B2B・高機密・厳格な業務プロセスではハイブリッドが安定。
- 意思決定の軸：ユーザー規模、業務WFの複雑さ、監査要求、コストの予見性。
どちらの選択肢もご相談ください。Power Apps/Power Automateでの実装も、PRMONEでの業務レイヤー設計も、要件に応じて最適案をご提案します。
（執筆者は Microsoft 365 元MVP。ベンダー都合ではなく“要件起点の設計”をお約束します）
まとめ：外部公開は“技術”ではなく“運用設計”の勝負
外部パートナーと“安全に早く回る”関係を築くには、アカウント・権限・業務・監査・コストを構造で制御すること。
M365標準で始め、スケールや要件の厳格化に合わせてPRMONEを業務レイヤーとして増設する——これが現実解です。
