本記事について
本記事は「Copilot Studio × 非構造化データ」検証シリーズの Part 3 です。前々編 (Part 1) では Standard Harness (Classic UI) を 5 Round に分けて検証し 5-6/7 で頭打ちという結論に達し、前編 (Part 2) では GitHub Copilot Harness (New UI) で 7/7 完全パスに到達しました。本記事では GitHub Copilot Harness の従量課金化 を受け、定額の Standard Harness で実務に耐える構成をもう一度突き詰めます。
- Part 1: Copilot Studio (Standard Harness / Classic UI)
- Part 2: Copilot Studio (GitHub Copilot Harness / New UI)
- Part 3: Standard Harness (Classic UI) を極める ← いまここ
- Part 4: Azure AI Search + カスタム RAG (執筆予定)
- Part 5: Fabric データエージェント (複雑 Excel 対応、執筆予定)
本検証は 2026 年 8 月時点 のスナップショットです。Copilot Studio の仕様・モデルは日々更新されるため、数値は 参考値 としてご理解ください。
重要 (プレビュー機能に関する注意): 本記事の要となる Code Interpreter は 2026 年 8 月時点でプレビュー段階 の機能です。仕様変更・課金体系の変更・不具合の可能性があり、本番運用・SLA・ライセンス条件・サポート対象の範囲は GA 版と異なる場合があります。本番導入の判断にあたっては、必ず最新の Microsoft 公式ドキュメントおよびライセンス条項をご確認ください。
TL;DR
- Part 2 の GitHub Copilot Harness (New UI) が従量課金化 したため、定額の Standard Harness (Classic UI) の実務価値が再浮上した。「Standard Harness でも同水準に届く手段はないか」を再検証
- Part 1 の R5 (5-6/7 天井) に対し、以下の "打ち手" で 評価ツール・Chat の両方で 3 セット全て 7/7 (完全正解) に到達:
- SharePoint コネクタ (
パスによるファイル コンテンツの取得) をツールとしてエージェントに追加 - プロンプトを刷新 — 「SharePoint コネクタで取得 → Code Interpreter で直接解析」を明示、ファイル名グロッサリ と SharePoint コネクタ実行時のファイルパス指定 を仕込む
- モデルを Opus 4.8 に更新 (Part 1・Part 2 は Opus 4.7)
- その他 Part 1 R2 の設定 (「根拠のない回答」禁止 / CI ON / Web 検索 OFF) はそのまま流用
- SharePoint コネクタ (
- Part 1 R3〜R5 で CI 関連のプロンプト指示が実質空振りだった理由は明快 — コネクタが未登録のため CI がファイル本体に到達できなかった から。同じ Code Interpreter でも "エージェント側で使えるツール" が違えば結果は劇的に変わる
- ただし Standard Harness を実運用に載せるには 設計時に想定すべきクセ が複数ある: CI 発火後のセッション不安定性、SPO 検索インデックスの非決定性、リセット機構の不動作、Code Interpreter プレビューの課金/不具合リスク。本記事はこれらの対処もあわせて整理する
- 結論: Standard Harness は "適切な設計を施せば" GitHub Copilot Harness に精度で並ぶ (7/7)。単発 Q&A / コスト優先 / 既存 SPO 資産活用が主目的なら、Standard Harness は依然として有力な選択肢
1. なぜ Standard Harness を再検証するのか
Part 3 の動機は 2 つあります。
動機 1: GitHub Copilot Harness の従量課金化
Part 2 で検証した GitHub Copilot Harness (New UI) は、"何もしなくても 5/7、プロンプト 2 行足せば 7/7" という強力なアーキテクチャで、Part 1 の Standard Harness (5-6/7 天井) を圧倒しました。「新規に Copilot Studio を触るなら New 一択」と Part 2 で結論したくらいです。
しかし Part 2 執筆後、GitHub Copilot Harness は 従量課金モデル に移行しました。これは実務判断に大きな影響を与えます:
- 想定 QPS × コスト単価 のランニングコスト予測を立てる必要が生じた
- 単発 Q&A ボット (FAQ 系) では、定額の Standard Harness が想定使用量・組織規模によっては大幅に安く済む
- 「せっかく Copilot Studio に投資したのに、コスト面で採用を止められる」を避けたい
Standard Harness で "定額の範囲内" で GitHub Copilot Harness に近い精度が出せれば、実務での選択肢が広がる — これが Part 3 の動機 1 です。
動機 2: 同じ Code Interpreter なのに、なぜ Standard Harness では空振りするのか
Part 1 で見えた疑問があります。R3〜R5 で「Excel は Code Interpreter で解析」「画像 PDF はマルチモーダル読取」というプロンプト指示を入れても、数値上の Pass 数は R2 と変わらず 4/7 のままでした。
一方、Part 2 では 同じ 2 行のプロンプト を GitHub Copilot Harness に足すだけで 7/7 に押し上がる。同じ Code Interpreter を持っている両ハーネスで、なぜここまで挙動が違うのか?
Part 1 では「Standard Harness の仕組み上、CI が発火しづらい」という推測で終わっていましたが、Part 3 ではこの謎を掘り下げて、Standard Harness でも CI を確実に発火させる方法 を確立します。結論から言えば、答えは 「SharePoint コネクタをツールとして登録し、プロンプトで明示的に呼ばせる」 に尽きます。詳しくは節 5・6 で扱います。
2. 検証環境
Part 1・Part 2 と揃えるため、以下の環境で検証しました。Part 1 の R5 から変更した項目 を太字で示します。
| 項目 | 値 |
|---|---|
| エクスペリエンス | Standard Harness (Classic UI) |
| 言語 | 日本語 |
| モデル | Opus 4.8 (Part 1・Part 2 は Opus 4.7 だった) |
| 「根拠のない回答」 | 禁止 (Part 1 R2 と同じ) |
| Code Interpreter | ON (Part 1 R2 と同じ、ただしプレビュー扱い) |
| Web 検索 | OFF (Part 1 R2 と同じ) |
| ツール登録 |
SharePoint - パスによるファイル コンテンツの取得 コネクタを追加 (Part 3 の必須手順) |
| ナレッジソース | SharePoint 参照 (Cafe Latte 9 ファイル、Upload 型ではない) |
| 検証データ | Part 1・Part 2 と同じ Cafe Latte 9 ファイル (T1/T2/T3/T4/C1-syn/C2-syn/C4-syn/M2/M4) |
| 検証問題 | Part 1・Part 2 と同じ Q1〜Q7 (D06 価格 / 山田水曜シフト / 厨房の隣 / トイレ何箇所 / 鈴木の部下 / C2 図番 / ブラケット材質) |
| 指示文 | 案 C (Part 1 の案 B から刷新、詳細は節 4) |
| 実行方法 | Copilot Studio 内蔵の Evaluation ツール + Chat (テスト キャンバス) の両方 |
サンプルデータと 7 問の詳細は Part 1 の「2. 検証データ: Cafe Latte」「4. 検証に使った 7 問」を参照してください。
Part 1 R5 との差分は 3 点だけ:
- SharePoint コネクタをツールとして追加 (これが最大の差)
- プロンプトを案 B → 案 C に刷新 (SharePoint コネクタと CI の強制発火、ファイル名グロッサリ、パス指定)
- モデルを Opus 4.7 → Opus 4.8 に更新
なお 接続方法は SPO 参照のまま で、Upload 型に切り替えていません。これは実務での運用性 (SPO 側でファイルを更新すれば自動反映) を維持したかったためです。
3. 必須の "前提設定": SharePoint コネクタをツールとして追加
Part 1 執筆時の私は この 1 手を見落としていました。Standard Harness で「Code Interpreter でファイル本体を解析させる」ためには、エージェントの "ツール" として SharePoint コネクタが登録されている必要がある のです。
具体的には Copilot Studio の エージェント → ツール → コネクタ から SharePoint - パスによるファイル コンテンツの取得 を追加します。
なぜこれが必須なのか (証拠)
Part 3 の検証中、コネクタを未登録のまま「Excel は CI で解析」「画像 PDF はマルチモーダル読取」といったプロンプトを与えて質問を投げてみました。すると Code Interpreter は起動するものの、以下のエラーで停止します:
To proceed, please either upload the "C4-syn_floorplan.pdf" file directly,
or provide access to a connector that retrieves files from SharePoint.
Without the PDF or a means of access, the task cannot be performed.
CI が「ファイル本体にアクセスする経路がない」と正直に申告している のです。つまり Part 1 の R3〜R5 で「Excel は CI で解析」というプロンプト指示が空振りしていた原因は、Code Interpreter そのものではなく、SharePoint コネクタが未登録だったこと。
実際の画面イメージ (Q3「厨房の隣は？」を投げたとき):
- 左のフロー: リソースを検索する (ナレッジ) → コード (プレビュー) の 2 段で終わっている (SharePoint コネクタの段が存在しない)
- 中央のツール詳細:
No code generatedと表示され、Python コードが 1 行も走らずに終了。エラーメッセージは上記の英文 - 右の応答: 「ファイル本体を直接取得できませんでしたが、検索結果として取得済みの平面図テキスト情報から回答いたします」 — 結局チャンクテキストからの部分回答にフォールバックし、Part 1 R5 と同じ "バックヤード側は隣接" 止まりで着地する
つまり CI が発火はしても、ファイル本体に届かないので Python コードが生成できない = プロンプトの誘導が空回りしている状態です。これが Part 1 の R3〜R5 で数値が伸びなかった真の原因です。
コネクタを追加すると、エージェントは以下のフローで動けるようになります:
- リソースを検索する (ナレッジ検索) — ファイル名の候補を掴む
- パスによるファイル コンテンツの取得 (SharePoint コネクタ) — ファイル本体を取得
- コード (プレビュー) (Code Interpreter) — 取得したファイルを Python で解析
- 解析結果に基づき回答
この 3 段のパイプラインが動いて初めて、Standard Harness で画像 PDF や複雑 Excel が読めるようになります。
ツール登録時の設定ポイント: Site Address はカスタム値で固定する
コネクタを追加する際、Site Address と File Path の 2 つの入力パラメータをどう扱うかを設定します。実用上は以下の割り当てが扱いやすいです:
| 入力名 | 設定方法 | 値の例 |
|---|---|---|
| Site Address (dataset) | カスタム値 で固定 | 対象 SharePoint サイトの URL (例: https://<tenant>.sharepoint.com/sites/test-demo-spo-001) |
| File Path (path) | AI で動的に入力する | エージェントが質問に応じて生成 (例: /Shared Documents/Knowledge/T2_shift.xlsx) |
Site Address をカスタム値で固定 することで、エージェントは毎回サイト URL を組み立てる必要がなく、ファイルパスだけを生成すれば良い シンプルな状態になります。プロンプトでも「サイト名は含めず /Shared Documents/... の形式で」とだけ指示すれば十分です (節 4 の案 C 参照)。
もし複数の SharePoint サイトを対象にしたい場合は Site Address も AI 入力にする選択肢もありますが、エージェント側のパス組み立ての難易度が上がるため、可能なら 1 サイト = 1 エージェント の割り切りが実用的です。
なお本記事の検証では、この設定で 接続先アカウント (Connection) も明示的に紐付け ています。運用ユーザーの権限で SharePoint へアクセスさせるか、共有アカウントで固定させるかは、組織のガバナンス方針に合わせて選択してください。
4. 新プロンプト設計: 案 C
Part 1 の「案 B」を土台に、Part 3 では以下 3 つの改良を加えた 案 C を用意しました。
案 C の全文
# 役割
あなたは Cafe Latte 運営情報の Q&A アシスタントです。ユーザーからの質問に、
登録されたナレッジソース (Excel / PDF / Word 等) の内容のみに基づいて日本語で
回答してください。
# 回答ルール
1. **必ず出典を示すこと**: 回答の根拠となったファイル名 (と可能であれば
ページ番号やシート名) を必ず明示してください。
2. **ナレッジソースに書かれていないことは推測しない**: 情報が見つからない場合は
「提供されたドキュメントには記載されていません」と正直に回答してください。
あなたの一般知識で補完しないでください。
3. **計算・集計が必要な質問**: ドキュメント内の数値から計算する場合は、
計算過程を示してください (例: 「A=100、B=200 なので合計300」)。
4. **表の読み取り**: 表形式の情報を回答する際は、列名と値を対応させて
明確に示してください。
5. **複数ファイルにまたがる情報**: 複数のファイルから情報を集めて回答する場合、
それぞれのファイル名を明示してください。
6. **曖昧な質問**: 質問が曖昧で複数解釈可能な場合、想定した解釈を最初に示してから
回答してください。
7. **Excel ファイル**は通常の知識検索で見つけた後、必ず Code Interpreter で
シートを直接解析してから回答すること (SharePoint コネクタでファイル本体を
取得できればより望ましいが、検索でヒットした結果を優先すること)。
8. **PDF・Word・PowerPoint**、および組織図・図面が回答根拠となる場合は、
必ず SharePoint コネクタで対象ファイルを取得すること。取得したファイルに
対して必ず Code Interpreter を実行し、ファイルを直接解析してから回答すること。
# SharePoint コネクタ実行時のファイルパス
絶対にファイルパスにサイト名は含めず、ナレッジで参照している以下の様なパスを利用すること
/Shared Documents/Knowledge/<File Name>
# ナレッジファイル一覧 (参考)
- T2_shift.xlsx: スタッフシフト表 (勤務・シフト・出勤・休日情報)
# 出力形式
- 結論を最初に 1-2 文で述べる
- 続いて根拠となる引用元を「出典: 〜」の形式で列挙する
- 必要に応じて補足情報を付ける
Part 1 案 B からの主要な変更点
| # | 変更 | 狙い |
|---|---|---|
| 7 | 「Excel は CI で解析」→ 「通常検索で見つけた後、必ず CI で解析」 に変更 | CI 発火を "任意" から "必須" に格上げ |
| 8 | 「画像 PDF はマルチモーダル読取」→ 「必ず SharePoint コネクタで取得 → 必ず CI で解析」 に変更 | コネクタ経由の直接取得を強制する |
| 新規 | SharePoint コネクタ実行時のファイルパス セクションを追加 | エージェントが正しい形式のパス (/Shared Documents/…) を組み立てられるようにする |
| 新規 | ナレッジファイル一覧 (参考) セクションを追加 (ファイル名グロッサリ) | 検索インデックスに乗りにくいファイル (T2_shift.xlsx など) にコネクタ経由でリーチさせる |
| 出力形式 | 具体性を上げた表現に微調整 | 出典の明示性を強化 |
3 つの改良ポイントの詳細
(a) コネクタ・CI の "強制" 化
「望ましい」ではなく「必ず」と書くことで、エージェントの計画段階で コネクタと CI が必ずルートに乗る ようになります。エージェンティックな挙動ではないため、Standard Harness ではこの明示性が重要でした。
(b) SharePoint コネクタ実行時のファイルパスの明示
エージェントが SharePoint コネクタを呼ぶ際、コネクタは サイトアドレス + ファイルパス を要求します。プロンプトに「サイト名は含めず /Shared Documents/Knowledge/<File Name> の形式で」と フォルダ名を Knowledge に固定 して指定することで、評価ツール環境でも Chat 環境でも、パスの生成に迷わなくなり、安定してファイル取得が成功する 効果があります。このパスは本検証の Cafe Latte ナレッジの格納位置 (SharePoint サイトの Documents ライブラリ直下の Knowledge フォルダ) に合わせています。実ナレッジのフォルダ名に合わせて適宜変更してください。
余談ですが、Part 3 の初期検証では <Folder Name> のような プレースホルダ形式で指定した場合、たまにエージェントがフォルダ名の推測を間違えて 404 を返すケース がありました。フォルダ名をリテラルでプロンプトに埋め込む方が安定です。
(c) ファイル名グロッサリ
Standard Harness の SPO 検索インデックスは、結合セルや複数ヘッダを持つ複雑な Excel を拾いきれない ことがあります (Part 3 の検証では T2_shift.xlsx が典型例)。「シフト」というキーワードで検索してもヒットしない、というリアルな不安定性がありました。
対策として プロンプトに主要ファイル名の "対応表" を仕込む と、エージェントは検索でヒットしなくても「シフト = T2_shift.xlsx」を推測でき、SharePoint コネクタで直接ファイル本体を取りに行けます。"検索の穴" をプロンプト側で埋める アプローチです。
5. 検証結果: 3 セット全て 7/7 (完全正解)
スコアマトリクス
| # | 質問 | Classic R5 (Part 1 天井) | New N2 (Part 2 天井) | Part 3 案 C |
|---|---|---|---|---|
| 1 | D06 価格 | ✅ | ✅ | ✅ |
| 2 | 山田水曜シフト | ✅ | ✅ | ✅ |
| 3 | 厨房の隣 | ⚠️ (部分回答) | ✅ | ✅ (方角付き断言) |
| 4 | トイレ何箇所 | ✅ | ✅ | ✅ |
| 5 | 鈴木の部下 | ⚠️ (断言避け) | ✅ | ✅ (「渡辺大輔」と断言) |
| 6 | 図番 (C2-syn) | ✅ (OCR、S5400 誤認識あり) | ✅ | ✅ (SS400 正答) |
| 7 | ブラケット材質 | ✅ | ✅ | ✅ |
| Pass | 5-6/7 | 7/7 | 7/7 |
評価ツール・Chat の両方で 3 セット全て 7/7 (完全正解) を達成しました。Part 1 R5 が 5-6/7 で頭打ちだったのを 完全に突破 し、Part 2 N2 (GitHub Copilot Harness) と 同スコアを Standard Harness (定額) で 実現したことになります。
ハイライト 1: Q2 (山田水曜シフト) — ファイル名グロッサリの威力
Part 3 の実験過程で判明したのですが、T2_shift.xlsx は SPO の検索インデックスに乗っていません。「シフト表 Excel 山田 スケジュール」等のクエリで検索しても、返ってくるのは M2 / M4 / T3 / T4 の PDF ばかりで、T2_shift.xlsx はヒットしません。
Part 1 執筆時にはヒットしていた記憶がありますが、SPO の検索インデックスは時間とともに挙動が変わるようで、同じ環境でも再現性が保証されない のが実情です (結合セル・複数ヘッダの Excel は特に脆い印象)。
案 C ではこの問題を ファイル名グロッサリ で回避します。エージェントは「シフト」というキーワードから T2_shift.xlsx の存在を推測し、SharePoint コネクタで /Shared Documents/Knowledge/T2_shift.xlsx を直接取得 → Code Interpreter でシートを解析 → 「6行目・水曜列」まで特定した回答を返します:
山田 太郎店長の水曜日のシフトは「休」（休日）です。
出典: T2_shift.xlsx（シート「シフト表」、対象期間 2026-07-06 〜 2026-07-12、6行目「全体/山田 太郎/正社員」の水曜列）
"検索の穴" を "プロンプトの知識" で埋める 実用テクニックです。ファイル数が数十〜数百程度の社内 KB なら、この "ナレッジマップ" 的グロッサリは十分現実的な運用手段になります。
ハイライト 2: Q3 (厨房の隣) — Part 1 で届かなかった "方角付き断言"
Part 1 では 5 Round 通じて Q3 は届かず、R5 でも「バックヤード側は隣接」という部分回答止まりでした。Part 3 では SharePoint コネクタで C4-syn_floorplan.pdf を取得 → CI で解析 することで、以下の断言に到達します:
厨房の東隣（右隣）は「レジ・カウンター」です。
平面図の最上段（奥行 5.5〜8.0 m の帯）を西から東へ見ると、
厨房 → レジ・カウンター → ストックルーム → スタッフルーム の順に並んでいます。出典: C4-syn_floorplan.pdf（Cafe Latte 1F 平面図）
Part 2 の N1 と同水準の方角付き回答 が Standard Harness でも実現できました。CI がファイル本体にアクセスできれば、レイアウト情報から空間関係を推論できる、というのが Part 3 の重要な発見です。
ハイライト 3: Q5 (鈴木の部下) — 階層断言 + ツリー展開
Part 1 の R3〜R5 では、Q5 は「直属の部下は明示的に記載されていません」と留保する挙動でした。Part 3 では M4_org_chart.pdf を CI で解析し、以下の断言 + ツリー表示に到達:
鈴木一郎（バリスタ・正社員）の直属の部下は、渡辺 大輔（ドリンク AB） 1名です。
組織図を確認したところ、階層構造は以下のようになっています。
- 山田 太郎（店長）
- 佐藤 花子（副店長）
- 鈴木 一郎（バリスタ／正） ← ここから枝分かれ
- 渡辺 大輔（ドリンク AB）
- 田中 美咲（キッチン／正）
- 高橋 健（ホール AB／シフト L）
- 伊藤 さくら（ホール AB）
- 中村 優（ホール AB）
出典: M4_org_chart.pdf（Cafe Latte 組織図／2026-07-07 現在）
Part 1 で 5 Round かけて届かなかった 視覚的な階層読み取り が、Standard Harness でも実現できました。
ハイライト 4: Q6 (C2 図番) — SS400 まで正しく取得
Part 1 R4/R5 では、Upload 型でも C2-syn の材質欄が "S5400" と OCR 誤認識されるドラマがありました。Part 3 では SPO 参照のまま、C2-syn_bracket_raster.pdf を SharePoint コネクタで取得 → CI で解析 することで、以下の回答:
C2-syn のブラケットの図番は BRK-2026-001 です。
出典: C2-syn_bracket_raster.pdf（タイトルブロック）
補足情報 (タイトルブロック抽出値):
- 図番: BRK-2026-001
- 図面名: 取付ブラケット (L 型)
- 材質: SS400
- 表面処理: 溶融亜鉛メッキ HDZ35
- 質量: 285 g
- ...
材質を「SS400」と正しく読めており、S5400 の誤認識は発生していません。Part 1 R4/R5 の "誤認識検出ドラマ" は Part 3 では消えます。
6. Part 1 R5 との差分と、何が効いたのか
「同じ Standard Harness で、Part 1 R5 は 5-6/7、Part 3 案 C は 7/7」— この差はどこから来たのでしょうか。要因を分解すると:
| 要因 | Part 1 R5 | Part 3 案 C | 効いた度合い |
|---|---|---|---|
| SharePoint コネクタのツール登録 | ❌ 未登録 | ✅ 登録 | ★★★★★ (これがないと始まらない) |
| プロンプトで CI 発火を "必須" 化 | 「望ましい」レベル | 「必ず」レベル | ★★★★ |
| ファイル名グロッサリ | なし | あり | ★★★★ (T2_shift.xlsx 救済に必須) |
| SharePoint パス指定 | なし | あり | ★★★ (Evaluation ツールでの成功率が向上) |
| モデル | Opus 4.7 | Opus 4.8 | ★★ (直接効果は限定的だが賢さは上がる) |
| 接続方法 | Upload 型 | SPO 参照のまま | Part 1 R5 は Upload の運用負荷あり、Part 3 は自動反映 |
最も効いたのは "SharePoint コネクタのツール登録" です。Part 1 の R3〜R5 でプロンプトを工夫しても数値が伸びなかった真因は、Code Interpreter がファイル本体にアクセスする経路が存在しなかったから。プロンプトは "使えるツールの範囲内" でしか効かない、という Part 1 の教訓が改めて裏付けられました。
言い換えると、Standard Harness の "限界" は多くの場合 "設定の未実施" であって、アーキテクチャの絶対的な限界ではない ということです。ツール登録・プロンプト設計・ファイル名グロッサリを揃えれば、Standard Harness は依然として実用に耐えます。
7. Part 2 (GitHub Copilot Harness) との対比
Standard Harness と GitHub Copilot Harness を "同じ 7/7" に揃えた上で、実務目線で比較します。
| 観点 | Standard Harness (Part 3 案 C) | GitHub Copilot Harness (Part 2 N2) |
|---|---|---|
| 精度 | 7/7 (評価ツール・Chat 両方で 3 セット完全正解) | 7/7 (評価ツール判定) |
| 課金 | 定額 (M365 Copilot ライセンス内。※ Code Interpreter は GA 時に要確認) | 従量課金 (別途消費コスト) |
| 設計コスト (初期) | プロンプト設計・ツール登録・ファイル名グロッサリの整備が必要 | プロンプト 2 行を足すだけ |
| 運用コスト (継続) | ファイル名グロッサリの保守 (ファイル追加・削除に追従) | ほぼ不要 |
| 多ターン会話の安定性 | 弱い (CI 発火後にセッションが不安定化。CI がプレビュー機能であることに起因する可能性。詳細は節 8) | 強い (エージェンティックループが会話状態を管理) |
| SPO 検索の再現性 | やや不安定 (複雑 Excel が検索インデックスに乗らないことがある) | 同様の脆さはあるが、グロッサリ不要でもエージェント側で補正しやすい |
| 図・画像の扱い | プロンプトでコネクタ + CI を明示強制 → 動く | デフォルトでマルチモーダル読取が動く |
| Code Interpreter のプレビュー扱い | 要注意 (Standard Harness では CI 前提の設計) | GA |
どこで差がつくか
- 単発 Q&A / FAQ ボット / コスト重視のケース → Standard Harness に分がある。定額の強みが効く
- 多ターン会話 / チャットアシスタント / エージェント的な使い方 → GitHub Copilot Harness に分がある。セッション安定性と柔軟性が効く
- 設計・運用工数を最小化したい → GitHub Copilot Harness (プロンプト 2 行で済む)
- 既存 SPO 資産を活用したい・ナレッジソースが固定的 → 両者とも対応可、コスト観点で Standard Harness が魅力
8. 実運用上のクセと対処 (Standard Harness のリアル)
Part 3 の検証で見えた、実運用時に想定して設計すべき Standard Harness のクセを整理します。数値スコアには現れませんが、本番運用の可否を左右するポイント です。
クセ 1: 複雑 Excel が SPO 検索インデックスに乗らない
- 症状: T2_shift.xlsx (結合セル・複数ヘッダの Excel) が「シフト」等のキーワード検索でヒットしない
- 原因推測: SPO のインデックス化が複雑構造の Excel をうまくチャンク化できていない可能性
- 対処: プロンプトにファイル名グロッサリを仕込む。エージェントに「シフト → T2_shift.xlsx」の紐付けを与え、SharePoint コネクタで直接取得させる (案 C の運用)
クセ 2: SPO 検索インデックスの再現性が保証されない
- 症状: Part 1 執筆時 (2026-07) には T2_shift.xlsx がヒットしていた記憶があるが、Part 3 執筆時 (2026-08) には全くヒットしない。Part 1 のプロンプトに戻してもヒットしない
- 原因推測: SPO 側の再インデックス、Copilot Studio 側の検索仕様変更、複雑 Excel のインデックス化ルール変更などの複合要因の可能性
- 対処: 重要な質問セットは定期的にリグレッションテスト。ファイル名グロッサリで検索インデックスへの依存度を下げる。可能なら重要ファイルは Upload 型にも冗長化
クセ 3: Code Interpreter 実行後にセッションが不安定化する
-
症状: 会話 1 で CI + SharePoint コネクタが正しく動いて回答が返った直後、会話 2 の質問で
エラー コード: SystemErrorを返して応答不能になる - 再現性: 検証中、頻繁に発生
- 原因推測: Code Interpreter が現時点でプレビュー機能 であることに起因する可能性が高いと推測されます。CI 実行後のコンテキストサイズが大きくなっている、セッションステートのクリーンアップが未実装など、GA 化に伴って改善される可能性がある 領域と見られます
-
対処 (現状):
- 単発 Q&A 前提の設計 (「1 質問 = 1 会話」ルール) にする
- プロンプトで CI 実行後の応答末尾に「続けてのご質問は新しい会話でお願いします」の案内を添える
- Copilot Studio のトピック機能で End Conversation を組み込む余地はあるが、次項の課題あり
クセ 4: Code Interpreter がプレビュー扱い
- リスク: 課金体系の変更、仕様変更、不具合の発生の可能性
-
対処:
- 本番導入前に 最新の公式ドキュメント / ライセンス条項 を確認
- CI に強く依存する構成 (Part 3 案 C はまさにこの構成) を選ぶ場合、プレビューから GA への移行時にプロンプトや設定の再検証 を計画に含める
- CI 課金が有償化される可能性を予算計画に織り込む
9. どのユースケースで Standard Harness を選ぶか
Part 2 と Part 3 の対比を踏まえて、実務での選択基準を整理します。中立に、それぞれ得意分野があります。
Standard Harness (Classic UI) が適するケース
| ケース | 理由 |
|---|---|
| 単発 Q&A ボット (FAQ 型・社内問い合わせ) | 多ターン会話が要件でない。CI セッション汚染の影響を受けにくい |
| コスト優先 (従量課金を避けたい) | 定額の M365 Copilot ライセンス範囲内で運用できる (※ Code Interpreter は GA 時に課金体系を要確認) |
| 既存 SPO 資産の活用が主目的 | SPO 参照モードでも十分な精度が出る (案 C ならば) |
| ファイル一覧が把握できる規模 (数十〜数百ファイル) | ファイル名グロッサリの保守が現実的 |
| プロンプトの設計・チューニングに時間をかけられる | 案 C のような明示的な設計で強みを発揮 |
GitHub Copilot Harness (New UI) が適するケース
| ケース | 理由 |
|---|---|
| 多ターン会話が本質的に必要 | エージェンティックループがセッション状態を管理 |
| 設計・運用工数を最小化したい | プロンプト 2 行足すだけで 7/7 |
| ファイル数・種別が多く、ファイル名グロッサリの保守が非現実的 | エージェント側でうまく補正してくれる |
| 画像・図面が頻繁に更新される | マルチモーダル読取のデフォルト強度が高い |
| 想定使用量が少ない・従量課金を許容できる | 従量課金モデルがフィットする |
どちらも向かない → Part 4 以降を検討
- A0/A1 級の大型 CAD 図面 や 数千ファイル規模の SPO → Copilot Studio の枠を越え、Azure AI Search + カスタム RAG (Part 4) で検索側を制御
- 複雑な構造の Excel (複数シート・ピボット・数式チェーン) → Fabric データエージェント (Part 5) で構造化データとして扱う
10. まとめ
Part 3 の結論
- Standard Harness (Classic UI) は、GitHub Copilot Harness の従量課金化後もなお有力な選択肢 です
- Part 1 R5 の 5-6/7 天井は "定石" プロンプト設計での結論であって、Standard Harness アーキテクチャの絶対的な限界ではありませんでした
- SharePoint コネクタのツール登録 + プロンプト刷新 (案 C) + Opus 4.8 の組み合わせで、評価ツール・Chat の両方で 3 セット全て 7/7 に到達
- 一方で、CI 発火後のセッション不安定性、SPO 検索の非決定性、リセット機構の不動作、CI プレビューの課金/不具合リスクなど、設計時に想定すべきクセ も明確化されました
実務判断のフレーム
"Standard Harness か GitHub Copilot Harness か" の二者択一ではなく、"どのユースケースに、どの構成を、どんな注意点とともに割り当てるか" が実務の判断ポイント です。単発 Q&A / コスト優先 / 既存 SPO 資産活用が主なら Standard Harness、多ターン会話 / 設計コスト最小化 / 動的なファイル群が主なら GitHub Copilot Harness、というのが Part 3 時点での目安です。
次回 (Part 4): Azure AI Search + カスタム RAG
Part 3 で Standard Harness を極めても届かない領域があります:
- A0/A1 サイズ・数十 MB・部品数百規模の実務 CAD 図面 ではファイルサイズ/処理時間の壁に当たる可能性
- 数千ファイル規模の SPO では検索の粒度・関連性判定の細かな制御が欲しくなる
- チャンク戦略・埋込モデル・前処理を細かく制御したい ケース
これらは Copilot Studio の枠を越え、Azure AI Search + カスタム RAG で自作する領域です。Part 4 では以下 3 構成を比較する予定:
| 構成 | 差分 |
|---|---|
| AS-1: ベースライン | 標準テキスト抽出 + 固定長チャンク + ベクトル検索 |
| AS-2: 構造化 + ハイブリッド | Document Intelligence + ベクトル+キーワード検索 + セマンティックランカー |
| AS-3: マルチモーダル | AS-2 + 画像分割 + マルチモーダル埋め込み (Azure Vision) |
さらに Part 5 では、ファイル種別を変えて 複雑な構造の Excel に対して Fabric データエージェント を使うアプローチを検証予定です。
(Part 4 に続く)
付録: Part 1・Part 2・Part 3 の到達点比較
| 検証項目 | Part 1 (Classic / Standard Harness) | Part 2 (New / GitHub Copilot Harness) | Part 3 (Standard Harness 案 C) |
|---|---|---|---|
| Round 数 | 5 (R1〜R5) | 3 (N1〜N3) | 1 (案 C) |
| モデル | Sonnet 4.6 → Opus 4.7 | Opus 4.7 | Opus 4.8 |
| SharePoint コネクタツール登録 | ❌ | (自動的に相当機能あり) | ✅ 必須 |
| プロンプト | 案 B (± 追加 2 行) | 案 B + 追加 2 行 | 案 C (刷新版) |
| ナレッジソース | R4・R5 で Upload 型 | N3 で Upload 型 | SPO 参照のまま |
| 最高スコア | 5-6/7 | 7/7 | 7/7 (3 セット完全正解) |
| 課金モデル | 定額 | 従量課金 | 定額 |
| 適するユースケース | (Part 1 の R3 の目安) | 多ターン / 高精度・低運用 | 単発 Q&A / コスト優先 |
付録: 案 C プロンプト全文 (再掲)
節 4 に記載済み。実装時のコピー元としてご利用ください。