生成AIを開発に入れて、コードを書く速度は確かに上がりました。それなのにプロジェクト全体のリードタイムがあまり縮まらない——同じ感覚を持っている方は多いはずです。実装だけが速くなった結果、レビュー、プルリクエストの処理、ドキュメントの合意という人間側の工程が、全体の速度を決める制約になりました。この問題への現在の主流の答えがスペック駆動開発(仕様駆動開発)ですが、実際に回すと壁に当たります。仕様は書き切れないのです。書き切ろうとすれば、ボトルネックは実装から仕様合意の工程へ移るだけで、全体は速くなりません。本コラムで書くのは、問いを立て直した先の進め方です。仕様を書き切ることをあきらめ、AIが空白を埋めるときの判断基準だけを渡す。CLAUDE.mdのようなAIが常時読むファイルを、指示書ではなく「憲法」として書く。そして人間が書けなかった仕様のほうは、書くコストがほぼゼロになったAIに受入テストケースとして書かせ、人間はその一覧を確定する仕事だけを持つ。Anthropic自身がClaudeの学習に使っているConstitutional AI——細かい規則を網羅せず、原則を与えて個別の判断はモデルに演繹させる——の発想を、開発プロセスの運用に転用した形です。条文の書き方、AIに出させる解釈一覧の様式、テストケース一覧をどの粒度で人が見るかまで、実際に運用している形で書きます。
生成AIをシステム開発に導入して、コードを書く速度は確かに上がりました。それなのにプロジェクト全体のリードタイムはあまり縮まっていない。この感覚は、現場では次の四つの形で現れます。
四つに共通しているのは、コードが間違っているわけではないことです。生成物の品質ではなく、生成物と業務のあいだの確認に時間がかかっています。つまりボトルネックが「実装」から「確認と合意」へ移動しました。実装だけが桁違いに速くなった結果、レビュー、プルリクエストの処理、ドキュメントの合意という人間側の工程が、プロジェクト全体の速度を決める制約になったということです。
全体の速度を決める工程が、AIの導入とスペック駆動の採用でどこへ移るかを並べている。
制約は消えず、位置が変わる — 実装からレビューへ、レビューから仕様合意へ。
この問題への現在の主流の答えが、スペック駆動開発(Spec-Driven Development / 仕様駆動開発)です。コードを書く前に仕様・受入条件・スコープ外を文書として確定し、それをAIへの入力と、レビューの判定基準の両方に使います。AWSのKiroやGitHubのSpec Kitのように、開発ツールそのものがこの形を組み込むようになりました。
理屈は通っています。AIが作りすぎるのは指示の空白を勝手に埋めるからであり、レビューが機能しないのは判定基準がレビュアーの頭の中にしかないからです。仕様が文書としてあれば、網羅されているか、余計なものがないかを、仕様との突き合わせで確認できます。判定基準を明文化するという利点自体は本物です。
実際に回してみると、すぐに壁に当たります。仕様は決まりきりません。
考えてみれば当たり前で、仕様を完全に書き切れるならウォーターフォールは失敗していません。実物を見て初めて要件が分かるから反復開発が生まれたのであって、AIのために完全な仕様を前置きするのは、その経緯を逆に辿る動きです。要件定義に「曖昧さゼロ」を求める基準そのものが成立しないことは、要件定義でプロジェクトが失敗する理由に書いた通りです。
しかも、書き切ろうとしてもボトルネックは解消しません。移動するだけです。まだ何も見えていない段階で、想像をもとに詳細を議論することになります。これは判断のコストが最も高いやり方で、全体の生産性はむしろ下がります。実装が速くなった分を、仕様合意の会議が食べていきます。
ここで、何を棄却したのかを明確にしておきます。スペック駆動が重いのは、
の二点であって、仕様という成果物自体が無価値だからではありません。この区別が、後半で効いてきます。
では問いを変えます。「どうすれば仕様を書き切れるか」ではなく——
不完全な仕様のまま、AIの拡張解釈が適切に乗るには、何が要るか。
AIが空白を埋めること自体は避けられません。であれば、埋め方を導く判断材料だけを渡せばよいことになります。「書き切る」から「委ね方を制御する」への転換です。
ここで借りたのが、Anthropic自身がClaudeの学習に使っているConstitutional AIの発想です。禁止事項を網羅的に列挙するのではなく、憲法と呼ばれる原則の集合を与え、個別のケースの是非はモデルに演繹させる。本来は学習の手法ですが、ここではその考え方を開発プロセスの運用に転用します。
具体的には、CLAUDE.mdのようなAIに常時読ませるプロジェクトファイルを、指示書ではなく憲法として書きます。書くのは指示ではなく、判断基準です。
| 指示として書いた場合 | 判断基準として書いた場合 | |
|---|---|---|
| 記述 | この画面の確定ボタンは右上に置く | この業務では誤操作防止より操作速度を優先する。ただし金銭が動く確定操作と、削除操作は例外とする |
| 効く範囲 | その画面だけ | すべての画面と、今後追加される画面 |
| 書かれていない場面 | 判断材料がなく、AIが自分の一般論で埋める | 原則から演繹して埋められる |
| 外れたとき | その画面を直して終わる | 条文を直すと、以後の全画面に反映される |
指示は、書いた場面にしか効きません。判断基準は、書いていない場面にも効きます。AIが空白を埋めるという性質は変えられないので、埋めるときに参照するものの側を変える、という考え方です。
なお、この進め方はスペック駆動開発の対極ではありません。何を動かない正本として先に固定するかという設計の問題であり、その整理は仕様駆動か、テスト駆動か、評価駆動かに書いています。本コラムで扱うのは、正本を「文章で書かれた仕様」に置くことをやめた場合に、代わりに何を置くかという各論です。
憲法として運用できるかどうかは、どの抽象度で書くかでほぼ決まります。抽象から具体へのグラデーションで整理すると、5段階になります。
| レベル | 内容 | 条文の例 | 扱い |
|---|---|---|---|
| L1 | 価値観 | ユーザーの入力を信用しない / 業務が止まることを、データが少し汚れることより重く見る | 前文。単体では解釈がぶれる |
| L2 | 裁定基準(衝突したときの優先順位) | 操作速度と誤操作防止が衝突したら操作速度を優先する。ただし金銭が動く確定操作と削除操作は確認を挟む / 締めの整合と入力の手間が衝突したら、締めの整合を優先する | 憲法の主戦場。AIに考えさせる層 |
| L3 | 不変条件・禁止事項 | 物理削除は書かない、論理削除とする / 金額の計算に浮動小数点型を使わない / 新規ライブラリの導入は提案までとし、実装しない | 解釈の余地なし。作りすぎの防止はここで効く |
| L4 | 規約・パターン指定 | 日付の扱いはdayjsに統一する / エラーは例外ではなくResult型で返す | 機械化(lintや型)までの仮住まい |
| L5 | 個別仕様 | この画面の確定ボタンは右上に置く | 憲法に入れたら負け。チケットに書く |
境目の判定基準は一つで足ります。「半年後の別の機能でも、そのまま使えるか」。使えるならL3以上なので憲法へ、使えないならL5なのでチケットへ。この一問だけで、憲法が個別仕様の物置になることを防げます。
そして拡張解釈が最もよく働くのはL2です。L3以下は解釈の余地がないので安全な代わりに、書いていない場面には効きません。L1は解釈が広すぎて、同じ条文から反対の結論も出せてしまいます。AIに考えさせたいことはL2で書き、考えさせたくないことはL3で書く。これがこの方式の中核です。
AIに考えさせたいことはL2で書き、考えさせたくないことはL3で書く。L5は憲法に入れない。
憲法の分量は、そのままAIが毎回読む量になる。長くなるとL2の条文の効きが薄まる。
運用上の注意を一つ加えます。L4は溜めないことです。規約は本来lintと型で機械的に強制すべきもので、憲法に書くのは強制手段が用意できるまでの仮住まいです。L4が増えるとファイル全体が長くなり、AIが毎回読む量が増えて、L2の条文の効きが薄まります。lintルールに落とせたL4は、憲法から消します。
憲法を書いても、最初から十分な条文が揃うことはありません。それでも運用が成り立つのは、次の二つを回すからです。
差分そのものとは別に、「仕様に書かれていなかった箇所を、どう解釈して実装したか」を一覧で出させます。人間が確認するのはコード全量ではなく、この一覧です。様式は次の形で運用しています。
## 解釈の宣言（この差分で、仕様に書かれていなかった箇所）
1. 締め処理後に到着した伝票の扱い
採った解釈: 受領日ではなく締め日で判定し、翌月分として登録する
根拠: L2-03「締めの整合と入力の手間が衝突したら、締めの整合を優先する」
外れたときに壊れる範囲: 月次集計、督促対象の抽出、前月比の表示
2. 一覧画面の既定の並び順
採った解釈: 更新日の降順
根拠: 該当する条文なし（L5相当と判断し、暫定でこの解釈を採用）
外れたときに壊れる範囲: この画面のみ
重要なのは「根拠」と「外れたときに壊れる範囲」の二列です。根拠に「該当する条文なし」と書かれた項目は、憲法に条文を足すべき候補がそのまま並んだリストになります。壊れる範囲の列は、確認の優先順位を決めるために使います。範囲が「この画面のみ」なら流し、「月次集計と督促」まで及ぶなら止めて確認します。頼んでいない実装、つまり作りすぎも、根拠のない解釈としてこの一覧に現れます。
解釈が間違っていたときに、その場のコード修正で終わらせません。憲法に条文を一行足します。これを回すと、憲法は「最初に書き切る文書」ではなく「解釈の失敗から育つ文書」になります。第2章で棄却した「書き切れない」という問題は、書き切らずに済ませることで消えます。
ただし、外れをすべて条文にすると憲法が肥大化してL4と同じ問題を起こすので、還流には条件を付けています。
人が確認するのはコード全量ではなく解釈の一覧で、外れた解釈は条文として憲法へ戻る。
憲法は最初に書き切る文書ではなく、解釈の失敗から育つ文書になる。
ここからが本題です。第2章で棄却したのは「人間が書き切ること」であって、仕様の価値ではありませんでした。なら、書くコストがほぼゼロになったAIに書かせればよいことになります。棄却理由だけが消えて、仕様の利点である「判定基準の明文化」は残ります。
ただし、AIに文章の仕様書を書かせても検証にはなりません。読んで頷いて終わりです。文章は、読み手が自分の理解で補完しながら読めてしまうため、AIの理解と人間の理解がずれていても、ずれたまま合意が成立します。
委ねるべきは、受入テストケースの生成です。憲法と要求から、「この振る舞いが正しいはずだ」というテストケース群をAIに先に書かせます。テストケースは実行可能な仕様であり、AIが業務をどう理解したかが、検証できる形で外に出てきます。文章の仕様書との違いはここだけですが、この違いが決定的です。
運用の各論を書きます。
入力は、憲法と要求と既存のケース一覧の三つです。既存の一覧を渡すのは、粒度と語彙を揃えさせるためです。渡さないと、機能ごとに粒度の違う一覧が出てきて、人が比較できなくなります。
先に出させるのは、ケース名の一覧だけです。テストコードの本体も、実装も、この段階では書かせません。本体まで書かせてしまうと人が読む量が増え、第1章のレビューが溜まる問題に戻ります。人が確定した後で、確定した一覧に対して本体と実装を書かせます。
ケース名は業務の言葉で、一行で書かせます。「締め日当日に受領した伝票が、当月分として登録される」という粒度です。ケース名にモックやDIといった実装の語彙が出てきたら、粒度が細かすぎる合図なので、その塊はまとめさせます。
並べる軸を指定します。正常系、業務ルールの境界、異常系、権限、締めと時刻。この五つの軸で章立てさせると、業務システムで穴が空きやすい場所が見出しとして残るため、後の確認で「その章が丸ごとない」ことに気づけます。
そして、人間の仕事が次のように変わります。
第1章で挙げた四つの痛みは、すべてこの一覧の境界で回収されます。作りすぎは「どのテストケースがその実装を要求したのか」と問えるため、要求元のないコードとして構造的に露見します。網羅性の不足は一覧の穴として、コードを読むよりはるかに見つけやすい形で現れます。使い勝手の問題は、操作の優先順位をL2に書いておけば、一覧を生成する段階で反映されます。レビューの滞留は、人が読む対象がコードから一覧に変わることで解消します。
テストケース名の一覧を人が確定する、と書きました。ここが人間に残る最重要の仕事なので、何をどう見るのかを具体的に書きます。見るのは三つです。
第一に、穴。業務上あるはずのケースが一覧にないことを探します。目で追って探すのではなく、業務の軸で数えます。有効なのは次の五つです。
このうちAIが最も落とすのは訂正と取消です。要求には「登録する」「承認する」と書かれていても、「承認を取り消したときに何が戻るのか」は書かれていないことがほとんどで、この空白は業務を知らないと埋まりません。締めと訂正の二つの章が薄い一覧が出てきたら、まずそこを疑います。
第二に、過剰。誰も要求していないケースを探します。判定は一件ずつ、「このケースは、誰のどの業務が困るから必要なのか」を問うだけです。答えられないケースは削ります。削ったケースが実装を要求していたなら、その実装ごと消えます。作りすぎを、コードのレビューではなく一覧の段階で止められるのはこのためです。
第三に、ずれ。ケース名が業務の言葉になっていないものを探します。「ステータスが2から3に遷移する」と書かれていたら、AIがデータの形は理解したが業務の意味を理解していない合図なので、「差戻しされた申請を、担当者が修正して再提出する」に直させます。この直しは表現の問題ではなく、AIの理解の修正です。名前が業務の言葉で書けないケースは、たいてい中身も業務と対応していません。
確定の作法も決めておきます。確定した一覧には版を付け、以後の実装はその版への適合で判定します。そして、実装の都合で一覧を書き換えることを禁じます。テストが通らないときに直すのは実装であって、一覧ではありません。一覧を変更するのは、業務の理解が変わったときだけで、そのときは版を上げます。生成物の側から正本を書き替えさせないという規律で、これが崩れると一覧は実装の記録に成り下がります。
人が必ず通る関門は、憲法の条文の変更と、テストケース一覧の確定の二箇所である。
人の仕事が、執筆と精読から、確定と裁定へ移る。
「AIが仕様を書き、AIが実装し、AIが検証するなら、全部が同じ間違いをしたときに誰も気づかないのではないか」——この批判は必ず来ますし、正当です。
答えは、人間の関門をテストケース一覧の確定に置くことです。コード全量の精読は放棄しますが、業務知識で検証しやすい形の関門を一つ、必ず人間が通します。共倒れはこの一点で断ち切ります。関門を一箇所に絞るからこそ、そこに業務知識のある人の時間を集められます。
実務では、これに三つの補強を足しています。
この三つを足したうえで、人間が通す関門は「憲法の条文の変更」と「テストケース一覧の確定」の二箇所になります。統制の重心が、成果物を全部見ることから、判断基準と合格基準を握ることへ移ります。
整理します。
スペック駆動開発は間違っていませんでした。重かったのは「白紙から人間が書き、全員で読み合わせる」という執筆と合意の形式であって、仕様そのものではありません。執筆はAIへ、確定は人間へ。この分業に組み替えた時点で、スペック駆動の利点である判定基準の明文化だけが、軽い形で手に入ります。
そして、書き切れない部分を扱うのが憲法です。仕様に書かれなかった空白は必ず残りますが、そこにAIが乗せる解釈を、L2の裁定基準が導きます。外れた解釈は条文として還流し、次の空白の埋め方が変わります。仕様が扱うのは書けた部分、憲法が扱うのは書けなかった部分という分担です。
「スペック駆動に疲れた」の疲れの正体は、書く作業でした。書くのをやめて整える側に回ると、同じ利点が軽くなります。
ただし、これは「速く書く」自動化の話ではありません。人間の仕事を、執筆と精読から、確定と裁定へ移し替えるプロセスの組み替えです。実装のAI化はもう終わった話で、次にプロジェクトを短縮するのは、仕様の生成と検証をAIに委ね、人間の関与を「憲法の維持」と「テストケース一覧の確定」の二点に絞ることだと考えています。
最後に、まだ検証できていない論点を仮説として置いておきます。
仮説1: 次のボトルネックは、顧客側の意思決定に移ります。制約は消えず、移動します。確認と合意の工程をここまで痩せさせたとき、次に全体の速度を決めるのは、要件を出し確定の判を押す顧客側の意思決定速度と、テスト・受入の工程になるはずです。開発側だけが速くなったプロジェクトで何が起きるかは、これから観測したいところです。
仮説2: 憲法は一本でよく、モデルの違いはタスクの割り当てで吸収します。モデルの解釈力に合わせて憲法を分岐させる案も考えましたが、管理する文書が増えるうえ、モデルの癖への最適化は世代交代で陳腐化します。憲法には「モデルが変わっても書き直さなくてよいことしか書かない」と定義し、代わりに先頭に想定モデルを明記して、実行モデルとずれたら警告を出す。分岐ではなく検知で足りる、と今は考えています。
仮説3: 一番難しいのは技術ではなく、保証モデルの交換を組織が受け入れることです。この方式の本質は、品質保証の根拠を「人が全部見た」から「仕組みを通った」に置き換えることです。自分の裁量が及ぶ範囲なら今日から始められますが、事前承認の文化が強い組織では、運用ログ——ゲート通過後の不具合率、人間のレビューでの追加検出率——を証拠として貯め、データで交渉するほかありません。不可逆な判断への責任だけは、どんな仕組みでも人間から消えません。逆に言えば、ボトルネックをその一点まで痩せさせることが、この進め方の到達点です。
これらは実プロジェクトで回しながら検証し、続編で報告します。工程との対応づけはウォーターフォールでAI駆動開発を回すに、テスト工程そのものの組み替えはClaude × AWSで変わるAI駆動開発のテストに整理しています。
Chapter Techでは、開発プロセスの現状分析から、判断基準の設計、レビューと承認の関門の再配置、効果測定までの定着支援をAI Delivery Scope+として提供しています。自社のCLAUDE.mdが指示書になっていないか、という点検の段階からで構いません。お問い合わせからご相談ください。