こんにちは、近森淳平ことpei0804です。元々はデータ基盤の開発をやっていたところから、業務整理にも踏み込むうちに、いまではRevOpsの設計と構築まで担当するようになりました。これまでの取り組みはRevOpsへ至る道データ活用による事業革新への挑戦とRevOps実践で学んだ俺が最強のデータ基盤になることの重要性で発表しています。

RevOps AF US 2026に参加してきました。ちょうど自社のRevOps設計が一段落したタイミングで、この領域の最先端との距離感を正確に測りたいと思ったのが参加の動機です。「方向性は同じ、でもスピードが違う」というのが、2日間を通じた正直な感想です。見えてきた共通テーマに絞り、自分の目の前の世界との共通点とギャップを書きます。

RevOps AF US 2026 とは

RevOps AF は、Revenue Operations（RevOps）の専門家コミュニティ「RevOps Co-op」が主催する年次カンファレンスです。 2026年のUSカンファレンスは5月6〜7日にサンフランシスコで開催されました。

主なテーマと持ち帰り

2日間を通じて、以下の3つのテーマがセッションをまたいで何度も出てきました。

ボトムアップとトップダウンは両輪: 現場主導の試行は速いがスケールしない、経営主導はリソースを確保できる反面、現場から乖離しやすい。両方が噛み合って初めて変革が定着する
アウトプットではなくアウトカムで測る: 経営層が見ているのは仕組みの精緻さではなく成果そのもの。使われているかは見えても、それが成果につながっているかは別問題
RevOps の成熟度モデルが Always-on（常時稼働）へ: Reactive（受動）→ Proactive（能動）の2段階で語られてきた領域に、AIエージェントによる第3段階が加わった

持ち帰ったのは「方向性は同じ、でもスピードが違う」という感覚でした。テーマ自体は自分の現場でも普段から出てくる話ばかり。差は「実践して失敗して改善した回数」です。

RevOpsはSaaSだけの話ではない

Why the Bowtie Is the Right Strategic Framework for Modern RevOps（Steve Busby）

RevOpsはSaaSだけの話ではありません。このセッションはその主張を、「Bowtieモデル」というフレームワークで整理していました。

これからRevOpsに取り組む人で、SaaS系ではない事業に関わる人なら、必ず投げかけられる質問があります。「RevOpsってSaaSじゃないと成立しないのでは」。私自身、自社でRevOpsを設計する中で何度もこの問いを受けてきました。「何かを売る行為の本質は変わらない」と答えてはきたものの、それを裏付ける構造を持っていませんでした。Bowtieは、その欠けていたピースでした。

収益サイクルを可視化するモデルには、よく知られているものが2つあります。購入をゴールとする段階型のFunnel（漏斗型）と、顧客を中心に据えた循環型のFlywheelです。

参考：Funnel vs. Flywheel: Which Model is Right for Your Business? - Growth Rocket

しかし、どちらも受注後まで含めた全体像を持ちません。Bowtieはその欠落に応えるモデルで、受注後を含む収益サイクル全体を、蝶ネクタイ（Bowtie）の形で上下2つの層に構造化しています。

出典：Revenue Operations Associates Copyright Revenue Operations Associates 2025

上半分は収益サイクルの3つのフェーズです。マーケが担う需要創出（Demand Creation）、営業が動くパイプライン加速（Pipeline Acceleration）、カスタマーサクセスが受け持つ関係拡張（Relationship Expansion）。従来のFunnel思考は最初の2つで完結していました。リードを獲得して受注したら終わり。しかし実際には、受注後のRelationship Expansionこそが持続的な収益を生む源泉です。蝶ネクタイの左の獲得フェーズと右の拡張フェーズが、対称に存在する構造になっています。

下半分が、BowtieをFunnelやFlywheelと決定的に異なるものにしている部分です。3つのフェーズ全体を横断するClosed Loop（閉じたループ）の改善サイクルで、Relationship Expansionで得た顧客の声や行動データがDemand Creationに戻り、摩擦を診断し、プロセスを継続的に改善する。Steve Busbyはこのレイヤーを「ここがRevOpsのパートだ」と呼びました。RevOpsとは、このClosed Loopを回す実践です。

このClosed Loopが扱うのは「顧客との関係を獲得し、維持し、拡張する」という普遍的な営みであり、SaaS固有のサブスクリプション構造に依存していません。だからこそSteve Busbyは、BowtieはSaaS専用ではなく、業種を問わず使える普遍的なフレームワークだと言い切りました。

