※本ブログは、米国時間 7 月 23 日に公開された ‘1 million documents to 300+agents: Building an enterprise-scale Microsoft 365 Copilot connector’ の抄訳です。

100 万件のドキュメント。月間 10 万人以上のユーザー。300 以上の Copilot Studio エージェント。これらを支える Microsoft 365 Copilot コネクタの構築を通じて得られた知見をご紹介します。

企業のナレッジの大半は、利用者から信頼されているにもかかわらず、日々の業務の流れの中ではめったにアクセスされないポータルやリポジトリに存在しています。このコネクタは、まさにそのギャップを埋めるために構築されました。

Microsoft では、社内ドキュメントを、サポートされている Copilot エクスペリエンス全体でグラウンディング用のコンテキストとして利用できるようにするため、エンタープライズ規模の Microsoft 365 Copilot コネクタを構築しました。このコネクタは現在本番環境で稼働しており、エンジニアリング、サポート、フィールドの各職種にわたるチームに利用されています。

この記事の対象読者: プロトタイプの段階を終えて本番運用を検討しているプラットフォーム チーム、開発者、コネクタ オーナーの皆さま。本記事では、Microsoft 365 Copilot を通じてエンタープライズのナレッジを見つけやすく、再利用しやすくするうえで役立った、設計上の選択、セキュリティとガバナンスに関する考慮事項、スキーマに関する判断、運用パターン、検索品質を高めるためのプラクティスについて説明します。

Microsoft 365 Copilot コネクタが重要な理由を理解する

Microsoft 365 Copilot コネクタは初めてですか？まずは Microsoft 365 Copilot コネクタの概要と Copilot connectors API のドキュメントをご覧ください。

コネクタが稼働し、サポートされている Microsoft 365 Copilot エクスペリエンス向けに構成された瞬間から、コンテンツはそれらのエクスペリエンスでグラウンディング用のコンテキストとして利用できるようになります。これは、次のことを意味します。

• Copilot Chat — ユーザーは自然言語で質問し、メール、ファイル、Teams のメッセージとあわせて、皆さまのコンテンツに基づいた回答を得ることができます。ポータルにアクセスする必要はありません。
• Copilot in Microsoft 365 apps — Word、PowerPoint、Excel の Copilot (サポートされている場合) では、ユーザーが下書きの作成、要約、プレゼンテーションの作成を行う際に、皆さまのナレッジがコンテキストとして表示される場合があります。
• Copilot Studio エージェント — 適切な権限とライセンスを持つユーザーは、コネクタのコンテンツを対象範囲とするカスタム エージェントを構築できます。私たちの場合、Microsoft 社内のチームによって 300 以上のエージェントが作成されました。インシデント対応アシスタント、オンボーディング用 Copilot、ドメイン固有の Q&A ボットなど、いずれも私たちによる追加作業なしで実現しています。
• Copilot CLI と開発者ツール — Copilot CLI は、ターミナルで作業する開発者向けのコマンドライン エクスペリエンスです。エンジニアは、同じ信頼できる正式なコンテンツに基づいた回答を、ターミナルや IDE で得ることができます。
• Copilot Retrieval API — 適切なアクセス権を持つチームは、インデックス化されたナレッジをプログラムからクエリして、私たちが想定もしていなかったカスタム エクスペリエンスを構築できます。

重要なポイントは、コネクタが単なる取り込みパイプラインではないということです。クリーンなスキーマ、信頼性の高い取り込み、適切なアクセス制御に投資すれば、サポートされている Copilot エクスペリエンスは、サーフェスごとに個別の統合を必要とすることなく、そのコンテンツを再利用できます。

用語について簡単に補足します。この記事で説明しているのは、Microsoft 365 Copilot 同期コネクタ (以前は Graph コネクタと呼ばれていたもの) です。同期コネクタはコンテンツを Microsoft 365 substrate に取り込んでインデックスを作成するもので、コンテンツをその場でクエリするフェデレーション コネクタとは異なります。

本番運用に向けたギャップに備える

公開ドキュメントを参照すれば、ゼロの状態から動作するコネクタを作成するところまでは到達できます。しかし、動作するコネクタを本番環境レベルのコネクタへと発展させる過程で、想定していなかった 4 つのギャップが明らかになりました。テナントの構成、セキュリティとコンプライアンスへの対応準備、見つけやすさ、そして共有されるスロットリング制限です。

テナントの構成を早期に検証する

