Power AppsのCanvas appを、GitHub Copilot CLIやClaude CodeなどのAIコード生成ツールから作成・編集できるプレビュー機能が公式ドキュメントで案内されました。結論から言うと、これはPower Apps Studioを置き換える機能ではなく、自然言語で要件を伝え、ローカルのAIツールが.pa.yamlやPower Fxを生成・検証し、Power Apps Studioの共同編集セッションへ同期する新しい作成支援です。2026年5月21日時点で確認したMicrosoft Learnでは、対象ページの最終更新日は2026年5月20日と表示されています。(Microsoft Learn)
管理者や開発者が最初に見るべきポイントは、プレビュー機能であること、Power Apps StudioのCoauthoringが前提になること、.NET SDK 10.0以降とAIコード生成ツールが必要なこと、そしてDLP・権限・ALMの確認を省略できないことです。特に本番アプリへ直接適用するのではなく、開発環境または検証環境で小さく試し、生成結果を人がレビューしてから展開する流れが現実的です。(Microsoft Learn)
Power PlatformのAI/Copilot更新で何が変わるのか、利用者と管理者向けに整理
今回の「Create and edit canvas apps with AI code generation tools」は、Power AppsのCanvas app開発に外部のAIコード生成ツールを組み合わせるプレビュー機能です。Microsoft Learnでは、GitHub Copilot CLIやClaude Codeなどを例に挙げ、自然言語で作りたいアプリや変更内容を伝えると、AIツールがCanvas app向けのスキルを使って画面、コントロール、Power Fx式を含む.pa.yamlファイルを生成し、Canvas app authoring MCP serverで検証し、Power Apps Studioのライブ共同編集セッションへ同期する流れが説明されています。(Microsoft Learn)
従来は、Power Apps Studio上で画面やコントロールを配置しながらアプリを作るのが中心でした。今回の更新により、開発者や技術寄りのMakerは、ローカルのIDEやAIツール上で要件を文章化し、生成された構成をPower Apps Studioへ反映するという開発スタイルを選べます。ただし、Power Apps Studioを閉じて単独で完結する仕組みではありません。Power Apps Studioを開き、Coauthoringを有効にしたアプリのセッションと連携する点が重要です。(Microsoft Learn)
| 観点 | 従来のPower Apps Studio中心の作成 | AIコード生成ツール連携後 |
|---|---|---|
| 作成方法 | 画面上でコントロールを配置し、プロパティやPower Fxを編集 | 自然言語で要件を伝え、AIツールが構成や式を生成 |
| 作業場所 | 主にPower Apps Studio | ローカルのAIツール、IDE、Power Apps Studioの共同編集セッション |
| 生成物 | Studio上のアプリ構成 | 画面、コントロール、Power Fxを定義する.pa.yaml |
| 検証 | MakerがStudio上で確認 | MCP serverを使ってYAMLを検証し、エラー修正を支援 |
| 向いている作業 | 手作業での画面調整、細かな確認 | 初期案の作成、既存画面の変更案、繰り返し修正 |
できることと、できないと考えるべきこと
このプレビューでできることは大きく3つです。新しいCanvas appを自然言語の要件から作ること、既存のCanvas appに対して変更内容を文章で伝えて編集すること、そしてローカルの開発環境で作業しながらPower Apps Studioの共同編集セッションと同期することです。Microsoft Learnでは、在庫管理、従業員オンボーディング、売上ダッシュボード、現地検査アプリなどの例が示されています。(Microsoft Learn)
一方で、「AIが作ったのでそのまま本番公開してよい」と考えるのは危険です。Microsoftはこの機能をプレビューとして位置付けており、プレビュー機能は本番用途を想定しない場合があり、機能制限や変更の可能性があります。さらにPower Platformのプレビュー条件では、プレビューが現状有姿で提供され、SLAや限定保証の対象外となる場合があることも示されています。(Microsoft)
実務では、次のように位置付けると失敗しにくくなります。
| 活用シーン | 適性 | 理由 |
|---|---|---|
| 新規アプリのプロトタイプ作成 | 高い | 画面構成やフォーム案を短時間で作り、Studioで確認できる |
| 既存アプリの軽微なUI変更 | 高い | 「一覧をカード型にする」「履歴画面を追加する」など自然言語で指示しやすい |
| DataverseやSharePointを使う業務アプリの下書き | 中程度 | データソース、列、権限、DLPの確認が必要 |
| 大規模な本番アプリの直接編集 | 低い | 変更範囲が見えにくく、プレビュー機能のリスクもある |
| 個人情報や規制対象データを含む検証 | 低い | プレビュー条件、AIツール側のデータ取扱い、社内ポリシー確認が必須 |
利用前に確認する前提条件
Microsoft Learnで示されている主な前提条件は、.NET SDK 10.0以降、GitHub Copilot CLIやClaude Codeなどのコード生成ツール、Power Platform環境、Canvas appを作成または編集できる権限、そしてPower Apps StudioでCoauthoringを有効にした状態です。Coauthoringは、Power Apps Studioでアプリを開き、Settings > Updatesから有効化する流れが案内されています。(Microsoft Learn)
管理者は、単にツールを入れられるかではなく、次の条件を確認してください。
| 確認項目 | 見るべきポイント |
|---|---|
| 環境 | 既定環境ではなく、開発・検証用の環境で試す |
| 権限 | Makerが対象環境でCanvas appを作成・編集できるか |
| Dataverse権限 | アプリがDataverseを使う場合、テーブルの読み取り・作成・更新権限があるか |
| Coauthoring | 対象アプリで有効化されているか |
| DLP | 使用予定のコネクタが業務データ、非業務データ、ブロック済みに適切に分類されているか |
| AIツール | 社内で利用が承認されているツールか、入力してよい情報の範囲が決まっているか |
| ALM | ソリューション、環境変数、接続参照、テスト環境への展開手順があるか |
Power PlatformのEnvironment Makerロールは、アプリ、接続、カスタムAPI、Power Automateフローなどのリソースを作成できます。ただし、Dataverseデータへのアクセス権限は別問題です。Environment Makerだからすべてのテーブルデータを扱える、という理解は誤りです。(Microsoft Learn)
セットアップの基本手順
AIコード生成ツールでCanvas appを扱うには、Canvas apps pluginを導入し、Canvas app authoring MCP serverを構成します。Microsoft Learnでは、Power Platform Skills marketplace pluginを追加し、Canvas apps pluginをインストールする手順が示されています。(Microsoft Learn)
/plugin marketplace add microsoft/power-platform-skills
/plugin install canvas-apps@power-platform-skillsプラグインを入れたら、MCP serverの接続を設定します。手順としては、Power Apps Studioで対象のCanvas appを開き、Coauthoringが有効であることを確認し、ブラウザーのPower Apps Studio URLをコピーします。その後、AIツールで/configure-canvas-mcpを実行し、Designer URLを渡します。ツールは環境ID、アプリID、クラスター情報を抽出して接続を構成します。(Microsoft Learn)
/configure-canvas-mcpMicrosoft Learnでは、Canvas apps pluginのスキルとして、新規作成用の/generate-canvas-app、既存アプリ編集用の/edit-canvas-app、MCP設定用の/configure-canvas-mcpが示されています。コマンド名や挙動はプレビュー中に変わる可能性があるため、導入時は利用中のプラグインのヘルプや公式リポジトリも確認してください。(Microsoft Learn)
新規Canvas appを作るときの実務フロー
新規アプリをAIコード生成ツールで作る場合は、最初から複雑な業務要件を詰め込まないことが重要です。まずは「一覧」「詳細」「入力フォーム」「保存」「検索」など、業務の最小単位で作ります。そのうえで、Power Apps Studioでプレビューし、Power Fx、データ接続、レスポンシブ表示、入力チェックを確認します。
実務で使いやすいプロンプトは、次のように条件を分けて書く形式です。
在庫管理用のCanvas appを作成してください。
目的:
倉庫担当者が在庫品目を検索し、詳細を確認し、棚卸数量を更新できるようにする。
対象ユーザー:
現場担当者。スマートフォンで利用する。
データソース:
DataverseのInventoryテーブルを想定。
主な列はItemName、SKU、Location、Quantity、LastCountedDate。
画面構成:
1. ホーム画面
2. 検索可能な在庫一覧画面
3. 在庫詳細画面
4. 棚卸数量の更新画面
要件:
- 一覧では品名とSKUで検索できる
- Quantityが0以下の場合は警告表示する
- 更新画面では数量を必須入力にする
- 保存後は詳細画面に戻る
確認したい点:
生成後にPower Fxのエラー、データソース参照、画面遷移を検証してください。ポイントは、アプリ名だけでなく、対象ユーザー、データソース、画面、操作、入力チェック、変更してよい範囲を書くことです。「いい感じの在庫管理アプリを作って」では、見た目は整っていても、業務で使えない画面になりやすくなります。
既存Canvas appを編集するときの注意点
既存アプリを編集する場合、AIツールは共同編集セッションから現在のアプリ状態を同期し、既存の画面やコントロールをローカルの.pa.yamlとして扱います。その後、変更内容を自然言語で伝えると、更新された.pa.yamlが生成・検証され、Power Apps Studioへ同期されます。(Microsoft Learn)
既存アプリでは、変更指示を広げすぎないことが大切です。たとえば次のように、対象画面、対象コントロール、期待する動作を明確にします。
既存の経費申請Canvas appを編集してください。
対象:
HomeScreenの申請一覧ギャラリー
変更内容:
- Statusが"Pending"の申請だけを表示するフィルターを追加
- 画面上部に「承認待ちのみ表示中」というテキストを追加
- 既存の詳細画面への遷移は変更しない
変更してはいけない範囲:
- データソース接続
- SubmitFormの処理
- ApprovalHistoryScreen「全体を使いやすくして」といった指示は、意図しない画面構成の変更や式の置き換えにつながります。特に本番で使っているアプリを検証環境にコピーして試す場合でも、保存前に差分を確認し、主要なユーザー操作を一通りテストしてください。
Coauthoringの制限を理解しておく
この機能の前提になるCoauthoringは、複数のMakerが同時にCanvas appを編集できる便利な機能です。ただし、万能ではありません。Microsoft Learnでは、複数編集時に検索、名前を付けて保存、別アプリを開く、元に戻す・やり直し、作成バージョンの切り替えなどが利用できないこと、最大共同編集者数が10であること、最初にアプリを開いたMakerのロケールにアプリ言語が固定されることなどが示されています。(Microsoft Learn)
AIコード生成ツールを接続する場合も、共同編集セッション上の変更として扱われます。人間のMakerが同時に作業していると、同じコントロールや画面に対する変更が競合する可能性があります。実務では「AI編集中は対象画面を他のMakerが触らない」「編集対象をチケットやコメントで明示する」「大きな変更前にアプリを保存・エクスポートする」といった運用ルールを作るべきです。
管理者が確認すべきDLPとコネクタ制御
AIツールはMCP serverを通じて、利用可能なコントロール、API、コネクタ、データソースを検出できます。だからこそ、Power Platform管理者はDLPポリシーを先に確認する必要があります。Power Platformのデータポリシーは、コネクタを業務データ、非業務データ、ブロック済みに分類し、組織データの意図しない公開リスクを下げるためのガードレールとして使われます。(Microsoft Learn)
DLPポリシーの影響は設計時だけではありません。Microsoft Learnでは、ポリシー違反のあるコネクタの組み合わせは、Power AppsやPower Automateの設計時・実行時の両方で影響を受けると説明されています。既存のアプリやフローも、後からDLPポリシーが変更されると影響を受ける可能性があります。(Microsoft Learn)
AIコード生成ツールを導入する前に、少なくとも次を確認してください。
| 管理項目 | 確認内容 |
|---|---|
| コネクタ分類 | SharePoint、Dataverse、SQL、HTTP、カスタムコネクタが適切なグループにあるか |
| ブロック対象 | 個人向けメール、SNS、未承認SaaSなどが必要に応じてブロックされているか |
| 検証環境 | 本番と同等のDLPで試すのか、検証用に緩めるのかを明確にする |
| エラー時の連絡先 | MakerがDLPエラーを見たときに相談できる窓口を用意する |
| 変更通知 | DLP変更により既存アプリが動かなくなる可能性を利用部門へ知らせる |
ALM・移行・展開で失敗しやすいポイント
AIコード生成ツールで作ったCanvas appも、Power PlatformのALMから外れるわけではありません。開発環境で作成し、テスト環境で検証し、本番環境へ展開する基本は同じです。Power Appsのソリューションは、アプリやコンポーネントを環境間で移動し、ALMを実装するための仕組みとして説明されています。(Microsoft Learn)
Canvas app単体のパッケージエクスポートは便利ですが、Dataverse依存、フロー、接続参照などを含む本格的なALMではソリューションを使うべきです。Microsoft Learnでも、Canvas apps packageはALMをサポートせず、Dataverseが利用できない場合の基本的なインポート・エクスポート用途に留める考え方が示されています。(Microsoft Learn)
また、環境ごとにSharePointサイト、リスト、SQL Server、データベース名などが変わる場合は、値をアプリ内にハードコードしないことが重要です。Power Platformの環境変数は、ソリューションを環境間で移動するときに、テーブル、接続、キーなどの外部参照を環境ごとに差し替えるために使えます。(Microsoft Learn)
展開時の現実的な流れは次のとおりです。
| フェーズ | 作業 | 注意点 |
|---|---|---|
| 開発 | AIツールでプロトタイプ作成、Studioで確認 | 本番データを使わない |
| レビュー | .pa.yaml、Power Fx、接続、画面遷移を確認 | 生成結果をそのまま信用しない |
| テスト | 検証環境へソリューション展開 | DLP、権限、環境変数を本番相当にする |
| 受入 | 業務担当者が操作確認 | 例外ケース、入力ミス、権限差を確認 |
| 本番 | 管理ソリューションとして展開 | 変更履歴とロールバック手順を残す |
セキュリティ面で見落としやすいこと
Canvas Apps PluginのGitHub READMEでは、資格情報は公式のAzure Identity SDKを通じて安全に扱われ、トークンを直接保存・管理しないと説明されています。一方で、MCPは新しく発展中の標準であり、MCP server、ホスト、クライアント、エージェント、AIアプリ、モデルを含む統合システム全体のセキュリティを確認する必要があるとも述べられています。(aka.ms)
管理者は、AIツールの利用可否だけでなく、次のような運用ルールを決めておくと安全です。
- プロンプトに入力してよい情報と入力してはいけない情報を明文化する
- 個人情報、顧客情報、契約情報、未公開の財務情報を検証プロンプトに含めない
- 社内承認済みのAIツールだけを使う
- MCP serverを接続できる環境を開発・検証環境に限定する
- 生成されたPower Fxやコネクタ追加をレビュー対象にする
- AIが追加したデータソースやAPI呼び出しをDLP・監査の観点で確認する
特に「AIが自動で検証した」という表現を、セキュリティレビュー完了と混同しないでください。MCP serverによる検証は、Canvas appとして成立するかを確認する助けにはなりますが、社内のアクセス制御、データ分類、監査要件、業務リスクまで自動で保証するものではありません。
トラブルが起きたときの確認ポイント
変更がPower Apps Studioに反映されない場合は、まずMCP serverとの接続を疑います。Microsoft Learnでは、AIツールに利用可能なコントロールを一覧表示させて接続を確認すること、Coauthoringが有効か確認すること、/configure-canvas-mcpを再実行して環境IDやアプリIDが正しいか確認することが案内されています。(Microsoft Learn)
MCP serverが応答しない場合は、ターミナルでdotnet --versionを実行し、.NET SDK 10.0以降が入っているか確認します。あわせて、Power Apps Studioのセッションが有効なままか、Coauthoringが有効か、新しいDesigner URLで再設定する必要がないかを確認してください。(Microsoft Learn)
変更によってアプリが壊れた場合は、AIツールに直近の安定版へ戻すよう依頼する方法も示されています。ただし、実務ではAI任せにせず、変更前のソリューション、エクスポート、バージョン履歴、スクリーンショット、テスト結果を残しておくことが重要です。(Microsoft Learn)
開発者向けのプロンプト設計のコツ
AIコード生成ツールでCanvas appを作るときは、プロンプトを「依頼文」ではなく「設計メモ」として書くと精度が上がります。特に、データソース名、列名、画面名、変更禁止範囲を具体的に書くと、後でレビューしやすくなります。
避けたい指示は次のようなものです。
営業管理アプリをいい感じに作って。この指示では、対象ユーザー、データ、画面、権限、操作、入力チェックが不明です。結果として、見た目だけ整った汎用アプリになりやすくなります。
実務向けには、次の形式が使いやすいです。
目的:
誰が、何の業務で、どの成果を得るためのアプリか。
対象ユーザー:
利用者の役割、利用端末、利用頻度。
データソース:
Dataverse、SharePoint、SQLなど。テーブル名、リスト名、主要列。
画面構成:
必要な画面名と各画面の役割。
操作:
検索、登録、更新、削除、承認、添付、通知など。
入力チェック:
必須、形式、上限値、重複チェック、エラー表示。
変更してよい範囲:
新規作成なのか、既存画面の一部変更なのか。
変更してはいけない範囲:
既存の接続、フロー、画面、フォーム、Power Fx式など。AIツールに任せる部分と、人が判断する部分を分けることも重要です。画面案や初期Power Fxの生成はAIに向いています。一方で、業務ルール、権限設計、例外処理、データ保護、公開判断は人が責任を持つべき領域です。
管理者と開発者が今すぐやるべきこと
まず管理者は、プレビュー機能を本番利用の前提で解禁するのではなく、検証用のPower Platform環境を用意し、Coauthoring、DLP、Maker権限、AIツールの利用ルールを確認してください。特に、外部AIツールに入力してよい情報の範囲を決めていない組織では、技術検証より先にガバナンスの線引きが必要です。
開発者やMakerは、小さなCanvas appから試すのが安全です。在庫一覧、経費申請、問い合わせ受付、点検記録など、画面数が少なく、データソースが明確で、テストしやすいアプリを選びましょう。生成後は必ずPower Apps Studioで動作確認し、Power Fx、接続、入力チェック、画面遷移、レスポンシブ表示を確認します。
今回の更新は、Power Apps開発を「画面上で作る」だけでなく「要件を文章化し、AIと共同で構成を作る」方向へ広げるものです。ただし、プレビュー機能である以上、成功の鍵は導入スピードではなく、検証環境、権限、DLP、ALM、レビュー体制を整えてから使うことです。まずは1つの小さな業務アプリで試し、生成結果の品質、管理者レビューの負荷、既存の展開プロセスとの相性を確認してください。
コメント