第1章 — バイブコーディングの地図

ユウキの挫折

ユウキはスタートアップのフルスタックエンジニアだ。入社3年目、チームは5人。新機能の開発スピードが命のフェーズにいた。

ある日、CTO の提案で Claude Code を導入した。最初の1週間は魔法のようだった。

「ユーザーダッシュボードを作って」と言えば、React コンポーネントが生成される。「API エンドポイントを追加して」と言えば、Express のルーティングが整う。開発速度は体感3倍になった。

しかし2週目、異変が起きた。

• 同じような関数が3箇所に重複して生成されていた
• テストが一切書かれていない
• 命名規則がファイルごとにバラバラ
• import パスが壊れていてビルドが通らない

「AI に任せきりにした結果、コードベースがスパゲッティになった」——ユウキはそう気づいた。

バイブコーディングの3つのレベル

Karpathy が提唱した「バイブコーディング」は、実は均質な概念ではない。実践者のコミュニティでは、大きく3つのレベルに分類されるようになった。

Level 1: カジュアルバイブ

Karpathy が描いた原型。コードを読まず、AI の出力をそのまま受け入れる。個人の趣味プロジェクトや、使い捨てのスクリプトには十分機能する。

向いているもの: ハッカソン、概念実証、個人ツール

リスク: セキュリティ、保守性、スケーラビリティのすべてが犠牲になる

Level 2: ガイデッドバイブ

AI の出力を人間がレビューし、必要に応じて修正する。CLAUDE.md にプロジェクトルールを書き、基本的な制約を与える。多くの開発者が現在このレベルにいる。

向いているもの: 小規模チームの機能開発、個人の本番プロジェクト

リスク: 人間のレビュー品質に依存。疲労やスキル差で品質がばらつく

Level 3: ハーネスドバイブ

本書の主題。AI の出力品質をシステムとして保証する。hooks で自動チェックし、skills で手順を標準化し、subagents で専門性を分担する。人間は「設計」に集中し、「実行の監視」は仕組みに任せる。

向いているもの: チーム開発、本番サービス、長期プロジェクト

必要なもの: ハーネスエンジニアリングの知識と実践

AI コーディングツールの進化

ハーネスエンジニアリングが生まれた背景を理解するために、AI コーディングツールの進化を振り返ろう。

第1世代: 補完型（2021〜）

GitHub Copilot に代表される。カーソル位置のコードを「次の行」として予測する。人間が書くコードの延長線上にあり、制御は完全に人間側にある。

第2世代: 対話型（2022〜）

ChatGPT の登場で「コードを会話で生成する」パラダイムが生まれた。人間が要件を自然言語で伝え、AI がコードブロックを返す。コピー＆ペーストが必要だった。

第3世代: エージェント型（2024〜）

Cursor、Aider、Claude Code が代表。AI がファイルシステムに直接アクセスし、コードを読み・書き・実行する。人間は「何を作るか」を伝えるだけでよい。

なぜ Claude Code なのか

2025年現在、エージェント型 AI コーディングツールは複数存在する。なぜ本書では Claude Code を軸に据えるのか。

Claude Code が選ばれる理由は「ハーネスの深さ」にある。

Claude Code は「ハーネスエンジニアリングのために設計されたツール」と言っても過言ではない。設定の自由度と制御の粒度が他を圧倒している。

ユウキの決意

スパゲッティコードの山を前に、ユウキは決心した。

「AI を使うのをやめるんじゃない。AI の使い方を変えるんだ」

先輩エンジニアのミサキに相談すると、彼女はこう言った。

「ユウキ、馬に乗ったことある？ 馬は速いけど、手綱なしじゃどこに行くかわからない。CLAUDE.md っていう手綱があるの。そこから始めよう」

こうしてユウキのハーネスエンジニアリングの旅が始まった。

次の章では、その最初の一歩——CLAUDE.md の設計——に踏み込む。