3製品の公式ページを順番に読んで、どれも「エージェントが作れる」と書いてあり、区別がつかなかった。そういう経験をされた方に向けて書いています。

結論から書きます。決めるのは2問です。

先に言っておきたいことが1つ。社内の誰かが「Copilot Studio でいいんじゃないか」と言っているなら、その人はたいてい正しい。この記事は反論の材料ではなく、その主張が当たっている条件と外れている条件を見分けるためのものです。

そしてもう1つ。選定に入る前に、社内をひと通り数えたほうがいい。Microsoft 365 Copilot に社内の知識をつなぐ作り方は3製品にまたがっていくつもあって、そのうちのいくつかは Copilot Studio のエージェント一覧に出てきません。「うちにはまだ何もない」と思っていても、もう動いているものがあるかもしれない。どこを見れば数えられるかは、節「社内に何があるか、何を聞くか」にまとめました。

2問で決める

上から順に答えてください。問1 に該当したら、そこで決まります。

この2問は当方が組み立てたものです。公式にも判断の手引きはありますが、Agent Builder と Copilot Studio の2製品だけを比べたもので、Microsoft Foundry が入っていません。3製品を1つの分岐に載せたものは公式にないので、公式の判断基準を組み替えました。

問1 — 次のどちらかに該当しますか

  • 独自のコードやフレームワークを動かす（Microsoft Agent Framework、LangGraph、Semantic Kernel を持ち込む）
  • Azure 側の統制が要件になっている（ネットワーク分離、Azure Policy、モデルを自分の Azure 環境に配置する）

該当する → Microsoft Foundry。

Foundry は Azure のリソースとして動きます。作り方は2種類。指示とモデルとツールを指定するだけの prompt agent と、自分のコードをコンテナに入れて動かす hosted agent です。

該当しない → 問2へ。

判断に迷いやすいので、否定例を1つ。オンプレミスのシステムにコネクタでつなぐだけなら、「Azure 側の統制が要件」には当たりません。 Copilot Studio のコネクタで届きます。ここで言う Azure 側の統制は、エージェントそのものを Azure のリソースとして置き、Azure のネットワークやポリシーの下で動かす必要がある場合の話です。

#### 「モデルを選びたい」は Foundry の理由になりません

ここは誤解されやすいところです。Copilot Studio でも、エージェントの主モデルは選べます。

一般提供されているものに GPT-5.5 Chat、Claude Sonnet 4.6、Claude Opus 4.6 と 4.7。外部モデルとして Anthropic、xAI、Mistral のものも使えます。ただし外部モデルは管理者が有効にしないと出てきません。

ただしこの「選べる」は、公式ページの冒頭で標準ハーネスの機能として説明されています。Copilot Studio の中にはランタイムが3つあるので（後の節で触れます）、どれでも同じように選べるとは読めません。

「モデルを選べたほうがいい」で Foundry に行くと、遠回りになります。Foundry が要るのは、モデルを自分の Azure 環境に置いて使う場合と、独自のコードを動かす場合です。

この誤解が起きる理由ははっきりしています。3製品を「単純なほうから高機能なほうへ並ぶもの」として見ているからです。そう見ると、モデルの選択という高度そうな機能は上のほうにあるはずだと考えてしまう。この見方が外れていることは、記事の最後にもう一度書きます。

問2 — 次のどれかに該当しますか

  • Teams のチャットで使わせる
  • 部門をまたいで配る、または社外に出す
  • 多段階のワークフローや承認が要る
  • Microsoft 365 の外のシステムにつなぐ
  • 開発・テスト・本番の環境を分ける必要がある
  • Customer Managed Keys が要件になっている

該当する → Copilot Studio。

該当しない → Agent Builder。

問2 がこの形になるのは、Agent Builder 側に制約があるからです。公式ドキュメントが「既知の制限」として明示しているもの。

Microsoft 365 Copilot で作ったエージェントは、Teams のチャットでは使えません。ここは読み間違えやすい。Agent Builder 自体は Teams のデスクトップと Web クライアントから使えます。「Teams で作れる」ことと「Teams のチャットで動く」ことが別なので、分けて読んでください。

Customer Managed Keys もサポートされていません。理由が公式に書かれていて、Agent Builder のエージェントは環境に紐づかないから、とあります。

加えて Agent Builder が想定するのは「個人または小さなチーム」。部門や組織や社外顧客に配る前提のもの、多段階のワークフローや承認を含むもの、Microsoft 365 の外のシステムにつなぐものは、Copilot Studio 側に置かれています。

#### Customer Managed Keys を選定条件にするなら、条件があります

