先週、AnthropicはClaude Codeでプロダクションアプリを構築するための推奨アーキテクチャを公開しました。中核となる考え方は、Plannerがプロンプトを拡張して仕様にし、Generatorが機能を実装し、Evaluatorが出力を基準に照らして評価するというマルチエージェントの仕組みです。
これはGANsに着想を得た堅牢なパターンです。1つのシステムが生成し、別のシステムが批評し、その緊張関係が品質を押し上げます。
しかし、誰も話題にしていないギャップがあります。
共有される盲点問題
あなたのGeneratorがClaudeで、EvaluatorもClaudeの場合、それらは同じ学習データ、同じバイアス、同じ盲点を共有します。
それは、あなたの共に働く人に、あなたが手伝って書いたものを校正してもらうようなものです。彼らは誤字を見つけるでしょう。しかし構造的な問題――誤った前提、あなたたち二人が思いつかなかったエッジケース――は生き残ってしまいます。なぜなら、あなたたちは「正しいもの」がどう見えるかという同じメンタルモデルを共有しているからです。
私たちはこの状況を目にしてきました：
- 評価は通ったが、期限切れのないクライアントサイドのトークン保存を使っていた認証フロー
- 両方のエージェントが「完了」とみなしたが、レート制限がなかったAPIエンドポイント
- テストでは動いたが、プロダクションのスケールに対してインデックスがなかったデータベースクエリ
Generatorは「動くかどうか」を最適化します。Evaluatorは同じ質問を少し違う角度から問いかけます。でも、誰も次のことを問わないのです：「これを本番で壊すとしたら何でしょう？」
同一モデルのEvaluatorが見逃すもの
コード生成時、AIモデルには一貫した失敗パターンがあります。それらはランダムではありません。体系的です：
ハッピーパス最適化。 AIは、想定される入力を完璧に扱うコードを書きます。エッジケース、同時アクセス、ネットワークタイムアウトなどは、モデルがプロダクションのシナリオではなくプロンプトの状況に最適化してしまうため、飛ばされがちです。
セキュリティを後回しにする姿勢。 モデルは、セキュリティをジュニア開発者がよくやるのと同じように扱います――機能が動くようになってから追加するもの。ハードコードされたシークレット、CSRFの不足、SQLインジェクションのベクターなどです。
被害範囲の盲目性。 エージェントが認証ミドルウェアを変更したとしても、それがそのモジュールに依存するどれだけのサービスに影響するかを考えません。モデルはローカルに考え、システム全体としては考えないのです。
テストカバレッジの穴。 AIが生成するテストは実装をなぞります。コードにバグがあれば、そのテストは、そのバグを「期待される振る舞い」としてエンコードしてしまうことがよくあります。
なぜ外部評価がすべてを変えるのか
成熟したエンジニアリング組織は、コードを書いた開発者に対して、そのセキュリティレビューも同時に書かせたりしません。別チームがあり、別のチェックリストがあります：
- セキュリティレビューは機能ではなく、攻撃ベクターを探す
- アーキテクチャレビューは正しさではなく、結合度や被害範囲を見る
- パフォーマンスレビューは機能の完成度ではなく、ボトルネックを見る
AIコードでも同じことが言えます。外部評価は、Generatorが最適化していなかった次元にまたがってスコア付けすべきです：
- セキュリティ――認証変更、シークレット、インジェクションのリスク
- 被害範囲――どれだけ多くのコンポーネントに影響するか
- テストの穴――テストが新しい振る舞いを実際にカバーしているか
- 依存関係――サプライチェーン上の懸念
- 破壊的変更――API契約の修正
評価基準が生成基準と直交している場合、Generatorが構造的に見られない問題を見つけられます。
欠けていたピース：進化する信頼
Anthropicの仕組み（ハーネス）は、各スプリントを同じ扱いにします。最初の機能も、50回目の機能も、同一の評価を受けます。記憶も学習もありません。
しかし実際のチームでは、信頼は積み上げで得られます。綺麗なコードを一貫して出荷している開発者は、日常的な変更に対する精査が少なくて済みます。AIエージェントも同じようにあるべきです：
- 新しいエージェントは最大の精査から開始する
- クリーンなPRごとに信頼が段階的に積み上がる
- 高リスクの指摘が出たら、信頼は即座にリセットされる
- 信頼されたエージェントは低リスク変更を自動マージする
- 信頼されていないエージェントは人によるレビューが必要になる
そのハーネスは、スプリントごとの品質管理を提供します。信頼スコアリングは、時間とともに増幅していく品質管理を与えます。
全体像
Anthropicのハーネスは単一セッション内のコード品質を解決します。しかし、次の課題には対処していません：
- セッションをまたいだ学習（エージェントは時間とともに改善するのか？）
- マルチエージェントのガバナンス（1つのリポジトリでClaude + Copilot + Cursor）
- リスクに比例したレビュー（依存関係の更新と認証ミドルウェア変更の扱い）
- 監査ログ（どのエージェントが、どのリスクスコアで、どの判断をしたのか）
Generator-Evaluatorのループは、内側のフィードバックサイクルを処理します。ガバナンスはその外側のすべて――組織のポリシー、信頼関係、リスクベースのルーティング――を扱います。
どうするべきか
- ハーネスのパターンを使う：インナーループの品質のために使います。機能します。
- 外部評価を追加する：Generatorが最適化していなかった、異なる基準で評価します。
- 信頼を段階的に構築する。 クリーンなコードを出すエージェントを追跡します。データでレビュー方針を決めましょう。
- 安全なものは自動化する。 信頼されたエージェントによる低リスクPRは、人によるレビューを必要としません。
- 監査ログを保持する。 本番が壊れたときに、その変更を導入したエージェントまで追跡できます。
ハーネスはより良いコードをもたらします。ガバナンスは、出荷されるものが安全であるという確信をくれます。両方が必要です。
これは私たちが MergeShield で取り組んでいるアプローチです。6つの次元にまたがる外部リスクスコアリング、時間とともに進化するエージェントごとの信頼スコア、そして信頼されたエージェントの自動マージルールを提供します。挙動を確認するには インタラクティブなデモを試してみてください。
