「何を選ぶか」ではなく「基盤をどう設計するか」──ツール選定の前に確認すべき5つの観点

データ基盤の設計さえ誤らなければ、その上に載せるツールやAIソリューションの選択肢は自由に広がる。逆に基盤が緩ければ、どれほど高性能なツールを導入しても効果は薄く、時には効果がまったく出ないケースすらある。ツール選定で本当に問うべきは「何を選ぶか」ではなく「基盤をどう設計するか」である。

SFA再構築やMA刷新の場面では、機能比較表を並べて「どれが最も高機能か」を検討するプロジェクトが多い。だが機能の優劣は、選定の本質ではない。本稿では、ツール選定の前に確認すべき5つの観点を、機能の判定基準としてではなく、データ基盤をどう設計するかという思考の道具として提示する。

この観点を見落としやすいのは、SFA再構築プロジェクトの実務を任された担当者である。ツールの機能比較には慣れていても、その裏側にあるデータ構造まで設計した経験は少ない。選んだツールが半年後に機能不全を起こす原因は、たいていツール自体にはなく、その下にある基盤の設計にある。

機能で選ぶ発想はなぜ限界を迎えるのか

多くのツール比較記事は、突き詰めれば「どの機能が優れているか」の一覧化に終始している。実際、国内の代表的なMA・SFA比較記事の多くは、価格・搭載機能・カスタマイズ性を横並びで一覧化する構成を取っている。そこにあるのは機能表であり、組織全体のデータインフラとして基盤をどう設計するかという視点ではない。機能単体の優劣を積み上げても、基盤の設計問題は解決しない。

単機能ツールの寄せ集めが招くデータの断絶

これも基盤の設計次第である。Pavilionの調査によれば、GTM（Go-To-Market）組織は平均30〜40のツールを稼働させている（Pavilion, 2026）。そのうち73%で機能が重複しているという。ツールを機能単位で選び足した結果、データはツールの数だけ分断される。営業担当者一人当たりの利用ツール数は平均8.3個にのぼる（Pavilion, 2026）。どのツールにどのデータがあるかを追うだけで負荷になる。現場の42%が「ツールが多すぎて疲弊している」と回答している（Pavilion, 2026）。chiefmartecの調査（State of Martech 2026、Frans Riemersma・Scott Brinker）でも、市場に出回るツールの総数は15,505に達し、前年から0.79%増にとどまったと報告されている。新たに1,488のツールが登場する一方で、1,367が姿を消した。淘汰されているのは、基盤に接続できない単機能ツールである。

統合された基盤の上に立つスタックが生む定量的な差

これも基盤の設計次第である。Forresterの調査（Marketing Operations Maturity Report, 2026）では、コアツールが5個以下の組織と25個以上の組織を比較している。ヘッドカウント当たりのパイプラインは、5個以下の組織の方が23%多い。データの帰属精度も92%対67%と開きが大きい。Demandbase（Labs by Demandbase, 2026、579テナント調査）も同様の傾向を示す。CRM・MAP・予測スコアリング・広告ツールを統合した組織は、MQA（Marketing Qualified Account）転換率が3.62%に達する。非統合の組織は2.37%にとどまり、統合側が53%上回る。商談化までの日数も、統合側が49.8日、非統合側が68.9日と28日の差がついた。差を生んでいるのは個々の機能ではない。それらが同じ基盤の上でつながっているかどうかである。GTM領域のコンサルティング各社の間でも、「最高のスタックを求める発想」から「つながった最小限のツールを持つ発想」への転換が指摘され始めている。ツールの数を追うのではなく、層として設計されているかどうかが問われている、という論調は本稿の立場と重なる。

国内の代表的なMA・SFA比較記事を実際に読み比べても、運用設計やSLA連携の解説は充実している一方、データガバナンス・AI統合・組織全体のデータインフラという視点はほとんど触れられていない。海外では定量データを伴って語られ始めている論点が、国内ではまだ機能比較の一歩手前で止まっている。

観点1・観点2　データは統合できる設計か／AIを乗せられる設計か

国内のツール比較記事の多くも、選定基準として機能一覧を並べる域を出ていない。ここから先の5つの観点は、機能の判定基準ではなく、基盤をどう設計するかという思考の道具として使う。

観点1：データは統合できる設計か