Copilot Studio 側で Customer Managed Keys を使うのに要るものは2つ。

  • マネージド環境であること。公式は「Power Platform は Customer Managed Keys をマネージド環境でのみサポートする」と書いています
  • Azure Key Vault

そして代償が2つ。

  • 有効化のあいだ、最大48時間 Copilot Studio が使えなくなります
  • Microsoft Agent 365 のセキュリティ監査ログとして Copilot Studio の外へ送られるデータは、自社で管理する鍵では暗号化されません

「Customer Managed Keys が要件だから Copilot Studio」で終わらせず、ここまで確認してください。48時間の停止は、稼働中の環境なら調整が要ります。

8条件のうち、3つはあなた一人では答えられません

この分岐は8条件です。問1 に2つ、問2 に6つ。

問2 の6条件のうち5つは、あなたが答えられるはずです。「Teams のチャットで使わせるか」「部門をまたぐか、または社外に出すか」「多段階のワークフローや承認が要るか」「Microsoft 365 の外のシステムにつなぐか」「開発・テスト・本番の環境を分けるか」。

残る3つは、他の人に聞かないと答えられません。問1 の2つと、問2 の Customer Managed Keys です。

  • 独自のコードやフレームワークを動かすか → 開発の担当者
  • Azure 側の統制が要件か → クラウド基盤の担当者
  • Customer Managed Keys が要件か → 情報システム部門

答えを持っていない問いに勘で答えると、選定をやり直すことになります。聞くべきことは節「社内に何があるか、何を聞くか」にまとめました。

製品が決まっても、選べないことがあります

分岐は製品を出します。ただし組織側の条件で選べない場合がある。これは選定の入力ではなく拒否権として働きます。

問2 で製品が重なって見えたときは、ここで決まります。組織側の条件を満たせないほうが落ちる。

ただし問1 は別です。 問1 は要件なので、組織側の条件では回避できません。独自のコードを動かす必要があるのに Azure がない、という状態は、製品選定の問題ではなく契約の問題です。選定を進める前に、そこを決めてください。

「Copilot Studio でいい」がいつ正しいか

冒頭に書いたとおり、多くの社内案件は Copilot Studio に着地します。Teams のチャットで使わせたい、部門で使いたい。ごく普通の要望です。それが問2 に該当するので、Copilot Studio になる。

正しいのは、問2 のどれかに該当するとき。上に挙げた6条件のどれかです。

外れているのは2つの場合だけ。

  1. 独自のコードを動かす、または Azure 側の統制が要件なのに Copilot Studio を選ぶとき。Microsoft Foundry の領域です
  2. 問2 のどれにも該当しないのに Copilot Studio を選ぶとき。Agent Builder で足りますし、統制を見る部署も増えません

2番目が見落とされやすい。理由は節「選んだ結果、統制と請求はどこに入るか」で書きます。

決裁の場で使う一文

分岐の結果を、この形で埋めてください。

3つ目と4つ目の空欄は、次の節で埋まります。

選んだ結果、統制と請求はどこに入るか

製品を選ぶと、それを見る場所と請求が立つ場所が変わります。ここが「Agent Builder で足りるなら、そのほうが軽い」の中身です。

この表の並べ方は当方が決めました。各セルの内容は公式ドキュメントの記述ですが、この4項目で横に並べたのは当方の整理です。

公式は3製品を比較表という形では並べていません。代わりに no-code / low-code / pro-code という層として、3つを同じ画面に置いています。社内で「Copilot Studio でいい」と言う人が、この並びを見ている場合があります。あの層は作り手の技術レベルで分けたもので、機能の上下を示したものではありません。 上の層に置かれているものが、下の層のできることを全部含んでいるわけではない（このあと出てきます）。

見る担当が増えるかどうかが、いちばん効きます

決裁の場でいちばん効くのはここです。Agent Builder なら、統制を見る担当が増えません。

Agent Builder を管理するのは Microsoft 365 管理センター。すでに Microsoft 365 を見ている人の作業範囲に収まります。管理者は一覧を見て、有効化・無効化・割り当て・ブロック・削除ができる。

Copilot Studio は Power Platform 管理センターへ移ります。そしてこれは、Microsoft 365 を見ている人とは別の担当者であることが多い。環境の分離、ロールベースのアクセス制御、DLP とコネクタのポリシー、テレメトリ。機能は増えます。ただしそれを回す人が要ります。

Microsoft Foundry は Azure 側。Microsoft Entra の ID、ロールベースのアクセス制御、ネットワーク分離、Azure Policy。さらに Foundry は自前の管理面を持っていて、公式は Foundry Control Plane と呼び、「Microsoft 以外のものを含む複数プラットフォームのエージェントを運用する」場合に使うものだと説明しています。

