複数の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が繰り返し拾ったのは、主に次の問題です。

未解決リスクが「記録されているだけ」でclose/merge readyに見えてしまう
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に任せれば速く安全に開発できる」とは、まだ言わない。

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