Kawase Keisuke / VPoP, Sansan

AI時代のUIの重要性は、AI時代においても人間が手綱をにぎらなければいけないというところと関わっていると思う。もし完全にすべてをAIに任せるだけの世界になるなら、水道管が土の中にあるように、インフラが普段僕らの目には見えないように、UIはいらない。が、自動運転のLV4（完全自動運転）だとしても、ハンドルって格納されるケースが多いけど、いざとなったら人間が操作できるインターフェースは残してる、なんでかっていざというときやばいから。と、いうように、どこかしらで人間が手綱を握る必要がある以上、UIは必須。しかもわかりはすいUIが。車の例で言うと普段使わないからと言って、ハンドルが、AIに使いやすいようになんか謎のボタンが百個あるみたいな操作系だったらどうか。普段使わない分だけ、操作方法って余計に思い出せないのに、さらに、久しぶりに見た操作系がわけわからなかったら、操作方法思い出せずに死ぬ。人間が操作する頻度がさがるからこそ、久しぶりに触っても操作を思い出せるように、より学習せずとも人間の直感でコントロールできるユーザーインターフェースが必要。UIとは、外部記憶でもあるとおもうんです。どう操作したらいいか、というがインターフェスが自然とアフォードしてくるかどうかがよりAI時代重要になる（アフォーダンスの重要性がよりシビアになる）。AI時代にUIがいらなくなる、というのはこの観点を考慮できていない意見だと思います。

ユーザーとしてAgentを使っていても、Agentic型とWorkflow型の組み合わせによる日々の進化を実感しています！！！ AIエージェントのための段階的セマンティックレイヤの育て方 - Sansan Tech Blog buildersbox.corp-sansan.com/entry/2026/01/… --- Step 4: 自由クエリを探索用のfallbackとして残す すべてをWorkflow型で固めてしまうと、新しいユースケースの発掘が難しくなります。 そこで、自由にSQLを発行できるMCP Toolも並行して用意しています。既知のユースケースはPreset Query Tools（Workflow型）で対応し、未知の探索的な依頼はFree SQL Tool（Agentic型）で対応する使い分けです。そのため、dim/fact/aggにおいては、テーブルやカラムのdescription（説明）も整備することでAgentic型でのハルシネーションを抑制しています。 それでもなお、Agentic型ではハルシネーションやパフォーマンスの課題が付きまといます。そのため、頻出するパターンやユーザーフィードバックからWorkflow型に落とし込めるユースケースが見つかったら、それを起点にリモデリングとセマンティックレイヤ構築を進めています。 探索（Agentic）で発掘し、定型化（Workflow）で固める。このサイクルを回し続けることで、セマンティックレイヤを段階的に成長させていきます。

ユーザーとしては自然な振る舞いになっていますが、裏側ではAgenticとWorkflowが様々なシーンで組み合わせながら動作しています！ --- 営業支援AIエージェントで考えるAgenticとWorkflowの設計論 - Sansan Tech Blog buildersbox.corp-sansan.com/entry/2026/01/… --- AgenticとWorkflowを組み合わせることで、再現性と柔軟性を両立できます。この組み合わせには2つのパターンがあります。Workflow-in-Agentは、Agentが決定するが実行は決定的なスキル（サブワークフロー）に委譲する形です。Agent-in-Workflowは、Workflowを背骨にし探索が必要なノードだけAgentに委譲する形です。「繰り返し可能な結果が必要な部分はWorkflow、探索が必要な部分はAgentic」という使い分けで、Workflowをコンテナ、Agenticをコンテナ内で動く探索アルゴリズムとして捉えられます。 組み合わせ方は依頼の性質で変わります。型が確立している領域（商談準備の標準フォーマット、優先度スコアリングなど）では、Workflow主体で情報の補完や例外処理にAgenticを使います。探索的な領域（市場動向の把握、リスク発見など）ではAgentic主体で結論の構成や見せ方にWorkflowを使います。第1章の例で言えば、「A社の商談準備」や「重要案件の優先度順」はWorkflow主体＋Agentic補助、「XX業界で競合が強い領域」はAgentic主体＋Workflowで構成化、という構造です。このように、依頼の性質に応じて主従を変えながら組み合わせることが実践的な設計の鍵です。

このアーキテクチャとこのステップだよね、と今となっては当たり前に思うくらいシンプルでガシガシ進めやすいAgent開発です！ -- Step 1: 「屋台骨」の定義とローカルでの価値検証 Step 2: 「間口を広げる」ためのWebUI化と高速フィードバック Step 3: 「体験を深める」ための機能追加と賢い技術選択 Step 4: 体験を拡張する「並列開発」と、変化への向き合い方 -- データエンジニアの観点でプロダクト開発を語る - Sansan Tech Blog buildersbox.corp-sansan.com/entry/2026/01/…

このチーム体制めっちゃいいなと思いながらAIエージェントに本気で取り組んでいます！（URLからも本気度が！） -- エージェントアプリケーションチーム： AIエージェントのコア機能とUI開発 データモデリングチーム： AIが必要とするデータ連携・セマンティックレイヤーの構築 データプラットフォームチーム： 全社共通のDWHや開発基盤の整備 FDEチーム：SansanAI エージェントのプリセールス、顧客への装着支援 -- データから収益を生み出す挑戦。Sansanの独自資産を武器に、本気でAIエージェントを作りに行く話 - Sansan Tech Blog buildersbox.corp-sansan.com/entry/data-wit…

ドラッカーの「マネジメント」を読み直そうと思い、ふと思い出して「もしドラ」を読んだら、おもしろくてびっくりした…！これはヒットしたのも納得した。当時学生だったから全然よく分からなかったなー。

