Power Apps Code Appsで始める業務アプリ開発①：開発方式を理解し、最初の業務を決める
連載：Power Apps Code Appsで始める業務アプリ開発・第1回 ｜ 連載のまとめ
Power Apps Code Apps（以下、Code Apps）に興味があっても、「普通のWebアプリ開発と何が違うのか」「最初に何を作ればよいのか」が分からないと、取り組みを始めにくいものです。
この連載では、備品管理アプリを題材に、開発方式の理解から環境・ライセンスの準備、実装、共有、本番運用までを全4回でたどります。今回はCode Appsの役割をつかみ、小さな試作の対象と完成条件を決めます。
備品管理の進め方と例は設計・導入の提案です。個別テナントで手順を実行した結果を示すものではありません。
1. Code Appsの開発方式を理解する
1.1 Power AppsとCode Appsの関係
Power Appsは、業務アプリの開発・実行に使うサービス、コネクタ、データ基盤を備えています。Code Appsはその中で、アプリの画面と操作をWebコードで作る方式です。ReactやVueなどを使い、Visual Studio Codeなどの統合開発環境（IDE）で開発したアプリをPower Platformへ発行します。Code Appsは2026年2月5日に一般提供が発表されました。[1][2][3]
開発中は、ソースを編集し、ローカルで動かし、データへの接続を加え、ビルドして発行する作業を繰り返します。発行後はPower Appsのホストからアプリを起動し、組織の認証・共有の仕組みを使って利用します。
「画面を自由に作る仕事」と「社内アプリとして利用できるようにする仕事」の両方が必要です。開発者が画面を完成させても、利用者のライセンス、アプリ共有、データ源の権限が揃うまで業務利用は始められません。
1.2 ほかのPower Appsの方式も一度比較する
独自の画面を必要とする理由を言葉にしてからCode Appsを選びましょう。以下は選択の目安です。
| 重視すること | 比較する方式 | 最初に確認する点 |
|---|---|---|
| 業務担当者による画面・数式の改修 | キャンバス アプリ | 標準コントロールで要件を満たせるか |
| Dataverse中心のデータ管理 | モデル駆動型アプリ | 標準フォーム・ビューで運用できるか |
| 独自UIとWeb開発資産の活用 | Code Apps | Webコードを継続保守できるか |
Code Appsは、Power Appsの画面に追加する部品を作るPower Apps component framework（以下、PCF）とは用途が異なります。アプリ全体をWebコードで構築する方式として扱います。[3][4]
1.3 基盤に任せること、自分たちで作ること
Code Appsはシングルページアプリケーション（SPA）に対応しています。SPAは、ブラウザー側のコードで画面や操作を組み立てるWebアプリです。データ源へのアクセスには、Power Appsクライアントライブラリ（以下、Power Apps SDK）と、接続先に合わせて生成されるデータ操作用のコードを使います。[3]
| 基盤を利用する領域 | 自分たちで設計・保守する領域 |
|---|---|
| Microsoft Entra IDによる認証とアプリの読み込み | 画面、入力チェック、状態管理 |
| アプリ発行・共有の仕組み | 利用者区分、データ権限、業務ルール |
| SDK、コネクタによるデータ接続 | 検索、更新、通信エラー、同時編集 |
| Power Platformの管理・監視との連携 | ソース、依存ライブラリ、問い合わせ対応 |
秘密情報を使う処理、重い処理、複数更新をまとめて確定する処理は、データ源や業務APIなどのバックエンドに置く設計を検討します。アプリ内のボタン表示だけで更新権限を制御せず、データ源側でも許可・拒否できるようにします。
ここまでの確認： Code Appsを試す理由を説明できること、コードを保守する担当者を決められること、バックエンドが必要な処理を区別できることを確認してください。
2. 最初に作る業務アプリを小さく決める
2.1 備品管理から始める
最初の試作は、備品の一覧、検索、詳細、登録、更新を扱うアプリとします。データを読む・書くという基本操作に加え、閲覧専用者と編集者の違いも確認できます。こうした小規模な試作を、PoC（Proof of Concept、概念実証）と呼びます。PoCの目的は、自社の業務・環境で利用できるかを確かめることです。
最初から承認、通知、添付、AI、複雑な帳票をすべて加えると、どこで問題が起きたかを判断しにくくなります。まず基本操作と権限を完成させ、次に必要な機能を追加してください。
2.2 企画メモを1枚にまとめる
| 項目 | 備品管理の記入例 | 自社で記入する内容 |
|---|---|---|
| 解決したいこと | Excelの備品台帳を複数人で管理しづらい | 現在の困りごと |
| 利用者 | 総務担当者、閲覧する社員 | 利用部署・人数 |
| 基本操作 | 一覧、検索、登録、更新 | 試作に含める操作 |
| データ源 | 開発用Dataverse | 正式なデータ源の候補 |
| 権限 | 総務は編集、社員は閲覧 | 誰が何をできるか |
| 完成条件 | 別ユーザーが正しい権限で操作できる | 判断できる条件 |
| 今回保留すること | 承認、添付、通知 | 次の段階に回す機能 |
| 責任者 | 業務責任者・開発担当・管理者 | 担当者名 |
2.3 完成条件を先に決める
試作の合格条件は「画面が動いた」だけにしません。作成者以外が起動できる、閲覧者の更新が拒否される、本番相当のデータ件数で検索できる、検証環境へ移せる、費用と保守担当を説明できる、という条件を用意してください。
性能目標は自社の業務に合わせて決めます。例えば検索の許容時間を決める際は、想定件数と同時利用人数もセットで記録します。目標値が決まっていない段階では、測定結果を保存して業務担当者と判断してください。
次へ進む条件： 業務責任者が対象機能と完成条件を確認し、開発者が最初に実装する範囲を説明できれば、環境の準備へ進みます。
付録A. 最初の打合せで使う記入シート
| 項目 | 記入欄 |
|---|---|
| アプリ名・対象業務 | |
| 困っていることと期待する効果 | |
| 今回作る機能／保留する機能 | |
| 利用者数・月間利用者数 | |
| データ源・想定件数・添付量 | |
| 閲覧者／編集者／管理者の区分 | |
| 開発・検証環境名とID | |
| 既存ライセンス／追加購入の候補 | |
| 業務責任者・開発者・管理者 | |
| 完成条件と確認日 | |
| 必須だが未確認の要件 |
今回のまとめ
Code Appsでは、Webコードで独自の画面を作り、Power Platformの認証・共有・データ接続を利用します。最初の取り組みでは、業務の範囲を絞り、利用者の権限と保守担当まで含めた完成条件を決めると、試作の目的が明確になります。
用語メモ
| 用語 | 意味 |
|---|---|
| SPA | ブラウザー側で画面と操作を組み立てるWebアプリ |
| SDK | 基盤機能を利用するライブラリ |
| PoC | 自社要件への適合を確認する小規模な試作 |
参考資料
筆者が事前に行った調査を基に構成し、機能・価格・ライセンスの基準日は2026年10月6日としています。2026年11月5日に、以下の公式資料で一般提供、開発方式、実行時の役割とPCFとの用途の違いを確認しました。実際の契約・環境条件は、導入時に自社の契約と公式資料で確認してください。
- Microsoft公式：Code Apps一般提供の発表
- Microsoft公式：Code Apps概要・要件・ライセンス・制約
- Microsoft公式：Code Appsアーキテクチャ
- Microsoft公式：Power Apps component framework