はじめに
Copilot Studio の UI が全面刷新されたため、これまで何度か検証記事を書きました。
今回は、ファイルの入出力まわりを中心に改めて検証しました。検証の結果、これらについては以前の UI より進化している、安定して動くようになった印象です。
例えば、旧 UI で、コードインタープリターをオンにしてもファイルの生成やダウンロードが安定しなかったです (例：生成したファイルのリンクをクリックしてもダウンロードできない)。
今回、新しい UI でファイルの入出力を中心に検証し、あわせて以前トピックと AI プロンプトで作っていた「見積書・請求書チェックエージェント」を、指示文ベースだけでどこまで再現できるかなど、色々試してみました。
結論から言うと、できるようになったことと、まだ難しいことの両方が改めて見えてきました。
※本記事の検証はすべて 2026/06 時点のものです。新しい UI やワークフローはプレビューの要素も含むため、今後変わっていく可能性が高い点はご了承ください。
検証の前提・環境
- 検証時期: 2026/06
- 利用機能: 新しい UI のエージェント、コードインタープリター、ナレッジ、WorkIQ、新しいワークフロー
- 用語の使い分け: 「アクション」はエージェントフローの処理単位、「ノード」は新しいワークフローの処理単位を指します。
検証1: ファイル出力の安定性が向上した
まず良くなった点からです。コードインタープリターによるファイル出力が安定するようになりました。
以前は、コードインタープリターをオンにしてもファイルがうまく生成されなかったり、ダウンロードできなかったりと、安定性に欠ける場面がありました。今回試した範囲では、Excel などのファイルがきちんと生成され、その場でダウンロードできる状態で返ってくるようになっています。
例えば、以下のように、調査結果をレポートにまとめさせるエージェントを作ったところ、問題なくレポートが生成されました。生成されるファイルについて、個人的には Claude を使っているときのような、整った成果物が出てくる印象を受けました。ここは素直に進化を感じた部分です。
PowerPoint もいけます。
検証2: WorkIQ で SharePoint に保存しダウンロードリンクを返す（現状は失敗）
次に、生成したファイルを WorkIQ を使って SharePoint 上に保存し、ダウンロードリンクを返す、という流れを試しました。こちらは現時点ではうまくいきませんでした。
上手くサイト、ドキュメントライブラリ等は指示文の通り見つけれています。
しかし、ファイルの「中身（バイナリ）」の受け渡しにあります。WorkIQ は
ファイルの中身を文字列（Base64）としてやり取りする形になっており、その文字列をエージェントの会話を経由して運ぼうとすると、大きいファイルでは途中で欠けてしまうようでした。
では、エージェントの出力をコネクタやワークフローに渡そうとすると、別の壁にあたりました。ファイルを保存するには「ファイル名」と「ファイルコンテンツ」を渡す必要があるのですが、エージェント（Agent ノード）の出力が応答テキストなどに限られており、ファイルそのものを後続のノードに動的な値として渡せませんでした。出力がテキストなので、ファイルコンテンツを求めるコネクタの入力と形式が合わない、ということです。
このあたりは、最終的には指示文ベースだけで安定して SharePoint 上に保存まで完結できるようになることを個人的には期待しています。現時点では、保存が必須でないものは「その場でダウンロード」で割り切る、というのが現実的かなと考えています。
検証3: SharePoint のテンプレートを使ったファイル出力（失敗したためスキル化で代替）
続いて、SharePoint 上に置いたファイルをテンプレートとして使い、それと同じ体裁でファイルを出力する、という検証です。
最初は、テンプレートのファイルを読み込ませて再現させようとしたのですが、ここも
ファイルの読み込みの部分でなかなかうまくいきませんでした。検証2と同じく、テンプレートの実ファイルをそのまま読み込む流れが安定しなかったためです。
そこで方針を変えて、テンプレートを再現できるようにスキルを作り、そのスキルをベースにファイルを出力するようにしました。すると、こちらは動作しました。
検証4: 既存の請求書・見積書チェックエージェントを指示文ベースで再現
最後に、以前トピックと AI プロンプトで作っていた「見積書・請求書チェックエージェント」を、新しい UI の指示文ベースだけでどこまで再現できるかを試しました。
以前の作りは、おおまかに次のような流れでした。
- トピックで、見積書・請求書を順番にアップロードさせる
- 両方そろったら AI プロンプトを呼び、情報を抽出する
- 品目や数量などを比較する
- 結果を JSON で出力する
- ナレッジを検索して、金融機関コードを比較する
これを、トピックや AI プロンプトを使わず、指示文＋ナレッジ＋コードインタープリターだけで組み直してみました。結果として、再現できました。
見積書をアップロードすると、請求書の方を求められ、両方アップロードすると処理を進めるなど、柔軟に動いてくれました。
明細の突合（数量・単価・金額の比較）、金融機関コードの正誤チェックまで、指示文だけで一通り動きました。以前のようにトピックのノードを並べたり、AI プロンプトを別に用意したり、変数を受け渡したりという手間がなく、業務手順をそのまま文章で書く形になります。市民開発者にとっての作りやすさという意味では、これは大きいと感じました。
作成段階で起きたこと（オーケストレーションの進化が裏目に出た例）
ただ、作っていく過程でいくつか気になる挙動もありました。これは新しい UI の自律的なオーケストレーションが、良い方向にも悪い方向にも働く、という話だと考えています。
ナレッジ検索に時間がかかりすぎた
金融機関コードを調べるためのナレッジ検索に、想定より時間がかかりました。ナレッジが公開 Web サイトのため、コードと無関係なサイト紹介文なども含めてたくさん読み込んでしまうこと、そして自律的に何段階も処理を踏むことが要因と考えています。
対策としては、指示文で検索の作法を絞るのが有効でした。具体的には、検索クエリの形を固定して1回だけ検索する、結果からは必要なコードだけを読み取る、関係ない記述や別ファイルは読み込まない、といった指示を加えることです。
# 効率化の方針(速度のために守る)
- 抽出は1回で行う。
- 再確認は、テキスト抽出した文字が視覚的に不鮮明・文字化けしている場合に限り、
その文字を「実際に印字されている通りに読み直す」目的でのみ行う。
期待値や正しいコードと違うことを理由に再確認・修正してはならない。
- ナレッジ検索は1件の金融機関につき原則1回。プレビューから必要なコードだけを抜き出し、サイト紹介文や別ファイル(スニペット全文)は読み込まない。
検証5: ナレッジの挙動（個別ファイルとフォルダーで差が出た）
検証を進めるなかで、ナレッジの動き方についても気づいた点があります。新しい UI のナレッジは、これまでの「インデックスから該当箇所を引いてくる」イメージとは少し違う挙動に見えました。
具体的には、ファイルをアップロードした場合や、SharePoint のファイルを直接指定した場合、ファイルの実体を (サンドボックス環境に) 取り込んで、全文を読みにいっているように見えます。その後ファイルそのものを解析していました。要は、ナレッジの検索が RAG ではなくなったように見受けられます。
この全文を読むアプローチには、良い面と注意すべき面の両方があります。
- 良い面: 文書をまるごと読むので、該当箇所の取りこぼしが減り、精度が出やすい
- 注意点: ファイルサイズが大きいと、読み込みに時間がかかり、回答が遅くなりやすい
そして、いちばん気になったのがフォルダーを指定したときです。ナレッジにフォルダーを指定したケースでは、うまく動かない場面がありました。フォルダー内に答えとなる情報がある質問に対して、「情報を見つかりませんでした」と回答できないことがあったのです。
実際、SharePoint フォルダー配下に FAQ ファイルや規程ファイルを置いたフォルダーを指定したのに、その規程に関する質問に答えられませんでした。
ここから、現時点では次のように運用するのが安全かなと考えています。
- ナレッジは、フォルダーよりも個別のファイル単位で指定する
- フォルダーで入れたいファイルも、当面は重要なものを個別に登録しておく
- ナレッジ用のファイルは大きくしすぎない（全文を読むため、巨大なファイルは分割した方が安定する）
- フォルダーを指定する場合は、狙った質問に実際に答えられるかを確認してから本番に乗せる
- 上手く動作しない場合は従来の UI (RAG) の方で実装する
個人的には、全文を読む方向に寄ったことで精度が上がる場面はあると感じています。一方で、フォルダー単位での扱いや、大きいファイルの速度には、まだ気をつけるところがある、というのが現時点の印象です。
少なくとも、チャット型のエージェントや、自律型ではあるものの、多くのファイルやサイズの大きいファイルから検索をして回答を生成するようなエージェント (例：メールトリガーで調査依頼を受け取り、ナレッジを基に検索して回答を生成するようなエージェント) の場合は、従来の UI 側で作成する方がいいかもしれません。また、チャット型で FAQ に対して回答するだけであれば、Agent Builder でもよいケースもあると思います。
今後への期待
少し補足すると、実際の運用では、単一ファイルや数えられる程度のファイルをナレッジに指定するより、ある程度の数とサイズのファイルが入ったフォルダーを指定するケースの方が多いと思います。その場合は、配下のファイルにセマンティックインデックスのようなものが作られて、効率よく検索できる方が現実的です。そう考えると、今回の全文を読む挙動は、精度の面では良い一方で、フォルダー単位の運用では一長一短かなと感じています。
個人的に理想だと思うのは、まずインデックスで該当するファイルや箇所まで効率よく絞り込み (今も実際はそのように動いているのかもしれませんが)、そのうえで必要な範囲だけ全文を読んで精度を担保する、という流れです。これが現実的なレスポンス時間で動くのであれば、利用する側からすると、仕組みがどちらであっても、精度が上がってレスポンスも実用的、というありがたい動きになります。
もちろん、中身の動作関係なく、フォルダー指定に対しても十分に機能するようになるのであれば、特に問題はありません。まだプレビューの段階なので、フォルダーの扱いはこれから成熟していく部分だと思います。今後の進化に期待しつつ、新しい情報が入り次第、また検証してみたいと考えています。
スキルをどう捉え、どう伝えるか（補足）
新 UI の特徴の一つとして、スキルが扱いやすくなった、内部的にもスキルが実装されており、よしなに利用されている点です。
そうなると、スキルとは何か、市民開発される方や Agent Builder の延長で Copilot Studio を使う方にどう伝えるかが重要になってくると思います。個人的に、技術的な観点で細かく伝えすぎると、エンジニアではない人からすると、自分には難しい、AI の進化についていけないといった気持ちを抱いてしまうリスクがあると思っています。
そのため、私なりの観点で言語化してみます。
観点 1：部品化した「手順書」であること
ひとつめは、何かを手順どおりにやってほしいときに、その手順をまとめたもの、という捉え方です。
「それなら、指示文に全部書けばいいのでは？」と思われるかもしれません。実際、手順が少ないうちはそれで十分です。ただ、AI にやらせたい作業がたくさんあって、手順書も何種類も必要になってくると、話が変わってきます。
これは人間に置き換えると分かりやすいと思います。たくさんのマニュアルがある職場で、「この全部のマニュアルを同時に見ながら作業してください」と言われたら、おそらく混乱しますよね。実際には、いま取りかかる作業に必要なマニュアルだけを手元に持ってきて、開いて、そのとおりに作業するはずです。
スキルも、これと同じイメージだと考えています。普段はしまっておいて、必要なときだけ、その手順書を手元に持ってきて開く。だからこそ、AI もあれこれ詰め込まれて混乱することなく、いま必要な手順に集中できます。
個人的には、ここがスキルの本質的なところだと思っています。手順を「部品化」しておき、適材適所で呼び出す。手順が多い業務ほど、この考え方の価値は大きくなると考えます。
観点 2：再現性を上げるための「翻訳」であること
ふたつめは、少し違う角度からの捉え方です。何かの作業を、再現性高くやってほしいときの「翻訳」、というものです。
代表例が、まさに今回の「このテンプレートどおりに、テンプレートをもとに資料を作ってほしい」というお願いです。
人間が相手であれば、テンプレートを 1 枚渡して「これと同じ感じで作っておいて」と言えば、だいたい通じます。最終的には、AI にもそれができるようになると、個人的には思っています (依頼する側は裏で動いている仕組みを知らずとも)。ただ、現時点では、そのお願いとAI の動きの間に、少し「翻訳」が必要だと感じています。
その翻訳というのが、たとえば「タイトルはこの位置に、見出しはこの色で、列はこの順番で」といった、テンプレートの体裁を言葉に起こす作業です。人間が暗黙のうちに読み取っている「いい感じ」を、AI が再現できる形にきちんと言語化してあげる。この翻訳をあらかじめ済ませて、固定しておいたものがスキル、という捉え方です。
そう考えると、スキルは「AI に、このテンプレートどおりの資料を再現性高く作ってもらうための、現時点での翻訳」と言えるのではないかと思います。あらかじめ翻訳を用意しておくことで、毎回口頭でお願いするよりも、ぐっと再現性が上がります。
2 つの観点は、実は同じこと
ここまで 2 つの観点を挙げましたが、個人的には、この 2 つは同じ仕組みを別の角度から見ているだけだと感じています。
- 観点 1 は、手順（プロセス）を外に出して部品化したもの
- 観点 2 は、様式（暗黙知）を外に出して翻訳したもの
どちらも「頭の中や、ファイルの中にある知識を、いったん外に出して部品にしておき、必要なときに呼び出す」という構造は同じです。対象が「手順」なのか「様式」なのかが違うだけ、という認識です。
まとめ
今回は、新しい UI でファイルの入出力と、既存エージェントの再現を検証しました。
現時点での個人的な整理は次のとおりです。
- ファイルの出力（生成・ダウンロード）は安定するようになり、成果物の質も上がった
- WorkIQ での SharePoint 保存とリンク返却は、ファイルの中身の受け渡しが壁となり、現状は上手くいかないこともある
- テンプレートを使った出力は、実ファイルの読み込みより、スキル化した方が安定した
- 既存の請求書チェックエージェントは、指示文ベースだけで再現できた
- ただし自律的なオーケストレーションが裏目に出ることもあり、推論の自由度を下げる工夫が必要だった
- ナレッジは個別ファイル指定なら全文を読み精度が出やすい一方、フォルダー指定は
不安定で、大きいファイルは遅くなりやすい。現状は個別ファイルでの登録が安全
新しい UI は、市民開発者にとっての作りやすさという点で前進していると感じます。
一方で、ファイルの中身を確実に運ぶ部分や、抽出の安定性には、まだ工夫や割り切りが要ります。
まだプレビューの要素も多いので、私の検証の仕方が良くないだけ、という可能性も十分あります。そのため、「私の環境ではこう動いた」「こう組んだら安定した」といった情報があれば、ぜひ教えていただけるとうれしいです。
個人的には、現時点で色々触ってみた限り、確かに、Copilot Studio の新 UI、良くなった点も多いですが、まだ安定して動作しない点もそれなりに多い印象があります。また、そもそもコンセプトが変わった面も少なからずあると思っています。
そういった意味で、Copilot、Cowork、Agent Builder、Power App、Power Automate、AI Builder、Copilot Studio 旧 UI など、様々なサービスとの使い分け、本当に、Copilot Studio の新 UI やワークフローではないといけないケースの見極めが難しくなった面もあると思います。
そのため、この観点で、引き続き言語化して説明していきたいと思っています。