AIエージェントの要件定義で変更管理は何から決めるべきか
# AIエージェントの要件定義で変更管理は何から決めるべきか
AIエージェントの要件定義は、完成した瞬間に終わる仕事ではない。むしろ、動かし始めてから変更が増える。
最初は「この業務を要約してほしい」だったのに、次の週には「承認が必要なときだけ止めてほしい」に変わる。さらにその次は、「入力に議事録だけでなく画面キャプチャも入れたい」となる。ここで変更管理の型がないと、要件書もプロンプトも、いつの間にか別物になる。
この仕事で本当に先に決めるべきなのは、機能そのものよりも「変更をどう扱うか」だと思っている。
AIエージェントの要件定義で変更管理が崩れるのは内容より入口
変更がうまく回らない現場では、たいてい「少し直しておいて」がそのまま流れていく。ところが、AIエージェントは人間よりも変更の影響を広く受ける。
入力が変われば出力が変わる。権限が変われば実行できる範囲が変わる。停止条件が変われば、同じタスクでも止まるタイミングが変わる。つまり、1つの変更が複数の設計要素に波及する。
だから、変更管理は「どこを直すか」より先に、「その変更はどの種類か」を分けるところから始めたほうがいい。
- プロンプトだけの変更か
- 入力スキーマの変更か
- 出力フォーマットの変更か
- 承認フローの変更か
- 停止条件や例外処理の変更か
ここを分けずに進めると、変更の粒度が毎回あいまいになる。あいまいなまま更新すると、次回の修正理由も残らない。
AIエージェントの 要件定義で先に決める4つ
AIエージェントの要件定義における変更管理では、最低でも次の4つを先に決めておくと崩れにくい。
1. 変更の発生源
変更はどこから来るのかを固定する。
たとえば、現場メモ、議事録、顧客の指摘、PoCでの実行結果、営業からの修正依頼など、入口が複数あるときは、どれを正式な変更起票にするのかを決めておく必要がある。
入口が増えるほど、変更の責任も曖昧になる。まずは「誰が、どの形式で、どこに書いたら変更扱いにするか」を決める。
2. 差分の書き方
変更管理で一番大事なのは、差分が読めることだ。
「ここを修正」だけでは足りない。修正前と修正後、そして変更理由が並んでいないと、後から見た人が判断できない。
ここでは、差分を次のように書くと扱いやすい。
- 変更前
- 変更後
- 変更理由
- 影響を受ける要件
- 再テスト観点
3. 影響範囲
1行の修正でも、実際には複数の箇所に波及する。
入力が変われば、評価設計も変わる。出力が変われば、確認観点も変わる。権限が変われば、停止条件の見直しが必要になる。ここを見落とすと、修正したつもりが、別の場所で古い前提が残る。
この意味で、AIエージェントの要件定義は「仕様の文章」ではなく「依存関係の管理」に近い。
4. 再合意の相手
変更は、書き換えれば終わりではない。
誰が再確認するのか、どこまで人間が責任を持つのかを決めておかないと、AIが勝手に更新したように見える危険がある。
特に、承認者、業務オーナー、実装者、運用担当で見ている観点が違う場合は、再合意の相手を最初から一覧にしておくといい。
版管理だけでは足りない理由
版番号を振るだけでは、変更管理は成立しない。
なぜなら、版番号は「何回更新したか」は示せても、「なぜ変えたか」「誰が見直すか」「どこまで影響したか」までは伝えないからだ。
実際、公開情報を見ても、考え方はかなり近い。たとえば AIOps Rail のAIエージェント向けガードレール は、想定外の変更をそのまま通さず、制御を挟む発想だし、Microsoft Intune の変更レビュー用エージェント も、変更を確認してから進める前提になっている。ServiceNow のAIエージェント変更 も、変更保存だけでなくテストやバージョン管理を含めて扱う。Acsim の要件定義における変更管理 も同じで、変更を計画的に管理して初めて影響を抑えられる。
要するに、AIエージェントの変更管理は「更新」ではなく「再確認」の設計だ。
そのまま使える変更管理テンプレート
このテンプレートを1件ずつ埋めるだけでもだいぶ変わる。
- 変更理由
- 変更前の要件
- 変更後の要件
- 影響を受ける入力
- 影響を受ける出力
- 影響を受ける権限
- 影響を受ける停止条件
- 再テスト観点
- 再合意が必要な人
- 戻し先
このテンプレートのいいところは、AIに読ませても、人間に見せても同じ順番で確認できることだ。
Kakusillでも、会議メモや修正依頼をただ並べるのではなく、差分と影響を先に構造化するほうが扱いやすい。変更管理の目的は、作業を増やすことではなく、後戻りを減らすことにある。
Atsumellの視点
私たちがAI開発パートナーとして見ているのは、要件そのものよりも、要件が変わったときに現場が止まらないかどうかだ。
関連する記事として、次の3本を先に読んでほしい。
この3本を先に読んでおくと、変更管理は単独の話ではなく、入力・依存関係・版管理の上に乗る話だと分かりやすい。
もし現場で「変更のたびに毎回迷う」「レビューの基準が人によって違う」「どこまでAIに任せてよいかが曖昧」という状態なら、要件定義の進め方を見直すタイミングに来ている。Atsumellでは、こうした変更の入口と再合意の設計を、Kakusillを使って構造化しながら整理している。
まずは変更を1件だけ取り出して、理由・差分・影響・再合意先を書いてみてほしい。そこから先は、かなり見通しがよくなる。
