バイブコーディングは、勢いよく作り始められるのが魅力です。頭の中にある「こういうものが欲しい」を、そのままAIに投げて形にしていける軽さがあります。私も最初は、そのスピード感にかなり助けられました。
ただ、少し大きいものを作り始めると、勢いだけでは崩れやすくなります。画面が増える、条件が増える、修正を何度も重ねる。そうなると、最初に何を作ろうとしていたのか、どこまでを今回の対象にするのかが少しずつ曖昧になります。
私が痛感したのは、仕様メモがないと、AIだけでなく自分も「何を直しているのか」を見失いやすいということです。速く作るために始めたはずなのに、後半で前提確認に戻る時間が増える。そこで最近は、短くても仕様メモを先に置くようにしています。
- バイブコーディングは速い反面、仕様メモがないと途中から判断基準がぶれやすくなります。
- 重い設計書ではなく、目的、対象、入力、出力、触らない範囲、完了条件だけでも効果があります。
- 仕様メモはAIのためだけでなく、自分が提案を採るか捨てるかを判断するための戻る場所になります。
勢いで作れるほど、途中から何を直しているのかが混ざりやすい
作り始めの数十分は、勢いだけでもかなり形になります。AIに「こんな画面が欲しい」「こういう表を出したい」と伝えるだけで、動くものが出てくることもあります。ここはバイブコーディングの楽しいところです。
問題は、そのあとです。最初は一画面だけのつもりだったのに、条件を追加し、表示を変え、保存機能を足し、並び替えも欲しくなる。そうしているうちに、AIも自分も「今回の目的」がぼやけてきます。
そもそもの勢いの魅力は、こちらの記事で書きました。
その次の段階で必要になるのが、勢いを止めるためではなく、勢いがずれたときに戻る場所です。
特に投資情報を整理するようなツールでは、条件や表示項目がぶれると、あとから見たときに何を比較しているのか分からなくなります。利益を出すための魔法ではなく、候補を整理する道具だからこそ、前提を残す意味が大きいと感じました。
仕様メモは重い設計書ではなく、戻る場所を残すメモで十分
仕様メモという言葉を使うと、何十ページもある設計書を想像してしまうかもしれません。私も最初は、そんなにきっちり書くならバイブコーディングの軽さが消えてしまうと思っていました。
でも実際に必要だったのは、完璧な設計書ではなく、迷ったときに戻れる短いメモでした。対象画面、目的、入力、出力、触らない範囲、完了条件。これだけでも、AIへの指示と自分の確認がかなり安定します。
- この機能で何を実現したいか
- 今回見るデータや入力項目は何か
- 画面や出力として何が見えればよいか
- 今回触らない範囲はどこか
- 何ができたら完了とみなすか
仕様書をAIに書かせた記事もあるので、そこまでの延長で見るとつながります。
重い設計書を作る前の、小さな前提メモ。それくらいの位置づけにすると、作り始める軽さも残せました。
私の場合、最初からきれいに書こうとすると手が止まります。だから、最初のメモは箇条書きで十分にしています。あとで読み返したときに「何のために作っていたか」が分かれば、少し不完全でも作業の支えになります。
仕様メモがあると、AIの提案を採るか捨てるかが判断しやすい
AIの提案が複数出たとき、仕様メモがないと「なんとなく良さそう」で選びがちです。見た目がきれい、説明が自然、便利そう。そういう理由で採用すると、最初の目的から少しずつ離れることがあります。
仕様メモがあると、判断が変わります。今回の目的に必要か。入力と出力の関係が崩れていないか。触らないと決めた範囲に入り込んでいないか。完了条件に近づいているか。こうした基準で見られるので、提案を採る理由も捨てる理由も言葉にしやすくなります。
たとえば、AIが「グラフも追加できます」と提案してくれたとします。便利そうではあります。でも今回の仕様メモが「候補一覧を同じ条件で並べる」なら、グラフ追加は次回に回せます。逆に「変化を見比べたい」が目的なら、グラフは採用候補になります。
仕様メモはAIを縛るためだけではなく、自分が寄り道に流されないための基準にもなります。ここがあると、速さと落ち着きの両方を少し持ちやすくなりました。
メモがないまま修正を重ねると、会話の中に前提が散らばる
バイブコーディングでよく起きるのが、会話の途中で条件を足していく流れです。「やっぱりこの項目も」「ここは除外して」「表示名は変えて」。その場では自然ですが、長く続くと前提が会話のあちこちに散らばります。
前提が散らばると、AIが古い条件を拾ったり、自分が最新の条件を説明し直したりする時間が増えます。作業が進んでいるように見えて、実際には同じ前提確認を何度も繰り返していることがありました。
短い仕様メモがあると、条件を足したときにそこへ戻せます。会話で決まったことをメモ側へ反映する。次の依頼では、そのメモを見ながら頼む。これだけで、AIとのやり取りがかなり散らばりにくくなります。
私はここで、仕様メモを作業前だけのものではなく、作業中に更新するものとして見るようになりました。最初に全部を決めるのではなく、決まったことを一箇所へ戻していく感覚です。
この更新をサボると、次の依頼でまた同じ説明をすることになります。逆に、決まった条件を一行だけでもメモへ戻しておくと、次の修正ではそのメモを貼るだけで会話を再開できます。ここは小さいですが、長い作業ほど効きました。
バイブコーディングの軽さを残すなら、メモは一枚に収める
仕様メモを作るといっても、バイブコーディングの魅力まで消してしまうと続きません。作る前に全部を決めようとすると、今度は手が止まります。私に合っていたのは、一枚で見返せるくらいの短さにすることでした。
目安としては、AIにそのまま渡せるくらい短く、でも自分があとで見ても判断できるくらい具体的に書くことです。抽象的に「使いやすくする」だけだと弱いですが、「候補一覧で、銘柄名、理由、確認日を同じ行に表示する」まで書けば、判断しやすくなります。
メモを重くしないためには、完璧さを狙わないほうがよかったです。最初は仮で書く。作りながら直す。ズレたら戻る。これくらいなら、勢いを削らずに使えます。
私は、最初のメモを書く時間を5分から10分くらいに収めるようにしています。それ以上かけると設計そのものが目的になりやすいからです。短く始めて、作業中に育てるくらいが、バイブコーディングの軽さと両立しやすいと感じています。
速く作るためにメモを省くのではなく、速く戻るためにメモを置く。この考え方に変えると、仕様メモは面倒な作業ではなく、バイブコーディングを長持ちさせる道具に見えてきました。
次は実際の仕様メモの最小形と、崩れた例を残していく
今回わかったのは、仕様メモは大げさな設計書ではなく、AIと自分が同じ場所へ戻るための小さな地図だということでした。勢いで作る良さは残しながら、前提が散らばるのを防ぐ。そのくらいの距離感が、今の私には合っています。
次にやりたいのは、実際に使っている仕様メモの最小形を記事として残すことです。空欄を埋めればAIに渡せるテンプレートにしておけば、次に同じような小さなツールを作るときにも使えます。
あわせて、メモなしで進めて崩れた場面も記録したいです。どの条件が抜けたのか。どこで会話が散らばったのか。どのタイミングで戻ればよかったのか。失敗例まで残せると、仕様メモの意味がもっと具体的になります。
バイブコーディングは、雑に作ることではなく、勢いを使って小さく形にする方法だと思っています。その勢いを後半まで残すために、私はこれからも短い仕様メモを先に置くようにします。小さくても、戻る場所があるだけで作業はかなり安定します。
