バイブ・コーディングとエージェント型エンジニアリングは、私が望むよりも早く近づいてきている

2026年5月6日

最近、HeavybitのHigh Leverageポッドキャストで、AIコーディングツールについてジョセフ・ルシオと話しました: Ep. #9, The AI Coding Paradigm Shift with Simon Willison。以下は私のハイライトです。そこには、自分の仕事の中でバイブ・コーディングとエージェント型エンジニアリングが収束し始めているという、ぞっとするような気づきも含まれています。

ポッドキャストの良いところは、時々、これまで言葉にできなかったアイデアをあえて口に出して考えるよう促してくれることです。

バイブ・コーディングとエージェント型エンジニアリングは重なり始めている

バイブ・コーディングという言葉が最初に使われてから数週間後、私は Not all AI-assisted programming is vibe coding (but vibe coding rocks) を公開しました。そこで私は、「『バイブ・コーディング』は、責任ある形でAIにコードを書かせることとはまったく別物だ」という強い確信を明確に示し、その後それを エージェント型エンジニアリング（agentic engineering） と呼び始めました。

ジョセフが2つの違いを持ち出してきたとき、私は、以前ほどには私の中で両者が明確に分かれていない、という突然の気づきを得ました:

変な話なんですが、もう私の中ではそうしたものがすでに曖昧になってきています。かなり不安になります。

私は、バイブ・コーディングは「コードを一切見ない」ことだ、という非常にはっきりした線引きがあると思っていました。プログラムの方法すら知らないかもしれません。プログラミングができない人で、やりたいことを頼んで、ものが返ってきて、それが動けばそれでいい。動かなければ「動かない」と伝えて、指をくわえて待つわけです。

しかし、どの時点でも、コードの品質だの、そうした追加の制約だのを本気で気にしていない。私のバイブ・コーディングへの見解では、それは「使ってよい場面と使ってはいけない場面を理解しているなら」素晴らしいものです。

つまり、あなたのための個人用ツール。もしバグがあっても痛いのはあなただけでいい。どうぞ！

他の人のためにソフトウェアを作っているなら、バイブ・コーディングは極めて無責任です。というのも、それは他人の情報だからです。他人は、あなたのくだらないバグのせいで傷つきます。そこよりも一段高いものが必要です。

それとは対照的なのがエージェント型エンジニアリングで、あなたはプロのソフトウェアエンジニアです。セキュリティや保守性、運用、パフォーマンスなどを理解しています。これらのツールを、自分の能力の限り最大限に活用している。だから、私が引き受けられる課題の範囲が、これらのツールの支えによってかなり増えているのを感じています。

とはいえ、私はまだ、ソフトウェアエンジニアとしての25年の経験に寄りかかっています。

目標は、高品質な本番システムを作ることです。低品質なものを速く作るのは良くないと思っています。私は、より高品質なものをより速く作りたい。自分が作るものは、以前よりもあらゆる面で良くなっていてほしい。

問題は、コーディングエージェントがより信頼できるようになるにつれて、私は書かせたコードのすべての行をレビューしなくなっていることです。たとえそれが本番レベルのものであってもです。

例えば、Claude Codeに「SQLクエリを実行して結果をJSONとして出力するJSON APIのエンドポイント」を作らせれば、ちゃんとやるだけだということは、私は十分承知しています。壊すことはしません。自動テストを追加させればいいですし、ドキュメントを追加させればいいです。そうすれば、ちゃんと良いものになるはずだと分かっています。

でも私は、そのコードをレビューしていない。すると今、罪悪感のようなものが湧いてきます。レビューしていないなら、本番で使うことが本当に責任ある判断なのだろうか？

私を本当に助けてくれるのは、昔、大きな組織でエンジニアリングマネージャーとして働いていたときのことを思い出すことです。別のチームが作ったソフトウェアが、私のチームの依存先になっている。

もし別のチームが何かを手渡してきて、「これは画像リサイズのサービスです。あなたの画像をリサイズするための使い方はこれです」と言ったら……私は彼らが書いたコードのすべての行を見に行ったりはしません。

代わりに、彼らのドキュメントを見て、それを使っていくつかの画像をリサイズします。そして自分の機能の出荷を始めます。もし画像リサイザー側にバグがあるようだったり、パフォーマンスが良くなかったりする問題に当たり始めたら、その時に初めて、彼らのGitリポジトリを掘り下げて状況を確認するかもしれません。でも基本的には、それは半分ブラックボックスのように扱っていて、必要になるまで見ません。

