相互査読ワークフロー_CodexとClaude Code

CROSS-MODEL REVIEW CodexとClaude Codeに “お互いをレビューさせる ” Discord連携で作る相互査読ワークフロー 原理原則 → 実装 → 応用 → 検証まで うさうさ研修工房

0. スコープ この記事の構成 事実（一次情報・論文）と筆者の解釈・推奨を明確に分けて解説する 01 原理原則 なぜ「別モデルに読ませる」ことに 効果があるのか（一次情報ベース） 04 応用 CIゲート化、セキュリティレビュー分業 Codex × Claude Code 相互査読ワークフロー 02 アーキテクチャ Discordをハブにした全体設計 05 確認・検証 運用が「効いている」とどう確認するか、 限界は何か 03 実装 Claude Code側／Codex CLI側 それぞれのフック設定 06 研修での扱い方 法人研修で教える際に 外してはいけない注意点 2

1. 原理原則 なぜ「自己レビュー」では不十分なのか 自己レビューの構造的な弱さ 事後合理化 F1スコアで統計的有意差 p = 0.008 迎合（sycophancy） 文脈汚染 原則 A 書いたモデルにそのまま採点させない 複数ラウンドでも改善しにくい writer-reviewer separation 検証研究：文脈を分離したクロスコンテキストレビュー（CCR）は同一セッション 原則 B レビュアーは “新しいセッション ”で読む 内レビューより有意に高い精度 文脈の分離 Codex × Claude Code 相互査読ワークフロー 3

1. 原理原則 学術側の裏付け：マルチエージェント査読・改善 単一LLMより複数エージェントに役割分担させたほうが精度・具体性が上がるという知見が積み上がっている AgentReview MARG MAgICoRe 会議査読プロセスを著者・査読者・エリアチェ リーダー・ワーカー・エキスパートに役割を分け Solver・Reviewer・Refinerを分離して反復する アの役割でシミュレート て査読を生成 コード改善フレームワーク いずれも「役割分離（ role separation）」が品質向上の鍵とされる Codex × Claude Code 相互査読ワークフロー 4

2. アーキテクチャ Discordを中心に置いた全体設計 ローカル環境 Claude Code Discordサーバー 合流層 #cc-updates / #cx-updates（Webhook） 人間 Generator or Reviewer 中継Bot（discord.py / discord.js） 最終判断 （マージ可否） Codex CLI #review-request Generator or Reviewer #review-result Codex × Claude Code 相互査読ワークフロー 5

3. 実装

実装① Claude Code 側
Stop / SubagentStop フックで差分を Discord Webhook へ POST する
フック対応イベント
.claude/settings.json
{
"hooks": {
"Stop": [{
"matcher": "*",
"hooks": [{
"type": "command",
"command": "bash ~/.claude/hooks/discord-notify.sh"
}]
}]
}
}
WEBHOOK_URL="$DISCORD_CC_WEBHOOK_URL"
DIFF=$(git diff --stat | tail -n 20)
curl -s -X POST "$WEBHOOK_URL" \
-H "Content-Type: application/json" \
-d "$(jq -n --arg diff "$DIFF" \
'{content:"✅ 完了", embeds:[...]}')"

Codex × Claude Code 相互査読ワークフロー

PreToolUse / PostToolUse / Notification / Stop / SubagentStop

設定単位
~/.claude/settings.json（グローバル）
または .claude/settings.json（プロジェクト）

実行方式
シェルコマンドとしてcurl 等を直接実行できる

注意
Webhook URL は環境変数で管理し、
ハードコード禁止

6

3. 実装 実装② Codex CLI 側 2026年時点、フック機構は “UnderDevelopment” 扱い。制約を踏まえた設計が必要 ⚠ 機能フラグ必須 ⚠ 対象は Bash のみ config.toml で [features].codex_hooks = true と 明示的に有効化しないと動作しない PreToolUse が対象にできるのは現状 Bash ツール呼び出しのみ。 apply_patch やファイル編集、 MCPツール呼び出しは対象外 ~/.codex/config.toml レビュアー起動：ヘッドレス実行 [features] codex_hooks = true 文脈分離の原則（原則B）を機械的に守るため、対話セッションでなく codex exec を使う [[hooks]] event = "PostToolUse" matcher = "shell" command = "bash ~/.codex/hooks/discord-notify.sh" Codex × Claude Code 相互査読ワークフロー codex exec "diffをレビューしてください。 SPEC.mdとの矛盾、セキュリティ上の 懸念、ロジックの誤りを指摘してください。" 7

