Microsoftは、エンタープライズ向けエージェントがMicrosoft 365のコンテキストやツール、Copilotの知性を安全に利用するための「Work IQ API」を、2026年6月16日（月）に一般提供（GA）開始すると発表した。エージェント開発者がM365データへの独自のRAGスタックやガバナンス基盤を自前で構築せずとも、テナント境界・監査・権限制御を備えた形でM365全体の情報にアクセスできる仕組みが整う。

Work IQ APIとは何か

Work IQ APIは、Chat・Context・Tools・Workspacesの4つのAPIドメインで構成される、エージェント向けM365インテリジェンスレイヤーだ。

  • Chat API: M365 Copilotが持つ応答能力全体へのプログラムアクセスを提供する。エージェントからCopilotの回答生成能力を呼び出せる
  • Context API: メール・カレンダー・Teams・ファイル・SharePoint・OneDriveといった職場データを、エージェントが消費しやすい最適化された形式で返却する
  • Tools API: ファイル操作・メール送信・会議スケジュールなどのM365アクションをエージェントから実行できる
  • Workspaces API: エージェントが中間状態を保存・参照するための作業領域を提供する

これら4つのAPIを組み合わせることで、エージェントはM365テナントの情報を読み書きしながら、人間の代わりに業務フローを自律実行できるようになる。

GAで提供される主要機能

GA時点で利用可能になる機能として、Microsoftの開発者ブログは以下を明記している。

エージェント間通信（A2A）

Agent-to-Agent（A2A）プロトコルのサポートにより、Work IQ APIを呼び出すエージェント同士が委譲・連携できる。複数のスペシャリストエージェントをオーケストレーターが束ねるマルチエージェント構成で活用しやすい。

リモートMCPサーバー（再設計版）

Model Context Protocol（MCP）向けのリモートサーバーが刷新される。MCPはローカルとリモートの2形態があるが、GAではリモートMCPが整備され、ツールスタイルでWork IQ機能にアクセスできる。

REST API

標準的なREST APIアクセスにより、既存のアプリケーションやサードパーティエージェントからWork IQを呼び出せる。Microsoftはサードパーティエージェントからの呼び出しも正式にサポートすると明言している。

ライセンスとコスト構造

Work IQ APIの利用料金は、Copilot Creditsによる従量課金モデルを採用する。Work IQ API専用のSKU・サブスクリプション・ユーザーライセンスは存在せず、既存のCopilotクレジット枠から消費される形になる。

この構造が意味するのは、利用量をコントロールしやすい反面、エージェントが想定外のツール呼び出しを繰り返すとクレジット消費が膨らむという点だ。Microsoft自身も管理者向けのコストコントロール機能の整備を強調しており、事前に使用量を試算した上で予算キャップをかけることを推奨している。

セキュリティとガバナンス

Work IQ APIがエンタープライズ環境に向けて特に強調するのがガバナンス面だ。

  • テナント境界の厳格な管理: 他テナントのデータへのアクセスは設計上できない
  • パーミッション・トリミング: 委任ユーザーコンテキストに基づき、呼び出しエージェントが本来アクセスできない範囲のデータは返却されない
  • 監査ログ: エージェントがどのAPIを何回呼び出したかが記録される
  • 管理者によるコストコントロール: テナント管理者がCopilotクレジット消費に上限を設けられる

エージェントがメール送信・会議作成・ファイル操作といった破壊的アクションを取れる以上、権限設計と監査体制の整備は必須だ。

実務への影響――日本のエンジニア・IT管理者へ

エージェント構築者へ

自前でM365データ連携のRAGレイヤーを構築していた開発者は、Work IQ APIへの移行を検討する価値がある。特に以下のケースでは効果が高い：

  • 社内エンタープライズアシスタントが「社員の予定・メール・ファイル」を横断して回答する必要がある
  • Copilot Studioで構築したエージェントを、社外のPythonやNode.jsアプリから呼び出したい
  • マルチエージェント構成で、専門化されたエージェント同士に業務を委譲させたい

まず検証すべき3点

  • 必要なプロトコルの確認: A2A（エージェント委譲）・REST（アプリ統合）・MCP（ツールアクセス）のどれが自分のユースケースに合うかを先に絞る
  • 認証・権限の事前テスト: Microsoft Learnには委任ユーザーコンテキストへの言及があるが、実テナントでの挙動確認が不可欠。本番前に検証環境で試す
  • Copilotクレジット消費の試算: 「ツール呼び出し1回あたりのクレジット消費×想定呼び出し数」を算出し、月間コストの上限を管理者と合意してから開発を進める

6月16日以降に確認すること

現時点でMicrosoft Learnにはプレビュー時点の記述が残っているため、GA後のドキュメントで最終的なエンドポイントと制約事項を必ず再確認する必要がある。プレビューと仕様が変わっているケースは珍しくない。

筆者の見解

Work IQ APIは、M365の価値を「Copilotというインターフェース」に閉じ込めず、エージェントという自律型ソフトウェアに開放するという意味で、アーキテクチャ上の方向性として正しい。メール・カレンダー・ファイルを横断するコンテキストはMicrosoftが長年かけて蓄積した最大の資産であり、それをAPIで外部から利用できるようにするのは、M365プラットフォームの真の力を引き出す一手だ。

個人的に注目しているのは、ガバナンスを保ちながらサードパーティエージェントにも開放したという点だ。「M365のデータを使いたいが、Copilot Studioだけに縛られたくない」という開発者の現実的なニーズに正面から応えた格好で、これはMicrosoftが取れる正しい打ち手だと思う。

ただし、「Copilot Creditsの消費量が予測しにくい」という課題は引き続き残る。エージェントが自律的に動く以上、ツール呼び出し数はコントロールが難しく、思ったより早くクレジットが枯渇するリスクは念頭に置いておきたい。まず一つの狭いユースケースで動かし、監査ログとコスト消費を計測してから段階的に広げる——その慎重なアプローチが実務では現実的な選択になる。

M365はバラバラに使っても意味が薄く、統合して使ってこそ価値が出るプラットフォームだ。Work IQ APIがその統合を「エージェント時代」にまで延伸させる礎になるのか、6月16日以降の実際の動作検証に注目したい。

出典: この記事は Microsoft Work IQ APIs go GA on June 16: what agent builders get の内容をもとに、筆者の見解を加えて独自に執筆したものです。