2026年8月 Copilot Studio License Update 関連情報まとめ

はじめに

2026年8月 の Copilot Studio Licensing Guide の更新にて、GitHub Copilot Harness (≒ New agents and workflows) の GA が発表されました。

Acrobat Accessibility Report

これは Copilot Studio の大きな節目であり、また今後の Copilot Studio の方向性やライセンス形態についても様々な言及が行われました。

このブログではそれらの内容を私の理解と合わせてまとめています。
といっても、この発表が行われた 2026/8/4 の深夜から早朝にかけての私のツイートの総まとめみたいなものですけどね。

Posts by koruneko32767 x.com

また、これはあくまでも 2026/8/4 現在の情報をもとに記載してある内容なので、それ以降に読む方はお気を付けを―

新しい Copilot Studio の方向性と 2026 年 8 月のライセンスアップデートについてまとめる

Overview

2026 年 8 月に Copilot Studio に関する大きなアップデートがありました。

今回のアップデートでは、単に新しい機能が追加されただけではなく、Copilot Studio が今後どのような製品になっていくのか？という方向性も示されています。

また、新しい Copilot Studio で利用される GitHub Copilot Harness について、Copilot Credits を利用した新しい価格モデルも発表されました。

方向性の話とライセンスの話は別々に公開されていますが、内容としては密接に関係しています。

ということで今回は、以下の内容をまとめて紹介します。

• 人とエージェントの働き方はどのように変わるのか
• Copilot Studio や Power Platform は今後どう位置付けられるのか
• これまでの Copilot Studio と新しい Copilot Studio は何が違うのか
• 新しい Copilot Studio を利用する際に気を付けること
• 2026 年 8 月のライセンスアップデート
• GitHub Copilot Harness で消費される Copilot Credits

なお、本記事は 2026 年 8 月 4 日時点で公開されている情報と、私の環境で確認した Copilot Studio の表示をもとに記載しています。

プレビュー機能の提供状況、ライセンス条件、Copilot Credits の消費量などは、今後変更される可能性がありますのでご注意ください。

参考情報

今回の記事を作成するにあたり、主に以下の情報を参考にしています。

• The New Copilot Studio and the Next Wave
• More powerful agents and workflows for autonomous business processes: Introducing a new harness for Copilot Studio
• Microsoft Copilot Studio Licensing Guide
• Microsoft Copilot Credits Guide
• Build - Microsoft Copilot Studio（GitHub Copilot）
• Overview of usage-based billing - Microsoft Copilot Studio（GitHub Copilot）
• New Harness, New Rules? CAT's Got You | The Custom Engine
• Copilot Studio - Technical Deep Dive v1.0

新しい Copilot Studio が目指しているもの

個人の生産性向上だけが「山の頂上」ではない

これまでの生成 AI 活用では、個人の生産性向上が大きく注目されてきました。

例えば、以下のような利用方法ですね。

• メールを要約する
• 文書やプレゼンテーションを作成する
• 必要な情報を検索する
• 会議の内容を整理する
• 日常的なタスクを支援する

これらは引き続き重要です。

しかし、今回公開された動画では、個人の生産性向上だけでは「山の頂上ではない」と説明されています。

個人の業務を効率化するだけでなく、チームでの協働や、業務プロセス全体の変革まで AI の活用範囲を広げる。

そこが、Microsoft が次に目指している方向性です。

人とエージェントが一緒に仕事をする

今後の働き方として示されているのが、Human-Agent Teams です。

エージェントが人間の仕事をすべて置き換えるという話ではありません。

人間とエージェントが、それぞれの得意なことを担当しながら、一緒に業務を進めていくという考え方です。

人間は、主に以下のような役割を担当します。

• 業務の目的を決める
• 判断基準を定める
• 最終判断を行う
• 関係者と合意する
• 責任を持つ

一方、エージェントは以下のような役割を担当します。

• 必要な情報を集める
• 作業を複数の手順に分解する
• ツールやシステムを操作する
• 処理結果を整理する
• 必要に応じて別の方法を試す

人が主導し、エージェントが伴走する働き方ですね。

3 種類のエージェント

今回の記事では、エージェントの活用範囲が以下の 3 段階で整理されています。

種類	主な役割
Personal Agents	個人の情報整理、文書作成、日常業務を支援する
Team Agents	会議、情報共有、共同作業、チーム内の連携を支援する
Process Agents	複数ステップや複数システムを含む業務プロセスを支援する

個人の生産性向上はゴールではなく、チームの協働や業務プロセス変革へ進むための出発点ということですね。

Power Platform や既存の業務アプリが不要になるわけではない

Agentic AI が進化していくと、これまで利用していたアプリや業務システムが、すべてエージェントに置き換わってしまうように感じるかもしれません。

しかし、Microsoft は SharePoint、Dynamics 365、Power Platform などの業務アプリケーションがなくなるとは説明していません。

今後の業務アプリケーションは、以下の 2 つの役割を持つようになります。

1. これまでと同じように、人が画面を操作して業務を行うためのアプリケーション
2. エージェントが情報を理解・取得し、操作を実行するための業務基盤

つまり、業務アプリケーションが人間専用の操作画面ではなく、人とエージェントが一緒に利用する基盤へ広がっていくということです。

Power Platform の役割

Power Platform も、もちろん不要になるわけではありません。

Power Platform には以下のような製品があります。

• Power Apps による業務アプリの作成
• Power Automate による業務の自動化
• Power BI によるデータ分析
• Power Pages による Web サイトやポータルの作成
• Dataverse による業務データの管理
• コネクタによる Microsoft 365、Dynamics 365、外部サービスとの連携

Copilot Studio のエージェントが高度になっても、エージェントが利用するデータ、アプリ、API、コネクタ、自動処理などは必要です。

そのため、Power Platform が不要になるのではなく、エージェントが業務を実行するための基盤として、さらに重要になっていくのではないかと思います。

Copilot Studio の役割

Copilot Studio も、単にチャットボットや会話エージェントを作成する製品ではなくなりつつあります。

新しい Copilot Studio では、以下のような要素を組み合わせて利用します。

• Agent
• Workflow
• Skills
• Knowledge
• Tools
• Connected agents

Copilot Studio が業務の推論や処理のオーケストレーションを担当し、Power Platform、Microsoft 365、SharePoint、Dynamics 365、Microsoft Fabric、Azure、外部システムなどがデータや実行手段を提供するイメージですね。

また、Copilot Studio は特定の AI モデルだけに固定されず、今後登場するさまざまな Agentic AI の進化を取り込んでいく基盤として位置付けられています。

組織としてエージェントを活用する

エージェントを作成できることと、組織として継続的に価値を生み出せることは別の話です。

いきなり全社規模で展開するよりも、まずは効果を確認しやすい業務から小さく始めるのがよいと思います。

効果が見えやすい業務から始める

最初に対象とする業務は、以下のような特徴があると進めやすそうです。

• 実行頻度が高い
• 手順や判断基準をある程度整理できる
• 複数の情報を確認する必要がある
• 人による例外判断が発生する
• 品質や完了率を測定できる
• 現在の課題や業務負担が明確である

個人の作業効率化から始めること自体は問題ありません。

ただし、そこで終わりにするのではなく、最終的にはチームの協働や業務プロセス全体へ対象を広げ、組織としての価値につなげることが重要です。

人の判断を残す

エージェントを利用するからといって、すべての判断をエージェントに任せる必要はありません。

特に、以下のような判断には人間を残した方がよいでしょう。

• 最終確認
• 承認
• 例外判断
• 対外的な意思決定
• 法務、財務、セキュリティに関する判断

エージェントには、判断に必要な情報を整理させたり、選択肢を提示させたりすることで、人間の意思決定を支援させます。

作成して終わりにしない

生成 AI を利用した Agent は、事前に定義された処理だけを実行する Workflow と異なり、状況に応じて判断や処理経路を変える可能性があります。

そのため、作成して公開した時点を完成とするのではなく、継続的に以下の内容を確認する必要があります。

• 正確性
• 完了率
• 安全性
• 再現性
• 実行時間
• Copilot Credits の消費量
• 実際の業務成果
• 利用者からのフィードバック

これまで以上に Evaluation と Monitor が重要になるということですね。

これまでの Copilot Studio と新しい Copilot Studio

従来の Copilot Studio は、主に会話エージェントをローコードで作成する製品として利用されてきました。

作成者が Topic、条件分岐、メッセージ、Action、Agent flow などを定義し、エージェントがどのような経路で処理を進めるかを設計します。

一方、新しい Copilot Studio では、エージェントに達成するべき Goal を与え、Agent、Workflow、Skills、Tools などを組み合わせて業務を実行します。

比較項目	これまでの Copilot Studio	新しい Copilot Studio
主な用途	会話型エージェント	複雑な業務プロセスの実行
設計方法	Topic、分岐、定義済みフロー	Goal、Agent、Workflow、Skills
実行方法	作成者が定義した経路を中心に実行	状況に応じて処理を計画・選択
対象範囲	単一の会話やタスク	複数ステップ、複数システム、長時間処理
ファイル操作	会話や定義済み処理が中心	文書や成果物を含む業務処理
開発と運用	作成、テスト、公開	Build、Preview、Evaluate、Monitor
AI 基盤	固定的な会話体験を前提に設計	特定モデルに依存せず、Agentic AI の進化を取り込む
主な価値	個人の支援	個人、チーム、業務プロセス全体の支援

この変化は、従来の機能が廃止されるという意味ではありません。

予測可能性を重視する従来型のエージェントと、柔軟な推論を行う新しいエージェントを、用途に応じて使い分ける形になります。

新しい Copilot Studio の設計・運用で重要になること

新しい Copilot Studio では、これまでとは少し異なる設計や運用が必要になります。

特に重要だと思うのが、以下の 5 点です。

1. 非決定的な Agent と決定的な Workflow を組み合わせる
2. Skills を業務ノウハウの再利用単位として利用する
3. Evaluation を継続的に行う
4. Harness を作成時に慎重に選択する
5. Copilot Credits の利用量を管理する

非決定的な Agent と決定的な Workflow を組み合わせる

新しい Copilot Studio では、すべての処理を AI に任せるわけではありません。

Agent と Workflow には、それぞれ向いている処理があります。

