元自治体職員（現営業職）がCopilot Studioの新機能「アプリ」で消耗品在庫管理アプリを「自然言語だけ」でつくってみた

はじめに

アーティサンの村上です。

以前、Copilot Studioでエージェントを作ってみた記事を書かせていただきましたが、そのCopilot Studioに「アプリ（プレビュー）」という新しい機能が追加されました。
やりたいことをチャットで伝えるだけで、業務アプリをAIが作ってくれるというものです。

今回は、どの会社でも身近な「消耗品の在庫管理」を題材に、実際にアプリを作ってみました。

先に結論をお伝えすると、チャットで依頼して承認ボタンを押していくだけで、約12分でSharePointリストとつながった在庫管理アプリが公開までできました。

一方で、プレビュー版ならではの挙動や、権限・クレジットまわりなど、社内で使う前に知っておきたい点も見えてきました。

「Power Appsとは何が違うの？」という疑問をお持ちの方も多いと思いますので、そのあたりもあわせてお話させていただければと思います。

※本記事は、2026年10月時点のプレビュー版で試した内容です。画面や機能、ライセンス・課金の条件は、一般提供（GA）までに変わる可能性がありますので、参考情報としてご覧いただければと思います。また、プレビュー機能は本番環境での利用を想定したものではありません（Microsoft Learn）。

Copilot Studioの新機能「アプリ（プレビュー）」とは

「アプリ」は、作りたいものを自然な言葉で伝えると、AIがアプリの画面・データ・処理をまとめて組み立ててくれる機能です。

ホーム画面を開くと、「エージェント」「AIワークフロー」と並んで「アプリ（プレビュー）」が並んでいます（図1）。

いずれも「GitHub Copilot」というラベルが付いています。

公式ドキュメントにも「アプリの作成はGitHub Copilotハーネス（実行環境）で動いている」と書かれており（Apps overview）、エージェントやワークフローと同じ土台の上で動いているようです。

図1 Copilot Studioホーム画面

公式情報や今回触ってみた範囲で、押さえておきたいポイントは次のとおりです。

• 作り方：チャットで依頼→生成→プレビューで確認→会話で修正→公開、という流れです。生成されたコードは読み取り専用で確認でき、変更は会話でCopilot Studioに依頼します（FAQ）。
• 作成場所：新しいアプリは「個人用の環境（personal environment）」に作られます。画面上にもその旨の通知が出ました。
• データ：コネクタ経由で社内データにつながります。今回はSharePointリストを使いました。
• 管理：Microsoft Entraの認証や、既存のコネクタ・データポリシーがそのまま適用され、公開したアプリはMicrosoft 365管理センターから把握できます。
• 課金：作る側はCopilotクレジットを消費する従量課金、使う側はPower Apps Premium、またはCopilotクレジットの消費が必要です（詳しくは後半の「必要なライセンス・課金」で整理しています）。
• 提供状況：2026年9月にパブリックプレビューとして発表されました。

実際に消耗品在庫管理アプリを作ってみる

今回は、「依頼文を送る」→「承認する」→「動かしてみる」→「SharePointを確認する」の順に進めました。依頼文を送ってからアプリのプレビューが表示されるまで、およそ12分でした。

① 依頼文を送る

「アプリ（プレビュー）」を開くと、入力欄だけのシンプルな画面が出てきます。

今回は、次の依頼文を送りました。ポイントは、データの保存先（SharePointサイト）を最初から伝えておくことかと思います。

保存先を指定しないと、ブラウザの中だけにデータを保存するアプリになる場合があり、そうなると社員同士で在庫を共有できません。

社内の消耗品（コピー用紙、トナー、文房具、衛生用品など）の在庫管理アプリを作ってください。

【データの保存先】指定のSharePointサイトにリストを作成して保存。リストは「品目」と「入出庫履歴」の2つに分ける

