40代マネージャーのVibe Coding開発記3
外部イベントで少しだけ登壇しました
みなさんこんにちは。たきあすです。
先日、外部イベントで登壇しました。会社内での登壇や発表は何度かあるのですが、外部は初めてだったので結構練習していきました。結婚式のスピーチの次ぐらいに練習した気がします。ただ慣れてくると調子に乗って長くしゃべりたくなってしまうので、気をつけないといけないなと思いました。
さて今回は、Vibe Coding開発記の第3弾です。開発当時の記憶がどんどん薄くなっていくので、今回で最後にできるよう頑張ります。
今回の記事で言いたいこと
- AIは暴走するので準備して対処しましょう
- 個人開発頑張っていきましょう！
開発記
レビュー自動化したい！
メイン開発エージェントがCursorになってから開発していたのは、AI駆動型のレビュー管理ツールでした。マネージャーという立場上、チームメンバーの設計成果物についてレビューをする機会が多かったのですが、文章表現などの体裁面での指摘が多いことに悩みを感じていたことが発端でした。
もちろん、テンプレート化や作成後のチェックリストも活用していたりしていたのですが、形骸化しやすくあまり効果を感じることはできませんでした。「まぁ、それもどうしようもないかな」と心にしまっていたところに、今回のAIエージェントの進化です！もうこれはやるしかないなと。
開発の進め方
開発自体は実際のプロジェクトのような形で進めた方がよさそう、というのがXや技術ブログ界隈で散見されていたので、要件定義 ⇒ 設計 ⇒ 実装 ⇒ テスト ⇒ リリースの流れで進めていきました。個人開発なのでウォーターフォール型ではなく、プロトタイピング開発に近いですね。
要件定義
最初の要件定義で決まっていたのは以下ぐらいだった記憶しています。
- プラットフォームはAWS
- サーバーレスアーキテクチャ
- ブラウザからアクセスできる
あとはやりたいこと、実現したいことをCursorに伝えて、システム構想書として整理してもらいました。プロタイプとはいえ、最初にきちんとAIと会話して要件整理するのが良いかと思いました。ちなみに今思うと、以下の項目は要件定義の段階である程度決めておけば良かったなと思います。
- システム名称
- テーマカラー
ちなみにシステム名称は仮決めしたら特許庁の検索サイトーJ-PlatPatで商標登録されていないか確認した方が良いです。私の場合、システム名称を資材名やWeb画面のヘッダなどに多用していたのですが、使っていた名前が商標登録されていたことに完成間近で発覚し、資材を修正する羽目になりました。
無料公開する場合でもトラブル防止のためにも、商標登録されているものは使わない方が吉だと思います。テーマカラーについても商標はあるものの、そこまでシビアに気にしなくても良いかなと思うので、あとで気に入らなくて直すぐらいなら決めておく方が良いと思います。
設計
設計はあくまで基本設計レベルに留めました。AIエージェントは設計ドキュメントの作成を依頼すると、コードサンプルやらフロー図までガシガシ作成していきます。ドキュメントがあるのは悪いことではないですが、最初から作成していくと更新していくのが大変になるし、AIのコンテキストも増えてコスト増に繋がるので、実装フェーズで修正が多発するような詳細設計レベルのドキュメントは作らなくてよいかなと思ってそうしていました。
ただ命名規約は絶対に決めた方が良いです。命名規約はリソース名、関数名、テーブル名、カラム名などに使うキャメルケースやスネークケースなどのルールです。この辺りをルール化していないと、AIは自由にコーディングしていきます。フロントエンドはキャメルケースなのにバックエンドはスネークケースになっているなどのことが発生し、実装フェーズでトラブルが起きた時のデバッグに苦労します。
■命名規則のルールについて（補足説明）
スネークケース（snake_case）: 単語間をアンダースコア（_）で区切る命名規則。例：user_name、first_name、created_at。主にPython、Ruby、データベースのカラム名などで使用される。
キャメルケース（camelCase）: 最初の単語は小文字で始め、2番目以降の単語は大文字で始める命名規則。例：userName、firstName、createdAt。主にJavaScript、Java、C#の変数名や関数名で使用される。
パスカルケース（PascalCase）: すべての単語が大文字で始まる命名規則。例：UserName、FirstName、CreatedAt。主にクラス名やコンストラクタ名で使用される。
私の場合、命名規約を作っていなかったので、ちぐはぐ状態になっており、そのちぐはぐによって正常に動作しないケースもありました。またAIに修正を依頼すると、期待している名前がスネークケースの場合とキャメルケースの場合、どちらも受け取れるような冗長な造りにしてしまったりするので、綺麗にするのにかなり時間を使いました。なので絶対に命名規約だけは作成した方が良いです。
実装
いよいよ実装フェーズ。やはりVibe Codingは実装が一番楽しいですよね。最初の内は結構さくさく作ってくれます。が、しかし！しかし！AIは暴走します。ただ質問しているだけなのに、依頼と解釈してどんどんコードを改変していきます。
私：「なぜ動かないのでしょうか? 」
↓
AI：「動かない理由はここが原因です。動くように対処しますね」
↓
AI：「あれ、linterエラーが出ています」
↓
AI：「よく分からないけど直していきます」
↓
AI：「出来ました！」
↓
スパゲッティコードの入口にようこそ
恐怖しかありません。これに対応する対策は今のところ、以下の3つしかないと思っています。
- 「...... なお、コードの修正はまだしなくて良いです。」
- コードをGitで管理してこまめにコミットする
- 性能の良いLLMモデルを選定する
ちょっと深堀りしていきます。
「なお、コードの修正はまだしなくて良いです」を付与する
これは必ずつけた方が良いです。なお、「指示をするまでコード修正はダメだよ」という旨をシステムルールに入れても聞いてくれません。ルールはrobots.txtみたいなレベルなのだと思います。なので面倒ですがプロンプトに直接入れましょう。
コードをGitで管理してこまめにコミットする
これは本当にそうですね。恥ずかしながら開発当初はgitで管理しておらず、その日の作業終わりにプロジェクトフォルダを丸ごとコピーしてバックアップしていました。この場合、日次レベルでしか復元できないので、AIの凶悪な暴走に打ち勝つことはできません。git触ったことなくて、知識がなかったとしてもAIに助けてもらってgitで管理しましょう。
性能の良いLLMモデルを選定する
コストが許すなら最新モデルを使った方が絶対良いです。sonnet4とsonnet3.5だと体感で5～10倍ぐらい暴走率が違います。sonnet3.5だとかなり気を使って指示、依頼をしないと暴走率が跳ね上がるような気がします。
テスト
テストは、本当に恥ずかしながら手動でポチポチやっていました。最近ようやくcypressなど使って自動化に励んでいますが、当時は本当に手動で全部やってました。本当に語れることがないのが実情です....
リリース
テストが終わったらリリースですが、リリース前に意識したことは難読化でしょうか。マネタイズもできたら良いなーと思って始めたので、ソースをそのまま公開するのはやめて難読化してからリリースすることにしました。フロントエンドはviteのプラグインを使って、バックエンドはpythonで開発していたのでpyarmorを使うことにしました。
難読化すると動作がおかしくなるという情報もあったのですが、そこまで大きなトラブルもなくテストも終わったので無事にリリースすることができました。
最後に
開発初めからリリースまでだいたい3か月ぐらいかかった気がします。平日は出社前に2hぐらい。休日は多いときで12hぐらいは使っていた気がします。トータルすると300hは超えていた気がします。
数字で見るとかなり大きいですが、自分の思いやイメージが形になっていくのが面白くもあり、AI暴走の地獄を乗り越えたのはいい思い出です。また今回の開発経験では、かなり技術的なスキルが上がったと感じています。マネージャーになってから自分で手を動かすことが少なかったので余計にそう感じるのかもしれません。
リリースするまでを視野に入れると、個人開発者でもプロダクトマネージャーみたいな視点が育っていくので、是非、個人開発者が増えて欲しいなとも思いました。かなり駄文でしたが、このブログが誰かの何かに役に立ったり刺激を与えられたら嬉しいです。
みんなで一緒に個人開発ライフ楽しんでいきましょうー！
個人開発したドキュメントレビューシステムのデモ版は以下で公開しています。
AWSがあればそんなに時間がかからずデプロイできるので、ぜひ使ってみてご意見頂けると嬉しいです。
ReviewMasterのGitHubリポジトリ ※構築手順はSETUP.mdを見てください。
Discussion