Railwayが登録ユーザーの利用履歴から営業対象を選別した方法

はじめに

最近、サイドプロジェクトで金融商品分析サイトを制作するにあたり、クラウドデプロイプラットフォームのRailwayを初めて利用してみました。それまではVercelとSupabaseで十分だと考えていましたし、エラー追跡ツールのSentryも本当に必要なのか悩んでいたところでした。コスト面からRailwayを試してみたところ、技術面だけでなく顧客を獲得しサポートする手法に関しても参考にすべき点が数多くありました。折しも、Railwayが2026年5月6日に公開した『Kill your onboarding』という記事を目にしました。新規登録者に画一的な営業メールを送るのを改めた経験を綴った記事です。

当時、Railwayには1日1万件以上の新規登録があり、2026年4月以前の累計登録者数は約290万人に達していたといいます。**営業チームが求める顧客条件であるICP¹に合致するアカウントを約2万1000件特定していたものの、実際にアプローチできていた割合は1%未満にとどまっていました。**企業に所属するユーザーであっても、個人プロジェクトを進めているのか、チームの実環境を構築しているのかによって必要な支援は異なるにもかかわらず、一律の案内メールを送り続けていたのです。この記事は売上不振の原因を追究したり、売上の改善を実証したりした報告書ではなく、営業対象を見つけ出してアプローチする手法を見直した初期の事例です。

利用履歴を営業チームが活用できるようにする

製品の利用体験を通じて顧客を獲得するPLG²においては、登録手続きを簡素化することが極めて重要です。ただし、会社名やチームの規模を尋ねない場合、営業チームは別のデータから利用目的を把握しなければなりません。

私のように個人プロジェクトを作る人もいれば、会社の業務で使うチームもあるはずです。RailwayではGitHubアカウントやメールアドレスで登録すればすぐにデプロイできるようにし、企業名やエンジニア数を尋ねるアンケートは意図的に設けなかったといいます。まずは製品を使ってもらうことを優先し、エンタープライズ顧客を発掘するプロセスは別途用意する必要がありました。

当時の営業チームは、AE（アカウントエグゼクティブ）1名とSE（ソリューションエンジニア）2名という構成でした。この小さなチームが、2万1000件もの潜在的な企業アカウントの中から、どこに優先してアプローチすべきかを判断できるよう支援する仕組みが求められていました。

創業者のクーパーも、すでに獲得した見込み顧客と利用履歴を営業活動に十分活用できていないと指摘していました。

RailwayはPostHogを用いて、製品の利用イベントを長期にわたり収集していました。内部システムであるbackboardにも、プロジェクトのサービス構成、インスタンスサイズ、データベース接続、デプロイ結果などが記録されていました。分析に必要なデータは揃っていたものの、そのデータから営業チームがアプローチすべきアカウントを抽出するプロセスが抜け落ちていたのです。

マッキンゼーによるPLG研究でも、製品の利用体験と企業情報を併せて分析し、適切なタイミングで営業チームが介入する手法が解説されています。利用行動に基づいて購買の可能性を評価した見込み顧客をPQL³と呼びます。単に登録者数を増やすだけでなく、どのユーザーにどのようなサポートが必要かを見極める取り組みです。

企業アカウントにより多く見られる行動

Railwayのソリューションエンジニアであるデス・コンロン（Des Conlon）は、企業アカウントと個人の趣味アカウントで、それぞれどのような行動が頻繁に現れるかを比較しました。Hexとdbtで分析環境を構築し、行動ごとの発生比率を算出しました。反復的なクエリを作成する際にはHexのLLM機能を活用しましたが、最終的なスコアは自身で厳選した行動と重み付けによって計算しました。

コンロンは、一見すると予測精度が最も高そうなシグナルをあえて除外しました。

たとえば、SSO（シングルサインオン）の利用は企業アカウントで顕著に見られましたが、これは営業チームと商談済みの顧客のみが有効化できる機能でした。まだ接触できていない企業顧客を見つけ出すという目的には役立ちません。コンロンは、このように結果を知った後に生じる情報が入力データに混入する「ラベル漏れ（Label Leakage）⁴」を警戒したのです。

コンロンが選定した基準は、個人開発者でも行い得るものの、企業アカウントで圧倒的に多く見られる行動でした。以下の5つを組み合わせています。

