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
1.2k
Houtou.pm #1
papix
May 31, 2025
Tweet
Share
More Decks by papix
See All by papix
Perl歴約10年のエンジニアがフルスタックTypeScriptに出会ってみた
papix
1
520
YAPC::Kyotoの「全て」 / All of "YAPC::Kyoto"
papix
0
1.5k
イベントの中の人 / Inside the Events
papix
0
280
2022年に始めるPerlでWebサービス開発(趣味)
papix
0
540
ワーケーションに関する考察
papix
3
2.2k
(今更)Amplifyさっくり体験
papix
0
860
はてなにおけるGitHub Actions活用事例 / GitHub Actions in Hatena
papix
0
2.4k
ミススペルを発見するmisspellのご紹介 / Introduce misspell
papix
0
1.1k
「知らなかった」を聞きに行く 〜海外カンファレンス参加のススメ〜 / builderscon 2019
papix
0
350
Other Decks in Technology
See All in Technology
CDK Vibe Coding Fes
tomoki10
1
580
DatabricksにOLTPデータベース『Lakebase』がやってきた!
inoutk
0
150
ソフトウェアテストのAI活用_ver1.25
fumisuke
1
570
VGGT: Visual Geometry Grounded Transformer
peisuke
1
630
オフィスビルを監視しよう:フィジカル×デジタルにまたがるSLI/SLO設計と運用の難しさ / Monitoring Office Buildings: The Challenge of Physical-Digital SLI/SLO Design & Operation
bitkey
1
360
QuickSight SPICE の効果的な運用戦略~S3 + Athena 構成での実践ノウハウ~/quicksight-spice-s3-athena-best-practices
emiki
0
260
cdk initで生成されるあのファイル達は何なのか/cdk-init-generated-files
tomoki10
1
580
Amplify Gen2から知るAWS CDK Toolkit Libraryの使い方/How to use the AWS CDK Toolkit Library as known from Amplify Gen2
fossamagna
1
280
NewSQLや分散データベースを支えるRaftの仕組み - 仕組みを理解して知る得意不得意
hacomono
PRO
3
230
Delegating the chores of authenticating users to Keycloak
ahus1
0
180
united airlines ™®️ USA Contact Numbers: Complete 2025 Support Guide
flyunitedhelp
1
470
ABEMAの本番環境負荷試験への挑戦
mk2taiga
5
860
Featured
See All Featured
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
53
2.9k
Become a Pro
speakerdeck
PRO
29
5.4k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
507
140k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
7
740
Art, The Web, and Tiny UX
lynnandtonic
299
21k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
29
9.6k
A Tale of Four Properties
chriscoyier
160
23k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
31
2.4k
How GitHub (no longer) Works
holman
314
140k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
30
2.1k
What's in a price? How to price your products and services
michaelherold
246
12k
[RailsConf 2023] Rails as a piece of cake
palkan
55
5.7k
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 ご清聴ありがとうございました!