この記事は、Sansan Data Intelligence開発Unit ブログリレーの最終回（Vol.17）です。
Data Intelligence Engineering Unitの部長を務める多賀谷洋一です。
データクオリティマネジメント「Sansan Data Intelligence」をリリースして、半年が経ちました。半年間を通じて確信したのは、このプロダクトは変化の激しいAI時代の勝負どころに立っているということです。NVIDIA CEOのJensen Huang氏が「経済価値が生まれる場所」と呼ぶアプリケーションレイヤー、ここで勝つ条件は、独自データ・ドメイン知識・顧客基盤の3つ。Sansanはその3つを揃え、今まさに最前線に立っています。リリースから半年で事業は急速に立ち上がり、チームには確かな手応えが生まれています。今回はブログリレー最終回として、今このモーメンタムの中で働く魅力をお伝えします。
AI時代の「勝負どころ」に立つプロダクト
Jensen Huang氏は、AI産業を5層のレイヤー構造として描いています。下からエネルギー、チップ、インフラ、ファウンデーションモデル、そして一番上にはアプリケーション。
下の4つのレイヤーはいずれも、参入に莫大な投資を要します。年間60兆円超が動くAIデータセンター、数千億円規模の学習コスト——資本の規模がそのまま競争力になる世界です。今から新たなプレイヤーが競争優位を築くのは困難です。
しかし、アプリケーションレイヤーは違います。顧客への価値を決めるのは資本の大きさではなく、独自のデータとドメイン知識です。
ただし、ここにも落とし穴があります。
Anthropicは今、ファウンデーションモデルを提供するだけでなく、Claude CodeやCoworkなどアプリケーション層へと大胆に事業を拡大しつつあります。つまり「単なるエージェント」を作るだけでは、モデルプロバイダー自体がとてつもなく強い競合になります。
Sequoia CapitalのJulien Bek氏は、この構造を次のように捉えています。
If you sell the tool, you're in a race against the model. But if you sell the work, every improvement in the model makes your service faster, cheaper, and harder to compete with.
Services: The New Software By Julien Bek - Published March 5, 2026
（翻訳）ツールを売るなら、モデルとの競争を余儀なくされる。しかし仕事の成果を売るなら、モデルが進化するたびにあなたのサービスは速く、安く、競合に強くなる。
顧客に価値を届け続けるには、ツールではなく成果を提供できる立場に立つこと。そのためには、代替不可能な土台が必要です。
その条件は3つに収束します。独自データ（他社が真似できない独自のデータベース）、ドメイン知識（業界・業務の深い理解を体現したプロダクト）、そして顧客基盤（提供した成果に対して価値あるフィードバックして共創してくださる顧客）。
Sansanには、この3つが揃っています。そしてSansan Data Intelligenceは、まさにAI時代に顧客へ真の価値を届けていくプロダクトだと言えます。
なぜなら、AIエージェントがアプリケーション層で真の価値を生むには、自律的に判断・行動できる状態が必要であり、そのためには常に正しい情報を参照できる状態が不可欠だからです。
しかし、企業のデータ管理の現実はこうです。企業は数十のシステムにまたがるデータを保有し、同じ取引先を「A株式会社」「A（株）」「A社」と別々の名前や異なるIDで参照しています。AIエージェントが「A社の与信状況を確認して」と指示されても、同一企業を正確に結びつけられなければ、エージェントは間違った判断を下します。どれだけ高度なモデルを使っていても、データが正しくなければ正しい結果は出ません。
この問題を解決するのが、企業や事業所を一意の識別子（SOC: Sansan Organization Code）で管理し、常に正確で最新の状態に保つSansan Data Intelligenceです。このプロダクトは、その基盤となるマスターデータにおいてあらゆる企業や事業所に識別子であるSOCを付与します。個人に対するマイナンバーがあることで行政システムが連携して個人へのサービスを提供できるように、SOCがあることで複数システムを跨いで正しく企業や事業所を特定して連携させることができます。これにより、AIエージェントが目的とする企業や事業所を異なるシステムにおいて正確に特定し、そのリッチデータを取得し、正しく判断して自律的に業務を実行できます。
このように、Sansan Data Intelligenceは、Sansanだからこそつくることができる「AI時代の基盤」となるのです。
データクオリティマネジメント「Sansan Data Intelligence」
Sansan Data Intelligenceは、2025年12月にリリースされた「データクオリティマネジメント」サービスです。Sansanとして約4年ぶりの新規プロダクトで、構想からリリースまでわずか半年で実現しました。
企業が抱える取引先データの品質問題は深刻です。「重複・表記ゆれ・更新漏れ」を経験している企業は約8割にのぼります。（*1）
この問題は、近年急速に広がるAI活用にも直撃しています。AI導入企業の約9割が「期待通りの精度が出ない」と報告していますが、その根本にあるのがGarbage In, Garbage Out——質の低いデータを入力すれば、出力も質の低いものになるという原則です。
具体的には、営業担当者の手入力による「株式会社」と「（株）」の表記ゆれ、企業の移転・合併情報の更新放置、市場全体の未取引企業が可視化されていない状態などが挙げられます。これらはいずれも、誤った情報を元にしたアプローチや商談機会の損失に直結します。
こうした問題は、社員が主導する一時的な名寄せプロジェクトでは解決できません。手作業では対応しきれない量とスピードで、データの劣化は常に進んでいるからです。必要なのは、構造的・継続的なデータ品質の維持です。
Sansan Data Intelligenceは、企業のCRM/SFAや基幹システムに蓄積された取引先データを、Sansanの企業データベース（事業所データ1000万件超）と照合し、4つの価値を継続的に提供します。
- 識別・正規化：表記ゆれや重複を含むデータを一意に識別して、正しい企業・事業所単位に統合
- 最新化：移転や合併、社名変更などの情報を自動検知し、常に最新のマスターデータを維持
- リッチ化：業種、売上高、従業員数、系列情報など、営業戦略に必要な属性情報を付与
- ホワイトスペース可視化：自社データにはない、市場の未接触企業（ホワイトスペース）を可視化し、ターゲティングリストとして提供
これを支えるのが、企業・事業所の識別子であるSOCです。Sansanは10年以上の名寄せ技術の蓄積を経て、この識別子を大規模データに付与する技術を磨いてきました。SOC v2では従来のRDB（Relational Database）型から時系列グラフモデルへと全面移行しました。Entity（Node）とRelationship（Edge）で構成し、全Edgeが有効期間を保持します。最新のスナップショットだけでなく、「2020年4月1日時点ではA社はB社の子会社だった」といった過去時点の関係性まで扱う高い表現力を持つアーキテクチャへと根本から設計し直しました。
既存プロダクト「Sansan Data Hub」が名刺情報を起点としていたのに対し、Sansan Data Intelligenceは企業・事業所のマスターデータを起点としています。名刺がない企業、一度も会ったことのない取引先まで含めて、企業のデータ資産全体を統合管理できます。将来的にはリスクチェック、APIによるあらゆるシステムとの連携強化、グローバル展開へとプラットフォームを拡張していく見込みです。
（参照：Sansan Data Intelligenceリリースに寄せて）
技術的な挑戦と成長環境
Sansan Data Intelligenceを構成する技術スタックは、モダンかつSansanだからこそプロダクション利用できる要素もあり、エンジニアにとって貴重な経験ができる構成になっています。コアデータモデルの設計から、Google Cloudを活用したインフラ、Go言語とそのエコシステムを採用したバックエンド、Next.js（App Router）とTypeScriptを採用したフロントエンド、AIを活用した開発手法まで、各領域に技術的な挑戦や成長環境があります。
コアデータモデル：SOC v2
（参照：ブログリレーVol.03）
Sansan Data Intelligenceのデータモデルの中心にあるのは、驚くほどシンプルな構造です。それは、Entity（Node）とRelationship（Edge）、から構成されるグラフモデルです。Sansanではこの新しいデータモデル、そしてそれに基づく識別子をSOC v2（Sansan Organization Code Version 2）と呼んでいます。
企業はNode、企業同士の関係はEdge。「A社はB社の子会社である」「A社はC拠点に所在する」「A社とD社は合併した」——現実世界の複雑な企業情報が、すべてこの2つのプリミティブで表現できます。
さらにこのモデルが強力なのは、全Edgeが有効期間を持つという点です。Edgeは「いつからいつまでその関係が成立していたか」を保持します。つまりこのグラフは現時点のスナップショットだけではなく、時間軸を含んだ企業変遷の完全な記録となります。「2025年3月1日時点でA社はB社の子会社だったか」「この合併はいつ発生したか」——任意の時点の状態を、任意の時点でグラフから取り出すことができます。
名寄せとは集合論的にはEquivalence Classを求めることであり、Graph的に表現することが自然である。
Vol.03 SOCv2: MasterData as a Service (MDaaS) 10年もののSystemを作り替える
集合論に基づいたこのモデルは、Sansanを代表するエンジニアのMakoto Nagaiが設計しました。その設計ドキュメント (Design Doc) を読んだ時に、「NodeとEdge、有効期間のみでこれだけのことが表現できるのか」という驚きと静かな興奮があったことを覚えています。10年以上にわたって企業データの名寄せと向き合い続けたSansanが、最終的にたどり着いたシンプルな構造。複雑な現実を、最小限のプリミティブで過不足なく記述できる。真に良い設計はシンプルで美しい——そう確信させてくれる設計です。
グラフデータベース：Spanner Graph
（参照：ブログリレーVol.09）
Spanner Graphは Google Cloud Spannerの機能の1つで、グラフ構造のデータに対して専用のクエリ言語（GQL: Graph Query Language）でクエリできます。
「合併・移転・親子関係のつながりを辿る」という、SOC v2に基づくデータ取得はグラフ探索そのものです。だからこそ、Spanner Graphとの相性は必然でした。
通常のSQLではグラフチェーンを辿るクエリは複雑になります。一方でGQLでは、例えば -[:edge]->{0,100} という1行で「エッジを0〜100回辿る」ことを表現できます。「合併や分割というイベントを何段辿っても対象企業を特定する」という処理は、まさにこのGQLが力を発揮する問題です。
ところが、プロダクションの企業データで検証を進めるうちに、Spanner Graphを使い倒しているからこそ気づく特性が見えてきました。Sansanのエンジニアの滑川が突き止めたのは「パフォーマンスの支配的要因はグラフの経路数であって、パスの長さや幅ではない」というものです。実際に検証すると、パスの長さや幅はパフォーマンスへの影響は軽微だったのに対し、経路数は次の表のようにパフォーマンスに大きな影響を与えました。
| 経路数 | 応答時間 |
|---|---|
| 1,024 | 355ms |
| 2,048 | 696ms |
| 32,768 | 13,733ms |
さらに、同一経路数であってもグラフの形状によって実行速度が約10倍違うケースがあることも突き止めました。
現在1000万件を超える企業・事業所データ、複雑な資本関係、合併の連鎖。Sansan Data Intelligenceだからこそこの特性の理解が重要です。この検証のような経路数が爆発する企業が出てきた場合には、適度なクエリ分割やSQLとのハイブリッドな運用、ショートカットを作る設計などが求められることになります。
Spanner Graphをこの深さまで実運用で検証しているのはSansanだからこそです。しかも2026年5月末時点では、Spanner GraphはEnterpriseエディションまたはEnterprise Plusエディションでしか使うことができません。Sansanでしか経験できない技術チャレンジはたくさんあり、Spanner Graphはその一つです。
モダンな技術スタック
（参照：ブログリレーVol.01, Vol.03, Vol.14）
次の3つの主要システムともにGoogle Cloud上で稼働し、モダンな技術スタックを採用しています。これにより、エンジニアは顧客価値を生むためのシステム設計やプロダクト開発に注力できます。
- MasterData System: 組織と組織間の関係性を表す時系列グラフモデル（SOC v2）によるマスターデータ基盤
- Application: ユーザー向けのユースケースを提供するフロントエンドとバックエンドマイクロサービス
- Data Hub: データの識別・統合処理を行うデータパイプライン
インフラ
- GKE（Google Kubernetes Engine）Autopilotベースの社内共通プラットフォーム Orbit を採用。開発・ステージング・本番環境のマニフェスト定義、Secret Manager統合、ArgoCDによるデプロイ管理などを担い、インフラの認知負荷を大幅に削減
- Terraformによるインフラ管理（IaC：Infrastructure as Code）
- Argo CDとGitHub ActionsでCI/CDを整備
- Observabilityは OpenTelemetry + Cloud Monitoring / Cloud Trace / Cloud Loggingを採用
- 認証は社内共通基盤 Auth Oneを採用
データ基盤
- メインデータベースにCloud Spannerを採用。前述のように、グラフデータベースもSpanner GraphによりCloud Spannerで完結
- MasterData SystemのデータパイプラインはDataflow with Apache Beamで構築し、バッチとストリーミングを透過的に実装可能
バックエンド・API
- バックエンドにはGo言語を採用。goroutineによる軽量な並行処理がデータパイプラインと高い相性。MasterData SystemとData Hubで言語を統一しており、人材の流動性を高めている
- バックエンドとフロントエンドのAPI通信は Connect を採用。Protobufのシンプルなスキーマ記述からGo/TypeScript双方のコードを自動生成でき、スキーマから型安全な開発が可能
フロントエンド
- フロントエンドにはNext.js（App Router）+ TypeScriptを採用。React Server Componentsにより複数マイクロサービスからのデータ集約をシンプルに実現
- UIライブラリはヘッドレスUIライブラリ Base UI を採用。スタイリングにはCSS Modulesを使い、学習コストを最小化
AI活用による開発生産性の向上
（参照：Sansan Data HubリアーキテクチャVol.2, ブログリレーVol.08）
Sansan Data Intelligence開発におけるAI活用は「速度より質を重視する」という哲学のもとで進めています。質と量ともに十分なコンテキストをAIに与えられるかどうかが成否を分ける鍵です。
Claude Codeでコードを書くことは当然として、特徴的な取り組みはADR（Architecture Decision Record）を参照させるAI活用です。PR（Pull Request）に対してAIがADRを参照し、アーキテクチャ違反を検知・指摘します。これはコードのレビューにとどまらず、修正提案まで行います。このほか、Issue・PR・ドキュメントの日英自動翻訳、コードとドキュメントの乖離検出と修正提案など、開発の摩擦を取り除く自動化が組み込まれています。
さらに現在取り組んでいるのは、Spec-Driven DevelopmentをベースにAIが実装から開発環境へのデプロイまで自律的に実行し、実際の動作を自動検証するという挑戦です。「コードを書いてレビューする」から「デプロイして動かして確認する」まで、ソフトウェア開発のサイクル全体をAIが担えるかを探っています。これが実現すれば、エンジニアは「何を作るか」「なぜそう設計するか」という判断に、これまで以上に集中できるようになります。
AIを開発に活用することへの注目が高まる今、私たちはAIと共に開発する方法論そのものを最前線で作り出している組織です。
Sansan Data Intelligence事業のモーメンタム
データの規模も急速に拡大しています。リリースから半年という短期間で、Sansan Data Intelligenceがカバーする事業所データは1.5倍に拡大しました。事業所カバレッジを広げて識別精度を高めるという、エンジニアが解いている問題は事業の成長に直結しています。
エンジニアの関与は実装にとどまりません。「シフトレフト」のマインドセットを持つことを呼びかけ、プロダクトのWHYからプロダクトマネジャーと一緒に明確化します。「なぜこの機能が必要か」「どのデータが事業課題を解決するか」その問いをエンジニアがプロダクトマネジャーや事業部（営業やCS: Customer Successなど）と同じ文脈で考えています。
こうした背景には、チームに根付いた文化があります（参照：ブログリレーVol.04, Vol.10）。「その機能、本当に"今"必要ですか？」——これは実装コストの話ではなく、顧客価値のために優先順位を問い直す言葉です。顧客へ真の価値を届けること、ひいては事業としてSansan Data Intelligenceを成功させることが組織全体に共有されています。Sansan Data Intelligenceに関わる誰もが同じ価値観を起点に動くことで、意思決定の往復が減り、安定したリズムで開発が進みます。
こうしたモーメンタムは、エンジニア・プロダクトマネジャー・事業部が一体になって生み出しています。毎月開催される「Sansan Data Intelligence推進部定例」には、事業部長・営業・CS・プロダクトマネジャー・エンジニアが一堂に会し、OKRの進捗、ロードマップの方向性、顧客の声が共有されます。受注の喜びも全員で分かち合います。職種を越えたメンバーが同じSlackチャンネルで受注報告を受け、反応を返します。事業所データ1000万件を達成した時には、喜んでいただけるお客様の多さに事業部全体で歓喜が湧き起こりました。エンジニアによるプロダクトの改善がすぐに、そしてしっかりとお客様に届く。エンジニアと事業の近い距離感がここにあります。
目指す先も明確です。Sansan・Eight・Bill One・Contract Oneに続くSansanの新たな事業の柱として、「識別子が付与され、クレンジングされ、企業情報がひも付いた、AI-Readyなデータを顧客の環境に供給する」という、AI時代のデータ供給レイヤーを担っていきます。さらにその先にはデータ供給に留まらず、顧客のAI環境自体に入り込んで顧客の課題を解決していく未来も容易に想像できます。海外展開も可能なアーキテクチャのため、国内に留まらずグローバルな事業展開にも期待が高まります。
まとめ
Sansanには、AI時代のアプリケーション層で真の価値を生むための、独自データ・ドメイン知識・顧客基盤という3つの条件が揃っています。Sansan Data Intelligenceは、Sansanだからこそ開発でき、そして世の中に大きなインパクトを出していく新規プロダクトです。
プロダクトを支える技術は、SOC v2の時系列グラフモデル、Google Cloudを活用したモダンなスタック、AIを最大限に活用した開発プロセスなど、エンジニアにとって挑戦的かつ魅力的な環境です。これにより、エンジニアは事業を成功させるための本質的な問いに集中できます。
そして今、事業を成功させるモーメンタムが巻き起こっています。顧客を理解し、技術的に困難な問題を解いていくその先に事業の成功があります。エンジニア・プロダクトマネジャー・事業部が一体で動き、受注の喜びを全員で分かち合う。事業や受注という自社目線だけでなく、Sansan Data Intelligenceを利用するお客様がその価値を実感してお客様自身の事業を成功させることが私たちの存在意義。Sansan Data Intelligenceに関わるすべての社員が熱量を持ってモーメンタムを起こしています。
Sansan Data Intelligenceでは、このモーメンタムの中で一緒に世の中に大きなインパクトを生み出す仲間を求めています。
Sansan技術本部ではカジュアル面談を実施しています
Sansan技術本部では中途の方向けにカジュアル面談を実施しています。
Sansan技術本部やData Intelligence Engineering Unitでの働き方、仕事の魅力などについて、現場のエンジニアやマネジャーの視点からお話しします。「実際に働く人の話を直接聞きたい」「どんな人が働いているのかを事前に知っておきたい」とお考えの方は、ぜひエントリーをご検討ください。
