Work IQ APIの使い方｜A2A・MCP・REST完全解説

Microsoftは2026年4月、Microsoft 365 Copilotにエージェント連携の標準APIとして「Work IQ API」のパブリックプレビューを開始しました。
Work IQ APIはエージェント間連携のA2A、データソース接続のMCP、そして直接呼び出しのREST APIを統一的に束ねる開発基盤で、従来のCopilot Chat APIから段階的に置き換わっていきます。 　
本記事では、2026年5月時点の公式ドキュメントをもとに、Work IQ APIの3層構造と提供状態、Entra ID delegated認証、Microsoft 365 Copilotライセンス要件、サンプルリポジトリからの実装パターン、料金、そしてCopilot Chat APIから移行するときに詰まりやすい論点までを体系的に解説します。
あわせて、A2Aプロトコルv1.0のメソッド名（SendMessage／SendStreamingMessage／GetTask）と初回応答で返るcontextIdによる会話継続など、API設計者がプレビュー段階で押さえておくべき判断軸を整理しました。

Work IQ APIとは：M365 Copilotのエージェント連携基盤

Work IQ APIはREST・A2A・MCPを統合し、Copilotの推論・検索・ツール実行を支える統一基盤として設計されている（出典：Microsoft Tech Community）

Microsoftは2026年4月、Microsoft 365 Copilotのエージェント開発者向けに「Work IQ API」のパブリックプレビューを公開しました。Work IQ APIは、エージェント間通信のA2A、データソース接続のMCP、そして直接呼び出しのREST APIを統一的に束ねる開発基盤です。

公式ドキュメントWork IQ API overviewでは、Work IQ APIを「Copilot Chat APIの後継として、エージェント間連携・外部データ統合・直接呼び出しを統一する開発基盤」と定義しています。

これまでCopilot Chat APIで扱っていた「Copilotにメッセージを投げて応答を得る」操作は、Work IQ APIではA2A経由のエージェント呼び出し、MCP経由のデータ問い合わせ、REST API経由の直接呼び出しのいずれかで表現します。

要点を3行に圧縮すると次のとおりです。

• 3つのプロトコルを1つの基盤に集約
  A2A（Agent-to-Agent）はエージェント同士の通信、MCP（Model Context Protocol）はデータソース・ツール接続、REST APIは直接呼び出しを担う。
  3層を同じ認証・ライセンス基盤の上に統合した
  
  

• 既存Copilot Chat APIからの段階移行
  Copilot Chat APIは引き続き利用可能だが、新規開発はWork IQ API推奨。
  現時点ではA2AとLocal MCPが利用可能で、Remote MCPとREST APIは近日提供予定として段階的に開放される
  
  

• Microsoft 365 Copilotライセンスが前提
  個人テナントの開発者単独契約では呼び出しが通らない。
  Microsoft 365 CopilotライセンスとEntra ID delegated認証の両方が必要で、検証段階から本番ライセンスを意識した設計が求められる
  
  

A2A・MCP・RESTの3層構造を一度押さえておくと、後続セクションの実装・認証・料金・移行の話がすべて同じ枠組みで理解できます。

---

なぜ今Work IQ APIが必要なのか：Copilotエコシステム拡張の要請

Work IQ APIが登場した背景には、Microsoft 365 Copilotが「ChatBot＋プラグイン」から「エージェントの実行基盤」へとポジションを切り替えたことがあります。ここでは、なぜ既存のCopilot Chat APIでは足りなくなったのかを、エコシステム側の要請として整理します。

Copilot Chat APIが想定していなかった「エージェント間連携」

Work IQ API overviewでは、Work IQをCopilot Chat APIの本番向け進化形と位置付けています。

Microsoft 365 Copilotエージェントの活用が広がるなかで、エージェントが他のエージェントを呼び出す「エージェント連鎖」のユースケースが現場で増えてきました。

Chat APIはこの「エージェント間呼び出し」を一級概念として扱っていなかったため、開発者は独自プロトコルでエージェント間通信を組まざるを得ない状況が続いていました。

