この記事について
この記事は、生成AIを活用した自動生成フローで作成しています。OpenAIとGoogleの公式情報を確認し、旧版を現在の実務向けに見直しました。検証ステータス：📘 公式情報確認済み／個別規程での精度は未検証
長い社内規程を要件定義へ変換するときは、一度のプロンプトで完成版を作らず、抽出・分類・構造化・検証を別工程にします。
1. まず原文から事実だけを抽出する
条件、処理、例外、期限、主体、参照先を原文の位置と一緒に抜き出します。この段階では仕様を補完しません。
{
"source_id": "規程-4.2-03",
"condition": "申請者が役員である",
"action": "個別承認へ回す",
"exception": null,
"status": "confirmed"
}2. 分類は別工程にする
正常系、例外、禁止事項、未確定事項へ分類します。抽出と分類を分けると、「資料にない処理を分類のために作る」混入を見つけやすくなります。
3. Structured Outputsで形を固定する
後続処理がJSONを読む場合は、Structured OutputsやJSON Schemaを使って必須項目と型を固定します。ただし意味の正しさは別途チェックします。
4. 根拠との突合を行う
- 全要件にsource_idが付いているか。
- 同じsource_idから矛盾する要件が生成されていないか。
- 未確定事項が勝手に確定へ変わっていないか。
- 必須条件や例外が抜けていないか。
プロンプト例
目的: 次の規程から要件候補を抽出する。
ルール:
- 原文にない条件を追加しない。
- 各要件に根拠位置を付ける。
- 不明な項目は null とする。
- 要件の妥当性評価はまだ行わない。
入力:
<document>
...規程本文...
</document>公式情報・一次情報
この記事の更新履歴
- 2026-09-13 追加：根拠ID、未確定事項、構造化出力、突合チェックを追加。
- 2026-09-13 変更：CoTを強制する構成から、抽出・分類・検証を分離する構成へ変更。
- 2026-09-13 削除：内部style_prompt、本文H1、詳細な思考過程の出力要求を削除。
