複数のCodexに文書レビューを分担させたら、見落としは減りそうだが万能ではなかった

この記事は、複数のCodex sessionに文書レビューを分担させる運用を、小さく実験した記録です。

結論から言うと、複雑な文書レビューでは効果がありそうでした。

ただし、万能ではありません。

今回言えるのは、かなり限定された範囲です。

• review-onlyのgovernance docsでは、重要な見落としが複数sessionで繰り返し見つかった
• 観点を分けたreviewは、細かい境界漏れを拾いやすかった
• ただし、速い、安い、常に高品質、実装にも安全、とは言えない
• 今回の結果は、code変更、DB変更、auth、本番作業、自動化には一般化しない

何を試したのか

試したのは、実装ではなく文書レビューです。

対象にしたのは、AI agentの実行境界やEvidence Gateを定義するgovernance docsです。

たとえば、次のようなことを文書で決めています。

• Issueをcloseしてよい条件
• PRをmergeしてよい条件
• GitHubのIssue情報を読むだけのagentが、write権限を持たないこと
• run logやcommand resultを、どこまでEvidenceとして扱ってよいか

こういう文書は、一見きれいに書けていても、読み方によっては危ない抜け道が残ります。

そこで、同じ対象文書を複数のCodex sessionでreviewし、見落としが減るかを見ました。

比較した見方

今回の記事で出てくる方式は、ざっくり次の3つです。

名前	意味
A1	1つのsessionで対象文書全体を見る
A3	3つの独立したsessionで、それぞれ対象文書全体を見る
C3	3つのsessionに観点を分けて、担当laneごとに見る

C3の「lane」は、担当観点のことです。

たとえば、あるsessionは権限境界を見る、別のsessionはredactionやsecrets境界を見る、別のsessionはschemaやEvidence Gateを見る、という分け方です。

ここで大事なのは、C3を「いつも強い」と言いたいわけではないことです。

むしろ、C3は出力が増えます。

そのぶん統合の手間も増えます。

なので、軽い作業には向きません。

今回見たかったのは、重めの文書レビューなら、観点を分ける価値があるかです。

T1で見えたこと

V4-T1では、Issue closeとPR mergeの境界を定義する文書をreviewしました。

複数のrunnerが繰り返し拾ったのは、主に次の問題です。

1. 未解決リスクが「記録されているだけ」でclose/merge readyに見えてしまう
2. waiverが広すぎると、検証済みEvidenceの代わりに読めてしまう

これは危ないです。

「リスクを書いた」ことと、「リスクを解決した」ことは違います。

同じように、「waiverがある」ことと、「検証済みである」ことも違います。

この区別が曖昧だと、AI agentや人間が後から読んだときに、まだ閉じてはいけないIssueを閉じてよいように見えてしまいます。

さらにC3では、whole-document reviewだけでは薄くなりやすい細かい論点も出ました。

• child PRがparent issueの状態を古くしたままmerge-readyに見える可能性
• no-code/docs-only closeでもrollback/reopen noteが必要ではないか
• approved workflow という言葉が、別承認なしの実行権限に見える可能性

T2で見えたこと

V4-T2では、GitHub Issue Readerのread-only境界を定義する文書をreviewしました。

ここで一番強く出た指摘は、次のものです。

reader snapshotが、下流でreadinessやwrite authorityに見えてしまう可能性がある。

つまり、reader自身はGitHubにwriteしない。

でも、readerが作ったsnapshotを別の処理が受け取ったときに、それを「ready判定」「write許可」「close/merge許可」のように扱ってしまう危険がある、ということです。

これも、文書上の境界としては重要です。

「読むだけ」は「実行してよい」ではありません。

C3では、さらに細かい論点も出ました。

• comment readの範囲を、読む前にどう絞るかが曖昧
• linked issue/PRをたどる深さが曖昧
• label readがrepo-wide / org-wide scanに広がる余地がある
• owner/repo#number だけでは、rename後の検証anchorとして弱い場合がある
• partial / blocked snapshotに、warningやmissing fieldを構造化して残す必要がある

このあたりは、全体をざっと読むreviewでは落ちやすい細部です。

観点を分ける価値が出やすいところでした。

T3で見えたこと

V4-T3では、Evidence Collector Contractをreviewしました。

中心になった指摘はこれです。

verified evidenceはissue contractとEvidence Gate rulesの両方を満たす必要があるのに、state tableやschema/exampleではEvidence Gate rule参照が弱い。

言い換えると、本文では「ちゃんとEvidence Gate rulesも満たす必要がある」と言っているのに、表やexampleだけを見ると、弱い条件でverifiedにできるように見える、という問題です。

