エージェントが数百件規模の対象（過去セッションの知識抽出、大量ファイルの監査・移行など）を処理するとき、「どれを読み・どれを読まずに片付け・どこまでやるか」というスコープ判断をエージェントが自律で取らない。全部読むのは過剰消費、読まずに片付けるのは越権で、どちらの既定もエージェントのものではない。判断コストが非対称なのが根拠: ユーザーにとって表を見て型を選ぶのは数十秒、エージェントの誤判断は数百件分の浪費か不可逆な取りこぼしになる。

実践

• 証拠を先に揃える: 全文を読まずに安価な分析だけ行う — 属性別の内訳（プロジェクト×時期×処理済み信号等）、機械信号の抜き取り検証（最新の1、2件を実物と突き合わせて信号の信頼性を確認）、各対象の冒頭部分（例: 最初の実ユーザー発話）によるリクエスト型分類。
• bucket 単位で聞く: 個別対象ではなく「この型は読む／この型は片付ける」という集合単位の選択肢にし、件数・例・推奨を添える。選択肢が有限で根拠が見えるのでユーザーは短時間で判断できる。
• 質問は1ラウンドに束ねる: 段階ごとに聞くと尋問になる。分類を済ませてから、片付け可否・読む型の選択・どこまでやるかをまとめて1回で聞く。
• 無人実行のフォールバック: 聞けないときは破棄側の判断（読まずに片付ける）を一切しない。予算内で保守的に処理し残りは次回に送る。

検証と実例

抜き取り検証は必須工程にする。実例では機械信号（処理済み判定の文字列マッチ）の抜き取り確認で誤分類39件を検出し、読む価値のある層を破棄直前で救った。型分類の収穫予測（実装・修正依頼型は高収穫、機械作業・挨拶のみはゼロ）は実測と一致し、bucket 選択により約100件中77件を読まずに安全に片付けられた。