この記事は、判断の再現とマルチエージェントに関する検証シリーズの1本である。複数のエージェントに批判的レビューをさせる設計で、根拠となる前提を先にシート化して原典照合する手順を検証した。
この記事で分かること
- 前提条件シートが無いと、批判の指摘がどう歪むか
- 原典照合すると、指摘がどれくらい変わったか
- シート作成から再判定までの具体的な手順
この記事で分からないこと(正直に書く)
- レビューに使う視点の数がそもそも適切だったか
- 前提シートを使わない他の案件でも同じ割合で撤回が起きるか
何をしたか — 批判レビューの前に前提条件シートを挟んだ
受託先(上場企業)向けの提案について、複数の視点から批判的にレビューするエージェント構成を検証した。レビューの根拠になっている前提を先にP番号つきの前提条件シートへ書き出し、原典と照合してから判定させる手順を挟んだ(出所: 自社の運用記録、確認日2026-09-06)。
何が起きたか — 原典照合後、指摘の過半が撤回・修正された
最初の批判レビューは、用意した視点のすべてが全滅判定を出していた。しかし前提を原典照合してから同じエージェントを再開し、1件ずつ「維持/修正/撤回」を再判定させたところ、指摘の過半が撤回または修正された(出所: 自社の運用記録、確認日2026-09-06)。例えば、ある画面遷移を直接変更すべきだという指摘は、提携先との取り決めで変更できないことが原典で確認され撤回された。別の指摘は、案件のUI上に表示されるという前提そのものが誤りだと分かって修正された。批判の対象になった案件側の情報だけでなく、レビュー側が持ち込んだ前提にも、自社の記憶に由来する誤りが2件混ざっていたことも分かった。
なぜ気づけなかったか
一般論として正しい批判は、前提の誤りに気づきにくい。批判エージェントの指摘は具体的で断定的な文体で返ってくるため、指摘そのものの体裁が整っているほど、その根拠になっている前提を疑う動機が生まれにくい。前提条件シートを挟む工程が無ければ、初回の全滅判定をそのまま案件の欠陥として採用していた可能性が高い。
どう直したか — シート作成・原典照合・再判定・未確認の隔離
手順を次の順に固定した。1件目に、批判の根拠になる前提をP番号と出典つきでシート化する。2件目に、各前提を原典(規約・確定仕様・実測の有無)と照合する。3件目に、同一の批判エージェントを再開し、1件ずつ「維持/修正/撤回」を判定させる。4件目に、原典に当たれなかった項目は未確認として隔離し、判定に混ぜない。未確認の項目は、ある機能が有料か無料かのように結論を左右する分水嶺になり得るため、確認待ちのリストとして別枠に残す。
再発防止の手順
- 批判レビューを走らせる前に、根拠になる前提をP番号つきでシート化する
- 各前提を原典と照合する。自分の記憶由来の前提も照合の対象に含める
- 原典照合後、同一エージェントを再開して1件ずつ「維持/修正/撤回」を再判定させる
- 原典に当たれなかった項目は未確認として隔離し、判定結果に混ぜない
- 未確認項目は確認要求リストに変換し、結論を出す前に解消する
この手順は、指示直前に何を自問すべきかを扱う「指示直前の3検査と汚れた作業ツリーへの委任」や、委任先が付けた出典をそのまま使わない「出典は候補にすぎない」とも、前提を疑ってから使うという点でつながっている。最初の全滅判定がどう覆ったかの詳細は「複数エージェントの批判が全滅判定を出すとき」を参照してほしい。
批判レビュー・マルチエージェント構成の設計について相談したい場合は、お問い合わせから編集部まで連絡してほしい。
よくある質問
Q1. なぜ前提条件シートが必要なのか
批判エージェントの指摘は具体的で断定的な文体で返ってくるため、体裁が整っているほど根拠となる前提を疑う動機が生まれにくい。前提を原典照合する工程が無ければ、誤った前提に基づく指摘をそのまま採用してしまう。
Q2. 原典照合の結果、何が起きたのか
最初の批判レビューは全滅判定だったが、前提を原典照合してから1件ずつ再判定させたところ、指摘の過半が撤回または修正された。
Q3. 誤った前提はどちら側にあったのか
批判の対象になった案件側の情報だけでなく、レビュー側が持ち込んだ自社の記憶に由来する前提にも2件の誤りが混ざっていた。
Q4. 未確認の項目はどう扱うのか
原典に当たれなかった項目は未確認として隔離し、判定結果には混ぜない。確認要求リストに変換し、結論を出す前に解消する。