Spekitで営業AIの答えを古くしない方法｜元ネタの持ち主を決める

「営業がAIに聞いたら、去年の価格表のまま答えていた」「資料は直したのに、AIの答えだけが古いまま残っている」——営業の現場にAIの回答を入れた会社の営業企画やマーケの担当から、こうした声が出始めています。営業支援の基盤 Spekit が公式ブログで紹介した調査では、提供元の調査で、営業支援の担当者の48.8%が「手元の内容の4割超に更新が必要」と答えています。古くなった情報は、どの会社でも思った以上に残っているということです。答えが古いのはAIの性能の問題ではありません。AIが読みに行く元ネタに、持ち主と見直しの周期が決まっていないことが原因です。この記事では、営業の画面の中でAIが答える Spekit を例に、元ネタの持ち主の決め方、見直しの周期、古くなった情報の止め方を整理します。

Spekit は、営業が使う画面の中に社内の知識を届ける米国の基盤

Spekit は、営業の担当者がふだん使う画面の中で、社内の知識や資料、助言を届ける営業支援の基盤です。2026年10月時点の公式サイトは、自らを「AIを前提にした営業支援の基盤」と呼び、統制された知識の置き場と、その知識をもとに答えるAIアシスタントを中心に据えています。

AIアシスタントの名前は AI Sidekick です。公式の説明では、Chrome の拡張機能としてどのタブでも動き、Salesforce、Gmail、Gong、Slack の画面の中に出てきます。営業が顧客管理の画面で商談を開いたまま質問すると、社内の知識から答えや資料、次の一手の案を返す、という使い方です。

答えの元になる知識の置き場は、GTM Knowledge Engine と呼ばれています。公式の説明では「承認され、版を持ち、劣化を確かめた知識」を一か所に置き、AIの出力はその知識にもとづく、とされています。答えの質は、この置き場に何が入っていて、どれだけ新しいかで決まる、というのが製品の考え方です。

営業支援という取り組みの全体像や、資料の一元化の進め方は、セールスイネーブルメントを扱った記事に譲ります。本稿は、AIが答えるときの元ネタの鮮度に絞ります。

作っている会社と、国内でまだ知られていない理由

公式サイトの記載では、Spekit は2018年にメラニー・フェレイ氏が創業した会社で、同氏が最高経営責任者を務めています。報道発表は米国コロラド州デンバーの日付で出されています。2025年11月には、Gartner の営業支援の基盤の評価で「ビジョナリー」に位置づけられたと提供元が発表しています。

国内でまだ知られていない理由は、確かめた範囲で三つあります。一つ目は、画面・資料・ヘルプがすべて英語で、日本語の画面や日本語での回答に対応するかを公式の資料で確かめられなかったことです。

二つ目は、Salesforce との深い連携を前提にした製品であることです。公式サイトは Salesforce との双方向の連携を最も深い連携と説明しており、米国の営業組織の働き方に合わせた作りだと読めます。三つ目は、営業支援の専任の担当を置く会社が国内ではまだ多くないことで、この種の製品の買い手が育っていないことも理由に挙げられます。

国内の会社が検討するなら、日本語の知識を置いたときに検索と回答がどこまで正しく動くかを、最初に試して確かめる項目として扱う必要があります。本稿では、その確認が済んだ前提で、答えを古くしない運用を考えます。

2026年に出た機能と、その提供の状態

答えの元ネタに関わる機能は、2026年6月16日の報道発表と、同じ時期の公式の発表ページ、その後の公式ブログで説明されています。提供の状態が機能ごとに違うため、表に分けて整理します。

機能	中身（公式で確かめた範囲）	提供の状態
GTM Knowledge Engine 2.0	接続した道具はすべて一つの統制された知識の置き場を読み、作ったものは担当者が送る前に統制を通って戻る	2026年6月16日に発表
コンテンツの統制	鮮度の点数、作成からの経過の分布、更新・統合・アーカイブ・削除のAIによる推奨	6月の発表ページで案内
矛盾と劣化の検出	古くなったおそれのある内容や、新しい内容と食い違う内容に印を付け、見直すべき一覧を出す	2026年8月の公式ブログで説明
AI Content Builder と Brand Studio	承認された知識と商談の情報から、競合の対策表や営業の手引きの下書きを作る	一般提供
MCP サーバー	社内の知識を Claude・ChatGPT・Copilot・Gemini などのAIからも読めるようにする	ベータ
ダイナミックコンテンツ	元の事業が変わると知識が自ら更新される	ロードマップ（未提供）

