AIエージェントの導入判断は、モデル比較より「どこで見つかり、誰が許可するか」で決まる

1. 発見面

まず必要なのは、エージェントを探す面である。OpenAI は ChatGPT app directory、Anthropic は Claude directory、 Microsoft は Agent Store、Google Cloud と AWS は Marketplace を前に出す。ここでは会話そのものより、 検索、カテゴリ、注目一覧、パートナー一覧の方が導入を左右し始める。

2. 承認面

見つかるだけでは足りず、誰が有効化するかが必要になる。OpenAI は workspace 管理者に app enablement や action control、 parameter constraint、domain restriction を持たせる。Anthropic も owner が organization connector を有効化する。 Microsoft は request、publish、approve の流れを正面から製品化している。

3. メタデータ面

何を比較するかも変わっている。今は単なる説明文より、Capabilities、write action、Certification、pricing model、 deployment option、protocol support、Agent Card のようなメタデータが重要になる。Google Cloud が A2A Agent Card を listing の核に置き、 AWS が MCP / A2A や pricing / deployment filter を前面に出すのは、その典型である。

4. 配備面

最後に必要なのは、カタログから実際の仕事場へ入る面である。OpenAI は ChatGPT conversation と custom apps、 Anthropic は Claude / Claude Desktop、Microsoft は Microsoft 365 Copilot、Google Cloud は Gemini Enterprise、 AWS は AgentCore Runtime や Gateway までを配備経路にしている。ここが弱いとカタログはあっても使われない。

OpenAI は、利用者向けのアプリ面を一気に統合した

Apps in ChatGPT は search、deep research、sync、write actions、custom app を一つの語彙へまとめた。 Apps SDK も approved app を ChatGPT app store と Codex distribution へつなげ、developer mode は read / write を含む MCP client として働く。 OpenAI の特徴は、配布面が利用者向け製品の中にそのまま見えていることだ。

Anthropic は、MCP-backed integration を Claude の通常操作へ近づけた

Claude can now connect to your world は integrations を調査と実務操作の両方へ広げ、directory は one-click の接続面を用意した。 help center では pre-built connector と custom connector の追加手順、owner による organization enablement が明示されている。 Anthropic の強みは、接続規約の話を UI と接続手順へ落とし切っている点にある。

Microsoft は、エージェントをレジストリと承認フローで管理する色が強い

Agent Store は Microsoft、partner、自社製 agent を同じカタログで扱い、Admin Center 側で Capabilities、Data & tools、 Security & compliance、Certification、Activity を review できる。Agent 365 はその上で agent ID、registry、access control、 visualization、security をまとめる。つまり Microsoft は、エージェントを app というより managed asset として見せている。

Google Cloud は、パートナー配布と enterprise deployment を A2A でつないだ

Cloud Marketplace 側では AI agent が出品対象になり、A2A Agent Card が存在条件になる。Gemini Enterprise 側では Google-made agent、partner-made agent、自社製 agent をまとめて発見し統制できると説明される。 Google Cloud の特徴は、marketplace listing と enterprise runtime を protocol metadata でつなぐ構図が明確な点である。

AWS は、調達と deployment option を agent product の一部として前面化した

AWS Marketplace の AI agents and tools は、semantic search、category browsing、deployment option、pricing model、 compliance filter、MCP 対応を見る購入者向けの面になっている。さらに agent mode が search、comparison、evaluation の specialized agents で software procurement を助ける。AWS の主眼は、agent を買って比べて配備するまでの friction を減らすことにある。

directory 掲載は、信頼の代わりではない

listing があると導入候補にはなりやすいが、それだけで安全とは言えない。実務で必要なのは、どのデータを読むのか、 どの操作を書けるのか、どの接続先ドメインへつながるのか、どの認定や証明があるのかを別に見ることだ。

MCP / A2A 対応は、統制の代わりではない

protocol support は portability と discoverability を強くするが、「誰が approve するか」「どこで revoke するか」は別レイヤーである。 OpenAI の action control、Anthropic の owner enablement、Microsoft の publish / approve、Google の marketplace review が必要になるのはそのためだ。

承認フローは、後付けの admin 機能ではない

今の product 差は、agent の賢さだけでなく受け入れの速さにもある。申請、review、publish、block、parameter constraint が product surface としてあると、agent の展開速度と事故率の両方が変わる。

調達できることと、運用できることも別である

Marketplace が procurement friction を下げても、継続運用時の observability や write action の統制が弱ければ本番運用は難しい。 つまり discovery surface の次に見るべきは、運用責任を引き受けられる control surface があるかどうかである。

workspace 内の調査・文書作業

• admin が write action のある app を制限しつつ、検索系 app だけ先に enable する
• user は directory から必要な app を connect し、会話の中で使い分ける
• 導入差は model quality より app availability と action policy に出やすい

営業や顧客対応の既製エージェント導入

• Microsoft の template agent や Agent Store のように、業務 agent を catalog から選ぶ流れが出てきた
• 重要なのは prompt より、誰に deploy するか、どの data と tool を触るか、handoff をどう見るかである
• approval chain が弱いと rollout は止まりやすい

パートナー製エージェントの比較と調達

• Google Cloud や AWS では、agent を catalog で比較し、pricing、deployment option、protocol support を見ながら選べる
• buyer は use case だけでなく、container か API か、どこへ登録できるか、どの compliance に乗るかを先に見られる
• この時点で procurement は technical design と分離しにくい

自社製エージェントの社内展開

• Apps SDK、custom connector、Agents SDK、A2A Agent Card のような surface があると、自社 agent も catalog に載せやすい
• 重要なのは build speed より、publish ルール、review、更新手順、disable のしやすさである
• internal rollout でも distribution surface がある方が、shadow agent を減らしやすい

見つけやすさが足りない組織では、directory と store が先に効く

まず必要なのが「何が使えるのか分からない」を解くことなら、app directory、Agent Store、partner marketplace の整備度が大きい。 ここでは model の微差より、catalog の分かりやすさが adoption を左右する。

承認待ちが痛い組織では、admin control が比較軸になる

apps や connectors を一つずつ人手で審査すると展開が遅い。RBAC、action control、parameter constraint、publish workflow、 domain restriction が product に組み込まれているかが重要になる。

partner ecosystem を重視する組織では、marketplace metadata の厚みが効く

pricing、deployment option、protocol support、certification、partner validation が揃っていると、buy versus build の判断が速くなる。 ここでは Google Cloud と AWS の見せ方が比較しやすい。

移植性を重視する組織では、protocol だけでなく admission policy も見るべきである

MCP や A2A は移植性を高めるが、実務ではそれだけで足りない。誰が listing を作るか、誰が publish するか、どこで block できるかまで見ないと、 「つながるが運用できない」状態に陥りやすい。