今さらゼロから vibe coding を試して考えた

業務ではコードレビューを前提にコーディングエージェントを利用しています。
今回はプライベートで、コードを読まない完全な vibe coding をゼロから試しました。
その結果と、業務に持ち込むための条件について考えたことをまとめます。

これまではやらなかった

業務では、LLM を使ったコーディングエージェントを日常的に利用しています。ただし、開発ルールとして「コードレビューを経ずにリリースしてはいけない」と定められているため、誰が書いたコードであってもレビューを行っています。

そのため、いわゆる vibe coding ではなく、出力されたコードを責任を持って調整した上でレビュー依頼を出すようにしています。自分で説明できないコードを他人に渡すのは不誠実だと思っているためです。

一方で、最近は「コードはもう人間が書かなくてもいいのでは」という空気もあります。テストコードまで含めてエージェントに任せる、という例も見かけます。恥ずかしながらこれまで完全な vibe coding は試したことがなく、既存プロダクトの開発に部分的に適用し、細かくチェックする形でしかエージェントを使ったことがありませんでした。

そこで今回、プライベートでゼロからエージェントでアプリ作成を試してみました。
題材は、娘向けの簡単なクロスワードパズルです。少しずつ文章が読めるようになってきたので、遊びながら言葉に触れられるものを作ろうと思ったのと、どうせ試すなら実用性のあるものがよかったので。

条件は「基本的にコードは読まない」。プロンプトを入力し、出力されたコードを動かし、確認してフィードバックのプロンプトを作成。中身には踏み込まない、完全な vibe coding を 0 からやってみました。

なお成果物は github に置いてあります。
https://github.com/kyuwabara/cross-word

思ったよりちゃんと動いた

最初のプロンプトは次の通りです。

クロスワードパズルを作るアプリケーションを作成します。
要件は以下です。

- ひらがなのみを用いたクロスワードパズルであること
- ノート PC でサーバーを起動し、家庭内 LAN でタブレットからアクセスできるようにすること
  - WWW に公開する予定はない
- 技術スタックの選定は自由だがあまり過剰な実装を行わないこと
  - 作成した問題を保存したり乱数を指定したりする機能は不要
- クロスワードパズルとして成立するためのルールを満たすこと
  - クロスワードパズルのルールは調べてください
- 5歳児の学習用として使用するため、語彙の範囲をそのレベルにすること
  - 簡単な外来語（例：レモン、オレンジなど）は使用可とする
  - その場合もひらがなで表記すること
- 縦横のマス目の数を指定できるようにすること

これらを踏まえてアプリケーションを作成してください。
仕様や技術スタックなど、決定事項については必要に応じて CLAUDE.md に記載すること。

技術スタック含め丸投げ。CLAUDE.md すらお任せで、だいぶ適当です。

成果物はこのようになりました。

ほんのりレトロな見た目。Flaskが採用されるとは思ってなくてちょっとびっくりした。

出力された Flask アプリケーションをローカルで起動。
見た目はそれらしく、実際に入力もできる。想像していたよりもちゃんと「クロスワード」になっていました。

いくつか気になる点はあったものの、この段階ではコードは読んでいません。
軽く触って動作を確認し、そのまま娘に渡して感想を聞きました。気になった点をそのままフィードバックとして投げ返します。

ユーザー（5歳児）からリクエストです。
- キーボードのレイアウトを変えてください
  - 右から順に縦に「あいうえお」「かきくけこ」･･･と並べてください
- ヒントが少し広すぎます
  - 例：あきにたべるくだもの -> かき
    - なし、くり、ぶどう、いちじくなど他にも候補があって絞りきれません
- こたえあわせ機能で、間違っているところの正解がなんなのかわかるようにしてください

ユーザー（5歳児の父）からリクエストです。
- キーボードなどをなくした「印刷モード」をつけてください
  - 紙に印刷して字を書く練習もできるようにしたいです

その後何度かやり取りしてこうなりました。

キーボードが娘の見慣れたものになり、いんさつボタンが付いた。

ここまでやってみた感じ「思ったよりいけるのでは？」という感触でした。
コードの中身を知らなくても、プロンプトとフィードバックだけでそこそこ形にはなる。少なくとも今回のような小規模なアプリなら、十分成立しているように見えます。

動いていたがバグはあった

数回のフィードバックを経て、アプリはひととおり形になりました。
娘も普通に遊べていますし、ぱっと見では大きな問題はありません。

