1. はじめに
最近、X(ex-Twitter)で、@super_bonochin さんが WorkIQ を理解しるための、とても素晴らしい動画を作成してくださいました。とてもわかりやすい動画ですので、ぜひご覧ください。
Work IQ のさらに深掘り
今日は、Work IQ についてさらに深掘りしていきたいと思います。
これから深掘りをしていくため、ストーリーに沿って説明をしていきたいと思います。
ところで
AI エージェントやアプリケーションを開発するとき、必要な情報は最初から仕様書にまとまっているとは限りません。実際の業務では、仕様書としてまだ綺麗にまとまっていなかったり、次のような場所に分散している可能性もあります。
- お客様との何度ものメールのやりとり
- OneDrive や SharePoint に保存された文書(Word, Excell, PowerPoint)
- Microsoft Teams のチャットやチャネルでのチームメンバーとの会話
- Microsoft Planner で管理しているタスク
これらを手作業で探して仕様書にまとめ、AI に渡す方法もあります。しかし、情報が増えると検索に時間がかかったり、アクセス権の扱いにも注意が必要になってきます。
そこで、今回は Work IQ と GitHub Copilot を組み合わせてみました。今回はメールのやり取りを元に仕様書を作成し、GitHub Copilot で要件整理、設計、実装、テスト、Microsoft Foundry へのデプロイまで進めました。
最初に結論を示し、その後で手順、製品ごとの役割、検証から得た学び、注意点を説明します。
本記事の前提
本記事は 2026 年 10 月 1 日時点の情報と、私の検証環境で得た結果を基にしています。Work IQ、GitHub Copilot、Microsoft Foundry には更新中またはプレビュー中の機能があります。利用前に、記事末尾の公式ドキュメントで最新の仕様を確認してください。
2. 最初に結論:今回できたこと
私の検証環境では、次の流れで AI エージェントを作成しました。
AI エージェントに関する要望をメールで受信
↓
GitHub Copilot から Work IQ を使って自分のメールを検索
↓
メールの内容をアプリの要件として整理
↓
不足する仕様を GitHub Copilot が質問
↓
利用者が仕様を決定
↓
詳細設計書と構築手順書を作成
↓
AI エージェントを実装してテスト
↓
Microsoft Foundry へデプロイして動作確認
ここで大切なのは、Work IQ だけで設計からデプロイまで自動化したわけではないことです。各製品とツールの役割を分けると、次のようになります。
| 製品・機能 | 今回の役割 |
|---|---|
| Work IQ | Microsoft 365 のメールや関連情報を、サインインした利用者の権限に基づいて検索・取得する |
| GitHub Copilot | 要件を整理し、不明点の確認、文書作成、コード生成、テストを支援する |
| Microsoft Foundry 向けの開発・デプロイツール | 私の指示と Azure 上の権限に基づき、リソースと AI エージェントを作成・更新する |
| Microsoft Entra ID | 利用者を認証し、認可された利用者のコンテキスト情報を Work IQ に伝える |
| Azure RBAC | Azure のロールベースのアクセス制御として、Foundry や Azure リソースに対する操作を制限する |
必要な環境、権限、ツールを準備した私の環境では、一連の作業を継続して進められました。ただし、同じ指示を与えれば、どの環境でも同じ結果になるわけではありません。
3. Work IQ とは
Work IQ は、AI エージェントが組織や業務のデータ、コンテキスト、ツールを利用するための仕組みです。Microsoft 公式ドキュメントでは、既存の権限、コンプライアンス、ガバナンスを維持しながら Microsoft 365 のデータを扱うものと説明されています。
また、任意のプログラミング言語で、「Work IQ API」を利用したアプリケーションを実装すると、皆様が Web アプリケーションやスタンドアローン・アプリケーションの中でも Work IQ を利用することができます。
Work IQ API が推論対象として挙げている情報は次のとおりです。
- 電子メール
- 会議と予定表
- OneDrive と SharePoint の文書
- Microsoft Teams のメッセージ
- 人と組織に関するコンテキスト
- Microsoft Planner のプラン
- エンタープライズ検索の結果
たとえば、「昨日、お客様から届いた AI エージェントに関する要望を探してください」と問い合わせると、サインインした利用者がアクセスできる範囲を対象に検索できます。実際の結果は、データの保存場所、アクセス権、検索条件、組織のポリシーに左右されます。
Work IQ API には、次の接続方式があります。
| 接続方式 | 主な用途 |
|---|---|
| Agent-to-Agent(A2A) | 別の AI エージェントから Work IQ へ構造化されたタスクを委任する |
| Local MCP | Work IQ CLI をローカルの Model Context Protocol(MCP)サーバーとして利用する |
| Remote MCP | IDE、CLI、AI エージェントからリモートのツールを呼び出す |
| REST API | アプリケーションやサービスから会話形式で問い合わせる |
A2A は AI エージェント同士がタスクをやり取りするためのプロトコルです。MCP は、AI アプリケーションから外部のデータやツールを呼び出すための共通仕様です。