ドキュメントに記載されている手順は、テナントでコネクタを作成し、データを取り込むところから始まります。私たちの環境では、本格的な本番運用の前にアーキテクチャを検証する必要があり、その過程でドキュメントに記載されていないいくつかの問題に直面しました。次の点に注意してください。

• クロステナントのデータ フロー。現時点では、Entra ID テナント間のクロステナント データ フローについて、サポートされているモデルはありません。私たちは、コネクタの運用を単一のテナントに集約することでこの問題を解決しました。
• 「Draft」状態のまま進まない問題。権限が正しく設定されていても、コネクタが「Draft」状態のまま動かなくなることがあります。プラットフォーム チームを通じてエスカレーションするのが、最も早い解決方法でした。
• オーナーシップの空白。複数のプラットフォーム チームの責任範囲が重なり合っており、単一のオーナーが存在しません。必要になる前に、エスカレーション パスを特定しておいてください。
• 開発テナントのライフサイクル。開発テナントには、ドキュメントに記載されていない自動削除ポリシーが適用されている場合があります。開発テナントを長期的なステージング環境として当てにしないでください。

セキュリティとコンプライアンスへの対応を早期に開始する

アプリを登録して権限を構成するのは、簡単な部分にすぎません。エンタープライズ規模のクロステナント コネクタでは、さらに次のものが必要でした。

• 脅威モデル
• プライバシー レビュー
• Responsible AI レビュー
• プラットフォーム チームによる設計レビュー
• セキュリティ例外の承認

テンプレートは存在しませんでした。チェックリストもありませんでした。あらかじめ定められた手順もありませんでした。これは、コードを書くよりもずっと前から始まった、相当な労力を要する取り組みでした。

コネクタのコンテンツを見つけやすくする

取り込みに成功しても、Copilot が皆さまのコンテンツを優先するとは限りません。既定では、メールやユーザーのファイルの方が上位にランク付けされます。コネクタのコンテンツのランク付けは、クライアントによって異なります。ある結果が表示された理由、あるいは表示されなかった理由を把握する手段はありません。UserPrincipal のサポート (インデックス化されたアイテムにユーザー ID を関連付けて、そのユーザーのメールやファイルと同じシグナルでランク付けされるようにする機能) は、私たちにとって重要なプラットフォームの改善点です。近い将来これを採用し、Copilot の結果において、コネクタのコンテンツがユーザーのその他の業務コンテンツと並んでより確実に表示されるようにすることを目指しています。

スロットリングと共有の制限を考慮して設計する

ドキュメント数が約 100 万件に達した段階で、スロットリングは設計上の重要な考慮事項となりました。私たちは、再試行ロジック、指数バックオフ、429 応答の監視、そして取り込みの遅延を迅速に検出するための運用アラートによって、これに対処しました。

Microsoft 365 Copilot コネクタ プラットフォームには、テナント内のすべてのコネクタで共有されるグローバルなレート制限があります。別のコネクタの取り込みが急増すると、自分のコネクタがスロットリングされます。しかも、429 応答は、その理由も、誰がその枠を消費しているのかも教えてくれません。現時点では、共有クォータを可視化する手段も、優先順位の仕組みも、容量を予約する方法もないため、予期しないバックプレッシャーに耐えられるようにパイプラインを設計しておく価値があります。

スケールに対応したコネクタを構築する

私たちのアーキテクチャは、ソース コンテンツを取り込み処理のコンピューティングから分離するという 1 つの原則に重点を置きました。この選択により、パイプラインの再試行や監視が容易になったほか、ドキュメント プラットフォームの変化に合わせてパイプラインを進化させやすくなりました。

データとコンピューティングを分離する

設計の中核となる原則は、データ層を取り込み処理のコンピューティングから完全に分離することでした。ドキュメント プラットフォームはコンテンツを Azure Blob Storage に格納しており、これが信頼できる唯一の情報源です。取り込みパイプラインがそのデータを所有したり複製したりすることはありません。代わりに、変更に反応して、その場で変換を行います。

