遅延コストをトリアージ指標に
cubby ai team
キューを抱えたAIエージェントが直面する問題は、プロダクトマネージャが直面する問題と同型である。やるべきことが多すぎ、スループットは有限、そして「どれから先に」の明快な答えがない。標準的な答え — FIFO、深刻度の階層、声が大きい順 — はすべて同じ方向に間違っている。目の前の作業項目を最適化していて、キューが待っている間に発生している経済的損失を最適化していない。
Don Reinertsen の『Principles of Product Development Flow』(2009) は、この分野で最も明快な経済的答えを供給した。そしてその枠組みは、ほとんど無加工でエージェントのトリアージに移植できる。Reinertsen の定義は、DXによる Cost of Delay 解説 で引用されている通り、運用に直結している。遅延コストとは「製品の入手可能性の変化に対するライフサイクル利益の偏微分」である。平たく言えば、待ち時間あたりのドルである。彼はこの指標に、よく持ちこたえてきた経験則を添えている。「もし一つだけ定量化するなら、遅延コストを定量化せよ」。そして、約85%のプロダクトマネージャは、ある項目を一ヶ月遅らせるといくらかかるかを答えられない、という観察も。
待ち時間に値をつけられないなら、トリアージはできない。
WSJF — 形式ではなく、計算式
Scaled Agile Frameworkの WSJFガイダンス は、Reinertsenの考えをバックログ向けに運用化している。項目を「遅延コスト ÷ 作業期間」で順序付ける。SAFeは遅延コストを3つの相対的入力(ユーザー・事業価値、時間的緊急性、リスク低減または機会創出)に分解し、4つ目の入力(ジョブサイズ)を分母に置く。直感はキュー理論である。サービス容量が有限なとき、スループット重み付け価値を最大化する方針は、経済的緊急性で重み付けされた「最短ジョブ優先」である。それがWSJFである。
計算式は残し、儀式は捨てればよい。生き残るのは計算式の方である。それは、運用者がエージェントで、キューが数秒ごとに更新される環境にもそのまま翻訳できる。
なぜエージェントのトリアージにきれいに写るのか
構造的な理由が3つある。
1. エージェントのキューは末尾遅延に支配される。 リサーチ、ドラフト、ツール呼び出しを並行するエージェントには、厳しいスループットの上限がある。コンテキストウィンドウ、ツールのレート制限、推論時間。スループット重み付けの経済学は、まさにキュー理論が設計された対象である。SAFeチーム自身、WSJFはキュー理論とReinertsenの遅延コスト枠組みから採られたと明言している。
2. ほとんどのタスクには既知の緊急性曲線がある。 「認証プロバイダを乗り換えるべきか」のリサーチは、数週間に渡って平坦な緊急性曲線を持つ。「認証プロバイダの障害が今ユーザに影響しているか」のリサーチは、分単位で段差をもつステップ関数である。2025年のサーベイ AIOps in the Era of Large Language Models は、2020〜2024年の183論文を通して、エージェント設計で経験的に最も難しいのはモデルではなく、部分観測下での障害認識と優先順位付けであることを示している。遅延コストは、そこに投入できる最も明快なスカラーである。
3. エージェントはジョブサイズが読みやすい。 人間チームのジョブサイズ見積もりは難しいことで知られている。エージェントの場合は比較的容易である。トークン数、ツール呼び出し回数、見込みウォールクロック。WSJFの分母が、手元にそのまま渡されているのである。
cubby aiの形にしたバージョン
我々はエージェントをSAFeのバックログ上では走らせていない。ストリーム上で走らせている。だから、WSJFのリアルタイム退化形を使っている。表現は2つの数字と1つの動詞である。
- CoD/分: 各保留タスクについて、依頼者が表明した待ち時間あたりのドル、未表明ならシステム既定値。空白よりも既定値の方がよい。
- 見込み完了コスト: ウォールクロックの秒数と、推論およびツールのドル。
- トリアージ動詞: 今すぐ、まとめて、後で、やらない。
順位付けは CoD/分 × 期待残存価値 を 見込み完了コスト で割ったもの。動詞は結果であり、画面の先頭に出る。前述のDX解説に出てくる Hirschorn の例 — エンジニアの人件費とビルド時間短縮を突き合わせて社内投資を正当化する — は、別の時間スケールでの同じ操作である。
要点は数値の精度ではない。要点は、その数値がそこにあり、見え、議論にかけられることである。遅延コスト欄を示せないチームはトリアージをしているのではない。直近のメッセージの差出人に反応しているだけである。
立場
計算式を借りよ。スプレッドシートは捨てよ。我々が毎回欲しい形は、cubby aiの他の部分と同じ形である。最初に次の決断 (どのタスクを走らせるか)、次に根拠 (CoD/分、見込みコスト)、最後に却下した代替案 (走らせないと決めたものと、さらに先送りした場合のコスト)。
もし一つだけ定量化するなら、遅延コストを定量化せよ。Reinertsenは2009年に正しかった。運用者がエージェントになった今、彼はさらに正しい。
出典
- Engineering Enablement — Cost of Delay (DXニュースレター) — Reinertsenの定義を逐語で引用し、具体的なCIビルド時間の事例を提供。
- Scaled Agile Framework — Weighted Shortest Job First (WSJF) — WSJFの正準形式と4つの入力要素。Reinertsenからの出自を明記。
- arXiv 2507.12472 — A Survey of AIOps in the Era of Large Language Models — 183論文のサーベイ。障害認識と優先順位付けがエージェント運用の支配的な難問であることを指摘。
- pingfatigue.com — アラート疲労研究索引 — トリアージが重要である根拠となる「量」の文脈を提供。incident.io 2024調査による週42ページ/エンジニアの中央値など。
- Splunk — Mean Time to Acknowledge (MTTA) — 遅延の金額的規模を提供。約12.5万ドル/時、Global 2000で年約4,000億ドル。