Work IQ Chat APIは、Microsoft 365 Copilotの会話機能を独自アプリやエージェントに組み込み、メール、会議、ドキュメント、Teamsメッセージなどの業務コンテキストを踏まえて応答させるためのAPIです。ポイントは、単にMicrosoft 365データを検索するのではなく、Copilotの会話・推論・引用付き回答をアプリ側から利用できるようになることです。
2026年6月3日に更新されたMicrosoft Learnの公式情報では、Work IQ Chat APIは/betaのAPIとして案内されており、本番アプリケーションでの利用はサポート対象外とされています。一方で、Work IQ API全体は2026年6月16日に一般提供へ進むと告知されており、管理者は認証、同意、課金、展開範囲を早めに確認しておく必要があります。(Microsoft Learn)
Microsoft 365 CopilotのAI/Copilot更新で何が変わるのか
Work IQ Chat APIの大きな変化は、Microsoft 365 Copilotの会話能力を「Copilot画面の中だけ」ではなく、業務アプリ、社内ポータル、カスタムエージェント、外部のAIオーケストレーターから使いやすくなる点です。
従来、Microsoft 365上の業務データをAIで扱うには、Graph APIでデータを取得し、別途インデックスを作り、権限管理や機密ラベル、監査、検索精度を自前で考慮する必要がありました。Work IQ APIは、Microsoft 365の既存のアクセス許可、コンプライアンス、ガバナンス制御を維持しながら、業務データを安全に推論できるアプリやエージェントを作るための仕組みとして説明されています。(Microsoft Learn)
特にChat APIは、ユーザーが自然文で質問し、Copilotが業務コンテキストに基づいて回答する「会話体験」をアプリに埋め込むための実装面が明確になった点が重要です。
| これまでの実装で起きがちな課題 | Work IQ Chat APIで変わる点 |
|---|---|
| Microsoft 365データを外部に同期・インデックス化する必要がある | Microsoft 365の信頼境界内で、既存の権限を尊重しながら業務データを参照しやすい |
| Graph APIで取得したデータをアプリ側で要約・推論する必要がある | Copilotによる会話応答として、合成済みの回答を受け取れる |
| 独自RAGの権限管理、鮮度、監査設計が重くなりやすい | Microsoft 365 Copilotの基盤を使い、権限トリミングやガバナンスに沿った設計にしやすい |
| 1問1答の検索体験に寄りやすい | 複数ターンの会話を作成・継続できる |
| ユーザー体験が社内アプリとCopilotで分断される | 業務アプリ内にCopilotベースの会話体験を組み込める |
ただし、Work IQ Chat APIは「何でもできる万能API」ではありません。公式ドキュメントでは、REST APIはファイル作成、メール送信、会議作成などのアクションや、コードインタープリター、画像生成、長時間タスクをサポートしないとされています。回答もテキスト中心であり、AI生成内容は確認が必要です。(Microsoft Learn)
Work IQ Chat APIの基本仕様
Work IQ Chat APIでは、まずCopilot会話を作成し、その会話IDを使って同期応答またはストリーミング応答で会話を継続します。
| 処理 | 主なエンドポイント | 役割 |
|---|---|---|
| 会話を作成 | POST https://workiq.svc.cloud.microsoft/rest/beta/copilot/conversations | 新しいCopilot会話を作成し、後続リクエストで使うconversationIdを取得する |
| 同期会話を継続 | POST https://workiq.svc.cloud.microsoft/rest/beta/copilot/conversations/{conversationId}/chat | プロンプトを送信し、完了した応答をまとめて受け取る |
| ストリーミング会話を継続 | POST https://workiq.svc.cloud.microsoft/rest/beta/copilot/conversations/{conversationId}/chatOverStream | Server-Sent Eventsで応答を段階的に受け取る |
会話作成は空のJSONボディで実行でき、成功時は201 CreatedとcopilotConversationが返ります。同期会話では200 OK、ストリーミング会話ではtext/event-streamのSSEとしてcopilotConversationが返る仕様です。(Microsoft Learn)
リクエストで特に重要なパラメーター
同期・ストリーミングのチャットでは、次のパラメーターを意識する必要があります。
| パラメーター | 必須/任意 | 確認ポイント |
|---|---|---|
message | 必須 | ユーザーが送信するプロンプト本文。業務アプリ側では、画面上の入力値や定型プロンプトをここに入れる |
locationHint | 必須 | タイムゾーンなどのユーザー位置情報。日時を含む質問では回答精度に影響しやすい |
additionalContext | 任意 | アプリ側が持つ補足情報を会話の根拠として追加する。社内FAQの抜粋、画面上の案件情報などに向く |
contextualResources | 任意 | OneDrive/SharePointファイルを文脈として指定したり、Web検索グラウンディングを制御したりする |
webContext.isWebEnabled | 任意 | Web検索を使うかどうかを制御する。Web検索をオフにする指定は1ターン単位で行う必要がある |
公式例では、OneDriveまたはSharePointファイルのURIをcontextualResources.filesに渡し、そのファイルを要約する使い方や、webContext.isWebEnabledをfalseにしてWeb検索グラウンディングをオフにする使い方が示されています。(Microsoft Learn)
利用者への影響：Copilotが「今の仕事」に近い場所で使える
利用者にとっての変化は、Microsoft 365 Copilotを開いて質問するだけでなく、日常的に使う業務画面の中でCopilotに近い回答を得られる可能性が広がることです。
たとえば、次のような使い方が考えられます。
| 活用シーン | 具体例 |
|---|---|
| 社内ポータル | 「今週対応すべき人事・総務関連のタスクをまとめて」と聞く |
| 営業支援アプリ | 顧客とのメール、会議、関連提案書を踏まえて商談準備メモを作る |
| プロジェクト管理画面 | Teamsの会話、会議、関連ドキュメントから未完了タスクを整理する |
| ITヘルプデスク | ユーザーの問い合わせ内容に、社内ナレッジや直近のやり取りを加えて回答案を作る |
| 経営・部門レポート | 関連ファイルや会議内容をもとに、意思決定に必要な論点を要約する |
ただし、利用者が見られる情報が増えるわけではありません。Work IQは、Microsoft 365の権限、秘密度ラベル、情報バリアなどを尊重し、サインインしているユーザーがアクセスできる範囲で動作すると説明されています。管理者や開発者は「APIを使うと全社データが丸見えになる」という誤解を避けつつ、アクセス権が広すぎるSharePointサイトや共有ファイルがないかを先に点検すべきです。(Microsoft Learn)
管理者への影響：Entra ID、同意、課金、エージェント管理を分けて確認する
管理者が最初に確認すべきなのは、Work IQ Chat APIそのものの設定だけではありません。Microsoft 365 Copilotのエージェント管理、Microsoft Entra IDのアプリ同意、Copilot Creditsや従量課金、ユーザー・グループ単位の展開制御を分けて整理する必要があります。
Work IQ APIのサービスプリンシパルを作成する
Work IQ APIを組織で使うには、管理者がWork IQ APIのサービスプリンシパルを作成する必要があります。これは組織単位の初期設定で、アプリがWork IQ API向けのアクセストークンを要求できるようにするための準備です。公式ドキュメントでは、Azure CLIで次のアプリIDを使って作成する手順が示されています。(Microsoft Learn)
az ad sp create --id fdcc1f02-fc51-4226-8753-f668596af7f7この設定が抜けていると、アプリ登録のAPIアクセス許可でWork IQが検索できない、または認証設定が進まない原因になります。開発チームだけで完結しないため、早い段階でEntra ID管理者を巻き込むのが安全です。
WorkIQAgent.Askの管理者同意を確認する
Work IQ Chat APIで使う最小権限は、委任された職場または学校アカウント向けのWorkIQAgent.Askです。個人Microsoftアカウントとアプリケーション権限はサポートされていません。(Microsoft Learn)
WorkIQAgent.Askは、サインインしているユーザーに代わってWork IQエージェントへ質問し、回答を受け取るための権限です。公式の権限リファレンスでは、この権限には管理者同意が必要であり、サインインユーザーにスコープされたMicrosoft 365リソースへの読み取り・書き込みアクセスを含むと説明されています。(Microsoft Learn)
実務では、次の観点でレビューします。
| 確認項目 | 判断基準 |
|---|---|
| どのアプリに同意するか | 社内開発アプリ、Copilot Studio/Foundry連携、サードパーティアプリを区別する |
| 誰が利用するか | 全社ではなく、まず検証用グループ・部門単位で始める |
| 何の業務データを扱うか | メール、会議、Teams、SharePoint、OneDriveのどれを主な対象にするか明確にする |
| 同意の取り消し手順 | 不要になったアプリはEntra IDでWorkIQAgent.Askの管理者同意を取り消す |
| 既存トークンの扱い | 同意を取り消しても既存トークンは期限切れまで有効な場合があるため、即時停止の期待値を調整する |
Microsoft Learnでは、管理者はEntra IDのアプリ登録からWorkIQAgent.Askへの同意を付与または取り消せるとされています。取り消し後は新しいトークンを発行できなくなりますが、既存トークンは有効期限まで残る点に注意が必要です。(Microsoft Learn)
Copilot Creditsと従量課金を確認する
課金面は特に混乱しやすいポイントです。Work IQ REST APIのプレビュードキュメントでは、Microsoft 365 Copilotアドオンライセンスを持つユーザーはREST APIを追加コストなしで利用でき、アドオンライセンスを持たないユーザーは現時点でサポートされないと説明されています。(Microsoft Learn)
一方、2026年6月3日のPartner Center告知では、Work IQ APIは2026年6月16日に一般提供となり、Copilot Creditsを使った従量課金モデルになると案内されています。カスタムエージェントやサードパーティAIプラットフォーム経由でWork IQ APIを使う場合は課金対象となり、管理者はMicrosoft Admin Centerで支払い方法、アクセス方針、利用上限、アラートを設定する必要があるとされています。(Microsoft Learn)
つまり、展開前には次のように整理してください。
| 状況 | 管理者が確認すべきこと |
|---|---|
| プレビュー検証中 | Microsoft 365 Copilotライセンス、APIのプレビュー条件、本番利用不可の扱いを確認する |
| 2026年6月16日以降に利用予定 | Copilot Credits、従量課金、支払い方法、利用上限、アラートを確認する |
| Copilot Studio/Foundry/サードパーティ経由で利用 | Work IQ APIの呼び出しが課金対象になるか、誰の利用として計上されるかを確認する |
| Microsoft製の事前構築済みエージェントを使う | カスタム/サードパーティ利用とは課金条件が異なる可能性があるため、管理センターと契約条件を確認する |
料金やSKUは変更される可能性があります。社内展開時は、Microsoft Learnだけでなく、Microsoft 365管理センター、契約情報、CSP/EAの案内を合わせて確認するのが確実です。
Microsoft 365管理センターでエージェントの公開範囲を制御する
Work IQ Chat APIを使うエージェントやアプリを展開する場合、Microsoft 365 Copilotのエージェント管理も重要です。Microsoft 365管理センターでは、Copilotエージェントの有効化、無効化、割り当て、ブロック、削除を管理できます。ユーザーがアクセスできるのは、管理者が許可したエージェントに限られると説明されています。(Microsoft Learn)
また、Agent Registryでは組織内で利用可能なエージェントを一覧し、Microsoft製、外部パートナー製、組織公開、作成者共有などの種類で確認できます。高リスクなエージェント、所有者不在のエージェント、過剰な権限、機密データアクセスなどの観点も管理対象になります。(Microsoft Learn)
展開時は、いきなり全社公開せず、次の順序で進めると失敗しにくくなります。
| フェーズ | やること |
|---|---|
| 検証 | 開発者・管理者・業務部門の少人数でAPI動作、回答品質、権限トリミングを確認する |
| 限定展開 | 部門またはセキュリティグループ単位で公開し、想定外のデータ参照やコスト増を確認する |
| 利用ルール整備 | 機密情報、顧客情報、外部Web検索、回答の二次利用に関するルールを明文化する |
| 本番展開 | 利用上限、監査、問い合わせ窓口、障害時の停止手順を整えてから範囲を広げる |
| 継続管理 | Agent Registry、利用レポート、Entra IDの同意状況、Copilot Credits消費を定期確認する |
開発者への影響：Graph APIではなく「会話を扱うAPI」として設計する
開発者が誤解しやすいのは、Work IQ Chat APIを「Microsoft 365データを検索するだけのAPI」と捉えることです。Microsoft Graph APIがMicrosoft 365データのCRUDや取得を担うのに対し、Copilot APIはMicrosoft 365データをもとにしたAI機能を提供するものと説明されています。(Microsoft Learn)
Work IQ Chat APIでは、設計の中心を「データ取得」ではなく「会話の流れ」に置く必要があります。
実装で押さえるべき設計ポイント
| 設計ポイント | 実務上の注意 |
|---|---|
| 会話IDの管理 | conversationIdをユーザーセッションや画面遷移に合わせて安全に保持する |
| タイムゾーン指定 | 会議、予定、締切に関する質問ではlocationHint.timeZoneを正しく渡す |
| 追加コンテキスト | アプリ画面上の案件ID、顧客名、閲覧中のドキュメントなどをadditionalContextで補う |
| ファイル指定 | OneDrive/SharePointファイルを使う場合、ユーザーがそのファイルにアクセスできる前提を確認する |
| Web検索制御 | 社内情報だけで答えさせたい場面ではwebContext.isWebEnabledを明示的に制御する |
| ストリーミング | UX重視のチャット画面ではchatOverStreamを使い、途中応答の表示やキャンセル処理を設計する |
| エラー処理 | 401、403、タイムアウト、空応答をユーザー向けメッセージに変換する |
| 回答検証 | AI生成回答は不正確な場合があるため、重要判断に使う画面では引用や根拠確認を促す |
よくある失敗は、アプリ側の文脈を十分に渡さず、ユーザーに毎回長い説明を入力させてしまうことです。たとえば営業支援アプリなら、ユーザーが開いている顧客、商談、関連ファイル、直近の会議などをアプリ側で補足し、「この商談の次回打ち合わせに向けた論点を整理して」のような短い入力でも使える体験にする方が実用的です。
同期応答とストリーミング応答の使い分け
| 方式 | 向いている場面 | 注意点 |
|---|---|---|
| 同期応答 | バッチ処理、短い回答、社内ツールの裏側で回答を生成する処理 | 応答完了まで画面が待つため、長い回答では体感速度が悪くなりやすい |
| ストリーミング応答 | チャットUI、長めの要約、ユーザーが回答生成を見ながら待つ画面 | SSEの再接続、キャンセル、途中表示、最終メッセージ確定の処理が必要 |
| 別APIの検討 | 検索結果やコンテキストだけが必要な場合 | Chat APIではなく、Context APIやSearch/Retrieval系APIの方が向く場合がある |
Chat APIは、Copilotが返すような応答をアプリに組み込むためのAPIです。データだけを取得して自社モデルで回答を作りたい場合や、検索結果を一覧表示したい場合は、別のAPIを選んだ方が設計が素直になることがあります。
移行・展開時の注意点
既存のMicrosoft 365連携アプリや独自RAG基盤がある場合、Work IQ Chat APIへの移行は「置き換え」ではなく「役割分担」で考えるのが現実的です。
既存実装から見直すべきポイント
| 既存の仕組み | 見直し方 |
|---|---|
| Graph APIでメールやファイルを取得している | データ操作はGraph API、業務コンテキストに基づく会話応答はWork IQ Chat APIに分ける |
| SharePointを外部ベクターストアに同期している | 同期対象、権限管理、鮮度要件を見直し、Work IQで代替できる範囲を検証する |
| 社内チャットボットがFAQだけを見て回答している | 会議、メール、関連ドキュメントを踏まえた回答が必要な領域にWork IQを使う |
| 生成AIの回答に根拠が出ない | Chat APIの応答に含まれる引用・属性情報をUIに表示できるか検討する |
| 全社展開済みのエージェントがある | Agent Registryで所有者、公開範囲、権限、リスクを棚卸ししてからWork IQ連携を追加する |
本番利用前のチェックリスト
| 項目 | 確認内容 |
|---|---|
| API状態 | 利用するエンドポイントが/betaか、一般提供済みか、サポート条件を確認したか |
| ライセンス | 対象ユーザーにMicrosoft 365 Copilotライセンスまたは必要な契約があるか |
| 課金 | Copilot Credits、従量課金、上限、アラート、支払い方法を確認したか |
| Entra ID | Work IQサービスプリンシパル、アプリ登録、リダイレクトURI、OBOフローを確認したか |
| 管理者同意 | WorkIQAgent.Askの同意対象アプリをレビューしたか |
| データ権限 | SharePoint、OneDrive、Teams、メールの共有範囲が過剰でないか |
| Web検索 | Web検索グラウンディングを使う場面と使わない場面を分けたか |
| ログ・監査 | 誰が、どのアプリから、どの業務シナリオで使うか追跡できるか |
| UI | 引用、注意文、回答の確認導線、エラー表示を用意したか |
| 停止手順 | 問題発生時にアプリ公開停止、同意取り消し、課金停止を実行できるか |
どのケースでWork IQ Chat APIを使うべきか
Work IQ Chat APIは、次の条件に当てはまる場合に特に有効です。
| 向いているケース | 理由 |
|---|---|
| 社内アプリにCopilot風のチャット体験を組み込みたい | 会話作成・継続・ストリーミング応答をAPIで扱える |
| Microsoft 365の業務コンテキストを踏まえて回答させたい | メール、会議、ドキュメント、Teams、人物・組織コンテキストを利用できる |
| ユーザーごとの権限を崩さずAI回答を作りたい | サインインユーザーのアクセス権に沿って動作する |
| 独自RAGのインデックス運用を減らしたい | Microsoft 365側の基盤を使い、別の同期・ベクターストア運用を減らせる可能性がある |
| アプリ画面の文脈とCopilotの業務文脈を合わせたい | additionalContextやcontextualResourcesでアプリ側の情報を補える |
一方で、次の用途には向きません。
| 向かないケース | 理由 |
|---|---|
| メール送信や会議作成をAPIだけで完結したい | REST APIの既知の制限として、メール送信や会議作成などのアクションはサポート外 |
| 画像生成やコード実行をさせたい | コードインタープリターやグラフィックアートはサポート外 |
| 長時間の非同期ジョブを実行したい | 長時間タスクはゲートウェイタイムアウトのリスクがある |
| Microsoft 365 Copilotライセンスなしで使いたい | プレビュードキュメント上、ライセンスなしユーザーのサポートは現時点で案内されていない |
| 厳密な正解だけを自動処理したい | AI生成回答は不正確な可能性があり、検証導線が必要 |
まず管理者と開発者がやるべきこと
Work IQ Chat APIは、Microsoft 365 Copilotを業務アプリやエージェントに近づける重要な更新です。ただし、実装のしやすさだけで導入すると、権限、課金、Web検索、回答品質、エージェント管理でつまずきます。
最初にやるべきことは、次の5つです。
| 役割 | 次のアクション |
|---|---|
| Microsoft 365管理者 | Agent Registryで既存エージェント、公開範囲、所有者、リスクを棚卸しする |
| Entra ID管理者 | Work IQサービスプリンシパルとWorkIQAgent.Askの管理者同意手順を確認する |
| セキュリティ担当 | SharePoint/OneDrive/Teamsのアクセス権、秘密度ラベル、情報バリアを点検する |
| 開発者 | 同期/ストリーミング、additionalContext、contextualResourcesの使い方を小さな検証アプリで試す |
| 情シス・予算管理者 | Copilot Credits、従量課金、利用上限、アラート、支払い方法を確認する |
導入判断では、「Copilotをどこに埋め込むか」よりも、「どの業務判断を、どのデータ文脈で、誰に支援させるか」を先に決めることが重要です。Work IQ Chat APIは、社内アプリにAIチャットを足すための部品ではなく、Microsoft 365に蓄積された仕事の文脈を、権限を保ったまま会話体験へつなぐための実装基盤として捉えると活用しやすくなります。
コメント