AIエージェントを立ち上げて最初に届く報告は、多くの場合こうです。「回答が当たり障りのない内容になる」「自社の製品名を間違える」「顧客に使えないトーンで書いてくる」。指示文（Instructions）を何度書き直しても改善しない。
原因は指示文ではありません。エージェントが自社について何も知らないまま動いているからです。優秀な中途社員を採用しても、事業内容・製品ラインナップ・顧客像・社内用語を一切伝えなければ、当たり障りのない仕事しかできません。AIエージェントも同じです。
HubSpotはこの前提情報を、ContextとKnowledge Vaultsという2つの仕組みで扱います。本記事では、HubSpot公式ナレッジベースの記載に基づき、両者の違いと、大企業で誰がどこを管理すべきかを整理します。
目次
混同されやすい2つですが、役割は明確に分かれています。適用範囲と設定方法の2軸で見ると理解しやすくなります。
| 観点 | Context | Knowledge Vaults |
|---|---|---|
| 内容 | ビジネスに関する基本情報 | 特定のユースケース向けの情報セット |
| 適用範囲 | HubSpotの複数のAIツール全体に自動適用 | プロジェクトまたはエージェントに手動で追加 |
| 設定の手間 | 一度設定すれば全体に効く | 用途ごとに用意する |
| 典型例 | 会社概要、ブランドのトーン、ICP、ペルソナ | 特定製品の仕様書PDF、キャンペーンの対象リスト |
2行目が本質的な違いです。Contextは「全社共通の前提」であり、設定すればすべてのAIツールに自動的に適用されます。Knowledge Vaultsは「この用途にはこの資料」という個別の紐づけです。
この構造を踏まえると、着手の順序が決まります。Contextを整えないままKnowledge Vaultsを個別に作り込むと、同じ前提情報を用途ごとに重複して書くことになり、更新が追いつかなくなります。まず共通部分をContextに集約してください。
設定項目は4つのタブに分かれています。どこに何を書くかを把握しておくと、社内の担当分担が決めやすくなります。
| タブ | 設定項目 |
|---|---|
| Business | ブランドキット（声・トーン・ガイドライン）、企業の識別と分類、所在地と規模、ビジネスプロフィール、市場とエコシステムの文脈、テクノロジースタック、製品・サービス |
| Customers | 理想顧客プロフィール（ICP）、ペルソナ |
| Team & Processes | ユーザープロフィール、メールパーソナリティ（トーン・スタイル・声） |
| Custom | 自由形式テキストまたはファイルのアップロード |
この一覧で注目すべきは、CustomersタブにICPとペルソナが独立した項目として用意されている点です。多くの企業でICPの定義は営業資料やマーケティングの企画書の中に散在しています。それをAIが参照できる場所に一元化すること自体が、社内の共通言語を作る作業になります。
設定はAgent Hubの［Context］タブから行い、各項目の「編集」または「追加」で入力します。対応範囲は全製品・全プランとされていますが、Knowledge Vaultsを含む一部の機能には別の条件があります。
両者ともトーンを扱うため重複して見えますが、適用対象が違います。
ブランドキットは会社としての声です。ウェブサイト、ブログ、公式なコンテンツに適用される全社共通の規範を書きます。一方メールパーソナリティは個人の書き方です。同じ会社でも、営業担当ごとに顧客との距離感や文体は異なります。この個人差を保持する仕組みです。
実務では、この2つの関係を明示しておく必要があります。「会社の規範は守るが、個人の文体は残す」という運用にするなら、ブランドキットには禁止事項と必須事項を書き、表現の幅はメールパーソナリティに委ねます。ブランドキットに細かい文体規則を書き込むと、個人差が消えてすべてのメールが同じ調子になり、顧客に違和感を与えます。企業としての声の設計については100式の考え方も参考になります。
見落とされやすい項目です。自社が使っているツール群をContextに書いておくと、AIの回答が自社の環境を前提としたものになります。
たとえば「リードを営業に引き渡す仕組みを作りたい」という相談に対し、テクノロジースタックが未設定なら一般論が返ります。設定されていれば、実際に使っているツールの組み合わせを前提とした回答になります。相談のたびに前提を説明し直す手間が消えます。
Knowledge Vaultsは、エージェントが回答の根拠として参照する情報の置き場です。公開されている情報によれば、ナレッジベースやCRMなどのソースからデータを取得して問いに答える、エージェントの中核的な参照先として機能します。
ここで重要なのは、入れるべきものを絞ることです。「関連しそうな資料をすべて入れる」という運用は、精度を下げます。矛盾する情報が複数含まれていると、エージェントはどちらを採用すべきか判断できません。
判断基準は「その情報が唯一の正であるか」です。同じ内容について複数のバージョンが存在する資料は、統合してから入れてください。
| 種類 | 判断 | 理由 |
|---|---|---|
| 公開している製品仕様・FAQ | 入れる | 顧客向けの正であり、更新の責任者が明確 |
| 価格表（最新版） | 入れる。ただし更新手順を決める | 古い価格を回答すると顧客対応上の事故になる |
| 営業の提案資料（複数版） | 統合してから入れる | 版が複数あると矛盾する回答が出る |
| 社内の議事録・検討メモ | 入れない | 検討途中の案が確定情報として回答される |
| 個人が作成した手順書 | 正規化してから入れる | 属人的な例外運用が全体に広がる |
4行目が最も事故が起きやすい項目です。議事録には「〜という案もある」「〜は検討中」という記述が含まれます。エージェントはこの前置きを落として断定的に回答することがあります。検討段階の情報は入れないという原則を、運用ルールとして明文化してください。
2026年に入って加わった変化です。公開されているアップデート情報によれば、Knowledge Vaultsはカスタムオブジェクトの接続に対応しています。
これは大企業にとって実質的な意味を持ちます。標準オブジェクトだけでは表現できない自社固有のデータ——製造業の装置情報、契約単位の履行状況、案件と引合の関係——をエージェントが参照できるようになります。
ただし前提があります。そのカスタムオブジェクトのデータが実際に更新されていることです。作られたが入力されていないオブジェクトを接続しても、エージェントは空の情報を参照するだけです。データモデルの設計についてはHubSpotカスタムオブジェクトの設計判断と作らない基準で整理しています。
Contextは全AIツールに自動適用されるため、変更の影響範囲が広くなります。したがって編集権限の設計が統制上の論点になります。
公式ナレッジベースには、権限の区分が記載されています。スーパー管理者とパートナー管理者はほぼすべての項目を編集できます。案件創出エージェントの管理者は、Businessタブの「製品・サービス」のみ編集できます。すべてのユーザーは、メールパーソナリティとユーザープロフィールを作成・更新できますが、メールパーソナリティは作成者のみが編集・削除できます。
この区分は、実務の分担とほぼ対応します。整理すると次のようになります。
| 領域 | 管理すべき部門 | 更新の頻度 |
|---|---|---|
| ブランドキット（声・トーン） | 広報・ブランド担当 | 年次または方針変更時 |
| 製品・サービス | 商品企画・マーケティング | 製品リリースのたび |
| ICP・ペルソナ | マーケティング・経営企画 | 半期または戦略見直し時 |
| テクノロジースタック | 情報システム | ツール導入・廃止のたび |
| メールパーソナリティ | 各担当者本人 | 随時 |
この表を作ることが、実は最初の作業です。項目ごとに「誰が責任を持つか」が決まっていないと、Contextは初期設定のまま放置されます。とくに2行目の製品・サービスは、更新が止まると顧客への誤案内に直結します。製品リリースのチェックリストにContextの更新を含めてください。
放置の影響は静かに広がります。Contextは全AIツールに自動適用されるため、古い情報が全社の出力に反映され続けます。
典型的な例が製品名の改称です。HubSpot自身も2026年にOperations HubをData Hubへ、Breeze AgentsをAgent Hubへと改称しています。自社の製品名やサービス名が変わったとき、Contextを更新しなければ、エージェントは旧称で顧客に案内します。顧客対応エージェントを稼働させている場合、この誤りは顧客に直接届きます。
したがって、Contextの管理は「設定作業」ではなく「継続的な運用」として扱う必要があります。四半期ごとの棚卸しを定例業務に組み込むのが実務的です。
すべてを一度に埋める必要はありません。効果が出やすい順序があります。
最初に着手すべきはBusinessタブの製品・サービスです。エージェントが最も頻繁に参照し、誤りが顧客に届きやすい項目です。次にブランドキットのトーンを設定します。これで出力の文体が安定します。3番目にCustomersタブのICPとペルソナを入れ、提案内容の妥当性を上げます。テクノロジースタックとCustomタブは、必要が生じてから追加すれば十分です。
この順序の根拠は、誤りの影響の大きさです。製品情報の誤りは顧客対応の事故になりますが、テクノロジースタックの未設定は回答が一般論になるだけです。影響の大きい順に埋めるのが合理的です。
株式会社100がAIエージェントの運用設計を支援する際も、エージェントの構築より先にこのContext整備に着手します。ここを飛ばして構築を進めると、出力の品質が上がらず、「AIは使えない」という評価が組織に定着してしまいます。一度この評価が付くと、覆すのに数倍の労力がかかります。
公正に整理します。前提情報の整備は効果が大きい一方、それだけで解決しない問題もあります。
| 観点 | 効果 | 限界 |
|---|---|---|
| 出力の一貫性 | 全AIツールで前提が揃い、文体と用語が安定する | 個人差を消しすぎると不自然になる |
| 作業量 | 一度設定すれば全体に効く | 更新責任者を決めないと放置される |
| 費用 | Context自体の設定に追加費用は発生しない | エージェントの実行にはクレジットが必要 |
| 精度 | 自社固有の情報を前提とした回答になる | CRMのデータ品質が低ければ改善しない |
| 統制 | 権限区分で編集を制限できる | 影響範囲が全社なので変更手順の設計が必要 |
4行目が最終的な制約です。Contextは前提情報を与えますが、日々の商談記録や顧客対応の履歴はCRMのデータそのものです。商談の経緯がメールの本文にしか残っていなければ、Contextをどれだけ整えても要約は作れません。AI活用の議論がデータ基盤の整備に行き着くのは、この理由によります。クレジットの消費構造はHubSpotクレジットとは？料金の仕組みと消費レートを徹底解説で解説しています。
公式ナレッジベースには、対応範囲として全製品・全プランと記載されています。ただしKnowledge Vaultsを含む一部の機能には別の条件があるとされているため、利用可否は自社のプランで確認してください。
不要にはなりません。Contextは「自社について何を知っているか」であり、Instructionsは「このタスクで何をするか」です。役割が異なります。ただしContextが整っていれば、Instructionsに自社説明を書く必要がなくなり、指示文は短く保守しやすくなります。
参照した公式ナレッジベースの記載には、受け入れ形式・容量制限の明記を確認できませんでした。大量の資料を投入する計画がある場合は、実装前に公式ドキュメントの専用ページおよび営業担当者にご確認ください。
できます。メールパーソナリティはユーザー単位で設定でき、作成者のみが編集・削除できるとされています。会社としての規範はブランドキットに、個人の文体はメールパーソナリティに分けて設定してください。
推奨しません。検討途中の案が確定情報として回答される事故が起きます。確定した内容を正式な文書として整理してから投入してください。
過去に生成された内容が書き換わることはありません。変更後の生成に適用されます。ただし変更の影響は全AIツールに及ぶため、大きな変更を行う際は業務時間外に実施し、主要な用途で出力を確認してから展開することをおすすめします。
項目ごとに責任部門を決め、その担当者に必要な範囲の権限を与えてください。全社に開放すると、更新の履歴が追えなくなります。逆に情報システム部門だけに閉じると、製品情報の更新が滞ります。項目単位の分担が現実的です。
参照元を確認してください。HubSpotのアシスタントは回答の根拠となる参照元を提示します。多くの場合、Contextの不足ではなくCRM側のデータが古い、あるいは必要な情報がレコードに記録されていないことが原因です。
本記事はHubSpot公式ナレッジベースおよび製品ページの公開情報（2026年9月1日取得時点）に基づいて作成しています。Knowledge Vaultsのカスタムオブジェクト対応については公開されているアップデート情報に基づく記述です。Agent Hubはパブリックベータであり、仕様・権限区分・エディション要件は変更される可能性があります。