AI機能における UI設計とアーキテクチャの教訓

Transcript

1. AI 機能における UI 設計とアーキテクチャの教訓 Develop チーム 片倉 ktkr 春彦 Hubble 「20 Weeks by Hubble AI 」でハマった🕳️
2. 自己紹介 片倉 "ktkr" 春彦 株式会社Hubble Develop チーム Dev-eX バックエンド開発 Ruby, Rails, Java, LLM... 🍺🍶☕️🧖🚴🏂🚗🩼 原発から出会い系まで硬軟さまざまなプロジェクトに揉まれ、 流浪の末に Hubble に辿り着いた男 Role: Tech: Hobby:
3. 背景：先日完走したプロジェクト 20 Weeks by Hubble AI 🏁 20 週連続でAI 機能をリリースする狂気的な挑戦 先日、無事に完走しました🎉 今回のテーマ 「10 Weeks by Hubble AI 」第10 弾：申請プロセスを AI で整理で発生した「設計とアーキテクチャの教訓」
4. PoC は順調でした（過去形） ✅ PoC ( 理想) 単発の処理で検証 レスポンス：数秒 「これならいける！」と確信 ⚠️ 本番 ( 現実) リリース翌日… API レスポンス：最大30 秒 エラーは出ないが永遠のLoading… ユーザー体験としては「死んでいる」も同然でした。
5. 設計の敗北 ⚡️ 既存UI ( ウィザード) 同期的 サクサク進みたい VS 🐢 AI 処理 (LLM) 非同期的 試行錯誤と待ち時間 「待てないUI 」に「待たせる処理」を 無理やりねじ込んだ結果の破綻。
6. 現状：20 週を走り抜けてなお、続く戦い 🚧 応急処置 テキスト抽出処理の最適化 キャッシュ戦略の見直し 処理の非同期化 🔥 根本解決はまだ道半ば 「複数回のLLM 処理」をどうUX に落とし込むか？ ウィザード形式からの脱却も含めて再検討中 プロジェクトは完走しましたが、Develop チームの戦いは終わっていません。
7. まとめ：今回の学び 1. 既存のUI （ウィザード等）にAI を安易に乗せてはいけない AI の「推論時間」はDB アクセスとは桁が違う 直列実行が必要なら、UI 自体を「待てる形」に変えるべき 2. ボトルネックはアーキテクチャにある 精度だけでなく、 「UX としての速度」を設計段階で考慮する Hubble のAI 機能は、こうした泥臭い改善を積み重ねて進化しています。 （共感してくれた方、後で乾杯しましょう🍻）
8. Thank You! Hubble Develop Team