仕様駆動かテスト駆動か評価駆動か― AIが繋がりの整合を取る今駆動は選ぶものではなく組むもの

この一年ほどで、性格の違う三つの「駆動」が同時に脚光を浴びました。

仕様駆動開発（Spec-Driven Development / SDD。カタカナでスペック駆動開発とも呼ばれます）は、AIエージェントに実装を任せる前提で、仕様書を先に書き、そこから設計・タスク・実装を展開させる進め方です。AWSのKiroやGitHubのSpec Kitのように、開発ツールそのものがこの形を組み込むようになり、「プロンプトで場当たり的に指示するのではなく、仕様を正面から書く」流れとして広まりました。

テスト駆動開発（Test-Driven Development / TDD）は、二十年以上前からある手法です。それが「AIが書いたコードを、何を根拠に信用するか」という文脈で再発見されました。実装を書く手が人からAIに替わったことで、テストは開発補助ではなく、人の意図をAIに伝え、生成物を検証する装置として意味を強めています。

評価駆動開発（Eval-Driven Development / EDD）は、LLM機能の開発現場から出てきた流儀です。生成や要約のように出力に唯一の正解がない機能は、単体テストの合否では品質を語れません。評価セット——英語のままevals（エバル）と呼ばれることも多いものです——と合格基準を先に作り、プロンプトの変更もモデルの更新もスコアの推移で判断する。この進め方が、LLMアプリケーション開発の標準になりつつあります。

三つが出揃った結果、論争も起きています。仕様駆動はウォーターフォールの再来だ、AIの時代にテストを人が書くのは無駄だ、評価セットこそ本物のテストだ——それぞれの立場から、択一の構図で語られがちです。

しかし三つを並べてみると、対立しているようでいて、実は同じ形をしています。次章でその形を取り出します。

AIが変えたのは、実装の値段です。コードを書くことが高価だった時代は、書く行為そのものが設計判断の連続であり、開発手法は「どう書くか」を扱っていました。生成が安くなった今、書く部分の多くはAIに渡せます。人に残るのは、出来上がったものを何と突き合わせて合格とするかを、先に決めておく仕事です。

この視点で三つの手法を並べ直すと、違いは一点に絞られます。突き合わせる先——動かない側に置く正本——をどこに置くかです。

注意したいのは、「駆動」の本質が先に書くことではなく、動かさないことにある点です。テスト駆動開発の要点は、テストを先に書く手順そのものではなく、テストを動かない側に置いて実装をそこへ従わせる力の向きにありました。AIが相手になると、この意味はむしろ純化します。生成物の都合に合わせて正本を書き替えてしまえば、突き合わせは成立しません。出来上がったコードに合わせてテストを直す、実装の挙動に合わせて仕様を直す——人間のチームでも起きていたこの逆流が、生成が速くなった分だけ簡単に起きるようになったからです。

どの手法を名乗るかにかかわらず、AI駆動開発の規律は一行に要約できます。正本はどれかを決め、生成物の側からそれを書き替えさせない。三つの「駆動」は、その正本の置き場所につけられた名前です。

置き場所が三つあるのは、対象の性質が三種類あるからです。

• 合否を外部との合意が決める対象——受託開発の検収、複数部門にまたがる業務要件。ここでは合意できる文書だけが正本になれます。テストも評価セットも、合意の記録としては検収に耐えません。固定すべきは仕様です
• 挙動が決定的で、入出力を定義できる対象——業務ロジック、計算、データ変換。ここではテストが最も安く確実な検証手段です。仕様書の文章より、実行できるテストのほうが厳密に挙動を固定できます
• 出力が非決定的で、唯一の正解がない対象——LLMによる生成・要約・分類。ここでは個別の入出力を固定するテストが書けません。評価セットと基準を固定し、統計的に合否を判定するほかありません

重要なのは、この三種類が一つのシステムの中に同居することです。業務システムにLLMの要約機能を足す案件を考えると、検収に出す機能一覧と受入基準は仕様駆動で固め、金額計算のロジックはテスト駆動で書き、要約の品質は評価セットで追う。三つの駆動が、同じリポジトリの中で同時に走ります。