3. 実装 Discord中継Botの設計要点 discord.py / discord.js なら数十行程度の実装で足りる 1 役割タグを必須にする 投稿に「[Generator: Codex]」のようなタグを付け、 Botがどちらのモデルが書いたかを機械的に判 定できるようにする 原則Aの強制 Codex × Claude Code 相互査読ワークフロー 2 3 スレッド単位でセッションを分離 Webhook URLはSecret管理 1つのレビュー依頼＝ 1スレッドとし、 知っている人は誰でも投稿できてしまうため、 過去の議論が別案件に混入しないようにする 環境変数・ Secret Managerで管理する 文脈の分離 毎分30リクエスト程度のレート制限も考慮 8

4. 応用 運用への組み込み方 CIゲート化 専門分業 多段レビュー Codex × Claude Code 相互査読ワークフロー PR作成時にGitHub ActionsからCodexまたはClaude Codeを“批評役(Critic)”として起動。Discordには結果のサマリのみ流 し、実装ログはCIに残す コード生成が得意なモデルと、指示追従・慎重な推論が得意なモデルを固定せず、案件ごとに入れ替えて偏りを減らす Generator → Reviewer（別モデル） → Reconciler（人間 or 三者目のモデル）の3段構成。Discordのチャンネルをそのままス テージ管理に使う 9

5. 確認・検証 「効いている」とどう確認するか クロスモデルレビューには効果があるという報告がある一方、万能ではない ✓ 効果が出やすい領域か セキュリティ・ロジックエラーのような、モデル間で見落としパターンが異なりやすい 領域か。単純な整形・スタイル指摘なら単一モデルでも十分という指摘も踏まえ費 用対効果を見る ✓ 最終判断は人間に残す 合流層（Reconciler）を自動化しきらず、マージ可否の最終責任は人間が持つ設計 にする Codex × Claude Code 相互査読ワークフロー ✓ ラウンド数を増やしすぎない 同一文脈内で往復を重ねても改善しにくいという報告がある以上、“新規セッション での1回の独立レビュー”を軸に設計する ✓ 誤検知・過検知を記録する レビュアー側指摘の採択率をログ化し、ノイズが多い場合はプロンプトやレビュー範 囲を見直す 10

6. 研修での扱い方 法人研修で教える際の注意点 ツールの繋ぎ方以上に、考え方をセットで教えることが重要 単純化を避ける 1 「別モデルにレビューさせれば安全」という単純化は避ける。効果が実証されているのは限定的な条件下（役割分離・文脈分離）であることを明示する セキュリティ運用とセットで扱う 2 Webhook URLの漏洩・フックスクリプトの信頼性レビュー（Codex CLIも“未レビューのフックは信頼確認が必要”という設計）など、基礎とセットで扱う モデル同士の合意を過信しない 3 両方のモデルが同じ盲点を共有している可能性は常に残る。人間のレビューを代替するものではなく補完するものと位置づける Codex × Claude Code 相互査読ワークフロー 11

まとめ 自己レビューの弱点（迎合・文脈汚染）を避けるには、書いた本人に採点させない・新規セッションで読む、という2原則が軸になる Discordは、CodexとClaude Codeという別ベンダーCLIを“文脈分離したまま”仲介できるハブとして使いやすい Claude Code・Codex CLIともにフック機構を持つが、Codex側はBashツールのみ対象・機能フラグ必須という制約があるため設計時に確認が 要る 効果があるとされる領域（セキュリティ・ロジックエラー）とそうでない領域（単純な整形）を見極め、往復回数を無闇に増やさず、最終判断は 人間に残す 人間のレビューを代替するものではなく、補完するもの。