この記事について
この記事は、生成AIを活用した自動生成フローで作成しています。OpenAIとGoogleの公式情報を確認し、旧版を現在の実務向けに見直しました。検証ステータス：📘 公式情報確認済み／個別業務での精度は未検証
複雑な要件定義では、最初から完成版の仕様書を生成するより、要件を小さな管理単位へ分け、根拠と状態を固定してから統合する方がレビューしやすくなります。
最初に「要件台帳」を作る
各要件へ一意のIDを付け、少なくとも「要件内容」「根拠資料」「確定／未確定」「関連する要件ID」「受入条件」を記録します。LLMには文章をきれいにする前に、この台帳を埋めさせます。
ID: R-014
要件: 承認者が申請者本人の場合は自動承認しない
根拠: 業務規程 4.2
状態: 確定
関連: R-008, R-021
受入条件: 代理承認者へルーティングされること未確定事項を推測で埋めない
資料に書かれていない条件は「不明」「要確認」として残します。生成AIが一般的な業務慣行を補ってしまうと、それが本当の要件なのか後から判別できません。
モジュール間はインターフェース契約でつなぐ
モジュールごとに入力、出力、エラー、責任範囲を固定し、他モジュールとの接続点をIDで参照します。文章の相互参照だけに頼らないのがポイントです。
形式はStructured Outputs、意味は別検証
JSONなど機械処理する出力では、利用可能なAPIのStructured OutputsやJSON Schemaを使って型と必須項目を固定します。ただし、スキーマに通ったことは要件が正しいことを意味しません。ID重複、参照切れ、未確定事項の残存、受入条件の不足などはアプリケーション側でも検証します。
実務フロー
- 元資料から要件候補を抽出する。
- 各要件へIDと根拠を付ける。
- 未確定事項を別表へ分離する。
- モジュールごとの入出力契約を作る。
- 機械検証できる項目をコードで確認する。
- 最後に人間が意味と優先順位を確認して仕様書へ統合する。
まとめ
コンテキストを長くすること自体が目的ではありません。中間成果物を固定し、何が事実で何が未確定かを追跡できる状態にすることが、複雑な要件定義での再現性を高めます。
公式情報・一次情報
この記事の更新履歴
- 2026-09-13 追加：要件台帳、受入条件、未確定事項、機械検証の実務フローを追加。
- 2026-09-13 変更：長文プロンプト中心の構成から、中間成果物を固定する要件管理中心の構成へ変更。
- 2026-09-13 削除：内部style_prompt、本文H1、詳細な思考過程の出力要求、根拠のない精度保証を削除。
