はじめに

以前、Copilot Studio の新しい UI（GitHub Copilot ハーネス）でファイルの入出力を検証した際は、エージェントが作ったファイルを SharePoint に保存したり、ワークフローに渡したりするところで止まっていました。

あれから数か月がたち、改めて試してみたところ、チャットから使う場合は、作ったファイルを SharePoint に保存できるようになっていました。

ただ、チャットでファイルを返すか、SharePoint に保存してリンクを返すかの違いだけだと、「仕事を任せる」という観点では、個人的にはそこまで大きな違いは出ないのではないかと思っています。

個人的に重要だと考えているのは、ワークフローからエージェントにファイルを渡し、エージェントが処理したファイルを決まった場所に保存し、それをきっかけに次の処理が動くという形です。これができると、最終的には部門ごとのエージェントがファイルを受け渡しながら動くようなシナリオにもつながっていくと考えています。つまり、業務プロセスに組み込むエージェント作成の幅が広がる、また、複数の部門をまたいでエージェントが人間の代わりに仕事をするような形も実現できるようになると思います。

そこで今回は、この形に向けて「どこまでできるのか」「できないのはなぜか」を、段階を追って試してみました。結論としては、ワークフローから通常のエージェントにファイルを渡す方法は見つからず、渡せたのは「インラインエージェント」だけでした。その原因も、ある程度見えてきたので、あわせて整理します。

※本記事の検証は 2026/10/26〜27 時点のものです。新しい UI やワークフローはプレビューの要素を含むため、今後変わっていく可能性が高い点はご了承ください。

検証の前提

項目	内容
検証日	2026/10/26〜27
エージェント	GitHub Copilot ハーネス（新しい UI）、モデルは Claude Sonnet 5.5
保存先	検証用の SharePoint サイトのドキュメントライブラリ（受付・出力などのフォルダー）
題材	架空の「タクマス精機」の見積依頼 Excel（数量に全角数字、納期が「11月末」などの揺れをわざと入れたもの）

本記事では、次の2つを呼び分けます。

呼び方	中身
通常のエージェント	エージェントの画面で作って公開したエージェント。ワークフローの Agent ノードでは「既存のエージェント」として選び、「メッセージ」欄で指示を渡す
インラインエージェント	ワークフローの Agent ノードの中で「このワークフローの新しいエージェント」を選んで作るエージェント。指示文もノードの中に書く

インラインエージェントについては、Add an agent node to a workflow で紹介されています。

6月時点で止まっていたところ

まず、前回の検証で止まっていたところを振り返ります。

やりたかったこと	6月時点の結果
作ったファイルを Work IQ で SharePoint に保存する	ファイルが base64（ファイルを文字に置き換えたもの）としてエージェントの会話を通り、途中で欠けた
作ったファイルをワークフローの後ろのノードに渡す	Agent ノードの出力はテキストなどに限られ、ファイルとして渡せなかった
SharePoint のファイルをコネクタで取得して加工する	取得したファイルが壊れて開けなかった

今回は、この3つが今どうなっているかを中心に見ていきます。

検証1：チャットからは、作ったファイルを保存できるようになった

まず良くなった点からです。エージェントに SharePoint コネクタの「ファイルの作成」をツールとして追加し、チャットから依頼すると、作ったファイルを壊さずに保存できるようになっていました。

エージェントの構成

検証用に「ファイル保存テストエージェント」という通常のエージェントを作りました。モデルは Claude Sonnet 5.5、ツールは「ファイルの作成」の1つだけです。

「ファイルの作成」の入力は、次のように設定しています。

入力	設定
サイトのアドレス	検証用サイトに固定
フォルダーのパス	保存先のフォルダー（検証_出力）に固定
ファイル名	エージェントに任せる
ファイルコンテンツ	エージェントに任せる

指示文は次のとおりです。検証用なので、保存先のサイズや SHA256（ファイルの指紋のような値）まで報告させています。（報告の表の形など、一部を短くして載せています）

あなたは、作ったファイルを SharePoint に保存できるかを確かめる検証用のエージェントです。

## 一番大事なルール
- 作ったファイルを base64 などの文字に変換して、会話や回答に書き写さないこと。
- 保存のツールには、実行環境のファイルの場所（file:///app/created/<ファイル名>）を渡すこと。それで渡せない場合は、文字に変換して続けず、「ファイルとして渡せなかった」とその理由を報告して止まること。
- 保存に失敗したのに、成功したように報告しないこと。
- 使うツールは「ファイルの作成」だけ。保存したファイルを読み戻したり、検索したりしないこと。

