2026年6月3日に更新されたMicrosoft公式情報で、Microsoft 365 Copilot拡張の設計に重要な選択肢が増えました。ポイントは、Work IQ Context APIによって、Copilotが回答に使う業務コンテキストを「完成した回答」ではなく、エージェントが扱いやすい文脈データとして取得できる方向が示されたことです。
これにより、開発チームは「Graph connectorsでデータを取り込むべきか」「Retrieval APIでテキスト片を取得すべきか」「Chat APIでCopilotの回答まで任せるべきか」「自社エージェント側で推論したいのでContext APIを使うべきか」を切り分けて考える必要があります。管理者側では、Microsoft Entra IDの同意、既存のMicrosoft 365権限、秘密度ラベル、コンプライアンスポリシー、Copilot Creditsによる利用量管理を確認することが実務上の出発点になります。(Microsoft Learn)
Microsoft 365 CopilotのAI/Copilot更新で何が変わるのか
今回の更新は、Microsoft 365 Copilotの画面に新しいボタンが増えるというより、Copilot拡張やAIエージェントを作る側の「文脈取得の面」が広がる変更です。
MicrosoftはWork IQを、Microsoft 365のメール、予定表、会議、チャット、ファイル、人、共同作業パターン、業務システムなどをもとに、組織の働き方を意味的に理解するレイヤーとして説明しています。Work IQは「Chat」「Context」「Tools」「Workspaces」という構成で説明され、Context APIはそのうち、Copilotが回答に使うコンテンツを集約し、回答文に合成せずにエージェント向け形式で返すものとして位置づけられています。(Microsoft)
従来のCopilot拡張では、よくある選択肢は次のようなものでした。
| 方式 | 主な役割 | 向いている場面 |
|---|---|---|
| Synced connector | 外部コンテンツをMicrosoft Graphに取り込み、インデックス化する | 社内Wiki、規程集、ナレッジベースなど、更新頻度が比較的落ち着いた情報 |
| Federated connector | MCPを使い、外部システムの情報をリアルタイム取得する | 在庫、チケット、顧客情報など、ソースに残したまま参照したい情報 |
| Retrieval API | SharePoint、OneDrive、Copilot connectorsなどから関連テキスト片を取得する | 自社アプリや独自RAGで、Microsoft 365内の根拠テキストを使いたい場合 |
| Chat API | Microsoft 365 Copilotの回答生成までAPIで利用する | アプリ側で回答文をそのまま表示したい場合 |
| Context API | Copilotが使う業務文脈を、エージェントが処理しやすい形で取得する | 自社エージェント側で比較、抽出、評価、別モデルへの入力を行いたい場合 |
つまり、Work IQ Context APIは「検索APIの置き換え」だけではありません。エージェントが次の処理に使うための、より業務文脈に寄った取得面と考えると分かりやすくなります。
Context APIは「回答」ではなく「判断材料」を返すための選択肢
Context APIを理解するうえで重要なのは、Chat APIとの違いです。
Chat APIは、Copilotがユーザーに返すような回答を生成する方向のAPIです。一方、Context APIは、Copilotが回答に使うであろうコンテンツを集約し、エージェントが消費しやすい形で返すものと説明されています。(Microsoft)
たとえば、営業支援エージェントで次のような処理をしたい場合を考えます。
「来週のA社商談に向けて、直近の会議、メール、提案資料、未完了タスクをもとに、商談リスクを3つ抽出し、CRM更新案を作る」
このとき、単にCopilotの文章回答を表示したいだけならChat APIが候補になります。しかし、自社アプリ側で次のような処理を続けたいなら、Context APIの発想が合います。
- 取得した会議・メール・ファイルの文脈を自社の評価ロジックに渡す
- リスク分類だけは自社の業界別ルールで判定する
- 生成AIの回答前に、取得根拠を監査ログやレビュー画面に表示する
- CRM、チケット管理、契約管理など別システムの情報と突き合わせる
- 最終回答は別のモデル、別のワークフロー、承認プロセスで扱う
要するに、Context APIは「Copilotに全部答えさせる」のではなく、「Copilotが見ている業務文脈を、エージェントや業務アプリの部品として使う」ための選択肢です。
Graph connectorsやRetrieval APIは不要になるのか
結論から言うと、不要にはなりません。むしろ役割の切り分けが重要になります。
Microsoft 365 Copilot connectorsは、外部の業務データをCopilotやMicrosoft Searchなどで使えるようにする仕組みです。同期型コネクタは外部コンテンツをMicrosoft Graphへ取り込んでインデックス化し、フェデレーション型コネクタはMCPを使ってリアルタイムに取得します。(Microsoft Learn)
Retrieval APIは、SharePoint、OneDrive、Copilot connectorsから関連するテキストチャンクを取得し、自社の生成AIソリューションをMicrosoft 365の知識でグラウンディングする用途に向きます。データを別インデックスに複製せず、Microsoft 365のアクセス制御を保ちながら関連テキストを取得できる点が特徴です。(Microsoft Learn)
一方、Work IQ Context APIは、より「エージェントが業務文脈を理解して処理する」方向に寄った取得面です。既存の検索、コネクタ、Graphデータをすべて捨てる話ではなく、次のように整理すると判断しやすくなります。
| 判断ポイント | 選びやすい方式 |
|---|---|
| 外部ナレッジをCopilotやSearchに出したい | Synced connector |
| 外部システムにデータを残したままリアルタイム参照したい | Federated connector |
| 自社RAGにMicrosoft 365由来のテキスト片を渡したい | Retrieval API |
| Copilotの完成回答を自社アプリに組み込みたい | Chat API |
| エージェント側で業務文脈を比較・評価・加工したい | Context API |
| メール送信、会議作成、ファイル操作などの実行まで扱いたい | Tools APIまたはMCPツール |
失敗しやすいのは、「新しいAPIが出たから、すべてContext APIへ移行する」と考えることです。ナレッジの取り込み、検索、回答生成、アクション実行は別の問題です。既存のGraph connectorsで安定している領域は残し、エージェントが追加の文脈判断を必要とする領域から検証するのが現実的です。
管理者が最初に確認すべき設定とガバナンス
Work IQ APIまわりで最初に見るべきなのは、APIの書き方ではなく、誰の権限で、どのデータに、どのアプリがアクセスするのかです。
Microsoft Learnでは、Work IQ APIはMicrosoft Entra IDの委任認証を使い、リクエストはサインインユーザーのコンテキストで実行されると説明されています。OBO、つまりOn-Behalf-Ofフローはサポートされますが、アプリケーション単独の認証はサポートされません。また、Microsoft 365の権限、秘密度ラベル、コンプライアンスポリシーが自動的に適用されるとされています。(Microsoft Learn)
管理者は、少なくとも次の項目を確認してから検証を始めるべきです。
| 確認項目 | 実務上の見方 |
|---|---|
| Microsoft Entra IDの同意 | Work IQ API利用アプリに管理者同意が必要か、誰が承認するかを決める |
| サービスプリンシパル | 組織でWork IQ APIのサービスプリンシパルを作成済みか確認する |
| 委任権限 | アプリがユーザーの代理でどの操作を行うのかをレビューする |
| Microsoft 365権限 | SharePoint、OneDrive、Teams、メールの過剰共有を棚卸しする |
| 秘密度ラベル | ラベル付き情報が意図せずエージェントの文脈に入らないか検証する |
| 監査ログ | 誰が、どのアプリから、どの範囲の情報を参照したか追跡できる状態にする |
| 利用量と課金 | Copilot Creditsの消費、支出制限、部門別管理を設計する |
Work IQ APIの権限リファレンスでは、組織管理者がWork IQ API用のサービスプリンシパルを作成する必要があること、OAuthスコープとしてapi://workiq.svc.cloud.microsoft/WorkIQAgent.Askを使う例、WorkIQAgent.Askには管理者同意が必要であることが示されています。(Microsoft Learn)
特に注意したいのは、「Copilotが既存権限を尊重する」ことと「既存権限が適切である」ことは別問題だという点です。SharePointサイトが広く共有されすぎている、退職者や異動者のアクセス権が残っている、Teamsの古いチャネルに機密ファイルが置かれている、といった状態では、エージェントの取得精度が上がるほど情報露出リスクも見えやすくなります。
開発者が設計時に見るべきポイント
開発者は、まず「Context APIで取得した文脈を、どの処理に使うのか」を明確にする必要があります。曖昧なまま実装すると、結局Chat APIでよかった、Retrieval APIで十分だった、あるいはConnectorの設計が足りなかったという手戻りが起きます。
取得した文脈をそのままユーザーに見せない
Context APIは、エージェント向けの文脈取得面として捉えるべきです。取得結果をそのまま画面に出すのではなく、次の処理を挟む設計が安全です。
- ユーザーが参照してよい根拠だけを表示する
- 機密性の高い情報は要約せず、元リンクと権限確認に誘導する
- 重要な判断は「根拠」「推論」「提案」を分けて表示する
- 生成結果には人間の確認ステップを入れる
- 回答不能、根拠不足、権限不足を明示できるUIにする
たとえば、法務レビュー支援エージェントで、契約書、メール、会議メモを横断して論点を抽出する場合、最終判断までAIに任せるのは危険です。Context APIで得た文脈をもとに「確認すべき条項」「関係者」「過去の合意事項」を整理し、法務担当者が判断できる形にするほうが実務向きです。
時間依存の問い合わせではロケーション情報を扱う
Work IQ APIのA2A例では、会議予定のような時間に依存する問い合わせでLocationメタデータが必要とされています。日付や時刻を扱うエージェントでは、タイムゾーンやユーザー所在地の扱いを曖昧にしないことが重要です。(Microsoft Learn)
日本企業でよくある失敗は、海外拠点のユーザー、UTC表記のログ、Teams会議のタイムゾーンを混在させたまま「明日」「今週」「次回会議」を処理してしまうことです。設計段階で、ユーザーのタイムゾーン、会議の開催タイムゾーン、表示タイムゾーンを分けて扱うべきです。
MCPやTools APIとの境界を分ける
Work IQ MCPは、Microsoft 365のインテリジェンス機能をMCP経由でAIエージェントに公開する仕組みです。Microsoft Learnでは、少数の汎用ツールとリソースパスを組み合わせる設計、実行時にスキーマを取得する考え方、細かな制御をパス・メソッド・テナントポリシーで行う考え方が示されています。(Microsoft Learn)
これは便利ですが、開発者にとっては「取得」と「実行」を分ける設計がより重要になります。
| 処理 | 注意点 |
|---|---|
| 読み取り | 取得範囲、根拠表示、権限不足時の挙動を設計する |
| 要約・比較 | AI生成結果の誤りを前提に、根拠確認のUIを用意する |
| 書き込み・送信 | メール送信、予定作成、ファイル更新は承認フローを入れる |
| 自動実行 | 監査、ロールバック、実行前確認、例外処理を必須にする |
Context APIで取得した文脈をもとに、Tools APIやMCPツールでアクションを実行する構成は強力です。しかし、取得精度が高いほど、誤った自動実行の影響も大きくなります。最初の展開では「提案まで」「下書きまで」「人間承認後に実行」など、段階を分けるのが安全です。
移行・展開時にやるべき現実的な進め方
既存のCopilot拡張やGraph connectorsを使っている組織は、いきなり全面移行するのではなく、現在の構成を棚卸ししてから判断します。
既存構成を4分類する
まず、現在のCopilot拡張や社内AIアプリを次の4つに分けます。
| 分類 | 例 | 対応方針 |
|---|---|---|
| ナレッジ参照型 | 規程検索、FAQ、製品仕様検索 | 既存connectorやRetrieval APIで十分か確認 |
| 文脈統合型 | 会議、メール、ファイルを横断した案件整理 | Context APIの検証候補 |
| 回答生成型 | Copilot風の回答をアプリ内に表示 | Chat APIの検証候補 |
| 実行型 | メール送信、会議作成、CRM更新 | Tools API、MCP、承認設計を含めて検討 |
Context APIの導入価値が出やすいのは、単一文書の検索ではなく、複数の業務シグナルを組み合わせて判断する領域です。たとえば「プロジェクトのリスク」「顧客対応の経緯」「会議で決まった未完了タスク」「関係者間で合意済みの内容」などは、単純なキーワード検索よりも業務文脈が重要になります。
小さな対象グループで検証する
展開は、全社一斉ではなく、業務範囲が明確な部門から始めます。おすすめは、次の条件を満たすチームです。
- 利用するSharePointサイトやTeamsチャネルが明確
- データ所有者が決まっている
- アクセス権の棚卸しができる
- AIの出力をレビューできる業務担当者がいる
- 成果指標を定義しやすい
たとえば、営業企画部門で「商談準備メモの作成時間を減らす」、情報システム部門で「障害対応の過去経緯確認を早くする」、人事部門で「制度問い合わせの根拠確認を効率化する」といった範囲なら、効果とリスクを比較しやすくなります。
評価指標は回答精度だけにしない
Context APIを使うエージェントの評価では、単に「答えが合っているか」だけでは不十分です。次の観点を含めて評価します。
| 評価項目 | 確認内容 |
|---|---|
| 根拠の適切性 | 参照すべき会議、ファイル、メールにたどり着けているか |
| 権限の妥当性 | ユーザーが見られない情報が出ていないか |
| 再現性 | 同じ条件で極端に違う結論にならないか |
| レイテンシ | 業務フロー内で待てる速度か |
| コスト | Copilot Creditsの消費が想定範囲か |
| ユーザー体験 | 根拠確認、修正、承認がしやすいか |
| 監査性 | 後から誰が何を取得・実行したか追えるか |
MicrosoftはWork IQ APIの課金について、ChatとContextは変動要素、Toolsは固定要素を持つ従量課金として説明しており、Copilot Creditsで管理される予定です。また、Microsoft 365管理センターでAIクレジット利用状況、請求方式、支出制限、ユーザーやグループ単位の管理を扱うダッシュボードにも言及しています。(Microsoft)
導入時に避けたい失敗
すべての情報をエージェントに渡そうとする
Context APIを使うからといって、関係しそうな情報を広く取りすぎる設計は危険です。文脈が増えれば精度が上がるとは限りません。ノイズが増えると、誤った関連付けや不要な機密情報の混入が起きます。
実務では、「案件ID」「顧客名」「期間」「対象チーム」「対象ドキュメントライブラリ」などでスコープを絞る設計が必要です。
コネクタの品質を軽視する
外部データをCopilotで使う場合、コネクタ側のタイトル、本文、URL、アクティビティ、説明文などの設計が検索・グラウンディング品質に影響します。Microsoft Learnでも、同期型コネクタでCopilotが取り込んだコンテンツを効果的に使えるようにするため、semantic labels、contentプロパティ、urlToItemResolver、user activities、接続作成時の説明などが挙げられています。(Microsoft Learn)
Context APIを使っても、元データの構造や説明が雑であれば、良い文脈は取得しにくくなります。AI拡張の品質は、API選定だけでなく、データ設計と運用で決まります。
プレビューとGA予定を混同する
2026年6月3日更新のMicrosoft Learnでは、Work IQ API overviewはpreviewとして説明されています。一方、Microsoft 365 BlogではWork IQ APIsが2026年6月16日に一般提供予定と発表されています。公開時点では、テナントでの利用可否、API仕様、課金、制限、サポート範囲が変わる可能性があります。(Microsoft Learn)
本番導入前には、必ず最新のMicrosoft Learn、管理センター、ライセンス情報、利用規約を確認してください。特にAPIの/beta配下にある機能は、本番アプリでの利用可否や仕様変更リスクを慎重に扱う必要があります。
管理者と開発者の実務チェックリスト
最後に、導入前に確認すべき項目を整理します。
| 立場 | 確認すべきこと |
|---|---|
| Microsoft 365管理者 | Work IQ APIの利用可否、サービスプリンシパル、管理者同意、対象ユーザー、監査ログ |
| セキュリティ担当 | SharePoint/Teams/OneDriveの過剰共有、秘密度ラベル、DLP、保持ポリシー、情報バリア |
| 開発者 | Chat API、Context API、Retrieval API、connector、MCPの役割分担 |
| アプリ責任者 | どの業務判断をAIに任せ、どこから人間承認にするか |
| 経理・IT企画 | Copilot Credits、支出制限、部門別利用量、PoC後の費用見込み |
| データ所有者 | 参照されるデータの正確性、更新頻度、権限、メタデータ品質 |
最初の一歩としては、既存のCopilot拡張や社内AIアプリを棚卸しし、「検索で十分なもの」「Copilotの回答が欲しいもの」「エージェント側で文脈を処理したいもの」「アクション実行まで必要なもの」に分けることです。
Work IQ Context APIは、Microsoft 365 Copilot拡張に新しい取得面を加える重要な選択肢です。ただし、成功の鍵は新APIの採用そのものではありません。既存の権限設計、コネクタ品質、監査、コスト管理、人間の承認フローを整えたうえで、業務文脈を使う価値が高いユースケースから段階的に展開することが、もっとも現実的な進め方です。
コメント