網羅性が要る列挙タスクでは、走査面の「構造」だけでなく「出自」を点検する — 自作リストを走査面にしない
AI に網羅的な列挙(候補探索・監査・リスク洗い出しなど)をさせるとき、分類軸(型・カテゴリ)を列挙より前に持ち込むと出力がその分類に収束する。見落としやすいのは、プロンプト文言ではなく走査対象リストの側に原因があるケース。しかも原因は2層あり、構造を直しても出自が残る。
第1層: リストの構造
対象リストを分類ごとのセクションに分けると、対象を選んだ時点で分類も決まる:
- ある対象を走査して出た候補が全件同じ分類になる(他分類の可能性は否定されたのではなく、問われていない)
- 別の対象で候補0件になったとき、真の空白なのかその分類だけ飽和していたのかを区別できない
対処: 走査対象リストは分類と直交する軸で並べ、分類は列挙後に写像する(生成 → 分類の2段分離)。各対象に全分類の問いを当てることを手順に固定する(手順に書かない問いは実行されない)。
第2層: リストの出自(見落としがち)
セクションを割らなくても、リストを作ったときの問いが分類に偏っていれば同じ結果になる。表面上は網羅的に見えるので気づかない。
自己診断のやり方: リスト各行に共通する属性を数える。実例では19行中18行が同じ属性を持っており、その属性はまさに潰そうとしていた分類の探し方そのものだった。「このリストはどんな問いで作ったか」を明示的に問う。
最も強い対処: 走査面を自作リストから外部シグナルへ移す
自分で書いたリストを広げても、恩意で作った別のリストになるだけ。母集団の選定を自分の関心から切り離すには、利用者側が実際に使っている言語や、第三者が持つグラフを走査面にする:
- 利用者の言語(検索語・問い合わせ文・エラー文言など)を起点にし、そこから対象を事後的に回収する
- 自作リストは走査面から降ろし、カバレッジ記録(触れたものの記録)として使う。「見るべきものの全体ではない」と本文に明記する
ただし外部シグナルへの入口語は自分で選ぶので、入口語の語彙が同じレンズなら回収される対象も同じ側に落ちる。入口語の網羅性も同じ基準で点検する(実例: 事務・書式系の語ばかりで、地理・価格・消費者向けの語群が欠けていた)。
実績ラベルもアンカーになる
候補リストや分類表に「実証済み」「相性◎」のような既存成功例のラベルを載せると、有望さの証拠として読まれる。実態は「その分類の実行経験がある」だけ。実績ラベルは最後の同点決勝にのみ使うと明記する。
検証
- 記録フォーマットに分類別の内訳を持たせ、「当てて0件」と「当てていない」を記号で書き分ける(例:
0と—)。これがないと空白の証明と未実施が区別できない - 件数を記録するならどの段階の数かを定義する(列挙段階か、スクリーニング通過後か)。未定義だと同じ記号が回によって別の意味になる
- 1対象の走査で単一分類しか出なかったら、それ自体を記録する
- 過去の走査記録は書き換えず、未実施の問いを「要再走査」として後から追記する
手順を入れ替えたときの落とし穴
走査面を入れ替えるような改訂では、上位の規範文書(思想・判断基準の正本)の追従漏れが最も危険。手順側に「迷ったら正本に戻れ」と書いてある限り、正本の古い記述は廃止した設計を復活させる経路になる。改訂後は正本・索引・メタデータ(説明文・見出し)まで旧設計の残存参照を機械的に検索する。
適用範囲
網羅性が価値の中心にある列挙タスク全般(候補探索・セキュリティ監査・リスク洗い出し・レビュー観点の網羅)。逆に、既に分類が確定している対象を処理するタスクでは分類別の構造でよい。