Bowtieが業種を問わない構造なら、それを回すRevOpsもまた業種を問いません。

ただし、フレームワークがあるだけでは回りません。「受注後は別部署の仕事」という従来の働き方が残る限り、Closed Loopは必ずどこかで切れます。これは構造的に起きることであり、だからこそ、どうつなぎ直すかは簡単ではありません。それを実際に進めようとするとき、何が阻むのか。続くセッション群は、その問いに正面から向き合うものでした。

依頼を待つ側から、変革を起こす側へ

Release the Brake: This Moment Belongs to Operators(Sowmya Srinivasan)

Sowmyaはセッションの冒頭で、RevOps担当者の立場をこんなふうに表現しました。「私たちは長らく『見えないチーム』だった。うまくいっているときは誰も気にせず、壊れたときだけ修理屋として呼ばれてきた」

この話は、RevOps担当者に限った話ではありません。システムを作る側と依頼する側という構造は、どの組織にも存在します。依頼が来たら作る、壊れたら直す。「自分から動く」という発想自体が、この種の仕事には馴染まないと思われてきました。

しかし、営業・マーケティング・カスタマーサクセスを横断するシステムをRevOpsとして統合的に構築しようとすると、この前提は成り立ちません。部門間のデータフローを設計することも、無駄なプロセスを洗い出して棚卸しすることも、全体像を描くことも、誰かの依頼を待っていては始まらないからです。設計者としてのオーナーシップを持たない限り、統合的なシステムは永遠に完成しません。能動的な取り組みが、構造的に必要になるのです。

Sowmyaはその核心を「Myth 04」として提示しました。

「RevOpsはビジネスを支援する」という認識こそが、最も問題だと言います。支援しているだけでは、誰がシステムを設計するのでしょうか。SowmyaはRevOpsがこれまで担ってきた役割を「メカニック(整備士)」と表現しました。

「メカニックとして考えるのをやめ、アーキテクトとして考え始める。本来問うべきは『これをどう直すか』ではなく『このプロセスはそもそも存在すべきか』だ」

何か壊れたら直し、頼まれたら作り、声の大きい人の依頼から順に実装する。それがこれまでの働き方でした。本来あるべきは、「そもそも、これは必要なのか」という問いを立てるアーキテクトとしての働き方です。

では、なぜこの転換が組織の中で進まないのでしょうか。Sowmyaはその正体を、4種類の「オペレーショナルドラッグ(組織内摩擦)」として整理しました。

種類	例
Consensus Drag(合意の摩擦)	ブログ1本の公開に14ステップの承認と9週間が必要だった企業の事例
Handoff Drag(引き継ぎの摩擦)	顧客の文脈が部署間で受け渡されず、担当変更のたびに関係をゼロから築き直す
Tools Drag(ツールの摩擦)	営業担当が独自スプレッドシートやチートシートで案件を回している状態は、工夫ではなくシステムの機能不全のサイン
Legacy Drag(レガシーの摩擦)	「2019年の法務トラブルが理由で設計された承認プロセス」が今も残り続ける

オペレーショナルドラッグを整理した後、Sowmyaが指摘したのは「では効率化しよう」という反応自体が落とし穴だということです。「もっとアウトプットを」「この手作業をなくせ」「もっと生産性を上げろ」。そういう声は組織の中に常にあります。しかし、その問いの立て方がすでに間違っている。「壊れたプロセスでも効率化はできる。でも正確にすればするほど、壊れる速度が上がるだけだ」

効率化は漸進的です。「どうすれば速くできるか」を問い続ける限り、同じ構造の上で回り続けます。本当に問うべきは「このプロセスはそもそも存在すべきか」であり、プランニングのたびにその問いから始める必要があります。変革は複利的に積み上がる、とSowmyaは言います。

セッションの締めくくりで、Sowmyaはこんな主旨のことを言っていました。

「成長は営業の問題でも、マーケの問題でも、プロダクトの問題でもない。成長はシステムから生まれる。そしてそのシステムを設計しているのは私たちだ」

From Sales Ops to RevOps: A People-First Playbook(Jelena Arnold)

アーキテクト思考の重要性が共有されても、実際の変革は進まず「見せかけ」で終わる現実があります。

