Vibe Codingは実プロジェクトで通用するのか？ 約6ヶ月試してわかったことと必要なスキル

1. はじめに：この記事の前提と、私の定義する「Vibe Coding」

本題に入る前に、少しだけ私の立ち位置とこの記事の前提をお話しさせてください。

私はプログラマーとして約5年働いた後、現在はデータサイエンティストとしてAI構築とシステム構築を並行して行っています。
そのため、この記事でお話しする 「Vibe Codingは実プロジェクトで通用する」という結論は、あくまで私が身を置くデータサイエンスやAI開発の領域での話かもしれません。純粋なWebフロントエンド開発や、巨大なエンタープライズ系システムなど、他のIT分野でそのまま通用するかどうかは私自身テストしていません。

しかし、私がこの約6ヶ月間で試行錯誤し、Vibe Codingを使いこなすために工夫した「設計の考え方」や「AIとの付き合い方」には、きっと他の分野のエンジニアの方々にとっても役立つヒントがあるのではないかと思い、この記事を書くことにしました。

また、最近「Vibe Coding」という言葉をよく耳にしますが、この記事では私が考える以下の定義を使用します。
私が考えるVibe Codingとは、「自然言語をメインにプログラムを作成し、人はほぼコーディングしない状態（90%以上自然言語）」のことです。AIにコードの書き方を聞いて、それを人がタイピングしていくのは、個人的にはVibe Codingに入らないかなと思います。

直近の2つのプロジェクトで、実際にVibe Codingを用いて最終納品まで行ってみました。特に最近リリースされたGemini 3.0やOpus 4.6あたりから性能が飛躍的に上がっており、そこで得られた「リアルな所感」をまとめていきます。

2. 結論：Vibe Codingは強力だが、「シニア向け」の武器だと感じた

私のケースにおける結論から言うと、Vibe Codingは実業務でも十分に通用しました。
実際に生産性はかなり上がり、コードの品質も向上し、なにより「方向転換（仕様変更）」が以前よりはるかに楽になりました。

しかし、誰でも使える魔法の杖ではありませんでした。
プログラミングの基礎があり、経験豊富なシニアレベルのエンジニアにとってのみ強力な武器になる、というのが私の印象です。プログラミング経験が浅い人がやると、AIの言われるがままに進んでしまい、逆に生産性が下がったり、納品物として認められない品質に陥るケースが多かったです。特に課題だと思ったのが、ジュニアレベルのエンジニアがVibe Codingで作業を行うと、実力が伸びないことでした。

3. 対象プロジェクトの規模感と、「一人作業」に行き着いた理由

今回私がテストした納品物は、超大規模なシステムではありません。私が実際に日常的に使用している研究支援ツール（技術スタック：Python + Neo4j + OpenAI）です。

具体的な規模感としては以下の通りです。

• ソースコード： 約1.5万行
• ファイル数： Pythonファイル約100本

よくある「チュートリアルのToDoアプリ」のような単純なものではありませんが、かといって「大企業の基幹システム」でもありません。規模としては大きくないものの、UI・ビジネスロジック・ファイル管理・AIエージェント連携・ログ管理といった異なる関心領域が一つのシステムに同居しています。さらにデータ層にはグラフDB（Neo4j）を採用しており、エンティティ間の関係性をグラフ構造で扱う設計判断が随所に入っています。 「単一の技術領域で完結しない、現実的な複雑さを持つプロジェクト」で、Vibe Codingの検証対象としてはちょうど良いと考えました。

最初はメンバーレベルのエンジニアと一緒に作業していましたが、途中から「完全に一人で作業する」ほうが圧倒的に生産性が高いことに気づきました。

なぜなら、Vibe Codingを使った開発では「テストしながら設計を頻繁に変え、壊して作り直す」ことの連続になったため、ジュニアメンバーに共有したり教えたりするより一人でループを回すほうが効率的だったからです。彼らにはそのスピード感についてきてもらうのが難しい状況でした。

彼らのスキル不足というよりは、今回の私のプロジェクト特有の『頻繁に設計を壊しては作り直す』という超高速なサイクルが、そもそもチームでの同期開発に向いていない（属人性の極みである）のが原因かもしれません。

