Microsoft 365 Copilotの“最短”RAG構築術 Azureでの完全カスタムも徹底解説：RAG構築術 Microsoft編

LLMの精度を向上させる方法として注目される「RAG」。本稿では「Microsoft 365 Copilot」と「Microsoft Azure」を用いたRAG構築法を、手軽な方法からフルカスタムの方法まで網羅的に解説する。

[村田知己，キーマンズネット]

　企業における生成AIの利用が本格化する中、外部情報の検索機能を大規模言語モデル（LLM）に組み合わせる手法、「RAG」（Retrieval-Augmented Generation＝検索拡張生成）に注目が集まっている。キーマンズネットの読者調査では「興味がある生成AI関連技術」として「AIエージェント」（59.1％）に続いてRAGが2位（47.7％）だった。

　企業においてRAGを用いたシステムを構築する場合、高性能なLLMを従量課金で使用できる「Amazon Web Services」（AWS）、「Microsoft Azure」（Azure）、「Google Cloud」などの大手クラウドサービスを用いるのが一般的と言える。本特集では、これら3社のクラウドサービスでRAGを構築する方法を解説する。今回はMicrosoft編だ。

• 第1回：Microsoft編（本稿）
• 第2回：Google Cloud編（2025年8月25日公開予定）
• 第3回：AWS編（2025年9月1日公開予定）

Microsoft 365 CopilotとAzureでRAGを構築するパターン3選

　MicrosoftはRAGを以下の2つのプロセスに分けて解釈し、これらを一貫して支援するサービスと、それぞれを固有に支援するサービスを提供する。

1. ユーザーが入力したクエリに応答するために必要な情報を取得するプロセス（Retrieve）
2. 取得した情報をプロンプトに付加（Augment）してLLMの外部知識として入力し、LLMに応答を生成（Generation）させるプロセス

最も簡単な“最短実装法”

　「Microsoft 365 Copilot」（以下、Copilot）プランを契約している場合、「Microsoft 365 Copilot Chat」（以下、Copilot Chat）で「Researcher」（日本語の機能名は「リサーチツール」）、「Analyst」（日本語の機能名は「アナリスト」）という事前定義済みのエージェントを利用できる。これらは企業内のデータとWeb上のデータの両方に基づいて推論するAIエージェントであり、Researcherは調査、Analystはデータの分析に特化している。

リサーチツールの利用イメージ（出典：MicrosoftのWebサイト）

　Microsoftの担当者によれば、取材時点ではこれが「最も簡単なRAG実装パターン」であり、該当プランを契約するだけでRAG相当の機能を利用できる。

　これらのエージェントは「Microsoft Teams」のチャットや「Microsoft Outlook」の電子メールなどのMicrosoft 365内の情報にアクセスし回答する。「Microsoft 365 管理センター」から各種クラウドストレージやCRMなどMicrosoft 365外の情報源にアクセスするためのコネクターを設定することで、普段の業務で使用しているデータを広く検索対象にできる。

　Microsoft 365のユーザーは追加料金不要でCopilot Chatを利用できるが、本稿執筆時点では上記のエージェント機能は別途Copilotプランの契約が必要なことに注意してほしい。導入検討の際はMicrosoftのWebサイトで最新の情報をチェックする必要がある。

自分好みのエージェントを作るなら「Copilot Studio」

　上記のResearcherとAnalystは簡易的に使用できる反面、機能が事前に定義されているため、自分好みのAIエージェントを作成したい場合は「Copilot Studio」を利用することになる。

　Copilot StudioはAIチャットbotやAIエージェントをノーコード／ローコードで構築できるプラットフォームだ。

　Copilot Studioの「エージェントビルダー」を使うと、AIとの対話型形式でエージェントを構築できる。手動でプロンプトや接続するデータソースを選択することもでき、非エンジニアがノーコードでAIエージェントを作りたいのであれば、まず使いたいツールだ。

エージェントビルダーでのエージェント構築画面（出典：MicrosoftのWebサイト）

　Copilot Studioでは「Power Automate」のようにワークフローを構築することもでき、エージェントビルダーよりも細かいカスタマイズが可能だ。

　Copilot Studioの利用は、加入しているプランによっては従量課金制になる可能性がある。MicrosoftのWebサイトから最新の情報を入手した上で利用してほしい。

フルカスタムするなら「Azure AI Foundry」で

　ここまではMicrosoft 365 CopilotやCopilot Studioのプラン内でシンプルにRAGを構築する方法を紹介したが、要件によってはAzureでフルカスタムしたRAGシステムを構築することもできる。

　上述したようにMicrosoftはRAGを以下の2つのプロセスに分けて解釈し、Azureはこれらを一貫して支援するサービスと、それぞれを固有に支援するサービスを提供している。

1. ユーザーが入力したクエリに応答するために必要な情報を取得するプロセス（Retrieve）
2. 取得した情報をプロンプトに付加（Augment）してLLMの外部知識として入力し、LLMに応答を生成（Generation）させるプロセス

　AzureのRAG関連サービスの一覧は以下の通りだ。データの抽出から検索、生成、UIまでRAGの構築に必要な機能を一通り提供している。

Azureで提供されているRAG関連サービスの一覧（出典：Microsoftの提供資料）

　「Azure AI Foundry」（旧 Azure AI Studio）はAzureにおけるAIサービス開発の統合プラットフォームであり、Azureを用いたAIサービス開発の基軸となるサービスだ。ここから各サービスを呼び出して利用するのが定石となる。