## 手順
1. 依頼の内容から、コードの実行環境でファイルを作り、/app/created/ に置く。
   - 金額は数式ではなく、計算した値を書き込む。
   - ファイル名は、依頼で指定された名前の拡張子の前に、実行時刻を _HHMMSS の形で付ける。同じ名前のファイルが保存先にあると保存できないため。
2. 作ったファイルについて、実行環境で次の2つを計算する。
   - サイズ（バイト数）
   - SHA256（hashlib で計算）
3. 「ファイルの作成」で保存する。
   - ファイル名：手順1の名前
   - ファイル コンテンツ：file:///app/created/<ファイル名>
4. ファイルを開くリンクを作る。共有リンクは作らない（ドキュメントライブラリにアクセスできる人が開く前提）。
   - リンク＝ <サイトのアドレス> の後ろに、手順3の結果の Path をつなげたもの
5. 最後に、ファイル名・実行環境でのサイズ・SHA256・保存先のサイズ・保存先のリンク・結果を表で報告する。

## 補足
- Excel・Word・PowerPoint のファイルは、SharePoint が保存のときに情報を書き足すことがあるため、保存先のサイズが大きくなっても失敗とはしない。サイズが違うことだけを報告し、原因を調べに行かないこと。

ポイントは、「ファイルコンテンツ」の欄に、ファイルの中身ではなく、実行環境（サンドボックス）上のファイルの場所を渡すことです。

ファイル コンテンツ：file:///app/created/出張精算_20261020.xlsx

この渡し方だと、ファイルが文字に置き換えられて会話を通ることがないため、6月のように途中で欠けることがありません。最初の1回は、指示文で渡し方を指定しなくてもエージェントが自分でこの形を選んでいましたが、毎回同じ動きになるよう、指示文に明記しています。

テストの流れ

20,000 行の Excel を作って保存する

プレビューのチャットで、次のように依頼しました。

検証用に、20,000行 × 6列（連番、日付、部署、品目コード、数量、金額）のダミーデータの Excel を作ってください。1行目は見出しで太字。ファイル名は 大きめテスト_20000行.xlsx です。保存してリンクを返してください。

エージェントは実行環境でファイルを作り、「ファイルの作成」を1回だけ呼んで保存しています。

最後に、指示文どおりの表で結果が返ってきました。

SharePoint の保存先のフォルダーを見ると、ファイル名に実行時刻が付いた形で保存されています。

返ってきたリンクから開くと、20,000 行のデータが入っていました。

PowerPoint を作って保存する

同じエージェントで、PowerPoint も試しました。

「ファイル連携検証」というタイトルで、3枚の PowerPoint を作ってください。1枚目は表紙、2枚目と3枚目には箇条書きを3行ずつ入れてください。ファイル名は ファイル連携検証.pptx です。保存してリンクを返してください。

保存されたファイルを開くと、指定どおりの内容になっていました。

※今回は体裁については特に指定していません

結果

試したファイル	実行環境のサイズ	保存先のサイズ	中身
出張精算（3行＋合計）	5,184 バイト	12,713 バイト	正しい
ダミーデータ 20,000 行	728,747 バイト	736,533 バイト	正しい（20,000 行入っている）
PowerPoint 3 枚	30,295 バイト	38,948 バイト	正しい

保存先のほうが毎回 7〜9KB ほど大きくなっていますが、開いてみると中身は正しく入っていました。保存先のファイルには、作っていない部品（customXml など）が増えていたので、SharePoint 側が Office ファイルに情報を書き足しているのではないかと考えています（確認はできていません）。

また、最初は SharePoint MCP も一緒に付けていたのですが、エージェントが保存後に読み戻しや検索で寄り道してしまったので外しました。ツールを「ファイルの作成」1つにし、指示文で file:///app/created/<ファイル名> を渡すように明記すると、ツールの呼び出し1回で終わるようになりました。

※ドキュメントライブラリにアクセス権のある人が開く前提であれば、共有リンクは作らなくても、サイトのアドレスと保存先の Path をつなげたリンクで十分かと思います。

検証2：ワークフローから通常のエージェントには、ファイルを渡せなかった

