Vibe Codingの現在地 : 2026年7月版〜 ハーネス、レビュー、テスト 〜(ソロプレナー視点)

ソロでダンジョン潜りがち、プロダクトエンジニアの池内です。今回は、2025年から起こったとされるムーブメント、Vibe Codingについての現在地を、個人的な知見と実践知から語ってみたいと思います。ここで扱うスコープですが、ソロないし極小の開発チームによる、ということで、一定規模のチーム開発における視点は含まれていません。また、プロダクトのもたらす事業価値やユーザー価値についてもここでは関心事としません。

Vibe Codingとは（おさらい）

Vibe Coding（バイブコーディング）とは、Andrej Karpathy氏が広めたとされる言葉で、ソフトウェア開発の手法がこれまでのプログラミング言語を記述する方法から、自然言語による指示（プロンプティング）に置き換わっていくことを表明するものでした。ざっくり歴史をまとめると以下のようになるのですが、

• 2025年2月：Andrej Karpathy が 「Vibe Coding」 という言葉を初めて公に提唱。「まず作る」ことを重視した新しい開発スタイルとして、シリコンバレーを中心に急速に広まる。

• 2025年前半〜中盤：Lovable、Bolt.new、v0、Replit などのAIノーコード、ローコードツールが急速に普及。プログラミング経験が少ない人でもWebアプリやプロトタイプを短時間で構築できるようになる。

• 2025年後半：Cursor や Anthropic などの強力なAIコーディングエージェントが登場・普及。エンジニアだけでなく、デザイナーやPMなど非エンジニアも実用レベルのアプリ開発に参加できる時代が始まる。

• 2026年2月：単にAIへ指示してコードを書かせる「Vibe Coding」の段階から一歩進み、品質・設計・テスト・運用までAIを活用して管理する 「エージェンティック・エンジニアリング（Agentic Engineering）」 という考え方が提唱される。AIを「コード生成ツール」ではなく、「協働するエンジニア」として扱う開発スタイルへと進化する。

この間じつに1年で、一体どれだけの進化を遂げたのだろうと思うとちょっと震えますね。

なにがVibe Codingであってなにがそうでないか、という点はおそらく読者によってことなるものと想像します。狭義には、コードは一切見ないし把握することもないが、最終成果物（アプリのUIと動作結果）をもって、アプリの品質を定義して改善まで行う作業、ということになるのではないかと思います。となると、僕を含めてソフトウェア開発を専門とするエンジニアが行っているのはVibe CodingではなくAgentic Engineeringであると整理できます。また昨今はハーネス・エンジニアリングやループ・エンジニアリングといったバズワードが生みだされているようです（基本的にすべて同系列の話題を取り扱っているという理解です）。

とにかく、本稿ではAI前提のソフトウェアの開発スタイルのまとめてVibe Codingと呼んでいると思っていただき、厳密な定義が気になる方は適宜読み替えをお願いいたします。

Vibe Codingはもう前提

2025年前半がある意味勃興期かつ、期待と失望が入り交じっていた時期だったかなと思います。Vibe Codingによって一見それらしいアプリはつくることができるのですが、考慮すべきセキュリティやデータ管理の要件が満たされていないアプリが問題視され（AIの誤操作によるデータの全喪失という事件もありましたね）プログラミングの民主化という意味では意義を認められていたものの、Vibe Codingは素人の遊び、というように揶揄の対象にもなっていたかと思います。

個人的に潮目が変わったのはやはり2025年の後半で、Claudeでいうと Opus 4.1以降、OpenAI CodexのGPT-5以降が出てから、これはもう一線を越えたかもしれないと強く考えるようになりました。2025年末には、自分のコーディングは99%がエージェントに依頼をする方式になっていました。これは誇張なしに、1行、1文字、1pxの修正であってももはやAIに指示を出しています。自分でコードエディタを開いて中身を編集する、ということをもうしていないですね。

そんなわけで自分ももはやVibe Codingをしているのではないか？と思いこの記事を書くきっかけにもなったのですが、一世代前のVibe Codingといまのそれとではちょっとレベルが違うというか、Vibe Coding 2.0? は人間が下手に細かく指示をするよりもざっくり任せたほうがいいものが出てくる節すらあります。

コードレビューについて

AI時代において、コードレビューをするかどうかという問いが立ちあがっています。プルリクエスト、下から見るか？横から見るか？問題（違）。これはAIによってコーディングが高速化し、プルリクエストの作成数が激増することによる問題意識とともに語られます。コードの品質は人間が担保するべきなのだから、AIが書いたものは人間がレビューしなくてはならない。そのような考えが支持されるいっぽう、レビューの負荷が人間、特に特定の人に集中することで、そのプロセスが開発工程のボトルネックになるという問題が顕在化してきました。

