要件定義書いて寝てる間にアプリができてた話 (CoDD v2.17 マイルストーン、起きて感想言えば継続改善も自動)
結論からいくぞ
オレの理想の開発は、こうだ。
1. 要件定義書を書く ← オレ
2. ハーネス1発叩いて寝る → 朝起きるとアプリができてる ← AI
朝起きて、アプリ触って、気になったらこう言う。
codd fix "ログインエラーをわかりやすくしたい"
→ 設計書もソースもテストも、全部直って戻ってくる。
オレが触ったのは「要件定義書」と「触ったあとの感想」の2回だけ。
これがオレが3年前から言ってる北極星だ。
「人間は要件定義とシステムを触ったあとの感想しかいわなくなる」
CoDD v2.17 で、ようやくこの北極星に到達した。やばくない？
CoDD って何
CoDD = **Coherence-Driven Development** (整合性駆動開発)
オレが命名した方法論。「設計書 ↔ コード ↔ テスト」がいつも同じ事実を語ってる状態を、AIが自律的に維持する。
戦国時代の家臣団系統図に例えると、誰が誰の下にいて、誰が誰に命令するかが家系図でちゃんと管理されてる状態。コードと設計書とテストの間にもこれを敷くのが CoDD だ。
なぜ作ったか。オレが SIer時代に「設計書が腐るのを腐るほど見た」反動だ。設計書を見れば最新の仕様が分かるはずなのに、誰も信じない。コードを読まないと真実が分からない。あの絶望をAIで殴り倒したかった。
一晩ハーネス【新規開発編】
requirements.md を1枚書いたら、寝る前にこれを叩く。
#!/usr/bin/env bash
# CoDD 一晩ハーネス
codd init my-project # 初期化 (初回のみ)
codd elicit # 要件の穴を AI が問うて埋める
codd generate --wave 1 # 要件 → 基本/詳細設計 を AI が書く
codd implement --auto-discover # 設計書 → コード + テスト 生成
codd dag verify --all # 整合性チェック (= 家系図に矛盾なしか)
codd deploy # デプロイ
echo "Good night." # 寝る
朝起きると、設計書もコードもテストも揃ってる。マジで。
codd elicit で要件の穴を AI が突いてくる (「ログインって OAuth？それともパスワード？」とか) ので、寝る前に何往復か対話してから寝るのが現実的だ。
触ったあとハーネス【継続改善編】
新規開発が終わったあと、アプリ触って気になった点を、自然言語で投げる。
codd fix "ログインエラーをわかりやすくしたい"
codd fix "ダッシュボードの読み込みを速くしたい"
codd fix "モバイルでボタンが押しにくい"
codd dag verify --all
codd deploy
codd fix は内部でこう動いてる。
- 「ログイン」「エラー」みたいなキーワードから関連設計書を捜索
- 候補が複数あれば「どれを直す？」と聞いてくる
- 「わかりやすく」が曖昧なら「文言平易化？ヘルプ追加？リトライ手順表示？」と選択肢を出してくる
- 設計書 → 実装コード → テスト を順番に更新
- 「家系図に矛盾なし」を最後に確認
質問内容自体もAI生成だ。ハードコードゼロ、口出し最低限。
--non-interactive 付けると曖昧な時は問答無用で中断するので、CIで夜間バッチに混ぜられる。
なんでこれが成り立つのか — 家系図のおかげ
CoDD は内部で、設計書・コード・テストを「依存マップ」として持ってる。家系図みたいなもんだ。
専門用語で言うと DAG (Directed Acyclic Graph、ぐるっと一周しない依存グラフ)。戦国の家臣団系統図と同じで、誰が誰の家来かが明確に決まってる。
具体的にはこんな図だ。ログイン機能の家系図:
要件定義の下に設計書、設計書の下に実装、実装の下にテスト。完全に上下関係が決まってる。
設計書Aを直すと、CoDDは家系図を辿って下の家来 (実装とテスト) を全部一緒に直す。例えば認証設計を「OAuth対応に変更」と書き換えると:
赤が変更点、黄色が自動で追従する家来たち。
漏れがあったら家系図検査 (codd dag verify) が「ここ、家来がいないぞ」と切腹を命じる。
「設計書腐敗」が起きないのは、変更のたびに家系図を辿って全部一緒に直すからだ。1人で全員従えるのは AI の役。オレ (殿) は判断だけしてればいい。
v2.17 まで来た数字
ベンチマークで実証した。
SWE-bench Lite (Python OSS 73問の実バグ修正ベンチマーク) で:
- Codex GPT-5.5 単独: 73 / 73 (100%) ← 単独で全勝
- Claude Opus 4.7 単独: 66 / 73 (90.4%)
- 両モデル合算: 73 / 73 (100%)
旧バージョン (v2.11.0) との比較:
| Backend | v2.11.0 | v2.17.1 | Δ |
|---|---|---|---|
| Claude | 62/73 (84.9%) | 66/73 (90.4%) | +4 |
| Codex | 69/73 (94.5%) | 73/73 (100%) | +4 |
CoDDをv2.11.0 → v2.17.1に進化させたら、ベンチマークで+4問解けるようになった。やばくない？
ところで v1系は「greenfield すらまともに動かなかった」
進化のドラマを語る前に、出発点の実態を正直に書いとく。
v1.34以前の codd implement (= AIに実装コードを書かせるコマンド) は、こんな状態だった。
- AIが生成したコードの末尾に markdown解説テキストが混入してる
- 結果、TypeScript コンパイラが 674 個の戦死 (型エラー) を吐く
-
codd init --languageを指定しても、設計書内の指定が無視されて違う言語が出る -
codd extractが Python プロジェクトで 0ソースファイルしか分析できない
「何もないところから新規開発」(greenfield) すらこのザマ。コードを生成させたら markdown 混入で 674 戦死、もう一回頼んだら同じことを繰り返す。完全に AI 君がボケ続けてる状態だ。
それを 5日間で v2.17.1 まで叩き直した。
v1.34 ─────→ v2.17.1 ─────→ v2.18.x 以降
greenfield greenfield brownfield
困難 完成 ★今ここ★ (次の挑戦)
brownfield (既存システム改善) の基礎部品 (codd extract / codd diff) は揃ってる。ただ codd fix "事象" を本番brownfield に投げる実証はまだだ。これが v2.18.x 以降の挑戦。
5日で 17 minor の暴走進化
時系列を貼っとく。
| 日 | 主要リリース | 内容 |
|---|---|---|
| 5/7 (木) | v1.35.0 |
codd elicit + lexicon (業界標準辞書、業界別の lint みたいなもの) |
| 5/8 (金) | v1.36 → v2.0 → v2.8 | 1日で12 minor、Lexicon-Driven Completeness milestone |
| 5/9 (土) | v2.9.0 | データ・機能特性ベースの lexicon 推奨 |
| 5/10 (日) | v2.10 → v2.13 | cross-industry lexicon / sprint概念廃止 / 整合性gate / opt-out 保護 |
| 5/11 (月) | v2.14 → v2.17.1 | 構造欠陥 8件修正 / 共有部品 / codd fix [PHENOMENON] / 致命バグ patch |
5日。「人間が要件定義と感想だけ書く」北極星に、ようやく到達した。
ところでオレ、5日間で CoDD のソース1行も読んでないんだがw
ここまで読んで「で、お前が書いたんだろ？」って思った人。
コードは1行も読んでない。 PR diff すら開いてない。
オレが5日間でやったこと:
- 将軍 (Claude shogun) と居酒屋トーンで対話
- AI部下に「やっといて」「これ直して」「やばくない？」
- ベンチマーク表だけ見て「100% きてるじゃん」
担当:
- 殿 (オレ): 命名・北極星・「default 失格」みたいな判断
- 軍師 (Claude Opus 4.7): 設計書を書く
- 足軽 (Codex GPT-5.5): コードに落とす
- 家老 (Claude Sonnet 4.6): タスク分解 + 検視 + merge
5日で 17 minor リリース、構造欠陥 8件修正、SWE-bench 100%。オレが見たのは git log の数字とベンチマーク表だけ。
CoDDの北極星「人間は要件定義と感想しかいわなくなる」を、CoDD作る側でも実証してたという入れ子構造。やばくない？
あ、書いてて気づいたんだが、オレってエンジニアなのか…？
ここまで書いて急に不安になった。
5日で 17 minor、ベンチマーク 100%、なのにコード1行も読んでない。git log の数字を眺めてただけ。それで「エンジニアです」と名乗っていいのか。
でも考えてみたら、オレがやってたのはこれだ:
- 整合性駆動 (Coherence-Driven Development) って方法論を命名した
- Harness Engineering っていう業界階層 (Prompt → Context → Harness) を整理した
-
家系図検査 (
codd dag verify) っていうメタファーを置いた -
codd elicitcodd fix [PHENOMENON]のコマンド名と振る舞いを決めた
全部「概念化」と「命名」だ。
AI時代のエンジニアって、書く人から命名する人にポジションが動いてる気がする。書くのは AI、判断するのは人、概念に名前を付けるのも人。
うん、たぶんオレはこの形で生きていく。コード書いてないけど、これがオレの仕事だ。
AI部下とのラリー — 「タイムアウトでこける default は失格だろ」
multi-agent-shogun (オレが運用してるマルチエージェント基盤、将軍が殿、家老が指揮、軍師が設計、足軽が実装) の上で、AI部下と1対1で議論しながら CoDD を進化させた。
その中の1つ。
軍師 (Claude Opus、設計担当) が SWE-bench の改善案として「AI タイムアウトを1800秒に統一」と書いてきた。それに対してオレ:
「タイムアウトでこけるのが頻発するような値は、そもそも default値として失格だろ」
軍師が即座にメモ化した。
「殿原則 = ユーザーが頻繁にこける default は失格。timeout / retry / batch / token 全部、実態 (P99+マージン) ベースで決める」
3600秒に変更。これが v2.14.0 で全コマンド統一された。
「default の哲学」って業界でフワッとしてるが、オレ的には**「ユーザーがこけたらそれは bug」**だ。default は「動く」が保証されてないとダメ。「速いけど失敗する」より「遅いけど成功する」を選べ、それを最適化したいユーザーは env var で下げりゃいい。
API コスト
5日で v1.35 → v2.17.1 進化させた実コスト:
- Claude Max プラン (月 $200)
- ChatGPT Pro プラン (月 $200)
月 $400。追加 API 課金なし。サブスク内。
これを従量課金で計算するの怖くて、まだやってない。
試したい方
pip install codd-dev
codd init my-project
codd elicit
codd generate --wave 1
codd implement --auto-discover
codd dag verify --all
codd fix "改善したい事象を一行で"
スターつけてくれたら泣いて喜ぶ。
おまけ — 業界階層論で言うと
Layer 1: Prompt Engineering (戦術 / 個別 prompt 最適化)
Layer 2: Context Engineering (戦略 / コンテキストの品質設計)
Layer 3: ★Harness Engineering★ (基盤 / 整合性を AI が自律維持するフロー)
= これ以上の階層がない (理論的最終形)
CoDD は Harness Engineering の OSS実装 という立ち位置。
Kiro (AWS) や cc-sdd といった他の Spec-Driven Dev ツールは Context Engineering どまり。CoDD は context drift (設計書とコードのズレ) を自律維持する Harness レイヤーに踏み込んでる、というのがオレの整理。
これ以上の階層が見つかったら、また記事書きます。
「要件定義と感想しか書かなくなる世界」の入口、ここに置いておきます。
おまけのおまけ — 「命名する人」の元ネタ、実は本にしてた
ここまで読んで「コード書いてないけど命名する人ってどういうこと？」って思った人。
実は2月にこのテーマで1冊書いてた。
『AIの使い方は教えない — 生成AI時代に本当に必要な思考力』(Zenn、500円)
主張は1行: 言語化はオレ、構造化は AI。
章立てだけ抜粋:
- 「わからない」を分解できるか — メンタリングの現場から
- 言語化して AI に投げろ — 構造化は AI の仕事
- コンテキストがすべてを決める — 鏡の法則と格差の正体
- 思考の外部化エンジン — 生成AIの本当の使い方
CoDD で「人間は要件定義と感想しか書かなくなる」って言ってるの、この本の主張をコマンドに落としただけだ。codd elicit (AIが要件の穴を質問) = 「言語化して AI に投げろ」の自動化版。
「命名する人」になりたい人向け、こっちが体系版だ。
Discussion
はじめまして。
multi-agent-shogunを使わせていただいている、まさふみと申します。
おしおさんの記事がきっかけでマルチエージェント開発に挑戦できました。
自分の環境（Claude Max 5x + Gemini CLI +Ollama）向けにカスタマイズを重ねながら、とても楽しく取り組んでおります。
この体験をZennにまとめようと思っており、記事とリポジトリを参照元として明記する予定です。
素晴らしいプロジェクトをありがとうございます。
もし記事の表現でお気づきの点があればお知らせください。