だから「どれが正解か」は、対象を一種類しか想定していない問いです。冒頭の論争が噛み合わないのは、仕様駆動を推す人は合意が要る開発を、テスト駆動を推す人は決定的なロジックを、評価駆動を推す人は非決定的な機能を、それぞれ念頭に置いて話しているからです。全員が自分の対象については正しく、他人の対象については的を外しています。

どれでもいい、という言い方は投げやりに聞こえるかもしれません。正確に言い直すと、こうなります。手法の選択はもう争点ではない。争点は、自分の目の前の対象がどの性質か、そしてそれらをどうつなぐかに移った。

手法論争には、もう一つ暗黙の前提があります。開発は一本のパイプラインであり、駆動元はその先頭に一つだけ置かれる、という絵です。この絵の上でなら、先頭を仕様にするかテストにするか評価にするかは、たしかに択一になります。

実際の開発は、この絵の通りには流れません。仕様がテストを導出し、テストが実装を駆動する。ここまでは直列に見えますが、実装を動かした観測が評価セットを育て、評価の結果が仕様の改訂を促し、改訂された仕様がまたテストを更新します。線は一方向ではなく、戻る線と循環が最初から含まれています。

つまりこれは列ではなくグラフです。動かない正本がノードになり、「何が何を導出し、何と突き合わせるか」がエッジになります。そして根——最初に固定するノード——は一つとは限らず、案件の性質によって位置が変わります。

同じ変化を、実行の側で先に見ています。AIエージェントの実行は、単発の指示からループへ、ループから複数エージェントをノードとエッジで組むグラフへと進みました（この経緯はグラフエンジニアリングを受託開発の標準に取り込むに書いています）。実行の側がグラフになったのなら、それを統制する方法論の側だけが一本の直列のままでいられるはずがありません。仕様駆動・テスト駆動・評価駆動が同時に再考されているのは流行の偶然ではなく、実行のグラフ化に方法論が追いついていく過程だと考えています。

そしてこのグラフには、根の置き方よりも大きな変化が、線の側に起きています。次章で見ます。

そもそも、なぜ駆動はこれまで一方向の直列で語られてきたのか。理由は思想ではなくコストです。正本と正本の突き合わせが、高価だったからです。

仕様書とテストの整合を確かめるのは人手のレビューであり、数日がかりの作業でした。だから突き合わせは工程の節目にまとめて実行するしかなく、駆動元を一つに決めて一方向に流し、逆向きの反映は変更管理という重い手続きに封じ込めた。直列のパイプラインは、整合コストが高い世界での最適化だったのです。手法が択一で語られてきた背景には、この制約があります。

AIが変えたのは、生成の値段だけではありません。突き合わせの値段です。仕様書とテストコードの矛盾の列挙、実装と設計の乖離の検出、評価結果と受入基準の突き合わせ——人手で数日かかっていた整合確認を、AIは数分で、しかも何本でも同時に回せます。

するとエッジの意味が変わります。工程の節目に一度だけ流れる線ではなく、常時張られた整合の線になります。

• 仕様を一行変えれば、影響を受けるテストと評価項目がその場で列挙される
• テストの失敗は、実装の誤りだけでなく、仕様の曖昧さを照らす——「このケースの挙動は、そもそも仕様に書かれていない」
• 評価スコアの劣化は、仕様に書かれていなかった暗黙の前提を明るみに出す——「基準にはないが、ユーザーが期待していたもの」がそこにある

一方向の駆動では、正本の欠陥は下流で事故として見つかっていました。全ての線が常時動くと、欠陥は書いた直後に指摘として返ってきます。仕様はテストから「その受入基準は実行可能な形で書けているか」を問われ、テストは評価から「その網は品質の実感と一致しているか」を問われ、評価は仕様から「その基準は合意と繋がっているか」を問われる。駆動は上流から下流への片面ではなく、両面から働き、三つの正本は互いに検証され続けることで多角的に精緻になっていきます。

ここで、第2章の規律が効いてきます。整合を常時取ることと、正本が生成物の都合で流されることは、紙一重だからです。矛盾の検出と修正案の生成まではAIに任せてよい。しかし正本への書き戻しは、人の承認を通す。この一線を保つ限り、常時整合は正本を崩す力ではなく、正本を磨く力として働きます。逆に言えば、生成物から正本を書き替えさせないという規律は、AIに整合を任せるための前提条件でもあるのです。