外部データ・ツール接続の標準が業界全体で固まった

並行して、AnthropicとMicrosoft、OpenAIなどが推進するMCP（Model Context Protocol）が、外部データ・ツール接続の事実上の標準として定着しました。

Microsoft 365 Copilotにおいても、SharePoint・Outlook・TeamsなどのMicrosoft 365データに加え、Copilot connectorsやEnterprise Searchを通じて取り込まれた業務データへ接続する標準口としてMCPを取り込む必要が出てきました。

A2A・MCP・RESTを1つの開発者面に統一する判断

Work IQ APIは、A2A（エージェント間連携）・MCP（データ・ツール接続）・REST（直接呼び出し）の3層を、同じ認証・同じライセンス・同じドキュメント体系の上で束ねる判断をした結果として登場しています。

これにより、開発者は「Copilotエコシステム上で動くエージェントとデータ接続を、どのプロトコルでもWork IQ APIに従えば動く」という設計指針を得られるようになりました。

AI総合研究所の見立てとしては、エージェント連携が必須要件になる業務（受注処理・社内問い合わせ・契約レビューなど）で、独自プロトコルを選ぶ理由は事実上消えたと考えています。

---

Work IQ APIの3層構造（A2A・MCP・REST）の全体像

ここからは、Work IQ APIの3つのプロトコル層がそれぞれどの役割を担うかを、開発者から見た呼び出し方の違いで整理します。

下記の表で、3層の責務を比較します。

プロトコル層	主な役割	通信形式	2026-05時点の状態
A2A（Agent-to-Agent）	エージェント間の対話・タスク委譲	JSON-RPC 2.0／HTTP	パブリックプレビュー公開済み（v1.0）
MCP（Model Context Protocol）	データソース・ツールへの接続	JSON-RPC／stdio・HTTP	Local MCPは公開済み／Remote MCPは近日提供予定
REST API	アプリやバックエンドからWork IQを会話型に呼び出すREST／JSON API	REST／JSON	近日提供予定（2026年5月以降順次）

3つの層は排他関係ではなく、1つのアプリから複数を組み合わせて呼び出す前提で設計されています。

たとえば「ユーザーからの依頼を受けたエージェントが、別エージェント（A2A）を呼び出し、そのエージェントが社内データソース（MCP）にアクセスし、アプリ／バックエンドが最終応答を受け取る（REST）」というフローは典型的な使い方です。

A2A／MCP／RESTを使い分ける判断軸

3層をどう使い分けるかは、以下の3つの問いで判断できます。

• 呼び出す相手はエージェントか、データか、アプリ／バックエンドからの直接呼び出しか
  エージェント呼び出しならA2A、データ・ツール呼び出しならMCP、アプリやバックエンドからWork IQを会話型に呼ぶならREST APIを選ぶ
  
  

• 既存のA2A／MCPサーバー実装を活用できるか
  A2Aプロトコル・MCP仕様はオープン仕様だが、Work IQ APIから接続するには、プロトコル互換性を確認したうえで、Work IQ側の認証・提供範囲（Local／Remote MCPの可否、Gateway要件等）に合わせた接続設計が必要になる
  
  

• Copilot Chat APIで動いている既存資産があるか
  ある場合は、後述するREST APIへの段階移行を計画する。新規ならA2A／MCPから設計を始める方が将来コストが小さい
  
  

3層の使い分け方を最初に決めてから個別実装に入ると、後でプロトコル変更による手戻りを大幅に減らせます。

---

A2Aプロトコル：エージェント間通信の標準仕様

A2A（Agent-to-Agent）は、Work IQ APIにおけるエージェント間通信の標準プロトコルです。ここでは、A2Aの最新仕様と、Work IQ APIでの実装上のポイントを整理します。

A2A v1.0のメソッド名とJSON-RPCエンベロープ

