「バイブ・コーディング」と自律型AIエージェントの進化が、正直少し怖いレベルに達している件

最近話題の「バイブ・コーディング（Vibe Coding）」と、自律的にコードを書くエージェント型エンジニアリング。両者の境界線がどんどん曖昧になってきていて、一エンジニアとして少し複雑な心境です。効率化は歓迎だけど、ここまで来るとどこか取り残されるような不安も……皆さんはどう感じていますか？

数週間分くらいの進捗を見逃しているのかもしれないけど、AIが以前より信頼できるようになったとは到底思えない。エラーがより巧妙になっただけじゃないかな。

コードがコンパイルエラーになるなら、それはすぐ気づける。コンパイルできても動かない場合も、まだ見つけやすい。

もしコンパイルも通って動作もするのに、特定の境界条件で変な動きをしたり、セキュリティ脆弱性があったり、あるいは技術的負債や怪しげなアーキテクチャ判断が紛れ込んでいたりすると、それを見つけるのは難しい。レビューの負担が軽くなるどころか、むしろ増している気がするよ。

結局のところ「正しそうに見える」コードをレビューするほうが、明らかにダメなコードをチェックするより精神的にずっと疲れるんだよね。

「バイブコーディング（Vibe Coding）」やLLMが、規律のないエンジニアリング組織やエンジニアを生んだわけじゃない。彼らはただ、元々あったそうした現状を露呈させ、加速させただけだよ。

これまでも、コードの書き方に適当な（あるいは何のルールもない！）エンジニアなんていくらでもいた。同じように、本番環境へのデプロイ基準がガバガバなエンジニアチームだって山ほどある。この概念自体は新しいものじゃない。ただ、これまでSDLC（ソフトウェア開発ライフサイクル）に沿った開発なんてしてこなかった個人やチームが、より多くのコードを吐き出し、アイデアを形にするのが劇的に簡単になっただけのことさ。

もし1日に200行しか書けなかったのが2,000行書けるようになったら、他に何が壊れるだろうか？結局のところ、ソフトウェア開発ライフサイクル全体が「数百行書くのに丸一日かかる」という前提で設計されていたわけだ。それが今や、その前提が崩れている。

エンジニアリングの成果指標としてLOC（コード行数）がいまだに使われているなんて、恥ずかしい話だよ。

コーディングエージェントって、最初のワンショットで解決策の核心に迫るのに、最後の5％や10％を完成させるためにものすごい手間がかかるってことに気づいた？

コーディングの問題へのアプローチ方法を変えれば、エージェントはそのギャップを埋められるはずだ。10年前は、バグが後続のコードを壊さないよう、10〜15分おきに手を止めてリファクタリング、テスト、分析を繰り返して完璧を確認していた。今のコーディングエージェントにはそれができないし、やろうとしない。バグや歪んだ設計を抱えたまま突き進んでしまうんだ。

直感的には、エージェントをそうした節目で止めようとしてしまいがちだけど、それは理由があって不可能だ。むしろ、やり直しコストは極めて低いんだから、エージェントがミスをした最初の地点を見つけてプロンプトを修正すべきだよ。修正しようとせずに、いっそ全コードを削除して（安いものだからね）、最初から実行し直す。これをプロンプトが完璧なコードを吐き出すまで繰り返すんだ。

「おいおい、それだと人間がやることが多すぎるだろ！」って思うかもしれないけど、それこそが重要な点だよ。人間は依然として必要なんだ。こういうツール運用をすれば、コードを書く速度は10倍になるよ。

自分にとっての違いは、パイプラインの品質と厳格さにあると思う。

バイブコーディング：ワンショットやフューショットで出力し、スモークテストをして、壊れるまで（あるいは壊れないことを祈って）使う。軽量なPoCや、リスクの低い個人・家族・小規模チーム向けアプリには最適だ。

エージェントエンジニアリング：

• 機能的正確性、パフォーマンス、インフラ、回復力/可用性、スケーラビリティ、保守性など、より広範な懸念事項を重視する。
• 作業フローを管理するための多段階パイプラインを持っている。
• ステージは、プロジェクトの受け入れ、選定、仕様策定、エピック分割、ストーリー分割、コーディング、ドキュメント化、デプロイなどがある。
• 各ステージで、決定論的な品質ゲート（テスト通過、ベンチマーク達成など）と、敵対的レビュー（プロジェクトのビジネス価値、仕様の網羅性、コードの優雅さ、ユビキタス言語の簡潔さなど）を組み合わせる。

これはスライダーのようなものだよ。正直、3ラウンドもの敵対的レビューや価値見積もり、詳細仕様書作成なんてやっていられないときは、自分のシステムにチケットを投げ込んで済ませることもある。機能を出荷するためだけにね。

賢明で謙虚、そして常に学び続けている人による素晴らしい記事だね！

お気に入りの引用：「コンピュータが自分でコードを書けるようになった今、ソフトウェアエンジニアとしてのキャリアが終わるなんてこれっぽっちも思っていない。理由はいくつかあるが、第一に、これらは既存の経験を増幅させるツールだからだ。自分が何をすべきか理解していれば、これらを使って圧倒的に速く走れる。[...]」

「これらのツールを使うたびに、自分たちがしていることの難しさを思い知らされる。ソフトウェアを作り上げるのは、とてつもなく難しい仕事だ。世界中のAIツールをすべて手に入れたとしても、私たちが達成しようとしていることは、依然として非常に難しいものなんだ[...]」

