本記事について
本記事の検証・サンプルデータ生成・執筆は 2026 年 7 月時点で生成 AI を駆使して実施 したものです。合成データの生成コード、Copilot Studio への質問投げ、結果の分析、記事化までのほぼすべての工程で AI アシスタントと対話しながら進めています。
Copilot Studio の挙動・利用モデル・UI 仕様は日々更新されるため、本記事の結果は 執筆時点のスナップショット である点にご留意ください。
なお本検証で使用した Copilot Studio エージェントは、Classic experience で作成しています。オーケストレーターが異なるため、New experience 側では本記事と結果が変わる可能性があります（→ Part 2 で検証予定）。
また本検証は各 Round につき Evaluation ツールで 1-3 回実行 した結果に基づいています。LLM の非決定性により、試行を重ねると個別の Pass/Fail 判定はぶれ得ます。実際、執筆中に同じ Round を再実行したところ Q3・Q5 で回答内容が変化したケースもありました。本記事の数値は「参考値」としてのご理解をお願いします。
TL;DR
- 「既存の SharePoint (SPO) にある資料を Copilot Studio で検索させたい」 という実務ニーズを起点に、5 段階の改善策 を順に試して精度がどこまで伸びるかを検証
- Round 1: SPO 参照 + デフォルト設定 → テキスト系は OK、図面 PDF はほぼ全滅（4/7 Pass）
- Round 2: モデルを Opus に + 「根拠のない回答」を禁止 + Code Interpreter を ON + Web 検索を OFF → 改善はゼロ（正答率も 4/7 のまま。）
- Round 3: 指示文に「Excel は CI で解析」「画像 PDF は画像として確認」を追加 → 数値上は R2 から変わらず（4/7 Pass）だが、R2 の Q3 で見られた "偶然の正答" が honest な失敗に変わるなど 回答の信頼性 が向上
- Round 4: どうしても取れない画像 PDF のために ナレッジソースを Upload 型に切り替え → 図面 PDF の OCR と OCR 誤認識の自己検出まで届く（5-6/7 Pass、Q6 画像 PDF が取れる）
- Round 5: R3 のプロンプト改良 × R4 の Upload を合わせた Classic の天井 → R4 の強み (Q6/Q7) を維持しつつ Q3 が部分回答まで到達（5-6/7 Pass）
- どの Round でも「厨房の隣は？」のような空間関係や「○○の部下は？」のような図の階層関係は完全には解けず、部分的な示唆にとどまる。これは Classic experience の絶対的な限界 → Part 2 で New experience にて検証。
- 【追記 (Part 3)】 ただし Part 1 執筆後の追加検証で、SharePoint コネクタをツール登録し、プロンプトでコネクタ/CI/ファイル名グロッサリを強制発火 させる手法により、Classic Chat でも単発クエリで 7/7 まで到達可能 と判明。定額の Classic を極めたい場合は Part 3 を参照。
1. なぜ検証したのか
Copilot Studio で設計図、平面図、組織図等のデータをどの程度扱えるかという議論がよく出るため、それらの "非構造化データ" がどこまで実用に耐えるかを検証したかった。特に多くの現場では、既に SharePoint (SPO) 上に大量の資料が蓄積されている。「既存の SPO のドキュメントを Copilot Studio のナレッジソースとして指定するだけで、社員の質問に答えてくれるアシスタントになるか？」というのが実務での最大の関心事だ。
ネットの記事は「PDF アップロードするだけ！」で終わっているものが多いが、実務では：
- 表の複雑さ（結合セル、複数ヘッダ）
- 図面（CAD 出力の PDF、スキャン PDF）
- 図の意味理解（フローチャート、組織図、平面図）
- 同じ情報が複数フォーマットにまたがるケース
こういうリアルなケースでの精度差が知りたい。
主な精度の向上方法としては以下が思い当たる。
- 指示文を強化する
- ナレッジの説明文を強化する
- ナレッジの持ち方を変更する (SPO/Dataverse/AI Search)
- データを整理、クレンジングする
- LLM のモデルを変える
- Copilot Studio の設定を変える
- 新しい機能を試す (New experience)
そこで本記事では 「SPO 参照のデフォルト設定」を出発点 として、以下 5 段階の改善策を順番に試し、精度がどこまで伸びていくかを検証する。
| Round | 改善策 | 主な変更点 |
|---|---|---|
| Round 1 | 出発点 | Classic experience + SPO 参照 + デフォルト設定（Sonnet 4.6 / 「根拠のない回答」許可 / Code Interpreter OFF） |
| Round 2 | エージェント設定のチューニング | モデルを Opus 4.7 に + 「根拠のない回答」を禁止 + Code Interpreter を ON + Web 検索を OFF |
| Round 3 | プロンプト改良 | 指示文に「Excel は CI で解析」「画像 PDF は画像として確認」を追加（SPO 参照のまま） |
| Round 4 | ナレッジソース接続方法の変更 | SPO 参照 → ファイル Upload 型 (Dataverse) に変更 |
| Round 5 | Round 3 + Round 4 の組み合わせ | Upload 型 + プロンプト改良 2 行両方。Classic experience で打てる手の天井 |
Dateverse へのファイルアップロードは非構造化データにも対応しているため Round 4 あたりで精度が大幅に改善すると期待。
なお本記事では Copilot Studio の Classic experience (Standard Harness) で検証している。新しい New experience (GitHub Copilot Harness、エージェンティックループ・コーディングハーネスを備える) を使うとまた別の景色が見えるので、Part 2 で扱う。
2. 検証データ: Cafe Latte
📖 用語メモ: ベクター PDF と ラスター PDF
- ベクター PDF: 中身が「文字コード＋図形の数式」で構成された PDF。Word や CAD ソフトから直接出力したものが該当。テキストはコピペ・検索可能。
- ラスター PDF: 中身が「画像（ピクセル）」で構成された PDF。スキャナで取り込んだ紙、ベクター PDF を画像化したものが該当。読むには OCR が必要。テキストのコピペはできない。
今回の検証では、同じ内容のペア（T3/T4、C1/C2）を用意して、この違いが Copilot Studio の検索精度にどう効くかを見る。
権利面をクリアするため、架空のカフェ「Cafe Latte」の運営データを Python で自動生成した。ポイントは 「同じ情報を複数フォーマットで用意する」 こと。これで「表 vs PDF vs 図面」の精度比較が同じ土俵でできる。
| ID | ファイル | 内容 |
|---|---|---|
| T1 | T1_menu.xlsx |
メニュー価格表（15 品目、Excel シンプル表） |
| T2 | T2_shift.xlsx |
スタッフシフト表（結合セル・複数ヘッダ） |
| T3 | T3_manual.pdf |
店舗運営マニュアル（メニュー表を PDF 内に埋込） |
| T4 | T4_manual_raster.pdf |
T3 をラスター化した画像 PDF（OCR 依存） |
| C1-syn | C1-syn_bracket_vector.pdf |
部品図（ベクター PDF、寸法・注記・表題欄あり） |
| C2-syn | C2-syn_bracket_raster.pdf |
C1 をラスター化した画像 PDF |
| C4-syn | C4-syn_floorplan.pdf |
店内平面図（10 室、諸元表付き） |
| M2 | M2_meeting_minutes.pdf |
週次会議議事録（自由記述テキスト） |
| M4 | M4_org_chart.pdf |
組織図（8 名の階層構造） |
生成は Python + matplotlib + reportlab + openpyxl。すべての内容は 1 つの cafe_data.py に集約してあり、正解が既知なので評価が楽。
各ファイルの見た目
以下は各ファイルの実物イメージ。ブログ後半では「これらを Copilot Studio がどう検索するか」を追いかける。
T1 — メニュー価格表 (Excel) 6 列 × 15 行の素直な表。ID・カテゴリ・品名・価格・提供時間・主原材料。
T2 — スタッフシフト表 (Excel) 部門ごとにグループ化、結合セル・複数ヘッダあり。「休」は赤色ハイライト。
T3 — 店舗運営マニュアル (PDF) 2 ページ構成。1 ページ目に店舗基本情報とメニュー表を PDF 内に埋め込み。2 ページ目は業務手順。
T4 — 店舗運営マニュアル (ラスター PDF) T3 と全く同じ内容だが 画像化してある（グレースケール、スキャン風）。テキスト抽出は 0 バイト、OCR 依存。
C1-syn — 部品図 (ベクター PDF) 三面図・寸法・注記・表題欄を持つ機械部品図（L 型ブラケット）。すべてテキストとして抽出可能。
C2-syn — 部品図 (ラスター PDF) C1-syn と同じ図面を画像化したもの。OCR 経由でしか読めない。
C4-syn — 店内平面図 (PDF) 厨房・レジ・トイレ・客席など 10 エリアの配置図、諸元表・凡例付き。
M2 — 週次会議議事録 (PDF) 自由記述形式の議事録。6 月度売上、新メニュー、8 月シフト、トイレ改修工事の 4 議題。
M4 — 組織図 (PDF) 8 名の階層構造。店長 → 副店長 → 3 名 → 3 名の 4 段ツリー、色分け付き。
検証観点
- 抽出精度: ファイルから内容を拾えるか
- 構造保持: 表の階層や図の関係が回答に反映されるか
- 検索精度: 曖昧な質問でも該当箇所を引けるか
- 回答生成: 引いた情報を正しく要約・推論できるか
- 引用の妥当性: 根拠が正しく示されるか
3. 指示文（システムプロンプト）の設計
同じデータでも指示文の書き方で結果が大きく変わるため、以下の指示文で統一した（ブログ内では「案 B」と呼称）:
# 役割
あなたは Cafe Latte 運営情報の Q&A アシスタントです。ユーザーからの質問に、
提供された検索結果 (Excel / PDF / Word 等) の内容のみに基づいて日本語で回答してください。
# 回答ルール
1. 必ず出典を示すこと
2. 検索結果に書かれていないことは推測しない (見つからなければ「記載なし」と正直に)
3. 計算・集計が必要な場合は計算過程を示す
4. 表形式の情報は列名と値を対応させる
5. 複数ファイルにまたがる情報はファイル名を併記
6. 曖昧な質問は想定した解釈を先に述べる
# 出力形式
- 結論を最初に述べる
- 出典を「出典: 〜」の形式で列挙
指示文にケチると LLM は自由に喋りすぎる（ハルシネーションの温床）。この指示文はハルシネーションを抑え、出典明示を強制することで、後の精度評価をしやすくする狙い。
4. Round 1: SPO 参照 + デフォルト設定
出発点は「Copilot Studio でエージェントを作って、SharePoint 上の資料をナレッジに指定するだけ」。設定は何もいじらずに 7 問投げてみた。
検証環境:
| 項目 | 値 |
|---|---|
| エクスペリエンス | Classic |
| ナレッジソース | SharePoint 参照 (Cafe Latte 資料 9 ファイル) |
| モデル | Sonnet 4.6 (デフォルト) |
| 「根拠のない回答」 | 許可 — デフォルト（LLM が知識ソースにない情報でも答えてよい） |
| Code Interpreter | OFF — デフォルト |
| 指示文 | 案 B (前節参照) |
結果: 4/7 Pass (D06 価格 / 山田水曜シフト / トイレ何箇所 / ブラケット材質)
検証に使った 7 問と Round 1 の結果
以降の Round でも同じ 7 問を投げて比較する。この 7 問はいずれも 意図的に少し難しく設計 している (単一値照会・表参照・空間関係・階層構造・画像 PDF などバリエーションを網羅)。
| # | 質問 | 想定される主な参照ファイル | R1 結果 |
|---|---|---|---|
| 1 | D06 の価格は？ | T1_menu.xlsx (単一値) | ✅ |
| 2 | 山田店長の水曜日のシフトは？ | T2_shift.xlsx (表参照) | ✅ |
| 3 | 厨房の隣の部屋は？ | C4-syn_floorplan.pdf (空間関係) | ❌ |
| 4 | トイレは何箇所ある？ | C4-syn_floorplan.pdf (諸元表) | ✅ |
| 5 | 鈴木一郎の直属の部下は？ | M4_org_chart.pdf (図の階層) | ❌ |
| 6 | ブラケットの図番は？ (C2-syn について) | C2-syn_bracket_raster.pdf (ラスター画像 PDF) | ❌ |
| 7 | ブラケットの材質は？ | C1-syn_bracket_vector.pdf (ベクター PDF 注記) | ✅ |
表・議事録・PDF テキスト系は問題なく引ける
- 「D06 の価格は？」 → T1_menu.xlsx と T3_manual.pdf から「620 円（税込）」と正答。Excel と PDF の両方から取得。
- 「山田店長の水曜日のシフトは？」 → T2_shift.xlsx から週間表を作って「休」と正答。scope も明示。
- 「トイレは何箇所ある？」 → C4-syn_floorplan.pdf の諸元欄から「3 箇所（男・女・多目的）」と正答。
- 「ブラケットの材質は？」 → C1-syn_bracket_vector.pdf の注記から「SS400 (JIS G 3101)」と正答。
いずれも テキストとして書かれている情報 なので、SPO 参照経由の検索でも問題なく引ける。
図面 PDF・画像・階層構造はほぼ全滅
一方で、以下 3 パターンは軒並みダメだった。
「ブラケットの図番は？(C2-syn)」 ← ラスター画像 PDF
C2-syn_bracket_raster.pdf はラスター形式（画像ベース）の PDF であるため、テキスト情報を自動抽出することができませんでした。
正直に「読めません」と回答。参考として C1 の図番を提示するが、C2 自体は諦める。
「厨房の隣の部屋は？」 ← 空間関係
テキスト情報からは「厨房の隣の部屋」を明確に特定できませんでした。
平面図の面積や部屋名一覧は引けるが、「隣接関係」という視覚情報からしか読み取れない情報には答えられない。
「鈴木一郎の直属の部下は？」 ← 図の階層構造
組織図はPDF形式のグラフィックであるため、テキスト情報からは階層の線を正確に読み取ることができません。
シフト表の部門情報を組み合わせて「同じドリンク部門に渡辺 大輔がいる」までは示すが、直属関係は明示できないと honest な回答。
この時点の結論: 「Sharepoint に PDF アップロードするだけ」の限界
つまり SPO 参照 + デフォルト設定 では、テキストとして書かれている情報しか活用できない。図として、画像として、レイアウトとして表現されている情報は完全に落ちる。Copilot Studio に "貼っただけ" では、非構造化データの半分も見えていない ということ。
これでは実務にはならない。次の Round では設定をチューニングして改善を狙う。
5. Round 2: エージェント設定を推奨値に
「デフォルトのままでダメなら、まずは設定を推奨値にしよう」というのが最初の一手。以下 4 つを変えた。
| 設定 | Round 1 (デフォルト) | Round 2 |
|---|---|---|
| モデル | Sonnet 4.6 | Opus 4.7 |
| 「根拠のない回答」 | 許可 | 禁止 |
| Code Interpreter | OFF | ON |
| Web 検索 | ON | OFF |
Round 2 の狙い:
- モデル最新化: より高性能なモデルで抽出・推論力を上げる
- 「根拠のない回答」を禁止: LLM が「ナレッジソースにない情報で回答」できなくなる。「わからない」を正直に返すよう強制。ハルシネーション抑制。
- Code Interpreter を ON: エージェントが Python コードを実行して PDF や Excel を後付けで解析可能に
- Web 検索を OFF: ナレッジソース (SPO/Upload) 以外の外部 Web 情報が回答に混入しないように封じる。回答の根拠を提供資料に限定して、上の「根拠のない回答禁止」とあわせハルシネーション経路をさらに絞る (Web 検索は「根拠のない回答」を許可した場合の抜け道になり得る。禁止設定と一貫させるために OFF)
これで一気に精度が上がる…はずだった。
結果: 4/7 のまま (!)
同じ 7 問を投げた結果、正答率は 4/7 で Round 1 と大して変わらなかった。
| # | 質問 | R1 | R2 |
|---|---|---|---|
| 1 | D06 価格 | ✅ | ✅ |
| 2 | 山田水曜シフト | ✅ | ✅ |
| 3 | 厨房の隣 | ❌ | ⚠️ (おそらくテキスト順から推測した偶然) |
| 4 | トイレ何箇所 | ✅ | ✅ |
| 5 | 鈴木の部下 | ❌ | ❌ |
| 6 | 図番 (C2-syn) | ❌ | ⚠️ (正しい回答はないが参考情報を提示) |
| 7 | ブラケット材質 | ✅ | ✅ |
Q3 の "偶然の正答" — 面白い副次発見
Round 2 で Q3 (厨房の隣) が正答したのは、実は 偶然 だった。
Copilot Studio が C4-syn の PDF テキストを抽出すると、部屋名が 描画順 で「厨房 → レジ・カウンター → ストックルーム → スタッフルーム」と並ぶ。Opus はこの テキストの並び順 から空間隣接を推論して「レジ・カウンター」と答えたようだ。
つまり 平面図を "見て" 判断したのではなく、テキストの並びをたまたま空間関係の代替として使えた だけ。データの並びが違えば外していた可能性が高い。信頼できる正答ではないと思われる。
まとめ: 設定チューニング単独では効果薄
Round 2 単独ではほぼ効果なし。データソースを変える前に、まずはプロンプトでどこまで底上げできるかを Round 3 で見てみる。
6. Round 3: プロンプト改良で SPO 参照を底上げ
Round 2 で「設定は変えても効かない」と分かった。ではナレッジソースは SPO 参照のまま、指示文 (システムプロンプト) を強化 するとどうか。実務では SPO の自動反映を保ちたい ので、接続方法を変える前にここで一手間掛ける価値は大きい。
追加した指示 2 行
案 B のプロンプトに以下を追加:
7. Excel ファイルについてもコードインタープリターで解析して中身を確認して回答すること
8. ラスター画像 PDF もマルチモーダル読取または画像として確認して中身を判断すること
これらは 「検索でヒットしなくても、CI やマルチモーダル機能を能動的に呼び出せ」 という誘導。エージェントが自身の使えるツールを積極活用するようナッジしている。
エージェント設定と接続方法は Round 2 と同じ (Opus / 「根拠のない回答」禁止 / CI ON / Web 検索 OFF / SPO 参照)。
結果: 4/7 Pass のまま — ただし "回答の質" が変わる
| # | 質問 | R1 | R2 | R3 |
|---|---|---|---|---|
| 1 | D06 価格 | ✅ | ✅ | ✅ |
| 2 | 山田水曜シフト | ✅ | ✅ | ✅ |
| 3 | 厨房の隣 | ❌ | ⚠️ (偶然) | ❌ (正直な失敗) |
| 4 | トイレ何箇所 | ✅ | ✅ | ✅ |
| 5 | 鈴木の部下 | ❌ | ❌ | ⚠️ (断言せず参考提示) |
| 6 | 図番 (C2-syn) | ❌ | ⚠️ (参考提示) | ⚠️ (参考提示) |
| 7 | ブラケット材質 | ✅ | ✅ | ✅ |
数値上は R2 と同じ 4/7 Pass。しかし個別回答の中身を見ると変化が見える。
改善点 (回答の質):
- Q3 (厨房の隣) が "偶然" から "honest な失敗" に — R2 では偶然「レジ・カウンター」と答えて Pass だったが、R3 では「隣接関係は文字情報からは判別できない」と honest に不明を宣言 (詳細は後述の副次発見)
- Q7 (材質) が引用リッチに — C1 の注記を能動的に引き、図番・表面処理などまで併せて回答
- Q5 (鈴木の部下) は "断言はしないが参考として渡辺大輔を提示" するようになる — R2 の完全 ❌ から、シフト表を横串で見て「業務上のペア」を示すレベルに
残る弱点 (数値が伸びない理由):
- Q5 は依然として ⚠️ — 直属関係を明示的に断言せず「直属の部下は明示的に記載されていません」と留保。プロンプトの「見つからなければ記載なしと正直に」が強く効いている
- Q6 (C2 図番) は ⚠️ (参考提示) 止まり — SPO 参照型では画像 PDF に手が届かない。プロンプトで「画像として確認せよ」と指示しても、Classic experience の SPO 参照経由では画像認識ツールが発火せず、C1 の図番を参考として提示するに留まる
- Q3 (厨房の隣) は完全な ❌ — Classic experience の絶対的な限界
副次発見: プロンプト改良は "偶然の正答" を "正直な失敗" に変える
面白い現象があった。プロンプトを改良した結果、Q3 で「偶然の正答」が消えた。
Round 2 (プロンプト強化前) では、Q3 に対して「厨房の隣にレジ・カウンター」と (偶然) 正答していた。しかし Round 3 では:
テキスト情報からは各部屋の正確な位置関係(隣接関係)を判別することはできません。図面は画像として確認する必要があります。
と honest に「わからない」 と答える。
これは プロンプトが「画像として確認せよ」と明示した結果、Classic には画像確認ツールがないと正直に告白した ということ。精度指標だけで見れば悪化に見えるが、信頼性は逆に向上している。ユーザーが誤答を信じてしまうリスクが減った。
「良いプロンプトは、モデルを正直にする」— この観点は、精度スコアだけでは見えないが実務では極めて重要。
Round 3 の限界: 画像 PDF に届かない・組織図で断言しきれない
Round 3 で信頼性は上がったが、画像 PDF (Q6) はどうしても取れず、組織図 (Q5) も断言に至らない。SPO 参照型では、CI もマルチモーダル読取も画像 PDF の中身にアクセスできないため、C2 図番は「参考として C1 を示す」止まり。組織図についてもプロンプトの誠実性強制が「明示記載なし」の告白を強めてしまう。
もし画像 PDF (スキャン図面など) が業務で必須なら、SPO 参照のままでは限界。次の Round 4 では、ナレッジソースを Upload 型に切り替える最終手段 を試す。
【後日追記 (Part 3 での検証で判明)】
上記の「SPO 参照経由では画像認識ツールが発火せず空振り」という R3 の結論は、実は R3 のプロンプト設計の限界 であって、SPO 参照モード自体の絶対的な限界ではなかった。SharePoint コネクタを "ツール" としてエージェントに登録し、プロンプトで「対象ファイルを必ずコネクタで取得 → Code Interpreter で直接解析」と明示的に誘導 すれば、SPO 参照モードのままでも SPO 上のファイル本体を取得して CI で解析でき、画像 PDF (Q6) や複雑 Excel (T2) も含めて突破可能。つまり R3 の CI 関連指示 (「Excel は CI で解析」等) は、この時点ではコネクタが未登録のため CI がファイルに到達する経路がなく、実質的に指示が空振り していた可能性あり。詳しくは Part 3 で扱う。
7. Round 4: ナレッジソースを Upload 型に切り替える
Round 3 でプロンプト改良まで手を尽くしても、SPO 参照型では 画像 PDF (Q6) が取れない。この根本制約を回避するには、ナレッジソースの接続方法を変える しかない。
- Round 1〜3: SharePoint 参照型 (SPO ライブラリを指定)
- Round 4: ファイル Upload 型 (Copilot Studio にファイルを直接アップロード → 裏では Dataverse に格納)
エージェント設定 (Opus / 「根拠のない回答」禁止 / CI ON / Web 検索 OFF) は Round 2 のまま (プロンプトは改良前に戻し、接続方法単体の効果を見る)。ナレッジソースだけ差し替えて 7 問投げ直す。
結果: 5-6/7 Pass (Q6 に色がつく)
| # | 質問 | R1 | R2 | R3 (SPO+改) | R4 (Upload) |
|---|---|---|---|---|---|
| 1 | D06 価格 | ✅ | ✅ | ✅ | ✅ |
| 2 | 山田水曜シフト | ✅ | ✅ | ✅ | ✅ |
| 3 | 厨房の隣 | ❌ | ⚠️ (偶然) | ❌ (正直な失敗) | ❌ |
| 4 | トイレ何箇所 | ✅ | ✅ | ✅ | ✅ |
| 5 | 鈴木の部下 | ❌ | ❌ | ⚠️ (断言避け) | ⚠️ (不安定) |
| 6 | 図番 (C2-syn) | ❌ | ⚠️ (参考提示) | ⚠️ (参考提示) | ✅ (OCR) |
| 7 | ブラケット材質 | ✅ | ✅ | ✅ | ✅ (OCR 誤認識の自己検出) |
特筆すべき改善は Q6、つまり画像 PDF の読み取り。CI が Upload 型のファイルにアクセスできるようになったので、OCR や画像解析が回り始めた。
ハイライト: OCR 誤認識の自己検出
Q7 (「ブラケットの材質は？」) に対する回答:
取付ブラケット(L型)の材質は SS400 (JIS G 3101) です。
補足 (表記の差異について)
- C1-syn_bracket_vector.pdf (ベクター図面): 材質「SS400 (JIS G 3101)」
- C2-syn_bracket_raster.pdf (ラスター図面): 材質「S5400 (JIS G 3101)」
C2 では OCR 等の影響と思われる「S5400」表記が見られますが、
JIS G 3101 に定められている一般構造用圧延鋼材の規格上、正しくは SS400 です
(C1 のベクター図面と一致)。
これは驚き。以下 3 つを エージェントが自律的にやっている:
- C1（ベクター）と C2（ラスター）で 同じ図番なのに値が違うことに気づく
- 「JIS G 3101 に SS400 という規格がある」という一般知識で妥当性を検証
- C2 の "S5400" は OCR 起因の誤認識と結論
「案 B」指示文の「矛盾があれば明示する」を、期待以上に賢く解釈している。
さらに実用面で嬉しいのは、引用が SharePoint 上の PDF のページ直リンク (#page=1) 付きで返ってくる こと（Upload 型でもファイル本体は SPO 内部に保存されているため）。回答の中の引用マークをクリックすると原本の該当ページへ飛べる。実務では「回答だけ信じず、ソースを必ず見に行く」ワークフローに直結する実装で、地味にありがたい。
Round 4 の残された限界
Round 4 で図面 PDF (Q6) は解決した。しかし依然として:
- Q3 (厨房の隣): 「隣接関係の記載なし」と honest な失敗のまま。CI で PDF を解析しても座標情報から空間関係は推論できない。
- Q5 (鈴木の部下): 不安定。試行によって「渡辺 大輔」と正答したり「部下はいません」と誤答したり。プロンプト誘導がないとキーワードマッチ寄りの判断になる印象。
- Upload 型の運用コスト: 元ファイルが SPO で更新されても、Copilot Studio 側に自動反映されない。再アップロードが手動作業になる。
Round 3 vs Round 4: トレードオフの存在
面白いのは、Round 3 (SPO+prompt) と Round 4 (Upload) で 得意領域が違う こと:
- Round 3: プロンプトの誠実性強制で 回答の信頼性 が高い (偶然の正答が消える、C2 を C1 で代替提示するなど誠実な回答)。一方で Pass 数は伸びない
- Round 4: Q6 (画像 PDF) を突破し、Pass 数が増える。一方で Q5 は不安定な推測回答に戻る
つまり Classic experience では "回答の誠実さ" と "画像 PDF 対応" の両方を同時に取りにくい。では両方を合わせたらどうなるか？—— それが Round 5。
8. Round 5: Upload + プロンプト改良 (Classic の真の天井)
Round 3 (SPO+プロンプト改良) では 信頼性 が上がり、Round 4 (Upload) では Q6 画像 PDF が取れるというトレードオフが見えた。両方を組み合わせたらどこまで行けるか？ これを Round 5 として試した。Classic experience でユーザーが打てる手は、ここでほぼ打ち尽くしになる。
設定
- 接続方法: Upload 型 (Round 4 と同じ)
- プロンプト: 案 B + Round 3 の追加 2 行 (「Excel は CI で解析」「画像 PDF は画像として確認」)
- エージェント設定: Opus 4.7 / 「根拠のない回答」禁止 / CI ON / Web 検索 OFF (Round 2 と同じ)
結果: 5-7/7 Pass (Classic の天井)
Copilot Studio 内蔵の Evaluation ツール (次節で詳述) で独立実行した結果:
| # | 質問 | R1 | R2 | R3 | R4 | R5 |
|---|---|---|---|---|---|---|
| 1 | D06 価格 | ✅ | ✅ | ✅ | ✅ | ✅ |
| 2 | 山田水曜シフト | ✅ | ✅ | ✅ | ✅ | ✅ |
| 3 | 厨房の隣 | ❌ | ⚠️ (偶然) | ❌ (正直な失敗) | ❌ | ⚠️ (バックヤード側は隣接と部分回答) |
| 4 | トイレ何箇所 | ✅ | ✅ | ✅ | ✅ | ✅ |
| 5 | 鈴木の部下 | ❌ | ❌ | ⚠️ (断言避け) | ⚠️ (不安定) | ⚠️ (断言せず参考提示) |
| 6 | 図番 (C2-syn) | ❌ | ⚠️ (参考提示) | ⚠️ (参考提示) | ✅ (OCR) | ✅ (OCR) |
| 7 | ブラケット材質 | ✅ | ✅ | ✅ | ✅ (OCR 誤認識を自己検出) | ✅ (OCR 誤認識を自己検出) |
Evaluation ツール判定は 6 Pass / 1 Fail (Q5)。R4 の 5 Pass / 2 Fail から Q3 が Pass に浮上 した (Evaluation ツールの緩めの判定基準では、後述の「バックヤード側は厨房と隣接」という部分回答も Pass 扱いになる)。
厨房の隣には、平面図上で ストックルーム(4.0 m²) および スタッフルーム(5.0 m²) が配置されているバックヤードエリアがあります。
⚠️ 補足: 平面図には... 厨房・ストックルーム・スタッフルームがまとめて配置されていることは読み取れますが、「厨房のちょうど隣がどの部屋か」という正確な隣接関係(東西南北どちら側か等)まで文字情報から一意に断定はできません。
プロンプトの「画像として確認せよ」誘導が Upload 型のファイル本体アクセスと組み合わさって、諸元表以外の凡例テキストからバックヤードエリアの構成を引くようになった。ただし正解の「レジ・カウンター」には触れておらず、「一意に断定はできない」と honest に補足しているため、実質的には ⚠️ (部分的正答 + 誠実な限界告白)。
Q6/Q7 (画像 PDF・OCR 誤認識の自己検出) は R4 レベルを維持している。
副次発見: プロンプトの "honest モード" は Q5 では底上げにつながらない
面白いのは、R3 (SPO+プロンプト改良) も R5 (Upload+プロンプト改良) も、Q5 (鈴木の部下) では "断言避け" となること。
- R3: 「直属の部下は明示的に記載されていません」 + 「シフト表からは渡辺大輔が鈴木氏の指導下にあると解釈できる」
- R5: 「直属の部下は明示的に記載されていません」 + 「業務上のペアとしては渡辺大輔が最も近い立場」
いずれも "直属の部下" を断言せず参考情報として提示するパターン。これは プロンプトの「見つからなければ記載なしと正直に」が強く効いているため と推測される。Q5 は「視覚的には線で接続されているが、テキストとして『鈴木 → 渡辺』の直属関係は明記されていない」データなので、誠実なプロンプトに従うと断言を避けるのが自然ということ。
一方で Q3 では R5 の Upload+プロンプトの組み合わせが効いている のも面白い。R3 では完全に諦めていたのに、R5 では「バックヤード側は隣接」まで探りに行くようになる。Upload でファイル本体に届くこと + プロンプトの「画像として確認せよ」が合わさると、本文テキスト以外の凡例・追記部なども拾いに行く という仕様の可能性がある。
まとめ: Classic の天井は 5-7/7
Round 5 で Classic experience で打てる手はほぼ打ち尽くした。結果:
- 確実に取れる: Q1/Q2/Q4/Q6/Q7 の 5 問 (テキスト系 + 画像 PDF OCR)
- 微妙 (⚠️): Q3 (部分回答止まり) / Q5 (断言避け)
- 完全な失敗: なし (すべての質問で honest な部分回答は返す)
つまり Classic experience の実質的な天井は 5-7/7 (Evaluation 判定で 6/7)。「空間関係」「図の階層構造」を "断言可能なレベル" で解けないという結論は変わらず、これは次の Part 2 (New experience) で突破できるかを検証する。
9. Classic experience で判明した限界
5 Round を通して見えてきた Classic experience の壁 を整理する。
【後日追記 (Part 3)】
以下 3 つの限界は R1〜R5 の「定石」プロンプト設計 での結論。Part 1 執筆後の追加検証で、SharePoint コネクタをツール登録 + プロンプトでコネクタ/CI/ファイル名グロッサリを強制発火 させる手法により、限界 3 (SPO 参照 + 画像 PDF) や 限界 2 (組織図の階層断言) は Chat 単発クエリで突破可能と判明した。限界 1 (空間関係) についても Chat で "方角付き断言" に近い挙動が観察される場合がある。詳細は Part 3 で。
限界 1: 空間関係の推論 (Q3)
「厨房の隣は？」に対して、C4-syn 平面図を引いても:
各部屋の正確な位置関係 (隣接関係) を判別することはできません。図面は画像として確認する必要があります。
図の座標情報から "隣接" を推論することはできない。人間なら平面図をパッと見て「厨房の右にレジ・カウンター」とわかる情報が、Classic の LLM には届かない。プロンプトで指示してもツールがないため空振り。
限界 2: 図の階層構造の読取 (Q5)
組織図の "ボックスと接続線" から鈴木一郎の直属の部下を判別するには、視覚的な理解が必要。
- Round 3 (SPO+プロンプト改良) では 「直属の記載なし」と honest に留保しつつシフト表から渡辺大輔を参考提示するレベル
- Round 4 (Upload+CI) では 不安定 — 試行ごとに「渡辺 大輔」と正答したり「部下はいません」と誤答したり
- Round 5 (Upload+プロンプト改良) でも R3 と同様に 「直属の記載なし」と留保しつつ参考提示
いずれも 図としての視覚情報を根本的には "理解" していない ことが露呈する。
限界 3: SPO 参照型 + 画像 PDF (Q6)
SPO 参照型では、どんなに設定・プロンプトをチューニングしても ラスター画像 PDF の中身は読めない。エージェントが自ら「OCR を回そう」としても、SPO 参照型はチャンクテキストしか渡されないため手詰まり。
この限界を回避するには ファイルを Upload 型で入れ直す しかない (Round 4 で確認)。
10. 併せて見ておきたい: Copilot Studio 内蔵の Evaluation 機能
今回の検証では、Copilot Studio に内蔵されている 「QA アシスタントを評価する」機能 も使ってみた。質問をリストで登録して一括実行し、各回答に対して 自動で Pass / Fail を判定してくれる。判定基準は「応答の関連性、完全性、ソースの使用・裏付け」など。
本記事で取り上げた 7 問（いずれも意図的に少し難しいもの）を Round 4 (Upload + 推奨設定) の構成 で走らせた結果は以下。
| # | 質問 | 判定 | コメント |
|---|---|---|---|
| 1 | D06 の価格は？ | ✅ Pass | T1_menu.xlsx / T3_manual.pdf を併引 |
| 2 | 山田店長の水曜日のシフトは？ | ✅ Pass | 週間シフト表付き |
| 3 | 厨房の隣の部屋は？ | ❌ Fail | 「隣接関係の記載なし」と正直に回答 |
| 4 | トイレは何箇所ある？ | ✅ Pass | 3 箇所、面積・改修情報付き |
| 5 | 鈴木一郎の直属の部下は？ | ❌ Fail | 「明示的記載なし」と回答（前述の非決定的パターン） |
| 6 | ブラケットの図番は？ (C2-syn) | ✅ Pass | 表題欄全項目抽出、OCR 誤認識も自発検出 |
| 7 | ブラケットの材質は？ | ✅ Pass | SS400 正答、OCR 誤認識の自己検出も |
結果: Pass 5 / Fail 2 (正解率 71%)。Fail の 2 問は 「空間関係」と「階層構造」 という、本記事ですでに限界として指摘した領域と完全に一致した。
なお、同じ Round を何回か実行すると、同一の質問でも回答内容が変化するケースがあった。例えば Round 3 (SPO + プロンプト改良) の Q5「鈴木の部下」では、ある試行では「渡辺大輔さんが直属の部下」と断言する一方、別の試行では「直属の部下は明示的に記載されていない」と留保することもあった。LLM の非決定性により、微妙なデータ (見た目には存在するがテキストとしては明記されていない情報) ではパス/フェイル判定がぶれ得る。本記事の各 Round 列は各問 1 回の実行に基づくスナップショットである点にご留意ください。
この Evaluation 機能の便利なところ:
- 判定理由がテキストで返ってくる: 例えば Q3 は「エージェントが質問に回答しなかったため、応答の関連性・完全性・ソースの使用については評価されませんでした」
- リグレッション検知に使える: プロンプトやナレッジを変更した際に同じセットを走らせれば、改善・悪化の判定が楽
-
想定回答 (
expectedResponse) も持たせられる: 今回は使わなかったが、入れるとより厳しい判定になる
11. 総論: 何が使えて何が使えないか
ここまでの検証結果を 1 枚の早見表 にまとめる。実装前に「自分の使いたいデータで Copilot Studio が使い物になるか」の当たりをつけるのに使える。
質問 × Round 全体マトリクス
まずは 7 質問 × 5 Round の一覧を再掲。
| # | 質問 | R1 SPO デフォルト | R2 SPO 設定チューニング | R3 SPO+プロンプト改良 | R4 Upload | R5 Upload+プロンプト改良 |
|---|---|---|---|---|---|---|
| 1 | D06 価格 | ✅ | ✅ | ✅ | ✅ | ✅ |
| 2 | 山田水曜シフト | ✅ | ✅ | ✅ | ✅ | ✅ |
| 3 | 厨房の隣 | ❌ | ⚠️(偶然) | ❌(正直な失敗) | ❌ | ⚠️(部分回答) |
| 4 | トイレ何箇所 | ✅ | ✅ | ✅ | ✅ | ✅ |
| 5 | 鈴木の部下 | ❌ | ❌ | ⚠️(断言避け) | ⚠️(不安定) | ⚠️(断言避け) |
| 6 | 図番 (C2-syn) | ❌ | ⚠️ (参考提示) | ⚠️(参考提示) | ✅(OCR) | ✅(OCR) |
| 7 | ブラケット材質 | ✅ | ✅ | ✅ | ✅(OCR 誤認識を自己検出) | ✅(OCR 誤認識を自己検出) |
| Pass | 4/7 | 4/7 | 4/7 | 5-6/7 | 5-6/7 |
データ種別 × 期待精度
Round 1 (デフォルト) と、Classic の到達点 (R5 = Upload + プロンプト改良) の比較。
| データ種別 | 本記事のサンプル | R1 デフォルト | R5 チューニング済 |
|---|---|---|---|
| Excel（シンプル表） | メニュー価格表 (T1) | ◎ | ◎ |
| Excel（結合セル・複数ヘッダ） | スタッフシフト表 (T2) | ○ | ◎ |
| PDF（テキスト中心） | 週次会議議事録 (M2) | ◎ | ◎ |
| PDF（埋め込み表） | 店舗運営マニュアル (T3) | ○ | ◎ |
| PDF（ラスター化・スキャン） | マニュアルの画像 PDF 版 (T4) | △ | ○ (Upload 時) |
| CAD 図面 PDF（ベクター） | 機械部品図 (C1-syn) | ○ | ◎ |
| CAD 図面 PDF（ラスター） | 部品図の画像 PDF 版 (C2-syn) | × | △ Upload なら OCR 誤認識あり / SPO 参照だと × |
| 建物平面図 PDF | 店内平面図 (C4-syn) | × | △（テキスト情報・部分回答のみ、正確な空間関係は不可） |
| 組織図 PDF | 組織図 (M4) | × | △（参考情報としての提示に留まり、直属関係の断言は不安定） |
凡例: ◎ 問題なく使える / ○ 概ね使える / △ 部分的 / × ほぼ実用にならない
注: 「×」は「情報が引き出せない」を意味する。誤答を返すのではなく「該当情報が見つからない」と返すため、ハルシネーションのリスクは低い（「根拠のない回答」を許可にして指示文が甘い場合は誤答リスクあり）。
質問タイプ × 期待精度
同じデータでも、質問の書き方で結果は変わる。
| 質問タイプ | 例 | 精度（Round 3～5 チューニング済） |
|---|---|---|
| 単一値照会 | 「D06 の価格は？」 | ◎ |
| 表参照（行 × 列） | 「山田店長の水曜のシフトは？」 | ◎ |
| 複数ファイル横断 | 「営業時間は？（マニュアル + 議事録の変更告知を統合）」 | ○ |
| 数値集計・計算 | 「ドリンクの平均価格は？」 | ○（Code Interpreter が計算） |
| 単純な階層読み | 「副店長は誰？」 | ○（キーワード次第） |
| 矛盾検出・自己検証 | 「C1 と C2 で値が違うがどっちが正？」 | ○（賢いモデルほど強い） |
| 空間関係の推論 | 「厨房の隣は？」「トイレの近くの席は？」 | × |
| 図の階層関係の読取 | 「鈴木の部下は？」「A の親組織は？」 | ×（誤読・非決定的、プロンプトで補える場面はある） |
5 Round から言えること
- 設定チューニング (R2) 単独ではほぼ効果がない。「モデル最新化 + CI ON」を SPO 参照のままやっても正答率は変わらない
- プロンプト改良 (R3) は数値上の Pass は伸ばさないが、回答の信頼性を上げる — 偶然の正答が honest な失敗に変わる、C2 を C1 で代替提示するなどの誠実化が進む
- 接続方法の変更 (R4 Upload) では画像 PDF まで届く。CI が実力発揮するには「手元にファイルがある」ことが必要
- R3 + R4 の組み合わせ (R5) が Classic の天井。R4 の強み (Q6/Q7) を維持しつつ Q3 が部分回答まで到達。ただし Q5 はプロンプトの誠実性強制により断言避けのまま
- どんな手を打っても "空間関係" と "図の階層構造" は Classic experience の "定石" (R1〜R5) では断言可能なレベルまでは届かない。これらは Part 2 (New experience) 以降で挑戦する領域 (Part 3 では Classic をさらに詰めた場合の到達点も検証予定)
- プロンプトは "使えるツールの範囲" でしか効かない。Classic には画像認識ツールがないので、「画像として確認せよ」と指示しても空振り (SPO 参照で C2 が読めないのはこの理由)
- LLM の非決定性により、同じ問でも試行によって回答が変わることがある。実務では複数回実行して安定性を見るのが望ましい
- ファイル名・ID・キーワードを明示的に書ける質問ほど強い。ユーザー側の「良い質問の書き方」教育でも底上げできる
12. 実務での示唆
5 Round の検証から得られた実用的な知見:
- 既存 SPO を "参照するだけ" では非構造化データの半分も見えない — 出発点 (Round 1) はほとんどのユーザーが最初に試す構成だが、そのままでは実用にならない
- 設定チューニング (Opus / 「根拠のない回答」禁止 / CI ON / Web 検索 OFF) 単独では効果が薄い — SPO 参照型では CI が実力を出せないため。「モデルを Opus に上げれば解決」は幻想
- プロンプト改良 (R3) は数値ではなく信頼性を上げる — Excel は CI 解析、画像 PDF は画像確認、と指示文で誘導。Pass 数は R2 と変わらないが、偶然の正答が honest な失敗になるなど回答の質が変わる。SPO の自動反映を保ったまま実現できるのが強み
- 画像 PDF が必須なら Upload 型に切り替える (Round 4) — CI が手元のファイルを解析できるようになり、OCR や画像処理が動く。ただし再アップロードが手動作業に
- 両方の良いとこ取り (R5 = Upload + プロンプト改良) は Q3 を部分回答に持ち上げる — ただし Q5 はプロンプトの誠実性強制により断言避けのまま。「全ての問で完全パス」は Classic では難しい
- クリティカルな回答は必ず出典を確認 — 「部下はいません」レベルの誤答や、同じ質問でも試行によって回答が変わるケースが普通に起きる
- 良いプロンプトは "偶然の正答" を "正直な失敗" に変える — 精度指標には出にくいが、信頼性の観点では大きな改善
- 表の項目名・列名は "検索されやすい語彙" にする — 「役職: 副店長」より「副店長: 佐藤 花子」の方が引かれやすい
- 【Part 3 参照】"SPO 参照でも Classic の限界を突破する" 追加手法を Part 3 で検証 — SharePoint コネクタをツール登録 + プロンプトでコネクタ/CI/ファイル名グロッサリを強制発火することで、Classic Chat 単発クエリで 7/7 に到達可能。従量課金化した New と比較して Classic (定額) を選ぶ場合の実務ガイドとして参照ください
実装選定の目安
| 用途 | 推奨構成 | 理由 |
|---|---|---|
| テキスト系のみ、更新頻繁 | SPO 参照 + 推奨設定 | 十分な精度、運用楽 |
| 画像・図面を含む、既存 SPO 活用したい | SPO 参照 + 推奨設定 + プロンプト改良 (R3) | 運用性を保ったまま回答の誠実性が上がる (ここまでは画像 PDF は取れない) |
| 画像・図面を含む、精度最優先 | Upload + 推奨設定 + プロンプト改良 (R5) | Classic の天井の可能性。画像 PDF の OCR まで届き、Q3 も部分回答可能 |
| 空間関係・階層構造を "断言できるレベル" で扱いたい | Classic では論める → Part 2 以降 の検討 | Classic の限界の可能性 |
13. 次回予告
本シリーズは全 5 部構成の Part 1。Part 2〜Part 5 では、Classic では届かなかった領域やファイル種別の難しさを、別の手段で突破できるか、あるいは Classic をさらに詰めた場合の到達点 を検証していく予定。
Part 2: Copilot Studio (New experience)
本記事は Classic experience で 5 Round 進めた結果、「空間関係」「図の階層構造」を断言可能なレベルで解けない 2 大限界 が残った (R5 で Q3 は部分回答までは到達)。
Part 2 では、Copilot Studio の新しい New experience でこの 2 大限界に挑む。こちらは:
- コーディングハーネス（Code Interpreter / エージェントの自律的なコード実行）
- エージェンティックループ（LLM が自ら計画 → 実行 → 観察 → 判断を回す）
といった機能が組み合わさっており、単発の RAG では届かないシナリオに踏み込める可能性がある。
特に興味があるのは:
- 空間関係（「厨房の隣は？」）を、エージェントが「平面図をコードで解析 → 各エリアの座標抽出 → 隣接関係を算出」まで自律的にやってくれるか
- 「鈴木の部下は？」のような組織図の階層読取が、エージェンティックループで安定するか
- 図面 PDF に対する ファイル名ヒント不要化（Classic experience では "C2 図面版" と明示しないと引かれなかった問題）
- SPO 参照型で残った 画像 PDF (Q6) が New experience で救えるか
【検証結果 (追記)】
Part 3: Copilot Studio (Classic) を極める
Part 2 の New experience が 従量課金化 したことを受け、実務導入の選択肢として Classic (Standard Harness) をもう一度検証し直す。この Part 1 の R5 (Upload + プロンプト改良) の先に、「SharePoint コネクタをツール登録 + プロンプトでコネクタ/CI を強制発火 + ファイル名グロッサリを仕込む」 という手法で 単発クエリ Chat では 7/7 Pass に到達可能 という検証結果が得られている。
想定シナリオとして:
- Part 1 の R5 と同じ 7 問セットを 新プロンプト (コネクタ強制 + グロッサリ) で再検証し、R5 の 5-6/7 からの向上幅を確認
- Part 2 の New N2 (7/7 ・従量課金) と同スコアを Classic (定額) で実現できるか のコスト対精度検証
- Chat での 7/7 の裏側にある 実運用上の注意点 (CI 発火後のセッションの不安定性、SPO 検索インデックスの非決定性、コネクタ未登録時のファイル取得失敗など) の整理
- どのユースケースなら Classic を選ぶ価値があるか の中立的な判断材料の提供 (単発 Q&A / コスト優先 / 既存 SPO 資産活用 などのフィット見極め)
Part 3 は "Classic を見限る" 記事ではなく、"Classic を使いこなしたい人向けの実務ガイド" を目指す。
【検証結果 (追記)】
Part 4: Azure AI Search + カスタム RAG
Part 4 では、対象を より実務に近い大容量・高解像度の CAD 図面 に拡張し、Copilot Studio で詰まる領域 を Azure AI Search で挑む。
想定シナリオ:
- A0/A1 サイズ、数十 MB、部品数百 の実務 CAD 図面
- Copilot Studio の New experience でも詰まる (ファイル制限・処理時間・詳細検索の粒度)
- Azure AI Search なら チャンク戦略・埋込モデル・前処理を細かく制御 できる
比較する 3 構成:
| 構成 | 差分 |
|---|---|
| AS-1: ベースライン | 標準テキスト抽出 + 固定長チャンク + ベクトル検索 |
| AS-2: 構造化 + ハイブリッド | Document Intelligence + ベクトル+キーワード検索 + セマンティックランカー |
| AS-3: マルチモーダル | AS-2 + 画像分割 + マルチモーダル埋め込み (Azure Vision) |
Part 5: Fabric データエージェント (複雑 Excel 対応)
Part 5 では、Fabric データエージェント を使い、複数シート・ピボットテーブル等を含む複雑な Excel を、非構造化ドキュメントとしてではなく 構造化データとして扱う アプローチを検証予定。
- Classic・New experience の Code Interpreter では届かない スキーマ理解 + SQL 的クエリ の世界
- ファイル種別に応じて エージェント選択自体を切り替える のが有効か、New experience だけで十分かを対比
シリーズ全体のねらい
環境を段階的に "重装備" にしていくと、どこまで届くか を対比するのがシリーズ全体の目的。
| Part | 環境 | 主なチューニング手段 |
|---|---|---|
| Part 1（本記事） | Copilot Studio (Classic experience) | プロンプト・設定（「根拠のない回答」 / Code Interpreter / Web 検索）・モデル選択・接続方法 |
| Part 2 | Copilot Studio (New experience) | コーディングハーネス・エージェンティックループ |
| Part 3 | Copilot Studio (Classic) を極める | SharePoint コネクタ + Code Interpreter + ファイル名グロッサリ / 実運用の注意点 |
| Part 4 | Azure AI Search + カスタム RAG | 前処理・チャンク・埋込モデル・検索モード・大容量対応 |
| Part 5 | Fabric データエージェント | 複雑 Excel をスキーマ理解・SQL 的クエリで扱う |
Part 1→ Part 2→ Part 3→ Part 4→ Part 5 と進むにつれて、実装難度や対応領域が広がっていく想定 (Part 3 は Part 2 と並行して "Classic に留まる選択肢" を中立に検証する位置付け)。実務では「自分のユースケースがどこまでを必要とするか」を見極める指針になるはず。
（Part 2 に続く）
付録: 検証で使ったサンプルデータの中身
- 店舗基本情報: Cafe Latte / 東京都渋谷区代々木 / 席数 32
- メニュー: 15 品目（ドリンク 10 / フード 5）、価格 300〜1,200 円
- スタッフ: 8 名（正社員 4 / アルバイト 4）
- 議事録: 6 月度売上、新メニュー（ゆずレモネード）、8 月シフト、トイレ改修
- ブラケット: 図番 BRK-2026-001、材質 SS400、寸法 100 × 60 × 60 mm
- 平面図: 12 × 8 m、部屋 10 個、諸元表付き
- 組織図: 4 階層、山田店長 → 佐藤副店長 → 3 名 → 3 名の階層
すべてのファイルと生成コードはリポジトリの samples/ 配下に保存されている。