次に、本題のワークフローとの連携です。SharePoint の「受付」フォルダーにファイルが置かれたらワークフローが起動し、Agent ノードで通常のエージェントを呼ぶ、という形で試しました。

呼び出す通常のエージェントには「営業部見積受付エージェント」を用意しました。見積依頼の Excel を開き、表記の揺れをそろえて製造部向けの「製造依頼」の Excel を作り、保存して Teams で知らせる役割です。

項目	設定
ツール	ファイルコンテンツの取得（ファイルを取りに行く用）、ファイルの作成、Teams のメッセージ投稿
指示文の主なルール	ファイルを base64 などの文字にして書き写さない／開く前に先頭2バイトが `PK`（xlsx の目印）かを確かめる／開けなかったら推測で埋めずに止め、Teams に理由を知らせる

ファイルの渡し方は、次の4通りを試しています。

1. 「ファイルコンテンツ」をそのままメッセージ欄に入れる

まずは素直に、「ファイルコンテンツの取得」の結果をメッセージ欄に入れてみました。エージェントは「依頼文にバイナリが文字として貼り付けられており、実行環境にファイルとして置かれていない」と判断して処理を止め、Teams にその旨を投稿してくれました。

推測で埋めずに止まる、という指示どおりの動きだったのは良かったのですが、ファイルは受け取れていません。

2. 識別子などを渡して、エージェントのツールで取得させる

中身だけ渡しても足りないのかと思い、ファイルの識別子・パス・ファイル名を渡し、エージェント自身に「ファイルコンテンツの取得」で取りに行かせる形も試しました。

ファイルの特定と取得まではできたのですが、取得した中身が文字化けして返ってきて、Excel として開けませんでした。エージェントは「コンテンツタイプを推測する」を true と false の両方で取り直していましたが、どちらも同じ結果でした。

3. base64 の文字にして渡す

ワークフローのノードとして「ファイルコンテンツの取得」を動かすと、結果は $content-type と $content（base64）の形で正しく返っています。

base64 は安全な文字だけでできているので、メッセージ欄に入れても壊れないはずです。動的な値の一覧には「ファイルコンテンツ」しか出てこないため、式で $content を取り出して渡しました。

body('ファイル_コンテンツの取得')?['$content']

この回は、base64 を受け取って元に戻すだけの検証用エージェント（ツールなし）を別に用意し、メッセージ欄には次のように渡しています。

見積依頼の Excel を base64 にして渡します。
ファイル名：（拡張子付きのファイル名）
base64：（上の式）

base64 自体は崩れずに届いたのですが、エージェントがそれを実行環境のコードに書き写して元に戻す段階で、文字数がずれて失敗しました。

base64 は 4 文字ずつ元に戻すため、文字数は必ず 4 で割り切れます。今回は約 1 万 8 千文字あり、「AAAA…」が何百個も続く部分もあったため、書き写す途中で文字が欠けたか増えたと考えられます。小さめのファイルでもこの結果だったので、実務で使うのは難しいかと思います。

4. ワークフローを使わず、チャットで同じツールを使う

「ワークフローから呼んだから壊れたのか」を切り分けるため、チャットでも試しました。ツールは「パスによるファイルコンテンツの取得」の1つだけにし、ファイルパスは取得するファイルに固定しています。

指示文では、ツールを1回だけ呼び、戻り値の形（JSON か文字列か、先頭100文字、base64 の文字だけでできているか、文字化けの記号が混じるか）と、実行環境にファイルとして置かれたかを、見たまま報告させました。依頼文は「ファイルを取得して、手順どおり報告してください。」だけです。

取得したファイル	戻り値
CSV（同じ明細を CSV にしたもの）	ただの文字列として、正しく返った
Excel（.xlsx）	ただの文字列で、先頭は `PK` だが、文字化けの記号（�）が大量に混じる

チャットでも同じように壊れたので、ワークフローかどうかは関係なく、通常のエージェントがツールで Excel などのファイルを取得すると壊れるという結果でした。

なぜ壊れるのか

ここからは、検証結果をもとにした私なりの整理です。中の仕組みが見えるわけではないので、推定を含む点はご了承ください。

ファイルの中身は「数字の列」

どんなファイルも、中身は 0〜255 の数字（バイト）が並んだものです。

CSV のようなテキストファイルは、その数字が UTF-8 という「文字の読み方のルール」に沿って並んでいます。たとえば e5 93 81 は「品」です。ルールに当てはめれば必ず文字に戻せるので、CSV は正しく取得できました。

