提案キューを「溜まるだけのゴミ箱」にしない — 自動トリアージの作り方

AI に情報源（チャットログ・RSS・議事録）を要約させると、副産物として「やってみては？」という 提案が出る。これを JSONL などに溜める仕組みはすぐ作れるが、消化する仕組みを同時に作らないと 必ず腐る。実例では 47件が9日間 pending のまま滞留し、セッション冒頭の表示が提案47行で埋まって ノイズになり、結局誰も読まなくなった。原因は単純で、status を変える口が --done / --reject の人間の手打ちだけだったこと。

教訓: 生成する仕組みを作ったら、消化する仕組みを同じ PR で作る。 「あとで手で捌く」は運用されない。

設計

夜間バッチに1ステップ足すだけでよい。

情報源 → 要約 → 提案キュー(JSONL) → ★トリアージ → done / rejected / TODO起票

トリアージの中身は3段:

1. 裏取り: 提案の主張を Web 検索にかける（提案は伝聞であり未検証なので、これが要）
2. 判定: 安いLLMに検索結果を渡し、構造化 JSON を返させる
3. 反映: status を書き戻し、採用分だけ実作業キュー（TODOファイル）へ起票する

判定の返り値

{ "verdict": "confirmed|refuted|unclear", "finding": "根拠の要約", "adopt": true, "reason": "..." }

verdict（主張が事実か）と adopt（自分たちがやるべきか）を分けるのが肝。 「事実だが自社に打ち手がない」を rejected にできる。

status 規則

verdict	adopt	結果
refuted	—	rejected
confirmed	true	done + TODOへ起票
confirmed	false	rejected
unclear	—	pending 据え置き（N回で打ち切り → rejected）

unclear を rejected にしないこと。 未検証を根拠に捨てるのは、検証したのに捨てるのと意味が違う。 ただし据え置きだけだと毎晩同じ提案を再検証して無料枠を焼くので、triageAttempts を数えて 3回 unclear なら打ち切る。「保留」と「無限リトライ」を両立させる唯一の形。

コストを焼かないための既定値

• 確度が高いものだけ処理する（confidence: high のみ）。低確度は人が見たときだけ
• 1回あたりの件数に上限（3件程度）。溜まった47件を一晩で全部投げない
• 検索もLLMも無料枠・定額枠のプロバイダを使う。フォールバック経路は再実装せず既存モジュールを import する

実装上の要点

既存の検索モジュールから関数を切り出す

CLI しか無いモジュールは、runCli の中にフォールバック分岐（A社が落ちたらB社）が埋まっていることが多い。 分岐を再実装してはいけない。runCli から純粋な search() を切り出し、runCli はその薄いラッパに戻す。 stdout.write / return 1 を throw に変えるだけで済み、既存テストは全部通ったままにできる。

export async function search(query, options = {}) { /* 分岐はここ。失敗は throw */ }
export async function runCli(argv, deps = {}) {
  try { printResult(stdout, opts, await search(opts.query, {...opts, ...deps})); return 0; }
  catch (e) { stderr.write(`${e.message}\n`); return e.code || 1; }
}

レコードは壊さず足す

既存フィールドはそのままに verdict, finding, adopt, triagedAt, triageProvider, triageAttempts を足す。 既に人手で done にした行を再処理しない。

TODO起票は既存の書式に合わせる

追記先の見出しが見つからないときは何も書かない（勝手に見出しを作らない）。番号付きリストなら 既存の採番を読んで続きから振る。フォーマットを壊すと人間側の読み方が崩れる。

検証（ここを省くと「動いたつもり」になる）

• --dry-run で対象ファイルの sha256 が変わらないことを確認する。「変更していないつもり」は証拠にならない
• バッチへの配線は実行して確かめる。構文チェックだけでは足りない。特にステータス行を 正規表現で拾う設計なら、バッチ経由で実行して実際に一致するかを見る
• 本番実行の前に対象ファイルを退避しておく（キューと TODO ファイルの両方）

Windows のバッチに足す場合の罠

• PowerShell 5.1 に渡す .ps1 は BOM 付き UTF-8 で書く。 BOM が無いと OEM コードページ(932等)で 読まれ、日本語リテラルが化けてパースエラーで落ちる。既存ファイルに追記するときも BOM を消さない
• 既存が CRLF なら追記行も CRLF に揃える
• コンソール無し（hidden 起動）だと子プロセスの UTF-8 出力が化けるため、スクリプト冒頭で [Console]::OutputEncoding = [System.Text.UTF8Encoding]::new($false) を立てる。 日本語を含むステータス行を正規表現で拾う設計は、これが無いと常に不一致になる

効果

47 pending → 実行1回で done 1 / rejected 1 に減り、以後は夜間に無人で消化される。 重要なのは件数ではなく、キューが単調増加を止めたこと。