私は、それと同じようにエージェントも扱い始めています。とはいえ、まだ居心地の悪さがあります。なぜなら、人間には自分の行動に対する責任があるからです。チームは評判を作ります。「あっちのチームは信頼できる。彼らは過去に良いソフトウェアを作ってきた。彼らがくだらないものを作ってしまうことはない。そうなればプロとしての評判に響くからだ」と私は言える。

Claude Codeには、プロとしての評判がありません！ つまり、自分が行ったことに対する説明責任を取れない。けれども、それでもちゃんと証明し続けています――何度も何度も、私が好むスタイルで、まっすぐで分かりやすいことを吐き出して、それを正しく実行してくれている。

ここには 逸脱の正規化 が関わっている要素があります。モデルが、私が注意深く監視していなくても正しいコードを書けてしまうたびに、将来の別の場面で誤って信じてしまい、痛い目を見るリスクが生まれるのです。

ソフトウェア評価の新しい難題

昔は、コミットが100件あるGitHubリポジトリを見つけて、良いREADMEがあり、自動テストやいろいろが揃っていれば、その人がそのプロジェクトに相当な配慮と注意を払ってきたのだとかなり確信できました。

しかし今は、1日分でもなければ、たった30分で、コミットが100件あるgitリポジトリに、美しいREADMEと、コードのあらゆる行を網羅する包括的なテストをつけてしまえるのです！ それは、相当な配慮と注意を払って作られてきたプロジェクトと、見た目がまったく同じです。たぶん同じくらい良いのかもしれない。分かりません。見ただけでは判断できません。私の自分自身のプロジェクトでさえ判断できません。

そこで気づきました。私がテストやドキュメントの品質よりも価値を置くのは、「誰かがそのものを実際に使っていること」だという点です。たとえばバイブ・コーディングで作られたもので、過去2週間、毎日使っているなら、それは、吐き出されただけでほとんど触られていない何かより、私にとってずっと価値があります。

ボトルネックは移動した

もし1日に書くコードが200行から2,000行に増えるのなら、何が壊れるのでしょうか？ ソフトウェア開発のライフサイクル全体は、実は「数百行のコードを作るのに1日かかる」という考え方の上に設計されていた。そして今、それが成り立たなくなったのです。

下流側だけの話ではなく、上流側の話でもあります。私は、Jenny Wenによる素晴らしい講演を見ました。彼女はAnthropicのデザインリーダーで、彼女は「デザインには〈正しく〉やる必要があるという考え方に基づいたデザインプロセスが、すべて存在する」と言っていました。というのも、エンジニアに引き継いで、エンジニアが間違ったものを作るのに3か月費やしてしまったら、それは壊滅的だからです。

高価な作業につながるようなデザイン結果を生むために、非常に広範なデザインプロセス一式を整えているわけです。しかし、作るのに3か月かからないのであれば、コストが間違った場合のリスクをこれまで以上に大幅に減らしているのだから、デザインプロセスはもっと大胆にできるのかもしれません。

なぜ私はまだキャリアに不安を感じていないのか

エージェントとの会話を見ていると、ほとんどの人間にとってそれが「月の言語」みたいなものだということが、よく分かります。

コンピュータが自分でコードを書けるようになって、これでソフトウェアエンジニアとしての私のキャリアが終わりだ、とは私は全く思っていない理由がいくつもあります。その一つは、これらのものが、既存の経験の増幅器になっている点です。何をすればいいか分かっているなら、これらを使うことで非常に速く動けます。[...]

私はこれらのツールを使いながら働いていると、私たちがやっていることがどれほど大変なものかを、絶えず思い知らされます。ソフトウェアを作り出すことは、ひどく難しいことです。そして、仮に私に世界中のAIツールを全部与えたとしても、ここで私たちが達成しようとしていることは、それでも本当に難しいのです。[...]

政治コメンテーターのMatthew Yglesiasは昨日、tweetをして、「5か月経った今、vibe codeはやりたくないと決めた気がする。つまり、AIのコーディング支援を使って、より／より良く／より安いソフトウェア製品を作り、それをお金で私に売るような、ちゃんと専門的に運営されたソフトウェア企業を使いたい。」と言いました。これは私にもかなりしっくりきます。配管についてYouTube動画を十分見れば、自宅の配管をいじれるかもしれません。でも、私は配管工を雇いたいです。

SaaS提供者に対する、企業が自前のソリューションを作ることによる脅威について：

さっき私が言ったことを、今さらながら思い出しました。私は、あなたのサイドプロジェクトを、数週間使ってみたことがある場合にしか使いたくない、という話です。その企業版の考え方は、「少なくとも他の2つの巨大な企業が、そのCRMを6か月間うまく使えている」までは、CRMは導入したくない、ということです。[...] うまく機能することが実証されるまで、リスクを取って導入する前に確かめたいのです。