データエンジニアの観点でプロダクト開発を語る

はじめに

SansanのData Direction Groupの中根です。

2024年にデータエンジニアとしてSansanに入社しました。社内でのデータ利活用、Sansan BIの開発を経て、現在はエージェントアプリケーションチームとしてSansan AIエージェントの開発に携わっています。前職ではSIerとして10年以上、システム開発やCCoEに携わってきました。

坂口が「『データから収益を生み出す』ことへの挑戦」というテーマで、SansanがAIエージェントで目指す世界観を語りました。本記事ではデータエンジニアの観点でプロダクト開発についてお話しします。

アプリケーション開発とデータエンジニアリングは一見別物ですが、実は共通する点が多いと思っています。ここではその共通点と、そこから発展するプロダクト開発の進め方について話していきます。

依頼を価値に変えるサイクル

私たちデータエンジニアは、日々こんな依頼を受けていると思います。

「SFAから、条件に合う重要顧客を出してほしい」
「プロダクトの利用状況を、意思決定に使える形で整理したい」
「特定施策を打ち出すため、データに基づいた仮説出しを一緒にやってほしい」

依頼からドメイン知識を汲み取り、データモデルに落とし込み、ユーザーへ提供する。フィードバックがあればさらに対応し、改善、継続的に支援する。このような一連のサイクルを回しているのではないでしょうか。

このサイクルは、プロダクト開発においても本質的に同じです。社内で価値を生んでいる営みを、プロダクトという形に落とし込む。そこに"データから収益を生み出す"という考え方が成り立ちます。

ただ、いざその「落とし込み」を進めると、これまで意識していなかった論点が現れます。

「プロダクト」に求められる視点

社内向けの営みとプロダクト開発は、似ているようで同じではありません。プロダクトとして成立させようとすると、これまで暗黙の前提となっていた部分が通用しなくなるからです。

たとえば品質やセキュリティです。社内の営みでは都度確認で済ませていたことも、プロダクトとして提供するなら、明確な非機能要件として整理・取りまとめが必要になります。

では、こうした論点を踏まえ、どのように開発を進めていくのがよいのでしょうか。ここでもまた、データエンジニアリングで培ったリズムが生きてくると考えています。

価値提供を速く回す、私たちの開発ストーリー

皆さんは、依頼を受けたとき何を重視するでしょうか。私は、いち早く結果を返すことだと思っています。なぜなら、必ずしもユーザーが求めているものと、自分の想定は一致しないからです。だからこそ早くアウトプットを返して、期待されている形を確認する。これはプロダクト開発においても変わりません。

ここからは、この考え方で私たちが実際にどう価値提供のサイクルを回していったか、その開発ストーリーを4つのステップでご紹介します。

これから4つのステップでストーリーを語りますが、この構成は複数のイテレーションを経て到達した1つの姿です。

図：エージェントアプリケーションのアーキテクチャ概念図

Step 1: 「屋台骨」の定義とローカルでの価値検証

プロダクトというゴールを考えると、やらなければならないことは非常に多く見えます。チーム内のメンバーが思い浮かべるエージェント像も、往々にしてとてもリッチなものです。

しかし、そのすべてを最初から作ろうとすると、時間がかかりすぎる上に、価値の核が見えないまま作った機能は後で無駄になる可能性も高くなります。そこで重要になるのが、「価値の起点（コア体験）に最短でたどり着けるか」という判断軸です。私たちはこの「引き算」の考えに基づき、まず何よりも先に「屋台骨」となる価値の源泉にフォーカスしました。

Sansanが持つ1st Party Data: 他にはない弊社プロダクト独自のデータから生み出されるインサイトこそがまさにコアとなります。
コアデータを体験できるユースケース: すべてを実装するのではなく、たとえば特定のユースケースに絞って価値を返すこと。我々は営業活動でポピュラーな「企業へのアプローチ」をまずは設定しました。
上記を検証するためのAgenticな機能: スピード感を重要視し、データにおける体験を確認できる必要最小限の機能のみに絞り込みました。

この時点では、これだけに絞っています。この屋台骨の価値を検証するために、専用のWebアプリケーションすら用意せず、検証ユーザーにローカルPC上でADKのDev UIを起動してもらう形を取りました。

技術選定：なぜADK？

エージェント開発のフレームワークとして、私たちはADK（Agent Developer Kit）を選びました。理由は次の通りです。

