Work IQ API と MCP で Microsoft 365 Copilot はどう拡張されるか

はじめに

Microsoft 365 Copilot 周辺の拡張ポイントとして、Work IQ API / MCP / REST / A2A という言葉が並び始めています。

この記事では、2026年6月7日時点で確認できる Microsoft 公式情報をもとに、開発者・情シス向けに次の観点を整理します。

• Work IQ API は Microsoft 365 Copilot をどう拡張するのか
• A2A / MCP / REST はどう使い分けるのか
• 権限継承・監査・テナント境界をどう考えるべきか

なお、Work IQ API 関連の情報はプレビュー段階のものを含みます。Microsoft のブログでは Work IQ APIs の一般提供は 2026年6月16日予定と説明されています。一方で、Microsoft Learn の個別ドキュメントでは、2026年6月7日時点で preview と明記されているページがあります。この記事では「ブログでは GA 予定が告知されているが、個別機能の実装ドキュメントは現時点で preview 表記が残っている」という前提で整理します。

特に、プロトコルごとの提供状況（後述）と課金条件（後述）は、ブログ・Developer Blog・各 overview ページで表記の前提が異なります。読む時期や参照ページで状況が変わるため、断定的な記述は避けています。実装する場合、特に 2026年6月16日以降に読む場合は、必ず最新の公式ドキュメントを確認してください。

Work IQ とは何か

Work IQ は、Microsoft 365 Copilot とエージェントの背後にある「職場コンテキストの理解レイヤー」と捉えると理解しやすいです。

従来の API 利用では、メール、予定表、Teams メッセージ、SharePoint ファイル、OneDrive、外部業務データなどを個別に取得し、アプリ側で検索・要約・権限制御・プロンプト組み立てを作り込む必要がありました。

Work IQ はその一部を Microsoft 365 側のランタイムに寄せます。公式ドキュメントでは、Microsoft 365 データ、組織システム、外部ソースをまたいで、セマンティックな理解を継続的に構築し、既存の権限やポリシーを尊重しながらエージェントが利用できるようにするものとして説明されています。

要するに、Work IQ API は「Microsoft 365 のデータを単に取る API」というより、Copilot を支えている文脈理解・検索・推論・ツール呼び出しといった仕組みの一部を、外部のアプリやエージェントからも使えるようにする入口、と捉えると整理しやすいです。

Copilot 拡張の見取り図

ざっくり整理すると、Microsoft 365 Copilot の拡張は次のように分けられます。

ポイントは、外部アプリやエージェントが直接すべてのデータソースを抱え込むのではなく、Work IQ を通して Microsoft 365 のコンテキストを利用する構図になることです。

Microsoft は Work IQ API のプロトコルとして、A2A、MCP、REST を挙げています。つまり「1つの API 形式に統一する」というより、エージェントやアプリの形に応じて入口を選ぶ設計です。

また、Work IQ API は Chat、Context、Tools、Workspaces というドメインでも説明されています。Chat / Context は Copilot 的な会話や grounding に関わり、Tools は Microsoft 365 エンティティやアクションへのアクセス、Workspaces はエージェントが処理中の状態や中間成果物を Microsoft 365 テナント境界内で扱うための領域です。プロトコル軸とドメイン軸を分けて見ると、設計判断がしやすくなります。

A2A / MCP / REST の使い分け

現時点での理解では、3つの入口は次のように使い分けると整理しやすいです。

方式	向いている用途	見るべき論点
A2A	エージェント同士の連携、Copilot 側エージェントとの対話	どのエージェントを呼ぶか、ヘッドレス実行で有効な応答が得られるか
MCP	IDE、CLI、エージェント基盤から Microsoft 365 の文脈やツールを使う	ツール定義、認証、管理者同意、テナントポリシー
REST	独自アプリから Copilot の応答をプログラム的に利用する	テキスト応答中心、検索 grounding、長時間処理やアクション非対応などの制約

A2A: エージェント同士をつなぐ

