2026 年 10 月時点の情報です。
Microsoft Copilot Studio の画面と挙動、課金の仕組みは変わりやすく、この記事で扱う機能にはプレビュー段階のものが含まれます。
この回で確かめること
この回が、連載の最終回です。
第 1 回から第 3 回の結果をもとに、次のことを確かめます。
- 検証 A から G の結果を、運用の設計にどう生かすか
- 取り次ぎ先の部門エージェントまで含めて、どうデバッグするか
- [評価] タブで、取り次ぎ先の内容が落ちたことを見つけられるか
- この検証に、実際にいくらかかったか
これまでのおさらい
| 回 | 分かったこと |
|---|---|
| 第 1 回 | スキルと指示の正本を Copilot Studio の外に置き、画面ではファイルを差し替えるだけにする構成を組んだ |
| 第 2 回 | ハブのスキルはハブ経由の回答に効く。部門にしかないスキルの効果は、ハブ経由の回答には出なかった (この見方は第 3 回で改めた) |
| 第 3 回 | 部門にしかないスキルは、ハブから呼ばれたときも使われる。届かなかったのは、ハブが回答を自分の見出しに組み直すときに落としていたため。ハブの [プレビュー] は部門エージェントの公開版を呼ぶ |
この回の公開に合わせて、GitHub のリポジトリの検証 F と G の記録に、費用の節を追加しました。
届く場所、届かない場所
第 2 回の表に、第 3 回の結果を加えると、次のとおりです。
| 置いた場所 | 部門エージェントに直接聞いたとき | ハブに聞いたとき |
|---|---|---|
| ハブのスキル | - | 効く |
| ハブの指示 | - | 効く (ただし体裁はハブのスキルが決める) |
| 部門にしかないスキル | 使われることがある | 使われる。利用者に届くかは、ハブの回答の組み立て方で決まる |
| 部門の指示 | 効く | 公開した後は届いた (ハブにスキルがない構成で確かめた) |
| 部門のナレッジ ソース | 効く | 効く (事実はほとんどの回で保たれる) |
言えること、言えないこと
言えること
- 部門にしかないスキルも、ハブから呼ばれたときに使われる。ただし、利用者に届くかはハブが回答をどう組み立てるかで決まる。
- ハブの [プレビュー] は、部門エージェントの公開版を呼ぶ。部門を変えたら、公開してから試す必要がある。
- 取り次ぎ先で何が起きたかは、推論カードの Used tool、部門エージェントの [履歴]、Application Insights で確かめられる。
言えないこと
- ハブがいつ回答を組み直すか。回答の構成を決めるスキルがなくても、組み直して内容を落とすことがあった。
- どう書けば落とされずに済むか。ハブのスキルに「削らない」と書くなど、書き方の工夫は試していない。
- これらが今後も変わらない仕様なのか。接続エージェントは、GitHub Copilot ハーネスではプレビュー段階の機能です。
回数や条件の詳細は、第 3 回とリポジトリの tests/records/検証G.md にまとめています。
設計への影響
ハブと部門エージェントの構成でスキルを運用するなら、次のように組みます。
| 変えたいこと | 書く場所 | 根拠 |
|---|---|---|
| 全部門に共通の体裁や決まり | ハブのスキル (1 か所) | E-01 |
| 部門ごとの振る舞いで、確実に利用者に届けたいもの | ハブの共通スキルの中の「部門ごとの」節 | E-03 |
| 部門ごとの振る舞いで、部門の側に置きたいもの | 部門のスキル。ただし、ハブの回答の構成の中に、その内容が収まる場所があるかを確かめる | G |
| 知識 (規程、手順、表) | 部門の SharePoint の published フォルダー |
A から D |
| 部門の受け持ち | 接続するときの説明文 | D |
| 部門エージェントの指示 | 事実の扱い方 (根拠に基づく、条件を落とさない、など) | E-03 |
| あいさつ文 | [...] > [設定] > [あいさつとプロンプト] に直接書く | E-02 |
部門ごとの振る舞いをハブの共通スキルに書く場合は、1 つ割り切りが要ります。
第 1 回では、部門を増やしてもハブの指示を変えずに済む形を目指しました (検証 D)。
共通スキルに部門ごとの節を書くと、部門を増やしたり変えたりするたびに、ハブの共通スキルも直すことになります。
それでも、直すのはスキルのファイルで、ハブの指示ではありません。
正本を Copilot Studio の外に置き、画面では差し替えるだけという運用は、そのまま保てます。
部門ごとの記述を「部門ごとの」節の中だけにまとめておけば、直す場所はそこだけで済みます。
部門のスキルに置く場合は、ハブの回答の構成を先に決め、部門のスキルが足す内容をその構成のどこに入れるかまで設計します。
末尾に 1 文を添えるだけの内容は、ハブの見出しのどこにも当てはまらなければ落ちます。
判定を検証 A から G でまとめると、次のとおりです。
| 検証 | 判定 |
|---|---|
| A 口調 | 合格 (条件付き) |
| B エスカレーション | 合格 (条件付き) |
| C 部門固有の手続き | 不合格 (ハブ経由) / 合格 (直接)。部門を公開し直していない条件での結果 |
| D 部門の追加 | 合格 |
| E 境目 | 合格 (E-01、E-03) / 不合格 (E-02) |
| F 書き方か仕組みか | どちらでもない。ハブが回答を組み直すときに落としていた (G で特定) |
| G 取り次ぎ先の確認 | 部門のスキルは使われる。ハブの [プレビュー] は部門の公開版を呼ぶ |
| 総合 | 成立する。ただし、利用者に届くかはハブのスキルが決める |
取り次ぎ先までデバッグする方法
運用に入れた後も、スキルが効いているかは定期的に確かめます。
とくに、機能が更新されたときは、同じ質問を投げ直して、上の表のとおりかを確かめてください。
| 方法 | 見えるもの | 注意 |
|---|---|---|
推論カードの Used skill:
|
そのエージェント自身で使われたスキルの名前 |
[プレビュー] で回答の上の推論カード (見出しは Thought for N seconds) を開く (エージェントをテスト (GitHub Copilot))。以前の表記は Loading skill:。[履歴] から開いた会話にはスキルの行が残らないので、投げた直後に見る |
| 推論カードの Used tool | ハブが部門に渡した依頼と、部門が返した回答 | エンド ユーザー プレビュー をオフ (既定) にしておく。部門で使われたスキルの名前は出ない |
| 部門エージェントの [履歴] | ハブから呼ばれた回のセッション (依頼文、部門の回答、消費したクレジット) |
Used skill: の行は残らない |
| Application Insights | ハブ、部門、ナレッジ検索のつながりと、各段の入出力 | 次の節を参照。スキルの読み込みは記録されない |
| 回答の目印 | 検証 F のように、スキルの本文で回答に決まった 1 文を書かせる | ハブが落とすと見えなくなる。Used tool や [履歴] と組み合わせる |
| [監視] タブ | エージェントが消費した Copilot クレジット | この検証では、公開前に開いたときは指標が空だった。Microsoft Learn では、プレビューと評価で使った分も含め、確定値は数時間以内に [監視] に反映され、[監視] の値が請求の基準とされている (推定クレジット使用量の理解)。この検証の実測では、数時間から 1 日ほど遅れて反映された |
画面の表記は、2026 年 10 月時点で確かめたものです。
Application Insights で見えたもの
Power Platform 管理センターのデータのエクスポートで、環境のテレメトリを Application Insights に送れます (Application Insightsを用いた環境レベルのテレメトリ(プレビュー))。
マネージド環境と Azure のサブスクリプションが前提です。
新しく設定したときは、届くまで最大 24 時間かかります。
この検証でも、設定から 1 時間以内の会話は届かず、1 日以上たってから投げた会話が届きました。
検証 G の構成で、ハブの [プレビュー] から 2 問を投げました。
1 問 (1 ターン) は、dependencies テーブルの次のスパンになりました。
InvokeAgent ハブ (ルート)
├ ExecuteTool 人事 (gen_ai.tool.type = agent) … tool.call.arguments に依頼、tool.call.result に人事の回答
│ └ InvokeAgent 人事
│ ├ ExecuteTool DataverseFileAttachment × 3 から 6 … ナレッジの検索
│ └ OutputMessages 人事 … 人事の回答
└ OutputMessages ハブ … 利用者への最終回答
ハブと人事のスパンは同じ operation_Id でつながり、operation_ParentId で親子をたどれました。
| 質問 | ハブの ExecuteTool の結果 (人事が返した回答) | 人事の OutputMessages | ハブの OutputMessages (最終回答) |
|---|---|---|---|
| 有給は半日単位で取れますか | 整理番号あり | あり | あり |
| 通勤手当の上限はいくらですか | 整理番号あり | あり | なし |
画面を開かなくても、テレメトリだけで、どの段で内容が落ちたかを特定できました。
運用に入れた後、利用者の会話をまとめて調べるときに向いています。
一方で、次の点に注意が要ります。
- スキルの名前は、どのスパンにも出てきません。スキルが使われたかは、回答の中身から判断します。
- 属性の中の日本語は
\uXXXXの形にエスケープされているため、日本語の文字列でcontainsを使っても当たりません。英数字 (この検証では整理番号) で探します。 - Microsoft Learn には、接続エージェントの一部のシナリオで親子関係が正しく対応しないこと、大きな内容は切り捨てられることがあると書かれています。
使ったクエリは、リポジトリの tests/records/検証G.md に載せています。
[評価] タブで見つけられるか
[評価] タブでは、テスト用の会話をまとめて流し、回答を採点できます (エージェントを評価する (プレビュー))。
2026 年 10 月時点で、GitHub Copilot ハーネスで使えるテスト方法は「全般的な品質」だけで、期待する回答との比較はしません。
この連載の検証 A から F では使っていませんでした。
運用で回帰テストに使えるかを見るため、検証 G の構成で試しました。
テスト セットは、リポジトリの tests/eval_F再現.csv の 5 問 (人事の 4 問と、担当窓口への引き継ぎを確かめる B-01) です。
| 回 | ハブの tone-and-format
|
合格 | 人事の 4 問で、整理番号がハブの最終回答に届いた |
|---|---|---|---|
| 1 | あり | 5 / 5 | 0 / 4 |
| 2 | あり | 4 / 5 (B-01 が失敗) | 0 / 4 |
| 3 | あり | 4 / 5 (B-01 が失敗) | 0 / 4 |
| 4 | なし | 4 / 5 (B-01 が失敗) | 4 / 4 |
分かったことは次のとおりです。
- 全般的な品質は、取り次ぎ先の内容がハブで落ちたことを検出しません。 整理番号が届いた 4 回目も、落ちた 1 から 3 回目も、人事の 4 問の判定と理由は同じでした (合格、「関連性があるように見えます」)。
- 結果の画面で分かるのは、ハブの最終回答と、呼んだスキルと接続エージェントの名前までです。部門エージェントが何を返したかは、部門の [履歴] (チャネル欄が「評価」) で確かめます。
- 設計どおりの引き継ぎ (B-01) は、4 回中 3 回が「未回答の質問が残っています」として失敗しました。判定は実行ごとに揺れます。
- [評価] は保存済みの構成で動きます。画面でスキルを削除しても、保存が終わっていなければ、削除前の構成で採点されました。
[評価] は、構成を変えたときに回答の質が大きく崩れていないかを見る目安には使えます。
ただし、取り次ぎ先の内容が利用者まで届いているかは、Used tool や [履歴] で別に確かめる必要があります。
つまずいたとき
| 症状 | 最初に見るところ |
|---|---|
| 部門エージェントに入れたスキルが、ハブ経由で効かない | まず Used tool で部門の回答を見ます。部門の回答にあれば、ハブが落としています。ハブの回答の構成に収まる場所を作るか、ハブの共通スキルの「部門ごとの」節に書きます。部門の回答にもなければ、部門エージェントを公開したか、description を確かめます |
| 部門エージェントの指示が、ハブ経由で効かない | 部門エージェントを公開したか。公開した後も効かなければ、Used tool でハブが組み直していないかを見ます |
| スキルが使われない (部門に直接聞いたとき) |
description に、いつ使うかがキーワードを含めて書かれているか |
| 差し替えたのに変わらない | [保存] したか。ハブ経由で部門の変更を見るなら、部門エージェントを公開したか |
| [評価] の結果に変更が反映されない | 変更を保存したか。[評価] は保存済みの構成で動きます |
| [評価] では合格なのに、回答に足りない内容がある | 全般的な品質は、取り次ぎ先の内容が落ちたことを検出しません。Used tool か部門の [履歴] で確かめます |
| 表の値だけ回答に使われない | その文書が xlsx になっていないか。SharePoint 経由では Excel のセルを引けません |
| 期待した部門に振られない | 接続するときの説明文の重なり。除外の書き方 |
| 根拠のない質問に答えてしまう | [ナレッジ] に「すべての Web サイトを検索する」が残っていないか |
| スキルを 2 つ入れたのに 1 つしかない | 同時にドロップすると 1 つしか入りません。1 つずつ入れ直します |
| あいさつ文を変えたい | スキルでは変わりません。[...] > [設定] > [あいさつとプロンプト] です |
この検証にいくらかかったか
最後に、第 1 回から予告していた費用です。
| 検証 | 金額 | 内容 |
|---|---|---|
| A から E | 4,734.99 円 | 環境の構築と、検証 A から E のすべて |
| F | 1,148.54 円 | 18 回の質問と、人事エージェントの公開 2 回 |
| G と [評価] | 3,132.09 円 | 公開の確認、検証 F の再現と対照の 18 回、[評価] 4 回、Application Insights の確認の 2 問 |
| 合計 | 9,015.62 円 |
金額は Azure のコスト分析の値 (税抜き) です。
検証 G は、検証 A から F とは別の検証用テナントで行いました。
検証 F の間は、ほかに何も動かしていません。
18 回の質問と公開 2 回で 1,148.54 円なので、1 問あたり約 64 円 (公開の分を含む) になります。
課金は従量課金制です。費用に出たのは Copilot のメーター 1 本だけで、ほかのサービスの費用は出ていません。
検証 G も同じで、Application Insights のデータを受け取る Log Analytics の費用は 0 円でした。
検証 G では、見込みを大きく外しました。
ハブの画面に出るクレジットだけで見積もったところ、接続先の部門エージェントの消費が入っていなかったためです。
| 画面 | 表示されたクレジット | 含まれていないもの |
|---|---|---|
| ハブの [履歴] (ハブ経由の 1 回) | 6 から 21 | 部門エージェントの消費 (部門の [履歴] では、同じ 1 回で 22 から 48) |
| [評価] の「使用したクレジット」(4 回の計) | 44 | 部門エージェントの消費 (部門の [履歴] の「評価」のセッションで計 577) |
接続エージェントの構成では、ハブの画面の数字だけでは費用を見誤ります。
見積もるときは、部門エージェントの [履歴] の数字も足してください。
この検証で分かったことを生かした実際の案件では、同じような構成のエージェントを作成し、プレビューで動作を確かめるまでの費用が 2,000 円弱で済みました。
範囲は違いますが、この検証の構築と検証 A から E (4,734.99 円) の半分以下です。
どこでクレジットを使い、どこは使わずに済むかが分かっていたので、手探りの試行を省けました。
費用を見るうえでの注意です。
| 注意 | 内容 |
|---|---|
| 作り始めた時点から課金される | GitHub Copilot ハーネスでは、公開前の [プレビュー] での試行や評価も対象です (使用率に基づく請求の概要) |
| Microsoft 365 Copilot のライセンスでは賄われない | GitHub Copilot ハーネスのエージェントの使用は、ライセンスに含まれません (GitHub Copilotハーネスを使用してエージェントのコストを管理する) |
| 接続先の部門エージェントも消費する | ハブ経由で呼ばれた回も、部門エージェントの側でクレジットを消費します。ハブの [履歴] や [評価] の画面の数字には含まれません (この検証の実測) |
| 単価 | 従量課金制では、Copilot クレジットあたり 0.01 ドルです (従量課金制メーター) |
| 金額は条件で変わる | 消費するクレジットは、質問の内容、使うモデル、呼び出すツールで変わります。上の金額は、この検証の条件での実績です |
料金は 2026 年 10 月時点の Microsoft Learn の記載と、この検証の実績です。
次に決めること
この検証で、スキルで吸収できることと、できないことの境目が引けました。
実際の運用に入れる前に、次の 3 つを決めておくとよいと考えます。
| 決めること | 選択肢 |
|---|---|
| ハブの回答の構成 | 部門のスキルが足す内容を入れる場所を、構成に用意する / 部門ごとの振る舞いはすべてハブの共通スキルに書く |
| あいさつ文を管理するか | 文面を正本の 1 ファイルとして置き、人が貼り付ける / 変える頻度が低いので管理の対象から外す |
| 部門エージェントの指示をどこまで書くか | 事実の扱い方だけにする。ハブ経由の回答の文体や体裁は、ハブのスキルで決まる |
終わりに
4 回にわたって、Copilot Studio のスキルを差し替えて、エージェントの振る舞いを変える検証を紹介しました。
- スキルと指示の正本を Copilot Studio の外に置き、画面ではファイルを差し替えるだけにする運用は、成り立ちます。
- ハブと部門エージェントの構成では、部門のスキルもハブから呼ばれたときに使われます。ただし、利用者に届くかはハブが回答をどう組み立てるかで決まります。確実に届けたい振る舞いは、ハブのスキルに書きます。
- 部門エージェントを変えたら、公開してから試す必要があります。取り次ぎ先で何が起きたかは、Used tool と部門の [履歴] で確かめられます。
- 例外は、あいさつ文だけです。
モデルの外側にある指示、スキル、ナレッジを設計するという点で、今回の取り組みは「ハーネス エンジニアリング」と呼ばれる考え方に近いものです (Harness Engineering - first thoughts (英語))。
Copilot Studio では「ハーネス」が実行基盤の名前 (GitHub Copilot ハーネスなど) でもあるので、この見方は別の機会にまとめます。
検証に使ったキットは、すべて GitHub に置いてあります。
機能が更新されたら、同じキットで同じ質問を投げ直すことで、結果が変わったかを確かめられます。