Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Houtou.pm #1
Search
papix
May 31, 2025
Technology
0
480
Houtou.pm #1
papix
May 31, 2025
Tweet
Share
More Decks by papix
See All by papix
Perl歴約10年のエンジニアがフルスタックTypeScriptに出会ってみた
papix
1
340
YAPC::Kyotoの「全て」 / All of "YAPC::Kyoto"
papix
0
1.5k
イベントの中の人 / Inside the Events
papix
0
270
2022年に始めるPerlでWebサービス開発(趣味)
papix
0
530
ワーケーションに関する考察
papix
3
2.2k
(今更)Amplifyさっくり体験
papix
0
850
はてなにおけるGitHub Actions活用事例 / GitHub Actions in Hatena
papix
0
2.3k
ミススペルを発見するmisspellのご紹介 / Introduce misspell
papix
0
1.1k
「知らなかった」を聞きに行く 〜海外カンファレンス参加のススメ〜 / builderscon 2019
papix
0
340
Other Decks in Technology
See All in Technology
VueUseから学ぶ実践TypeScript #TSKaigi #TSKaigi2025
bengo4com
3
5.3k
Postman AI エージェントビルダー最新情報
nagix
0
170
カンファレンスのつくりかた / The Conference Code: What Makes It All Work
tomzoh
7
830
アプリケーションの中身が見える!Mackerel APMの全貌と展望 / Mackerel APMリリースパーティ
mackerelio
0
350
mnt_data_とは?ChatGPTコード実行環境を深堀りしてみた
icck
0
170
Standard Schema: スキーマライブラリの統一企画とは何か
nozomuikuta
1
490
研究開発部メンバーの働き⽅ / Sansan R&D Profile
sansan33
PRO
3
17k
AIに実況させる / AI Streamer
motemen
3
1.3k
AIのための オンボーディングドキュメントを整備する - hirotea
hirotea
9
2.1k
Introduction to Sansan for Engineers / エンジニア向け会社紹介
sansan33
PRO
5
37k
MCP で繋ぐ Figma とデザインシステム〜LLM を使った UI 実装のリアル〜
kimuson
1
1k
ITエンジニアを取り巻く環境とキャリアパス / A career path for Japanese IT engineers
takatama
3
1.5k
Featured
See All Featured
4 Signs Your Business is Dying
shpigford
183
22k
Unsuck your backbone
ammeep
671
58k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
105
19k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
5
610
Into the Great Unknown - MozCon
thekraken
38
1.8k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
331
21k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
42
2.3k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
228
22k
Building Flexible Design Systems
yeseniaperezcruz
329
39k
Keith and Marios Guide to Fast Websites
keithpitt
411
22k
Building Applications with DynamoDB
mza
95
6.4k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
25
2.8k
Transcript
本資料は、トグルホールディングス株式会社に許可なく複製・転載をしないようお願いします。 AI時代の 社内Webサービス ⽴ち上げ事例のご紹介
© toggle holdings inc. 2 papix(パピックス) 所属 2025/01〜 トグルホールディングス株式会社 出⾝
Perl界隈 - (⼀社)JPA理事 - 湘南.pm / 湘.なんか ⾸魁 趣味 旅⾏、料理 SNS X: @__papix__ / id:papix
© toggle holdings inc. 3 事例: Conversation Stocker
© toggle holdings inc. 4 前提: CTO室 • 4⽉に発⾜ •
CTOのid:myfinderの下に4⼈のエンジニアが集まる • そのタスクの1つとして、 「会話資本の実現」が挙がった
© toggle holdings inc. 5 前提: 「会話」は資本 • ※以下は社内の会話に基づくpapixの理解 •
資本: 事業活動や経済活動の元⼿となるリソース(主に資⾦) • 事業活動には情報が必要 ◦ ⼈間が情報を整理して、そこから意味を⾒出す • LLMの登場により状況が変化 ◦ LLMが情報を整理してくれる ◦ ⼈間が整理するより、⼤量の情報を整理できる
© toggle holdings inc. 6 前提: 「会話」は資本 • LLMに情報を整理させるとなると、テキスト化が重要 ◦
LLMのinputはテキストが良い ◦ すべての会話がテキストコミュニケーションだと良いが… • テキスト化が難しい(⾳声でやり取りする)場⾯もある ◦ 1on1、⾯接(⾯談)、商談、発表… ◦ ⾳声でコミュニケーションする⽅が良い場⾯も当然ある
© toggle holdings inc. 7 前提: 「会話」は資本 • 資本たる「会話」を蓄積する必要がある ◦
その道具として「Conversation Stocker」を開発! • 社内向けにリリース、既に「会話」の蓄積を開始 ◦ 「活⽤」の部分はまだまだこれから… ◦ 今はとにかく「蓄積」しておけば、後から使えるはず ▪ AI/LLMの進化でさらなる可能性が広がる(かも)
© toggle holdings inc. 8 Conversation Stocker • 資本たる「会話(Conversation)」を蓄積(Stock)する
© toggle holdings inc. 9 Conversation Stocker • 資本たる「会話(Conversation)」を蓄積(Stock)する ◦
⽂字起こし精度は課題 ◦ 「Houtou.pm」が 「砲塔.pm」に… • しかし、後で会話を思い出し て⽂字起こしするよりはマシ 砲塔?
© toggle holdings inc. 10 Conversation Stocker 開発の流れ
© toggle holdings inc. 11 1. プロトタイピング • 技術検証を兼ねたプロトタイピング(2週間程度) ◦
v0を使ったプロトタイピングの開発 ◦ Azure Batch Transcriptionの試⽤ ◦ まずは動くモノを作ってみる • Cursorで磨き込み、プロトタイプをリリース ◦ まずは使ってもらう、課題を⾒つける
© toggle holdings inc. 12 v0 • Vercelが開発したWebサービス開発ツール ◦ プロンプトからUIを含むWebサービスをまるっと⽣成する
ことができる ◦ Neon(Serverless Postgres)と連携してデータの保存な ども可能 ▪ Vercel Blobなどもあるが… • 開発したWebサービスはVercel上で稼働する
© toggle holdings inc. 13 v0 • 環境変数設定のUXが良い(と思う) ◦ 「◯◯のAPIを使ってXXXをしたいです」と依頼すると、
API Tokenの⼊⼒画⾯が表⽰される • ⼊⼒したものは、Vercelの Environment Variablesとして保持 ◦ 意図せずユーザーに露出することを 防ぐことができる
© toggle holdings inc. 14 v0感想 • プロトタイプ⽣成ツールとして有意義 ◦ 従来は、ヒアリング→プロトタイプ開発、という流れ
◦ v0を使えば、プロトタイプ開発のコストを最⼩にできる ◦ まずはv0でプロトタイプを作って、ヒアリングしてブラッ シュアップする、という流れが作れる
© toggle holdings inc. 15 v0感想 • …というか、顧客がプロトタイプを作れるのでは? ◦ エンジニアはその実現を⽀援すればよい、という世界観?
◦ toggleでも実際に営業職の⽅がv0でプロトタイプを作って エンジニアと相談したり、という流れができつつある
© toggle holdings inc. 16 v0感想 • とはいえv0にも限界はある ◦ セキュリティ⾯など、そのまま実運⽤に載せられない
◦ ⼀定のコード量を超えるとポンコツになる(気がする) • ある程度まで⾏くと、v0を脱出する必要がある ◦ 従来はv0を脱すると戻れなかった ◦ 最近はGitHub連携でまたv0に戻って開発する、みたいなこ ともできるようになった、らしい…
© toggle holdings inc. 17 Cursor • v0である程度プロトタイプを作って、Cursorで磨き込み ◦ toggleでは何故か(?)Cursor派閥が多い
© toggle holdings inc. 18 Cursor感想 • 便利!!! ◦ tab押すだけで、なんかそれっぽくなる
• Agentはキャラクター付けすると愛着が湧く ◦ ⾃分はずんだもん⾵にしています ◦ ミスっても「ずんだもんだし…」 という気持ちになる ◦ 語尾が独特なキャラがオススメ
© toggle holdings inc. 19 プロトタイプ運⽤ • v0を作ってCursorで磨き込んだものを実リリース ◦ 4⽉中頃から開発を始めて、だいたい4⽉末くらい?
• いくつか課題が⾒つかった ◦ ⾳声データの⽋損が頻発 ◦ ⽂字起こし精度に課題
© toggle holdings inc. 20 2. プロトタイピングを捨てて正式版の開発 • プロトタイプは勢いよく捨てる!!! ◦
データスキーマ、UIの再設計 ◦ 5⽉辺りから開始して、3週間程度で実装 • 5⽉中頃から実運⽤を開始!
© toggle holdings inc. 21 正式版の開発にあたって意識したこと • コンテキストを⼩さくする ◦ コード量が増えると、⼈間もAIも認知負荷が⾼まる
▪ →マイクロサービス⾵ ◦ 細かい便利サービスを作れば、誰かが活⽤できる ▪ APIを提供して、これを組み合わせて価値を創造できる ▪ いわゆる「マッシュアップ」みたいな…
© toggle holdings inc. 22 Conversation Stockerの構成 • 以下の3コンポーネントで構成 ◦
Conversation Stocker(本体) ◦ Transcriptor ◦ benri-worker
© toggle holdings inc. 23 Conversation Stocker • 構成: Next.js
+ Vercel + Neon • ユーザー向けインターフェイスを担う ◦ 録⾳した会話は後述のTranscriptorに保存、⽂字起こしを 提供する
© toggle holdings inc. 24 Transcriptor • 構成: Hono +
Vercel + Neon + Azure Blob Service • 会話⾳声の保存と⽂字起こしを担う ◦ ⾳声はAzure Blob Serviceに保存 ◦ ⾳声保存や⽂字起こしのためのAPIを提供 • 複数の⽂字起こしサービスを統⼀的なインターフェイスで提供 ◦ 但し現時点ではAzure Batch Transcriptionのみ対応…
© toggle holdings inc. 25 benri-worker • 構成: Express +
Cloud Run ◦ 動画(Google Meetの録画)を⽂字起こしするにあたっ て、MP4を⾳声に変換する必要があった ◦ しかし、Vercelでffmpegを動かすのは困難… • 動画のURLを与えて、Cloud Runでffmpegを実⾏する • 余談: Expressなのはサンプルコードをそのまま使ったため…
© toggle holdings inc. 26 AI時代の プロダクト開発
© toggle holdings inc. 27 AI時代のプロダクト開発 • ※以下個⼈の⾒解です ◦ ⾼速にプロトタイプを開発、勢いよく捨てる
◦ まだまだエンジニアによる磨き込みは必要 ◦ 価値を提供する⼩さいサービスの連携が重要
© toggle holdings inc. 28 ⾼速にプロトタイプを開発、勢いよく捨てる • v0などで⾼速‧低コストにプロトタイプを開発する ◦ ヒアリングはアテにならない(ことが多い…)
◦ 「動くもの」だとイメージが湧きやすい ▪ 追加で何が必要か、何が不要か • ⾼速‧低コストに作ったものなので、捨てやすい ◦ 正式版として、ブラッシュアップしたものを作れる
© toggle holdings inc. 29 まだまだエンジニアによる磨き込みは必要 • データスキーマ ◦ UIよりもデータスキーマは変えにくい
◦ ⻑期的な運⽤に耐えられるスキーマ設計はやはりまだ⼈間 の⼒が必要 • セキュリティ ◦ v0で開発したプロダクトは、認証周りなど不⼗分な点があ る(と思った)
© toggle holdings inc. 30 価値を提供する⼩さいサービスの連携が重要 • コンテキストを狭めるのが重要 ◦ 特定のコンテキストは他のサービスに任せる
▪ 再利⽤が可能になる • APIで連携できるようにする ◦ v0でAPIを組み合わせて価値提供が可能になる ◦ エンジニアではない⼈が、APIを組み合わせてv0などでプロ ダクトを作り、課題解決ができる時代が来るかも…?
© toggle holdings inc. 31 価値を提供する⼩さいサービスの連携で必要なこと • APIを使わせる ◦ …ためにはAPI仕様をMachine
Readableにする必要がある • 以前、v0で⽣成したAPIドキュメントを別のv0に⾷わせたこと があるが、それでもうまく連携してくれた ◦ …が、既存の良い仕組みに乗っかりたい
© toggle holdings inc. 32 @hono/zod-openapi • Hono/zod/OpenAPIをベースにAPI開発ができる • @hono/swagger-uiも便利
◦ SwaggerのUI上でAPIを試すこともできる • Conversation Stockerの場合… ◦ Transcriptorを@hono/zod-openapiで開発、APIを提供
© toggle holdings inc. 33 @moznion/openapi-fetch-gen • OpenAPIの定義からopenapi-fetchを使ったClientを⾃動的に ⽣成できる •
Conversation Stockerの場合… ◦ TranscriptorのAPIクライアントを⾃動⽣成 ◦ Transcriptorの仕様を変更しても、OpenAPIの仕様から Clientを⽣成できるので、実装コストが低減 • 「Clientも書き換えるの⾯倒だな…」でAPIの修正に躊躇するの を防げる(?)
© toggle holdings inc. 34 まとめ
© toggle holdings inc. 35 まとめ • 会話資本を活かすために「Conversation Stocker」を開発 •
AI時代の開発として、次を意識した ◦ ⾼速にプロトタイプ開発、捨ててブラッシュアップ ◦ エンジニアの⼿でしっかり磨き込む ◦ APIを活⽤してコンテキストを狭める • Conversation Stocker、気になる? ◦ ぜひ⼊社して君の⽬で確かめてくれ!!!!!!!!
© toggle holdings inc. 36 ご清聴ありがとうございました!