生成AIの導入プロジェクトについて、厳しい数値が示されています。企業の生成AIパイロットのうち、測定可能な成果に届くのは5%とされています（株式会社100プレスリリース。同リリース上で調査名は明示されていません）。一方でエージェント型AIへの支出は、2025年の864億ドルから2026年に2,065億ドル、2027年に3,763億ドルへ拡大するとGartnerが予測しています（同リリースが引用するGartner「Gartner Says Autonomous Business and AI Layoffs May Create Budget Room, but Do Not Deliver Returns」2026年5月5日）。

投資は増えるが成功率は低い。この構造は、CRM導入の初期に起きたことの再演です。本記事では、2026年7月23日にパブリックベータで公開されたAgent Hubを導入する際に、何が失敗を招くのかを具体的に整理します。

なぜAIエージェントの導入は失敗するのか？

失敗の定義を先に決める

「失敗」の定義が曖昧なままでは議論が進みません。実務上、以下のいずれかに該当すれば失敗と考えるべきです。

• 稼働させたが、現場が使っていない（実行回数が想定を大きく下回る）
• 使われているが、削減効果を数値で示せない
• 出力の誤りが業務に影響し、確認工数が増えた
• クレジット消費が想定を超え、費用対効果が説明できない

いずれも技術的な不具合ではありません。すべて設計と運用の問題です。

共通点1：CRMデータの定義が部門ごとに違う

なぜこれが致命的なのか

AIエージェントはCRMデータを前提に判断します。Agent BuilderのActionsにはCRMレコードの読み取りと書き込みが含まれ、案件創出エージェントは過去1年間のフォーム送信・ページビュー・通話・ミーティング・ノート・メール開封を参照します。

ここで問題になるのは、データの「量」ではなく「定義」です。

先にやるべきこと

1. データ品質ツール（ベータ）で重複件数・フォーマット提案・未入力プロパティを数値化する
2. 重複レコードを統合し、電話番号や会社名の表記を統一する
3. 取引ステージ・リードステータス・解約理由の定義を部門間で合意し、文書化する
4. 週次のデータ品質ダイジェストを有効にして、劣化を継続監視する
5. 外部システムとの同期がある場合は、データスタジオでの同期設計を見直し、汚れたデータの再流入を止める

3番目が最も時間を要します。ツールで解決できない部門間の調整だからです。営業・マーケティング・カスタマーサクセス・IT部門が互いに不干渉の状態にある組織では、この調整を担う推進機能の不在そのものが最大のボトルネックになります。

共通点2：工程別の工数を計測していない

効果を証明できない導入は必ず止まる

「AIで効率化した」と報告するには、導入前の工数が分かっている必要があります。ところが多くの組織で、商談前準備に何分かかっているか、CRM入力に何時間使っているかを計測していません。

この状態で導入すると、次のような会話になります。「便利になった気はする」「でも人員は減らせない」「効果が見えないので予算は増やせない」。推進役が社内の抵抗勢力を説得するロジックを持てず、プロジェクトが停滞します。

計測の実務

全数調査は不要です。以下の粒度で十分機能します。

• 対象工程を5〜8個に絞る（商談準備、CRM入力、問い合わせ一次対応など）
• 各工程について、担当者3〜5名に2週間だけ所要時間を記録してもらう
• 月間発生件数を掛けて、部門全体の工数を推定する

この推定値が「導入前」の基準線になります。基準線がなければ、どれだけ成果が出ても証明できません。

共通点3：書き込み権限を最初から開放する

誤りが波及する構造

Agent Hubの設計思想は、複数エージェントが共有CRMコンテキスト上で動くことです。HubSpotのChief Product and Technology OfficerであるDuncan Lennox氏は、発表時に「問題は単一エージェントの管理ではなく、複数エージェント時の分断である」と述べています。

この共有構造は利点ですが、同時にリスクでもあります。あるエージェントが誤った値をCRMに書き込むと、その値を参照する他のエージェント、ワークフロー、レポートすべてに誤りが伝播します。