ここは誤解しやすいので、はっきり書きます。エージェントの統制の受け皿は、1つに集まっていません。Microsoft Agent 365 と Foundry Control Plane が、いまは並立しています。

ややこしいのは、片方向だけ移行が始まっていることです。セキュリティ機能は Agent 365 へ移りました（節「戻せるもの、戻せないもの、払ったもの」の末尾で書きます）。一方で Foundry Control Plane は消えていません。「セキュリティは Agent 365、フリートの運用は Foundry Control Plane」と読むのが、いまのところ実態に近い。

Agent Builder は既存の権限を超えません

公式が統制の原則として2つ挙げています。

新しい権限を作らない。利用者が SharePoint のサイト、Teams のチャネル、Outlook のメールボックスにアクセスできないなら、エージェントもそこの内容を出しません。

標準の記録が残る。監査ログ、アクティビティレポート、DLP と保持のポリシーが、そのまま適用されます。

野放しではない、ということです。そのうえで2つ、頭に置いてください。

まず、管理者が見ていなければ気づきません。統制がないのではなく、確認がないだけ。

もう1つ。Agent Builder は Microsoft 365 の中だけで完結していません。公式は「Copilot Studio が Agent Builder の機能を処理し、Microsoft 365 と Copilot Studio の双方向にデータが流れうる」と書いています。管理面が Microsoft 365 管理センターであることと、処理がそこで閉じていることは別の話です。

ハーネスの違いは、社外公開の可否に効きます

Copilot Studio の内部には、動かし方の違う3つのランタイムがあります。公式が「ハーネス」と呼ぶもの。選定の段階で押さえるのは1点だけでいい。

Copilot チャットハーネスの公開先は「社内チームのみ」です。問2 で「社外に出す」に該当した方は、Copilot Studio を選んだあと、このハーネスは使えません。標準ハーネスと GitHub Copilot ハーネスなら社外顧客にも公開できます。

どのハーネスで作るかは、作るときに決まります。選定の段階であなたが指定するものではありません。ただし「社外に出す」と決めているなら、作る人にその1点を伝えてください。 請求の立ち方もハーネスで変わります（このあと「請求はどこに立つか」で書きます）。

戻せるもの、戻せないもの、払ったもの

決裁の場で必ず聞かれます。「後で変えられるのか」。

Agent Builder から Copilot Studio へは、公式にコピーできます

移るもの。名前、説明、指示、推奨プロンプト、アイコン、ナレッジとして追加した SharePoint のファイル・フォルダ・サイト、ナレッジとして追加した Web サイト。

公式は「この操作でエージェントを Copilot Studio にコピーするので、作り直す必要はありません」と書いています。下から始めても無駄にならない、ということです。

ただし7項目は移りません。うち2項目は機能自体がありません

ここが「上のほうが高機能なんだから最初から Copilot Studio でいい」への答えになります。

公式ドキュメントの構成に注意してください。比較ページは「コピーできる」と書き、専用の節で「エージェントの中核となる設定と指示は保持される」「作業は失われず、やり直す必要なく拡張できる」とまで説明しています。そこだけ読むと、移らないものがあるとは気づけません。

移らない7項目は、そのページからリンクされた別のページにあります。

公式が挙げる「コピーされない設定」は7項目。そのうち2項目は、Copilot Studio に現在その機能がありません。公式の表記は "Not currently supported in Copilot Studio"。参照先を限定したエンタープライズ向けコネクタと、プロンプトから画像を生成する機能です。

残る5項目は移せますが、手作業が要ります。

  1. エンタープライズ向けコネクタの再設定
  2. 埋め込んだファイルの再アップロード
  3. Teams のチャットと会議を使うための Power Platform コネクタの追加
  4. メールを使うための Power Platform コネクタの追加
  5. ドキュメント・グラフ・コードを作る機能（コード実行）の有効化

Copilot Studio は Agent Builder の上位互換ではありません。

ただし決裁の場で効くのは、この2項目より「見る担当が増えるかどうか」です。画像生成が使えるかどうかより、統制を回す部署が増えるかどうかのほうが、決裁者には刺さります。上位互換の話は、技術で押し切られそうになったときの札として持っておく程度でいい。

コピーには条件があります

ライセンス（Copilot Studio または Microsoft 365 Copilot）。利用者の Microsoft 365 ライセンスで Dataverse が使えるようになっていること。公式の表記は Common Data Service のエンタイトルメントです。そしてコピー先の環境がサポートされたデータロケーションにあること。この3つが揃っていないと実行できません。