Agent が向いている処理

• 状況の解釈
• 調査や要約
• 複数情報の整理
• 柔軟な判断
• 提案の作成
• 例外や不確実な状況への対応

Workflow が向いている処理

• 承認
• 通知
• 記録
• システムの更新
• 定められた順序での処理
• 同じ入力に対する一貫した実行

柔軟な推論や判断は Agent に任せ、決められた処理を確実に実行する部分は Workflow に任せる。

この 2 つを組み合わせることで、柔軟性と統制を両立させます。

すべて Agent で頑張るという話ではないのですね。

Skills が業務ノウハウの再利用単位になる

Skills は、エージェントに業務の進め方を教えるための、再利用可能な能力です。

例えば、以下のような業務ノウハウを Skills として整理できます。

• 契約書をレビューする手順
• 顧客や業界を調査する方法
• 提案書を作成する際のルール
• 社内基準に沿って確認する方法
• 特定形式の文書や成果物を作成する手順

個人がその都度プロンプトを入力するのではなく、業務の進め方や判断基準を Skills として標準化します。

一度作成した Skills を複数のエージェントから利用することで、業務ノウハウを再利用しやすくなります。

Evaluation が従来以上に重要になる

目標志向の Agent は、同じ依頼であっても、状況に応じて異なるツールや処理経路を選択する可能性があります。

そのため、一度正常に動いたからといって、常に期待した結果になるとは限りません。

以下のようなテストケースを用意し、継続的に評価する必要があります。

• 正常な入力
• 情報が不足している入力
• 矛盾する情報が含まれる入力
• 例外処理が必要な入力
• アクセス権限が不足している場合
• ツールや外部サービスが失敗した場合
• 高コストになりやすい長時間処理

評価結果を確認しながら、Instructions、Knowledge、Tools、Skills、Model、Workflow などを改善していきます。

「動いたから完成！」ではなく、継続的に評価と改善を行う必要があるということですね。

Harness は作成時に慎重に選択する

GitHub Copilot Harness と Standard Harness では、利用できる機能、作成方法、ライセンス条件などが異なります。

今回の投稿では、Harness は新しいエージェントを作成する際に選択し、後から別の Harness へ相互変換することはできないと説明されています。

GitHub Copilot Harness で作成したエージェントを Standard Harness へ移行したり、Standard Harness で作成したエージェントを GitHub Copilot Harness へ移行したりすることはできません。

別の Harness を利用する場合は、新たにエージェントを作成し直す必要があります。

後から簡単に変更できるものではないため、エージェントを作成する前に、目的や要件を整理する必要があります。

新しい Harness は Copilot Credits が必要

Standard Harness や Copilot Chat Harness は、条件を満たすことで Microsoft 365 Copilot ライセンスの範囲内で利用できます。

一方、GitHub Copilot Harness で動作する New agents and workflows では、Copilot Credits が必要です。

GitHub Copilot Harness では、公開後の実行だけでなく、自然言語による作成、Preview、Evaluation などでも Copilot Credits を消費します。

新しい機能を試す際は、機能面だけでなく、Copilot Credits の消費量についても確認する必要があります。

Copilot Studio ライセンス ガイド 2026 年 8 月アップデート

ここからは、2026 年 8 月に公開された Copilot Studio Licensing Guide の更新内容について紹介します。

今回の更新では、Copilot Studio のエージェントやワークフローを動かす基盤が、以下の 3 種類の Harness として整理されました。

1. GitHub Copilot Harness
2. Standard Harness
3. Copilot Chat Harness

GitHub Copilot Harness

複雑なエンドツーエンドの業務プロセスに対応する、新しいエージェント型の作成・実行基盤です。

Copilot Studio の New agents and workflows で利用されています。

Standard Harness

Topic、条件分岐、Agent flow などを事前に定義する、従来型の会話エージェント基盤です。

予測可能性や、定められた処理経路を重視するシナリオに向いています。

Copilot Chat Harness

組織のナレッジを利用して、Microsoft 365 Copilot を拡張するための基盤です。

SharePoint などの情報を参照する、比較的シンプルなナレッジ エージェントなどに利用されます。

Copilot Studio 画面に表示されている移行案内

2026 年 8 月 4 日時点で、私の Copilot Studio 環境には以下のメッセージが表示されています。

🎉 Introducing credit-powered capabilities

Agents and workflows created before August 3 will remain on the current pricing model until September 1, then transition to credit pricing.

日本語にすると以下の内容です。

Copilot Credits を利用する機能の提供開始

8 月 3 日より前に作成されたエージェントとワークフローには、9 月 1 日まで現在の価格モデルが適用されます。その後、Copilot Credits による課金へ移行します。

この表示から、すでに作成されている New agents and workflows についても、2026 年 9 月 1 日から Copilot Credits ベースの価格モデルへ移行する予定であることが分かります。

GitHub Copilot Harness とは

GitHub Copilot Harness は、Copilot Studio の New agents and workflows を動かす、新しい実行・オーケストレーション基盤です。

ユーザーから依頼を受けると、エージェントが処理を計画・推論し、コンテキストを維持しながら複数ステップの処理を実行します。

Harness とは、エージェントが以下のような処理を行うためのソフトウェア基盤です。

• 処理を計画する
• 推論する
• コンテキストを維持する
• ツールを選択する
• システムを操作する
• 他のエージェントへ作業を依頼する
• 複数ステップのタスクを完了する

GitHub Copilot Harness では、以下の要素を組み合わせて業務を実行します。

• Instructions
• Knowledge
• Tools
• Skills
• Workflows
• Model
• Connected agents

Standard Harness が、作成者によって定義された Topic やフローを中心に動作するのに対し、GitHub Copilot Harness は、目標や状況に応じて実行方法を判断する、より適応的な処理を前提としています。

なお、名称に「GitHub Copilot」とありますが、これは開発者向けの GitHub Copilot 製品そのものを意味するものではありません。

Copilot Studio の新しいエージェント基盤の名称です。

紛らわしいですね。

Microsoft 365 Copilot ライセンス ユーザーへの影響

Microsoft 365 Copilot ライセンスには、Copilot Studio の Author ロールが含まれています。

そのため、Microsoft 365 Copilot ライセンスを持つユーザーは、引き続き Copilot Studio にアクセスしてエージェントを作成・管理できます。

これは既存の機能から変わったわけではありませんが、今回ライセンス ガイドに明記されるようになりました。

また、以下の条件を満たす Standard Harness または Copilot Chat Harness の利用は、Microsoft 365 Copilot ライセンスに含まれます。

1. 利用者が Microsoft 365 Copilot ライセンスを保有している
2. ライセンスを持つ本人として認証されている
3. Teams や Microsoft 365 Copilot などの Microsoft チャネルで利用する
4. 従業員向けの Business-to-Employee シナリオである
5. 公平な利用制限の範囲内である

画面上の分類と完全に 1 対 1 で一致するわけではありませんが、Standard Harness と Copilot Chat Harness は、おおむね従来の Classic agents に相当します。

そのため、Microsoft 365 Copilot ライセンスを持つユーザーが Microsoft チャネルで利用する、従来型の社内向けエージェントについては、今回の変更による影響は限定的です。

外部 Web サイトで利用する場合や、Microsoft 365 Copilot ライセンスを持たないユーザーが利用する場合は、別途 Copilot Credits が必要になる可能性があります。

GitHub Copilot Harness で Copilot Credits が必要になる操作

GitHub Copilot Harness については、Microsoft 365 Copilot ライセンスだけでは、以下の操作がカバーされません。

1. 自然言語によるエージェント、Workflow、Skills の作成
2. Preview によるテスト
3. Evaluation による評価
4. 公開後のエージェント実行
5. Workflow の実行

これらには、原則として Copilot Credits が必要です。

公開操作そのものは Copilot Credits を消費しません。

ただし、公開後の実行では Copilot Credits が必要になるため、公開時には少なくとも 1 つの Copilot Credits 購入オプションをテナントに設定する必要があります。

GitHub Copilot Harness は、おおむね New agents and workflows に相当します。

Microsoft 365 Copilot ライセンスだけで従来型のエージェントを利用していた組織が New agents and workflows を利用する場合、新たに Copilot Credits の購入や課金設定が必要になります。

ここが今回のライセンスアップデートにおける、特に大きな変更点ですね。

GitHub Copilot Harness の Copilot Credits 消費

GitHub Copilot Harness では、Copilot Credits は大きく以下の 2 つのタイミングで消費されます。

• 作成時
• 実行時

作成時の消費

自然言語を利用してエージェントや Workflow を作成する場合は、1 回の作成セッションにおける会話回数を基に、以下のような目安が示されています。

作成シナリオ	会話回数	推定消費量
軽い作成	1～2 ターン	1～20 Credits
中程度の作成	3～5 ターン	21～60 Credits
重い作成	6 ターン以上	61 Credits 以上

会話回数が増えるほど、反復的な修正を伴う複雑な作成シナリオと見なされ、消費量が増える傾向があります。

Preview と Evaluation の消費量は、エージェントを実際に実行した場合のランタイム消費量と同等です。

一方、自然言語や LLM を使用せず、画面上で手動設定を行う場合は Copilot Credits を消費しません。

Build タブや Monitor タブで行う、手動の構成や設定作業も対象外です。

実行時の消費

実行時の Copilot Credits 消費量は固定ではなく、主に以下の 4 要素で決まります。

Models

利用する AI モデルです。

品質、速度、推論能力などによって、Copilot Credits の消費量が変動します。

Runtime

エージェントを動かし続けるクラウド上の実行基盤です。

複数ステップの処理や、長時間実行される処理も含まれます。

Context

エージェントが処理に利用する背景情報です。

• ユーザー
• 役割
• 過去のやり取り
• メール
• ファイル
• 会議
• 組織内の関係性

Tools

エージェントが業務を実行するために呼び出す操作です。

• メールの送信
• 予定の登録
• 文書の更新
• データの取得
• 外部システムの操作
• Workflow の実行

シナリオ別の推定値は以下のとおりです。

実行シナリオ	主な特徴	推定消費量
軽い実行	少数の情報源、軽い推論、1 個以下の成果物	100～300 Credits
中程度の実行	複数の情報源、構造化された推論、2 個以上の成果物	300～500 Credits
重い実行	広範な情報集約、深い推論、多数の成果物	500 Credits 超

