Power Apps Code Appsで始める業務アプリ開発④：共有・検証から本番運用へ進む

連載：Power Apps Code Appsで始める業務アプリ開発・第4回 ｜ 連載のまとめ

第3回「備品管理アプリを作ってみる」では、Power Apps Code Apps（以下、Code Apps）で備品管理アプリの画面とデータ接続を作る流れを説明しました。最終回では、試作アプリを別の社員と共有し、検証環境で本番運用を始める条件がそろっているかを確かめます。

ここで確認したいのは、業務機能に加えて、利用者の権限、環境ごとの接続、復旧、監視、費用です。小さなアプリでも、この一巡を経験しておくと、次のアプリを展開する際の共通手順が見えてきます。

以下は備品管理アプリを導入するための手順例です。共有テストや本番移行の結果は、実際に使うテナントで確認します。

1. 共有と利用者別の検証

Mermaid原図

各段階で課題を記録し、必須条件が未解決なら対処や範囲の見直しへ戻ります。

1.1 発行と共有を行う

変更後にnpm run buildとpa app pushを実行し、Power Appsの作成者ポータルで対象アプリの共有・詳細を確認します。試作用の利用者グループへ共有してください。^[6]

利用者ごとに、実行権利、環境へのアクセスとアプリの共有、データ源の権限と接続を確認します。アプリを共有した後、データを閲覧・更新できる範囲もデータ源側で確かめてください。

1.2 三つの立場で試す

テストする人	期待する結果
編集を許可された利用者	起動、閲覧、登録・更新ができる
閲覧専用の利用者	起動・閲覧はでき、更新はデータ源側で拒否される
共有対象外の利用者	アプリへのアクセスが許可されない

テストには、開発者と別のアカウントを使います。初回の接続同意、データ取得、更新、社内ネットワーク、対象端末を確認し、実際の結果を記録してください。

1.3 うまく動かない場合は層を分けて調べる

症状	最初に確認するところ
アプリを開けない	アカウント、テナント、実行権利、共有、環境アクセス
アプリは開くがデータが出ない	接続、同意、データ権限、データ損失防止（DLP）ポリシー、通信
登録・更新だけ失敗する	書込権限、必須項目、型、業務ルール
ローカル実行だけ失敗する	ブラウザープロファイル、Local Play、ローカル通信許可
社内端末だけ失敗する	プロキシ、ブラウザー設定、対象URLへの通信

上表は原因を切り分けるための確認順序であり、原因を断定するものではありません。時刻、アカウント、環境、操作、画面のメッセージをセットで残すと、担当者へ引き継ぎやすくなります。

次へ進む条件： 別ユーザーの実行結果と、権限不足時の拒否を確認し、未解決の課題に担当者を割り当てます。

2. 環境間の移送と本番移行の判断

2.1 ソリューションで移送する

ソリューションは、アプリなどの構成要素をまとめて環境間で移送する仕組みです。Code Appsをソリューションに含めるには、Microsoft Dataverse（以下、Dataverse）のある環境を使います。Dataverseがない環境では、ソリューションを指定せずにアプリを発行します。^[3]

開発環境で試作用ソリューションを用意します。プロジェクトのルートで次のコマンドを実行し、山括弧を含むプレースホルダー全体を対象ソリューションのID（GUID）に置き換えます。

npm run build
pa app push --solution-id <ソリューションGUID>

発行後、開発環境からソリューションをエクスポートし、検証環境へインポートします。接続参照は、コネクタの接続を指すソリューションの要素です。移送先で接続参照をその環境の接続に割り当て、設定、権限、共有を確認します。データの移行、資格情報、共有の準備もそれぞれ記録してください。^[3][4]

2.2 データ保護を確認する

公式資料によると、ビルド済みのアプリファイルは公開エンドポイントから配信され、配信元でのIPアドレスによる制限には対応していません。機密情報は、認証と認可を経てデータ源から取得する設計にします。^[1]

APIキー、DBパスワード、実顧客データをソースや配信ファイルへ含めないでください。ブラウザーへ配信する値は、ビルド時の変数に置いても秘密の保管先にはなりません。