A2A は Agent-to-Agent の略で、エージェント同士の会話やタスク委譲を扱う入口です。

たとえば、社内ポータルのエージェントが Microsoft 365 側のエージェントに「このユーザーの今週の会議文脈を踏まえて回答してほしい」と依頼するような構成も考えられます。

ただし、公式クイックスタートでは、Word / Excel / PowerPoint など一部の Microsoft 365 エージェントは Office 製品の文脈で動くよう設計されており、ヘッドレスに A2A で呼び出しても有用な応答を返さない場合があると説明されています。つまり、A2A は万能なリモート実行 API ではなく、「エージェントの設計意図」とセットで考える必要があります。

MCP: ツールと文脈をエージェントに渡す

MCP は Model Context Protocol の略で、AI エージェントが外部ツールやデータソースを扱うためのプロトコルです。

Work IQ MCP は、Microsoft 365 intelligence を MCP サーバーとして公開するものです。公式ドキュメントでは、読み取り、作成、更新、削除、アクション実行、Copilot 呼び出し、スキーマ発見などを、10個の汎用ツールで扱う設計が説明されています。

ここで重要なのは、「ツール数を増やす」のではなく「パスとスキーマを実行時に発見する」考え方です。たとえば、メールを読む、予定を作る、Teams メッセージを取得する、といった操作を個別の大量ツールとして持つのではなく、fetch や create_entity のような汎用ツールとリソースパスの組み合わせで扱います。

開発者にとっては、IDE や CLI の AI アシスタントが、SharePoint の仕様書、Teams 会議の議事録、過去メールなどを参照しながらコード生成や調査を進める用途が見えてきます。

なお、MCP には Local MCP と Remote MCP の形態があります。Local MCP は Work IQ CLI をローカルの MCP サーバーとして動かし、IDE や CLI の AI アシスタントから使う形です。Remote MCP はリモートの Work IQ MCP エンドポイントを使う形です。

提供状況については、参照する時期とページで表記が変わるため、断定は避けたほうが安全です。整理すると次のようになります。

• 2026年6月7日に確認した時点の API overview（preview）では、プロトコル選択の表で coming soon が付いているのは REST のみで、A2A・Local MCP・Remote MCP は preview で参照できる状態として整理されています。
• Microsoft 365 Developer Blog では、6月16日の GA で A2A・刷新された Remote MCP サーバー・REST が提供されると説明されています。
• 4〜5月の公開プレビュー告知時点では、REST と Remote MCP が「coming soon」扱いでした。

つまり「いつ・どのページを見たか」で状況が異なります。実装前には必ず最新の公式ドキュメントで提供状況を確認してください。

情シスにとっては、MCP サーバーをどのテナントで許可するか、どのユーザー・グループに使わせるか、管理者同意をどう扱うかが論点になります。

REST: 独自アプリに Copilot 応答を組み込む

補足: REST API は、上記のとおり API overview の現行ページ（2026年6月7日に確認した時点）では「coming soon」と表記されています。以下は公開されている REST overview（preview）の内容に基づく整理であり、実際の利用可否は時期により変わります。

Work IQ REST API は、独自アプリから Microsoft 365 Copilot との複数ターン会話をプログラム的に行う入口です。

公式ドキュメントでは、エンタープライズ検索 grounding と Web 検索 grounding を使い、Microsoft 365 の信頼境界内で回答を返すと説明されています。これにより、独自にベクトル DB、検索基盤、オーケストレーション層を作る負担を下げられる可能性があります。

一方で、REST API には制約もあります。公開情報では、ファイル作成、メール送信、会議作成のようなアクションやコンテンツ生成スキルはサポートされない、テキスト応答のみ、長時間タスクはタイムアウトしやすい、といった制限が示されています。

したがって REST は、まずは「業務アプリに Copilot 的な回答を組み込む」用途に向いています。実行系の操作まで任せたい場合は、MCP や Copilot Studio のアクション、Power Platform コネクタなども含めて設計する必要があります。

権限継承の論点

