整合性駆動開発（CoDD）とは？設計書とコードの整合性をAIで維持する開発手法と導入判断

整合性駆動開発（CoDD／Coherence Driven Development）は、設計書・コード・テストの相互参照を依存グラフとして管理し、要件が変わっても壊れない状態を保ちながら開発を進める手法です。AI駆動開発で生成物が増えるほど、設計書とコードは黙って乖離します。この記事では、CoDDが解く課題、仕様駆動開発（SDD）やTDDとの違い、coddコマンドによる依存グラフの構築と整合性検証、frontmatterでの依存宣言、そして本番案件で採用すべき現場と見送るべき場面までを、実装者の判断基準に落として解説します。数値・版番号の基準は原典とGitHubの一次情報で、いずれも時点付きの非断定表記です。

まとめ：整合性駆動開発は依存グラフで設計とコードのズレを封じる手法

CoDDの核は一つです。設計書とコードとテストの依存関係を機械可読な形で宣言し、変更が起きた瞬間に「どこが壊れるか」を自動で特定する。プロンプトエンジニアリングが単発の指示、コンテキストエンジニアリングが永続的な背景知識を扱うのに対し、CoDDは「変更時の整合性維持」というハーネスエンジニアリングの未解決領域を担います。

実務判断はこう置きます。要件変更が頻繁で、複数の設計書が依存し合う本番案件なら採用の価値がある。逆に、数日で捨てる試作や単一ファイル規模の開発では設計先行のコストが重く、見送る方が速い。生成AIにコードを書かせる比率が高いチームほど、乖離を検知する仕組みが利いてきます。CoDDは仕様駆動開発（SDD）を置き換えるものではなく、SDDが定めた仕様を「変更後も一貫させる」層として上に載る関係です。

整合性駆動開発（CoDD）とは｜設計書とコードの乖離を依存グラフで解消

まず概念の輪郭を押さえます。CoDDは2026年3月に原典が公開された新しい方法論で、検索ボリュームはまだ育っていません。ただし、AIがコードを量産する現場が抱える具体的な痛点に対する処方箋として設計されています。

CoDDが解く課題＝AI生成コードと設計書が乖離する構造的問題

AIエージェントに実装を任せると、コードは増えます。問題は、設計書がそれに追随しない点にあります。手動更新に頼る限り、ドキュメントは実装から遅れ、やがて「嘘の設計書」へと変わっていく。CoDDはこの乖離を構造で止めます。各Markdown設計書の冒頭にnode_idと依存先を宣言し、設計書とコードの関係を依存グラフとして保持する。要件が一つ変わったとき、グラフを逆にたどって影響範囲を割り出す。人がコードを読み直して波及を推測する作業を、機械の探索に置き換える発想です。

プロンプト・コンテキスト・ハーネスの系譜とCoDDの位置づけ

CoDDは突然生まれた概念ではありません。AI開発の制御手法は段階的に積み上がってきました。プロンプトエンジニアリング（2023〜2024年）は1回の指示に情報を詰め込む段階。コンテキストエンジニアリング（2024〜2025年）はCLAUDE.mdのような永続的な背景知識をファイルで管理する段階。そしてハーネスエンジニアリング（2025〜2026年）は、hookやSkill、ルール宣言でAIの実行そのものを制御する段階です。この三層目のうち「変更が起きたときに整合性をどう保つか」を担うのがCoDDにあたります。ハーネスの構造をより広く扱うアーキテクチャ設計はSpec・Context・Harness三層分離とAIエージェント開発の構造変化で整理しており、CoDDはその整合性維持の部分を具体化した位置づけになります。

Wave階層L1-L6が実現する上流から下流への生成と影響追跡

CoDDの設計書は、要件から実装まで6段の階層（Wave）で管理します。Wave 1が要件定義、Wave 2が基本設計・システム設計、Wave 3が詳細設計・API設計・DB設計、Wave 4がテスト戦略・インフラ設計、Wave 5が実装計画・受入基準、Wave 6が実装というレイヤーです。上流から下流へは「生成」の方向、つまり順に確定していきます。下流から上流へは「影響」の方向、つまり変更が起きたときに逆方向へトレースします。この二方向を一つのグラフで扱う点が、単なるドキュメント管理と分かれる部分です。上位の決定が下位に一貫して伝わる構造を先に作るため、初速は遅くなります。そのかわり、後からの変更に強くなります。

