Microsoft 365 Copilotの「Work IQ APIs – Endpoints: Declarative Agent Access」は、Copilot上の宣言型エージェントをチャット画面だけで使うものから、アプリケーションや業務ワークフローから呼び出せる部品へ広げる更新です。ポイントは、Work IQエンドポイント経由で、Microsoft提供のファーストパーティエージェントや、テナント内で定義した宣言型エージェントにプログラムからアクセスできるようになることです。プレビューは2026年4月、一般提供は2026年6月が予定されていますが、Microsoft 365 Roadmapの予定は変更される可能性があります。(Microsoft)
管理者は「どのエージェントを、誰が、どのデータに基づいて、どのアプリから呼び出せるのか」を確認する必要があります。開発者は、認証、権限、エージェントID、APIのプレビュー仕様、エラー処理を早めに検証しておくべきです。
Microsoft 365 CopilotのWork IQ APIs更新で何が変わるのか
今回の更新は、Microsoft 365 Copilotの利用体験を「ユーザーがCopilot画面でエージェントを選んで会話する」だけに閉じず、外部アプリや業務システムからエージェントを呼び出せるようにするものです。
公式ロードマップの対象項目は、ID 559019「Microsoft Copilot (Microsoft 365): Work IQ APIs – Endpoints: Declarative Agent Access」です。説明では、Work IQエンドポイントを通じて、ファーストパーティおよびテナント定義の宣言型エージェントへプログラムからアクセスし、より大きなワークフロー内で専門エージェントを起動できるとされています。(Microsoft)
| 項目 | 内容 |
|---|---|
| 対象サービス | Microsoft Copilot (Microsoft 365) |
| 機能名 | Work IQ APIs – Endpoints: Declarative Agent Access |
| ロードマップID | 559019 |
| 状態 | In development |
| プラットフォーム | Developer |
| クラウド | Worldwide (Standard Multi-Tenant) |
| プレビュー | 2026年4月予定 |
| 一般提供 | 2026年6月予定 |
| 主な変更 | Work IQエンドポイント経由で宣言型エージェントをプログラムから呼び出せるようにする |
実務上は、Copilotエージェントを「会話用の追加機能」ではなく、「業務アプリケーションから呼び出すAI処理単位」として扱えるようになる点が重要です。
たとえば、以下のような利用シーンが考えられます。
| 利用シーン | 想定される使い方 |
|---|---|
| 社内ITヘルプデスク | 問い合わせ管理システムからITサポート用エージェントを呼び出し、社内ナレッジに基づく一次回答案を生成する |
| 営業支援 | CRMや案件管理画面から、提案資料・過去メール・会議内容を踏まえた次アクション案を取得する |
| 法務・契約確認 | 契約レビュー用エージェントに、該当案件の文書や社内基準を踏まえた確認観点を出させる |
| インシデント対応 | 障害対応フローの中で、Teamsメッセージ、会議、関連ドキュメントを踏まえた状況整理を依頼する |
ただし、これは「エージェントが何でも自動実行できる」という意味ではありません。Work IQ APIは、Microsoft 365の既存のアクセス許可、コンプライアンス、ガバナンス制御を維持しながらMicrosoft 365データを安全に推論するための仕組みとして説明されています。(Microsoft Learn)
Declarative Agent Accessを理解するための前提
宣言型エージェントとは、Microsoft 365 Copilotを業務シナリオに合わせてカスタマイズする仕組みです。開発者や管理者は、指示、アクション、ナレッジを定義して、特定業務向けのCopilot体験を作れます。宣言型エージェントは、Microsoft 365 Copilotと同じオーケストレーター、基盤モデル、信頼されたAIサービス上で動作します。(Microsoft Learn)
これまでの主な利用イメージは、ユーザーがMicrosoft 365 Copilot、Teams、Word、PowerPointなどのCopilot体験からエージェントを選び、会話する形でした。今回のDeclarative Agent Accessでは、そのエージェントを業務アプリやワークフローから呼び出せるようになるため、利用場面が大きく広がります。(Microsoft Learn)
変更前と変更後の違い
| 観点 | 変更前の中心 | 今回の更新で広がる範囲 |
|---|---|---|
| 利用方法 | Copilot UI上でユーザーが手動でエージェントを選択 | アプリケーションや業務フローからエージェントを呼び出す |
| 対象 | 主に対話型の利用 | バックエンド処理、ワークフロー、エージェント間連携 |
| 開発者の関与 | エージェント作成やプラグイン連携が中心 | 認証、API呼び出し、エラー処理、結果の組み込みも必要 |
| 管理者の関与 | 配布、ブロック、ユーザー割り当て | API経由の利用範囲、権限、監査、データ露出リスクの確認が重要 |
特に注意したいのは、API経由になることで「ユーザーが目で見てエージェントを選ぶ」場面が減る可能性がある点です。管理者は、どのアプリがどのエージェントを呼び出すのかを把握し、利用者に説明できる状態にしておく必要があります。
Work IQ APIとの関係
Work IQは、Microsoft 365 Copilotとエージェントの背後にあるインテリジェンスレイヤーです。Microsoftの説明では、メール、会議、ドキュメント、チャットなどのMicrosoft 365データに加え、仕事上の関係性やパターンを踏まえて、コンテキストの組み立て、応答の根拠付け、スキル選択、ツール呼び出しを調整するものとされています。(Microsoft Learn)
Work IQの重要な特徴は、リクエストがサインインユーザーのコンテキストで実行され、Microsoft 365のアクセス許可、秘密度ラベル、コンプライアンスポリシーが適用される点です。つまり、APIから呼び出せるようになるからといって、ユーザーが本来アクセスできないメール、ファイル、会議情報まで見えるようになるわけではありません。(Microsoft Learn)
サポートされるプロトコルの考え方
Work IQ APIでは、A2A、MCP、RESTといった複数のプロトコルが説明されています。Microsoft Learnでは、プレビュー段階でA2AとローカルMCPを利用でき、RESTとリモートMCPは近日公開予定とされています。(Microsoft Learn)
| プロトコル | 向いている用途 |
|---|---|
| A2A | 別のエージェントからWork IQへ処理を委任する |
| MCP | AIアシスタントや開発環境のツールとしてWork IQを使う |
| REST | アプリケーションやバックエンドから要求・応答型で呼び出す用途に向く見込み |
今回のロードマップ項目は「Declarative Agent Access」に焦点を当てたものです。したがって、開発時には「Work IQ API全体で何が使えるか」と「宣言型エージェント呼び出しで正式に使えるインターフェース」を分けて確認してください。プレビュー仕様を前提に本番設計を固めすぎると、GA前後の仕様変更で手戻りが発生しやすくなります。
利用者への影響
一般利用者にとっては、最初から画面上の大きな変化として見えるとは限りません。影響が出やすいのは、業務アプリや社内ポータル、申請フロー、問い合わせシステムなどにCopilotエージェントの応答が組み込まれるケースです。
たとえば、社内ポータルの「申請内容を確認する」ボタンを押したときに、裏側で宣言型エージェントが呼び出され、必要な確認事項や不足情報を返すような設計が考えられます。
利用者に説明すべきポイントは次の3つです。
| 説明すべき点 | 理由 |
|---|---|
| どの業務でCopilotエージェントが使われるのか | AIが関与する範囲を明確にするため |
| どのデータを参照する可能性があるのか | メール、ファイル、会議、Teamsメッセージなどへの不安を減らすため |
| 最終判断は誰が行うのか | エージェントの出力をそのまま業務判断に使う誤解を避けるため |
特に、承認、契約、セキュリティ、顧客対応のような高リスク業務では、エージェントの出力を「判断材料」として扱い、最終判断を人間または既存の承認プロセスに残す設計が安全です。
管理者が確認すべき設定とガバナンス
管理者が最初に見るべき場所は、Microsoft 365管理センターのエージェント管理です。Microsoft Learnでは、Microsoft 365 admin centerの「Agents > All agents」からエージェントレジストリを確認し、各エージェントの詳細、ユーザー、データとツール、権限などを確認できると説明されています。(Microsoft Learn)
エージェントの棚卸しを行う
まず、テナント内に存在するエージェントを棚卸しします。確認すべき項目は、単に「使われているか」ではなく、「API経由で呼び出されたときに問題がないか」です。
| 確認項目 | 見るべきポイント |
|---|---|
| エージェント名と所有者 | 誰が管理し、問い合わせ先が誰か |
| 作成元 | Microsoft提供、Copilot Studio、SharePoint、その他の作成元 |
| 利用対象ユーザー | 全社公開か、特定ユーザー・グループ向けか |
| ナレッジソース | SharePoint、OneDrive、コネクタ、埋め込みファイルなど |
| アクション・ツール | 外部API、MCPサーバー、プラグインを使うか |
| 権限 | 委任権限か、アプリケーション権限か、ユーザーに代わって何ができるか |
| 機密情報への接触 | メール、予定表、組織ファイル、顧客情報を扱うか |
Microsoft 365管理センターでは、エージェントに対してInstall、Uninstall、Block、Pin for usersなどの操作が用意されています。API経由の利用が広がる前に、不要なエージェントや管理者不明のエージェントはブロックまたは削除候補として整理しておくと安全です。(Microsoft Learn)
Data & toolsタブを重点的に確認する
「Data & tools」タブでは、そのエージェントがどのデータにアクセスでき、どの外部ソースやツールを参照し、どのようなアクションを実行できるかを判断するための情報が表示されます。Microsoft Learnでは、この情報を使って、テナント内に展開されたエージェントのガバナンス判断を行えると説明されています。(Microsoft Learn)
特に確認したいのは、以下の項目です。
| 項目 | 注意点 |
|---|---|
| Can read | 組織ファイル、メール、予定表など、読み取り可能なデータカテゴリを確認する |
| Knowledge sources | 参照元のSharePointサイトやファイルが適切か確認する |
| Tools | 外部システムに対して作成・更新・削除を行う可能性があるか確認する |
| Permissions | ユーザーに代わって実行される処理の範囲を確認する |
| Sensitivity labels | 埋め込みファイルや参照データの秘密度ラベルを確認する |
Data & toolsタブは読み取り専用で、データソースやツールを変更するには、Copilot StudioやFoundryなどの作成元でエージェント構成を更新する必要がある点にも注意してください。(Microsoft Learn)
ユーザー割り当ては段階展開にする
最初から全社に展開するのではなく、特定ユーザーまたは特定グループに絞ったパイロットを推奨します。Microsoft 365管理センターでは、エージェントのインストール対象を「Just me」「Entire organization」「Specific users/groups」から選べるため、部門単位や検証チーム単位で段階的に展開できます。(Microsoft Learn)
おすすめの展開順は次の通りです。
| フェーズ | 対象 | 目的 |
|---|---|---|
| 検証 | IT管理者、開発者、セキュリティ担当 | API呼び出し、権限、ログ、エラーを確認する |
| 小規模パイロット | 1部門または1業務チーム | 実業務での出力品質と運用負荷を確認する |
| 限定展開 | 関連部門全体 | 問い合わせ、教育、ガイドラインを整える |
| 全社展開 | 対象業務の利用者全体 | 標準業務フローとして定着させる |
開発者が確認すべき実装ポイント
開発者にとって重要なのは、単にAPIを呼び出せるかではありません。ユーザーの権限で正しく動くか、適切なエージェントを指定できるか、失敗時に安全に止められるか、出力を業務システムへどう戻すかまで設計する必要があります。
認証は委任認証を前提に設計する
Work IQでは、Microsoft Entra IDの委任認証が使われます。Microsoft Learnでは、リクエストはサインインユーザーのコンテキストで実行され、On-Behalf-Ofフローがサポートされ、アプリケーションのみの認証はサポートされないと説明されています。(Microsoft Learn)
つまり、バックエンドシステムが「システム権限だけで全ユーザーの情報を横断的に取得する」設計は前提にできません。業務アプリから呼び出す場合も、どのユーザーの代理として呼び出すのかを明確にする必要があります。
検証時には、次の要素を確認してください。
| 項目 | 確認内容 |
|---|---|
| アプリ登録 | テナント内アカウント向けに構成されているか |
| アクセス許可 | WorkIQAgent.Ask の委任アクセス許可が付与されているか |
| 管理者同意 | 必要なスコープに管理者同意が付与されているか |
| トークン | 対象ユーザーが api://workiq.svc.cloud.microsoft に合っているか |
| ユーザーライセンス | 呼び出しユーザーにMicrosoft 365 Copilotライセンスがあるか |
Work IQ APIのクイックスタートでは、組織でWork IQサービスプリンシパルを作成し、WorkIQAgent.Ask 委任アクセス許可を持つアプリ登録を用意する手順が示されています。(Microsoft Learn)
エージェントIDは不透明な値として扱う
特定のエージェントを呼び出す場合、エージェントIDの扱いが重要です。Microsoft Learnでは、WorkIQ CLIの list-agents コマンドやMicrosoft 365 Copilot ChatのURLからエージェントIDを確認する方法が説明されています。また、エージェントIDは分解・解析せず、不透明な文字列としてそのままAPIに渡すよう注意されています。(Microsoft Learn)
やってはいけない実装は、エージェントIDの一部をテナントIDや種類コードのように解釈して条件分岐することです。ID形式は将来変わる可能性があるため、設定値として安全に保存し、管理者が更新できる設計にしておくべきです。
プレビュー仕様のまま本番固定しない
Work IQはプレビュー段階では、機能とAPIが一般提供前に変更される可能性があり、SLAも設定されていないとされています。(Microsoft Learn)
そのため、2026年6月のGA予定前に開発を始める場合は、以下を前提にしてください。
| 設計項目 | 推奨 |
|---|---|
| API仕様 | ラッパー層を作り、呼び出しコードをアプリ全体に散らさない |
| エラー処理 | 401、403、空応答、タイムアウトを明確に分ける |
| ログ | プロンプト全文や応答全文を無条件に保存しない |
| 設定 | エンドポイント、エージェントID、タイムアウトを環境別に管理する |
| リリース | GA後に仕様差分を確認してから本番範囲を広げる |
よくあるエラーを先に想定する
Work IQ APIのクイックスタートでは、401 Unauthorized、403 Forbidden、スコープ不足、ライセンス不足、空の応答などのトラブルシューティング例が示されています。たとえば、403 ForbiddenはユーザーにMicrosoft 365 Copilotライセンスがない場合や、WorkIQAgent.Ask への同意が不足している場合に発生し得ます。(Microsoft Learn)
開発時には、以下のように利用者に分かるメッセージへ変換すると運用しやすくなります。
| 技術的な症状 | 利用者・管理者向けの表示例 |
|---|---|
| 401 Unauthorized | 認証情報が無効です。再サインインしてください。 |
| 403 Forbidden | この機能を使う権限またはライセンスがありません。管理者に確認してください。 |
| Required scopes | 必要な管理者同意が不足しています。アプリ登録のAPIアクセス許可を確認してください。 |
| 空の応答 | エージェントがこのコンテキストで応答できない可能性があります。対象エージェントを確認してください。 |
| タイムアウト | エージェント処理に時間がかかっています。時間をおいて再実行してください。 |
特に、Word、Excel、PowerPointのようなOffice製品コンテキストで動作する一部エージェントは、ヘッドレスなA2A呼び出しでは有用な応答を生成しない場合があると説明されています。業務システムから呼び出す前に、対象エージェントがAPI経由の利用に適しているかを必ず検証してください。(Microsoft Learn)
既存環境からの移行で注意すべき点
既にCopilot Chat API、独自RAG、外部LLM連携、Copilot Studioエージェントを使っている組織では、今回の更新を単なる追加機能として見るのではなく、エージェント連携の設計を見直す機会として捉えるべきです。
Copilot Chat APIを使っている場合
Microsoft Learnでは、Work IQはCopilot Chat APIの運用環境向けの進化として位置付けられ、新しいプロジェクトはWork IQを基に構築することが推奨されています。一方で、既存のCopilot Chat API統合は引き続き機能するものの、実験や初期開発向けのパブリックプレビューに残ると説明されています。(Microsoft Learn)
移行時には、以下を確認してください。
| 確認項目 | 見直し内容 |
|---|---|
| 認証方式 | Work IQの委任認証とOBOフローに合わせる |
| 呼び出し単位 | 汎用チャットではなく、目的別エージェント呼び出しに整理する |
| 出力形式 | 業務アプリに戻す形式を定義する |
| 監査 | どのユーザーが、どのエージェントを、どの処理で呼んだか追跡できるようにする |
| 例外処理 | ライセンス不足、権限不足、エージェント非対応を分けて処理する |
独自RAGを使っている場合
独自にベクターデータベースや社内検索基盤を作っている場合でも、すぐに置き換える必要はありません。ただし、Microsoft 365データを扱う用途では、Work IQがアクセス許可やコンプライアンス制御を維持した形で推論できる点が強みになります。(Microsoft Learn)
判断基準は次の通りです。
| 現在の構成 | Work IQを検討しやすいケース |
|---|---|
| SharePointやOneDrive中心のRAG | 権限トリミングや秘密度ラベル対応の運用負荷が大きい |
| メール・会議・Teamsを含む独自連携 | データソースが増え、同期や監査が複雑化している |
| 部門別AIアプリ | 部門ごとの宣言型エージェントとして再整理したい |
| 外部業務システム中心 | Microsoft 365文脈と外部データを組み合わせたい |
展開前チェックリスト
GA予定の2026年6月までに、管理者と開発者は以下を確認しておくと移行リスクを減らせます。
| 担当 | チェック項目 | 完了目安 |
|---|---|---|
| 管理者 | Microsoft 365 Roadmap ID 559019のステータス、対象クラウド、GA予定を確認する | すぐ |
| 管理者 | Agents > All agentsでエージェントを棚卸しする | プレビュー期間中 |
| 管理者 | Data & tools、Permissions、Securityタブを確認する | プレビュー期間中 |
| 管理者 | 全社展開前にSpecific users/groupsでパイロット対象を限定する | GA前 |
| 管理者 | 利用者向けに、AI利用範囲と最終判断ルールを明文化する | GA前 |
| 開発者 | Work IQの認証方式、WorkIQAgent.Ask、管理者同意を検証する | プレビュー期間中 |
| 開発者 | 呼び出すエージェントIDを確認し、設定値として管理する | プレビュー期間中 |
| 開発者 | 401、403、空応答、タイムアウトの処理を実装する | GA前 |
| 開発者 | 応答ログに機密情報を保存しすぎない設計にする | GA前 |
| 開発者 | GA後にAPI仕様差分を確認し、本番範囲を広げる | GA後 |
失敗しやすいポイント
この更新で特に失敗しやすいのは、「CopilotエージェントをAPIで呼べるなら、既存の自動化にそのまま組み込める」と考えてしまうことです。実際には、権限、ライセンス、エージェントの実行コンテキスト、出力の扱いまで含めて設計する必要があります。
| 失敗例 | 対策 |
|---|---|
| 全社公開エージェントをそのまま業務アプリから呼び出す | まず特定ユーザー・グループでパイロットする |
| アプリケーション権限で横断的に呼び出せると誤解する | Work IQは委任認証前提で、アプリケーションのみの認証はサポートされない点を確認する |
| エージェントIDを解析して実装する | 不透明な文字列として保存し、変更可能な設定にする |
| Officeアプリ文脈のエージェントをヘッドレスで呼び出す | API経由で有用な応答が返るか個別に検証する |
| 応答全文をログ保存する | 秘密度ラベルや個人情報を考慮し、ログは最小化する |
| プレビュー仕様で本番展開する | GA後に仕様、SLA、制限事項を再確認してから範囲を広げる |
よくある疑問
この更新は一般ユーザー向けですか？
直接の対象は開発者と管理者です。ただし、業務アプリやワークフローに組み込まれると、一般ユーザーも間接的に影響を受けます。ユーザー向けには、「どの業務でAIエージェントが使われるのか」「出力をどう扱うべきか」を説明する必要があります。
すべての宣言型エージェントをAPIで呼び出せますか？
ロードマップでは、ファーストパーティおよびテナント定義の宣言型エージェントへのプログラムアクセスが説明されています。ただし、実際にどのエージェントがどの方式で有用に呼び出せるかは、エージェントの種類、構成、ユーザー権限、プレビュー仕様に依存します。Officeアプリの文脈を前提とするエージェントは、ヘッドレス呼び出しで期待通りに動かない場合があります。(Microsoft)
Work IQ APIはセキュリティをバイパスしますか？
バイパスしません。Work IQのリクエストはサインインユーザーのコンテキストで実行され、Microsoft 365のアクセス許可、秘密度ラベル、コンプライアンスポリシーが適用されます。ただし、APIの応答を受け取った後に、別システムへ保存・転送する部分はアプリ側の責任になります。(Microsoft Learn)
管理者は今すぐ何をすべきですか？
最初に、Microsoft 365管理センターでエージェント一覧を確認し、不要なエージェント、所有者不明のエージェント、外部ツールを使うエージェントを整理してください。次に、開発者と一緒にWork IQ APIの検証環境を作り、特定グループだけで呼び出しテストを行うのが現実的です。
まとめ：まずはエージェントの棚卸しと小規模検証から始める
Microsoft 365 Copilotの「Work IQ APIs – Endpoints: Declarative Agent Access」は、宣言型エージェントを業務アプリやワークフローに組み込むための重要な更新です。チャット画面で使うCopilotから、業務プロセスの中で呼び出すCopilotへ進むための基盤と捉えると分かりやすいでしょう。
一方で、プログラムから呼び出せるようになるほど、管理者のガバナンスと開発者の設計責任は重くなります。まずは、テナント内のエージェントを棚卸しし、Data & tools、Permissions、ユーザー割り当てを確認してください。そのうえで、特定業務・特定グループに限定したパイロットを行い、認証、権限、出力品質、ログ運用、例外処理を検証するのが安全な進め方です。
コメント