Power Apps Code Appsで始める業務アプリ開発②：環境・体制・ライセンスを準備する

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

Power Apps Code Apps（以下、Code Apps）の第1回「開発方式を理解し、最初の業務を決める」では、開発方式の違いと、最初に作る備品管理アプリの範囲を整理しました。今回は、実装を始めるための環境・担当者・ライセンスを用意します。

社内アプリでは、開発者の端末だけで準備が完結するとは限りません。管理者への依頼と利用者の実行権利を先に整理しておくと、「作れたが他の社員が使えない」という問題を早く見つけられます。

備品管理の進め方と例は設計・導入の提案です。個別テナントで手順を実行した結果を示すものではありません。

1. 管理者と一緒に準備する

1.1 開発者だけでは準備できないものを整理する

Power Platformの「環境」は、アプリやデータなどを管理する単位です。この連載では、試作を行う開発環境と、別ユーザーでの操作や本番相当の条件を確認する検証環境を使います。データ源はMicrosoft Dataverse（以下、Dataverse）を想定しています。本番利用を始める際は、本番環境も分ける構成を推奨します。

管理者への依頼	依頼する理由	受け取る情報
組織アカウントと対象環境へのアクセス	正しい組織・環境で作成するため	アカウント、環境名・ID
Code Apps機能の有効化	アプリを発行・実行するため	有効化済みの確認
作成権限	初期化、接続、発行に必要	付与した権限
Dataverseとテーブル	試作のデータを保存するため	テーブルの論理名
テスト利用者とデータ権限	作成者以外の動作を確かめるため	編集者・閲覧者のアカウント
DLP・CSP・ネットワーク確認	接続やローカル実行を可能にするため	許可する接続先、制約

DLP（データ損失防止）はデータの扱いを制御するポリシー、CSP（Content Security Policy）はブラウザーでの読み込みや通信を制御する方針です。データ接続の可否と、開発中のアプリがブラウザーから接続できるかを、それぞれ確認します。

管理者は、Power Platform管理センターで「管理 → 環境 → 対象環境」を開き、「設定 → 製品 → 機能」からCode Appsを有効にします。画面の表示や権限は対象環境で確認してください。^[1]

1.2 試作段階で把握したい制約

2026年11月10日に確認した公式資料では、Power Apps for Windows、SharePointフォーム統合、Power Platform Git統合、セキュリティで保護された暗黙的な接続は未サポートです。^[1]

SharePointのリストへ接続することと、SharePointの標準フォームを置き換えることは別の要件です。また、Power Platform Git統合の制約があっても、ローカルのソースをGitで管理する作業は行います。対象端末、認証方式、社内ネットワークでの動作はPoC（概念実証のための小規模な試作）に含めてください。

オフライン、特殊なデバイス機能、厳密な閉域運用、SSR（サーバー側で画面のHTMLを生成する方式）が必須の場合は、適合性が未確認であることを企画メモに記録し、最初に検証します。

1.3 役割を決める

業務担当者は業務ルールと受入判断、開発者は実装とコード保守、Power Platform管理者は環境・共有・ライセンス、データ管理者は権限とデータ保護を担当します。同じ人が複数の役割を兼ねる場合も、作業の責任を明記してください。

次へ進む条件： 開発環境のID、テーブルの論理名、担当者、テスト利用者が揃い、利用する接続先が許可されていることを確認します。

2. ライセンスと予算を先に用意する

2.1 作る人と使う人の権利を分けて確認する

Power Apps Developer Plan（以下、Developer Plan）は、開発・テスト用の環境を無料で利用できるプランです。本番利用の代替にはなりません。Code Appsの公式資料では、利用者の実行条件として、Power Apps Premium（以下、Premium）、従量課金、アプリパス、自動請求によるPremium割当を挙げています。^[1][2]