仕様駆動開発やTDDとの違いとcoddコマンドの整合性検証フロー

CoDDを導入するかは、既存の開発手法との違いを正確に掴んでから決めます。特に仕様駆動開発（SDD）との関係を誤解すると、二重に手法を入れて現場が混乱します。

SDD・TDDとCoDDの駆動要素・設計変更への耐性の比較整理

三者は「何を起点に開発を駆動するか」で分かれます。TDDはテストケース、SDDは仕様書、CoDDは依存グラフと整合性です。決定的な差は、仕様が途中で変わったときに現れます。

SDDは「最初に仕様を書く」ことを解きますが、「途中で仕様が変わったとき何が壊れるか」までは自動化しません。CoDDはそこを引き受けます。両者は競合ではなく、SDDで書いた仕様をCoDDが変更後も一貫させる補完関係です。SDDそのものの進め方やツールは仕様駆動開発（SDD）とは何かと従来手法との違いで詳しく扱っており、CoDDを検討する前提知識として先に読むと差分が掴めます。

coddコマンド群による依存グラフ構築と整合性検証の実行手順

CoDDはCLIで運用します。配布はpip install codd-dev、実体はGitHubのyohey-w codd-devで公開されています（v1.2系・2026年4月時点）。中核となる操作は次の流れです。

1. codd init：プロジェクトを初期化し、要件ファイルを起点に置く
2. codd scan：各設計書のfrontmatterを解析し、依存グラフを構築する
3. codd impact：変更ファイルの波及範囲を帯域（Green・Amber・Gray）で分類する
4. codd validate：frontmatterと実ファイルの整合性・未処理項目・構造を検査する
5. codd implement：設計書からコードをスプリント単位で生成する

実験的な位置づけとして、V-Model検証を行うcodd verify、既存コードから設計書を逆生成するcodd extractもあります。後者はブラウンフィールド、つまり設計書が存在しない既存プロジェクトへの後付けに効きます。Gitのpre-commitフックと組み合わせると、整合性が壊れた状態のコミットを止められる点も実務的です。

frontmatterの依存宣言フィールドとGreen/Amber/Grayの判定

依存グラフの原料は、各Markdown設計書の先頭に書くfrontmatterです。宣言するフィールドは、一意識別子のnode_id（domain名の形式）、処理順序を示すwave、依存先を並べるdepends_on、関連の種類を示すrelation（derives_fromやimplements、verifiesなど）、対応するコードを指すsource_filesです。原典の設計思想では、このfrontmatterを人が手書きするのではなくAIが自動付与し、frontmatterを唯一の正とします。codd impactが返す帯域は判断の粒度を変えます。Greenは高信頼で自動更新の対象、Amberは中信頼で人の確認を必須とし、Grayは低信頼の参考情報です。この帯域があるため、AIの自動修正を全面的に信頼せず、要所に人間の承認ゲート（HITL）を挟めます。

整合性駆動開発を本番導入すべき現場と見送るべき場面の判断基準

ここからは判断を言い切ります。CoDDは万能ではありません。設計先行のコストを払う価値がある現場と、払うと遅くなるだけの現場が明確に分かれます。

採用の条件＝要件変更が頻繁で複数設計書の依存が絡む実案件開発

採用が効くのは、要件が動く前提の本番案件です。複数の設計書が依存し合い、一箇所の変更が離れた実装に波及する規模で、初めてグラフの自動追跡が人手を上回ります。生成AIにコードを書かせる比率が高いほど効果は大きくなります。AIが速く書くほど、乖離も速く進むからです。中長期に保守するプロダクトで、ドキュメントが腐ることを実際に痛みとして経験しているチームには、設計先行の初速低下を補って余りある投資になります。

見送るべき場面は短命なプロトタイプや単一ファイル規模の小開発