RevOpsへの移行に取り組む企業の多くが、リーダーを採用し、役職名を変え、全社ミーティングで宣言する。それだけで終わってしまいます。実態は従来と同じ「依頼が来たら作る」業務のまま、適切な権限も渡されないまま。これでは何も変わりません。Jelena Arnoldはこの状態を「Sales Ops 2.0」と呼びました。

「多くの企業が部門名を変えているだけで、本格的な文化転換をしていない」と言います。

Sales OpsとRevOpsのモットーの違いを、Jelenaはこう言い切ります。

Sales Opsのモットー：「何が必要ですか？作ります」 RevOpsのモットー：「私たちはここを目指す。どうやって辿り着くか」

この転換は、思考だけでなく行動様式そのものを変えることを求めます。

組織全体の意思統一は「目標ではなく出発点」だという主張も印象的でした。リーダー全員が新しい定義に合意した瞬間を「達成」と思った途端、現場では例外対応の名のもとにスプレッドシートが乱立する状態へ逆戻りします。

変革を定着させるには、トップダウンとボトムアップの両方が必要です。リーダーシップが優先事項を設定し、現場がそれにコミットする。どちらが欠けても変革は機能しません。Jelenaが強調したのは、リーダー合意は出発点であって到達点ではないという点でした。「リーダーシップ・アライメントはゴールではなくスタートライン」。合意の瞬間は祝う価値があるが、そこからが本番だと。

Jelenaが続けて言ったのは、ここで言うアライメントとは経営層の合意のことではなく、現場との一つひとつの会話で積み上げていくものだという話でした。そしてその対話を、RevOps担当者は直接の指揮命令権を持たないまま進めなければなりません。

「まだ権限も信頼もない時に、人を動かすためには、社内のステークホルダーを相手に営業手法を使え」という提言がありました。

具体的には、Listen→Validate→Clarify→Closeの4ステップを社内コミュニケーションに適用するというものです。

ステップ	何をするか
Listen（聞く）	相手の話を最後まで聞き、本当の関心事を引き出す
Validate（承認する）	不満の内容ではなく、相手の感情をまず受け止める（同意ではなく承認）
Clarify（明確化する）	表面的な不満を額面通りに受け取らず、解くべき論点を絞り込む
Close（合意する）	解決策を提示し、相手の合意を取り付ける

各ステップで陥りがちな罠も示されました。Listenでは、相手が話し終わる前に頭の中で答えを組み立て始めてしまう。相手はそれを察します。Validateでは、「それは大変ですよね」と先に受け止めず、いきなり「でも、データではこうですよ」と返してしまう。相手は身構えます。Clarifyでは、最初に出てきた不満を額面通りに受け取って、まったく違う問題を直してしまう。本人たちは本当の問題をうまく説明できないだけなのに。Closeでは、解決策を提示してそのまま承認を待つだけ。それはCloseというより、ほとんど「祈り」です。

4つの罠のうち、特に難しいのがValidateでした。スライドには「同意ではなく、承認」という言葉がありました。これが4ステップの中で最もわかりにくい部分です。

例えば、「リードの質が悪い」という不満を受けたとき、まずListenでもっと話を引き出し、Validateで「それは大変ですよね」と感情を承認し（内容への同意ではなく）、Clarifyで「これはリード量ではなくフィット（適合性）の問題ですよね」と論点を絞り込み、Closeで「ではマーケが見込みありと判断したリード数を増やせれば、問題解決に向かいますか」と提案する。

たった一つの不満に向き合うのに、これだけの組み立てが要ります。変革は、こういうことの積み上げの上に成り立つ。そして、この積み上げに求められるのは、技術ではない領域の力でした。

Why Technical Skills Alone Aren't Enough to Succeed in RevOps（Arriel Balogun・Tana Jackson・Dom Freschi）

Tana Jackson は、医療機関での初めての管理職時代の話を語りました。受付業務を6週間で効率化することに成功したものの、勤続18年のスーパーバイザーから「最初はあなたのやり方が好きじゃなかった。でも今はいい」と告げられた経験。「問題を『直すこと』に集中するあまり、そこで長年働いてきた人々の感情や歴史に目を向けなかった」と、15年経った今も振り返っています。この経験から、感情的知性（Emotional Intelligence）と関係構築の重要性を学んだと言います。

