TDDD

(TODO Driven Development)

TDDD（TODO Driven Development）は、特定時代の生成AI環境における実務的な開発運転方法の記録です。

Contents

Why TDDD

なぜ TDDD が必要なのか

TDDD（TODO Driven Development）は、
新しい開発技法を発明するために生まれたものではない。

すでに起きてしまった変化に、開発プロセスを追いつかせるため
に生まれた。

実装の死

生成AIの登場により、
「実装を書くこと」はもはや開発の中核ではなくなった。

その結果、コードは 消耗品 になった。
今日書かれたコードは、
明日にはAIによって消され、書き直される前提で存在している。

それでもなお、システムは動き続けなければならない。

変わったのは「How」ではない

この変化は、
「どう書くか（How）」が変わった話ではない。

本質的に変わったのは、
「どこで止めるか（Where）」
である。

整備士は飛行機から降りる

かつてエンジニアは、

つまり、飛行中も機内に同乗する存在だった。
しかし、生成AIによって実装が自動化されると、
エンジニアは次第に機内から降ろされる。

離陸前に設計と判断を済ませ、
離陸後は「触れない」ことが前提になる。

これは選択ではない。
構造的に起きている変化である。

問題は「誰が操縦しているか」ではない

よくある議論はこうだ。

しかし、本当の問題はそこではない。

操縦桿がどこにあるか
そして
操縦の判断がどこに記録されているか
である。

コードは判断を保持できない

コードは実装を保持するが、
判断を保持しない。

それらはコメントや設計書に断片的に残るが、
コードそのものは判断の媒体にならない。

生成AI時代において、
コードに判断を預けることは危険である。

TODO は判断を保持できる

TODO は、
未来の実装に対する 判断のメッセージ である。

TODO は、
実装が消えても消えない。

実装が書き換わっても、
TODO に残された判断は次の実装に引き継がれる。

TDDD がやっていること

TDDD は単純である。

これだけである。

なぜループなのか

生成AIは一度で正解に到達しない。人間も同じである。

だから TDDD は、
一発で完成させることを目指さない。

判断を更新し続けるループとして開発を捉える。

なぜ境界が重要なのか

生成AIは、
境界が曖昧な場所で必ず暴れる。

これを明示しない限り、
AIは善意で越境する。

TDDD では、
境界を TODO の形で明示する。

境界は設計書ではなく、
実行前提の判断として TODO に置かれる。

なぜ年次版なのか

TDDD は現在のツール構成に依存している。

これらが統合されれば、
TODO生成と実装は一体化するだろう。

その時、TDDD の形も変わる。
だからこれは永遠の理論ではない。
その年の現実に合わせた運転方法である。

TDDD が置きたいもの、置かないもの

TDDD は思想を最小に保つ。

これらは TDDD の外側 に置く。
それらを Loop A に載せることはできるが、
TDDD 自体はそれを強制しない。

まとめ

実装はもう主役ではない。

残るのは、

TDDD は、
それらを TODO という形で未来に渡すための
最小の開発ループである。

コードが消えても、
TODO が残っていれば、
開発は続けられる。

TDDD 応用編（2026）

これは何か

このドキュメントは、TDDD を 実務で安定して回すための具体手順 を示します。
設計理論は最小限に留め、「どう使えば事故らないか」を中心に書きます。

応用編で前提にする2つの理由

設計の理由：再作成前提であることが、価値の継続につながる。

手段の理由：対話型生成AIと自動生成AIには、まだ明確な役割差がある。

TDDD 応用編は、この2点だけを前提に組み立てます。

TDDD 応用編の全体サイクル

  1. 対話型生成AIで TODO を作る
  2. 自動生成AIに TODO を実行させる
  3. レビューして TODO に戻す

これを繰り返します。

1. 対話型生成AIで TODO を作る

ここが 最重要工程 です。

1-1. 仕様を把握させる

目的は「正解を出すこと」ではなく、前提を揃えること です。

1-2. AIが暴れてよい境界を決める

必ず次を明示します。

例：

- 外部 API には触らない
- DB スキーマは変更しない
- ファイル I/O は行わない

1-3. 境界内の TODO を作らせる

対話型AIに、こう頼みます。
この境界の中だけで、実装用 TODO を作ってください。
やらないことも含めて明示してください。

1-4. 必要なら YAML を出させる

コードより先に 構造だけ を YAML にします。

成果物：

todo/
  ├─ TODO.md
  └─ schema.yaml（必要な場合）

2. 自動生成AIに TODO を実行させる

ここでは 判断させない。

2-1. 大きなシステムは「1境界1PJ」

これは設計思想ではなく、AIの認知限界への対策です。

2-2. TODO フォルダを唯一の根拠にする

自動生成AIには、必ずこう指示します。
todo フォルダの内容のみを根拠に、xx言語で実装してください。
TODO に書かれていないことは実装しないでください。

2-3. おかしな動きが出たら「テストを TODO にする」

例：

手順：

  1. 本人による動作確認
  2. 実行する
  3. 期待と違う点を確認する
  4. 修正は次工程で行う

3. レビューと再TODO化

3-1. 可能なら別の自動生成AIでリファクタリング

※ 人間と違う観点でテストを増やすことには、あまり意味はありません。

3-2. 最初に TODO を作った対話型AIにレビューさせる

3-3. フィードバックはすべて TODO に戻す

  1. TODO を作る
  2. 実装する
  3. 確認する
  4. TODO を直す

TDDD は一発完成を目指しません。

境界をつなげるテクニック（大規模化の入口）

TDDD は境界単体では小さいが、疎結合にすれば拡張できます。

使えるテクニック例：

こうすると：

応用編の限界

これらには別の設計が必要です。

まとめ

TDDD 応用編は、再作成され続けることを前提にした実務的な開発ループです。

応用編補足：11の境界という「見えない地図」

TDDD 応用編で最も重要なのは、「どこで区切るか」 を誤らないことです。

その判断を助けるために、VCDesign / VC-AD では AIが見落としがちな「コードの外側の制約」を 11の境界 として整理しています。

これらはコード（As Code）として表現しにくく、AIが最も暴れやすい領域です。

11の境界の全体像

11の境界は、性質ごとに4つのグループに分かれます。

Group 1：変えられない前提（Context）

設計で解決しようとしてはいけない境界

  1. 物理・現場制約
  2. 組織・境界
  3. ガバナンス

例：

TDDDでの扱い

Group 2：選ぶだけのリソース（Resource）

設計ではなく「選択」の結果で決まる境界

  1. 実行基盤
  2. ネットワーク
  3. プラットフォーム

例：

TDDDでの扱い

Group 3：守るべき品質標準（Standard）

AIが勝手に壊してはいけない境界

  1. 信頼性（SRE）
  2. セキュリティ
  3. 可観測性

例：

TDDDでの扱い

Group 4：VC-ADの主戦場（Core Domain）

正解がなく、意思決定しか存在しない境界

  1. 分散の本質
  2. データ意味論

例：

TDDDでの扱い

ここは AIが最も苦手な領域 であり、 TDDD 応用編で最も丁寧に扱う必要があります。

応用編での実践的な使い方

境界分割のチェック

1つの境界で PJ / TODO を切る前に、次を確認します。

混ざっていたら 分割する。

境界をつなげるときの原則（疎結合）

これにより、TDDD を 大規模システムにも適用可能 にできます。

TDDDと11の境界の関係

応用編では、地図を見ながら運転する ところまでを扱います。

まとめ

これができれば、TDDD は小規模だけでなく 現実の大規模システムにも拡張できる。

Resources