AIツールの社内展開でいちばん難しいのは、最初に導入することではなく、最初に使い始めた部門から他の部門に広がることです。エンジニアリングで成果が出ても、マーケティングやカスタマーサクセスでは「便利だが自分の仕事にどう使うのか」で止まる——多くの会社が経験している壁でしょう。

Anthropicが公開したHubSpotの事例は、その壁をどう越えたかが読み取れる内容になっています。HubSpotはマーケティング・営業・カスタマーサービスの成長を支援するエージェント型カスタマープラットフォームで、スタートアップからエンタープライズまで世界で数十万社の顧客を持つ企業です。

事例ページが挙げる成果は次のとおりです。

なお、これらの数値についてはページ末尾に注記があります。2025年までの特定部門における選定顧客の実装をHubSpotが社内分析したものであり、あくまで例示であって、構成・利用状況・文脈によって結果は変わるとのことです。この種の事例数値を社内で引用する際には、この前提もあわせて共有しておくのが誠実でしょう。

HubSpotの各チームが抱えていたのは、組織を横断する共通の課題でした。時間に対して手作業が多すぎる、というものです。

エンジニアはマイグレーションや保守作業に多くの時間を費やしていました。必要な仕事ですが、顧客価値に直接つながるものではありません。マーケティングチームは終わりのないコンテンツアセットを作り続けながら、キャンペーン間で一貫した文脈を保つことに苦労していました。カスタマーサクセスマネージャーは個別化されたガイダンスを提供したいと考えていましたが、最優先アカウント以上には手が回らなかった。

シニアカスタマーサクセスマネージャーのSarah Caruthers氏の発言(要旨)が、この最後の点を的確に表しています。自分は最高のCSMとして最高の戦略的助言をすることはできる、けれども手取り足取りの支援や進捗の管理が伴わなければ、実行までは見届けられなかった。顧客向けに個別化されたコンテンツを作るには1時間、場合によってはそれ以上かかっていたため、個別化は主要顧客だけに取っておかざるを得ず、担当アカウント全体には適用できなかった、というのが実情でした。

エンジニアリング側の課題は、HubSpotの分散したコードベースを渡り歩くことでした。数千のサービスが日々相互に作用している環境です。大規模なマイグレーションに取り組むときや、馴染みのないコードを理解する必要があるとき、その学習曲線がすべてを遅くしていました。

複数のAIツールを評価した結果、HubSpotはClaudeを自社AIスタックにおける有力な選択肢のひとつと位置付けました。

エンジニアリングにとって決定的だったのは、Claude CodeのMCP(Model Context Protocol)対応でした。これによってClaudeをHubSpotの既存サービスや社内システムに直接つなげられるようになったからです。Developer Experience AIチームのエンジニアリングリード、Francesco Signoretti氏は、Claude CodeがMCPをファーストクラスの機能としてサポートしたときに試してみることに興奮した、と述べています(要旨)。HubSpotの社員が日々任されている現実の問題を解くという点で、当時開発中あるいは試用中だった他のツールと比べて優れた仕事をした、という評価です。

HubSpotは実際のHubSpot業務から取ったエンジニアリングタスク群を使って社内ベンチマークを実施しています。その結果、Claudeは完成したソリューションに到達するまでに必要な人間の介入が一貫して最も少なかったというのが選定の根拠になりました。

Signoretti氏はモデル世代による違いにも触れています(要旨)。Claude Sonnet 4.5は4つの情報を同時に尋ねてくるのを見た一方、Claude Sonnet 4はもっと逐次的に情報を求めてきた。これによって開発プロセスをさらに速められた、という指摘です。エージェントの性能を「往復回数の少なさ」で評価しているのは、実務的で参考になる視点です。

マーケティングとカスタマーサクセスにとって、採用の触媒になったのはClaudeプロジェクトでした。最高マーケティング責任者のKipp Bodnar氏は、誰かが適切な文脈を見つけて強い指示を備えたプロジェクトを作るという難しい仕事を一度やり終えると、あとは自然に使われて定着していく、と述べています(要旨)。そうしたプロジェクトが、他のチームが必要としていた周辺的なユースケースまでカバーした、と。

