AI CoE のための Microsoft AI 製品選定入門
AI CoE を立ち上げ、組織への AI 導入を加速しようとすると、Microsoft 365 Copilot、GitHub Copilot、Microsoft Copilot Studio、Microsoft Foundry、さらに Microsoft Security Copilot や Azure SRE Agent など、多くの製品が候補に挙がります。
選択肢が多いため、すべて比較してから導入しようと考えたくなります。一方で、導入を急ぐあまり、効果や利用方法が分からない段階から全社基盤を作り、全員へ展開することにもリスクがあります。AI を使える人材の育成も、基盤完成後まで待てません。
この記事では、製品カタログを網羅するのではなく、目的とシナリオから最初の2製品程度を選び、利用から得た知見を基盤、人材育成、次の展開へ戻す方法を整理します。
目次
- 先に結論
- 製品ではなく目的から始める
- 3つの軸で候補を絞る
- シナリオから最初の2製品を選ぶ
- 専門製品は別の軸で考える
- まず使って知見を展開へつなげる
- 効果は導入後に確かめる
- AI 人材を役割別に育てる
- 全社 AI 基盤を固定された製品にしない
- 導入判断を段階的なゲートにする
- AI Agent も組織の管理対象になる
- まとめ
先に結論
企業の AI 導入では、最初からすべての製品を試したり、全社で利用する単一の AI 基盤を完成させたりする必要はありません。
最初に決めるのは製品ではなく、次のどちらを始めたいのかです。
- 人が AI を使う: 日常業務やソフトウェア開発を AI で支援する
- AI を業務へ組み込む: 組織固有の知識、システム、業務フローを使う Agent や AI Application を作る
「人が使う」ことから始めるなら、一般の Knowledge Worker 向けに Microsoft 365 Copilot、Developer 向けに GitHub Copilot という組み合わせが考えられます。
「業務へ組み込む」ことを検証するなら、Low-code の Copilot Studio と、Pro-code の Microsoft Foundry を比べる方が自然です。GitHub Copilot は Pro-code 開発の開発支援をしますが、Copilot Studio と対になる Agent の実行基盤ではありません。
そのうえで、次の循環を作ります。
まず使う。利用結果をナレッジとして残し、効果とリスクを分析する。成立したシナリオだけを標準化して展開する。
全社 AI 基盤は、最初から1つの製品へ統一した環境ではなく、安全に試せる環境、Identity、Data Governance、監査、評価方法、再利用部品、相談窓口を含む仕組みとして育てます。
製品ではなく目的から始める
「AI を導入する」は目的ではありません。何を改善したいのかが曖昧なままでは、利用者数や Prompt 数が増えても、投資効果を判断できません。
最初に、AI の導入によって変えたいことを仮説として置きます。
| 目的の種類 | 仮説の例 |
|---|---|
| 効率 | 会議後の記録作成や情報収集にかかる時間を減らせる |
| 品質 | Review の観点や Test Coverage を増やせる |
| 体験 | 単純作業や調査時の認知負荷を減らせる |
| 能力拡張 | 専門家でなければ難しかった分析の入口を作れる |
| 事業成果 | 顧客への回答時間や Service 提供までの Lead Time を短縮できる |
ここで大事なのは、導入前から「生産性が何％向上する」と成果を確定しないことです。導入前に置けるのは、あくまで検証する仮説です。
たとえば GitHub Copilot を導入する目的が Developer Experience の向上なら、生成した Code の行数だけでは判断できません。Pull Request の Lead Time、Review の手戻り、障害件数、調査時間、Developer の認知負荷まで見て、初めて改善したかを評価できます。
3つの軸で候補を絞る
Microsoft の AI 製品を同じ表で横並びにすると、役割の違う製品を比較してしまいます。候補は次の順番で絞ると整理しやすくなります。
1. 人が使うか業務へ組み込むか
| 方向 | 主な利用者 | 代表的な製品 |
|---|---|---|
| 人が AI を使う | Knowledge Worker、Developer、Operator | Microsoft 365 Copilot、GitHub Copilot |
| AI を業務へ組み込む | Business Maker、Development Team、Platform Team | Copilot Studio、Microsoft Foundry |
Microsoft 365 Copilot は、Teams、Outlook、Word、Excel などの Microsoft 365 Application と Microsoft Graph の組織 Data を使った業務支援を提供します。
GitHub Copilot は、IDE や GitHub 上で Coding、Review、Test、調査、Issue からの実装など、Software Development を支援します。
Copilot Studio は、組織の Data や System へ接続し、Agent と Workflow を作成・管理する Low-code の環境です。
Microsoft Foundry Agent Service は、Prompt Agent や独自 Code による Hosted Agent を構築、配置、拡張するための Managed Platform です。
2. 汎用か専門特化か
Microsoft 365 Copilot や Copilot Studio は、幅広い職種や業務を対象にできます。一方で、Security や Site Reliability Engineering のように、専門 Data、Tool、Workflow があらかじめ組み込まれた製品もあります。
この違いは後で詳しく扱いますが、専門製品は汎用製品と常に比較する候補ではありません。該当する業務シナリオがある場合だけ選定へ加えます。
3. Low-code か Pro-code か
AI を業務へ組み込む場合は、作る人と必要な制御の深さで分けます。
| 比較軸 | Copilot Studio | Microsoft Foundry |
|---|---|---|
| 主な作り手 | Business Maker、Power Platform Team | Application Developer、AI Engineer、Platform Team |
| 作り方 | Graphical、Low-code、Connector 中心 | Portal、SDK、API、独自 Code |
| 得意な範囲 | 部門業務、Microsoft 365、Power Platform、既存 Connector | 独自 Application、独自 UI、Model 選択、Network や Runtime の詳細制御 |
| 運用 | Power Platform の Governance と ALM | Azure の Identity、Network、Observability、DevOps |
実際の System 構築では、Low-code と Pro-code のどちらか一方だけで完結するシナリオは多くありません。たとえば Development Team が Pro-code で MCP Server や API を作り、RAG で利用する Knowledge Source、Index、Data Pipeline を整備します。Business Maker は、それらを Copilot Studio の Tool や Connector として呼び出し、部門の会話、承認、業務 Flow へ組み込みます。
| 担当 | 主な役割 |
|---|---|
| Pro-code Team | MCP Server、API、RAG、認証、権限、監視など、複数の Agent から安全に再利用できる機能を提供する |
| Low-code Team | 再利用機能を業務手順、会話、Trigger、Approval、Microsoft 365 の利用体験へ構成する |
この組み合わせなら、業務部門は System の内部実装を毎回作らずに改善を続けられます。開発・Platform Team は、機密 Data や更新操作を MCP Server や API の境界で管理し、変更、監査、障害対応を共通化できます。
したがって、どちらが上位か、どちらか一方へ統一するかという関係ではありません。何を業務部門が変更可能にし、何を開発・Platform Team が共通機能として管理するかという Ownership の境界で判断します。
シナリオから最初の2製品を選ぶ
すべての製品を試さなくてよい理由は、利用場所、利用者、Data、実行範囲、非機能要件から多くの候補を事前に除外できるためです。
最初に次を確認します。
- 誰が利用するのか
- Teams、IDE、独自 Web Application など、どこで利用するのか
- Microsoft Graph、Source Code、業務 System など、何を参照するのか
- 回答だけか、System の更新まで行うのか
- 誤った場合に人が修正できるか
- Identity、Network、監査、Data Residency にどのような要件があるか
- 誰が継続的に管理・改善するのか
その結果、要件上どちらでも成立する製品が残った場合だけ、同じシナリオで比較します。
シナリオ A: まず社員が AI を使う
| 対象 | 最初の製品 | 検証する仕事 |
|---|---|---|
| 営業、企画、管理部門 | Microsoft 365 Copilot | 会議整理、Document 作成、Mail、組織内の情報探索 |
| Developer、Cloud Engineer | GitHub Copilot | Coding、Test、Review、障害調査、Infrastructure as Code |
この組み合わせは製品同士を競わせるものではありません。職種ごとに異なる仕事で、AI を利用したときの価値と育成方法を確かめるものです。
シナリオ B: AI を業務へ組み込む
| 対象 | 最初の製品 | 検証する仕事 |
|---|---|---|
| 部門主導の業務改善 | Copilot Studio | 社内規程の回答、Help Desk、申請、Ticket 登録 |
| 開発 Team 主導の独自 Service | Microsoft Foundry | 顧客向け AI、独自 UI、複数 API、独自 Runtime を使う Agent |
この場合は、同じ小さな業務シナリオを両方で作り、回答精度だけでなく、実装時間、変更のしやすさ、監査、運用負荷、Cost を比較できます。
シナリオ C: 業務利用と独自開発をつなぐ
Microsoft 365 Copilot を利用者の入口、Copilot Studio を業務 Agent の構築環境として組み合わせる方法もあります。逆に、Microsoft Foundry で作った Agent を独自 Application から使い、その開発を GitHub Copilot で支援する構成もあります。
重要なのは、必ず2製品に制限することではありません。最初の学習範囲を検証可能な範囲に保つために、目的ごとに2製品程度まで絞るという考え方です。
専門製品は別の軸で考える
Azure Copilot、Microsoft Security Copilot、Azure SRE Agent は、汎用 Copilot や Agent Builder とは少し異なります。
| 専門製品 | 対象業務 | 組み込まれている主な能力 |
|---|---|---|
| Azure Copilot | Azure の設計、運用、最適化、トラブルシューティング | Azure Control Plane、Azure の公式情報、利用者の RBAC 範囲にある Resource と環境 Context |
| Microsoft Security Copilot | SOC、Threat Hunting、Identity、Data Security、IT Administration | Defender XDR、Sentinel、Intune、Entra、Purview などの Security Data と Workflow |
| Azure SRE Agent | Incident Response、Root Cause Analysis、Mitigation | Azure Monitor、Application Insights、Runbook、Source Code、Incident Platform などの運用 Context |
専門製品の価値は、専門知識を反映した Prompt だけではありません。対象分野の Data、Tool、Workflow、Role、監査、Human Oversight まで含めて提供されることです。
そのため、選定は次の順番になります。
- 対象業務に Microsoft の専門製品があるか確認する
- 標準機能で要求を満たせるか確認する
- 足りない部分を専門製品上で拡張できるか確認する
- それでも不足する固有業務だけ Copilot Studio や Microsoft Foundry で作る
Security Incident の Triage を行うために、最初から汎用 Agent を独自開発する必要はありません。専門製品が対象とするシナリオなら、まず既製の業務能力を評価する方が、構築と継続運用の範囲を小さくできます。
まず使って知見を展開へつなげる
AI 導入、人材育成、全社基盤整備は、別々の Project にすると進行が分断されます。次の循環として同時に進めます。
1. まず使う
対象者と期間を限定した Sandbox で、実際の仕事に近い Task を試します。禁止事項だけを並べるのではなく、利用可能な Data、Human Review が必要な操作、相談先を明確にします。
最初は、誤りを人が発見・修正でき、結果を本番へ自動反映しない Task が向いています。
- Meeting Summary の下書き
- Document や Mail の Draft
- Source Code の説明と Test Case の提案
- Read-only の Data 分析
- Incident 調査手順と原因候補の整理
2. ナレッジ化して分析する
利用回数だけでなく、どの職種が、どの Task で、どのような結果を得たかを記録します。
- 成功した Prompt や Agent Instruction
- 利用した Data Source と Tool
- AI の出力を人がどの程度修正したか
- 失敗、Hallucination、権限不足、Data 品質の問題
- 節約できた時間と、新たに増えた Review 時間
- 再利用できる Connector、Evaluation、Runbook
個人の Prompt 集だけにせず、シナリオ、前提、結果、Risk、再現手順をまとめます。これが人材育成の教材と、次の基盤要件になります。
3. 成立したものだけ展開する
効果と Risk を確認できたシナリオは、Template、権限、Data 接続、Evaluation、Support 方法を標準化して対象を広げます。
成立しなかったシナリオは、製品を変える前に原因を切り分けます。Data が不足していたのか、Task が曖昧だったのか、Model の能力が足りなかったのか、運用 Cost が見合わなかったのかで、次の実験は変わります。
効果は導入後に確かめる
AI の効果を「生産性向上」という1つの言葉にまとめると、何を測るべきか分からなくなります。少なくとも次の5つに分けます。
| 効果 | 確認すること |
|---|---|
| 効率 | 作業時間、Lead Time、処理件数、Cost が変わったか |
| 品質 | 誤り、手戻り、Test、障害、回答の一貫性が変わったか |
| 体験 | 認知負荷、集中、満足度、仕事の進めやすさが変わったか |
| 能力拡張 | 以前は難しかった分析や作業に着手できたか |
| 事業成果 | 顧客への回答時間、Conversion、Service Delivery が変わったか |
検証前に Baseline を取ります。導入後の自己申告だけでは、繁忙期、Team 構成、業務量の変化と AI の効果を区別しにくいためです。
Developer Experience なら、次のような指標を組み合わせます。
- Issue 着手から Pull Request 作成までの時間
- Pull Request 作成から Merge までの時間
- Review Comment、手戻り、Reopen の件数
- Test 作成と障害調査にかかる時間
- Change Failure Rate と復旧時間
- AI 出力の採用率ではなく、人が修正した割合と理由
- Developer の認知負荷と満足度
速度が上がっても、Review 負荷や障害が増えれば、組織全体の生産性が上がったとは限りません。定量指標と利用者への定性調査を一緒に見ます。
AI 人材を役割別に育てる
全員を AI Engineer にする必要はありません。必要な能力を役割ごとに分けます。
| 役割 | 身に付ける能力 |
|---|---|
| AI User | 適切な Task の選択、Context の与え方、出力の検証、Data 取扱い |
| AI Champion | 部門のシナリオ発見、利用支援、成功・失敗事例の収集 |
| Business Maker | Copilot Studio、Connector、Workflow、権限、簡易 Evaluation |
| AI／Application Developer | Microsoft Foundry、API、RAG、Evaluation、Observability、Secure Coding |
| Platform／Security Team | Identity、Network、Data Governance、監査、Cost、Risk Management |
| Business Owner | Outcome、Risk、Human Oversight、展開・停止の判断 |
研修は製品画面の操作説明だけで終わらせません。実際の業務シナリオを教材にして、出力の検証、失敗の記録、改善、成果発表までを含めます。
中央の AI Enablement Team は、すべての Agent を代わりに作る Team ではありません。共通 Guardrail、Template、評価方法、相談窓口を用意し、各部門の AI Champion や Maker が自分たちの仕事を改善できるようにします。
全社 AI 基盤を固定された製品にしない
導入初期に「全社 AI 基盤」を1つの大きな System として作ると、利用実態が分かる前に Architecture、製品、Data 接続を固定することになります。
初期の全社 AI 基盤は、次の共通 Capability として定義する方が変更しやすくなります。
| Capability | 初期に用意するもの |
|---|---|
| 安全な探索 | 対象者を限定した Sandbox、利用可能な Data と禁止操作 |
| Identity | Microsoft Entra ID、User／Agent Identity、Least Privilege |
| Data Governance | Classification、Access Control、Oversharing 対策、Retention |
| Human Oversight | Review、Approval、停止手順、Escalation |
| Observability | 利用状況、品質、Tool 実行、Cost、Security Event |
| Evaluation | Baseline、Test Dataset、評価指標、展開・停止条件 |
| Reuse | Prompt、Instruction、Connector、Tool、Runbook、Architecture Pattern |
| Enablement | Training、Community、Office Hours、Support 窓口 |
Sandbox にも Guardrail は必要です。ただし、本番と同じ制約をすべて先に作り込むのではなく、扱う Data と実行権限を限定して、失敗時の影響を小さくします。
本番利用へ移すときに、監査、Availability、Support、Data Lifecycle、Cost Management などをシナリオの Risk に応じて追加します。
導入判断を段階的なゲートにする
導入を急ぐことと、最初から全社展開することは同じではありません。期間を区切り、判断 Gate を置くことで、学習速度を保ちながら展開 Risk を抑えられます。
| 段階 | 目的 | 次へ進む条件 |
|---|---|---|
| Explore | 製品とシナリオの適合性を知る | 実行可能で、重大な Risk が管理できる |
| Pilot | 実業務で効果と運用を測る | Baseline に対する改善と、許容できる品質・Cost が確認できる |
| Standardize | 再利用可能な形にする | Owner、権限、監査、Support、Evaluation が定義されている |
| Scale | 対象部門や利用者を広げる | 利用増加に対して品質、Security、Cost を継続監視できる |
| Operate | 継続改善または撤退を判断する | Outcome を定期評価し、変更・停止できる |
Pilot では、すべての候補製品を試しません。要件から候補を2つ程度まで絞り、回答品質、実装期間、運用負荷、変更容易性、監査性、Total Cost など、まだ分からない部分だけを比較します。
展開しない判断も成果です。価値が出ない条件や、必要な Data 品質、Human Review の Cost が分かれば、次の投資判断を改善できます。
AI Agent も組織の管理対象になる
最後に、もう1つ補足しておきたい点があります。Microsoft を含むさまざまな企業が、多数の AI Agent が人と協働する将来像を示しています。将来は AI Agent の数が人間の人口を上回るという見方もありますが、その時期や規模を確定した事実として扱うことはできません。ただし、企業内で Agent が急速に増え、業務の一部として常態化していく方向性は、導入戦略へ織り込む必要があります。
Agent は質問に答えるだけではありません。Data を参照し、API や MCP Server を呼び出し、Message を送り、承認された範囲で業務 System を操作します。そのため、数が増えてから台帳を作るのでは遅く、人や Application を管理してきたのと同じように、最初から管理対象として扱う必要があります。
| 管理項目 | 確認すること |
|---|---|
| Inventory | どの Agent が存在し、何の目的で、どの Platform 上で動いているか |
| Identity | Agent 固有の Identity があり、人の Credential を共有していないか |
| Owner／Sponsor | 誰が目的、品質、Access、継続・停止の判断に責任を持つか |
| Access | どの Data、Tool、API へ、どの権限と有効期限で Access できるか |
| Lifecycle | 作成、承認、公開、変更、定期 Review、停止、廃止の手順があるか |
| Observability | Agent の判断、Tool 実行、Data Access、Cost、Error を追跡できるか |
| Risk／Compliance | Human Approval が必要な操作、禁止事項、監査証跡、Incident 対応が定義されているか |
重要なのは、すべての Agent を中央 Team が作ることではありません。各部門が Agent を作れる状態を保ちながら、登録、Identity、Owner、最小権限、監視、停止という共通の Guardrail を適用します。人の入社、異動、退職に合わせて Access を管理するように、Agent にも作成、役割変更、権限 Review、廃止の Lifecycle が必要です。
Microsoft の例では、Microsoft Agent 365 が Agent の可視化、Governance、Security のための Control Plane を提供し、Microsoft Entra ID Governance for Agent Identities が Identity、Owner／Sponsor、Access Review、Lifecycle を管理する考え方を示しています。これは Microsoft 製品だけを選ぶという話ではなく、今後どの Platform で Agent を構築・調達するとしても、同じ管理要件が必要になるという例です。
この流れを製品構成にも反映したのが、2026年5月1日に一般提供された Microsoft 365 E7 です。E7 は、Microsoft 365 E5 に Microsoft 365 Copilot、Microsoft Entra Suite、Microsoft Agent 365 を加えた上位 Suite です。目的は単に E5 の機能を増やすことではなく、人が Copilot を使い、多数の Agent が業務を実行する環境を、共通の Identity、Access Control、Security、Compliance、Lifecycle Management の下で安全に拡大することにあります。
Microsoft Agent 365 は対象となる Plan へ追加する方法もあるため、Agent を管理するには必ず E7 が必要という意味ではありません。E7 は、AI の実験段階から全社展開へ進み、利用者と Agent の生産性・管理・保護を統合したい組織向けの選択肢として捉えると分かりやすくなります。
まとめ
企業の AI 導入では、製品の多さをそのまま比較対象の多さにしないことが大切です。
最初に、「人が AI を使う」のか「AI を業務へ組み込む」のかを決めます。次に、汎用か専門特化か、Low-code か Pro-code かを確認し、利用場所、Data、実行範囲、非機能要件、運用主体から候補を絞ります。
- AI の利用を始めるなら、Microsoft 365 Copilot と GitHub Copilot
- 業務 Agent の構築方法を比べるなら、Copilot Studio と Microsoft Foundry
- Security や SRE の専門業務なら、該当する専門製品を先に評価する
これは固定的な製品標準ではなく、最初の学習範囲を決める例です。
導入後は、利用結果をシナリオ、効果、失敗、Risk、再利用部品としてナレッジ化します。その知見を研修、Guardrail、Template、評価方法へ戻し、成立したシナリオだけを段階的に展開します。
目指すのは、最初から完成した全社 AI 基盤ではありません。
安全に試し、結果から学び、学んだことを人材と基盤へ戻し、価値を確認できた範囲を広げ続けられる組織能力です。
参考資料
- Microsoft 365 Copilot overview
- Agents for Microsoft 365 Copilot
- What is GitHub Copilot?
- Copilot Studio overview
- What is Microsoft Foundry Agent Service?
- What is Azure Copilot?
- Microsoft Security Copilot
- Azure SRE Agent
- Microsoft 365 Copilot adoption guide
- Overview of Microsoft Agent 365
- Microsoft Entra ID Governance for Agent Identities
- Compare Microsoft 365 E3, E5, and E7 license features