Houtou.pm #1

Transcript

1. 本資料は、トグルホールディングス株式会社に許可なく複製・転載をしないようお願いします。 AI時代の 社内Webサービス ⽴ち上げ事例のご紹介
2. © toggle holdings inc. 2
 papix（パピックス） 所属 2025/01〜 トグルホールディングス株式会社 出⾝ Perl界隈 - （⼀社）JPA理事 - 湘南.pm / 湘.なんか ⾸魁 趣味 旅⾏、料理 SNS X: @__papix__ / id:papix
3. © toggle holdings inc. 3
 事例: Conversation Stocker
4. © toggle holdings inc. 4
 前提: CTO室 • 4⽉に発⾜ • CTOのid:myfinderの下に4⼈のエンジニアが集まる • そのタスクの1つとして、 「会話資本の実現」が挙がった
5. © toggle holdings inc. 5
 前提: 「会話」は資本 • ※以下は社内の会話に基づくpapixの理解 • 資本: 事業活動や経済活動の元⼿となるリソース（主に資⾦） • 事業活動には情報が必要 ◦ ⼈間が情報を整理して、そこから意味を⾒出す • LLMの登場により状況が変化 ◦ LLMが情報を整理してくれる ◦ ⼈間が整理するより、⼤量の情報を整理できる
6. © toggle holdings inc. 6
 前提: 「会話」は資本 • LLMに情報を整理させるとなると、テキスト化が重要 ◦ LLMのinputはテキストが良い ◦ すべての会話がテキストコミュニケーションだと良いが… • テキスト化が難しい（⾳声でやり取りする）場⾯もある ◦ 1on1、⾯接（⾯談）、商談、発表… ◦ ⾳声でコミュニケーションする⽅が良い場⾯も当然ある
7. © toggle holdings inc. 7
 前提: 「会話」は資本 • 資本たる「会話」を蓄積する必要がある ◦ その道具として「Conversation Stocker」を開発！ • 社内向けにリリース、既に「会話」の蓄積を開始 ◦ 「活⽤」の部分はまだまだこれから… ◦ 今はとにかく「蓄積」しておけば、後から使えるはず ▪ AI/LLMの進化でさらなる可能性が広がる（かも）
8. © toggle holdings inc. 8
 Conversation Stocker • 資本たる「会話（Conversation）」を蓄積（Stock）する
9. © toggle holdings inc. 9
 Conversation Stocker • 資本たる「会話（Conversation）」を蓄積（Stock）する ◦ ⽂字起こし精度は課題 ◦ 「Houtou.pm」が 「砲塔.pm」に… • しかし、後で会話を思い出し て⽂字起こしするよりはマシ 砲塔？
10. © toggle holdings inc. 10
 Conversation Stocker 開発の流れ
11. © toggle holdings inc. 11
 1. プロトタイピング • 技術検証を兼ねたプロトタイピング（2週間程度） ◦ v0を使ったプロトタイピングの開発 ◦ Azure Batch Transcriptionの試⽤ ◦ まずは動くモノを作ってみる • Cursorで磨き込み、プロトタイプをリリース ◦ まずは使ってもらう、課題を⾒つける
12. © toggle holdings inc. 12
 v0 • Vercelが開発したWebサービス開発ツール ◦ プロンプトからUIを含むWebサービスをまるっと⽣成する ことができる ◦ Neon（Serverless Postgres）と連携してデータの保存な ども可能 ▪ Vercel Blobなどもあるが… • 開発したWebサービスはVercel上で稼働する
13. © toggle holdings inc. 13
 v0 • 環境変数設定のUXが良い（と思う） ◦ 「◯◯のAPIを使ってXXXをしたいです」と依頼すると、 API Tokenの⼊⼒画⾯が表⽰される • ⼊⼒したものは、Vercelの Environment Variablesとして保持 ◦ 意図せずユーザーに露出することを 防ぐことができる
14. © toggle holdings inc. 14
 v0感想 • プロトタイプ⽣成ツールとして有意義 ◦ 従来は、ヒアリング→プロトタイプ開発、という流れ ◦ v0を使えば、プロトタイプ開発のコストを最⼩にできる ◦ まずはv0でプロトタイプを作って、ヒアリングしてブラッ シュアップする、という流れが作れる
15. © toggle holdings inc. 15
 v0感想 • …というか、顧客がプロトタイプを作れるのでは？ ◦ エンジニアはその実現を⽀援すればよい、という世界観？ ◦ toggleでも実際に営業職の⽅がv0でプロトタイプを作って エンジニアと相談したり、という流れができつつある
16. © toggle holdings inc. 16
 v0感想 • とはいえv0にも限界はある ◦ セキュリティ⾯など、そのまま実運⽤に載せられない ◦ ⼀定のコード量を超えるとポンコツになる（気がする） • ある程度まで⾏くと、v0を脱出する必要がある ◦ 従来はv0を脱すると戻れなかった ◦ 最近はGitHub連携でまたv0に戻って開発する、みたいなこ ともできるようになった、らしい…
17. © toggle holdings inc. 17
 Cursor • v0である程度プロトタイプを作って、Cursorで磨き込み ◦ toggleでは何故か（？）Cursor派閥が多い
18. © toggle holdings inc. 18
 Cursor感想 • 便利！！！ ◦ tab押すだけで、なんかそれっぽくなる • Agentはキャラクター付けすると愛着が湧く ◦ ⾃分はずんだもん⾵にしています ◦ ミスっても「ずんだもんだし…」 という気持ちになる ◦ 語尾が独特なキャラがオススメ
19. © toggle holdings inc. 19
 プロトタイプ運⽤ • v0を作ってCursorで磨き込んだものを実リリース ◦ 4⽉中頃から開発を始めて、だいたい4⽉末くらい？ • いくつか課題が⾒つかった ◦ ⾳声データの⽋損が頻発 ◦ ⽂字起こし精度に課題
