2026年6月時点の前提
この記事を読む前に、以下の提供状況を把握しておいてください。
- Microsoft Foundry は現行ブランド名（旧称：Azure AI Studio / Azure AI Foundry）
- Foundry IQ は機能によって GA（一般提供）と preview が混在
- Microsoft IQ は、Work / Web / Foundry / Fabric の 4 層からなる「コンテキスト／インテリジェンス層」の総称
- Work IQ MCP servers in Copilot Studio は preview 機能で、Copilot Studio から追加する場合は Microsoft 365 Copilot ライセンスが必要
- 一方で、Work IQ API は 2026年6月16日から提供されており、Microsoft 365 Copilot ライセンスとは別に従量課金で利用できるアクセス体系もある
そのため、この記事では Copilot Studio から Work IQ を使う構成 と、Work IQ API を別経路で使う構成 を意識的に分けて説明します。
本番導入を前提に検討している場合は、各機能の提供状況・認証方式・課金条件を公式ドキュメントで個別に確認することをお勧めします。
前回のおさらい
前回の記事では、「Copilot Studio だけで AI エージェントは完成するのか？」という問いを起点に、Foundry IQ・Copilot Studio・Work IQ の役割分担を整理しました。
要点だけ振り返ると以下になります。
- Copilot Studio は ローコードでエージェントを組み立てる GUI ツールであり、SharePoint・Dataverse・アップロード文書・Web サイト・Microsoft Copilot connectors などのナレッジソースを扱える
- Foundry IQ は Foundry 側のマルチソース知識基盤であり、Copilot Studio の標準ナレッジとは別の仕組み
- Copilot Studio から Foundry IQ を使う場合は Foundry IQ connector（preview）経由で、知識基盤をツールとして呼び出す
- Azure AI Search など既存の検索基盤を Copilot Studio から使いたい場合は、カスタムナレッジソースや connector、OnKnowledgeRequested などの仕組みで接続する考え方が基本
- 本番導入では、ナレッジ設計・権限設計・運用ルールまでセットで設計することが重要
今回はその続きとして、実際にどう組み合わせるか（構成パターン）と、ナレッジ設計の考え方を整理します。
その前に：Microsoft IQを理解しておく
構成パターンの話に入る前に、2026年の前提として押さえておきたいのが Microsoft IQ という枠組みです。
Microsoft は、個別に登場していた知識・コンテキスト関連の機能群を 「Microsoft IQ」という 1 枚の傘の下に並べ直しています。狙いは、エージェントに渡す「コンテキスト」を製品横断で扱えるようにすることです。
Microsoft の表現を借りるなら、エージェントの品質は、渡されるコンテキストの質に大きく左右される と言えます。
Microsoft IQ はこの課題を、次の 4 つのレイヤーに整理しています。
| レイヤー | ざっくりした担当範囲 |
|---|---|
| Work IQ | Microsoft 365（メール・Teams・SharePoint など）の業務コンテキスト |
| Web IQ | Web 上の情報 |
| Foundry IQ | Foundry 側で構成するマルチソース知識基盤 |
| Fabric IQ | Fabric 側のデータ／ビジネスコンテキスト |
前回扱った Foundry IQ と Work IQ は、この 4 層のうちの 2 つにあたります。
「名前が似ていて混乱する」のは当然で、もともと別レイヤーを担う別機能だと理解しておくと、構成を考えるときに迷いにくくなります。
⚠️ 各レイヤーは GA / preview が混在しています。特に、Copilot Studio から利用する Work IQ MCP servers は preview です。検証・本番導入前には、最新の提供状況を必ず確認してください。
構成パターンを考える前の判断軸
「どの構成にするか」を決める前に、まず以下の 3 つを整理すると判断しやすくなります。
- ナレッジはどこにあるか（M365 / Power Platform 内で完結するか、複数システムに散っているか）
- 誰に何を見せるか（全社共通か、部門・役職・案件単位で出し分けが必要か）
- どこまでパーソナライズするか（共通回答で十分か、個人の業務文脈に合わせるか）
この 3 つの答えによって、後述する構成パターンのどれが適切かが変わります。
構成パターン 3 つ
ここからは、前回整理した役割分担を踏まえた 代表的な 3 パターン を示します。シンプルな順に並べています。
パターン A：Copilot Studio の標準ナレッジソースだけで完結
最もシンプルな構成です。
- ナレッジが SharePoint・Dataverse・アップロード文書・Web サイト などでおおむね完結している
- アクセス権が SharePoint / Dataverse 側で整理できている
- パーソナライズはそこまで重視しない
- まずは FAQ、規程、マニュアル、部門文書 の参照から始めたい
この場合、Copilot Studio の標準機能だけで一定のエージェントが作れます。
複雑な知識統合が不要であれば、Foundry IQ を持ち出さなくても十分に成立します。
向いているケース： 社内 FAQ、特定部門の文書検索、規程・マニュアルの参照など。
パターン B：Copilot Studio ＋ Foundry IQ connector（preview）
ナレッジが M365 の外にも広がってくると、このパターンが候補になります。
- 参照すべきデータが 複数のシステムやデータソースに分散している
- 大規模・複雑な知識基盤を Foundry 側で一元的に構成したい
- Copilot Studio を 対話 UI / 業務導線 / トリガー制御 のフロントとして使いたい
この場合は、Foundry IQ connector（preview）を経由して Foundry IQ knowledge base を呼び出す形になります。
役割分担としては、Copilot Studio が 対話とオーケストレーション を、Foundry IQ が マルチソースの知識基盤 を担います。
向いているケース： 複数の業務システムを横断する技術文書検索、営業ナレッジ活用、製品情報の横断検索など。
Foundry IQ connector は preview のため、本番運用前提では提供状況と制約の確認が必須です。
パターン C：Copilot Studio から Foundry IQ と Work IQ を呼び分ける
さらに、個人やチームの業務文脈に合わせた回答を返したい場合に検討するのがこのパターンです。
この構成では、Copilot Studio がフロント／オーケストレーター となり、用途に応じて次を呼び分けます。
-
共通・制度・技術文書・製品ナレッジ
→ Foundry IQ connector 経由で参照 -
ユーザーやチームのリアルタイムな業務文脈（メール、会議、チャット、最近の作業文脈など）
→ Work IQ MCP tools / servers 経由で参照
つまり、Foundry IQ の中に Work IQ が自動的に混ざるというより、
Copilot Studio が「共通知識」と「個人・チーム文脈」を必要に応じて取り分ける構成 と考えると分かりやすいです。
- 共通知識は Foundry IQ
- 業務文脈は Work IQ
- その呼び分けと会話体験を Copilot Studio が担う
という整理です。
Work IQ は、Data / Memory / Inference の 3 層が連動して、Microsoft 365 や業務システムのシグナルをつなぎ、よりパーソナライズされた回答を返せるようにするレイヤーです。
Foundry IQ と組み合わせることで、「正しい共通知識」×「個人の業務文脈」 を両立しやすくなります。
⚠️ Copilot Studio から追加する Work IQ MCP servers は preview で、追加には Microsoft 365 Copilot ライセンス が必要です。
なお、Work IQ 全体としては API 提供も始まっており、そちらは別の課金体系で利用できるため、「Work IQ 全体が preview でライセンス必須」という理解にはしない 方が正確です。
パターン早見表
| パターン | 構成 | 主な用途 | 提供状況の注意点 |
|---|---|---|---|
| A | Copilot Studio 標準ナレッジのみ | M365 / Power Platform 内で完結するシンプル用途 | 特になし |
| B | Copilot Studio ＋ Foundry IQ connector | 複数ソースを束ねる大規模知識基盤 | connector が preview |
| C | Copilot Studio ＋ Foundry IQ connector ＋ Work IQ MCP tools | 業務文脈に合わせたパーソナライズ | Work IQ MCP servers in Copilot Studio が preview・Microsoft 365 Copilot ライセンス必要 |
いきなり C を目指すのではなく、要件に応じて A → B → C と段階的に検討する のが現実的です。
ナレッジ設計の考え方
構成パターンを選んだら、次は「何を・どう知識として渡すか」です。
前回挙げた「企業導入で難しくなるポイント」を、設計の観点から具体化します。
① 何をナレッジにするかを先に決める
情報が SharePoint・Teams・ファイルサーバー・業務システムに散らばっている状態のまま接続すると、エージェントが的外れな回答を返すリスクがあります。
- 対象範囲を絞る：まずは用途に直結する文書群から始める
- 重複・古い文書を整理する：同じテーマの新旧文書が混在すると回答が揺れる
- 「ナレッジにしないもの」も決める：何でも入れない判断が品質を左右する
この前提に立つと、ナレッジ設計は精度設計そのもの だと分かります。
② ナレッジ設計と権限設計はセットで考える
人事情報・案件情報など、全社員に開示できないデータは必ず存在します。
- パターン A なら SharePoint / Dataverse 側のアクセス権 を整理することが起点
- パターン B/C なら、Foundry 側・各データソース側・接続方式 まで含めて、誰がどのナレッジに到達できるかを一貫して設計する
特に Foundry IQ では、すべてのデータソースで自動的にユーザー単位のアクセス制御が効くわけではありません。
そのため、以下を事前に確認する必要があります。
- 対象の knowledge source が document-level permission / ACL 同期 に対応しているか
- caller の Microsoft Entra ID でクエリできる構成か
- 共有接続になりやすい API key 接続 で、機微情報を扱っていないか
「エージェントを作ってから権限を考える」のではなく、
ナレッジを選ぶ段階で、認証方式と権限制御まで一緒に決める のが鉄則です。
③ 回答根拠（引用）をどこまで出すか決める
「どの文書を参照して答えたか」を表示するかは、信頼性とユーザー体験に直結します。
- 社内問い合わせ・技術文書検索など、根拠が重要な用途では引用を出す
- 用途に応じて、引用の粒度・見せ方・文書タイトルの表示方法 をポリシーとして決めておく
- 「引用を出す前提」でナレッジを整備しておくと、運用後の信頼性が上がる
④ 運用と改善サイクルを最初から組み込む
PoC で動いても、更新ルールがなければナレッジは古くなり、やがて使われなくなります。
- ナレッジの更新担当・更新頻度 を決める
- 回答ログを振り返る仕組み を用意する（うまく答えられなかった質問の収集）
- 改善を回す担当者 を明確にする
- preview 機能を使う場合は、仕様変更時の追随担当 も決めておく
ツールの設定だけでなく、
ナレッジ設計・権限設計・業務導線・運用ルールをセットで考える ことが重要です。
まとめ
- Microsoft IQ は Work / Web / Foundry / Fabric の 4 層からなるインテリジェンス層 で、Foundry IQ と Work IQ はそのうちの別レイヤー
- 構成は要件に応じて段階的に検討する
- パターン A：Copilot Studio 標準ナレッジで完結（M365 / Power Platform 内のシンプル用途）
- パターン B：Copilot Studio ＋ Foundry IQ connector（preview）（マルチソースの大規模知識基盤）
- パターン C：Copilot Studio が Foundry IQ connector と Work IQ MCP tools を呼び分ける（共通知識＋業務文脈）
- Work IQ については、Copilot Studio で使う Work IQ MCP servers は preview だが、Work IQ API 全体は別のアクセス体系でも提供されている
- ナレッジ設計では「何を入れ／何を入れないか」を先に決め、権限設計・認証方式とセット で考える
- 回答根拠の出し方をポリシー化し、運用・改善サイクルを最初から組み込む
「Copilot Studio だけで足りるか／Foundry IQ を組み合わせるか」は、結局のところ 社内のデータ構造と要件次第 です。
構成パターンとナレッジ設計を先に描いておくことで、PoC から本番運用までの距離がぐっと縮まります。
導入を検討している方へ
「構成パターンは分かったけど、自社のデータ構造だとどれが最適か判断できない…」という方へ。
この記事を書いている私たちナレッジコミュニケーションでは、Microsoft の AI エージェント導入を支援するサービスを提供しています。
Microsoft AIエージェント導入支援サービス｜ナレッジコミュニケーション
Microsoft AI Cloud Partner Program 認定、「AI Platform on Microsoft Azure」分野の Specializations 取得、マイクロソフト ジャパン パートナー オブ ザ イヤー 2025「AI Partner Award」受賞など、Microsoft 領域での実績を重ねてきました。
PoC から本番導入までの伴走をご希望の方は、お気軽にご相談ください。
参考リンク
- What is Microsoft Foundry? | Microsoft Learn
- Microsoft IQ documentation | Microsoft Learn
- What is Foundry IQ? | Microsoft Learn
- Knowledge sources summary | Microsoft Copilot Studio | Microsoft Learn
- Connect to custom knowledge sources | Microsoft Copilot Studio | Microsoft Learn
- Azure - Foundry IQ - Connectors | Microsoft Learn
- Work IQ MCP overview (preview) | Microsoft Copilot Studio | Microsoft Learn
- Work IQ API overview | Microsoft Learn
- Microsoft AIエージェント導入支援サービス｜ナレッジコミュニケーション