バイブコーディングに疲れた？原因はCursorじゃなかった。KDDIが示した「設計80%」への逆転法

Cursor（カーソル）を導入して数週間。コードは確かに早く書けるようになった。Claude（クロード） Code（クロードコード）も試した。「自分でも業務ツールを作れる」という感覚が戻ってきた。

でも、なんか疲れている。

以前より忙しくなった気がする。AIが生成したコードのデバッグに時間をとられる。「動くはずなのに動かない」が増えた。これって、私だけなのかな。

私はCSからバイブコーディングで開発に戻ってきた元エンジニアだ。10年以上のブランクを経て、AIと一緒にコードを書く楽しさを再発見した。だからこそ、この「疲弊」の感覚が気になった。調べていくと、これは個人の問題じゃないとわかった。

この記事では、バイブコーディング疲弊の正体と、KDDIが実践している処方箋を紹介する。先に結論を言う。問題はCursorでもClaude Codeでもない。設計プロセスの方にある。

「AIで速くなったはずなのに、なぜか疲れている」の正体

Cursorを入れた直後の1週間は感動する。補完の精度が高い。チャットで「こういう機能が欲しい」と話すとコードを書いてくれる。業務ツールの試作が1日でできるようになる。

ところが2週間目あたりから雲行きが変わってくる。

AIが生成したコードが意図通りに動かないことが増えてくる。エラーをAIに投げると直してくれるが、また別の場所で問題が出てくる。コードの全体像が見えなくなって、「何がどこでつながっているか」の把握に時間がかかる。

そして気づくと、バイブコーディングを始める前より忙しくなっている。

この感覚、実はデータが証明してくれた。

Harness社が2026年2月に実施した調査（米英独仏印の開発者700名）によると、AIヘビーユーザーの96%が夜間・週末の緊急対応に追われており、開発負荷が増していることが示された。69%が「AI生成コードのデプロイで問題が頻繁に発生している」と回答した。AIによるコード生成は確かに速くなった。ただし下流のDevOps（開発→テスト→デプロイの一連フロー）プロセスが追いつけていない。これが調査の結論だ。

コードの品質面でも問題が起きている。GitClearの2025年レポートでは、2.11億行のコードを分析した結果、コードチャーン（一度書いたコードが短期間で書き直される比率）の増加傾向が報告されている。重複コードブロックの急増も指摘されており、AIによるコード量の増加が保守コストを押し上げる構造が見えてきた。

「書いた量は増えたが、直す量も増えた」。この状況は、決して個人の問題ではない。

# バイブコーディング疲弊の悪循環

要件がふわっとしたまま → AIにコード生成を依頼
    ↓
動くが、意図と少しずれたコードが生成される
    ↓
手で修正 → また少しずれる → また修正
    ↓
コード全体の理解が追いつかなくなる
    ↓
デバッグが長期化 → 疲弊

この循環、心当たりがある人は多いんじゃないかと思う。

「AIを使うと19%遅くなる」というデータが示すこと

2025年にMETR（機械学習評価のベンチマーク研究機関）が実施したRCT（無作為比較試験、Randomized Controlled Trial）で、衝撃的な結果が発表された。

METRの論文（arxiv.org）によると、熟練した開発者16名が246タスクを「AIあり」と「AIなし」でそれぞれ取り組んだ。結果、AI使用時は19%遅いという数値が出た。

開発者自身の事前予測は「24%速くなる」だった。予測と実測の間に43ポイントのギャップがある。

「なぜ？」と思う人も多いはずだ。

注意点として、この実験の対象は2.2万スター・100万行超の大規模OSSリポジトリだった。日常のスクリプト作成や小規模プロジェクトとは条件が違う。ただ、「大規模な既存コードベースに対してはAIが必ずしも速くない」という事実は参考になる。

この研究が示しているのは「AIが使えない」ということじゃない。「AIを入れれば自動的に速くなる」という前提が危ういということだ。

CSの仕事に長く関わってきた経験から言うと、ツールを入れただけでプロセスが改善した事例はほとんどない。ツールは、プロセスを変えるための手段に過ぎない。開発でも同じことが起きている。

METR RCT実験の結果グラフ — AI使用時と非使用時の作業時間比較

疲弊の本当の原因は「プロセスの未整備」

KDDIのアジャイル開発センター（KAG、KDDIの社内ソフトウェア開発部門）が2026年3月に発表したレポートが、この問題の核心を突いた。