HubSpotのMCPサーバーのドキュメントでも、LLMは誤った出力を生成し得るため、アカウントを変更する権限の利用時には常に確認が必要であり、本番環境以外での試験運用が推奨される旨が明記されています。

段階的な開放が唯一の安全策

Agent Builderには段階的な承認オプションがあり、どのアクションを自動実行させるかを制御できます。この機能を使わずに全自動から始める合理的な理由はありません。

共通点4：エージェントのオーナーが不在

エージェントは作った瞬間から劣化する

製品名が変わる。価格が変わる。組織が変わる。競合が変わる。エージェントのInstructionsとKnowledgeは、これらの変化に自動追随しません。

実例として、HubSpot自身が旧Operations HubをData Hubへ改称しており、AIアシスタントの名称も現在は「Breeze Assistant」に統一されています（「Breeze Copilot」は現行の公式ドキュメントには見当たりません）。こうした改称を反映しないままエージェントを動かせば、廃止済みの名称で顧客に案内することになります。

決めるべき3つの役割

• エージェントオーナー：Instructions・Knowledgeの更新責任者。エージェント1つに必ず1名
• ナレッジソース管理者：顧客対応エージェントが参照するコンテンツの鮮度管理。廃止済みページの除外を含む
• クレジット管理者：消費量の監視と、月間実行上限の調整

あわせて、四半期ごとの棚卸しをカレンダーに登録してください。「気づいたら直す」という運用は、実際には誰も直さないことを意味します。

権限モデルを設計に組み込む

Agent Builderでは、エージェントごとに「Assign access」でアクセス権限を設定できます。所有者とスーパー管理者のみ編集・実行、所有者とスーパー管理者のみ編集で全員実行可、全員編集・実行可、そしてチーム・ユーザー単位でRun / Run & editを付与するCustomの4系統です。

1,000名規模の組織では、この権限モデルをそのままガバナンス文書に落とせます。「誰がエージェントを作れるか」を無制限にすると、半年後には用途不明なエージェントが並び、誰も統制できない状態になります。

共通点5：クレジット消費の統制設計がない

単価は低いが総額は膨らむ

主要エージェントのクレジットレートは以下のとおりです（1クレジット＝約0.01ドル）。

単価だけを見ると安価ですが、対象を絞らずに実行すると総額が跳ね上がります。たとえば1万件のコンタクトに3つの問いを投げると、3万回答×10クレジット＝30万クレジット（約3,000ドル相当）です。

統制の3手段

1. 月間実行上限を設定する：Agent Builderの設定画面でエージェントごとに指定できます
2. 実行対象を絞る：ICP条件、接点の有無、直近の活動期間などでフィルタを設ける
3. Run historyで推定消費量を定期確認する：公式ドキュメントには実際のコストが変動する可能性があると注記されています

加えて重要なのが、クレジットプールは他のBreeze・AI機能と共有される点です。マーケティング部門が大量消費すると営業側のエージェントに影響します。部門横断での配分方針を先に決めるべきです。詳細レートはHubSpot製品・サービスカタログで確認してください。

成功する組織は何を先にやっているか？

合計すると3〜4ヶ月です。「数分で設定できる」という製品説明は事実ですが、成果を出すまでの期間はこの規模になります。この見立てを経営層と共有せずに始めると、2ヶ月目に「まだ成果が出ないのか」という圧力を受けて設計が飛ばされます。

メリットとデメリットを公正に評価すると？

よくある質問（FAQ）

Agent Hub導入で最も多い失敗は何ですか？

CRMデータの定義が部門ごとに異なる状態で稼働させることです。取引ステージやリードステータスの定義が統一されていないと、エージェントは誤った前提で判断し、その結果をCRMに書き込みます。共有コンテキスト構造のため、誤りが他のエージェントやレポートにも波及します。

導入前にデータをどこまで整えるべきですか？

全社の全プロパティを完璧にする必要はありません。対象業務が参照するプロパティに限定して、重複の統合、表記の統一、定義の合意を行うことが現実的です。データ品質ツールで現状を数値化し、優先順位を決めてください。

