サムネイル

「CRMに入力しない時代」の設計思想 — Day AIが問い直すこと

  • 0

「CRMに入力してください」というアラート、いつからか誰も本気で読まなくなっていませんか。

営業もCSも「入力コストのために顧客との時間を奪われている」という違和感を、20年間ずっと抱え続けてきた領域です。

そこにHubSpotで10年以上プロダクトを率いた元CPOが「もう入力させないCRM」を建てて、Sequoiaが$20M(約31億円)をつけました。

プロダクト名はDay AI、フレーミングは「Cursor for CRM」です。

この記事は、Day AIを「導入するかどうか」ではなく「プロダクト設計の前提が何を問い直しているか」の視点で読み解きます。

CRMを選ぶ人ではなく、プロダクトを設計する人に向けた整理です。

Day AIとは何か — HubSpot元CPOが作った『Cursor for CRM』

Day AIは、メール・Zoom・Slackなどの会話データをAIが自動で読み取り、CRMを人の手を介さず構築していくプロダクトです。

2026年2月にSequoia主導で$20M(約31億円)のSeries Aを調達し、この時点で約120社の顧客と非公開ベータを1年以上回してきた実績を持ちます。

創業者はChristopher O'Donnellさん。

HubSpotに2011年に参画してから10年以上プロダクトを率い、マーケティングツールだったHubSpotを「Salesforceの牙城に食い込めるCRM」にまで育てた立役者です。

共同創業者のMichael Piciさんも元HubSpotのVP of Product, Revenue。

CRM設計の第一線を走ってきた2人が、自分たちが作ってきたHubSpot型CRMの限界を認めて、ゼロから作り直しにきたプロダクトなんですよ。

「自分が作ってきたパラダイムを、自分で否定しにきた」ここが最大の読みどころです。

Sequoiaが投資判断で拾った構造

Sequoiaで共同リードのPat Gradyさんは投資理由として、「部分的なソリューションでは、昨日のやり方に閉じ込められる」という言い方をしています。

CRMにAI機能を「後付けで足す」戦略と、「AI前提でゼロから設計し直す」戦略は根本的に別物、という判断ですね。

この判断は、プロダクトを設計する側にとってかなり重い示唆を含んでいます。

既存プロダクトに「AI機能追加」で乗り切れる領域と、「設計の前提から作り直さないと解けない」領域の線引きが、CRMの事例で先に見えてきたということです。

Day AIが問い直す前提 — 「営業データは入力するもの」か

CRMという製品カテゴリの20年間、暗黙の前提は「営業担当者が顧客との会話を要約して入力する」でした。

ダッシュボードも、パイプライン管理も、予測精度も、全部この入力データを土台に組み上がっています。

問題は、この前提が事実上ずっと崩れていたことです。

営業は「顧客と話す」ために雇われているのに、勤務時間の何割かを「話した内容をCRMに書き写す」作業に使わされてきました。

しかも書き写した内容は、話した瞬間の温度感やニュアンスが抜け落ちた要約でしかない。

Sequoiaの表現を借りると「声の変化、質問の内容、複数チャネルでのやり取りといった機微が失われて、予測精度が下がる」ということですね。

メール・Zoom・Slackを聴いてCRMを自動構築

Day AIの仕組みはシンプルで、営業やCSが日常的に使っているメール、Zoom、Slack、カレンダー、LinkedInといったソースをAIが直接聴取し、顧客・案件・タスクの構造をCRM側で自動生成します。

営業担当者は「入力しない」のではなく「入力する対象がそもそも存在しない」設計です。

導入のオンボーディングも15分で完了する設計になっており、「まず1〜2ヶ月かけてデータモデルを設計する」というエンタープライズCRMの立ち上げ工程を根本から外しています。

ここが面白いところなんですが、この設計だとCRMは「営業のための入力箱」ではなく「経営やチーム全体が観察するための出力ダッシュボード」に役割が変わります。

データを作る責任者が「人間の営業」から「AIの聴取エージェント」に移るわけです。

Cursor for CRM が示す設計思想 — CRMは「編集する」から「観察する」へ

「Cursor for CRM」というフレーミングは、プロダクト設計の観点で読むと単なるマーケコピー以上の意味があります。

Cursorは、コードを書く行為の主導権を「人間が全部タイピングする」から「AIが提案してきたものを人間が判断する」に反転させました。

エディタは「入力デバイス」から「AIとの対話インターフェース」に役割を変えたんですよ。

同じ構造変化を、CRMという領域でDay AIが起こそうとしています。

CRMは「営業が手で更新するデータベース」から「AIが作った文脈を人間が観察して意思決定するインターフェース」に反転する、ということです。

この反転が起きると、プロダクト側で設計しなければならない要素が3つ変わります。

  1. データエントリーUIの優先度が急落する(入力する対象がないので)
  2. 「観察・検索・要約」のUIが最重要になる(AI生成データを人間が扱う場所になる)
  3. データの「信頼性の見せ方」が新しい設計課題になる(AI推論を人間が判断するために、根拠の可視化が必須)

3番目、けっこう見落とされがちなポイントです。

AIが自動生成した顧客情報を人間が意思決定に使う場合、「どのメールの・どの発言から抽出したか」を辿れないと、そのデータは使えません。

編集型CRMなら「自分が書いた記憶」が信頼担保だったのが、観察型CRMでは「AIが根拠を提示できるか」が信頼担保に変わるんですよ。

