AI要件定義は依存関係を先に決めるべき理由
AI要件定義でいちばん危ないのは、「何ができるか」だけを先に決めることだ。
できることは増える。
でも、どれから動かすかが決まっていないと、業務はすぐにほどける。
実際の現場では、AIは単独で仕事を終わらせない。
何かを読む。何かを 判断する。何かを待つ。何かを止める。
この順番が崩れると、出力はあっても実務は進まない。
依存関係を後回しにすると何が壊れるか
依存関係とは、ある処理が別の処理にどれだけ依存しているかだ。
たとえば、メール返信AIは本文を読む前に、相手・案件・温度感を把握したい。
タスク作成AIは、会議メモを読む前に、案件状態や期限を見たい。
提案書AIは、入力データの最新化が済んでからでないと動かしたくない。
この順番が曖昧だと、AIはそれらしい答えを返す。
だが、現場では使いにくい。
なぜなら、依存関係が決まっていない出力は、次工程に渡しにくいからだ。
ここで重要なのは、依存関係は「実装の都合」ではなく「要件の一部」だという点だ。
どの情報が先に必要か。
どの状態が揃わないと動いてはいけないか。
どの承認が来るまで止めるか。
これを決めずにAIを入れると、後で人間が全部つなぎ直すことになる。
先に決めるべき依存関係は5つ
1. 入力の依存関係
まず、何が揃わないと開始できないかを決める。
会議メモだけでは足りないのか。
CRMの活動履歴も要るのか。
相手との直近メールも必要か。
ここを決めると、AIが読む順番がはっきりする。
たとえば、問い合わせ返信の下書きを作るなら、本文だけでなく、送信相手、件名、過去のやりとり、返信の目的が必要になることが多い。
逆に、依存関係が決まっていれば、不足時に何を聞き返すかも決めやすい。
2. 権限の依存関係
次に、どの権限が先に必要かを決める。
読む権限、書く権限、送る権限は同じではない。
AI社員の権限設計は、実は依存関係の整理でもある。
たとえば 社内AIエージェントは権限設計から で見たように、参照権限と実行権限を分けて考えるだけで事故は減る。
さらに、送信や変更のような外部影響のある操作は、最後に回す方が安全だ。
3. 状態の依存関係
AIが今どこにいるかも、依存関係に含まれる。
受付済みなのか。確認中なのか。下書き済みなのか。送信待ちなのか。
状態が決まらないと、次に何をしてよいかが決まらない。
これは AIエージェントの状態管理を先に決めるべき理由 と同じ話だ。
状態が先、実行は後。
この順番がないと、AIは途中で止まったのか、終わったのかが判別できない。
4. 評価の依存関係
評価も、依存関係の一部だ。
何ができていれば合格なのか。
何が欠けたら差し戻すのか。
どのログを見れば説明できるのか。
ここが先に決まっていないと、改善の余地も見えない。
だから AIエージェント 評価設計は何から決めるべきか のように、成功条件と失敗条件を先に閉じる考え方が効く。
依存関係があるから評価できる。
評価できるから改善できる。
5. 変更の依存関係
最後に、何が変わったらどこを再確認するかを決める。
メール本文が変わったら再要約するのか。
案件ステージが変わったら再チェックするのか。
権限が変わったら再承認なのか。
変更の依存関係がないと、AIは古い前提のまま動く。
これは地味だが、実務ではかなり危ない。
古い状態で正しく見える出力ほど、後で修正が大変になる。
依存関係は、図より先に順番で考える
依存関係を図にすると見栄えはいい。
ただ、図だけで終わると運用で崩れる。
先に見るべきなのは順番だ。
- 何を読むか
- 何を判断するか
- 何を待つか
- 何を止めるか
- 何を記録するか
この順番が揃うと、AI要件定義は一気に実務になる。
逆に、順番がないまま機能を並べると、どこから実装しても途中で詰まる。
ここは AI要件定義は受け入れ条件から逆算する と AI要件定義は禁止条件から決める の中間にある。
受け入れ条件はゴール。禁止条件は境界。
依存関係は、その間をつなぐ順番だ。
よくある失敗は、だいたい同じ
失敗は、だいたい三つに集約される。
1. 先に全部つなぐ
便利そうに見えるので、最初からSlack、Gmail、CRM、カレンダーを全部つなぐ。
だが、依存関係が決まっていない連携は、ただの複雑化だ。
何が起点で、何が結果かが曖昧になる。
2. 後で並び替える前提にする
最初は雑でも後で整える、というやり方は人間には通用する。
だがAIは先に動く。
先に動いたものを後で直す方が、結局高くつく。
3. 評価を最後に回す
依存関係がないと評価できない。
評価がないと、改善の優先順位がつけられない。
だから評価は最後ではなく、最初から依存している前提で決めた方がいい。
Atsumellの視点
Atsumellでは、AI要件定義を「何を作るか」ではなく「どう流れるか」から見る。
Kakusill の役割もそこにある。
仕様をAIが扱える構造にするには、機能一覧より先に、依存関係を解く必要がある。
特に、AIエージェントやAI社員を業務に入れるときは、依存関係の設計がそのまま運用のしやすさになる。
入力が揃わないと動かない。
権限が足りないと止まる。
状態が不明だと再開できない。
評価がないと改善できない。
この順番を先に決めておくと、AIは「何でもできる存在」ではなく、「任せると回る存在」になる。
参考
- A Practical Guide to Building Agents | OpenAI
- Mitigate jailbreaks and prompt injections | Anthropic
- MCP Resources
- MCP Tools
- OWASP Top 10 for LLM Applications
