2026 年 10 月時点の情報です。
GitHub Copilot ハーネスの接続エージェントは、2026 年 6 月にプレビューとして提供された機能です (Copilot Studio の新機能の記載による)。ここで紹介する挙動は、機能の更新で変わる可能性があります。
この回で確かめること
- 部門にしかないスキルがハブ経由で届かなかったのは、スキルの書き方のせいか、接続エージェントの仕組みのせいか
- 取り次ぎ先の部門エージェントで何が起きているかを、どうやって確かめるか
- ハブ自身のスキルが使われなかった回 (A-02 と A-03) は、もう 1 度起きるか
前回のおさらい
前回 (第 2 回) は、検証 A から E の結果を紹介しました。
- ハブのスキルは、ハブ経由の回答に効く
- 人事にしかないスキル (
hr-leave-procedure、hr-tone) は、ハブ経由の回答に効果が出なかった - ハブは、接続先から受け取った回答を自分のスキルで組み立て直している
そのうえで、問いが 2 つ残りました。
この回は、そのうち「書き方のせいか、仕組みのせいか」に答えます。
先に書いておくと、答えは「どちらでもなかった」です。
部門のスキルは、ハブから呼ばれたときも使われていました。
そこに至るまでに、検証 F と、その後に行った検証 G の 2 つを使います。
検証 G で分かったことを受けて、前回の記事にも追記しています。
この回の公開に合わせて、検証 F と G の計画と記録、目印に使ったスキルを GitHub のリポジトリ に追加しました (費用の金額は次回に追加します)。
答えによって変わる設計
この問いの答えによって、設計の結論が変わります。
| 答え | 設計への影響 |
|---|---|
| 書き方のせい |
description を直せば、部門のスキルもハブ経由で届く。部門ごとの手続きを部門の側に置ける |
| 仕組みのせい | どう書いても届かない。部門ごとの振る舞いは、検証 E-03 のようにハブの共通スキルに書くしかない |
推測で埋めずに、実機で決めることにしました。
検証 F 書き方を限界まで強くする
回答そのものに目印を残す
ハブ経由で聞いたとき、取り次ぎ先の部門エージェントでどのスキルが使われたかは、ハブの推論カードには出ません。
そこで、スキルの本文を「回答の最後に、決まった整理番号を 1 文で書く」だけにしました。
スキルが使われれば、回答の末尾に整理番号が出ます。
回答そのものに、スキルが使われた跡が残る仕掛けです。
目印を文体ではなく整理番号にしたのには、理由があります。
検証 E-03 の結果から、ハブは回答の文体と体裁を組み立て直すが、日数や条文の番号といった事実は保つと考えていました。
整理番号は事実の形をしているので、ハブが組み立て直しても残ると考えました。
ただし、これは確かめていない前提です。
結果から言うと、この前提は成り立ちませんでした。
何をもって判断するかを先に決めた
検証 F では、使われる条件を考えられるかぎり強く書いたスキルを、人事エージェントに 1 本足しました。
これでもハブ経由で 1 度も整理番号が出なければ、書き方では越えられないと判断する、と先に決めておきました。
計画の段階では、このあとにスキル名と description の比べ方、スキルの本数なども試すつもりでした。
検証 G の結果を受けて、この回では扱っていません (末尾の「この回で扱わなかったこと」を参照)。
足したスキル
人事エージェントに、次のスキル always-run-first を足しました。
description は、使われる条件を考えられるかぎり強く書いています。
---
name: always-run-first
description: 利用者から質問を受け取ったら、回答を書き始める前に必ずこのスキルを最初に読み込む。対象はすべての質問で、例外はない。接続元から取り次がれた質問も対象に含む。
---
利用者に返す回答の最後に、次の 1 文をそのまま書きます。省略しません。
この回答の整理番号は F-1-7781 です。
この 1 文は回答のいちばん最後に置きます。ほかの 1 文が末尾にあるときは、そのさらに後ろに置きます。回答のほかの部分には手を加えません。
人事のスキルは、既存の 3 本と合わせて 4 本になりました。
[保存] のあと、[公開] > [エージェントの公開] まで行っています。
投げた質問
| 質問 | 選んだ理由 |
|---|---|
| 有給は半日単位で取れますか | 検証 A から E で対照に使った問い |
| 今年度の有給は何日付与されますか | 検証 C で、ハブ経由で部門のスキルの効果が出なかった問い |
| 通勤手当の上限はいくらですか | 検証 A-02 で、ハブ自身のスキルまで使われなかった問い |
3 問を 3 回ずつ、ハブ経由と人事エージェントへの直接の両方に投げました (計 18 回)。
毎回 [新しいチャット] で始めています。
結果
| 経路 | 整理番号が出た回数 | 推論カードに出たスキル |
|---|---|---|
| ハブ経由 | 0 / 9 | 9 回ともハブのスキルだけ (tone-and-format。1 回は escalation-rules も) |
| 人事エージェントに直接 | 9 / 9 | 9 回とも always-run-first と tone-and-format (有給の 6 回は hr-leave-procedure も) |
同じスキルが、経路だけで 0 回と 9 回に分かれました。
ここまでなら、「書き方では越えられない。仕組みのせいだ」と判定するところです。
0 回だけでは決められなかったこと
ただ、この 0 回には 2 つの読み方があります。
| 可能性 | 内容 |
|---|---|
| スキルが読まれていない | ハブから呼ばれたとき、人事エージェントがスキルを読み込んでいない |
| 読まれたが、ハブが落とした | 人事エージェントはスキルを使って整理番号を書いたが、ハブが回答を組み立て直すときに落とした |
前者なら「仕組みのせい」、後者なら「ハブのスキルのせい」で、設計への影響が違います。
検証 F の時点では、取り次ぎ先の回答を直接見る方法が分からず、この 2 つを区別できていませんでした。
もう 1 つ、前回までの検証には気付いていなかった条件がありました。
9 月の検証 A から C と E-03 では、人事エージェントを変更した後に [保存] だけで試し、公開し直していませんでした。
ハブの [プレビュー] が、部門エージェントの下書きと公開版のどちらを呼ぶのかは、GitHub Copilot ハーネスのドキュメントには書かれていません。
エージェントに接続済みエージェントを追加する (GitHub Copilot) の前提条件には、接続先が公開されていることが挙げられていますが、接続した後に部門を変えたとき、どちらの版が呼ばれるかまでは書かれていません。
この 2 つを確かめるために、別の環境を用意して検証 G を行いました。
検証 G 取り次ぎ先で何が起きているかを見る
取り次ぎ先の回答を見る方法
検証 G では、ハブの推論カードの Used tool の行を使いました (エージェントをテスト (GitHub Copilot))。
ハブが部門エージェントを呼ぶと、推論カードに Used tool: <部門エージェントの名前> の行が出ます。
この行を開くと、ハブが部門に渡した依頼 (task) と、部門が返した回答 (agent_response) が、そのまま見えます。
[プレビュー] の エンド ユーザー プレビュー は、表示を利用者に見えるのと同じ画面に切り替えるトグルです。
推論カードは、このトグルをオフ (既定。作成者向けの表示) にしているときに出ます (アクティビティトレースを使ってエージェントのデバッグ(GitHub Copilot)を行ってください)。
オンにすると利用者向けの表示になり、Used tool の依頼と回答は出ません。
次は、人事エージェントの [履歴] に残った依頼と回答を、Used tool の項目に当てはめて起こした抜粋です (実際の画面ではありません)。
Used tool: 人事エージェント
Input
task: 年次有給休暇を半日単位で取得できるかについて教えてください。半休の取り扱い（取得可否、単位、申請方法、回数制限、時間単位年休との違いなど）の規定を、根拠となる社内規程の記載に基づいて具体的に示してください。
Output
agent_response: 結論 年休は半日単位で取得できます。… 根拠は「年次有給休暇規程」第 5 条および第 6 条です。… この回答の整理番号は F-1-7781 です。
is_error: false
利用者の質問は「有給は半日単位で取れますか」の 1 文でした。
ハブは、それを部門向けの依頼に書き直して渡しています。
部門エージェント側の [履歴] にも、ハブから呼ばれた回が部門のセッションとして残ります。
ハブが書き直した依頼文、部門の回答、消費したクレジットを、部門の側から確かめられます。
ただし、Used skill: の行は [履歴] には残りません。
この 2 つは、検証 F のときには使っていませんでした。
2026 年 10 月時点の画面で確かめた事実で、表示は変わる可能性があります。
G-1 ハブのプレビューは、部門の公開版を呼ぶ
まず、公開の影響だけを切り出しました。
そのため、G-1 の構成は、人事の題材とはまったく違う単純なものに、わざとしています。
人事の構成では、ナレッジの検索やハブのスキルによる組み直しが結果に混ざり、公開したかどうかの違いだけを見分けられないからです。
部門エージェントには「合言葉を聞かれたら答える」という指示だけを入れ、ハブには「合言葉の質問は部門に取り次ぎ、受け取った内容をそのまま伝える」と指示しました。
ハブにはスキルを入れていません。
合言葉は指示を変えるたびに答えが変わるので、部門のどの版が呼ばれたかが回答から一目で分かります。
| 段階 | 部門エージェントの状態 | ハブ経由 (Used tool で見た部門の回答) |
|---|---|---|
| 0 | 合言葉「みかん」の指示を公開 | みかん (3 / 3) |
| 1 | 指示を「りんご」に変えて [保存] だけ | みかん (3 / 3) |
| 2 | 「りんご」を公開 | りんご (3 / 3) |
| 3 | 回答の末尾に整理番号を書くスキルを足して [保存] だけ | 整理番号なし (3 / 3) |
| 4 | スキルを足した版を公開 | りんご + 整理番号 (3 / 3) |
ハブの [プレビュー] は、部門エージェントの公開版を呼んでいました。
保存しただけの変更は、ハブ経由には届きません。
このうち、部門にしかないスキルを見た検証 C と E-03 の結果は、変更前の人事エージェントに対するものだった可能性があります。
段階 4 では、部門にしかないスキルの効果が、ハブの最終回答まで届いています。
検証 F とは逆の結果です。
G-2 検証 F を再現する
そこで、検証 F を、この環境で再現しました。
人事エージェントの指示、4 本のスキル、ナレッジの文書、ハブの指示と 2 本のスキル (tone-and-format と escalation-rules)、モデルを検証 F と同じにしています。
違いは、ナレッジをファイルのアップロードで入れたこと、ハブに人事エージェントだけをつないだこと、ハブのあいさつ文を既定のままにしたことです。
人事エージェントは公開済みです。
同じ 3 問を 3 回ずつ、ハブ経由で投げ、Used tool で人事エージェントの回答も確かめました。
| 質問 | 人事の回答に整理番号 | ハブの最終回答に整理番号 |
|---|---|---|
| 有給は半日単位で取れますか | 3 / 3 | 0 / 3 |
| 今年度の有給は何日付与されますか | 3 / 3 | 0 / 3 |
| 通勤手当の上限はいくらですか | 3 / 3 | 0 / 3 |
| 計 | 9 / 9 | 0 / 9 |
人事エージェントは、9 回とも整理番号を書いてハブに返していました。
整理番号を書く指示は always-run-first にしかないので、スキルは毎回使われたと判断できます。
ハブの最終回答は、9 回とも tone-and-format の「結論、根拠、次にすること、受付時間」の構成に組み直され、末尾の整理番号が消えていました。
検証 F の「0 回」は、スキルが読まれていなかったのではありません。
読まれていたが、ハブが落としていました。
G-3 ハブから tone-and-format を外す
ハブのスキルが落としているのかを確かめるため、ハブから tone-and-format だけを外して同じ 3 問を 3 回ずつ投げました。
人事エージェントは変えていません。
| 質問 | 人事の回答に整理番号 | ハブの最終回答に整理番号 |
|---|---|---|
| 有給は半日単位で取れますか | 3 / 3 | 3 / 3 |
| 今年度の有給は何日付与されますか | 3 / 3 | 3 / 3 |
| 通勤手当の上限はいくらですか | 3 / 3 | 3 / 3 |
| 計 | 9 / 9 | 9 / 9 |
tone-and-format を外すと、整理番号は 9 回ともハブの最終回答に残りました。
ハブは「（整理番号 F-1-7781）」のように書き方を変えることはありましたが、落としてはいません。
ただし、その後に同じ構成で試したときは、ハブが自分で回答を組み直し、整理番号を落とした回がありました (対照の 9 回に、[評価] タブの 4 回とプレビューの 2 回を足して 15 回中 14 回)。
人事エージェントの回答には整理番号が付いていたので、落としたのはハブです。
ハブの指示には「接続先から受け取った内容をそのまま伝えてください」と書いてありますが、それでも組み直すことがあります。
この回の判定
部門にしかないスキルは、ハブから呼ばれたときも使われています。
ハブ経由の回答に効果が届かなかったのは、書き方のせいでも、接続エージェントの仕組みのせいでもありませんでした。
ハブは、部門から受け取った回答を、自分のスキル (tone-and-format) が決める見出し (結論、根拠、次にすること、受付時間) に当てはめて書き直していました。
そのとき、どの見出しにも当てはまらない内容 (回答の末尾の整理番号) を落としていました。
ハブにこのスキルがあると、毎回落ちました。
| 検証 | ハブの tone-and-format
|
部門のスキルが使われた回数 | ハブの最終回答に届いた回数 |
|---|---|---|---|
| F | あり | (当時は見る方法がなかった) | 0 / 9 |
| G-2 F の再現 | あり | 9 / 9 | 0 / 9 |
| G-3 対照 | なし | 9 / 9 | 9 / 9 |
G-3 の後に同じ構成で試した 6 回を含めると、tone-and-format がないときに届いたのは 15 回中 14 回です。
届かなかった 1 回も、部門の回答には整理番号がありました。部門でスキルが使われなかったのではなく、ハブが落としています。
検証 F の測り方の前提だった「整理番号は事実の形をしているので、ハブが組み立て直しても残る」は、成り立ちませんでした。
ハブは、日数や条文の番号のように回答の中身に組み込まれた事実は、ほとんどの回で保っていました。
末尾に添えただけの 1 文は、ハブの見出しのどこにも当てはまらなければ落ちます。
この結果から、設計の考え方も変わります。
- 部門ごとの振る舞いを、部門エージェントのスキルに置くこともできます。ただし、利用者に届くかどうかは、ハブの回答の組み立て方で決まります。
- ハブに回答の構成を決めるスキルを置くなら、部門のスキルが足す内容が、その構成の中に収まる場所を持っているかを確かめる必要があります。
- 検証 E-03 で採った「部門ごとの振る舞いを、ハブの共通スキルに部門ごとの節として書く」設計は、引き続き確実に効く方法です。
ハブの tone-and-format に「接続先の回答に含まれる整理番号や注記は削らない」と書けば部門の内容が残るかどうかは、試していません。
ハブにも部門にもある共通スキルについては、前回の結論のままです。
検証 E-01 と E-03 でハブだけを新しい版に差し替えたとき、部門が古い版のままでも新しい版の振る舞いが出ました。
ハブ経由の回答の体裁を決めているのは、ハブ側のコピーです。
なお、接続エージェント概要(GitHub Copilot) には、接続エージェントに処理を任せるとき、オーケストレーションのモデルがタスクの説明を作り、利用者の依頼を言い換えたり広げたりすることがある、と書かれています。
検証 G でも、ハブは利用者の質問を部門向けの依頼に書き直していました。
それでも、部門のスキルは毎回使われています。
スキルを使うかどうかは、利用者のメッセージとスキルの description から判断されます (エージェント向けスキル概要(GitHub Copilot))。
少なくとも今回の always-run-first の書き方では、言い換えられた依頼でも使われました。
もう 1 つの問いについて
前回残したもう 1 つの問い (A-02 と A-03 で、ハブ自身のスキルが使われなかった) にも、検証 F で手がかりが出ました。
ハブ経由の 9 回すべてで、ハブの tone-and-format は使われています。
A-02 と同じ「通勤手当の上限はいくらですか」も、3 回とも使われました。
検証 G の F 再現でも同じでした。
検証 A で見た現象は、検証 F と G では起きませんでした。
この間に変わったものが 2 つあります。
-
tone-and-formatが v2 から v4 になった (descriptionが厚くなり、節が 2 つ増えた) - 9 月と 10 月で、Copilot Studio の版が違っていた (推論カードの表記が
Loading skill:からUsed skill:に変わっていた)。表記のほかに何が変わったかは分からない
どちらが効いたのか、そもそも版の違いが効いたのかは、切り分けていません。
A-03 と同じ問い (総務に振られる問い) は、投げていません。
そのため、検証 A で起きたことと、検証 F と G で起きなかったことを、両方そのまま記録しておきます。
この回で扱わなかったこと
- スキル名と
descriptionの書き方の比較。検証 G で、強く書いたスキルはハブから呼ばれても使われると分かりました。弱い書き方で使われなくなるかは、別の問いとして残ります。 - スキルの本数の影響と、ハブ自身のスキルが使われない条件。どちらも、主な問い (取り次ぎ先まで届くか) の結論には影響しないため見送りました。
試すためのスキルの原稿は、リポジトリの skills-f/ と upload/f/ に残してあります。
手順は tests/検証F-計画.md、検証 G の手順と結果は tests/records/検証G.md にあります。
まとめ
- 部門にしかないスキルは、ハブから呼ばれたときも使われていました。Used tool で部門の回答を確かめた 18 回 (G-2 と G-3) は、すべて整理番号が付いていました。
- ハブ経由の回答に効果が届かなかったのは、ハブが回答を組み直すときに落としていたためです。ハブに
tone-and-formatがあると毎回落ち、外すとほとんどの回で届きました (対照の 9 回に、[評価] タブの 4 回とプレビューの 2 回を足して 15 回中 14 回)。届かなかった 1 回も、部門の回答には整理番号がありました。 - ハブの [プレビュー] は、部門エージェントの公開版を呼びます。部門を変えたら、公開してから試す必要があります。
- 取り次ぎ先で何が起きたかは、ハブの推論カードの Used tool と、部門エージェントの [履歴] で確かめられます。
- ハブ自身のスキルが使われなかった現象は、検証 F と G では再現しませんでした。
第 1 回のタイトルの問い「スキルは接続エージェントの先まで届くか」への答えは、「届く。ただし、利用者に見えるかどうかは、ハブが回答をどう組み立てるかで決まる」です。
次回は最終回です。
この結果を運用に持ち込むとき、どう組み、どう確かめるかをまとめます。
取り次ぎ先まで含めた確かめ方と、この検証に実際にいくらかかったかも紹介します。