• Blob Change Feed — Azure Blob Storage の変更フィードは、ドキュメントが作成、更新、削除されるたびにイベントを発行します。これがすべての取り込み処理のトリガーとなるため、ポーリングも、スケジュールされたフル クロールも不要です。
• Azure Function (イベント駆動型) — Azure Function が変更フィードをリッスンし、各イベントを処理します。この関数は BLOB を読み取り、コンテンツを変換し、メタデータを充実させたうえで、アイテムを Microsoft Graph connectors API にプッシュします。関数はステートレスであり、すべての状態はストレージ層と Microsoft Graph プラットフォームに保持されます。
• 境界としてのストレージ — 関数は BLOB ストレージへの読み取りアクセス権を持ちますが、書き戻すことはありません。データは、ストレージ → 関数 → Graph API という一方向に流れます。これにより、パイプラインの動作を把握しやすく、安全に再試行できる状態が保たれます。BLOB イベントの再処理は常にべき等です。
• Graph API による取り込み — アイテムは再試行ロジックを使用してプッシュされ、429 応答に対してはバックオフを行い、Application Insights によって可観測性を確保しています。

この分離により、次のことが実現します。

• ドキュメント プラットフォームは、取り込みパイプラインに手を加えることなく、新しい形式、新しいメタデータ、再編成など、ストレージを独立して進化させることができます。
• パイプラインは Azure Functions の従量課金プランによって水平方向にスケールするため、コンテンツ更新の急増に備えた容量計画は必要ありません。
• 障害は分離されます。問題のある BLOB が他の取り込みをブロックすることはなく、変更フィードによって自然な再試行のセマンティクスが提供されます。

スキーマ設計を反復的に改善する

私たちは、スキーマ設計を最も効果の大きい意思決定として扱いました。4 回の反復を通じて検索品質を大幅に向上させましたが、これはすべて、次のようなスキーマとメタデータの改良によって実現したものです。

• ドキュメントの種類 (TSG、Runbook、アーキテクチャ ドキュメント、オンボーディング ガイド) を、それぞれ異なるプロパティ セットにマッピングしました。
• Copilot のランク付けに最適化した、詳細な接続の説明を記述しました。
• 鮮度とオーナーシップのシグナルとなるカスタム プロパティを追加しました。
• 合成データではなく、実際のユーザーのクエリを使用してテストしました。

安全な認証とデプロイのパターンを使用する

いくつかのパターンを採用することで、環境をまたいだデプロイをシンプルに保つことができました。

• Managed Identity を本番環境でのサービス間通信に使用しました。
• Infrastructure-as-code を採用し、商用クラウドとソブリン クラウド全体で一貫したデプロイを実現しました。
• 環境固有の構成を当初から抽象化しました。

検索品質を測定する

Microsoft 365 Copilot プラットフォームにオンボードしたことによるメリットの 1 つは、Copilot チームが使用している Search Evaluation フレームワークを利用できたことです。これにより、評価インフラストラクチャを一から構築することなく、実際のユーザーのクエリに対する適合率や再現率を含め、検索品質を測定することができました。私たちはこのフレームワークを使用してパイプラインの変更をテストし、ユーザーに影響が及ぶ前にリグレッションを検出しました。

コネクタの正常性を監視する

コネクタが正常であることは他のすべての前提条件となるため、私たちは次の仕組みを構築しました。

• 取り込みの失敗やスロットリングの急増に対するアラート
• 再取り込みのシナリオに対応する復旧の自動化

効果を確認する

コネクタの稼働後、3 つの点が際立っていました。ポータルがプラットフォームへと変わったこと、その上にエージェントのエコシステムが形成されたこと、そして必要な制御を維持しながら品質を測定する新しい方法を得られたことです。

ポータルからプラットフォームへ

ドキュメント プラットフォームは、人々が訪れる目的地から、Microsoft 全体の AI エクスペリエンスを支えるナレッジ ソースへと変わりました。ユーザーはもうポータルに移動する必要はありません。ナレッジは Copilot Chat、Copilot in Word、Copilot in VS Code、Azure Copilot の中に直接表示されます。ナレッジの活用は既存のワークフローに組み込まれ、自然に、かつ状況に応じて行われます。

エージェントのエコシステム

Microsoft 365 Copilot プラットフォームの中核となる価値提案は、コンテンツを一度プッシュすれば、複数の AI サーフェスで利用できるようになるという点です。実際に、まさにそのとおりになりました。

現在、300 以上の Copilot Studio エージェントがこのコネクタを基盤として構築されています。コンテンツは Copilot Chat、Copilot CLI、Work IQ (Microsoft のワークプレース インテリジェンス エクスペリエンス)、その他の AI を活用した開発者ツールに表示され、これらはすべて単一の取り込みパイプラインによって実現されています。Microsoft 社内のチームは、次のようなものを作成しました。

