執筆している2026年10月2日時点の情報です。Cowork は更新が速い機能のため、最新情報は必ず公開情報（本記事末尾の参考リンク）もあわせてご確認ください。
「社内のメールや文書を踏まえて回答するアプリを作りたい」
「Work IQ APIを使えば、検索からメール送信まで任せられる？」
「バックエンドから呼べるなら、利用者なしのバッチでも動く？」
Microsoft Copilotの業務情報を、自作のアプリやエージェントから利用するための仕組みとして、Microsoft Work IQ APIが案内されています。
ただし、設計時には、情報をもとに回答することと、外部へ操作を実行することを分ける必要があります。
特にWork IQ REST APIには、認証方式、応答形式、対応する処理について明確な制限があります。
本記事では、公式資料に基づき、接続方式の役割とREST APIの設計ポイントを整理します。実行済みの検証レポートではなく、実装前に対応範囲を理解するための解説です。
1. 最初に結論：REST APIは「回答する仕組み」であり、万能な操作APIではありません
Work IQ REST APIは、Microsoft Copilotとの複数ターンの対話を、プログラムから利用するためのAPIです。
業務情報やWeb情報を根拠にした回答を受け取れますが、公式資料では次の制限が示されています。
| 項目 | REST APIの対応 |
|---|---|
| 業務情報を踏まえた自然言語の対話 | 対応 |
| 複数ターンの会話 | 対応 |
| OneDrive・SharePointファイルを文脈として指定 | 対応 |
| テキストの応答 | 対応 |
| メール送信・会議設定・ファイル作成などのアクション | 非対応 |
| コードインタープリターや画像生成などのツール | 非対応 |
| 長時間タスク | 非対応。ゲートウェイタイムアウトが発生しやすいと説明 |
たとえば、「会議の準備に必要な情報を整理する」と「参加者へ会議案内を送信する」は、別の処理です。
回答を受け取れたことを、メール送信やファイル保存が完了したこととして扱わないことが、最初の設計ポイントです。
出典：Microsoft Learn — Work IQ REST API Overview
2. Work IQは、業務情報と文脈をアプリへつなぐ
Work IQは、Microsoft 365のデータと業務の文脈を組み合わせ、AIが仕事に関する情報を扱えるようにする層として説明されています。
公式のAPI概要では、次の情報が推論対象として挙げられています。
- メール
- 会議・予定表
- OneDrive・SharePointの文書
- Teamsのメッセージ
- 人や組織の情報
- Plannerのプラン
- エンタープライズ検索の結果
ただし、この一覧は、すべての保存場所やアイテムを無条件に取得できるという意味ではありません。利用者の権限、対象データの対応条件、適用されるポリシーなどが関係します。
検索結果だけでなく、情報を整理した回答を受け取る
REST APIでは、自然言語の質問を渡し、業務情報などを根拠に生成された回答を受け取れます。
このように、回答を参照情報に結び付けることをグラウンディングと呼びます。
ファイル一覧を返すだけのAPIと同じ感覚ではなく、必要な情報の検索と、それを踏まえた回答生成を委ねる仕組みとして考えると分かりやすくなります。
出典：
Microsoft Work IQ API ／ Work IQ REST API Overview
3. REST・MCP・A2Aは、呼び出す側の構成から選ぶ
Work IQには、複数の接続方式があります。
| 方式 | 役割 | 向いている構成の例 |
|---|---|---|
| REST | アプリからリクエストを送り、応答を受け取る | Webアプリやバックエンドが質問し、結果を表示する |
| MCP | AIアシスタントが外部機能をツールとして呼び出す | 開発環境やAIクライアントから業務情報を参照する |
| A2A | エージェント同士で構造化されたメッセージやタスクをやり取りする | 別のエージェントからWork IQへ処理を委任する |
**MCP（Model Context Protocol）**は、AIアプリと外部の情報・ツールを接続するためのプロトコルです。Work IQではLocal MCPとRemote MCPが案内されています。
**A2A（Agent-to-Agent）**は、エージェント間の通信や委任に使うプロトコルです。
公式資料でも、この選び方は推奨であって、厳密な使い分けの規則ではないとされています。
プロトコルの名前だけで、実行できる操作を判断しない
ここで注意したいのが、接続方式と、提供される機能は別という点です。
「MCPなら何でも操作できる」「A2Aなら長時間処理が必ず使える」とは限りません。選択した方式が公開している機能と、その制限を個別に確認します。
また、本記事で扱うREST APIの制限を、確認せずにWork IQ全体へ広げることも避けましょう。
出典：Microsoft Learn — Microsoft Work IQ API：Supported protocols／Choose a protocol
4. 認証は「サインインした利用者」が前提
Work IQ APIの公式概要では、Microsoft Entra IDの委任認証を使うと説明されています。
委任認証とは、サインインした利用者の文脈でアプリが処理を行う方式です。
重要な条件は次の3つです。
- リクエストは、サインインした利用者の文脈で実行される
- OBO（On-Behalf-Of）フローに対応
- アプリケーション単独認証は非対応
OBOは、アプリ単独認証ではありません
OBOは、バックエンドが利用者に代わって下流のAPIを呼び出す際に使う認証フローです。
概念的には、次のような構成になります。
サインインした利用者
↓
フロントエンド
↓
バックエンド
↓ 利用者に代わるOBOフロー
Work IQ API
これは認証の考え方を示す図であり、トークンの取得手順や必要なスコープを網羅するものではありません。
「バックエンドから呼べる」ことと、「利用者の文脈が不要である」ことは別です。
そのため、クライアント資格情報だけを使い、アプリ単独で全社データを処理するバッチを前提に設計すると、対応条件に合いません。
利用者の権限が、回答の範囲に関係する
公式資料では、Microsoft 365の権限、秘密度ラベル、コンプライアンスポリシーが適用されると説明されています。
同じ質問でも、利用者がアクセスできる情報が異なれば、得られる回答も異なる可能性があります。
また、アプリ側で回答をキャッシュしたり、共有画面へ表示したりする場合、その取り扱いは別途設計が必要です。
ある利用者の権限で取得した回答を、別の利用者にも無条件で見せてよいわけではありません。
出典：Microsoft Learn — Microsoft Work IQ API：Authentication and security
5. 「回答」「確認」「実行」を分けたアプリ構成にする
たとえば、業務情報から進捗を整理し、関係者への連絡を支援するアプリを考えてみます。
以下は説明用の構成例です。実装済みのシステムや検証結果ではありません。
利用者が質問する
↓
Work IQ REST API
業務情報を踏まえたテキストの回答
↓
アプリに確認用の内容を表示する
↓
利用者が内容・宛先・操作を確認する
↓
必要な場合だけ、別の実行用APIで操作する
↓
操作の成功・失敗を確認して表示する
REST APIへの依頼例は、次のようにします。
指定したプロジェクトについて、確認できる進捗と未解決事項を整理してください。
確定した事実と、情報が不足している点を分けてください。
関係者に追加確認すべき質問も挙げてください。
その回答を実際に送信したい場合は、送信機能を提供する別のAPIやツールと、その操作に必要な権限・承認を設計します。
文章の生成と、成果物の作成も別
REST APIがテキストで報告案を返すことと、Wordファイルを作成してSharePointへ保存することも異なります。
| 得たい結果 | 分けて考える処理 |
|---|---|
| 報告内容を画面で読む | テキスト回答を表示する |
| Word文書として保存する | 文書生成と保存の処理を別途用意する |
| 関係者にメールを送る | 宛先確認と送信処理を別途用意する |
| 会議を設定する | 日時・参加者の確認と予定作成を別途用意する |
AIの回答文ではなく、実行したサービスの結果をもとに完了を判定することが重要です。
REST APIの制限の出典：Microsoft Learn — Known limitations
6. Web検索の無効化は「会話全体の設定」と思い込まない
Work IQ REST APIでは、既定で次の両方を利用すると説明されています。
- エンタープライズ検索によるグラウンディング
- Web検索によるグラウンディング
社内情報だけをもとに回答してほしい場合、Web検索をどう扱うかは重要な設計項目です。
特に注意したいのが、Web検索の無効化は1ターンごとの指定である点です。
公式資料では、Web検索を必要としない各メッセージで、無効化を指定する必要があるとされています。
1回目の質問：Web検索を無効化
2回目の質問：Web検索を無効化
3回目の質問：Web検索を無効化
上記は設計上のイメージであり、実際のリクエスト形式ではありません。
最初の質問だけで無効化し、その設定が以後の会話全体へ自動的に引き継がれると考えないようにします。
アプリで常に無効化する方針なら、各リクエストへ必要な指定を付ける共通処理を用意し、追加質問や再試行時にも適用されることを確認するのが一案です。
ただし、Web検索を無効化することだけで、必ず指定した1ファイルだけが回答根拠になる、とまでは判断できません。情報源の指定と検索範囲は、別途確認します。
出典：Microsoft Learn — Work IQ REST API Overview
7. 「独自RAGが全部不要」とは言い切らない
**RAG（検索拡張生成）**は、関連情報を検索し、その情報を使ってAIの回答を生成する構成です。
独自に作る場合、データ収集、索引化、権限の扱い、情報検索、モデルへの受け渡しなどを設計する必要があります。
Work IQ REST APIを使うと、対応するMicrosoft 365の業務情報について、この検索・回答生成の処理を委ねられます。
ただし、次のような要件があれば、適合性を別途評価する必要があります。
| 確認する要件 | 設計上の問い |
|---|---|
| データの対応範囲 | 必要な保存場所・形式の情報を扱えるか |
| 検索結果の制御 | 独自のランキングや抽出規則が必要か |
| 応答形式 | テキスト応答で足りるか、厳密な構造化データが必要か |
| 処理時間 | 長時間の集計・分析を要求していないか |
| 認証方式 | 委任認証で成立する利用シナリオか |
| 保存・監査 | アプリ側の記録や再利用をどう管理するか |
公式REST概要には、セマンティックインデックスの制限が適用されることも記載されています。
APIが利用できることと、必要な情報が必ず見つかることは別です。また、生成された回答には誤りが含まれる可能性があるため、利用前の確認が必要です。
このため、本記事では「すべての独自検索基盤を置き換えられる」「常に最新で正確な回答になる」とは説明しません。
出典：Microsoft Learn — Work IQ REST API Overview
8. 実装前に確認したいチェックリスト
最初の試作では、操作を増やすより、利用者が質問してテキスト回答を確認する範囲から始めると、境界を整理しやすくなります。
以下は、公式の対応条件をもとにした筆者の設計チェックリストです。
| 観点 | 確認項目 |
|---|---|
| 認証 | サインインした利用者の委任認証になっているか |
| バックエンド | OBOを使う場合、利用者の文脈を正しく引き継ぐか |
| 会話管理 | 別ユーザーの会話や回答を混在させないか |
| 情報源 | 対象データと検索の制限を確認したか |
| Web検索 | 無効化が必要な各メッセージに指定しているか |
| 対応範囲 | RESTへ送信・予定作成・ファイル作成を期待していないか |
| 処理時間 | 長時間タスクを前提にしていないか |
| 表示と再利用 | 回答の保存先・共有先・閲覧範囲を適切に管理するか |
| 実行処理 | 別APIで操作する場合、承認・権限・重複実行対策があるか |
| 費用 | Copilot Creditsによる利用量と予算を確認できるか |
Work IQ APIは、公式資料ではCopilot Creditsによる従量課金とされています。APIの利用規約も適用されます。
既存のCopilotライセンスがあることだけを理由に、API利用が追加費用なしと判断しないようにしましょう。
また、今回確認した概要資料だけでは、各プロトコルのGA／Preview区分や地域別の利用条件を一律に確定できません。実装する方式の最新資料で確認してください。
出典：Microsoft Learn — Microsoft Work IQ API：Licensing requirements
9. まとめ
Work IQ APIは、Microsoft 365の業務情報を利用するアプリやエージェントを考えるうえで、有力な選択肢です。
ただし、REST APIを使う場合は、次の境界を押さえる必要があります。
- サインインした利用者の委任認証が前提で、アプリ単独認証は非対応
- 業務情報・Web情報を根拠にした複数ターンの対話に対応
- 応答はテキストで、送信・会議設定・ファイル作成などは別の処理
- 長時間タスクは非対応
- Web検索の無効化は、必要な各メッセージで指定
- 返された回答の確認と、アプリ側の情報管理は引き続き必要
「AIに依頼すれば最後まで全部やってくれる」と一括りにせず、回答する仕組み、利用者が確認する仕組み、操作を実行する仕組みを分けることが、実装後の手戻りを減らすポイントです。
参考リンク
いずれも2026年10月2日確認。
本記事について
本記事は、公開情報をもとに内容を整理し、できるだけ分かりやすく解説することを目的として作成しています。記載内容は個人の見解であり、所属組織の公式見解を示すものではありません。少しでもお役に立てればうれしいです。
ご質問・追記要望は本ページのコメント欄までお寄せください。