データの重力に近い：BigQueryやLookerといった弊社が主に利用するGoogle Cloudのサービスとの親和性が高く、データを動かさずに活用できる。
地続きで始められる：私たちのチームが開発しているSansan BIですでに利用しており、知見が蓄積されていた。

今、最も早く価値を届けられる選択としてADKを採用しました。ただし、これが恒久的な意思決定ではないという点はプロジェクトの最初から明確にしています。適切なフェーズで見直すルールのもと、速さを求めた結果としてこれを選んだのであり、将来的に別のフレームワークに移行する可能性も想定しています。コアの部分を抽象化して付け替えられる設計を意識することで、こうしたピボットにも対応できるようにしています。

Step 2: 「間口を広げる」ためのWebUI化と高速フィードバック

屋台骨の価値に手応えが見えたら、次のステップは、検証の「間口を広げ」、より多くの人に体験してもらうことです。そのためには、より一般的なWebUIが必要となりますが、ここでも完璧は目指しません。

WebUIによるアクセス: まずは社内アクセスに限定したWebUIを用意しました。評価サイクルを高速に回すことを目的とするため、社内のコンテナ基盤Orbitを採用しました。Orbitを採用することでインフラストラクチャとして検討すべき要素を最小限に抑え、アプリケーション開発に集中できました。
認証: フィードバックをもらうには「誰が使っているか」を定量的に取得することが重要です。そのため、この段階で初めて「認証」機能が必要になりました。一方で、データに対する詳細なアクセス制御はまだ不要と判断し、スコープから外しています。

私たちは、このWebUIを「8割の完成度」で素早く提供し、フィードバックを得ることを重視しました。進め方としては、長くても2週間に1回は必ずレビューの場を設け、ユーザーの声を取り入れながら柔軟に開発を進めるサイクルを回しています。

Step 3: 「体験を深める」ための機能追加と賢い技術選択

より良い体験を提供していく段階で、ようやく他のサブ機能の検討が始まります。

セッション管理: 例えば、会話の文脈をなめらかにする「セッション管理」はコア機能と密接なため、早い段階で一部を取り入れました。特に、ユーザー評価の際に「どのような会話をしたか」を振り返り、再現するための機能は重要でした。
データアップロード機能: また、Sansanの1st Party Dataだけでは対応できないエッジケースのために、ユーザーが自身のデータをアップロードできる機能も追加しました。

こうした機能追加の際に意識しているのが、「How」にこだわりすぎないことです。例えばセッション管理の実装では、将来的な拡張性を考えて自前で実装できましたが、まずはフルマネージドで最低限の機能を提供できるVertex AIのセッションサービスを採用しました。厳しい要件が出てきた時点で改めて見直す方針とし、ここでもスピードを優先しています。

このように、機能として必要なものはもちろん、「今あると良いものは何か」を常に見極め、速く価値を届けるための判断を繰り返していくことが重要になります。

Step 4: 体験を拡張する「並列開発」と、変化への向き合い方

Step 3までで、価値の起点となる体験を届けるアプリケーションの雛形が出来上がりました。次のステップは、その体験の「幅」を広げ、同時に「深さ」を追求することです。

まず「幅」を広げるために、これまで定義した「コアとなるAgenticな機能」と「必要なデータ」の組み合わせを、別のユースケースでも同様に立ち上げていきます。いわば、Step 1で確立した成功パターンを、他の領域にも展開していくフェーズです。

この並行開発の過程で、次に「深さ」の追求が始まります。Step 1ではあえて深入りしなかった、「エージェントがどのようにデータを扱うか（RAGか、ツール利用か）」といった技術的な選択肢を、具体的なユースケースに沿って改めて深掘りしていくのです。

この深掘りこそが、非常に重要な意味を持ちます。なぜなら、後回しにしてきたサブ機能などが「本当に必要か」を、実装の観点から再評価する絶好の機会となるからです。ユーザーからのフィードバックと、技術的な実現性の両面から検討することで、初期段階で考えるよりもずっと解像度の高い意思決定が可能になります。

そして、このステップにおいても私たちが常に心掛けているのが、「作りすぎない」ことと「いち早くフィードバックを得る」という原則です。 AIを取り巻く環境は、新しいサービスやライブラリが次々と登場し、ものすごい速さで変化しています。昨日まで自分たちで実装しようとしていたものが、今日には便利なサービスとして提供されることも珍しくありません。

だからこそ、「今、本当に自分たちが作るべきものは何か」を常に見極め、やることを絞り続ける。このイテレーションを繰り返すことが、変化の速い時代において価値を提供し続ける上で不可欠だと考えています。