コピーはスナップショットです。元のエージェントは残りますが、元を更新してもコピー側には反映されません。

逆方向と、Foundry との行き来

Copilot Studio から Agent Builder へ戻す経路は、公式ドキュメントに記述がありません。「できない」ではなく「記述がない」という意味です。

Microsoft Foundry については行き来の経路があります。Foundry のエージェントは Microsoft 365 Copilot と Teams へ直接公開でき、これは一般提供されています。Copilot Studio を経由しません。逆に Copilot Studio から Foundry のエージェントに接続する機能もありますが、こちらはプレビューで、標準ハーネスに限られます。

この「Foundry から直接出せる」は、3製品の関係を考えるときに効いてきます。上の段が下の段を経由せずに出口へ届くなら、それは段ではありません。

請求はどこに立つか

金額の試算はこの記事では扱いません。構造だけ書きます。

別のクラウドの契約が要るのは Microsoft Foundry だけです。 Azure のサブスクリプションと請求先を決める必要があります。前払い枠（公式が Agent Commit Units と呼ぶ枠）を買う場合も、Azure サブスクリプションの所有者か予約購入者のロールが要る。

残る2つがタダという意味ではありません。追加の相手が Microsoft 365 側になるだけです。 公式が「追加費用なし」と書いているのは、Teams・SharePoint・Copilot Chat のチャネルで使う場合に限られます。

  • 社外に出す場合は含まれません。問2 で「社外に出す」に該当した方は、ここを確認してください
  • GitHub Copilot ハーネスを使う場合も含まれません。このハーネスの利用は Microsoft 365 Copilot ライセンスの対象外です
  • Microsoft 365 Copilot のライセンスを持たない利用者が共有のテナントデータ（SharePoint や Copilot コネクタ）を使う場合は、従量課金が発生します。Copilot Studio のライセンスか Power Platform のプランが必要になることもあります

前払い枠は Copilot Studio と Microsoft Foundry を横断します。ただし未使用分は翌年に繰り越されませんし、キャンセルと交換はできません。

金額はあえて出していません。試算に必要な変数（利用者数、機能ごとのレート、ハーネス、チャネル）を持ち込むと、選定の話が試算の話に化けます。決裁の場でまず必要なのは「新しい契約が立つのはどれか」の一行で、桁の話はその次です。ユースケース別の試算は別記事にあります。

2026年7月1日に、統制の前提が変わっています

すでに過ぎた日付です。読者のテナントでは、もう起きたこととして確認してください。

2026年7月1日以降、Copilot Studio と Microsoft Foundry のエージェントに対するセキュリティ機能には、Microsoft Agent 365 のライセンスが必要になりました。従来の Defender for Cloud Apps や Defender for Cloud のライセンスではカバーされません。対象のライセンスを持たないテナントは、この日にこれらの機能を失っています。

対象として公式が名指ししているのは、Copilot Studio と Microsoft Foundry のエージェント。Agent Builder は名指しされていません。ただし「名指しされていない」ことと「対象外である」ことは違うので、断定は避けます。

Copilot Studio のリアルタイム保護については、同じ公式文書の中で記述が食い違っています。片方は「変更なし」と書き、もう片方は対象ライセンスがなければ無効化される機能として挙げている。自社の状況は設定画面で確認してください。 次の節の確認項目に入れました。

社内に何があるか、何を聞くか

冒頭で触れた「一覧に出ないもの」の話です。あわせて、分岐で答えられなかった3条件も、ここで聞いてしまいます。

誰に聞くか

Microsoft 365 のテナント管理者（または Copilot の管理者ロールを持つ人）と、Power Platform 管理者。この2人は別人であることが多いので、両方に当たってください。

分岐の問1 については、開発の担当者とクラウド基盤の担当者。Customer Managed Keys については、暗号鍵の方針を持っている人（情報システム部門のセキュリティ担当）。合わせて5者です。

何を聞くか

棚卸しのために聞くこと。

  1. Microsoft 365 管理センターの Copilot > Agents の一覧を出してほしい（作成者や作成日が出るなら、それも）
  2. Copilot Studio のエージェント一覧も出してほしい。ただし Copilot Studio の中で Microsoft 365 Copilot 向けに作るタイプのエージェントは、この2番目の一覧にも出てきません。1と2を揃えても漏れるので、次の3と4も必要です
  3. Microsoft Agent 365 のエージェントレジストリ（ライセンスがあれば）
  4. Microsoft Foundry から公開されたエージェントがないか。Foundry には自分だけに公開する方法があり、それは管理者の承認を必要としません。上の3か所には出ない可能性があります

