2026年8月26日の Claudeforce（SalesforceとAnthropicの戦略的提携）は、多くのメディアが「どのモデルをエージェントの中心に据えるか」という モデル選定・囲い込み の文脈で報じた。homula もその論点は別稿で整理した。だが本稿が注目するのは、その報道の陰で静かに起きた 構造の転換 のほうだ。Salesforce は今回、CRM という基幹システムを MCP（Model Context Protocol）で外部エージェントに開き、"統治された行動基盤（governed system of action）" に作り替えた（Salesforce 公式、Salesforce IR）。
homula はエンタープライズ向けの AIエージェント・インテグレーターとして、MCP を活用した統合基盤 Agens を軸に、企業の基幹・業務システムをエージェントへ安全につなぐ設計を手がけてきた。その視点から見ると、Claudeforce の本質は「Claude が賢いから選ばれた」ではなく、基幹システム側が"エージェントに使われる形"へ自らを再構成し始めた ことにある。この動きは Salesforce に限らない。本稿では、そこで現れた 「ハーネス」という新しい層 を一次情報ベースで解剖し、日本企業がいま何を設計すべきかを示す。
「ハーネス」という新しい層——AIforceが可視化したもの
今回の発表で最初に押さえるべき固有名詞は、Claude でも Agentforce でもなく AIforce だ。AIforce は Salesforce が「信頼できるエンタープライズ・ハーネス（trusted enterprise harness）」と呼ぶ層で、自社の業務データ・ワークフロー・ガバナンスルール・権限を、MCPサーバー・API・CLIツール を通じて 任意のエージェント に開く（Salesforce 公式）。Salesforce の CEO マーク・ベニオフ自身も、「AIforce ハーネス＋Headless 360 を通じて、Claude が Data 360・Tableau・Slack・Salesforce ワークフロー全体に 統治されたアクセス（governed access） を得る」と説明している（Benioff の投稿）。
ここで「ハーネス」という言葉が重要だ。従来、企業システムとAIをつなぐのは その都度作り込む個別インテグレーション だった。ハーネスは、その配線を 標準化された一本の接続層 に置き換える。エージェント側から見れば、AIforce に対して MCP でつなげば、背後の CRM・BI・チャットにまとめて手が届く。Salesforce はこれを「複雑で高コストな連携なしに、あらゆるエージェントへ業務データとワークフローを届ける」ものと位置づけている。
サーバーMCPとハーネスは地続きだ。 MCP は「バックエンドの業務システムをエージェントにつなぐ」プロトコルで、homula の統合基盤 Agens が担う領域そのもの。AIforce は、Salesforce が自社を「MCPで開かれるハーネス」として製品化した例だと捉えると理解しやすい。基幹ベンダーが自らハーネス化する動きは、MCP がエンタープライズの標準接続面になりつつあることの表れだ。
「記録するシステム」から「行動するシステム」へ
もう一つのキーワードが Headless 360 だ。Salesforce は Headless 360 と MCP ベースの接続を通じて、自社を 第三者のAIエージェントからアクセスできる"統治された行動基盤" として位置づけ直した。背後ではセキュリティ・権限・業務ルールを従来どおり執行し続ける、という設計である（Forrester、CX Today）。
これは、企業システムの価値の重心が動いたことを意味する。これまで基幹システムは「正確に記録する装置（system of record）」として評価されてきた。だが agentic の時代には、エージェントに委任した業務を安全に"実行させる"装置（system of action） であることが問われる。Claudeforce に付属する 「Salesforce in Claude」 プラグインは、会議準備・商談の健全性レビュー・パイプライン確認など 37種のプリビルトな営業スキル を備え、営業担当やエージェントがライブの売上文脈を読み、パイプラインを更新し、統治された行動（governed action） を Claude から直接取れるようにする。パイロット顧客に提供中で、オープンベータは2026年9月ごろ、追加スキルは2026年後半に順次投入とされる（Salesforce 公式）。
言い換えれば、Salesforce は 画面（UI）ではなく、その下にあるデータモデル・業務ロジック・権限層 に価値を寄せた。CRMの操作画面をエージェントが代替していくなら、勝負どころは「誰が・何を・どこまで実行できるか」を握る 統制層 になる、という賭けだ。
なぜエンタープライズが待っていたのは“ここ”なのか
エージェントに基幹システムを触らせる——この一言に、多くのCIOは長らく及び腰だった。理由は明確で、エージェントに新しい権限体系を別途作れば、統制が二重化して破綻する からだ。Claudeforce のアーキテクチャが評価されているのは、まさにこの点を回避する設計になっているとされるからである。
分析記事によれば、Salesforce in Claude では 既存の権限モデルがそのまま適用される。CRUD・項目レベルセキュリティ（field-level security）・共有ルールがすべて維持され、各 MCP トランザクションが 匿名のサービスアカウントではなく、認証済みの「その人」として実行される——つまり 設計・監査すべき"第二のセキュリティモデル"を作らずに済む、という点が「企業が待っていたもの」と評されている（Pebblous による分析）。
従来型の連携と、ハーネス経由の違いを整理すると次のようになる。
| 観点 | 従来の個別API連携 | ハーネス経由（MCP） |
|---|---|---|
| 接続 | システムごとに作り込み | 標準プロトコル（MCP）で一本化 |
| 権限 | 連携用アカウントに集約されがち | 認証済みユーザー本人の権限を継承 |
| 実行判定 | アプリ外で再実装しやすい | 基幹側の業務ルールで執行 |
| 統制の重複 | 二重の権限体系になりやすい | 既存の権限・監査を再利用 |
要点は、統制を"実行の地点"に置く という思想だ。エージェントの外側に別の許可リストを積むのではなく、行動が起きる基幹システムの内側で権限と業務ルールを効かせる。これは homula がこれまでツール単位の統制として論じてきた方向と一致する。
落とし穴：ハーネスは“誰の代理か”まで記録できるか
ただし、ここで手放しに賞賛するのは早い。「MCPでつないだ＝統制できた」ではない。 ハーネス化がもたらす新しい死角がある。
分析では、MCP ベースの接続で残る監査証跡が「どのMCPサーバーが呼ばれたか」は記録しても、「どのエージェントが・誰の代理で呼んだのか」までは十分に残らない場合があると指摘される。これは、最小権限・利用者ごとの帰属（per-user attribution）・個人単位での失効（revocability）というエンタープライズID統制の基本を満たせないリスクだ（エンタープライズ×MCPの統制論点）。基幹側が権限を執行しても、「その操作は本当に本人の意図だったのか」 を後から再構成できなければ、統制は片肺になる。
ハーネス化で最も危ういのは、認証済みセッションの権限でエージェントが動く 点だ。プロンプトインジェクションでエージェントが乗っ取られれば、それは正規ユーザーの権限のまま基幹を操作しうる。露出（つなぐ）と統制（勝手に走らせない）は、必ずセットで設計しなければならない。「つないだから安全」ではなく、誰が・いつ・どのツールを・どんな引数で・誰の代理で呼んだか を追える記録と、危険な操作の承認ゲートが要る。
つまり、ベンダーが提供するハーネスは強力だが、単一ベンダーの中で完結する統制 に留まる。実際の企業は Salesforce だけで動いてはいない。基幹は複数ベンダーにまたがり、n8n や社内システムも混じる。基幹への"エージェント・アクセス"をめぐって各社の方針が割れているいま、ベンダー横断で効く統制 をどこに置くかが、次の設計課題になる。
homulaの観点：ハーネスは“自社にも”要る
Claudeforce が示したのは、特定製品の勝敗ではなく 「エージェント時代に基幹システムが取るべき形」 だ。日本企業がここから引き出すべき順序は、はっきりしている。
第一に、自社の"ハーネス"を持つ。基幹・SaaS・社内システムを、その都度の作り込みではなく MCP という標準面でエージェントに開く。homula の統合基盤 Agens は、まさにこのハーネスにあたる——200以上のツールと構築ゼロで接続 し、業務システムをエージェントが使える形に束ねる。単一ベンダーのハーネスに全社を預けるのではなく、横断で効くハーネス を自社の統制思想の下に置くことが要点だ。
第二に、統制を"実行の地点"に、そして"誰の代理か"まで敷く。前節の落とし穴——利用者ごとの帰属・個人単位の失効・監査の再構成——を埋めるのが、承認フロー・DLP・5年分の監査ログ・RBAC を提供する Agens Control だ。認証済みセッションの権限で動くエージェントに対し、どの操作を承認ゲートの内側に残し、誰の意図で何が実行されたかを追えるようにする。
第三に、小さく始めて型を先に敷く。全業務をいきなり開くのではなく、読み取り系や低リスクな操作から接続し、行動系は承認・監査の内側に置く。この「業務の棚卸しとプロトタイプ、統制設計」を数日で回すのが、homula の AIエージェント・ブートキャンプ の領域だ。
まとめ
Claudeforce の見出しは「Claude が Salesforce の中心に座った」だった。だがその下で起きたのは、基幹システムが MCP で開かれた"統治された行動基盤"へと再構成された という、より普遍的な構造転換である。企業システムの価値は「記録する画面」から「安全に行動させるハーネスと統制層」へ移りつつある。
この局面で勝ち筋を握るのは、単一ベンダーのハーネスに乗るだけの企業でも、統制を恐れて接続を閉ざす企業でもない。自社のハーネスを標準（MCP）で持ち、統制を"実行の地点"と"誰の代理か"の両方に敷ける企業 だ。基幹をエージェントに開く扉が各社から次々に用意されるいま、開き方と閉じ方を一体で設計しておくことが、次の一年の差になる。
自社の基幹・業務システムを、どこまでエージェントに開き、どこに承認・監査を残すべきか。MCPを使った"自社のハーネス"と、その統制設計の第一歩を、homula がご一緒します。