「プロダクトで成果を出す」 ──Contract Oneのプロダクトマネジャーが職種の枠を越えて挑戦する理由
「プロダクトで成果を出す。そのために必要なら職種の枠にはこだわらない」 そう語るのは、取引管理サービス「Contract One」のプロダクトマネジャー（PdM）を務める午菴と北野です。二人がいま向き合っているのは、AIによって大きく変わり始めたプロダクト開発の現場です。PdM自らがUI改善を実装し、エンジニアは事業視点で提案し、法務メンバーも企画や商談に入り込む。役割や肩書きにとらわれず、それぞれがプロダクトの成果に向けて動いています。役割や職種の枠を越えて挑戦する。そんなContract One事業部では、どのようなプロダクトづくりが行われているのでしょうか。 異なるキャリアを歩んできた二人に、Contract Oneならではのプロダクトづくりと、そこでPdMが果たす役割について聞きました。 午菴 夏希 / Natsuki GoanContract One事業部 プロダクト室新卒で広告代理店にて営業・販売促進・新規事業に従事。2017年よりデザイナーに転身し、大手人材企業の転職サービスの企画・開発を担当。 2020年12月にSansan株式会社へ入社し、ビジネスデータベース「Sansan」のプロダクトデザイナーを経て、2024年からContract Oneのプロダクトマネジャー兼プロダクトデザイナーを務める。 北野 浩司 / Koji KitanoContract One事業部 プロダクト室大学院卒業後、外資系計測機器メーカーにエンジニアとして入社し、研究開発者向けSW/HWのテクニカルサポートに従事。その後、製造業調達部門に特化したSaaSスタートアップに転職。マーケティングや導入活用支援を兼務したのちプロダクトマネジャーとして新規事業の立ち上げに携わった。 2025年8月にSansan株式会社に入社し、プロダクトマネジャーとしてContract Oneの製品企画を推進している。 「事業のためなら何でもやる」──異なるキャリアからContract OneのPdMへ ──これまでのキャリアについて教えてください。 午菴：はじめは広告代理店で営業をしていたのですが、お客様と深く向き合う中で「作って届けるところまで関わりたい」という気持ちが強くなり、デザイナーに転身しました。 そこでさまざまなクライアントの案件に携わるうちに、今度は一つのプロダクトに長期的に向き合いたいという思いが生まれ、事業会社への転職を考えていたタイミングでSansanを知りました。個人的にも名刺アプリ「Eight」を使っていて、そこで出会った人との縁が仕事につながった経験もあったので、以前からSansanのミッションには共感していました。Sansanへ入社後はデザイナーとしていくつかのプロダクトに携わり、約2年前からContract OneのPdMを務めています。異動のきっかけは、事業責任者の尾花から「PdMをやってみないか」と声をかけてもらったことでした。 ──PdMをやってみることに抵抗はなかったのですか。 午菴：全くありませんでした。私の働くモチベーションは、事業への貢献を実感できることにあります。ユーザーに良い体験を届けたり、身近なチームメンバーの助けになったり、形はさまざまですが、自分の働きが誰かの役に立っている瞬間が好きなんです。なので、「デザインじゃないといけない」というこだわりは特になかったですね。ちょうどPdMが足りていなかったこともあり、「事業のためなら何でもやります」という気持ちで引き受けました。今振り返ると、尾花が評価してくれていたのも、デザイナーとしての専門性以上に、そのスタンスだったのだと思います。 ──北野さんのこれまでのキャリアについても教えてください。 北野：大学院でシステム工学を専攻したのち、新卒入社した外資系の計測機器メーカーではエンジニアとして技術サポートや研修講師の仕事をしていました。 当時、仕事に一定のやりがいは感じていましたが、「新しい事業やプロダクトを作る挑戦がしたい」という思いが次第に強くなり、ご縁のあった創業期のSaaSスタートアップに転職しました。 そのスタートアップでは最初カスタマーサクセスの立ち上げに関わり、その後マーケティングも兼務するようになりました。そうした折に社内で新規プロダクトを立ち上げる話が持ち上がり、「お客様のことをよく知っているし、技術系のバックグラウンドもあるから」と声をかけてもらってPdMに転身しました。そこからはプロダクト開発の仕事を続けています。 ──Sansanに入社したのはどういった経緯ですか？ 北野： 私は、複雑な業務を解きほぐして、そこから得られたマニアックなインサイトをもとに課題を解決する、というプロセスがすごく好きで（笑）前職でも自動車業界特有の複雑な商習慣や帳票構造を読み解いて、得られた知見をお客様への活用提案やコンテンツ作成につなげることや、汎用的な機能としてプロダクトに落とし込むようなことをやっていたんです。そうした経験やスキルが生かせる次のチャレンジを探していたときにContract Oneに出会い、「契約書」という領域が面白いと思いました。 会社ごと、業界ごとに扱う契約書は大きく異なります。そこには各社・各業界固有の商慣習や取引の知恵が埋もれていて、まだ体系的な知見として整理されていない領域がたくさんありそうだと感じました。もう一つは、Sansanという会社自体への興味もありました。 以前からSansan社員の外部発信を見ていたので、PdMとして成長できる環境があるという印象を持っていましたし、Bill Oneの目覚ましい成長を見ていたので、Sansanが持つ組織的な営業の強さは確信していました。一定の顧客基盤と営業組織が整った会社の中で、これから伸ばそうとしている新規事業領域で働けば、自分が作ったものが社会により大きなインパクトで届くはずだという期待もありました。 AIで開発スピードは3倍に。Contract Oneで起きている変化 ──現在携わっているContract Oneとは、どのようなプロダクトなのでしょうか？ 午菴：Contract Oneは、契約書・発注書・見積書など、ビジネスで発生するあらゆる取引書類をデータ化・構造化して管理・活用できる取引管理サービスです。紙・電子を問わず高精度でデータ化し、契約書になじみがない方でも取引の条件や変遷を一目で把握してビジネスに生かせる環境を提供しています。 直近ではMCPサーバーの提供を開始するなど、契約データベースと生成AIを接続した新たな価値提供にも積極的に取り組んでいます。 jp.corp-sansan.com ──Contract Oneの企画が生まれるプロセスを教えてください。 午菴：いくつかパターンがありますが、まずは「ユーザーフィードバック」ですね。Sansanには、プロダクトごとにユーザーからのフィードバックを集約したSlackチャンネルがあり、お客様と接するフロントメンバーが、ヒアリングした要望や課題をSlackチャンネルに投稿してくれる仕組みがあります。 私たちPdMも常に目を通しているので、すぐに対応できそうなものは即座に企画として動かしています。次に、新規顧客の提案ベースで生まれるもの。「この機能がないから導入に踏み切れない」という場面で、クイックに意思決定して実装するというケースが結構あります。そして、将来的なプロダクトの方向性から逆算して「これをやるべきだ」という私たち自身の意志として考えるもの。あとは、ビジネス側からだけでなく、エンジニアから提案が上がることもよくあります。具体的には、パフォーマンス改善や将来の発展性を見据えた技術的な提案もありますし、ユーザーフィードバックを見て、「これすぐ対応できますよ」と自主的に拾い、課題や要件を整理してくれることもあります。そうした声を受けて、優先度を柔軟に組み替えることも多いですね。 ──AI活用によってプロセスはどう変わりましたか？ 午菴：企画プロセスの大きな流れは変わっていませんが、各ステップのスピードと精度が上がりました。 チームではClaude Codeを活用していて、議事録や社内ドキュメント、Slack、Salesforceなどあらゆる情報を参照しながら企画検討を進められるようになりました。提案資料やプロトタイプをクイックに作ってお客様に提案し、フィードバックをもとに修正してまた見せる——このサイクルが劇的に速くなっています。プロトタイプを作りながら企画を詰めていくので、企画が固まる頃にはある程度の体験も出来上がっている。結果として、新機能を届けるまでのスピードも上がってきていると感じます。実際の開発スピードも体感で2〜3倍くらいになっています。 以前は限られたリソースの中で「どれを優先するか」を必死に議論していましたが、今はAIによって開発スピードが劇的に上がり、「何を諦めるか」ではなく「いかに早く次の企画を生み出すか」という前向きな議論に変わりました。 ──以前別のインタビューで「簡単なUI改善ならPdMが自ら実装してリリースしている」と伺ったのですが、本当ですか？ 北野： はい、こちらの記事でも触れていますが、エンジニアだけでなく、PdMやデザイナーも影響範囲の限られた改善であれば自ら実装・リリースできるようにしています。AIを活用しながら、必要なチェックを経ればリリースできるルールを設けています。 PdMやデザイナーが自ら実装・リリースできるようになったことで、それまで開発リソースの都合で優先度を上げきれずにいたユーザビリティの課題をどんどん解消できるようになりました。そうした改善が進んだ結果、以前と比べてお客様からいただくフィードバックの純度が上がってきた感覚があります。表面的な問題が解消され、より本質的な課題にフォーカスが当たるようになってきた。 そうすると「事業を伸ばすために次に何をやるべきか」についての認識が、チーム内で自然と揃ってくるんです。これはAIを活用する前では得られなかった感覚で、興味深い発見でしたね。 エンジニアも法務も。“職種を越えて”プロダクトを作る ──エンジニア組織との距離感はいかがですか？ 午菴：エンジニアとの距離はかなり近いです。毎日のように誰かが私たちの席の隣に来て、気軽に話せる環境ですね。企画の早い段階からアーキテクトやエンジニアに入ってもらい、事業の状況や数字を共有しながら方針について議論しています。 だからこそ、技術負債の解消や将来の発展性を見据えた提案はもちろん、ユーザーフィードバックを拾って課題や要件を整理してくれることもあります。あとは、ミーティングの録画や議事録は全員がいつでも参照できる状態になっているので、自然と状況を把握して提案や相談をしてくれたり、ときには「これってどんな状況ですか？」という一言をきっかけに案件が動き出すこともあります。北野：入社して感じたのは、エンジニアがとにかく優秀だということです。技術だけに閉じず、事業がどうすれば伸びるかに強い関心を持っている。内部品質と事業インパクトのトレードオフが生じる場面でも、高いレベルでバランスよく判断している印象があります。新卒メンバーでもそういう視点で話をしているので、最初は驚きました。 ──職種を越えた連携という点では、法務担当との協業もユニークだと伺いました。 午菴：はい。法務担当のメンバーがドメインエキスパートとしてPdMのように企画から入り、さらに自らお客様の商談に同席して、熱量を持って提案することもあります。 AI時代に法務の業務がどう変わっていくべきかを自ら検証し、最前線で動いているんです。こうした職種の垣根を越えた連携は、Contract Oneの大きな強みですね。 「プロダクトで成果を出す」がPdMのミッション ──Contract OneにおけるPdMの役割はどう定義されていますか？ 午菴：以前、チームで「ミッションを言語化しよう」と話したときに、「プロダクトで成果を出す」という言葉になったんです。つまり、プロダクトで成果が出ることなら何でもやる、ということだと思っています。 企画をして、デリバリーのプロジェクトマネジメントをするのはもちろんですが、商談への同席も、展示会への参加も、社内で困っていることへの壁打ちも、デザインもやる。それぞれの得意なことを生かしながら、必要なことを必要なときにやっていくイメージです。北野： 実際、商談に同席する機会は多いですね。企画の方向性を考えるときにお客様の反応を直接見たいという目的で参加することもありますし、営業のメンバーから「提案に同席してほしい」と声がかかることもあります。 PdMの役割がきっちり定義されていないからこそ、そういう関係性が自然に生まれているのだと思います。私自身、お客様との接点が多い方が仕事しやすいタイプなので、こういう環境はとてもありがたいなと感じます。 ──AIが普及した時代に、PdMが担うべき価値とは何だと思いますか？ 午菴：AIの普及により判断材料が増え、スピードも上がりますが、どこに向かうかの意思決定は人の役割ではないでしょうか。 また、AIを活用することで生まれた時間を使って、一次情報をより取りにいけるようにもなりましたね。商談への同席もそのひとつで、そこでしか得られない
- プロダクトマネジメント
- 生成AI
- UIUX
Sansan Data Intelligenceが目指すデータの未来：プロダクト・エンジニアリング・ビジネスの三位一体で挑む新規事業
複数のシステムに散在するデータ、表記揺れや重複、更新漏れ。CRMとSFAで異なる情報が登録され、どれが正しいのか分からない。 こうした「データの信頼性」という構造的課題を解決するために生まれたのが、データクオリティマネジメント「Sansan Data Intelligence」です。Sansan Data Intelligenceは、Sansanが培ってきた名寄せ技術とSansan Organization Code（SOC）を活用し、企業が保有する取引先マスターのクオリティー向上を一気通貫で実現するプロダクトです。 2025年12月にリリースされ、現在はさらなるプロダクトの進化に向けた開発が進んでいます。今回は、Sansan Data Intelligenceに携わる3名——プロダクト戦略を統括する猿田、エンジニアリング組織を率いる多賀谷、そしてビジネスサイドからプロダクトマーケティングを担う鳴海に、Sansan Data Intelligenceの現在地と、この事業を一緒につくる仲間に求めるものを聞きました。 猿田 貴之（Sansan事業部 SDIプロダクト室 室長）Sansan Data Intelligenceプロダクト全体の方向性を統括し、プロダクトマネジャー・データサイエンティスト・デザイナーのマネジメントを担当。Sansan Data Intelligenceの立ち上げ前から一貫して携わり、2025年12月のリリースを経て、さらなるプロダクトの進化をリードしている。 多賀谷 洋一（技術本部 Data Intelligence Engineering Unit 部長）2025年12月のSansan Data Intelligenceリリースタイミングで入社。エンジニアがプロダクトマーケットフィットに集中できる体制構築や、より大きな役割を定義して任せる環境づくりを推進している。 鳴海 佑紀（Sansan事業部 Sansan DI推進部 副部長）Sansan Data Intelligence推進部にて営業・マーケティング・カスタマーサポートを統括。プロダクトマーケティングマネージャー（PMM）として、プロダクトをマーケットに届けるための全体設計と戦略策定を行う。Sansan Data Intelligenceの必要性を1年近く提唱し続け、立ち上げに至った経緯を持つ。 Sansan Data Intelligenceとは何か ──まず、Sansan Data Intelligenceを一言で説明するとどういったプロダクトですか？ 猿田：一言で言うと、お客様が持っている取引先マスターのクオリティマネジメントを実現するプロダクトです。もともとSansanには「Sansan Data Hub」という機能があります。これは名刺を起点に、集まったデータをCRMやSFAに流し込んで営業活動に使うというもので、主なユーザーは営業担当者です。一方でSansan Data Intelligenceが見ているお客様は、その手前で困っている人たち──情シス部門やDX部門、営業企画といった、全社のデータガバナンスを担う方々です。お客様の社内では、複数のシステムに同じ会社のデータがバラバラに登録されていて、表記揺れや重複、更新漏れが起きています。そのカオスな状態を、Sansanが持つ名寄せ技術とSOC（Sansan Organization Code／企業や事業所に対して付与される一意のコード）で整理し、クレンジングした上で足りない属性情報を補完する。 これを一気通貫で提供するのがSansan Data Intelligenceです。Sansan Data Hubが「名刺起点で営業をさらに強くする」プロダクトだとすれば、Sansan Data Intelligenceは「取引先マスター全体の営業DXの土台を作り、作り続ける」プロダクトになりますね。 顧客が抱えるデータ課題のリアル ──ビジネスの現場では、顧客のデータ課題はどのような形で見えていますか？ 鳴海： 特に多いのは、情報システム部門と営業企画・事業部門の方々からの相談です。前者は「データをクリーンに保ち続けたい」、後者は「データを使って事業戦略を考えたい」という欲求を持っていて、共通しているのは「社内のシステムにあるデータが全然信じられない」ということです。例えばCRMには昔の営業担当が登録した取引先情報が入っていて、SFAを見ると別の表記で書いてある。当社で言えば、創業時は漢字の「三三」で、今はアルファベットの「Sansan」ですよね。当時取引した会社のシステムには漢字の「三三」が残っているはず。その情報は間違ってはいないけれど、今は古い。こういうことが事業部門ごとのシステムで起きていて、もう何が正しいか分からない状態になっています。あるお客様は保有データが270万件あり、毎月5,000件ずつ増えていきます。こうなると、ショットで綺麗にすること自体がもう絶対に不可能ですし、次の日からデータは汚れていく。だからこそ、データそのものを継続的に維持する仕組みが必要なんです。さらに外部環境としてAI活用が求められる中で、「来月にはデータが綺麗になります」とか「ショットクレンジング頑張ります」では間に合わない。待ったなしのスピード感で、構造的に解決し続けるプロダクトが必要とされています。 Sansan Data Intelligenceのロードマップとビジョン ──プロダクトとして、半年から1年後にどういう世界を実現したいのでしょうか。 猿田： 短期的には鳴海が言った通りで、お客様の社内に散らばっているデータがちゃんと使える状態になり続けていることを「当たり前」にしたい。具体的には、SOCとその裏側にあるデータが今、570万法人・1,000万事業所をカバーできる規模に拡大しています。これをさらに増やしていくことで、「うちのデータでは識別できない」と言われていたお客様にも応えられるようになってきています。1年後の話をするともう一段やりたいことがあって、それは「AIが使えるデータの供給レイヤー」として位置づけられることです。皆さんがAI活用でいちばんつまずくのは、AIモデルの性能そのものではなく、AIに食わせるデータが揃っていないということだと思います。社内のデータがバラバラだったり、表記揺れしていたり、重複している状態では、どんな優秀なAIがあっても精度の高い回答は返ってこない。Sansan Data Intelligenceはそこを構造的に解決し続けるプロダクトでありたい。クレンジングされて、識別コードが振られて、会社情報や事業所情報がひも付いている—いわゆるAI-Readyなデータを、APIやMCPのような形で各社のシステムやAI環境に供給していく。「まずはSansan Data Intelligenceを通してデータ活用しよう」と思ってもらえる存在を目指しています。まさにSansanが掲げる「ビジネスインフラになる」というビジョンを実現する、インフラ側のプロダクトです。 エンジニアのマインドセットと技術的挑戦 ──プロダクトを支えるエンジニアチームは、どういうマインドセットで向き合っているのでしょうか。 多賀谷：大前提として、これは新規プロダクトであり、プロダクトマーケットフィット （PMF） させることが最優先です。だからエンジニアも、お客様や営業組織、カスタマーサクセス、プロダクトマネジメントといった他部門に積極的に染み出していって、一緒にPMFさせるという姿勢が重要です。技術的には、プロダクトのコアバリューを作る領域をしっかり見極めて丁寧に設計・実装しつつ、逆に既存システムがある部分は早く作れるアーキテクチャで進めようといった意思決定をしていく。そのバランス感覚がエンジニアのマインドセットとして大事なところですね。 ──ビジネス要件が技術そのものを変えた場面はありましたか？ 多賀谷： いちばん重要なのは「SOC v2」と呼んでいるデータアーキテクチャです。EntityとRelationshipという非常にシンプルな構造で、過去の履歴も含めた企業や事業所のデータ構造を表現できる。シンプルでありながら柔軟性が高い設計になっていて、ここがビジネスの競争優位性になっています。そのデザインを提案したドキュメントを見るだけでワクワクするような、そういうものですね。既存のSansan Data Hubのシステムもありながら、新しく作るところは完全に新しく、モダンなアーキテクチャになっていて、それが併存している。このビジネス要件と既存要件が技術判断に与えた影響は大きいです。 プロダクト・エンジニアリング・ビジネスの連携 ──エンジニアリングとプロダクト開発の連携は、具体的にどのように成り立っているのでしょうか。 猿田：Sansan Data Intelligenceでは、プロダクトマネジャーが所属するプロダクト側と、多賀谷率いるエンジニアチームで開発体制を組んでいます。大きな価値提供の単位としてEpicを定義し、その中にユーザーストーリーがあり、さらにその下にPBI（プロダクトバックログアイテム）がある。これを、基本的にエンジニアとPdMが一緒に作っていく運用です。単に「PdMが要件を書いて投げて、あとはエンジニアが実装する」という分業ではなく、Epicという大きな価値のレベルから一緒にリファインメントしていくのが特徴です。SOC v2のような技術的な設計議論にもPdMが入っていって、プロダクトの競争優位に関わる議論を一緒にしています。同時に、短期的な事業要求もすごく高いので、その両立をどう図るかは鳴海、多賀谷と一緒に常に議論しているところですね。SOC v2やSansan Data Intelligenceのアーキテクチャという大きなピクチャーを描きながらも、既存のSansan Data Hubのお客様をも新しい世界にお連れしたい。事業の計画とエンジニアリングの計画を綿密にすり合わせる必要があるので、そこはかなり難しいですが、やりがいのある部分です。多賀谷：別の観点で補足すると、エンジニアに対しては「シフトレフト」の考え方を推進しています。もともとはQAやセキュリティーの文脈で使われる言葉ですが、自分よりも前工程の方にどんどん染み出していこうと。さらに、Sansanが評価の仕組みとして採用している「ミッショングレード制度」では、グレードが上がるほど影響範囲を広げることが期待されています。 グループレベル、部署レベル、あるいは事業目線──次のグレードを目指して、より大きな範囲の仕事を任せ、その期待レベルで仕事をしていくように意識づけをしています。それによってエンジニア、プロダクト、営業組織が三位一体となって仕事できるマインドセットや環境を醸成しています。 部門間連携がもたらす効果 ──ビジネスサイドから見て、この連携体制にはどのようなメリットがありますか？ 鳴海：お客様に対する説明の解像度がぐっと高まるというのは、営業もCSもみんな感じていると思います。データ系のプロダクトなので、お客様からの質問が深いんですよ。「なぜこのデータを識別できないのか」「識別要件は何か」「データの更新頻度はどうか」──こういう技術的な質問を毎回持ち帰ってしまうと商談は長引くし、お客様の熱も冷めてしまう。でも当社のエンジニアの特徴として、現場から「なぜこの人はそういう質問をしたんだろう」と背景を聞いてくれる方が多い。コンテキストを間違えずにやりとりができるので、営業もその解像度で話せるようになります。 実際、社内でもトップ営業の人間はSansan Data Intelligenceやデータマネジメントに関して「すごく詳しいね」とお客様からコメントをもらえたりする。それはやはり、部門を超えて近い距離で協働しているからこそだと思います。あとは、部門を超えたマネジャー会議を毎週やっていたり、四半期に1回「ざっくばらんの会」と称して、エンジニアからビジネスサイドまで全員集まってピザを食べながら話す場を設けていたり。そういうマインド醸成も含めて、みんな前のめりで参加してくれるのはありがたいですね。 Sansan Data Intelligenceにどんな人が来てほしいか ──Sansan Data Intelligenceにどんな人に来てほしいか、それぞれの視点から聞かせてください。 多賀谷： まずは、新規事業を一緒に作るというマインドを持ったエンジニアです。ただ、新しいものを作るだけでいいかというと、そうではない。裏側はデータプロダクトなので、技術的に難しい領域でもあります。その高い技術水準にもチャレンジしつつ、新規事業としてビジネスも成立させる──その両立を目指せるエンジニアと一緒に働きたいですね。鳴海：お客様の業務やペイン──つまり痛みそのものに興味を持ってくれるかどうかが大事だと思っています。自分が企画するもの、自分が作るものが、お客様の現場の何を変えるのかを自分の言葉で語ってくれる人がいると、こちらも相談しやすいし、もっと情報を取ってこようという気持ちになります。もう一つ、新規事業なので「言われたから作ります」という受け身の姿勢だとスピード感が追いつかない。「これが必要だよね。これができたなら、次はこれも必要だよね」と、連鎖的に思考を巡らせてくれる方が入ってくれると、間違いなくフィットすると思います。猿田：補足するなら、「How」に
- 生成AI
- データ分析
- 組織運営
AI時代の今、Sansan Data Intelligenceで働く魅力
この記事は、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通信は <a href="https://connectrpc.com
- Go
- Next.js
- TypeScript
- Google Cloud
- 生成AI
2026年6月技術イベント予定
Sansan株式会社では、技術イベントや勉強会の主催・登壇・協賛を行っています。 各イベントの詳細については、以下のリンクからご確認ください。 ※開催状況により、すでに受付を終了している場合がございます。 ※掲載している内容は公開当時の情報です。最新情報は各イベントページをご確認ください。 イベント開催情報 2026/06/17(水) h4 a { color: #1487BD !important; text-decoration: none !important; font-weight: 700; } h4 a:hover { color: #0E5F8F !important; } 食べログ x ANDPAD x Sansan モバイル勉強会 #4 食べログ、アンドパッド、Sansanが共催するMobile勉強会です。 今回のテーマは「OS・アップデート」。OS 標準 API の進化や UX 改善の話から苦労話まで、モバイル開発ならではの知見を共有します。 開催日時：2026/06/17(水)19:00 〜 21:30 開催場所：Sansan株式会社 本社 参加方法：https://andpad.connpass.com/event/395841/ 協賛情報 2026/06/08(月)～06/12(金) h4 a { color: #1487BD !important; text-decoration: none !important; font-weight: 700; } h4 a:hover { color: #0E5F8F !important; } 2026年度 人工知能学会全国大会（第40回）（JSAI2026） 2026年度 人工知能学会全国大会（第40回）（JSAI2026）に、Sansan株式会社はプラチナスポンサーとして協賛します。 また、ポスター発表2件と口頭発表1件を行います。Sansanブースもありますので、ぜひお立ち寄りください。 ■ポスター発表 ① RT-QMC: 順序変換を用いた準モンテカルロサンプリングによるロバストな初期学習データ選択 発表者：田柳 俊和 セッション会場：Y会場（展示ホールAB-1） セッション日時：2026年6月8日（月）16:10 ～ 17:40 講演番号：1Yin-B-10 ② スキャン文書画像を用いたページ欠落検出手法の検討 発表者：宮本 優一、吉村 皐亮 セッション会場：Y会場（展示ホールAB-1） セッション日時：2026年6月8日（月）16:10 ～ 17:40 講演番号：1Yin-B-21 ■口頭発表 GITによる複数ページ請求書の文脈を考慮したページ単位画像分類 発表者：ライ シンユ、本田 悠太郎 セッション名：非構造データからの情報抽出（OS-19） セッション会場：F会場（メインホールB） セッション日時：2026年6月9日（火）15:30 ～ 15:45 講演番号：2F5-OS-19a-01 フォローお願いします！ Sansanの公式アカウントでは、最新のイベント情報をいち早くお届けします。 ぜひフォローしてください！ X： @SansanTech connpass：Sansan株式会社
- iOS
- Android
- 機械学習
- 生成AI
勉強会「自社で育てるLLM/VLM/VLA：学習・活用の実践知」 実施報告
Sansan株式会社 技術本部 研究開発部の齋藤です。 2026年3月26日に勉強会「自社で育てるLLM/VLM/VLA：学習・活用の実践知」を、Sansan株式会社、株式会社ABEJA、株式会社松尾研究所の3社共同にて開催しました。 sansan.connpass.com 本ブログでは、勉強会の様子をご紹介します。 本勉強会の背景 本勉強会では、LLM、VLM、VLAなどのモデルを自社でファインチューニングし、活用している方、あるいは予定している方にご登壇いただき、それぞれの取り組み内容や、実践を通じて得られた知見を共有していただきました。 生成AIのAPIを活用する形とは異なり、LLM、VLM、VLAを自社でホストする場合には、さまざまな課題があります。そうした課題に対して各社がどのように向き合い、工夫しているのかを共有することで、日本企業におけるLLM、VLM、VLAの活用に少しでも貢献できればと考えています。 登壇内容 今回はSansan株式会社、株式会社ABEJA、株式会社松尾研究所からそれぞれ1名が次のタイトルにて登壇を行いました。 登壇タイトル 登壇者 VLAモデル間におけるピック＆プレース性能の比較評価 株式会社ABEJA DP開発本部 データサイエンス部 データサイエンス2G ロボティクス・基盤モデル強化T チームリーダー／瀧田浩平 メール検索に特化したエージェントの強化学習 株式会社松尾研究所 共同研究チーム シニアデータサイエンティスト／太田幹 契約書からの情報抽出を行うLLMのスループットを、バッチ処理を用いて最大40%改善した話 Sansan株式会社 研究開発部 シニアリサーチャー／齋藤慎一朗 VLAモデル間におけるピック＆プレース性能の比較評価（株式会社ABEJA DP開発本部 データサイエンス部 データサイエンス2G ロボティクス・基盤モデル強化T チームリーダー／瀧田浩平） LLMやVLMの技術を応用し、自然言語の指示理解やロボットの視覚認知、高度な運動制御を実現するVLA技術について、論文評価だけでは見えにくい実環境での精度や挙動の違いを調査されていました。さらに、ロボットアームの実際の動きを動画を用いて発表されていました。 普段の私の業務では触れることがないVLA技術に関する実体験を聞くことができ、将来性を強く感じました。また、学習したモデルを搭載したロボットアームを勉強会会場に持ってきていただき、場が盛り上がりました。 メール検索に特化したエージェントの強化学習（株式会社松尾研究所 共同研究チーム シニアデータサイエンティスト／太田幹） メール検索に特化したエージェントを自社で強化学習し、フロンティアモデルと同程度の軽量モデルを構築する方法を紹介されていました。またどのような学習ツールを用いたか、どのような試行錯誤を経て実験を進めたかについても語られていました。 詳細は松尾研究所さんの次のブログにて公開されています。 zenn.dev エージェントを自分で学習しようとしたことがなかったため、従来の機械学習モデルの学習方法と、エージェントの学習方法の違いが面白いと思いました。また、今回の検証の条件において、フロンティアモデルよりも精度、速度が上回るエージェントを構築されていたことに驚きました。 契約書からの情報抽出を行うLLMのスループットを、バッチ処理を用いて最大40%改善した話（Sansan株式会社 研究開発部 シニアリサーチャー／齋藤慎一朗） 私からは、ファインチューニングしたLLMをvLLMで運用する際に発生していたタイムアウトエラーを、バッチ処理を活用することで削減した事例を紹介しました。特に、バッチ処理を導入したことでスループットを最大40%改善できた点について共有しました。何を計測し、どのような判断のもとでバッチ処理を採用したかの思考の流れについて詳しく発表しました。 資料は以下です。 speakerdeck.com 懇親会 懇親会では軽食と飲み物を片手に、多くの参加者とお話ししました。特に、APIで運用しているモデルを自社での運用に切り替える際の進め方に困っている方が多かったと感じました。 最後に 本勉強会は定期開催を予定しており、次回は夏頃の開催を企画しております。実施の際には改めて告知します。 また、Sansan技術本部ではカジュアル面談を実施しています。 Sansan技術本部での働き方、仕事の魅力について、現役エンジニアの視点からお話しします。「実際に働く人の話を直接聞きたい」「どんな人が働いているのかを事前に知っておきたい」とお考えの方は、ぜひエントリーをご検討ください。
- 生成AI
- LLM
- 機械学習
AI駆動開発でContract Oneをビジネスインフラへ。「やり切った」の先にある新たな挑戦
キャリアは、選択の積み重ねでできています。 どんな経験を経て、なぜSansanを選び、いまどんな挑戦に向き合っているのか。 「Sansan 3 Stories」では、これまでの歩みと、実際にSansanで働いて感じたこと、そしてこれからの挑戦を「過去・現在・未来」の3つのストーリーでお届けします。今回のインタビューでは、外資系企業やスタートアップで数々の開発組織をけん引し、現在は「Contract One」でAIを活用した開発の最前線に立つのペトラスに話を聞きました。 ペトロ ペトラス / Petras PetroškevičiusContract One Engineering Unit日本でデータベースマーケティング企業を共同創業し、CTO兼取締役として電通へ売却後、日本最大の携帯電話保険代理店のエンジニアリングチームとシステムをゼロから構築。外資系大手生命保険会社のアーキテクチャの近代化や、手書きAI-OCRクラウドサービスのR&D、地図広告配信プラットフォーム構築とエンジニアリング組織立ち上げをリードした。 2026年にSansan株式会社に入社。AIを活用した契約管理プロダクトの設計・開発に携わりながら、エンジニアリング組織のマネジメントも担っている。 Story 1 過去｜「やり切った」の先へ。次の挑戦を求め続けたキャリア ──これまでのキャリアについて教えてください。 ペトラス：元々はリトアニア出身で、大学では物理学を専攻していました。 当時、日本の半導体技術は世界的にも有名で「日本語を覚えれば、日本の技術論文や特許を直接読めるようになるかもしれない」と思ったのが日本語を学び始めたきっかけです。大学を卒業する頃に日本で仕事が決まり、そこから20年以上日本で働いています。来日した時はちょうどインターネットブームで、自分で会社を立ち上げてデータベースマーケティングの事業を行い、最終的には事業売却も経験しました。その後は、外資系生命保険会社でアーキテクチャチームを立ち上げたり、100億円規模のシステム刷新プロジェクトに携わりました。また、大手通信キャリア向けの携帯電話の保証サービスの事業にも携わり、日本市場向けにエンジニアリング組織もシステムもゼロから作り、最終的には数千万人規模のお客さまに利用いただくサービスへと成長しました。その中で100名規模の組織づくりやCTOも経験しています。その後も、AI-OCRクラウドサービスのR&Dヘッドを務めたり、直近では地図広告プラットフォームの構築やエンジニアリング組織立ち上げにも関わったりと、常に新しい技術と事業に向き合ってきました。 ──さまざまな経験を積まれてきた中で、転職を考えるタイミングには共通点があるのでしょうか。 ペトラス：「やり切った」と感じたタイミングですね。事業が大きく成長して、自分の中でもある程度やるべきことをやり切ったと感じると、「次はどんな挑戦をしようか」と自然に考えるようになります。たとえば、携帯電話の保証サービスの事業では、最終的に全国規模まで成長しました。そこまでいくと、新しい挑戦が必要になる。常に、「次にどんな課題へ向き合うか」を考えてきた気がします。 ──数ある選択肢の中で、なぜSansanを選んだのでしょうか？ ペトラス：会社を選ぶときに、私が大事にしていることは3つありました。1つ目は、自社プロダクトを作っていること。業務課題に対して、自らプロダクトを開発して解決しようとしている会社に魅力を感じていました。2つ目は、最新技術を積極的に取り入れていること。エンジニアにとって、新しい技術を使える環境はとても重要です。そして3つ目が、エンジニアリングに本気で投資している会社であること。Sansanは、採用も含めて技術への投資が非常に強く、成長に対する強い意思を感じました。AIの波が本格的に来たタイミングで、これまで自分が経験してきた「スタートアップでのスピード感」「大規模システムの厳格さ」「AIを活用した開発」、これらを生かせる場所を探していたんです。そんな中でContract Oneに出会い、すぐに興味を持ちました。 単に契約書を管理するためのツールではなく、AIを活用しながら契約データを横断的につなぎ、企業活動における「Single Source of Truth（信頼できる唯一の情報源）」になろうとしている。その思想に強く惹かれました。さらに、経営陣やContract Oneのメンバーと話した時に、昔スタートアップを立ち上げていた頃と同じ熱量を感じたんです。「テクノロジーでビジネスを変えたい」という強い意思がある。そこも、Sansanを選んだ大きな理由でした。 Story 2 現在｜AIで開発サイクルを最速化。変わり始めたエンジニアの役割 ──現在、どのようなプロダクトや課題に向き合っていますか？ ペトラス：現在、全社の契約書をデータ化し、一元管理できる「Contract One」というプロダクトのエンジニアリングチームを率いています。Contract Oneは、すでにARR（Annual Recurring Revenue／年間経常収益）10億円を突破した急成長中のサービスです。プロダクト紹介資料より私たちは今、AI時代を見据えた検索機能やAIチャット、さらには、AIエージェントが自律的に契約データへアクセスし、活用できるようにするための「MCP」の開発も進めています。また、「何を作るか」だけでなく、「どうやって作るか」というテーマにも向き合っています。AIの最新手法を活用しながら、いかに開発サイクルを最速で回していくか。ここが今、大きなテーマです。 ──最速で開発サイクルを回すために、どのようなことに取り組んでいるのでしょうか？ ペトラス：Contract Oneではすでに、ビジネスサイドとエンジニアの境界線がなくなってきています。プロダクトマネジャーがAIツールを使って、「UI変更」や「簡単な機能変更」などの機能開発ができるようになっています。 一方で、エンジニアもAIを活用してプロダクトの利用状況などを分析し、自ら新しい機能の起案を行うことが当たり前になってきています。こうした動きを可能にしているのが、自社開発した独自のAI駆動開発のプロセスとツール群です。AIを用いて膨大なコンテキストを収集し、コード生成まで含めて開発サイクルを高速化する取り組みを進めています。しかし、ただ早く開発するだけでは品質やセキュリティーのリスクが高まります。 そこで、これらを「安全に」実現するために、開発プロセス全体を8つのフェーズに分解し、それぞれのフェーズについてプロセス、ツール、基準、リスクレベル、成熟度モデルを定義しています。開発プロセスについては、こちらのTech Blogでも紹介しています。 buildersbox.corp-sansan.comこれにより、プロダクトの課題発見やアイデアの起案から、実装、運用検知までの一連の流れを「誰でも進められる仕組み」にしています。重要なのは、開発プロセスの中からいかに人間の介在を減らし、AIを活用して高速に回せるかです。そうすることで、アイデアからリリースまでの時間を大幅に短縮できるようになっています。 ──AIがあることで、ペトラスさん自身の働き方やモチベーションに変化はありましたか？ ペトラス： 以前は、身につけた技術を使って勝負していました。 でも今は、それがかなり簡単になり、自分で作れる生産量が圧倒的に増えました。エンジニアって、やっぱり作ったものが動いていることを見るのが一番楽しいんです。 今は作ろうと思えばほとんどのものが作れちゃうので、自分のキャリアの中でも今が一番楽しい、一番ハッピーな時期ですね。 Story 3 未来｜AI時代のビジネスインフラをつくる、新たな挑戦 ──今後、Sansanでどんなことにチャレンジしていきたいですか？ ペトラス： Contract Oneを、企業の利益を守る「AI契約データベース」としてさらに進化させていきたいと考えています。これまで人が契約書を読んで、確認して、管理していたものを、今後はAIエージェントが人に代わってやっていくことになるでしょう。ほとんどの企業の既存のシステムが「人間が使うこと」を前提に作られていて、AIエージェントがそのまま使える状態になっていません。そこに大きなビジネスの可能性があると考えています。 契約のライフサイクル全体をAIエージェントが理解し、人間の代わりに仕事をこなす世界を目指したいと考えています。今はどの会社も同じようなツールやAIモデルを使える時代です。市場調査をしてビジネスアイデアを出して、同じようなスピードで開発することができますが、だからこそ最終的に重要になるのは「データ」だと思っています。Sansanの強みは、企業・組織・個人のデータに加え、Bill Oneの請求・発注データ、そしてContract Oneの契約データまでを扱っていることです。企業の一連のビジネスの流れを掴めることは、他社に真似できないSansanの強みだと考えています。Sansan全体のデータ基盤を生かした横断的なプラットフォームとして価値を出していきたいですね。 ──最後に、今後どんな人と一緒に働きたいですか？ ペトラス：最新技術をキャッチアップしていることはもちろんですが、AIをはじめ、フロントエンド、バックエンド、インフラまで幅広く興味を持ち、ユーザーの課題を自ら考えながらプロダクトを作れる人と一緒に働きたいですね。今のContract Oneでは、エンジニアも単に実装するだけではなく、プロダクトの企画や課題整理にも深く入り込んでいます。実際に、まだ詳細化されていないアイデアを、週単位でエピックとして形にしていくような動き方も増えています。このように、エンジニアもただ作るだけでなくプロダクトマネジャーの領域に踏み込んでおり、両者の境界線はどんどんなくなってきています。 おそらく半年も経つと、もう完全に同じチームになっていると思いますね。新しい技術を使いこなし、AI駆動開発のプロセスを確立しながら、ユーザーの課題の本質に向き合っていく。そして、次世代のビジネスインフラを共につくり、業務とエンジニアリングの未来を変えていきたいと思っています。 今のSansanは、本当に可能性の最前線にいます。 Sansanでは一緒に働く仲間を募集しています！ Sansanでの働き方や仕事の魅力などについて、実際に働くメンバーがお話しします。 少しでも興味を持っていただけた方は、ぜひカジュアル面談にお申し込みください！ 関連する求人 open.talentio.com open.talentio.com</ci
- 生成AI
- DevOps
- 組織運営
新卒エンジニア向けに情報セキュリティ研修を行いました［2026年版］
こんにちは。情報セキュリティ部 Product Securityグループの北澤です。 昨年に引き続き、新卒エンジニア向けに研修を行いました。この記事では、本年度の研修内容についてお伝えします。 研修について 昨年と同じく、丸一日かけて実施しました。 研修スケジュール 基礎編では、Web、インフラやモバイルなどの領域を問わず必要な情報セキュリティーの基礎に関する講義を行いました。午後にはSQL InjectionやXSSなどをはじめとしたWebアプリケーションに関する攻撃手法とその防衛について講義を行いました。 講義内容 基礎編 午前中は基礎編の講義を行いました。 最初にそもそも「情報セキュリティ」とは何か？ から始まり、対策をしない場合はどのような被害が考えられるのか？ Webサービスを公開していると実際にどの程度攻撃が行われるのか？ ということをお話ししました。 そこから、対策するためには何を知るべきか？ 脆弱性とは何か？ 脆弱性情報を渡されたときにリスクと対応優先度をどう考えればいいのか？ という実際の現場で直面するだろう課題と考え方について講義を行いました。 また、Claude CodeやCodexなど、AIエージェントの活用が加速している現状を鑑みて、昨年の内容に加え、AI周りのセキュリティについても触れるようにしました。内容としてはローカルでAIエージェントでコーディングを行う際に注意すべき点、プロダクトにAI機能を組み込む際に気を付けるべき点の二つについて話をしました。 いくつか資料を紹介します。 情報セキュリティとは 機密性についてのスライド 可用性についてのスライド 対応優先度を考える上で大切な項目 深層防御／多層防御 を説明するためのたまねぎ Web編 午後はインジェクションなどWebサービスに埋め込んでしまいやすい問題について、項目ごとに脅威・攻撃手法・対策についての講義を行いました。具体的には以下です。 SQL Injection XSS 認証不備 認可不備 SSRF CSRF 設計に関する問題 コンポーネント（ライブラリなど）に関する問題 ログに関する問題 暗号化の不備 SQL Injectionの概要の説明 SQL Injectionの影響と対策について XSSの概要の説明 昨年との違いとしては、内容に応じてローカルでハンズオン用アプリケーションを動かしてもらい、実際に講義ごとに攻撃を体験してもらうようにしました。 SQL Injectionのハンズオン操作説明スライド ハンズオンアプリケーションに攻撃ペイロードを送信しようとしている画面 攻撃ペイロード送信によって、パスワード無しでadminにログインできてしまった状態 裏話ですが、ハンズオンのアプリケーションは実験的にAspireを使い、開発や立ち上げが楽になるようにしてみました。SSRFのような複数アプリケーションを扱うものや、SQL Injectionのようにアプリ+postgresというDBコンテナを扱うものに対してはかなり開発体験が良かったですね。 aspire.dev 新卒のメンバーにアナウンスする際も、「Hostプロジェクトディレクトリでdotnet runしてね」で済むのでめちゃくちゃ楽でした。 CSRFは実際に攻撃されることの体験をして欲しいなと思っていたので脆弱な簡易SNSサービスと罠サイトである出席確認サイトを用意してみました。 簡易SNSサービスにログインしてもらった状態で、罠である「出席確認」のボタンを押してもらい、裏でスクリプトが動き、「ざわさんにごはんおごります！」という意図しない書き込みが簡易SNSに対して行われることを体験してもらいました。（ざわさんとは講師である私のことです） CSRF体験用の簡易SNS 簡易SNSにログインした状態で出席ボタンを押すと 罠サイトの出席確認システム画面 講師にごはんをおごる内容がSNSに投稿される。新卒のみなさん、ごちそうさまです。 ざわさんにごはんおごります！が投稿されます。 「やられた～」という声もあがり、実際にCSRF脆弱性を作り込んでしまったときの怖さをわかっていただけたかなと思います。 脆弱性について話したあとに、脆弱性を防ぐ・発見するためのセキュアな開発プロセスについて講義を行いました。 セキュアな開発プロセスの大事さについての説明スライド 設計時には設計時の、実装時には実装時に必要な対策をする、といった内容です。 設計時の問題がリリースギリギリになってわかるものほど悪夢的なことはないので、それを防ぐためにそれぞれの工程ごとにどのような検証を行う必要があるかについて話しました。 CTF Web編の後には楽しみながら実践的に知って記憶をしてもらうためのCTF（Capture the Flag）を行いました。昨年と同じく、攻撃対象のアプリケーションはASP.NET Coreで自前で用意し、スコアサーバにはCTFdを利用しました。 簡単なSQL InjectionからBlind SQL Injection、XSSによる管理者セッション窃取やjwtのalg:noneまでとさまざまな難易度の問題を用意し、挑んでもらいました。 CTFでは実際の攻撃者の動きを学んでもらうことを心がけました。 例えば、XSSではただアラートを表示させるなどではなく、実際に管理者にその画面を送信し、管理者のセッションを奪取してログインするという、より本格的な導線を用意していました。 CTFのXSS1問題 以下ブログ用画像のためにローカルで動かしています。 サンドイッチショップの検索バーでalert()を表示させるスクリプトを記述している <figure class="figure-image figure-image-fotolife" title=
- セキュリティ
- 生成AI
- 研修
SETチーム3年間の歩み。Playwright導入からAI自動化の到達へ
はじめに 技術本部 Quality Assurance Engineering Unitの杉本です。SETチームが発足したのは2023年6月。あれから3年が経ちました。最初の成果については以前SETチーム始動 Playwrightで実現した最初の成果 - Sansan Tech Blogで紹介しているので、本記事ではそこから先、この3年で積み上げてきたものと、直面した難しさ、そしてこれからの展望について書いてみようと思います。3年というのは、振り返ってみると短いようで長い時間でした。フレームワークの選定から始まり、社内への展開、そしてAIエージェントによる自動運用に至るまで、技術の話だけでなく組織や制度、QAという職能の意味合いまで考え続けた3年でもありました。少し長くなりますが、お付き合いいただけるとうれしいです。 この3年でやってきたこと 1. 始まりはBill Oneビジネスカードから 詳しくは前述の記事に譲りますが、ざっくり振り返ると、2人体制でスタートしたSETチームは最初の四半期でBill OneビジネスカードのE2Eテスト自動化を完了させ、2人で半日から1日かかっていたリグレッションテストを15分まで短縮することができました。E2EテストフレームワークにはPlaywrightを選定し、Page Object Model（POM）を採用。「プロダクトエンジニアもE2Eテストを書く」という思想を軸に据えた、最初の小さな成功体験でした。Bill Oneビジネスカードを最初の対象に選んだのは、当時リリースされたばかりのサービスだったからです。今後機能がどんどん追加されていくフェーズで、リグレッションテストの負荷もこれから急増していくことが見えていました。自動化の投資対効果が一番高いプロダクトを狙った、という言い方もできます。 2. プロダクトへの横展開 Bill Oneビジネスカードでの成果を皮切りに、当社の主要プロダクトへPlaywrightを広げていきました。順序としてはまずBill One全体に波及させ、続いてSansan、Contract One、Eightの順で展開しました。主要4プロダクトすべてにPlaywrightが入っている状態を、3年かけてつくることができました。プロダクトごとに使用言語も文化も異なる中で、ひとつのフレームワークでここまで横断できているのは、社内でもあまり例を見ないことだと思います。とはいえ、横断するうえで一番の壁は技術ではなく文化でした。「テストにどれだけコストをかけてよいのか」という考え方が、プロダクトによって本当に違うのです。リリース速度を最優先するプロダクト、自動テストへ手厚く投資したいプロダクト、業務委託の方による手動テストを中心に回しているプロダクト。それぞれに事情があり、それぞれに正しさがあります。加えて、各プロダクトはエンジニアの人数も業務委託の方の人数も多く、役割分担も異なるため、ステークホルダーが非常に多くなりがちです。誰がE2Eテストを書き、誰がメンテし、誰がレビューし、誰が壊れたときに直すのか。こうした役割を、プロダクトごとに改めて握り直す必要がありました。技術的にPlaywrightを入れるよりも、この合意形成のラウンドを回すことのほうが時間も気力も使った、というのが正直なところです。さらに、主要4プロダクトに加え、Sansan Labs、Auth One、デジタル名刺メーカーといった周辺プロダクトにもPlaywrightが入っていきました。SETはレビューや初期セットアップの支援といった形で関わり、結果として社内でPlaywrightが使われる範囲はじわじわと広がっていきました。 3. プロジェクト型Jump!という仕組み・人の課題に向き合う ここまで書くと拡張が順調に進んだように聞こえますが、横展開を進めるうえで一番の壁はやはり人の問題でした。SETチームに入りたいという人は決して多くなく、採用も簡単ではありません。そこで、期間限定で他部門からSETに移動し、もとのプロダクトに戻っていく仕組みを導入しました。当初は「留学制度」と呼んでいた仕組みですが、その後社内で整備が進み、現在は「プロジェクト型Jump!」という名称になっています。プロジェクト型Jump!は4カ月という期間で、これまでにContract Oneから1名が参加してくれました。Jump!参加者がContract Oneに戻ってからは、同プロダクトに自らPlaywrightを導入・運用するというサイクルが生まれ、SETチームが直接書かなくてもPlaywrightが広がっていく動線をつくることができました。体験談の記事もどうぞ。Jump into puddles〜SETエンジニアに転生してみた件〜 - Sansan Tech Blogただし、この仕組みで一番難しいのは技術ではなく評価の部分です。本人が一時的に所属している部門から外れるため、誰と・どのように評価を握るのかをあらかじめ決めておかなくてはなりません。さらに、4カ月間で何を達成できたら成功と言えるのかというゴール設定も、事前に合意しておく必要があります。これらを曖昧にしたまま走り出すと、本人が一番苦しむことになります。仕組みとして整備された今も、ここは毎回丁寧に握る必要があると感じています。 4. 少人数で広げきったこと 人の話でもう一点、誇りに思っていることがあります。この3年、SETチームは業務委託の方に入っていただく時期もありましたが、コアメンバーは入れ替わりを繰り返しつつも基本的に3人前後で推移してきました。3人前後で主要4プロダクトと周辺プロダクトをカバーし、さらにプロジェクト型Jump!を展開し、後述するAIエージェント群まで構築できたことは、素直に誇れる成果だと思っています。少人数だからこそ、自分たちだけで継続することを早々に諦め、留学制度やAIへと思想を寄せられたとも言えます。3人ですべてのプロダクトの手を動かそうとした瞬間に破綻するので、必然的に「自分たちで書かない仕組み」をつくる方向に振り切ることができました。 5. ジョブディスクリプションを作り続けたこと ここはあまり外に出してこなかった部分ですが、SETでは3年の中で「自分たちはどうあるべきか」というジョブディスクリプションをメンバーと何度も協議し、アップデートし続けてきました。バージョン1、2、3、3.1、3.2と、合計5回作り直しています。メンバーの入れ替わりがあり、横断するプロダクトが変わり、AIという前提が登場し、走りながら考えが変わる部分もある。だからその都度メンバーと話し、「何をやるべきか」「何をやらないべきか」を必ず再定義して進めてきました。SETの根本にあるのは「技術で品質を保証する」というシンプルな思想で、その品質がいかにエンジニアに届き、会社のバリューとして外に出ていくのか。そこを常に問い直してきました。技術選定や成果物よりも、このジョブディスクリプションを5回書き直してきたことこそが、3年で一番大事な営みだったと、いま振り返って思います。 6. AIによる自動生成と自動修復 そして、直近の大きな進展がAIの活用です。 きっかけ 正直に書くと、AIに踏み切ったきっかけは綺麗な話ばかりではありません。ひとつには、業務委託に依存している部分のリソースコストを最適化したい、という現実的な事情がありました。もうひとつは、QAがボトルネックと言われがちな構造があり、本当にボトルネックだったかどうかは別として、そう言わせない状態をつくる必要があった、ということです。速度を上げるための自動化、その自動化を回し続けるためのAI、という順序です。開発中に、PlaywrightからAgent機能が公式リリースされました。世界中で同じ方向に走っている人がいるとわかり、自分たちの方向性は間違っていなかったと確信できた瞬間でもありました。Playwright Agentsについては別記事で詳しく書いていますので、興味のある方はそちらもご覧ください。Playwright AgentsでE2Eテストの民主化を実現する - SEED構想の提案 - Sansan Tech Blog 仕組みの全体像 日々のメンテナンスのため定期実行を回し、結果はGitHub ActionsでSlackとNotionに連携、Notionにスタックされていく仕組みを構築しました。そのうえで、Generator系とOperation系という2系統のエージェントを実装しています。 Generator・テストコードを書くエージェント Generatorの役割は、Notionのテスト仕様DBに書かれたテストケースから、実際に動くPlaywrightのテストコードを生成し、PRとして上げるところまでを一貫して行うことです。具体的には次のような流れになります。仕様取得 → 新規ブランチ作成 → コーディング（UIコンポーネントの扱い、要素特定、テストデータ生成・識別などのSkillsを参照）→ 検証ループ（実際にPlaywrightで走らせる）→ 静的解析 → コードレビュー → PR作成。ポイントは、コード生成をワンショットで終わらせていないことです。生成→実行→エラー→修正、を内部で何度も回し、最終的に全テストが通った状態のものだけがPRに上がるように設計しています。さらに、UIコンポーネントの扱い方や要素特定の作法、データ生成・データ識別といったテスト固有のノウハウを「Skill」としてMarkdownで切り出し、エージェントが必要に応じて読み込む構造にしています。プロダクト固有の構造情報（Page Objectやアーキテクチャ）も別途定義してあり、テスト技法とプロダクト知識を分離するという設計思想を取っています。 Operation・エラーを仕分けし、原因を追い、自動で直すエージェント群 Operation側はGeneratorよりさらに分業されていて、実際にはSorter、Tracer、Healerの3つのサブエージェントが連携して動きます。1つ目がSorterです。定期実行で出たエラーログをNotionから拾い、既存の修正チケットとの類似性を判定します。エラーが新規なのか、過去に起きていたものの再発なのかを見極め、新規なら新規チケットを起票し、既存なら同じチケットに発生日情報を追記します。これで「いつ、何回起きているエラーなのか」が自動で蓄積されていきます。2つ目がTracerです。エラーがLocator系やAssertion系のものであれば、フロントエンドリポジトリのGit履歴・PR・Notion上のPBI（プロダクトバックログアイテム）を辿り、対応する変更を探します。スコアリングして「仕様変更の可能性が高い／可能性あり／手動調査推奨」のいずれかを判定し、仕様変更であれば修正提案まで生成します。3つ目がHealerです。Tracerが出した修正提案を、Git worktreeで隔離された環境に適用してPlaywrightで実行し、通ればそのままPRを作成します。失敗すればチケットに失敗理由を残します。つまりSorterで「これは仕様変更か不具合か」を見立て、Tracerで「どのコミット・PRが原因か」を突き止め、Healerで「直してPRを上げる」までを自動でやる、ということです。仕様変更による壊れは自動で修復され、不具合の可能性があるものだけ人間にエスカレーションされる。そういう運用フローになりました。結果として、テストコードの生成も、実行後のエラー仕分け・原因追跡・修復も、ほぼ自動化することができています。なお、このAI運用の取り組みは2026年3月のJaSST'26 Tokyoでも発表しました。生成AIで支える自動E2Eテストの継続運用 - Speaker Deck 苦労したこと 1. コスト削減というものさしのズレ E2E自動化はどうしても、時間短縮、リソース削減という文脈で語られがちです。確かに最初の成果はそこに表れますし、わかりやすい指標でもあります。ただ実際にやってみるとわかるのですが、テストコードのメンテナンスにかかるコストは決して小さくありません。QAの世界では、品質が良くなったことを数値で表すのが本当に難しいです。だからこそ、自動化率やテスト工数の削減といった、目に見えやすい指標が成果として持ち上げられがちで、それが本来の目的だと勘違いしてしまう人も少なくありません。結果として、とにかく自動化を進めようという案がどんどん上がってきます。けれど、その自動化したテストを誰がメンテし、何回実行し、どんな安心を担保するのか。その先の未来についてはあまり語られないのです。なので、SETに自動化してほしいという依頼が来るたびに、同じような会話を繰り返してきました。何回実行することを想定しているのか、そのテストが壊れたとき誰が直すのか、本当に自動化すべきシナリオなのか。中にはこちらがやりたくないだけと受け止めた人もいたかもしれません。それでも、先述した通り、ジョブディスクリプションのおかげで、SETとしての方針は3年間ぶれていません。コスト削減ではなく、何度も繰り返し実行できることそのものが価値である。この強い気持ちで言い続けてきました。繰り返し実行できることのメリットは、「いつもの仕様通りに動いている」という確認になり、担当者が代わっても安心できる土台になることです。コスト削減が結果的についてくることはあっても、それを目的に置くと、メンテコストとの綱引きで必ず破綻します。 2. 横断ゆえの限界 SETチームは各部門を横断する形で動いていますが、本来E2Eテストのコードを一番うまく書けるのは、そのプロダクトを深く知っているプロダクトエンジニアです。横断チームが3人前後で書き続けるモデルには構造的な限界があり、プロジェクト型Jump!の整備や、AIによる自動修復の構築は、この課題への現実的な回答でもありました。 3. 副産物としての発見 苦労ばかりではなく、副産物として得られたものもあります。E2Eテストのコードが、実質的に仕様書として機能する場面です。「検索した後に検索ウィンドウが表示されなくなった」というような、ドキュメントに落とし込まれておらず、人の記憶も曖昧な仕様について、E2Eテストのコードを読めば過去の挙動がわかる。これは当初想定していなかった効用でした。 3年間で自分自身に起きたこと 少しだけ個人的な振り返りをさせてください。私はもともとプロダクト開発を長くやってきた人間です。QAというポジションに就いていなくても、品質に頭を悩ませることはずっとありました。ただ、QAとしてのポジションに移り、第三者の視点から改めて品質を問い直す機会を持てたことは、自分にとって本当に良かったと感じています。JSTQB Foundation Levelも取得しました。正直に書くと、シラバスが直接実務で役に立つ場面はあまりありませんでした。テストケースありきでテストコードを書いてきましたし、プロダクト開発で品質に向き合ってきたため、テスト観点自体が大きく変わるということもありませんでした。ただ、JSTQBを通じてひとつ強く理解したことがあります。テストという行為に対して、人類はかなり体系的にナレッジを積んできているということです。シラバスに記された膨大な観点・技法・用語の整理は、それ自体が知の蓄積です。そして、ここから先の話なのですが、この体系的なナレッジをAIに持たせれば、AIはテストに関してもっと賢くなれるはずだ、ということもこのタイミングで実感しました。JSTQBは、人間がテストを学ぶためのものだと最初は思っていましたが、いまでは、AIにテストを学ばせるためのものでもあると考えています。E2Eテストを通して、ユニットテストの重要性については、3年経ってむしろ確信を深めました。E2Eテストでカバーできない粒度の品質保証、リファクタリング時の安全網、仕様としてのコードの読みやすさ、実行速度、いずれを取ってもユニットテストの果たす役割は大きいです。AIが入ってきて、テストのやり方そのものが大きく変わっていく時代に身を置けたことは、得難い経験でした。手動テストから、Playwrightを使ったE2Eテスト、さらにAIでテストコードが生成される、このテスト手法のあり方の変遷を経験できたことは、この3年を通して一番貴重な体験だったと思います。 これからどうなっていくのか E2E自動テストは、これからプロダクトエンジニア自身の手によって、あるいはAIの手によって、常に書かれ・修復され続けるものになっていきます。QAだから書く、SETだから書く、というポジションや概念を一度外して、誰でもE2Eテストを書き、メンテナンスできる状態にしていく。これがこれからの時代の潮流になっていくはずです。E2Eテストの民主化が進むと、エンジニアはコードを書く段階でテストにコミットするシーンが増えていくでしょう。設計・開発・テストというサイクルの中で、テストという工程はむしろ縮小していくと想像しています。これはとても良いことです。リリースサイクルは速くなり、ドメイン知識を深く持ったエンジニアがテストを書くほうが、結果的により高い品質を担保できるはずです。時間がなくて後回しにされがちだったテストが、最初から組み込まれた状態で進むようになる。これは大きな前進です。ではQAという職能が消えるかというと、私はそうは思っていません。AIがコードを生成するとき、AIはどうしても「テストを通すためのコード」を書いてしまう可能性があります。あるいは逆に、「コードを通すためのテスト」を書いてしまう可能性もあります。AIを役割ごとに分けて、批判的なレビューを別エージェントに任せる、そういう工夫はしていきますが、それだけではどうしても拾いきれない領域が残るはずです。そこで重要性を増すのが、人による探索的テストであり、第三者であることだと考えています。プロダクトの内側からは見えない違和感、仕様書にもテストケースにも書かれていない「ユーザーが本当に困るところ」を、第三者の視点で拾いに行く役割。これは、AIが進化すればするほど、むしろ希少価値が高まっていく仕事だと思っています。ユニットテストやE2Eテストの機械的な実行はAIに任せられる時代になりました。その先で、人がやるべきテストとは何か。この問いに向き合っていくことが、これから
- Playwright
- 生成AI
- QA
「Sansan Tech Talk @関西 vol.3 〜データ活用のリアル〜」 イベント参加レポート
はじめに こんにちは。技術本部CTO室、中部支店勤務の中村です。 先日、4/23にオフラインイベント「Sansan Tech Talk @関西 vol.3 〜データ活用のリアル〜」をSansan関西支店にて開催しました。 本記事では、イベントの様子を簡単に振り返ります。 前置き：そもそもSansan Tech Talkとは？ Sansanは現在、地方拠点のエンジニア採用に力を入れており、その一環として各拠点で技術イベントを開催・共催しています。各拠点に所属するメンバーや地域コミュニティーの傾向などを考慮してイベントを設計しており、2026年4月時点では、 関西支店では、「Sansan Tech Talk」シリーズ(#kansai_33techtalk) 福岡支店では、「Fukuoka_33tech」シリーズ(#fukuoka_33Tech) 中部支店では、「Nagoya Tech Talk」シリーズ(#nagoya_tech_talk) を開催しています。また、シリーズものではありませんが、京都にはSansan Innovation Labという拠点もあり、「ICLR2026 論文読み会」などのアカデミック向けイベントを開催しています。 本編：イベントレポート 本イベントでは、Sansanのエンジニア3名と一般応募枠2名によるデータ活用に関する実践知の共有LT、および懇親会を行いました。 オープニング オープニングでは、CTO笹川からSansan関西支店の紹介がありました。関西支店は、大阪駅や西梅田駅、北新地駅などから堂島の地下街を抜けて徒歩5〜10分ほどでアクセス可能です。エンジニアは30名ほどが所属しており、地方拠点の中でも最大規模の支店です。 また、関西支店を含めた地方拠点のエンジニア採用に力を入れている背景や地方拠点勤務のメリットなどの話もありました。詳細が気になった方は、ぜひこちらの記事をご覧ください。 buildersbox.corp-sansan.com Talk1. 運用システムにおけるデータ活用とPlatform トップバッターはPlatform Engineering Unit所属の水谷から、Platform Engineeringにおけるデータ活用についての発表でした。 インフラやアプリケーションのログ・トレースなどのデータは、活用はおろか収集すらできておらず、障害調査や設定が属人化しやすい——そんな課題はよくありますが、Sansanでも例外ではありませんでした。 そこでPlatform Engineering Unitでは、Orbitというコンテナアプリケーション基盤を開発・提供しました。Orbitを利用することで、アプリケーション開発者は運用データを意識することなく、整備された形で収集できます。また、アラート原因調査においてもGemini Cloud Assist Investigationsを活用し、膨大なテレメトリデータから原因特定の仮説を提示することで、調査の属人化を防ぐ仕組みを提供しているという内容でした。 CTO室でもAIアプリケーションを開発しており、その一部をOrbit上で稼働させていることから恩恵を実感しています。（Orbitについては実録・Platform Engineering 失敗から学び、AI時代の波を乗りこなす技術 - Speaker Deck にて詳しく紹介しています。） speakerdeck.com Talk2. これからの「データマネジメント」の話をしよう Sansan事業部プロダクト室の坂口からは、AI時代の今、そしてこれからに求められるデータマネジメントについての発表がありました。 データ基盤の技術スタックや手法が進化・確立し、構造化データのマネジメントは成熟しつつある一方、生成AIが普及する中では、構造化データに加えて、外部のドメイン知識や業務コンテキストを構造化したナレッジ基盤を構築することが重要である。そうすることで、AIによるデータ分析の精度向上や、これまで人手で行ってきた構造化データ整備の自動化につながるという内容でした。 また、実際にこの取り組みの検証として進めている、Bill Oneデータ分析エージェントの構成についても紹介されました。 speakerdeck.com Talk3. Data Enabling Teamのこれから CTO室の矢田は、Data Enabling Teamの立ち上げとこれからの取り組みについて発表しました。 Sansanのデータエンジニア組織は少人数の職人集団で構成されており、データ活用ニーズが高まるにつれ、各事業部から寄せられる分析依頼やダッシュボード作成依頼などがボトルネックになりやすいという課題がありました。 その課題に対処すべく、「データエンジニアはデータ基盤を作りデータを提供する」から「現場がデータで意思決定できる状態を作る」への転換を目指して、Data Enabling Teamを立ち上げました。 そして具体的な取り組みとして、「過去の分析依頼内容を元にした、AIによる一次回答の自動提供」や「法務部・情報セキュリティ部と連携した、データアクセス管理統制の最適化」を進めているという内容でした。 speakerdeck.com Talk4. AI時代に増えるデータ活用先 LT登壇枠一人目は、STORES 株式会社の小野さん(https://x.com/taaaaaaakayuki) による、全社のデータ利活用促進に向けた取り組みの発表でした。 STORESでは、エンジニア以外の職種の方にもClaude Codeを導入してEnablingを行うことで、データ抽出や分析のハードルを下げているとのことでした。また、データの可視化についても、既存のBIツールを提供するのではなく、フロントエンドとSQLを書けばデプロイできるダッシュボードアプリケーション基盤を提供することで、誰でも手軽にデータを可視化できる仕組みを整えているそうです。 ダッシュボードはコード管理されないことが多く無法地帯になりがちで、その回避策としてBI as Codeのソリューションが選ばれることが多いと思いますが、スクラッチアプリケーションを提供し、誰でもAIコーディングエージェントを用いて開発できるようにするというアプローチは非常に興味深いものでした。 speakerdeck.com Talk5. データ定義の混乱と戦う 〜管理会計と財務会計〜 LT登壇枠二人目は、株式会社ヌーラボの尾上さん(https://x.com/wonohe)による、泥臭い会計データに向き合ったという内容の発表でした。 尾上さんが所属する部署では、上場準備のためにIRデータを整備するデータ基盤を構築することになり、数字の正確性が求められたため、複雑な計算ロジックを元に実装されたそうです。 上場後、マーケティングメンバーが意思決定のためにIRデータを参照した際、数字に違和感があるという事態が発生しました。 原因は、IRとマーケで求められるデータ定義が異なっていたことでした。尾上さんは、IRデータ（財務会計）とマーケデータ（管理会計）の定義の違いを明確にして両者を分けることで、データ定義の混乱と戦ったと語られていました。 私も日々、SFAなどの営業・契約データを元にした分析を行っており、定義や解釈の違いに悩まされることが多いので、とても共感できました。 speakerdeck.com 懇親会 トークセッションの後には懇親会も行われました。 さまざまな職種の方が参加されており、登壇内容を深掘りした議論や、各社のデータ活用に関する課題・取り組みについての情報交換が行われていました。私は関西支店でのエンジニアイベントに参加するのは初めてだったのですが、拠点エリアが異なるため普段はお会いする機会のない方々と交流でき、貴重な体験となりました。 おわりに 改めて、ご登壇いただいた皆さま、会場にお越しいただいた参加者の皆さま、本当にありがとうございました。 5/21（木）にも関西支店で次回イベント「Sansan Tech Talk @関西 vol.4 〜データ正規化の深淵〜」を予定しておりますので、ぜひ奮ってご参加ください!! また、5月には中部支店、Sansan Innovation Lab（京都）でもイベント開催を予定しておりますので、こちらもぜひご参加ください。 5/27(水) 19:00~ Nagoya Tech Talk #3 〜CloudNative × Platform〜 5/28(木) 19:00~ 【ハンズオンあり】MLOps勉強会 @京都 Sansan技術本部ではカジュアル面談を実施しています Sansan技術本部では中途の方向けにカジュアル面談を実施
- データエンジニアリング
- 生成AI
- データマネジメント
AI時代のビジネスインフラをつくる。 メガベンチャーを経てSansanの新規プロダクトに挑む理由
キャリアは、選択の積み重ねでできています。 どんな経験を経て、なぜSansanを選び、いまどんな挑戦に向き合っているのか。 「Sansan 3 Stories」では、これまでの歩みと、実際にSansanで働いて感じたこと、そしてこれからの挑戦を「過去・現在・未来」の3つのストーリーでお届けします。今回のインタビューでは、メルカリ、スマートニュースというメガベンチャーで開発組織のマネジメントや全社プロジェクトをけん引し、現在はSansanの新規プロダクトであるデータクオリティマネジメント「Sansan Data Intelligence」の開発に挑む多賀谷に話を聞きました。 多賀谷 洋一 / Yoichi TagayaData Intelligence Engineering Unit 部長メーカーや初期フェーズのスタートアップでのソフトウェアエンジニアを経て、2017年に株式会社メルカリに入社。急成長期から変革期におけるプロダクト開発や技術組織のマネジメントに従事。2022年にスマートニュース株式会社に入社。社長室技術担当として経営戦略に基づく部門横断プロジェクトを推進。 2025年12月にSansan株式会社に入社。部長として新規・既存プロダクトの技術・組織マネジメントに従事している。 Story 1 過去｜どんな課題に向き合い、なぜSansanを選んだのか ──これまでのキャリアについて教えてください。 多賀谷：大学院の博士課程で機械理工学の分野で微細システムを扱っていました。実は「とにかく何でもやる」という学際領域だったので、「どんな技術領域であってもまずは自ら学んでキャッチアップし、結果を出す」というマインドセットが培われたのかなと思っています。キャリアのスタートは外資系の計測機器メーカーで、1台数千万円の装置向けのソフトウェア開発に携わっていました。しかし、iPhoneなどが登場してアプリやサービスの一般ユーザーが急拡大する中で「もっと多くの人が直接使うソフトウェアの領域に携わりたい」と考えるようになり、その後フリーランスや初期のスタートアップを経験しました。 ──その後、メルカリに入社されたのですね。 多賀谷：はい。2017年にメルカリに入社しました。日米のフリマ事業や新規事業の立ち上げを経験した後、エンジニアリングマネジャーになり、その後エンジニアリングディレクターとなって、組織の拡大とエンジニアが自律的に開発する環境作りをけん引しました。この時期には、レガシーシステムの改善や置き換えという、急成長スタートアップにありがちなハードな課題にも向き合いましたね。その後メルペイでは、Fintech特有の高い基準が求められる中でのプロセス整備やセキュリティー対策など、一般的に想像されるコンシューマー向けサービスよりも「きっちりつくる」という経験をしました。急成長する組織でのマネジメントではとてもストレッチした経験をさせてもらった一方で、次の挑戦として「技術でちゃんと事業成果を出したい」という思いが強くなりました。プロダクトマネジャーとエンジニアなど分業化が進むとどの会社でも起こり得ることなのですが、後工程となるエンジニアが少し受け身になり「言われたものを作る」という状態になりがちです。当時、私自身が事業のことを深く理解して、技術で事業成果を作るための経験や知識がまだ足りていないと感じるようになりました。だからこそ、それができる新しい環境を求めてスマートニュースへ移りました。エンジニアバックグラウンドを持つ共同創業者で現CEOの浜本階生さんとダイレクトに働く機会をいただいたからです。 ──スマートニュース入社後は、どのようなミッションに取り組んだのでしょうか？ 多賀谷：入社当初は、事業損益の改善や収益拡大のため、インフラコストの最適化や、国内の大手通信会社との提携に際して求められる厳しいセキュリティー基準のクリアなど、成果が事業数字に直結する領域で課題解決に取り組みました。その後はCEO室の一員として、「技術を強みとしてどう売上を成長させるか」という全社組織横断のプロジェクトを任せてもらいました。この領域はものごとが複雑に絡み合っていて、何か1つのことをして売上が生まれるような単純な領域ではありませんでした。広告プロダクト、エンジニアリング、営業組織の役員とも密に連携し、3つの組織が同じ方向を向いて、広告主様や広告代理店様のためのプロダクトを正しく作っていけるようにプロジェクトを推進しました。結果として、売上成長につなげる成果を出すことができ、エンジニアリングと事業を結びつけるという他では得られない経験をさせてもらいました。 ──BtoC向けのイメージが強いキャリアですが、なぜSansanへの入社を決めたのでしょうか？ 多賀谷：メルカリやスマートニュース出身というと、「BtoC（コンシューマー）」のプロダクトに携わっている人と思われがちです。でも実際には、スマートニュースの広告プロダクトやメルペイの加盟店向けシステムなど、「BtoB（ビジネス）」の要素を持った領域で多くの経験を積んできました。そんな中でAIの時代が来て、「AIの時代だったらよりBtoBの領域でこそ、大きな価値を出せるのではないか」と考えていたところ、さまざまな巡り合わせがあってSansanと出会いました。Sansanへの入社の決め手は大きく3つありました。1つ目は、Sansanの新規プロダクト「Sansan Data Intelligence」が、まさにAI時代の基盤になっていくと思えたことです。2つ目は、一緒に働く人の魅力です。技術本部長の塩見やCTO笹川と何度も話をさせてもらう中で、塩見の「この人と一緒にやっていきたい」と思わせる人柄や、笹川の技術力の高さに魅力を感じました。3つ目は、このフェーズになっても創業経営者が3人も最前線で活躍していることです。「Founder Mode（創業者モード）」という言葉もありますが、創業経営者が素早く意思決定できるので、最速で事業インパクトを出せる環境があることも魅力的でしたね。 Story 2 現在｜壮大なプロジェクトとSansanのカルチャー ──現在、どのようなプロダクトや課題に向き合っていますか？ 多賀谷：現在、「Sansan Data Intelligence」という、新規プロダクトに向き合っています。これは、企業の取引先データを最新・正確な状態に保つ「データクオリティマネジメント」サービスです。社内システムに散在する取引先データを取り込んで、表記揺れ・重複・陳腐化といった品質問題を解消することにより、全社横断的なデータ活用を促進します。プロダクト紹介資料よりこの裏側では、日本に存在するあらゆる企業や事業所（本社、支社、店舗、工場、病院、学校など）を一意に特定して管理するマスターデータを構築し、整備しています。簡単にいうと、個人に対して識別子を振る「マイナンバー」がやっているように、あらゆる企業や事業所に対してSOC（Sansan Organization Code）と呼ぶ識別子を振るという、実はかなり壮大なプロジェクトなんです。企業の設立や統廃合、移転、代表者の変更など、変化し続ける実態に合わせて、誰も集中管理していないデータを収集して更新をかけていく必要があります。日本国内だけでなく海外の企業や事業所まで考えると、さらに壮大です。企業や事業所の識別子があることで何がすごいかというと、AIの時代において圧倒的な力を発揮するんです。この識別子があれば、AIが複数のデータベースやシステムをまたいでも同一の企業や事業所を正確に特定し結果を出してくれるようになります。それにより、「Sansan」「Bill One」「Contract One」といったSansanの各プロダクト間でデータがシームレスに連携するだけでなく、さらに、お客様が持つ社内システムとも正確につながるための、強力な基盤となります。そして、識別子によって一意性を担保した高品質なマスターデータがあることによって、実現できるアプリケーションもあります。たとえば、識別子を持たずに管理している取引先リストの重複排除や表記揺れの訂正（データクレンジング）、リスト情報への属性情報の付与（リッチ化）、未アプローチ企業の可視化（ホワイトスペース可視化）などです。企業のオペレーションや営業戦略を変革するサービスを提供していきます。 ──技術的な難易度はどのあたりにあるのでしょうか？ 多賀谷：まず、データソースの品質がまちまちなんです。自社収集を含む多様な手段で収集したデータソースがあり、それらを結合して、本当に1つの正しいもの、いわゆる「Single Source of Truth（信頼できる唯一の情報源）」を作ることが簡単ではないのです。データプロダクトを扱ったことがある方は経験があるかもしれませんが、一度作ったデータが壊れたり不整合が発生したりすると、その問題の調査や修正にはとても苦労します。そうならないように、データパイプラインやデータ結合のロジックを慎重に構築しているのです。さらにエンジニアリングで重要なのは、1回作って終わりではなく、そこに時間軸があることです。常に品質が保たれて、企業マスターデータが最新であり続ける状態にするのがエンジニアリングとして本質的に難易度が高いです。あとは、最速でPMF（プロダクトマーケットフィット）を達成すること。でも達成して終わりじゃなくて、そこから事業が大きく成長し続ける状態を作らないといけない。そしてマスターデータの提供以上にやっていきたいこともたくさんあります。実際に事業を作るのは不確実性があって非常に難易度が高く、同時に最高に面白いですね。 ──Sansanに入社して、良い意味でのギャップや発見はありましたか？ 多賀谷：入社後の発見で言うと、Sansanのバリューズが、組織に深く浸透していることに驚きました。私は入社当時から「意思と意図をもって判断する」というバリューが特に好きです。「誰が言ってるか」ではなく「コトに向かう」ためのベースになる考え方で、自律的に判断し、その結果に責任を持つ。さらに、それを繰り返すことで人が成長して、成長した人が事業成果をもっと大きくする。そういう意味ですごく好きなバリューです。Sansanのミッション・ビジョン・バリューズあとは、学んでよかったなと思うのが「グロースマインドセット」です。 当初は、グロースマインドセットは単に新しいことを学ぶ意思くらいにしか理解していませんでした。でも、原典となる本*1を読んでみたら、「硬直マインドセット」と対になる概念だと知りました。グロースマインドセットは日本語版の本では「しなやかマインドセット」と訳されていて、「人間の能力は努力や経験、学習によって伸ばすことができる」と考える心の状態です。逆に硬直マインドセットは「人間の能力は生まれつき決まっていて変えられない」というものです。この対比による理解は、もう目から鱗でしたね。失敗を避けるんじゃなくていいチャンスだと捉える姿勢が、心理的安全性や高いパフォーマンスにすごく強く結びついてるんだなっていうのが、私にとってすごい発見でした。部署の月例全体ミーティングで使ったスライドあともう1つ入社して気づいたことなのですが、経営陣のスタンスも印象的でした。CEOの寺田は事業成果を出すための強い意思を持ちつつも、メンバーの話を深く理解した上で建設的でしかも本質的な意見を出してくれます。 その影響もあってか、前向きで意思と意図を持ってプロジェクトを押し進めている人が多いなと感じています。 Story 3 未来｜AI時代、エンジニアはどう事業を創っていくべきか ──今後、Sansanでどのようなことにチャレンジしていきたいと考えていますか？ 多賀谷：事業での成功は当然として、それを作る組織や人が成長して、やりたいキャリアに進んでいけるようにしたいですね。事業面で言うと、Sansan Data Intelligenceが市場にしっかりと受け入れられ、本当にお客様のシステムに組み込まれている状態を作りたいです。それによって、お客様が持っている複数のシステムを連携させて、AIがその中で自律的に仕事をしているような価値を生み出していきたいです。現在、Claude、Gemini、GPTなどAIのファウンデーションモデル（基盤モデル）は海外の企業が握っています。だからこそ、その上の「エージェントやアプリケーションのレイヤー」は日本の会社が戦っていくところだと思うんです。 ただ、Anthropicが事業領域を広げるなど、そこも競争が激しいのは事実です。単なる孤立したエージェントやアプリケーションじゃなくて「Sansanだからこそできる」という強固な土台が必要です。Sansanには「独自のデータ」と、それを生み出す「Digitization（人も間に入ったオペレーションによる正確なデータ化）」を行う強力な部門があります。他社には絶対に真似できないデータを土台としたAI活用で、Sansanだからこそ作れる強固なAIエージェントやアプリケーションを提供していきたいですね。<img src="https://cdn-ak.f.st-hatena.com/images/fotolife/s/sansantech/202
- 生成AI
- プロダクトマネジメント
- 組織開発
第40回人工知能学会全国大会（JSAI2026）にプラチナスポンサーとして協賛します
こんにちは、研究開発部のライです。 2026年6月8日(月)から6月12日(金)にGメッセ群馬で開催される人工知能学会全国大会（JSAI2026）に、Sansan株式会社はプラチナスポンサーとして協賛し、ブース出展および発表を行います。Sansanからは、ポスター発表2件と口頭発表1件を行います。 本記事では各発表の概要と、ブースについて紹介します。 ポスター発表 ① RT-QMC: 順序変換を用いた準モンテカルロサンプリングによるロバストな初期学習データ選択 ② スキャン文書画像を用いたページ欠落検出手法の検討 口頭発表 GITによる複数ページ請求書の文脈を考慮したページ単位画像分類 ブース出展 ブース位置：ポスター・展示会場（B会場付近） 現地企画「「Sansan Lunch Meetup」のご案内 ポスター発表 ① RT-QMC: 順序変換を用いた準モンテカルロサンプリングによるロバストな初期学習データ選択 RT-QMC: Robust Initial Training Data Selection via Rank-Based Transformation and Quasi-Monte Carlo Sampling 発表者：田柳 俊和 セッション会場：Y会場（展示ホールAB-1） セッション日時：2026年6月8日（月）16:10 ～ 17:40 講演番号：1Yin-B-10 概要 事前学習モデルの特徴空間を活用し、ラベル付け前データから効率的にサンプルを選定する手法「Rank-Transformation Quasi-Monte Carlo（RT-QMC）」を提案しました。 ② スキャン文書画像を用いたページ欠落検出手法の検討 A Study on Methods for Detecting Missing Pages Using Scanned Document Images 発表者：宮本 優一、吉村 皐亮 セッション会場：Y会場（展示ホールAB-1） セッション日時：2026年6月8日（月）16:10 ～ 17:40 講演番号：1Yin-B-21 概要 スキャンされた文書画像を入力とし、画像情報そのものやOCR結果を活用することで、人的誤りによるページ欠落を検出する複数のアプローチを提案し評価しました。 口頭発表 GITによる複数ページ請求書の文脈を考慮したページ単位画像分類 Context-Aware Page-Level Image Classification of Multi-Page Invoices Using GIT 発表者：ライ シンユ、本田 悠太郎 セッション名：非構造データからの情報抽出（OS-19） セッション会場：F会場（メインホールB） セッション日時：2026年6月9日（火）15:30 ～ 15:45 講演番号：2F5-OS-19a-01 概要 複数ページからなる請求書に対し、ページ間の文脈と順序を考慮した画像分類手法を提案します。GITの動画キャプショニングの枠組みを応用し、複数ページを同時に入力して分類ラベル列を生成する手法を提案し評価しました。 ブース出展 ブース位置：ポスター・展示会場（B会場付近） 会期中は企業ブースの出展も予定しています。 プロダクトにおけるAI活用事例や研究開発の取り組みをご紹介予定です。現場のエンジニア・研究員とも直接お話しいただけますので、ぜひお気軽にお立ち寄りください。ブースではオリジナルノベルティーもご用意しています！ 学会に参加される方は、ぜひ発表・ブースともにお越しいただけるとうれしいです。現地でのディスカッションを楽しみにしています！ 現地企画「「Sansan Lunch Meetup」のご案内 Sansanでは、JSAI 2026に参加される学生のみなさん向けに、ランチ交流会「Sansan Lunch Meetup @JSAI2026」を開催します。 「企業のR&Dってどんな雰囲気？」「研究とプロダクト開発ってどうつながるの？」「研究員・エンジニアのキャリアについて聞いてみたい」など、気になることをカジュアルに質問いただける場です。当日は、自然言語処理・画像認識・機械学習・LLM活用などに取り組むメンバーも参加予定です。研究内容やインターンシップについて、ランチを食べながら気軽にお話ししましょう！ 日時：2026年6月9日（火）12:10〜13:25 / 2026年6月10日 12:20〜13:35 対象：JSAI 2026 に参加される学生の方 参加費：無料（抽選制） 定員：各日程10名 ▼詳細・お申し込みはこちら 6/9開催：https://connpass.com/event/393082/ 6/10開催：https://connpass.com/event/394039/ Sansan技術本部ではカジュアル面談を実施しています！ Sansan技術本部では中途の方向けにカジュアル面談を実施しています。 Sansan技術本部での働き方、仕事の魅力について、現役エンジニアの視点からお話しします。 「実際に働く人の話を直接聞きたい」「どんな人が働いているのかを事前に知っておきたい」とお考えの方は、ぜひエントリーをご検討ください。 forms.gle
- 生成AI
- 機械学習
- 自然言語処理
自働化、カイゼン、標準化ーー組織のAI活用を3倍にする製造業の知恵
はじめまして。Contract One Engineering Unitで部長をしている大島です。2025年6月にチームにジョインしたので、もうじき1年になります。この1年でContract OneもContract One Engineering Unitも大きく成長しました。 今回はARR（Annual Recurring Revenue／年間経常収益）10億円達成し、さらに勢いを増すContract Oneを支えるべく、開発組織として日々向き合っている、生産性向上について書きたいと思います。 個人技の限界——「速い人」がいるだけでは組織は変わらない TPS——製造業が教えてくれた「仕組みで勝つ」構造 ソフトウェア開発との親和性が高い 自働化がハーネスエンジニアリングと驚くほど重なる 標準を常にアップデートし続ける仕組みがAI活用と相性が良い 組織全体での標準化に対する知見の豊富さ 標準化——「何が正常で、何が異常か」を定義する 開発プロセスを8フェーズに分解する リスクベースで標準の深さを決める 成熟度モデルで「どこにいるか」を可視化する 自働化——8フェーズのすべてで、異常を即検知し、止め、共有する 自工程完結——各工程が品質に責任を持つ アンドン——「止まる勇気」がチームを速くする カイゼン——標準化を更新し、ループを一段上げる おわりに——AIが活躍できる面積を広げ続ける Sansan技術本部ではカジュアル面談を実施しています 個人技の限界——「速い人」がいるだけでは組織は変わらない 私がジョインした2025年6月より前から、チームはAI活用と向き合ってきました。今となっては当たり前のことですが、2025年6月には生成AI縛りで開発を行う、LLM Weekを行いました。その取り組みは以下にまとめています。buildersbox.corp-sansan.comその後も継続的にAI活用を進めてきました。プロンプトの工夫、コンテキストの渡し方、AIとの対話の流儀——それぞれが自分なりのやり方を模索しながら、確かな手応えを掴み始めていました。気がつけば2倍、3倍のスピードで仕事を回せる人が出てきました。 しかし組織全体を見渡すと、どうでしょう。生産性は思ったよりも上がっていないのです。これは私たちだけの課題ではありません。DORAレポートでも、AIは個人の有効性を大幅に向上させる一方で、組織・製品レベルのパフォーマンス向上は限定的であると報告されています。 さらにDORAは、AIは「魔法の杖」ではなく、組織の既存能力を反映し増幅する「鏡」であると指摘しています。つまり、プロセスや標準が整っていない組織でAIを導入しても、その混乱が加速するだけなのです。 チーム全体の生産性を変えたいなら、個人の習熟を組織の標準に変えることが大事なのです。 TPS——製造業が教えてくれた「仕組みで勝つ」構造 個人の習熟を組織の標準に変えるにはどうすればいいか——この問いに向き合ったとき、私が立ち返ったのは製造業の知見でした。私はもともと、自動車メーカーでソフトウェアエンジニアをやっていました。その時学んだ、大好きな概念の1つにトヨタ生産方式（TPS）があります。複数の部門と人が関わる生産ラインで、品質と速度を両立させてきたこのフレームワークは、「チーム全体でAI活用を標準化する」という私たちの課題にそのまま適用できると考えました。TPSの構造はシンプルです。標準化が土台にあり、その基準のもとで自働化が機能します。自働化とは、単に作業を自動化するのではなく、異常が起きたら即座に検知して止まれる仕組みを組み込むことです。そして自働化の実践から得られた学びがカイゼンとして標準化にフィードバックされ、ループが一段上がります。当時は「制約が多いな」と感じることもありましたが、今になってその本質がよくわかります。なぜAI活用にTPSなのか。それには4つの理由があります。 ソフトウェア開発との親和性が高い 自働化がハーネスエンジニアリングと驚くほど重なる 標準を常にアップデートし続ける仕組みがAI活用と相性が良い 組織全体での標準化に対する知見が豊富 順に説明します。 ソフトウェア開発との親和性が高い TPSはアジャイル開発の源流です。スクラムの生みの親であるジェフ・サザーランドもTPSから強い影響を受けています。つまりTPSの考え方は、私たちが日常的に実践しているものの原型であり、未知の概念ではありません。 自働化がハーネスエンジニアリングと驚くほど重なる 2026年2月頃から爆発的に広がったハーネスエンジニアリングは、AIの不確実性をハーネスでコントロールし、誰でも同じ品質で再現できる“型”として活用するアプローチです。異常を検知して止める仕組みを組み込み、人間の判断を要所に残す——これはまさにTPSの自働化そのものです。別々の文脈から生まれた2つの考え方がここまで一致するのは、本質的に正しいアプローチだからだと感じています。 標準を常にアップデートし続ける仕組みがAI活用と相性が良い AI活用の世界では、ツールもベストプラクティスも日々変化します。「一度決めたら終わり」の標準では、すぐに陳腐化してしまいます。TPSのカイゼンは、標準を固定するのではなく、例外が出るたびに更新し続けることを前提とした仕組みです。この「標準は生き物である」という発想が、変化の激しいAI活用の現場にぴったり合います。 組織全体での標準化に対する知見の豊富さ ソフトウェア開発の生産性改善は、個人やチーム単位で語られることが多いです。しかし実際の開発は、企画・設計・実装・QA・運用と複数の役割が関わるラインです。TPSは複数の部門と人が関わる生産ラインを何十年もかけて最適化してきた知見の塊です。「個人の工夫を組織の仕組みに変える」という私たちの課題に対して、これほど実績のあるフレームワークは他にありません。私たちはこれまで、チームの生産性を最大化するためにスクラムをベースとしたソフトウェア開発を行ってきました。しかしAI活用が進むにつれ、スクラムのプラクティスの一部は少しずつ不要になってきていると感じています。AIがコードを書き、レビューを補助し、テストを生成する世界では、従来のスプリント単位の進め方が最適とは限りません。 一方で、スクラムの源流であるTPSに立ち返ると、AI活用にそのまま使える構造が見えてきます。標準化、自働化、カイゼンのループは、AIツールが変わっても、チームの人数が変わっても、普遍的に機能する枠組みです。 だからこそ私たちは、スクラムの「先」にあるフレームワークとしてTPSを参考に、AIを組織で活用するための取り組みを始めました。 以下では、標準化・自働化・カイゼンがどのように私たちの開発プロセスに落とし込まれているかを紹介します。 標準化——「何が正常で、何が異常か」を定義する TPSにおいて標準化は土台です。自働化は、「何が正常か」が定義されていなければ機能しません。ソフトウェア開発においてこの標準化を実現するために、私たちは3つのことを行いました。プロセスの分解、リスクベースでの標準の深さの決定、そして成熟度の可視化です。 開発プロセスを8フェーズに分解する まず「どこを標準化するか」を明確にするために、ソフトウェア開発のプロセス全体を8つのフェーズに分解しました。Phase 0 — コンテキストエンジン: AIが効果的に動くための土台です。仕様・設計・ドキュメントを機械可読な形で整備し、コンテキストとして配信できる状態にします。 Phase 1 — プロダクトディスカバリー: エピックの定義とストーリーへの分割を行うフェーズです。「何を作るか」をAIが理解できる形に落とし込みます。Phase 2 — 設計とADR: 外部設計・内部設計・イベントストーミングなどを扱います。設計の意思決定をADR（アーキテクチャ決定記録）として残すことで、AIへのコンテキスト提供にもなります。Phase 3 — プランニング: ストーリーをタスクに分解し、順序を決めます。AIが計画を補助し、漏れや依存関係を早期に顕在化させます。Phase 4 — テスト＆仕様駆動開発: 先にテストを書き、そのテストを通すコードをAIに書かせます。テストが「AIへの仕様伝達手段」になるフェーズです。Phase 5 — インナーループ（コーディング）: 実装の本体です。AIがテストをパスするコードを書き、人間はレビューと設計判断に集中します。Phase 6 — 自動ガードレール（PRレビュー）: 静的解析・リンティング・AIレビューによる自動品質チェックを行います。Phase 7 — オブザーバビリティ: リリース後の監視を担います。本番環境での異常検知と通知を行い、品質を守る最終防衛ラインです。各フェーズに「正常系」と「例外」を定義することが標準化の実態です。正常系が定義されたフェーズではAIに任せられる範囲が明確になり、例外が定義されたフェーズでは人間が介入すべきポイントが明確になります。 リスクベースで標準の深さを決める 8つのフェーズを定義した次の問いは、「全部を同じ厚さで標準化するのか」です。答えはNOです。現状のAIにすべてを任せることはできません。すべてを同じ基準で標準化した場合、AIは補助的な利用にとどまり、大きな生産性向上にはつながりません。そこで私たちが取り入れたのがリスクベースアプローチです。考え方はシンプルで、リスク = 影響度 × 発生確率でスコアリングし、Tierに応じてテストやレビューの基準を変えます。Tier 1（スコア6〜9）: 契約管理や認証など、最高リスク領域。ユニットテスト80%以上のブランチカバレッジ、E2Eテストのハッピー＋ネガティブパスが必須。PRレビューはシニアアーキテクト必須。Tier 2（スコア4〜5）: 通常のレビューとハッピーパスのE2Eテスト。Tier 3（スコア2〜3）: 軽量なレビューと任意のテスト。Tier 4（スコア1）: デスクチェックのみで、自動承認の候補。AIレビューもTierによって深度を変えます。Tier 1にはコンテキストを考慮した深いレビューを、Tier 4には軽量な自動チェックを。高リスクに厚く投資し、低リスクは最小限にする。このメリハリがあるからこそ、品質と安全性を保ちながら、AIに任せられる領域を最大化できます。 成熟度モデルで「どこにいるか」を可視化する 8つのフェーズを定義したら、次の問いは「それぞれが今どのレベルにあるか」です。各フェーズで5段階の成熟度レベルを定義しました。判定の軸は「再現性」「監査可能性」「例外の扱いが仕組み化されているか」です。L1: 手動作業が中心、品質にばらつきがあるL2: AIエージェントを使い始め、基本的な自動化を導入しているL3: AIが品質チェックや変換を支援し、人間が判断しているL4: AIが主導し、人間は最終承認のみL5: AIが自律的にディスカバリーから検証まで実行している一気にL5を目指すのではなく、フェーズごとに効果とリスクを確認しながら段階的に進めます。この成熟度モデルにより、「標準化がどこまで進んでいるか」がチーム全体で共有できるようになりました。 自働化——8フェーズのすべてで、異常を即検知し、止め、共有する 標準化によって土台が整ったら、次はその基準のもとで自働化を機能させます。「自動化」ではなく「自働化」——単に作業を機械に任せるのではなく、異常が起きたら即座に検知して止まれる仕組みを組み込むことです。ソフトウェア開発に置き換えると、こうなります。 仕様が明確で迷わず進められるタスク（正常系）は、AIが流し切る 仕様の曖昧さやツールの不足といった例外は、すぐに顕在化させて人が対応する そして例外が出たら、次回は正常系になるよう標準を更新する この自働化を、コーディング（Phase 5）だけでなく8フェーズすべてに組み込んでいるのが私たちのアプローチの特徴です。コンテキスト整備から設計、テスト、レビュー、監視まで——すべてのフェーズで「正常系をAIが流し、例外を検知して止まる」仕組みを構築しています。 各フェーズには評価と手戻りの仕組みも設けています。フェーズの完了時に成果物を評価し、問題が解消しない場合は1つ前のフェーズに戻ります。 たとえば、Phase 5（コーディング）でAIの出力品質が上がらない場合、Phase 5自体を改善するのではなく、Phase 4（テスト）やPhase 0（コンテキスト）の標準に問題がないかを遡って確認します。上流の標準が整っていなければ、下流の自働化は機能しない——この原則を仕組みとして組み込んでいます。 さらに、先述のリスクベースアプローチにより、フェーズごとのワークフローを柔軟に切り替えられるようにしています。Tier 1（高リスク）のタスクでは全フェーズを厳密に通しますが、Tier 4（低リスク）のタスクではフェーズを軽量化し、AIに大きく委ねます。同じ8フェーズでもリスクに応じて深さが変わる——この柔軟性が、品質を保ちながら速度を出すための鍵です。 当面の目標は全フェーズでL3以上——AIが品質チェックや変換を支援し、人間が判断する状態です。現状ではPhase 5への課題が集中していますが、それは上流フェーズの成熟度が上がった結果、ボトルネックが可視化されたとも言えます。 そして自働化を支える具体的な仕組みが、自工程完結とアンドンです。 自工程完結——各工程が品質に責任を持つ 自工程完結とは、各工程が自身の成果物のクオリティに責任を持ち、次の工程に不良を流さないという考え方です。「後工程で誰かが直してくれるだろう」ではなく、自分の工程の中で品質を検証し、基準を満たしていることを確認してから次に渡す。8フェーズそれぞれがこの自工程完結を果たすことで、初めて全体の自働化が成立します。中でも特に重要なのはPhase 0（コンテキストエンジン）・Phase 4（テスト＆仕様駆動開発）・Phase 6（自動ガードレール）です。 Phase 0が整っていなければ、AIはコンテキストを正しく理解できず、何をやらせても的外れになります Phase 4が整っていなければ、AIが生成したコードの正しさを保証できません Phase 6が整っていなければ、速度を上げるほど品質リスクが増します
- 生成AI
- 生産性
- 開発プロセス
AIの出力を「信頼」に変えるまでに、考えたこと ─ JaSST Tokyo 2026 登壇レポート
はじめに こんにちは。Bill OneでQAエンジニアをしている林樹坤です。 2026年3月20日、JaSST Tokyo 2026に登壇しました。部長の佐藤と共同登壇で、Sansan QA組織のAI戦略と、私が設計したAIテスト支援システム「AITAS」の実践事例を話しました。 この記事は、AITASについて書いてきたシリーズの第3弾です。 第1弾：テスト設計の属人化からの脱却─AIで工数半減と品質標準化を実現したQAチームの挑戦 - Sansan Tech Blog ─ AIに丸投げの失敗から始まり、4ステッププロセスを構築して属人化と工数を解消した話 第2弾：Vol.17 AI駆動開発を加速させるQAフローの最適化 - Sansan Tech Blog ─ 「レビュー地獄」とドメイン知識の空洞化という副作用を乗り越えるためにAITAS 2.0を再設計した話 本記事は、その先です。AITASを作り続ける中でずっと向き合ってきた「AIの出力を信頼に変えるとはどういうことか」という問いを、JaSST Tokyo 2026という場で言語化する機会を得ました。「信頼」に向けた工夫と、発表後に気づいたことを書きます。 登壇当日の様子 当日の発表資料 発表で使用したスライドを公開しています。以降の本文に出てくる「AITAS」「Step 0〜3」「精度測定の仕組み」などの全体像はスライドで確認いただくと、より理解しやすくなります。 speakerdeck.com 改めて、問いの核心 第2弾の締めで「次の課題はナレッジDB」と書きました。その課題に取り組みながら、AITASは現在v2.1まで進化しています。JaSST Tokyo 2026の発表冒頭では、聴衆にこう問いかけました。 AIを使い始めたけど、その出力、本当に信頼できていますか？ この問いは、freeeさんとの合同イベント（2026年2月）でSlidoに寄せられた42件の質問から来ています。最もUpvoteを集めたのは「AIでのテスト実行時の結果の信頼性はどのように確保していますか？」でした。これは他の誰かの問いではなく、私自身がずっと向き合ってきた問いです。工数を削減したことは第1弾で書きました。精度を数値で追う仕組みを作ったことは第2弾で書きました。それでも「信頼できるか」という問いへの答えは、発表の場に立つまで自分の中でも整理しきれていませんでした。 「信頼」に向けた工夫 AITASのパイプライン構造：Step 0〜3の概要ここでいう「信頼」をまず整理します。AIの出力精度が高いこと。その精度が、誰がいつ実行しても安定して再現され、根拠を持って説明できること。そして実務レベルでは、AITASを使ったテスト設計でCriticalなインシデントが出ず、品質を下げないこと。この3点が、私にとっての「信頼」の定義です。精度はその一要素に過ぎません。その信頼を実現するために、AITASはPBI仕様書・Figmaデザイン・ナレッジDBをインプットし、テスト分析・観点・ケースを生成する4ステップのパイプラインとして設計しています。スライドで全体像を確認してもらえると理解しやすいですが、本記事では特に「なぜこう設計したか」という判断の部分を3つに絞って掘り下げます。 どのくらい生成させるか、先に決める AIにPBIを渡す前に、まずQA視点でテストの重さを判定するステップを設けています（Step 0：QAサイジング）。 ※第2弾ではStep 1と表記していましたが、現在のバージョンでは0始まりの番号に統一しています。このステップが必要だと気づいたきっかけは失敗でした。AIに「テスト観点を出して」と丸投げしたとき、XS規模のPBIに100件超の観点が返ってきた。問題は「AIに何を出力させるか」だけを考えて、「どのくらい出力させるか」を人間が決めていなかったことでした。インプットが多ければ出力も多くなる。当たり前のことを見落としていたのです。ここで重要なのが「開発サイズ ≠ QAサイズ」という考え方です。コード変更は数行でも、影響範囲の広さ・機能の複雑さ・テスト準備の複雑さでQAのサイズが大きく変わります。開発サイズXSでも、QAサイズはM・Lの場合は十分あります。Step 0はこの判断を、生成前に確定させる仕組みです。 AIにドメイン知識を持たせる AIにPBIをそのまま渡すだけでは、Bill Oneの業務ルールを知らない状態でテスト設計させることになります。そこでStep 1（テスト分析サマリー）では、ナレッジDBに蓄積した機能仕様・業務ルール・過去バグのパターンをインプットし、AIを「よそのQAエンジニア」から「Bill One専属のQAエンジニア」に変えることを目指しています。こうしてステップごとに「AIに何をさせるか」を設計した上で、AITAS全体には3つのガードレールを組み込んでいます。 ガードレール1：根拠の明示（不確実な情報には [要確認] タグを付けさせる） ガードレール2：リスクベースの優先順位設計（影響度×発生確率で判定） ガードレール3：約3000文字の出力制御プロンプト（誰が実行しても同じフォーマット・粒度になるよう統一） また、各ステップでAIのロールを切り替えています。Step 0はプロダクトマネジャー兼アジャイルコーチ、Step 1はテストアナリスト、Step 2/3はQAエンジニア。ロールを変えることで、各ステップで求めている思考の粒度が変わります。 数値で可視化する 重みの根拠は、精度ツールの最適化ではなく「見落としたときの影響度」から逆算しています。重大な見落としと軽微な表現ミスを同列に扱うのは意味がない。QA組織として何を守るかという設計思想から来ている数字です。 精度 = 1 − （重大×3 + 中程度×2 + 軽微×1）/ （観点総数×3） このスコアリングはエンジニアとQAのレビューコメントをAIが自動分析して行っています。精度ランクは80%以上が優秀（3カ月に1回分析）、60〜80%が許容（月1回分析）、60%未満が即改善です。この仕組みがあるから改善サイクルが回ります。「なんとなく精度が上がった気がする」では、組織への信頼を築けません。 AITASが目指してきたこと 半年以上運用してきましたが、AITASを使ったテスト設計でCriticalなインシデントは発生していません。AIを使い始めたことでプロダクト品質が下がったという実感もありません。さらに、誰が実行しても、複数回のバージョンアップ後も、精度は平均85%以上を維持しています。冒頭で定義した「信頼」の3点は、現時点で成立しています。 AIとQAエンジニアの役割分担：85%と15% AITASでは、テスト観点の生成・分析・ケース作成といった作業をAIが担い、判断と意思決定を人間が担うという役割分担を設計の前提にしています。現時点の比率でいうと、AIが約85%、人間が約15%です。 AIが担う85%は、構造化された観点の生成とパターンベースのケース作成です。残り15%はスコープを引く判断・リスクの最終評価・仕様の曖昧さの解釈・AIが出した量から「本当に必要なもの」を見極めること、これは人間にしかできません。 100%を目指さないのは意図的な設計です。残り15%こそ、QAエンジニアの価値がある場所だと考えているからです。 発表後に気づいたこと セッション終了後のDiscordには「ナレッジがプロダクトの成長に応じて陳腐化するのを防ぐ仕組みは？」という質問が来ました。発表では十分に話せなかった部分です。現状の対策は3つあります。Notionに期限フィールドを設けて「いつ見直すか」を明記すること、仕様書への直リンクで変更を検知できるようにすること、PBIや仕様書が更新されたときにSlack通知を飛ばすこと。ただ、現状、これらはすべて「人が都度対応する」前提の仕組みです。最終的に目指しているのは、PBIの変更をトリガーにナレッジが自動更新される仕組みです。開発高速化が進む中で、手動更新には限界があります。ここはAITASの次の課題です。 シリーズを振り返って 振り返ると、AITASは最初から「信頼できるテスト設計をAIで実現する」という同じ問いに向き合ってきました。第1弾では属人化を解消し、誰が実行しても同じ品質を出すことを目指しました。第2弾では過剰生成とドメイン知識の空洞化という副作用と戦い、生成をコントロールする仕組みを作りました。本記事では、その「信頼」とは何かを改めて言語化しました。 問いは変わっていません。ただ、向き合い方が深くなってきた感覚があります。 AITASはまだ完成していません。現在はプロンプト集として動いていますが、アプリ化を進めています。ナレッジの自動更新、他プロダクトへの展開、精度測定の継続改善──やることは積み上がっています。本記事を読んで何か気になることがあれば、気軽に声をかけてください。 We are hiring Sansan技術本部では中途の方向けにカジュアル面談を実施しています。Sansan技術本部での働き方、仕事の魅力について、現役エンジニアの視点からお話しします。「実際に働く人の話を直接聞きたい」「どんな人が働いているのかを事前に知っておきたい」とお考えの方は、ぜひエントリーをご検討ください。 open.talentio.com
- 生成AI
- QA
- テスト自動化
Bill Oneのデータ分析エージェントをインターンで開発した話
はじめに こんにちは、はじめまして！ Sansanの技術本部 CTO室 AI Solution Developmentでインターンをしていた広瀬エイトル（@Heitor_Hirose）です。*1 約1カ月半のインターンシップで、Bill One向けのデータ分析エージェントの開発に取り組みました。自然言語で質問するだけで、Bill Oneのデータを検索・集計・可視化できるツールです。 この記事では、技術スタックの選定理由、詰まったポイントを中心にまとめます。 なぜデータ分析エージェントが必要だったのか Bill Oneは、Sansanが提供する経理AXサービスです。事業の成長に伴い、営業メンバーやPdMからのデータ集計・分析依頼が増加しています。 しかし、対応できるデータエンジニアのリソースには限りがあります。依頼のたびに「何を・なぜ取りたいか」を言語化して伝えるコストが双方に発生して、ボトルネックになりつつある状況でした。さらに、どのようなデータが存在するのかが非エンジニアには把握しづらく、データの存在自体がブラックボックス化していました。 このような背景から、「誰でも自然言語でデータにアクセスできる状態を作る」ことをゴールに据えて開発を始めました。 取り組みの全体像 今回のインターンでは主に2つの軸を中心に進めました。 ① データモデリング ディメンショナルモデリング・スタースキーマの設計 dbt + BigQueryを用いたデータ基盤の整備 データエンジニアの仕事を肌感覚で理解する ② AIエージェント開発 Google ADK（Agent Development Kit）を用いたエージェント実装 AG-UIプロトコルによるフロントエンドとの通信 Cloud Run + IAPによるインフラ構築 LLMOps（Langfuse）の導入 システムアーキテクチャ プロダクト全体の基本的なシステムはすべてGoogle Cloud Platform上に構築されています。3つのコンポーネントを主軸に構成されています。 コンポーネント iceberg-ui データ分析エージェントのフロントエンド Next.js / Cloud Run penguin-agent-api エージェント実行・AG-UIミドルウェア ADK / FastAPI / Cloud Run penguin-agent エージェントのセッション管理 Vertex AI Agent Engine フロントエンド（iceberg-ui）とエージェントAPI（penguin-agent-api）はAG-UIプロトコルで通信しています。セッション管理にはVertex AI Agent Engineを使用していますが、後述する理由からエージェントの実行環境としては使用していません。 エージェント向けのデータ基盤層 エージェントがアクセス制限の必要な生データに直接触れないよう、エージェント専用のデータモデリング層を設けています。これにより、エージェントはエンジニアが用意・整形したデータのみを使って分析する構造になっています。 扱えるデータソースは主に2種類です。 modeled-data（BigQuery） 当社の統合データ基盤であるColossusから取得したCRM系データ・プロダクトデータを、エージェントが扱いやすい形に整形したデータがあります。ファクトテーブルとディメンションテーブルを想定している用途ごとに分離・整形しています。これらのデータはエージェントの回答精度の品質と設計に直結しているため、慎重に扱っています。 Knowledge System（Markdownファイル群） Colossusに存在するデータソースのテーブル定義などが記述されたMarkdownファイル群です。プロジェクトのGitHub上で管理されており、ADKのツール呼び出しとして使用できるようになっています。Bill Oneの営業が使用する特殊な用語の説明・日々行っている分析手法・過去の実例をナレッジとしてまとめており、エージェントはクエリ実行前にこれを参照して適切なテーブル・カラムを選択できます。 LLMOps層 penguin-agent-apiから社内で構築・運用されているLangfuseに対してトレースを送信しています。各ユーザーが使用したBigQueryのコストやエージェントの動作を観測できる状態に保っています。 その他 このプロダクトでは、Bill Oneに関係する社員にのみ使用することを想定しているため、iceberg-uiにIAPを設定しています。これにより、指定したGoogleグループのみがアクセスできる状態を担保するようにしました。 AIエージェントの開発 ADK + AG-UIを選定した理由 エージェントの主要なフレームワークとして、Google ADK（Agent Development Kit）を採用しました。主な理由は２つです。 1つ目は、同じチームで開発している既存のエージェントサービスと技術スタックを合わせるためです。そちらも社内の社員向けに機能を提供しているのですが、ADK + AG-UIの構成を採用しています。同じチームで異なるフレームワーク、構成を並行してメンテナンスするコストを避けました。 2つ目は、ADKではBigQueryを前提とした標準ツールが複数整備されており、今回のケースととても相性が良かったためです。 フロントエンドとの通信にはAG-UI（Agent-User Interaction Protocol）を採用しました。AG-UIはCopilotKitチームが開発したオープンプロトコルで、エージェントとユーザーインターフェースの間のやり取りをイベントストリームとして標準化できます。社内の既存プロジェクトが同じ構成でAG-UIを採用していたため、フロントエンドに関する実装の一部を流用でき、開発効率の向上につながりました。 行き詰まったポイント: Vertex AI Agent Engineに対する調査不足 当初はVertex AI Agent Engineをエージェントの実行環境として使用する設計を試みました。しかし、以下の制約に直面しました。 Agent Engineをランタイムとして使う場合、通信方式をカスタマイズできない 対応しているのはA2AとGoogle独自のSSEのみで、AG-UIには未対応 Next.jsのAPI RouteでAG-UIプロトコルを自前実装すれば対応可能だが、チームのメンテナンスコストを考えて断念 最終的に、エージェントの実行環境はFastAPI on Cloud Runに完全移行し、Vertex AI Agent Engineはセッション管理のみに用途を限定しました。この判断により、AG-UIミドルウェア（pypi.org/project/ag-ui-adk）をそのまま使用でき、実装量を大幅に削減できました。 from ag_ui_adk import ADKAgent, add_adk_fastapi_endpoint adk_agent = ADKAgent( adk_agent=root_agent, app_name=app_name, session_service=shared_session_service ) add_adk_fastapi_endpoint(app, adk_agent, path="/penguin-agent") LLMOps - 可観測性のあるエージェントに Langfuse SDKを使用してトレースを管理・送信するようにしました。 LLMの生成は本質的に不安定なので、出力した結果の追跡性を確保することが重要です。penguin-agent-apiから社内で構築・運用されているLangfuseにトレースを送信する仕組みを実装しました。 社内Langfuse基盤の活用 SansanではLLMを活用した機能開発において、LLMOpsに取り組んでいます。複数プロダクトでの利用を前提に、セルフホスト型のLangfuseを社内共通基盤として整備しており、その背景や選定経緯は以下の発表資料を参照いただくとわかりやすいです。 speakerdeck.com buildersbox.corp-sansan.com 今回のデータ分析エージェントでも、この社内Langfuse基盤にそのまま接続する形でLLMOpsを実現しました。環境を構築する必要がなく、インターン期間内でもスムーズに可観測性を確保できた点は、社内整備の恩恵を大きく受けた部分だと思います。 Langfuse SDKによるトレース管理 社内Langfuseをフル活用するために、アプリケーションに対してLangfuse SDKを導入しました。ADKのCallback機能を活用して指定したツールのトレースや必要なユーザー情報を取得するようにしました。 実行されたプロンプト・レスポンス全文 レイテンシ・トークン使用量 BigQueryの実行コスト（クエリごとのコストをspanに保存） トレースに対して社員情報の付与 これにより、セッション単位での評価・分析や、エラー・異常レスポンスのトレース単位での特定・調査が可能になりました。 アプリケーション上での透明性確保 LLMの生成結果に対する検証可能性をアプリケーション上でも提供するため、エージェントが実行したSQL・Web検索クエリと結果をiceberg-uiのUI上に表示しています。非エンジニアでも「エージェントが何をしたか」を確認できるようにしています。 ユーザーヒアリングから生まれた機能 PdMやエンジニアとのランチ・Slackを通じたヒアリングをもとに、以下の機能を追加実装しました。 グラフ表示機能 「テーブル表示だけでは生成結果がわかりづらい」という声をもとに実装。推移・軸比較・割合など一般的なグラフ種別に対応しています。 エージェントワークフローの可視化 エージェントが実行したSQL・Web検索クエリをUI上に表示する機能です。生成結果の妥当性をエンジニアが検証しやすくすることを目的としています。 会話共有機能 画面から共有専用URLを発行でき、適切なIAM権限を持つユーザーが会話内容を閲覧できます。「エージェントの出力をエンジニアに確認してもらいたい」というユースケースに対応しました。 おわりに 実現できたこと 自然言語でBill Oneのデータを検索・集計・可視化できる状態の構築 Langfuseによるログ・トレースの整備と可観測性の確保 ユーザーヒアリングをもとにした機能拡張 インターン期間内に着手できなかったこと Langfuseのデータをもとにしたエージェントの継続的改善サイクルの構築 MCPなど他のアプローチとの比較、データ分析エージェント運用の優位性の検証 学んだこと Vertex AI Agent Engineで行き詰まった経験から実感したように、新しい技術、手法はまず手を動かして制約を早めに把握することが設計判断につながることを学びました。また、エージェントの精度はモデルよりデータ基盤の品質に依存する部分が大きく、データモデリングへの投資が回答品質に直結しました。このことから、開発してアプリケーションを動かせるようにするだけではなく、改善フローを運用できる状態にする重要性を特に感じました。Langfuseを入れて初めてエージェントの挙動やコストが見えるようになったことで、作って終わりではなく、最初から可観測性を意識して開発することの重要性を実感しています。 それと同じくらい、Sansanという会社への解像度も上がりました。LLMOpsの社内共通が基盤整備されていることを証拠に、データに対して本気で向き合っている組織であることがわかり、またプロダクトの方向性に直結するような、職種を越えたコミュニケーションが自然に生まれる文化も印象的でした。ここで得た経験と視点を、今後の学びと開発に生かしていきたいと思います。 最後に、メンターの中村さん、斉藤さん、データモデリング師匠の矢田さん、ランチでお話しいただいたPdM・エンジニアの皆さん、本当にありがとうございました！ Sansanでは就業インターンを募集しています Sansanでは、就業インターンを学年を問わず募集しています。 newgradsevents.corp-sansan.com Sansanのエンジニア職インターンでは、インターン用のタスクを実施するわけではありません。 サービスに関わる技術選定からリリースまでの一気通貫した開発といったような、やりがいを得られる環境を準備しています。 チャレンジの場として、ぜひSansanの就業インターンへの応募をお待ちしております！ *1:記事は、執筆者本人の了承を得て、代理で投稿しています。
- 生成AI
- BigQuery
- LLMOps
- Next.js
- FastAPI