A2AはA2A Protocol公式サイトで標準化されているオープン仕様です。Work IQ APIは2026年5月時点でA2A v1.0を採用しており、JSON-RPC 2.0をベースとしたメッセージエンベロープに A2A-Version: 1.0 ヘッダーを付与して通信します（v1.0変更点）。

メッセージは「method（呼び出すメソッド名）」「params（引数）」「id（呼び出し識別子）」の3要素を持ち、応答側は同じidを返すことで非同期処理にも対応します。

主要メソッドは以下の3つです。

• SendMessage（v1.0、旧名 message/send）
  エージェントへ単発のメッセージを送信し、即時応答を受け取る
  
  

• SendStreamingMessage（v1.0、旧名 message/stream）
  ストリーミング応答を受け取る。長文応答や逐次表示に使う
  
  

• GetTask（v1.0、旧名 tasks/get）
  非同期タスクの進行状況・結果を取得する
  
  

A2A v1.0は共通データモデル・標準操作・JSON-RPC/HTTPバインディングによってエージェント間相互運用を実現する（出典：A2A Protocol Official Specification）

v1.0以降のクライアントでは新メソッド名を使い、v0.3互換サーバーへ接続する場合のみ旧メソッド名を使い分ける必要があります。

contextIdによる会話継続

A2Aの大きな特徴は、contextIdという識別子で会話文脈を継続できる点です。エージェント間で対話が複数ターンに渡る場合、同じcontextIdを引き継いで送ることで、応答側は前回までの履歴を踏まえた応答を返せます。

これにより、エージェント側は「ユーザーから直接呼ばれた」「別エージェントから委譲された」のいずれでも、同じ会話メモリを使って一貫した応答ができます。

A2A仕様ではエージェントが新規contextIdを生成してもクライアント提供値を受け入れてもよいとされており、Work IQの例では初回応答にcontextIdが返ります。クライアント実装の基本パターンは、この返却値を保存し、次回以降のメッセージに付与する形で会話を繋ぐ流れです。

並行性が必要な業務では、同じcontextIdに対する並行呼び出しは順序保証されないため、ターンごとに直列化する設計が必要になります。

---

MCPプロトコル：データソース連携の標準化

MCP（Model Context Protocol）は、エージェントが外部データ・ツールへ接続するための標準プロトコルです。Work IQ APIは2026年5月時点でLocal MCPが利用可能で、Remote MCPは近日提供予定として段階的に開放されます。

Local MCPとRemote MCPの使い分け

公式ドキュメントWork IQ API overviewでは、Local MCPはエージェントと同一プロセス・同一マシンで動くMCPサーバーを指し、Remote MCPはHTTP経由で別ホストのMCPサーバーへ接続するモデルと位置付けられています。

下記の表で、両者の違いを整理します。

観点	Local MCP（公開済み）	Remote MCP（近日提供予定）
通信形式	stdio（プロセス間）	HTTP／JSON-RPC
接続先	同一マシン上のMCPサーバー	別ホストのMCPサーバー
認証	プロセス境界による分離	OAuth／APIキー等
主な用途	開発者ローカル検証、専用ツール	共有サービス、社内データ基盤

現時点ではLocal MCPで開発・検証を進め、Remote MCP提供開始後に本番想定のRemote MCPサーバー設計へ移行するのが現実的なロードマップです。

エンタープライズ用途では、Remote MCP公開後に社内データ基盤（SharePointやCopilot connectorsで取り込んだ業務データ）への接続をRemote MCPサーバーに集約し、複数エージェントが共通の接続口として利用するパターンが想定されます。

Work IQ MCPサーバーが公開する代表的なwork context

Work IQ MCPサーバーが、AIアシスタントや開発環境にツールとして公開する代表的なMicrosoft 365 work contextは以下のとおりです。

• Microsoft Graph経由のMicrosoft 365データ
  メール・予定表・People・OneDrive／SharePoint文書・Teams等、Copilotがアクセスできるユーザー権限内の組織データ
  
  

• Copilot connectors／Enterprise Searchで取り込まれた業務データ
  管理者がCopilot connectorsまたはEnterprise Search経由でCopilotに取り込んだ社内データソース
  
  

