はじめに
Microsoft 365 Copilot のエージェントビルダーに「スキル」を追加できるようになりました。SKILL.md と、テンプレートやスクリプトなどの同梱ファイルを ZIP でまとめてアップロードすると、エージェントがその手順に従って作業してくれる仕組みです。
Agent Builder にスキルを追加する (Microsoft Learn)
※記事執筆時点の公式ドキュメントでは「プレビュー（Frontier プログラム参加組織のみ）」と書かれている一方、メッセージセンター (MC1476977) では一般提供の展開も案内されています。お使いのテナントで「構成」タブにスキルが出てくるかを確認するのが確実かと思います。
以前、以下の記事で Copilot Studio の「ハーネス」と、GitHub Copilot ハーネスについて書きました。
これまで個人的には、エージェントビルダーは「指示文とナレッジで手軽にエージェントを作れるもの」で、それなりに凝ったファイルを作ったり、手順を踏んで処理したりするのは、それ以外の Copilot（例：PowerPoint の Copilot）や Copilot Studio の領域、という認識でした。ただ、スキルが入り、裏でスクリプトも動くとなると、その境目がかなり変わってきます。
そこで、Copilot Studio の GitHub Copilot ハーネスで以前試した検証を、同じ題材・同じ依頼文でエージェントビルダーにも流してみました。今回は、その結果から見えた「エージェントビルダーの進化」と「GitHub Copilot ハーネスとの違い」を整理してみます。
検証の前提
2026年10月時点の検証です。
| 項目 | エージェントビルダー | Copilot Studio |
|---|---|---|
| 作り方 | Microsoft 365 Copilot のエージェントビルダー | 新しい Copilot Studio（GitHub Copilot ハーネス） |
| モデル | 自動（ビルダーではモデルを選べない） | Claude Sonnet 5.5 |
| 指示文・スキル・ナレッジ | 同じものをそろえた | 同じ |
ビルダーはモデルを選べないので、モデルはそろえていません。そのため、ここで書く差は「ハーネスとモデルと、どこまで考えるかの自動判断」をまとめた製品としての差になります。使う側から見ると、これがそのまま実際の差だと思っています。
また、回数は多くありません。資料作成は1回、言い換えの検索は3回ずつ、後半の「考え直しが要るシナリオ」は各1回です。傾向の話として読んでいただければと思います。
エージェントビルダーでできるようになったこと
スキルを ZIP で追加できる
エージェントビルダーの「構成」タブに「スキル」の欄が増えています。「追加」から SKILL.md と同梱ファイルをまとめた ZIP をアップロードすると、指示文やナレッジと並んでスキルが表示されます。
追加したスキルを開くと、SKILL.md の中身（指示）と、同梱したファイルのフォルダー構成が確認できます。今回はスライドの部品集（PowerPoint）、部品カタログ（Markdown）、部品を複製するための Python スクリプトを同梱しました。
シフト作成のエージェントでは、スキル2つと、従業員マスタ・編成ルールの Excel をナレッジ（添付ファイル）として一緒に登録しました。公式ドキュメントでは、プレビュー中は「スキルとアップロードしたファイルのナレッジは併用できない」と書かれていますが、今回の環境では両方を入れて動いていました。
スキルの同梱ファイルがサンドボックスで動く
スキルの ZIP に入れたテンプレートやスクリプトは、エージェントの裏側のサンドボックス（作業用の隔離された環境）に置かれ、Python で読み書きできました。python-pptx（PowerPoint をコードで作るためのライブラリ）も最初から入っていました。
以下は、シフト作成のスキルを読み込んで実行しているところです。
公式ドキュメントでは、サンドボックスはネットに接続できず、パッケージの追加もできないとされています。入っているものだけで動かす前提でスキルを作る必要があります。
宣言型エージェントのカスタムスキル (Microsoft Learn)
テンプレートを書式ごと使う資料作成
Copilot Studio で使っていた「スライドの部品集（37枚）を同梱し、内容に合う部品を選んで複製して文章を差し替える」スキルを、ほぼそのままビルダーに入れてみました。架空の会社の社内イベント企画を、Word 3本の素材から10枚で作る依頼です。
結果、部品集の配色・フォント・図形はそのままで、10枚の資料が出てきました。構成案を表で出して確認を取ってから作る、作ったあとに画像にして見た目を確かめる、といった手順も SKILL.md のとおりに進めていました。
一方で、添付した Word のうち1本がアップロードエラーで読めなかったり、頼んでいない計算値（1人当たりの金額）を足していたりと、細かいところは確認が必要でした。
なお、テンプレートに沿った PowerPoint 資料の作成であれば、PowerPoint の Copilot でも十分にできます。そういう意味では、ただ単に資料を作成するという観点では、多くの生成 AI でほとんど差がなくなってきており、それ自体はもう差別化にならないくらい一般化してきた印象です。
ここで紹介したかったのは「ビルダーで資料が作れるようになった」こと自体よりも、テンプレートやスクリプトをスキルとして同梱し、決めた手順どおりに処理させられるようになった、という点です。
リストを全件取り込んでの検索
6,500件のクレームを入れた SharePoint リストをナレッジにして、「該当するクレームを全部出して」と頼む検証も流しました。
ビルダーは、リストをサンドボックスで表として全件読み込み、コードで絞り込んでいました。以下は「精密ギアボックス GB-200 で異音が出たクレームを全部」と頼んだときの回答です。「コーディングと実行」を開くと、リストを CSV として読み込み（pd.read_csv('ClaimRecords.csv')）、製品名と内容の語で絞り込んでいることが分かります。正解の22件をすべて返していました。
「動作不良で重大度が高く、まだ完了していないもの」のように3つの条件を掛け合わせた質問も、使った条件を書いたうえで正解の14件を返しています。
このように、製品名・顧客名・期間・重大度などの列で絞る質問は、件数まで正確に取れていました。該当がない質問には「該当なし」と答え、似た別の不具合を当てはめることもありませんでした。
以前のナレッジ検索（RAG：質問に近い行を検索で拾って読む方式）では「全件を返す」ことが苦手だったので、個人的にはここが一番大きな進化だと感じています。この点は Copilot Studio の GitHub Copilot ハーネスも同じで、どちらもリストを CSV として取り込んで解析する形で動いていました。
※そもそも以前はリストをナレッジに追加できなかったり、追加できても精度がいまいちだったりしました。それを踏まえると、かなり進化したと思います。
表記ゆれのある製品名で探す、「原因は1つのはず」という間違った前提を正す、といった質問も、ビルダーは数字を正しく返していました。
決まったルールでの組み立て
シフト作成（生産計画・休暇希望・従業員マスタから、編成ルールに沿って1週間分を組む）も試しました。ビルダーは、スキルの検証用スクリプトで自分の案を確かめ、2回流してどちらも必須ルールの違反は0件でした。
1回目は、スキルに付属の組み立て処理では資格の条件が足りないと判断し、最適化の処理を自分で書いて組み直していました。
確認の質問に答えてから2分10秒ほどで、検証結果つきの回答と、シフト表・調整メモ・出勤依頼メモの3つのファイルが出てきました。必須違反0件、延べ人数52名/52名と報告しており、出力されたファイルをこちらで別のスクリプトで確かめても、ルール違反はありませんでした。夜勤回数の偏りが目標を超えていることも、隠さずに書いています。
2回目は手で直しながら進め、結果も少し変わりました。回によって解き方は変わるものの、ルールが決まっていて、正しさをスクリプトで確かめられる仕事であれば、ビルダーでもここまでできるようになった、というのが今回の実感です。
Copilot Studio のほうが得意ではないかと感じた場面
ここまで見てきたとおり、ビルダーでできることはかなり広がりました。そのうえで、今回の結果から「こういう時は、Copilot Studio（GitHub Copilot ハーネス）のほうが得意なのではないか」と感じた場面があります。
言い換えの検索
1つ目は、言い方が揃っていない検索です。
| 質問 | 正解 | ビルダー（3回） | Copilot Studio |
|---|---|---|---|
| サーボモーターの「揺れる・ガタつく」系のクレームを全部 | 18件 | 14・14・14件 | 18件 |
| 錆や腐食に関するクレームを製品を問わず全部 | 25件 | 22・22・22件 | 25件 |
ビルダーは毎回「1秒の推論」で、最初に決めた言葉で1回探して答えていました。Copilot Studio は、まず対象の行の書き方の一覧を見てから言葉を決め、結果を見て「この行は錆ではないので外す」「別の言い方でも突き合わせる」と足し引きしていました。
以下は、1件のクレームを起点に「同じ種類の不具合を、言い方が違うものも含めて全部」と頼んだときの Copilot Studio の考えている途中です。防湿袋が破れていた行は錆ではないので外す、書き方の一覧を絞って見る、といった確かめ直しをしています。
同じ依頼で、ビルダーは21件（正解25件）でした。余計な行はありませんでしたが、「白いさび」「めっき面が酸化して黒ずんでいた」の行を取りこぼしていました。
指示文に「書き方の一覧を作って全部読む」「答える前にもう一度実行して照合する」と手順として書いた版も試しましたが、ビルダーの件数は変わりませんでした。件数の確認のような手間の少ない手順は実行される一方、結果を見て探し直す手順は飛ばされていました。
考え直しが要る場面
2つ目は、途中で「おかしい」と気づいて考え直す必要がある場面です。「1回で素直に答えると外れる」ように作ったシナリオを2つ、両方に流しました。どれも正解は、元データから事前に計算して確かめてあります。
シナリオ1：材料の食い違い
シフト作成のエージェントに、生産計画・休暇希望・前月実績の Excel を添付して依頼しました（従業員マスタと編成ルールはナレッジに登録済み）。
10月5日の週のシフトを組んでください。ファイルを添付します。
添付した材料には、次の3つの食い違いを仕込んでいました。
- 土曜日の備考は「土曜は日勤のみ」なのに、夜勤の必要人数が2名になっている
- 日曜日の区分は「休止（設備メンテナンス）」なのに、日勤の必要人数が4名になっている
- 休暇希望に、従業員マスタにいない社員の希望休が入っている
人に頼めば、組み始める前に「ここはどちらが正しいですか」と確認が入る場面です。
シナリオ2：条件の後出し
食い違いのない材料でシフトを組んでもらったあと、同じ会話で条件を2回続けて足しました。
鈴木さん (EMP-02) が急病で、10/8 と 10/9 は休みになりました。この週のシフトを組み直してください。
さらに、加藤さん (EMP-10) は今週は夜勤に入れなくなりました。組み直してください。
2つ目の条件を足すと、夜勤に入れる検査員が1人だけになります。編成ルールには「各直に有資格者を1名以上」「夜勤の翌日は休み」があるため、同じ人が2晩続けて入ることはできず、必須ルールをすべて守る組み方はありません（事前に計算で確認済み）。「組めません」と返すのが正解の問題です。
結果
| シナリオ | Copilot Studio | ビルダー |
|---|---|---|
| 1：材料の食い違い | 組み始める前に食い違いを3つとも指摘し、どちらで組むかを確認した | 確認せずに組んだ。食い違った人数をそのまま信じて表を作った |
| 2：条件の後出し | 「この条件ではルールを守った組み方がない」と理由つきで返し、表は作らずに判断を求めた | 「必須ルールの違反0件」と報告し、実際には検査員のいない夜勤の表を出した |
シナリオ2の1つ目の条件（鈴木さんの急病）でも差が出ていました。Copilot Studio は足りない人数を正直に返して選択肢を示した一方、ビルダーは前回のシフト表を見失って「添付してください」と聞き返し、組み直した表も夜勤が1名足りないままでした。
一番差が大きかったのは、2つ目の条件（解けない条件）です。Copilot Studio は、夜勤に入れる検査員を1人ずつ数えて「2晩は必ず検査員がいなくなる」と説明し、手で3回組み直したうえで、さらに約3万通りを自動で探して確かめていました。そのうえで「新しいシフト表はまだ作っていません。前回のファイルは今回の条件には使えません」と書いています。
ビルダーは、同じ条件で表を作り、「必須違反0件」と報告していました。
業務で一番困るのは「組めたように見えて、実はルール違反」というケースだと思います。今回それを避けられたのは Copilot Studio のほうでした。
なお、表記ゆれや間違った前提の質問では、ビルダーも数字は正しく返していましたが、Copilot Studio は「表記を読み替えた」「16件はすべて同じ製品」のように、聞かれていないが判断に役立つことを書き添えていました。ここにも同じ傾向が少し出ていたように思います。
個人的な考察：得意不得意を分けるのは「計画の立て直し」ではないか
ここからは個人的な見立てです。
ビルダーでできることが広がった理由は、GitHub Copilot ハーネスと同じように、サンドボックスでデータを表として取り込み、コードで解析するようになったからだと考えています。全件を数える、列で絞る、ルールどおりに組んで確かめる、といったことは、ビルダーでも十分にできるようになりました。
そのうえで、Copilot Studio のほうが得意ではないかと感じたのは、結果を見て「おかしい」と気づき、計画を立て直す必要がある場面です。言い換えの検索、材料の食い違い、解けない条件は、どれも「言われていないことに気づいて、止まる・疑う・探し直す」必要がありました。
検索について、もう少し補足します。RAG のようにベクトルの索引を使う方式は、意味の近いものを索引側が拾ってくれる反面、全件は返しにくいという認識です。全件を取り込んでコードで調べる方式は、網羅性は非常に高くなりましたが、意味の近いもの・言い換えを拾えるかは、エージェントが近い言葉を考えて探し、結果を読んでやり直す仕組みにかかってきます。
つまり、全件型で「本当に欲しい情報が見つかるか」は、この見直しのループを回すかどうかで決まる、と考えています。GitHub Copilot ハーネスは、その分時間もクレジットも多く使います。
クレジットの面では、シフトの考え直しシナリオ（材料の食い違いと条件の後出し）を流した会話で、画面の表示は約105クレジットでした。1回の依頼ではなく、確認への返答や条件の追加を何度か重ねた会話全体の値です。参考までに、今月の検証で同じエージェントを何十回と流した合計は、シフト作成のエージェントで約484クレジット、クレーム検索のエージェントで約397クレジットでした。繰り返し試した回数を考えると、個人的には思ったよりは抑えられている印象です。
指示文で手順として書くことで、ある程度は埋められると思います。ただ、今回試した範囲では、手順を書いてもビルダーは手間の少ない部分だけを実行していました。指示文で補いつつも、埋めきれない領域は残るのではないかと考えています。
それ以外の差やこの先、差が広がりそうなところ
今回の検証は、チャットで依頼して、渡した材料の範囲で答えを出してもらう仕事でした。
個人的には、次のような仕事になってくると、Copilot Studio のほうが得意な場面はさらに増えてくるのではないかと思っています。
ツール連携・チャット以外のトリガー・複数エージェント
エージェントビルダーは、独自のアクションやコネクタを登録して外部システムを操作することはできません（必要な場合は Copilot Studio にコピーする案内になっています）。
Agent Builder の概要 (Microsoft Learn)
Copilot Studio では、外部システムとの連携、メール受信や時刻などチャット以外をきっかけに動く自律型の仕組み、複数のエージェントをつなぐことができます。AI エージェントに「人の代わりに仕事の一部を任せる」という観点では、ここまでできるかどうかで、任せられる仕事の範囲はかなり変わると考えます。
そして、こうした仕事ほど、途中の結果を見て次の手を決め直す場面が増えます。今回見えた「計画の立て直し」の差は、仕事が長く複雑になるほど効いてくるのではないかと思っています。
ファイルの受け渡し
今回の検証は、利用者がチャットでファイルを添付し、エージェントが作ったファイルをチャットで受け取る、という範囲でした。この範囲でも、ビルダーは会話の途中で「前回作成したシフト表を添付してください」と前の結果を見失う場面がありました。
一方で、業務でエージェントに仕事を任せることを考えると、ファイルの受け渡しはチャットの中だけでは完結しないことが多いと思います。たとえば次のような流れです。
- 決まった場所にファイルが届いたら、それをきっかけにエージェントへ渡して処理させる
- 処理した結果で、元のファイルや別のファイルを更新する
- できあがったファイルを、SharePoint など別の場所にアップロードして関係者に渡す
Copilot Studio の GitHub Copilot ハーネスでは、ワークフローと組み合わせることで、こうした受け取りから処理、更新、別の場所への保存までをつなげられる方向に進んでいる認識です。まだ一部不安定なところもあり、この点は改めて検証が必要だと考えていますが、エージェントの推論とツールを組み合わせて成果物まで届けられるようになると、任せられる範囲はさらに広がるのではないかと思っています。
エージェントビルダーは、現時点ではチャットでの添付と受け取りが中心です。この「ファイルを受け取って、処理して、届ける」までを一連の仕事として任せられるかどうかも、今後の差として出てきやすいところかなと思います。
ハーネス自体の進化の速さ
GitHub Copilot ハーネスは、その名のとおり開発者が日々使っているものがベースになっているため、ハーネス自体の進化が速いと感じています。
対してエージェントビルダーは、裏でどのようなハーネスが動いているのか、公開情報は見当たりませんでした。今回、実行環境のフォルダー構成が Copilot Studio とは違っていたので、別の仕組みで動いているのではないかと思いますが、詳細は分かりません。今後の進化の速さという観点でも、少なからず差は出てくるのではないかと考えています。
それでもエージェントビルダーの進化はありがたい
とはいえ、エージェントビルダーの進化は、非常に多くの人にとってありがたいものだと思っています。
テンプレートを書式ごと使った資料作成や、全件を数える検索が、普段使っている Microsoft 365 Copilot の画面からライトに試せるようになりました。今回の検証でも、ルールが決まっていて正しさを確かめられる仕事は、かなりの水準でこなしていました。
個人的には、まずはエージェントビルダーで「スキルで手順を渡すとここまでできる」を体験し、結果を見て考え直す必要がある仕事や、外部システム・トリガー・複数エージェントが必要な仕事になってきたら Copilot Studio を検討する、という段階的な進め方が現実的かなと思っています。
まとめ
今回は、エージェントビルダーにスキルが入ったことで何ができるようになったのか、Copilot Studio の GitHub Copilot ハーネスと何が違うのかを、同じ題材の検証から整理しました。
- ビルダーでも、データを全件取り込んでの検索、テンプレートを書式ごと使う資料作成、ルールに沿った組み立てと検証まで、できるようになってきた
- 結果を見て気づき、計画を立て直す必要がある場面（言い換えの検索、材料の食い違い、解けない条件）は、Copilot Studio のほうが得意ではないか
- ツール連携・トリガー・複数エージェントまで含めた長い仕事になるほど、その傾向は強まりそう
あくまで2026年10月時点、少ない回数での検証です。私の検証の仕方による部分もあると思うので、「私の手元ではこうだった」といった情報が集まることも期待しています。
本記事が、エージェントビルダーと Copilot Studio の使い分けを考える際のお役に立てば幸いです。