コードレビューについてはAI以前からしばしば問題としては取り上げられており、特に少人数組織の場合、CTOやテックリードなどにレビュワーが偏りがちでした。組織内のスキル格差が大きい場合などは特に、レビューと修正のプロセスが双方の負担となることが多かったです。というように元々このプルリクエストのレビュー問題は存在していたのですが、人間のレビュワーがスケールしないうちに、コーディング側がスケールするようになってしまった、というのがこの1〜2年で起きたことです。

僕はいま自社開発についてはソロなのですが、複数のエージェントに開発を指示し、成果はすべてプルリクエストにしてもらっています。それで、コードをレビューするかでいうと、今ではほとんどしないです。と言い切ると語弊を生むのでこのあと少し説明するのですが、このスタイルもここ半年で変わったことかなと思います。2025年まではもう少しレビューをしていました。

ハーネス・エンジニアリング

前項で、AIの送ってきたプルリクエストをほとんどレビューしないと述べました。それで大丈夫かと思われると思うのですが、いわゆるハーネス・エンジニアリングをかなり厚めに行っています。

ハーネス・エンジニアリングというのは、AIが参照できるテキストファイルやスキル（Agent Skills）に技術的な要件を記述し、AIがそれらを守りながら自律的に稼働するようにする方法のことです。何やら新しい名前がついていますが、要するにただのドキュメンテーション技術ですね…。

僕はもともとソフトウェアのアーキテクチャやデータベースなどの設計領域に関心があって、アーキテクチャについて考えたり、認知負荷の低いディレクトリ構造について考えたりすることが結構好きでした。それらの重要な点をスキルとして登録し、エージェントに参照してもらうようにしています。アーキテクチャについて、従来から取り組んでいたドメイン駆動設計（DDD）とオニオンアーキテクチャを採用しているのですが、こうするとレイヤー（≒ディレクトリ）が明確に分かれるんですね。

これにより、例えばAIがつくってきたプルリクエストの変更ファイルが100個くらいになっていたとしても、自分がまず見なければいけないところはデータベースの操作系のコードなので、そうすると特定のレイヤー（この場合インフラ層）を重点的に見ればよい、ということがすぐに分かるんですね。こういう枝葉の刈り取りができることが結構大事だと思っています。

ので、コードレビューはほとんどしないとは言ったものの、レビューをしなくても良くなる準備のほうにしっかりコストをかけて、かつ、認証系を中心にセキュリティ関係とデータベース周辺については細かく把握するようにしています。ただそれもプルリクエストのタイミングというより、リリース前までにはしっかり把握しておくというような心づもりでやっています。

テスト、CIについて

ソフトウェアの品質担保において、単体テストやエンド・ツー・エンド（E2E）テストの実践は欠かせません。ということは界隈でも口を酸っぱく言われてきたのですが、どうしても速度とのトレードオフと見られおざなりになってしまうことも少なくありませんでした。いまではユニットテストはAIが実装コードとセットで書いてくれますし、E2Eテストの事前準備やデータ作りといったこともAIがこなしてくれるようになりました。これらを強制するのもハーネスづくりの範疇かとは思いますが、人力コードレビューの網羅性が下がっていく分、E2Eのテストを厚くしていくのは良いのではないかと思っています。

AIの書く単体テストは過剰である、というような意見もあって確かになと思ういっぽう、僕は開発にBunを利用することが多いのですが、ランタイムの性能でゴリ推ししていけばいいのかなと考えています。BunもRustになりますしね…。

WebフロントエンドだとPlaywrightやStorybook、モバイルだとMaestroといったツールの活用は以前から行われていましたが、どうしても単調作業になったり、すぐにテストが壊れたりするので運用が難しかったりもしました。AIによってこのあたりのフラストレーションが解消しつつあるのは光明です。

ごく最近だと、ClaudeがiOSのシミュレータを触れるようになったのですが、

これがすごくよくて、E2Eテストやスタイリングの修正や改善も一気に捗りそうだなと思っています。トークンの消費量はやや気になるものの。

人間は何を診るべきか