押さえておきたいのは、外のAIにつなぐ仕組みはベータで、知識が自ら更新される機能はまだ提供されていないことです。つまり2026年10月時点では、知識を新しく保つのは、AIの推奨を見て人が直す運用だということになります。

このほか、2025年11月には商談の会話を記録する Gong との連携を広げ、会話の要約や次の一手を Sidekick の中で見られるようにしたと発表されています。2026年10月20日には、商談の練習をAIと行う機能の提供も公式ブログで告知されましたが、商談の練習は本稿の主題ではないため、AIとのロールプレイを扱った記事に譲ります。

営業の画面の中でAIが答えると、何が変わるか

以前は、営業が資料や手順を探すとき、共有フォルダや社内の掲示板を開き、検索して、見つけたものを自分で読む必要がありました。古い資料に行き当たっても、更新日やファイル名から古いと気づける余地がありました。

営業の画面の中でAIが答えるようになると、営業は資料そのものではなく、AIがまとめた答えを受け取ります。顧客管理の画面から目を離さずに済むので、探す手間は大きく減ります。その一方で、答えの元になった資料がいつのものかが、営業から見えにくくなるという変化が起きます。

AIの答えは、古い資料にもとづいていても、新しい資料にもとづいていても、同じように整った文章で返ってきます。文章の整い方からは、元ネタの新しさが分からないのです。営業は答えを信じて顧客に伝えるので、古い情報がそのまま顧客に届きます。

もう一つの変化は、答えの届く範囲です。AIが答えると、一つの古い資料が、それを聞いた営業全員の答えに一度に混ざります。人が資料を探していた頃は、古い資料に当たる営業は一部でしたが、AIを通すと影響が全員に広がります。元ネタの管理の重みが、それだけ増すということです。

古い答えの原因は、AIではなく元ネタにある

Spekit の最高経営責任者は、2026年6月の報道発表で、質の悪い内容を入れればAIも質の悪い答えを返す、という趣旨を述べています。製品の発表でありながら、答えの質はAIのモデルではなく知識の側で決まる、と言い切っているのが特徴です。

古い答えが生まれる元ネタの状態は、おおむね三つに分けられます。一つは、新しい資料が作られたのに、古い資料が消されずに残っている状態です。AIは両方を読み、古いほうを使って答えることがあります。

二つ目は、資料の中の一部だけが古くなっている状態です。製品の説明は正しくても、そこに書かれた価格や対応している連携先だけが変わっている、という場合です。資料の一部だけが古いと、見直しのときにも見落とされやすいのが厄介な点です。

三つ目は、誰の持ち物でもない資料です。作った人が異動したり退職したりして、直す責任を持つ人がいなくなった資料は、内容が変わっても誰も直しません。持ち主のいない資料が、古い答えのいちばん大きな出どころになります。次の節から、この三つを順に塞いでいきます。

答えの元ネタを「承認済み」に限る意味

Spekit の公式ブログは、AIの道具が社内の資料の置き場につながると、その置き場の権限をそのまま引き継ぐことが多いと指摘し、「見られることと、承認されていることは違う」と書いています。営業が見られる資料のすべてが、顧客に伝えてよい正しい情報とは限らない、ということです。

この考え方に立つと、営業AIの元ネタは、社内のあらゆる資料ではなく、承認された知識に限るのが筋です。共有フォルダには、作りかけの資料、古い版、個人のメモ、検討中の案が混ざっています。AIにそれらを全部読ませると、承認されていない案が答えに出てくるおそれがあります。

承認済みに限るとは、具体的には、AIが答えに使ってよい知識の置き場を一つに決め、そこに入れる前に持ち主が内容を確かめる、ということです。Spekit の知識の置き場は、持ち主・版の履歴・権限・鮮度の監視を持つと説明されており、この運用を前提に作られています。

ただし、承認済みに限ると、答えられない質問が増えます。置き場にない情報を聞かれたとき、AIが「分からない」と返すのは、古い答えを返すより良い結果だと社内で合意しておきます。答えられない質問は、次に置き場へ足す知識の候補として記録します。

