More in
Sales Tech News
Meta Put an AI Agent in WhatsApp That Closes Sales for Any Business
6月 4, 2026
Are AI SDRs Worth It in 2026? The Data Says Build a Hybrid Team
6月 3, 2026
GTM Engineering in 2026: The Sales Hire That Replaces Three Roles
6月 3, 2026
ZoomInfo Feeds Verified Data to Your AI Sales Agents: The Single-Vendor Tradeoff
6月 3, 2026
Salesforce Summer '26 Drops Multi-Agent Orchestration June 15. Here's the Sales Ops Audit Before Your Agents Start Handing Off
6月 2, 2026
Outreach Wired In 20 New Buying Signals for Your Sales Team
6月 2, 2026
Salesforce Buys Contentful to Give Agentforce a Content Engine
6月 2, 2026
Why AI-Native Startups Pick Their CRM by the Agents, Not the UI
6月 2, 2026
Agentforce Just Hit $1.2B ARR in 14 Months: What CROs Should Audit Before Q3 Planning
6月 1, 2026
Sierra Just Crossed $15B Selling AI Customer Agents Into Half the Fortune 50. Here's the Sales Ops Read
6月 1, 2026
OpenAIのエンタープライズエージェントプラットフォーム:データサイエンスチームが構築を始める前にRevOpsが理解すべきこと
データサイエンスチームはすでに興奮している可能性が高い。おそらくすでにプロトタイピング中だ。そして会社にある程度の勢いを持つAIイニシアティブがある場合、OpenAIのインフラの上に内部エージェントを構築することを誰かがほぼ確実に言及している。
それは悪い直感ではない。しかし、誰もまだ話していないRevOpsの問題を生む。
2026年2月、TechCrunchはOpenAIが「Frontier」——企業が独自のAIエージェントをOpenAIの基盤モデルをエンジンとして使って構築・管理したい場合向けに設計されたエンタープライズプラットフォーム——をローンチしたと報道した。TechCrunchがそれを説明したように、プラットフォームはエージェントを「人間の従業員のように」扱うことを中心に構築されている——管理、監視、展開ツールが含まれる。これは新しいGPTモデルではない。モデルの上に座るインフラの層であり、事前構築済みのAIツールを購入するのを止めて独自のものを構築し始めたい組織を直接ターゲットにしている。
その区別——プラットフォーム対モデル——がRevOpsが正しく把握する必要がある最初のことだ。誰が何を所有するかが変わるからだ。
プラットフォーム対モデル:RevOpsがなぜこの違いを気にする必要があるか
会社がAIモデルへのアクセスを購入するとき(GPT-4、Claude、Gemini)、モデルが考える。データは自社のシステムにあり、モデルは与えた入力を処理する。セキュリティの境界は比較的明確だ。
エージェントプラットフォームは異なる。エージェントは行動するよう設計されている——データを読み取り、決断を下し、アクションを取り、結果をどこかに書き戻す。システムに接続する。認証する。永続的だ。そして重要なのは、機能するために必要なデータ——パイプラインのステータス、コンタクトレコード、ディールの履歴、予測シグナル——はRevOpsが所有し責任を持つCRMに存在することだ。
これは理論的ではない。収益に関係するすべての価値あるエージェントはベースとしてCRMの読み取りが必要で、有用であるためにおそらくCRMの書き込みが必要だ。それが何を意味するか考えてほしい。OpenAIのFrontierプラットフォーム上に構築されたカスタムエージェントがデータサイエンスチームの誰かによって承認され、商談ステージを更新し、コンタクトレコードにノートを書き込み、予測カテゴリーを変更する可能性がある。そしてRevOpsはそれが実行されていることさえ知らないかもしれない。
それが閉じる必要のあるガバナンスのギャップだ。
RevOpsのデータ準備チェックリスト
組織がエンタープライズエージェントプラットフォーム上で何かを構築する前に——OpenAIのFrontier、NVIDIAのオープンエージェントインフラ、または他のもの——データの家を整える必要がある。実際に重要なことを示す:
1. スキーマ文書が現在でアクセス可能だ。 エージェントはフィールドを消費する。過去3年間で4つの異なる営業チームが異なるネーミングをしたため、CRMスキーマに「ディールステージ」の14のバリエーションがある場合、エージェントはそのメスをスケールで複製する。プログラマティックアクセスを許可する前に、標準的なフィールドを文書化して実施する。
2. データ品質のベースラインが確立されている。 担当者が商談のクローズ日付を更新しないためにセグメントごとのウィンレートが一度も信頼できたことがない場合、そのフィールドで予測するようトレーニングされたエージェントは自信満々で聞こえる悪い予測を生成する。任意のシステムがそれを真実として消費し始める前にデータ品質のフロアを知る。
3. インテグレーション認証がレビューされている。 現在CRMへのAPIアクセスを持っているのは誰か?そのリストはいつ最後に監査されたか?エージェントプラットフォームはシステムアイデンティティの新しいカテゴリーを追加する——エージェント自体、それを設定した人間だけでなく。インテグレーション認証モデルはこれを考慮する必要がある。
4. 書き込みアクセスが明示的にスコープされている。 パイプラインデータを読み取るエージェントとそれを変更するエージェントの間には意味のある違いがある。読み取り専用エージェントはより低リスクだ。コンタクトレコード、ディールステージ、またはカスタムフィールドへの書き込みアクセスを持つエージェントは明示的な承認、文書化されたスコープ、ロールバックプロトコルが必要だ。
5. データ保持とプライバシーポリシーが自動化されたシステムをカバーしている。 欧州で事業を行っている会社の場合、コンタクトレコードから個人データを処理するAIシステムはGDPRとEU AI Actの下での義務をトリガーするかもしれない。出荷する前に確認する。
組織が答える必要があるガバナンスの問い
データ準備はテーブルステーク(最低条件)だ。より難しい会話はガバナンスだ——誰が何を承認する権限があり、何かが間違ったときに何が起きるか。
RevOpsがどんなエージェントが本番に入る前に提起すべき問いを示す:
誰がCRMへの書き込みのエージェントアクセスを承認するか? これはデータサイエンスだけの決断ではあるべきでない。CRMレコードを変更するエージェントは機能的にパイプラインを変更している。それはRevOpsと営業リーダーシップの判断呼び出しだ。今すぐ承認パスを確立する——最初のインシデントの後ではなく。
監査証跡は何か? エージェントが火曜日の夜に200件の商談ステージを更新した場合、何が変わり、なぜ、元に戻せるかを教えてもらえるか?ほとんどのCRMにはフィールドレベルの監査ログがあるが、デフォルトでは常に有効ではない。自動化された書き込みが起きる前にロールバックプロセスをオンにしてテストする。
エージェントのエラーをどのように処理するか? 人間の担当者はCRMで間違いを犯し、捕まえて修正するプロセスを構築してきた。エージェントのエラーは異なる——ランダムではなく系統的になりがちだ。誤設定された1つのルールで多くのレコードをすぐに破損できる。自動化されたシステムのエラー処理プロトコルは人間より厳しくあるべきだ、より寛大ではなく。
エージェントが誰も意図しないアクションを取るときのエスカレーションパスは何か? これは起きる。自動化がライブシステムに触れるとき常にそうだ。エスカレーションパス、インシデントオーナー、コミュニケーションプロトコルをそれが起きる前に定義する。
エージェントロジックの継続的なメンテナンスを誰が担当するか? 今日構築されたエージェントは変化するCRMスキーマ、進化するパイプライン、アップデートされるビジネスルールとやり取りする。誰かがロジックを所有して何かが変わったときにレビューする必要がある。「データサイエンスチームがそれを構築した」は持続可能な答えではない。
これらすべての背後にある内製vs購入の問い
Frontierのローンチが実際に強いる決断を一歩引いて名指しする価値がある。組織は今AIエージェントの購入(Salesforce Agentforce、HubSpot Breeze)とOpenAIのプラットフォームやNVIDIAのオープンソースツールキットのようなインフラ上での構築の間の本物の選択肢を持っている。
購入パスは出発点としてより低リスクだ。AgentforceとBreezeはそれぞれのCRMにすでに統合されている。ガバナンスツールが存在する。ベンダーがメンテナンスを担当する。しかし、彼らが構築したものに制約される。
構築パスはより多くの柔軟性と特定のワークフローへの潜在的により良いフィットを提供する。しかしデータ準備の負担、ガバナンス設計、継続的なメンテナンスをチームに置く。
ほとんどのRevOps組織にとって、現時点での正しい答えは「ゼロからすべてを構築する」ではない。「その上に構築されるものをガバナンスするのに十分なほどプラットフォームを理解する」だ。つまり、プロトタイピング中のデータサイエンスの部屋にいること——エージェントがすでに6週間CRMと話していた後に学ぶのではなく。
CRMガバナンスフレームワークについてより広く考えているなら、この決断はパイプラインアクセスを持つ任意のシステムについてすでに尋ねているべき同じ問いのセットに収まる。
今週すべきこと
データサイエンスチームの実験を止めることはできない——そしてすべきでもない。しかし、その実験がパイプラインの整合性を保護する構造の中で起きることを確認できる。
今週:
- ITまたはデータサイエンスチームに直接尋ねる。現在CRMに対してエージェントをプロトタイピングまたはスコープしているか?回答に驚くかもしれない。
- CRMのAPIアクセスログを取り出し、認識しないインテグレーションまたはシステムユーザーを特定する。アクティブでなくなったものを閉じる。
- CRM管理を率いる人と30分スケジュールし、1ページのポリシーの下書きを作る。エージェントは本番のCRMデータへの書き込みアクセスを得るために何を経由する必要があるか?最初の粗い下書きでも、ほとんどの組織が現在持っているものより多い。
- 低い賭けの1つのワークフローを特定する——おそらく完了したアクティビティのログや、メールエンゲージメントに基づくカスタムフィールドの更新——サンドボックス環境でシンプルなエージェントをパイロットすることを厭わない。本物のテストケースを持つことはガバナンスプロセスに対して作業する具体的なものを与える。
プラットフォームはすでに存在する。データサイエンスチームはすでにそれに興味を持っている。RevOpsの役割はここで物事を遅らせることではない——エージェントが収益インフラで動き始めるとき、設計したガードレールの中で動いていることを確認することだ。

Co-Founder & CMO, Rework