AI時代の新規LLMプロダクト開発: Findy Insightsを3ヶ月で立ち上げた舞台裏と振り返り

Transcript

1. © Findy Inc. 2025.12.16 AI Engineering Summit Tokyo 2025 AI時代の新規LLMプロダクト開発: Findy Insightsを3ヶ⽉で⽴ち上げた舞台裏と振り返り 1 ファインディ株式会社 データサイエンティスト 奥⽥ 堯⼦ @Daku-on
2. © Findy Inc. 2 ⾃⼰紹介
3. © Findy Inc. 3 ⾃⼰紹介 • 奥⽥ 堯⼦ (おくだ たかこ) • ファインディ株式会社 データサイエンティスト • Python⼀筋 (プロトタイプ開発では⽣成AIにTypeScript を書かせるなど柔軟に対応) • 好きなモデルはGemini 3、開発ツールはClaude Code
4. © Findy Inc. 4 今⽇話すこと 1. Findy Insightsのご紹介 2. 開発の流れ 〜 PoCから本番実装 2.1. プロトタイプ作成⼿法の詳細 3. 設計振り返り Good編 4. 設計振り返り More編 5. まとめ
5. © Findy Inc. 5 Take Home Message 生成AIで“合意形成の回転数 ”を上げつつ、既存基盤で “運用リスク ”を下げ、スピードと安定を両取りできた • 「1日1プロトタイプ」の圧倒的スピード AI活用によるローコストなプロトタイプ作成でプロダクト マネージャー (PdM) との合意形成サイクルを極限まで短縮。 • 「既存資産」による安定稼働 ベクトルDB含むDB設計や認証基盤設計、非同期処理等は 既存バックエンドチームの知見（Python外の技術含む）をフル活 用。AIにより素早くこれらの知見を実装。
6. © Findy Inc. 6 Findy Insightsのご紹介
7. © Findy Inc. 内部処理概要 7 ⾳声‧テキストデータを アップロード PostgreSQL (pgvector) ユーザ レスポンス AIエージェント クエリ RAG S3 ⽂字起こし
8. © Findy Inc. 8 開発の流れ PoCから本番実装まで
9. © Findy Inc. 開発チームの前提 9 1. Findy Team+の開発メンバー5名+奥⽥ 開発メンバーはミドル〜シニア 2. 奥⽥以外にLLMプロダクト開発経験なし 3. Findy Team+はRubyで開発してきたため、 Pythonの経験もチームとしてほぼなし
10. © Findy Inc. 開発の時系列 10 1. 2⽉：PoC開始 ひたすら技術検証とプロトタイプ作成 2. 5⽉：開発チームが集まる場でプロトタイプを⾒せながら キックオフ 3. 6⽉：開発チームと「どう実装するか」を 相談しつつ開発 4. 9⽉：α版リリース🎉 新機能開発へ…
11. © Findy Inc. プロトタイプ起点の開発フロー 11 1. 奥⽥がPdMから要望をヒアリングし、 プロトタイプとして反映 2. 実動するプロトタイプで、UXや挙動の認識齟齬を 早期解消 3. 開発チームとコードベースで連携し、本番実装への 落とし込みを策定 → アジャイル開発における (コードを書く) ビジネスアナリストに近い
12. © Findy Inc. 12 プロトタイプ作成時に⼼がけたこと PoC編
13. © Findy Inc. プロトタイプ作成時に⼤事にしたこと (PoC編) 13 1. 並列処理による処理時間短縮 PoC段階では素早い試⾏錯誤が必須。 LLMにリクエストを投げる部分には並列処理を採⽤して 1回あたりの実験にかかる時間を短縮。 2. 細かいロギング どこでコケたかを素早く特定することでデバッグ時間を 短縮し、実験時間を確保。
14. © Findy Inc. プロトタイプ作成時に捨てたこと (PoC編) 14 1. エラーハンドリング‧テスト エラー即落ち。リトライや単体テスト⼀切無し。 2. 複雑なフロントエンド実装 ドラッグ&ドロップで⾳声ファイルをアップロードし、 処理時間を確認できるだけ。 3. 複雑なインフラ Cloud Runでバックエンドと フロントコンテナをデプロイ。
15. © Findy Inc. 15 プロトタイプ作成時に⼼がけたこと 新機能編
16. © Findy Inc. プロトタイプ作成時に⼤事にしたこと (新機能編) 16 1. 既存技術スタックとの整合性 テーブル定義やUIライブラリは本番準拠のものを使い、 細かい部分も含めた実現可能性を担保。 2. フロントだけでなくデータや処理フローも作成 処理にどの程度の時間がかかるか、精度はどの程度かを 確認することで、本番実装時に最適な処理フローを エンジニアが考慮できるように。
17. © Findy Inc. プロトタイプ作成時に捨てたこと (新機能編) 17 1. エラーハンドリング‧テスト エラー即落ち。リトライや単体テスト⼀切無し。 2. インフラへのデプロイ 必要ならGitHub⾒て⾃分でローカルビルドしてね (AIにビルドさせてね)」という⽅針。 3. Figmaとのデザイン完全⼀致 技術的に表現できるか怪しい部分は検証するが、 細かいレイアウトやUIにはこだわらない。
18. © Findy Inc. 18 設計ふりかえり Good編
19. © Findy Inc. Good 1: レビュープロセスで技術の属⼈化を防ぐ 19 課題 • LLM周りの実装は特定メンバーに集中しやすい • 技術がブラックボックス化するリスク 対策 LLM未経験メンバーも積極的にレビュー参加 (ランダムレビュワー) 効果 • チーム全体でLLM実装の知⾒が共有される • 属⼈化を防ぎ、チームの技術⼒が底上げされた
20. © Findy Inc. Good 2: pgvector + HNSW インデックス 20 背景 • ニアリアルタイム更新のRAGが必要 • RDBとしてPostgreSQLを選定する予定 • チームにRAG構築経験者が奥⽥だけ メリット • 新しいDBを追加する必要なし • データ不整合のリスクが低く、運⽤コストが増えない • バックエンドエンジニアにも馴染みがある
21. © Findy Inc. 21 設計ふりかえり More編
22. © Findy Inc. More 1: LangChain から LangGraph への移⾏ 22 現状と課題 • LangChain のシンプルなチェーンを使⽤ • 複雑なフロー制御が難しい 選定の背景 開発当初はLangGraphはオーバースペックと思っていた 期待される改善 • 条件分岐やループが明⽰的で状態遷移が可視化される → デバッグ性向上 & 新しいノード (機能) の追加が容易
23. © Findy Inc. More 2: LLMを含む関数のテスト戦略 23 現状の課題 LLM の出⼒が⾮決定的で従来のCIに適⽤しづらい → 品質劣化の検出が困難 この⽅向性のLLM Observabilityもまだ発展途上という認識... LLMのテストにおけるベストプラクティスは模索中です。 知⾒をお持ちの⽅は、ぜひ懇親会で情報交換させてください。
24. © Findy Inc. 24 まとめ
25. © Findy Inc. 25 Take Home Message (再掲) 生成AIで“合意形成の回転数 ”を上げつつ、既存基盤で “運用リスク ”を下げ、スピードと安定を両取りできた • 「1日1プロトタイプ」の圧倒的スピード AI活用によるローコストなプロトタイプ作成でPdMとの 合意形成サイクルを極限まで短縮。 • 「既存資産」による安定稼働 ベクトルDB含むDB設計や認証基盤設計、非同期処理等は 既存バックエンドチームの知見（Python外の技術含む）をフル活 用。AIにより素早くこれらの知見を実装。
26. © Findy Inc. ご清聴ありがとうございました 26