ボトルネックが移る
チャット画面が一つなら、AI が聞いてきたことに答えるだけです。誰も疲れません。
AIエージェントのセッションが数本なら、並行して走っていても、まだ何とかなります。どのセッションも、ときどき手を止めて聞いてきます。どの案にするか、これは消していいか、設計はもう承認済みか。一つひとつは小さな質問で、ひと目見れば答えられます。
けれど規模は数本では止まりません。何十本にもなると、その小さな質問が一日中、何十個もの別々のウィンドウに散らばります。私たちのチームには、一日に何百本ものセッションを回す人もいます。夕方には、答える側に、いちばん大事な一問を考える力が残っていません。
これが**決断疲れ（decision fatigue）**です。一つの難しい決断から来るのではなく、たくさんの簡単な決断が、間の悪いときに、間の悪い場所に届くことから来ます。
私たちにとって、これは、エージェントを多く使う働き方全体の本当のボトルネックです。機械は増やせます。**機械に仕事を渡す人の注意力は、増やせません。**その人が昼前に力尽きれば、エージェントを足しても待ち行列が伸びるだけです。
以下は、私たちが使っている五つの段階です。いちばん安いものから、いちばん手間のかかるものへ並べています。どの段階も単独で使えます。どこまで登るかは規模次第です。
第一段階──見る場所を一か所に
いちばん簡単で、何も入れる必要がない方法です。**すべてのセッションに、一本のセッションへ報告させる。**そして、その一本だけを見ます。
指示に一行足すだけです。「終わったら、または聞きたいことがあれば、〇〇という名前のセッションに報告すること」。セッションを束ねる層がすでにあるなら（私たちは Muster を使っています）、「このリンクに報告すること」で済みます。
効くのは、質問が減るからではありません。見る場所が減るからです。何十ものウィンドウが一つになる。「どこかのセッションが止まって待っているのではないか」という、消えない不安がなくなります。
第二段階──質問に規則を
疲れの大半は、決めること自体から来ているのではありません。決める前に文脈を組み立て直すことから来ています。「どうしたいですか」という質問は、答える側にセッションを開かせ、最初から読み直させ、選択肢を自分で考えさせます。
そこで、質問そのものに規則を置きました。エージェントが上げてくる質問は、必ず次を満たすこと。
- それだけで読めること──セッションを開かずに、30秒ほどで読み切れる。
- 選択肢が付いていること──A、B、C、D。押せば終わり。
- **エージェント自身の推奨案が、理由付きで付いていること。**ここがいちばん重要です。ほとんどの場合、答える側は「推奨案で」を押すだけになります。
- 各選択肢の結果と、元に戻す方法が書いてあること。
考える作業を上に押し付けることは、エージェントには許されていません。考え終えて、提案する。人は承認するか、方向を直すだけです。
第三段階──人に聞かなくていい質問がある
いちばん疲れが減る段階で、いちばん飛ばされやすい段階でもあります。
私たちが自分たちの「責任者の判断待ち」の列を数え直したとき、結果は意外なものでした。20件のうち、**本当の決断は5件ほど。**残りは、誰かのうなずき待ちで止まっている細かな作業、締めの作業、片付けの作業でした。答える側は、意味のある5件を見つけるために、意味のない15件をかき分けていたわけです。
直し方は、聞かれた時点で質問を分類し、種類ごとに適切な相手へ回すことです。
- 技術的な質問 → 調整役のエージェントが答える。
- 日常的な業務の質問 → 業務アシスタントが答える。
- 責任者まで上がるのは、狭い範囲だけ。方針、セキュリティ、お金、本番環境、そして元に戻せない変更。
もう一つ、分類の問いを添えます。**これは元に戻せるか。**やり直せる作業ならエージェントが自分でやって、一行で報告する。一方通行の作業だけ、先に聞く。
そして、**範囲を決めて、事前に権限を渡しておく。**たとえば「このプロジェクトでは、テストがすべて通ったら、自分でメインブランチにマージしてよい」。一度の委任が、その後の数百の質問を消します。
決断疲れの正体は、多くの場合、分類疲れです。そして分類は、人よりも仕組みのほうが上手です。
第四段階──描いて、速く考える
質問をどれだけ短く書いても、読む側が頭の中で図を組み立てるしかない問題があります。三つのシステムをまたぐデータの流れ、五者の関係者、トレードオフのある二つのアーキテクチャ案。
この種の問題では、エージェントに──設計担当のエージェントと組ませて──聞く前に**すべてを図に描かせます。**全体を一度に見れば、決断は何度ものやり取りではなく、数分で下りることが多いです。
トークンは余計にかかります。それでも、アーキテクチャの判断を誤る代償や、決める人が問題の形をつかめずに午後が丸ごと止まる代償に比べれば安いものです。設計担当のエージェントが、ブランドの体裁に沿って描ける道具をあらかじめ持っていれば、さらに安くなります。
第五段階──判断の受信箱と、戻ってこなければならない答え
最後の段階は基盤です。人の判断が必要な質問を、すべてのセッション、すべてのマシンから、一つの受信箱に集める。答えたら、その答えが待っているセッションに自動で戻り、作業が続く。
難しいのは後半です。私たちは承認を二度、行方不明にしてしまいました。承認ボタンはある場所に書き込み、処理は別の場所を読み、受信箱は空のまま。答えが作業の場に戻れないなら、答えていないのと同じです。
硬い原則をいくつか。
- 質問と答えの記録は一つ。
- **速度は二つ。**待っているエージェントにはすぐ通知する（上限付き）。急がないものはまとめて、一回5件まで。
- 沈黙は、同意ではない。
- **一度答えたら、ずっと使う。**同じ質問が二度来るのは仕組みの欠陥。何度も繰り返す質問は、書かれた規則にする。
本当に楽になったか、測る
「楽になった気がする」は信用できません。私たちは次の数字を追っています。
- 一日に責任者まで届く質問の数──第三段階に登れば、これは下がるはずです。
- 質問から答えまでの時間。
- 聞き直さずに、前例で片付いた質問の割合。
- **責任者がエージェントの推奨案を却下した割合。**これが高いなら、エージェントが意図を読み違えています。直すべきは規則であって、質問の書き方ではありません。
いちばん高いもの
上の五つは、一つのことに行き着きます。エージェントが多い組織で**高いのは機械ではなく、機械に仕事を渡せる人の注意力です。**それを守るのは設計の仕事であって、本人の自制心の問題ではありません。
第一段階にかかるのは、プロンプト一行です。今日、試してみてください。