• セキュリティ資料のダウンロード： SOC 2などのセキュリティ・統制レポートをダウンロードする行動です。Railwayによれば、この行動を取ったユーザーに営業チームが連絡した際の返信率は約50%に達したといいます。個別の行動としては最も強力なシグナルでしたが、これ単体で企業顧客と断定することはありませんでした。
• シート数とその増加傾向： チームメンバーが何人いて、どのように増えているかを確認しました。2025年にシート課金を廃止していたため、追加料金を懸念してチームメンバーの招待をためらう影響を排除できました。
• 認証情報の再設定： 組織のセキュリティポリシーに起因している可能性があると推測しました。認証プロセスの使いづらさに起因する可能性もあるため、追加の検証が必要なシグナルでした。
• 外部・マネージドデータベースへの接続： 実データを接続する行動は、企業アカウントにおいてより頻繁に見られました。
• 特定のデプロイ失敗パターン： 単発のエラーではなく、実際の本番運用環境を構築する過程で直面するトラブルに近いパターンを重視しました。

各行動が企業アカウントでどれほど多く現れるかを重み付けとして用い、アカウントごとのスコアを算出しました。ここで使用された比率は企業と個人の行動の違いを示すものであり、メールを送信した際に売上がどれだけ伸びるかを測定した数値ではありません。

単純な加重和を採用した理由は2点ありました。まず新規登録者の場合、判断材料として確保できる行動データが通常1日分程度に限られるため、複雑なモデルに適用するには限界があったためです。これは会社が過去のイベントを1日分しか保管していなかったという意味ではありません。もう1点は、担当者がスコアの算出根拠を直感的に読み取れる必要があったためです。「セキュリティ資料をダウンロードし、チームメンバーは8名で、DBを接続した」という根拠が分かれば、誰にどのような理由でアプローチすべきかが判断しやすくなります。

支援が必要な行動が現れたタイミングでメールを送る

中程度のスコアのアカウントにはCustomer.ioを通じて自動メールを送信し、高スコアのアカウントには営業担当者やソリューションエンジニアが直接アプローチできるように連携しました。

自動メールは、登録後1日目、3日目、7日目といった機械的な日程設定では送信しませんでした。企業アカウント特有の利用行動が現れた直後に送信するよう設定したのです。

配信条件も厳格に定められています。以下の2点を同時に満たさなければなりません。

• 該当イベントが企業アカウントである可能性と相関していること
• 該当イベントが、ユーザーの手が少し止まっているか、重要な決断を下そうとしているタイミングであること

さらに、メールの内容はミーティングの打診ではありません。エンタープライズプランの売り込みでもありません。実在する営業担当者の名義で送信され、その文面は「このような作業を進めていらっしゃるようですが、何かお手伝いできることはありますか？」という程度にとどめられています。

**初日には約300〜400通を送信し、最初の24時間におけるイベント別の開封率は約50〜70%を記録しました。実際の返信は2件でした。**従来の汎用メールの開封率は約27%でしたが、この2つの数値を単純に施策前後の改善効果として比較することはできません。

Railway自身も、Apple Mailのプライバシー保護機能が開封率をかさ上げしている可能性がある点や、返信の見込みが高い対象をあらかじめ選別していた点を認めています。サンプルサイズも小規模でした。同じ条件のアカウントに対してメールを送らない場合や、汎用メールを送った場合と比較するA/Bテストは、まだ実施されていない段階でした。

私が参考にしたいと感じたのは、その送信条件です。単にDBを接続したすべてのユーザーに送るのではなく、企業顧客である可能性が高く、かつサポートを必要としているタイミングにあるかを併せて見極めていました。開封率の上昇だけで成功と判断するのではなく、その後の返信や商談、契約へとつながるかを検証できるアプローチです。

Oswarldの視点

この事例には、私がGTM戦略を策定する現場で幾度となく目にしてきた失敗パターンが如実に表れていました。

企業の成長が停滞すると、目につきやすいメールの文面やランディングページのデザインばかりに手を加えてしまうケースが見られます。私がGTM戦略の現場で見てきた事例の中には、誰に対して提案すべきかを定めるプロセスにこそ、より本質的な問題が潜んでいたこともありました。**どれほど優れた文章であっても、それを必要としている人に届かなければ効果を発揮できません。**Railwayの取り組みは、表現を推敲する前に、アプローチすべき顧客を十分に掘り起こせているかを再確認させてくれます。

コンロンがLookerとRailwayのそれぞれで直面した差異も興味深い点でした。Lookerの顧客には答えを出したい問いがあったものの、必要なイベントログやデータの蓄積・整理環境が整っていないケースが多かったといいます。一方、Railwayにはデータが存在していたものの、営業チームがアクションを起こせる分析へと結びついていませんでした。前者の場合は収集と整備から、後者の場合は顧客の選定基準から着手する必要がありました。