元ネタの持ち主を決める：項目ごとに部門と人を置く

承認済みの置き場を作ったら、次はその中身の一つ一つに持ち主を置きます。持ち主とは、その知識が正しいことに責任を持ち、変わったら直す人です。部門ではなく、名前で決めることが大事です。

持ち主は、その知識を最もよく知り、変わったときに最初に気づく人にします。製品の仕様なら製品の担当、導入の手順なら導入支援の担当、社内の申請の手順なら営業企画、事例ならマーケの担当、といった具合です。営業支援の担当が全部を持とうとすると、変化に気づくのが遅れます。

• 製品の仕様・機能の有無・対応している連携先 … 製品の担当
• 導入の進め方・必要な期間の目安 … 導入支援の担当
• 社内の手続き（見積もりの申請・値引きの承認の流れ） … 営業企画
• 導入事例・顧客の声 … マーケの担当（掲載の許可の管理も含む）
• セキュリティの質問への標準の答え … 情報システムの部門
• 持ち主が異動・退職するときの引き継ぎ先 … 営業企画が一覧で管理

最後の項目が特に大事です。持ち主の一覧を作っても、人が動けば持ち主のいない知識が生まれます。異動や退職の手続きに、持ち主の引き継ぎを組み込むと、持ち主のいない資料が増えるのを防げます。訴求の言い方の持ち主と改訂は前便の Octave の記事で扱ったので、ここでは営業が引く知識全体の持ち主に絞っています。

見直しの周期は、変わる速さで分ける

持ち主を決めたら、見直しの周期を決めます。すべての知識を同じ周期で見直すと、変わりやすい知識には遅すぎ、変わりにくい知識には手間がかかりすぎます。知識の種類ごとに、変わる速さで周期を分けます。

知識の種類	変わるきっかけ	見直しの周期の目安	AIの答えでの扱い
製品の仕様・機能	製品の更新・新機能の提供	製品の更新のたびに。少なくとも月に一度	答えてよい。更新日を添える
導入の手順・期間	体制や手順の変更	四半期に一度	答えてよい
社内の手続き	規程や承認の流れの変更	変更のたびに。少なくとも半年に一度	答えてよい。手続きの窓口を添える
導入事例	掲載の許可の期限・顧客の状況の変化	半年に一度	掲載の許可があるものだけ
価格・値引き・契約条件	価格の改定・方針の変更	改定のたびに	答えさせない。担当の窓口に回す

表の最後の行にあるとおり、価格や契約条件は、見直しの周期を決めるだけでなく、そもそもAIに答えさせない区分にします。これは後の節で詳しく扱います。

周期を決めても、見直しが実際に行われなければ意味がありません。見直しの日を持ち主の予定に入れ、見直したら記録を残すようにします。見直したが変更がなかった、という記録も残すと、その知識がいつの時点で正しいと確かめられたかが分かります。

周期の起点にも注意します。作成日から数えると、作ってすぐ見直した知識も、長く放置された知識も同じ扱いになります。最後に持ち主が確かめた日から数えるようにすると、見直しの漏れが一覧で分かります。製品の更新や価格の改定のように、変わる日が前もって分かっている場合は、その日の直前に関係する知識の見直しをまとめて入れておくと、改定の当日から古い答えが出るのを防げます。

古くなった情報の検出は、AIに候補を出させる

周期の見直しだけでは、急な変化に追いつけません。製品の仕様が予定外に変わったり、二つの資料が食い違ったまま置かれたりすることがあります。こうした古さを拾うのに、AIの検出が役立ちます。

Spekit の公式の説明では、コンテンツの統制の機能が、知識ごとの鮮度の点数、作成からの経過の分布を示し、更新・統合・アーカイブ・削除の推奨をAIが出します。また、新しい内容と食い違う内容や、古くなったおそれのある内容に印を付け、見直すべき一覧を作るとされています。

ここで大事なのは、AIの検出は候補であって、古いと決めるのは持ち主だという位置づけです。作成から時間がたっていても、正しいままの知識はあります。逆に、作ったばかりでも、前提が変わって古くなった知識もあります。経過の日数だけで古さを判断しないようにします。

運用としては、AIが出した見直しの候補を、週に一度、持ち主ごとに振り分けて届けるのが現実的です。候補を受け取った持ち主は、直す・そのままにする・廃止する、のどれかを決めて記録します。候補を放置したままにしないよう、期限を決めておきます。