グラフだと分かれば、次の問いは「どう組むか」です。組み方の大部分は、制約から決まります。

• 契約形態——請負で検収があるなら、仕様のノードは外せません。準委任なら仕様を軽くし、テストと評価に比重を移せます
• 変更の頻度——要求が動き続ける探索段階で仕様を根に置くと、正本の改訂が開発を止めます。先に評価基準を固め、安定してから仕様に書き戻す順が働きます
• 非決定性の比率——LLM機能が中心のプロダクトなら評価セットが事実上の要件定義になり、決定的な業務システムならテストの網が主役になります
• 手元にある正本——仕様書が失われたレガシーシステムでは、動いている実装が唯一の事実です。まず現行の挙動をテストに写し取り、根を実装からテストへ移すところから始まります

上の図に挙げた組み方は、この制約の読みをそのまま線にしたものです。受託開発なら仕様を根に置き、検収の線を仕様へ戻す。LLM機能なら評価と実装のループを中心に置き、安定した基準を仕様へ書き戻す。レガシー保守なら実装を根に、特性テストを経由して少しずつ受託開発型のグラフへ近づけていく。そしてどの型で組んでいても、その上にAIの常時整合を重ねられます。

常時整合が可能になったことで、設計変数は一つ増えました。どの線を常時回し、どの線は節目だけにするか。そして検出された矛盾のうち、何を人の承認に上げるかです。全ての線を常時回すことが常に正しいわけではありません。検収直前の案件で仕様への指摘が毎日積み上がっても捌けませんし、承認の処理能力を超えて書き戻し候補が積もれば、正本は事実上動き始めます。整合の速さに承認の体制が追いつく範囲で線を張る——これも制約の読みのうちです。

ただし、制約を全部並べても組み方は一つに定まりません。同じ案件でも、どのノードを根に置くか、どの線を常時回すか、どこに人の承認を挟むかには、複数の妥当な答えがあります。優劣の一部は、走らせた後にしか分かりません。

ここが、設計者に残る領域です。想像力という言葉をここで使うのは、自由な発想という意味ではありません。制約を読み切ったうえで、どのノードを根に置き、どこに線を張り、どの線に常時整合を回し、どこに循環と承認を挟むかを構成する力のことです。手法の名前と手順を覚えることは、その出発点にすぎません。自分の案件の駆動グラフを白紙に描けるかどうかが、AI駆動開発における設計力の中身になっていくはずです。

整理します。

仕様駆動・テスト駆動・評価駆動の違いは、何を動かない正本として先に固定するかの違いです。適した固定点は対象の性質で決まり、一つのシステムに三つが同居します。だから択一の問いは成立せず、三つはノードとエッジのグラフとして組み合わさります。そしてAIは、そのエッジ——正本同士の突き合わせ——を即座に何本でも回せるようにしました。三つの正本が互いを検証し合い、両面から多角的に精緻になっていく。唯一の正解がないのは、このグラフの組み方だけです。

実務に持ち帰るなら、問いをこう置き換えることを勧めます。「どの手法を採用するか」ではなく——

このシステムの中で、合意が合否を決める部分・挙動を定義できる部分・正解が一つに定まらない部分は、それぞれどこか。

それぞれの部分で、動かない側に置く正本は何か。生成物の側からその正本を書き替えさせない仕組みはあるか。

正本と正本のあいだに、どの向きの線を張るか。どの線をAIで常時回すか。

検出された矛盾を誰がいつ捌くか。正本への書き戻しの承認は、整合の速さに追いつくか。

この四つに答えが書ければ、名乗る手法の名前はどれでも構いません。答えが書けないまま手法名だけを導入すると、正本のない駆動——生成物が生成物を承認する流れ——になり、速くなった分だけ検証の負債が積み上がります。

工程との対応づけはウォーターフォールでAI駆動開発を回すに、組織への定着の進め方はなぜAI駆動開発は定着しないのかに整理しています。Chapter Techでは、開発プロセスの現状分析から駆動グラフの設計、ルール整備、効果測定までの定着支援をAI Delivery Scope+として提供しています。自社の案件ではどこを正本に置くべきかという見立ての段階からで構いません。お問い合わせからご相談ください。