Microsoft Work IQ API (preview)は、Microsoft 365のメール、会議、ファイル、Teamsメッセージ、人・組織情報などを、既存の権限やコンプライアンスを維持したままAIアプリやエージェントから推論利用するためのAPIです。結論から言うと、これからMicrosoft 365 Copilot連携アプリや社内AIエージェントを作るなら、単なる検索APIではなく「Microsoft 365上の業務文脈を安全に推論する基盤」としてWork IQ APIを検証する価値があります。
一方で、Microsoft Work IQ API (preview)はまだプレビュー扱いです。2026年5月16日に更新された公式のライセンス情報では、Work IQ APIを呼び出す各ユーザーにMicrosoft 365 Copilotアドオンライセンスが必要で、ライセンス済みユーザーには追加の従量課金がない一方、ライセンスなしユーザーの利用は現時点でサポートされていないとされています。導入前に、ライセンス、Microsoft Entra IDの同意設定、利用規約、プロトコル選定、プレビュー段階のSLAなしという前提を必ず確認してください。(Microsoft Learn)
Microsoft Work IQ API (preview)で何が変わるのか
Microsoft Work IQ API (preview)の最大の変化は、アプリ側でMicrosoft 365データを集めて、別途インデックス化し、LLMに渡す構成を必ずしも自前で作らなくてよくなる点です。
従来のAIアプリ開発では、次のような設計がよく使われていました。
| 従来の実装 | 課題 |
|---|---|
| Microsoft Graphなどでデータを取得する | データ取得後の権限管理や秘匿情報の扱いをアプリ側で考える必要がある |
| ベクトルDBにメール・文書・チャットを同期する | データ更新、削除、保持期間、監査対応が複雑になる |
| LLMに検索結果を渡して回答させる | 回答根拠、権限、秘密度ラベル、コンプライアンスの設計負荷が高い |
| 個別サービスごとに検索ロジックを作る | メール、Teams、SharePoint、会議情報を横断した推論が難しい |
Work IQ APIは、Microsoft 365 Copilotとエージェントの背後にある「Work IQ」をアプリから利用できるようにするものです。Microsoft Learnでは、Work IQがメール、会議、ドキュメント、チャットに加え、パターン、好み、関係性などの文脈を組み合わせて推論し、次に取るべき行動を提示する知能レイヤーだと説明されています。すべてのリクエストはサインインユーザーのコンテキストで実行され、Microsoft 365の権限、秘密度ラベル、ガバナンスを尊重します。(Microsoft Learn)
実務上は、Work IQ APIを「Microsoft 365データに対するAI推論の入口」と捉えると分かりやすいです。単に「ファイルを探す」「メールを取得する」だけなら既存APIで足りる場合がありますが、「最近の顧客対応の論点をメール、会議、Teams、SharePointから整理して次のアクションを出す」といった用途では、Work IQ APIの価値が出やすくなります。
影響を受ける対象者
Microsoft Work IQ API (preview)は、開発者だけでなくMicrosoft 365管理者、Entra ID管理者、セキュリティ担当、ライセンス管理者にも影響します。
| 対象者 | 主な影響 | 最初に確認すべきこと |
|---|---|---|
| Microsoft 365管理者 | Copilotライセンス、組織内での利用可否、MCPサーバー利用管理に関わる | 対象ユーザーにMicrosoft 365 Copilotアドオンライセンスがあるか |
| Microsoft Entra ID管理者 | アプリ登録、サービスプリンシパル、委任アクセス許可、管理者同意が必要になる | WorkIQAgent.Ask の委任アクセス許可を誰が承認するか |
| アプリ開発者 | A2A、MCP、REST予定などのプロトコル選定が必要になる | まずA2Aで検証するか、MCPで開発環境連携から始めるか |
| セキュリティ・法務担当 | プレビュー利用規約、データ保存、プライバシー、レート制限の確認が必要になる | Work IQ API経由で得たデータや回答をアプリ側でどう保持するか |
| 既存Copilot Chat API利用者 | 将来的な移行計画が必要になる | 新規開発をWork IQ API前提に切り替えるか |
特に重要なのは、Work IQ APIが「アプリケーション単独の権限で組織データを広く読むAPI」ではない点です。公式ドキュメントでは、Microsoft Entra IDの委任認証を使い、リクエストはサインインユーザーのコンテキストで実行され、OBOフローはサポートされる一方、アプリケーション専用認証はサポートされないとされています。(Microsoft Learn)
対応プロトコルはA2A、MCP、REST予定の3系統で考える
Microsoft Work IQ API (preview)では、アプリやエージェントの構成に合わせて複数のプロトコルを選べます。公式概要では、パブリックプレビュー時点でA2AとローカルMCPが利用可能、RESTとリモートMCPは今後提供予定とされています。(Microsoft Learn)
| プロトコル | 向いている用途 | 状態 | 実装時の注意点 |
|---|---|---|---|
| A2A | 複数エージェント間のタスク委任、社内AIエージェントからWork IQへ問い合わせる構成 | 利用可能 | A2A-Version ヘッダー、JSON-RPC形式、contextId の扱いを確認する |
| Local MCP | IDE、CLI、AIコーディングアシスタントからMicrosoft 365の業務文脈を参照する | 利用可能 | Work IQ CLI、Node.js、管理者同意、EULA受諾が必要になる |
| Remote MCP | リモートMCPサーバーとしてWork IQを利用する構成 | 公式概要ではcoming soon | 利用可能地域や管理機能の提供状況を確認する |
| REST | Webアプリやバックエンドサービスから会話型に呼び出す構成 | coming soon | 現時点の設計では、RESTを前提にしすぎず抽象化しておく |
A2Aを使う場合、Work IQ Gatewayのエンドポイントは https://workiq.svc.cloud.microsoft/a2a/、トークン audience は api://workiq.svc.cloud.microsoft、スコープは WorkIQAgent.Ask です。A2A v1.0の SendMessage を使うには A2A-Version: 1.0 ヘッダーが必要で、ヘッダーを省略するとv0.3扱いになるため、v1.0のメソッド名ではエラーになる可能性があります。(Microsoft Learn)
Work IQ APIに向いている用途・向かない用途
Work IQ APIは強力ですが、すべてのMicrosoft 365連携を置き換えるものではありません。用途を間違えると、実装が複雑になったり、プレビュー仕様変更の影響を受けやすくなったりします。
| 判断軸 | Work IQ APIに向いている | 別の手段を検討した方がよい |
|---|---|---|
| 目的 | 複数のMicrosoft 365情報を横断して要約・推論したい | 特定ファイルのメタデータ取得、予定表の単純なCRUD |
| 入力 | 自然言語の質問や依頼 | 厳密な条件検索、定型的なデータ処理 |
| 出力 | 回答、要約、次のアクション、文脈整理 | 監査用の完全なデータ一覧、バッチ抽出 |
| データ範囲 | メール、会議、Teams、OneDrive、SharePoint、人・組織情報をまたぐ | 単一サービスだけで完結する |
| 運用要件 | Copilotライセンス前提の限定ユーザー向けAI体験 | ライセンスなしユーザーも使う大規模汎用API |
例えば、営業担当が「明日のA社との商談に向けて、最近のメール、会議メモ、Teamsのやり取りから懸念点と次の確認事項をまとめて」と尋ねるアプリは、Work IQ APIと相性がよい用途です。
一方で、「SharePointの特定フォルダーにあるファイル一覧を毎晩取得してCSVに出力する」といった処理は、Work IQ APIよりも既存のMicrosoft GraphやSharePoint APIの方が適している可能性があります。Work IQ APIは、単なるデータ取得ではなく「業務文脈を推論する」場面で使うのが基本です。
管理者が確認すべき設定
Microsoft Work IQ API (preview)を組織で検証する前に、管理者は次の項目を確認してください。
| 確認項目 | 内容 | 見落とすと起きること |
|---|---|---|
| Copilotライセンス | Work IQ APIを呼び出すユーザーにMicrosoft 365 Copilotアドオンライセンスが必要 | 403エラーや利用不可の原因になる |
| Work IQサービスプリンシパル | 組織内でWork IQリソースをプロビジョニングする | トークン要求やAPI利用の前提が整わない |
| アプリ登録 | クライアントアプリ用のEntra IDアプリ登録を作成する | 認証・同意・リダイレクトURI設定ができない |
| 委任アクセス許可 | WorkIQAgent.Ask を追加し、管理者同意を付与する | スコープ不足でAPIを呼び出せない |
| 認証方式 | デスクトップ/CLI検証はパブリッククライアント、本番Webアプリは機密クライアント＋OBOを検討する | 検証用設定のまま本番化してしまう |
| データ保持 | API結果やユーザー入力をアプリ側で保存するか決める | プライバシー、監査、削除要求対応が曖昧になる |
| プレビュー利用 | SLAなし、仕様変更、レート制限の可能性を前提にする | 本番障害時の責任分界やサポート期待値がずれる |
公式クイックスタートでは、組織でWork IQ APIを有効化する手順として、Work IQサービスプリンシパルの作成、アプリ登録、WorkIQAgent.Ask 委任アクセス許可の追加、管理者同意が示されています。サーバーサイドのWebエージェントでは、ユーザーのトークンをOBOフローで交換する構成が想定されています。(Microsoft Learn)
開発者が実装時に注意すべきポイント
開発者が最初に押さえるべきポイントは、A2Aのリクエスト形式、認証トークン、ユーザーのローカル時間、会話継続の扱いです。
A2AではJSON-RPC形式を正しく使う
Work IQのA2A v1.0では、POST https://workiq.svc.cloud.microsoft/a2a/ に対して、jsonrpc、id、method、params を含むJSON-RPCエンベロープを送ります。メソッド名はURLパスではなく、リクエストボディ内に指定します。複数ターンの会話では、前回レスポンスの contextId を次のメッセージに渡します。(Microsoft Learn)
「今日」「今週」を扱うならLocationメタデータを入れる
業務アプリでは「今日の会議」「今週の顧客対応」「昨日のTeamsメッセージ」のような相対日付の質問がよく使われます。Work IQでは、この種の時間依存クエリを正しく接地するために Location メタデータが必要とされています。タイムゾーンを渡さないと、ユーザーの地域とずれた結果になる可能性があります。(Microsoft Learn)
MCPは開発者体験の改善に向いている
Work IQ CLIは、CLIモードとMCPサーバーモードで動作し、AIコーディングアシスタントをMicrosoft 365データに接続できます。たとえば、仕様書、会議メモ、Teamsの議論を参照しながら実装方針を整理するような開発者向けシナリオに向いています。利用にはNode.js、Microsoft 365 Copilotライセンス、管理者同意などが必要です。(Microsoft Learn)
既存のCopilot Chat API利用者はどう移行を考えるべきか
公式概要では、Work IQはCopilot Chat APIの本番向け進化形として位置づけられています。新規プロジェクトは最初からWork IQを使うことが推奨され、既存のCopilot Chat API統合は引き続き動作する一方、Copilot Chat APIは実験や初期開発向けのパブリックプレビューにとどまり、本番SLAの対象ではないと説明されています。(Microsoft Learn)
ただし、Work IQ API自体も公式クイックスタートではパブリックプレビューとされ、一般提供前に機能やAPIが変わる可能性があり、SLAは設定されていないと明記されています。したがって、現時点での現実的な方針は「新規開発はWork IQ前提で検証を始めるが、本番展開はGA、SLA、契約条件、サポート範囲を確認してから判断する」です。(Microsoft Learn)
移行を始める場合は、次の順序で進めると安全です。
| 手順 | やること | 判断基準 |
|---|---|---|
| 既存機能の棚卸し | Copilot Chat APIで何を質問し、どのデータを参照しているか整理する | 単純なチャットか、Microsoft 365データ推論が必要か |
| 認証設計の確認 | ユーザー委任、OBO、アプリ登録、管理者同意を見直す | アプリ専用認証に依存していないか |
| プロトコル選定 | A2A、MCP、将来のREST予定を分けて設計する | すぐ実装する部分と将来差し替える部分を分離できているか |
| レスポンス処理の再設計 | contextId、引用、エラー、レート制限、再試行を実装する | 失敗時にユーザーへ適切に説明できるか |
| パイロット運用 | 少人数のCopilotライセンス保有者で検証する | 権限、秘密度ラベル、回答品質、遅延が許容範囲か |
| 本番判定 | SLA、利用規約、サポート、監査要件を確認する | プレビューのリスクを業務側が受け入れられるか |
セキュリティとコンプライアンスで誤解しやすい点
Work IQ APIは、Microsoft 365の権限、秘密度ラベル、コンプライアンス制御を尊重します。これは大きな利点ですが、「アプリ側の責任がなくなる」という意味ではありません。
たとえば、Work IQ APIから得た回答をアプリのデータベースに保存する場合、その保存先の暗号化、アクセス制御、保持期間、削除要求対応、監査ログはアプリ側の設計対象になります。Work IQ APIの利用規約では、アクセス認証情報の管理、データのコピーやスクレイピングの制限、広告・マーケティング目的でのデータ利用禁止、セキュリティ・プライバシー上の責任などが示されています。(Microsoft Learn)
特に、次の用途は慎重に扱うべきです。
| 注意すべき設計 | リスク | 代替案 |
|---|---|---|
| 全ユーザーの業務データをまとめて定期取得する | 権限、保持、削除、利用規約上のリスクが高い | 必要時にユーザー文脈で問い合わせる |
| Work IQの結果を長期間保存する | 情報更新や削除要求に追随できない可能性がある | 保存を最小限にし、保持期間を明確化する |
| ライセンスなしユーザーに中継して使わせる | ライセンス回避と見なされる可能性がある | 対象ユーザーに適切なCopilotライセンスを割り当てる |
| API制限を回避するために多重化する | レート制限、利用停止、規約違反のリスクがある | スロットリング前提の再試行と利用量制御を実装する |
よくあるエラーと対処法
初期検証では、認証・同意・ライセンス・A2Aバージョン指定で詰まりやすくなります。
| 症状 | 主な原因 | 対処 |
|---|---|---|
401 Unauthorized | トークンの aud が api://workiq.svc.cloud.microsoft ではない | トークンのaudienceを確認し、Work IQ向けに取得する |
403 Forbidden | Microsoft 365 Copilotライセンスがない、または反映待ち | 対象ユーザーにライセンスを割り当て、必要に応じて15〜30分待つ |
Required scopes を含む403 | WorkIQAgent.Ask の管理者同意がない | Entra IDで委任アクセス許可を追加し、管理者同意を付与する |
AADSTS65001: consent required | 同意が未完了 | 管理者同意を再実行する |
JSON-RPCの Method not found | A2A-Version: 1.0 ヘッダーなしでv1.0メソッドを呼んでいる | ヘッダーを追加するか、v0.3形式に合わせる |
| 「今日」「今週」の回答がずれる | Location メタデータがない | ユーザーのタイムゾーンを渡す |
| レスポンスはあるが本文が空に近い | ライセンス反映直後、またはOffice製品内での利用前提のエージェントをヘッドレス実行している | 時間を置いて再試行し、対象エージェントの用途を確認する |
公式クイックスタートでも、401、403、同意不足、WAMのリダイレクトURI不備、ライセンス反映待ちなどがトラブルシューティング項目として挙げられています。検証環境では、エラー時にHTTPステータスだけでなく、トークンのaudience、scope、tenant、ユーザーライセンス、A2Aヘッダーをまとめてログに残すと原因を切り分けやすくなります。(Microsoft Learn)
展開前の実務チェックリスト
Microsoft Work IQ API (preview)を社内検証から本番候補に進める前に、次のチェックリストを使ってください。
| チェック | 確認内容 |
|---|---|
| ユースケース | Work IQ APIでなければ解きにくい「Microsoft 365横断の推論」か |
| 対象ユーザー | Microsoft 365 Copilotアドオンライセンスを持つユーザーに限定されているか |
| 管理者同意 | WorkIQAgent.Ask の付与・承認フローが文書化されているか |
| 認証 | デスクトップ検証、本番Webアプリ、サーバーサイド処理で認証方式を分けているか |
| データ保護 | API結果、プロンプト、ログ、引用情報の保存方針が決まっているか |
| プロトコル | A2A、MCP、REST予定を抽象化し、仕様変更に備えているか |
| エラー処理 | ライセンス不足、同意不足、レート制限、タイムゾーン不足をユーザーに説明できるか |
| 監査 | 誰が、どのアプリから、どのような用途で呼び出したか追跡できるか |
| プレビューリスク | SLAなし、仕様変更、サポート制限を関係者が理解しているか |
| 移行計画 | Copilot Chat API利用中の場合、Work IQへの段階移行計画があるか |
まず何から始めるべきか
最初に行うべきことは、Work IQ APIを使うべきユースケースを1つに絞ることです。おすすめは、メール、会議、Teams、SharePointのうち複数の情報源をまたぐ、少人数向けの社内パイロットです。
たとえば、次のようなテーマが向いています。
| パイロット例 | 期待できる効果 |
|---|---|
| 営業担当向けの商談準備エージェント | 顧客とのメール、会議、資料を横断して論点を整理できる |
| 開発チーム向けの仕様確認アシスタント | 会議メモ、仕様書、Teams議論を参照して実装方針をまとめられる |
| プロジェクト管理向けのリスク要約 | 最近の議論やドキュメントから遅延・依存関係のリスクを抽出できる |
| 情報システム部門向けの問い合わせ整理 | Teamsやメールの問い合わせ傾向を整理し、対応優先度を判断しやすくする |
最初から全社展開を目指すのではなく、Copilotライセンスを持つ限定ユーザーでA2Aのサンプルを動かし、認証、権限、回答品質、遅延、ログ、データ保持を検証してください。その後、必要に応じてMCPによる開発者体験の改善や、将来のREST対応を見据えたアプリ設計に進むのが安全です。
Microsoft Work IQ API (preview)は、Microsoft 365 Copilot時代のAIアプリ開発を「データを集める実装」から「業務文脈を安全に推論する実装」へ移す可能性があります。ただし、プレビュー段階では仕様・提供範囲・サポート条件が変わる可能性があります。管理者はライセンスと同意設定を確認し、開発者はA2A/MCPの実装条件とエラー処理を固め、セキュリティ担当はデータ保持と利用規約を確認する。この3点を押さえてから、小さなパイロットで検証を始めるのが現実的な第一歩です。
コメント