こんにちは、よしこです。
最近、個人的に欲しいツールをVibe Codingで作ることが増えてきたので、私の中で定着してきた進め方をまとめてみようかなと思いました。
ちなみに “Vibe Coding”（雰囲気コーディング）というのは、「人間が音声やテキストで指示を出し、AIが主体となってコードを書くコーディングスタイル」を指すワードです。
私もこのやりかたをするときはほとんどコード書いてません。
ツール: ChatGPT 4o
成果物: 要件定義.md
まずは「何を作るのか」「ターゲットは誰か」「どんな機能が必要か」「画面構成はどうするか」などを決めます。好きなAIとチャットベースで喋りながらまとめていきます。
こっちが全然考えきってなくても、「◯◯なアプリ作りたいんだけど要件定義手伝ってー」から会話を始めれば必要な情報は向こうがヒアリングしてくれます。
ここはChatGPT 4oを使うことが多いです。トーンやノリが個人的な好みと合って楽しいし、推論モデルだとテンポが悪くなりがちなので。
仕様の壁打ち・まとめなら推論なくても全然できる程度の難易度です。
でもここは何でもいいと思います。話が弾むことが大事なので、好きなモデル・チャットで。
ポイントとして、プロダクトの名前もこの時点で決めておきましょう。名前はソースコードのあちこちに登場するので、後から変えると手間が増えるため。名前の案出しなんてAIの超得意分野なので楽しくやれます。
だらだら会話してても最後に「今まで話したこと要件定義.mdにまとめて」っていえばまとめてくれるので楽すぎる。私もう前半話したことの記憶消えてるのに。
ツール: ChatGPT 4o
成果物: 技術選定.md ディレクトリ構成.md DBテーブル設計.md API仕様.md など
次に利用技術、ディレクトリ構成、DB設計、API仕様などを決めていきます。
前段の壁打ちでこのあたりまでやっておく理由は、要件定義だけをAIに読ませてコーディングに入ると、思ってたのと違う技術で突っ走ってしまうことが多いからです。「DenoでやりたかったのにNodeで書かれた」「モバイルアプリのつもりがWebアプリがでてきた」などなど。
tokenがもったいないので、使う技術やディレクトリ構造は事前に決めておきます。
逆にこのへんのドキュメントさえあれば、それ通りに勝手に突っ走ってくれます。
この記事では要件定義と技術選定でセクションをわけていますが、実際はパキッとステップをわけず、同じチャットでごちゃ混ぜで話していることも多いです。
最後に「要件定義.mdと技術選定.mdを出して」と言えばちゃんとわけてくれるので便利。
気が向いたらDB設計やAPI設計も「これまで話した仕様だとどういうAPI・データ構造になると思う？」みたいに適当に聞くとばーっと叩き台を出してくれるので、ちょこちょこフィードバックしてmarkdown化。楽…
ちなみに自分の構成は、
になることが多いです。
このあと最後に全markdownを一気にChatGPT o3にレビューしてもらってもいいかもしれないですね。
軽く試してみたら、非機能要件やコスト面など見逃しがちなところを整理して指摘してくれました。
ツール: Claude Code
成果物: 環境構築、各アプリケーションの動くコード
いよいよコーディングに入ります。
最初にmonorepo全体を構築するときにはCLIベースの Claude Code を使っています。
このステップでは雛形ファイルを大量に生成したり依存インストールをしたりするので、エディタ型エージェントだと都度index生成や型解決なんかが走って重いんですよね。
あと環境構築はコマンドを多用するのでそこもCLIベースのほうがしっくりきます。
（類似ツールとして直近OpenAIからも Codex が出ました）
作業手順としては、まず自分でディレクトリを作ってgit initして、前段で作ったmarkdownドキュメントをdocs/に配置してコミット。
そこから claude を起動して、まずdocsの中身を全部読ませます。
docsを読ませると、だいたいそのまま勝手にその内容で構築し始めちゃうので、読ませる指示のときあわせて「不明点があったら質問して」と言っておくといいです。だいたいなんか抜けてたことを聞かれます。
作業はとにかくClaude Codeがどんどん進めてくれるので、人間は実行コマンドを見て「Yes」と答えるマシーンと化します。
個人的にはCLIベースでアウトプットがばーっと出ていくのがすごく近未来感あって、Claude Codeでこの工程をやってるときが一番テンションあがります。
順序として
みたいな感じで段階を踏んで進めるとやりやすいです。
事前にAPI定義書があればAPIもクライアントもそれ前提でやってくれるので疎通も楽。
それぞれの単位でlocal起動して動作確認して、たいてい何かしらエラーが出るのでClaude Codeにコピペして修正させるのを2ラリーくらいやればわりとそれぞれ立ち上がります。
（local起動コマンドをClaude Code経由で実行しちゃうとずっと立ち上がり続けてClaudeが帰ってこれなくなっちゃうので、別プロセスで自分で打ちましょう）
文章だけでViewの見た目も結構いい感じにやってくれますが、直したいところがあればそこも言葉でちょこちょこ直してもらいます。
ツール: Cursor
成果物: 最終的なアプリケーション
最後の微調整はおなじみCursorなどエディタ型のエージェントで進めます。
モデルはGemini 2.5 ProかClaude 3.7 Sonnetあたりを使うことが多いです。
長くなりすぎてるファイルをモジュール分割させたり、ちょっとした文言変更だったりはやっぱり自分でファイルを見ながら進めたほうが楽なので、エディタ型が合います。
ちなみに、AIのアウトプットに自分が手動で手を加えると、コンテキスト上で認識されていなくて次の生成で元に戻されちゃうことがよくあります。なので手を加えたときは「調整したので認識してください」って言っておくと戻されなくなります。へたに手を出すほうが手がかかる感…
以上、最近こんな感じでやってるなーというのをまとめてみました。
作ったものとしては、たとえば音声でAIと話せて、不自然だったらフィードバックをくれる言語学習アプリ。
デザインもかなりClaudeがいい感じにやってくれました。
今は各AIと自然な会話をしつつMCP Toolsも呼びまくれるようなLINEっぽいチャットベースの遊び場アプリを作っています。
私はWebばかりやっていてモバイルアプリの開発経験はほぼなかったのですが、今や日常的にモバイルアプリを作れるようになって実現できることが広がりました。（本当はFlutterのキャッチアップも兼ねて選んだのですが、Vibe Codingだとほんとにコード書かないのでキャッチアップにならなかった… 起動コマンドは覚えた。）
自分用でもデプロイするなら認証やAPI Keyの管理などはしっかりしないと怖いので、そういう指示を出すためにエンジニアの目や勘所は役立っていますが、それでも自分でコードを書かずにみるみるアプリができていく体験はやっぱりすごい。
人によってお気に入りの手順は違うかと思いますが、その中の一例としてどんな感じかのイメージを掴む助けになればうれしいです！
Be the first to comment
