Cory Nelson さんは、Harmonya の初代マーケティングディレクターです。Harmonya のマーケティングは、Cory さんがひとりで担っています。Harmonya は、消費財（CPG）ブランドと小売企業向けのプロダクトインテリジェンス企業で、2021年に創業し、ニューヨークとテルアビブを拠点としています。

Cory さんは、ある晩 Brew に登録しました。翌朝には、Thomas と私が Cory さんとミーティングをしていました。Cory さんは、すでに夜のうちに製品をじっくり使い込んでいました。キャンバスには、エージェンティックコマースやプロダクトインテリジェンスをテーマにした Harmonya のメールの下書きが並んでいました。Cory さんがミーティングを予約したのは、製品の案内が必要だったからではなく、さらに先へ進みたかったからです。

ここまでが、私が直接お話しできる部分です。以下の運用の詳細は、2026年8月20日に公開された Noah Adelstein さんによる The GTM Engineer の記事にもとづいています。Brew はこのコミュニティのスポンサーで、Noah さんもエッセイの中でそのことを明記しています。数字は Noah さんの記事によるもので、Cory さんの発言として紹介されています。私たちは、これを Brew の導入事例として計測したわけではありません。

何がうまくいっていなかったのか

Cory さんが Noah さんに語ったところでは、メールに費やしていたのは業務時間の5%ほどで、それでも十分な成果は得られていませんでした。以前の運用は、HubSpot の中で完結していました。テンプレートを開き、リスト全体を選んで、送信する。月1回のニュースレターと、ときどきの製品のお知らせ。誰にでも同じメッセージです。

Noah さんの説明によると、Harmonya が販売している相手は大企業の消費財ブランドで、その規模感を示す例として PepsiCo や Colgate が挙げられています。カテゴリー、役職、購買段階を無視した一斉配信では、そうしたリストを無駄にしてしまいます。Harmonya は、すでに HubSpot の中でこれを解決しようとしていました。フィールドを増やし、リストを増やし、Cory さんの1週間の時間をさらに費やす。ツールは重くなる一方で、メールの精度は上がりませんでした。

何を変えたのか

Cory さんは HubSpot をCRMとしてそのまま使い、その上に Brew を組み合わせて、メールの作成、セグメント化、配信を任せました。メールの大部分は、書体やレイアウトを目で確認できる Brew の画面で作っています。配信、オートメーションの立ち上げ、結果の確認は、MCPを通じて Claude から行っています。

Noah さんは、Harmonya の既存のホワイトペーパー、ブログ記事、動画を使ったシーケンスを紹介しています。その流れを、以下にまとめます。

ステップ	内容
1	クリック不要の短いメール。いくつかの数字を紹介し、ダウンロードはまだ求めない
2	ブログへ誘導するメール
3	読者が論旨に触れたあとで、ホワイトペーパーを届ける
報告されているロジック	ステップの間に待機を入れ、メールへの反応をもとにフォローアップを決める

私がほかの施策にも持ち込みたい教訓は、すべてのコンタクトに同じ紹介文を送るのではなく、メッセージが変わるようなカテゴリーで分けることです。

Cory さんが Noah さんに説明した流れ。外側に Claude、中間に Brew、その下に HubSpot。

Noah さんが報告したこと

Cory さんは Noah さんに、HubSpot でリスト全体に送っていた以前の配信と比べて、開封数とクリック数が倍以上に増えたと話しています。これは、ひとりの担当者が報告した比較として受け止めてください。統制された実験の結果でも、Brew の成果を保証するものでもありません。リスト、オファー、配信のペースが同時に変わっていますし、開封数はメールのプライバシー保護機能によってゆがむことがあります。

Noah さんは、最初のキャンペーンの内容を元の資料と照らし合わせて事実確認したことにも触れています。これは、どんなエージェントのワークフローでも、私なら必ず残したいステップです。

私たちのミーティングでは、取引先のアカウント、役職、そして実際に契約書にサインするのは誰か、といった話をしました。チームが一度も記録したことのない購買委員会の構成を、Brew が用意することはできません。CRMの情報は明示的に管理し、それがメールのワークフローにどう渡っているのかを確認しましょう。

あの朝に聞いたこと

Cory さんは、デモを必要とする見込み客としてやってきたわけではありません。オンボーディングのフローが想定していた以上に、すでに製品を使い込んでいました。そして、そのミーティングのあと、有料の顧客になってくれました。私はそのミーティングのことを、Product Hunt で1位になって学んだことに書いています。私たちのICP（理想の顧客像）が、スライドの上だけの存在ではなくなった最初の瞬間だったからです。

Cory さんが私たちに語ってくれた言葉は、こうです。「Claude がデザインにしたことを、Brew はメールでやってのけました。すでにエージェントを使って仕事をしている自分のやり方に、初めてしっくりきたメールツールです」。Noah さんの記事が公開されたあと、Cory さんは LinkedIn にこう投稿しました。「Brew + Claude は最強の組み合わせ！」

その1時間を、オンボーディングのスライドに費やすことはありませんでした。話したのは、Cory さんにとってすでに販売先となっているアカウントのこと、そして読み手が「ニュースレターのリスト」ではなくカテゴリーマネージャーだったら、シーケンスはどうなるのか、ということです。

私なら取り入れること

報告されているシーケンスからは、対象条件をどう確認していたのかまではわかりません。Brew のイベントの条件では、contact.<name> を使って Brew のコンタクトフィールドの現在の値を読み取れます。ただし、それはフィールドが同期され続けている場合に限られ、CRMに問い合わせるわけではありません。Brew の外にあるアカウントの状態を使うなら、アプリケーション側で対象条件を確認し、新しいイベントを送信しましょう。詳しくはオートメーションのガイドをご覧ください。

すでに信頼しているCRMは、そのまま使い続けましょう。その上にエージェントを組み合わせるのは、チームの誰かが最初の配信を元の資料と照らし合わせて読む場合だけにします。セグメントは、ワークショップで決めたペルソナ名ではなく、文面が変わるフィールドで分けましょう。そして、リストがまだフィールド1つと希望的観測だけなら、エージェントにライフサイクル施策を頼むのはやめておきましょう。

Noah さんのエッセイも、ぜひ読んでみてください。Noah さんは、私たちがどのミーティングで話したよりも長く、Cory さんと向き合っています。Cory さんが何から移行し、その後どんな成果を報告しているのかをまとめた短い版は、Harmonya の導入事例ページでご覧いただけます。

私たちが今ほかのチームに勧めているブリーフの形は、メールエージェントへのブリーフの書き方にまとめています。Claude が送信ボタンを押す場合にも変わらない受信トレイのルールについては、エージェントがメールを送る場合にも変わらないことをご覧ください。