これらは代表的なシナリオに基づく目安です。

実際の消費量は、以下の要素によって変動します。

• 依頼内容
• 利用するモデル
• 参照する情報量
• 実行時間
• ツールの呼び出し回数
• 作成する成果物の数
• 再試行や例外処理の発生回数

Copilot Credits は、単純なメッセージ回数ではなく、処理の複雑さや、エージェントが実際に行った作業量を反映する仕組みです。

なお、Copilot Studio で利用可能な各 AI Model のモデル別固定レートは公開されていません。

そのため、業務ごとの具体的な消費量を把握するには、代表的なシナリオを実際に実行し、Monitor や管理画面で測定する必要があります。

組織として準備すること

今回の更新を踏まえると、組織では単に Copilot Credits を購入するだけでは足りません。

設計、評価、ガバナンス、コスト管理をまとめて進める必要があります。

Harness の選択基準を決める

エージェントを作成する前に、どの Harness を利用するのか判断するための基準を決めておいた方がよいでしょう。

Standard Harness が向くケース

• FAQ
• ヘルプデスク
• 決められた手続き
• Topic や条件分岐を明示的に管理したい
• 処理の予測可能性を重視する
• Microsoft 365 Copilot ライセンスの範囲内で社内利用したい

GitHub Copilot Harness が向くケース

• 複数ステップの業務
• 複数システムを横断する処理
• 文書やファイルを作成・更新する
• 状況によって実行方法が変わる
• 例外時に別の方法を試す
• 他のエージェントへ作業を依頼する
• 長時間にわたって業務を継続する

Harness 間で既存のエージェントを相互変換できないため、機能だけでなく、将来的な拡張やコストも考慮して選択する必要があります。

Agent と Workflow の境界を決める

すべてを Agent に処理させると、結果やコストが不安定になる可能性があります。

柔軟な判断が必要な箇所だけを Agent に任せ、承認、通知、記録、システム更新などは Workflow で固定します。

Skills と業務ルールを整備する

業務ノウハウを Skills として再利用するためには、現場にある暗黙知を整理する必要があります。

例えば、以下のような情報です。

• 判断基準
• 参照する情報
• 作業手順
• 例外条件
• 成果物の形式
• 品質基準

エージェント導入は、既存の業務プロセスやナレッジを整理する機会にもなりそうですね。

Evaluation を運用に組み込む

公開前のテストだけでなく、公開後も実際の利用結果を監視します。

• 品質の低下
• 想定外の判断
• ツール実行の失敗
• 権限エラー
• Copilot Credits の増加
• モデル変更による挙動の変化

これらを定期的に確認し、評価結果をもとに改善を続けます。

Copilot Credits の利用方針を決める

Copilot Credits をすべての業務で一律に利用するのではなく、効果の高い業務へ優先的に配分する必要があります。

以下のような内容を比較して、費用対効果を確認するとよいでしょう。

• 業務価値
• 処理頻度
• 1 回あたりの Copilot Credits 消費量
• 月間の想定実行回数
• 手作業で必要な時間
• 品質向上の効果
• 失敗した場合の業務リスク

今回のアップデートをどう捉えるか

今回の Copilot Studio の更新は、単なる画面変更や新機能の追加ではありません。

Copilot Studio は、従来の会話型エージェントを作成する製品から、Agent、Workflow、Skills、Knowledge、Tools などを組み合わせて、複雑な業務プロセスを実行するプラットフォームへ進化しようとしています。

ただし、従来の Standard Harness や Copilot Chat Harness が利用できなくなるわけではありません。

予測可能性を重視する従来型のエージェントと、柔軟な推論や複雑な業務処理を行う新しいエージェントを、目的に応じて使い分ける形になります。

一方、GitHub Copilot Harness で動作する New agents and workflows では、自然言語による作成、Preview、Evaluation、公開後の実行などに Copilot Credits が必要です。

新しい機能が利用できるようになった！だけでなく、品質、ガバナンス、Copilot Credits の消費量まで含めて設計する必要があります。

また、Power Platform や既存の業務アプリが不要になるわけでもありません。

むしろ、人とエージェントが一緒に業務を行うためのデータ、アプリ、自動化、コネクタを提供する基盤として、これまで以上に重要になるのではないかと思います。

個人の生産性向上は重要です。

ただ、そこが「山の頂上」ではありません。

人とエージェントがそれぞれの強みを活かし、チームや業務プロセス全体を変えていく。

Copilot Studio も、そのための製品へ大きく変わろうとしているようです。

おわりに

Twitter でも会話していましたが、ライセンス複雑すぎますし、管理もしらなきゃいけないことや設定しなきゃいけないことなどなど多すぎて(少なくとも GitHub Copilot Harness の) Copilot Studio 導入・定着化はとてもとても大変ですね

また、まぁビジネスの関係上仕方ないよねーというのはわかるのですが、Microsoft 365 Copilot で GitHub Copilot Harness 関連の機能が使えないうえに、テストの際にもクレジット消費するのは厳しいなぁ...

Classic agent の利用権無くしていいので、Microsoft 365 Copilot ユーザーに一定の Copilot Credits 付与するようにして欲しいなぁ...と思うなど...

あとこのアップデートはマジで頼むぞーーーー
本当に困るので...

ところで Power Platform で環境作成すると、既定で Copilot Credits 超過時はテナント容量から引き落とす設定がオンになってますよね
この既定の動作の変更や、既存設定の一括変更の機能はいつ頃きますか？

8月中旬までにはきてくれますよね😉

— コルネ (@koruneko32767) 2026年8月3日

これ割と真面目に困ってて、
「お試して Copilot Credits 購入しました」
「でも社員には Microsoft 365 Copilot を割り当てて利用させているので、この設定がオンでも、まぁ実害はないかな」
という組織いくつかあったと思うんですよ

それが今回の更新で設定変更が急務になるわけですが
どうしろと？ https://t.co/u0dNz5gdMy

— コルネ (@koruneko32767) 2026年8月3日

【MEMO】生成AI 時代の働き方と組織設計

はじめに

お久しぶりです。
ブログをかくのはだいぶ久しぶりですね。

ただ、今回の記事は技術的な内容ではなく、この生成AI 時代に 個人/組織 としてどのように向き合うと良いか？という観点をベースに私の考えをざっくりまとめたものになります。
生成AI と広くいっていますが、Microsoft 365 Copilot や Copilot Studio の機能を活用する。という前提条件のもとまとめています。風呂敷広げ過ぎても収集つかないですからね。
まだまだ私の考えも粗が多いので、皆さんの意見も聴けるといいな。と思っています。

情報のまとめには Copilot を活用しています。
内容は私のほうで確認したものを記載していますが、言い回し気になってもそこは読み飛ばして貰えると助かります。

参考

ベースとして Satya Nadella 氏のこちらのノートを参考にさせてもらっています。
特に直近2つの投稿ですね。

snscratchpad.com

まだ見てない方は翻訳して是非読んでみることをおすすめします。

これは私個人が感じた感想でもありますが、読む際の注意点として、こちらは恐らく「生成AI」という全般的な内容について触れており、自社の製品についてなにかしら焦点を置いた記事ではない。ということを念頭に置いて読んだ方が良いんじゃないかな？と思っています。

Satya Nadella 氏の記事を読んでの私の考え要約

Microsoft 365 Copilot／Copilot Studio を起点に考える、個人と組織の将来像

生成AI の導入は、単なる業務効率化ではありません。
文章作成、要約、検索、分析といった個々の作業を速くするだけであれば、その効果は限定的であり、利用する製品やモデルが変わるたびに価値も揺らぎやすいです。

より重要なのは、生成AIを使う過程で生まれる指示、修正、評価、判断、成功・失敗の履歴を、組織固有の能力として蓄積し、次の仕事へ再利用できる状態をつくることであると考えています。

Microsoft 365 Copilot、Agent Builder、Copilot Cowork、Copilot Studioは、そのための具体的な実装基盤となります。
しかし、製品を導入しただけで組織が学習できるようになるわけではありません。
人とAIの役割、業務プロセス、ナレッジ管理、評価、教育、ガバナンス、コスト管理を一体として再設計して初めて、生成AI は組織能力へ変わると考えています。　　

1. 生成AI 導入の本質は「学習する組織」への変革である

生成AI の導入を、チャットツールの配布や文書作成時間の短縮だけで捉えると、その価値を過小評価することになってしまいます。

生成AI は、利用者の指示、判断、修正、例外対応を通じて、これまで個人の経験や会話の中に埋もれていた学びを記録し、整理し、再利用できる技術です。

そのため、再設計すべき対象は AI の使い方だけではありません。

• 人と AI の役割分担
• 業務プロセス
• 意思決定と説明責任
• 組織構造
• 人材育成
• 評価制度
• ナレッジ管理
• セキュリティ
• コスト管理

これらを個別に扱うのではなく、一つの組織システムとして見直す必要があります。

目指すべき状態は、単に「AI を利用できる組織」ではありません。
AIを前提として仕事を継続的に再設計し、人とAIが生み出す学びを、自社の能力として蓄積・再利用できる組織　　 です。

組織の競争力は、どのモデルや製品を採用したかだけでは決まりません。
利用結果からどれだけ学び、その学びを次の業務へ戻せるかによって決まります。

2. 人の能力と AI 資産は、相互に強化される

生成AI 時代に重要なのは、人の能力と AI の能力を対立させないことです。

人の専門性、経験、判断力、顧客理解、関係性、暗黙知は、組織の人的資本です。
一方で、AI への指示、エージェント、Skills、評価基準、業務フロー、成功・失敗の履歴、修正内容、ナレッジは、組織が構築する AI 資産となります。

AI 資産が増えることで、人の価値が下がるわけではありません。

人がより高い目標を設定し、異なる領域をつなぎ、結果を評価し、重要な判断を行うことで、AI 資産の品質も高まります。
反対に、蓄積された AI 資産が調査、整理、初稿作成、反復処理を支援することで、人は顧客理解、創造、対話、意思決定といった高付加価値な領域へ集中できます。
このように、人がより高付加価値なコア業務に集中できる状態こそが生成AI 導入により目指す姿だと私は考えています。

