Appearance
4. レビューワークフローの仕組み
12 件の不具合を確定させたコードレビューは、単一エージェントの自己レビューではなく、16 体のサブエージェントによる 2 フェーズのワークフローとして実行された（ワークフロー実行 ID: wf_6e9671d3-7ed）。
構造: 「次元別発見 → 敵対的検証」
フェーズ1: 発見（4 体が並列・独立）
├── 正確性レビュアー ─┐
├── 性能/メモリレビュアー ├─ それぞれが実ソースを読み、
├── セキュリティレビュアー │ スキーマに沿った具体的指摘を報告
└── 簡素化レビュアー ─┘
↓ 指摘 12 件
フェーズ2: 検証(指摘ごとに独立した懐疑エージェント)
└── 12 体が「この指摘は本当に実在するか」を反証する構えで検証
↓
12 件全件 CONFIRMED(棄却 0)→ 全件修正なぜこの構造なのか
devlog は理由を明確に書いている:
単一の自己レビューが見落としがちなものを捕まえられる。作者は既に自分のコードのメンタルモデルを信じてしまっているからだ。
- 次元の分離: 4 体がそれぞれ 1 つの観点だけに集中する。正確性と性能/メモリの 2 次元が GPU リークを独立に指摘したことは、指摘の確度を上げる副産物にもなった。
- 敵対的検証: 発見側の指摘を鵜呑みにせず、独立エージェントが「反証する」姿勢でコードを読む。修正コストと回帰リスクを払う前に偽陽性をふるい落とすための構造で、Fable 5 版の Qiita 記事で「指摘 🟥 → 独立懐疑 🟧」と呼ばれているものと同型。
結果の特徴: 偽陽性 0、しかし検証は素通しではなかった
12 件中 12 件確定・棄却 0 という結果だけ見ると「検証が甘かったのでは」という疑いが立つ。しかしセッションログはその読みを否定する材料を含んでいる:
- 検証エージェントが three.js のソースコードまで遡り、
dispose()未呼び出しが本当にリークになるかを解放チェーンのレベルで確認している。 - 検証段階は確認作業に留まらず、関連指摘の検証中に既存修正の「二次バグ」（最大半径到達後のチャンク肥大）を新たに発見した。検証が実質的な追加発見フェーズとして機能している。
- セキュリティ次元は「指摘 0 件」を返したが、これは静的クライアントサイト（バックエンドなし・認証なし・永続ユーザーデータなし・非定数文字列の DOM 注入なし）に対する正しい 0 であり、次元が仕事をしなかった 0 ではない。
つまりこのセッションの 12/12 は「検証が緩い」ではなく「発見側の precision が高かった」と読むのが妥当。ただし発見の絶対数は Fable 5 版より小さく、recall（取りこぼしのなさ）は規模の小ささゆえに直接は証明できない。この点は比較ページで扱う。
修正の適用と再検証
12 件は 1 コミット（a1ef6ee）でまとめて適用され、修正ごとに検証手段が用意された:
| 修正 | 検証方法 |
|---|---|
| GPU リソース解放 | リスタート 5 サイクル連続ストレス、エラーなし |
| 二次バグ（チャンク肥大） | 統計オーバーレイに maxChunkParts を新設し、60,000+ フレームで上限 400 に張り付くことを観測 |
| SpatialGrid / 位置ずれ / 簡素化 8 件 | ビルド + 挙動確認（tsc 型検査を含む） |
コスト
| 項目 | 値 |
|---|---|
| レビューワークフローのエージェント数 | 16 体（発見 4 + 検証 12） |
| セッション全体のワークフロー消費 | 945,733 トークン（判定パネル 6 体分を含む） |
| 発見→全件修正→検証→コミットまでの経過 | 約 26 分（12:13 → 12:39 のコミット間隔） |
1 確定バグあたりのワークフローコストは粗く見て ~79K トークン（945.7K ÷ 12。ただしこの分母にはアーキテクチャ判定パネルの消費も含まれるため、レビュー単体では更に小さい）。