要件定義書はAIへの「実行指示」になる――Hakuhodo DY ONEが基幹系で得たAI駆動開発の現実

AI駆動開発は、コーディングを速くするだけの話ではない。AIが設計からテストまでを短いループで回すなら、人間は要件定義の段階で業務判断、設計方針、完了条件、品質基準まで決める必要がある。Hakuhodo DY ONEの中原 柊氏が、数億円規模の基幹会計系システムの実践から、品質ゲート、予算、契約まで組み替わる現実を示した。

AIが設計からテストまでを担うと、要件定義で決めることが増える

AI駆動開発では、AIの役割がコーディングだけでなく、設計やテストまで広がる。その分、人間が要件定義で決める内容も増える。AI要件定義サミット2026で、Hakuhodo DY ONEの中原 柊氏は、この変化を実際の開発事例をもとに説明した。

講演で紹介された案件は、数億円規模の基幹会計系システムである。マルチベンダー体制のもと、VSCode、Cline、Amazon Bedrockなど一般に利用できるサービスでAI環境を構築した。特殊な自社モデルの性能ではなく、既存の企業システム開発をどう組み替えるかが題材だった。

従来のV字モデルでは、要求定義、要件定義、基本設計、詳細設計、製造、各テストを人が工程ごとに進める。各工程に人が関わるため、詳細な設計方針や次の工程の進め方は、前の工程を進めながら固めることができた。

中原氏が示したAI駆動開発では、この前提が変わる。要件定義の成果物をAIに渡すと、AIは基本設計、詳細設計、製造、単体テスト、結合テストまでを「AI Loop」として一気に進める。途中の設計書やコードを人が逐一確認するのではなく、結合テストまでの結果がまとまって人に戻る。

アジャイル開発も短い周期で設計、開発、テストを繰り返すが、中原氏が強調した違いは、そのループを人ではなくAIが担う点だ。この運用では、工程の途中で人が次の進め方を決める機会がない。そのため、どの方針で設計させ、どの成果物を残させ、何をもってテスト合格とするかを、AIへ渡す前の要件定義で決めておく必要がある。人間の判断が不要になるのではない。後工程で行っていた判断を、要件定義へ前倒しするのである。そんな意味で「要件定義のあり方自体が変わっていく」と中原氏は語った。

AIを動かす3点セットは、業務ルール・設計制約・完了条件

要件定義書の読み手も変わる。人間同士の合意文書であることに加え、AIが設計、実装、テストを進めるための入力になる。画面キャプチャを貼ったExcelや、人には分かりやすくても機械が解釈しにくい業務フローだけでは足りない。AIが作業範囲と判断基準を読み取れる粒度へ変換する必要がある。

実践では、現行の仕様書、ソースコード、データベース定義からAs-Isの業務フローと設計をAIで起こし、人が変更要件を加える。共通辞書やTo-Beの業務ルールを介して、要件定義書を生成する。さらに、後工程の進め方を定めるシステム全体方針書、実行制御方針書まで要件定義フェーズで用意した。

AI Loopを回す3点セットは、業務ルール、アーキテクチャ方針、テスト仕様である。業務ルールは判断基準を、アーキテクチャ方針は設計上の制約を伝える。テスト仕様には「ある条件でこの操作をしたら、こうなる」と期待する振る舞いを記し、その表現にGherkin形式（Given・When・Thenという自然言語でシステムの動作やテスト仕様を記述するフォーマット）を使った。AIに自由に作らせるのではなく、何を守り、何ができれば終わりかを先に渡す手法だ。

講演資料では、設計から単体テストまで、かつ限定領域での実測値として、AI Loopによる工数の「最大90％削減」を掲げた。一方、中原氏は講演で「理論上のポテンシャル」と表現し、現在の全プロジェクトで直ちに得られる数字ではないと補足した。AIと人が新しい進め方に順応し、品質上のリスクを扱えることが最大効率を実現する条件になる。

また、90％という値はプロジェクト全体の予算削減率ではない。要件定義、環境準備、人によるレビュー、契約調整などは対象の外にある。AI Loopの内側だけを速くしても、上流の判断や品質確認が詰まれば、案件全体の期間は同じ割合では縮まらない。効果測定も、工程と領域を分けて設計する必要がある。

品質ゲートを動かすと、予算と契約も動く

AIが大量の中間成果物を作るようになると、人間が設計書やソースコードをすべて読む方法は速度が追いつかなくなる。中原氏が紹介した実践では、中間成果物を記録し、業務要件を人がレビューする。生成手順を標準化し、どの要件からどの成果物が作られたかを追えるようにしたうえで、テスト結果を品質保証の中心へ置いた。ソースコードは原則として逐一確認せず、テストで完了条件を確かめる。

これは品質確認を省く話ではない。どこで、何を見て品質を判断するかを変える話だ。従来の工程末に設けた品質ゲートをそのまま残せば、AIの短いループが人の確認待ちで止まる。テスト駆動開発、人の業務要件レビュー、標準化、トレーサビリティによって、品質保証チームにも「何を見れば合格といえるか」を説明できる状態を作った。

この設計では、人間のレビュー対象もコードよりも上流へ寄る。生成された成果物を後から一つずつ読み直すのではなく、AIが参照した業務ルール、設計制約、完了条件が妥当かを先に確かめる。要件とテストの対応を追えるようにすれば、AIが作った量にかかわらず、何を根拠に合格としたかを説明しやすくなる。

初回の要件定義は、むしろ長くなる。後工程で決めていた設計方針や品質基準を前倒しし、AI環境、責任分界、契約まで組成するためである。一方、そこで作った辞書、方針書、成果物の型は改修時にも再利用できる。

大きく始めず、契約単位と人間の判断点を先に決める

講演で示された実案件では、ユーザー企業が社内稟議を通すため、成果物、金額、納期が見える請負契約を求めた。一方、ベンダーはAI駆動開発の工数、品質、手戻りを従来どおりに見積もることが難しく、請負責任を負いにくい。理論上の工数削減と、契約で保証できる見積もりの間に差が生じた。

中原氏が示した現実解は、スコープが変わりうる場合は準委任を検討し、請負にするならMVPなどの開発単位を小さく刻むことだった。1年分を一括で固定するのではなく、数カ月単位で計測し、品質と工数を見直す。導入テーマも、複雑な基幹系の一括刷新ではなく、範囲が限られ、短い周期で検証できる領域から始める。

ここまで述べた要件定義、品質管理、導入プロセスを、企業が自社で実践するための支援サービスが「Magicx Engineering Intelligence Suite」である。2026年6月、Hakuhodo DY ONEと当時の株式会社ReD.が共同運営していたコンサルティングチーム「Magicx consulting」が提供開始を発表した。エンタープライズに必要なガバナンス、セキュリティ、品質を前提に、要件定義から実装、標準化、内製化までを支援する。ReD.は同年7月1日付で「株式会社Magicx consulting」へ社名変更した。

AI駆動開発を始める際、最初に決めるべきなのは使用モデルだけではない。人が判断する業務、AIへ渡す成果物、品質の合格条件、契約上の責任を一つの設計としてそろえる必要がある。実装が速くなるほど、曖昧さを後工程へ送る余地は小さくなる。要件定義は、合意文書を作る工程から、人間の意思決定をAIが実行できる形へ変える工程に変化するわけだ。