正直なところ、この時点では「これで十分では？」と思っていました。
コードを読まなくても、外から触って挙動を確認し、気になる点を伝えれば改善される。少なくとも小規模なアプリであれば、このやり方でも成立しているように見えました。

挙動の不自然さに気付いたのは娘でした。
「ここ、何回やっても "きゅうきゅうしゃ" が入るよ？」
そう言われて見てみると、確かに「あたらしいパズル」ボタンを連打しても変わらない箇所(上の画像の 7 の部分)があります。他の部分は変わるので、ランダム性が全くないわけではなさそう。エージェントに直させようとも考えたのですが、自分の中ではこれでプロジェクトは一段落しているという認識があったので、直接コードを開いてざっと流し読みしました。

その結果、候補の単語群から最初の語を選ぶロジックにバグを発見しました。

https://github.com/kyuwabara/cross-word/blob/d222a96ead06d952df40d5497b21993c373b5551/crossword.py#L58-L60
60行目で全てが台無しだよ

今回は分かりやすかったですが、表面的な挙動だけを見ているだけで気づくのは難しいようなバグもあると思います。
外から触っている限りは「だいたい正しい」ように見えるからです。

娘向けの遊び道具であれば、「あれーおかしいね」で済みます。 しかしこれが業務のプロジェクトだったらそうもいきません。なぜこの実装なのか説明できる人がいない、という状態になります。

vibe coding で「動くもの」は作ることができましたが、それを自分の名前で出せるかというのはまた別の問題だと感じました。

自分の名前で出せるか

今回のバグは原因も単純で、すぐに修正できるものでした。プライベートなアプリなので、あれーおかしいねで済む話でもあります。

しかしこれを業務でやるのは（自分の頭が固いだけかもしれませんが）非常に抵抗があります。
まずこの実装をレビューに出せるか。自分が理解していないロジックを「たぶん大丈夫」とチームメンバーに渡すのは、個人的には無理です。バグがあった場合、その発見を他人に委ねることになります。
レビューが通ったとしても、本番環境で不具合が発生した場合、調査や修正にはチームのリソースを消費します。コードの振る舞いを理解していない状態で障害対応を行うのは効率も精神衛生上もよくありません。

今回の件で考えたのは、vibe coding の是非というよりは責任の持ち方の問題でした。
外から触ってだいたい動いていることと、内部ロジックを把握し説明できることは別物です。業務では後者が求められます。

業務に持ち込むための条件

今回のケースではコードを読んで原因を特定できましたが、毎回それでいいとも限りません。人間が読んで理解することと、仕様が保証されることは別であり、属人的な理解に頼らない仕組みが必要です。その役割を担うのがテストだと改めて感じました。
テストがあれば、期待する振る舞いが明文化されます。コードを書いたのが誰なのかに関わらず、それが満たされているかを確認できます。
vibe coding が業務で成立するかは、どこまでテストで仕様を固定できるかに大きく依存するのではないか、そんなことを考えました。

今のところの結論

ゼロから vibe coding を試してみて、思ったよりも「動くもの」が簡単に作れると感じました。プロンプト次第でまだ伸びしろはありそうです。
実際、コードを読まずに進められる開発は、正直かなり楽でした。フィードバックを重ねるだけで形になっていく感覚には、なるほど世間の人たちが感じていたのはこういうことかと納得しました。もっと早くやってみればよかった。
一方、動いていても責任は持てない場合がある、と感じました。コードを読めばバグは見つかりましたが、それは偶然目に付いただけです。自分が理解していない実装を、自分の名前で業務としてリリースできるかと言われると、今の自分には無理です。

今後も個人用途では vibe coding する機会があるでしょう。ただし、業務で全面的に任せるのであれば前提が変わります。人間が全てを把握していなくても壊れていないことを確認できる状態を作る必要があり、そのためのテストや運用が整っていない限り、安心して委ねることはできないでしょう。自分たちの環境はまだそこまで整備できていません。当面は誰が書いたかに関わらずコードレビューを行う運用を続けることになりそうです。もちろんレビュー前に自分でチェックすること前提で。

コードを書く主体が変わっても、何を作るか・何を保証するかを定義し、その品質を確認する役割はまだ人間が担う必要がありそうです。

それすら不要になる日が来たら、そのときは本当に役割が変わったと言えそうです。