どのくらいの期間を見込むべきですか？

工数計測、データ整備、定義合意、権限設計、検証、カスタム構築、ワークフロー統合を順に進めると、成果が見えるまで3〜4ヶ月が目安です。設定作業自体は数時間ですが、設計と合意形成にこの期間を要します。

費用が想定を超えないようにするには？

Agent Builderの設定画面で月間実行上限を指定し、実行対象をICP条件や接点の有無で絞り、Run historyで推定消費量を定期確認してください。またクレジットプールは他のBreeze・AI機能と共有されるため、部門横断の配分方針を先に決める必要があります。

書き込み権限はいつ開放すべきですか？

まず読み取りと出力生成のみに限定し、50件以上の出力を検証して誤りが許容範囲であることを確認してから、低リスクな操作を追加します。CRMプロパティの更新許可は、更新対象を限定し変更履歴の監査体制を整えてからにしてください。

現場の抵抗にはどう対処すべきですか？

削減時間を数値で示すことです。そのために導入前の工数計測が不可欠です。「商談準備30分→5分」という形で工程単位に示せれば、抵抗は大きく減ります。逆に「便利になる」という定性的な訴えだけでは現状維持バイアスを超えられません。

エージェントを何個作るのが適切ですか？

個数は目標ではありません。むしろ「オーナーが決まっていないエージェントを作らない」というルールのほうが重要です。四半期ごとに棚卸しし、実行回数が想定を大きく下回るエージェントは統合または削除してください。Agent Hubの Agents タブから削除・クローンが可能です。

ベータ版のうちに導入すべきですか？

検証目的の導入は合理的です。無料アクセス期間（顧客対応エージェントは14日間、案件創出エージェントは14日間）とテスト実行の無償枠を使えば、コストをかけずに自社適合性を判断できます。ただし全社展開の判断は、仕様が安定してからでも遅くありません。

すでに他社のAIツールを導入しています。併存できますか？

可能です。Agent BuilderのActionsにはMCP（Model Context Protocol）経由の外部システム連携が用意されており、HubSpot外のシステムを操作対象にできます。ただし複数のAI基盤を並行運用すると、どちらが真の情報源かが曖昧になります。データの正となる場所を先に決めてください。

社内に推進リソースがない場合はどうすればよいですか？

部門間の定義合意と現場への説明・トレーニングは、外部に委託できる領域です。株式会社100の100 Agent Worksでは、ヒアリングと業務棚卸しから設計・実装・テスト、稼働後の定期チューニングまでを支援しています。

まとめ：失敗の原因は設定画面の外側にある

Agent Hubは、AIエージェントの構築・管理コストを大幅に下げました。しかし下がったのは実装コストだけです。データ定義の統一、工数の計測、権限の設計、オーナーの任命、クレジットの統制——これらはいずれも設定画面の外側にあり、自社が引き受けるしかない作業です。

生成AIパイロットのうち測定可能な成果に届くのが5%という数字は、技術の限界ではなく設計の不在を示しています。逆に言えば、この5点を先に整えた組織は、残りの95%とは異なる結果を得られます。

株式会社100は、世界上位1%・日本唯一のHubSpot認定エリートパートナーとして、400社以上のCRM導入を支援してきました。部門横断の定義合意という泥臭い調整ごと引き受け、AIエージェントの運用設計を伴走します。

あわせて読みたい関連記事

• データエージェントとは？CRMデータクレンジングへの活用法
• Agent Builderの使い方｜自然言語でカスタムAIエージェントを作る手順
• HubSpot Agent Hub導入支援｜100 Agent WorksのAIエージェント運用設計

本記事はHubSpot公式サイト・公式ナレッジベースの公開情報（2026年8月12日取得時点）および株式会社100の公開プレスリリースに基づいて作成しています。市場予測はGartner（2026年5月5日）を引用元とする数値です。生成AIパイロットに関する数値は同プレスリリースの記載に基づきますが、リリース上で調査名は明示されていません。Agent Hubはパブリックベータであり、仕様・エディション要件・クレジットレートは変更される可能性があります。