逆に、見送るべき場面もはっきりしています。数日で捨てる検証用の試作、単一ファイルで完結する小さなツール、要件がほぼ固定で変更が想定されない開発。これらでは、Wave階層とfrontmatterを整える初期コストが、得られる整合性の恩恵を上回ります。この場合はバイブコーディング（AIに任せて素早く動かす進め方）の方が合理的です。CoDDを「常に正しい」と扱うと、小さな案件で過剰設計に陥ります。手法は案件の寿命と変更頻度で選ぶものです。

生産投入の判断はHITLゲートとCIへの整合性チェック組込み

本番投入で失敗しやすいのは、AIの自動修正をノーチェックで通す運用です。Green帯域だけを自動更新に回し、Amber以上は人が承認する。この線引きをCIに組み込み、codd validateが失敗したらパイプラインを止める。ここまで設計して初めて、CoDDは「動くドキュメント」として機能します。自社の開発体制にAI駆動開発を実運用として組み込む段階では、依存グラフの設計とHITLゲートの配置を含めた仕組み化が要です。設計から実装、運用の定着までを外部の知見と一緒に進めたい場合は、一創のAIエンジン開発で、生成AIを前提とした開発プロセスの構築を相談できます。エージェントの実行手順を標準化して制御する考え方はAgent SOPとLLMエージェントの制御も参考になります。

よくある質問

整合性駆動開発（CoDD）の導入検討でよく挙がる疑問に、一次情報を基準に簡潔に答えます。

整合性駆動開発は日本語と英語どちらの呼称が正式ですか？

英語表記はCoDD（Coherence Driven Development）で、日本語では「整合性駆動開発」と訳されます。実務では日本語主体で問題ありません。なお略語のCODDは、リレーショナルデータベース理論のE.F.Codd氏と表記が衝突するため、検索や社内共有では「整合性駆動開発」または「CoDD」を用いると誤解を避けられます。

CoDDはバイブコーディングやAIエージェント開発と何が違いますか？

バイブコーディングはAIに任せて素早く動かす進め方で、試作向きです。CoDDはその対極で、変更が頻繁な本番案件に向けて設計書とコードの整合性を保つ手法です。AIエージェント開発全体のうち、CoDDは「AIが作ったものをどう維持するか」に絞った層を担います。作る速さではなく、変えても壊れない構造を作る点が違いです。

小規模チームでも整合性駆動開発を導入する意味はありますか？

人数よりも、要件変更の頻度と設計書の依存の複雑さで判断します。少人数でも、長く保守するプロダクトで仕様が動くなら効果があります。逆に大人数でも、変更が想定されない短命な開発では初期コストが重くのしかかる。まずは既存コードからcodd extractで設計書を起こし、依存の絡み具合を可視化してから判断する進め方が現実的です。

既存プロジェクト（ブラウンフィールド）にCoDDを後付けできますか？

できます。実験的な位置づけですがcodd extractが既存コードから設計書を逆生成し、そこにfrontmatterの依存宣言を付与してグラフ化します。ゼロから設計書を書き直す必要はありません。まず一部のモジュールに限定して依存グラフを作り、影響追跡が実際に効くかを小さく検証してから範囲を広げると、導入リスクを抑えられます。

整合性駆動開発の導入に必要なツールや前提環境は何ですか？

CLIはpip install codd-devで導入できます（v1.2系・2026年4月時点）。設計書はMarkdownで管理し、frontmatterに依存を宣言します。Gitのフックと組み合わせるとコミット時の整合性チェックが自動化でき、Claude CodeのSkillと連携すれば人の承認ゲートを挟んだ運用も可能です。前提として、設計書を機械可読に保つ運用ルールをチームで合意しておくことが定着の条件になります。

関連記事

• 仕様駆動開発（SDD）とは：CoDDが前提とする「先に仕様、後にコード」の考え方と従来手法との違い
• Spec・Context・Harness三層分離とAIエージェント開発の構造変化：CoDDが担うハーネスエンジニアリング全体のアーキテクチャ
• Agent SOPとは：LLMエージェントの実行を標準作業手順で制御する仕組みと実装判断