これも基盤の設計次第である。設計を誤った場合、ツールを個別最適で増やすたびにAPI連携が場当たりになる。データはCSVでの受け渡しに頼り、更新のたびに手作業が発生する。正しく設計した場合は違う。マスターデータの単一ソースをあらかじめ定義し、新しいツールはそこに接続するだけで済む。MarTech.orgの調査では、スタック管理上の課題として「データ統合」を挙げた組織が65.7%にのぼる（MarTech.org, 2026）。コスト（18.4%）を大きく上回る割合である。統合設計の有無が課題の量を左右している。

典型的なパターンで考えるとわかりやすい。課題は、MAとSFAがAPI連携されておらず、月次でCSVを人手で突合していた状態である。実装は、顧客IDを軸にしたマスターデータを基盤側に定義し、両ツールがそこを参照する構成へ変更することである。効果は、手作業の突合が不要になり、リードの重複登録も解消されることである。

観点2：AIを乗せられる設計か

これも基盤の設計次第である。設計を誤った場合、データが散在・欠損した状態でAI機能を導入することになる。学習に使えるデータの質が低く、成果につながらない。Gartnerの調査では、Martechの活用率が49%まで低下している（Gartner Marketing Technology Survey, 2025）。機能の利用率も2020年の42%から2023年には33%まで下がり続けている。ツールを増やしても使いこなせていない実態がうかがえる。正しく設計した場合は逆だ。クレンジングされ構造化されたデータがすでに基盤にあり、AIはその上に乗せるだけで機能する。Gong Labsの調査では、収益部門のリーダーの96%が「来年までに自社もAIを活用している」と回答している（Gong Labs, State of Revenue AI, 2026）。前提となるのは、AIが読み取れる形にデータが整っているかどうかである。

基盤を整えないままAIを乗せることのリスクは、バイヤー側の変化を見るといっそう大きく映る。6senseの調査（Buyer Experience Report, 2025、4,000+バイヤー調査）によれば、B2Bバイヤーの94%が購買プロセスでLLMを利用しているという。バイヤーの側ではすでにAIが前提になっている一方、売り手側の基盤が追いついていなければ、そのギャップは商談の質に直結する。Forresterは2026年の予測で、生成AIをガバナンスなく使い続けることで、B2B企業全体が100億ドルを超える損失を被ると警告している（Forrester, 2026 B2B Predictions）。AIを「乗せられるか」は、基盤側のガバナンス設計を伴って初めて判断できる。

これを設計で解決した例を一つ挙げる。課題は、各ツールにデータが散在し、AIのスコアリング機能を有効化しても精度が低かった状態である。実装は、基盤側でデータをクレンジング・統合してからAIのスコアリングに接続し直すことである。効果は、スコアの精度が上がり、営業への引き継ぎ基準として使えるようになることである。

観点3・観点4　個人粒度を扱える設計か／セキュリティは担保される設計か

観点3：個人粒度データを扱えるか

これも基盤の設計次第である。設計を誤った場合、データは企業単位でしか紐づかない。誰が資料をダウンロードし、誰が価格ページを見たかが追えない。Forrester（The State of Business Buying, 2026、2025年Buyers' Journey Survey）によれば、1件の購買意思決定に社内13名・社外9名、合計22名前後が関与するという。この人数をひとつの企業アカウントにまとめてしまえば、誰が動いているかは見えなくなる。正しく設計した場合は逆だ。個人ID（またはそれに準ずる識別子）を基点に、MA・SFA・広告のデータが串刺しで追える。誰が、いつ、何に反応したかが可視化され、営業への引き継ぎ精度が変わる。

同様に、設計の違いが表れる例がある。課題は、企業アカウント単位でしかデータが紐づかず、誰が資料をダウンロードしたかが追えなかった状態である。実装は、個人IDを基点にMA・SFA・広告のデータを串刺しできる設計へ変更することである。効果は、誰が、いつ、何に反応したかが可視化され、営業への引き継ぎ精度が上がることである。

観点4：セキュリティ・コンプライアンスは担保されるか

これも基盤の設計次第である。設計を誤った場合、ツールごとにアクセス権限の設定がバラバラになる。誰が何のデータに触れられるかを一元的に把握できず、監査証跡も追いにくい。Gartnerは、2026年の内部監査計画で重視される領域の一つにデータガバナンスを挙げている（Gartner, 2025年11月発表）。監査責任者（Chief Audit Executive）の94%が、2026年の活動計画にデータガバナンスの監査対応を組み込んでいるという。正しく設計した場合は違う。アクセス制御と監査ログを基盤側で一元管理し、個々のツールはその制御に準拠する形で接続する。ツールを増やしても、守るべきルールは一つのままである。