分岐の答えを埋めるために聞くこと。

  1. 「独自のコードやフレームワークを動かす必要はありますか」（開発の担当者へ）
  2. 「Azure のネットワーク分離や Azure Policy は要件になっていますか。モデルを自社の Azure 環境に置く必要はありますか」（クラウド基盤の担当者へ）
  3. 「Customer Managed Keys は要件になっていますか。マネージド環境は使っていますか」（情報システム部門へ）

費用と統制の前提を確かめるために聞くこと。

  1. 「うちのテナントに Microsoft Agent 365 の対象ライセンスはありますか」
  2. 「Azure サブスクリプションはありますか。請求先は誰ですか」
  3. 「Power Platform 管理センターを見ているのは誰ですか」
  4. 「Copilot Studio のリアルタイム保護は今も有効ですか」（公式文書の記述が食い違っている点の確認）

11項目は多い。ただし5〜7 が返ってこないと分岐が埋まらないので、削るなら8〜11 のほうです。

5〜7 で「今のところ要件はない」と返ってきたら、それは「無い」として進めてください。ただし1つだけ頭に置いてください。あとから問1 の要件が出てきたときの経路は、公式に見つかりません。 Agent Builder から Copilot Studio へのコピーは用意されていますが、Agent Builder や Copilot Studio から Microsoft Foundry へ持っていく手順は、記述を見つけられませんでした（Copilot Studio から Foundry のエージェントに接続する機能はプレビューであります）。Azure 側の要件が出そうな案件は、最初からそこを詰めたほうが安全です。

返ってきた答えの読み方

0件だった。 上の1〜4で見つからなかった、という意味です。「誰も作っていない」とは断定できません。Foundry から自分だけに公開したものは見えないことがあります。

数件あった。 誰が作ったかを見てください。現場が作っているなら、選定は「これから何を選ぶか」ではなく、すでに動いているものをどう扱うかを含みます。ここで話の性質が変わるので、上司への報告の仕方も変えたほうがいい。

Agent 365 の対象ライセンスがない。 Copilot Studio と Microsoft Foundry を選ぶ判断に、ライセンスの費用が乗ります。

次の一歩

分岐の結果ごとに書きます。

Agent Builder になった方。 この記事で完結します。節「社内に何があるか、何を聞くか」の依頼を出して、既存のエージェントを1〜4の場所で数えてください。

Copilot Studio になった方。 作り方は「Copilot Studioで最初のAIエージェントを作る」、費用は「Copilot Studioの費用をユースケース別に試算する」、使い過ぎの防止は「Copilot Studioのクレジットを使い過ぎないための上限と通知の設定」へ。

Microsoft Foundry になった方。 当方にはまだ Foundry の記事がありません。公式ドキュメントの「Recommended path for new developers」から入るのが早いです。

そもそも業務に向くかどうかで迷っている方。 「Copilot Studioが向いている業務・向いていない業務」を先に読んでください。製品を選ぶ前の話です。

この記事で一番残してほしいのは、8条件の内訳よりも次の1点です。3製品は「下から上へ順に上がる道」としては並んでいない。

公式の層分けは間違っていません。壊れるのはその先です。上に上げれば下でできたことが全部できるわけではないし（7項目のうち2項目は Copilot Studio に機能がない）、上の段が下の段を飛ばして出口へ届くこともある（Foundry から Microsoft 365 Copilot への直接公開）。一列の道だと思っている限り、「とりあえず上を選ぶ」が正解に見えてしまいます。

今日できることを1つ。節「社内に何があるか、何を聞くか」の11項目を投げてください。宛先は同じ節に書いた5者です。別人であることが多いので、分けて出したほうが早く返ってきます。

3製品のどれを選ぶか、選んだあと統制と請求をどこに置くかでお困りでしたら、ご相談ください。使わせる範囲、既存の Microsoft 365 と Azure の契約、統制を見る体制をもとに整理します。お問い合わせフォームからご相談ください。

この記事の主な出典

社内で説明するときに使えるよう、主要な主張の出典を挙げます。すべて2026年8月28日に確認した英語版です（日本語版は機械翻訳で、実機の表記と一致しないことがあります）。

このほか、Customer Managed Keys の条件は Configure customer-managed encryption keys、3製品を層として並べた整理は Agents hub、課金は Licensing and Cost Considerations にあります。

モデル選択のページは、確認した時点で3週間前に更新されていました。 モデルの一覧は動きます。決裁の資料に載せるなら、その日に開き直してください。