「とりあえず動くアプリ」は、
なぜ数日で壊れるのか。

バグとは、期待される動作と実際の動作のずれのことです。ひと口にバグと言っても、生まれ方は3通りに分かれます。どれなのかが分かれば、どこを直せばいいかも決まります。下のタブを押して切り替えてください。

多くの開発者は、バグが出たとき「コードのどこが間違っているか」だけを探します。この3分類を知っていれば、原因を効率よく特定できます。AGIテスト駆動開発では、Phase 1 の要件定義、Phase 2 の設計、Phase 6 の Docker 環境構築という3段階で、3種類のバグを体系的に防ぎます。

テスト駆動開発（TDD / Test-Driven Development）は Kent Beck が提唱した作り方です。正しく動くと確かめた部品を積み上げれば、正しく動くアプリになる、という考え方に立っています。下のボタンで1段ずつ進めてください。

テスト駆動開発の4つの利点

それでも普及しなかった理由

利点は広く知られています。それでも実際にやっているチームは多くありません。最大の理由はコストです。

これらの障壁が普及を阻んできました。AGI の登場で、この状況が変わりつつあります。

バイブコーディング（Vibe Coding）とは、AIに自然言語で指示を出し、その場の雰囲気（バイブ）でアプリを組み立てる作り方のことです。2024年後半から急速に広まりました。プログラミングの民主化という点では画期的です。

「Todoアプリを作って」「ログイン機能を追加して」「デザインをモダンにして」。こうした日本語の指示だけで、見た目のよいアプリが数分で出てきます。経験が無くても、思いつきをすぐ形にできる時代になりました。

典型的な流れと、そこに無いもの

「速い、作れる」の先にある崩壊

1. 1ユーザーが増えるにつれて、エッジケースのバグが次々に報告される
2. 2バグを直そうとすると、別の箇所が壊れる（回帰バグ）
3. 3影響範囲を確認する手段が無いので、直すたびに新しいバグが出るモグラ叩き状態になる
4. 4コードベースが複雑になりすぎて誰も直せなくなり、プロジェクトが放棄される

2024年から2025年にかけて、この作り方で生まれたサービスが次々公開され、次々消えていきました。「一瞬にして崩壊する」という言い方は、残念ながら多くのプロジェクトの現実をそのまま表しています。

バイブコーディングが悪いのではありません。問題は、そのやり方に品質保証の仕組みが組み込まれていないことです。

AGIテスト駆動開発は、バイブコーディングの「速さ」と「手軽さ」を保ったまま、TDD の「品質保証」を両立させます。テスト設計・テストコード生成・テスト実行を AGI が自動で行うので、指示を出す側の感覚は今までどおりのまま、テスト付きのコードが返ってきます。

回帰テスト（かいきテスト / Regression Test）とは、コードを変えた後に、これまで動いていた機能がちゃんと動き続けているかを確かめるテストのことです。新しい機能を足したり、バグを直したりしたときに、その変更が他の場所に悪さをしていないかを検証します。

たとえばタスク管理アプリに「タスクの優先度設定」を足したとします。この後で「タスク作成」「タスク編集」「タスク削除」「締め切り通知」がすべて今までどおり動くかを確かめるのが、回帰テストです。

直すたびに別の場所が壊れる、を見る

機能Aを直すと機能Bが壊れ、Bを直すとCが壊れる。この連鎖を「デグレード（degradation）」と呼びます。下の2つのボタンで、回帰テストがある場合と無い場合を見比べてください。

なぜ実施されないのか

結論から言えば、ほとんどのエンジニアは回帰テストを実施していません。理由は3つです。

1. 時間がかかる手作業で全機能をテストすると、小規模なアプリでも数時間、中規模なら数日かかります。毎回の変更でこれをやるのは現実的ではありません。
2. 自動テストが整備されていない効率よくやるには自動テストの一式が要ります。しかし前章のとおり、テストコードを書くコストが障壁になり、多くのプロジェクトでは揃っていません。
3. 変更の影響範囲が把握できない「この関数を直したらどこに影響するのか」を正確に掴むのは、コードが大きくなるほど難しくなります。範囲が分からなければ何をテストすべきかも分からず、事実上できません。

AGI が解決すること

AGI（Artificial General Intelligence / 汎用人工知能）とは、特定の作業に特化するのではなく、人間のように幅広い知的作業をこなせるAIのことです。いまの大規模言語モデル（LLM）は「狭いAI（Narrow AI）」に分類されますが、AGIレベルのシステムは、複数の領域にまたがる推論・計画・学習を統合して行えます。

ここで言う AGI が持つ能力

• 自然言語で書かれた要件を理解し、技術的な設計に変換できる
• 設計にもとづいてテストケースを自動生成できる
• テストケースに合格する本体のコードを実装できる
• 変更が加えられたときに、影響範囲を分析して回帰テストを実行できる
• これらすべてを、一貫した文脈（コンテキスト）を保ちながら遂行できる

「高速なレスポンス」がずれていく

人間のチームでテスト駆動開発をやるとき、最大の課題は一貫性の維持です。要件定義を書くプロダクトマネージャー、設計するアーキテクト、テストを設計するQAエンジニア、実装するプログラマーは、通常は別々の人間です。それぞれ違う解釈、違う前提、違う優先順位を持つので、工程の間で認識のずれが必ず起きます。

環境の用意

AGIテスト駆動開発を実践するための道具として ccagi-sdk が提供されています。手順は3つです。公式サイトからインストーラーを取得する。VS Code（Visual Studio Code）にAGI拡張機能をインストールする。プロジェクトの初期設定を行い、AGIがプロジェクトの構造を認識できる状態にする。

VS Code を使うのは、拡張機能が豊富で、ターミナルが統合されているためです。AGIとのやり取りが同じ画面の中で完結します。AGIへの指示は、VS Code のターミナルかコマンドパレットから出します。

導入の手順は「はじめ方」で細かく書いています

ここからが実務です。Phase 1 から Phase 8 まで、各フェーズで必要な書類、AGIへの具体的な指示、レビューで見るところを並べます。枠で囲った日本語が、実際にAGIへ言う言葉です。そのままコピーして使えます。フェーズの帯から選んでください。

コードを書く前に、これだけの書類を作ります。一見すると面倒に思えますが、それぞれに明確な理由があります。人間が手作業で全部作るのは膨大な労力ですが、AGIが自動生成するので負担は最小限です。

Phase 1 で3つ、Phase 2 で6つ、Phase 3 で1つ、Phase 8 で1つ。合計 11 の書類が、この作り方の土台になります。

バグの修正コストは、発見が遅れるほど指数関数的に増えます。要件定義の段階で見つけたバグの修正コストを1とすると、次のようになる、というのがソフトウェア工学の教科書で紹介される定説です。