この循環を成立させるためには、次の情報を組織の学習資産として保持する必要があります。

• AIへ何を意図して依頼したか
• どの情報やツールを利用したか
• 人がどこを修正したか
• 何を良い成果と評価したか
• どの判断を採用し、どの判断を棄却したか
• どの条件で成功し、どの条件で失敗したか
• 次回どのように改善するか

これらを外部サービスや個人のチャット履歴だけに閉じ込めると、AI を使うたびに学びは生まれていても、その学びを自社の競争力として再利用できません。

生成AI 時代に守るべき資産は、データだけではありません。
評価、修正、判断、成功・失敗、ナレッジ更新の仕組みまで含めて、組織固有の知的資産として管理する必要があります。

3. 人の役割は、実行から委任・評価・統合へ移行する

生成AI 活用が成熟するほど、多くの知識労働者は、すべての成果物を自ら直接作る働き方から、AI や他者へ仕事を委任し、その結果を評価・統合する働き方へ移行していきます。

この役割を私は、AI PM あるいは AI オーケストレーターと表現しています。

ここでいう AI PM は、管理職やプロジェクトマネージャーという職種名ではありません。
自分の仕事を進める際にも必要となる実務能力です。

具体的には、次の能力が求められます。

1. 仕事の目的を定義する
2. 目的から逆算してタスクを分解する
3. 人、Copilot、Cowork、Skills、Agent、Power Automate などを利用した自動化へ適切に委任する
4. 利用可能な情報、制約、禁止事項を明示する
5. 完了条件と評価基準を定義する
6. 複数の案や結果を比較する
7. 根拠、欠落、矛盾、リスクを確認する
8. 結果を統合し、正式な成果物へ変える
9. 最終的な判断と説明責任を担う
10. 成功・失敗から得た学びを次回へ残す

これは、単にプロンプトの書き方が上手くなることではありません。
仕事そのものを分解し、人と AI の強みを組み合わせ、最終的な品質と責任を管理する力です。

ただし、全員が Agent Builder や Copilot Studio の開発者になる必要はありません。

全員に必要なのは、AI へ任せる仕事と、人が責任を持つ判断を切り分ける力です。
Agent や Skills を作る役割、Copilot Studio で組織エージェントを設計する役割、全体の標準やガバナンスを設計する役割は、専門性や職務に応じて一部の人材が担うことでも十分組織は回ると思います。
全員にこれらのスキルをすべて身に着けさせようとするのは、教育コストの観点からも好ましくないと思います。

4. 全社統制と現場の自律を両立する組織構造

中規模以上の組織で生成AI を展開する場合、中央組織がすべてを作成・承認する中央集権型では、AI CoE や IT部門がボトルネックになってしまいます。

一方で、各部門へ完全に任せると、重複開発、品質差、所有者不在、セキュリティリスク、コスト増加などの問題が起こってしまいます。

そのため、全社共通の戦略、基盤、ガードレールを AI CoE などの中央部隊が整備し、現場が業務に近い場所で実験・改善するフェデレーテッド型の組織が適していると思います。

中央部隊は、次の役割を担います。

• 経営方針と投資の優先順位
• AI CoE による共通原則、標準、参照アーキテクチャ
• IT・セキュリティによる環境、権限、接続、監査
• 評価基準、リスク分類、公開・廃止ルール
• 共通テンプレート、共通 AI 資産、ナレッジ基盤
• コスト、ライセンス、利用状況の可視化
• 教育、チャンピオン制度、コミュニティ支援

現場側は、次の役割を担います。

• 業務課題の発見
• 小規模な試行と検証
• 業務固有のナレッジや例外の整理
• AI 資産の改善
• 成功・失敗事例の共有
• 業務成果の評価
• CoE へのフィードバック

AI CoE は、何でも作る中央開発部門ではありません。

全社共通の方向性を示し、現場が安全に実験できる土台を提供し、部門を越えて再利用できる資産を選定・標準化する役割を担います。

中央が方向性とガードレールを持ち、現場が実験・改善を担うことで、統制とスピードを両立できるようにします。

5. Microsoft 365 Copilot　エコシステムは管理モデルで使い分ける

Microsoft 365 Copilot、Agent Builder、Copilot Cowork、Copilot Studio は、機能・技術として単純な上位・下位の関係ではありません。

誰が利用し、誰が所有し、どのように共有・更新し、どこまで継続保守するかが異なる実行・管理モデルです。

Microsoft 365 Copilot

Microsoft 365 Copilot は、個人を主な操作主体とし、Copilot Chat、Excel、Word、PowerPoint、Outlook、Teams などの日常業務で、検索、要約、下書き、分析、会議支援を行う基盤です。

個人の生産性向上を中心とするが、組織のデータ、権限、業務文脈の中で利用されるため、完全に個人だけに閉じた仕組みではありません。
少々乱暴に定義すると、Work IQ のことですね。

Agent Builder

Agent Builder は、個人が短期間でカスタムエージェントを作成し、限定的に共有する用途に適しています。

共有を「限定的」としている理由としては、共有先へ共同編集権限を付与できず、通常の保守が単一所有者へ依存してしまうからです。
管理者による所有権の再割り当ては可能でも、継続的な共同保守、開発・検証・本番の分離、ALM などには向いていません。

したがって、個人利用、短期プロジェクト、検証、使い捨てエージェントには適しますが、異動・退職後も維持する重要な組織エージェントには原則として利用しないほうがよいです。

1点留意しておきたい点として、現状 Teams の特定のチャットや会議をナレッジとして Agent を作成したい場合は Copilot Studio では行えず、Agent Builder を利用する必要がある。という点です。
※コネクタうまい事使えばできなくもないですが。

Copilot Cowork

Cowork は、個人が複数工程の仕事を Copilot へ委任する実行環境です。
タスクはローカル上ではなく、クラウド上で処理されます。

Skills や Plugins によって、専門的な仕事の方法や Microsoft 365 外部サービスを再利用できます。
一方で、実行量に応じてコストが発生するため、利用者、用途、上限、予算、反復処理の標準化を管理する必要があります。

個人の AI 実行力を高める仕組みであり、チーム共同編集のためのプロジェクト管理基盤ではない点に注意が必要です。

Copilot Studio

Copilot Studio は、組織として継続利用するエージェントを、Power Platform 環境の、権限、ソリューション、ALM、公開、監視の仕組みの中で管理することが可能なサービスです。

複数人で保守する、業務品質へ影響する、異動・退職後も維持する、外部システムを操作するといったエージェントは、Copilot Studio で管理することが比較的適しています。

製品は機能数だけで比較せず、利用主体、所有、共有、更新、継続保守、コスト、ガバナンスの要件から選定する必要があります。

6. AI 資産は段階的に育て、組織標準へ昇格させる

すべての AI 活用を最初から全社標準として管理する必要はありません。

現場が自由に試せる余地を残さなければ、新しい使い方や価値ある業務改善は生まれにくいからです。

一方で、個人の試作を無秩序に許可・共有すると、所有者不在、重複、品質不明、セキュリティリスク、更新停止、コスト増加が起こってしまいます。

そのため、AI 資産を段階的に育てる必要があります。

レベル0：個人の試行

個人が Copilot Chat、単発のプロンプト、個人用 Agent Builder などを利用し、業務上の価値と課題を確認する。

レベル1：チーム共有

再利用可能な指示、テンプレート、Skill などとして整理し、限定的な範囲で共有する。
利用期間と所有者は明確にする。

レベル2：部門候補

複数人が継続利用し、業務品質やコストへ影響する場合、正式な評価対象とする。
所有者、保守担当者、評価基準、リスク、利用データ、公開範囲を定義する。

レベル3：全社標準

複数部門で再利用する資産は、Copilot Studio、管理対象 Plugin、正式ナレッジ、テストセット、RACI、ALM、監視を備えた組織資産として運用する。

昇格の判断では、次の観点を確認する。

• 明確な業務成果がある
• 他者や他業務で再利用できる
• 品質・安全性が評価されている
• 所有・更新・サポートを継続できる
• コストが価値に見合っている
• 異動・退職後も維持する必要がある
• 機密情報や外部システムを扱う
• 監査・説明責任がある

AI 資産の価値は、作成されたことではなく、再利用でき、保守でき、学習ループへ接続できることによって決まります。

7. 実践からナレッジを生み、次の仕事へ戻す

AI を実行して成果物を作っただけでは、その成果は組織としての能力にはなりません。

組織として学習を成立させるには、実行結果を記録し、評価し、学びを抽出し、次の業務へ再利用する必要があります。

学習ループは、次の流れで構成するとよいでしょう。

1. 実行する
   AI を活用して業務成果を作る。

2. 記録する
   指示、利用情報、出力、人の修正、採用・不採用の判断を残す。

3. 振り返る
   成功・失敗の原因、適用条件、例外、リスクを分析する。

4. 学ぶ
   繰り返し利用できるパターン、判断基準、注意点を抽出する。

5. 評価する
   人が事実、妥当性、品質、安全性、業務文脈を確認する。

6. 再利用する
   ナレッジ、Skills、エージェント、業務フロー、教材へ反映する。

生成AI は、ログから論点を抽出し、情報を分類・要約し、過去の評価結果と照合し、ナレッジ候補を作る支援ができます。

しかし、文脈、妥当性、正式化、説明責任、更新・廃止の判断は、人が担う必要がある。

この循環では、「業務」、「AI 資産」、「ナレッジ」、「教育・人材」の4つのライフサイクルを接続します。

業務  
→ ログ  
→ ナレッジ  
→ AI資産  
→ 教育  
→ 次の業務

学習ループの目的は、ログを集めることではありません。
検証された知識を次の仕事、AI 資産、教育へ戻し、組織としての能力を継続的に高めることです。

8. セキュリティとガバナンスは継続的に更新する

ガバナンスは「導入前に一度行うチェック」として扱うのではなく、現在の利用状況と技術の高度化に応じて継続的に更新する必要があります。

導入フェーズで整備されるべきだった基盤