【品目】品名、カテゴリ、単位、保管場所、在庫数、発注点、発注状況（未発注／発注中／入荷済み）を登録・編集できる。在庫数が発注点以下の品目は赤く強調し「要発注」と表示

【入出庫の記録】「使用（出庫）」「補充（入庫）」をボタンひとつで記録。数量・記録者・メモを入力し、在庫数を自動で増減。在庫を超える出庫は不可

【履歴】新しい順に表示し、品目と種類で絞り込める

【ダッシュボード】「要発注の品目数」「発注中の品目数」を大きく表示。在庫数と発注点をグラフで比較

画面は日本語で、PCでもスマホでも見やすいデザインにしてください。

（実際の依頼文を要約しています）

② 承認しながらSharePointリストを作ってもらう

送信すると、AIが準備を進め、「DLP（データ損失防止）ポリシーで許可されていることを確認した」というメッセージのあと、1分ほどで「リスト作成」の承認カードが表示されました（図2）。

カードには「中リスク」の表示があり、作られる列の名前や種類を確認してから「承認」を押す仕組みです。

AIが勝手に社内データを触らないようになっているのは、情報システムのご担当者様にとっても安心できる点だと思います。

図2 依頼文とリスト作成の承認カード

承認カードを広げると、作成される列の名前や種類、選択肢まで確認できます。

承認すると、AIは「リストを作成したので、SharePointの利用者向けに列の表示名を日本語にします（内部名は英語のまま）」と続けました。

列ごとに承認が求められ、列名の変更だけで14件の承認がありました（図3）。リスト作成とあわせると15回です。

正直なところ、押す回数が多くて少し大変なくらいでした（笑）。

図3 列名を日本語にする承認

ただ、この「内部名は英語、表示名は日本語」という作り方は、SharePoint構築では定石のやり方です。

日本語の列名で作ると内部名が読めない文字列になるので、そこまで考えてくれているのは「わかっているな」と感じました。

ここまでで、依頼から約4分です。

③ アプリが完成する

その後、AIが画面のプログラムを書き進め、依頼から約12分でアプリが完成しました（図4）。この時点で公開まで済んでおり、公開用のURLも発行されていました。

図4 完成直後のプレビュー

左側のチャットでは、AIが完成報告をしてくれます。入っている機能の説明に加えて、次のようなことも書かれていました。

• 「アプリを共有しても、データへのアクセス権は付与されません。使う社員にはサイトの編集権限が必要です」

権限が自動で付与されないのは安心ですし、それをきちんと案内してくれるのもありがたい点です。

なお、サイト全体の編集権限までは必要なく、対象のリストへの閲覧・追加・編集など、必要最小限の権限を付ける形でも運用できます。

④ 品目を登録して使ってみる

完成直後はデータが空なので、「品目を登録」から5件ほど登録しました（図5）。カテゴリや発注状況の選択肢は、SharePointリストの設定から読み込んでいます。

図5 品目の登録フォーム

登録すると、トップ画面に「要発注の品目」と「発注中の品目」の件数が大きく表示され、在庫数と発注点を比べるグラフも描かれました（図6）。発注点を下回った品目は赤くなっています。

図6 ダッシュボード

下の品目一覧では、要発注の行が赤く強調され、「要発注」のバッジが付きます（図7）。各行の「使用」「補充」ボタンから、入出庫を記録できます。

図7 品目一覧

試しにボールペンを5本「使用」してみました（図8）。

記録者の名前は次に入力するときも入ったままになるので、毎回入力する手間もありません。

図8 使用（出庫）の記録

「入出庫履歴」タブでは、誰がいつ何を使ったか・補充したかが新しい順に並びます（図9）。

図9 入出庫履歴

⑤ SharePoint側を確認する

最後に、データが本当にSharePointに保存されているか確認しました。サイトコンテンツを開くと、「品目」と「入出庫履歴」の2つのリストができています（図10）。

図10 SharePointのサイトコンテンツ

