本記事について
本記事は「Copilot Studio × 非構造化データ」検証シリーズの Part 2 です。前編 (Part 1) では Classic experience を 5 Round に分けて検証し、5-6/7 Pass を天井に「空間関係」「図の階層構造」で断言に至らないという結論に達しました。本記事ではその 2 大限界に New experience で挑みます。
- Part 1: Copilot Studio (Classic experience)
- Part 2: Copilot Studio (New experience) ← いまここ
- Part 3: Azure AI Search + カスタム RAG (執筆予定)
- Part 4: Fabric データエージェント (複雑 Excel 対応、執筆予定)
Part 1 と同様、本検証は 2026 年 7 月時点 のスナップショットです。Copilot Studio の仕様・モデルは日々更新されるため、数値は 参考値 としてご理解ください。また各 Round は Evaluation ツールで 1-3 回実行 の結果に基づいており、LLM の非決定性による判定のブレが混じり得ます。
重要 (プレビュー機能に関する注意): 本記事で扱う New experience は 2026 年 7 月時点でプレビュー (public preview) 段階 の機能です。仕様変更・挙動変化・GA 時の破壊的変更の可能性があり、また 本番運用・SLA・ライセンス条件・サポート対象の範囲は GA 版と異なります。本番導入の判断にあたっては、必ず最新の Microsoft 公式ドキュメントおよびライセンス条項をご確認ください。
TL;DR
- Part 1 の Classic experience は R5 (Upload + プロンプト改良) で 5-6/7 Pass が天井、「空間関係 (Q3)」「階層構造 (Q5)」を断言できずに終わっていた
- 本記事では New experience で同じ 7 問を 3 段階 (N1 → N2 → N3) で検証:
- N1: SPO 参照 + Opus 4.7 (他はデフォルト) → 5/7 Pass (いきなり Classic の天井に到達し、Q3 と Q5 も正答)
- N2: N1 に プロンプト改良 (Part 1 の追加 2 行) → 7/7 Pass (完全パス)
- N3: ナレッジソースを Upload 型 に切替 → 7/7 Pass (N2 と同スコア。引用の粒度が細かくなるが、Pass 数の上積みや OCR 品質の差はなし)
- 結論: 「空間関係」「階層構造」の 2 大限界は、New experience の最小構成 (SPO 参照 + Opus 4.7 に切替、他はデフォルト) だけで突破する。Classic での 5 Round のチューニング苦労は "エクスペリエンス選択" 1 発でひっくり返る
- ただし最小構成でも落とし穴あり: N1 で Q2 (シフト表) が意外にも失敗 した。プロンプト改良 (N2) で救済されるが「デフォルトのままで全部盛り」にはならない
1. Part 1 の振り返り: Classic の 5 段階と残った 2 大限界
Part 1 では、Copilot Studio Classic experience で以下 5 Round を試しました:
| Round | 改善策 | Pass |
|---|---|---|
| R1 | SPO 参照 + デフォルト設定 | 4/7 |
| R2 | エージェント設定チューニング (Opus / 「根拠のない回答」禁止 / CI ON) | 4/7 |
| R3 | + プロンプト改良 (Excel は CI 解析 / 画像 PDF は画像確認) | 4/7 |
| R4 | ナレッジソースを Upload 型に | 5-6/7 |
| R5 | R3 + R4 の組み合わせ | 5-6/7 |
残った限界のおさらい:
| 質問 | データソース |
|---|---|
| Q3 (厨房の隣は？): 空間関係の推論 → 部分回答止まり |  |
| Q5 (鈴木一郎の直属の部下は？): 図の階層構造 → 断言できず参考提示 |  |
| Q6 (C2-syn 画像 PDF の図番): Upload 型で OCR 発火するが、"SS400" が "S5400" と誤認識される (自己検出で救済) |  |
これらは Classic experience が「取ってきたチャンクテキスト + LLM 1 発の回答生成」というシングルターン構造 に縛られているのが主因、というのが Part 1 の結論でした。本記事では エージェンティックループを基本アーキテクチャに据えた New experience で、これらがどう変わるかを見ます。
2. New experience とは何が違うか
Copilot Studio の New experience (2026 年 7 月時点で public preview) は、Classic の裏側にあった "シングルターン RAG" を、エージェンティックループ に置き換えたものと理解できます。
大まかな違い:
| 観点 | Classic experience | New experience |
|---|---|---|
| 回答の作り方 | 検索 → チャンク取得 → LLM が 1 発で回答生成 | 計画 → 検索 → 実行 → 観察 → 再計画 の反復 (エージェンティックループ) |
| ツールの使い方 | Code Interpreter などは "必要に応じて呼ばれる" (発火頻度は控えめ) | エージェントが 自律的にツールを選び、繰り返し呼び出す (コーディングハーネス) |
| 図・画像の扱い | SPO 参照ではチャンクテキストのみ。マルチモーダル読取は限定的 | 画像や PDF レイアウトを直接 "見に行く" ケースが増える (今回の Q3/Q5 突破の主因) |
| 失敗時の挙動 | 「わからない」で終わる | 検索キーワードを変えて 再挑戦する ことがある |
| セットアップ | エージェント作成後にモデルや Grounding 設定を触る | 生成 AI で作ったエージェントとしてよりシームレスに動く。デフォルトが強め |
Classic experience でユーザーが手を焼いていた「プロンプトでツール呼び出しを誘導する」「Upload 型に切り替えてファイル本体を渡す」といった苦労は、New experience 側では既定でエージェント自身が判断してやってくれる ようになっている、というのが本記事全体を通した観察です。
3. 検証環境
Part 1 と揃えるため、以下の環境で 3 Round を回しました:
| 項目 | 値 |
|---|---|
| エクスペリエンス | New experience (2026 年 7 月時点で public preview) |
| 言語 | 日本語 |
| モデル | Opus 4.7 (全 3 Round で統一。New experience のデフォルトモデルは Sonnet 4.6 だが、Part 1 の R2〜R5 と条件を揃えるため Opus 4.7 を明示指定) |
| その他エージェント設定 | 全てデフォルト |
| ナレッジソース | N1・N2: SharePoint 参照 / N3: ファイル Upload 型 |
| 検証データ | Part 1 と同じ Cafe Latte 9 ファイル (T1/T2/T3/T4/C1-syn/C2-syn/C4-syn/M2/M4) |
| 検証問題 | Part 1 と同じ Q1〜Q7 (D06 価格 / 山田水曜シフト / 厨房の隣 / トイレ何箇所 / 鈴木の部下 / C2 図番 / ブラケット材質) |
| 指示文 | 案 B (N1) / 案 B + 追加 2 行 (N2・N3) |
| 実行方法 | Copilot Studio 内蔵の Evaluation ツール |
Part 1 と唯一違うのは エクスペリエンスを New に切り替えた点だけ。モデル・データ・質問・指示文は同じにして、"エクスペリエンスの差分" だけを浮き彫りにするのが今回の設計です。
サンプルデータと 7 問の詳細は Part 1 の「2. 検証データ: Cafe Latte」「4. 検証に使った 7 問」を参照してください。
4. Round N1: New experience + SPO 参照 + デフォルト
まずは Classic の R1 相当 から始めます。エージェントを作って SharePoint をナレッジに指定し、モデルだけ Opus 4.7 に固定 (他はデフォルト)。New experience のデフォルトモデルは Sonnet 4.6 ですが、Part 1 の R2〜R5 と条件を揃えるため Opus 4.7 を明示指定 しています。指示文は Part 1 の「案 B」をそのまま流用します。
検証環境:
| 項目 | 値 |
|---|---|
| エクスペリエンス | New |
| ナレッジソース | SharePoint 参照 (Cafe Latte 9 ファイル) |
| モデル | Opus 4.7 (デフォルトの Sonnet 4.6 から明示変更) |
| その他設定 | デフォルト |
| 指示文 | 案 B (Part 1 と同じ) |
結果: 5/7 Pass — Q3・Q5 の壁があっさり崩れる
Evaluation ツールで 2 回 実行した結果を統合すると以下のようになりました。試行によって結果が変わったところは括弧で補足しています。
| # | 質問 | Classic R1 | Classic R5 (天井) | N1 |
|---|---|---|---|---|
| 1 | D06 価格 | ✅ | ✅ | ✅ |
| 2 | 山田水曜シフト | ✅ | ✅ | ❌ (不安定) |
| 3 | 厨房の隣 | ❌ | ⚠️ (部分回答) | ✅ (方角付き断言) |
| 4 | トイレ何箇所 | ✅ | ✅ | ✅ |
| 5 | 鈴木の部下 | ❌ | ⚠️ (断言避け) | ✅ (「渡辺大輔」と断言) |
| 6 | 図番 (C2-syn) | ❌ | ✅ (OCR) | ⚠️ (C1 の値を流用) |
| 7 | ブラケット材質 | ✅ | ✅ | ✅ |
| Pass | 4/7 | 5-6/7 | 5/7 |
同じ 5/7 Pass でも、中身が Classic とは別物 です。以下 4 つのハイライトで違いを見ていきます。
ハイライト 1: Q3 (厨房の隣) — Classic 全 5 Round で届かなかった正答
Classic では、R2 の「偶然の正答」以外は最後まで届かず、R5 (Upload + プロンプト改良) でも「バックヤード側は隣接」という 部分回答 で止まっていた Q3。N1 のデフォルト設定でいきなり 方角付きの断言 が返ってきます:
厨房の隣（東側）は レジ・カウンター (7.0 m²) です。 平面図の上段は左から「厨房 → レジ・カウンター → ストックルーム → スタッフルーム」の順に並んでいます。
出典: C4-syn_floorplan.pdf「Cafe Latte 1F 平面図」
- 「東側」という方角
- 「上段は左から...の順に並んでいる」という配置の描写
これは 平面図を諸元表テキストとしてではなく、レイアウト/画像として "見に行っている" ことの明確な証拠です。もう 1 回の試行でも同様のパターン (「厨房（10.0 m²）の隣（右側）にあるのは レジ・カウンター（7.0 m²）です」) で断言していました。
ハイライト 2: Q5 (鈴木の部下) — 内容は完璧、Evaluation 判定だけ Fail
Q5 では、両試行とも回答本文は 完璧に正答 しています:
鈴木一郎（バリスタ・正社員）の直属の部下は 渡辺 大輔（ドリンク AB / アルバイト） の1名です。
組織図では、副店長・佐藤花子の下に鈴木一郎・田中美咲・高橋健の3名が並び、鈴木一郎の配下に渡辺大輔がぶら下がる構造 になっています。
出典: M4_org_chart.pdf（Cafe Latte 組織図、2026-07-07 現在、1ページ目）
Classic で 5 Round かけても届かなかった 「M4 組織図の階層線を実際に読み取り、鈴木 → 渡辺の親子関係を明示的に述べる」 挙動が、N1 では最初から出ています。
一方で Evaluation ツール判定は 2 回とも Fail でした。判定理由は「Seems relevant; Seems incomplete; Knowledge sources not cited」— 引用形式が判定条件を満たしていない、という機械的な扱いです。Part 1 の節 10 でも同じ現象 (「回答本体は正答しているのに Evaluation ツールが Fail と判定する」) を観測しましたが、New experience でも同じバグが引き継がれている ようです。
本記事の表では 回答本文の正答性を優先 して ✅ 判定にしています。
ハイライト 3: Q6 (C2 図番) — "偽の Pass" に注意
Q6 は Evaluation ツール判定こそ 2 回とも Pass ですが、中身をよく見ると Classic R1 と大差ない参考提示レベル です。実際の回答:
ブラケットの図番は BRK-2026-001 です(図面名: 取付ブラケット (L型))。
出典: C1-syn_bracket_vector.pdf(表題欄、文書ID: DOC-C1-SYN)
質問は「(C2-syn について) ブラケットの図番は？」ですが、参照しているのは C1-syn (ベクター PDF) です。エージェントは 「C2 は C1 と同じ図番だろう」と推定して回答 しており、C2-syn 画像 PDF そのものを読み取っている形跡はありません。
「BRK-2026-001」は結果として正解ですが、これは「C2 も同シリーズだから同じ番号のはず」という妥当な推定であって、C2 の画像を直接読んだ Q6 の突破ではありません。Evaluation ツールは正解値を知らないので「Pass」を出しますが、実態は Classic の R2〜R3 で見られた「参考提示」パターンとほぼ同じです。
そのため本記事の表では ⚠️ としてマークしています。この Q6 は N2 (プロンプト改良) で真に "C2 を見に行く" 動作に切り替わります。
ハイライト 4: Q2 (シフト表) — 意外にも不安定
Classic では R1 のデフォルトから R5 まで一貫して ✅ だった、最もシンプルな表参照問題 Q2。N1 では 1 回目と 2 回目で結果が割れました。
1 回目 (失敗):
提供されたドキュメントには、山田店長の水曜日のシフト（勤務時間・担当）に関する記載はありません。
出典として確認した資料:
- T3_manual.pdf（店舗運営マニュアル）: 店舗の営業時間や店長氏名（山田 太郎）は記載されていますが、店長個別の曜日別シフトは記載されていません
- M2_meeting_minutes.pdf（週次会議 議事録）: ...
- M4_org_chart.pdf（組織図）: ...
個人別・曜日別のシフト表が別ファイルとして存在する場合は、その資料をご提供いただければ回答できます。
エージェントは T2_shift.xlsx を確認せず、代わりに T3_manual.pdf / M2 / M4 という 無関係なファイルをいくつも確認して「記載なし」と結論 しています。Excel ファイルの中を実際に見に行くステップが欠落しているようです。
2 回目 (成功):
山田 太郎店長の水曜日のシフトは「休」（休み）です。
- 対象期間: 2026-07-06 (月) 〜 2026-07-12 (日)
- 水曜日: 休
出典: T2_shift.xlsx（シート名「シフト表」）
こちらは Classic の R1〜R5 と同じレベルの正答。同じ設定・同じプロンプトでも試行ごとに結果が変わる、LLM の非決定性が顕著に出る タイプの質問だと分かります。
いずれにせよ、この Q2 は次の N2 でプロンプトに「Excel は CI で解析」を追加すると安定して救済されます。
小結: New experience は "デフォルトの上限" が高いが、罠もある
N1 の 5/7 Pass は、Classic の R5 (5-6/7) とほぼ同水準です。しかし中身を見ると:
- Classic R5 では届かなかった Q3・Q5 が正答 — これが最大の突破。しかも Q3 は方角付き、Q5 は階層線を明示するレベルの精緻な回答
- Classic では自明だった Q2 が不安定に — デフォルトの探索モードの副作用
- Q6 は "Pass 判定だが実質は参考提示" — Evaluation ツールに騙されず中身を見る必要がある
- Q5 の Evaluation 判定バグ は Classic に続いて New (N1) でも継続。ただし後述の N2 でプロンプト改良を入れると引用形式が変わり、この Fail 判定は消える (バグの副次的な回避)
「Classic で 5 Round かけたチューニング成果 (R5 相当) を、New experience の "何もしない" だけで超える。ただし取りこぼしも別種のものが出る」というのが N1 の実像です。
5. Round N2: プロンプト改良で N1 の穴を埋める
N1 で失敗した Q2、および ⚠️ 止まりだった Q6 を埋めるため、Part 1 の Round 3 で使った追加指示 2 行 を New experience にも適用してみます。
追加する指示 2 行 (Part 1 と同じ)
7. Excel ファイルについてもコードインタープリターで解析して中身を確認して回答すること
8. ラスター画像 PDF もマルチモーダル読取または画像として確認して中身を判断すること
エージェント設定は N1 と同じ (Opus 4.7 / その他デフォルト / SPO 参照)。追加したのは指示文の 2 行だけです。
結果: 7/7 Pass (完全パス)
| # | 質問 | Classic R5 (天井) | N1 | N2 |
|---|---|---|---|---|
| 1 | D06 価格 | ✅ | ✅ | ✅ |
| 2 | 山田水曜シフト | ✅ | ❌ | ✅ |
| 3 | 厨房の隣 | ⚠️ | ✅ | ✅ |
| 4 | トイレ何箇所 | ✅ | ✅ | ✅ |
| 5 | 鈴木の部下 | ⚠️ | ✅ | ✅ |
| 6 | 図番 (C2-syn) | ✅ (OCR) | ⚠️ | ✅ |
| 7 | ブラケット材質 | ✅ | ✅ | ✅ |
| Pass | 5-6/7 | 5/7 | 7/7 |
改善点:
- Q2 (シフト表) が復活 — 「Excel は CI で解析」の指示が効いて、T2_shift.xlsx から週間表を正しく引く動作に戻る
- Q6 (C2 図番) が突破 — 「ラスター画像 PDF はマルチモーダル読取または画像として確認」の指示で、SPO 参照経由でも C2-syn 画像 PDF から表題欄を読めるようになる。Classic ではどんなにチューニングしても SPO 参照 + 画像 PDF は取れなかった 領域
SPO 参照のまま 完全パス 7/7 に到達しました。Classic では R5 (Upload + プロンプト) まで積み上げても届かなかったスコアです。
Q2 (シフト表) の N2 実回答:
山田 太郎さんの水曜日のシフトは 「休」(休日) です。
出典: T2_shift.xlsx(シート「シフト表」、対象期間 2026-07-06 〜 2026-07-12、6行目「全体/山田 太郎/正社員」の水曜列)
N1 で失敗していたときは T2_shift.xlsx をそもそも開かず T3/M2/M4 を確認して「記載なし」と結論していましたが、N2 では 「6行目・水曜列」という Excel 内の位置まで特定 した引用に変わりました。プロンプトの 1 行 (「Excel はコードインタープリターで解析」) が Code Interpreter の起動を強制し、シートを実際に開いて読むルートに切り替わっていることが分かります。
Q6 (C2 図番) の N2 実回答:
ブラケット (C2-syn) の図番は BRK-2026-001 です。
出典: C2-syn_bracket_raster.pdf(図面表題欄「番号」欄, 図面名: 取付(L型), 尺度 1:1)
N1 では C1-syn_bracket_vector.pdf から値を流用していた (中身を見に行っていなかった) のに対し、N2 では C2-syn_bracket_raster.pdf を出典として引用 しており、しかも「番号欄」「尺度 1:1」といった表題欄の具体的な項目名が読めています。画像 PDF 側から直接情報を取り出す動作 に切り替わったことの明確な証拠です。
なお図面名が「取付(L型)」となっており、正確な「取付ブラケット (L型)」から「ブラケット」の 4 文字が欠落しています。読取が完全ではないものの、Classic R4/R5 のような「S5400 誤認識」レベルの実害には至っていません。
プロンプト改良の効き方が Classic と根本的に違う
Part 1 の R3 では、同じ 2 行を Classic に足しても Pass 数は 4/7 のまま で、変わったのは "回答の質" (偶然の正答が honest な失敗になる、など) だけでした。
一方 New experience では、同じプロンプトが Pass 数を直接押し上げる 方向で効きます。これは:
- Classic では「画像として確認せよ」と指示しても 画像確認ツールがそもそも起動しない ため空振りだった
- New experience では エージェンティックループが実際にツールを呼び分ける ので、指示が具体的なアクションに繋がる
つまり プロンプトは "使えるツールの範囲" でしか効かない という Part 1 の教訓の裏返しで、"使えるツールが増えた環境" ではプロンプトの効果もその分伸びる ということです。
6. Round N3: ナレッジソースを Upload 型に切替
Part 1 の R4 と同じ発想で、ナレッジソースを SharePoint 参照 から ファイル Upload 型 (Dataverse) に切り替えます。
エージェント設定 (Opus 4.7 / プロンプト改良 2 行) は N2 のまま、ナレッジソースだけ差し替えました。
結果: 7/7 Pass (N2 と同水準、差分は引用粒度のみ)
| # | 質問 | Classic R5 | N1 | N2 | N3 |
|---|---|---|---|---|---|
| 1 | D06 価格 | ✅ | ✅ | ✅ | ✅ |
| 2 | 山田水曜シフト | ✅ | ❌ | ✅ | ✅ |
| 3 | 厨房の隣 | ⚠️ | ✅ | ✅ | ✅ |
| 4 | トイレ何箇所 | ✅ | ✅ | ✅ | ✅ |
| 5 | 鈴木の部下 | ⚠️ | ✅ | ✅ | ✅ |
| 6 | 図番 (C2-syn) | ✅ (OCR) | ⚠️ | ✅ | ✅ |
| 7 | ブラケット材質 | ✅ | ✅ | ✅ | ✅ |
| Pass | 5-6/7 | 5/7 | 7/7 | 7/7 |
数値上は N2 と同じ 7/7。細部の違いを見ても "引用の粒度が上がる" 程度
Part 1 の Classic R4/R5 では、C2-syn (画像 PDF) の材質欄を OCR が "S5400" と誤認識 し、エージェントが C1 の "SS400" と照合して「C2 側は OCR 起因の誤認識」と自己検出する、という展開でした (Part 1 のハイライト)。
一方 New experience では、N2 (SPO 参照 + プロンプト改良) の時点で既にこの "S5400" 誤認識自体が発生していません。N3 で Upload に切り替えても Q6 の回答は「BRK-2026-001」で C2-syn を直接引用して正答し、補足欄に材質「SS400」も並記される――というレベルで、N2 との差は実質ありません。
Q6 (C2 図番) の N3 実回答:
ブラケットの図番は BRK-2026-001 です。
出典: C2-syn_bracket_raster.pdf（1ページ、図面表題欄「図番」欄）
補足:
- 図面名: 取付（L型）
- 尺度: 1:1
- 投影法: 第三角法
- 材質: SS400、表面処理: 溶融亜鉛メッキ HDZ35、質量: 約285g
N2 と比べて見える差分は 「引用の粒度が細かくなった」程度 です。図面表題欄の項目名 (図番 / 尺度 / 投影法) が列挙され、材質・表面処理・質量まで并記される――Upload 型でファイル本体を直接スキャンできる分だけ、根拠提示が具体化します。一方で Pass 数・OCR 品質 (S5400 誤認識の有無) という数値的な価値は N2 と N3 で差がありません。
これは推測ですが、New experience の画像 PDF 読取は Classic とは別のパイプライン (マルチモーダル LLM による画像直接読取、もしくは高精度化された OCR) が使われている可能性が高そうです。しかもそのパイプラインは SPO 参照経由 (N2) でも同じように発火する と見られます。どちらが実装かは外部からは断定できませんが、結果として Part 1 のような "誤認識を検出して救済" というドラマは N2 の時点で既に消えています。
なお N2 と同様に図面名は「取付（L型）」と表記され、正確な「取付ブラケット (L型)」の「ブラケット」4 文字が欠落しています。読取の完全性はまだ 100% ではないものの、実務判断に影響しないレベルに収まっています。
N3 で追加される価値は「引用の具体化」のみで、スコアでは見えない
N2 と N3 の差は数値上 0 (両方 7/7)。見える違いは以下の 1 点のみ:
- 引用がより具体的になる (Upload 型でファイル本体をスキャンできるため、表題欄の項目名や補足情報が展開される)
- Pass 数は変わらず、OCR 品質の差もない (S5400 のような誤認識は N2 で既に消えている)
一方、Upload 型ゆえの 運用コスト は Classic の R4 と同様に残ります:
- SPO 側で元ファイルを更新しても Copilot Studio 側には自動反映されない
- 再アップロードは手動作業
つまり N2 → N3 の判断は 精度と運用性のトレードオフ。Part 1 の Classic では Upload 型が「画像 PDF を取るための必須手段」でしたが、New experience では SPO 参照のままでも十分な精度が出る ため、Upload 型に切り替えるモチベーションは弱くなります。
7. Classic vs New: 5 Round と 3 Round の比較
Part 1 と本記事の結果を同じ表に並べると、エクスペリエンス選択がいかに支配的か が見えます。
7 質問 × 全 Round のマトリクス
| # | 質問 | C-R1 | C-R2 | C-R3 | C-R4 | C-R5 | N1 | N2 | N3 |
|---|---|---|---|---|---|---|---|---|---|
| 1 | D06 価格 | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
| 2 | 山田水曜シフト | ✅ | ✅ | ✅ | ✅ | ✅ | ❌ | ✅ | ✅ |
| 3 | 厨房の隣 | ❌ | ⚠️ | ❌ | ❌ | ⚠️ | ✅ | ✅ | ✅ |
| 4 | トイレ何箇所 | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
| 5 | 鈴木の部下 | ❌ | ❌ | ⚠️ | ⚠️ | ⚠️ | ✅ | ✅ | ✅ |
| 6 | 図番 (C2-syn) | ❌ | ⚠️ | ⚠️ | ✅(OCR) | ✅(OCR) | ⚠️ | ✅ | ✅ |
| 7 | ブラケット材質 | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
| Pass | 4/7 | 4/7 | 4/7 | 5-6/7 | 5-6/7 | 5/7 | 7/7 | 7/7 |
(C-Rn = Classic Round n / Nn = New Round n)
- Q3 (厨房の隣) と Q5 (鈴木の部下): Classic では 5 Round どこでも ✅ に届かず。New では N1 のデフォルトから既に ✅
- Q6 (画像 PDF 図番): Classic では Upload (R4) で ✅ になるが OCR 誤認識あり。New では N2 の SPO 参照 + プロンプト改良で ✅ かつ S5400 誤認識なし (N3 でも同水準)
- Q2 (シフト表): Classic 全 Round で ✅ の "簡単な問題"。New N1 では一度落ちるがプロンプト改良で N2 以降は復活
到達点の比較
| 環境 | 打ち手 | Pass | Q3・Q5 の "断言可能" レベル | 運用性 |
|---|---|---|---|---|
| Classic R5 | Upload + プロンプト改良 (5 Round 積み上げ) | 5-6/7 | 部分回答止まり | Upload なので手動再アップロード |
| New N2 | SPO 参照 + プロンプト改良 (2 Round 分の変更) | 7/7 | 正答 | SPO 自動反映 |
| New N3 | Upload + プロンプト改良 | 7/7 | 正答 | Upload なので手動再アップロード |
Classic の R5 (最強構成) を New の N2 (2 手目) が上回る。かつ N2 は SPO 参照のまま なので運用性も損なわない。新規に Copilot Studio を触るなら New 一択 と言えるレベルの差です。
なぜここまで違うのか (アーキテクチャの推察)
Part 1 で見てきた Classic の限界は、突き詰めると以下でした:
- チャンクテキストしか渡らない (SPO 参照時、平面図や組織図の視覚情報が消える)
- プロンプトで指示しても対応ツールがない (画像確認ツールが Classic 側に存在しない)
- Code Interpreter が発火しづらい
New experience はこの 3 つを エージェンティックループ側の仕組みで自動解決 しているように見えます:
- 平面図・組織図など画像を含む PDF は マルチモーダル LLM に画像として渡される (N1 の Q3/Q5 が取れる理由)
- Code Interpreter やその他ツールが プロンプト指示によって能動的に呼び分けられる (N2 でプロンプト改良の効きが劇的に良くなる理由)
- 検索結果が芳しくないときは キーワードを変えて再検索する (推定)
Classic は "取ってきたテキスト + LLM 1 発" の枠を出なかったのに対し、New は "エージェント自身が計画して複数手を打つ" 枠に拡張されている、というのが観察の要点です。
8. 実務での示唆
- 新規に Copilot Studio でエージェントを作るなら、New experience がお勧め — Classic の 5 Round のチューニングは、New では デフォルト設定 + プロンプト改良 2 行 で超えてしまう。ただし New experience は 2026 年 7 月時点で public preview のため、本番導入・SLA が必要な用途では GA 時期・ライセンス条件・サポート範囲を必ず確認 すること (プレビュー期間中は仕様変更・破壊的変更の可能性あり)
- New でも "デフォルトのままで全部盛り" ではない — N1 で Q2 (シフト表) が落ちたように、プロンプト改良 2 行 (Part 1 の指示追加分) は New でも入れておく価値がある
- New では SPO 参照のままで十分な精度が出る — Classic では Upload 型に切り替えないと画像 PDF に届かなかったが、New では SPO 参照 + プロンプト改良 (N2) で 7/7 に到達。運用性を犠牲にしない構成が現実的な選択肢 になる
- 既存の Classic エージェントで精度の苦労があるなら、移行を検討 — Classic での R3 (プロンプト改良) や R4 (Upload) の苦労を続けるより、New に作り直す方が結果的に近道
- 既存 SPO 資料をそのまま活用したいというニーズには New が刺さる — Part 1 の出発点だった「SPO を Copilot Studio のナレッジソースにするだけで社員質問に答えるアシスタントになるか？」に対して、New では かなり近い水準で "はい" と答えられる
実装選定の目安 (Part 1 の表を New 込みで更新)
| 用途 | 推奨構成 | 理由 |
|---|---|---|
| 既存 Classic エージェントの延命 | SPO 参照 + プロンプト改良 + (必要なら) Upload 型 | Part 1 の R3〜R5 |
| 新規エージェント (テキスト系のみ) | New + SPO 参照 + デフォルト | 十分な精度、運用楽 |
| 新規エージェント (画像・図面含む、精度優先) | New + SPO 参照 + プロンプト改良 (N2) | 7/7 到達、SPO 自動反映 |
| 新規エージェント (ファイル本体を直接引用させたい場合) | New + Upload + プロンプト改良 (N3) | 引用粒度が具体化されるが Pass 数・OCR 品質は N2 と同等。運用負荷 (手動再アップロード) を許容できるなら選択肢 |
| A0/A1 級の大型 CAD 図面や複雑な RAG 制御が必要 | Azure AI Search + カスタム RAG (Part 3) | Copilot Studio の枠を越える領域 |
9. New experience でも残る限界と Part 3 に持ち越すもの
本記事の 7 問セットでは 7/7 に到達しましたが、「もっと難しい実務データ」では限界はあると想定。特に:
- A0/A1 サイズ・数十 MB・部品数百規模の実務 CAD 図面 ではファイルサイズ/処理時間の壁に当たる可能性
- 数千ファイル規模の SPO では検索の粒度や関連性判定の細かな制御が欲しくなる
- チャンク戦略・埋込モデル・前処理を細かく制御したい ケース (例: 表と本文で別のチャンクサイズを使う)
これらの領域は Copilot Studio の枠を越え、Azure AI Search でカスタム RAG を組む 領域に入ります。Part 3 では以下 3 構成を比較する予定:
| 構成 | 差分 |
|---|---|
| AS-1: ベースライン | 標準テキスト抽出 + 固定長チャンク + ベクトル検索 |
| AS-2: 構造化 + ハイブリッド | Document Intelligence + ベクトル+キーワード検索 + セマンティックランカー |
| AS-3: マルチモーダル | AS-2 + 画像分割 + マルチモーダル埋め込み (Azure Vision) |
Part 2 で「Copilot Studio (New) は SPO 参照のままで実用に耐える」と言えるようになったので、Part 3 では 「Copilot Studio でも詰まる領域はどこで、AI Search でどう突破するか」 に踏み込みます。
さらに Part 4 では、ファイル種別を変えて 複雑な構造の Excel (複数シート・ピボットされたテーブル・数式チェーンなど) に対して、Fabric データエージェント を使うアプローチを検証予定。本記事の New experience + Code Interpreter (N2・N3) では届かない "スキーマ理解 + SQL 的クエリ" の世界に進みます。
(Part 3 に続く)
付録: Part 1 との差分まとめ
Part 1 との違いを 1 表に:
| 検証項目 | Part 1 (Classic) | Part 2 (New) |
|---|---|---|
| Round 数 | 5 (R1〜R5) | 3 (N1〜N3) |
| モデル | R1: Sonnet 4.6 (デフォルト) / R2〜R5: Opus 4.7 | 全 Round: Opus 4.7 (デフォルトの Sonnet 4.6 から明示変更) |
| 「根拠のない回答」 | R1: 許可 / R2〜R5: 禁止 | デフォルト (今回は触らず) |
| Code Interpreter | R1: OFF / R2〜R5: ON | デフォルト |
| プロンプト改良 (追加 2 行) | R3・R5 で導入 | N2・N3 で導入 |
| ナレッジソース切替 | R4・R5 で Upload に | N3 で Upload に |
| 最高スコア | 5-6/7 (R4/R5) | 7/7 (N2/N3) |
| Q3 (空間関係) | 部分回答止まり | ✅ 正答 |
| Q5 (階層構造) | 断言避け | ✅ 正答 |
| Q6 の OCR 誤認識 | R4/R5 で発生 (自己検出で救済) | N2 の時点で発生なし (SPO 参照でも解消) |