Arriel Balogun は、CPQ構築で「複雑なことをシンプルにする人」として評判を得た結果、社内の誰もが「クリスマスリストを持ってくる」ようになりました。気づけばエンジニアとの設計打ち合わせから連続ミーティングへと日程が埋まり、朝4時まで稼働する日々。たとえやれることであっても、持続可能な形にするには境界線が必要だと学んだと言います。

Dom Freschi はビジネス言語とテクニカル言語の翻訳者としてプロジェクトを動かした経験から「経営層が求めるたった一つの数字の背後には、誰も解けていない巨大な氷山がある」と表現し、ビジネスとテックを繋げることの重要性を語りました。

組織として変革を進めるには、経営層との関係構築という別の問いもあります。RevOpsが「戦略パートナー」として認識されるかどうかで、できる仕事の広さは変わります。

Panel: Selling RevOps as a Strategic Partner（David Nelson・Sandy Robinson・Jose Aleman）

経営層から信頼を勝ち取る方法が、「Getting a Seat at the Exec Table」をテーマにしたパネルセッションで議論されていました。

Sandy Robinsonが繰り返し強調したのは、RevOpsが経営層に提示できる「オペレーティングプラン」を必ず持つことです。自社のアウトカムと、RevOpsがそこにどう寄与しているかを構造化したドキュメントを指します。Quavoがベンチャーキャピタル出資から3億ドル規模のプライベートエクイティ投資へ移行し、新CROが着任する局面で、Robinsonは着任前にこのプランを直接持ち込み、自身の価値を即座に認識させたと言います。

Jose Alemanは、経営層の語彙に話を合わせるべきだと指摘しました。チケット対応や進捗管理ではなく、「収益拡大」「収益保護」「リスク低減」という本質的な意図に紐づけて語る。直近の取締役会で議論された議題を読み込んで、データとして組み立てる。語彙を揃えて、はじめて議論の土台に立てます。

Robinsonの発言で特に刺さったのは、「経営層は、私たちが作ったクールなものには関心がない。彼らが見ているのはアウトカムだけ」という一言でした。「精緻な仕組みを作った満足感」と経営層の関心の間にあるギャップを、率直に突いています。

具体的な動き方として、横断プロジェクトのオーナーを取りに行く話もありました。Robinsonは、エンタープライズ向けのAIノートテイカーが全社導入される局面で、部門横断のオーナーとして手を上げた経験を共有しました。CFO、プロダクト、財務、経理まで巻き込み、各部門のユースケースを束ねる立場に立つことで、普段関わらない部署にもRevOpsの存在感を示せたと言います。

そして、席を待たない姿勢です。

"If they don't give you a seat at the table, bring a folding chair."

席が与えられないなら、自分で折りたたみ椅子を持ってきなさい。

Robinsonが引用したShirley Chisholmの言葉です。語彙を合わせ、席を自分で持ち込む。

AI × RevOps実践

ここまでは、変革に向き合う姿勢の話が中心でした。AI × RevOpsのセッションでは、その姿勢を踏まえて「実際にどう動かすか」が具体的に共有されていました。

4つのセッションを通じて感じたのは、議論の粒度でした。概念や可能性の話ではなく、どのプロセスのどの工程に何を載せるか、それを何で測るか、どこで詰まるかという解像度で話が進んでいきます。具体性のレベルが、すでに別段階に入っていました。

Rolling Out AI: From Newb to Black Belt Use Cases

登壇者は「AIをやれ」というトップダウンの号令を受けたRevOps責任者です。GTMツールスタックをどう問い直し、どう実装に踏み込んでいるかを、初心者向けの考え方から具体的なエージェント構築事例まで段階を追って共有していました。

最初に印象に残ったのは、AIをどう使うかという考え方そのものについての指摘でした。AIは「使い道のほうを探している解決策」だというものです。

従来のソリューション導入は順番が決まっていました。問題を特定し、評価を行い、ベンダーを選定し、ビジネスケースを構築して導入する。問題があって、それを解く道具を探しに行く流れです。AIの場合は順序が逆になります。強力な道具が先に手元にあり、それをどの業務に当てるかをこちら側が定義しなければならない。この根本的なアプローチの変化が、AI導入を混乱させている原因の一つだという分析です。さらに「内製するか購入するか」の境界もAIによって曖昧になっています。AIツールを買うことと、AIで何かを作ることが、機能面でほぼ等価になりつつある。登壇者はこの状況を「制約のないオープンワールドゲームに放り込まれた状態」と表現していました。過去の枠組みが提供してくれていた「ガードレール」が失われている。

