クロスモデル検証
VMark は互いに挑戦し合う 2 つの AI モデルを使用しています: Claude がコードを書き、Codex がそれを監査します。この敵対的セットアップにより、単一モデルでは見落とすバグを捉えます。
なぜ 2 つのモデルが 1 つより優れているのか
すべての AI モデルには盲点があります。あるカテゴリのバグを一貫して見落としたり、より安全な代替品よりも特定のパターンを好んだり、自分の仮定を疑わないことがあります。同じモデルがコードを書いてレビューすると、それらの盲点は両方のパスで生き残ります。
クロスモデル検証はこれを打ち破ります:
- Claude（Anthropic）が実装を書きます — 完全なコンテキストを理解し、プロジェクトの規約に従い、TDD を適用します。
- Codex（OpenAI）が独立して結果を監査します — 新鮮な目でコードを読み、異なるデータで訓練され、異なる失敗モードを持ちます。
モデルは真に異なります。それらは別々のチームによって構築され、異なるデータセットで訓練され、異なるアーキテクチャと最適化目標を持ちます。両方がコードが正しいと同意すると、単一モデルの「大丈夫に見える」より信頼性がはるかに高くなります。
研究は複数の角度からこのアプローチを支持しています。マルチエージェントディベート — 複数の LLM インスタンスが互いの応答に挑戦 — は事実性と推論精度を大幅に改善します[1]。ロールプレイプロンプティング（モデルに特定の専門家の役割を割り当てる）は推論ベンチマークで標準的なゼロショットプロンプティングを一貫して上回ります[2]。最近の研究では、最先端の LLM が評価されていることを検出して動作を調整できることが示されています[3] — これは別の AI によって詳細に調べられることを知っているモデルが、より慎重で媚びのない作業を生み出す可能性が高いことを意味します[4]。
クロスモデルが捉えるもの
実際には、2 番目のモデルは次のような問題を見つけます:
- 最初のモデルが自信を持って導入した ロジックエラー
- 最初のモデルが考慮しなかった エッジケース（null、空、Unicode、並行アクセス）
- リファクタリング後に残った デッドコード
- 一方のモデルのトレーニングがフラグを立てなかった セキュリティパターン（パストラバーサル、インジェクション）
- 書くモデルが合理化してしまった 規約違反
- モデルが微妙なエラーでコードを複製した コピーペーストバグ
これは人間のコードレビューの原則と同じです — 2 つ目の目がコードを書いた人には見えないものを捉えます — ただし両方の「レビュアー」と「著者」が疲れ知らずで、コードベース全体を数秒で処理できます。
VMark での動作方法
Codex Toolkit プラグイン
VMark はcodex-toolkit@xiaolai Claude Code プラグインを使用しており、Codex を MCP サーバーとしてバンドルします。プラグインが有効化されると、Claude Code は自動的にcodex MCP ツールにアクセスできます — Codex にプロンプトを GOOD して構造化された応答を受け取るためのチャンネル。Codex は サンドボックス化された読み取り専用コンテキスト で実行されます: コードベースを読めますがファイルを変更できません。すべての変更は Claude が行います。
セットアップ
- Codex CLI をグローバルにインストールして認証:
npm install -g @openai/codex
codex login # ChatGPTサブスクリプションでログイン（推奨）- xiaolai プラグインマーケットプレイスを追加（初回のみ）:
claude plugin marketplace add xiaolai/claude-plugin-marketplace- Claude Code に codex-toolkit プラグインをインストールして有効化:
claude plugin install codex-toolkit@xiaolai --scope project- Codex が利用可能か確認:
codex --versionそれだけです。プラグインは Codex MCP サーバーを自動的に登録します — 手動での.mcp.jsonエントリーは不要。
サブスクリプション vs API
劇的に低いコストのためにOPENAI_API_KEYの代わりにcodex login（ChatGPT サブスクリプション）を使用してください。サブスクリプション vs API プライシングをご覧ください。
macOS GUI アプリの PATH
macOS GUI アプリは最小限の PATH を持ちます。codex --versionがターミナルで動作するのに Claude Code が見つけられない場合、Codex バイナリの場所をシェルプロフィール（~/.zshrcまたは~/.bashrc）に追加してください。
プロジェクト設定
/codex-toolkit:initを実行してプロジェクト固有のデフォルト（監査フォーカス、努力レベル、スキップパターン）を含む.codex-toolkit.md設定ファイルを生成します。
スラッシュコマンド
codex-toolkitプラグインは Clause + Codex のワークフローを調整する事前構築されたスラッシュコマンドを提供します。インタラクションを手動で管理する必要はありません — コマンドを呼び出すだけで、モデルが自動的に調整します。
/codex-toolkit:audit — コード監査
主要な監査コマンド。2 つのモードをサポートします:
- Mini（デフォルト） — 高速 5 次元チェック: ロジック、重複、デッドコード、リファクタリング債務、ショートカット
- Full（
--full） — 徹底的な 9 次元監査でセキュリティ、パフォーマンス、準拠、依存関係、ドキュメントを追加
| 次元 | チェック内容 |
|---|---|
| 1. 冗長コード | デッドコード、重複、未使用のインポート |
| 2. セキュリティ | インジェクション、パストラバーサル、XSS、ハードコードされたシークレット |
| 3. 正確さ | ロジックエラー、競合状態、null 処理 |
| 4. 準拠 | プロジェクトの規約、Zustand パターン、CSS トークン |
| 5. 保守性 | 複雑さ、ファイルサイズ、命名、インポートの健全性 |
| 6. パフォーマンス | 不必要な再レンダリング、ブロッキング操作 |
| 7. テスト | カバレッジのギャップ、欠落しているエッジケーステスト |
| 8. 依存関係 | 既知の CVE、設定セキュリティ |
| 9. ドキュメント | 欠落しているドキュメント、古いコメント、ウェブサイトの同期 |
使い方:
/codex-toolkit:audit # コミットされていない変更についてのMini監査
/codex-toolkit:audit --full # 完全な9次元監査
/codex-toolkit:audit commit -3 # 最後の3コミットを監査
/codex-toolkit:audit src/stores/ # 特定のディレクトリを監査出力は重大度評価（重大/高/中/低）とすべての発見に対する修正提案を含む構造化されたレポートです。
/codex-toolkit:verify — 以前の修正を検証
監査の発見を修正した後、Codex に修正が正しいことを確認してもらいます:
/codex-toolkit:verify # 最後の監査からの修正を検証Codex は報告された場所の各ファイルを再読み取りし、各問題を修正済み、未修正、または部分的に修正済みとしてマークします。また、修正によって導入された新しい問題をスポットチェックします。
/codex-toolkit:audit-fix — 完全なループ
最も強力なコマンド。監査 → 修正 → 検証をループでチェーンします:
/codex-toolkit:audit-fix # コミットされていない変更でループ
/codex-toolkit:audit-fix commit -1 # 最後のコミットでループ何が起こるか:
ループは Codex がすべての重大度でゼロの発見を報告したとき、または 3 回の反復後（残りの問題があなたに報告される）に終了します。
/codex-toolkit:implement — 自律的な実装
Codex にプランを送って完全な自律的実装:
/codex-toolkit:implement # プランから実装/codex-toolkit:bug-analyze — 根本原因分析
ユーザーが説明したバグの根本原因分析:
/codex-toolkit:bug-analyze # バグを分析/codex-toolkit:review-plan — プランレビュー
アーキテクチャレビューのために Codex にプランを送る:
/codex-toolkit:review-plan # 一貫性とリスクのためにプランをレビュー/codex-toolkit:continue — セッションを続ける
発見について反復するために以前の Codex セッションを続ける:
/codex-toolkit:continue # 中断したところから続ける/fix-issue — エンドツーエンドの Issue 解決者
このプロジェクト固有のコマンドは GitHub Issue の完全なパイプラインを実行します:
/fix-issue #123 # 単一のIssueを修正
/fix-issue #123 #456 #789 # 複数のIssueを並行して修正パイプライン:
- GitHub から Issue を 取得
- 分類（バグ、機能、または質問）
- 説明的な名前での ブランチ 作成
- TDD での 修正（RED → GREEN → REFACTOR）
- Codex 監査ループ（最大 3 ラウンドの監査 → 修正 → 検証）
- ゲート（
pnpm check:all+ Rust が変更された場合はcargo check） - 構造化された説明での PR 作成
クロスモデル監査はステップ 5 に組み込まれています — すべての修正が PR が作成される前に敵対的レビューを受けます。
特化エージェントとプランニング
監査コマンドを超えて、VMark の AI 設定には上位レベルのオーケストレーションが含まれます:
/feature-workflow — エージェント駆動の開発
複雑な機能のために、このコマンドは特化サブエージェントのチームを展開します:
| エージェント | 役割 |
|---|---|
| プランナー | ベストプラクティスを調査し、エッジケースをブレインストーミングし、モジュール式のプランを生成 |
| 仕様ガーディアン | プロジェクトルールと仕様に対してプランを検証 |
| 影響アナリスト | 最小限の変更セットと依存関係エッジをマップ |
| 実装者 | プリフライト調査付きの TDD 駆動実装 |
| 監査者 | 正確さとルール違反について diff をレビュー |
| テストランナー | ゲートを実行し、E2E テストを調整 |
| 検証者 | リリース前の最終チェックリスト |
| リリーススチュワード | コミットメッセージとリリースノート |
使い方:
/feature-workflow sidebar-redesignプランニングスキル
プランニングスキルは以下を含む構造化された実装プランを作成します:
- 明示的な作業アイテム（WI-001、WI-002、... ）
- 各アイテムの受け入れ基準
- 最初に書くテスト（TDD）
- リスク軽減とロールバック戦略
- データ変更が含まれる場合の移行プラン
プランは実装中の参照のためにdev-docs/plans/に保存されます。
アドホックな Codex 相談
構造化されたコマンドを超えて、いつでも Claude に Codex に相談するよう頼めます:
あなたの問題をまとめて、Codexに助けを求めてください。Claude は質問を作成し、MCP 経由で Codex に送り、応答を組み込みます。これは Claude が問題で詰まっているときや、アプローチについてセカンドオピニオンが欲しいときに役立ちます。
より具体的にすることもできます:
このZustandパターンが古い状態を引き起こす可能性があるかどうかをCodexに尋ねてください。このマイグレーションのSQLをエッジケースについてCodexにレビューしてもらってください。フォールバック: Codex が利用できない場合
Codex MCP が利用できない場合（インストールされていない、ネットワーク問題など）、すべてのコマンドが適切に機能低下します:
- コマンドはまず Codex に「
Respond with 'ok'」と ping します - 応答がない場合: 手動監査 が自動的に開始されます
- Claude が各ファイルを直接読み取り、同じ次元分析を実行します
- 監査はまだ起こります — ただしクロスモデルではなくシングルモデルです
Codex がダウンしているためにコマンドが失敗することを心配する必要はありません。常に結果を生み出します。
哲学
アイデアはシンプルです: 信頼するが確認する — 異なる脳で。
人間のチームはこれを自然に行います。開発者がコードを書き、同僚がレビューし、QA エンジニアがテストします。各人が異なる経験、異なる盲点、異なるメンタルモデルをもたらします。VMark は同じ原則を AI ツールに適用します:
- 異なるトレーニングデータ → 異なる知識のギャップ
- 異なるアーキテクチャ → 異なる推論パターン
- 異なる失敗モード → 一方が見落とし他方が捉えるバグ
コストは最小限（監査ごとに数秒の API 時間）ですが、品質の改善は実質的です。VMmark の経験では、2 番目のモデルは通常最初のモデルが見落とした監査あたり 2〜5 の追加問題を見つけます。
Du, Y., Li, S., Torralba, A., Tenenbaum, J.B., & Mordatch, I. (2024). Improving Factuality and Reasoning in Language Models through Multiagent Debate. ICML 2024. 複数の LLM インスタンスがいくつかのラウンドにわたって応答を提案し議論することで、すべてのモデルが最初に間違った答えを生成しても、事実性と推論が大幅に改善されます。 ↩︎
Kong, A., Zhao, S., Chen, H., Li, Q., Qin, Y., Sun, R., & Zhou, X. (2024). Better Zero-Shot Reasoning with Role-Play Prompting. NAACL 2024. LLM にタスク固有の専門家の役割を割り当てることで、12 の推論ベンチマークにわたって標準的なゼロショットとゼロショット思考の連鎖プロンプティングを一貫して上回ります。 ↩︎
Needham, J., Edkins, G., Pimpale, G., Bartsch, H., & Hobbhahn, M. (2025). Large Language Models Often Know When They Are Being Evaluated. 最先端モデルは評価コンテキストと実際のデプロイを区別できます（Gemini-2.5-Pro は AUC 0.83 に達する）。別の AI が出力をレビューすることを知っているモデルがどのように動作するかについての意味があります。 ↩︎
Sharma, M., Tong, M., Korbak, T., et al. (2024). Towards Understanding Sycophancy in Language Models. ICLR 2024. 人間のフィードバックで訓練された LLM は、真実の応答を提供するのではなく、ユーザーの既存の信念に同意する傾向があります。評価者が人間ではなく別の AI である場合、この媚びるプレッシャーが取り除かれ、より正直で厳密な出力につながります。 ↩︎