品目を開くと、アプリで登録した内容がそのまま入っていました（図11）。ボールペンの在庫数も、25本に更新されています。

図11 SharePointの品目リスト

入出庫履歴にも、品名・種類・数量・記録者・メモ・記録日時が記録されています（図12）。

図12 SharePointの入出庫履歴リスト

ひとつ気になったのは、SharePointの一覧画面（既定のビュー）に「品名」の列が表示されていなかったことです。データは保存されていますが、SharePointで直接一覧を見るなら、ビューに「品名」列を追加しておくとよいと思います。

こういった細かいところは、最終的な人の目での確認がまだ必要そうです。

⑥ AIが次の改善も提案してくれる

完成報告の最後には、AIから「次に追加できる機能」の提案もありました。

• 品目一覧をカテゴリで絞り込む
• 入庫を記録したら、発注状況を「入荷済み」に自動で切り替える
• アプリ名を英語（Office Supplies Inventory）から日本語に変える

どれも、実際に使い始めたら「そうそう、それがほしかった」となりそうなものばかりです。

今回はここまでとしますが、「お願いします」と返すだけでどんどんアプリが育っていくのは、この機能ならではの楽しさだと思います。

使ってみてわかったメリット・デメリット

ひとことで言うと、「たたき台づくりは驚くほど速い。ただし、社内で本格的に使うには確認と準備が必要」という印象です。

メリット

• 要件を言葉にすれば、動くものがすぐに出てくる：依頼から約12分で、ダッシュボード・一覧・履歴までそろったアプリができました。「こんなものがほしい」を関係者で見せ合うには十分だと思います。
• データの入れ物まで作ってくれる：SharePointリストの作成から列名の日本語化まで、会話の中で完結しました。「内部名は英語、表示名は日本語」というSharePointの定石も押さえています。
• 必要なところで人の承認を挟む：今回の検証では、リストの作成や列の変更の前に、毎回承認カードが表示されました。
• AIが注意点を正直に教えてくれる：「実際の動作は確かめていない」「共有してもデータの権限は付かない」といった説明が、完成報告に添えられていました。
• 次の改善をAIの方から提案してくれる：「カテゴリでの絞り込み」「入庫時に発注状況を自動更新」など、使う人の目線で次の一手を出してくれます。

デメリット・気をつけたい点

• 「動作確認」は人がやる必要がある：AI自身も「画面の操作は確かめていない」と書いており、登録や入出庫が正しく保存されるかは自分で試す前提です。
• 承認の回数が多い：今回はリスト作成と列名の変更で、あわせて15回承認ボタンを押しました。安全のためとはいえ、少し手間に感じるかもしれません。
• SharePoint側の細かい調整は必要：一覧画面に「品名」列が出ていないなど、SharePointで直接見るには手直しがいります。リスト名が日本語のため、URLが「Lists/List」のような名前になる点も気になりました。
• 権限設定は別途必要：アプリを共有してもSharePointリストの権限は付かないため、使う人には、対象のリストへの閲覧・追加・編集など、必要最小限の権限を付ける必要があります。気を付けたい点です。
• コストが見えにくい：作る側はプレビューやテストも含めてCopilotクレジットを消費し、Power Apps Premiumを持たない利用者はアプリを開くたび・データを読み書きするたびにCopilotクレジットを消費します。試行錯誤や利用者が増えるほど使用量も増えるため、事前の確認が必要です。
• 個人環境に作られる：部署や会社全体で運用するなら、環境の分け方や管理のルールを決めておきたいところです。

既存のPower Appsとの違い

いちばん大きな違いは、「画面を自分で組み立てる」のがPower Apps、「作りたいものを伝えてAIにコードごと作ってもらう」のがCopilot Studioのアプリという点だと思います。

