SaaSが「名前付きの同僚」を出荷し始めた
これまでAIエージェントは「機能」だった。要約する、下書きする、検索する——アプリに付いた便利なボタンの延長線上にあった。ところが2026年9月、その位置づけが静かに、しかし決定的に変わった。SaaSベンダーが名前と職種を持つエージェントを、あたかも新入社員のように出荷し始めたのだ。
Salesforceは9月11日、Casey・Paige・Carter・Hunter・Marshall・Piper・Fin という7体の名前付き「Agentforce」エージェントを発表した（Salesforce公式）。同じ月、AnthropicとSalesforceは「Claudeforce」を打ち出し、CRMをそのままClaudeの中へ持ち込んだ（Salesforceプレスリリース）。Microsoftも営業・サービス・財務向けの役割別Copilotを準備している（Constellation Research）。
homulaは特定ベンダーに寄らないAIエージェント・インテグレーターとして、この「製品にエージェントが埋め込まれる」流れを日々見ている。本稿は、何が起きたのかを一次情報で整理したうえで、日本企業がどのプラットフォームに乗るか以前に引いておくべき設計の線——中立レイヤー——を論じる。
何が変わったのか——「機能」から「職種を持つ実体」へ
今回の波の本質は3点に集約できる。
1. エージェントに「職種」と「持続時間」が与えられた
Salesforceの7体は、それぞれ営業・カスタマーサービス・コマース・IT/HR・サプライチェーン・CX という業務機能に割り当てられている。たとえば Casey は音声・SMS・WhatsApp・Webチャットをまたいで問い合わせを解決するサービスエージェント、Paige は Slack や社内ポータルで従業員のIT/HR依頼を捌くエージェントで、いずれもすでに一般提供されている（Salesforce Break、Unite.AI）。
とりわけ重要なのは、アウトバウンド営業を担う Hunter が新しい 「ロングホライズン・ランタイム（long-horizon runtime）」 の第一号として、数週間〜数か月にわたって案件を追い続ける設計になっている点だ（Salesforce Blog）。このランタイムは3つの能力で支えられている。
- メモリ: セッションをまたいで文脈と進捗を保持し、会話が終わっても仕事が止まらない
- 永続実行（durable execution）: 計画を時間をかけて走らせ、状況変化に応じて再開・軌道修正する
- 動的ステアリング（dynamic steering）: ユーザーのフィードバックでエージェントの設定を走行中に更新する
Hunter はパイロット段階にあり、一般提供は2026年11月が予定されている（Unite.AI）。「一問一答のボット」から「週単位で目標を追う担当者」へ——これは運用・監査の前提を大きく変える変化だ。
2. エージェントが「モデルの中」まで入り込んだ
Claudeforce はこの入り込みを象徴している。8月26日に発表された拡張パートナーシップの中核は、「Salesforce in Claude」というプラグインで、37本の営業スキル（商談準備、案件の健全性レビュー、パイプライン・レビューなど）を備える。営業担当はClaudeから離れずに、生きた売上コンテキストを参照し、パイプラインを更新し、Salesforceの権限とガバナンスを保ったまま「統制された操作」を実行できる、とされる（Salesforce公式、CIO）。9月半ばにはDreamforceに合わせて有料Claudeプラン向けのベータ提供が始まった。価格は未開示で、Claudeの推論はAnthropicと別契約になる点にも注意が必要だ。
CNBCによれば、Salesforceのマーケットはこのタイミングでいわゆる「SaaSpocalypse（SaaS終焉論）」への回答という文脈も帯びていた（CNBC）。エージェントの入口が「アプリの画面」から「対話モデルそのもの」へと動いている、という潮目の変化がここにある。
3. 各プラットフォームが「自前の統制面」を持ち始めた
Microsoftは営業・サービス・財務向けの役割別Copilotを10月にプレビュー提供し、Copilot Agent Store 経由で配布する。営業向けはDynamics 365に加えSalesforceなど他社CRMにも接続するという（Constellation Research）。あわせてMicrosoftは「Agent 365」で、社内のあらゆるエージェント（自作・純正・ISV製）を一元台帳化し、役割ベースのアクセス制御、DLP境界、活動モニタリングを提供する構えだ。
つまり各社は「名前付きエージェント」だけでなく、それを統べる自社製のガバナンス面まで同時に押し出している。これが次章の論点に直結する。
| プラットフォーム | 出荷したもの | 統制の置き場所 | 提供状況（2026年9月時点） |
|---|---|---|---|
| Salesforce Agentforce | 7体の名前付きエージェント＋ロングホライズン・ランタイム | Salesforceの権限・ガバナンス | Casey/Paige等はGA、Hunterはパイロット（GAは11月予定） |
| Claudeforce（Salesforce×Anthropic） | Salesforce in Claude（37営業スキル） | Salesforce権限を継承しClaude内で実行 | 有料Claudeプラン向けにベータ |
| Microsoft Copilot | 営業・サービス・財務の役割別Copilot | Agent 365（台帳・RBAC・DLP） | 10月プレビュー予定 |
この波が日本企業に突きつける3つの論点
埋め込み型の名前付きエージェントは、単体で見れば導入が速く、業務に馴染みやすい。問題は複数プラットフォームを併用する現実の企業で起きる。
論点1: サイロ化。多くの日本企業はSalesforceもMicrosoft 365も、その他のSaaSも同時に使っている。各プラットフォームのエージェントは、そのプラットフォームの中に閉じたメモリ・スキル・統制を持つ。放置すれば「部門ごとに増えたAIエージェント」ならぬ「製品ごとに増えたエージェント」が生まれ、横断の可視化も統制もできなくなる。これは以前に論じたスーパーエージェントで単一の入口に束ねるという課題の、ベンダー版だ。
論点2: ロックイン。エージェントの価値の多くは、蓄積されたメモリ・スキル・実行履歴に宿る。それがプラットフォーム固有の形式で貯まるほど、乗り換えコストは跳ね上がる。あるアナリシスは「信頼とロックインが2026年のエージェント意思決定を規定する」と述べ、AIのロックインは「今四半期の最良モデルが来四半期には二番手になる」ほど変化が速いぶん、通常のソフトより深刻だと指摘する（Kai Waehner, Q3 2026）。
論点3: ガバナンスの分散。各社が自前の統制面（Salesforceの権限、Agent 365 など）を持つことは、裏を返せば統制が製品ごとに分断されることを意味する。監査ログの形式も、承認フローの粒度も、権限モデルもバラバラでは、経営が「誰が・どのエージェントに・何を許しているか」を一枚で説明できない。
「便利だから」と各SaaSの名前付きエージェントを個別にオンにしていくと、半年後には統制不能なエージェント群が社内に散在する。まず引くべきは、個別導入の是非ではなく、横断で見る・束ねる・統べる中立レイヤーの線である。
「どこに雇うか」ではなく「どう束ねるか」——中立レイヤーという解
救いは、業界がロックインの反作用として中立の相互運用標準を育ててきたことだ。2025年12月、Linux Foundation は Agentic AI Foundation（AAIF）を中立の上位財団として立ち上げ、MCP（Model Context Protocol）と A2A（Agent2Agent）を同じ傘の下に置いた。A2A はエージェント同士の連携を担う標準で、2026年1月に本番対応の v1.0.0 に到達し、4月時点で150以上の組織が支持している（A2A Protocol（PR Newswire）、a2a-protocol.org）。
両者の役割分担はシンプルだ。
- MCP: エージェントと「ツール・データ」をつなぐ（DB、API、社内システム）
- A2A: エージェントと「他のエージェント」をつなぐ（専門エージェント、オーケストレーター、サブエージェント）
興味深いのは、Salesforce・SAP・ServiceNow・Workday・Google・Microsoft・AWS といった、まさに今回名前付きエージェントを出しているプレイヤー自身が、これらの中立標準の支持者でもある点だ。つまり**「埋め込み型エージェントを採る」ことと「中立レイヤーを持つ」ことは、二者択一ではない**。
先を行く企業のアーキテクチャには共通点がある——メモリ層・スキル/ツール層・通信層を、モデルやプラットフォームのランタイムから切り離すこと。こうしておけば、あるプラットフォームのエージェントが優位でなくなったとき、文脈を失わずに載せ替えられる（Constellation Research）。名前付きエージェントを「雇う」のはよい。ただし雇用契約（統制と可搬性）は自社側に持つ、というのがこの設計思想だ。
homulaの観点：埋め込み型エージェントと「共存」する設計
homulaは、AIエージェント・インテグレーターとして、特定プラットフォームの製品を売るのではなく、複数のエージェントを中立に束ね、統べることを支援する。今回の波に対する実務的な勝ち筋は「排除」でも「全面採用」でもなく、次の順序での共存設計だ。
第1に、棚卸し（見える化）。どのSaaSの名前付きエージェントが、どの部門で、どんな権限で動いている（動こうとしている）かを洗い出す。見えないものは統べられない——これはシャドーAI/シャドーMCPで繰り返し論じてきた原則だ。
第2に、統一ガバナンス。プラットフォームごとに分断された承認・監査・権限を、横断の一枚に引き直す。homulaの Agens Control は、承認フロー・DLP・5年分の監査ログ・RBAC を提供し、「誰が・どのエージェントに・何を許すか」を製品の境界を越えて統制する土台になる。埋め込み型エージェントの「自前の統制面」は、この横断ガバナンスの下に入れ子で位置づければよい。
第3に、中立の接続・オーケストレーション層。homulaの Agens はMCPを活用した統合基盤で、200以上のツールと構築ゼロで接続する。特定ベンダーの画面やモデルに閉じず、n8n / Dify / LangGraph といった実装技術を組み合わせて、社内の複数エージェントを一つの入口・一つの統制の下に束ねる。MCP/A2A という中立標準に立脚することで、プラットフォームの盛衰に事業を人質に取られずに済む。
そのうえで、ユースケースごとに「プラットフォーム純正の名前付きエージェントを採るか、中立レイヤー上で内製するか」を判断すればよい。判断の前に**共通の土台（可視化・統一統制・中立接続）**を敷いておくことが、ロックインとサイロ化を同時に回避する鍵になる。最短の入り口としては、業務棚卸しからプロトタイプ、ROI試算までを3〜5日で完結する AIエージェント・ブートキャンプ で、自社の「どこを純正・どこを中立に」の線引きを短期間で描くことをおすすめしたい。
判断基準はシンプルに:（1）そのエージェントに蓄積される価値（メモリ・スキル）は可搬か、（2）統制は自社の横断基盤の下に入れ子にできるか、（3）中立標準（MCP/A2A）で他システムとつながるか。3つが揃うなら「雇って」よい。揃わないなら、まず中立レイヤーを敷いてからにする。
まとめ
2026年9月の潮目は、「AIエージェントを機能として足す」時代の終わりを告げている。SaaSは名前と職種を持つエージェントを出荷し、対話モデルの中にまで業務を持ち込み、それぞれ自前の統制面を押し出してきた。導入は速く、魅力的だ。しかし複数プラットフォームを併用する日本企業にとって、無計画な個別導入はサイロ化・ロックイン・ガバナンス分散という三重の負債を招く。
問うべきは「どのプラットフォームに雇うか」ではなく、「どう束ね、どう統べ、どう可搬性を残すか」だ。中立標準（MCP/A2A）と、モデル・ランタイムから切り離した中立レイヤーを先に敷いておけば、埋め込み型エージェントとも安心して共存できる。名前付きエージェントは雇ってよい——ただし、雇用の主導権は自社に残す。
埋め込み型エージェントの波に押し流されず、可視化・統一統制・中立接続の土台を先に敷きたい企業は、homulaにご相談ください。自社の「どこを純正・どこを中立に」の線引きから、一気通貫で設計します。