一方、xlsx は、中身の XML ファイルを ZIP で圧縮したものです。圧縮すると、数字の並びは文字のルールとは関係のないものになります。こうしたファイルを、ここではバイナリファイルと呼びます。Word や PowerPoint、PDF、画像も同じです。

文字として読むと「�」に置き換わり、元に戻せない

バイナリを無理に文字として読むと、ルールに合わない数字に出会うたびに「読めない印 �」に置き換わります。しかも、どの数字であっても同じ1つの印になるため、あとから元の数字に戻すことはできません。

たとえば、サンプルの xlsx の途中にある 16 個の数字を文字として読むと、次のようになります。ルールにたまたま合った数字だけが文字になり、残りは � に置き換わっています。

数字：8a 1e a4 0e 44 3d 8a 9e bc cf 2e 75 85 b6 29 6d
文字：�  ・  �  ・  D  =  �  �  �  �  .  u  �  �  )  m
（・は目に見えない制御文字）

今回のサンプルの見積依頼 Excel を、手元で実際に文字として読み直してみると、次のようになりました。

項目	値
元のファイル	5,605 バイト
� に置き換わった数	1,886 か所
文字からファイルに戻したサイズ	9,318 バイト（ZIP として開けない）

戻すとかえって大きくなるのは、� という印そのものが 3 つの数字（ef bf bd）でできているためです。

base64 は、どんなファイルでも、壊れない 64 種類の文字（A〜Z、a〜z、0〜9、+、/）だけで書き表す方法です。3 つの数字を 4 文字にするので少し長くなりますが、元に戻せます。同じサンプルなら 7,476 文字になり、戻すと元と完全に一致しました。

壊れているのはコネクタではなく、その結果をモデルに渡すところ

同じ「ファイルコンテンツの取得」でも、ワークフローのノードとして動かすと base64 で正しく返り、エージェントのツールとして呼ぶと文字化けしました。コネクタが返すもの自体は同じはずなので、違いは受け取る側の扱い方にあると考えています。

ワークフロー（Power Automate と同じ仕組み）では、文字ではない中身は base64 にして $content に入れる決まりになっています（Handle content types in Azure Logic Apps）。

一方、エージェントのツールとして呼んだときは、$content も $content-type もない、ただの文字列が届いていました。エージェントの仕組みの中で、バイナリが base64 に包まれないまま文字として読まれ、その時点で壊れているのではないかと考えています。

ちなみに、保存の側には file:/// を渡すと実ファイルに置き換えてくれる仕組みがあります。読み込みの側にはそれに当たる仕組みがない、という片寄った状態に見えます。正直、コネクタが種類の情報（Content-Type）まで返しているのに、なぜバイナリとして扱わないのかは謎です。

※コミュニティでも、新しい体験でツールにファイルを渡すと壊れるという報告が 2026/07 から続いており、回答者の一人は「想定された動作ではない」と書いています（Microsoft Q&A）。

検証3：インラインエージェントなら、受け取って保存までできた

Agent ノードの記事を改めて読み直すと、SharePoint のファイルからデータを取り出す例は、インラインエージェントの指示文に「ファイルコンテンツ」を入れる形になっていました（Add an agent node to a workflow）。これまで試していたのは、通常のエージェントのメッセージ欄だったので、同じ形で試してみました。

ワークフローの構成は検証2と同じで、Agent ノードの「エージェント」を「このワークフローの新しいエージェント」に切り替えただけです。

インラインエージェントの指示文

指示文は、Agent ノードの中の「指示」欄に書きます。最初は受け取れるかだけを確かめ、その後に「製造依頼を作って保存する」部分を足しました。最終的な指示文は次のとおりです（判定の選択肢の説明など、一部を短くして載せています）。（）の部分は、文字ではなく、指示欄の稲妻のアイコンから入れる動的な値です。

あなたはタクマス精機 営業部の見積受付エージェントです。この下に渡す見積依頼の Excel を読み、内容を報告してください。

## 一番の目的：ファイルがどの形で届いたかを確かめる
1. 実行環境の /app/uploads、/app/workspace、/app/created と、/app 以下にある .xlsx ファイルを一覧にする。
2. 見積依頼が次のどれで届いたかを判定する（ファイル／テキスト／壊れている／なし）。
3. ファイルとして置かれていたら、先頭2バイトが "PK" か、openpyxl の load_workbook で開けるかを確かめる。

