はじめに
こんにちは！最近エンタープライズ向け AI エージェントの設計を何本も触っている横浜情報機器株式会社のロホマン シャヒンです。
Microsoft Tech Community に「Copilot Studio と Microsoft Foundry、どちらで AI エージェントを作るべきか」という実践的なガイドが公開されました。社内でも「どっちを使えばいいの？」という質問をよく受けるので、内容を整理してみました。
競合ではなく「出発点の違い」——この視点がすごくしっくりきました。
1. まず整理：2つのプラットフォームとは
Microsoft は現在、AI エージェントを構築するためのプラットフォームを2つ提供しています。
Microsoft Copilot Studio は、ローコードのガイド付き開発環境です。ビジネスユーザーや IT 管理者が、コードをほぼ書かずに会話型エージェントを素早く作れます。Microsoft 365 や Teams とのネイティブ統合が強みで、HR アシスタントや社内ポリシーボットといったユースケースで力を発揮します。
Microsoft Foundry（旧 Azure AI Foundry）は、コードファーストの Azure ネイティブ環境です。開発者・アーキテクト・AI エンジニアが、アーキテクチャ設計からデプロイ・運用まで自前でコントロールしたい場合に使います。GitHub や VS Code との連携、CI/CD パイプライン統合、高度な評価・トレーシングが揃っています。
「どちらが優れているか」ではなく、「チームの状況に合った出発点はどちらか」が正しい問いの立て方です。
2. Copilot Studio が向いているケース
Copilot Studio を選ぶべき状況には、次のような特徴があります。
- ビジネス部門・IT 管理者が主体となってエージェントを作る・運用する
- ローコードのガイド付き操作で素早くデプロイしたい
- Microsoft 365 や Teams に直接組み込む体験が必要
- ビジネスプロセスの自動化（承認フロー、チケット起票、ステータス確認など）
- ソフトウェア開発リソースにあまり依存したくない
代表的なユースケースは以下のとおりです。
| ユースケース | なぜ Copilot Studio が適切か |
|---|---|
| HR ポリシーアシスタント | ビジネス主導で運用、コンテンツ変更が頻繁 |
| IT ヘルプデスクトリアージ | 会話 UI ＋ ワークフロー自動化で対応可能 |
| 従業員セルフサービスポータル | Teams ネイティブ統合、管理しやすい |
| 部門別オンボーディングエージェント | 設定変更は現場が担当できる |
「開発速度を最大化して、まず動くものを届けたい」というシナリオでは Copilot Studio が圧倒的に速いです。
3. Microsoft Foundry が向いているケース
Foundry を選ぶべき状況は、コードファースト・エンタープライズグレードの要件が絡むときです。
- 開発者・アーキテクトがエージェントをソフトウェア製品として構築する
- カスタムオーケストレーションや複雑なシステム連携が必要
- 高度なモデル選定・ライフサイクル管理が求められる
- マルチエージェントシステムや長時間実行ワークフローを組む
- プライベートネットワーキング・コンプライアンス・データレジデンシーの要件がある
- GitHub・VS Code・DevOps ツールチェーンと統合したい
- 高度な評価・トレーシング・可観測性が必要
特に、複数のシステムをまたいで動く AI エージェントや、監査ログ・ガバナンス要件が厳しい業種（金融・医療・製造など）では Foundry の強みが際立ちます。
4. 実践シナリオ別の推奨プラットフォーム
Microsoft の公式ガイドに掲載されている4つのシナリオが分かりやすかったので、日本語でまとめます。
シナリオ①：HR ポリシーアシスタント
SharePoint のドキュメントをもとに社内ポリシーや休暇申請の質問に答えるエージェント。
→ 推奨: Copilot Studio
ビジネス主導で運用でき、コンテンツ更新が頻繁。素早いデプロイが価値を最大化する。
シナリオ②：IT ヘルプデスクトリアージエージェント
質問への回答、チケット起票、ステータス確認、エスカレーションを自動化。
→ 推奨: Copilot Studio（または Hybrid）
基本は Copilot Studio
で対応可。カスタム検索や高度なオーケストレーションが必要になれば Foundry
で拡張。
シナリオ③：エンタープライズアーキテクチャアドバイザー
要件を受け取り、アーキテクチャパターンを提案、設計成果物を生成し、リスクを特定する。
→ 推奨: Microsoft Foundry
構造化出力・推論・評価・エンジニアリングワークフロー連携が必要。
シナリオ④：マルチエージェント型保険金請求処理システム
書類理解・不正評価・ポリシー照合・顧客通知・エスカレーションを複数エージェントで自動化。
→ 推奨: Microsoft Foundry（ユーザー向け UI は Copilot
Studio）
オーケストレーション・監視・ガバナンス・複数コンポーネント連携がコードファーストを必要とする。
5. 2つを組み合わせる「ハイブリッドアプローチ」
ほとんどの企業は、最終的に両方を使うことになります。
典型的なパターンは「Copilot Studio でビジネス向けフロントエンドを提供しながら、Foundry がカスタムオーケストレーション・高度な推論・エンタープライズ統合をバックエンドで担う」という構成です。
重要なのは、最初から「片方に統一しなければ」と思わないことです。今日のチームが一番速く動ける出発点から始めて、要件が育つにつれて拡張していく方が現実的です。
相互運用性を設計するときは、以下の4層を意識すると整理しやすいです。
- ツール・コネクタ層 — API・プラグイン・エンタープライズシステム
- エージェント層 — 専門エージェント同士の連携
- ワークフロー層 — ビジネスプロセス・自動化との統合
- チャンネル層 — Microsoft 365・Teams・カスタムアプリ
ガバナンスの設計も早めに行うことが重要で、Agent 365 などのツールを使うと Copilot Studio・Foundry 両方のエージェントを横断して監視・管理できます。
6. よくある失敗パターン
Microsoft のガイドで指摘されていた3つのミスが、実際の現場でもよく見られます。
ミス①：Copilot Studio と Foundry
を「競合」として扱う
どちらか一方を選ばなければならないという前提で動くと、チームに合わない選択をしてしまいがちです。「どちらから始めるか」に問いを変えると、判断がぐっとクリアになります。
ミス②：エージェントの複雑さだけで選ぶ
「複雑なエージェントだから
Foundry」という判断は単純すぎます。ビルダーペルソナ・所有権モデル・デプロイアプローチが実際の成否に影響します。
ミス③：評価とガバナンスを後回しにする
「まず動かしてから品質を考える」は AI
エージェントでは正直なところ厳しいです。品質・安全性・信頼性の評価指標は、最初の設計段階から一緒に決めておくのが結果的にラクでした。
7. まとめ
- Copilot Studio はビジネス主導・ローコード・素早い価値提供が必要な場面に強い
- Microsoft Foundry はコードファースト・高度なオーケストレーション・エンタープライズガバナンスが必要な場面に強い
- 「競合ではなく相補」——多くの組織は最終的に両方を使う
- 選択の軸は「誰が作るか」「どう運用するか」「どのレベルのコントロールが必要か」
- ガバナンス・評価は後回しにせず最初から設計する
この記事が少しでも参考になったら、ぜひシェアしていただけると嬉しいです！