はじめに
こんにちは。本業はシステムエンジニア／プロジェクトマネージャー（PM歴20年）です。この20年、インフラ系はプロですが、アプリ開発はど素人です。そんな私が2026年1月から趣味でiPhoneアプリ開発を始め、約半年で14本をApp Storeにリリースしました（資格対策アプリでは世界初・国内初のものもあります）。開発の主力は Claude Cowork で、サブエージェントによるマルチエージェント構成を使っています。
最初、私は完全な「バイブコーディング」で作っていました。そして途中で「AI駆動開発（spec駆動）」に舵を切りました。この記事は、その失敗込みの実体験です。ポエムにならないよう、実際に使っているドキュメント運用のサンプルも載せます。
開示: 本文で例に出すアプリは、いずれも私自身が開発したものです。宣伝が目的ではなく「この方法で作った実例」として挙げています。
面白い事実：「バイブコーディング」の生みの親も、もう卒業している
「バイブコーディング（vibe coding）」という言葉は、2025年2月に Andrej Karpathy（OpenAI共同創業者・元Tesla AI責任者）が名付けました。原文のニュアンスは「vibes に身を任せ、コードの存在すら忘れる」。差分（diff）も読まずAIの変更を受け入れ、エラーはそのまま貼って直させる——という開発スタイルです（Vibe coding - Wikipedia）。
ところが2026年、そのKarpathy自身が「vibe coding はもう時代遅れ（passé）」と言い、より監督と精査を伴うエージェント開発が標準になりつつある、と語っています（The New Stack）。
生みの親が1年で乗り換えた——これがこの記事のテーマそのものです。
用語整理：違いは「ガバナンス」
まず言葉を揃えます。
-
バイブコーディング：自然言語で"雰囲気"を伝え、AIが大半のコードを生成。設計・仕様・レビューは最小限（Google Cloud）。
-
AI駆動開発：AIを開発ライフサイクル全体（企画→要件→設計→実装→テスト→運用）に組み込む上位概念。
-
spec駆動開発（Spec-Driven Development）：仕様（spec）を一次成果物にして、設計・実装・テストを仕様から駆動する規律。
一言でいうと、両者の違いは ガバナンス、つまり「設計・仕様・レビューが有るか無いか」です。
私のバイブコーディング時代（2026年1〜2月）
最初は左にGemini・右にXcodeを並べ、生成されたコードをひたすらコピペしていました。純度100%のバイブコーディングです。結果、デグレード（先祖返り）が頻発しました。直したはずの箇所が次の生成で壊れる、の繰り返しです。
プロンプトを見直し、毎回最新コードを共有するようにしてデグレは減り、その後 VSCode ＋ コードアシスト、さらに Claude Cowork へ切り替えて生産性は激変しました。ただし——この時点でもまだバイブコーディングでした。最初の3本（Calc+ / Maker's Note / MyFanClub）は、この流儀で世に出ています。
転機：ユーザーが増えて「怖く」なった（2026年3月〜）
アプリの利用者が増え始めた頃、バイブの怖さに気づきます。AIが、こちらの意図と無関係にデータ構造（スキーマ）を勝手に変えてしまうリスクです。個人の実験なら笑い話ですが、すでに使ってくれているユーザーがいると、これは既存データの破壊に直結します。
そこで私は、これまで作ったアプリを一度リバースエンジニアリングし、ソースコードから設計書を復元しました。そして以降は「設計書を直す → コーディング」の順を必ず守るようにしました。行き当たりばったりの生成をやめた瞬間です。
AI駆動開発（spec駆動）への移行
7作目のPMP問題集アプリから、本格的にspec駆動へ移行しました。流れは 企画制作 → 要件定義 → 設計 → コーディング → テスト。
Cowork上では 契約駆動開発 を採用しています。CLAUDE.md をプロジェクトルールの唯一の正本にし、Main Claude がオーケストレーターを務め、実装・レビュー・制作を専用サブエージェントに分担させます（例：実装サブエージェント が実装＋自己チェック、レビューサブエージェント が並行安全性やアーキ準拠の品質ゲート）。Cowork自体も「アプリ開発／出題校正／販売戦略」のセッションに分け、文脈のノイズを避けています。
効果は明確でした。当初6〜9ヶ月と見積もっていた実装＋1,440問の制作を、マルチエージェントの並列処理で2週間以内に完走できました。勢いだけのバイブでは、この規模と品質は両立できません。
【本題】AIに任せて事故らないための「ドキュメント戦略」
ここがこの記事で一番伝えたい部分です。AI駆動開発を安定させる土台は、実はコードよりもドキュメントにあります。
まず、ドキュメントも"全部AIに書かせる"。人間はレビュアーに徹する
要件定義書も設計書も、まずAIに書かせます。人間はそれをチェックし、AIに直させる——この往復を回します。ここで大事なのが品質の考え方です。
-
AIの初稿は、最初から100点は出ません。体感で70点くらいのこともあります。
-
その70点の設計書のまま実装へ進むと、手戻りが雪だるま式に膨らみます（設計の穴がコード全体へ波及するため）。
-
だから、実装に入る前に設計書の70点を1点でも上げます。人がレビュー → AIが修正 → また見る、を繰り返す。
-
そして「90点くらい取れたな」と思えたら次工程へ進みます。100点は待ちません。
なぜ100点を待たないのか。理由は2つあります。70→90点は比較的すぐ到達できますが、90→100点は非常に時間がかかる。しかも、その時「100点だ」と思っていたものが、あとで見ると実はそうではない——というのが現実です。机上で100点は作れないのです。
だから90点で前に進み、MVPを出してから、アジャイル開発で100点に近づけていく。実ユーザーの反応という"答え合わせ"がある状態で磨くほうが、はるかに確実です。
合言葉は「設計書の1点は、実装の100点に化ける」。上流のドキュメントで品質を作り込むほど、下流の手戻りは減ります。これが"いきなり実装"のバイブコーディングとの決定的な差です。
そして、AIに安く・速く・壊さず書かせるための土台が、次の3つのドキュメント運用です。
原則1: ドキュメントはMarkdownに統一する
最近のAIはExcel・Word・PowerPointも読めます。ですが、リッチ形式はトークンを大量に消費し、Gitの差分も追えません。仕様書・設計書・規約はすべて .md で持ちます。差分レビューができ、AIも低コストで読めます。既存のdocx/xlsx/pptxは、mdへ変換して正本化します。
原則2: ドキュメント管理体系を「索引（index）」に集約する
ファイルが増えると、AIは「どこに何があるか」を探すだけでトークンと時間を浪費します。そこで、各ファイルのパス・目的・AIの使い方を1枚の索引にサマライズし、AIには「まずこの索引を読め。関連ファイルだけ参照しろ（全読みするな）」と指示します。
# ドキュメント索引（docs/00_index.md）
| # | パス | 目的 | 主な読者 / AIの使い方 |
|------|----------------------------|----------------------------|----------------------|
| 01 | design/01_企画書.md | 市場・コンセプト・仕様・ロードマップ | PM。まず全体像 |
| 02-1 | design/02-1_アーキ.md | レイヤ構成・並行性・主要プロトコル | 実装前に必読 |
| 02-2 | design/02-2_データモデル.md | スキーマ / マイグレーション | スキーマ変更は必ずここを先に更新 |
| 02-3 | design/02-3_画面UI.md | 画面仕様（唯一の正本） | UI実装の基準 |
| 02-5 | design/02-5_テスト戦略.md | テスト / CI / 品質ゲート | QA・実装担当 |
| — | CLAUDE.md | 開発規約・禁止事項 | 全作業の前提（デグレ防止） |
これは汎用化した例ですが、私の実プロジェクト（PMP問題集アプリ）では、01企画書 / 02-1アーキ / 02-2データモデル / 02-3画面UI / 02-4多言語 / 02-5テスト戦略 / 02-6運用・セキュリティ / 02-7出題品質保証 という番号体系に、「役割・主な読者・読む順序図・トピック別逆引き表」まで持たせています。さらに、索引を grepベースの参照運用にしたことで、Cowork起動プロンプトのトークンを約 -70% 削減できました。「AIに全部読ませない」ための地図が、この索引です。
原則3: デグレ防止などの開発規約は必ず CLAUDE.md に書く
AIは文脈が切れると過去の決定を忘れ、勝手にデータ構造やAPIを変えます。これがデグレの温床です。だから、プロジェクトの絶対ルールを CLAUDE.md（＝唯一の正本）に固定し、毎回の作業前提にします。ここが整うと、初めて「安心してAIに任せられる」状態になります。
# CLAUDE.md（プロジェクト規約・抜粋）
## 絶対ルール（デグレ防止）
- データモデル/スキーマを変更する時は、必ず docs/design/02-2_データモデル.md を
先に更新し、マイグレーション方針を書いてから実装する。
既存の永続プロパティ名を勝手に変更・削除しない。
- 公開API・関数シグネチャの破壊的変更は禁止。必要時は理由と影響範囲を残す。
- 変更は「要件 → 設計書 → 実装 → テスト」の順。設計書を飛ばした実装はしない。
- 既存の命名・アーキ（5層構成）に従う。独自の型・命名を勝手に増やさない。
## 作業の進め方
- まず docs/00_index.md を読み、関連ファイルだけを参照する（全読みしない）。
- 不明点は勝手に仮定せず、質問するか設計書に追記してから実装する。
この3点が効く理由はシンプルです。①でトークン効率、②でAIの探索コスト削減、③でデグレ防止。つまり「AIが安く・速く・壊さずに働ける」土台になります。私がバイブから脱却できた実感の中心は、まさにここにありました。
データで見る現実
主観だけでなく、数字でも裏付けがあります。Sonarの調査では、すでにコードの約42%がAI生成・AI支援とされています。一方で、2026年の複数のセキュリティ調査は、AIが生成したコードの相当な割合に既知の脆弱性が含まれる（インジェクションやXSSなど）ことを繰り返し報告しています（Veracode）。
つまり、開発者に求められるスキルは「書く（生成）」から「評価する（レビュー・方向づけ）」へ移っています。生成量が増えるほど、ガバナンス（設計・レビュー）の価値が上がる。これが、バイブから spec駆動へ寄せる合理的な理由です。
結論：どこでバイブ、どこでspec駆動か
二者択一ではありません。プロジェクトの段階に応じてガバナンスの強さを上げていくのが実践的です。
-
バイブが向く：試作・探索・使い捨てスクリプト・一人で完結する小物。速さと勢いが正義の場面。
-
spec / AI駆動が必須：ユーザーがいる／データを持つ／認証・課金・暗号化などの重要処理／チーム開発／長期保守。
私自身、最初の数本はバイブで十分でした。「ユーザーがつき始めた瞬間」が、設計書とレビューへ投資に切り替えるサインでした。そこで舵を切ったから、半年で14本を、勢いだけに頼らず出せたのだと思います。
まとめ
-
バイブコーディングは入口として最高。まず動くものを作る力は本物。
-
ただしユーザーとデータがつき始めたら、ドキュメントとレビューに投資する。
-
ドキュメントもAIに書かせ、人はレビュアーに徹する。設計書は90点で次へ進み、MVP後にアジャイルで100点に近づける。
-
土台は3点：md統一・索引に集約・CLAUDE.mdに規約。これで「AIが安く・速く・壊さず働ける」。
生みの親のカーパシー（Karpathy）ですら、1年でvibeから“監督付きのエージェント開発”へ乗り換えました。私たち実務者はなおさら、勢い（vibe）と規律（spec）を、場面で使い分けるのが良いはずです。
次回予告（#2）：「組織でAI駆動開発を回すための方法論」。個人で確立した“設計書 → 実装 → レビュー”の型を、どうやってチーム開発の型に落とし込むか——を書きます。更新に気づけるよう、フォロー・ストックしておいてもらえると嬉しいです。