第8章 回し続ける仕組み ―― AIによる判定・分類とデータアーキテクチャ（Step7）

8-1. ここまでを人手で回し続けることは、現実的に不可能である

第5章から第7章まで、購買グループを設計する手順を述べてきた。属性を整え、アカウントを一意にし、関係性を読み解き、役割を推定し、グループを定義し、役割ごとに価値を設計し、フェーズごとに施策を組み、営業と受け渡す。

読者の中には、ここまで読んで「正しいが、回せない」と感じている人がいるだろう。その感覚は正しい。

ターゲットアカウントが100社あり、1社に平均3つの購買グループがあり、1グループに4役割がいる。1,200のセルに人を割り当て、それぞれの人の部門と役職を最新に保ち、誰がどのフェーズにいるかを判断し、毎日入ってくる新しいリードをどのグループのどの役割に置くかを決める。これを人手で、毎日、続ける。不可能である。

だから、購買グループのマーケティングは、AIの活用と切り離せない。ここで言うAIは、コンテンツを生成する道具のことではない。判定し、分類し、更新し続ける道具である。第5章で「最終的にはAIを使う」と先に述べたのは、この工程のことである。Step7は、ここまでの設計を、人手ではなく仕組みで回し続けるためのデータアーキテクチャを構築する工程である。

先に結論を述べる。グルーピングこそ、セールス・マーケティング領域でAIが最も効く仕事の1つである。人間が判断に迷い、時間を費やし、結局やり切れずに放置してきた「この人はどの部門の誰の部下で、何の役割か」という問いに、AIは根拠を添えて即答できる。

8-2. 入力 → AI判定 → 出力

Step7のアーキテクチャは、3つの層で描ける。入力、AI判定、出力である。

入力は、人と接点が生み出すデータである。名刺、MAの接点データ、SFAの商談・活動データ、外部データベース（法人番号・業種・売上規模・ニュース）。第5章で整えた個人の属性情報、一意化されたアカウント、営業・インサイドセールスの聞き取りもここに含まれる。

AI判定は、入力を購買グループの構造に変換する層である。当社が実装している判定は、主に4つある。

第一に、住所から事業所への自動割り当て。名刺やフォームの住所を、アカウントの拠点マスターに照合し、その人がどの事業所に属するかを判定する。エリア単位のグループを成立させる基礎である。

第二に、役職・部門から役割への推定。第5章の山田・田中の例で示した通り、部門、役職、そしてシグナルの有無から、着火役・旗振り役・門番・金庫番のいずれかを推定する。根拠を添え、確度を持たせる。

第三に、接点データから関与関係の可視化。同じアカウントの複数の人物が、同じ資料を見ている、同じウェビナーに参加している、同じ時期に同じテーマのページを閲覧している。この重なりから、「この人たちは同じ検討に関わっている」という関与関係を推定し、グループとして束ねる。第4章で述べた、名刺に現れないプロジェクト単位のグループを捉える主要な手段である。

第四に、外部シグナルの付与。ニュース、プレスリリース、人事異動情報、採用情報といった外部データから、「新工場設立」「海外進出」「役員交代」といったシグナルをアカウントに付与する。プロジェクトの発生を、社内データより先に捉える経路になる。

出力は、自動で更新され続けるデータベースである。第5章で描いた目指す姿――6階層が1枚で見える状態――が、人が手を入れなくても最新に保たれている。新しいリードが入れば、事業所が割り当てられ、役割が推定され、既存のグループに紐づくか新しいグループが立つ。外部でニュースが出れば、該当アカウントにシグナルが付く。

8-3. MA/SFAで購買グループをどう表現するか

ウェビナーで「購買グループをMA/SFAの上でどう表現するのか」という質問を受けた。実装に直結する問いなので、本書の考え方を示す。

やってはいけないのは、会社単位でフラグを立てることである。「A社はABMターゲット」「A社は検討中」という企業レベルの1つのフラグでは、第4章で述べた「1社に複数の購買グループが同時に存在する」構造を表現できない。情報システム部の検討が進んでいることと、人事部の検討が止まっていることを、同じフラグが同時に示すことはできない。

