# 提案キューを「溜まるだけのゴミ箱」にしない — 自動トリアージの作り方 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ファイル）へ起票する ### 判定の返り値 ```json { "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` に変えるだけで済み、既存テストは全部通ったままにできる。 ```js 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 に減り、以後は夜間に無人で消化される。 重要なのは件数ではなく、**キューが単調増加を止めたこと**。 ---