社内データ統合のスコープを最初に整理し、どのソースをCopilot connectors側で取り込むかを設計初期に固めると、後の運用統制が大幅に楽になります。

---

REST API：直接呼び出しと従来Copilot Chat APIからの移行

REST APIは、アプリやバックエンドからWork IQを会話型に呼び出すREST／JSON APIです。2026年5月時点では近日提供予定（2026年5月以降順次公開）と位置付けられており、A2A／MCPで包めないユースケースを担います。

REST APIの位置付けとカバー範囲

公式ドキュメントWork IQ API overviewでは、REST APIは「アプリやバックエンドからWork IQをプログラム的に呼び出す会話型REST API」として提供予定と説明されています。エンドポイントの具体名や粒度は公開時点で確定するため、公式ドキュメントの最新情報で確認するのが安全です。

Copilot Chat APIで提供されていた「ユーザーからCopilotにメッセージを送り、応答を得る」操作は、Work IQ APIのREST API経由で呼び出す形に置き換わる想定です。

Copilot Chat APIからの移行パターン

Work IQ API overviewのCopilot Chat APIとの比較セクションでは、Copilot Chat APIで構築済みのアプリケーションは引き続き動作するが、新規開発はWork IQ APIを推奨と明記されています。

実務での移行パターンは以下の3通りに整理できます。

• 新規開発はWork IQ APIから始める
  A2A／Local MCPで設計し、REST APIが必要な箇所だけ公開後にREST層を追加する
  
  

• 既存Copilot Chat APIアプリは「機能追加時にWork IQ API化」
  新機能だけWork IQ APIで実装し、既存機能は当面Chat APIで維持して段階的に置き換える
  
  

• 大規模リアーキテクト
  REST API公開後に、既存のChat API呼び出しをREST APIに置換し、エージェント連携部分をA2A化する
  
  

AI総合研究所の見立てとしては、新規はWork IQ APIから始め、既存は機能追加時に置き換える「段階移行型」が、リスクとコストのバランスで最も現実的だと考えています。

---

認証とライセンス：Entra ID delegated＋M365 Copilotライセンス

Work IQ APIを呼び出すには、Entra ID delegated認証とMicrosoft 365 Copilotライセンスの両方が必須です。ここでは、認証フローとライセンス要件を整理します。

Entra ID delegated認証とOBOフロー

Microsoft Learn Work IQ API authenticationでは、Work IQ APIは「ユーザーに代わって（on-behalf-of）」呼び出すdelegated認証のみを受け付けると明記されています。

これは、Copilotが「ユーザーがアクセスできるデータにのみアクセスする」という設計原則に基づくもので、サービスアカウントによる「全ユーザーデータの一括取得」のような使い方はできません。

実装は以下の流れになります。

• ユーザーログイン
  Microsoft Entra IDでサインインし、アクセストークンを取得
  
  

• OBOフロー
  取得したアクセストークンをWork IQ APIスコープへ交換（On-Behalf-Of flow）
  
  

• Work IQ API呼び出し
  交換後のトークンをAuthorizationヘッダーに付与してA2A／MCP／RESTを呼び出す
  
  

Microsoft Entra IDのOn-Behalf-Ofフローは、委任権限を保持したまま複数API間で安全な認証連携を実現する（出典：Microsoft Learn）

セキュリティ統制上、トークンのスコープを最小化することと、トークン交換時のリフレッシュ戦略を設計初期に決めておくことが重要です。

Microsoft 365 Copilotライセンス要件

Microsoft 365 Copilotライセンスドキュメントによると、Work IQ APIを呼び出すユーザーはMicrosoft 365 Copilotライセンスを保有している必要があります。Business専用ではなく、Microsoft 365 Copilotが対象とするBusiness／Enterprise系プランで利用できます。

注意点は2つで、1つ目は「開発者個人のテナントだけでは本番要件を満たせない」こと、2つ目は「ライセンス保有者ごとに呼び出しコストが計上される」ことです。

