「このコード、捨てます」 カンファレンスの景品抽選アプリ開発から学ぶ、Vibe Codingの現在地

先日開催されたPHPカンファレンス関西で使った
景品の抽選アプリをVibeCodingで開発した話

Transcript

1. 「このコード、捨てます」 カンファレンスの景品抽選アプリ開発から学ぶ、Vibe Codingの現在地 </> phpカンファレンス関西アフターパーティ </>
2. わたり • CTO室 プロダクトチーム ◦ 現在はPOS開発 • AIツール ◦ 利用歴は約2年半 ▪ ChatGPTが公開されてすぐくらいから利用 ▪ 転職とほぼ同時期 ◦ 社内 ▪ AI利用のルール作り / AIツール価値検証や布教 ▪ プロダクトのAI開発最適化 ◦ プライベート ▪ AItuber作成（配信は10回くらい）
3. 今日は先日開催されたPHPカンファレンス関西で使った 景品の抽選アプリをVibeCodingで開発した話をします
4. "Vibe Coding"とは？ コードを 1 行ずつ記述するのではな く、AI アシスタントをガイドして、より 会話的なプロセスを通じてアプリケー ションを生成、改良、デバッグする ワークフローを指します。 この発表では主に人間がコードの内 容を確認したり直接編集をしないこと を指しています。
5. なぜ景品抽選アプリを作ることになったのか？ PHPerシールの交換を促す施策として、シールを集めて景品抽選するという企画が持ち 上がりました では景品の抽選をどうするか？ ガラガラや紙のくじなどいろいろ案があがりましたが どれも調整がしづらくコストも意外とかかったり 会場への持ち込み方法や返却方法も検討が必要でした 抽選を行うwebアプリもありましたが、思っているようなものがなくどれも決め手にかける 状態でした 今なら景品抽選くらいならすぐ作れるのではないかと考えました （しかし、提案して面倒だったら嫌なのでプロトタイピングします）
6. アプリ作成の流れ まずはLLMに決まっている仕様を入れました DBとしては無料で簡単に使えるものが良いので スプレッドシート かSQLiteで考えていましたが、 可能性を模索したいので最初はオープンクエスチョンで広いところから投げてみました 「カンファレンスで使う抽選アプリを作成したいです ノートpcを持ち込むのでブラウザで動いて、景品が減っていけばよいです」 「ユーザーidを入力して、1人最大5回まで抽選できます 抽選には派手なエフェクトを付けてください」 するとHTMLのコードを出してくれたのですが、 「ブラウザを閉じない限り 抽選回数が記録されます」というなかなかリスキーな提案だったので 「スプレッドシートや SQLiteと連携することはできますか？」という形で条件を明示しました
7. アプリ作成の流れ 「Googleスプレッドシートの連携に挑戦されることを強くお勧めします。」との提案 SQLiteは他端末でのセットアップが面倒だと思っていたのでスプレッドシートで確定 コードを出してもらい、指示通りに設定も進める （GASもリポジトリ内にGAS置き場のディレクトリを作成して保持->コピペ） 「エラー: Failed to fetch がでます」 みたいなことも脳死でコピペ入力しながら修正 動作確認を行い特に問題はなさそうになったので提案へ 動画をみながらだらだらやって4〜5時間程度
8. 確認 サンプルのアプリもできたので、チーム内に確認をなげました 「ガラガラなどを使う場合はいくらかかりそうです」 「意外とコストもかかり面倒なので、簡単にサンプルで抽選アプリを作成してみました」 「PC一台でもいけますが、できればスタッフの操作画面と来場者が見る画面を分けたいのでモ ニターは用意できると助かります」 「（画面録画を添付して）アプリの動作はこんな感じです」 という情報を共有しました -> 結果、アプリで行く方向で決定
9. 要件がかたまってくる 他の企画などもあり少し時間が空いて、 他チームの動向や企画、人員との兼ね合いでオペレーションが決まってきました チームと連携し、要件が固まる中で「抽選回数の管理機能」はスタンプでやるため不要 になりました しかし、抽選回数の管理はスプレッドシートのGASにもHTML側のJSにも関連処理があ ります しかしAIでは広範囲にまたがるこの機能をうまく削れませんでした
10. 一度捨てる
11. なぜ捨てたのか？ 元々の仕様が過剰だった • (現状)AIは削るのが苦手 • 調整が面倒 • 作り直しが大した手間ではない
12. 2度目の作成 今度は仕様がかなりかたまっているので最初からCursorに仕様全部入れて対応 仕様が固まっているので余計なやり取りも変なコードもなく、すぐに完成 （動作確認含めても1時間程度だったと思う） -> 提出して確認してもらう 音を付け足したりドラムロールの時間等を微調整
13. で、本番で動いたの？ 一度も問題なく、完璧に動作した 準備段階で会場のネット回線がかなり弱いことが判明、テザリングして対応 抽選は1度も問題が発生することなく無事役目を全う エラー時など万一の際の景品調整などもできるようにしていたが、起きず スプレッドシートに抽選と景品の排出日時がログとして残っている -> 何時に抽選に来る人が多かったか、どの時点でどれだけ景品が残っていたかが分析 可能
14. 実際VibeCodingしたものを利用してみてどうだったか 作るのは簡単 小さいうちはものすごい速さで作れるし改善できる 大きくなってくるとつらくなってくる 特にAIの最初の想定と異なる構造になると詰む コードは読めなくても作れるが、動作の概要（利用するツールの候補や性質、全体の動 作フローや設計）はわかっている方がよい おそらく仕様決めたりしているマネージャーならAI使うの初めてでも作れる
15. VibeCodingは実務で使えるものか？ 捨てるものを作る分にはあり MVP、使い捨ての修正用スクリプト、短納期のもの（簡単なLPやツール）など 特に、コード読むより手でテストした方が早いレベルなら有用 長期的に運用/改善するならどこかでコードを読まないといけなくなる どうにもならなくなってからコード読むとかなりしんどいので、 結局最初から読んで整えている方が楽だし最終的に早い 現状一番寿命が長くなりそうなモデルは無駄な付け足しが少ないGPT5
16. VibeCodingの現在値 「VibeCodingで100個のアプリを作りました」は比較的ハードルが低め - むしろ開発よりアイデア出しの方が大変 - 非エンジニアでコード読めずアプリを作っている人はかなり多くなっている 「VibeCodingで1サービスを1年間、改善し続けました」は、まだまだ厳しい - 初期はやれなくはないが、後で死ぬ
17. 寿命の長いプロダクトをAIを使いながら開発するには？ 計画を立てる AIは余分があると弱いので計画をしっかり立てることで寿命を延ばせる エンジニアはマネージャーか、 AIを部下にもつプレイングマネージャーかの二択になっていく コードは目を通す コードレビュー不要はまだ夢の話 AIは既存コードと似たようなコードを量産したり、付け足しでなんとかしがち -> 開発スピードも早いが負債が増えるとその増幅も早く、制御しないとすぐ死ぬ ちゃんと削るのは現状人間でないと厳しい 「リファクタして」で削ってくれることもあるが「ここ冗長では？」まで言わないとダメなときも多い AI利用で加速する開発のレビューが大変なので AIによる1次レビューも導入して負担を減らす （CodeRabbitなど）
18. 寿命の長いプロダクトをAIを使いながら開発するには？ 課題が出たらプロンプトやルールは適宜改善する • ディレクトリ構成を理解してくれない ◦ STRUCTURE.mdを作成して読ませる • 自動テストを作ってはくれるが後で作成して実行結果を見て調整してくる ◦ 自動テストを作成してから対応するように指示(Red-Green-Refactor) • プロジェクトの新規加入者に毎回説明するような独自ルールがある(暗黙知) ◦ 新人に説明が必須ならAIにも説明が必要 ◦ 明文化する ◦ 他、関連するデータは渡す（API仕様書や外部のスクリプト等）
19. AIツールを快適に使うための小技 （家だと）マイク入力を使っています 右⌘キーの右にF13（使わないキー）を設定して、 それをMacの設定で音声入力のショートカットにしています
20. 本日のまとめ VibeCodingは、プロトタイピングや単発のツール開発において革命的な力を発揮する。 一方で、長期的な運用や継続的な改善が求められるプロダクトには、まだ課題があり、 VibeCodingで長期的な開発を行えるまでは短くみてもまだ2,3年はかかりそう。 長期運用するには計画を立てる、ルールを作るなどうまくマネジメントしていくことが必 要。