CCC事例でTDDDが貢献できる可能性があるポイント

AnthropicのCCC（Claude’s C Compiler）は、
「AIエージェントを長時間自律実行させると何が起きるか」 を実証した極めて重要な実験である。
そこに私が実践しているTDDD開発手法が貢献できた可能性を残す。

0. 前提：CCCの偉大な実験とTDDDの立ち位置

AnthropicのCCC（Claude’s C Compiler）は、
「AIエージェントを長時間自律実行させると何が起きるか」 を実証した極めて重要な実験である。
TDDDは、この実験を否定するものではない。

TDDDが問うのは次の一点である：

その実験で生まれた「判断」は、どこに保存されているか？

CCCは能力を証明した。
TDDDは、その能力の過程で生まれた判断を「再利用可能な形に固定する」視点を提供する。

1. 判断の所在：環境ガードレール型 vs 成果物固定型

CCCの構造（環境ガードレール型）

• 越境はコンテナ隔離・ネット遮断・テストで抑制
• 判断はエージェントの試行錯誤の中に存在
• コードが書き直されると判断履歴は消える可能性がある

例：
stddef.h 探索順序は仕様ではなく「実装結果」として存在していた。

---

TDDDの構造（成果物固定型）

• 実装前に「境界（Where to stop）」をTODOとして明示
• AIは境界内だけを実装
• 境界変更はTODO更新でのみ行う

効果：

• 探索順序は推測ではなく「仕様」となる
• AIが入れ替わっても判断は保持される
• 再生成しても同じ前提が再現される

2. 11の境界による低レイヤ封じ込め

CCC事例をTDDDの境界地図にマッピングすると、
AIが暴れやすい低レイヤが明確になる。

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

追加項目：

• ツールチェーンのバージョン
• sysroot探索規則
• 標準ヘッダの責務分離
• 未知フラグの扱い

強化点：
未知フラグを「黙殺」ではなく、

unknown_flag_policy: error

とTODOで固定することで、
静かな性能劣化や互換性劣化を未然に防げる。

---

Group 3: Standard（守るべき制約）

追加項目：

• ABI（呼出規約）
• バイナリサイズ制限（例：32KB）
• 最適化レベルの意味

強化点：

boundary_id: B-SIZE-CONSTRAINT
text_segment_max: 32768

と契約化することで、
制約違反は偶発的事故ではなく「契約違反」になる。

---

Group 4: Core Domain（正解のない判断）

追加項目：

• _Atomic のサポート範囲

強化点：

atomic_support: unsupported
build_policy: fail_on_usage

と明示することで、
AIの「善意の越境」を防止する。

3. 性能を契約として扱う

CCCの課題の一つは性能である。
TDDDでは、性能は「結果」ではなく「境界契約」になる。

性能契約の例

baseline: gcc -O0
max_runtime_multiplier: 2.0
max_size_multiplier: 1.3

ループ構造

• Loop Cで計測
• 未達ならコード修正ではなくTODO更新
• 最適化手法の選択理由を履歴化

ここで重要なのは：
性能改善もまた「判断」であり、コードではなくTODOに保存されるべきである

4. 結論：TDDDが提供する「資産」の定義

TDDDはAIを賢くする技術ではない。
TDDDが提供する資産とは何か？

1. 判断の外部化
判断を「環境」や「一時的な実装」ではなく、
人間が読める成果物（TODO）に固定する。

2. 契約としての境界
境界違反をバグではなく「契約違反」として扱う。

3. 知見の圧縮
CCCのような大規模実験で得られた意思決定を、
再利用可能なTODO形式へと圧縮する。

最終定義

TDDDはAIを賢くする方法ではない。
判断を残す場所を設計し、
開発を「実装の反復」から「判断のループ」へと再定義する運転方法である。