AI上流工程で先に決める3つの論点
# AI上流工程で先に決める3つの論点
AI上流工程の相談は、話題が広がりやすい。
現場の困りごと、使いたいデータ、つなぎたいツール、例外時の扱い。どれも大事だ。だからこそ、議論が長くなりがちだ。
ただ、上流工程の仕事は「たくさん話すこと」ではない。あとから実装や運用で迷わないように、論点を減らすことだ。
この観点で見ると、AI上流工程で先に決めるべきものは3つに絞れる。
- 何を成果物にするか
- 誰が最後に決めるか
- どう検証するか
この3つが決まると、会話は急に短くなる。逆にここが曖昧だと、仕様書だけ増えて、どの案も「それっぽい」で終わる。
OpenAIの A Practical Guide to Building Agents が示しているのも、結局は同じだ。エージェントを作る前に、どこまで任せるか、どこで止めるか、どう測るかを先に決める必要がある。
1. まずは成果物を1つに絞る
AI上流工程でよくある失敗は、「結局何を作るのか」が最後までぼやけることだ。
議事録なのか、要件定義書なのか、判断メモなのか、テストケースなのか。全部欲しい気持ちはわかる。だが、最初から全部を狙うと、会話も実装も重くなる。
上流工程でいちばん効くのは、成果物を1つに絞ることだ。
たとえば営業フォローの案件なら、最初の成果物は次のどちらかで十分だ。
- 読むべき材料をまとめた判断メモ
- そのまま使えるテストケース一覧
この段階で仕様書を完璧に作ろうとすると、ほぼ確実に止まる。なぜなら、実装が必要とするのは分厚い文章ではなく、判断できる粒度だからだ。
アツメルでは、仕様をAIに渡す時に「まず何を一枚にするか」を決めると、初稿の作成時間が目に見えて短くなる。AIは、分割された論点の方が扱いやすい。
2. 次に、最後に決める人をはっきりさせる
AI上流工程は、便利な言葉が多い。
「現場の意見を尊重する」「柔軟に運用する」「ケースバイケースで判断する」。どれも正しい。だが、最後の決定者が誰かまで落ちていないと、実務では止まる。
ここで必要なのは、責任分界の明文化だ。
- 誰が要件を承認するか
- どこから人間承認に切り替えるか
- 例外時に誰が最終判断するか
- 変更依頼は誰が受けるか
AIに仕事を渡す時、人間が曖昧さを吸収してくれる前提は危ない。AIは空気を読むより、与えられたルールを優先するからだ。
これは Model Context Protocol でいう Resources と Tools の分け方にも近い。読むための文脈と、動かすための入口は別だ。上流工程でも、判断する人と実行する人を分ける方が、のちの設計が軽くなる。
3. 最後に、検証方法を先に置く
上流工程の議論でいちばん後ろに回りがちなのが、検証方法だ。
しかし、AIの仕事は検証できないと改善しない。ここを後回しにすると、導入後に「なんとなく便利」「なんとなく危ない」で止まる。
検証方法は、次の3つだけでも十分だ。
- 何が出れば成功か
- 何が出たら止めるか
- 何を見れば改善と判断するか
たとえば、営業フォローのAIなら、成功は「そのまま使える下書きが出ること」ではなく、「未返信候補の取りこぼしが減ること」かもしれない。停止条件は「社外秘の話題が混ざった時」。改善指標は「人間の修正回数が減ったか」だ。
OpenAIの Agent evals や guardrails の考え方は、この3点を先に固定する発想と相性がよい。
上流工程は、会話を増やす仕事ではない
AI上流工程は、会話が盛り上がりやすい。だからこそ、話を広げるより、要点を削る意識がいる。
成果物、責任分界、検証方法。
この3つが決まれば、残りは実装で埋められる。
逆に言うと、この3つが決まっていない段階で機能一覧を増やしても、後から全部ひっくり返る。
上流工程の価値は、きれいな資料を作ることではない。後工程が迷わない形に、最初の論点を絞ることだ。
会議メモを厚くするより、決定事項を一段で読めるようにした方が、実装側はずっと助かる。AI上流工程で本当に効くのは、その「一段に圧縮する」仕事だ。
