「バイブコーディング」をどうやめればいいのか？

2025年末にClaude Codeが人気を博し、多くのソフトウェア開発者がコーディングエージェントを主要な開発ワークフローに組み込むようになりました。Andrej Karpathyは、2026年3月のNo Priorsポッドキャストで「vibe coding（バイブコーディング）」という言葉を使い、「12月以来、おそらく一行もコードを書いていない。これは非常に大きな変化だ。普通の人はこれが起こったことや、その劇的な影響を理解していないと思う」と述べました。私は彼を信じます。多くの人がこれを単なるマーケティングや誇大広告だと考えていますが、私も昨年から一行もコードを書いていない人間として、彼は正直だと思っています。それが良いか悪いかは、あなたの視点によりますが、ソフトウェアエンジニアリングの新しい時代に入ったことは間違いありません。エージェントの急速な普及にもかかわらず、実践者やその出力を監視している人々の間には、スロップ（質の低いコード）の津波は終わるのか？利便性のために自らを破壊しているのか？どうすればこれを止められるのか？という一般的な不安が広まっています。 意図がコードに先行する UMLの共同制作者であるGrady Boochは、私たちはソフトウェアエンジニアリングの第三の黄金時代にいると主張しています。第一期（1940年代後半から1970年代）はアルゴリズムの時代でした。ハイレベル言語とコンパイラがマシンを抽象化しました。第二期（1970年代から2000年代）はオブジェクト指向抽象化の時代でした。第三期（2000年頃開始）はシステムの時代であり、ライブラリ、プラットフォーム、APIがサブシステム全体を抽象化しました。Boochは、この第三期はAIによって始まったのではなく、AIによって加速されただけだと注意深く述べています。しかし、彼はAIコーディングエージェントをGrace Hopper時代のコンパイラの登場と比較しており、それがここで重要な比較です。コンパイラはマシンを抽象化しました。エージェントはコード自体を抽象化します。私たちは今、初めて、意図から直接コードを生成できるようになりました。この能力の欠如が、かつてモデル駆動開発（MDD）をダメにした原因でした（UMLについてどう思うかは別として、もしかしたらMDDを何らかの形で復活させる時が来たのかもしれません）。実用的なレベルでは、抽象化を意図へと進めるにつれて、コードを信頼できるプロセスにするために役立った多くのツールや方法を失います。もし適応できれば、この変化は開発をスピードアップするだけでなく、ソフトウェアソリューションの質を大幅に向上させる可能性があると信じています。しかし現在、私たちはバイブコーディングのカジノに閉じ込められています。誰もが、まるで明日がないかのようにコードを生成し、レバーを引いて最善を願っています。 問題 バイブコーディングは、ほぼ普遍的に、（a）ソリューションやアーキテクチャに対する個人の理解を損なうこと、そして（b）プロンプトの指定不足、自然言語インターフェースの損失、非決定的なコード生成により信頼性が低いこととして説明されています。バイブコーディングをしているとき： - 作業しているコードベースの理解を止めてしまう。 - 構築されるメンタルモデルは曖昧で、主にプログラマーとしての自身の過去の経験に依存する。 - 無駄な/重複したコードやスタブへの認識を失う。 - 何が実装され、なぜ実装されたのかを見失う。 - 他の人にアーキテクチャを説明したり、潜在的な問題について推論したりできない。 - 計画を承認する前に、何が変わるかについての可視性がほとんどない。 エージェントは通常、何をするかを説明する短いエッセイを書きますが、それは限定的です。それは影響範囲を示しません。それが何かを部分的にしか実装していないこと、あるいはあなたが当然だと思っていた重要な何かを省略したことを教えてくれません。たとえ教えてくれたとしても、計画には学習可能な構造がないため、あなたはそれを見逃すかもしれません。これは、あなたのワークフローをゆっくりと消費し、ソフトウェアエンジニアとしてのあなたの厳密さを低下させるブラックボックス効果であり、最終的には盲目的にコミットをプッシュし、本番環境をダウンさせることになります。たとえあなたがコーディングエージェントをこのように乱用せず、手動でプログラミングを続けたいとしても、これが大規模なソフトウェアエンジニアリングの未来であることは否定しがたいでしょう。多くのエンジニアがコーディングエージェントをコアワークフローの一部として使用していること、そして多くの100倍開発者が、制御と意思決定が単なる目標からの邪魔であるかのように、それらを使って自律ループを作成しようとしているのを見ることができます。いずれにせよ、それは信頼に帰着します。あなたはコードベースに対する自身の理解を信頼できず、エージェントがあなたの望んだことを行ったと信頼することもできません。 ソリューションは未熟 これが悪いことであることは皆理解していますが、潜在的なソリューションはどうでしょうか？このトピックについては多くの議論がありますが、これまでのところ提案されているものはどれも説得力のあるものではないと私は主張します。まず、私たちが何をしようとしているのかについて合意する必要があります。それは、コーディングエージェントの出力に対する信頼を可能な限り最小限に抑えたいということです。それを支持するために、私たちは以下を望みます： - エージェントが要求されたことを確実に実行すること。理想的には決定論的に、それは不可能かもしれませんが、良い目標です。 - コードベースに対して何をしたかを監査し、追跡できること。理想的にはコードを読む必要なしに。 - フリクション（摩擦）を最小限に抑えること。バイブコーディングは、抵抗の少ない道であるため勝利しています。私たちはそれを受け入れ、規律ある道を簡単なものにする必要があります。そして、現在のソリューションのどれもがこれら3つの点を十分に満たしていません。それらのほとんどは、プロンプトエンジニアリングの何らかのバリエーションに依存しているか、あるいは単にそれであり、それは意図の蒸留（#1）とは異なります。 Markdown仕様 私が話す多くのエンジニアは、次のように始めます。「ええと、私はMarkdown仕様を使用し、エージェントパイプラインを調整してそれらをレビューし、コードとして実装し、それらを管理・更新します。そして、それは一貫性のためにレビューし、既存のコードベースに対してチェックし、競合するものをフラグ付けし、実装に引き渡します。そして、それが完了したら、仕様を更新してドキュメントとコードが決して乖離しないようにループバックします。つまり、Markdownが真実の源であり、他のすべてはそれを同期させ続けるために周回するだけです…」私の目がうつろになるにつれて、私は考えずにはいられません。仕様のためのシステムや構造化されたフォーマットはありますか？仕様のどの部分が実際に実装されているかを知る方法は？コードが仕様で指定された以外のことをしていると知る方法は？どのエージェントパイプラインですか？仕様が存在することをエージェントに思い出させる必要がありますか？なぜ私は直接エージェントにプロンプトしないのでしょうか？これらから多くの質問が派生しますが、通常、それらへの答えは非常に曖昧です。その時点で、これは検証可能な影響のない個人的なワークフロー最適化のように見えます。彼らが何をしているにしても、彼らにとっては「厳密」に感じられる、それだけです。これは、2026年2月のAddy Osmaniの記事「AIエージェントのための良い仕様の書き方」によって見事に例示されています。それは曖昧というわけではありませんが、密です。5つの原則、6つのセクションフォーマット、2,500のコンフィグファイルの研究、あなたが聞いたことのあるすべてのツールが言及されています。それはシステムのように見えます。そして、記事全体が単にエージェントのコンテキストでプロンプトエンジニアリングを説明していることに気づきます。仕様は「真実の源」ではなく、ガイドとなるプロンプトであるため、これを仕様駆動開発と真剣に呼ぶことはできません。エージェントに「コードは仕様に従っていますか？」と尋ねる以上の強制メカニズムや、ましてや調整メカニズムはありません。AIは、共有構文がないため、それを好きなように解釈できます。根本的に、Markdown仕様はエージェントに対する信頼の欠如に対処しておらず、管理するのが非常に面倒です。それらが有用になるためには、明確に構造化され、より大きなシステム内に配置される必要があります。 スキル これらは基本的に、タスクに応じて条件付きで注入されるコンテキスト/指示です。それらは有用である可能性がありますが、それでもエージェントがそれに従うことに完全に依存しており、これはMarkdown仕様と同じ方法で私たちのニーズを満たせません。実装するのがはるかに手間がかからないとしてもです。面白​​いことに、それらはしばしば、gstackのこの巨大な「QA」スキルのような、厄介な詰め物になりがちです。「バグを見つけて修正してください」とプロンプトするだけで、同じくらい（あるいはそれ以上）うまくいくと確信しています。