4. Vibe Coding最大の鍵は「AIが100%の力を出せる問題設定」

実際にVibe Codingをやってみると、AIに抽象的な課題を丸投げしても良い結果にはなりませんでした。システムが大きくなるにつれて、それっぽいコードは出ても中身が伴わず、絶望的な状況になります。

なぜか？それはLLMのコンテキスト（一度に処理できる情報量）の限界と、メモリ（記憶）の限界があるからだと思っています。指示が長くなると、AIは真ん中の内容や細かい条件をすぐに忘れてしまうことが頻繁に起こっていました。

この問題を解決するために考えたのが、Vibe Codingの本質は、単にプロンプトを投げることではなく、「どうすればAIエージェントが最大の力を発揮できるか、そのための問題設定（枠組み作り）をすること」だと思ったのです。

AIが迷わず、最高のパフォーマンスを出すための条件を逆算して考えると、以下の4つを満たす必要がありました。

1. 情報量の制限: 1回にAIが考えるための情報量（コンテキスト）を極力減らす。
2. 連携の排除: 作業を完全に独立させ、別々の課題として取り組ませることで、「複雑なシステム間連携」をそもそも考えさせない。
3. サンプルの提示: 見本（サンプル）を与えることで、AIの成功率を飛躍的に上げる（Few-shot learningの活用）。
4. 一般的な「型」の利用: AIがすでに大量のデータで学習している「一般的なやり方・構造」を指定することで、意図を正確に理解させる。

この「AIのための設計思想」を突き詰めた結果、私は自然と以下の 3つの具体的な手法 に行き着きました。

① 徹底的な「モジュール化」
【上記1, 2の解決策】
システムを徹底的に分割し、各パーツを独立させました。コンポーネント間の連携はファイル単位にするなど一番シンプルにし、「お互いの存在すら知らない」状態にします。これにより、AIは「今作っている一つの機能」にだけ100%集中できるようになります。

② デザインパターン（FactoryやTemplateなど）の活用
【上記3, 4の解決策】
AIと非常に相性が良かったのが「型」を決めることです。例えばFactoryパターンを採用すれば、自然と「サンプル（Few-shot）」ができるため、AIが完全に型に沿って精度の高いコードを出力してくれます。
また「〇〇パターンで書いて」と指示するだけで、AIは過去の膨大な学習データからその構造を瞬時に理解してくれるため、コミュニケーションコストもかなり下がります。

③ 概念から詳細へ、階層を分けた「設計書の作成」
【上記1の解決策】
IT業界の基本である「設計書」ですが、Vibe Codingではこれを「AIの認知負荷を物理的に下げるため」に使います。

一度にすべての要件を渡して考えさせるのではなく、「概念設計書」「アーキテクチャ設計書」「コンポーネント設計書」「詳細設計書」とレベル別に細かく分割し、段階的にAIと壁打ちしながら作っていくのが、AIをパンクさせないための工夫でした。

そしてここでもう一つ重要なカギとなるのが、この分割によって「AIが実装時にすべての設計書を読む必要がなくなる」ということです。

システムを細かくモジュール化し、さらにモジュールごとに設計書を分割して書くことで、いざ実装フェーズに入った際、AIには「今から作る機能に関係する設計書」だけを渡せば済みます。
巨大な全体仕様書を毎回読ませるようなことを避けることで、LLMのコンテキスト（文字数制限）を大幅に節約でき、結果として本当にAIの負担が下がり、出力の精度が劇的に安定するのです。

5. 実際の作業ワークフローと「全量AI任せ」の現実

実際の作業は以下のようなループで進めました。

1. 概念をざっくりAIに伝え、どう分割するかを相談する（コードはまだ書かない）
2. コンポーネント設計 → うまくいかなければ概念から再検討
3. 詳細設計 → レビューし、必要ならコンポーネント再設計
4. 実装ボタンを押してAIにコーディングさせる
5. テストし、また設計書の修正に戻る

最初は自分でも少しコーディングしていましたが、慣れていくとどんどん全量をAIに任せるようになり、今ではもう自分でコーディングはしていません。

また、これらの作業において、私はClaude CodeとGitHub Copilotの両方を併用しました。

