2026年9月現在、AIエージェント基盤は「開発」「実行」「業務データ連携」のどこを任せたいかで選ぶ。GoogleはADKなどによるコード開発と統合管理、AWS Bedrock AgentCoreはフレームワークを問わない実行基盤、Microsoft Copilot Studioはローコードの業務エージェント構築を比較の出発点にするとよい。
名称の補足: Google公式ではVertex AI Agent Builderは現在、Gemini Enterprise Agent Platformの一部として案内されている。本記事では旧称で検索する読者にも分かるよう旧製品名を併記する。出典: Google公式ドキュメント（確認日: 2026年9月9日）。
「うちはAWSだけど、AIエージェントもAWSで作るべき？」
この質問、最近めちゃくちゃ多い。正直、1年前なら「既存のクラウドに合わせておけばいい」で済んだ。でも2026年9月時点では、Google・AWS・Microsoftの3社がそれぞれ本気のAIエージェント基盤を出していて、機能差が無視できないレベルになっている。
3社の公式ドキュメントを比較すると、開発ツール、実行基盤、業務データ連携に置く重点が異なる。以下のコードは公式API仕様に合わせた構成例であり、この更新でクラウドへデプロイした実測結果ではない。この記事では、Google Vertex AI Agent Builder、AWS Bedrock AgentCore、Microsoft Copilot Studioを、開発者目線で徹底比較する。
スペック比較 — 3プラットフォームの全体像
| 項目 | Google Vertex AI Agent Builder | AWS Bedrock AgentCore | Microsoft Copilot Studio |
|---|---|---|---|
| リリース時期 | 2024年GA、2026年2月大幅強化 | 2025年10月GA（AWS公式リリースノート） | 2023年GA、2026年3月Wave 1更新 |
| 開発アプローチ | コード中心（ADK）+ ローコード | フレームワーク非依存・インフラ層 | ローコード中心 + Pro開発者向けSDK |
| 対応LLM | Gemini・第三者モデル（Model Garden。利用条件はモデルごとに確認） | 任意の基盤モデル（エージェント実装から接続） | Copilot Studioで提供されるモデルを選択（環境・提供状態による） |
| マルチエージェント | ADKで標準サポート、A2Aプロトコル対応 | フレームワーク非依存で任意の構成可能 | Copilot Studio内でエージェント間委譲 |
| セキュリティ | VPC-SC、CMEK、IAMベースのエージェントID | microVMセッション分離、VPC接続、PrivateLink | Azure Sovereign Cloud、Defender AI Security |
| プロトコル対応 | A2A、MCP | MCP | MCP、A2A（Computer Useは別のUI操作機能） |
| 課金モデル | 従量課金（vCPU時間 + クエリ数） | 標準サーバーレス従量 / InstancesはEC2料金と管理料金 | Copilot Creditsの従量課金・前払い等（標準ハーネス。Microsoft 365 Copilotの対象利用は別条件） |
| 最適ユーザー | Pythonで書きたい開発者 | インフラ制御を重視するエンジニア | Microsoft 365を使う組織のビジネスユーザー |
開発体験で比較する — 最初のエージェントを動かすまで
エージェント基盤を選ぶとき、最初に気になるのは「どれくらい早く動くものが作れるか」だろう。3つのプラットフォームで、同じ「社内FAQ応答エージェント」を構築してみた想定シナリオで比べる。
事例区分: 想定シナリオ
以下は公式ドキュメントとチュートリアルを基に構成した典型的な開発フローです。
Google Vertex AI Agent Builder — ADKで100行以下
GoogleのAgent Development Kit（ADK）は、Pythonでエージェントを書くためのオープンソースフレームワークだ。LangChainやLlamaIndexとの統合も標準で、既存のPythonエコシステムをそのまま活かせる。
# 構成例: Python 3.10以降。公式Quickstartを基にした最小例（未実行）
# pip install google-adk
# GOOGLE_API_KEY等の認証設定は公式Quickstartに従う
from google.adk.agents.llm_agent import Agent
# 説明用のサンプルデータ。実在する会社の規程ではありません。
def search_faq(query: str) -> dict:
"""説明用FAQを検索する。本番では認可済みの検索処理に置き換える。"""
if "有給" in query:
return {"answer": "申請手順と承認者を人事担当者に確認してください。"}
return {"answer": "該当FAQはありません。人事担当者に確認してください。"}
root_agent = Agent(
model="gemini-flash-latest",
name="faq_agent",
description="説明用FAQを検索するエージェント",
instruction="search_faqを使って回答し、情報がなければ人事担当者への確認を案内してください。",
tools=[search_faq],
)
# この例はGemini APIでの開発用。Vertex AIでの実行は認証・モデル設定を別途行う。
# latestはモデル更新に追従する。本番ではモデル選定と回帰テストが必要。
ポイント: ADKはPython開発者にとって直感的。A2A（Agent-to-Agent）プロトコルに対応しているので、Google以外のプラットフォームで動くエージェントとも連携できる。Agent Engineにデプロイすれば、スケーリングやセッション管理は自動。
AWS Bedrock AgentCore — インフラ抽象化のプロ
AgentCoreの特徴は、「どのフレームワークで作ったエージェントでも動く」こと。LangChain、CrewAI、自前のPythonスクリプト、何でもいい。AgentCoreが面倒を見てくれるのは、ランタイム、セキュリティ、オブザーバビリティのインフラ層だ。
# 構成例: AgentCore Runtimeへデプロイ済みのエージェントを呼び出す（未実行）
# pip install --upgrade boto3
# AWS認証を設定し、呼び出し権限 bedrock-agentcore:InvokeAgentRuntime を付与する
import json
import os
import uuid
import boto3
client = boto3.client("bedrock-agentcore", region_name=os.environ["AWS_REGION"])
response = client.invoke_agent_runtime(
agentRuntimeArn=os.environ["AGENT_RUNTIME_ARN"],
runtimeSessionId=str(uuid.uuid4()),
contentType="application/json",
accept="application/json",
payload=json.dumps(
{"prompt": "有給休暇の申請方法を教えてください"},
ensure_ascii=False,
).encode("utf-8"),
)
print(response["response"].read().decode("utf-8"))
# promptはこの構成例の入力キー。実際にはデプロイ済みエージェントの入力仕様に合わせる。
# このコードはデプロイ処理ではない。OAuth認証のRuntimeには直接HTTPS経由でアクセスする。
ポイント: AgentCoreの強みはmicroVMによるセッション分離。標準サーバーレスのmicroVM方式はセッションを分離して実行するが、ツールの認可や外部データストアのアクセス制御まで不要になるわけではない。セッション上限は標準microVM方式で最大8時間、2026年8月6日にGAとなったRuntime Instances方式で最大14日間と異なる。
Microsoft Copilot Studio — 自然言語でエージェントを作る
Copilot Studioは、他の2つとはアプローチが根本的に違う。「エージェントを作るのに、コードは必須ではない」という思想。Microsoft 365のデータを知識ソースやコネクタから利用できるのが比較上の特徴だ。ただし、必要な接続、認証、アクセス権の設定は別途行う。
// 構成例: 公開済みCopilot Studioエージェントとの会話接続（未実行）
// npm install @microsoft/agents-copilotstudio-client
// ESMファイル（例: client.mjs）で実行する。
import {
CopilotStudioClient,
ConnectionSettings,
} from '@microsoft/agents-copilotstudio-client';
const token = process.env.COPILOT_ACCESS_TOKEN;
const environmentId = process.env.COPILOT_ENVIRONMENT_ID;
const schemaName = process.env.COPILOT_SCHEMA_NAME;
if (!token || !environmentId || !schemaName) {
throw new Error('認証トークン・環境ID・エージェントのスキーマ名を設定してください');
}
const settings = new ConnectionSettings({ environmentId, schemaName });
const client = new CopilotStudioClient(settings, token);
for await (const activity of client.startConversationStreaming()) {
if (activity.text) console.log(activity.text);
}
for await (const activity of client.sendActivityStreaming({
type: 'message',
text: '有給休暇の申請方法を教えてください',
})) {
if (activity.text) console.log(activity.text);
}
// トークンは適切な権限の認証フローで取得し、ログに出さない。
// SharePointの知識ソース設定やエージェント作成を行うコードではない。
ポイント: エージェントの作成は自然言語やグラフィカルな画面で行い、上のSDK例は公開済みエージェントへの会話接続に使う。Microsoft公式の更新履歴では、A2Aは2026年4月、Computer Useは同年5月のGA項目に掲載されている。両者はそれぞれエージェント連携とUI操作であり、同じ機能ではない。
本番運用で比較する — スケーリングと監視
2026年9月の確認ポイント:GoogleはAgent BuilderからGemini Enterprise Agent Platformへの案内に移行している。AWSは2026年8月6日発表のRuntime Instancesで、EC2の計算資源を使う実行方式を追加した。標準microVM方式と長時間実行の上限が異なり、InstancesにはEC2料金に加えてプロビジョニングした計算資源の管理料金がかかる。Microsoftは2026年7月以降、新規エージェントにMicrosoft EntraエージェントIDを自動作成し、環境レベルでオプトアウトできないと案内している。開発の手軽さだけでなく、実行方式・認証・課金単位を同じユースケースで比較したい。
上記の一次情報（確認日: 2026年9月9日）: Googleの移行案内 / AWS Runtime Instances GA（2026年8月6日） / Copilot Studio更新履歴（2026年7月の項目） / Copilot Creditsのライセンス条件。
PoC（概念実証）で動くことと、本番環境で安定運用できることは別物だ。ここの差が、実は3プラットフォームで一番大きい。
| 運用機能 | AWS | Microsoft | |
|---|---|---|---|
| オートスケーリング | Agent Engineが自動管理 | 標準サーバーレス / EC2 Runtime Instances（構成に応じて管理） | Azure基盤で自動 |
| セッション管理 | Agent Engine Sessions（GA） | 標準microVM方式のセッション分離 / EC2 Runtime Instances | Copilot Studio内蔵 |
| オブザーバビリティ | トレース・ログ・イベント | AgentCore Observability | Power Platform分析 |
| メモリ（長期記憶） | Memory Bank（GA） | エピソードメモリ（GA） | Work IQ連携 |
| コード実行 | サンドボックスCode Execution（GA） | Code Interpreter | Power Automate連携 |
| ロングランタスク | 標準対応 | 標準microVM: 最大8時間 / Runtime Instances: 最大14日間（AWS、2026年8月6日） | Power Automate Flowで対応 |
| IaCサポート | Terraform対応 | CloudFormation, CDK, Terraform | Bicep, ARM |
AWSの「microVMセッション分離」は、金融やヘルスケアなどの規制業界で特に響く。標準microVM方式のセッション分離は仮想化による隔離であり、物理専有やSOC 2・HIPAAへの適合をそれだけで保証するものではない。Googleはオープンスタンダード（A2A、MCP）への対応でマルチクラウド戦略に強く、Microsoftは既存のMicrosoft 365データや業務ツールとの連携を軸に選定しやすい。
セキュリティとガバナンスで比較する
エンタープライズにとって、ここが一番の選定基準になることが多い。
Google: オープンスタンダード重視
VPC Service Controls（VPC-SC）でネットワーク境界を設定し、CMEK（Customer-Managed Encryption Keys）で暗号化キーを自分で管理できる。2026年2月にはIAMベースのエージェントIDがプレビューで登場し、「どのエージェントが何にアクセスできるか」をIAMポリシーで制御できるようになった。
AWS: 分離アーキテクチャのリーダー
AgentCoreの最大の特徴はmicroVMによるセッション分離だ。Firecrackerベースの軽量VMで各セッションを隔離する。AgentCore Policyでは、自然言語でエージェントの行動境界を定義できる。「顧客データの削除は禁止」「外部APIへのアクセスは承認済みリストのみ」といったルールを、コードではなく言葉で書ける。
Microsoft: エコシステム統合型セキュリティ
Azure Sovereign CloudでHIPAA、SOC 2、CCPAに対応。Microsoft Defender AI Security Posture Managementで、AIエージェントの脅威を既存のセキュリティ運用と統合的に監視できる。IT部門が知らないうちに従業員が作る「シャドーAIエージェント」の検出機能は、Microsoftだけの特徴だ。
【要注意】プラットフォーム選定で失敗する3つのパターン
失敗1: 「とりあえず既存クラウドで」と思考停止する
❌ AWS環境だからBedrock一択でしょ、と深く検討しない
⭕ ユースケース（社内生産性 vs 顧客対応 vs データ分析）ごとに最適なプラットフォームを評価する
なぜこれが重要か: 社内のMicrosoft 365データを使うエージェントなら、AWS上に構築するよりCopilot Studioの方が圧倒的に早い。逆に、マルチクラウドで動くエージェントが必要なら、GoogleのA2Aプロトコル対応が効いてくる。
失敗2: PoCの開発速度だけで判断する
❌ デモが一番早くできたプラットフォームに決定
⭕ 本番運用に必要な要素（監視、ロールバック、コスト管理、セキュリティ監査）まで含めて評価する
なぜこれが重要か: IDCの予測では、Global 1000企業の多くがAIインフラコストを最大30%過小見積もりするとされている（参照: IDC/CIO.com, 2025）。PoC段階では見えないインフラコスト、運用コスト、セキュリティ対応コストが本番で表面化する。
失敗3: ベンダーロックインを軽視する
❌ プラットフォーム固有の機能に全面依存する設計
⭕ MCP（Model Context Protocol）やA2Aなどのオープンプロトコルを活用し、ポータビリティを確保する
なぜこれが重要か: AIエージェントの領域は変化が極めて速い。今年最適なプラットフォームが来年も最適とは限らない。エージェントのコアロジックをオープンなフレームワーク（LangChain、ADK等）で書いておけば、プラットフォーム移行のコストを大幅に抑えられる。
筆者のおすすめ — 組織タイプ別の選び方
Google Vertex AI Agent Builderを選ぶべき組織
- Python開発者チームがいる
- マルチクラウド or マルチベンダー戦略を採用している
- A2AやMCPなどオープンプロトコルでの相互運用を重視する
- Geminiモデルの日本語性能を活かしたい
AWS Bedrock AgentCoreを選ぶべき組織
- AWS環境に投資済みで、インフラチームが強い
- 金融・医療などの規制業界で、セッション分離が必須
- フレームワークに縛られたくない（LangChain今日、CrewAI明日、でもOK）
- ロングランタスク（データ分析、レポート生成等）が多い
Microsoft Copilot Studioを選ぶべき組織
- Microsoft 365を全社で使っている
- 非エンジニアのビジネスユーザーにもエージェント作成を開放したい
- Teams・Outlook・SharePointのデータを即座に活用したい
- IT部門がシャドーAI対策を含むガバナンスを求めている
正直、2026年9月時点で「この1つが全方位で最強」というプラットフォームは存在しない。むしろ、ユースケースごとに使い分ける「マルチプラットフォーム戦略」が現実解になりつつある。社内生産性はCopilot Studio、顧客対応エージェントはBedrock、R&D向けの実験的エージェントはVertex AI、という組み合わせは十分あり得る。
運営元 Uravation よりAIエージェントを構想から本番運用まで進める順番と、体制・KPIの決め方をまとめた資料を無料で公開しています。 AIエージェント導入ロードマップを受け取る（無料）
参考・出典
- Vertex AI Agent Builder | Google Cloud — Google Cloud（参照日: 2026-03-19）
- Amazon Bedrock AgentCore — AWS（参照日: 2026-03-19）
- 6 core capabilities to scale agent adoption in 2026 — Microsoft Copilot Blog（参照日: 2026-03-19）
- Agent Development Kit (ADK) Documentation — Google（参照日: 2026-03-19）
- 2026 Release Wave 1 Plans for Copilot Studio — Microsoft（参照日: 2026-03-19）
- ADK Python Quickstart — Google（確認日: 2026-09-09。Agent定義・instruction・関数ツール・モデル指定の確認）
- Boto3 invoke_agent_runtime / AgentCore Release notes — AWS（確認日: 2026-09-09。Runtimeの呼出APIと2025年10月のGA記録）
- CopilotStudioClient / ConnectionSettings — Microsoft（確認日: 2026-09-09。SDKの会話接続仕様）
まとめ: 今日から始める3つのアクション
- 今日: 自社のAIエージェントユースケースを3つ書き出し、「社内データ連携」「セキュリティ要件」「開発チームのスキル」の3軸で優先度をつける
- 今週中: この記事の比較表を使って、最優先ユースケースに最適なプラットフォームの無料枠でPoCを開始する
- 今月中: 本番運用を見据えて、セキュリティ要件（データ分離、アクセス制御、監査ログ）のチェックリストを作成し、プラットフォームの適合性を検証する
あわせて読みたい:
- Google ADKでAIエージェントを構築する実践ガイド — ADKの詳細な使い方をステップバイステップで解説
- A2Aプロトコルとは？MCPとの違いとマルチエージェント連携の新常識 — オープンプロトコルの全体像を把握
—
この記事はAIgent Lab編集部がお届けしました。ご質問・ご相談は お問い合わせフォーム からお気軽にどうぞ。