項目	Copilot Studioのアプリ（プレビュー）	Power Apps（キャンバスアプリ）
作り方	チャットで依頼し、会話で修正	Power Apps Studio画面（アプリを作成・編集するための画面）で部品を配置し、Power Fx（関数）で動きを付ける
中身	AIが書いたプログラムのコード。コードは読み取り専用で閲覧できる	ローコードの部品と関数
向いている人・アプリ	要件を言葉にできる業務担当者。 簡易なアプリ（登録・編集・閲覧・削除など）	Power Appsの操作を覚えた市民開発者 作り込みが必要なアプリ
データ	コネクタ経由。 今回はSharePointリストをAIが作成	基本的にはSharePoint、Dataverse、各種コネクタを自分で設計して接続
作成場所	個人用の開発環境	選んだPower Platform環境
課金	作る側：Copilotクレジット（従量課金） 使う側：Power Apps Premium、またはCopilotクレジット	Power Appsのライセンス
成熟度	プレビュー	一般提供。運用実績も情報も豊富

なお、Power AppsにもCopilotでアプリを作る機能や、コードで作る「コードアプリ」があります。

そのため、今後は境界が少しずつ近づいていくものと考えています。

必要なライセンス・課金（作る側・使う側）

「結局、何のライセンスがあれば使えるの？」は、ご担当者様がいちばん気になるところだと思います。プレビュー中のため今後変わる可能性があり、あくまで参考情報としてご覧いただきたいのですが、2026年10月時点でMicrosoftが公開している情報を整理すると、次のとおりです。

先にまとめると、課金は「作る側」はCopilotクレジット、「使う側」はPower Apps Premium（ない場合はCopilotクレジット）の2つに分かれます。管理する場所も、作る側はPower Platform管理センター（環境単位）、使う側はMicrosoft 365管理センター（ユーザー単位）と分かれています。

作る側（アプリの作成者）

項目	内容	根拠
必要なもの	Copilot Studioへのアクセス	Apps overview（Microsoft Learn）
課金	作成・プレビュー・テストのたびにCopilotクレジットを消費（作り始めた時点から課金対象）	Apps overview Overview of billing for agents powered by the GitHub Copilot harness（いずれもMicrosoft Learn）
管理する場所・単位	Power Platform管理センターで、環境単位で管理。 環境に割り当てた前払いの容量、または環境の従量課金プランから引かれる	Manage costs for agents powered by the GitHub Copilot harness Microsoft 365管理センターでのアプリ管理

使う側（アプリの利用者）

項目	内容	根拠
Power Apps Premiumがある場合	アプリの実行ではCopilotクレジットを消費しない。 ただし、Power Apps PremiumのAPI要求の上限を超えた場合や、Work IQ APIsなど別料金のサービスを使う場合は消費する。	Microsoft 365管理センターでのアプリ管理（Microsoft Learn）
Power Apps Premiumがない場合	アプリを開くたびと、データの読み書きなどのAPI呼び出しごとにCopilotクレジットを消費（API呼び出し1回で0.1クレジット）	Copilot Managed Runtime（Microsoft Learn） ※Copilot Studioで作ったアプリの公開先となる実行基盤の説明
管理する場所・単位	Microsoft 365管理センターで、ユーザー単位で管理（利用者ごとの使用上限やクレジットの割り当てを設定）。 Copilot Studioのエージェントのような環境単位の課金は、アプリの実行には適用されない	Microsoft 365管理センターでのアプリ管理（Microsoft Learn）
ホスト	Microsoftがホストする基盤で動作。 Azureなどを自社で用意する必要はない	Apps overview（Microsoft Learn）
データへのアクセス	サインインした人の権限でアクセス。 アプリを共有してもSharePointリスト（またはDataverse）への権限は付与されない	Apps overview（Microsoft Learn）

使う側で消費するクレジットも、作る側と同じ「Copilotクレジット」です。Power Appsのライセンスとは別の仕組みになるため、Power Apps Premiumを持たない社員に使ってもらう場合は注意が必要です。