ガードレールがない状況では、いま使っているツール群を今までの基準のまま見ていいのか、というところから怪しくなります。ここで登壇者が出してきたのが、ゼロベース評価という発想でした。GTM（市場開拓）ツールを一つひとつ取り上げ、「もし今ゼロから入れ直すなら買うか」を問う。Salesforceでさえ例外ではないと述べ、「ほんの3か月前なら一蹴していたような問いだが」と前置きしつつ、真剣に検討していました。背景には、ツール間の機能セットが半年単位で重なり合い融合していくため、特定時点の「正解」が短命だという認識があります。

これだけ変化が早いと、意思決定のスタイル自体を見直さなければ追いつけません。ここで肝になるのは、ツールをすぐ撤去することを「失敗」と捉えない姿勢でした。年単位で長く使うのを前提にした時代から、3〜6か月で賭け直す時代へ。撤退をためらわないことが、AI時代の意思決定の出発点になっている、という話でした。

このセッションでは、実際に動いているAIエージェントの事例も紹介されていました。PoCの段階を超えて、実際の業務プロセスとして稼働しているものばかりでした。

名刺取り込みエージェント（構築時間：約1時間）
イベントで配布された名刺をスマホで撮影するだけで、Glean（社内知識検索ツール）がデータを抽出・分類し、Google Sheetsを中継してClay（データエンリッチメントツール）でデータを補完し、Salesforceに登録、マーケティングオートメーションがキャンペーンに自動投入する一気通貫フロー。
法務向け契約分析ツール（構築時間：約3時間）
Salesforceに添付されたNDAやMSA（基本契約）の書類をAIが検索・分類し、署名有無や契約種別を判定。契約メタデータをデータウェアハウスに自動格納する仕組み。
レポーティングエージェント（構築時間：約6時間、精度：98%）
Salesforce上にカスタムオブジェクトとして「データディクショナリ（自社固有の業務定義）」を置き、自然言語の問い合わせをSalesforceレポートに変換して自動グラフ化。

AIへの向き合い方が非常に参考になりました。そして、「こういうのやりたいな」と思っていたものが、目の前で動いていることに正直驚きました。

Beyond Use Cases: A Strategic Framework for Scaling AI in B2B Sales（Jiaxi Zhu）

個別のユースケースが回り始めたとしても、それを全社規模でスケールさせることは別の問題です。Jiaxiはこのスケールの難しさを体系的に整理しました。

前提として置かれた数字があります。営業活動の約40〜50%は自動化可能だと試算されている。一方で、MITの調査ではAIプロジェクトの95%がスケールに失敗している。可能性と現実の間には大きな乖離があるという出発点です。

乖離の原因として、現場主導（個人最適化されていてスケールしない）と中央主導（現場実態から乖離しやすい）の非対称性が挙げられました。営業担当者は技術的素養の有無を問わずAIを業務に取り込み始めている。現場での試行錯誤は速く回るものの、特定の個人やチームに最適化されているためスケールしにくい。一方で経営層主導の中央展開は、リソースと一貫性を確保できる反面、現場の実態から乖離しやすい。B2B営業は意思決定者・実務担当者・アナリストなど多様なステークホルダーを横断し、案件ごとにカスタマイズを要するため、買ってきてそのまま当てはめるようなAI導入は機能しにくいという結論でした。

その上で、Jiaxiが繰り返したのは「利用率はAIの人気を示すが、価値は示さない」という点でした。利用者数やダッシュボード訪問数は普及度を示しますが、ビジネス価値とは必ずしも連動しません。利用が実際に成果につながっているかをA/Bテスト等で確かめる仕組みが必要であり、AI展開は「ツール導入の問題ではなく、価値の明確化の問題だ」と整理されていました。

また展開の際には、データ・ワークフロー・人材の3軸を並行して設計する必要があるという枠組みも提示されました。データの定義は組織目標と整合しているか（例えば営業の接触量を電話の件数だけで測るのか、メッセージのやり取りも含めて測るのか）。ワークフローは営業の繁閑サイクルに沿っているか（ホリデーシーズンに大規模刷新は避ける）。人材ではジュニアとシニアで期待値を分けて再設計する（ジュニアは担当アカウント数の量的拡大、シニアは関係性の質の深化）。

