やりたいこと
社内に散らばっているドキュメント（SharePoint、ファイルサーバー、業務 DB 等）を AI が読めるようにして、社員が質問したら的確に答えてくれる仕組みを作りたい。
この仕組みを実現するには 2 つのステップ が必要です：
| ステップ | やること | 呼び方 |
|---|---|---|
| ① | ドキュメントを AI が検索・理解できる形に変換する | AI Ready Data の整備 |
| ② | 整えたデータを使って AI が回答を生成する | RAG（Retrieval-Augmented Generation） |
❌ そのまま投入
SharePoint の .pptx → そのまま AI に渡す → 図表の中身を理解できない → 期待外れな回答
✅ 整えてから投入
SharePoint の .pptx → テキスト化・図表解析・意味で分割 → 適切な情報だけ AI に渡す → 的確な回答
本記事では ステップ ①（AI Ready Data の整備） に焦点を当て、Microsoft プラットフォームで選べる 3 つの方法 を比較します。
3 つの方法の概要
AI Ready Data を整備してベクトルインデックス（AI Search）に投入するまでの方法は、大きく分けて 3 つあります。
| 方法 | 一言で言うと |
|---|---|
| 方法 1: AI Search SharePoint Indexer (プレビュー) | AI Search から直接 SharePoint を参照 |
| 方法 2: AI Search OneLake Indexer + Integrated Vectorization | OneLake にドキュメントを集約 → AI Search 側で解析・チャンク・Embedding を自動実行 |
| 方法 3: Fabric Notebook フルカスタム | Notebook でドキュメント解析・チャンク・Embedding をすべてコードで制御 |
方法 1: AI Search 直接連携
方法 2: OneLake + Integrated Vectorization
方法 3: Fabric Notebook フルカスタム
3 つの方法はいずれも、最終的に Azure AI Search のベクトルインデックス にデータを投入するところがゴールです。その先の RAG（検索 → LLM 回答生成）は共通です。
方法 1 — AI Search SharePoint Indexer
仕組み
Azure AI Search の SharePoint Online インデクサー（プレビュー機能）を使い、SharePoint のドキュメント ライブラリから直接ドキュメントを取り込んでインデックスを作成します。
特徴
- コードゼロ — Azure Portal 上でインデクサーを設定するだけ
- SharePoint の権限をそのまま反映 — ドキュメント レベルの ACL をインデックスに引き継げる
- 差分更新が自動 — スケジュール実行でドキュメントの追加・更新を検出
制約
- プレビュー機能（GA 未定）— 本番ワークロードでの利用はリスクあり
- 対象は SharePoint のみ — 業務 DB やファイルサーバーは対象外
- ドキュメント解析が基本的 — 組み込み OCR のみ。表・図・見出し構造の理解は限定的
- チャンク制御が固定長分割のみ — セマンティック チャンキング（意味単位の分割）は不可
- 前処理の自由度が低い — Skillset で軽微な加工はできるが、PII マスキングや重複排除などの高度な処理は困難
適するケース
- SharePoint のテキスト主体のドキュメント（Word、テキスト PDF）だけが対象
- PoC や社内検証レベルの利用
- 構築に時間をかけられない場面
方法 2 — OneLake Indexer + Integrated Vectorization
仕組み
まず Microsoft Fabric の Data Pipeline で各種データソースから OneLake にドキュメントを集約します。その後、AI Search の OneLake Indexer（GA）がドキュメントを自動取得し、Integrated Vectorization（Skillset）でチャンク分割 → Embedding 生成 → インデックス登録を一括実行します。
特徴
- コード量ほぼゼロ — Fabric 側は Data Pipeline の設定、AI Search 側は JSON 定義とポータル設定で完結
- 複数ソース統合 — SharePoint だけでなく業務 DB、ファイルサーバー等も OneLake に集約できる（200 以上のコネクタ）
- 差分更新が自動 — OneLake Indexer がドキュメントの追加・更新を自動検出
- スケジュール実行が組み込み — インデクサーの機能として定期実行を設定可能
- OneLake で一元管理 — ドキュメント原本を一箇所に集約し、コピーの散在を防ぐ
制約
- チャンク品質は AI Search の Skillset 依存 — Text Split skill や Document Layout skill の範囲内
- 前処理の自由度が限定的 — Skillset で実行できる範囲に制約される
- 図表解析の精度 — Document Layout skill は基本的な構造認識に対応するが、複雑な表やグラフの解析はフルカスタムに劣る
適するケース
- 複数のデータソースを統合したいが、コードは書きたくない
- まず動く PoC を短期間で構築したい
- チャンク品質に高い要件がない（テキスト中心のドキュメント）
- 運用コストを最小化したい
方法 3 — Fabric Notebook フルカスタム
仕組み
Fabric Data Pipeline で OneLake にドキュメントを集約した後、Fabric Notebook（Python / PySpark）内で全処理を実行します。Document Intelligence でセマンティックチャンキング → カスタム前処理 → Embedding 生成 → AI Search Push API でインデックス投入、というパイプラインを自前で構築します。
特徴
- チャンク品質が最高 — Document Intelligence のセマンティック チャンキングをフル活用。表・図・見出し構造を保持した分割が可能
- 前処理の自由度が無制限 — PII マスキング、重複排除、メタデータ正規化、社内用語辞書の適用など、何でもできる
- Embedding モデルを選べる — Azure OpenAI の最新モデルに自由に切り替え可能
- Vision モデルとの組み合わせ — 図表やグラフを画像として GPT-4o 等に解析させ、説明文を生成できる
- カスタム メタデータ — ドキュメントの部署・カテゴリ・更新日等を自由に付与してフィルタリング検索に活用
制約
- Python 実装が必要 — パイプライン全体をコードで記述・保守する必要がある
- 差分更新を自前で実装 — 新規・更新ドキュメントの検出ロジックを自分で作る
- 運用負荷が最大 — パイプラインの監視・エラーハンドリング・リトライ処理の設計が必要
- 構築期間が長い — 最低限動くものを作るだけでも方法 1・2 より時間がかかる
適するケース
- 図表・グラフが多い PDF / PowerPoint が大量にある
- 検索精度が業務に直結する（正確でないと困る）
- 社内用語や業界固有の語彙への対応が必要
- 複雑な前処理（PII 除去、重複排除）が要件
- 本番品質のシステムを構築する最終段階
3 つの方法の比較
判断フローチャート
段階的アプローチ（推奨）
3 つの方法は排他的ではなく、段階的に移行 できます：
- 方法 1 または 2 で PoC — 短期間で動くプロトタイプを構築し、RAG の効果を検証する
- 品質を評価 — 図表の質問や社内用語を含む質問で回答品質を測定する
- 不足があれば方法 3 に移行 — OneLake にデータを集約するところまでは 2 と 3 で共通なので、インデックス生成方法だけ差し替えられる
方法 2 と方法 3 は「OneLake にドキュメントを集める」ステップが共通です。方法 2 で始めて、チャンク品質に不満が出たら方法 3 に切り替える、という段階的移行が可能です。
整えたデータを AI で使う — Microsoft Foundry
3 つの方法のいずれを選んでも、最終的には Azure AI Search のベクトル インデックス ができあがります。ここから先は共通です。
Foundry とは
Microsoft Foundry は、AI エージェントを作って・動かして・届けるための統合プラットフォームです。以前は「Azure OpenAI でモデルを呼んで」「AI Search でインデックスを検索して」「自前のアプリで組み合わせて」……と複数サービスを自分で貼り合わせる必要がありましたが、Foundry がこの統合を担います。
RAG の動作フロー
- 検索（Retrieval）：AI Search から質問に関連する情報を探す
- 生成（Generation）：見つけた情報をもとに LLM が回答を作成
Foundry を使うと、この仕組みが ポータル上の設定だけ で構築できます。
Microsoft Foundry の利点
| ポイント | 説明 |
|---|---|
| AI Search との統合 | ベクトル インデックスを「ナレッジソース」として接続するだけ |
| エージェントとして動く | 単なる Q&A ではなく、ツールを使って複数ステップで回答するエージェントを作れる |
| Teams / Copilot に公開 | 作ったエージェントを容易に Teams や M365 Copilot に配信できる |
| 権限管理が組み込み | 誰がどのデータを参照できるか、エンタープライズの権限構造を尊重する |
| 評価・改善の仕組み | 回答品質を自動評価し、プロンプトを改善するツールが内蔵されている |
Microsoft 365 Copilot との使い分け
「SharePoint のドキュメントに質問したいなら、M365 Copilot でいいのでは？」という疑問は当然あります。
| 観点 | M365 Copilot | 方法 1〜3 + Foundry |
|---|---|---|
| 追加構築 | 不要（ライセンスだけ） | 必要 |
| 図表・グラフの内容理解 | 限定的 | Vision モデルで明示的に解析（方法 3） |
| 検索ロジックのカスタマイズ | 不可 | Hybrid Search + Re-ranker を自由に調整 |
| チャンキング粒度の制御 | 不可 | 方法に応じて最適化可能 |
| 社内用語への対応 | 限定的 | シノニム辞書やカスタム Embedding で対応 |
| 複数ソースの横断検索 | M365 内のみ | 業務 DB・外部システムも含めた統合検索 |
| エージェントとしての拡張 | 制限あり | ツール連携・マルチステップ推論が可能 |
要するに、M365 Copilot は「すぐに始められる 70 点の方法」、方法 1〜3 + Foundry は「手をかけて 100 点を目指す方法」と言えると思います。ファイルサイズや解析精度に制限のある方法を取るか、足りない分を追加開発して精度向上を図るか。これは扱うファイルの特性やビジネスの特性によって選択することになります。
社内のドキュメントが主にテキスト中心で「だいたい答えてくれればいい」なら M365 Copilot で十分。図表が多い・検索精度が業務に直結する・M365 外のデータも統合したい、という要件があればカスタム構築が効いてきます。
M365 Copilot も性能向上してるので、待っていればできるようになることも増えると思いますが、「ライセンス」という固定料金での提供である限りは、何らかの制限は残らざるを得ないのだろうと、個人的に思います。
実際に始めるには
ステップ 1: 方法 2 で PoC を構築する
- SharePoint の 1 つのサイト（50〜200 ドキュメント程度）を対象にする
- Fabric Data Pipeline で OneLake に取り込む
- AI Search の OneLake Indexer + Integrated Vectorization でインデックスを自動生成
- Foundry でエージェントを作り、AI Search をナレッジソースとして接続
- 同じ質問を M365 Copilot と Foundry エージェントの両方に投げて比較
ステップ 2: 品質を評価する
- 図表に関する質問で差が出るか
- 社内用語を含む質問で差が出るか
- 検索精度（適合率・再現率）を定量的に測定する
ステップ 3: 必要に応じて方法 3 に移行する
- チャンク品質に不満がある → Fabric Notebook で Document Intelligence のセマンティック チャンキングを導入
- 前処理が必要 → PII マスキング、メタデータ正規化などをコードで追加
- OneLake にデータを集約するステップはそのまま再利用できる
ステップ 4: 本番化する
- 対象ドキュメントを拡大
- 差分更新パイプラインを構築（新規・更新ドキュメントを自動反映）
- 権限管理（ACL）の設計・実装
- Teams への公開
まとめ
| 疑問 | 答え |
|---|---|
| AI Ready Data を整備する方法は？ | 3 つある。直接連携 / OneLake + 自動処理 / Notebook フルカスタム |
| どれを選ぶ？ | PoC は方法 2、本番で高品質が必要なら方法 3。段階的に移行できる |
| 整備したデータをどう使う？ | Microsoft Foundry でエージェントを作り、Teams 等に配信 |
| M365 Copilot じゃダメ？ | ダメではない。検索精度・対象範囲に要件があるならカスタム構築 |
- データを整える方法は 3 段階 — 手軽さと品質のトレードオフ
- 段階的に進める — まず方法 2 で動かし、品質に不満があれば方法 3 へ
- AI を動かす場所は Foundry — どの方法で整備しても、出口は共通
なお、お題をドキュメント RAG としたので、すべての方法で出口 = エージェントが問い合わせる先を Azure AI Search としましたが、ベクトル検索に対応しているデータベースを使用する方法もあります。
データベースを使用する際のポイントは、データの二重管理を避けることです。すでに Cosmos DB や PostgreSQL にナレッジが蓄積されているなら、そこにベクトルフィールドを追加するだけで RAG の検索基盤が作れます。
AI Search が不要になるわけではなく、検索精度・マルチソース統合・Foundry 連携が必要になったときに AI Search を追加する という段階的アプローチも考えられます。