こんにちは。麗です。

バイブコーディングの「バイブ（vive）」とは、雰囲気・ノリ・フィーリングといった意味をもつ言葉です。その言葉どおりに「これ作って～！」とAIに伝えるだけで、それっぽいものを作ってくれます。

そこで私は大きな間違い犯してしまいました。

今日は私がやらかした失敗と反省について、お話していこうかと思います。

アイデアを即実装していた過去

バイブコーディングを初めてすぐ、「これを作って～！」と伝えるだけで、それらしいものが出来るのが楽しくて、アイデアが浮かぶたびにすぐ実装を依頼していました。

「これをやりたい」 「あれもやりたい」 「こっちもよろしく」

そんな具合に思いつくままに伝え続けていたのです。

そればかりか、せっかく時間をかけて実装してくれたのに「やっぱり今のなし！こっちにして」とAIの努力を水の泡にしてしまうこともありました。

深く考えずに依頼し、そしてまた別の思いつきを依頼する。

これはわたしのADHDの特性が結構出ていたかと思います。

そんな風に作っていたプログラムは、いつのまにか中規模クラスのものになっていました。このプログラムが、Office-Chronosです。

初めのうちは、それでも問題なくプログラムが動いていたのです。

だから、「これでいいんだ」とも思いながら開発を進めていたのですが、ある時からバグが多発するようになりました。

一つ実装すると一つ壊れる。

一つ直すと、また別のところが壊れる。

そんなバグだらけの状態が続くようになってしまったのです。そして、プロジェクトが機能しなくなっていました。

そこで、ようやく気付きました。

自分の指示の仕方が悪かった、と。（遅い）

答えられない質問

「自分が悪かった」と気づいた私は、自分のしてきたことを反省しました。

中でも思い出したのは、AIからもらった質問の数々。

AIの指示を出すと「言語はどれにしますか？」「どのように表示しますか？」などの質問をされることがあります。

その質問を受けて、内心「わからない・・・」と思うことがたびたびあったのです。

焦って適当な答えを返してしまうこともれば、何にも考えず選択肢から選んでしまったこともありました。

答えられなかった理由は、そういう質問があることを想定していなかったからです。

「伝え忘れていた」ではなく、何一つ考えていなかったからです。

自分が何のために、何をやりたいのか。

やりたいことを実現するために、どの順番で何をしていくのか。

AIにコーディング部分をすべて任せるからこそ、それが自分でわかっていないと、ダメだと思いました。

アイデアが浮かんだらまず idea.md に入れておく

このように反省した私は、アイデアが浮かんだらまず idea.md に入れておくようになりました。

「今すぐにでも形にしたい」という想いをグッとこらえて、idea.md に書き込む。

即思いついたアイデアほど即実行したくなりますが、意外とどこかに吐き出せればそれで気が済んだりもします（笑）つまりidea.mdに書き込むだけで満足してしまうこともありました。

いったん寝かせたあと、熱が冷めなかったアイデアだけを実装していくようにしました。

ちなみに私は、 idea.md を活用していますが、アイデアを載せておく場所は正直どこでもOKです。

アナログ手帳だって良いし、普段自分が使っているツールだって良いと思いますが、内容を詰めるときにAIと一緒に見れるように私はプロジェクト内にidea.mdを置いておきました。

【追記】 この記事を書いてから数週間が経過しましたが、今はアナログのメモ帳とマインドマップも活用しています。

相談セッションを立ち上げる

アイデアを寝かせるようになってから少し経った頃、自分の中では「このアイデアは完ぺき」と思っていても、実装してみると穴だらけのアイデアであることに気が付きました。

そこで、いきなり実装に入らずに「相談」のためのセッションを立ち上げるようにしたのです。

そこで行うのは、自分のアイデアの不明確な点を浮き彫りにして、言語化してもらう、といった作業です。

また、自分だけでは細かい部分まで決めきれないことも多々あるので、AIと一緒に考えて決めていくようにしました。

この相談セッションで難しいのは、AIが要望を即実行したがる傾向にあることなのですが、「このセッションでは相談のみで実装はしないで」みたいに最初に伝えておくと、いきなり実装には入らずにアイデア提案などから行ってくれることが多いです。

アイデアを実装プランに落とし込む

そして、最もやって良かったことがこれです。

「企画要件書→仕様書→設計書→実装プラン」という流れで、少しずつ詳細を決めていくようにしたことです。

相談セッションを立ち上げるようになってから、設計の甘さを痛感するようになり、このやり方に至りました。

• 企画書：やりたいことを書くもの
• 要件書：必要なことを書くもの
• 仕様書：どう動くかを書くもの
• 設計書：どう作るかを書くもの
• 実装プラン：どう進めるかを書くもの

それぞれこのような意味があるものです。

状況によってこのステップは端折るものの、やりたいことの明確化・言語化を意識してから実装を依頼することをずっと徹底しています。

もしかすると、ここで「こんなに細かい流れを辿らなくてもAIがやってくれるよ」と思う人もいるかもしれません。

正直に言うと、本当にその通りで、「やりたいこと」をはっきり言語化できさえすれば一発で生成してもらえることもあります。

• 企画書：やりたいことを書くもの
• 要件書：必要なことを書くもの
• 仕様書：どう動くかを書くもの
• 設計書：どう作るかを書くもの
• 実装プラン：どう進めるかを書くもの

この流れを辿るのは、AIの為でもありますが、何よりも「初心者である自分自身のため」なんです。

非エンジニアの私にとって、プログラムがどのように作られているのか、まったく分かっていませんでした。

見えているのは「やりたいこと」と「成果物」のみであり、その流れはブラックボックス状態だったんです。

やりたいこと → 必要な条件 → 動き方 → 作り方 → 実装順

こういう流れを辿っていくことで、何がどのようにできているかという概念が頭に入りやすくなりました。

また、目に見えたバグがあったときに、なんとなく理由が分かることも増えてきました。

成果物が自分の意図したものと違ったときに、どこで間違えたのか分かるようになってきました。

そもそも、自分の意図したことが伝わりやすくなり、目立ったバグが出ることも減り、手戻りが少なくなっています。

せっかくAIエージェントを使ってるんだからもっと自動化したほうが……と思うこともありますが、とても勉強になりましたし、手戻りを考えると逆に早いなとも感じます。

この記事のまとめ

最後に、私が失敗から学んだことをまとめておきます。

• アイデアが浮かんでもすぐ実装しない。まず idea.md に入れておく
• 実装前に「相談」の時間を設けて、アイデアを明確化・言語化する
• 「やりたいこと→やる手順」の流れを先に持っておく
• 1セッション1テーマの粒度でステップを組んで実装

いま冷静に振り返ってみると、「そんなの当たり前だろう。アホか！」って言いたくなる部分も沢山ありますね（笑）

実際に取り組んでいるときは、どうしても視野が狭くなってしまうものだと、記事をまとめながら痛感します。