2026年9月10日、Dreamforceに先立ち、SalesforceはTrusted Enterprise AI Harnessを発表しました。これは、AIエージェントに顧客とビジネスについての共通理解を与え、あなたのルールの範囲内で行動できるようにするコンポーザブルなアーキテクチャです。6つの信頼できる機能（コンテキスト、エージェンシー、アクション、ガバナンス、セキュリティ、モデル）に加え、すべてのエージェントを一か所で把握・統制するための新しいAI Control Planeをまとめています。
戦略的な発想は鋭いものです。モデルがコモディティ化するほど、差を生むのはモデルに与える独自のコンテキストと、それを安全に行動へ結び付ける力になります。ただし、時期と範囲には注意が必要です。多くの部品は今日でも存在しますが、新機能と統合された体験の提供が始まるのはFY28初頭（2027年初め）で、価格は公表されておらず、セキュリティとコスト管理の層の一部はこれから構築する必要があることをSalesforce自身が認めています。
そこで、エージェント連携を仕事として提供してきた立場からの率直な見方です。harnessは、現実の問題（共有のコンテキストも統制もないままエージェントが至る所に増えていくこと）に対する正しい診断です。しかし、安全なサポートエージェントを1つ動かすために、6層のエンタープライズアーキテクチャを構築する必要があるチームはほとんどありません。それが本来の目的なら、eeselのようにすぐ働けるチームメイトは、ガードレール、シミュレーション、承認、アクティビティログをすでに備えており、FY28ではなく数分でSalesforce Service Cloudに接続できます。
Salesforceが実際に発表したこと
まず実体から見ていきましょう。名前が多くを語りすぎているからです。Salesforceはこれを「Trusted Enterprise AI Harness」と呼んでいますが、購入する単一の製品ではありません。これは、エージェントが確実かつ安全に働くために必要なものをすべて提供する共通のコンポーザブルなアーキテクチャで、企業がエージェントごとにそれらの機能を個別に構築・管理しなくて済むようにするものです。
この提案は1つの賭けに基づいており、Salesforceの社長兼Chief Platform and Engineering OfficerであるRohan Kumarがはっきりと述べています。
"The Agentic Enterprise won't be defined by which model a company chooses. Models will continue to change, and intelligence will increasingly be available everywhere. What will differentiate an enterprise is the trusted, proprietary context it brings to that intelligence, starting with the customer, and its ability to securely turn that context into action."
Salesforceは問題全体を、一見単純な1つの問いで表しています。「この注文を今日、履行できますか？」単一のシステムでは完全な答えを持っていません。CRMは顧客を知り、ERPは在庫を知り、契約は約束事を持ち、分析はビジネス用語を定義し、ポリシーは実際に何を約束できるかを決めます。harnessは、自由度の高いAIの推論を、予測可能な答えに必要なビジネスルールや統制につなぐことを目指しています。
SalesforceのEinstein Trust Layerの資料を読んだことがあれば、この図は見覚えがあるはずです。プロンプトがモデルに届く前後で、セキュリティの各段階（安全なデータ取得、グラウンディング、マスキング、有害性検出、監査証跡）をどう通過するかを示しています。harnessは本質的に、この考え方を1つのプロンプトから、会社のすべてのエージェントとアクションへ拡大したものです。
6つの信頼できる機能
ここが核心です。Salesforceは、信頼は最初から6つの機能のそれぞれに組み込まれており、1つのシステムとして一緒に使うことも、必要な部分だけ選ぶこともできると述べています。1つのエージェントを包む6つの層と、その上に載るControl Planeを思い浮かべてください。
マーケティング文言を言い換えるのではなく、「この注文を履行できるか？」という例に当てはめて、それぞれが実際に何をするかを示します。
| 機能 | 内容 | 注文の例では |
|---|---|---|
| Trusted Context | データ、メタデータ、セマンティクス、ナレッジ、リアルタイムのシグナル、メモリを、顧客とビジネスの共通理解にまとめる | 顧客、その契約と権利、そしてその顧客にとって「利用可能な」在庫が何を意味するかを把握している |
| Trusted Agency | 推論、計画、状態、メモリ、オーケストレーション。柔軟なAIと決定論的な統制を組み合わせる | 注文を履行できるか、次に何が起きるかを、確実性が必要なルールに従って判断する |
| Trusted Action | エージェントをアプリ、API、ワークフロー、業務プロセスに安全に接続し、実行できるようにする | 在庫を確保し、注文を更新し、履行を起動し、あるいは人に引き継ぐ |
| Trusted Governance | AIが依拠するデータ、メタデータ、ポリシー、プロセスを、リネージ、品質、ガードレールとともに統制する | 答えが信頼できる情報と適切な取り扱いポリシーに基づくことを保証する |
| Trusted Security | エージェントが見られるもの、できることに、ID、権限、プライバシー、ランタイムセキュリティを適用する | エージェントが許可されたデータだけを見て、許可された操作だけを行うことを保証する |
| Trusted Models | 精度、性能、コスト、ビジネス上の必要性に応じた、賢いモデルルーティング | タスクを最適な知能に振り分け、技術の進化に合わせてモデルを入れ替えられる |
このリストを読むと気づくことがあります。これらは、ライブのキューにエージェントを置いたことのある人なら誰でも気にする点と同じです。実際のデータに基づかせること。行動させつつ、限度の範囲内にとどめること。見てはいけないものを見られないようにすること。これは本当に筋の通ったフレームワークで、Salesforce版に触れなくても、各要素をここまできれいに名付けること自体が役に立ちます。
AI Control Plane
より新しい考え方であり、最も重要だと私が考えるのがAI Control Planeです。組織全体でエージェントが増えるにつれ、どのAIが動いていて、どう成果を出し、何を許可され、いくらかかっているかを知る一貫した方法が必要になります。Control Planeは、その単一の管理画面になることを目指しています。
具体的には、Control Planeでは、エージェントの検出と登録、IDとポリシーの設定、ライフサイクル管理、パフォーマンス評価、挙動と成果の観察、コスト管理ができます。興味深いのは、SalesforceとサードパーティのAIの両方にまたがることを想定している点で、複数のエージェントプラットフォームを使う企業が、理論上はそのすべてを一か所から統制できます。
この野心は現実の課題に根ざしています。VentureBeatのローンチ分析によると、企業はすでに平均3.1のエージェントプラットフォームを運用しており、85%が2つ以上を運用しています。この乱立を目の当たりにしてきた人にとって、そのすべてを覆う中立的な統制レイヤーはまさに望むものに聞こえるでしょう。
このフレーミングが響く理由：本当のボトルネックは信頼
今回の発表が単なる再パッケージ以上なのは、エージェントの本番導入を実際に妨げているものを狙っているからです。もはやモデルの品質ではありません。信頼です。Valoirの CEO兼プリンシパルアナリストであるRebecca Wettemannは、こううまく表現しました。
"We've really moved from AI FOMO to AI FOMU, fear of messing up. People worry that autonomous agents will run amok unharnessed and either do something deleterious to the business or run up a million-dollar token bill. It's the vendors that succeed with governance and trust that will succeed in getting customers from interesting AI pilots to AI in production."
この恐れがすべてです。自信ありげなボットが静かに間違った答えを出し続けるのを私は見てきました。だからこそ、すべての導入は顧客に触れる前に実際の履歴でテストすべきです。実名の企業顧客であるRocket MortgageのCTO、Shawn Malhotraも、Salesforceが売りにするオープン性に同調しました。彼はForkastに、自分のチームは1つの閉じたスタックに将来を賭けたくなく、状況の変化に応じてモデルを入れ替える自由がほしいと語りました。
率直な評価：何が現実で、何がまだロードマップか
公平な記事なら、ここで一度立ち止まる必要があります。ビジョンは強力ですが、これはローンチであって出荷済みの製品ではなく、報道では、計画を立てる前に知っておくべき現実的なギャップがいくつか指摘されました。
1つ目は時期です。統合された体験の提供は、FY28初頭まで始まりません。AIの時間感覚では氷河のような遅さで、VentureBeatのCarl Franzenは当然の指摘をしています。顧客はすでに他で構築を進めており、ブランド付きのharnessを待ってはくれそうにないため、顧客を呼び戻すには価格、使いやすさ、機能のいずれかで特に魅力的である必要があります。
2つ目に、すべての部品が出来上がっているわけではありません。Salesforceの名誉のために言えば、Rohan Kumarはこれを率直に語っています。
"I wouldn't say we have all the capabilities, just to be fair, because some of these things, especially when it comes to trusted security and the FinOps piece, there are things that we need to go build."
3つ目に、メッセージが完全には固まっていません。diginomicaのStuart Lauchlanは、コスト管理が2か所に同時に現れる点（ブリーフィングではTrusted Governanceに含まれ、書面の発表ではControl Planeの内側にある）に気づきました。フレームワークがまだ新しいことを示す小さな兆しです。
次に定義をめぐる論争があります。業界の他の部分では、「agent harness」は単一モデルを取り巻くツール、メモリ、コンテキストの足場を指します。Salesforceはこれを会社全体のコンテキストとガバナンスにまで広げ、Kumarも従来の定義は彼の見方では「very limited」だと認めました。それが先見的なのか、Data 360、MuleSoft、Tableau、Agentforceにかぶせたバズワードの拡張なのかは、議論の余地があります。
最後に、「オープンでコンポーザブル」という訴求がどうしても呼び込むロックインの問題です。ForkastのDana Ellisonはこれを的確に言い表しました。
"The challenge for decision-makers is balancing this promise of composability against the risk of vendor lock-in. If you centralize your agent governance on a single platform, you are effectively betting on that platform's ability to remain neutral and interoperable as the market evolves."
これらのどれも、harnessが悪いアイデアだということにはなりません。早すぎるアイデアだということです。カテゴリーを定義しようとする野心は本物で、Lauchlanも、大手ベンダーがこぞってコンテキストと信頼でより優れていると主張し合う、2年間の「sea change」の始まりと見ています。ただ、魅力的なアーキテクチャ図を、今四半期に導入できるものと取り違えないでください。
本当にharnessは必要か？
私が実際にじっくり考えたい問いです。答えは、あなたがどんな立場かではっきり分かれます。
多数のシステムにまたがって多くのエージェントを運用する大企業で、本当の課題が大規模なガバナンス（誰が何をしてよいか、すべてをどう見渡すか、予想外のトークン請求をどう避けるか）なら、このようなcontrol planeはまさにあなたを狙ったもので、FY28まで追う価値があります。
しかし、「Salesforce AI harness」を検索する人の多くは、まだその課題を抱えていません。もっと狭い課題があります。サポートキューに、安心してオンにできるAIエージェントを1つ置きたい。その目的に、エンタープライズharness一式は、問いが求める以上に重い答えです。これはよくある「これはインフラだが、私がほしかったのは従業員だ」というギャップです。harnessは足場であり、組み立て、データを接続し、部品が揃うのを待つのはあなた自身です。
興味深いのは、Salesforceが6層のアーキテクチャにまとめているガードレールが、サポートエージェントにとっては他ではすでに最低条件だという点です。ここで私なら、構築の土台となるプラットフォームではなく、すぐ働けるチームメイトを選びます。eeselでは、同じ懸念が、組み立てる層ではなく標準の設定として現れます。
- **稼働前の信頼：**ガバナンスのフレームワークの代わりに、実際の過去チケット数百件でシミュレーションを実行します。それらを再生し、エージェントの回答をチームが実際に送った内容と照らして採点するので、顧客より先にギャップが見えます。これは「暴走するのでは」という不安に直接答えます。
- **範囲を限定した操作と承認：**どのチケットを扱い、どの操作を実行できるかを正確に決められ、機密性のあるものには人による承認ステップがあります。
- **標準のオブザーバビリティ：**すべての実行がステータスと結果とともに記録されるので、「挙動を観察する」は、プロビジョニングする機能ではなく、開くだけの画面です。
もう1つ触れておきたい点があります。harnessはヘッドレスで構築されていることを強調しており、MCP、API、プラグイン経由で、ClaudeやSlackからも利用できます。このエージェントに親和的でプログラム可能な面は本当に良い発想で、eeselも同じ発想を取りました。eeselは、すべてのワークスペースに本物のCLI（@eesel/cli）とMCPサーバーを提供しており、ダッシュボードで設定したのと同じチームメイトをターミナルやスクリプトから操作できます。連携の接続、常設の指示の編集、ヒューマン・イン・ザ・ループの操作の一覧表示と承認（eesel approvals）、実行履歴の閲覧（eesel activity）まで、すべてコマンドラインで行えます。Claude CodeやCursorのようなコーディングエージェントでも同じことができます。これはControl Planeが目指す「エージェントをコードとして統制する」という考えと同じで、艦隊全体向けのFY28ではなく、チームメイト1つ分としてすでに利用できます。コマンドの全容は、eesel CLIのドキュメントで詳しく説明しています。
Salesforceのキューでeeselをお試しください
数年がかりのプラットフォームへの賭けではなく、Salesforce Service Cloud上で安全に動くAIエージェントが目的なら、eeselの出番です。既存のキューにチームメイトとして加わり、ヘルプセンターと過去のチケットを読み、選んだケースで返信の下書きや自動送信を行い、すべての操作を範囲限定、承認、記録の下に置きます。Service Cloud Casesに直接接続するので、今日の午後に自分の履歴でシミュレーションして、何かが本番に出る前に数字を確認できます。FY28の提供を待つ必要はありません。
料金は固定の月額プラン1つで、席ごとの料金ではなくチケットまたはチャット1件につき1クレジットです。クレジットカード不要の100クレジットの無料プランもあり、「一般提供が近づいてから価格を発表する」のを待つこととは大きく異なる負担感です。Salesforce AIスタック全体を比較検討中なら、私のAgentforceの料金解説とAgentforceの代替サービスまとめが自然な次の読み物です。「AIはサポートキューで実際にどう機能するのか」をさらに深く知りたい場合は、カスタマーサービス向けAIや、AIエージェントとルールベースのチャットボットの違いから始めてください。
Trusted Enterprise AI Harnessは、企業規模でエージェントを統制するための、真剣でよく練られたビジョンであり、実際に出荷されるのを見るのが本当に楽しみです。ただ、信頼できるサポートエージェントを1つ稼働させるという具体的な目的のために、まずharnessを構築する必要はありません。そのままチームメイトを迎えることができます。