Vibe Coding×プロダクト開発：リプレイス高速化の舞台裏

2025-06-16 セミナー『Vibe Coding×プロダクト開発：リプレイス高速化の舞台裏』のスライドです

Transcript

1. 1 Vibe Coding×プロダクト開発 ゼロイチだけじゃない！ ⼤規模プロジェクトでの活⽤法 武⽥ ⼤佑 (どすこい) GMOペパボ株式会社 EC事業部 プロダクトチーム 2025.06.19
2. 2 アジェンダ 1. ⾃⼰紹介 2. Vibe Codingとは 3. 事例紹介 4. 知⾒とまとめ
3. 3 アジェンダ 1. ⾃⼰紹介 2. Vibe Codingとは 3. 事例紹介 4. 知⾒とまとめ
4. ⾃⼰紹介 4
5. 5 ⾃⼰紹介 EC事業部 プロダクトチーム 武⽥ ⼤佑 Daisuke Takeda どすこいと名乗っています！ 去年はNext.jsの開発が多かったですが、 最近はバックエンドの開発を主にしています。 業務活⽤とは別に、AIやLLMに興味があり、 それらの領域で登壇もしてました (ICONIP2024, JASAI2024) • X: @doskoi64
6. 6 私たちは「⼈類のアウトプットを増やす」ことをミッションとし、 インターネットやテクノロジーの⼒で情報発信のハードルを下げる⽀援をしています。
7. 7 アジェンダ 1. ⾃⼰紹介 2. Vibe Codingとは 3. 事例紹介 4. 知⾒とまとめ
8. Vibe Codingとは 8
9. ペパボのコンテンツを引⽤します 9 Vibe Codingとは https://speakerdeck.com/daisuketakeda/vi becodingshi-dai-noenziniaringu https://tech.pepabo.com/2025/04/04/decla ration-vibe-coding-training/
10. 10 完全に雰囲気に⾝を任せて、コードの 詳細に気を払わず、⾃然⾔語だけで指 ⽰をしてコーディングする Andrej Karpathy (X:@karpathy) 2025-02 OpenAIの創設メンバー Vibe Codingとは Vibe Codingとは
11. 11 2022 ~ 2023 Vibe Codingとは
12. 12 2024 ~ 今 Vibe Codingとは
13. 13 ⼈間とAIのドライバー交代
14. 14 https://staff.persol-xtech.co.jp/hatalabo/mono_engineer/568.html Vibe Codingとは
15. 15 Vibe Codingとは コーディングにおける“⾃動運転”のレベル https://speakerdeck.com/watany/the-end-of-the-special-time-granted-to-engineers?slide=36
16. 16 ⼈間が数⼗、数百⾏コードを1⽇で書くところ... AIを使えば1万⾏書くことができる 圧倒的な量を誰でも書くことができる ⼈間とAIのドライバー交代 Vibe Codingとは
17. 17 コードを検証できない コードを更新できない コードを保証できない 祈ることしかできない 1万⾏コードを簡単にリリースできない Vibe Codingとは
18. 18 AIによる圧倒的な量を どうやって価値へ繋げるのか Vibe Codingとは
19. 19 AIによる桁違いのコードの物量をなんとかしたい！ そこで、これまで培ってきた エンジニアリング どうやって⼤量リリースするのか Vibe Codingとは
20. 20 • 優れた設計（アーキテクチャ）思想 • 変更に強いデータモデリング • 徹底された⾃動化テスト • 品質を維持するためのガードレール • 迅速かつ安全なリリースを実現するCI/CDパイプライン • 多段階の抽象度でのドキュメンテーション どうやって⼤量リリースするのか Vibe Codingとは
21. 21 ビジネス価値に繋げるために... • ⼤量リリースに対応したマーケティング • ⼤量リリースを前提としている企画、ディレクション • ⼤量リリースを対処できるカスタマーサポート エンジニアリング部⾨だけでなく、組織全体で対応していく どうやって⼤量リリースするのか Vibe Codingとは
22. 22 アジェンダ 1. ⾃⼰紹介 2. Vibe Codingとは 3. 事例紹介 4. 知⾒とまとめ
23. 事例紹介 23
24. 事例紹介 • 多数のバッチ機能のコードをGoにリプレイスします • 既存コードにはドキュメントや⾃動テストが⼗分には ない • クリーンアーキテクチャを参考にディレクトリ構成など を整え、⾃動テストも充実させたい ⽬的紹介 24
25. 事例紹介 • ドキュメントが無く⾃動テストが充実していない、古い⾔語ラ ンタイムのコードをバージョンアップ対応する実装難易度は、 AIを⽤いて全体を置き換えることとそれほど実装難易度に差が ないのではないかと考え、検証も含めて実施した • 静的解析があるコンパイル⾔語で、並列実⾏にも強みがあるGo を⽤いたリプレイスを採⽤した 経緯 25
26. 事例紹介 • ⾃動テストが充実していて、ディレクトリ構成などが 整っているGoの実装へのリプレイスをすべてのバッチ で完了する • 元の⾔語で実装されているバッチの処理を正とする • できるだけ同じプロンプトで実装を完了させる ⽬指すゴール 26
27. 事例紹介 • AIによるコード⽣成のみで実装させる⽅法を⽬指した • 最終的に、AIによる実装で、複数の置き換え作業を並 列に進められる状態を⽬指す • レビューはVibeでせず、⼈が従来の⼿法でする ⽅法 27
28. 事例紹介 • これらの状況で試⾏錯誤した様をお伝えします！ • 全然だめな実装だったNG例を3つ、 動いてよさそうだったOK例を2つ紹介します！ • みなさまのVibe Codingの知⾒に寄与できると幸いで す！ 今回のお話では... 28
29. NG例1: 単純にリプレイス元のコードを元にリプレイスするように伝える 29 事例紹介 意図 単純にリプレイス元のコードを指定して、Goにリプレイスするように指⽰ 最も単純で最低限のプロンプトでコード⽣成させた <@元のコード>をGoにリプレイスしてください。
30. NG例1: 単純にリプレイス元のコードを元にリプレイスするように伝える 30 事例紹介 結果 ⼤きなmain.go 動かなかったが、どこが原因で動いていないかの調査が困難 反省 レビューも運⽤もできない 本番環境へマージするのは困難 ⼩さいバッチ処理のコードだと、これでリプレイスが⼗分可能かもしれない
31. NG例2: 中間⽣成物を作らせてそこからgoのコードを⽣成 31 事例紹介 意図 ⼀度、仕様を⽂章にして、そこから新しくGoのコードを書かせた <@元のコード>のドキュメントをmdファイルに書いてください。 依存先、依存元や処理の詳細について書いてください。 <@中間⽣成物md>を参考に、Goへのリプレイスを書いてください。
32. NG例2: 中間⽣成物を作らせてそこからgoのコードを⽣成 32 事例紹介 結果 Goのパッケージ分割や依存するDBを扱う処理はうまくできてそう main.goが⼤きく、ほとんどそこに実装が集中してしまっている 詳細まで実装がされてなかったり、TODOのままで未実装だったりする 反省 細かく実装して、詳細まで実装して欲しい Goのパッケージ構造やディレクトリ構成を意識してファイル分割して欲しい
33. NG例3: 中間⽣成物を作ってもらう+ディレクトリ構成を指⽰+TDDで細かく実装 33 事例紹介 意図 ディレクトリ構成をREADMEで指⽰ Goパッケージの分割も明⽰ 少しずつ進めて、詳細に実装を進めて欲しいのでTDDで実装してもらう <@中間⽣成物md>を参考に、Goへのリプレイスを書いてください。 <ディレクトリ構成を書いたREADME>を参考にクリーンアーキテクチャを意 識してパッケージ分割やファイル分割をして。 細かくTDDで実装して。
34. NG例3: 中間⽣成物を作ってもらう+ディレクトリ構成を指⽰+TDDで細かく実装 34 事例紹介 結果 細かく完了を報告してくるようになった Goのパッケージ分割やディレクトリ構成が整った ファイルが細かく分けられ、テストコードもすべてに書かれた ただし、TODOで実装されてないものやモックテストが多かった 反省 元のコードがわからなくなることがあったので、リプレイス元のコードも指⽰ TDDを指⽰するより、単にテストコードを書くように指⽰
35. あとすこし...！ 35
36. OK例1: 元のコード、ドキュメント、READMEを参考+テストコードも書く 36 事例紹介 意図 リプレイス元のコードも指⽰、テストコードも書いてもらうようにした これまでの反省を⽣かした結果を詰め込んだ <@中間⽣成物md>を参考に、<@元のコード>をGoへのリプレイスを書いて ください。 <ディレクトリ構成を書いたREADME>を参考にパッケージ分割やファイル分 割をして。 それぞれの実装に、できるだけテストコードを書いて。
37. OK例1: 元のコード、ドキュメント、READMEを参考+テストコードも書く 37 事例紹介 結果 Goのパッケージ分割やディレクトリ構成が整った その上で、実装がほとんど完了していた テストコードも単純なケースは書かれていた 実⾏したら動くし、動作も正しそうだった！ 反省 まぁまぁよかったけど....
38. OK例1: 元のコード、ドキュメント、READMEを参考+テストコードも書く 38 事例紹介 結果 Goのパッケージ分割やディレクトリ構成が整った その上で、実装がほとんど完了していた テストコードも単純なケースは書かれていた 実⾏したら動くし、動作も正しそうだった！ 反省 まぁまぁよかったけど.... 巨⼤PRになってレビューが困難...！
39. もう⼀歩...！ 39
40. OK例2: タスク分解してもらう→各タスクをサブタスクにわけてTDDの指⽰ 40 事例紹介 <@中間⽣成物md>を参考に、<@元のコード>をGoへのリプレイスをします。 <ディレクトリ構成を書いたREADME>を参考にパッケージ分割やファイル分割を します。これをいくつかのタスクに分割して進めたいです。 タスク分割をしてmdに書き出してください。 <@元のコード>をGoへのリプレイスをします。 適宜、<ディレクトリ構成を書いたREADME>を参考にしてください。 今回は<タスクmd>のタスクをサブタスクに分けてTDDで実装します。 サブタスクに分解してください。 サブタスクをもとにTDDで実装していってください。
41. OK例2: タスク分解してもらう→各タスクをサブタスクにわけてTDDの指⽰ 41 事例紹介 意図 これまでの知⾒を⼊れてみる タスク分解→サブタスク分解×TDDという語をプロンプトに含め、少しずつ実 装する タスクごとにPRを切ることで、⼤きすぎないPRでマージしていける
42. OK例2: タスク分解してもらう→各タスクをサブタスクにわけてTDDの指⽰ 42 事例紹介 結果 ⼗分レビューできる⼤きさのPRに分けることができた！ テストコードも⼗分に書けている 実装の⽅向性が変な時や、意図してない動きをした時に⾒つけることができる コードの量によってPRを分けることもできる 反省 割と良い！ タスク分解、サブタスク分解で妥当かどうかは⼈間が吟味、判断が必要 タスク実⾏の粒度が⼩さいので、やり直しも簡単にさせられる
43. 知⾒とまとめ 43
44. 44 • 実装に対して必要な情報を渡して、タスクを分解し て、細かく実装してもらうと⽐較的よかった • ⼈間側も完成物に対する⾼い解像度が必要になりそう • Vibe Codingによって短時間で実装を試せるので、ガン ガン失敗しても時間浪費は短かかった 知⾒とまとめ 1/2 まとめ
45. 45 • 実装完了まで⼈間がコードを触る時間が短くなった • 設計,レビュー/検証が⼈間の仕事になりそう 知⾒とまとめ 2/2 まとめ
46. 46 AIによる圧倒的な量を どうやって価値へ繋げるのか
47. 47 Let’s Vibe