見つけたエージェントを、最初の一件へ進める

営業担当者が、商談メモを整理するエージェントをストアで見つけたとする。 デモでは要約から次の行動まできれいに並ぶ。しかし自分のメモには、「導入は次回検討」「価格は未確認」と書かれている。 これを確約や確定価格としてCRMへ入れてしまえば、便利な要約が次の担当者を誤らせる。

これは導入判断を考える想定例である。 試したい担当者、顧客データの接続を確認する管理者、料金を見る調達担当者は、同じ製品を別の問いで見ている。 「掲載されている」「接続できる」「使ってよい」「仕事に役立つ」を一つにまとめると、その違いが消えてしまう。

2026年4月27日までの公開資料から、本稿では五社の発見・配布・調達の入口を比較する。 私の判断は、モデルの能力に加え、候補の説明を具体的な試用条件へ変えられるかを見たい、というものだ。 選んだ理由、許可する範囲、仕事の完了条件を説明できれば、利用者は最初の一件へ進む提案を出せる。

OpenAI：仕事の途中で見つけ、会話から呼び出す

OpenAIの2025年10月6日のAppsの発表は、会話に応じた提案や名前での呼び出しと、会話内の操作画面を説明した。 たとえば、文章の構成からスライドの作成へ進む場面を示している。 使うサービスを別の画面で探すだけでなく、取り組んでいる仕事から候補を知る入口である。

同年12月17日のアプリ申請とディレクトリの発表では、掲載アプリの検索、開発者による審査申請、MCPの接続情報やテスト方法、掲載情報、提供国の提出が説明された。 利用者へデータ共有の種類とプライバシーポリシーを示す接続手順も含まれる。 会話で見つける入口と、提供者が説明をそろえて掲載する入口が結び付いた。

ただし、提供者が掲載審査を通ったことと、自社の顧客メモを扱わせる判断は別である。 商談の例なら、共有される情報と出力先を確認し、曖昧な発言をどう残すかまで試したい。 会話の流れに候補が現れる便利さを生かすには、そこで何を任せるかも具体的にする必要がある。

Anthropic：普段使うサービスをClaudeへつなぐ

Anthropicの2025年7月14日のコネクタディレクトリの発表は、リモートのサービスとローカルのデスクトップ拡張を探す入口を用意した。 接続先に認証する操作と、デスクトップ拡張をインストールする操作を分けている。 発表時には、リモート接続は有料プラン向けという利用条件もあった。

発表の例には、Linearの実際のチケットからリリースノートを作る使い方がある。 一般的な文章を作るだけの状態から、普段の仕事の記録を読む状態へ変わる。 これはベンダーが示した利用例であり、作成時間や正確さが独立に測定された結果ではない。

商談メモの仕事でも、既存サービスをつなぎたいのか、独立した既製エージェントを調達したいのかで探す対象が変わる。 コネクタは、接続先の情報や操作をClaudeから扱うための入口として見ると分かりやすい。 掲載されたツールすべてが、商談整理の業務手順を完成品として備えるとは判断しない。

Microsoft：作る人、許可する人、使う人をつなぐ

Microsoftは2025年5月22日のAgent Storeの発表で、Microsoft、パートナー、自社製のエージェントを見つける場、用途の説明、共有や公開の経路を示した。 自社で作ったものも、担当者の手元に置くだけでなく、利用者が見つける場所へ配れる構図である。

対象日以前に固定したAgent Storeの管理資料では、管理者がデータや操作、提供者、認定情報などを確認し、利用者やグループを選ぶ手順が説明される。 自社製エージェントでは、作成者の申請と管理者の審査を経て公開する流れを示している。 これは資料の当時の版であり、4月にストアが初めて登場したという意味ではない。

営業部門の内部用エージェントなら、業務を知る人が説明や手順を作り、管理者が接続と配布範囲を確認し、担当者が使うという分担を考えられる。 ただし、管理画面に認定情報があることから、曖昧な商談メモを正しく整理する能力まで結論付けることはできない。 掲載や配布の判断と、実際の仕事での品質を併せて見る必要がある。

Google CloudとAWS：購入後の利用先まで比較する

Google Cloudの2025年10月14日のMarketplaceとGemini Enterpriseの記事は、従業員が候補を探し、IT担当へ調達を依頼し、管理者が購入したエージェントを登録する経路を説明した。 提供者側では、A2AのAgent Cardから能力や接続先などの情報を取り込む仕組みを示している。 カタログの情報が、利用先へ登録する判断材料になる。

AWSの同年7月16日のAI agents and toolsの発表も、用途を自然言語で探し、MCPやA2Aへの対応、配備方式を比較し、購入して利用へ進む流れを示す。 AgentCore Runtimeへの配備とGatewayへのツール追加など、利用する対象に応じた経路がある。 利用者の既存アカウントへ接続するだけの操作とは、調達や配備の仕事が異なる。

さらに10月31日のAWSの更新では、Runtime用コンテナの契約・従量課金と、API型の製品のOAuth設定を簡略化する経路が説明された。 どの形で提供されるかによって、運用する環境と費用の確認点が変わる。 同じ用途名が付いていても、購入後の仕事は同じではない。

