※本記事は2026年7月22日に米国で公開されたHow Salesforce Pilots Its Own Softwareの翻訳です。本記事の正式言語は英語であり、その内容および解釈については英語が優先されます。
多くの企業は、顧客やベータテスターにソフトウェアの不具合を見つけてもらいます。Salesforceは、その不具合を自ら先に見つけることを選びました。言い換えるならば、Salesforceの主要製品は、顧客に届く前に厳しい試練を経ているのです。それは、75,000人のSalesforce従業員が日々の業務でその製品を実際に使うという試練です。従業員たちはサポートチケットを提出し、混沌とした実際の業務シーンでそれらを負荷をかけながら試し、複数の言語で問い合わせを行います。
つまり、従業員たちは実際のユーザーと同じ行動を取るのですが、その行動は製品チームの想定とはまったく異なることも多いのです。
これがSalesforceの「Customer Zero」というモデルです。
自律型のAIエージェントが、多くの組織による評価のスピードを上回るペースで普及するなか、Salesforceが自社製品を社内で徹底的に検証するその手法は、エンタープライズソフトウェアにおいて最も学びの多いプロセスのひとつとなっています。
信念に基づく取り組み、プロセスではなく
Salesforce on Salesforce TechnologyのSVPであるアンディ・ホワイト（Andy White）にCustomer Zeroについて説明を求めると、彼はそれをプロセスではなく理念として語っています。
Customer Zeroは、Salesforceが長年抱いてきた深い信念です。自社の製品で会社を運営することによって、私たちは製品をより良いものにしています
アンディ・ホワイト（Andy White）、Salesforce SVP
ホワイトのチームは「Digital Enterprise Technology」（DET）組織の一部であり、Salesforceの製品チームにとって単なる穏やかなテスト環境ではなく、要求の厳しい社内顧客として機能しています。同チームは新しいツールを実際の業務フローに組み込み、厳格な事業成果に基づいて評価し、その結果を開発サイクルに直接フィードバックしています。
DETと製品開発との関係は多面的です。75,000人の社内ユーザーのニーズや不満を代弁する立場と、コストを管理し、指標を追跡し、パフォーマンス目標を達成する事業運営者としての立場を兼ねています。そして最後に重要な点として、DETはSalesforce自身のためのオーダーメイドのソリューションではなく、Salesforceの顧客のためのソリューションを追求しているということです。
Salesforceの従業員はこの関係を理解しています。数カ月先に市場に出るはずの、新しいツールへの早期アクセスは、従業員に本物の熱意を生み出し、そのある種の特権こそがこのモデルを機能させる要素の一つとなっています。一般的にベータプログラムは、一部の顧客に機能を試してもらいフィードバックを求めるものですが、Customer Zeroでは企業全体が未完成のソフトウェアで事業を運営することを求められ、その当初の不便さこそが取り組みの目的であり、参加の対価であると位置づけています。
何をパイロット対象にするのか
すべてのツールが、すぐにCustomer Zeroの対象になるわけではありません。
選定されるツールは、会社がスピードを上げたいと考えている製品への意図的な投資であり、その製品がどのように機能し得るか、あるいはどのように機能すべきかを見極めるためのものです。可能な限り、そのツールはグリーンフィールド（言い換えるならばゼロベース、完全新規）のアプローチと組み合わせられます。つまり、Salesforce内に明確な業務ニーズがありながら既存の解決策がない業務領域を見つけ、そこから着手するというものです。真のグリーンフィールド領域では、破壊すべき既存のプロセスも、損なうべき根強いユーザーの期待も、守るべき従来のパフォーマンス基準も存在しません。初期のパイロットがうまくいかなかった場合でも、開発者は従業員がすでに頼りにしているシステムへの信頼を損なうことなく、方向を修正できます。
Customer Zeroの背景にある考え方自体は、新しいものではありません。Salesforceは長年、自社の事業を自社製品で運営してきました。この取り組みは社内では「Salesforce on Salesforce」と呼ばれています。 Agentforceの登場によって変化したのは、そのスピードです。初めて、エージェントの構築にコードが不要となり、準備にかかる時間もごくわずかになったことで、社内のさまざまなチームがそれに応じて動き始めました。エージェントの数はほぼ一夜にして数百に達し、導入状況にはばらつきが生じ、品質にも影響が出ました。
Customer Zero & Agentforce Transformation Leadであり、Salesforceの部門横断的なエージェントポートフォリオを管理する立場にあるリズ・アロイジ（Liz Aloisi）は、この現象を「エージェントの乱立（agent sprawl）」と名付けました。この混乱から、Customer Zeroとしての学びが生まれました。それは、エージェントの数を絞り、より質の高いものを構築し、慎重に規模を拡大するというものです。
プロダクトマーケットフィットも重要な要素です。Customer Zeroは、社内の業務遂行上の課題が社外の、つまりマーケットのニーズを反映している場合に、最も効果を発揮します。ホワイトの言葉を借りれば、Salesforceのような特性を持たない顧客向けに作られた製品は、本来、社内でのパイロット導入には適さない可能性が高いといえます。製品を作る側、テストする側、最終的に購入する側の間の三者間の一致があることで、真にフィードバックが意味を持つようになります。
パイロット版の設計
パイロット版の設計対象が特定されると、すべてのCustomer Zeroパイロットは体系立った手順を踏みます。ユースケースを考案し、エージェントを構成し、テストを行い、リリースリング（段階的に配信グループ）へ展開し、拡大前に注意深く監督するという流れです。リリースリングは通常、数百人の従業員という小規模な単位から始まり、その後はスケジュールではなくシグナルに基づいて規模を拡大していきます。ホワイトのチームは、エージェントの精度が70%に達するまで、対象を全従業員に拡大しません。この基準は、代替対象となる人間のパフォーマンスと比較した際のエージェントの性能に対する信頼度を反映したものです。
「監督」の段階こそが、本当の学びが生まれる場です。Agentforce Observabilityを用いて、チームはすべてのやり取りを検証します。従業員が何を質問したか、エージェントが何を返答したか、そしてどこで対話が破綻したかを含めてです。これらのパターンが、次の改善サイクルを推進します。
TechForceのSenior Directorジェイソン・ペレス（Jason Perez）と、そのチームはTechForce Agentへのアップデートを絶えず提供しています。やり取りを分析し、モデルを調整し、信頼が高まるにつれてアクセスを段階的に拡大しています。
Customer Zeroの実践例：TechForce Agent
TechForce Agentは、Customer Zeroのプロセスが設計どおりに機能している、Salesforceにおける最も明確な例のひとつです。TechForceは、75,000人全員のSalesforce従業員に対するITサポートを担っており、失敗がすぐに目に見え、フィードバックも即座に得られる、大量かつ影響の大きい環境で運用されています。
ペレスのチームがサポート対応にAIエージェントを試験導入し始めた際、最も単純なユースケース、つまり知識に関する質問への回答から着手しました。対応率（ハンドルレート）、すなわちエージェントが人間の介在なしに完全に解決したサポート依頼の割合は、ほぼ即座に30%台前半まで上昇したのです。これは初動としては非常に良好な結果であり、チームに拡大に向けた早期のシグナルを与えました。
その後、より複雑な業務フローが対象となり、それに伴って、実際の運用でしか生じない種類の摩擦も見られるようになりました。TechForceは、紛失・盗難デバイスへの対応を頻繁に行っていますが、これは1件あたり1時間以上を要する、人間による確認と処理が必要な業務です。同グループは当初、こうした報告への対応にエージェントを導入しましたが、従業員は紛失した機器を自然言語で表現し、ある人は「phone」、別の人は「iPhone」、また別の人は「Pixel」と入力していました。エージェントはこれらの表現を会社の正確な資産データベースに正しく対応づけることができなかったため、誤ったデバイスをロックしたり、誤った住所に代替機を発送したりするリスクがありました。
この問題の解決には、シリアル番号とデバイス記録に対する確定的なマッチングレイヤーの構築が必要であり、これは実際のIT業務から生まれた解決策でした。この解決策は、「Agentforce Graph」の開発にも直接つながりました。これは、エージェントが自然言語による入力と構造化された企業データとの間で、正確かつ検証済みの結びつけを行うことを可能にする機能であり、現在では外部の顧客にも標準機能として提供されています。これは、Customer Zeroが、管理されたテストでは決して得られないような製品に関する知見を生み出す様子を示す、鮮やかな一例といえるでしょう。ペレス氏のチームは、自らのプロセスを改善するだけではありません。彼らは製品チームに、想定していなかった課題を提示し、製品チームがそれをすべての顧客のために解決したのです。
18カ月にわたる改善の結果、TechForce Agentの顧客満足度スコアは76%から90%まで上昇しています。年末までには95%を目標としています。かつて1時間以上を要していた紛失・盗難対応のワークフローは、現在では約15分で解決できるようになっています。
実践的なフィードバックループの拡大
TechForce Agentのテストは、社内パイロットの最も純粋な形といえます。これに対して、他のCustomer Zeroの展開は異なる形で運用されています。Salesforce自身の顧客向けサービス上で稼働し、従業員と外部の顧客が同じ本番製品を並行して利用し、改善がリアルタイムで行われます。Help Agent、help.salesforce.com上でのSalesforceによるAgentforceの実装は、2024年10月にローンチされた、その最も代表的な例です。400万件を超える対話を経て、現在では問い合わせの約70%を人手を介さずに解決しており、年末までに80%を目標としています。
Help AgentがCustomer Zeroの物語において重要である理由は、その背後にある改善への規律にあります。例えば、Salesforceのユーザーは、Help Agentがどこから回答を得ているのかについてより詳しい情報を求めていたため、アルファシャ・ズルキフリ（Alfasha Zulkifli）のチームはエージェントにインライン引用機能を追加しました。チームがこの引用機能を社内でテストしたところ、利用率は27%上昇し、信頼度に関する指標も明確に改善しました。この機能を外部の顧客に展開した結果も同様の裏付けとなり、「社内で機能するものは、社外でも機能する」というCustomer Zeroの核心的な考えを直接的に実証しました。
GTM AI Strategy Directorのクリスティーナ・モンディーニ（Cristina Mondini）は次のように述べています。「私たちは少し悔しい気持ちになることがあります。お客様はこの素晴らしいソリューションを最初からそのまま手にできますが、私たち社内のチームは、そこに至るまでに多くの試行錯誤を重ねなければならなかったからです」
成功の定義と、そのゴールを動かし続けること
エージェンティックな開発における難しい課題の一つは、十分なデータが集まる前に「良い状態」とはどのようなものかを予測することです。パイロットを拡大する前に、チームはAIエージェントのパフォーマンスをベースラインと直接比較して測定します。アロイジ（Aloisi）は次のように述べています。「自分がどこから始めたのかが分からなければ、どれだけ測定可能な改善を実現したのかを評価することは難しくなります」
ベースラインを超えて、成功のためには目標が変化し続けることを受け入れる必要もあります。AIエージェントの性能が既存のテストケースに対して向上するにつれて、チームはより難易度の高いテストケースを導入します。例えば、実際のサポートデータから得られた、現実的な顧客からの質問など、エージェントがすでに習得した領域に意図的に挑戦するようなものです。半年前には優秀とされたスコアが、新たな最低基準になります。その仕組みは単純です。基準を上げれば、製品はより良くなるのです。
どの組織も学べることは？
製品を顧客が目にする前に、自社の従業員をテストの最前線として活用したいと考えているすべての企業に対して、SalesforceのCustomer Zeroを率いるリーダーたちは、共通する核心的なアドバイスを提供しています。
- “グリーンな”領域から始める：ツールや業務フローがまだ存在しない業務領域を見つけましょう。何もない状態から始めることで、真のベースラインを確立し、失敗のリスクを抑え、人々が既に利用しているシステムを損なうことなく方向転換ができます。
- 導入前と導入後を測定する：導入前に人間によるベースラインを確立し、AIエージェントの性能が向上するにつれて基準を上げ続けましょう。
- 業務の流れに組み込む：従業員が既に時間を使っている場所にAIエージェントを組み込みましょう。導入によって日々の習慣を変える必要が生じる場合、その導入は失敗します。
- 早期の成果で勢いをつける：シンプルで確度の高いタスクから始め、その成果を活かして、複雑な業務フローに必要な組織的な信頼を獲得しましょう。
このモデルを支える文化は、その仕組み自体と同じくらい重要です。ホワイトは3つの要素を挙げています。製品が開発サイクルのどの段階にあるかを明確にし、従業員がそれに応じて期待値を調整できるようにすること。ベータ版のソフトウェアを強制的に使わせるのではなく、利用しないという選択肢を認めること。そして、繰り返される改善を失敗ではなく目標そのものとして捉え直すことです。Customer Zeroの目的の一つは、有償の顧客が製品に触れる前に、その製品の不具合を洗い出すことです。これらすべてに、大規模な人員は必要ありません。
ホワイトは次のように述べています。「これは規模の問題というよりも、シグナルの問題だと思います。良いデータポイントを得られていて、自分たちが行っていることを測定できている限り、それこそが本当に重要なことなのです」
Customer Zeroが持つ本当の競争優位性は、その結果として生まれる製品そのものにあります。Salesforceが何かをリリースするとき、その製品は既に、最初にアクセス権を持ち、それをうまく機能させることに本気で関わってきた従業員による日々の利用を経て生き残ったものなのです。そうした従業員たちは、製品の支持者になっていきます。粗さの残る部分は見つけ出されて研磨され、そこから得られた学びは公開され、顧客もそこから学べるようになっているのです。そう、どの組織も、Customer Zeroになることができるのです。
本記事、または公式に言及されている未提供のサービスや機能は現在利用できないものであり、予定通りに、または全く提供されない可能性があります。お客様は、現在利用可能な機能に基づいて購入をご判断くださいますようお願いいたします。