個人の使い方ではなく「よくできたプロジェクトが1つあること」が普及の起点になったという観察は、社内展開に悩む組織にとって最も持ち帰る価値のある部分かもしれません。

現在、Claudeは複数のチームを支えています。

エンジニアリングはClaude Codeを開発業務に使い、MCPを通じてHubSpotのインフラに接続しています。2025年のリブランディングの際には、本来なら数か月の手作業を要したはずのフロントエンドのマイグレーションをClaude Codeで加速させました。新任エンジニアはこれまでより早く意味のあるコードを本番に出せるようになっており、Signoretti氏は、最近チームに加わったインターンが、自分が4年前にHubSpotに入ったときと比べてはるかに早く本番へ更新を出した、と述べています(要旨)。

マーケティングはClaudeプロジェクトとアーティファクトを使ってキャンペーンの文脈を集約し、コンテンツ制作を速めています。Bodnar氏の言葉として印象的なのは、Claudeについて気に入っている点のひとつは「とても良いテイストを持っていること」であり、マーケティングはテイストがすべてだ、というものです(要旨)。Claudeのモデルはコードであれ文章であれ、書くことに常に強かった、とも付け加えています。

カスタマーサクセスは顧客との会話の準備と、個別化されたフォローアップの生成にClaudeを使っています。かつて個別化されたフォローアップに何時間もかけていたマネージャーが、いまは数分で生成できるようになり、その分の時間がより深い戦略的な会話に回っている。Caruthers氏は、Claudeが自分に顧客のより戦略的なパートナーであるための支援と時間を与えてくれた結果、顧客から「これまで以上に意味のある会話になっている」と言われるようになった、と述べています(要旨)。

エンジニアにとっての変化は生産性以上のものだとSignoretti氏は言います(要旨)。Claude Codeは自分をより良いエンジニアにしてくれた。AIが進化し続けるにつれ、自分の役割はますます創造的になっていくと予想している——システム設計や、開発したい理想のユーザーワークフローを理解することに、多くの時間が使えるようになる、と。

将来について、HubSpotはClaudeのモデルをビジネスの運営方法そのものの基盤になるものと見ています。Caruthers氏は、Claudeは小規模事業のオーナーから成長中の組織、さらにその先まで、必要とする人にとって大きな支えになりうる、と述べています(要旨)。

この事例を、本ブログで既に取り上げた他の事例と並べてみると輪郭がはっきりします。Vega Securityは調査業務そのものをエージェント化した事例、Leagueは規制産業でのAIネイティブ転換の事例、そしてDoorDash・Spotify・RampのOffice Hours対談は開発組織のあり方の変化を語ったものでした。HubSpotの事例が加えているのは、同じ製品が部門ごとに違う入口(エンジニアリングはMCP、マーケティングはプロジェクト、CSは個別化)から入り、それぞれの言葉で定着していくという横方向の広がりの記録です。

日本企業に置き換えて考えると、参考になる点は3つに絞れます。第一に、選定の物差しを「賢さ」ではなく人間の介入回数の少なさに置いたこと。第二に、社内展開の単位を個人のプロンプトではなく文脈と指示が詰まったプロジェクトにしたこと。第三に、既存システムへの接続手段(HubSpotの場合はMCP)を確保することが、エンジニアリング部門での採用を決めたこと。ツールを増やすより、いまあるシステムとどうつなぐかが先だという順番は、SaaSが多層に積み上がった日本の企業環境でこそ効いてきます。

自社で同じことを始めるなら、まずは部門を1つ選び、その部門の「毎回同じ文脈を集め直している仕事」をひとつプロジェクト化してみるところからでしょう。うまくいったプロジェクトが1つできれば、あとは横に広がる——それがHubSpotの経験でした。

INNOOV株式会社について

この記事は、AtlassianやIntercomなどのSaaS導入支援と、AIを活用した業務プロセス改善を行うINNOOV株式会社がお届けしました。「自社でもこんな仕組みを作ってみたい」「ツール導入を相談したい」という方は、お気軽にお問い合わせください。

▶ INNOOV株式会社 公式サイト

参考文献HubSpot Claude Platform (API) case study | Claude by Anthropic