こうした領域を担う職種こそが、GTMエンジニアです。営業チームの勘だけに頼るのではなく、行動データを比較し、誤ったシグナルを排除し、現場の担当者が納得できるスコアを設計して実行へとつなげる役割です。AIがクエリの作成や分析を支援してくれるようになったとしても、どのような顧客を見つけ出したいのかを定義し、その結果が妥当であるかを検証する責任は、依然として人間に求められていると考えます。

韓国内では、GTM関連の職種に対する関心はまだそれほど高くありません。私はこの領域の重要性が今後さらに増していくと確信しており、発信を続けています。優れた製品を作り上げることと同じくらい、その製品を真に必要とする顧客を見つけ出し、事業の売上へと結びつける取り組みが欠かせないからです。

おわりに

Railwayの事例を自社の業務に取り入れる際は、以下の項目を点検してみるとよいでしょう。

• 登録後の行動履歴をもとに、営業チームがアプローチすべき対象を選定できているか確認する。
• スコアリングを導入している場合、担当者がその算出理由を理解し、判断の誤りを修正できる運用になっているかを見極める。
• メール施策の成果は、開封率だけでなく、返信や商談、契約締結まで追跡する。比較対照群を設けてこそ、配信自体の純粋な効果を測定できる。

オンボーディングメールの文面を修正する前に、そのメールが真にアプローチすべき顧客へ、必要なタイミングで届いているかを確かめてみてください。

読者の皆さんの組織では、ユーザー登録後のどのような行動を手がかりに営業担当者がアプローチしているでしょうか。実際に効果のあった選定基準などがあれば、ぜひコメント欄で教えてください。

参考資料と関連リンク

主要出典

• Des Conlon, “Kill your onboarding: selling to 10,000+ new users a day”, Railway Engineering Blog, 2026年5月6日：PLGからセールス転換に至る全プロセスを実務者の視点から解説しています。

背景知識

• McKinsey, 『From product-led growth to product-led sales: Beyond the PLG hype』, 2023.08.08。製品の利用体験と営業活動を統合的に設計する手法を取り上げた研究です。
• Apollo, 『GTM Engineer: The Revenue Strategist Building Modern Go-to-Market Systems』, 2026.02.25。営業戦略とデータ、自動化業務を結びつけるGTMエンジニアの役割を解説しています。

筆者のアン・グァンソプ（安光涉）は、世宗大学経営学部教授であり、INLEVEL9のリードコンサルタントを務める。大学で経営データ管理やビジネスアナリティクスなど統計・データ分析を教える傍ら、実務の現場ではGTM戦略およびAI戦略コンサルティングを主導し、テクノロジーとビジネスの接点を設計している。AI対話システムの記憶アーキテクチャ（HEMA）研究で学術論文を発表しており、世界のAI論文を毎日キュレーションするDaily Arxivプロジェクトを運営中。高麗大学校技術経営専門大学院修士課程およびKMBA修了。著書に『考えを委ねる人々：ホモ・ブレインレス』がある。

著者 アン・グァンソプ（Oswarld） は世宗大学校 兼任教授、INLEVEL9 戦略コンサルタントです。経歴、研究、著書、最近の活動は著者紹介で更新しています。 最近の活動 · 2026年7月：HEMA-2: A Consolidation-Aware Tri-Memory Architecture with Multi-Channel Scheduling for Lifelong Conversational AI。

각주

1. ICP（Ideal Customer Profile）：理想的な顧客プロファイル。「自社製品を最も有効活用できる顧客はどのような組織か」を定義した基準。企業規模、業界、地域、資金調達ステージなどを組み合わせて策定する。 ↩

2. PLG（Product-Led Growth）：プロダクト主導型成長。製品そのものの利用体験を軸に顧客を獲得・転換していく戦略。営業チームによるサポートを組み合わせる場合もある。Slack、Notion、Figmaなどが代表例。 ↩

3. PQL（Product Qualified Lead）：製品の利用行動に基づいて購買の可能性を評価したリード。マーケティング施策への接触を中心に評価するMQLと区別して用いられる概念。転換率は製品や顧客層、評価基準によって異なる。 ↩

4. ラベル漏れ（Label Leakage）：予測対象である正解ラベルの情報が入力データに混入してしまう現象。検証時には高い精度が出ているように見えても、実際に予測を行う時点でその情報が得られない場合、同様の精度は期待できない。 ↩