20. © toggle holdings inc. 20
 2. プロトタイピングを捨てて正式版の開発 • プロトタイプは勢いよく捨てる！！！ ◦ データスキーマ、UIの再設計 ◦ 5⽉辺りから開始して、3週間程度で実装 • 5⽉中頃から実運⽤を開始！
21. © toggle holdings inc. 21
 正式版の開発にあたって意識したこと • コンテキストを⼩さくする ◦ コード量が増えると、⼈間もAIも認知負荷が⾼まる ▪ →マイクロサービス⾵ ◦ 細かい便利サービスを作れば、誰かが活⽤できる ▪ APIを提供して、これを組み合わせて価値を創造できる ▪ いわゆる「マッシュアップ」みたいな…
22. © toggle holdings inc. 22
 Conversation Stockerの構成 • 以下の3コンポーネントで構成 ◦ Conversation Stocker（本体） ◦ Transcriptor ◦ benri-worker
23. © toggle holdings inc. 23
 Conversation Stocker • 構成: Next.js ＋ Vercel ＋ Neon • ユーザー向けインターフェイスを担う ◦ 録⾳した会話は後述のTranscriptorに保存、⽂字起こしを 提供する
24. © toggle holdings inc. 24
 Transcriptor • 構成: Hono ＋ Vercel ＋ Neon ＋ Azure Blob Service • 会話⾳声の保存と⽂字起こしを担う ◦ ⾳声はAzure Blob Serviceに保存 ◦ ⾳声保存や⽂字起こしのためのAPIを提供 • 複数の⽂字起こしサービスを統⼀的なインターフェイスで提供 ◦ 但し現時点ではAzure Batch Transcriptionのみ対応…
25. © toggle holdings inc. 25
 benri-worker • 構成: Express ＋ Cloud Run ◦ 動画（Google Meetの録画）を⽂字起こしするにあたっ て、MP4を⾳声に変換する必要があった ◦ しかし、Vercelでffmpegを動かすのは困難… • 動画のURLを与えて、Cloud Runでffmpegを実⾏する • 余談: Expressなのはサンプルコードをそのまま使ったため…
26. © toggle holdings inc. 26
 AI時代の プロダクト開発
27. © toggle holdings inc. 27
 AI時代のプロダクト開発 • ※以下個⼈の⾒解です ◦ ⾼速にプロトタイプを開発、勢いよく捨てる ◦ まだまだエンジニアによる磨き込みは必要 ◦ 価値を提供する⼩さいサービスの連携が重要
28. © toggle holdings inc. 28
 ⾼速にプロトタイプを開発、勢いよく捨てる • v0などで⾼速‧低コストにプロトタイプを開発する ◦ ヒアリングはアテにならない（ことが多い…） ◦ 「動くもの」だとイメージが湧きやすい ▪ 追加で何が必要か、何が不要か • ⾼速‧低コストに作ったものなので、捨てやすい ◦ 正式版として、ブラッシュアップしたものを作れる
29. © toggle holdings inc. 29
 まだまだエンジニアによる磨き込みは必要 • データスキーマ ◦ UIよりもデータスキーマは変えにくい ◦ ⻑期的な運⽤に耐えられるスキーマ設計はやはりまだ⼈間 の⼒が必要 • セキュリティ ◦ v0で開発したプロダクトは、認証周りなど不⼗分な点があ る（と思った）
30. © toggle holdings inc. 30
 価値を提供する⼩さいサービスの連携が重要 • コンテキストを狭めるのが重要 ◦ 特定のコンテキストは他のサービスに任せる ▪ 再利⽤が可能になる • APIで連携できるようにする ◦ v0でAPIを組み合わせて価値提供が可能になる ◦ エンジニアではない⼈が、APIを組み合わせてv0などでプロ ダクトを作り、課題解決ができる時代が来るかも…？
31. © toggle holdings inc. 31
 価値を提供する⼩さいサービスの連携で必要なこと • APIを使わせる ◦ …ためにはAPI仕様をMachine Readableにする必要がある • 以前、v0で⽣成したAPIドキュメントを別のv0に⾷わせたこと があるが、それでもうまく連携してくれた ◦ …が、既存の良い仕組みに乗っかりたい
32. © toggle holdings inc. 32
 @hono/zod-openapi • Hono/zod/OpenAPIをベースにAPI開発ができる • @hono/swagger-uiも便利 ◦ SwaggerのUI上でAPIを試すこともできる • Conversation Stockerの場合… ◦ Transcriptorを@hono/zod-openapiで開発、APIを提供
33. © toggle holdings inc. 33
 @moznion/openapi-fetch-gen • OpenAPIの定義からopenapi-fetchを使ったClientを⾃動的に ⽣成できる • Conversation Stockerの場合… ◦ TranscriptorのAPIクライアントを⾃動⽣成 ◦ Transcriptorの仕様を変更しても、OpenAPIの仕様から Clientを⽣成できるので、実装コストが低減 • 「Clientも書き換えるの⾯倒だな…」でAPIの修正に躊躇するの を防げる（？）
34. © toggle holdings inc. 34
 まとめ
35. © toggle holdings inc. 35
 まとめ • 会話資本を活かすために「Conversation Stocker」を開発 • AI時代の開発として、次を意識した ◦ ⾼速にプロトタイプ開発、捨ててブラッシュアップ ◦ エンジニアの⼿でしっかり磨き込む ◦ APIを活⽤してコンテキストを狭める • Conversation Stocker、気になる？ ◦ ぜひ⼊社して君の⽬で確かめてくれ！！！！！！！！
36. © toggle holdings inc. 36
 ご清聴ありがとうございました！