具体例もいくつか紹介されました。米国では機能していた顧客感情測定ツールが、テキストメッセージ中心で商談が進む地域では通話記録のサンプル不足で動かなくなった、という失敗事例。あるいは、CRMとそこに統合されていないAIツールを行き来しながら、数値を覚えつつ電話で顧客対応する「コンテキストスイッチング」が現場の負荷になっているという指摘。どちらも、机上の戦略では見落とされがちな現場の摩擦です。

Integrating AI into Sales Planning（Stephanie Martin）

余談ですが、このセッションは最初から最後までスライドが映らないトラブルが続き、Stephanie MartinとWerner Schmidtの2人によるフリートークに近い形で進行していました。手元のメモから印象に残った論点を抜き出しています。

続くテーマはセールスプランニング、つまり収益計画づくりへのAI適用です。AIをスケールさせる横断的な話から、特定領域に踏み込んだ話に切り替わります。

そもそもセールスプランニングは本質的に複雑です。収益目標、TAM（対応可能市場）に対するカバレッジ、ヘッドカウント、キャパシティ、テリトリー設計、クォータ配分、活動量設計、パイプラインのコンバージョン率、アトリビューション分析と、30〜40ピース規模のパズルがすべて噛み合って初めて機能します。さらに市場環境、製品ロードマップ、組織体制が常に外乱として作用するため、一度立てた計画はすぐに陳腐化していきます。

そこに2022年以降の変化が重なります。「成長のためなら多少のコストは許容される」時代から、「収益性のある効率的な成長（Profitable Efficient Growth）」が前提条件になる時代へ。ROIを伴わない人員増は許されない。計画の難易度が一段上がっているという認識がセッションの出発点でした。

そして経営層からは「AIで生産性を25%、40%、ときには60%向上させよ」という指示が降ってくる。組織が一度に吸収できる変化の量には限界があり、スプレッドシート中心のオペレーションがそれを阻んでいる。この圧力と現場のギャップをどう埋めるかが、Stephanie MartinとWerner Schmidtが提示した問題でした。

選択肢として議論されたのが、「汎用LLMで自前構築するか、目的特化型プラットフォームを買うか」です。

"Don't file your taxes in a conversation with ChatGPT."

ChatGPTとの会話で確定申告をするな。

数十億ドル規模の収益計画を、ガバナンスのない対話型AIに丸ごと預けるのは、ChatGPTに確定申告を任せるのと変わらないリスクだ、というのが論旨でした。30〜40個の変数が絡み合うセールスプランニングには、数字の正となる唯一の置き場、変更の履歴が残る仕組み、複数部門が同じ数字を見て議論できる場が必要になる。これらは汎用LLM単体では作りきれない、と整理されていました。「今の技術を悪いプロセスの上に載せるのは、最悪の使い方だ」という指摘も残っています。

もう一つの論点が、計画運用のリズムです。年次計画を4ヶ月かけて作り上げ、あとは触らない、という従来のサイクルが、戦略の動きに追いつかなくなっている。戦略が動いたら計画も動かす「Continuous and Dynamic Planning（継続的かつ動的な計画運用）」に切り替える必要がある、という問題意識でした。

The Future of RevOps with AI（Jeff Ignacio）

クロージングキーノートでJeff Ignacioが描いたのは、AIによってRevOpsという仕事そのものがどう変わっていくかの見取り図でした。

最初に出てきたのが「ジェヴォンズのパラドックス」、つまり効率化が進むほど需要は減らず増えるという経済現象をRevOpsに当てはめた指摘です。取締役会で求められていた二次分析を提供しても、感謝の言葉ではなく三次分析の依頼が返ってくる。RevOpsが成果を出すほど、要求はさらに増えていく。「効率化すればするほど、需要は減らずに増える」

AI活用の使い方には二段階があるとJeffは整理しました。第一段階は既存業務をより速く・強くこなす「インクリメンタル（漸進的）」な活用。第二段階は、これまで物理的に不可能だった業務を可能にする「飛躍（leapfrogging）」型の活用です。代表例として挙げられたのが営業電話の聞き込みでした。従来は人間が4倍速で再生しても週に聞ける本数には限界がありましたが、AIを使えば全顧客・全見込み客・全ステージ・全業界・全セグメントの通話を網羅的に分析できる。サンプル抽出ではなく全件のWin/Loss分析が初めて可能になる。これまで誰も得られなかったインサイトが手に入ります。