(例:Work IQ API REST API を利用したアプリケーションのシーケンス図)
出典:Microsoft Work IQ API
Work IQ Sample Apps
(※ 上記サンプルは C#, Rust, Swift を提供していますが、筆者は Java でサンプルを実装しています。任意の言語で利用可能です)
3.1 独自の検索基盤が不要になるのか
通常、Microsoft 365内のメールや文書をAIに回答させるには、データの収集、検索インデックス、関連情報の検索、大規模言語モデルとの連携、アクセス権限の確認などを個別に実装する必要があります。
Work IQを利用すると、これらの仕組みを一から構築しなくても、Microsoft 365内の情報について質問し、利用者がアクセスできる情報を元にした回答を受け取れます。つまり、Microsoft 365の業務情報を検索し、AIの回答につなげるまでの一連の処理を利用できる点が、Work IQの大きな特徴です。
そのため、Work IQ が対応する Microsoft 365 の情報を使うシナリオでは、独自の RAG(検索拡張生成)基盤や同期処理を構築する作業を減らせる可能性があります。
ただし、すべての検索基盤を置き換えるわけではありません。Work IQ が対応しないデータソース、独自のランキング、特殊な前処理、保存期間や応答時間に関する固有要件がある場合は、別の構成が必要です。
4. 実際に試した手順
4.1 メールで要望を受け取る
今回は、次のようなメールをお客様から受信した場面を想定しました。
こんな機能を持つ AI エージェントが欲しいのですが、
作成できますか?
実際の検証用メールには、必要な機能、利用目的、想定する利用者も記載しました。それでも実装に必要な情報は不足していたため、不明点を対話で決める方針にしました。
4.2 GitHub Copilot から Work IQ を利用する
GitHub Copilot に、次のように依頼しました。
今日、○○さんから
「こんな機能を持つ AI エージェントが欲しい」
というメールを受信しました。
該当するメールを確認し、そのエージェントを作成するための詳細設計書と
構築手順書を作成してください。
メールに書かれていない内容は推測で決めず、
実装に必要な不明点として私に確認してください。
私の環境では、GitHub Copilot から Work IQ MCP を呼び出し、該当するメールを検索できました。Microsoft は、GitHub Copilot CLI を Remote Work IQ MCP に接続する手順と、Work IQ CLI を GitHub Copilot in VS Code のローカル MCP サーバーとして利用する方法を公開しています。
出典:
4.3 不足する仕様を対話で決める
メールだけでは仕様が足りなかったため、GitHub Copilot から追加の質問が表示されました。たとえば、動作環境について次のような選択肢が提示されました。
動作環境が不明確です。
どの環境を利用しますか?
選択肢 A:Microsoft Foundry
選択肢 B:ローカル環境
選択肢 C:その他の実行環境
今回は Microsoft Foundry を選び、文書作成だけでなく、実装、テスト、デプロイ後の動作確認まで依頼しました。
質問の内容や表示方法は、GitHub Copilot の機能、実行モード、拡張機能、プロンプトによって変わります。また、提示された選択肢が業務要件やセキュリティ要件を満たすとは限りません。利用者が内容を確認して決定する必要があります。
4.4 実装から Microsoft Foundry へデプロイの詳細
実際には、上記の後「仕様書の作成後 Foundry にデプロイして」と指示すれば、環境が整っている場合は、下記のように仕様書作成から実装、デプロイまでを自動的に行なってくれます。
- メールから要件を抽出する
- 不明点を整理して利用者に確認する
- 詳細設計書と構築手順書を作成する
- AI エージェントとテストを実装する
- 必要な Azure リソースとモデルを確認する
- Microsoft Foundry へデプロイする
- デプロイ後の AI エージェントを呼び出す
実際に上記の過程を行い作成した AI エージェント
5. 認証と認可で確認したこと
Work IQ API は Microsoft Entra ID の認証・認可を使用します。これは、アプリケーション単独の権限ではなく、サインインした利用者の代理として処理する方式です。2026 年 10 月 1 日時点の公式ドキュメントでは、アプリケーションのみの認証はサポートされていません。
また、Work IQ API をアプリケーションから使うには、組織の管理者が Work IQ を有効にし、必要な OAuth 2.0 のアクセス許可に同意する必要があります。
利用者がサインイン
↓
Microsoft Entra ID が利用者を認証
↓
Work IQ が認可された利用者のコンテキストを取得し処理
↓
Microsoft 365 の権限、秘密度ラベル、
コンプライアンスポリシーを適用
↓
許可された範囲の結果を返す
Work IQ API は、Microsoft 365 の既存の権限、秘密度ラベル、コンプライアンスポリシーを適用します。そのため、利用者がアクセスできない情報は、原則として Work IQ 経由でも取得できません。
一方で、元の共有設定が広すぎれば、その設定に従って情報が見える可能性があります。Work IQ は SharePoint、OneDrive、Teams などの誤った共有設定を自動修正しません。導入前に、Microsoft 365 側の権限と組織のポリシーを確認してください。
出典:
6. 接続方式毎にできる事が異なる
A2A、MCP、REST API は、同じ Work IQ を利用していても目的が異なります。
- A2A:別の AI エージェントからタスクを委任し、構造化された結果を受け取る
- MCP:AI アシスタントが Work IQ をツールとして呼び出す
- REST API:アプリケーションから自然言語で問い合わせ、複数ターンの回答を受け取る
特に REST API は、メール送信、ファイル作成、会議予約などのアクションをサポートしていません。Microsoft 365 のデータを作成・更新する場合は、対応する Work IQ MCP の Entity Tool など、別の方法を選びます。
Work IQ MCP には、情報の取得、エンティティの作成・更新・削除、アクションの実行、自然言語による問い合わせなどを行うツールがあります。実際に許可される操作は、OAuth のアクセス許可、リソースパス、HTTP メソッド、利用者、テナントポリシーによって制御されます。
出典:
7. 今回の検証から学んだこと
7.1 業務情報 (M365のデータ) を、開発 (AIエージェント) の入力にできる
私の環境では、メールを手作業でコピーせず、GitHub Copilot から Work IQ を使って要望を確認しました。情報源と AI の推測を分けるようプロンプトで指示すると、不足する仕様を人が判断しやすくなります。
7.2 Work IQ と開発ツールの責務を分けて考える
Work IQ は業務コンテキストを提供します。GitHub Copilot は設計や実装を支援し、Foundry 向けのツールは Azure 上の操作を行います。この区別を明確にすると、「Work IQ がメールを読んで自動的に本番へデプロイする」といった誤解を避けられます。
7.3 独自実装を減らせる範囲を見極める
対応する Microsoft 365 データを検索して回答へ反映する用途では、検索インデックスや同期処理を自前で構築する作業を減らせます。ただし、データソースや要件によっては独自の検索基盤が必要です。置き換えられる範囲を先に確認した方が安全です。
8. 利用前に確認する注意点
8.1 AI が作成した成果物は、そのまま本番環境で利用できるとは限りません。
例えば、要件の読み取り漏れ、設計上の考慮不足、ソースコードの不具合、Infrastructure as Codeによる意図しないリソース作成、テストケースの不足、過剰なアクセス権限などが含まれる可能性があります。
そのため、本番環境へ適用する前に、担当者が内容をレビューし、テスト環境で動作を確認してください。あわせて、セキュリティ、アクセス権限、費用、社内ルールへの適合性を確認し、組織で定められた承認手続きを行うことが重要です。
Work IQやGitHub Copilotは、情報収集や開発作業を効率化するための仕組みです。生成された成果物の正確性や安全性を自動的に保証するものではなく、最終的な確認と判断は人が行う必要があります。
8.2 同じ手順を実行しても、すべての環境で同じ時間内に完了するとは限りません。
例えば、作成するエージェントの機能が複雑な場合や、既存コードの修正が必要な場合は、設計、実装、テストに時間がかかります。また、Azureの利用権限が不足している、利用したいモデルのクォータやキャパシティが不足している、対象リージョンで必要な機能を利用できない、社内ネットワークから接続できない、といった理由で作業が中断する場合もあります。
さらに、必要なライブラリ、接続情報、管理者による同意、組織内のデプロイ承認などが事前に準備されているかどうかによっても、完了までの時間は変わります。
今回紹介した結果と所要時間は、必要な環境と権限を事前に準備した私の検証環境における一例です。すべての環境で同じ結果や処理時間になることを、Microsoftまたは各製品が保証するものではありません。
8.3 Copilot Credits とライセンスを確認する
Work IQ API は、Copilot Credits を使う従量課金モデルです。利用前に、組織で使用量ベースの請求を設定し、予算、使用量、割り当てを確認してください。
一方、Microsoft Agent 365 の管理対象 Work IQ MCP サーバーを Microsoft Foundry や Copilot Studio から使う構成は、別のライセンス要件があります。公式ドキュメントでは Microsoft 365 Copilot ライセンスが必要とされているため、Work IQ API の従量課金と同じ条件だと考えないでください。
出典:
- Microsoft Work IQ API
- Managing AI experiences enabled by usage-based billing
- Work IQ MCP overview (preview)
8.4 プレビュー機能を本番前提にしない
Microsoft Agent 365 の管理対象 Work IQ MCP サーバーは、2026 年 10 月 1 日時点でプレビューです。公式ドキュメントには、本番利用を目的とせず、機能が制限される場合があると記載されています。仕様、ライセンス、対応クライアント、管理方法は今後変わる可能性があります。
また、Work IQ、GitHub Copilot、Microsoft Foundry の連携方法は複数あります。本記事で試した GitHub Copilot 経由の構成と、Foundry から管理対象 Work IQ MCP サーバーを直接利用する構成を混同しないようにしてください。
出典:Work IQ MCP overview (preview)
9. まとめ
私の検証環境では、Work IQ で Microsoft 365 のメール(データ)を参照し、その内容を GitHub Copilot による要件整理と開発へつなげられました。必要な環境と権限を準備したうえで、対話しながら仕様を決め、Microsoft Foundry へのデプロイまで進めています。
今回のポイントは、次の 3 点です。
- Work IQ は、既存の Microsoft 365 の権限やポリシーを適用しながら業務コンテキストを提供する
- 設計、実装、テスト、デプロイは、GitHub Copilot、開発ツール、利用者の判断と権限が担う
- 課金、ライセンス、管理者の同意、プレビュー条件を構成ごとに確認する
Work IQ を使えば必ず短時間で開発できるわけではありません。しかし、情報源を確認しながら要件を整理する手段として、試す価値があると感じました。まずは権限を限定した検証環境で、取得される情報と実行される操作を確認することをお勧めします。
冒頭で紹介した X(ex-Twitter)の投稿の動画にもありますが、AI を扱う際にキモとなるのは扱うデータです。
ビジネスで扱うデータが Microsoft 365 内にある利用者であれば、Work IQ を利用する価値、もしくはお試しいただく価値は十分にあると思います。
ぜひ、Work IQ をお試しください。
10. 参考資料
- Work IQ overview
- Microsoft Work IQ API
- Work IQ MCP overview
- Microsoft Work IQ CLI
- Connect GitHub Copilot CLI to the Work IQ MCP server
- Work IQ REST API overview
- Work IQ A2A overview
- Work IQ API permissions reference
- Managing AI experiences enabled by usage-based billing
- Work IQ MCP overview (preview)