Attio・Gong・Attention との違い — 設計思想の対比

記事の画像

AIネイティブCRM周辺には、Day AI以外にも有力プレイヤーがいます。

ただし各社の設計思想は微妙にずれていて、比較表を見るときに機能一覧ではなく「どこに設計の重心を置いたか」で読み分けると輪郭がはっきりします。

プロダクト
設計の重心
ユーザーが「する」こと
Attio
柔軟なデータモデルとAIエージェント
オブジェクトを自分で設計し、AIに動かさせる
Gong
通話の記録と分析
通話後の振り返り・コーチングに使う
Attention
通話中のリアルタイム支援とCRM自動記入
商談中にAIから提案を受け、既存CRMに反映
Day AI
全チャネル聴取によるCRM自動構築
そもそも入力せず、AIが構築した文脈を観察する

Attioは「AIネイティブCRM」を掲げていますが、思想の中心は「柔軟なデータモデル×AI」で、ユーザーが自分たちのビジネスに合わせてオブジェクトを定義できることを強みにしています。

裏を返すと、設計工数が発生する前提のプロダクトです。

GongとAttentionは、そもそもCRMを「置き換える」ではなく「補完する」設計です。

GongはHubSpotやSalesforceの横に立って通話データを分析する層、Attentionは既存CRMへの自動記入を担うレイヤー。

既存CRMの入力コストを下げる方向ですね。

Day AIだけが「既存CRMを補完せず、置き換える」立ち位置に立っていて、しかも「入力するCRMそのものの存在」を疑っています。

ここが根本的に別ゲームです。

「AIネイティブCRM」というカテゴリ名だけで括ると全部同じに見えますが、設計思想を並べると4社は別々の仮説に賭けていることが読み取れます。

プロダクトが読み解くべき波及効果

記事の画像

Day AIのアプローチが正しかった場合、CRM周辺だけでは波及が終わらない話になります。

ここは自社プロダクトを設計している立場で読むべきポイントです。

第一に、営業やCSのKPI設計が変わります。

「CRM入力率」「更新頻度」といった従来の運用指標が意味を失います。

代わりに「顧客文脈の網羅性」「AI予測精度」といった観察側の指標が中心に来る。

営業組織のマネジメントは、入力を強制するマネージャーから、AI出力を検証・活用するマネージャーへ役割が変わっていきます。

第二に、既存CRMベンダーへのプレッシャーが構造的に強まります。

HubSpotもSalesforceも既に「AI機能追加」で対応していますが、Sequoiaが「部分的では追いつけない」と判断した通り、既存の入力型データモデルを維持したままではDay AI型の体験を出せません。

ここが既存プレイヤーの構造的な弱点になります。

第三に、CRM以外の「人間が手入力してデータベースを育ててきた」プロダクト領域にも同じ問いが波及します。

プロジェクト管理ツール、ATS(採用管理)、ヘルプデスク、経費精算、資産管理。

「入力を頑張らせる」設計思想で立ち上がってきたSaaSは、Day AI型の再設計プレッシャーを近い将来受ける可能性が高いです。

自社プロダクトがこの3つのうちどこに位置するか、一度棚卸ししておく価値はあります。

使い始めるとしたら、まず何を見るか

もし早期試用を検討するなら、機能一覧を読む前に押さえておく3つの前提があります。

1つ目は日本語対応。

現時点でDay AIは英語圏を中心に展開していて、日本語会話の音声認識精度・日本語メール文脈解釈の水準・国内商習慣への適応度は公式で個別に確認する必要があります。

海外プロダクトの「AIが理解する」は、日本語だと想定外に精度が落ちるケースが多いです。

2つ目は国内法規対応。

会話音声とメール本文をAIが自動聴取する設計なので、個人情報保護法・GDPR・録音の同意取得プロセスといった論点が全部関係します。

日本市場での本格運用には、これらの整備状況を公式に問い合わせて確認してからが安全です。

3つ目は既存CRMからの移行運用。

Day AIは「置き換え」を前提としたプロダクトなので、HubSpotやSalesforceを長年運用してきた組織が乗り換える場合、既存データの資産化・並行運用期間の設計・組織のトレーニングコストが発生します。

プロダクトの設計思想が違うぶん、機能単位の移行より運用単位での移行になります。

まずは、自社の営業やCSが「本当に入力コストで疲弊しているのか」を1週間データで測ってみるところからで十分です。

数字が出てからDay AI型の設計を検討しても遅くありません。

最後に - 「入力しないCRM」が来た日

Day AIが提示しているのは、単なる新しいCRMプロダクトではなく「入力を前提に組まれてきたプロダクト設計そのものを問い直せ」というメッセージです。

自分がCRMを担当していなくても、この問いは効きます。

プロジェクト管理、採用管理、ヘルプデスク、資産管理。

「人間の手入力を頑張らせる」設計思想のプロダクトは、いま同じ問いに再び向き合わされる位置にあります。

HubSpotのプロダクトを10年以上作った本人が、自分の作品を「時代遅れ」と言い切って作り直しに来た事実は、業界全体への合図です。

CRMを選ぶかどうかではなく、自分のプロダクトのどこに「入力させ続けている前提」が残っているか、一度棚卸ししてみてください。

「それ、AIに聴かせられませんか?」という問いから、次の設計は始まります。

会員登録して機能を使おう

この機能を利用するには、無料の会員登録が必要です。
お気に入りの記事を保存して、あとで読み返しましょう!