Work IQ API の実務上の最大論点は、機能そのものよりも「誰の権限で何が見えるのか」です。

公式ドキュメントでは、Work IQ は Microsoft Entra ID の delegated authentication を使い、リクエストはサインインユーザーの文脈で実行されると説明されています。On-behalf-of flow はサポートされますが、application-only authentication はサポートされないとされています。

これはかなり重要です。

アプリケーション権限で「バックエンドが何でも読める」方式ではなく、基本的にはユーザーが Microsoft 365 上でアクセスできる範囲に沿って Work IQ が応答する、という考え方になります。Microsoft 365 の権限、秘密度ラベル、コンプライアンスポリシーも自動的に適用されるとされています。

開発者視点では、次のような設計判断になります。

• 独自アプリ側で二重に ACL を再実装しない
• ただしアプリ固有の認可は別途設計する
• OBO flow を使う場合、ユーザー文脈がどこで失われるかを確認する
• ログにはプロンプトや回答の機微情報を安易に残さない

情シス視点では、次のような確認が必要です。

• 管理者同意が必要なアプリ・MCP サーバーを把握する
• 利用可能なユーザー・グループを制御する
• 監査ログや利用状況を確認できる運用を作る
• SharePoint / OneDrive / Teams の既存権限が過剰でないかを棚卸しする
• 秘密度ラベルや DLP ポリシーが現実の業務データに適用されているか確認する

ここでありがちな誤解は、「Copilot や Work IQ を入れると新しい情報漏えい経路が突然生まれる」というより、「既存の権限設計の甘さが AI によって見えやすくなる」という点です。

AI エージェントは、人間より速く、横断的に、自然言語で情報を探せます。だからこそ、既存のアクセス権が広すぎる場合、その影響が体感しやすくなります。

Copilot connectors との関係

外部データを Microsoft 365 Copilot に入れる方法としては、Copilot connectors も重要です。

公式ドキュメントでは、Copilot connectors は大きく synced connectors と federated connectors に分けられています。

synced connectors は、外部データを Microsoft Graph にインデックスして、Copilot や Microsoft Search から検索可能にします。各アイテムに ACL を持たせ、ユーザーがソースシステムでアクセスできるものだけを表示する仕組みです。

federated connectors は、MCP を使ってリアルタイムに外部データを取得します。インデックスせず、データをソース側に残したまま扱えるため、ライブ性が高いデータや、Microsoft 365 側に取り込みたくないデータに向いています。ただし、公開情報では federated connectors は read-only と説明されています。

整理すると、外部データ活用は次のように考えられます。

やりたいこと	候補
外部ナレッジを Copilot Search / Copilot Chat で検索対象にしたい	synced connector
インデックスせずリアルタイム参照したい	federated connector / MCP
独自アプリから Copilot 的な回答を得たい	Work IQ REST API
AI エージェントに Microsoft 365 のツール操作をさせたい	Work IQ MCP / Copilot Studio actions

開発者向けの設計メモ

開発者が最初に考えるべきことは、「自分のアプリが AI の頭脳を作るのか、Microsoft 365 Copilot の文脈理解を借りるのか」です。

独自の RAG を作る場合、データ取り込み、差分同期、ACL、検索、再ランキング、プロンプト構築、監査、削除反映などを自前で扱います。これは自由度が高い一方、Microsoft 365 データを安全に扱うには実装・運用コストが大きくなります。

Work IQ API を使う場合、Microsoft 365 側の semantic index、Copilot の grounding、既存権限、テナント境界を活用できます。そのかわり、提供される API の制約、プレビュー段階の変更、ライセンスや課金などの商用条件を受け入れる必要があります。

課金まわりは「どのレイヤーの話か」を分けて読む

課金については、参照するドキュメントによって前提が異なるため、混同しないよう注意が必要です。

