「これ、誰が使うんですか」
デモの最後に聞かれた。
答えに詰まったわけではない。利用部門の名前は決まっていたし、想定ユーザーも資料に書いてあった。
ただ、その人がこのAgentを開く場面を、一つも説明できなかった。
検索できる。要約できる。資料も比較できる。
で、誰の何が軽くなったんだっけ。
利用者は決めていた
PoCの企画書には、対象ユーザーを書く欄がある。
開発者、設計者、品質担当、管理者。役割名を入れれば、とりあえず空欄ではなくなる。
私もそれで十分だと思っていた。
利用者が決まっていて、ユースケースがあり、画面もある。質問を入れれば回答が返る。
ど典型です。
ところが現場へ持っていくと、使うタイミングがない。
既存の会議資料を作る人は、別の場所から情報を集めている。判断する人は、回答そのものより根拠の抜けを確認したい。引き継ぐ人は、会話文ではなく記録として残る形式を求めている。
Agentは便利だった。仕事の流れには入っていなかった。
「誰が使うか」では足りなかった
必要だったのはユーザー像ではなく、principalだった。
ここでいうprincipalは、単に画面を触る人ではない。最終的に確認・判断・説明・記録・引き継ぎの責務を負っている人だ。
同じ設計者向けでも、軽くしたい責務によって必要な出力は変わる。
確認を軽くする → evidence / gap / conflict
判断を助ける → options / constraints / escalation
説明を軽くする → rationale / source / version
記録を残す → structured artifact / operation log
引き継ぎを助ける → state / unresolved items / next action
私は「質問に答えるAgent」を作っていた。
現場が欲しかったのは、確認すべき材料を揃え、抜けを残し、次の担当者へ渡せるartifactだった。
会話は成立していた。責務の受け渡しは成立していなかった。
作った本人が一番使っていた
利用ログを見ると、開発中はよく使われていた。
主な利用者は自分だった。
プロンプトを直す。検索結果を確認する。回答を見て、良くなったと喜ぶ。デモ前には何度も触る。
一方で、責務を負っている人は、デモの後に数回開いただけだった。
「動いた」と喜んでいるのは誰か。
この問いは地味に刺さる。
作り手は、モデルの改善をそのまま価値の改善として見やすい。回答が詳しくなった、toolを使えるようになった、検索対象が増えた。
principal側から見ると、確認箇所が増えただけかもしれない。説明責任を負うのは変わらないのに、AIの出力まで検証対象として追加されることもある。
Agentを入れたはずなのに、仕事が一段増えた。
完敗です。対戦ありがとうございました。
出力からではなく、責務から設計する
この失敗の後、最初に決めるものを変えた。
「何を回答させるか」ではなく、次の順番で見る。
- 最終的に責務を負うのは誰か
- その人が今、何を確認・判断・説明しているか
- どの部分はAIへ移してよいか
- どの部分は人に残し、材料だけ整えるべきか
- 受け取った後、次に何をするか
ここを飛ばすと、Agentは作り手の都合を利用者へ押し付ける。
「チャットで聞けば何でも返ります」は、作る側には気持ちいい。使う側には、いつ聞くのか、どこまで信じるのか、誰が最後に確認するのかが残る。
気持ちよさと運用しやすさは別。
Agentは仕事の中心でなくてよい
Agentを導入すると、既存業務をAgent中心に組み直したくなる。
実際には、人が負っている責務の一部へ、必要な形で差し込む方が残りやすい。
会議前の確認材料を作る。判断不能な点を残す。根拠付きの下書きを作る。引き継ぎ用の状態を更新する。
派手ではない。
その代わり、「どこで使うか」が説明できる。
Agentは動いた。誰の仕事も減っていなかった。
この状態から抜けるために必要だったのは、機能追加ではなく、誰のどんな責務を軽くするのかを先に固定することだった。
この失敗を含め、本番投入前に確認したいPrincipal / Artifact / Boundary / Runtime / State / Observabilityの観点を、チェックリスト本にまとめています。