ツールによって得意・不得意が異なると感じていて、今回の検証時点では「GitHub Copilotは設計書作成に強く、Claude Codeは実際にコードを書くのが優れている」という印象でした。(GithHub CopilotはClaude Opus4.6を使いました)

ただし、こういったツールの特性は、背後にあるモデルのアップデートやプロンプトですぐに変わってしまうと思います。そのため「このツールが正解」と固執するのではなく、最新のものを試しながら、その都度決めていく必要があるかなと思います。

6. AIは間違える。だから「複数AIによるクロスレビュー」と「人間の基礎力」が必須

Vibe Codingにおいて最も重要なのは、AIの作業物を必ず確認（レビュー）することです。

設計書をちゃんと書いても、想定漏れがあるたびに独自のロジックを入れたり、たまに変な間違いをします。

しかし、人間が全量をチェックするのはかなり疲れる作業です。そこで私は、ある程度成果が出るパーツに関しては、AIにレビューをさせるようにしました。

具体的には、Claude CodeとGitHub Copilotの両方に作業結果をレビューさせます。

同じコードや設計書を見せても、AIによって見る観点が微妙に違うため、異なる箇所の指摘が出たりします。AI同士のクロスチェックを入れることで、作業の間違いやベストプラクティスからの逸脱を細かく拾い上げることができます。

一方で、人間の目で絶対に見るべきポイントもあります。例えば「テストコード」です。AIにテストコードも書かせていますが、中身を確認しないと、本当に必要なテストは行ってなかったり、非効率的なテストになっていたりしました。

また、アーキテクチャの変更など広範囲にわたる修正では、この「AIレビューのループ」自体を複数回回す必要もあります。
特に、システムのコアになるところの設計判断は、まだAIだけで設計するといまいちなところが多かったので、重要な設計判断は私がすべて細かく指示したり、場合によっては直接書いたりしました。

ここでモノを言うのが、人間の「プログラミングの基礎力」です。

メモリ管理、デザインパターン、データ構造などの基礎知識があるからこそ、複数AIのレビュー結果を統合し、正しい判断を下すことができます。API利用料は月に数万円を超えますが、ジュニアエンジニアを採用するより遥かに安く、圧倒的に速いです。

7. まとめと、今後のエンジニアのあり方

私の経験上、Vibe Codingで成果を出すための最大の鍵は、プロンプトの小手先のテクニックなどではなく、「AIが100％のパフォーマンスを出せるように課題設定（枠組み作り）を行うこと」だと感じています。

それは結局のところ、「その時点でのAIの弱点をどう人間がカバーし、乗り越えるか」というアプローチになります。
今の時点では、LLMのコンテキスト量の制限、記憶の限界、そしてシステムのコア部分の設計判断が最大のボトルネックであったため、私はその対策として「徹底的なモジュール化」やシニアが設計する「階層的な設計書」という解決策を提供しました。

しかし、今後モデルがアップデートされれば、この弱点は変わり、また別の壁が現れるはずです。だからこそ、Vibe Codingの本質は特定の設計手法に固執することではありません。「常に最新のAIの性能と弱点を見極め、それに合った解決策（アーキテクチャやワークフロー）を提案し続けること」ことではないでしょうか。

そのAIの弱点を見極め、適切な対策を設計できる「エンジニアとしての基礎力と応用力」を持つ人こそが、Vibe Codingという強力な武器をフル活用し続けられるのだと思います。

8. 余談

Vibe Codingは本当に強力です。アイデアを実現する速度は圧倒的で、テストしながらベストなやり方を探す「トライ＆エラー」のコストが格段に下がりました。

しかし一方で、AIの作業を正しくレビューできないエンジニアは、AIに振り回され、いずれAIに交代されるだけになると思います。
特に恐ろしいのはAIの進化速度です。私自身、今はコンピューターサイエンスの基礎知識や今までの経験でなんとか耐えていますが、「シニアレベルのレビューすらいらなくなる時代」、「人が解決できる弱点が無い時代」があと何年残っているでしょうか。あと1〜3年もすれば、私ですら不要になるかもしれません。

恐ろしくもあり、非常に面白い時代が来たなと感じています。