• SharePoint、Teams、OneDrive の権限
• 組織全体共有、共有リンク
• サイト、データ、AI 資産の所有者
• 異動・退職時の権限変更
• DLP、秘密度ラベル、保持・廃棄
• 監査ログ
• Connectors の管理
• エージェント作成・共有ポリシー
• 利用規程、管理責任者、ライセンス対象者

導入済みであっても、実施済みと仮定せず、技術アップデートや利用状況の変化に合わせて再点検する必要があります。

運用・定着化で継続すること

• 権限の定期点検
• Agent Builder、Skills、Plugins、Copilot Studio の棚卸し
• 所有者不在資産の検出と移管
• 共有範囲の見直し
• ナレッジ鮮度の確認
• AI 資産品質の評価
• 利用状況とコスト監視
• インシデント対応
• 教育内容の更新
• 不要資産の停止・廃止

高度化に伴い追加する統制

• Cowork や Copilot Studio の従量課金
• Plugins、外部 Connectors、外部 API
• Work IQ API / Work IQ MCP
• 外部モデルの利用
• 評価データ、トレース、フィードバック、メモリの評価
• 組織としての学習の知的財産管理

Microsoft 365 Copilot は、基本的に利用者が持つ既存の権限範囲で情報を利用します。

そのため、Copilot が新しい権限問題を作るわけでなく、以前から存在した過剰共有、放置サイト、古い権限を見えやすくする点を理解しておく必要があります。
これは管理者だけでなく、利用者全員が理解しておくべきことです。

安全な定着は、一度きりの導入チェックではなく、導入時、運用、高度化の3フェーズで統制を見直し続ける運用設計によってはじめて実現することができます。

9. 役割、評価、教育、コミュニティ、コストを一体で設計する

生成AI の価値を最大化するには、技術基盤だけでなく、人と組織の運用設計を整える必要があります。

役割と責任

AI CoE がすべてを抱えないよう、RACI チャートなどによって活動ごとの責任を明確にしましょう。

例)

• 経営：AI戦略、投資方針、リスク許容
• 業務責任者：業務成果、優先順位、最終的な業務責任
• AI資産オーナー：品質、所有、更新、廃止
• IT・セキュリティ：環境、権限、接続、監査
• 人事・L&D：役割、教育、評価、リスキリング
• ナレッジ責任者：正式化、鮮度、更新
• 作成者：設計、実装、テスト、改善
• コミュニティ・チャンピオン：現場の知見とフィードバックの循環

評価

評価は、次の4層を分けて測り、学習ループで接続するといいのではと考えています。

1. AI 実行・AI 資産の品質
2. 業務プロセスの成果
3. 組織・事業成果
4. 個人の人事評価

チャット回数、利用日数、トークン数(Copilot Credits 消費量)、エージェント実行回数を、個人の人事評価へ直接使ってはいけません。

利用量は価値を示さず、無駄な利用やコスト増加を誘発する可能性があるためです。

評価すべきなのは、成果物の品質、適切な AI 利用判断、出力の検証、リスク判断、再利用可能な改善、ナレッジ共有、他者支援、組織への波及です。

評価者はその点を理解したうえで、個人の活動や実績を評価する必要があると考えています。
ここは大きくはこれまでの評価基準と変わらないかと思います。
変わるとすると、情報の横展開や他者への支援がこれまで評価項目になかった場合は、新たに付け加えた方がよいのではないか。という点です。

教育

教育は、固定された機能教材と継続学習を分ける必要があると思います。

固定教材として維持するのは、生成AI の基礎、セキュリティ、責任分担、禁止事項、出力検証、主要製品の基本、申請・審査・廃止プロセスです。
これらは変化の激しい生成AI 領域においても比較的教材の更新が少ない要素であると思います。

新機能、モデル、Skills、Plugins、活用事例、失敗事例、AI PM 型の働き方、評価方法、コスト最適化は、技術アップデート、社内コミュニティや実務の状況を通じて継続的に更新する必要があります。
これらは一度学んで終わりではない要素であるので、継続的な学習方法の確立と、教材のアップデート方法の確立が求められます。

コミュニティ

社内コミュニティは単なる交流会の場で終わらせてはいけません。

成功、失敗、疑問、改善案、新機能、再利用可能な AI 資産、組織としての生成AI 活用の評価結果、現場課題を、現場と AI CoE の間で循環させる組織学習のインフラとして構築していく必要があります。

コスト

コストは、固定ライセンス、従量費、運用費へ分ける必要があります。

目的は利用を抑制することではなく、高価値業務へ予算を配分し、反復性の高い処理を標準化し、品質、再利用性、コストを同時に最適化することです。

技術、役割、評価、教育、コミュニティ、コストが連動して初めて、生成AI の力は組織能力として定着していきます。

10. 小さく始め、学びながら継続的に拡大する

生成AI の全社活用を、最初から完成した全社基盤として設計することは現実的ではありません。

製品、モデル、利用方法、課金、リスクは変化し続けるため、組織自身が学びながら管理モデルを更新する必要があります。

フェーズ1：準備・小さく始める

• 現在の利用状況、権限、AI 資産、コストを把握する
• 全社原則とリスク分類を定義する
• 小規模な業務や小規模なチームで試行する
• 成果と失敗を記録する

フェーズ2：試行・評価

• 業務成果と AI 資産の品質を評価する
• 所有者、評価基準、更新方法を設定する
• 再利用可能なプロンプト、テンプレート、ナレッジを整理する
• 特定のチームや部門へ限定的に展開する

フェーズ3：標準化・拡大

• 反復性が高く、複数人が利用する業務を標準化する
• RACI、ALM、監視、教育体制を整備する
• 部門間で再利用する

フェーズ4：全社展開・最適化

• 評価、改善、教育、コミュニティが自走できるようにする
• AI 資産の棚卸しと廃止による、資産の最新化を定常化する
• 品質、リスク、コストを継続的に最適化する
• モデルや製品が変わっても学習資産が残るように設計にする

意思決定者が確認すべきなのは、単に何のサービス導入するかだけではありません。

• AI へ任せる仕事と、人が責任を持つ判断は何か
• どの業務を再設計するのか
• 何を組織固有の知識・判断軸として残すのか
• どの AI 資産を個人利用から組織標準へ昇格するのか
• 品質、コスト、リスクをどう評価するのか
• 学びを次の業務へ戻す仕組みがあるか
• AI 活用が一部の人材へ依存せず、組織能力になっているか

生成AI 活用の成否は、ライセンス数や利用回数では決まりません。

人と AI の役割を再設計し、AI 資産を所有・評価・更新し、現場と CoE の学習ループを接続し、コスト・リスク・価値を同時に管理できるかによって決まります。

AI を導入した組織ではなく、AI を前提として学習し続ける組織こそが、生成AI 時代の競争力を持つと考えています。

まとめ

生成AI時代の組織設計では、次の10点が重要になると考えています。

1. 生成AI 導入を、ツール導入ではなく組織学習システムの構築として捉える
2. 人の能力と AI 資産を相互に強化する
3. 個人の役割を、実行から委任・評価・統合へ広げる
4. AI CoE と現場によるフェデレーテッド型組織を構築する
5. Microsoft 365 Copilot エコシステムを管理モデルで使い分ける
6. AI 資産を個人の試行から組織標準へ段階的に昇格させる
7. 実行結果をナレッジ、AI資産、教育へ戻す学習ループを持つ
8. セキュリティとガバナンスを継続的に更新する
9. 役割、評価、教育、コミュニティ、コストを一体で設計する
10. 小さく始め、評価・改善しながら組織能力として拡大する

生成AI は、単に人の作業を代替する技術ではありません。

人と AI が共に学び、その学びを再利用可能な組織資産へ変えるための技術であると私は捉えています。
組織がその循環を設計できるかどうかが、今後の競争力を左右すると思います。

おわりに

以上がざっくり？私の生成AI 時代における 個人/組織 としての働き方要点です。

働き方といっても機能の使い方ではなく概念的なところの考えですので難しいですね。。。

冒頭でも述べたように、考えが甘いところや突っ込みどころなど満載など思いますので、皆さまの意見も是非伺いたいです。
皆さまのコメントお待ちしております。

Power Apps の Tab 遷移順について

はじめに

私も仕様変更をすっかり失念していて沼に嵌ってしまったので、自戒も込めて Power Apps の Tab 遷移の挙動についての共有です。

公式ドキュメント

learn.microsoft.com

2026年4月現在の Tab 遷移の挙動

まずクラシックコントロールで利用可能な "TabIndex" ですが、こちらは現在 0 より大きい数を設定することはできません。
0 より大きい値を設定したとしても、それは 0 として扱われます。
* TabIndex = -1 は現時点でも機能し、これは Tab 遷移をしない扱いとなります。

現在の Tab 遷移順は、画面上に設定されたコントロールの座標によって制御され、左から右へ、そして上から下へと "Z" 順のパターンで遷移します。

ただし、コンテナはギャラリー、Form のような親コントロール内にあるコントロールは例外です。
これらは画面上の順序に関わらず、親コントロールの順序が来た場合、その中にあるコントロールが続いて順に遷移していく動作となります。

ここで気を付けなくてはいけないのは、この挙動を確認できるのは公開中のアプリのみであるという点です。

開発中のアプリではコントロールを配置した順にタブ遷移が行われてしまいます。

また、X や Y の値が Power Fx 式によって更新されるなど、コントロールが画面上で動的に移動する場合も、ナビゲーションの順序は更新されないため、このようなアプリを作成する場合は注意が必要です。

この挙動は "TabIndex" プロパティが廃止されたモダンコントロールも同様です。

旧設定を利用したい場合

もし "TabIndex" で設定した数値での Tab 遷移を行いたい場合はこちらの"廃止済み"の設定をオンにする必要があります。

おわりに

すっかり忘れてた...

そして確かにググると私が5年前に書いたこの記事がヒットする...
よくない...

koruneko.hatenablog.com

ただ過去のブログを更新する余力は個人にはないのです...

見つけ次第地道にアップデートしていきます。

Power Apps のエクスポートコントロールを PC でも利用する & 2026/01/06 時点の挙動について

はじめに

Power Apps のコントロールには「インポート」や「エクスポート」コントロールがあることはご存知でしょうか？