• 関連するトラブルシューティング ガイドを見つけやすくするインシデント対応アシスタント
• アーキテクチャ ドキュメントを状況に応じて取得するオンボーディング用 Copilot
• チームのコンテンツを対象範囲とする、ドメイン固有の Q&A エージェント
• 人による監督を伴うサポート強化ワークフロー

クリーンなスキーマ、適切なアクセス制御、信頼性の高い取り込みなど、コネクタを一度で正しく構築することに投資したからこそ、サポートされている Copilot エクスペリエンスはそのコンテンツを自動的に再利用できています。300 以上のエージェントのいずれについても、私たちのチームによる追加の統合作業は必要ありませんでした。

測定可能な品質と維持されたガバナンス

新しい機能が加わる一方で、この移行によって最も重要なものが守られました。それは、既存の制御と、自分たちの取り組みを測定する手段です。

• 大規模なプログラムによるアクセス。Copilot Retrieval API を使用すると、適切なアクセス権を持つチームは、ドキュメント チームを介さずに、インデックス化されたナレッジをプログラムからクエリできます。取り込みは 1 回、活用は複数のサーフェスで。
• ガバナンスの一元管理を維持。AI と統合されても、コネクタは引き続き既存の Microsoft 365 のセキュリティとアクセス制御に依存しています。ガバナンス ポリシーとアクセス制限は、引き続き一元的に管理されています。これは、ソブリン クラウドへのデプロイや規制対象の環境にとって極めて重要でした。
• 品質が測定可能に。評価フレームワークを導入したことで、回答の品質を定量化し、継続的に改善できるようになりました。これは、プラットフォームが単なる静的なポータルだった頃には不可能だったことです。

コネクタ構築時にこれらの推奨事項を適用する

Microsoft 365 Copilot コネクタを計画している場合、プロトタイプから本番環境へ移行する前に私たちが優先して取り組むべきだと考えるプラクティスは、次のとおりです。

• コードを書く前に、セキュリティとコンプライアンスに関する話し合いを開始する — 想定よりもかなり多くの時間を見込んでおいてください。
• 最も効果の大きい意思決定としてスキーマ設計を扱う — 早い段階から実際の Copilot クエリでテストし、積極的に反復してください。
• 初日から評価の仕組みを構築する — Copilot が皆さまのコンテンツを実際に効果的に活用しているかどうかを測定する必要があります。
• コネクタ自体の正常性監視を構築する — 監視対象はパイプラインだけではありません。
• エコシステムを見据えて設計する — しっかりと構築すれば、想定していなかった方法で、ほかの人々がその上に新たなものを構築していきます。

投資に見合う価値を実現する

Microsoft 365 Copilot コネクタの公開ドキュメントでは、「何を」するのかが説明されています。この記事では「どのように」行うのか、そしてさらに重要な「なぜそれだけの価値があるのか」を取り上げています。

セキュリティの承認には数か月を要しました。スキーマの反復は 4 回に及びました。運用準備には、私たちの誰もが見込んでいなかったオーナーシップが必要になりました。しかし、その見返りは確かなものです。組織のナレッジが AI を通じてアクセス可能になり、信頼できる正式なコンテンツに基づいて、サポートされている Microsoft 365 Copilot エクスペリエンス全体で利用できるようになります。

プラットフォームは強力です。そこにたどり着くまでには労力がかかります。本番運用の最初の 1 年間で、このコネクタを基盤に 300 以上のエージェントが構築されましたが、そのいずれにおいても私たちのチームによる追加の統合作業は必要ありませんでした。

始めましょう

• Microsoft 365 Copilot コネクタの概要
• Copilot connectors API を使用する
• 接続を作成および管理する
• スキーマを登録および管理する
• Copilot Studio でナレッジ ソースとして Copilot コネクタを追加する
• Microsoft Graph のスロットリング ガイダンス
• Azure Blob Storage の変更フィード

ディスカッションに参加しましょう

Microsoft 365 Copilot コネクタを大規模に構築したことはありますか？皆さまが得た知見をぜひお聞かせください。下のコメント欄で経験を共有し、皆さまの環境でどのパターンが有効だったか (あるいは有効でなかったか) をお知らせください。

ご存じですか？Microsoft 365 Roadmap では、Microsoft 365 のアプリとサービス全体にわたる今後の更新情報を確認できます。Microsoft 365 Copilot のリリース ノートでは、一般提供されている Copilot の機能をプラットフォーム別に確認できます。最新の状況を把握するために両方のリソースを定期的にご確認ください。なお、ロードマップの日付は暫定的なものであり、変更される可能性があります。