古い情報の止め方と、廃止を決める人

古いと分かった知識は、まず答えに使われないようにします。直すまでに時間がかかる場合でも、古いまま答えに出続けるのを止めることが先です。直すことと止めることを分けて考えると、対応が早くなります。

止め方には段階があります。内容を直す、一時的にAIの答えに使わないようにする、置き場から廃止する、の三つです。廃止は取り消しが難しいので、持ち主と営業企画の二人で決めることにします。廃止した知識が営業の手元の資料に残っていないかも確かめます。

• 新しい価格表を置き場に足したが、古い価格表を消さなかったため、AIが両方を読んで古いほうの価格で答える
• AIの推奨どおりに作成から1年たった資料をまとめて削除し、まだ正しかった導入の手順まで消えてしまう
• 持ち主が退職した資料を、誰も廃止の判断ができないまま置き場に残し続ける
• 古い資料を置き場から消したが、営業がそれを手元に保存して顧客に送り続けている
• 直すまでの間もAIの答えに使われ続け、修正の完了を待つ数週間に古い情報が顧客に伝わる

一つ目と二つ目の失敗は、正反対の向きです。古いものを残しすぎても、新しいものを消しすぎても、答えは誤ります。廃止の判断をAIの推奨に任せず、持ち主が中身を見て決めることで、どちらの失敗も防げます。

営業AIに答えさせない項目

元ネタをどれだけ新しく保っても、営業AIに答えさせるべきでない項目があります。答えが顧客との約束になってしまうもの、状況によって答えが変わるもの、誤ると法務の問題になるものです。

• 価格・値引きの幅 … 個別の条件で変わる。営業企画や上長の承認の窓口に回す
• 納期・導入の完了日の約束 … 体制や在庫で変わる。導入支援の担当に確かめてから伝える
• 契約条件・保証・責任の範囲 … 法務の確認が要る。標準の条項の所在だけを示す
• 競合の製品との比較 … 相手の製品は変わる。誤れば信用を損ない、表示の決まりにも関わる
• まだ提供していない機能の時期 … 約束と受け取られる。製品の担当の公式の答えだけを使う
• 顧客ごとの例外の扱い … 個別の取り決めで、他の顧客に広げられない

これらの項目は、AIが答えを作らずに、担当の窓口や正式な手続きを示すようにします。答えさせない項目を一覧にして、置き場の運用の決まりに書いておくと、後から知識を足す人も迷いません。

競合の比較は、営業から特に求められる項目ですが、AIに自由に答えさせると、古い情報や推測が混ざります。競合の対策表を作るなら、持ち主を置いて承認した版だけを答えに使い、比較の表現は法務が確かめます。

外のAIにつなぐときに、外に出るもの

2026年6月の発表では、社内の知識を Claude・ChatGPT・Copilot・Gemini などのAIからも読めるようにする MCP サーバーが、ベータとして案内されました。営業が別のAIを使っていても、同じ承認済みの知識から答えられるようにする狙いです。

この仕組みを使うと、知識の置き場の中身が、つないだ先のAIの側にも渡ることになります。どのAIに、どの範囲の知識を読ませるかを、つなぐ前に決めておく必要があります。社内向けの手続きや、特定の顧客に関わる情報まで渡す必要はないはずです。

また、つないだ先のAIが知識をどう扱うか、学習に使うかどうかは、そのAIの契約と設定で決まります。Spekit の側で使っているAIの提供元や、知識の保存場所、学習への利用の扱いは、2026年10月時点の公式の資料で確かめられませんでした。ベータの機能を使う前に、提供元と情報システムの部門に確かめる項目として扱ってください。

外につなぐ範囲を広げるほど、古い知識の影響も広がります。つなぐのは、持ち主と見直しの周期が回り始めてからにするのが順番です。

営業から上がる「答えが違う」の受け方

どれだけ準備しても、古い答えや誤った答えは出ます。そのとき最初に気づくのは、顧客と話している営業です。営業が「答えが違う」と感じたことを、元ネタの持ち主に届ける道を作っておきます。知らせる窓口が営業ごとにばらばらだと、同じ誤りが何度も別々に届き、持ち主の側で同じ確認を繰り返すことになります。窓口は一つに決め、受け取る担当も名前で決めておきます。