こちらのコントロールを利用することで、データ(テーブル)を一度ローカルに保存した後、別の Power Apps アプリでそのデータをインポートして利用する。みたいなことができるようになります。

learn.microsoft.com

似たような機能として SaveData 関数 や LoadData 関数 があります。
こちらはいわゆるキャッシュデータの作成/読み込み機能のようなものですね。

learn.microsoft.com

これらの機能のうち、今回は先に紹介した エクスポート/インポート コントロールについての Tips について紹介します。

エクスポート/インポート コントロール

制限事項

ドキュメントでも記載されている通り、こちらのエクスポートコントロールは Web ブラウザーではサポートされていない(利用できない)です。

では PC では利用できないのか？というと必ずしもそういうわけではありません。

PC での利用方法

Web ブラウザーで利用できないだけであって、他の開き方を利用すればこちらのコントロールを PC でも利用することが可能です。

そのやり方は Power Apps のデスクトップアプリケーションを利用するというやり方です。

Microsoft Store では Power Apps のアプリが配布されています。

apps.microsoft.com

こちらを利用することで PC でもエクスポートコントロールを利用することが可能です。

ユーザーに「デスクトップアプリ or モバイルアプリでこのアプリのエクスポート機能は利用してね」というような案内が必要になってきますが、一応運用回避するやり方もあるということを覚えておくと、いざというとき役に立つかもです。

2026/01/06 時点のこちらのコントロールの挙動について

ここまで回避方法を記載しましたが、 2026/01/06 現在、こちらのインポートコントロールは正常に動作していません。

インポートを行っても処理が正常に完了せず、またモニターで確認をすることでエラー原因を特定することもできません。

正直あまり使わないコントロールなので記憶が定かではないのですが、昔は使えたはず...
最近のアップデートによって使えなくなったか、実は今後非推奨になるコントロールの可能性もありますかね。

ここでこれ以上私の推測を話しても仕方がないので、現在 Microsoft に問い合わせ中ですので、続報がわかり次第追記したいと思います。

このことをメモとして記載するためにこの記事書いたまである。

おわりに

Power Apps には色々なコントロールや関数があります。
普段使わないコントロールや関数も試してみることで新たな気づきを得られることもありますので、是非試してみてくださいね。

新年1発目 vibe.powerapps.com で 2026 年を記念したアプリを作成する

はじめに

Happy New Year!

2026 年、新年を記念したアプリを vibe.powerapps.com で作成してみました！

特に技術的な紹介とかしている記事ではないですw
所謂ネタブログ

vibe.powerapps.com に関する記載はこちらをご覧ください。

koruneko.hatenablog.com

2026 年記念アプリを作成する

プロンプト

以下のようなプロンプトを入力しました。

Please create an app inspired by the 2026 Year of the Horse.

そして修正してもらったプロンプトがこちら。

Design an interactive app themed around the 2026 Year of the Horse, blending cultural education, entertainment, and personalization. Key features should include: a dynamic calendar highlighting important dates and traditions related to the Year of the Horse; daily horoscopes and personality insights for users based on their birth year and Chinese zodiac; a virtual horse companion that users can customize, care for, and interact with; educational modules about the symbolism, history, and global celebrations of the Year of the Horse; gamified challenges and quizzes to unlock themed rewards; social sharing options for users to post achievements and festive greetings; and a vibrant, animated interface inspired by traditional Chinese art and modern design. Ensure accessibility, multi-language support, and mobile responsiveness.

Plan

What are we solving for?
Design an interactive app themed around the 2026 Year of the Horse, blending cultural education, entertainment, and personalization. Key features should include: a dynamic calendar highlighting important dates and traditions related to the Year of the Horse; daily horoscopes and personality insights for users based on their birth year and Chinese zodiac; a virtual horse companion that users can customize, care for, and interact with; educational modules about the symbolism, history, and global celebrations of the Year of the Horse; gamified challenges and quizzes to unlock themed rewards; social sharing options for users to post achievements and festive greetings; and a vibrant, animated interface inspired by traditional Chinese art and modern design. Ensure accessibility, multi-language support, and mobile responsiveness.

User roles
general user
Individuals exploring cultural insights, entertainment, and personalized features around the Year of the Horse.
As a user, I need to:

• View a dynamic zodiac-themed calendar so that I can learn about key cultural dates and traditions.
• Access daily horoscope and personality insights based on my birth year so that I can enjoy personalized guidance.
• Customize and interact with a virtual horse companion so that I feel engaged and entertained.
• Complete gamified quizzes and cultural challenges so that I can unlock themed rewards and learn interactively.
• Share festive greetings and achievements on social platforms so that I can celebrate with friends and family.
• Switch between languages so that I can comfortably use the app in my preferred language.
• Navigate an accessible and visually appealing interface so that I can enjoy the content regardless of device or abilities.

content curator
User responsible for updating cultural and educational content, horoscopes, and challenges.
As a user, I need to:

• Update educational modules about traditions and symbolism so that users stay informed with accurate cultural knowledge.
• Publish daily horoscope information so that users receive fresh and personalized insights.
• Create gamified quizzes and challenges so that users remain entertained while learning.

community manager
User managing social interactions, sharing features, and engagement campaigns.
As a user, I need to:

• Monitor and manage social sharing options so that festive messages are safe and appropriate.
• Analyze user engagement trends so that I can provide targeted cultural campaigns.

Agent や Workflow(Agent Flow) の Create はできないんですよねー...

Data

App

言語に日本語がないので追加してみましょう。

日本語追加できた！
でも元から上にあったやつただの飾りになっちゃったけど...？

Vive Power Apps 難しい...

おわりに

2025年、 Vibe Coding はバズワードの1つとなり、恐らく 2026 年はより技術的にできることが増えていくことが予想されますが、 Power Apps での Vibe Coding はまだまだ課題が多そうな印象ですねー...

改めまして、2025 年私のブログを読んでいただけたり、コミュニティイベントに参加してくれた皆さま、そして SNS やリアルで関わっていただけた皆さまありがとうございました。
2026 年も技術情報の発信やコミュニティイベントを開催していきますので、よろしくお願いいたします。
情報発信については、新しい形での発信も予定しており、現在頑張っているところですので、発表を楽しみにしてもらえると嬉しいです。

直近で予定しているイベントとしては Japan Power Platform Community Caravan があります。

jppcc.connpass.com

2026年に開催が予定されているイベント会場は以下です。

• 名古屋会場 2026年1月17日(土)
• 東京会場 2026年1月31日(土)
• 広島会場 2026年2月7日(土)
• 佐賀会場 2026年2月14日(土)
• 沖縄会場 2026年2月21日(土)
• 石川会場 2026年2月28日(土)
• 大阪会場 (検討中)

日本各地で開催し、オンサイト限定のネットワーキングも目的としたイベントです！
ご都合があえば皆さま是非ご参加ください。

それでは改めまして、皆さま 2026 年度もよろしくお願いいたします。

Power Automate の「イベントの更新」で既存出席者には通知を飛ばさないようにする

はじめに

Outlook や Teams では作成したイベントで参加者の追加 or 削除をした場合、更新内容を「追加/削除された出席者のみ」に送付することが可能です。

社内イベントなどで、参加希望者にインビテーションを送付したりするような際、参加者の追加とかはできれば自動化したいーと思うかもしれません。

これを自動化するには、 Power Automate のクラウドフローを利用することになりますが、クラウドフローで実現しようとした際少し工夫が必要になってきます。

今回は、上記のようなフローの作成方法を簡単に紹介します。

フローの作成

利用するアクション

アクションは「イベントの更新 (V4)」を利用して、参加者の追加・削除を行います。

アクションを利用する際に気を付けること

こちらのアクションの必須項目は

• 予定表 ID
• ID
• 件名
• 開始時刻
• 終了時刻
• タイム ゾーン

の6項目です。

learn.microsoft.com

先で紹介したような「参加者の更新を自動化する」というようなシナリオだと、上記必須項目に加えて「必須出席者」の7項目だけ入力を行おうとするパターンが多いと思います。

ただこの7項目だけですと、多くの場合既存参加者にもまとめてイベントの更新通知が送られてしまいます。

原因はよくよく確認すると他の項目が、元の値から変更されてしまっているからです。

「イベントの取得」などで取得した結果と、実行履歴を比較してみてください。

多くの場合参加者情報を表す "requiredAttendees" だけでなく、

• body
• location
• importance
• showAs

の4項目が変化してしまっているかと思います。

まず "body" は「本文」にあたり、なにも設定されていない場合はそのまま本文が空白で更新されてしまいます。

次に "location" は「場所」にあたり、オンサイトイベントで場所を指定している場合はもちろん、 Teams 会議の場合でも「Microsoft Teams 会議」が設定されることになります。
ここも何も指定しないと空白で更新されてしまいます。

"importance" は「重要度」にあたり、なにも設定しない場合はデフォルト値である "low" に設定されてしまいます。
Outlook や Teams でイベントを作成した場合、デフォルトでは "normal" が設定されます。
ここに差異が発生しているのですね。

最後に "showAs" は「表示方法」にあたり、なにも設定しない場合はデフォルト値である "free" = 「空き時間」に設定されてしまいます。
Outlook や Teams でイベントを作成した場合、デフォルトでは "budy" = 「取り込み中」 が設定されます。
ここも同様に差異が発生しているのですね。

上記のように、参加者にも関係ある情報が変化してしまっているので、全員に通知が飛んでしまっているのですね。

従って、これらの値についても元の値と同じ値となるようにアクションを設定してあげる必要があるというわけです。

もちろん、他にもイベントの設定を変更していた場合は同様に同じ値となるようにアクションを設定しなければならないということですね。

まとめ

まとめると、「イベントの更新 (V4)」は

🆖：設定した項目の値のみ更新
🆗：すべてのパラメーターについて値の更新

ということです。

おわりに

このフローは色々なところで利用される割に、自分のブログはもちろん、他のブログなどでもあまり触れらていなかったのでまとめてみました。

【イベント宣伝】今年も Japan Power Platform Community Caravan を開催します！

コミュニティ紹介

Power Platform で【つながる】 【ひろげる】 をテーマにしたコミュニティイベント「Japan Power Platform Community Caravan」を日本各地開催！

コミュニティに参加して日本各地のユーザーとつながり、最新情報や事例を共有し、ネットワークを広げる絶好の機会です。