• Microsoft 365 ブログや Developer Blog では、Work IQ API 全体を Copilot Credits 建ての従量課金（GA 後の姿）として説明しています。Tools は固定要素、Chat / Context は変動要素を持つとされ、Microsoft 365 管理センターには Copilot Credits の利用状況、課金方式（前払い / 従量）、支出制限、ユーザーやグループ単位の管理に関するダッシュボードが追加される予定です。
• 一方で、REST API overview（preview）の Licensing には、Microsoft 365 Copilot アドオンライセンスを持つユーザーは REST API を追加費用なしで利用でき、ライセンスを持たないユーザー向けの提供は現時点では未対応、と書かれています。

この2つは「全体の従量課金モデル（GA 想定）」と「現在の REST のプレビュー時点でのライセンス条件」という別レイヤーの話で、前提が違います。どちらか片方だけを見て「追加費用なし」または「すべて従量課金」と断定すると誤解しやすい部分です。

コスト試算をする際は、対象プロトコル（REST / MCP / A2A）、preview か GA か、対象ユーザーの Copilot ライセンス有無を分けたうえで、最新ドキュメントで確認するのが安全です。情シス側では、技術検証と同時に利用量管理の設計も見ておく必要があります。

現実的な段階導入

現実的には、次のような段階導入がよさそうです。

1. REST API（提供状況を確認のうえ）で、社内アプリに「Microsoft 365 文脈つきの回答」を組み込む
2. IDE / CLI 向けに Work IQ MCP を試し、開発者体験を検証する
3. 業務エージェントで必要な操作を MCP / Copilot Studio actions / Power Platform connector に分解する
4. 外部データは synced connector と federated connector を使い分ける
5. 権限、監査、DLP、秘密度ラベルの棚卸しを並行して進める

情シス向けの確認リスト

情シス側では、技術検証と同じくらいガバナンス設計が重要です。

• Microsoft 365 Copilot ライセンスの有無
• Work IQ API / MCP 利用に必要な管理者同意
• 利用対象ユーザー・グループ
• Copilot Credits、支出制限、利用量管理の方針
• SharePoint / OneDrive / Teams のアクセス権棚卸し
• 秘密度ラベル、DLP、保持ポリシーの適用状況
• ログ、監査、インシデント対応の流れ
• 外部 MCP サーバーやカスタムコネクタの審査基準

特に MCP は便利な一方で、AI エージェントに「使えるツール」を渡す仕組みです。人間向け SaaS 連携と同じ感覚で許可すると、権限、操作、監査の整理が追いつかない可能性があります。

「どのエージェントに、どのツールを、誰の権限で、どのデータ範囲に対して使わせるか」を明文化することが、導入前の実務ポイントになります。

まとめ

Work IQ API は、Microsoft 365 Copilot の文脈理解を外部アプリやエージェントから使いやすくするための API 群です。

A2A はエージェント同士の連携、MCP はエージェントや IDE / CLI にツールと文脈を渡す入口、REST は独自アプリから Copilot 的な回答を得る入口、と整理すると見通しがよくなります。ただし各プロトコルの提供状況は preview と GA の境目で動いているため、断定せず最新ドキュメントで確認するのが前提です。

そして、実務で一番大事なのはプロトコル選択だけではありません。Work IQ は delegated authentication を前提に、既存の Microsoft 365 権限やコンプライアンスポリシーを尊重する設計です。つまり、導入の成否は API 実装だけでなく、既存の情報設計、アクセス権、監査、DLP の成熟度にも左右されます。

まずは小さなユースケースで REST や MCP を試しつつ、並行して Microsoft 365 側の権限棚卸しを進めるのが、開発者・情シス双方にとって現実的な第一歩だと思います。

参考情報

• Microsoft Work IQ API overview
• Work IQ overview
• Announcing the new Work IQ APIs（Microsoft 365 Blog）
• Work IQ: Production-ready intelligence for every agent（Microsoft 365 Developer Blog）
• Work IQ REST API overview
• Work IQ MCP overview
• Work IQ A2A quickstart
• Microsoft Work IQ CLI
• Copilot connectors overview
• Federated connectors overview
• Extend agents with Model Context Protocol in Copilot Studio