## 読む内容
- 品目コード（すべて）
- 合計金額：明細の数量×単価の合計に、消費税10%（1円未満切り捨て）を足したもの。数量は全角数字や「個」を取り除いて半角の整数にする
- 希望納期：YYYY-MM-DD にする。「11月末」はその月の末日。年がなければ 2026年

## 作るファイル
読み取った内容から「製造依頼」の Excel を新しく作る。
- シート名「製造依頼」
- 上部：依頼番号、顧客名、営業担当、依頼日、希望納期
- 明細の表：品目コード、品名、数量、単価、金額
- 表の下：小計、消費税、合計（金額は数式ではなく計算した値）

## 保存（必ずこの場所と名前で）
- 作ったファイルを実行環境の /app/created/ に、次のファイル名で保存する
- 「ファイルの作成」に次の値をそのまま渡す。変えたり、別の名前を考えたりしない
  - フォルダーのパス：/（ライブラリ）/出力
  - ファイル名：製造依頼_（ファイル名）.xlsx
  - ファイル コンテンツ：file:///app/created/製造依頼_（ファイル名）.xlsx
- 保存に失敗したときは、別の場所や方法を試さずに止め、どこで失敗したかと返ってきたメッセージを報告する

## ルール
- 推測で埋めない。読めなかった項目は null にし、理由を書く。
- base64 などの文字を書き写さない。

ファイル名：（拡張子付きのファイル名）
見積依頼のファイル：（ファイル コンテンツ）

最後の「見積依頼のファイル」に入れているのは、「ファイルコンテンツの取得」の結果の「ファイルコンテンツ」です。検証2の1で、通常のエージェントのメッセージ欄に入れたものと同じ値です。

ファイルとして受け取れた

まず、「作るファイル」と「保存」の部分を入れずに実行したところ、ファイルが実行環境の /app/uploads/ に本物の xlsx として置かれました。

先頭は PK で、openpyxl（Python で Excel を扱う部品）でも開けています。品目コード、合計金額、希望納期もすべて期待どおりでした。

なお、置かれるファイル名は元の名前ではなく、「ファイル_コンテンツの取得-ランダムな文字」でした。前のノード名が付いているので、プラットフォームが添付ファイルとして取り込んでいるのではないかと考えています。

作ったファイルを決まった場所に保存できた

次に、同じインラインエージェントに「ファイルの作成」をツールとして追加し、指示文に「作るファイル」と「保存」の部分を足して、受け取った見積依頼から「製造依頼」の Excel を新しく作って保存させました。

インラインエージェントでは、ツールの入力（保存先のフォルダーなど）を固定できません。そこで、保存先のフォルダーは指示文に直接書き、ファイル名はトリガーの「ファイル名」を動的な値で入れて指定しています。

結果、指示どおりの場所と名前で保存されました。

開いてみると、表記の揺れもそろえたうえで、小計・消費税・合計まで正しく入っていました。

現在地の整理

ここまでの結果をまとめると、次のとおりです。

やりたいこと	通常のエージェント	インラインエージェント
ワークフローからファイルを受け取る	できない（文字化け、または書き写しで失敗）	できる（指示文にファイルコンテンツを入れる）
チャットでファイルを受け取る	添付・ナレッジならできる	―
ツールで SharePoint のファイルを取得して加工する	テキストファイルのみ。Excel などは壊れる	―（今回は不要だったので未確認）
作ったファイルを SharePoint に保存する	できる（`file:///` を渡す）	できる（保存先は指示文で指定）
Agent ノードの出力をファイルとして後ろへ渡す	できない（出力はテキストか構造化データ）	できない

ワークフローからファイルを受け取って加工し、保存するところまでは、インラインエージェントで一応つながりました。

インラインエージェントで十分かというと

ただ、正直なところ、インラインエージェントだけで実務の仕組みを作るのは不便だと感じています。

設定できることが少ない

インラインエージェントで設定できるのは、指示・モデル・Work IQ・ツール・ナレッジ・出力の形です（Add an agent node to a workflow）。スキルは使えず、今回試した範囲ではツールの入力を固定することもできませんでした。ほかのワークフローで使い回すこともできません。