👉 コミュニティ詳細はこちら：

jppcc.connpass.com

開催場所一覧

名古屋会場

～Power Platformに関わる全ての人のための集い～
Japan Power Platform Community Caravan in 名古屋では、実装の疑問・お悩みをみんなで解決するセッションを開催！
初心者もベテランも歓迎、ネットワーキングで仲間と学ぼう！

📅 1/17(土) 13:30 〜 18:30
📍 日本マイクロソフト 中部支店
👉 詳細はこちら： Japan Power Platform Community Caravan in 名古屋 - connpass

東京会場

~立ち上げ、推進、そして経験者まで。社内コミュニティに関わる全ての人のための集い~
Japan Power Platform Community Caravan in 東京では、社内コミュニティの課題を語り合うラウンドテーブル形式イベント！

📅 1/31(土) 13:00 〜 18:30
📍 品川グランドセントラルタワー
👉 詳細・申込： Japan Power Platform Community Caravan in 東京 - connpass

広島会場

~仲間と学びを分かち合うことを楽しむ時間を一緒に創りましょう！~
Japan Power Platform Community Caravan in 広島では、「Microsoft Power Platform なんでも意見交換会」を開催！

📅 2/7(土) 13:00～17:00
📍 株式会社ビットゼミ
👉 詳細・申込： Japan Power Platform Community Caravan in 広島 - connpass

佐賀会場

~Power Platform お悩み・困りごと相談~
Japan Power Platform Community Caravan in 佐賀では、Power BIのハンズオンを中心に、Power Platformのお悩み相談を行うイベントを開催！

