生成AIの台頭は、コードの記述だけでなく、テスト生成や設計・ドキュメント作成に至るまで、SDLC（ソフトウェア開発ライフサイクル）全体のコスト構造に劇的な変化をもたらしつつあります。実装や修正のコストが大きく下がる現代、最適な開発プロセスはどうあるべきか。本稿では、従来の「手戻り防止型」のウォーターフォールや「無限反復型」のアジャイルに代わる、新たな2パス型開発プロセス「キャリブレーションモデル（CDM）」という仮説を提示。要件認識の誤差を実物で測定・補正し、確実な品質へ収束させるためのマネジメント手法の可能性について議論を深めます。
「AI駆動開発に、テスト駆動開発（TDD）の思想を組み込んだら、開発プロセスはどう変わるのか？」
すべては、このシンプルな一つの問いから始まった。
本稿では、この問いを出発点として議論を重ねるなかで見えてきた、AI時代における新たな開発プロセスの仮説「キャリブレーション開発モデル」の可能性と、その設計思想の変遷について順を追って整理し、これから私たちがどのような開発プロセスを模索していくことになるのか、その展望を考えてみたい。
最初の直感はこうだった。
AIに実装を任せると、速くコードは出る。しかし、
という現象が極めて発生しやすい。これはAIが前後の文脈を「なんとなく」解釈し、辻褄の合うそれっぽいコードを瞬間的に出力してしまうからだ。
そのため、TDD（テスト駆動開発）のプロセスを挟むというアプローチが有効ではないかと考えた。
という流れにすることで、AIの出力を「人間の主観的な感覚」ではなく「機械的かつ客観的に検証可能な仕様」に直接接続できるのではないか、という可能性である。
つまり、AI駆動開発にTDDを入れるというより、「AIを使うからこそ、制御不能なハルシネーションを防ぐためのTDD的なガードレールが必要になるのではないか」という仮説だ。実装ではなく仕様を中心に開発を進めるという設計思想は、AIの特性と非常に相性が良いのではないかと考えている。
ここで一つ気づいた。
AI時代になると、ウォーターフォールの順序性も変わるのではないか？
従来のウォーターフォールは「要件定義 → 基本設計 → 詳細設計 → 実装 → テスト」という、段階的な滝のようなプロセスだった。なぜこの順序が必要だったかというかというと、人間が手作業でコードを書くコストが極めて高かったからである。設計が曖昧なまま実装に入ると、後から手戻りが発生したときの金銭的・時間的ダメージが大きすぎる。だからこそ、前工程で仕様と設計をガチガチに固める必要があった。
しかし、AI時代は実装コストがほぼゼロに近づく。するとプロジェクトのボトルネックは実装ではなく、
という「要求定義」と「検証条件」へとシフトしていくのではないか。その結果、開発の流れも自然と、
要件定義
受け入れテスト定義
AI実装
検証
という形を志向していく可能性が考えられる。人間がWordで分厚い詳細設計書を書いてから実装するのではなく、期待するテストケース（＝振る舞いの定義）を記述することで、設計や実装の大部分をAIが自律的に生成するようなプロセスの可能性を模索することになるだろう。
そうなると、設計書は実装を指示するための「入力」ではなく、動作するコードから事後的に生成される「出力」へとその役割を変えていく可能性が考えられる。
もし実装コストが極端に下がるなら、「最初から正しいアーキテクチャや完璧な設計を当てる」という考え方自体を見直す余地が生まれるかもしれない。
従来は、
要件
設計
実装（高コスト）
であったため、実装前の設計フェーズで考え抜くことに大きな価値があった。しかしAI時代は、
要件 → テスト → 実装（低コスト） → 問題発見 → 再実装
というサイクルのコストが圧倒的に小さくなる。だとしたら、机上の空論で悩み続けるより、「まず作る → 実際に動かす → 動いた実物を見て設計を見直す」というアプローチの方が合理的なケースが激増するのではないか。
ここで議論は「失敗コスト」の話に進む。もちろん、金融、医療、航空宇宙といった、1周目の失敗コストが極端に高く許されない領域はある。だが、多くのエンタープライズ開発において、
つまり、設計という事前防衛策で品質を担保するのではなく、テストという検証手段で品質を担保する方向に、開発の重心がシフトしていく可能性を模索することになる。
ここで一度、議論にズレが生じた。
「2周目」を「リリース後のユーザー学習」と捉える解釈（アジャイルやリーンのフィードバックループ）があった。しかし、ここで本当に考えていたのはもっと手前の話、すなわち「本番デプロイ前のデリバリープロセス」の話だ。
従来のプロセスでは「後戻りコストが高い」ことが前提となっていたが、AIによってそのコストが圧縮されるなら、「順序性よりも、段階的な検証と反復の重要性が高まるのではないか」という問いが生まれる。
しかしAI時代においては、要件定義から実装、確認までのサイクルが極めて短期間で回るようになる可能性がある。そうであれば、最初から「1周目は真の要求を理解するための探索、2周目で本番用への最適化」を前提にしたプロセスを模索する余地があるのではないか。
一発勝負で100点を目指すのではなく、まずは基準となる実物を作り、動くものを見て解像度を高めながら本番品質へと収束させていく、そうした段階的な進め方の有用性を探っていくことになるだろう。
本稿で想定しているのは、本番リリース前に、同一プロジェクトのデリバリープロセス内で複数周（2周）回すというアプローチの可能性である。
ここで重要な制約が入る。
「何周も回すのは、プロジェクト管理や予算管理の観点から破綻する。だからこそ『2周』という強い縛りが必要だ」
無制限の反復には、プロジェクト管理を困難にする側面があるのではないか。AIによって実装コストが下がることで、かえって無限のやり直しを要求しやすくなるという懸念だ。
「もう1回だけ作り直そう」
「もう少しここを改善しよう」
「もう1パターン別の画面案を作ろう」
これが繰り返されると、開発コストが下がる一方で意思決定コストが跳ね上がり、プロジェクトの収束が見えなくなるリスクが考えられる。意思決定者の時間とエネルギーは無限ではない。選択肢が増えすぎることで、かえって「どれを選べばいいか分からない」という意思決定麻痺が生じてしまう。
AIの劇的な実装コスト低下は、逆説的に人間の「意思決定コスト」を肥大化させ、プロジェクトの着地点をあいまいにしかねない。
したがって、反復回数を無限に許容するのではなく、プロセスを「探索（Calibration）」と「収束（Convergence）」の2フェーズに厳格に固定する境界線が必要となる。これにより、手戻りのコストを抑えつつ、意思決定コストの肥大化を防ぎ、有限の工期で確実にプロジェクトを着地させることが可能になる。
「開発サイクルを反復する」「AI主導で開発する」というアイデア自体は、もちろん私たちが初めて提唱するものではない。近年、国内外でいくつかの類似したアプローチが議論されている。
類似したアプローチは存在するものの、AIの特性を踏まえて「意思決定の迷走を防ぐために反復回数を2回に規定する」という点に焦点を当てた議論は、まだ十分に整理されていないと思われる。たとえばスパイラルモデルはリスクが解消されるまで何周も回る前提だし、アジャイルも無限スプリントが基本だ。
ここで検討しているキャリブレーションモデルという仮説が特徴的なのは、この「無限反復の禁止」という点にある。AIによって作る・試す・やり直すコストが下がるほど、人間の「意思決定コスト」が相対的に高まり、プロジェクトの着地点が見えにくくなるのではないか、という問題提起である。だからこそ、第1相：探索（Calibration）、第2相：収束（Convergence）の2パスに固定する境界線が有効になるのではないか、という仮説だ。
なお、FDEの定義や起源については、「FDE（Forward Deployed Engineer）とは？AI導入を成功させる新職種の役割・必要スキル・企業事例を解説」や「FDEという新たな役割に、私たちはなぜこれほど期待を寄せてしまうのか？」をご参照ください。また、FDEの多義性については「うちのFDE - FDEという多義的な役割」でも深く議論しています。さらに、プロジェクトマネジメントオフィス（PMO）におけるFDE精神の応用として、「PMO 2.0: FDEとAntigravityがもたらす「課題解決型PMO」の可能性」も執筆しています。
ここで、この思考の根っこにある本質的な人間観に行き着いた。
「どちらかというと、人間の初期の言語化能力を信用していないから、このプロセスが必要になるのではないか」
この視点は重要だと考えている。「AIで開発が速くなるから2周できる」というのは単なる技術的な手段にすぎない。そもそも「人間は最初から自分たちの欲しい要件を完璧に言語化することは難しいのではないか」という、人間の認知特性についての仮説が出発点となる。
従来のウォーターフォールは、以下のような仮定を暗黙の前提としている。
しかし実際のプロジェクトにおいて、実物を見るまで本当に必要な仕様を実感しづらいという現象はしばしば見られる。これは業務担当者が嘘をついているわけでも、PMのヒアリング能力が低いわけでもない。本人たちも、実物を見るまで本当に必要なものが完璧にイメージできているわけではないからだ。
これは、業務担当者が自分たちの要求を持っていないわけではない。ビジネスユーザーは、「今、業務の何に困っているか」「何を自動化・効率化したいか」「どんな操作が嫌で、どんなストレスがあるか」「何は便利だから絶対に変えたくないか」といった、日々の業務に根ざした真のニーズ（要求）を確かに持っている。
ただ、それを最初から具体的なシステム仕様という高解像度な言語（技術スペック）へと変換することが難しいのではないか、という点である。
これは家を建てる時の施主の感覚にとてもよく似ている。施主は最初から「広くて明るいリビングが欲しい」「たくさん収納が欲しい」「暖かい家がいい」という要求（要件）を持っている。しかし、
といった具体的な解像度は、図面やモックアップなどの実物を検証するまで見えにくいことが多い。要求そのものは当初から存在しているものの、その初期段階における解像度が低い状態にある、と捉えるのが自然だろう。
したがって、このモデルがアプローチしようとしているのは、要件の変化への追従（アジャイル）や、顧客ニーズのゼロからの探索（リーン）とは異なり、「すでに存在する要件の解像度をいかに早く高めるか（Calibration）」という課題に対する可能性の模索であると考えている。
ここで、「CGや模型を作る感覚」と表現すると、また別の誤解が生まれる。
「模型（プロトタイプ）というと、使い捨てのチープなものを想像してしまう。しかし1周目の探索フェーズで作るのは、そんなハリボテではない」
キャリブレーションモデルの1周目で開発するのは、モックアップや画面紙芝居ではない。
そのものである。ただし、複雑な既存データ移行や、極端な非機能要件、セキュリティ権限の例外、監査証跡といった「デリバリー工数の大半を消費するが、要件の解像度向上には寄与しない本番周辺要件」を後回しにする。
これは全体の「80%完成品」であり、使い捨てる模型ではない。建築で例えるなら、「スケルトン状態の完成住宅」に近い。家としての骨組みとインフラは本気で建てられており、実際に住むことができる。ただ、造作家具や庭の植栽、細かい内装仕上げといったディテール（20%の要素）はまだ施されていない、という状態だ。
つまり、一般的なプロトタイピング思想とも根本的に異なる。
「いや、アーキテクチャやデータモデルは、パフォーマンスやセキュリティといった重要な非機能要件に紐付いている。だから後回しにするのはおかしくないか？」
これも非常に鋭い指摘だ。ここにも思想のアップデートが必要だった。
アーキテクチャやデータモデルは、非機能要件やビジネス制約と直結しているため、1周目の最初から本質的な設計を行う必要があると考えられる。
ただし、ここでキャリブレーションモデルの思想がより鮮明になる。
「1周目から設計を真剣に行いつつも、それらもまた『必要に応じて2周目で作り替える余地』をチーム全体が共有しておく」
という関係性の構築だ。これは「アーキテクチャを考えない」ということでは断じてない。「人間側の不完全な業務理解の段階で、後戻りできない完全なアーキテクチャを決定しない」ということだ。
1周目において、チームは以下をすべて「仮説」として構築する。
そして2周目（収束フェーズ）に入った時点で、1周目の動作検証によってキャリブレートされた（正しいとわかった）仮説を、本番稼働に耐えうる本物へと昇格させる。
従来の開発プロセスにおいて、「設計は契約（合意後の変更はペナルティ）」とされがちだった。
しかしAI時代においては、「設計は検証可能な仮説」へと位置づけが変わっていくのではないだろうか。
ここで一気に視界が開けた。
「AI駆動開発の真の価値は、開発者が『手戻りの恐怖』を完全に捨てられることにあるのではないか」
世の中の多くの人は、AI駆動開発を「AIが人間の代わりに高速でコードを書いてくれる技術」と捉えている。しかし、生産性向上の本質はそこではない。手戻り（仕様変更や設計のやり直し）にかかるコストとリードタイムが劇的に削減されることの方が、プロジェクト全体に与えるインパクトは遥かに大きい。
人間中心の従来型開発では、
「設計にミスがあった → 3ヶ月後のテストフェーズで発覚 → 修正の影響調査 → 変更承認プロセスの稼働 → 設計書の修正 → コードの書き換え → 関連するテストの再設計・手動再テスト」
というプロセスが走り、膨大な時間とコストが溶けていった。だからこそ、関係者は全員手戻りを極端に恐れ、「完璧な要件定義」や「変更のない完璧な設計」を神話のように追い求めた。しかし実際には、事前に完璧を見抜くことは誰にもできなかった。
AI時代は、この構造が根本から逆転する。
「設計にミスがあった → テストとコードをAIがその場で修正・再生成 → 瞬時に全体テストを実行して確認」
これが数時間で現実のものとなる。そうであるなら、設計の基本思想自体を転換しなければならない。
「手戻りを防ぐ（防衛的設計） → いつでも手戻りできるようにする（可変的設計）」
ウォーターフォールが強いる堅苦しい順序性も、アジャイルが強いる厳密なスプリント管理やベロシティ測定も、すべては「変更という不確定要素を、人間が管理可能な範囲に閉じ込めるため」の防衛策であった。
キャリブレーションモデルはこの防衛策を捨て去る。
「変更は必ず起きる。人間の理解は実物を見て初めて深まる。だから、設計もデータモデルも変わる。変わったら、AIの力を使って超高速で作り直せばいい」
これは極めてラディカルな思想だ。ただし、無限に作り直すカオスを避けるため、プロジェクト管理の枠組みとして「1周目（探索：手戻り上等）」→「2周目（収束：本番化）」の2つのパスに厳格に固定する。
ここで、自分自身に対して最も手痛い反論をぶつけてみる。
「AI駆動開発を導入すれば、生産性は10倍、100倍になるはずだ。ならば、なぜこのような『2周固定』などの新しい管理手法が必要なのか？単に『速いから2周まわせばいい』というだけの話ではないのか？」
この問いを掘り下げたとき、議論は最も深遠な領域へと到達した。
世間で行われている「AIの生産性向上」に関するさまざまな実験結果を整理してみよう。
「AIで開発が爆速になる」と叫ばれる一方で、現場の実感として「思ったほど全体のリリース速度が上がっていない」「むしろAIの尻拭いで開発者が疲弊している」という声が消えないのはなぜか。
ひとつの要因として、多くの検証が「既存の開発プロセスの枠組みを維持したまま、部分的にAIツールを導入している」点にあるのではないか、という仮説が成り立つ。
すなわち、ウォーターフォールの開発工程や、アジャイルのスプリントプロセスの形は一切変えず、コーディング部分にだけCopilotやCursorをあてがっている。
これは、せっかく高性能な「自動車（AI）」を発明したのに、それまで馬車が走っていた「デコボコの馬車道（承認と分断のプロセス）」の上を走らせて、「馬車より少し速い程度だ」と測定しているようなものである。
AIを導入しても、
これらがプロセスの随所に残っている場合、AIによるコーディングの高速化が全体のリードタイム短縮に直結しにくくなる可能性がある。ボトルネックが「実装（コードを書く）」から「レビュー・承認・検証・合意形成」という人間側のオーバーヘッドへとシフトしてしまうからではないか。
AIの真のポテンシャルを引き出すには、古い開発工程にAIをプラグインするのではない、AIが持つ「手戻りコストの低さ」を最大化するように、開発プロセスの構造自体を2周型（探索と収束）へと抜本的に再設計していくアプローチの可能性を模索することになるだろう。
Chapter Techでは、このアプローチをエンタープライズDX & FDE支援サービスを通じて、実際のプロジェクトへ適用・支援しています。また、よりシンプルなコーポレートサイト制作やWebサイト構築においては、当社のWeb制作サービス「デジステップ」にて、高品質・高速なデリバリーを提供しています。
「2周で終わらせる」という時間的制約と、「1周目で本気で本番用の構造を作る」という品質の担保を両立させるには、もう一つの強力な歯車が必要となる。それがTDD（テスト駆動開発）だ。
1周目で80%完成（スケルトン状態）を目指すと言っても、その「80%」の正しさが何によって保証されるのかが曖昧であれば、2周目は収束するどころか、1周目の負債の山を片付けるだけの泥沼のデバッグ工程に化けてしまう。そこでTDDが真価を発揮する。
要件を定義した瞬間、以下のようなサイクルを徹底する。
要求定義 → 受入テスト定義 → 非機能テスト定義 → AIによる自動実装 → テスト合格 → 人間による実物確認
1周目の探索フェーズが目指すのは、「事前定義された受入テストが100%通過している状態」だ。業務的なハッピーパスに関しては、完全に動作するものが出来上がっている。
このテストによる堅牢なガードレールが存在するからこそ、2周目でアーキテクチャの構造をドラスティックに変更したり、ERDのテーブル定義を整理し直したり、モジュールの責任範囲を組み替えたりすることが、恐れることなく可能になる。どのような大改造を施そうとも、裏で「受入テスト」が通っている限り、システムの業務的整合性が破壊されていないことが保証されるからだ。
従来の開発で手戻りが恐ろしい最大の理由は、コードを書き直す作業そのものの大変さではない。「変更によって、どこがどのように壊れたか、人間には影響範囲が分からない」という闇に対する恐怖だ。だから誰も古いコードを触れなくなり、継ぎはぎの設計で破綻していった。
要件がテストコードという「動作する仕様書」として固定されているならば、データモデルの全面作り直しであっても、テストさえ通ればシステムは正しい。
ここで1周目の役割を以下のように捉えてみる。
AIとTDDの組み合わせは、お互いの弱点を補い合う最高のパートナーである。
この組み合わせがあって初めて、「1周目で探索し、2周目で収束させる」という開発プロセスが実務レベルで機能し始めるのではないだろうか。
ここで、これまでの開発業界で行われてきた「プロトタイピング」や「MVP」の議論と、このキャリブレーションモデルの間に存在する、致命的な認識のズレを正しておかなければならない。
この「80%」という数字の解釈については、単なる「手抜き開発」と誤解されないよう、慎重に整理しておく必要があると考えている。
ここでは、以下のような解釈を提案したい。
「1周目は、手抜きで80%の完成度を目指す工程ではない。1周目もまた、その時点で分かっている仕様に対して『100%の完成』を本気で目指す工程である」
1周目の時点で定義できている機能要件、データモデル、テストケースに関しては、一切の妥協なく完璧に通し切る。本気で作るのだ。
そのように構築しても、初期の要件定義の解像度の限界から、実物を見て初めて顕在化する仕様の不足や変更（仮に全体の20%とする）が観測されるのではないか、という想定である。
つまり、
この考え方は、アジャイルや一般的なMVP（Minimum Viable Product）の思想とは異なるアプローチを示唆しているのではないか。
これは非機能要件についても同様だ。1周目で非機能要件を完全に無視するのではなく、
すなわち、「人間の初期の言語化は、機能・非機能を問わず、本質的に不完全（低解像度）である」という事実を, プロセスの前提として暖かく受け入れているのである。
ここでもう一つ、プロジェクトマネジメントの観点から決定的な思考の修正を行っておく。
「2周も回せば十分な品質になるから、2周にする」と考えるべきではない。
このプロセスの本質は以下のように考えられる。
「2周で完璧になるからではなく、プロジェクトをビジネスとして確実に『終わらせる（収束させる）』ために、反復回数を2周に固定する」
アジャイル的な反復思考の最大の弱点は、「作れば作るほど、触れば触るほど、もっと改善できるアイデア（要求）が無限に湧き出てくる」という点にある。その要求に際限なく付き合っていると、いつまでも本番リリースができず、予算と時間は無限に溶けていく。
このモデルが提起するマネジメントの姿勢は、ある種厳格な境界線を設ける点にある。
「どれほど魅力的な改善案が追加で浮上したとしても, この開発枠組みにおいては2周目の収束フェーズで確実にプロジェクトをクローズさせる」
なぜなら、ビジネスにおけるシステム投資の目的は、「永遠にリリースされない完璧な自己満足システム」を作ることではなく、「期日通りにビジネスの現場で稼働し、利益（P&L）に貢献するシステム」を手に入れることだからだ。
したがって、このモデルは「2周で十分」という技術的妥協ではなく、「2周で終わらせる」というマネジメント上の意思決定の枠組みとして提案したい。
ここで、本仮説の思想核心に到達する。
「このモデルは、単に『より高品質なソフトウェアを作るための手法』ではないのではないか」
品質向上だけを目的にしてしまうと、アジャイルの罠に嵌まる。「もっと良くできる」という誘惑は、開発チームのエンジニアリング的良心を刺激し、プロセスを無限反復へと引きずり戻すからだ。
このモデルが目指すのは、単なる品質向上やバグの削減そのものではなく、「初期段階の低解像度な要件理解を、動作する実物を媒介に早期に高解像度化し、限定されたプロセス内でプロジェクトを確実に着地（収束）させること」であるという視点だ。
品質の向上やバグの減少は、その収束プロセスの副産物として結果的に得られるものに過ぎないのではないか。
既存の開発アプローチとキャリブレーションモデルの前提の違いを、以下のように整理できる。
この考え方をひとつの仮説として整理するなら、以下のような展望を描くことができる。
「人間は確かに要件を持っているが、その初期段階の言語化解像度は不完全である。キャリブレーションモデルは、AI駆動開発とテスト駆動開発の圧倒的な低コスト性を利用して、既知の要求を早期に100%実体化させ、実物との対話によって要件の解像度を限界まで高めた上で、その補正データを基に2周目のパスでシステムを確実に収束させることを目指す、AI時代の『プロジェクト収束フレームワーク』という仮説である」
ここで初めて、この一連の探索・収束型プロセスに「キャリブレーション（Calibration）」という名前を冠した理由について述べておきたい。
仮説の本質を示す言葉として、「探索・収束型2パス開発」が最も正確かもしれない。しかし、
「ウォーターフォール、アジャイル、スクラム、リーン、スパイラル」
といった歴史的な開発方法論の並びに置いたとき、「探索・収束型2パス開発」では単なる仕様説明文に聞こえ、方法論としてのシンボル性に欠ける。
歴史を振り返ると、優れた開発手法の名前は、その物理的プロセスを直接説明していないことが多い。
名前は、その手法が持つ「手触り」や「思想のシンボル」であるべきだ。
だからこそ、私たちはこれを「キャリブレーション（校正・調律）」と呼ぶ。
温度計やGPSが、現実の基準値と突き合わせて目盛りを補正するように、私たちの要件認識もまた、動くコードという現実の基準器と突き合わせて「目盛りを校正（キャリブレート）」される必要があるからだ。無理に「認識校正型開発」などと日本語訳せず、そのまま「キャリブレーション」と呼ぶ。それこそが、ウォーターフォールやアジャイルと対等に並び立つに足る響きを持つ。
しかし、注意しなければならない。名前は単なるラベルである。
ウォーターフォールを「水が流れる仕組み」といくら説明しても、ガントチャートの引き方は分からない。同じように、キャリブレーションを「計測器のチューニング」といくら説明しても、ソースコードは書けない。
主役はあくまで、これから検証していく具体的かつ実践的なプロセスである。
キャリブレーションという言葉は、この一連のプロセスを提示するための、薄いパッケージのシールに過ぎない。
ここで、本稿における議論の軌跡を、出発点から終着点まで一気通貫で整理しよう。
本モデルの立ち位置をより明確にするため、従来の主要な開発手法や概念との決定的な差分を整理する。
| 手法・概念 | 従来アプローチの思想 | キャリブレーションモデルの思想 |
|---|---|---|
| ウォーターフォール | 「要件定義フェーズで要件は完全に定義できる」と考え、手戻りを徹底的に防ぐ。 | 「要件は最初からあるが解像度が低い」と考え、1周目の実装で解像度を上げて手戻りを受け入れる。 |
| アジャイル | 「要件は変化し続ける」と考え、リリース後もスプリントの反復（無限ループ）を繰り返す。 | 「要件は1周目で高精度化できる」と考え、反復を「探索」と「収束」の2パスに固定して終わらせることを目指す。 |
| プロトタイピング | 学習や検証のための「使い捨ての簡易モック」を作る。 | 1周目から本物のデータベースとアーキテクチャで「本気で作る（捨てない）」。 |
| MVP (Minimum Viable Product) | リスク検証のために、提供する機能のスコープを「最小限に絞る」。 | 現時点で言語化できる機能は「最初からすべて本気で作りきる」。 |
| Spec-Driven Development | 仕様（Spec）をAIに対する唯一の正解ソース（入力）として固定する。 | 仕様自体が「1周目の動作検証を経て初めて高解像度化（出力）される」と捉える。 |
| スパイラルモデル | リスクが十分に低減されるまで、らせん状に「何周でも反復する」。 | リスク測定と補正のプロセスを、管理上「2周」に固定する。 |
このキャリブレーションモデルという仮説は、適用すればすぐに機能するような魔法ではない。プロジェクトにおいて実効性を持たせ、確実に収束させるためには、以下のような「工学的前提条件」が満たされる必要があると考えている。
要件の整理、テストコードの起票、アーキテクチャの変更影響調査、およびソースコードからの設計ドキュメントの逆生成に至るまで、SDLCの全工程においてAIエージェント（AntigravityやCursor等）をフル稼働させ、人間側の事務的オーバーヘッドを極限まで排除すること。
「どうせ2周目で直すから、適当に作っておこう」という甘えは、2周目の収束を不可能にする。1周目時点の仕様書に書かれたテストは、本気で100%満たし、本番同様の技術スタックで構築しなければならない。
AIに実装を指示する前に、受入条件となるテストコード（TDDのレッド状態）を固定すること。これがなければ、AIの生成するコードの妥当性を機械的に検証できず、手戻りのコストが跳ね上がる。
「1周目はUIだけ、2周目でデータベース」といったスコープの先送りは行わない。1億件のデータ量やセキュリティ要件など、判明している非機能制約は最初からアーキテクチャ設計に組み込み、テストを走らせる。
2周目は「収束（Convergence）」のフェーズである。1周目で浮き彫りになった誤差の修正と仕上げに徹し、「やっぱりここも変えたい」という新たな思いつきは、原則としてこのプロジェクト内では却下し、次の開発フェーズへと回す。
テストがすべてパスし、1周目で検出された誤差の補正が完了した時点で、プロジェクトを完成とみなす。「もっと磨き上げられる」というエンジニアリング的なこだわりを、管理上の意思決定によってコントロールすること。
キャリブレーションモデルにおいて、全体の開発工数は以下のような比率で配分されるという仮説を立てている。
この極端な比率の背景には、ソフトウェア開発における「工数と価値の非対称性」がある。
システム開発において、ユーザーが最も価値を感じるコアの業務ロジックや基本画面は、全体の約20%の要素にすぎない。そしてこのコア領域は、現在のAI駆動開発（Cursorやエージェント）が最も得意とし、驚異的な速度でコードとテストを自動生成できる部分である。そのため、わずか20〜30%の工数で、システムの本質部分（スケルトン）を100%動作する形で具現化し、ユーザーにぶつけることができる。
一方で、本番稼働するために絶対に無視できない残りの要素（緻密な例外処理、大量データのパフォーマンスチューニング、詳細なエラーハンドリング、監査ログの設計、既存レガシーシステムからのデータ移行、他システムとの結合試験、本番デプロイ手順の構築など）は、全体の8割の工数を消費する。
この重厚な「収束プロセス」に、1周目でキャリブレートされた（正しいと実証された）データモデルと要件を基にして、残りの70〜80%の工数を一気に集中投下する。
これにより、「要件が間違っていて、苦労して書いた例外処理や移行スクリプトがすべて無駄になった」という最悪の手戻りロスを完全に排除する。
ただし、プロジェクトの性質やシステムの特性に応じて、以下の調整幅を持たせるべきだ。
キャリブレーションモデル（CDM）におけるプロジェクトの進め方をより具体化するため、10週間の開発プロジェクトを想定したマスタスケジュール（ガントチャート）と、タスク間の依存関係を、旧来のウォーターフォール型プロセスと比較して示します。
両モデルのスケジュールを比較すると、以下の3つの決定的な違いが浮かび上がります。
タスクをホバーすると、接続関係がハイライトされます。
期待仕様をテストとして先に固定し、客観的な合格基準を定義。
妥協なく本気で動くコードを作り、機能仕様を実体化。
実物と対話し、言語化できていなかったズレ（誤差）を測定。
測定された誤差を基に、データモデルやアーキテクチャ設計を最適化。
テスト資産に守られた状態で、セキュリティや既存移行など本番周辺要件を統合。
本番リリースを行い、運用自走体制を引き渡して確実に収束。
要件定義からリリースまでが一方向の依存関係になっており、テスト工程（W8-W9）で不具合や要件のズレが検出された場合、手戻りのフィードバックが要件定義や設計（W1〜W2）まで遡り、すべての整合性を崩してしまいます。これは計画外の混沌としたループ（炎上）を引き起こします。
探索パス（1.1〜1.3）で得られた「実物検証からの測定誤差」を、2.1（測定誤差の反映・設計最適化）へと確実に引き渡す「計画的なフィードバックループ」が最初からプロセスとして組み込まれています。これにより、2周目（本格実装）は不確実性を排除した状態で、安全かつ高速に進めることができます。
AI時代のシステム開発は、単に「AIを使ってコードを速く書くこと」ではない。
AIの本当のインパクトは、要件定義から設計、実装、テスト、ドキュメント生成に至るSDLCの各工程のコストを劇的に押し下げたことにある。その恩恵として、私たちは「かつてはプロジェクトの敗北を意味していた『手戻り（仕様変更・設計変更）』を、プロセスの内側に正規のステップとして安全に組み込む権利」を手に入れた。
しかし、手戻りの容易さに甘えて無制限の反復（アジャイルの無限ループ）を許せば、プロジェクトは永久にクローズしない。
だからこそ、プロセスを「2周」に固定するアプローチが有効ではないか。
このプロセスを、私たちは「キャリブレーションモデル」という仮説として整理した。その本質は、
という可能性の提示にある。
最後に、この仮説の「新規性」について、学術的・実務的な観点から誠実に整理しておきたい。
かつて、ソフトウェア開発の現場に「CI/CD（継続的インテグレーション・デプロイ）」という自動化技術が登場した時、人類は単に「ビルドを数分速くする」という局所的な効率化を選ばなかった。代わりに、それまでは工数的に不可能だった「デプロイごとの自動テストの全件実行」や「静的解析による品質ゲートの設置」といった、「それまでできなかった新たなプロセスを開発ライフサイクルに組み込むこと」を選択した。
DevOpsの台頭もまた、単なるサーバー運用のコスト削減ではなく、開発チームと運用チームが同じ一次データを見て協働する「プロセスの統合」へと進化した。
テクノロジーによって生産性が劇的に向上した時、人類はいつも「速く作る（速度の最大化）」ことよりも、「それまでコスト的に諦めていた、より本質的な工程を追加する（プロセスの高度化）」ことを選んできたのだ。
AI駆動開発がもたらした圧倒的な余剰工数に対しても, 私たちは同様のアプローチを検討できるはずだ。
単に「コードが速く書けるようになった」と喜ぶのをやめ、それまではコスト的に不可能だった、
という、より豊かで本質的な「キャリブレーション」のプロセスを、新しいソフトウェア開発の選択肢として模索していく。
これが、対話を重ねる中で私たちが描いた、AI時代のソフトウェア開発プロセスに関するひとつの可能性である。