ここでも、設計の有無が結果を分ける。課題は、ツールごとにアクセス権限の設定がバラバラで、監査証跡も追いにくかった状態である。実装は、アクセス制御と監査ログを基盤側で一元管理する設計へ切り替えることである。効果は、監査対応にかかる工数が減り、権限管理の抜け漏れも解消されることである。

観点5　運用を型化できる設計か

属人化を防ぐ運用設計

これも基盤の設計次第である。設計を誤った場合、運用はツールを使いこなせる特定の担当者に依存する。その人が異動・退職した瞬間、更新ルールも命名規則も引き継がれず、基盤は静かに壊れていく。正しく設計した場合は違う。命名規則・更新フロー・入力ルールが基盤側の仕組みとして組み込まれ、誰が触っても同じ状態を保てる。

運用面でも同じ構図が繰り返される。課題は、運用が特定の担当者に依存し、異動のたびに更新ルールが引き継がれなかった状態である。実装は、命名規則・更新フロー・入力ルールを基盤側の仕組みとして組み込むことである。効果は、担当者が変わっても、基盤の状態を保てるようになることである。

精神論ではなくテクノロジーで型化する

これも基盤の設計次第である。「部門間で協力しよう」という掛け声だけでは、運用の型化は起きない。型化とは、ルールをテクノロジー側に埋め込むことである。GTM Partnersの調査によれば、平均的なB2B企業は23のベンダーからツールを購入している（GTM Partners, 2026）。一方、成果を出している企業は4〜6のプラットフォームに集約している。ツールの数を絞ることそのものが目的ではない。GTM Partnersは、データ・エンリッチメント・インフラ・CRM・シグナル・オーケストレーションという6つの層でスタックを捉えるモデルを提示している（GTM Partners, 2026）。層ごとに役割を明確にし、その層の中でツールを入れ替えられる状態こそが、型化された運用の姿である。

5つの観点が示す、設計の分岐点

ここまでの5つの観点は、いずれも同じ構造を持っている。設計を誤れば、データも運用も少しずつ壊れていく。正しく設計すれば、基盤は土台として機能し、その上のツールは自由に組み替えられる。5つの観点は選定基準の五択ではない。基盤という一つの土台を、五つの角度から点検する行為である。

5つの観点を並べると、基盤の設計次第でどちらの状態にも転びうることが見えてくる。

左の列に心当たりがあるなら、次に導入するツールの機能を比較する前に、基盤側の設計を見直す方が優先度は高い。SFA再構築プロジェクトを任された担当者にとって、この表は「次にどのツールを選ぶか」の前に、「今の基盤はどちらの列に近いか」を確認するためのものである。

まとめ

Q1. ツール選定で最初に確認すべきことは何か？ A. 機能の一覧ではない。データが統合できる設計になっているかどうかである。マスターデータという単一ソースが定義されているかを、機能比較より先に確認する。

Q2. AIを導入すれば基盤の課題は解決するか？ A. しない。AIは基盤の上でしか機能しない。データが整っていなければ成果も出ず、ガバナンスを欠いたまま導入すればリスクにもなる。

Q3. 個人粒度でデータを追う必要があるのはなぜか？ A. 1件の商談に社内13名・社外9名が関わる時代に、企業単位のデータでは誰が動いているか見えないからである。個人IDを基点にした設計が、営業への引き継ぎ精度を左右する。

Q4. セキュリティは個々のツールで対応すればよいか？ A. ツールごとの対応では守れない。アクセス制御と監査ログを基盤側で一元管理し、ツールはその制御に準拠させる必要がある。

Q5. 運用の属人化を防ぐには何が必要か？ A. 精神論ではなく、命名規則・更新フロー・入力ルールを基盤の仕組みとして埋め込むことである。担当者が変わっても崩れない状態を、仕組みで担保する。

Q6. 結局、ツールは何を基準に選べばよいのか？ A. 選ぶ基準ではなく、その前にある基盤の設計を点検することである。基盤の設計さえ誤らなければ、その先の選択肢は自由に広がる。基盤が緩ければ、どれほど高性能なツールを載せても効果は限定的なままである。