AI要件定義は状態遷移を先に決める
# AI要件定義は状態遷移を先に決める
AIに要件定義を渡すと、画面や文言はすぐ埋まる。だが、状態は意外と埋まらない。
申請中なのか、承認待ちなのか、差戻しなのか、完了なのか。ここが曖昧なまま進むと、AIは「それっぽい流れ」を作る。けれど、運用の現場ではその「それっぽい」がいちばん危ない。
要件定義で先 に決めるべきなのは、画面の数でもAPIの数でもない。どの状態から、何をきっかけに、どの状態へ変わるかだ。
OpenAIの Agent evals は、エージェントの品質を再現可能に測る考え方を置いている。(Safety in building agents) も、危ない流れにはガードレールが要ると明示している。MCP でも Resources と Tools を分けるのは、読む情報と動かす操作を混ぜないためだ。状態遷移を先に決める発想は、この分離とかなり近い。
状態が曖昧だと、AIは通常系だけを最適化する
たとえば「申請フローを作る」という要件があるとする。
AIはだいたい次のようなものを出してくる。
- 申請フォーム
- 確認画面
- 承認ボタン
- 差戻しコメント欄
見た目は整う。だが、これだけでは足りない。
- 申請者が保存できるのはどの状態か
- 承認者が差 戻しできるのはどの状態か
- 差戻し後に編集できるのは誰か
- 承認済みになったら何が止まるのか
ここを決めないと、UIはできても運用が壊れる。AIは入力と文言を埋めるのが得意だが、状態の責任分界までは勝手に引けない。
先に書くべきは状態一覧ではなく、遷移表
状態を列挙するだけだと弱い。効くのは遷移表だ。
最低でも次の5列があると、要件がかなり締まる。
| 現在状態 | トリガー | 次状態 | 実行者 | 止める条件 |
|---|---|---|---|---|
| 下書き | 申請送信 | 申請中 | 申請者 | 必須項目が未入力なら止める |
| 申請中 | 承認 | 承認済み | 承認者 | 権限外なら止める |
| 申請中 | 差戻し | 差戻し | 承認者 | コメントなしなら止める |
| 差戻し | 再送信 | 申請中 | 申請者 | 修正前のままなら止める |
| 承認済み | 取消 | 取消済み | 管理者 | 監査ログが残らないなら止める |
この表があると、画面設計の議論も自然に変わる。
「ボタンを置くか」ではなく、「この状態で押せるか」になる 。
「APIを作るか」ではなく、「この遷移を許すか」になる。
IPAの 要件定義を成功に導く1 2 8 の勘どころ でも、業務フローと振る舞いのモデルを分けて扱う視点が出てくる。状態遷移は、まさにその振る舞い側の芯だ。
状態遷移を先に決めると、AIレビューが速くなる
状態が閉じていると、AIレビューで見るポイントが減る。
見るべきなのは、だいたいこの4つで済む。
- 状態が抜けていないか
- 遷移の起点と終点が矛盾していないか
- 権限外の遷移が混ざっていないか
- 失敗時の戻し先が決まっているか
OpenAIの Agent evals の発想でいうなら、ここはテストケース化しやすい。
「承認済みから編集しようとしたら止まる」
「差戻し後に再申請したら申請中へ戻る」
「権限外ユーザーが取消を押したら失敗する」
こうしたケースが書ける時点で、要件はかなり強い。
逆に、状態が曖昧だとレビューは長引く。
「たぶんここはOKです」
「いや、そこは今の運用だと微妙です」
「じゃあ例外で……」
この会話が増えるほど、要件定義は設計の先延ばしになる。
明日からやるなら、1枚だけでいい
大きなテンプレートはいらない。まずは1ページでいい。
- 状態を5つ以内で書く
- 状態ごとの遷移トリガーを書く
- 各遷移の実行者を書く
- 止める条件を書く
- 戻し先を書く
この5行があるだけで、AIの出力はかなり現実寄りになる。
たとえば「問い合わせ対応」を考えるなら、
- 未着手
- 返信待ち
- 顧客確認中
- 完了
- 保留
くらいの状態に絞って、どこで人間が介入するかを決める。状態が見えると、AIに任せる範囲も見える。逆に状態が見えないと、AIはどこまでも広げる。
1枚で確認するなら、 状態とトリガーだけでいい
状態遷移表を完璧に作ろうとすると、途中で止まりやすい。だから、最初は少なくていい。
実務で使うなら、まず次の2つだけ埋めれば十分だ。
- 状態
- トリガー
この2つが埋まると、「何が起きたら次へ進むか」が見える。すると、自然に抜けるものも見える。
たとえば、状態だけ書いても弱い。
- 下書き
- 申請中
- 差戻し
- 完了
これだと、見た目の並びはできるが、運用はまだ曖昧だ。
そこにトリガーを足す。
- 下書き → 申請送信
- 申請中 → 承認
- 申請中 → 差戻し
- 差戻し → 再送信
- 完了 → 取消
ここまで書けば、AIに渡す前提がかなりはっきりする。レビュー時に見る場所も減るし、テストケースも作りやすい。要件定義の強さは、細かさよりも、判断を止められるかで決まる。
迷ったら「例外」と「戻し先」を同じ行で考える
状態遷移は、前に進むだけでは足りない。戻る線がある から運用になる。
たとえば、承認者が不在で保留に入ったとする。このとき必要なのは「保留」だけではない。
- 誰が保留を解除するのか
- どの条件で再申請に戻るのか
- 元の申請者が何を修正できるのか
ここまで決まって、ようやくAIに「設計してよい」と言える。戻し先がない要件は、だいたい実運用で詰まる。
まとめ
AI要件定義で先に決めるべきなのは、見た目の完成度ではない。状態遷移だ。
状態が決まると、遷移が決まる。遷移が決まると、権限と例外が見える。そこまで行けば、AIは「それっぽい案」ではなく、運用できる案を返しやすくなる。
要件定義は、何を作るかを並べる作業ではない。どの状態を、どの条件で、どこへ動かすかを閉じる作業だ。