KAG Tech Noteの記事によると、バイブコーディング疲弊の原因を「ツールの品質ではなく、組織のプロセスと設計力の欠如だ」と結論づけている。

従来の開発フロー、つまり「とりあえず作って直す」スタイルでは、設計に使う時間は全体の2割程度だ。実装とデバッグに8割の時間を費やす構造になっている。このフローにAIを組み込んでも、構造は変わらない。むしろAIがコードを大量に生成するぶん、「確認とデバッグ」の量が増えることさえある。

問題の本質はここにある。

AIが実装を担当してくれるようになったのに、人間側はまだ「確認とデバッグ」の役割に留まっている。

設計（=何を作るかを定義する作業）に人間が使う時間が増えていない。AIが生成したコードをひたすら確認するだけでは、仕事の質感が変わらない。

PeopleX（HRプラットフォームのスタートアップ）の事例が参考になる。PR TIMESの発表によると、同社は全エンジニアにCursor・Claude Code・GitHub Copilot（ギットハブコパイロット）等を支給した。その結果、全プロダクトの新規実装の約80%がAI生成コードになった。成功の鍵は設計ドキュメントの共有方法だ。CursorにプロジェクトをまたいだMDファイル（マークダウン形式のドキュメント）を横断読み込みさせる仕組みを整えた。「何を作るか」の定義が先にあることで、AIが文脈を保ちながらコードを生成できた。

「書く前に設計する」という当たり前のことが、バイブコーディングの文脈では省略されやすい。

開発フローの比較 — 設計と実装の比率

KDDIが辿り着いた「仕様駆動開発（SDD）」という処方箋

KAGが2025年9月から本格導入した手法が「仕様駆動開発」、英語でSpec-Driven Development（SDD）だ。

SDDの考え方自体はシンプルだ。コードを書く前に仕様書を書く。 ただ、従来の「設計書を書いてから実装」とは少し違う。AIが仕様書の作成を手伝い、その仕様書をもとにAIがコードを生成するという流れ全体を構造化している。

KAGが現在採用しているのは「cc-sdd」という国産OSS（オープンソースソフトウェア、誰でも無料で使える公開コード）だ。Qiitaの解説記事によると、Claude Code・Cursor・Gemini（ジェミニ） CLIのいずれでも動作する。

KAGはもともとAWS Kiro（AWSのSDD支援ツール、2025年11月に正式版リリース）を検証していた。その後、日本語対応と柔軟性の観点でcc-sddに移行した経緯がある。

SDD導入後、KAGの開発フローは「設計2割:実装8割」から**「設計8割:実装2割」**に逆転したという。テストカバレッジも向上した。AIが膨大な異常パターン（エッジケース）をあらかじめ考慮した仕様書を作るので、テストコードの網羅性が上がるという理由だ。

この話を聞いて、CSの仕事と似ているなと思った。顧客から「なんとなく困っている」と相談されたとき、すぐ解決策を出そうとすると的外れになる。まず「何が問題か」を整理してから動く。開発でも同じ構造だった。

Thoughtworksが2025年のAI支援エンジニアリングプラクティスとしてSDDを取り上げた記事によると、SDDは「バイブモード（まずチャット）」vs「スペックモード（まず計画）」の2択として認知されつつある。バイブモードが合う場面もある。ただ、継続してメンテナンスするプロダクトや、チームで共有するコードには、スペックモードの方が向いている。

cc-sddで今日から始める「設計80%:実装20%」の実践

cc-sddを実際に試すための流れを書いておく。Claude CodeかCursorが入っている環境があれば動かせる。

# cc-sddのインストール（Node.jsが必要）
npm install -g cc-sdd

# プロジェクトの初期化
cc-sdd init

# 要件を自然言語で入力してPLAN.mdを生成
cc-sdd plan "Slackの特定チャンネルをモニタリングして、
             キーワードが含まれるメッセージが来たら
             メール通知するツールを作りたい"

cc-sdd planを実行すると、AIが要件を分解してPLAN.md（全体設計書）を生成する。この段階では動くコードは一行も存在しない。代わりに「何を作るか」の設計書ができている。

# PLAN.mdをレビューしてから、機能単位でSPECを生成
cc-sdd spec --feature slack-monitor

# SPEC.mdが生成される（機能の詳細仕様書）
# 入力・出力・エラーハンドリング・エッジケースを列挙

# 仕様書が完成したらコード生成
cc-sdd implement --spec slack-monitor