作成者がPremiumを持っていることと、他の社員がアプリを使えることは別です。Microsoft 365の制限付きPower Apps利用権だけでCode Appsを利用できると予算を組まず、利用者ごとの実行権利を確認してください。

利用状況	最初に比較する選択肢	確認すること
個人で学習・試作	Developer Plan	非運用の範囲、組織アカウント
日常的に複数アプリを使う	Premium	購入数、利用者への割当
対象アプリを限定する	アプリパス／per app	購入条件、価格、環境への配分
月間利用者が少ない・変動する	従量課金	Azure課金設定と追加メーター

自動割当は、テナント内で利用可能なPremiumライセンスを利用者に割り当てる仕組みです。無料利用の方式として扱わないでください。アプリパスの日本円価格と自社での購入条件は未確認です。

Mermaid原図

2.2 人数とアプリ数を記録する

利用者一覧には、氏名またはグループ、既存の実行権利、追加購入の必要性、使うアプリ、月間利用の見込みを記入します。既存ライセンスを使える人と新規購入が必要な人を分けると、増分費用を計算できます。

2026年11月10日に確認したPremiumの日本向け公開価格は、税別2,998円／ユーザー／月相当、年払いです。この単価で100人分を追加購入する試算では、月相当299,800円、年額3,597,600円となります。同じユーザーが複数アプリを使っても、Premiumの基本料金をアプリ数で乗算しません。^[3]

従量課金の基本メーターは10米ドル／月間アクティブユーザー／アプリです。課金対象者20人が1アプリを使う例では月200ドルです。円のPremium料金と比較する際は、実契約における同じ通貨・税条件の単価を取得してください。^[5]

2.3 アプリ以外の費用も加える

費用	見積もるために集める情報
Dataverse容量	データ件数、添付、ログ、既存残容量
SQL・API等の接続先	契約、利用量、保守費
Azureバックエンド・監視	実行量、保存量、ログ量
自動化・AI	フローの用途、AI利用量、必要な権利
開発・保守	実装、試験、依存更新、問い合わせ担当

Premiumにはユーザーごとに250MBのデータベースと2GBのファイル容量の権利があり、テナント全体で合算して利用します。データベースの追加容量は、確認した日本向け公開価格では税別5,997円／GB／月相当、年払いです。ファイル・ログ容量の追加料金とは区別します。^[3][4]

調達担当者には、利用者数、利用アプリ数、月間利用見込み、既存ライセンス、必要容量を渡し、購入する製品・プラン（SKU）、適用条件、契約単価を確認してもらいます。Managed Environments（マネージド環境）、ゲスト、Dynamics 365付属権利などの条件も、該当する場合に確認してください。^[4]

次へ進む条件： 少なくとも試作の共有テストに参加する人について、実行権利と割当を確認します。本番費用は仮置きのまま試作を進めてもよいですが、未確認の費用を記録してください。

今回のまとめ

開発を始める前に、環境ID、データ源、管理者、共有テストの利用者を揃えます。費用は利用者の実行権利に加えて、容量、接続先、バックエンド、保守まで含めて見積もります。

用語メモ

用語	意味
Microsoft Entra ID	組織の認証などに使うID基盤
DLP	データの扱いを制御するポリシー
CSP	ブラウザーの読み込み・通信等を制御する方針
TCO（Total Cost of Ownership）	構築・利用・保守を含む総費用

参考資料

筆者が事前に行った調査（2026年10月6日時点）を基に構成しています。2026年11月10日に、以下の公式資料で環境の有効化、記載した制限、開発・テストと業務利用のライセンスの違い、掲載料金・容量・従量課金単位を確認しました。実際の契約・環境条件は、導入時に自社の契約と公式資料で確認してください。

1. Microsoft公式：Code Apps概要・要件・ライセンス・制約
2. Microsoft公式：Developer Plan
3. Microsoft公式：Power Apps日本向け価格
4. Microsoft公式：ライセンスFAQ
5. Microsoft公式：従量課金メーター