AI時代に考える、Sansanの新規プロダクトのアーキテクチャ

■ イベント
Sansan Tech Talk @関西 〜大阪からプロダクトを牽引する！技術とカルチャーのリアル〜
https://sansan.connpass.com/event/381322/

■ 発表者
技術本部 Data Intelligence Engineering Unit
横山 拓史

■ 技術本部 採用情報
https://media.sansan-engineering.com

Transcript

1. Data Intelligence Engineering Unit 横⼭ 拓史 AI時代に考える、 Sansanの新規プロダクトの アーキテクチャ Sansan Tech Talk @関⻄ 〜⼤阪からプロダクトを牽引する！技術とカルチャーのリアル〜
2. 横⼭ 拓史 Sansan株式会社 Data Intelligence Engineering Unit ⼤学卒業後、SESエンジニアとして 様々な業界のプロジェクトに関わる。 Sansanに業務委託として参加したことを契機に Webアプリ開発に興味を持ち、 別プロダクトのアーキテクトを経て 2022年にSansanに正式にジョイン。 Bill Oneではマネージャーとして参画し、 現在はマネジメントもできるテクニカルリードとして 多⾓的にSansan Data Intelligenceプロダクトに関わっている。
3. 新プロダクトをリリースしました https://buildersbox.corp-sansan.com/entry/2026/02/10/150000
4. Sansan Data Intelligence 公式HPより
5. 何やってたの？ - 開発基盤作ってました - 技術選定（Google Cloud + Go） - Argo CDベースのCI/CDフロー - DDDに由来するBounded ContextやAggregateによるディレクトリ構成 - ConnectとPub/Sub push Subscriptionを中⼼としたHTTPサーバーで完結するア ーキテクチャ - 基本的な共通ライブラリとテストのための基盤の提供 - 開発を⾼速化するためのボイラープレートとツール群 つまり、開発者がどうやって新機能の開発、運⽤を⾏っていくかの デザインをしていました
6. AI時代だし、それ前提で⼯夫したいよね
7. 基本戦略 コンテキスト を近くに置く 1 全てを AIに任せない 2 短いFeedback Loopを 構築する 3
8. 1. コンテキストを近くに置く AIが参照するコンテキスト情報は AIの実⾏環境と近い場所に置いたほうがいい AIの実⾏環境はコードベースなので、コンテキスト情報である ドキュメントもgitで管理 するようにした 以下のドキュメントをgitで管理 - Architecture Decision Record（ADR） - 各種手順書（通称usage） - オンボーディングドキュメント - Spec（Spec Driven Design 用）
9. 1. コンテキストを近くに置く - やってみてわかったこと - ドキュメントとコードベースの 整合性をとりやすい - AIによるコードレビューでADRを参考に してくれる - AIがコード出⼒する際もADRを参考に してくれる ドキュメント⾃体を書くときも AIが使える - 各種ADRやコードベースを参考にしながら ドキュメントを出⼒してくれる - ドキュメントそのものに対しての ADR もある ので、それも参考にしてくれる GitHub Actionsとの親和性もいい - ドキュメントが古くなっていないかの チェックを⽉1で実⾏→⾃動Issue化 ドキュメントレビューの体験向上 - AIレビューが実⾏される - GitHubによるレビュー体験の統⼀ ドキュメントの検索性はあまりよくない - 今のところAIで探している - 将来的にはAIでまとめドキュメントを作ったりするかも
10. 2. 全てをAIに任せない AIはファジーにコードを出⼒するのは得意だが、構造的なコードの出⼒を させるためには⼤量のコンテキストを読み込ませる必要がある そして⼤量のコンテキストを読み込ませたとしても、思った通りのコードは 出⼒してくれない ⼀⽅で、構造化されていないコードは、⼈もAIも理解するのは難しい 構造を出⼒する責務と、コードを書く責務を分離し 前者はツールに、後者はAIに任せることにした
11. 2. 全てをAIに任せない - directory構造 - DDDをベースとした3層の構造化でコンテキストを整理し、 スコープを明確化した 集約がpackageとしてプレゼンテーション層〜インフラストラクチャ層の 4層を包含している 集約を増やすことでAPIをブロックのように増やせる構造にしている BC (Bounded Context) DU (Deployment Unit) Aggregate (集約) BC: 知識・語彙の境界 (チームの境界) DU: デプロイ単位 (1プロセス、1コンテナ) Aggregate: トランザクション境界 (ドメインモデルの単位) 例: tenant/authorization/role
12. 2. 全てをAIに任せない - file構造 - role/ $sci gen template operation ¥ --bounded-context tenant --deployment-unit authorization --aggregate role --operation add コマンドを叩くと ファイルが出⼒される。 addのような オペレーション単位で 増やすこともできるし、 BC等が全くない状態から 丸ごとアプリケーションを 作ることもできる handler_v1.go APIエンドポイント add_v1_handler.go リクエスト受付 add_v1_application_service.go ユースケース add_v1_test.go テストコード internal/core/ entity.go ドメインロジック vo.go 値オブジェクト repository.go データ永続化 add_v1_adapter.go データ変換 added_event.go イベント定義 出⼒
13. 2. 全てをAIに任せない - やってみてわかったこと - ディレクトリとしてコンテキストを 区切ることで、AIが把握する必要の あるコンテキストのスコープが明確に ボイラープレート側にAIへの TODOコメントを記述できるので プロンプト側で楽ができる ボイラープレート側にテストの型も 持たせているので⾃然と テストカバレッジも上がっていく ボイラープレート⾃体が 安定するまでツールのメンテナンス コストがかかる - ⼩規模なプロジェクトには向かない アプローチではある ボイラープレートの内容変更を 既存に展開するのが⼤変 - スピード重視で共通化をさぼっていたため 今後の課題
14. 3. 短いFeedback Loopを構築する AIによってコードを⼤量に作れるようになった反⾯、 それらの品質を向上させるためにひたすらコードの改善を指⽰するのは苦⾏ できればAI⾃らが間違いに気づいて⾃律的に修正してくれるような Feedback Loopが存在する状態が望ましい。 AIが⾃⼰チェックできる仕組みとして以下を導⼊している - Lint - Service Level Test - AI コードレビュー（ADRベース） - ⾃動リグレッションテスト（開発中）
15. 3. 短いFeedback Loopを構築する - Service Level Test - 操作の⼊⼒→出⼒を検証するテスト (ビジネスロジック全体をテスト) - 実際のHTTPリクエスト経由でテスト - モックではなく エミュレーターを利⽤（devcontainerで提供）することで 実際の実装 を使⽤ - Cloud Spanner - Cloud Pub/Sub - Cloud Storage - etc… API全体を丸ごとテストとしてカバーすることで、 デプロイ → 動かない → 修正 → 再デプロイ というLoopをローカル環境で完結できるようにした
16. 3. 短いFeedback Loopを構築する - さらにシフトレフト！ - AIが⾃⼰チェックしてくれるようになったとしても、 慣れてくるとlintやtestの実⾏時間が遅いと感じるようになる。 特にlintは同じ出⼒エラーを何度も繰り返す。 Claude Code Skills, Rules, Hooksを駆使することでそもそもの 出⼒内容を向上させる。 特にSkillsは各ADRにリンクさせることで、 出⼒内容を任意のADRのルールに従っている状態に近づけられた。 （過信はNG）
17. 3. 短いFeedback Loopを構築する - やってみてわかったこと - lintが厳しすぎると、 AIは永遠にlint fixする - style的なものであればlintを緩くするのも⼿ それでも変なコードを 出⼒するときはある - 愛をもって接しましょう どれだけシフトレフトできるかが ⽣産性に直結する テスト等の仕組みがまだ提供できていない CI/CDなどは、基盤機能の提供がある場所に ⽐べて明らかに⽣産性が落ちる レビューのようなAIによるチェックを いれるのであれば別セッション上で 評価させた⽅がより精度が⾼い 例えばコード⽣成させた同じセッションで 「ADR との整合性とれてる？」って聞くより も、別セッションで評価させた⽅が精度が⾼い
18. まとめ チェックと段階的なFeedback Loopを構築することで、 より早いフェーズでコードの品質を向上し効率化 1 コンテキストを 近くに置く ドキュメントを git管理した。 副作⽤として ワークフローの構築が 簡単になった 2 全てをAIに 任せない Directoryで コンテキストの スコープを区切り、 ボイラープレート ツールの整備をした 3 短いFeedback Loopを構築する Skillsによる 出⼒内容の補正、 ローカルでの静的解析 やテストによる
19. 直近の取り組み - Spec Driven Development - 仕組みは作ったのでPoC〜展開のフェーズへ - Claude Code Skills, Rules, Hooksの構造化と最適化 - AIを⾃⼰点検可能にし、出⼒するコードの精度を⾼めて コードレビューをなくす ⽬標は、従来のチームのアウトプットを 個⼈が出せるようになること！
20. Sansan 技術本部 募集ポジション紹介 https://media.sansan-engineering.com/