この流れで集まった知らせは、月に一度まとめて見直します。同じ種類の知識で誤りが繰り返されるなら、その種類の見直しの周期を短くするか、答えさせない項目に移す判断をします。1件ずつの書き方を直す話は、ナレッジベースの1件の書き方を扱った記事に譲ります。

AIに任せる工程と人が決める工程、費用の増え方と止め方

ここまでの運用を、AIに任せる工程と人が決める工程に分けて整理します。AIは探す・まとめる・見つけるのが得意で、正しいと認めることと捨てることは人の仕事です。

AIに任せてよいのは、知識の検索、答えの要約と下書き、古くなったおそれのある知識や食い違う知識の検出、見直しの候補の一覧づくりです。人が決めるのは、元ネタを正と認めること、価格や約束に関わる答え、知識の廃止、答えさせない項目の線引きです。

費用の増え方は、2026年10月時点の公式サイトで料金が公開されていないため、提供元に確かめる必要があります。一般にこの種の製品は使う人数に応じて増えますが、加えて、公式ヘルプの記述では組織で AI Sidekick を使うには担当の窓口に申請して有効にする形になっています。AIの機能が別の契約や追加の費用になるかは、申請の前に確かめておきます。人の側の費用として、持ち主の見直しの時間も見積もりに入れます。

止め方は、二つの段階で考えます。答えに問題が出たときは、該当する知識を答えに使わないようにする。仕組み全体を止めるときは、AIの機能を無効にし、営業には知識の置き場を直接見てもらう形に戻す。AIを止めても、承認済みの置き場と持ち主の一覧は残るので、元ネタを整えた手間は無駄になりません。

導入の前に確かめること

ここまでの運用は、製品の機能がそろっている前提の話です。国内の会社が Spekit を検討するなら、契約の前に提供元へ確かめておきたい点があります。

一つ目は、日本語です。日本語で書いた知識を置いたとき、営業が日本語で聞いて、正しい知識を探して日本語で答えるかを、自社の実際の資料で試します。言い回しが違う質問、製品の略称を使った質問、英語と日本語が混ざった質問など、営業が実際に使う聞き方で試すと、思わぬ取りこぼしが見つかります。二つ目は、AIの機能の有効化の手続きと、それに伴う契約の扱いです。

三つ目は、データの扱いです。使っているAIの提供元、知識の保存場所、学習への利用の有無、ベータの MCP サーバーでつないだときの扱いを、情報システムの部門と一緒に確かめます。これらは2026年10月時点の公式の資料で確かめられなかった項目です。四つ目は、顧客管理の仕組みとの相性で、Salesforce 以外を使っている場合にどこまで連携できるかを確かめます。

• 持ち主と見直しの周期の運用は、Spekit に限らず、営業の画面の中でAIが社内の知識から答える仕組みすべてに当てはまります
• 製品を入れる前に、承認済みの置き場と持ち主の一覧を作っておくと、どの製品を選んでもすぐに使えます

まとめ

Spekit は、営業が使う画面の中で、承認された社内の知識をもとにAIが答える営業支援の基盤です。2026年6月の GTM Knowledge Engine 2.0 で、鮮度の点数や食い違いの検出といった統制の機能を強めましたが、外のAIにつなぐ仕組みはベータで、知識が自ら更新される機能はまだ提供されていません。営業AIの答えを古くしないには、元ネタを承認済みの置き場に限り、知識ごとに名前で持ち主を置き、変わる速さに応じて見直しの周期を決める。古い情報の検出はAIに候補を出させ、直す・止める・廃止するは持ち主が決める。価格や約束、競合の比較は答えさせず、営業からの「答えが違う」を持ち主に届ける道を作る。AIの機能より先に、この運用を回し始めてください。

• 製品の機能と提供の状態は、Spekit の公式サイト（ホーム・プレスページ・2026年6月の発表ページ・知識と営業支援のページ）、2025年11月24日と2026年6月16日の報道発表、2026年8月9日と10月20日の公式ブログを2026年10月26日に確かめた範囲に基づきます
• 使っているAIの提供元、知識の保存場所と学習への利用、日本語の対応、料金は公式の資料で確かめられなかったため、契約の前に提供元に直接確かめてください

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。