Microsoft 365 CopilotのWork IQ APIsに、従量課金のPay-As-You-Go Consumptionが追加される予定です。結論から言うと、開発者はあらかじめユーザーへMicrosoft 365 Copilotライセンスを割り当てていなくても、Work IQのエンドポイントをメーター制で呼び出せるようになります。利用料は、リクエストごとに呼び出したエージェントやモデルに応じて課金される形です。Microsoft 365 Roadmapでは、対象は「Microsoft Copilot (Microsoft 365)」、提供時期は2026年6月の一般提供予定として掲載されています。(Microsoft)
この変更は、単なるライセンス体系の追加ではありません。社内アプリ、業務エージェント、Copilot拡張を開発する組織にとって、「全員分の固定ライセンスを先に確保する」方式から、「利用量を見ながら小さく試す」方式へ移行しやすくなる点が重要です。一方で、API呼び出しがそのままコストにつながるため、管理者は課金ポリシー、対象ユーザー、予算アラート、監視方法を事前に決めておく必要があります。
Microsoft 365 CopilotのWork IQ APIs Pay-As-You-Go Consumptionとは
Work IQ APIs Pay-As-You-Go Consumptionは、Work IQのエンドポイントに対してメーター制の従量課金アクセスを提供する更新です。Microsoft 365 Roadmapの説明では、開発者が事前割り当てライセンスを必要とせずにエージェントや機能を呼び出せるようになり、利用量はリクエストごとに呼び出されたエージェントやモデルに基づいて課金されるとされています。(Microsoft)
Work IQは、Microsoft 365 Copilotやエージェントの背後にあるインテリジェンス層です。メール、会議、ドキュメント、チャットなどのMicrosoft 365データと、関係性、作業パターン、文脈を組み合わせて、業務データに基づく推論や応答生成を支えます。Microsoft Learnでは、Work IQ APIは既存のアクセス許可、コンプライアンス、ガバナンス制御を維持したまま、Microsoft 365データに対して安全に推論するアプリケーションを構築するためのAPIと説明されています。(Microsoft Learn)
押さえるべきポイントは、「データを丸ごと外部に複製して独自RAG基盤を作る」のではなく、Microsoft 365の権限や秘密度ラベルを尊重しながら、Copilotの業務コンテキストをアプリやエージェントから利用しやすくする方向の更新であることです。
何が変わるのか
今回の変更で最も大きいのは、開発・検証・限定展開のハードルが下がることです。
| 観点 | これまで意識しやすかった課題 | Pay-As-You-Goで変わる点 |
|---|---|---|
| ライセンス | 利用者ごとの固定ライセンスを前提に設計しやすい | 事前割り当てライセンスなしでの呼び出しが可能になる見込み |
| コスト管理 | 利用開始前に固定費が読みやすい一方、PoCでも初期負担が出やすい | 小さく始めやすいが、API利用量に応じた変動費管理が必要 |
| 開発 | 対象ユーザーをライセンス付与済みに限定しやすい | 業務アプリやエージェントから利用範囲を広げやすい |
| 管理 | ライセンス割り当て管理が中心 | 課金ポリシー、対象グループ、使用量監視が重要になる |
| 展開 | 全社展開前の費用見積もりが難しい場合がある | 部門単位・用途単位で利用実績を見ながら判断しやすい |
ただし、「安くなる」と断定できる更新ではありません。利用頻度が高いエージェント、複雑なモデル呼び出し、バックエンドからの自動実行が増えると、固定ライセンスよりコストが読みづらくなる可能性があります。特に、ユーザー操作1回に対して裏側で複数のWork IQ呼び出しが発生する設計では、想定以上の請求につながることがあります。
対象範囲と提供時期
Microsoft 365 Roadmap上の項目では、対象製品は「Microsoft Copilot (Microsoft 365)」、リリースフェーズはGeneral Availability、提供時期はJune CY2026です。クラウドインスタンスにはWorldwide (Standard Multi-Tenant)とDoD、プラットフォームにはDesktop、Linux、Mac、Webが含まれています。(Microsoft)
管理者が特に注意したいのは、対象にDoDが含まれている点です。一般企業向けのWorldwide環境と政府機関向けクラウドでは、展開タイミング、管理画面、利用条件、監査要件が異なる場合があります。自社テナントがどのクラウドに該当するかを確認し、ロードマップの「提供予定月」だけで本番計画を確定しないようにしましょう。
管理者が確認すべき設定
Pay-As-You-Go型のMicrosoft 365 Copilotサービスでは、管理者が課金ポリシーを作成し、対象のCopilotサービスに接続する流れが基本です。Microsoft Learnでは、課金プロセスは「billing policyを追加する」「billing policyをCopilotサービスに接続する」の2段階と説明されています。(Microsoft Learn)
Work IQ APIs向けの最終的な管理画面やメーター名は、一般提供時点の公式ドキュメントで確認が必要です。ただし、既存のMicrosoft 365 Copilot Pay-As-You-Go管理の考え方から、少なくとも次の項目は事前に整理しておくべきです。
Azureサブスクリプションとリソースグループ
Pay-As-You-Goの利用料はAzureサブスクリプションに紐づいて請求されます。セットアップには、Azureサブスクリプションとリソースグループに対する所有者または共同作成者の権限が必要とされています。(Microsoft Learn)
開発部門が自由に検証したい場合でも、個人や部門が勝手にサブスクリプションを紐づけると、請求先や予算責任が曖昧になります。おすすめは、用途別に次のような単位で分けることです。
| 分け方 | 向いているケース | 注意点 |
|---|---|---|
| 部門別 | 営業、情シス、開発などで利用量を分けたい | 部門横断エージェントの費用配賦が必要 |
| 環境別 | 検証、本番、PoCを分けたい | 本番移行時に設定漏れが起きやすい |
| アプリ別 | 社内ポータル、問い合わせBot、業務エージェントごとに管理したい | アプリが増えるとポリシー管理が複雑になる |
対象ユーザーは「全員」ではなくグループ指定から始める
課金ポリシーでは、対象範囲として全ユーザーまたは特定グループを選べる構成が案内されています。(Microsoft Learn)
初回展開では、全ユーザーではなくセキュリティグループ単位で始めるのが安全です。たとえば、最初は「WorkIQ-PAYG-Pilot-Users」のような検証用グループを作り、開発者、業務オーナー、情報システム部門の数十名に限定します。利用傾向、応答品質、1人あたりの月間コストを確認してから、部門展開や全社展開へ進める方が失敗しにくくなります。
予算アラートは「上限停止」ではない点に注意
Microsoft 365 Copilot Pay-As-You-Goの課金ポリシーでは予算を設定できますが、Microsoft Learnでは、予算額はメール通知のトリガーであり、予算超過後も利用は継続できると説明されています。(Microsoft Learn)
つまり、予算を設定しただけではコスト暴走を止められません。実運用では、次のような社内ルールを合わせて決めておく必要があります。
- 月間利用額が予算の50%に達したら開発責任者へ通知
- 80%に達したら新規ユーザー追加を停止
- 100%に達したら対象グループから一部ユーザーを外すか、対象サービスの接続解除を検討
- 本番アプリでは、アプリ側にも1ユーザーあたり・1日あたりの呼び出し回数制限を実装
特に、バックグラウンドジョブや定期バッチからWork IQ APIsを呼ぶ設計では、ユーザーが画面を開いていない時間にも課金が発生する可能性があります。人が操作するチャット型エージェントよりも、スケジュール実行型の方がコスト監視を厳しくするべきです。
コスト確認の導線を決めておく
Microsoft 365 CopilotのPay-As-You-Go利用量は、Microsoft 365管理センターのCost Managementページで確認でき、Azure側のMicrosoft Cost Managementでもコスト分析が可能とされています。(Microsoft Learn)
運用開始前に、「誰が」「どの頻度で」「どの画面を見るか」を決めておきましょう。たとえば、検証期間中は週1回、本番展開後は月2回、請求管理者とAI管理者が利用量を確認します。開発者だけに任せると、ビジネス部門の利用増によるコスト変動に気づくのが遅れることがあります。
開発者が確認すべき実装ポイント
Work IQ APIは、A2A、MCP、RESTといった複数のプロトコルに対応する設計です。Microsoft Learnでは、パブリックプレビュー時点でA2Aとlocal MCPが利用可能、RESTとremote MCPは今後提供予定と説明されています。(Microsoft Learn)
本番設計では、プロトコル選定を「今動くから」だけで決めないことが重要です。
| プロトコル | 向いている用途 | 開発時の判断基準 |
|---|---|---|
| A2A | エージェント同士のタスク委任、マルチエージェント連携 | 既存の業務エージェントからWork IQへ調査や要約を依頼したい |
| Local MCP | 開発環境、IDE、CLI、AIアシスタントからのツール呼び出し | 開発者が業務コンテキストを手元のツールで試したい |
| Remote MCP | 統一されたリモートツール連携 | 提供開始後に、複数ツールの設定を集約したい |
| REST | Webアプリやバックエンドからのリクエスト/レスポンス型呼び出し | サービス側から自然言語問い合わせや応答表示を実装したい |
認証面では、Work IQはMicrosoft Entra IDの委任認証を使用し、リクエストはサインインユーザーのコンテキストで実行されます。Microsoft Learnでは、OBOフローはサポートされる一方、アプリケーションのみの認証はサポートされないと説明されています。(Microsoft Learn)
ここは設計上の落とし穴です。サーバー側バッチや無人処理で「アプリ権限だけで全社データを推論する」ような作り方は、Work IQの前提と合いません。ユーザーの代わりに呼び出すWebアプリを作る場合は、サインイン済みユーザーのトークンを前提にOBOフローを検討する必要があります。
移行や展開で失敗しやすいポイント
固定ライセンス不要を「権限不要」と誤解する
Pay-As-You-Goは課金・ライセンス面の柔軟性を高める仕組みであり、Microsoft 365内のアクセス許可を無視できる仕組みではありません。Work IQのリクエストはサインインユーザーのコンテキストで実行され、Microsoft 365の権限や秘密度ラベルを尊重すると説明されています。(Microsoft Learn)
たとえば、ある社員が閲覧権限を持たないSharePointサイトの情報を、Work IQ経由で取得できるようになるわけではありません。管理者は、APIの有効化前にSharePoint、Teams、OneDrive、秘密度ラベル、外部共有設定を棚卸ししておくべきです。
PoCの呼び出し回数を本番見積もりに使ってしまう
検証中は利用者が少なく、質問内容も限定されます。本番展開後は、同じエージェントでも問い合わせ数、添付ファイル、会議データ、過去メールの参照頻度が大きく増える可能性があります。
見積もりでは、最低でも次の3つを分けて計算します。
| 見積もり項目 | 確認する内容 |
|---|---|
| 1ユーザーあたりの利用頻度 | 1日何回、どの業務で呼び出すか |
| 1業務あたりのAPI呼び出し回数 | 1回の操作で裏側のWork IQ呼び出しが何回発生するか |
| モデル・エージェントの違い | 高コストな呼び出しがどの処理で発生するか |
特に、ユーザーが「1回質問しただけ」に見えても、アプリ側で要約、分類、再検索、エージェント呼び出しを連続実行している場合は、課金対象の単位が増えます。
既存のCopilot Chat API連携を放置する
Microsoft Learnでは、Work IQはCopilot Chat APIの進化版として位置づけられ、新規プロジェクトはWork IQから始めること、既存のCopilot Chat API統合は継続利用できるものの、移行計画を立てることが推奨されています。(Microsoft Learn)
既存連携がある組織は、次の観点で棚卸ししましょう。
- どのアプリがCopilot Chat APIや関連APIを呼んでいるか
- 本番用途か、検証用途か
- 認証方式は委任認証か
- 将来的にWork IQへ移行した場合、同じユーザー体験を維持できるか
- Pay-As-You-Goに切り替えた場合、部門別のコスト配賦が可能か
「動いているからそのまま」にすると、GA後のサポート条件、SLA、課金モデルの整理が遅れます。
管理者と開発者が今やるべき準備
Work IQ APIs Pay-As-You-Go Consumptionは2026年6月の一般提供予定項目です。ロードマップの予定は変更される可能性があるため、実際の展開前にはMicrosoft 365管理センター、メッセージセンター、Microsoft Learnの最新情報を確認してください。Microsoft 365 Roadmap自体も、リリース日や説明は見込みであり変更される可能性があると明記しています。(Microsoft)
現時点で進めるべき準備は、次の順番がおすすめです。
| 優先度 | 実施内容 | 担当 |
|---|---|---|
| 高 | Work IQを使う候補アプリ、エージェント、業務シナリオを洗い出す | 開発者、業務部門 |
| 高 | Pay-As-You-Go用のAzureサブスクリプション、請求責任者、予算管理方法を決める | 管理者、経理、情シス |
| 高 | 対象ユーザーを全社ではなく検証グループに絞る | Microsoft 365管理者 |
| 中 | WorkIQAgent.Askなど、必要な委任権限と同意フローを検証する | 開発者、Entra管理者 |
| 中 | A2A、MCP、RESTのどれを使うか、アーキテクチャ別に整理する | 開発者 |
| 中 | SharePoint、Teams、秘密度ラベル、外部共有設定を棚卸しする | 情シス、セキュリティ担当 |
| 低 | ヘルプデスク向けに「課金」「権限」「利用できない場合」のFAQを用意する | 管理者、サポート担当 |
最初のPoCでは、「会議内容の要約」「営業案件に関するメール・Teams・ファイルの横断整理」「社内ナレッジに基づく問い合わせ回答」のように、利用価値と呼び出し回数を測りやすい業務から始めると判断しやすくなります。
まとめ：小さく始められる一方、課金と権限の設計が重要
Microsoft 365 CopilotのWork IQ APIs Pay-As-You-Go Consumptionは、Work IQの業務コンテキストをアプリやエージェントから活用しやすくする重要な更新です。事前割り当てライセンスなしで呼び出せるようになることで、PoCや部門限定の展開は始めやすくなります。
一方で、従量課金は「使った分だけ安くなる」仕組みではなく、「使った分だけ費用が動く」仕組みです。管理者はAzureサブスクリプション、課金ポリシー、対象グループ、予算アラート、Cost Managementの確認体制を整える必要があります。開発者は、委任認証、ユーザー権限、呼び出し回数、プロトコル選定を設計段階から考慮しましょう。
次に取るべき行動は、全社展開ではなく、まず候補シナリオを1つ選び、検証グループと予算ルールを決めることです。そのうえで、Work IQ APIの認証、呼び出し回数、応答品質、月間コストを実測し、本番利用に進めるかを判断すると安全です。
コメント