# テストコードも自動生成
cc-sdd test --spec slack-monitor

このフローで一番効いたのは「エラーハンドリングとエッジケースをAIが先に考えてくれる」点だ。バイブコーディングで詰まる原因の多くは「想定外のケースで止まる」ことだった。仕様書に書いてあれば、AIは最初からそのケースを含めたコードを生成する。

デバッグが激減した。

ひとつ正直に言っておく。cc-sddはまだ成長中のOSSで、ドキュメントが英語中心という点がある。詰まったときはQiitaの解説記事が参考になる。慣れるまでは、cc-sddを無理に使わなくていい。「まずPLAN.mdを自分で書いてからAIに実装させる」という手順だけ真似するのでも効果は出る。ツールより習慣の方が大事だ。

なお、英語圏ではGitHubが公式で提供する「GitHub Spec Kit」も選択肢になっている。AWS KiroはCloudインフラと連携する用途で強みがある。自分の環境に合ったものを選べばいい。

cc-sddワークフロー図 — 5ステップのフローチャート

「自分のチームは今どこで詰まっているか」チェックリスト

「SDDの考え方はわかったけど、自分のケースに当てはまるかわからない」という人向けに、フェーズ別の診断チェックリストを作った。

実装フェーズで詰まっているパターン

AIが生成したコードを、毎回大幅に手修正している
エラーメッセージをそのままAIに貼り付けるのが日課になっている
「とりあえず動かしてから考える」が口癖になっている
コードの全体像が誰もわかっていない状態が続いている

このパターンの場合、「仕様書を先に書く」フェーズがそもそも存在していない可能性が高い。cc-sddかAWS Kiroを試す価値がある。

設計フェーズで詰まっているパターン

「何を作るか」の定義を、チャットでAIと話しながら決めている
機能の境界線が曖昧なまま実装が始まっている
仕様書やドキュメントが後から（または書かれないまま）になっている
AIへの依頼が毎回長い説明文になっている

このパターンは、設計の時間を意識的に増やすことで解決する。プロダクトマネジャーやCSの仕事に近い。「要件を整理すること」がエンジニアリングの一部に入っていなかった人には、このシフトが特に効く。

デプロイ・QAフェーズで詰まっているパターン

テストコードを書かずに本番デプロイしている
AI生成コードのレビューが省略されている
ローカルで動いたのに本番で動かない、が繰り返されている
AI生成コードの意図がチームで共有されていない

このパターンはHarness調査が指摘する「コード生成は速くなったがDevOpsプロセスが追いついていない」構造そのものだ。テストコードもAIに生成させる習慣を取り入れると、ここが一気に改善される。

チェックリストを見ると気づくことがある。「AIのせい」で詰まっているケースが実は少ない。ほとんどは人間側のプロセスから来ている。

これはCSの仕事で10年間ずっと見てきた構造と同じだ。ツールを入れると問題が解決すると思いがちだが、使い方のプロセスが変わらないと状況は変わらない。

まとめ: ツールより先にプロセスを整える

バイブコーディングの疲弊を引き起こしているのは、ツールの限界ではなくプロセスの未整備だ。

METR RCTで示されたように、AIを使うだけで自動的に速くなるわけじゃない。コードの量が増えても「正しいものを作るための設計」が省略されていると、デバッグと修正のループに入る。

KDDIが示した「設計8割:実装2割」への逆転は、特別な技術を必要としない。「コードを書く前に仕様書を作る」という習慣の変更だ。cc-sddはその習慣を始めるための入口として機能する。

完璧な仕様書を書く必要はない。AIに「まずPLAN.mdを作って」と頼むだけでいい。その30分の投資が、後の数時間のデバッグを消してくれる。

バイブコーディングが本来楽しいものだったことを、思い出してほしい。

画像ディレクティブ一覧

#	場所	type	説明
1	記事冒頭	eyecatch	疲れたエンジニアがPCの前で頭を抱えている
2	H2「19%遅くなる」後	diagram	METR RCT結果グラフ（AI使用時vs非使用時の作業時間比較）
3	H2「疲弊の正体」後	comparison	従来フロー（設計2割:実装8割）vsSDD（設計8割:実装2割）比較図
4	H2「cc-sdd実践」内	diagram	cc-sddワークフロー図（5ステップフローチャート）

合計: 4枚

バイブコーディングに疲れた？ 原因はCursorじゃなかった。KDDIが示した「設計80%」への逆転法