当社の実装では、パーソンのレコードに、AIが判定した項目を根拠付きで付与する。「推定グループ：A社／情報システム部／◯◯事業所」「推定役割：旗振り役（根拠：部長職・同部門に着火役あり）」「事業所：◯◯事業所（根拠：住所照合）」。項目として持つから、MAではグループ単位・役割単位でセグメントを切って施策を打てる。SFAでは、営業が商談に紐づく関与者を役割付きで一覧し、空白の役割を確認できる。

そのうえで、判定はSFA側で確認・修正できる形にしておく。AIの推定は絶対ではない。営業が面談で「この方は旗振り役ではなく門番でした」と確認したら、その修正が反映され、次の推定の材料になる。AIが推定し、人が確認し、AIが学ぶ。この往復を前提に項目を設計する。

8-4. 鮮度を保つ ―― 部署改編・異動・退職

もう1つ、ウェビナーで受けた質問がある。「部署の統廃合や異動、退職があった場合、どう管理するのか」。購買グループの設計を実運用に載せた企業が、必ず直面する問いである。

答えの前提は、第5章で述べた「最新の情報が最高である」という原則に戻る。名刺は交換した瞬間の接点にすぎない。データベースの中の部署名・役職が、いまも正しいとは限らない。だから、鮮度を保つ仕組みを、最初からアーキテクチャに組み込む。

第一に、部署は正式名称で取り続ける。フォームや名刺から取得する部署名を、選択式の大分類ではなく正式名称で保持する。組織改編があった場合、旧名称と新名称の対応を持てば、履歴を追える。大分類しか持っていなければ、改編があったことにすら気づけない。

第二に、聞き取った情報をデータベースに集約する。異動・退職・組織変更の多くは、営業とインサイドセールスが対話の中で知る。「◯◯さん、4月から関西支社に移られたそうです」。この情報が架電メモやメールの中に留まっている限り、データベースは古いままである。第7章で述べたSLAの「戻す」経路――営業・ISが得た情報をSFAに反映する運用――が、鮮度維持の生命線になる。

第三に、SFAで固定化しない。営業が一度入力した部署・役職を、そのまま何年も正として扱わない。MA側の新しい接点（フォームの再入力、名刺の再交換）や外部シグナル（人事異動情報）と照合し、差異があればAIが更新候補として提示する。人が確認して確定する。

第四に、最新情報を取得し続ける経路を持つ。定期的なフォームの再入力を促すコンテンツ、名刺の再交換が起きる接点、外部データベースの定期照合。鮮度は一度きれいにすれば保たれるものではなく、取得し続けることで保たれる。

8-5. GTM Engineeringとの接続 ―― データ基盤なきAIは、混乱を自動化する

本章で述べたアーキテクチャは、『GTM Engineering Playbook』で提示した4つのレイヤー――データ基盤、シグナル、AI、プロセス――の上に、購買グループという構造を載せたものである。

ここで、第1部で述べた原則を再確認しておきたい。レイヤーの順序は飛ばせない。データ基盤なきAIは、混乱を自動化する。

購買グループの文脈では、これは極めて具体的な意味を持つ。アカウントが一意になっていない状態で役割推定を動かせば、AIは割れたレコードの片方だけを見て「このアカウントには着火役しかいない」と判定する。部門が大分類でしか取れていない状態で関与関係を推定させれば、AIは「営業部門」という括りの中の無関係な人たちを同じグループに束ねる。判定の精度は、AIの性能ではなく、入力の設計で決まる。Step1〜4を省略してStep7に飛ぶことは、混乱を高速で量産することに等しい。

逆に、入力が整っていれば、AIは人が決してやり切れなかった仕事を引き受ける。誰がどの部門のどの立場で、誰の部下で、何の役割で、いまどのグループのどの検討に関わっているのか――この判定と分類と更新を、AIが毎日、根拠付きで続ける。人は、その結果を確認し、修正し、そして本来の仕事に向かう。戦略を考えること、価値を磨くこと、顧客と対話すること。

判定・分類はAIへ、人は戦略と顧客との対話へ。これが、購買グループのマーケティングを回し続けるための分業である。

これで7ステップは完成した。誰に、何を、いつ・どう届け、そして回し続ける。残る問いは、これを誰が回すのか、である。次章では、購買グループをマーケティングと営業の共通言語にするための運用体制を扱う。