このため、検証段階からMicrosoft 365 Copilotライセンスを保有する検証ユーザーを準備し、本番想定の権限設計でテストする必要があります。

---

Work IQ APIの実装パターン：サンプルから始める3ステップ

Microsoftはwork-iq-samplesリポジトリでC#・Rust・Swiftの公式サンプルを公開しており、最初の検証はこのサンプルを起点にするのが定石です。

Step 1：サンプルリポジトリのクローンとローカル実行

work-iq-samplesリポジトリをクローンし、READMEに従って必要なシークレット（Entra IDアプリ登録情報、Copilotライセンスを持つテストユーザー）を環境変数に設定します。

C#サンプルは.NET 8、Rustサンプルはstable、Swiftサンプルはmacos／iOS環境を想定しており、自社の技術スタックに近い言語のサンプルから入ると学習コストを抑えられます。

Microsoft公式のwork-iq-samplesではC#・Rust・Swift向けA2Aサンプルが提供されている（出典：GitHub - microsoft/work-iq-samples）

Step 2：A2A経由でCopilotエージェントを呼び出す

最初の検証は、A2AのSendMessageでCopilotエージェント（Microsoft 365 CopilotエージェントまたはCopilot Studioで作った自社エージェント）を呼び出すパターンが分かりやすい起点です。

初回応答で返るcontextIdを次ターン以降のメッセージに付与して、複数ターンの会話が継続する挙動を確認すると、A2Aの設計思想が体感できます。

Step 3：MCP経由でデータソースに接続する

A2Aの呼び出しが通ったら、次にLocal MCPサーバーとしてWork IQをクライアント（AIアシスタントや開発環境）に登録し、Microsoft 365のwork contextを取得するパターンを試します。Remote MCPは近日提供予定のため、検証段階ではLocal MCPを起点にするのが現実的です。

詰まりやすいのは認証スコープの設定で、MCPサーバー側の権限とWork IQ API側のdelegatedスコープの両方を一致させる必要があります。

3ステップで「呼び出しが通る」「会話が継続する」「データが取れる」の3点が確認できれば、本番設計の議論に進める状態になります。

---

Work IQ APIの料金と利用条件

ここでは、Work IQ APIを商用利用するときに必要なライセンス・コスト要素を整理します。

Work IQ API自体の料金構造

2026年5月時点で、Work IQ API自体の呼び出し回数に対する追加課金は公開されていません。代わりに、呼び出すユーザーごとにMicrosoft 365 Copilotライセンス（Business／Enterprise系プラン）が必要となります。

Microsoft 365 Copilotの公式価格ページでは、Microsoft 365 Copilot Business add-onが2026年5月時点で月額$18（プロモーション価格）／$21（通常価格）で提供されており、これがWork IQ API利用の基本コストの土台になります。

下記の表で、Work IQ API商用利用に関わる主なコスト要素を整理します。

Microsoft 365 Copilot Businessは通常$21、プロモーション価格$18で提供され、Work IQ利用には対象ライセンスが必要（出典：Microsoft 365 Copilot Pricing）

コスト要素	内容	2026-05時点の単価
Microsoft 365 Copilotライセンス	Work IQ API呼び出しユーザーごとに必須	Business add-on $18プロモ／$21通常／ユーザー（プランで変動）
Copilot Studio Credits（任意）	自社エージェントをCopilot Studioで構築する場合	25,000 Copilot Creditsあたり$200／月（消費量はアクション・応答内容で変動）
MCPサーバー運用（任意）	Remote MCPサーバーを自社で運用する場合	インフラ費（Azure等）
エージェント開発工数	設計・実装・運用整備	自社／パートナー費用

API呼び出しに対する従量課金がない代わりに、ユーザー単位のCopilotライセンスが土台になる構造です。

このため、コスト試算は「呼び出し回数」ではなく「Work IQ APIにアクセスするユーザー数」で計算するのが正解になります。

コスト試算の考え方