「悪い言語哲学入門」おもしろかった。発言の意図というより、それが社会でどう機能するかが重要という学び。 以下がプロダクト観点でのアイディア例（もちろんこれだけで判断する訳では無いが、ポイントの一つとして。） 【プロダクト・組織に効くポイント】 - UX / コピー / AI生成文言 「不快に感じる人がいるか？」ではなく 「特定の人を不利な立場に置く言語行為になっていないか？」 - 社内コミュニケーション 評価・フィードバック・冗談が無意識に権力差を強化していないかを点検する視点。 - 炎上対応・ガイドライン設計 「悪意の有無」基準は脆い。影響ベースで考えると判断が安定する。

「言語化するための小説思考」を読んだ。良かった。 2025年は発信（登壇・記事・インタビュー）がとても増えて、良かったことや改善が必要なことがあり、振り返りの良いきっかけとなった。 個人的には「何か有益なことを言わなければ」「学びをまとめなければ」ではなく、「最近、自分はどこに違和感を持っているか」「まだ言葉にならない引っかかりは何か」ということから書くとよいのだろうなと。 例えば先日「システム x エンジン x インパクトでプロダクトと事業を強くする」という記事を公開したが、その切り口で考えるきっかけがあり、普段めちゃくちゃ考えているわけで、それを言語化するのがよいのだろうなと思った。 そして「どこに向かおうとしているのか」を意識しながら考えを深めるために文章でまとめて、ついでに発信していく、くらいが自分は丁度良いのかもしれない。

技術観点含めたSansan MCPサーバーの全貌です！！！ buildersbox.corp-sansan.com/entry/2025/12/…

先日発表しトライアル提供開始しているSansan MCPサーバーの全貌です！！！ buildersbox.corp-sansan.com/entry/2025/12/…

AIの評価の部分の発展は気になりますね "This next era of AI measurement will be defined by: - Private, use-case-specific evals built on proprietary data - Business-grounded metrics like accuracy, latency, hallucination rates, customer satisfaction - Continuous eval pipelines tightly integrated into production systems and feedback loops - Lineage and interpretability, especially in regulated verticals like healthcare, finance, and insurance Startups such as Braintrust, LangChain, Bigspin.ai and Judgment Labs are pioneering the infrastructure stack for this new era—offering eval harnesses, agentic benchmarking environments, real-time feedback loops, and more." bvp.com/atlas/the-stat…"

プロダクトの価値というより、株価の傾向という意味で勉強になった。 saastr.com/the-performing…

>AIの勝ち筋は、アルゴリズムよりも独自データから考えるべき blog.allstarsaas.com/posts/coupa-su…

a16zのGoToMarketの記事良いな。7年前の動画を元にしているみたいだけど今でも学びになる。 企業価値の大部分はGo-to-Marketで決まる。価格設定は単一の意思決定として最も重要。 市場カテゴリー創造とは - 顧客が技術コンセプトを理解していない - 自分たちに問題があることすら認識していない - 予算項目が存在しない - Gartnerも定義できていない 致命的な誤解 -「低価格で広く普及させ、後でアップセル」という戦略 - 販売が難しいのは価格のせいではなく、市場の準備不足やPMFの欠如 - 一度市場に価格を刻印すると、値上げは極めて困難 - 初期の低価格設定は将来市場を自己蚕食する 避けるべき罠 - 外部販売への早期依存(Pullがないと機能しない) - Contract engineering化(顧客個別要望に応えすぎ) - SKU乱立(既存製品にバンドルしない) - 営業チームの早期拡大(酸欠状態を引き起こす) - プロフェッショナルサービスの軽視(初期市場では顧客の不安を払拭するために、導入支援をセットで売ることは正当な戦略) 販売モデルから逆算し独立した製品として価格設定を行い、ストーリーを磨き、一緒にリスクを取ってくれる少数の顧客に集中する。 Going to market when no market exists a16z.news/p/going-to-mar…

Sansan、音声にも取り組んでいます。リアルな情報を構造化データに変えて、活用できるようにしていきます。 jp.corp-sansan.com/news/2025/1219…

#ノッカリアドカレ 17日目のnoteを書きました！これまでずっとプロダクトがキャリアの中心にあり「事業責任者」ではないけどガッツリ事業に向き合っているこの気持ちやスタンスが少しでも伝わると嬉しいなと思いました！ プロダクトから事業の構造をつくることはできないのか｜Kawase Keisuke @Kesuke2 note.com/kkawase/n/n38c…

【📢ブログを公開しました】 プロダクトマネージャー Advent Calendar 2025🎄 12日目は、Sansan事業部 VPoPの川瀬（@Kesuke2）が「システム × エンジン × インパクト」によるプロダクトの強化について紹介します。 日々の意思決定の整理にも役立つ内容です。 ✏️システム x エンジン x インパクトでプロダクトと事業を強くする #33Tech #Sansan技術本部 #Sansan buildersbox.corp-sansan.com/entry/2025/12/…

本日12月12日、約4年ぶりとなる新規プロダクト Sansan Data Intelligenceをリリースいたしました。 本記事では、プロダクトが生まれた背景、既存プロダクト Sansan Data Hub との関係性、そしてそれを支える技術的革新について紹介しています。 buildersbox.corp-sansan.com/entry/2025/12/… #33tech #Sansan

記事はこちら buildersbox.corp-sansan.com/entry/2025/12/…

久々にプロダクトマネジメント直球の記事を書きました。今の自分の感覚ではシステム（戦略・実行基盤・経済モデル）とエンジン（スピード・タイミング）含めてプロダクトマネジメントなのかなと思ったりしました。それに愚直に向き合うプロダクトマネージャー。