その上でJeffが強調したのは、AIには代替できないスキルセットでした。

"AI can be confidently wrong."
AIは自信満々に間違える。

AIが代替できないスキルとして挙げられたのが、「何が良い成果物かを判断できる目利き力」「組織固有のデータ定義とビジネスロジックの理解」「CRMのテーブル構造とフィールドの意味理解」「経営層との信頼関係構築」。特に目利き力は、そうだよなと素直に同意できる指摘でした。AIの出力を評価する基準を持っていなければ、使いこなしているのではなく使われているだけです。CRM構造理解の重要性も具体的で、MCP（Model Context Protocol、AIと外部システムを接続する仕組み）経由でClaudeにSalesforceやHubSpotを問い合わせると、四半期ごとのウォーターフォール分析のような複雑な計算では誤った答えが返ってくる。MCPは全レコードを保持せずコンテキストウィンドウを使い切ってしまうためです。テーブル構造とフィールドの意味を理解した人間が、構造化されたデータをAIに供給する設計を作らなければ動かない。

RevOpsの成熟度モデルの話も印象に残りました。これまでは「Reactive（受動的）→ Proactive（能動的）」の二段階で語られてきた領域です。Reactiveは「言われたからやる」「先に来たタスクから順にさばく、優先順位の概念がない」段階。Proactiveは「自分たちがどこに向かいたいかをわかっていて、ロードマップを描き、優先順位を立て、経営陣にそれを売り込み、重要なステークホルダーにもNoと言える」段階です。ここにAIエージェントの登場で、第三段階として「Always-on（常時稼働）」が現れた、というのがJeffの整理でした。エージェントは人間が眠っている間も動き続けるので、もはや同じ土俵で競うという発想ではなく、人間にできるのは、せいぜいエージェントが何をしているかを点検することと、その振る舞いをあらかじめ仕込んでおくことくらいになる。

複数のセッションを通じて共通していたのは、AIを真っ先に入れたがる風潮への警鐘でした。整っていないプロセスと不揃いなデータの上にAIを載せても、AIがそれを直してくれることはない。プロセスを定義し、人が使える状態にし、最低限機能する形が整って初めて、その上にAIを載せる意味が出てくる。Steve Busbyのキーノートでは、これを「AIファーストになりたいなら、AIに手を伸ばすのは一番最後でいい」という逆説で表現していました。

4つのセッションを通じて何より刺激を受けたのは、AIをこれだけ具体的に、そして体系的に語れているという事実でした。ユースケース紹介で終わらず、議論が地続きで積み上がっている。問いの解像度そのものが違うと感じました。

まとめ：方向性は同じ、でもスピードが違う

参加を決めたのは2025年11月のことでした。自社のRevOps設計が一段落したタイミングで、最先端との距離感を正確に測りたいと考えたのが動機です。まだ本格的な構築はこれからという局面でしたが、だからこそ今行く意味があると判断しました。そして、事業部に費用を支援いただき、参加が実現しています。

収穫はありました。RevOpsは元々自分の専門領域の外のものでしたが、カンファレンスに参加したことでこの先の輪郭がハッキリ見えました。最先端の人たちと目線は近いです。「待つのではなく、変革すべき」「技術だけでは足りない、翻訳力とEQが必要」。どれも自分の目の前の世界でも語られている話で、目指している方向性として大きな違いはありませんでした。
差がついているのはシンプルにスピードです。

スピードの差は、知識の差ではないと感じました。「知っている」ことは同じでも、「実践して失敗して改善した回数」が違う。カンファレンスで語られた具体的な失敗談の密度が、そのまま差の正体でした。まず動かす、そこからしか縮まらないと思います。

特に距離を感じたのは、AIの活用フェーズでした。AIをどう載せるか、データをどう整えるか、エージェントをどう運用に乗せるか。ここで語られていた粒度は、自分の現在地より一段も二段も先にありました。

やれるところから色々試して、勝ち筋を見つけて、守るべきところは守る。そういった動きを地道に重ねていくしかないのだと、改めて感じました。

依頼を待つのではなく、能動的に動く。適切に人を巻き込み、少しずつ改善を重ね、大きな変革につなげる。これを意識して、目の前の仕事に向き合っていこうと思います。