試行錯誤を重ねるとその分だけクレジットを消費するので、管理者側でクレジットの上限や監視を決めておくと安心だと思います。

社内で毎日使うアプリであれば、利用人数と回数から事前に試算しておくと安心です。

作る側の消費量は、Power Platform管理センターの「ライセンス」→「Copilot Studio」から環境ごとに確認できます（Microsoft Learn）。使う側の使用上限やクレジットの割り当ては、Microsoft 365管理センターで設定します（Microsoft Learn）。

本格的に導入を検討される際は、その時点の公式ドキュメントやライセンスガイドで最新の条件をご確認ください。

弊社でも、一般提供の際にあらためて情報を整理してお伝えできればと思います。

社内運用される際には「クレジットを過剰消費しないプロンプト」や「ガバナンス（実行できるのは？責任者は？など）」を検討、策定を進めながら使用していただく必要があるかと思います。

どんな使い方ができそうか

今回使ってみて、いちばん相性がよいと感じたのは、Excelや紙で回している「小さな管理業務」を、まず動く形にしてみる使い方です。

たとえば、次のような業務は「誰が、何を、いつ」を記録して一覧で見るという今回と同じ形なので、作りやすいと思います。

• 備品・貸出品の管理（ノートPC、プロジェクター、社用車など）
• 社内の申請・問い合わせの受付と対応状況の管理
• 研修やイベントの参加者管理
• 新入社員のオンボーディングの進捗管理
• 現場点検や巡回の記録

もうひとつは、要件を固めるためのたたき台づくりです。本格的なシステムやPower Appsで作り込む前に、この機能で画面を作って関係者に見てもらえば、「実はこの項目もほしい」といった声が早い段階で集まるのではないでしょうか。

AIからの追加機能の提案も、関係者で話し合うきっかけになりそうです。

一方で、多くの社員が毎日使う業務システムや、承認ルートが複雑な業務は、プレビューの今は慎重に検討した方がよいと考えています。

その場合は、「たたき台はこの機能で、本番はPower AppsやSharePointでしっかり作る」という使い分けが現実的だと思います。

ご担当者様としては、「現場が自由にアプリを作り始めたら管理しきれるのか」という不安もあるかと思います。

公開したアプリはMicrosoft 365管理センターで一覧でき、プレビュー中は利用できる人をセキュリティグループで絞れるようです。

まずは一部のメンバーで試し、運用ルールを決めてから広げていくのが安心だと思います。

最後に

今回は、Copilot Studioの新機能「アプリ（プレビュー）」で、消耗品在庫管理アプリを作ってみました。

正直なところ、最初は「チャットだけで本当に作れるのかな…」と半信半疑でしたが、ダッシュボードが表示されたときには少し感動してしまいました。

私がPower Appsを学び始めた頃にこの機能があれば、画面設計など、もう少し楽ができたかもしれません。

そして何より、完成したら終わりではなく、AIの方から「次はこんな機能を足せますよ」とどんどん提案してくれるのが、この機能のいちばんの魅力だと感じました。

今回は提案を受けたところで一旦区切りましたが、使いながら少しずつ育てていく、そんなアプリの作り方が当たり前になっていくのではないでしょうか。追加機能を試した様子も、また別の記事でご紹介できればと思います。

一方で、プレビュー版ならではの挙動や、権限・クレジットなど、社内で本格的に使う前に整理しておきたい点もあります。「簡単にできるだろう」と油断せず、まずは小さな業務から試してみるのがよいと思います。

私の方でもこの機能を使ってどんなアプリが作れるか、どんな利用ができるかを検証してみたいと思います！！！

弊社では、Copilot StudioやPower Platform、SharePointの導入・構築のご支援をしております。「自社の業務だとどんなアプリが作れそうか」「プレビューの機能をどう運用すればよいか」といったご相談も、お気軽にご相談いただけると嬉しいです。弊社としても最新情報を発信していければと思っております。

最後まで、ご覧いただきありがとうございました！