Microsoft Power Apps

解決する課題

• 紙やスプレッドシートで回している業務を、専任の開発者を確保せずにアプリ化したい
• 情シスへの開発依頼が滞留し、現場主導で小さな業務アプリを素早く作りたい
• 入力・承認・一覧表示といった定型的な業務アプリを毎回ゼロから実装するのが非効率
• 既存の Microsoft 365 や各種クラウドサービスのデータとつないだ画面を手早く用意したい

これらを、ドラッグ＆ドロップの画面設計と Excel 風の数式によるローコード開発で解決します。現場の担当者（市民開発者）でもアプリを組み立てられ、専門のコーディングを最小限に抑えられます。

主要概念と用語

• キャンバスアプリ: 白紙のキャンバスに画面とコントロールを自由に配置して作る方式。UI を細かく作り込みたいときに向く
• モデル駆動型アプリ: データモデル（テーブル・リレーション）を起点に、フォームやビューが自動生成される方式。業務プロセス中心の規模が大きいアプリに向く
• Dataverse: Power Platform 標準のデータストア。テーブル・リレーション・権限・ビジネスルールを持つマネージドなデータ基盤
• コネクタ: 外部サービスやデータ源への接続部品。Microsoft 365、SQL、SharePoint などの標準コネクタと、追加ライセンスが要るプレミアムコネクタがある
• 数式（Power Fx）: Excel に似た関数ベースの式言語。コントロールの動作やデータ操作を宣言的に記述する
• 環境（Environment）: アプリ・データ・フローをまとめる入れ物。開発/検証/本番などの単位で分離する
• コントロール: ボタン・入力欄・ギャラリーなど、画面に置く UI 部品
• Power Automate 連携: 承認や通知などのワークフローを、アプリから呼び出して自動化する仕組み

仕様・制限・クォータ

代表的な考え方です（具体値は変動するため定性的に示します）。

• 2つのアプリ方式: 自由レイアウトのキャンバスアプリと、データ起点で自動生成されるモデル駆動型アプリを用途で使い分ける
• 作成手段: ブラウザの Studio（デザイナー）で作成し、Power Apps モバイルアプリやブラウザから実行する
• コネクタの種別: 標準コネクタは基本ライセンスで使えるが、プレミアムコネクタ（SQL や Dataverse 以外の一部）や Dataverse 利用には上位ライセンスが必要になる場合がある
• データ量と委任（デリゲーション）: 大きなデータ源に対する一部の関数はサーバー側に委任できず、取得件数に上限がかかる。委任可能な書き方が推奨される
• 環境の分離: 開発・本番を環境で分け、ソリューションとして移送する運用が前提
• 対象範囲: 大規模・高トラフィックな汎用 SaaS よりも、部門内・業務特化のアプリに向く

内部の仕組み

Power Apps はブラウザ上のデザイナーで作ったアプリ定義を保存し、実行時はクライアント（ブラウザ／モバイルアプリ）がその定義を解釈して画面を描画します。データ操作はコネクタ経由で各データ源の API を呼び出し、結果を画面のコントロールにバインドします。

Excel 風の数式言語 Power Fx が中心で、コントロールのプロパティに式を書くと、参照先の変化に応じて自動で再計算されます。命令的なコードを並べるのではなく、宣言的に振る舞いを定義するのが基本です。

• Dataverse を使う場合、テーブル定義・リレーション・行レベルの権限・ビジネスルールがプラットフォーム側で管理される
• 委任では、可能な処理をデータ源側（サーバー）に肩代わりさせ、クライアントに全件を持ってこないように最適化する
• Power Automate と連携し、ボタン操作を起点に承認・通知・他システム連携などのフローを実行できる

設計パターン / ベストプラクティス

• 方式を正しく選ぶ。UI を作り込みたいならキャンバス、業務プロセスとデータ中心ならモデル駆動型を選ぶ
• 委任可能な書き方を徹底し、大きなデータ源でも先頭数百件で打ち切られないようフィルタ・検索を組む
• 環境を分離し、開発で作って検証を経て本番へ、ソリューションとして移送するライフサイクルを敷く
• 共通ロジックは部品化する。コンポーネントや子フローにまとめ、画面ごとの重複を避ける
• 接続情報を式に直書きしない。シークレットや接続は環境変数・接続参照で管理する
• データ源は Dataverse か既存基盤に寄せる。スプレッドシートを正本にせず、権限とスキーマを持つ基盤に集約する

運用・監視

• 環境ごとに管理し、管理センターでアプリ・コネクタ・ユーザー割り当てを把握する
• **アプリの分析（利用状況）**で、利用ユーザー数やエラー発生を確認し、放置されたアプリを棚卸しする
• ソリューションで移送し、手作業のコピーではなくパッケージ単位で開発から本番へ反映する
• DLP ポリシーで、業務データと外部サービスの不用意な組み合わせを環境横断で制御する
• 市民開発が広がるほど野良アプリ化を防ぐガバナンス（命名・所有者・棚卸し）を仕組み化する

コスト

• ライセンスは主にユーザー単位で、利用範囲によって体系が分かれる
  • Microsoft 365 に含まれる範囲では標準コネクタ中心の基本的な利用ができる
  • プレミアムコネクタや Dataverse を使う場合は上位ライセンスが必要になることが多い
  • 単一アプリ向けと、複数アプリを使える包括プランなどプラン体系が複数ある
• Dataverse を使う場合はストレージ容量も費用要因になる
• 具体的な単価やプラン内容は変動するため、公式の料金ページで最新値を確認する

セキュリティ

• アクセスは Microsoft Entra ID の認証を基盤に制御し、アプリ・データへのアクセス権を割り当てる
• Dataverse の権限で、テーブルや行レベルのアクセスをロールベースに細かく制御する
• DLP（データ損失防止）ポリシーで、業務コネクタと外部コネクタの組み合わせを制限し、データの不用意な持ち出しを防ぐ
• 接続やシークレットを式に直書きしない。接続参照・環境変数で管理し、移送時も安全に扱う
• 共有範囲を最小限にし、不要に広い共有や所有者不明のアプリを残さない

関連サービス・比較

ローコードで業務を回す Power Platform の中での Power Apps の位置づけを整理します。Power Apps が「画面・アプリ」を担うのに対し、Power Automate は「ワークフロー自動化」を担います。

Power Platform 内では、データ基盤の Dataverse、ワークフローの Power Automate、分析の Power BI が隣接し、Power Apps はこれらと組み合わせて使われます。他クラウドでは Google の AppSheet がローコードのアプリ作成基盤として近い立ち位置にあります。

ハンズオン / CLI例

Power Apps 自体の作成はブラウザのデザイナーが中心ですが、環境やアプリの管理は Power Platform CLI（pac）で行えます。az CLI では、データ基盤として連携する周辺リソースを準備できます。

# リソースグループを作成
az group create --name demo-rg --location japaneast

# Power Apps から接続するデータ源として Azure SQL サーバーを作成
az sql server create \
  --name demo-sql-0628 \
  --resource-group demo-rg \
  --location japaneast \
  --admin-user appsadmin \
  --admin-password "<強力なパスワード>"

# データベースを作成（業務アプリの正本データを格納する）
az sql db create \
  --name demo-db \
  --server demo-sql-0628 \
  --resource-group demo-rg \
  --service-objective S0

# Power Apps サービスからの接続を許可するファイアウォール規則を設定
az sql server firewall-rule create \
  --name allow-azure-services \
  --server demo-sql-0628 \
  --resource-group demo-rg \
  --start-ip-address 0.0.0.0 \
  --end-ip-address 0.0.0.0