AI駆動開発の事例はプロダクト開発やアジャイルの文脈で語られるものが多く、工程を承認で固定していくウォーターフォールにはそのまま当てはまりません。各工程の成果物は短時間で出るようになりましたが、その成果物を次工程の前提として固定する承認の責任は、AIに移せないためです。本コラムでは、要件定義から設計・実装・テストまでを通して、どの工程で誰が何に責任を持つのか、その責任を成立させるためにAIの生成をどう統制するのか、そして承認者が判断できるレビュー文書をどう作るのかを扱います。
AI駆動開発の事例は、プロダクト開発やアジャイルの文脈で語られるものが多くなっています。動くものを早く出し、使いながら直す。この前提は、ウォーターフォールにはそのまま当てはまりません。
ウォーターフォールが工程を分けているのは、作業を区切るためではなく、前工程の成果物を承認して次工程の前提として固定するためです。要件定義書が承認されれば設計はそれを前提に進み、基本設計が承認されれば詳細設計と実装がそれを前提に進む。後から前提が動けば変更管理に乗る。工程の数だけ、この固定が繰り返されます。
生成AIが変えたのは、各工程の成果物が出るまでの時間です。要件定義書も、設計書も、実装コードも、テストケースも、短時間で形になります。しかし固定そのもの——承認の判断と、その責任——は移せません。
そして工程を追うごとに、次の性質が効いてきます。
行き着くのは「承認したが読んでいない」という状態です。要件定義で起きればテストまで、基本設計で起きれば実装まで持ち越されます。
AIを工程に入れるとき、生成の方法より先に決まっている必要があるのは、どの工程で誰が何に責任を持つのかという設計です。
工程が変われば、成果物も承認者も変わります。AIが担える範囲も同じではありません。
工程間の承認が、次工程の前提を固定する。顧客側の判断を要するのは要件定義と受入テストの両端で、中間工程は承認者がベンダー側に閉じる。
この配置には、実務上の偏りが2つあります。
ひとつは、顧客側の判断を要するのが実質的に要件定義と受入テストの両端だということ。基本設計から結合テストまでは、承認者がベンダー側に閉じます。中間工程は自社の開発標準の中で統制を決められますが、両端は顧客との合意事項になるため、AI導入の難所は両端に集中します。
もうひとつは、工程が進むほど承認の対象が「文章」から「機械的に判定できるもの」へ移ることです。要件定義書の妥当性は読んで判断するしかありませんが、実装の妥当性はテストの合否で示せます。AIの生成を検証する手段も、下流ほど揃っています。裏を返せば、上流ほど人の判断に依存し、上流ほど導入の設計が要る。以下、要件定義の比重が重くなるのはこのためです。
要件定義書を一冊にまとめ、一人の責任者が承認する形は、AIが入る前から無理を抱えていました。業務要件・機能要件・非機能要件・移行要件は、判断できる人がそれぞれ違うからです。
AIを入れると分量が増えるため、この無理が先に表面化します。対応は、成果物を承認単位で割ることになります。章立てとして割るのではなく、一人の責任者が内容を読んで是非を判断できる範囲で割る、という意味です。
要件定義書を一冊のまま一人が承認する形をやめ、一人の責任者が読んで是非を判断できる範囲で割る。
承認単位を割らないまま分量だけが増えると、承認は一括で押す形に戻り、責任は形式だけのものになる。
割ることには副次的な効果があります。承認者ごとに読む分量が減り、判断に使える時間が増えます。逆に、承認単位を割らないまま分量だけが増えると、承認は一括で押す形に戻り、責任は形式だけのものになります。
割ったあとに残るのが、誰の判断も付かない要件の扱いです。業務所管部門の責任者に非機能要件の妥当性を問うても、答えは返ってきません。判断できない事項を承認範囲から外し、担当が付いていない要件を一覧として見えるようにしておくと、後工程で「誰も見ていなかった要件」が残らなくなります。
同じ考え方は下流にも適用できます。基本設計なら画面・帳票・バッチ・データモデル・外部インターフェースで承認者が分かれ、テストなら単体・結合・総合・受入で合否を判定する人が分かれます。工程ごとに「一冊」で扱わないことが、責任を実質のあるものにします。
AIの出力が誤る原因は、能力よりも入力側にあることが大半です。要件定義でよく見るのは次の3つです。
人はこの状況でも、経験から暗黙に版を選び、確度の低い情報を割り引いて読みます。AIは渡された入力を等価に扱うため、この割引が効きません。
コンテキストの設計とは、何を正本とするかを人が先に決める作業です。入力は3つに分けると扱いやすくなります。
| 区分 | 中身 | 生成での扱い |
|---|---|---|
| 正本 | 承認済みで版数が確定した文書、確定した用語集 | ここからの記述は成果物として書いてよい |
| 未確定の素材 | 議事録、ヒアリングメモ、現行画面の実物 | 候補にとどめ、確定した記述にしない |
| 参考 | 他社事例、業界標準、一般的なガイド | 抜けの指摘には使い、これを根拠に書かない |
この区別がないと、一般論としては妥当でもこの案件には該当しない記述が混ざります。文章として自然なため読んでも気づきにくく、レビューで落ちにくい種類の誤りです。
工程が進むと、この構図は変わります。要件定義の段階では正本が乏しく、素材と参考ばかりが手元にあります。基本設計では承認済みの要件定義書が正本になり、実装では設計書が、テストでは受入基準と設計書が正本になる。下流ほど正本が厚くなり、生成の確度は上がります。
裏返すと、要件定義でのコンテキスト設計の失敗は全工程に伝播します。誤った要件が正本として承認されれば、設計以降のAIはそれを疑いません。上流ほど人の判断が要るという先ほどの偏りは、ここでも同じ形で現れます。
対になるのが、出典を出力の必須項目にすることです。記述の一件ごとに、どの入力のどこから来たのかを残しておくと、参考区分を出典とする記述だけを抜き出して確認できます。レビューにかかる時間は、ここでほぼ決まります。
用語集も、正本として先に固定する対象です。呼び方が工程をまたいで揺れると、要件・設計・テストの対応が取れなくなります。人が書いても起きる問題ですが、AIは指摘されるまで揺れ続けます。
コンテキストを整えても、成果物を一括で生成させると、AIは判断できない箇所を埋めます。埋めた箇所は文章として自然なため、読んでも仮定だとは分かりません。
これを止めるのは指示の書き方ではなく、実行の枠組み側の制約です。AI活用の重心をプロンプト・コンテキスト・ハーネス・ループの4層で整理したとき(Claude Code プロジェクトパックで扱った区分です)、全工程に共通して効くのはハーネス層の次の4項目になります。
1. 判断できない箇所は、仮定として出力させる
入力から判断できない事項を埋めさせず、未確定の問いにIDを振って台帳に載せます。本文には、仮定であることと、その仮定が外れた場合に影響する項番を書く。AIにとって「分からない」と出力するのは自然な振る舞いではないため、出力形式の側に仮定欄を必須項目として持たせる形になります。
2. 生成と検証を分ける
生成した実行に自分の出力を検証させると、整合しているという結論しか出てきません。別の実行に、入力と出力の突き合わせを担当させます。出典のない記述の抽出、正本との矛盾の検出、受入基準が合否を判定できる書き方になっているか。いずれも機械的に確認できる項目です。
3. 出力形式を固定する
項番体系、受入基準の書式、記載必須項目を先に決めます。形式が揺れると版間の差分が取れず、レビューは毎回の全文読み合わせに戻ります。
4. 承認済み範囲を全面再生成しない
4つのうち最も効くのはこれです。修正は差分で行い、承認済みのファイルは書き込みの対象から外します。承認済みの内容が黙って書き換わると、承認の記録が指している対象が消え、記録そのものが無効になります。実務上は、承認済みの版を読み取り専用にして、変更は別ファイルの変更提案として出させる形が扱いやすくなります。
いずれも運用ルールとして配布しても守られません。許可設定、出力テンプレート、ファイルの権限といった、迂回に手間がかかる場所に置くことになります。
入力の区分から承認までを一本の流れに置くと、統制点の位置は次のようになります。この形は工程が変わっても同じで、入れ替わるのは正本の中身と承認者だけです。
工程が変わっても形は同じで、入れ替わるのは正本の中身と承認者だけ。
承認済み範囲は全面再生成しない。承認済みの内容が黙って書き換わると、承認の記録が指している対象が消える。
この配置で押さえているのは2点です。ひとつは、生成の入力になるのは正本と未確定の素材だけで、参考は起案に回さないこと。もうひとつは、承認された版が正本に昇格し、次の生成の入力になることです。承認が手続きで終わらず、次工程の入力を確定させる工程として流れの中に入ります。
工程別の効きどころも書いておきます。基本設計ではデータモデルの変更を特定の担当の管轄に限定し、他は提案のみとする。実装では、実装した実行にその実装のテストを書かせない。テストでは受入基準と設計書を正本とし、出来上がったコードから逆算したテストを作らせない。いずれも2番目の「生成と検証の分離」を、工程の事情に合わせて具体化したものです。
生成された成果物をそのまま回覧しても、承認は速くなりません。分量は増やせますが、承認者の時間は増えないためです。
承認者がレビューで実際にやっているのは、全文の検査ではなく、前回から変わった箇所の確認と、決めなければならない事項の判断です。網羅性を担保する本文と、判断を担保する文書とでは、求められる形が違います。
網羅性を担保する本文とは別に、判断材料だけを取り出した版を用意する。分量は増やせるが、承認者の時間は増えない。
本文は承認者の言葉で書く。要件定義なら業務の言葉、基本設計なら画面・帳票・業務フローの言葉、受入テストなら業務シナリオの言葉。
本文は、承認者の言葉で書きます。要件定義なら業務の言葉、基本設計なら画面・帳票・業務フローの言葉、受入テストなら業務シナリオの言葉です。システム用語への対応は別表に落とす。承認者が自分の語彙で読めない文書は、判断がベンダー側の解釈に依存します。
分量には上限を先に決めておくと扱いやすくなります。AIは分量を増やす方向に働くため、承認単位あたりのページ数を決めておくと、詳細は自然に付録へ落ちます。
もうひとつ、生成したことを隠さないという点があります。どの記述が生成で、どこを人が確認したのかを版の属性として残す。監査や検収で問われるのは「誰が書いたか」ではなく、「誰が確認し、何を根拠に承認したか」だからです。
各工程の中を3つに分けると、AIの効き方の差がはっきりします。前工程の成果物と現行資料を棚卸しする素材整理、成果物を書く記述、承認者との読み合わせと判断にあたる合意の3つです。
各工程を素材整理・記述・合意の3区分に分けると、AIの効き方の差がはっきりする。
工期の短縮率は3区分の構成比で決まる。短くなった記述の時間は、全体期間の圧縮ではなく承認の往復回数に振り向けるほうが噛み合う。
大きく縮むのは記述が支配的な工程です。基本設計・詳細設計・実装は、正本が揃っていれば記述の比重が大きく、効果もそのまま出ます。単体・結合テストも、受入基準と設計書が正本として機能していれば同様です。
縮まないのは合意が支配的な工程、つまり要件定義と受入テストです。複数部門にまたがり決裁が多段になるほど、この比重は上がります。関係部門が限られ現行資料が揃っている案件なら要件定義でも記述の比重は大きくなりますが、それは条件の良い案件だという理解が要ります。
工期の短縮率は、この構成比で決まります。見誤りやすいのは、記述が速くなった分だけ全体の期間を詰めるスケジュールです。合意の期間まで削ると、要件定義の後半とテストの終盤で承認が追いつかなくなります。短くなった記述の時間は、往復の回数に振り向けるほうが噛み合います。同じ期間で承認者に見せる回数を2回から4回に増やすと、1回あたりの差分が小さくなり、レビューの精度が上がります。
工程間の接続も、ここで決まります。要件定義の版、承認者、各要件の出典、仮定の解消記録が残っていれば、設計・テスト・検収のトレーサビリティはその上に載ります。ここが空白のまま設計以降で記録を取っても、大元の根拠には辿り着けません。
順序としては、生成の仕組みより先に決まっている必要がある項目が3つあります。工程を問わず同じです。
この3つが決まっていれば、生成側の実装は設定作業の範囲に収まります。決まらないまま生成から入ると、出てくるのは体裁の整った、責任の所在が不明な成果物です。
実際の案件では、既存の開発標準、成果物テンプレート、検収条件があるため、この当てはめは案件ごとの作業になります。Chapter Techでは、工程統制を含む開発標準の策定とAI駆動開発の定着支援をエンタープライズDX & FDE支援サービスとして、受託開発・SES企業のAI駆動開発シフトをDelivery Scope+の並走モデルとして提供しています。自社の開発標準にどう当てはめるかは、お問い合わせからご相談ください。
工程統制の実装はClaude Code プロジェクトパックとしてGitHubで公開しています。開発プロジェクト側ではなく組織側の統制については、AI駆動開発の最初のハードルは社内承認で扱っています。