📅 2/14(土) 13:00 〜 17:00
📍 MAIC佐賀(Microsoft Base 佐賀) ](https://maic-saga.com/)
👉 詳細・申込： Japan Power Platform Community Caravan in 佐賀 - connpass

沖縄会場

~Power Platform お悩み・困りごと相談~
Japan Power Platform Community Caravan in 沖縄では、Power BIを中心にPower Platformのお悩み相談が行えるイベントを開催！

📅 2/21(土) 13:00 〜 18:00
📍 沖縄県立図書館　４階ビジネスルーム
👉 詳細・申込： Japan Power Platform Community Caravan in 沖縄 - connpass

石川会場

~Power Platform 活用の一歩を踏み出そう！~
Japan Power Platform Community Caravan in 石川では、Power Platoformの基礎や活用事例を学び、お悩みを相談できるイベントを開催！

📅 2/28(土) 13:00 〜 18:30
📍 マイクロソフトベース金沢
👉 詳細・申込： Japan Power Platform Community Caravan in 石川 - connpass

サポーターの募集について

本イベントではサポーターとなっていただける企業・個人事業主様を募集しております。
サポーターとなっていいただける企業様には以下いずれかのサポートをお願いしたいです。

• イベント会場へのドリンクや軽食類の差し入れのご提供
• 多くの属性の方にイベントを周知していただくためのイベントの告知支援

サポーターとなっていただける企業・個人事業主様は各イベント会場で紹介を行わせていただきます。

※1 差し入れのご提供にて、サポーターとして紹介させていただくのは事前に申し出ていただいた場合に限定させていただきます。
※2 本イベントでは直接的な金銭のやり取りはご遠慮させていただいております。

サポーターとなっていただける場合はこちらのフォームからご応募お願いいたします。
→ https://aka.ms/JPPCC-Supporter

記念グッズについて

JPPCC 2026の開催を記念して、イベント記念Tシャツを作成しました！
興味のある方は各自イベント記念Tシャツよりお好きな商品をご自身でご購入ください。

clubt.jp

※Tシャツの代金はご自身での負担となります。ご了承の程よろしくお願いいたします。

突如現れた vibe.powerapps.com を試してみる

はじめに

日本時間、11/18(火)の午後あたりから、Power Apps のホーム画面を開くと見慣れないポップアップが表示されていました。

learn.microsoft.com

新しい Plan Designer だ！

これは Power Platform Community Conference 2025 で発表された、Plan Designer を利用することで、TypeScript ベースのコードにてアプリが作成される機能のようですね。

早速試してみたので、利用方法やざっくり機能を紹介してみようと思います。

前提条件

現状こちらの機能を利用するためには以下要件を満たしている必要があります。

• 対象の Power Platform 環境が「米国」であること　　
• ブラウザの言語が「英語」であること

Please pick a United States-based environment
The environment "[Your Env Name]" is not set in the United States region or English locale. Please select another environment. Learn more

上記制限があるため、今回の記事のスクショやプロンプトはすべて英語で行っています。

Vibe Power Apps(仮)を試してみる

アクセス

私の紹介したポップアップが表示されていない場合は https://vibe.powerapps.com/ からアクセスすることが可能です。

環境を指定して開きたい場合は https://vibe.powerapps.com/environments/[Your Env ID]/home で直接開くことができます。

画面の紹介

まず最初にアクセスし、またアプリを作成し始める画面がこちらになります。

サンプルを選択すると、サンプルプロンプトが挿入されます。

そして、鉛筆アイコン(Enhance prompt)を選択すると Copilot によって、プロンプトが強化されます。

Before

I want to create an app for employees that helps with hardware requests.

After

Design an employee-facing app for managing hardware requests within an organization. The app should allow employees to browse available hardware inventory, submit detailed requests specifying device type, preferred specifications, quantity, intended use, and urgency. Include options to upload supporting documents or images. Provide real-time notifications for request status updates (submitted, under review, approved, rejected, fulfilled). Enable employees to view their request history and current status. For administrators, implement dashboards to review, approve/reject, assign hardware, track inventory levels, and generate usage reports. Integrate role-based access control, audit logs, and ensure the interface is responsive and user-friendly for both desktop and mobile devices.

結構便利な機能ですね。

"Plans" タブを選択すると、作成したプランを確認することが可能です。

"Apps" タブを選択すると、作成されたアプリを確認することが可能です。

Plan を作成してみる

以下のようなプロンプトを試してみます。

I want to create a task management application. Make it possible to track progress in WBS format, Gantt charts, and Kanban boards.

日本語訳すると、以下のような指示を出しています。

タスク管理アプリを作成したい。WBS形式やガントチャート、カンバン形式で進捗が確認できるようにして。

では、こちらのプロンプトを強化してもらいましょう。

Design a comprehensive task management application that enables users to organize and track project progress using multiple visualization formats: Work Breakdown Structure (WBS), Gantt charts, and Kanban boards. The app should allow users to create projects, define hierarchical tasks/subtasks (WBS), assign resources, set dependencies, and deadlines. Integrate interactive Gantt charts for timeline planning, drag-and-drop scheduling, and progress tracking. Include Kanban boards for workflow management, enabling users to move tasks across customizable columns (e.g., To Do, In Progress, Done). Provide real-time updates, notifications, and collaboration features such as comments, file attachments, and user mentions. Support filtering, search, and reporting on task status, resource allocation, and project milestones. Ensure role-based access control, responsive design for desktop and mobile, and export options for WBS, Gantt, and Kanban views.

日本語訳

包括的なタスク管理アプリを設計してください。このアプリは、ユーザーがプロジェクトの進捗を複数の可視化形式で整理・追跡できるようにします：作業分解構成図（WBS）、ガントチャート、カンバンボード。 アプリでは、プロジェクトの作成、階層的なタスク／サブタスク（WBS）の定義、リソースの割り当て、依存関係や期限の設定が可能であること。 タイムライン計画のためのインタラクティブなガントチャートを統合し、ドラッグ＆ドロップによるスケジューリングや進捗管理を実現してください。 ワークフロー管理のためにカンバンボードを含め、ユーザーが「To Do」「In Progress」「Done」などのカスタマイズ可能な列間でタスクを移動できるようにします。 リアルタイム更新、通知、コメント、ファイル添付、ユーザーへのメンションなどのコラボレーション機能を提供してください。 タスクのステータス、リソース配分、プロジェクトのマイルストーンに関するフィルタリング、検索、レポート機能をサポートします。 ロールベースのアクセス制御、デスクトップとモバイルに対応したレスポンシブデザイン、WBS・ガント・カンバンビューのエクスポートオプションを確保してください。

めちゃくちゃ雑な指示から、必要であろう要件が簡潔にまとめられていますね！

要件をまとめるのが苦手な方でもこれならある程度のアプリが作成できるようになりそうですし、他にも更新された要件を確認することで、今後 Copilot や人に要件を伝えるにあたって、どのような点を押さえて伝えればよいのかの勉強にもなりそうです。

では上記プロンプトで早速 Plan を作成してみようと思います。

ちょっと見た目が変わっているかもしれませんが、なんとなく既視感のある Plan Designer の画面かと思います。

作成完了するまで5分程掛かるのでコーヒーでも飲んで待ちましょう。

作成が完了すると、こんな感じでアプリとコードを確認することができます。

なお、こちらのコードは Read Only なのでコードの編集は少なくとも今時点ではできなさそうです。

ダークモードが欲しいので追加でリクエストしてみます。

ちゃんとシステムに合わせてテーマ変更できる機能まで作ってくれました！

また、特定の要素を変更することもできます。
プロンプト入力欄の左下にある"Toggle inline edits"を選択します。

するとこのような形で要素を指定することができます。

例えばタイトルの要素を指定してみると、こんな感じでその要素に対するプロンプトや、色などを変更できるオプションが表示されます。

こんな感じで特定の要素を手軽に変更できます。

「表示されているタイトルの変更」という一見すぐ終わる指示を出してみましたが、実際はドキュメントの修正など色々関連してやらないといけないタスクがあり、Plan くんはそれを理解したうえでちゃんとやってくれていますね。

指示者がこんだけで終わるだろ。と、現場の意見を聞かずに作業を調整するとダメな例をまさかここで見ることになるとはw

最後に作成された Plan を保存して、公開してみたいと思います。

右上にある見慣れた保存アイコンと公開アイコンがそれですね。

公開を行おうとすると、下書き状態の Dataverse を公開するメッセージと、 Dataverse を選択する画面がでてくるため、 Dataverse を選択のうえ、 Publish を選択します。

公開が完了すると、先ほど紹介した Plan 一覧に表示されるようになります。

従来の Power Apps の画面上でも確認できます。

アプリは Code Apps として作成されていますね。

ソリューションは既定のソリューションに含まれています。

どこでソリューション指定できるんだろうか？？

おわりに

Microsoft Igniteが始まる前に記事を書きたかったので、だいぶ雑な説明になってしまって申し訳ないです。

PPCC では発表されたこれらがいよいよ現実として迫ってきている感がありますね！

news.microsoft.com

Copilot Studio で Web 検索をオンにすることができません

はじめに

いつからこの事象が発生しているのか、またこれが正式な機能変更なのかは定かではないのですが、Copilot Studio の設定から「Web 検索」をオンにして「すべての公開 Web サイトをエージェントが検索できるようにします。」が利用できなくなっています。

learn.microsoft.com

本来あるはずの設定項目

Web 検索が見当たらない

なお、この問題は多くのエージェントで確認できましたが一部エージェントでは確認できませんでした。
謎

回避方法

新規作成時に行える回避

新規作成時に、"特定の操作"を行うことでこの問題は回避することができます。

現在エージェントの新規作成を行おうとすると、「説明」にてチャットベースでエージェントの構築をすることができ、「構成」で「説明」で生成された設定内容を確認のうえ編集することができます。

ここで、「説明」でチャットを行う前に、「構成」を開きます。
これにより「Web 検索」の設定を行うことができるようになります。

ただ、構成で「オン」にしてても実際に作成されるエージェントの設定では「オフ」になっているので気を付けましょう。

「説明」でチャットを行った後に「構成」を開いてしまうと、「Web 検索」の設定がグレーアウトしてしまいます。

この状態で作成を行うと、「Web 検索」の設定項目自体が消えます。

この回避方法は新規作成するエージェントのみにできる対応ですね。

コードベースで修正を行う

Copilot Studio は VSCode を用いてコードベースで編集することが可能です。

やり方など詳しくは以下をご確認ください。

koruneko.hatenablog.com

さて、「Web 検索」の設定項目が見えなくなったエージェントのコードビューをみてみましょう。

みるべき対象のファイルは"agent.mcs.yml"です。

# Name: ユーザーサポート エージェント
# ユーザーの質問や依頼に対して、迅速かつ丁寧にサポートを提供するエージェントです。分かりやすい説明と親切な対応で、ユーザーの課題解決を支援します。
kind: GptComponentMetadata
instructions: |-
  ・ユーザーからの質問や依頼に対して、迅速かつ丁寧に対応すること。
  ・ユーザーが求める情報やサポートを的確に提供すること。
  ・分かりやすい言葉で説明し、専門用語の使用は必要に応じて補足すること。
  ・ユーザーの立場に立って、親切で思いやりのある対応を心がけること。
  ・不明点や追加の要望があれば、積極的に確認し、最適な解決策を提案すること。
  ・安全性やプライバシーに配慮し、個人情報の取り扱いには十分注意すること。
gptCapabilities: {}
conversationStarters:
  - title: 質問への回答
    text: ユーザーからの質問に分かりやすく答えてください。

  - title: 情報提供
    text: ユーザーが求める情報を調べて提供してください。

  - title: 使い方案内
    text: サービスや機能の使い方を説明してください。

  - title: トラブル対応
    text: ユーザーが困っている場合、解決策を提案してください。

  - title: 追加サポート
    text: ユーザーの要望に応じて、追加のサポートを提案してください。

  - title: 安全性の説明
    text: 個人情報の取り扱いについて説明してください。

上記のようになっているはずです。

このうち、「Web 検索」に当たる設定は gptCapabilities: 内にあるはずです。

現在はこちらが空白になっていますね。

gptCapabilities: {}

一応この設定のままエージェントをテストしてみます。

以下のように LLM の一般ナレッジを使用して生成されたことが確認できるかと思います。

では、「Web 検索」をオンにする設定を記載してみます。

「Web 検索」をオンにするには以下の設定を記載します。

gptCapabilities:
  webBrowsing: true

この設定を追加することで、Web 上の画面でも「Web 検索」の項目が復活していることが確認できます。

この設定にて先ほどと同じプロンプトでテストしてみます。

Web からの結果を参照して回答してくれていますね。

最後にコードベースでこちらの設定を false にして「Web 検索」をオフにしてみます。

gptCapabilities:
  webBrowsing: false

すると、Web 上の画面からなんと「Web 検索」の項目が消えていますw

一応こちらでも同じプロンプトを実行してみると、 LLM の一般ナレッジを使用して生成されたことが確認できるかと思います。

おわりに

挙動からして不具合な気がしますね。。。

ただ現行でエージェントを動かしている方や、これから新規作成しようとしている方に支障があると思ったので、回避方法を簡単にまとめておきました。

もうちょっと動作安定してくれないかなぁ。。。

Copilot Studio で環境/エージェントごとにメッセージ消費の制限を行う方法

はじめに

Copilot Studio は Power Apps や Power Automate とは異なり、ユーザーライセンスではなくテナントライセンスとして購入を行うライセンス形態となっています。

www.microsoft.com

そうなってきた場合、環境/エージェントごとなどで利用できるメッセージ数に上限を設けたい！というような要望が出てくると思います。

この記事では 2025/09/01 時点での環境/エージェントごとにメッセージ消費の制限を行う方法を備忘録も兼てまとめたいと思います。

参考文献

• Copilot Studio のライセンス
• Copilot Studio のクォータと制限
• Copilot Studio メッセージとキャパシティを管理する
• 請求レートと管理
• 従量課金制プラン

Copilot Studio の利用制限

作成権限

Copilot Studio で作成したエージェントを利用するには、メッセージパックに値するライセンスをテナントで購入する必要があります。

その他にも、エージェントを作成するにはユーザーに対して以下何れかを割り当てる必要があります。

• Microsoft 管理センター にて Copilot Studio ユーザー ライセンス (無料) を作成者に割り当てる
• Power Platform 管理センター で "Copilot Studio 作成者"ロールを割り当てる
• Microsoft 365 Copilot ライセンス を割り当てる
• (Copilot Studio 試用版ライセンスを割り当てる)

環境ごとに利用可能なメッセージ容量を割り当てる

Power Platform 管理センター にアクセスして、 ライセンス > Copilot Studio を開きます。

こちら

"Manage Copilot Credits" もしくは "セッションの管理" を選択します。

これは現状どちら選択してもそんなに変化はありません。
どちらも環境一覧が表示されますので。

Manage Copilot Credits

セッションの管理

制限を設定したい環境を選択します。

ここでは、テナント内で設定可能なメッセージ数の範囲内で、メッセージの制限や、超過時の挙動、超過の通知を設定することが可能です。

"Copilot Credits" にてその環境で利用可能なメッセージを割り当てることが可能です。
ここで設定したメッセージ数は他の環境による影響を受けることなく利用可能です。 つまり、テナント利用可能なメッセージ容量を超過してもこの環境には影響がなく、また他の環境からここで割り当てられた容量を消費される。という恐れがないということですね。

従って、プロジェクトの予算などでメッセージパックを購入した場合でもこちらの容量を設定するのがよいでしょう。
もちろんテナント全体での容量の割り振りの際でもこちらの設定を利用します。

こちらの設定はデフォルトは0になっています。

"容量の超過" では記載の通りですが、「この環境で容量がゼロに達したときの対処方法を選択します。」

現在設定可能なのは、容量超過時にテナントにプールされている容量を利用するかどうか？となっています。

こちらの設定はデフォルトでオンになっています。

"超過の通知" では、設定したメッセージ容量の X% になったら環境管理者に向けて通知を送信する機能です。

こちらの設定はデフォルトでオフになっています。

その他知っておくとよい制限は以下ですかね。

しきい値の使用量
テナントが前払いキャパシティの 125% に達すると、強制措置がトリガーされます。

超過分への対応 (125%)
カスタム エージェントは無効です。 エージェントを無効にしても、進行中の会話は中断されません。 その後のエージェントの呼び出しの試行はすべて、容量が増加またはリセットされるまで拒否されます。

強制施行された後のエージェントの動作
強制施行がトリガーされ、現在の会話が終了すると、エージェントは無効になります。 エンドユーザーが施行後にエージェントと対話しようとすると、次の応答が表示されます: 「申し訳ありませんが、どのようにサポートしたらいいのかわかりません」

この 125% の制限はあくまでもテナントの容量に対する措置となるようです。

環境ごとに割り当てたメッセージ容量にはこの 125% の措置は適用されないので注意してください。(環境ごとの制限にも適用されちゃうと、容量凄い超過できちゃいますからね。)

エージェントごとに利用可能なメッセージ容量を割り当てる

エージェントごとに利用可能なメッセージ容量を割り当てたい場合は先ほどと同様に、Power Platform 管理センター にアクセスして、 ライセンス > Copilot Studio を開きます。

こちら

"エージェントを管理する" を選択します。

こちらでは公開済みのエージェントが表示される(はず)です。(こちらに関しては公式ドキュメントがどこにあるのかわからなかった)

制限を適用したいエージェントの三点リーダーより "制限を設定する" を選択します。

すると環境ごとの制限時と同じような制限設定が表示されます。

"Copilot Credits" ではそのエージェントで使用可能なメッセージ容量を設定します。

ここで設定可能なメッセージ容量はその環境で利用可能なメッセージ容量の範囲内となっております。

"通知と調整のしきい値" は "Copilot Credits" を設定した場合に設定可能です。

"使用を停止する" にチェックを入れた場合は "Copilot Credits" で設定したメッセージ容量となった場合は対象のエージェントは動作しなくなります。

"超過の通知" は "Copilot Credits" で設定したメッセージ容量の X% となった場合にエージェント所有者に通知を送ります(ここ要検証)。

おわりに

Copilot Studio はエージェントの単純な機能だけでなく、管理回りのアップデートも頻繁に行われています。

まだまだ実運用を行う上では、あの機能もあればいいなーというのが多くあるかもしれませんが(特に管理回り)、日々日々アップデートが行われていますので、ロードマップを確認するなどして、組織やプロジェクトでの Copilot Studio の管理戦略を立てていきましょう。

欲しい機能がこないなーという場合は是非 Issues を挙げてください！