コンテンツセキュリティポリシー（CSP）は環境単位の設定です。外部通信や埋め込みを許可する際は、同じ環境の他アプリへの影響も確認します。データポリシーの適用範囲を確認したうえで、JavaScriptの通信先も管理し、コードレビューで確認します。^[2]

2.3 本番移行のチェックリスト

• 対象機能と例外処理を業務責任者が確認した。
• 通常利用者と閲覧専用者の権限をデータ源側でも確認した。
• 本番相当件数・同時利用・対象端末で性能を確認した。
• 検証環境へ移送し、開発データ・接続を誤って参照していない。
• 利用者の実行権利、共有、データ権限を準備した。
• 監視と問い合わせ窓口、復旧方法を決めた。
• 費用見積と保守担当を業務責任者・管理者が確認した。
• 未確認事項を整理し、開始を妨げる項目が残っていない。

未解決の必須要件があれば、本番開始を保留し、対処または範囲の見直しを行います。標準化の前に一部署で限定導入し、運用負担と効果を確認してください。

3. 公開後の運用

3.1 監視と問い合わせ対応

起動状況はPower Platform Monitorで確認します。より細かな通信や操作のログが必要なら、Azure MonitorのApplication Insightsとの連携を検討します。Application Insightsが収集するのは、アプリが正常に読み込まれた後の情報です。初期化などの起動エラーはPower Platform Monitorで確認します。^[5]

最初に見る指標は、起動成功率、応答時間、API失敗、業務処理の完了です。業務データを誰が変更したかを追う監査は、データ源側の機能も設計します。監視ログに申請内容や個人情報を過剰に記録しない運用にしてください。

3.2 更新と復旧を管理する

ソースのコミット、ビルドに使った依存バージョン、発行したアプリの版を対応付けます。更新前に検証環境で確認し、問題が起きた場合に旧版を再展開する手順を残します。アプリの復旧とデータの復旧は分けて考え、必要なバックアップと復旧時間を決めてください。

3.3 費用と利用者を見直す

毎月の運用では、実利用人数、従量課金、容量、監視ログ量、自動割当を確認します。異動・退職に合わせて共有とデータ権限を更新し、必要に応じてライセンス割当も見直します。

確認のタイミング	主な作業
障害・問い合わせ時	起動、接続、権限、業務処理を切り分ける
リリース時	検証、版の記録、共有・接続、復旧方法を確認
定期点検時	費用、容量、利用者、依存ライブラリ、担当者を確認
対象業務の拡大時	アプリ数、接続先、権限、保守・予算を再評価

付録B. 試作の結果を残すシート

確認項目	合格の目安	結果・担当者・対応期限
基本機能	一覧・検索・登録・更新が業務に合う
別ユーザー実行	作成者以外が起動し操作できる
認可	許可されない更新がデータ源で拒否される
性能	合意した件数と同時利用で目標を満たす
移送	検証環境で接続先と権限が正しい
復旧	旧版・データの復旧方法が決まっている
費用	ライセンスと追加費用を説明できる
保守	別担当者がビルド・改修・発行できる

今回のまとめ

共有、データ権限、環境移送、監視、復旧、費用管理までを一巡すると、業務アプリを継続して運用するための準備が見えてきます。一部署での限定導入から始め、効果と保守負担を確かめながら広げていきましょう。

この連載は、開発者が全体像をつかむとき、管理者へ準備を依頼するとき、試作の本番化を相談するときの共通資料として使えます。第1回の企画メモと、この回の評価シートを合わせて使うと、最初の狙いと実際の結果を比較できます。

用語メモ

用語	意味
ALM（Application Lifecycle Management）	開発から展開・保守までのアプリケーションライフサイクル管理
接続参照	ソリューション内で接続を参照する要素

参考資料

筆者が2026年10月6日時点で行った調査を基に構成しています。11月11日に、発行と共有、ソリューションによる移送、接続参照、配信の制限、CSP、監視の仕様を以下の公式資料で確認しました。導入時は、自社の契約と環境で適用条件を確認してください。

1. Microsoft公式：Code Appsの配信とアクセス制限
2. Microsoft公式：CSP設定
3. Microsoft公式：Code AppsのALM
4. Microsoft公式：データ接続・生成サービス・接続参照
5. Microsoft公式：Application Insights設定
6. Microsoft公式：Code Appsクイックスタート