そうなると、様式の決まりや判断のルール、保存先などを全部指示文に書くことになります。上の指示文も、検証用の簡単な内容でこの長さです。個人的には、一つひとつのインラインエージェントにそこまでのボリュームを持たせるのは難しいのではないかと思っています。

情報を取り出すだけなら割高

インラインエージェントで見積依頼を読み取ったときは 16.51 クレジットかかりました。一方、同じワークフローの「ファイルコンテンツの取得」のノードは 0.13 クレジットです。

ファイルから情報を取り出すだけであれば、以前は AI Builder のプロンプトでできていました。個人的な感覚では、本来は 0.1 クレジット程度でできてほしい処理に、その 100 倍ほどかかってしまう印象です。

※2026/09 には、文書から値や表を取り出す専用の Extract ノードもワークフローに追加されています（Add an extract node to a workflow）。ただ、記事には「Agent ノードの土台の上に作られている」とあり、費用感については言及が見当たりませんでした。取り出すだけのシナリオでは、こちらのクレジットも比べてみる価値があるかと思います。

そう考えると、このハーネスをワークフローで使う価値は、情報を取り出すことではなく、ファイルを受け取って、ファイルを直したり作ったりして保存するところまで任せられるかにあると考えています。

ファイルの受け渡しができると何ができるか

通常のエージェントでもワークフローからファイルを受け取れるようになれば、スキルで様式の癖や判断のルールを持たせたエージェントを、ワークフローの中でそのまま使えるようになります。以下は、私が想定しているシナリオの一部の例です（今回の検証で実現を確認したものではありません）。

部門間でのファイルの受け渡し

冒頭の図のように、営業部が受け付けた見積依頼を整えて製造部のフォルダーに置き、製造部のエージェントが工数と納期の回答書を作って営業部に返す、という流れです。

保存をきっかけに次のワークフローが動くので、人がメールでファイルを転送したり、フォルダーを見に行ったりする手間が減ります。SharePoint リストに「誰がいつ何を渡したか」を残せば、部門をまたいだ受け渡しの状況も一覧で見えるようになるかと思います。

届いたファイルを、会社の様式に転記する

以前の検証で、ナレッジのマスタや規程を組み合わせて、癖のある様式の Excel を埋めるエージェントを作りました。こうした「様式の癖」はスキルに持たせるのが向いていると考えています。届いた申込書や依頼書をきっかけに、そのエージェントが社内様式に転記して保存するところまで自動で動けば、人がチャットで依頼する手間もなくなります。

受け取ったファイルのチェックと差し戻し

取引先から届いた請求書や見積書をチェックし、問題がなければ所定のフォルダーへ、問題があれば指摘を書き込んだファイルを差し戻し用のフォルダーへ、という使い方も考えられます。チェックの観点を変えたいときはスキルを差し替えるだけで済むので、保守もしやすくなるかと思います。

いずれも、チャットで人が依頼するのではなく、ファイルが届いたことをきっかけに、エージェントが自分の担当分を処理して次に渡すという形です。個人的には、ここまで来て初めて「仕事を任せる」に近づくのではないかと考えています。

まとめ

今回は、Copilot Studio の GitHub Copilot ハーネスで、ワークフローからエージェントにファイルを渡せるかを検証しました。

チャットからは、file:/// で作ったファイルを SharePoint に保存できるようになった
ワークフローから通常のエージェントにファイルを渡す方法は見つからなかった。ツールで取得すると、バイナリが文字として読まれて壊れる
インラインエージェントの指示文にファイルコンテンツを入れれば、受け取りから保存までできた。ただし、スキルが使えないなど、実務で使うには不便な点も多い

個人的には、通常のエージェントがツールで取得したファイルを実行環境にファイルとして置けるようになるか、ワークフローの Agent ノードから通常のエージェントにファイルを添付として渡せるようになることを期待しています。また、ワークフロー内でエージェントの出力ファイルを動的なコンテンツとして扱えるようになることも期待しています。

そうなることで、業務プロセスに組み込むエージェントの作成の幅が広がりますし、結果として、Agent Builder との差別化要素にもなると思います。

私の検証の仕方が悪いだけかもしれないので、「私の手元ではこう渡したら動いた」といった情報があれば、ぜひ教えていただけるとうれしいです。新しい情報が入り次第、再検証したいと思います。

本記事が、Copilot Studio のワークフローとエージェントの組み合わせを検討されている方のお役に立てば幸いです。

参考