Azure AI Foundryがフォローする範囲（出典：Microsoftの提供資料）

　ユーザーが入力したクエリに応答するために必要な情報を検索して取得するプロセスである「Retrieve」を担うサービスとして代表的なのが「Azure AI Search」だ。Retrieveのプロセスを（1）インデックスの構築と（2）検索処理の2つに分けて解説する。

　（1）について、Azure AI Searchはデータ基盤サービスの「Microsoft Fabric」のデータを定期的に収集し、必要な加工を施した上でインデックスに格納するというパイプラインをローコード（簡易的なJSONの記述）で実現できるという。

　（2）について、Azure AI Searchは「フルテキスト検索」と「ベクトル検索」の2つの検索方式をサポートしている。前者は入力クエリに合致する文書をダイレクトに検索する方法、後者は単語の意味や文脈を基に関連性の高い文書を検索する方法だ。これらを組み合わせたハイブリッド検索や、AIによる検索結果の並べ替え機能を付与した「セマンティックハイブリッド検索」にも対応している。

　Retrieveを担うサービスとして「Azure Cosmos DB」や「Azure Database for PostgreSQL」などのデータベース製品も挙げられる。Azure Cosmos DBはMicrosoft Researchが開発した「DiskANN」というベクトル検索アルゴリズムを使用しており、少ないコンピューティングリソースで大規模なベクトル検索が実現できるという。Azure Database for PostgreSQLは「Apache AGE」という拡張機能を用いることでグラフ検索（単語同士の関係性をマッピングした「グラフ」を基に検索する方法）が可能になり、GraphRAG（Retrieveのプロセスでグラフ検索を使うRAG）の実装も可能だ。

　「Generation」を実行するサービスの代表例は「Azure OpenAI Service」だ。これはOpenAIの様々なAIモデルの利用環境を提供するためのサービスで、本稿執筆時点で最新の「GPT-5」から、推論モデルのo3-pro、テキスト埋め込みモデル、画像生成モデル、音声認識モデル、音声合成モデルといった、幅広い用途のためのモデルを利用できる。ちなみに「Model Catalog」というサービスではOpenAI以外のモデルも利用できる。「Gemini」派、「Claude」派、オープンモデルのファインチューニング派も安心してほしい。

Azure OpenAI Serviceで提供されているモデルの一覧　※GPT-5公開前のもの（出典：Microsoftの提供資料）

　RAG構築基盤としてAzureを使用するメリットについて、Microsoftの担当者は「フルマネージドサービスでありながら、利用者の習熟度、実現したいことの複雑性に応じた、柔軟性を持つサービスである点」を挙げる。例えば上述のAzure AI Searchはローコードでインデックス構築のためのパイプラインを構築することも、プロコードでの構築でも利用も可能だ。

　また、堅牢（けんろう）なセキュリティもAzureの強みだという。「Azure AI Content Filter」を利用することで、プロンプトインジェクション攻撃をはじめとした生成AIサービスを標的とした攻撃を検知し、ブロックできる。「Azure AI Red Teaming Agent」を使うと、公開したAIエージェントのセキュリティ対策の有効性を評価してくれるという。多くの企業が導入する「Microsoft Entra ID」を起点に権限管理ができる点もメリットの一つといえるだろう。

導入時の注意点

　実際にMicrosoft 365やAzureでRAGを構築する際は、自社にとって適切なパートナー企業を選ぶことも重要だ。Microsoftの担当者は「ドキュメント検索機能やLLMによる生成機能が注目されがちだが、『データソースから検索対象のドキュメントを特定し、検索インデックスに格納する』プロセスも重要だ」と話す。つまり、「Microsoft SharePoint」や「Microsoft Fabric」、社内のファイルサーバなどのデータ基盤同士の連携までサポートできるパートナーを選ぶ必要がある。

　その他、導入後のリスクとしてMicrosoftの担当者は以下の3点を挙げる。

1. 回答精度が低く、思ったより使われない
2. 想定よりコストがかかる
3. セキュリティインシデント発生

　1について、回答精度が低い原因としてはRetrieveしたドキュメントに回答のための情報が含まれていないケースが多いという。対処法としては、適切なデータソースへの接続と、「Azure Document Intelligence」といった解析AIサービスを用いたドキュメントのテキスト化などがある。

　2は、逆に想定より利用ユーザーが多く、見積もり時点よりコストがかかるというケースだ。RAG対象のドキュメントサイズが多すぎて、Azure AI Searchのコストが高くなっている場合もあるという。ベクトルデータを利用していれば「ベクトル量子化」の機能によって、検索精度をある程度維持したまま、データサイズを削減できるケースもある。また、AIモデルのコストが高い場合はモデル「gpt-4.1-mini」のようなサイズの小さなモデルに切り替えることが推奨される。

　3のセキュリティインシデントは、（1）プロンプトインジェクション攻撃によってAIエージェントが意図しない動作をした結果、Retrieveした内部文書が外部に送信されたなどのインシデント、（2）利用者が本来アクセスできない情報をRAGを通じて取得できてしまった、の2パターンが多いという。

　（1）の対策としては上述のAzure AI Content FilterによるブロックやAzure AI Red Teaming Agentでの評価、「Microsoft Defender for Cloud」での継続的な監視が重要になる。（2）はAzure AI Foundry の「Agent Service」経由で組織的なデータ管理をサポートするサービス「Microsoft Purview」と連携することで対処できるという。

　本稿ではMicrosoft 365とAzureによるRAG構築法を解説した。次回はGoogle Cloud編をお届けする。