いずれ「全てのコーディング」がバイブコーディングになると思う。でも、それはエンジニアリングという規律の価値を少しも下げないはずだ。

注：私は今でも、誰が生成したかにかかわらず、自分の管理下のコードはほぼすべて目を通しているし、エージェントが抱える問題もはっきり見えている……でも、トレンドも理解しているつもりだ。

私の考えでは、エンジニアリングは「コードを丹念に作る」ことから「エージェントの成果物を検証する、特注の包括的なメカニズムを作る」ことへシフトしていくはずだ。可能な限り技術的に（あるいは数学的に）証明可能にし、証明できない部分は人間がサッとレビューする。この検証メカニズムは視覚的なものになるだろうね。人間にとって最も情報帯域が高い入力は視覚だからさ。

「包括的な検証」というのは単なるテストじゃない。重なり合い、連動する複数のテストと指標のことだ。例えば、UIのE2Eテストだけでなく、バックエンドのDBで期待される変更をチェックするテストを重ねる。時には膨大なテストケースを生成して、個別の行を見るのではなく、テスト前後でのデータの「分布」を見るようにしている。ユニットテストは少ないけど、パフォーマンステストは充実させているよ。検証結果を色分けして、何かが壊れたら即座に原因を特定できるようにしているんだ。

これらはすべて手動でやるにはやりすぎだけど、エージェントとなら朝飯前だ。時間が経つにつれ、ものを壊さずに爆速で開発できるようになる。最近はコード修正のために新たな検証を追加することもほとんどなくなった。一度初期コストを払えば、あとは長く配当を受け取れるというわけだ。

もちろん、LLMの癖を考慮しつつ、最も自信を持てるテクニカルな制約を深く考える必要はあった。これは各プロジェクトに固有の作業だから、「複数の連動するテスト」といった高レベルの原則以外、一般化は難しい。各プロジェクトには、そのアーキテクチャや技術詳細に特化したカスタム検証スイートが必要になるんだ。

というわけで、これは今もエンジニアリングそのものだ。ただ、「コードはほとんど見ず、結果だけを見る」という意味でのバイブコーディングになっていくんだろうね。

下流工程だけでなく、上流工程もそうだよね。AnthropicのデザインリーダーであるJenny Wenの講演が素晴らしかったんだけど、今のデザインプロセスは「デザインを正しく決めること」を前提にしていると言っていた。もしエンジニアに仕様を渡して、3ヶ月かけて間違ったものを作らせたら悲劇的だからね。

その通りだ。特にデザイン側のツールが進化しすぎていて、もはやFigmaにとどまるための「翻訳コスト」を払う価値はなくなっていると思う。

AI至上主義者たちへ一言。

仮に、AIの正確性が人間より10倍完璧で、バグが10分の1で、有能なエンジニアより1000倍速いとしよう。

ここで想像してみてほしい。
道に10倍の凸凹がある車が、通常の1000分の1の速度で走っているとする。凸凹は10倍だけど、進む速度が圧倒的に遅いから、体感する揺れはむしろマシになるよね。

じゃあ逆に、凸凹は10分の1に減ったけど、1000倍の速度で走る車はどうだろう？体感する衝撃は、前よりずっとひどくなるはずだ。

エージェントコーディングっていうのはそういうことだ。乗り心地は今までよりずっと過酷になる。それを否定する声も多いけど、時が経てば否定できなくなるはずだ。

最後に言わせてもらうと、バイブコーディングは正直な言葉だけど、エージェントコーディングは「インチキ商法」だ。何十ものメモリやエージェントファイル、ルールを書き込んだファイルを大量に管理するハーネスを作るなんて議論は、完全に的外れだよ。そんなパラダイムは、LLMが完璧で信頼できる超正確なルール遵守マシンであり、業界の唯一の問題はルールを十分に明確に指定できていないことだと仮定しているようなものだ。

そんな信念は、LLMを十分に使い込んでいないか、LLMの仕組みを理解するほど技術的でない人しか持てない。高度に技術的なコミュニティがそんな誤った信念にしがみついているのは、非常に嘆かわしいことだよ。

Claude CodeにJSONクエリを実行して結果を出力するAPIエンドポイントを作らせたら、確実に正しく動くよ。失敗なんてしない。自動テストやドキュメントを追加させれば、完璧なものができる。

正直、これは真実じゃないと思う。JSON APIエンドポイントを作るだけでも、いくつもの意思決定が必要だ。

• エンドポイントの名前をどうするか
• どんなオプションを提供するか
• プロパティをどう命名するか
• レスポンスをどう検証するか
• エラーをどう扱うか
• コードベースのどの部分を共通化して再利用するか
• 将来的にどう変更される可能性があるか
• クエリの実行方法は最適化されているか

…

もしこれらすべてへの回答を知っているなら、Claude Codeに丸投げするより自分で組み立てる方がずっと早い。

もし答えが分からないなら、答えを見つける最短の方法はコードを書き始めることだ。

それに、書きながら境界条件や最適化、ログ出力、可観測性など、やるべきことに気づくことも多いしね。

著者は明らかにこの記事の文脈を「本番コード」だと断っているけど、JSON APIエンドポイントを何千個も作る必要があるわけじゃないんだから、Claude Codeを使う利点なんて感じないよ。