記事公開日
【Power Platform × AI】Microsoft公式プラグインをコーディングエージェントに導入して、キャンバスアプリとフローを自然言語で作ってみた
この記事のポイント
Power Apps Studioの画面を操作せずに、キャンバスアプリとPower Automateのフローを日本語の指示だけで作れるのかを検証しました。使用したのは、Microsoftが公式ドキュメントで案内している方法（コーディングエージェントにMicrosoft公式のcanvas-apps／power-automateプラグインを導入する構成。今回はClaude Codeを使用）です（2026年9月時点）。
- 日本語の指示だけでアプリもフローも作れた：
キャンバスアプリは約40分で3画面が生成され、Power Automateの承認フローも骨組みからTeams通知の追加まで会話で完結しました。日本リージョンの環境でも問題なく動作しています。 - 報告と実物のズレが起きにくい：
MCPサーバーが生成物を実際にコンパイルするため、Claude Codeは失敗を自分で検知して修正していました。今回の検証では、最終報告の内容と実機の画面は一致していました。 - ただし前提の導入作業は初心者向けではない：
.NET SDK・Azure CLI・Node.jsの導入とコマンド操作が必要で、スラッシュコマンドがClaude Codeの拡張機能パネルでは使えないなど、いくつかつまずきどころがありました。
こんにちは！DXソリューション営業本部の近藤です。
Microsoftは公式ドキュメントで、コーディングエージェントにPower Platform向けの公式プラグインを導入し、MCPサーバー経由でキャンバスアプリを作る方法を案内しています。
今回はこの方法を実際に導入し、経費申請アプリを日本語の指示だけで作れるのか、さらにPower Automateのフローまで作れるのかを検証してみました。
コーディングエージェントとして、今回はClaude Codeを使用しています。
目次
Microsoft公式プラグインでキャンバスアプリを作る仕組み
今回使うのは、Microsoft公式ドキュメント「AI コード生成ツールを使用してキャンバス アプリを作成および編集する」で案内されている方法です。
自然言語で依頼すると、コーディングエージェントがキャンバスアプリのソースである.pa.yamlを生成し、MCPサーバー（コーディングエージェントと外部ツールをつなぐ仕組み）がコンパイル検証を行い、共同編集セッション経由でPower Apps Studioにリアルタイムで反映される、という流れになっています。
この流れの中で特に重要なのが、MCPサーバーによるコンパイル検証です。
コンパイル検証があることで何が変わるのか：
MCPサーバーはローカルで動作し、生成された.pa.yamlを実際にコンパイルします。
そのため、コーディングエージェントはコンパイルが通るまで自分で修正を繰り返すことになり、エラーを残したまま「完成しました」と報告されることが起きにくくなります。
必要になるのは次の2つです。
Visual Studio Codeは必須ではありませんが、筆者はVisual Studio Code上のClaude Code拡張機能とターミナルを併用しました。
| 必要なもの | 補足 |
|---|---|
| .NET SDK 10.0 以降 | MCPサーバーがdotnetコマンドとして動作します。dotnet-installスクリプトを使えば、管理者権限なしでユーザー単位にインストールできます |
| コーディングエージェント | MCPサーバーとプラグインに対応していることが条件です。公式ドキュメントではGitHub Copilot・Claude Codeなどが例示されています（Claude Codeは有料プランが必要です） |
導入手順とつまずいた3つのポイント
導入自体は2行のコマンドで完了します。
ただし、実際に動かせるようになるまでに3か所つまずきました。
つまずき1：スラッシュコマンドはClaude Codeの拡張機能パネルでは使えない
Claude Codeの拡張機能パネル（Visual Studio Code上）から/pluginを実行したところ、「/plugin isn't available in this environment.」と表示されて先に進めませんでした。
解決策はシンプルで、ターミナルから起動し直すことでした。
ターミナル上で実行すると、マーケットプレイスの追加もプラグインの導入も問題なく通ります。
なお、導入さえ済んでしまえば、その後のスキル実行（/configure-canvas-mcpなど）は拡張機能パネルからでも動作しました。
つまずくのは最初の導入時だけです。
つまずき2：組織の管理設定に関する警告が出る
初回起動時にログやメトリクスの送信先設定について承認を求められました。
また、権限ルールの一部がツール側の想定と合っていないという警告も表示されましたが、いずれも動作には影響ありませんでした。
社内のセキュリティポリシーによっては確認が必要になる部分なので、事前に情報システム部門へ相談しておくと安心です。
つまずき3：Power Apps側で「コオーサリング」をオンにする必要がある
コオーサリング（共同編集）は、複数のユーザーが同じアプリを同時に編集できるようにする機能です。
今回の構成では、MCPサーバーがこの共同編集セッションを通じてPower Apps Studioへ変更を反映するため、あらかじめオンにしておく必要があります。
対象アプリを開き、設定 → 更新 → 新規タブから「コオーサリング」をオンにします。
ここで迷いやすいのが名称です。
公式ドキュメントでは「共同編集」と説明されていますが、日本語UIの設定画面では「コオーサリング」という表記になっています。
なお、あらかじめ保存済みのキャンバスアプリが必要で、ゼロの状態からは接続できません。
また、オンにすると「元に戻す」「名前を付けて保存」「検索」が使用できなくなる点にもご注意ください。
準備ができたら、Claude Code側で接続用のスキルを実行します。
すると、Power Apps StudioのURLを貼り付けるよう案内され、あわせて接続前の確認事項（コオーサリングを有効にすること、ブラウザタブを開いたままにすること）も提示されました。
URLを貼り付けると、環境ID・アプリID・環境カテゴリが自動で抽出され、接続が完了しました。
IDを自分で調べる必要がないのは助かります。
アプリを自然言語で生成してみた
準備が整ったので、さっそく依頼してみます。
投入したプロンプトは次の1文だけです。
完成までにかかった時間は約40分でした。
その間の動きに特徴があったので、順に紹介します。
実装前に「計画」を提示して承認を求めてきた
いきなり作り始めるのではなく、まず計画書が提示され、「この計画で進めてよろしいですか？」という確認で止まりました。
3画面構成（申請一覧・申請フォーム・承認キュー）について、各画面のファイル名・目的・使用コントロールが表で整理されています。
配色も「Ink Ledger」（濃紺の会計台帳）というコンセプト名とRGBA値付きで指定されていました。
作り始める前に方向性をすり合わせられるので、手戻りが起きにくい進め方だと感じます。
コンパイル失敗を自分で検知して修正した
実装が始まると、Claude Codeはプラグインに同梱された設計ガイドを順に読み込み、生成したYAMLのコンパイル検証を行っていきました。
検証が「Validation FAILED」となった際は、自分でコントロールの正しい定義を取得し直して修正しています。
最終報告では、修正した内容が8項目にわたって開示されました。
「ModernTextInputの現在値は.Valueではなく.Text」など、かなり具体的です。
あわせて、接続済みのデータソースが0件だったため、データはアプリを閉じると初期状態に戻るという制約も明示されました。
生成されたアプリの実物
実際にPower Apps Studioで確認すると、報告どおりの画面ができていました。
ナビゲーション行、合計金額・総件数・承認待ち件数のKPIカード、申請者検索ボックス、状態フィルター（すべて／申請中／承認済／却下）が並び、各行には申請者名・日付・用途・金額・状態バッジ・編集／削除ボタンが配置されています。
配色も計画どおりの「Ink Ledger」でした。
一覧を見ただけで、誰が・いつ・何に・いくら・どの状態かが分かる作りになっています。
できたアプリを会話で修正してみた
続いて、できあがったアプリを会話で修正できるかを試してみます。
次のように依頼しました。
途中で発生した不具合も自力で解決した
作業の途中で、同期処理が「対象ディレクトリに.pa.yaml以外のファイルが含まれている」というエラーを返しました。
原因は、Claude Code自身が生成した設計書（.mdファイル）が同じフォルダーにあったことでした。
この点も自分で原因を切り分け、設計ドキュメントを別フォルダーへ退避して処理を続行しています。
修正結果と副作用の自己申告
修正内容は変更前後を対比した表で報告されました。
| 項目 | 変更前 | 変更後 |
|---|---|---|
| 幅 | 行幅を2分割（各155px前後） | 68pxに固定 |
| 高さ | 40 | 32 |
| 文字サイズ | 13 | 12 |
| 配置 | 行いっぱいに伸長 | 右端に寄せ、縦は中央 |
実物でも報告どおり、ボタンが小さく右端にまとまっていました。
指示していない箇所については、承認キューの承認／却下ボタンを「同一行に両方を表示する必要があるため、意図的に据え置きました」と理由付きで説明してきました。
加えて「高さが32pxになり、モバイルの推奨タップ領域44pxを下回ります」と副作用も自己申告しています。
フローも自然言語で作れる（power-automateプラグイン）
同じマーケットプレイスには、canvas-apps以外にもプラグインが用意されています（筆者が確認した時点では8種類）。
そのうちpower-automateプラグインを使うと、Power Automateのクラウドフローを会話で作成・編集できます。
追加で必要になるもの
canvas-appsとは別に、2つの導入が必要でした。
| 必要なもの | 補足 |
|---|---|
| Azure CLI | 認証のみに使用し、Azure側にリソースは作られません |
| Node.js | MCPサーバーの起動に必要です。今回の検証で管理者権限の昇格が必要だったのはこれだけでした |
プラグインの導入自体は、マーケットプレイスを追加済みなので1行だけです。
canvas-appsとの違いとして、こちらはURLを渡す必要がなく、環境名を伝えるだけで接続できます。
ブラウザタブを開いたままにしておく必要もありません。
なお、Node.js未導入の状態ではMCPサーバーが起動できませんでした。
このときはAzure CLI経由でREST APIを直接呼び出して代替し、その原因と取得範囲の制限もあわせて開示されました。
疎通確認とフローの新規作成
まずは「環境のフローを一覧表示して」と依頼したところ、MCPサーバー経由でフローの一覧を取得できました。
続いて承認フローの作成を依頼します。
その結果、手動トリガー → 申請内容の整形 → 承認依頼 → 承認結果の判定、という骨組みが未公開の状態で作成されました。
承認・却下それぞれの分岐には、後から実処理に差し替えるためのプレースホルダーが置かれています。
「確認していただきたい点」として報告された3項目
ここでも、作業の副作用が自己申告されました。
環境に存在しなかった承認コネクタの接続を新規作成したこと（不要なら削除できる）、MCPの接続系ツールが一部動作せず別の方法で処理したこと、そしてこの環境はソリューションにラップされているため公開時に接続参照がすべて接続済みでないとエラーになること、の3点です。
環境に何かを追加したことを黙って進めず、削除できる旨まで添えてくる点は、業務で使ううえで安心材料になります。
フローの編集：依頼の裏にある課題まで解決してきた
続けて、承認結果に応じたTeams通知の追加を依頼しました。
依頼どおりに作ろうとすると、詰まる点は先に指摘されました。
既存のトリガーには承認者しかなく、Teams通知の宛先になる申請者のアドレスを取得できないという点です。
トリガーに「申請者」の入力項目を追加したうえで、通知アクションが組み込まれていました。
実物でも、承認された場合の分岐の末尾にTeams通知が追加され、パラメーターも報告どおりでした。
よくある質問
Q. canvas-apps／power-automateプラグインは、日本リージョンの環境でも使えますか？
はい、使えました。
Microsoftが公式ドキュメントで案内しているこの2つのプラグインは、日本リージョンの環境で問題なく動作し、日本語の指示でアプリとフローの生成・編集ができました（2026年9月時点）。
Q. Visual Studio Codeは必須ですか？
必須ではありません。
今回の検証で実際に必要だったのは.NET SDK 10.0以降とコーディングエージェント（今回はClaude Code）で、Power Automate側ではさらにAzure CLIとNode.jsが必要でした。
ただしスラッシュコマンドは拡張機能パネルでは使えず、ターミナルからの実行が必要です。
Q. Power Apps側で必要な設定は何ですか？
保存済みのキャンバスアプリを用意し、設定 → 更新 → 新規タブから「コオーサリング」をオンにする必要があります。
またMCPサーバーはそのブラウザタブのセッション経由で通信するため、作業中はタブを開いたままにしてください。
なおコオーサリングをオンにすると「元に戻す」「名前を付けて保存」「検索」が使用できなくなります。
Q. 生成された内容は信用できますか？
今回の検証では、報告内容と実機の画面が一致していました。
MCPサーバーが実際にコンパイルを行うため、Claude Codeはコンパイルが通らない状態では先に進めず、失敗を自分で検知して修正していました。
ただし常に一致するとは限らず、環境への副作用（接続の新規作成など）が発生する場合もあります。報告内容だけで判断せず、実際の画面や成果物も確認しながら進めることをおすすめします。
まとめ：開発者が使うなら十分に実用的
今回の検証で分かった学びは、次の3つです。
- 日本語の指示だけでアプリもフローも作れる：キャンバスアプリは約40分で3画面が生成され、承認フローも骨組みからTeams通知の追加まで会話で完結しました。日本リージョンの環境でも問題なく動作しています。
- 報告と実物のズレが起きにくい：MCPサーバーが生成物をコンパイルするため、Claude Codeは失敗を自分で検知して修正していました。副作用や未検証の箇所も自己申告してくるので、内容を確認しながら進められます。
- 導入のハードルは初心者向けではない：.NET SDK・Azure CLI・Node.jsの導入とコマンド操作が前提になります。逆に言えば、開発者やエンジニアが使う分には十分実用的で、提案やPoCのスピード向上が見込めます。
Power Platform向けの公式プラグインを導入すれば、アプリ画面の作り込みまで自然言語で進められます。
まずは検証用の環境で、保存済みのキャンバスアプリを1つ用意するところから試してみてはいかがでしょうか。
第2回では、ここで作ったアプリとフローをSharePointリストにつなぎ、申請から承認・通知までを実際に動かすところまでをご紹介します。
また、QESでは、今回のようなコーディングエージェントの活用を含め、業務で使えるAIエージェントの開発をご支援しています。
セキュリティ・ガバナンス設計からPoC・本番構築、運用と継続改善まで、プロフェッショナル開発と市民開発のどちらにも対応していますので、以下のリンクからサービスの詳細をご確認ください。
※このブログで参照されている、Microsoft、Power Apps、Power Platform、Power Automate、SharePoint、Microsoft Teams、Azure、Visual Studio Code、GitHub、Copilotは、米国およびその他の国におけるMicrosoft Corporationの商標または登録商標です。
※Claude、Claude Codeは、Anthropic PBCの商標または登録商標です。
