Work IQ・Fabric IQ・Foundry IQ・Web IQ の違いと使い分け
Microsoft の AI 関連情報を追っていると、Work IQ、Fabric IQ、Foundry IQ、Web IQ という似た名前が登場します。どれも AI エージェントへコンテキストを渡す仕組みですが、対象とする情報は同じではありません。
この記事では、4つの概要と違いを整理したうえで、問い合わせ対応エージェントを例に「どの IQ を、どの場面で使うか」を具体化します。読み終えたときに、自分のユースケースで最初に検討すべき IQ と、組み合わせ方を判断できることがゴールです。
目次
- 先に結論
- Microsoft IQ とは
- 4つの IQ の違い
- Work IQ は仕事の文脈を扱う
- Fabric IQ は事業の状態を扱う
- Foundry IQ は組織の知識を扱う
- Web IQ は最新の公開情報を扱う
- サンプル構成：問い合わせ対応エージェント
- 利用シーンから選ぶ
- 導入前に確認したいこと
- まとめ
- 公式情報源
先に結論
4つの違いは、エージェントに渡したいコンテキストを主語にすると整理しやすくなります。
| サービス | エージェントに理解させるもの | 代表的な情報 | 向いている問い |
|---|---|---|---|
| Work IQ | 人がどのように仕事をしているか | メール、会議、チャット、ファイル、人、予定 | 「この案件で誰が何を話していたか」 |
| Fabric IQ | 事業が現在どのような状態か | 顧客、注文、在庫、設備、KPI、リアルタイムイベント | 「在庫と配送状況から何が起きているか」 |
| Foundry IQ | 組織として何を正しい知識とするか | 規程、マニュアル、FAQ、技術文書 | 「規程上どう回答すべきか。根拠はどこか」 |
| Web IQ | 組織外でいま何が起きているか | ニュース、公開 Web サイト、最新の市場・製品情報 | 「今日公開された情報では何が変わったか」 |
選び方もシンプルです。
- Microsoft 365 上のメール、会議、チャットを使いたいなら Work IQ
- OneLake や Power BI にある業務データを、共通のビジネス用語で解釈したいなら Fabric IQ
- 複数の文書やデータソースから、引用付きの回答を返したいなら Foundry IQ
- 最新の公開 Web を検索し、URL 引用付きで回答を補いたいなら Web IQ
ただし、これは4択ではありません。それぞれを組み合わせれば、組織内外のコンテキストを Agent へ渡せます。たとえば顧客対応では、Work IQ で担当者のやり取りを確認し、Fabric IQ で注文の現在地を調べ、Foundry IQ で返品規程を確認し、Web IQ で配送会社が公開した最新の障害情報を調べる、という役割分担ができます。
Microsoft IQ とは
Microsoft IQ は、Copilot や AI エージェントの応答を、組織に対する共通かつ継続的に更新される理解で根拠付けるための統合インテリジェンス層です。
2026年8月6日時点の公式ドキュメントでは、Microsoft IQ は次の4つの能力で構成されています。
| 能力 | 提供するコンテキスト |
|---|---|
| Work IQ | 人、共同作業、ワークフローを含む、従業員の仕事に関する理解 |
| Fabric IQ | 業務エンティティ、その関係、プロパティ、アクション、ルールを含む、事業の現在地 |
| Foundry IQ | ポリシー、権威ある文書、再利用できるナレッジベースを含む、組織の知識 |
| Web IQ | Web 上の新しい現実世界の情報 |
これらに共通する狙いは、汎用モデルが最初から知らない組織内外の情報やコンテキストをエージェントへ与えることです。一方で、情報を取得する場所、意味付けの方法、回答後に実行できるアクションが異なります。
4つの IQ の違い
実装を考える前に、主な違いを比較します。
| 比較軸 | Work IQ | Fabric IQ | Foundry IQ | Web IQ |
|---|---|---|---|---|
| 中心となる役割 | 職場のコンテキストと操作 | 業務データの意味と状態 | 検索可能な組織知識 | 最新の公開 Web による根拠付け |
| 主なデータ領域 | Microsoft 365 と接続された業務システム | OneLake、Power BI、リアルタイム・運用データ | Azure Blob Storage、SharePoint、OneLake、Web など | Bing が索引化した公開 Web、指定ドメイン |
| 中心となる仕組み | Chat、Context、Tools、Workspaces | セマンティックモデル、オントロジー、Graph、各種 Agent | Azure AI Search（基盤）、Knowledge Base、Knowledge Source、Agentic Retrieval | Web Search、Grounding with Bing Search |
| 得意なこと | ユーザー権限で仕事を探し、推論し、操作する | 表や列を顧客・注文などの業務概念へ引き上げる | 複雑な質問を分解し、複数ソースから引用付きで回答する | モデルの知識期限を越えた公開情報を検索し、URL を引用する |
| 代表的な利用者 | Microsoft 365 を使う従業員と、その業務を支援する Agent | データ・分析・業務運用に関わる人と Agent | Agent や RAG アプリを開発・運用するチーム | 最新の外部情報を必要とする Agent とアプリ |
| 単独利用 | 可能 | 可能 | 可能 | 可能 |
利用基盤とライセンス前提
導入時は、扱うコンテキストだけでなく、各 IQ が依存するサービスと利用経路ごとの条件も確認します。
| IQ | 利用基盤・主な前提 |
|---|---|
| Work IQ | Microsoft 365 を基盤とする。Work IQ API は Microsoft 365 Copilot ライセンスとは独立した Copilot Credits の従量課金で利用できる一方、Microsoft 365 Copilot のエクスペリエンスや一部の MCP 経由では Microsoft 365 Copilot ライセンスが必要 |
| Fabric IQ | Microsoft Fabric を基盤とする。対象 Item へアクセスできる Microsoft Fabric ライセンスに加え、機能に応じたテナント設定、ワークスペース、Capacity が必要 |
| Foundry IQ | Azure AI Search の Knowledge Base が必須。Microsoft Foundry portal から構成したり Foundry Agent Service と統合したりできるが、これらの利用は必須ではない |
| Web IQ | Microsoft Foundry Agent Service の Web grounding tools。Basic または Standard の Agent environment、対応する Azure OpenAI モデルのデプロイ、Tool の設定が必要。一般的な Web Search では追加の Bing resource は不要 |
必要なライセンス、Capacity、ロールは、利用する API、Item、Tool や提供段階によって異なります。本番導入前に、採用する経路の前提条件と料金を個別に確認してください。
境界が重なる部分もあります。たとえば SharePoint は Work IQ から「ユーザーが仕事で扱うファイル」としてアクセスでき、Foundry IQ から「ナレッジベースの知識ソース」として検索できます。
この場合の判断軸は保存場所ではなく、仕事の流れの中でユーザーの文脈と操作が必要なのか、管理された知識として複数の Agent から再利用したいのかです。
Work IQ は仕事の文脈を扱う
Work IQ は、Microsoft 365 と外部システムにまたがる組織データ、コンテキスト、ツールへ Agent がアクセスし、推論するための workplace intelligence layer です。
公式ドキュメントでは、Work IQ を次の4つの要素で説明しています。
| 要素 | 役割 |
|---|---|
| Chat | 会話の継続や Agent 間の委任を含む、対話型の知能 |
| Context | 組織データを Agent が使えるコンテキストへ組み立てる |
| Tools | Microsoft 365 のデータ取得や作成・更新などのアクション |
| Workspaces | 長時間の処理で中間データや成果物を保持する作業領域 |
A2A、MCP、REST といった標準的な方法で利用でき、メール、予定表、ファイル、人、チャット、サイトなどを扱えます。各リクエストは特定ユーザーのコンテキストで実行され、そのユーザーが見たり操作したりできる範囲に制限されます。
Work IQ が向いている場面
- 顧客とのメールと Teams 会議をまとめ、次のアクションを提案する
- 会議参加者の予定を確認し、フォローアップ会議を作成する
- 過去のチャット、ファイル、担当者情報を横断して案件の経緯を整理する
- ユーザーがアクセスできる Microsoft 365 データの範囲で Agent に仕事をさせる
実際に試した使い方：Teams 会議から宿題を整理する
私自身も、VS Code、GitHub Copilot、Work IQ を組み合わせて、参加した Teams 会議の記録から、その日の宿題やタスクを整理しています。顧客情報を含むため実際の出力は公開できませんが、処理の流れは次のとおりです。
利用者の依頼文がそのまま Work IQ へ転送されるというより、GitHub Copilot の Agent が依頼の意図を解釈し、利用可能な Work IQ MCP tool と引数を選びます。VS Code は MCP client として構造化された tool call を Work IQ MCP server へ送り、返された Microsoft 365 のコンテキストを GitHub Copilot が Markdown へ整理します。
Work IQ MCP server で利用できる tool には、Microsoft 365 Copilot へ自然言語で問い合わせる ask、Microsoft 365 entity を取得する fetch、検索などの function を呼び出す call_function などがあります。実際にどの tool が選ばれるかは依頼内容と利用できる tool によって変わるため、この図では特定の1つに固定していません。
- その日に参加した終了済みの会議を確認する
- 各会議のトランスクリプト、議事録、会議チャットなど、利用できる記録を確認する
- 会議ごとに概要、主な要点、決定・確認事項をまとめる
- 宿題を内容、担当、期限の形で抽出し、日全体の優先アクションとして集約する
- 記録がない会議や、担当・期限を特定できない項目は、推測せず「確認できない」「要確認」と明記する
この使い方では、複数の会議を順番に開いてメモを見返さなくても、その日に何が決まり、自分やチームにどのアクションが残っているかを1つの Markdown ファイルで確認できます。VS Code 上に出力することで、内容を手元でレビューし、必要な修正や追記をしてからタスク管理へ反映できる点も便利です。
一方、トランスクリプトには音声認識の誤りが含まれる可能性があります。Work IQ と GitHub Copilot が生成した結果をそのまま社外共有や正式なタスク登録に使わず、担当者、期限、固有名詞を人が確認する運用が必要です。また、記録が存在しない会議について、会議名だけから議論内容を推測させないことも重要です。
ポイントは、単なる文書検索だけでなく、誰の仕事かという文脈を保ちながら、取得からアクションまでつなげられることです。
Fabric IQ は事業の状態を扱う
Fabric IQ は、OneLake 上の分析・リアルタイム・運用データを統合し、それを事業の言葉で解釈できるようにする Microsoft Fabric の能力です。
データベースに customer_id や shipment_status という列があっても、それだけでは Agent が「顧客が注文し、その商品が配送され、遅延が売上へ影響する」という業務上のつながりを一貫して理解できるとは限りません。
Fabric IQ では、Power BI セマンティックモデルやオントロジーを使って、次のような概念を定義・再利用します。
- エンティティ：顧客、注文、商品、店舗、配送
- プロパティ：注文金額、在庫数、配送状態
- 関係：顧客が注文する、注文に商品が含まれる、店舗が在庫を持つ
- ルールとアクション：在庫がしきい値を下回ったら補充を提案する
Fabric IQ の基盤は OneLake です。Power BI セマンティックモデルによる信頼済み KPI、オントロジーによる共通の業務語彙、関係をたどる Graph、自然言語で分析する Data Agent、リアルタイムの状態を監視する Operations Agent などを組み合わせます。
架空の販売・配送・経理システムで考える
Fabric IQ を具体的に理解するため、Web 販売を行う企業に、販売部、配送部、経理部の3つの業務システムがあるケースを考えました。各システムは独立した Azure SQL Database を使い、受注、配送手配、入金確認などの基幹処理は引き続き既存システムが担当します。
確認したいのは、個々のシステムを置き換えることではなく、次のような部門横断の問いです。
- 注文番号
ORD-12345は、現在どの部門で処理中か - 在庫確認済みだが、配送手配されていない注文はあるか
- 配送手配済みだが、到着予定日が未登録の注文はあるか
- 発送済みだが、未入金の注文はあるか
- 一定時間以上、処理が進んでいない注文はあるか
このケースでは、次の順番でデータへ意味を与えます。
- 3つの Azure SQL Database を Fabric Mirroring で OneLake へ継続的に複製する
- 共通の Order ID、または各システムの ID を対応付けるマッピングテーブルを使い、注文単位の統合ビューや統合テーブルを作る
- Ontology で
Customer、Order、InventoryAllocation、Shipment、Paymentなどの業務概念と関係を定義する - 利用者や Agent が、物理的なテーブル名ではなく「注文」「配送」「入金」という業務用語で状態を確認する
Mirroring では、Azure SQL Database 自体やデータベースファイルを OneLake へ移すわけではありません。元データを分析向けの Parquet / Delta Table として複製し、読み取り専用の SQL analytics endpoint を自動生成します。元の Azure SQL Database はトランザクション処理を続け、OneLake 側を横断的な検索、分析、監視に利用します。
ただし、Mirroring しただけでは3つの業務テーブルが並ぶだけです。注文の現在地を一貫して判断するには、共通の Order ID を各システムへ引き継ぐか、販売・配送・経理の ID 対応表を管理する必要があります。氏名、金額、注文時刻などを使った後付けの推測結合は、誤判定につながるため避けます。
Ontology では、たとえば「Customer が Order を作成する」「Order に Shipment と Payment が関連する」という意味を定義し、実際の OneLake 上のデータへバインドします。これにより、同じ業務用語と関係を Power BI、Agent、監視処理で再利用できます。
問い方によって入口を変える
同じ統合データを使う場合でも、利用目的によって適した入口は異なります。
| やりたいこと | 適した方式 | 理由 |
|---|---|---|
| 注文番号を指定し、決まった項目を返す | SQL analytics endpoint | 固定形式の参照を T-SQL で明示できる |
| 「配送待ちの注文を教えて」のように質問する | Fabric Data Agent | SQL、DAX、KQL などを生成し、自然言語で読み取り専用の回答を返す |
| 処理が一定時間止まった注文を継続監視する | Operations Agent | ルールを定期評価し、Teams 通知や承認付きアクションへつなげる |
| 複数部門の概念と関係を共通化する | Fabric IQ Ontology | データを業務用語と関係へ引き上げ、各体験から再利用できる |
Fabric Data Agent は custom app を含む外部の Agent からも利用できますが、データアクセスは読み取り専用です。受注変更や配送手配などの更新は、Fabric から元データベースを直接書き換えるのではなく、既存システムの正式な API やワークフローへ渡します。
また、2026年8月6日時点の Fabric Data Agent は非英語の質問、指示、例示をサポートしていません。日本語の Bot を作る場合は、Agent 間で英語へ変換する設計や、回答品質の検証が別途必要です。
この構成でも残る設計課題
- データの鮮度：3つの Mirroring は同時に完了するとは限らないため、各システムの最終更新日時を回答へ含める
- 現在地の判定：「在庫確認済み、配送未登録なら配送連携待ち」などの業務ルールを明示する
- 権限制御：顧客個人情報や決済情報を必要以上に Ontology や Agent へ公開せず、ユーザー権限、RLS、CLS、Purview policy を適用する
- 責任分界：Fabric は横断分析、検索、可視化、監視を担当し、基幹処理の更新は既存システムへ戻す
この例で理解しやすかったのは、Fabric IQ が単なる「複数データベース検索 API」ではないことです。Mirroring と統合処理でデータを利用可能にし、その上に Ontology で業務上の意味と関係を与えることで、初めて人や Agent が「この注文はいま入金待ち」と事業の状態として解釈できます。
Fabric IQ が向いている場面
- 「顧客」「注文」「配送」などの定義を、レポートと Agent で共通化する
- 複数部門のデータをまたいで、遅延や障害の影響範囲を分析する
- 売上、在庫、設備などのリアルタイムデータを監視し、対応を提案する
- Power BI で定義済みの指標や階層を Agent から利用する
2026年8月6日時点では、Fabric Data Agent と Operations Agent は GA ですが、Fabric IQ の IQ workload と Ontology などには preview の機能が含まれます。実運用へ採用する前に、利用する各 Item の提供状況を個別に確認する必要があります。
Foundry IQ は組織の知識を扱う
Foundry IQ は、複数の Knowledge Source を Knowledge Base にまとめ、Agent が組織固有の情報を権限に応じて検索できる managed knowledge layer です。Azure AI Search の代替サービスではなく、Azure AI Search を基盤として、その検索機能を Agent 向けの再利用可能な知識として扱いやすくするレイヤーです。
主な構成要素は次の3つです。
| 構成要素 | 役割 |
|---|---|
| Knowledge Source | インデックス化されたコンテンツやリモートコンテンツへの接続 |
| Knowledge Base | 検索する Knowledge Source と検索時のパラメーターをまとめる最上位リソース |
| Agentic Retrieval | 質問の分解、並列検索、セマンティックリランキング、回答の統合 |
Foundry IQ は、インデックス化される Knowledge Source の文書について、チャンク分割、ベクトル埋め込み、メタデータ抽出を自動化し、定期的な indexer 実行による増分更新を構成できます。また、インデックス化された Knowledge Source とリモート Knowledge Source に対して、キーワード・ベクトル・ハイブリッド検索を実行できます。検索結果には引用を含められるため、Agent の回答を元文書までたどれます。
1つの Knowledge Base を複数の Agent から共有できる点も重要です。規程検索をする Agent ごとに個別の RAG パイプラインを構築するのではなく、管理された知識層として再利用できます。
Azure AI Search から置き換えるものではない
Foundry IQ の導入は、Azure AI Search を別サービスへ置き換える移行ではありません。Foundry IQ の Knowledge Base と Agentic Retrieval は Azure AI Search 上に作成され、Azure AI Search がインデックス作成と検索の基盤を引き続き担当します。
既存の Azure AI Search index が Agentic Retrieval の要件を満たしていれば、そのテキストやベクトルを Search Index Knowledge Source として再利用できます。したがって、構成は次のように考えると理解しやすくなります。
Foundry Agent / Custom App
↓
Foundry IQ Knowledge Base
├─ Knowledge Source A
├─ Knowledge Source B
└─ Knowledge Source C
↓
Azure AI SearchFoundry IQ を追加するメリットは、検索エンジンを変更することではなく、これまで Agent や RAG アプリごとに実装していた検索のオーケストレーションを Knowledge Base 側へ寄せられることです。
- 複雑な質問を複数の subquery へ分解し、並列に検索する
- 質問内容に応じて、複数の Knowledge Source から検索先を選ぶ
- 検索結果をセマンティックリランキングし、統合して Agent へ返す
- 同じ Knowledge Base を複数の Agent や custom app から再利用する
- 引用や検索過程を含む、Agent が利用しやすい形式で結果を受け取る
たとえば「有給休暇の申請条件と、海外勤務者だけに適用される例外を教えて」という質問では、人事規程と海外勤務規程を別々に検索し、その結果を統合する必要があります。Azure AI Search の従来型の単一 query でもアプリ側に処理を実装すれば対応できますが、Foundry IQ の Agentic Retrieval は質問の分解、検索先の選択、結果の統合を Knowledge Base の検索フローとして扱えます。
一方、すべての検索を Foundry IQ へ変更する必要はありません。
| 要件 | 適した方式 | 理由 |
|---|---|---|
| 商品番号や文書 ID を指定する単純な検索 | Azure AI Search を直接利用 | 単一 query で十分で、低遅延かつ構成が単純 |
| query、filter、ranking を細かく制御する | Azure AI Search を直接利用 | 既存の検索パイプラインと制御を維持できる |
| 会話の文脈を含む複雑な質問 | Foundry IQ | 質問の分解と複数回の検索を利用できる |
| 複数の index や情報源を横断する | Foundry IQ | Knowledge Source の選択と結果統合を共通化できる |
| 同じ組織知識を複数の Agent で共有する | Foundry IQ | Knowledge Base を共通の検索 endpoint として再利用できる |
Agentic Retrieval は LLM による query planning と複数の検索を行うため、従来の単一 query より遅延が増えます。利用する構成によっては、Azure AI Search の retrieval token に加えて Azure OpenAI の input / output token も課金されます。まず既存の Azure AI Search index を Knowledge Source として接続し、同じ評価用質問で回答品質、引用、応答時間、コストを比較してから適用範囲を決めるのが現実的です。
Foundry IQ が向いている場面
- 社内規程、製品マニュアル、FAQ を横断し、引用付きで回答する
- SharePoint、Blob Storage、OneLake、Web など複数の情報源をまとめる
- 複雑な質問を複数の検索へ分解し、結果を統合する
- 共通の Knowledge Base を複数の Agent やカスタムアプリから利用する
2026年8月6日時点では、Foundry IQ は一般提供済みの機能とプレビュー機能が混在し、利用する Azure AI Search の REST API version によって提供状況が異なります。また、Microsoft Foundry portal と Azure portal から利用する Agentic Retrieval の機能はプレビュー扱いです。
Web IQ は最新の公開情報を扱う
Microsoft IQ の公式ドキュメントでは、Web IQ は AI システムと Agent に、Web 全体から新しい現実世界の情報を提供する能力と説明されています。
実装では、Microsoft Foundry Agent Service の Web grounding tools を使います。Agent が不足している情報を判断して検索クエリを作り、Bing から結果を取得し、その内容を回答へ統合して参照元 URL を示します。
主な選択肢は次のとおりです。
| Tool | 特徴 | 2026年8月6日時点の提供状況 |
|---|---|---|
| Web Search | Microsoft が Bing resource を管理する、最も始めやすい選択肢 | GA |
| Grounding with Bing Search | 自分で Bing resource を作成し、件数、鮮度、市場、言語などを指定できる | GA |
| Bing Custom Search を使うドメイン制限 | 許可・拒否するドメインを事前定義して検索範囲を制御する | Web Search からの利用は GA、Grounding with Bing Custom Search は preview |
Web IQ が向いている場面
- 今日のニュースや市場動向など、モデルの知識期限より新しい情報を調べる
- 配送会社、メーカー、行政機関が公開した最新情報を確認する
- 競合製品の公開ページを比較し、参照元 URL とともに回答する
- 許可した公式ドメインに絞って、外部情報を検索する
Foundry IQ との違い
Foundry IQ も public Web を Knowledge Source にできますが、中心となる考え方は、複数の情報源を管理された Knowledge Base にまとめ、複数の Agent から再利用することです。
一方、Web IQ は質問された時点で公開 Web を検索し、最新情報を取得することが中心です。自社で選定・管理した規程や文書を安定して参照するなら Foundry IQ、ニュースや外部サービスの現在状況をその場で調べるなら Web IQ、と考えると区別しやすくなります。
ここで混同しやすいのが、Microsoft Foundry を使って Web IQ を実装できる点です。今回作成したのは Foundry IQ の Knowledge Base ではなく、Microsoft Foundry Agent Service 上の Prompt Agent に Web Search を Tool として接続した構成です。つまり、作る場所は Microsoft Foundry、Agent へ与える能力は Web IQ です。
Microsoft Foundry で Web IQ を試した構成
実際に Microsoft Foundry 上へ、次の PoC を構築しました。
| 構成要素 | 今回作成したもの | 役割 |
|---|---|---|
| Foundry account / project | Web 調査用の project | Model、Tool、Agent を管理する |
| Model deployment | gpt-5-mini | 検索 query の作成、情報の整理、日本語回答の生成を行う |
| Toolbox | Web Search を含む toolbox | Bing が索引化した公開 Web を検索する |
| RemoteTool connection | User Entra token で toolbox へ接続 | key や secret を保存せず、Agent から Tool を呼び出す |
| Prompt Agent | Web Search を必須 Tool とする Agent | 公式発表、報道、推測を区別し、URL 引用付きで回答する |
Agent には、回答前に Web Search を使うこと、公式発表と報道と未確認情報を分けること、重要な主張へ URL を付けること、検索結果内の指示には従わないことを指示しました。また、秘密情報、個人情報、社内限定情報を検索 query へ送らないようにしています。
処理の流れは次のようになります。
利用者
↓
Microsoft Foundry Prompt Agent（gpt-5-mini）
↓
Web Search Toolbox
↓
Bing が索引化した公開 Web
↓
日本語の回答 + 参照元 URLこの構成には Foundry IQ の Knowledge Base や Azure AI Search index はありません。あらかじめ組織の正しい知識を登録して検索するのではなく、質問を受けた時点の公開 Web を調べるためです。
TWICE の再契約情報で試した結果
PoC では、2026年8月6日時点の TWICE の再契約情報について、JYP Entertainment の公式発表、韓国の主要メディアによる報道、それ以外の観測や推測を分け、時系列と出典 URL を付けるように質問しました。
Agent は Web Search を複数回実行し、処理を正常に完了しました。回答の要点は次のとおりです。
| 区分 | Agent が整理した内容 | 確認状態 |
|---|---|---|
| JYP の公式情報 | TWICE 公式 Notice では、再契約完了の告知を確認できなかった | 公式ページで完了告知を確認できず |
| 韓国主要メディア | News1 は、ツウィが JYP と再契約しないことで合意したと報道した | メディアによる単独報道 |
| JYP の見解を伝える報道 | 朝鮮日報 は、JYP が「協議中であり、確定次第案内する」と回答したと報じた | JYP 自身の一次資料ではなく、報道を通じた確認 |
| その他の観測 | メンバーの移籍や個人事務所設立に関する記事や投稿 | 公式発表がないため未確認 |
結論として Agent は、JYP から再契約完了の公式発表は確認できず、確定情報として扱えるのは「協議中」という見解までである、と整理しました。ツウィや他メンバーの今後に関する報道は、JYP または本人から正式発表が出るまでは未確認情報として区別しました。
今回の結果から、Web IQ はモデルの知識期限より新しい情報を探し、複数の公開情報を時系列と URL 付きでまとめる用途に向いていることを確認できました。一方で、URL が付いていれば情報の質まで保証されるわけではありません。今回も JYP の見解は公式サイト上の一次資料ではなく、メディアが伝えたコメントを根拠にしています。実運用では、公式ドメインの一次資料、主要メディア、まとめサイトや個人ブログの順に情報源を評価し、一次資料を確認できない場合はその事実自体を明記する必要があります。
Web grounding tools は public endpoint として動作し、VPN や private endpoint の境界には従いません。また、検索へ送信したデータは Azure compliance boundary と Geo boundary の外へ流れます。内部情報をそのまま検索クエリへ含めず、利用規約、データ境界、管理者による利用制限を確認したうえで採用する必要があります。
サンプル構成：問い合わせ対応エージェント
小売企業の問い合わせ対応 Agent を例にします。利用者から、次の質問が来たとします。
昨日相談した注文がまだ届いていません。いまどこにあり、キャンセルできるか教えてください。
この質問に正確に答えるには、1種類の情報だけでは足りません。
| 手順 | 必要なコンテキスト | 利用する IQ | Agent が行うこと |
|---|---|---|---|
| 1 | 昨日の相談内容、顧客とのメール、担当者 | Work IQ | ユーザーが参照できるメールや会議から対象注文と経緯を特定する |
| 2 | 注文、在庫、配送の現在状態 | Fabric IQ | 顧客・注文・配送の関係をたどり、配送状況と遅延の影響を確認する |
| 3 | キャンセル規程、返品条件、例外 | Foundry IQ | Knowledge Base から適用条件を検索し、根拠文書の引用を返す |
| 4 | 配送会社が公開した障害・遅延情報 | Web IQ | 現在の公開情報を検索し、参照元 URL とともに状況を補足する |
| 5 | 回答、連絡、後続作業 | Work IQ | 回答案を作り、必要に応じてメール送信やフォローアップを行う |
論理構成にすると、次のようになります。
利用者
↓
問い合わせ対応 Agent
├─ Work IQ ─ メール、会議、担当者、予定、アクション
├─ Fabric IQ ─ 顧客、注文、在庫、配送、リアルタイム状態
├─ Foundry IQ ─ キャンセル規程、返品条件、製品マニュアル、引用
└─ Web IQ ─ 配送障害、最新ニュース、外部サービスの公開情報この構成で大切なのは、4つの IQ が同じ情報を重複して持つのではなく、それぞれが得意なコンテキストを Agent へ渡すことです。Agent は質問に応じて必要な能力を呼び分け、最終回答を組み立てます。
小さく始めるなら
最初から4つすべてを導入する必要はありません。
- まず、最も価値が高くデータ準備ができている1領域を選ぶ
- その領域だけで回答品質と権限制御を検証する
- 足りないコンテキストを確認して、次の IQ を追加する
たとえば返品規程への問い合わせが多いなら Foundry IQ から始めます。配送状況の問い合わせが中心で、Fabric に注文と配送データがそろっているなら Fabric IQ が先です。担当者のメールや会議を起点に案件を整理したいなら Work IQ、外部の最新情報が必要なら Web IQ から始めます。
利用シーンから選ぶ
| やりたいこと | 最初に検討するもの | 理由 |
|---|---|---|
| 自分のメールと会議から今日の優先事項をまとめる | Work IQ | 個人の仕事の文脈と Microsoft 365 の操作が中心だから |
| 会議内容を確認して、次回の予定を作る | Work IQ | コンテキスト取得と予定表へのアクションをつなげるから |
| 在庫不足の原因を店舗・商品・配送の関係から調べる | Fabric IQ | 業務エンティティの関係と現在状態を扱うから |
| 設備データを監視し、異常時の対応を提案する | Fabric IQ | リアルタイムデータと業務ルールを扱うから |
| 社内規程を横断検索し、根拠リンク付きで回答する | Foundry IQ | 管理された Knowledge Base と引用が必要だから |
| 複数製品のマニュアルを共通のサポート Agent で使う | Foundry IQ | 複数 Knowledge Source を再利用可能な知識層へまとめるから |
| 今日発表されたニュースや市場情報を調べる | Web IQ | モデルの知識期限より新しい公開情報が必要だから |
| 公式サイトの障害・リコール情報を URL 付きで確認する | Web IQ | 外部の現在状況と参照元が必要だから |
| 顧客案件の経緯、現在状態、適用規程、外部状況をまとめて回答する | 4つを組み合わせる | 仕事、事業データ、組織知識、最新の公開情報が必要だから |
データの保存先だけで決めないことも大切です。SharePoint 文書を扱う場合でも、個人の仕事の流れで読み書きするなら Work IQ、組織の権威ある知識として索引化し複数 Agent で共有するなら Foundry IQ、というように目的から判断します。
導入前に確認したいこと
1. どの情報を正とするか
Agent を作る前に、メール、業務データ、規程のどれを正とするかを決めます。Fabric IQ のオントロジーや Foundry IQ の Knowledge Base を用意しても、元データの所有者や更新責任が不明確なら、回答品質は安定しません。
2. 誰の権限でアクセスするか
接続方法、実行主体、データが流れる境界は IQ ごとに異なります。特に Work IQ はユーザー単位の仕事の文脈を扱います。一方、Web IQ の Web grounding tools は public endpoint であり、検索データは Azure compliance boundary 外へ流れます。PoC で動かして終わりにせず、本番で誰が何を参照でき、どのデータを外部検索へ送ってよいかを確認します。
3. 回答の根拠をどう検証するか
Foundry IQ の引用、Fabric IQ のセマンティックモデルとオントロジー、Work IQ の監査ログ、Web IQ の参照元 URL など、回答やアクションを追跡できる設計にします。Agent の文章が自然かどうかだけでなく、元情報、権限、鮮度、再現性を評価します。
4. プレビュー機能をどこまで許容するか
2026年8月6日時点では、Fabric IQ と Foundry IQ の一部、および接続方法の一部にプレビュー機能があります。Web IQ でも一般 Web Search は GA ですが、Grounding with Bing Custom Search は preview です。プレビューは SLA や機能が制限される場合があるため、公式ドキュメントで利用する Item、Tool、API version の状態を確認し、本番要件に合うか判断します。
まとめ
Work IQ、Fabric IQ、Foundry IQ、Web IQ は似た名前ですが、Agent に与えるコンテキストが異なります。
- Work IQ は、人、メール、会議、チャット、ファイルなど「仕事の文脈」を扱う
- Fabric IQ は、顧客、注文、設備、KPI など「事業の状態と意味」を扱う
- Foundry IQ は、規程、マニュアル、FAQ など「再利用できる組織知識」を扱う
- Web IQ は、ニュース、公開サイト、外部サービスなど「最新の公開情報」を扱う
まずは「Agent が答えるために不足しているのは、仕事の経緯、業務データの意味、権威ある知識、最新の公開情報のどれか」を確認します。1つで足りなければ、役割を重複させずに組み合わせます。
IQ という名称から製品を選ぶのではなく、必要なコンテキストの種類から選ぶことが、設計の出発点です。
公式情報源
- Microsoft IQ documentation
- Work IQ overview
- Work IQ API overview
- What is Fabric IQ?
- Understand Microsoft Fabric licenses
- What is ontology (preview)?
- Mirroring Azure SQL Database
- Fabric data agent concepts
- Create and configure operations agents
- What is Foundry IQ?
- Foundry IQ frequently asked questions
- Web grounding tools overview