エンタープライズAIの主戦場が、「どのモデルが賢いか」から「どのモデルを業務システムの心臓部に据えるか」へ移りつつある。2026年8月26日、SalesforceとAnthropicは戦略的提携 「Claudeforce」 を発表した（Salesforce 公式プレスリリース、Salesforce IR）。CRM最大手が、特定ベンダーのモデルを自社エージェント基盤の 既定の推論エンジン に据える——この一手を、金融メディアは早くも 「モデル非依存（model-agnostic）なエンタープライズAIの終わりの始まり」 と評した（Yahoo Finance）。
homula はエンタープライズ向けのAIエージェント・インテグレーターとして、n8n / Dify / LangGraph といった複数の実行基盤とモデルを組み合わせ、企業のAIエージェントを設計・実装してきた。その視点から見ると、Claudeforceは単なる大型提携のニュースではない。「深い統合の果実」と「モデルの可搬性（乗り換えられる自由）」をどう両立させるか という、これからの数年で企業の巧拙を分ける論点を、極めて具体的な形で突きつけている。本稿では発表内容を一次情報で整理したうえで、日本企業が置くべき判断軸を掘り下げる。
Claudeforceとは何か——3方向の統合
Claudeforceの核心は、SalesforceとAnthropicが 3つの方向で同時に 製品を統合する点にある（Salesforce 公式、Digital Commerce 360）。
- Salesforceが「Claudeの中」へ: Salesforceが Claude 上のプラグインとして提供され、営業サイクル全体を理解して動く。会議準備・商談の健全性レビュー・パイプライン確認など 37種のプリビルトな営業スキル を備え、いわば「AIのCRO（最高売上責任者）」として機能する。
- Claudeが「Agentforceの中」へ: Claudeが Agentforce の Atlas Reasoning Engine に組み込まれ、既定の推論モデルとして Agentforce Vibes や Coworker を駆動する。
- Claudeが「Slackの中」へ: チームが日常的に対話している Slack に Claude を直接埋め込み、会話と自律的な業務実行の橋渡しをする。
つまり、アプリケーション（CRM）とモデル（LLM）が相互に相手の内部へ入り込む、双方向の深い結合である。単に「ChatGPTやClaudeをAPIで呼ぶ」水準の連携とは、統合の深度が異なる。
「規制業種でも使える」ことを設計の中心に置いた
Claudeforceが企業にとって重いのは、データ主権と規制対応を統合の前提に据えている 点だ。両社は、Claude を金融・ヘルスケア・サイバーセキュリティ・ライフサイエンスといった 規制業種向けの推奨モデル として位置づけ、機密データと処理を Salesforce の信頼境界（Trust Boundary）の内側に保つと説明している（Salesforce（2025年10月14日の提携拡張））。
技術的な差別化点として各社が強調するのは、Anthropic が Salesforce の信頼境界内に完全統合される初のLLMプロバイダー であり、Claude のトラフィックが Amazon Bedrock 経由で Salesforce の仮想プライベートクラウド（VPC）内に閉じる ことだ。早期採用として CrowdStrike や RBC Wealth Management が Agentforce 上で Claude を用いた事例が挙げられている（Salesforce IR）。
Claudeforceは2026年8月26日の発表で、「Salesforce in Claude」プラグインは一部パイロット顧客に提供中、オープンベータは2026年9月ごろ、追加スキルは2026年後半に順次投入とされる。また各種報道は、Salesforceが2026年に約3億ドル規模のAnthropicトークン利用を計画し、既存の出資（約3億ドルの持分）を補完すると伝えている（Yahoo Finance、Digital Commerce 360）。金額はいずれも報道ベースの数字である。
なぜ「モデル非依存の終わり」と呼ばれるのか
これまでエンタープライズAIの定石は、モデルを差し替え可能な部品として扱う「モデル非依存」 だった。ベンダーロックインを避け、価格や性能で最適なモデルを随時選ぶ——多くのCIOがこの原則を掲げてきた。Claudeforceが波紋を呼んだのは、業界を代表するアプリケーションベンダーが、その原則とは逆に 特定モデルを「既定の推論エンジン」に据える 選択を明確に打ち出したからだ。
深い統合には確かな見返りがある。プラグインとして磨き込まれた37スキル、信頼境界内でのデータ保護、規制業種向けの整備——これらは汎用APIの寄せ集めでは得にくい。一方で、モデルが基盤に深く食い込むほど、後から別モデルへ乗り換えるコストは上がる。プロンプト、評価データ、業務フロー、スキル定義が特定モデルの挙動に最適化され、可搬性が静かに失われていく。
この緊張は、homula が「モデル供給リスクと多モデル継続性」で論じてきた論点そのものだ。1社のモデルに深く依存した設計は、価格改定・提供終了・品質変動・地政学的リスクといった「供給側の事情」に業務の連続性を人質に取られる。Claudeforceは、その依存が アプリケーション層にまで織り込まれ得る ことを示した象徴例と言える。
企業が置くべき判断軸——「統合の深さ」と「乗り換えの自由」を分離する
では、深い統合の利点を捨てて全てを自前の疎結合で組むべきかというと、それも極論だ。homula が日本企業の現場で確認してきた勝ち筋は、「統合の深さ」と「乗り換えの自由」を、設計上あえて分離しておく ことにある。
| 判断軸 | 深い統合に寄せてよい領域 | 可搬性を守るべき領域 |
|---|---|---|
| 対象 | 定型的で差別化に効く業務（例: 営業支援の型化スキル） | 全社共通の推論基盤・機密データ処理 |
| 縛り | ベンダー製スキル/プラグインへの依存は許容 | プロンプト・評価・業務フローはモデル横断で保つ |
| 抜け道 | 効果が薄れたら該当領域だけ差し替え | MCP等の標準で接続層を抽象化し、モデルを部品化 |
| 統制 | ベンダーの信頼境界を活用 | 自社側にも承認・監査の制御点を必ず持つ |
鍵は接続層の抽象化だ。MCP（Model Context Protocol）のような標準でツール接続とコンテキスト受け渡しを共通化しておけば、モデルは「賢い部品」として扱え、業務側の資産（ツール、権限、監査）を特定モデルに縛らずに済む。加えて、ツール単位の承認ゲートとエージェント専用の非人間ID・最小権限を 自社側に 持っておけば、どのモデルが基盤に座ろうと、「誰が・何を・どの承認で実行したか」の制御点は手元に残る。
実務の要点は「1社に賭けるか否か」の二択ではない。差別化に効く狭い領域では深く統合し、全社の推論基盤と機密処理では可搬性を守る——この二層構成が、囲い込みの果実とリスク分散を同時に取りにいく現実解だ。
homulaの観点——モデルは選び、制御点は手放さない
homula は、エージェントを業務へつなぐ入口として Agens（MCPを活用し、200以上のツールと構築ゼロで接続するエンタープライズ向け統合プラットフォーム）を提供している。特定のCRMやモデルに最適化された「出来合いの深い統合」が魅力的に見える局面ほど、企業側に必要なのは 接続の速さそのものではなく、「速くつなぎ、なお乗り換えられ、統べられる」構造 だ。
その統制の中核が Agens Control である。承認フロー、DLP、5年分の監査ログ、RBACを備え、モデルやベンダーが変わっても「どのエージェントが・どの操作を・どの承認を経て実行したか」を自社側に残す。Claudeforceのように基盤へモデルが深く食い込む時代だからこそ、制御点を自社に置く ことが可搬性の担保になる。
進め方としては、まず業務を棚卸しし、「どこは深い統合に寄せてよく、どこは可搬性を守るか」を切り分けるのが定石だ。homula の AIエージェント・ブートキャンプ は、業務棚卸し・プロトタイプ構築・ROI試算を3〜5日で完結させ、n8n / Dify / LangGraph といった複数基盤・複数モデルを前提とした設計から内製化までを一気通貫で支援する。
まとめ
- 2026年8月26日、SalesforceとAnthropicは Claudeforce を発表。Claudeを Agentforce の Atlas Reasoning Engine に据え（既定の推論エンジン）、Salesforceを Claude 上のプラグイン（37の営業スキル）として提供し、Slackにも Claude を組み込む3方向の深い統合である。
- Claudeは規制業種向けの推奨モデルとされ、トラフィックは Amazon Bedrock 経由で Salesforce のVPC・信頼境界内に閉じる。CrowdStrikeやRBC Wealth Managementが早期事例に挙がる。
- この動きは「モデル非依存の終わり」とも評される。深い統合には果実がある一方、モデルが基盤に食い込むほど乗り換えコストは上がる。
- 現実解は二択ではなく 二層構成——差別化に効く狭い領域は深く統合し、全社の推論基盤と機密処理は可搬性を守る。MCPで接続層を抽象化し、承認・監査・非人間IDの制御点を自社側に持つことが要になる。
「どのモデルが賢いか」だけでは、もう勝負は決まらない。問われているのは、深い統合の果実を取りにいきながら、乗り換えの自由と統制を自社に残す設計だ。homulaがその切り分けから伴走する。