はじめに

2025 年 5 月に開催された Microsoft Build で紹介された、Power Apps の衝撃的新機能である Generative pages を触れるようになったため、試してみました。その上で、私の考えを整理したいと思います。

※Generative pages の p について、大文字で記載されているケースもありますが、上記サイトでは、小文字になっているため、こちらの記事も小文字にしています

Generative pages とは

自然言語、つまりチャットベースで作りたいアプリを指示すると、自動でアプリを作ってくれます。
以下は備品の予約をするアプリを作成している例です。

そして今までの Power Apps と異なるのは、React コードベースで作成されている点です。上記について、コードを見ると以下のようになっています。

これを見ると、それってローコード/ノーコードなの？Power Platformってローコード/ノーコードベースじゃないの？と思う方がいると思います。

この辺色んな解釈があると思いますが、とりあえず、Generative pages とは、上記のような方法でアプリを作れる新しい機能です。

なぜこのような新機能が出てきたのか

なぜこのような新機能が出てきたのか、私の見解を整理します。まず、Power Apps の強みは、ローコード/ノーコードでアプリを作れることです。これにより、プロの開発者ではなくても、また、IT 部門ではない方でもアプリを作ることができます。もちろん、それなりの学習は必要ですが、私自身、IT 部門ではない沢山の方がアプリを作成して自らの業務を効率化してきた事例を見てきましたし、その支援をしてきました。

そのような強みを踏まえ、「IT 部門ではない現場の部門の人が、自らアプリを作成して業務を効率化しました」、「たった●●の期間でアプリを作成しました」といった表現で Power Apps の強みが語られることも少なからずあった認識です。

しかし、皆さんご存じの通り、生成 AI が出てきて以降、自然言語で、つまりチャットや場合によっては音声ベースで指示を出すことで一気にアプリを作成できるようになってきており、アプリ作成のハードルが更に下がってきております。

もちろん、Power Apps についても、Copilot という機能で生成 AI を活用することで、アプリ作成のハードルは更に下がってきております。以下は以前書いた記事です。

しかし、Power Apps は Power Fx（Power Apps などで利用される言語）やコントロールをベースとしていることもあり、一般的なプログラミング言語と比べると、実現できることの幅や生成 AI による学習の進度という観点で、「生成 AI がアプリを自動生成する」というシナリオには、一定の限界があると考えられます。

そのため、Power Apps の強みを活かしつつ、React ベースのコードでアプリを構築するという、より生産性を高める大胆なアプローチが採られたのではないかと推察されます。個人的に、もしかするとキャンバスアプリの需要を食ってしまう可能性もあり、そういった意味でも、マイクロソフトは思い切った決断をしたと感じています。

Power Apps キャンバスアプリとの違い

Power Apps には多くの強みがありますが、たとえば以下のような点が挙げられます。今回の新機能は、以下の①②の強みを維持しつつ、React コードの利点を取り込む形で進化していると考えられます。

① 作成されたアプリは、特別な設定をしなくても Microsoft の認証・認可基盤（Entra ID）を利用できる
② Power Platform 専用のデータベースである Microsoft Dataverse をシームレスに利用できる
③ 多数のクラウドサービスと、コネクタを介して簡単に連携できるアプリを構築可能

そちらを踏まえつつ、検証をしていきたいと思います。

検証

では早速、いくつかのケースで検証をしてみます。なお、Generative pages は、記事執筆時点で、米国環境のみで利用できます。

また、作成自体は、モデル駆動型アプリから作成できます。

検証① 備品予約アプリ

キャンバスアプリでよく相談をいただく、備品の予約をするアプリを作ってみます。また、その際、カレンダー形式で既存の予約を表示するようにしたいと思います。短い文章だと上手く作成できなかったため、結構プロンプトの修正をしたり、イメージ図を入れたりするなど、やや試行錯誤する必要がありましたが、最終的には以下のようにカレンダー形式で既存の予約を表示し、既に予約がある場合は予約できないようなアプリを作れました。

また、試してみた感じだと、個人的に、テーブルの構造や列の名前などについてもプロンプトに含めてあげるとよりいい感じに作ってくれる気がします。

キャンバスアプリだと、標準でカレンダー形式のビューはないため、ギャラリーを使って工夫をして作成する必要があり、初学者の方からすると難易度高いのですが、あっという間に出来てしまいました。これは凄いですね。

検証② 注文アプリ (一括登録)

次に、注文アプリを作ってみました。その際、一括登録できるような機能を持たせるようにしました。こちらもイメージ図やテーブル構造もしっかり伝えることで、最終的に、データ送信を行うと、複数の商品を一括で注文できるアプリを作れました。