これは実務ではよくあります。

本文には正しいことが書いてある。

でも、実装者や運用者は表やexampleをコピーする。

そのときに抜け道が生まれます。

C3では、ここでも細かい論点が出ました。

• redaction_state はあるが、許可値や確認者、確認ruleが弱い
• gate_state = waived なのに、waiver_id が条件付き必須になっていない
• high/critical risk waiverを判定するrisk classificationが足りない
• artifact_ref がraw secret-bearing outputやprivate logsへの抜け道になり得る
• 「CIを実装しない」とは書いているが、trigger/rerun/dispatch/approveを明示禁止していない
• minimum evidence by work typeが表だけで、schema上のprofile/item stateになっていない

このT3では、runner outputをそのまま採用しませんでした。

いったんsecondary analysisを挟み、対象文書に照らして妥当なcandidate findingだけを整理しました。

そのうえで、docs-only follow-up PRとして文書を補強しました。

ここは今回の実験で重要な点です。

複数session reviewは、指摘を増やすだけでは意味がありません。

指摘を二次確認し、boundedな修正に落とせるかが大事です。

T3では、そのloopを一度回せました。

ここまでで言えること

今回の3 targetでは、複数session reviewは有望でした。

特に、次のような用途では効果がありそうです。

• AI agentの実行境界を書く文書
• Evidenceやapprovalの意味を決める文書
• 「読むだけ」と「実行してよい」を分ける文書
• close / merge / publication / automationのような権限境界を扱う文書

こういう文書では、文言の小さな曖昧さが大きな事故につながります。

1つのsessionで全体を見るだけだと、重要な穴は拾えても、細かい抜け道までは薄くなることがあります。

観点を分けるC3は、そこを補いやすいと感じました。

ただし、これは「C3がA3より常に優れている」という意味ではありません。

今回の評価は完全なブラインド評価ではありません。

また、統合負荷やusage/credit、wall-clock timeも十分には比較できていません。

そのため、現時点では次の表現が限界です。

review-onlyのgovernance docsでは、multi-session / C3が有用そうな再現的な兆候があった。

まだ言えないこと

ここはかなり重要です。

今回の結果から、次は言えません。

• 複数Codexの方が速い
• 複数Codexの方が安い
• 複数Codexの方が常に高品質
• C3はA3より一般に優れている
• 実装作業にも安全に使える
• code、DB、auth、production作業にも広げられる
• automationしてよい
• runner outputはそのままverified evidenceである

今回の対象は、review-onlyのgovernance docsです。

しかも、runnerの指摘はそのまま正解にしたわけではなく、secondary analysisを挟んでいます。

この境界を外すと、記事としては強く見えても、実験としては不正確になります。

実際に使うならどこで使うか

自分なら、次のような場面で使います。

• 重要なpolicy docsを公開・採用する前
• agentに渡すExecution Contractを固める前
• close / merge / publication / automationの境界を決める前
• Evidence Gateやapproval flowを設計するとき

逆に、次のような場面では使いません。

• typo修正
• 小さなdocs修正
• 実装方針が明確な小タスク
• すぐに人間が読める短いPR

C3は便利ですが、軽くはありません。

出力が増えるので、統合する親sessionや人間の負荷も増えます。

「重い文書レビューにだけ使う」くらいが現実的だと思います。

今回の一番の学び

一番大きかった学びは、複数sessionにすると「指摘の量」が増えるだけではなく、同じ穴が複数方向から繰り返し見えることです。

これはレビューではかなり助かります。

1つのsessionだけが言っていると、「本当に問題なのか？」と迷います。

でも、独立したwhole-document reviewと、担当laneに分けたreviewの両方が近いことを言っているなら、そこは文書側に読み間違えやすい構造がある可能性が高い。

その一方で、runner outputをそのまま信じるのは危険です。

今回も、最後はsecondary analysisを挟みました。

複数sessionは判断者ではなく、見落としを減らすためのreview surfaceとして扱うのがよさそうです。

結論

複数のCodexに文書レビューを分担させる運用は、review-onlyのgovernance docsでは有効そうでした。

特に、権限境界、Evidence、waiver、redaction、close/merge、automationのような論点では、観点を分ける価値があります。

ただし、これは万能ではありません。

速さやコストの優位はまだ言えません。

実装や本番作業に安全に使えるとも言えません。

現時点では、次のくらいの扱いが妥当です。

重めのreview-only governance docsでは、Partial Adopt candidate。

つまり、「重要な文書の見落としを減らすための道具」としては使えそう。

でも、「複数Codexに任せれば速く安全に開発できる」とは、まだ言わない。

その線引きが、今回いちばん大事な結論です。