「この申請業務をアプリにしたい」と説明すると、AIが入力画面や一覧を作ってくれる。業務担当者がその場で操作し、要望を伝え、画面を直す。こうした進め方を、Power Platformでも取り入れやすくなってきました。
Microsoftは2026年10月28日、Copilot CoworkでDataverseプラグインを使い、データモデルからアプリ作成まで進める例を公開しました。前日の10月27日には、canvas studio内でエージェントと共同編集するプレビューも発表されています。[1][2]
動くものを早く共有できることは、要件定義にとって大きな変化です。文章では伝わりにくかった操作や情報の並びを、業務担当者と同じ画面を見ながら確認できます。
そこでコンサルタントが意識したいのは、その画面を使って、どの業務判断を確定するのかです。
見栄えや操作感の確認に加えて、誰が何を申請し、どのデータを保存し、どの条件で次の状態へ進めるのかを合意する。AIで作るプロトタイプには、その議論を前へ進める役割を持たせたいと考えています。
今週の更新を、成果物の違いから読む
最初に、関連する機能の提供状態を整理します。「AIでアプリを作る」という説明でも、作成・編集する場所や成果物は同じではありません。
| 作成・編集の経路 | 2026年10月30日時点で公式発表から確認できること |
|---|---|
| コーディングエージェントからcanvas authoring agent pluginを使う | 9月1日にGAを発表。成果物はcanvas appで、人による直接編集と組み合わせられる。[3] |
| canvas studio内でエージェントと共同編集する | 10月27日にプレビューを発表。テナント設定の有効化とGitHub.comアカウントによるログインを案内。[2] |
| Copilot CoworkでDataverseプラグインを使う | 10月28日に提供を案内。記事のアプリ例はMicrosoft Copilot Managed Runtime（プレビュー）で実行され、Coworkでのアプリ作成にはFrontierプログラムへの参加が必要と説明。[1] |
Coworkの記事例で作られたアプリを、そのままcanvas appと同じものとして扱うことはできません。導入を検討する際には、生成される成果物の形式、データの保存先、後から編集する手段を確認します。
一方、canvas authoring agent pluginのGA発表では、AIに画面や数式などの変更を任せ、人が確認・調整する共同編集が説明されています。[3]
これらの動きを見ると、プロトタイプを作った担当者から実装担当者へ、何を引き継ぐかも重要になります。画面だけでなく、作成した資材と、その資材に反映した業務上の判断を共有できるようにしておきたいところです。
「備品を借りる画面」を作る前に、分岐点を出す
ここからは、備品貸出申請を題材にした設計例です。実在する案件や、特定の生成ツールで動作検証した結果ではありません。
業務担当者から、次の要望が出たとします。
社員が備品と利用期間を選んで申請し、上長が承認するアプリがほしいです。
この説明だけでも、申請画面、一覧、承認ボタンのある画面は構想できます。ただし、実装に影響する判断がいくつも残っています。
一つの申請で、備品を複数借りられるのか。承認された時点で在庫を確保するのか。申請中に同じ備品へ別の申請が入ったらどうするのか。承認後に利用期間を変えた場合、再承認が必要なのか。
たとえば、一申請につき備品一つと考えて作った画面と、一申請に複数の貸出明細を持たせる画面では、入力方法だけでなくデータ構造も変わります。
私なら、最初の生成指示に「未決事項を挙げる作業」を含めます。使用するツールの対応範囲を確認したうえで、次のような指示を出すイメージです。
備品貸出申請のプロトタイプを検討します。社員が申請し、上長が承認します。
まず、画面構成、必要なデータ、業務上の未決事項を提案してください。一申請で複数の備品を扱う案を前提にしますが、未決事項を確定済みとして実装しないでください。
今回確認したいのは、申請と明細の関係、承認前後で編集できる項目、在庫確保のタイミングです。データは架空の例を使い、既存テーブルを変更する前に変更案を示してください。
この指示で正しい設計が自動的に得られると期待するわけではありません。AIが置いた仮定を、人が確認できる形へ出すことが目的です。
最初のレビューでは、操作の途中で立ち止まる
画面ができたら、業務担当者に一連の操作を見てもらいます。ただし、すべてを最後まで動かしてから感想を聞く進め方では、判断が曖昧なまま通り過ぎることがあります。
備品貸出なら、申請者がプロジェクターとケーブルを同じ申請へ追加する場面で立ち止まります。
「二つの備品は、同じ期間でしか借りられませんか」。別々の期間が必要なら、利用期間を申請全体に持つか、明細ごとに持つかを検討します。
次に、上長が承認する場面で立ち止まります。
「承認は、貸出可能なことを確約する行為ですか。それとも利用目的を認める行為ですか」。後者であれば、承認後に備品管理担当者が手配可否を確認する工程が必要かもしれません。
さらに、承認後に申請者が期間を延長する場面も見ます。単なる日付変更として保存してよいのか、再承認と在庫の再確認が必要なのか。この回答によって、編集できる状態や実行する処理が変わります。
このように画面を使うと、「承認ボタンがある」という確認から、「承認すると何が確定するか」という合意へ進めます。
見えたことを、データと制御へ落とす
レビューで得た回答は、その場の会話で終わらせず、実装へつながる形で残します。
| レビューで得た合意の例 | データ・処理への反映案 | 次に確かめること |
|---|---|---|
| 一申請で複数備品を借りる。期間は明細ごとに指定する | 申請と貸出明細を分け、各明細に利用期間を持つ | 一部明細だけ変更・取消する場合の扱い |
| 上長承認は利用目的の承認とする | 承認状態と手配状態を区別する | 申請者へ「利用できる」と伝える時点 |
| 手配確定後の期間変更には再確認が必要 | 状態に応じた変更処理と確認経路を設ける | 他の申請と利用期間が重なった場合の判断 |
| 申請者は自分の申請を扱い、備品管理担当者は管理対象を横断して確認する | 権限要件を役割ごとに定義する | 別の担当者・利用経路から同じデータを扱う場合の整合性 |
ここで注意したいのが、画面上の制御と、業務ルールの実施場所です。
たとえば、プロトタイプで承認後の編集ボタンを隠せたとしても、それだけで「承認後は変更できない」という要件を検証したことにはなりません。他の画面や連携からの更新も想定し、どこで同じ条件を確認するかを設計します。
同時に二人が最後の一台を確保しようとするケースも、画面を一人で順番に操作するデモでは判断できません。画面レビューで見つけた論点を、後続の実装・テストへ渡す必要があります。
こうした制御をどこへ実装するかは、採用するアプリ構成や更新経路に合わせて決めます。この記事の表は設計上の提案であり、AI生成機能が自動で保証する内容ではありません。
AIの変更を承認する人には、変更の単位を見せる
Dataverseプラグインを使ったCoworkの公式記事では、利用者のDataverse権限で処理し、変更を承認カードで確認する流れが説明されています。[1]
この仕組みを検討する際には、承認する人が変更内容を判断できる状態も用意したいところです。
「備品申請アプリを作ってよいですか」という大きな確認だけでは、どのテーブルを新設し、既存データとどう関係づけるのかを見落としやすくなります。
私なら、既存データを再利用する判断、新しいテーブルを作る判断、権限を変える判断、サンプルデータを投入する判断を、個別に説明できるようにします。どのツールでも同じ承認画面が使えるという意味ではなく、レビューに必要な変更情報をそろえるという提案です。
特にプロトタイプでは、架空データで動きを確かめた状態と、実データへの接続を確認した状態を区別して記録します。画面が同じように見えても、レビューで確認できた範囲は変わるためです。
プロトタイプの終了時に、三つの成果物を残す
レビューを終えた時点で、私は次の三つを残したいと考えています。
一つ目は、合意した業務の流れと状態です。誰の操作で何が確定し、変更や取消がどの状態まで許されるのかを整理します。
二つ目は、合意したデータの単位と関係です。申請と明細をどう分けるか、既存の社員・備品情報をどこから参照するかを残します。
三つ目は、まだ証明していないことです。同時実行、権限、実データ連携、性能、環境間の移送などを挙げ、後続の担当者と確認方法を決めます。
この記録があれば、プロトタイプを発展させる場合にも、別の構成で本実装する場合にも、業務上の合意を引き継げます。
AIによって画面やアプリを作る時間が短くなるほど、短い時間で多くの案を比較できるようになります。その機会を、未決事項を見つけ、業務担当者と判断をそろえるために使う。Power Appsのプロトタイプを要件定義へつなげるうえで、そこにコンサルタントの価値があると考えています。
参考情報
確認日：2026年10月30日。以下はすべて送審日から過去1年以内に公開されたMicrosoftの一次資料です。公開日は記事表示とページのdatePublishedを照合。本文の業務例、指示文、レビュー方法は筆者の分析・提案です。
| 番号 | 直接URL | 公開日 | 参照内容 |
|---|---|---|---|
| [1] | From one prompt to a governed Dataverse app: the Dataverse plugin lands in Copilot Cowork | 2026年10月28日 | Dataverseプラグインの提供案内、記事例の実行基盤、利用条件、権限と変更承認 |
| [2] | Invite agentic coauthors to collaborate with you directly in canvas studio! | 2026年10月27日 | canvas studio内での共同編集のプレビューと導入条件 |
| [3] | Turbocharge your canvas development with the canvas authoring agent plugin – now generally available! | 2026年9月1日 | canvas authoring agent pluginのGA、成果物と人による直接編集 |
コメント