ここで、やっぱりプログラミングの基礎は押さえていたほうがいいぞ、みたいなことを言うべきなのかも知れませんが、ここ1−2ヶ月でもまた進化があって、そう、ヤツの登場、Fable 5ですね。Fable 5は本当にすごくて、フロントエンドのとくにデザイン面での質が一気に二世代くらい進化した感じがしています。フロントエンドに限らず、またFable5以外にもCodex 5.6やGrok 4.5など、コーディングレベルの高いAI（フロンティアモデル）が一気に台頭してきたことを実感しています。このブログを書いている最中にOpus 5も出ました（追いつかないので言及しません）。

こうなると、もう人間の平均よりもAIのほうが質が高いんですね。例えばパスワードの平文保存とか、WHERE句の漏れや取り違えによるデータの漏洩といったソフトウェア開発の "あるある" 問題（※ あってはいけないです本来）はもうデフォルトでケアされているので、これは少し程度が低い基準かも知れませんが、人間が心配するよりも先にAIがカバーしていることが増えていくことは間違いがないと思います。自動運転車が居眠り事故を起こすことはない、みたいな感じですかね…。

ただ、それでもやっぱり理解したほうがいいこと、抑えておいたほうがいいことは当然あって、主要なものを書いておきたいと思います。

認証・認可、セキュリティ全般

いうまでもないことですが最重要項目としてチェックします。チェックの方法ですが、目検と動作確認などによる古典的な確認のほか、実装したAIモデルとは別のAIモデルに検査させる、というのがおすすめです。

認証・認可まわりはすべて自分で実装せず（自分といってもAIが実装するわけですけど）Better Auth などのライブラリを活用するのがおすすめです。Better Authについては今度イベントに登壇するのでぜひ来てください。

データベース

アプリケーションの運用のなかでもっとも不可逆なもの、変更コストが高いものはデータベースだと言われています。あとから問題が判明するものとして、

• 必要なデータを保存していない（あとから取り返せない）

• 汎用性が高すぎるか、低すぎるかで拡張性に問題がおきる

• 将来的なデータ構造の変更、データ移行に苦労する構造か、最悪できない

このあたりがトラップかなと思います。例によって、普通にエンジニアリングチームで取り組んでいてもこういうことは起きるわけですが…。

リリース前（デプロイ前）であればテーブル定義はいくらでも変更できるので、ここもやはり細部まで自分が把握して進めるべきところですね。いずれにしても、データベースの設計ができる、レビューができるということは、Vibe Codingで一定品質のアプリケーションをリリースできるかどうかの分水嶺になるかなと思います。

べき論でいうとできるだけ診るべき、という論は立つのだと思うのですが、現実的にはもうAIがばんばんコードを実装してくる現実があって、人間の認知負荷を超えているのだと思うのですね。その結果、網羅的に目検しようとすると、精度が落ちてかえって重要なものを見落としてしまうという現象がおきると思っていて、品質を保つために割切ることも必要なのかなと思っています。なので安心して割切るためにその準備をしたほうがいいという理屈ですかね。

あと有効なのは複数のAIによるクロスレビューで、Codexの実装をClaudeに、Claudeの実装をGrokにレビューしてもらうなどしています。これで結構問題がつぶせることが多いです。AIに対してのレビュープロセスは相当ねちっこくできるのが利点なので、「ごめんさっき大丈夫ということだったけど本当にそうかもう一度調べて」みたいなことをよく言っています。

結局、アーキテクチャ論は大事

結論は若干月並みなところに帰結しようとしていますが、2026年のVibe Codingにおいても、システムの全体感や、ソフトウェアのアーキテクチャについて見通しをもったうえで取り組むことが大切かなと思います。

僕自身の個人的なやり方ですが、Agent Skillsをひととおり用意した状態で開発を進め、ある段階に達したら、フロンティアモデルのかつ最上位の設定で、レイヤーごとにリファクタリングをさせる、ということを行います。多いときで数千行、数百ファイルの変更がはいったプルリクエストになります。それでも、全レイヤーを順に見直していって、、というのでかかる日数は1−2日ですからね。これまでは本当に考えられなかったことです。

アーキテクチャについての知見が一切無いと、そもそもハーネスを用意できませんし——どこかから取り寄せたハーネスを理解せず使うという説もあって、実際それでもある程度機能しそうなわけですが——前述のとおり、どこを重点的に確認する必要があり、どこは薄くても良いかという見立てを立てられることが、最終的な速度と品質の両面に寄与すると思います。

当然のことながら僕自身も100%ミスのない仕事ができるわけではないので、凡事徹底、日々修練です。

最後にソフトウェア設計に関するおすすめの一冊を紹介して、今回は以上です。