両社が示す接続や統合の検証は、候補を絞る材料になる。 一方、商談の確約と検討を区別できるか、CRMで必要な項目を埋められるかは、自社のタスクで確かめる必要がある。 Agent Cardや対応規格の情報は接続の説明であり、その業務の合格点を代わりに決めるものではない。

購入候補を比べるAIにも、判断の理由を求める

AWSの2025年11月30日のagent modeの発表は、要件を会話で伝え、候補を比較し、社内承認へ渡す購入提案を作る利用方法を示した。 エージェントを選ぶ作業そのものをAIが支援する例である。 比較表の作成支援と、組織が購入を認める判断は、それでも別に残る。

商談整理なら、「営業支援に向くもの」だけでなく、「顧客の確約がない項目は未確定で残す」「試用ではCRMへ書き込まない」と要件を伝えたい。 候補の説明に対応がなければ、未確認として残す。 比較表が自然な文章で埋まっていても、提供者が説明していない機能を推測で足してよいわけではない。

私は、推薦された候補について、何を根拠に合うとしたか、何が足りず、何を試せば選べるかを求める。 価格の最安値だけでなく、接続準備や人の訂正を含む見積もりが必要になる。 AIが提案を整えることで、担当者が判断しやすくなるかを評価したい。

掲載情報を、一件の試用条件へ変える四つの確認

何を完成させるか

商談の合意、未確定事項、次の担当と期限を整理する。要約の流暢さだけを完了条件にしない。

どの入力と出力を使うか

読むメモ、対応する顧客、下書きの保存先を決める。CRM更新や外部送信を含む場合は別途具体化する。

誰に何を認めるか

試用する利用者とデータ範囲を決める。候補の提供者、接続先、要求する権限を説明と照合する。

費用と配備をどう比べるか

契約、モデル利用、配備先、準備や訂正の負担を確認する。掲載価格の単位が違う候補をそのまま順位付けしない。

これは本稿の試用設計であり、各社の共通仕様ではない。 すでに承認されたサービスを既存の範囲で使うなら、新しい調達が要らない場合もある。 必要な判断を具体化して、担当者が毎回無関係な審査をやり直さずに済む形へまとめたい。

よい候補かどうかは、同じ商談メモで確かめる

最初の試用は少人数とテストデータで行い、既存の手作業と同じメモを使うことを勧める。 確約、検討、日付がない宿題、似た名前の顧客を含め、何を完成とするかを先に決める。 これは本稿の提案であり、実施済みの製品比較ではない。

出力では、元のメモにない約束を追加していないか、未確定を隠していないか、担当者や顧客を取り違えていないかを見る。 読み取りを認めた範囲の外へアクセスしないことも確かめる。 下書きで十分なタスクなら、更新操作を加えず、その範囲で価値を測れる。

導入の評価には、接続準備の時間、レビュー待ち、利用者の訂正時間、採用できた結果を含めたい。 モデルだけを比較する試験ではモデル以外の条件をそろえ、製品を比較する試験では各製品で使える経路と費用を記録する。 早く承認されても訂正が多ければ、仕事の負担は減らない。

逆に、仕事の品質が十分なのに試用へ進めない場合は、何が未確認で止まっているかを探す。 利用者が候補を見つけられないのか、接続範囲が分からないのか、料金単位が違うのか。 ここまで分ければ、追加のモデル比較が必要か、導入条件の説明を補うべきかを判断できる。

使い始めた後の変更と停止も、試用に含める

利用目的、対象者、接続先、操作、確認した版を記録することを勧める。 商談の下書きだけを認めた製品が、更新後にCRMへの書き込みを要求したなら、同じ判断のまま使ってよいかを見直す。 これは本稿の運用提案であり、すべてのストアが同じ再承認を自動で行うという説明ではない。

停止するときは、ストアから使えなくすること、既存の接続を外すこと、実行中の仕事を止めることを分けて確認する。 提供者や接続先に残った認証も、必要に応じて失効させる。 一覧から消えたことだけで、すでに開始した処理や共有したデータまで取り消されたとは考えない。

利用者には、使えなくなった理由と、未完の下書きをどこへ引き渡すかも示したい。 止められる設計は、任せた仕事の状態を説明できる設計でもある。 候補発見の便利さと、利用後の変更を判断する手順を一緒に比べる。

仕事の詰まり方に合わせて、入口を選ぶ

既存サービスの情報を会話で使いたいなら、接続候補とデータ共有の説明を先に見る。 自社の手順を部門へ配りたいなら、作成者の申請から管理者の審査、利用者への配布までを追う。 パートナー製品を買いたいなら、料金、配備方式、利用先への登録まで比較する。

既製品が試用条件を満たすなら、自社で一から作る必要はないかもしれない。 固有の顧客識別や未確定事項の扱いが足りなければ、設定や追加実装で補えるか、独自に作る方がよいかを比べる。 ストアにあることも、自社製であることも、それだけで採用理由にはならない。

目指したいのは、担当者が「これを使いたい」と言えるだけでなく、「この仕事へ、この範囲で試し、この結果なら広げたい」と説明できることだ。 モデルの能力を確かめる仕事と、部署へ導入する仕事をつなぐ。 その説明を助けるカタログと配布経路なら、見つけた候補を実務の一件へ進められる。