登録されたデータ。Order テーブルと Order Item テーブルが紐づけられた形で登録されている。

個人的に、Power Pages では、Dataverse に対して一括でデータを登録する標準機能がない認識のため、こちらの技術が Power Pages でも利用できるようになったら非常に嬉しいです。

検証③ ステータス管理 (ドラッグ＆ドロップ)

上の二つは、キャンバスアプリでも実現できるアプリですが、次に、キャンバスアプリの標準機能では実現が難しい、ドラッグ＆ドロップでアイテムを移動して更新を行うようなアプリを作ってみます。

以下は、案件をステータスごとに表示して、ドラッグ＆ドロップでアイテムを移動してデータを更新するアプリです。このようなアプリを作ることができます。

なお、こちらの場合、イメージ図を付けると上手くいかなかったため、一旦、テーブル構造を基に指示文を書き、その後、色やボードの幅を修正するよう指示を出していきました。

通常の Power Apps との違い、苦手なこと

このように、従来から Power Apps キャンバスアプリの標準機能でできたことやできなかったことも、プロンプトベースで実現できるようになっています。

しかし、もちろん、現状はキャンバスアプリの標準機能でできたことのうち、Generative pages ではできないこともあります。

それは、上述もしたコネクタとの連携です。そのため、例えば、キャンバスアプリで Office 365 ユーザーコネクタを使って、アプリの利用者のプロフィール情報を自動で取得して、入力フォームに既定値として自動で設定するようなことは出来ません。

入力フォームアプリは作成できたが、アプリ利用者の名前やメールアドレスが既定値として自動で入らない。

そのため、作成したいアプリの要件として、コネクタを使って実装する場合は、現状は、引き続きキャンバスアプリで作成するのが良いと思います。

なお、Generative pages でも、Graph API を直接利用するアプリも作れるとは思いますが、この際は、Entra ID へのアプリ登録、アプリ ID やシークレットをアプリ内に埋め込む必要があることから、市民開発者ごとにこれらの情報を共有してアプリを作成させることはセキュリティの観点から現実的ではないと考えます。

組織展開、運用について

プレビュー機能として出てきた段階でこのクオリティのため、今後の期待値は非常に高いと思いますし、組織で利用したいというニーズも高まると考えます。そのため、展開や運用面について少し考えてみます。

まず、大前提として、現状モデル駆動型アプリのページとして追加できるため、Power Apps の有償ライセンスが必要です。

もちろん、リリースまで見据えると、作成者は、Dataverse、モデル駆動型アプリ、環境、セキュリティロール周りの知識も必要になるため、これまで SharePoint リストベースでアプリを作成していた方からすると、前提として学習することはそれなりにある認識です。

また、作成されたアプリは React コードベースで作成されているため、作成されたコードが正しいか判断することが難しいと思います。現状コード自体 read-only になっているものの、こちらは恐らく直接編集できるようになると考えますが、市民開発者にとって、直接修正することはハードルが高いと思いますし、コードをベースにした相談コストも高くなると考えます。

また、現状ではコードの修正もチャット経由で依頼する形になるため、リリース後に軽微な修正を行いたい場合でも、元々正常に動作していた機能のコードまで変更されてしまい、意図しない影響が出るのではないか、という不安があるかもしれません。

一方、従来のキャンバスアプリであれば、特定の個所のコードだけを直接編集する形になるため、他の部分に影響を与える心配は少なく、安心して部分的な修正を行うことができます。

そもそもコード自体の理解がなくてもアプリを作成できることは魅力のため、その前提でアプリを作成してリリースしても良いと決断するのであれば、「どのようなテストを経ればリリース可とするか」、「どのような業務であればこちらの機能を使用してリリース可とするか」などは決めておいた方が良いと考えます。

以下は展開方針の例です。

① IT 部門や DX 部門が機能の評価をして、組織の展開方針やルールを決める
　例) リリースする際は上司および IT 部門や DX 部門の承認を得る、原則として間接的な業務を効率化するアプリであればリリース可
② 申請制で評価を受け付ける ※マネージド環境を利用して共有範囲を制限する
③ リリースしたい場合は、上司の承認を得た上で申請をして承認を得たら本番用の環境を作成してそちらにアプリを移す

※Power Apps Premium のライセンスがある前提です

まとめ

今回は、Power Apps の衝撃的新機能 Generative pages を触ってみて、どんなことができるか整理しました。また、最後には、組織展開や運用面についても、私の考えを少し整理しました。

もちろん、これから機能は更に進化するでしょうし、上記私が試した以外のことも全然作れると思いますので、皆さんも色々触っていただき共有いただけると嬉しいです。