たとえば社内100名にWork IQ APIを使ったエージェントを提供する場合、Microsoft 365 Copilot Business add-on（プロモ$18）の土台で月額$1,800、通常$21なら月額$2,100が基本コストの目安です。さらに自社エージェントをCopilot Studioで作るならCopilot Credits、Remote MCPを自社運用するならインフラ費が積み上がります（プランによって単価は変動するため、最新は公式価格ページで確認）。

「PoCは10名で試したいが、本番は1,000名展開したい」というケースでは、PoCコストは抑えられても本番展開時のライセンスコストが大きくなる構造のため、PoCの段階で「本番展開時の月額ライセンス費」を上司・財務に共有しておくのが現実的です。

---

Work IQ API導入で詰まる論点と判断ポイント

ここでは、Work IQ APIを実プロジェクトに導入するときに詰まりやすい論点を整理し、判断軸を提示します。

詰まりポイント1：パブリックプレビューでの本番判断

Work IQ APIは2026年5月時点でパブリックプレビューであり、SLA・後方互換保証は通常のGAサービスより弱くなっています。

判断軸としては、以下の3つで分類するのが現実的です。

• 検証・社内ツール
  Work IQ APIで先行実装してOK。プロトコルの感触を掴む期間として活用
  
  

• 顧客向けプロダクト
  GA待ちが基本。プレビュー段階の挙動変更で顧客影響が出るリスクを避ける
  
  

• 基幹業務組み込み
  GA＋6か月程度の実績を待つのが安全。ただしA2A／MCPで設計だけ先行しておくと、GA後の実装が高速化する
  
  

詰まりポイント2：Copilot Chat APIとの並行運用設計

既存Chat APIアプリを抱える組織では、Chat APIとWork IQ APIの並行運用期間が発生します。

並行運用中は、認証トークンの管理・スレッド管理・ログ統合の3点で「どちらのAPI経由か」を識別できる設計にしておかないと、本番障害時の切り分けが困難になります。

詰まりポイント3：エージェント間連鎖の権限設計

A2Aで「エージェントAが、エージェントBを呼び出す」連鎖を組むとき、権限がユーザーから委譲されたまま連鎖の最後まで伝播するため、エージェントBがアクセス可能な範囲＝呼び出し元ユーザーの権限となります。

これを意識せずに設計すると、「エージェントBにユーザー権限を超えるデータを取らせたい」というケースで詰まります。設計初期に、エージェント連鎖ごとの権限境界を整理しておくのが定石です。

---

Work IQ APIエージェントを業務基盤に統合するなら

ここまで、Work IQ APIの3層構造・認証・実装パターン・料金・移行論点を見てきました。プロトコルとしての設計指針は明確ですが、実業務に組み込むには「エージェント連携・社内データ接続・実行統制・監査ログ」を一体で設計する必要があります。

AI Agent Hubは、Work IQ APIで構築したエージェントを業務フローに統合・運用するためのエンタープライズ向け基盤です。9種のAIエージェント（文書要約・問い合わせ応答・データ分析等）と社内データ接続・運用統制をワンストップで提供し、PoCから全社展開までの設計・実装・運用を一貫してサポートします。

Work IQ APIで作ったエージェントを最短で業務適用したい方は、まず資料をご覧ください。

---

まとめ：Work IQ APIで広がるCopilotエージェント運用

Work IQ APIは、検証段階ならwork-iq-samples（C#／Rust／Swift）からA2A→Local MCPの順で呼び出しを通すのが最短ルートです。Remote MCPとREST APIが順次公開される過程で、対応スコープを段階的に広げていく形になります。

商用展開ではMicrosoft 365 Copilotライセンスがコスト試算の土台となるため、PoC段階から本番ユーザー数ベースで月額試算を共有しておくとリスクを抑えられます。

Copilot Chat APIで稼働中のアプリは、新機能追加時にWork IQ API化する段階移行型が現実的です。エージェント間連鎖の権限設計とパブリックプレビュー段階での本番判断の2点を初期に固めておけば、GA後のスムーズな本番展開につながります。