Multi-Instance・Multi-Pass レビューアーキテクチャ

CCA-F（Claude Certified Architect — Foundations）試験のタスクステートメント 4.6「multi-instance・multi-pass レビューアーキテクチャの設計」は、Domain 4（プロンプトエンジニアリングと構造化出力、20% の比重）に位置し、単一の Claude 呼び出しでは信頼性が不十分な場合に CCA-F 受験者が手を伸ばすべきパターン言語を定義する。試験ではこのタスクを主に2つのシナリオクラスターで出題する：Structured Data Extraction（アンサンブルおよび judge-model パターンが高精度フィールド抽出の精度を向上させるケース）と Multi-Agent Research System（連続する専門化パスとレビュアーインスタンスが合成品質を守るケース）。コミュニティの合格報告では 4.6 は「配点は小さいが曖昧性が高い」トピックとして繰り返し挙げられており、コスト品質トレードオフおよび同一モデルによる judge の相関エラー失敗パターンを暗記していない限り、引っかけ選択肢が正当に見えてしまう。

この学習ノートでは CCA-F 受験者が設計できると期待される multi-instance・multi-pass の全領域を解説する：N 個の並列 Claude インスタンスを同一入力で実行することと、同一アーティファクトに N 個の順次専門化パスを実行することの定義上の違い、具体的なユースケース（高リスク分類、法的レビュー、複雑なコード解析）、アンサンブル投票のメカニズム、judge-model 批評パターン、専門化パスの分解（文法、論理、コンプライアンス）、依存関係によるパス順序付け、単一の高コストコールに対するコスト品質経済性、インスタンスとパスにわたる信頼度集約、不一致エスカレーション閾値、そして多様性レバーとしての温度変動。一般的な試験の落とし穴、CCA-F 実践アンカー、6問の FAQ でノートを締めくくる。

Multi-Instance・Multi-Pass レビューアーキテクチャとは

Multi-instance・multi-pass レビューアーキテクチャは、単一の Claude 呼び出しが安定して生成できるものを超えて、出力品質を向上させるための、相補的な2つのパターンファミリーである。受験者が混同しやすい別個のパターンであり、試験はシナリオに対して正しい方を選択できるかをテストする。

Multi-instance アーキテクチャは、同一入力を複数の独立した Claude インスタンスに並列で通し、出力を（通常は投票または judge によって）集約するものである。変動の軸は Claude 自体である——異なる乱数シード、異なる温度設定、場合によっては異なるモデル——同一のプロンプトと同一の入力に適用される。

Multi-pass アーキテクチャは、同一入力を複数の順次パスに通すもので、それぞれが異なるプロンプト、役割、またはフォーカスを持つ。変動の軸はレビューの観点である——文法パス、続いて論理パス、続いてコンプライアンスパス——同一のアーティファクトに適用される。

両ファミリーは組み合わせることができる（multi-pass パイプラインの重要パスをそれ自体が multi-instance アンサンブルとして実行するなど）が、解決する問題が異なる。Multi-instance は単一回答の分散を低減する。Multi-pass は複雑なレビューをより狭い、扱いやすいサブレビューに分解する。

2つのファミリーの比較

Multi-Instance アーキテクチャ — 同一入力への複数 Claude 呼び出しによるコンセンサス

最もシンプルな multi-instance アーキテクチャは N サンプルアンサンブルである：同一のシステムプロンプト、同一のユーザー入力、同一のスキーマが N 回並行して Claude に発行される。各呼び出しが独立した出力を返し、集約器が N 個の出力を単一の最終回答にまとめる。

同一の呼び出しを N 回繰り返す理由

Claude の出力は温度 0 でも完全には決定論的ではなく、温度が高くなるほど分散は大きくなる。同一のプロンプトが時々エッジケースの誤回答——誤分類カテゴリ、見逃した抽出フィールド、ずれた感情ラベル——を生成するようなタスクでは、N 回実行して多数決を取ることで単一呼び出しのノイズを平滑化できる。基礎となる統計的主張は明快である：各呼び出しが独立して確率 p > 0.5 で正解する場合、N 回の呼び出しの多数決が正解する確率は N に対して急速に上昇する。

Multi-Instance がコストに見合う場合

Multi-instance は次の3つがすべて成り立つ場合に価値がある：

• 単一呼び出しの品質が閾値に近いが安定してそれを超えていない。
• N 回の呼び出しを実行する単位コストが許容できる（通常、下流の判断が高価値であるため）。
• エラーモードが呼び出し間で相関していない（体系的な盲点ではなく、分散）。

Multi-Instance が適切でない場合

基礎モデルに体系的な盲点がある場合、multi-instance は助けにならない——プロンプトが特定のエッジケースを常に誤分類するなら、10回実行しても同じ誤回答が10個生成されるだけである。単一の高コスト呼び出し（より多くのコンテキスト、より良い例、より厳密なツールスキーマ）が既に品質基準を超えられるタスクでも役に立たない；そのような場合、単一呼び出しへの投資がアンサンブルより優れている。

Multi-Pass アーキテクチャ — 同一アーティファクトへの順次専門化パス

Multi-pass アーキテクチャは、同一のアーティファクト（法的文書、コード差分、サポートチケットの下書き）を複数の順次パスでレビューし、各パスが単一の全包括的レビュープロンプトよりも狭いフォーカスを持つ。前のパスの出力が後のパスに構造化されたコンテキストとして供給される。

パスを専門化する理由

「このプルリクエストをセキュリティ、パフォーマンス、スタイル、テストカバレッジ、ビジネスロジックの観点でレビューしてください」と Claude に求める単一のプロンプトは、5つの観点すべてに注意を薄く分散させる。同じ5つの問題事項を5つの順次パスとして実行すれば、それぞれが1つの Claude 呼び出しの全命令予算と全出力予算を得られる。コミュニティで報告されている試験の言語は明確である：観点が注意を奪い合うような場合、複雑な判断を狭いステップに分解することは単一のメガプロンプトよりも優れている。

3パス標準形

典型的な CCA-F グレードのパイプラインは次のようになる：

1. 構造パス — アーティファクトは正しい形を持っているか？（有効な JSON、期待されるセクションの存在、必須フィールドの入力）
2. 内容パス — ビジネスコンテキストを考慮した場合、内容は正確か？（ソースとの事実の一致、論理的健全性、主張の裏付け）
3. スタイル / コンプライアンスパス — アーティファクトはプレゼンテーションおよび規制上のルールを満たしているか？（トーン、長さ、必要な開示、禁止言語）

各パスは次のパスが取り込む構造化レポート（合格/不合格とメモ）を生成する。最終出力は結合された判定である。

Multi-Pass はレビュアー付きのプロンプトチェーン

Multi-pass レビューはプロンプトチェーンの特定の応用である。チェーンプロンプトのドキュメントは一般的なパターンを説明しており、multi-pass レビューはそれを各ステップが新しいアーティファクトを生成するビルダーではなく、異なる観点から同一のアーティファクトを検査するレビュアーであるケースに絞り込んでいる。

ユースケース — 高リスク分類、法的レビュー、複雑なコード解析

CCA-F のシナリオ問題は、単一呼び出しがもっともらしく十分なユースケースを選び、レビューアーキテクチャの追加コストを正当化するよう求める傾向がある。重みを担うのは3つの標準的なファミリーである。

高リスク分類（Structured Data Extraction シナリオ）

分類ラベルが下流のビジネス行動——詐欺/非詐欺、エスカレート/自動クローズ、規制申請の一致/不一致——を駆動する場合、単一呼び出しの分散は直接ビジネスリスクに変換される。5インスタンスのアンサンブルと多数決により、単一呼び出しで 85% の精度を大幅に向上させた最終回答が得られ、多くの場合そのコストは誤ったラベルの下流への影響に比べれば安価である。

法的レビュー

法的文書は複数の独立した複雑なレビュー観点を組み合わせている——条項間の定義の一貫性、相互参照の整合性、管轄固有の規則への準拠、契約条件の境界——これらはきれいに1つのプロンプトに収まらない。観点ごとに1つのパスを持ち、依存関係の順序で連鎖したマルチパスパイプラインは、単一の「この契約をレビューしてください」という呼び出しを常に上回る。また、各パスが独立した証跡を生成するため、multi-pass の結果はより監査可能である。

複雑なコード解析（Claude Code によるコード生成シナリオ）

コードレビューには正確性レビュー、セキュリティレビュー、スタイルレビュー、テストカバレッジレビューが必要である。Multi-pass パイプラインは各観点を独自のパスで実行し、構造パス（差分はコンパイルされるか？）が後続のセマンティックパスをゲートする。非常に高リスクな変更の場合、重要なパス（例えばセキュリティ）はそれ自体が multi-instance アンサンブルとして実行でき、両ファミリーを組み合わせる。

その他の本番グレード候補

• 医療トリアージノートレビュー（multi-pass：症状抽出、続いてリスクスコアリング、続いて処置方針）。
• 財務開示書草案作成（multi-pass：事実、続いてコンプライアンス、続いてトーン；コンプライアンスパスには multi-instance）。
• 学術ピアレビューシミュレーション（温度変動により多様な批評を表面化させる同一論文への multi-instance）。

アンサンブル投票 — 堅牢性のための独立インスタンスにわたる多数決

アンサンブル投票は典型的な multi-instance 集約器である。3つの投票戦略がほぼすべての試験ケースをカバーする。

単純多数決

N 個のインスタンスがそれぞれカテゴリ出力を生成する。集約器は最多票のカテゴリを選択する。同数の場合は決定論的なルールで決着する（例えば最も低い辞書順ラベル、または再質問プロンプトによるタイブレーカー）。これは単一ラベル分類（スパム/非スパム、12択のカテゴリ、1〜5の重大度レベル）に適した集約器である。

信頼度による重み付き投票

各インスタンスはラベルだけでなく信頼スコアも返す。投票は信頼度によって重み付けされる。高信頼度のインスタンスは2つの低信頼度インスタンスを上回る。これはモデルが較正された信頼度を生成する場合に機能するが——デフォルトではそうでないことが多いため、重み付き投票に依存する前に必ず較正を評価すること。

構造化抽出のためのフィールドレベル投票

構造化抽出では、投票はフィールドごとに実行される。5つのインスタンスが name、date_of_birth、diagnosis_code フィールドを持つ JSON オブジェクトを抽出する場合、集約器は各フィールドについて独立して投票する。これは重要である：単一のインスタンスが4つのフィールドを正確に取得して1つを見逃す可能性があるため、フィールドレベルの投票は正確な4つを保持し、5番目をアンサンブルの多数決で置き換える。

奇数 N の理由

二値または小カテゴリ問題で同数が不可能になるよう、多数決アンサンブルには常に奇数 N（3、5、7）を選ぶこと。偶数 N はタイブレーカーを必要とし、レイテンシを追加（再質問）するか、偏りを導入する（常に最初を選ぶ、常に最も信頼度の高いものを選ぶ）。

Judge-Model パターン — 2番目の Claude インスタンスによる最初の出力のスコアリングまたは批評

Judge-model パターンは2段階の multi-instance アーキテクチャであり、最初のインスタンスが候補出力を生成し、2番目のインスタンス——judge——が候補をスコアリング、批評、または承認/拒否する。judge インスタンスには異なるレビュー指向のシステムプロンプトが与えられる。

2つの一般的なバリアント

• スコアリングとゲーティング — judge は数値スコアと合格/不合格を返す；閾値以下の出力は拒否され、再生成、エスカレーション、または人間のレビュアーに渡される。
• 批評と修正 — judge は具体的な問題点（単なる評価ではなく）を含む構造化フィードバックを返し、元のインスタンスがそのフィードバックで再生成し、judge が承認するかリトライ上限に達するまでループが続く。

Judge が価値を加える場合

judge はレビュータスクが生成タスクより簡単な場合に価値を加える。一貫したサマリーを書くことは難しい；サマリーがソースを忠実に表現しているかを評価することはより簡単である。法的に準拠した条項を草案することは難しい；草案された条項が7つの必要なポイントに達しているかを確認することはより簡単である。この非対称性が生成とレビューを分離する核心的な正当化理由である。

相関エラーリスク

judge は通常、候補生成者と同じ Claude モデルであるため、モデルが持つ体系的な盲点を judge も共有する。Claude が特定の慣用句を常に誤読する場合、judge もそれを見逃す。同一モデルの judge はランダムエラーと文体エラーを効果的に低減するが、相関エラーは捉えられない。コミュニティの合格報告ではこれが繰り返し出る落とし穴として指摘されている——「judge は正確さを保証する」と主張する回答は間違いである。

Judge プロンプトの設計

judge プロンプトはスコアリング基準を明確にし、judge の注意がレビューに完全に費やされるよう十分に簡潔で、集約器が judge の判定に対してプログラム的に行動できるよう構造化出力（スキーマまたはツール使用）を要求するべきである。自由形式の散文で構築された judge は信頼性の高いパイプラインへの統合が難しい。

専門化パスの設計 — レビューの文法、論理、コンプライアンスパスへの分解

専門化パスの設計は、広いレビューを単一の Claude 呼び出しで正確に実行できる狭いパスに分割する技術である。具体的な内容はドメインに依存するが、方法は一貫している。

直交するレビュー観点の選択

良いパスは直交的である——アーティファクトの異なる次元を検査し、その発見が重複しない。文法、論理、コンプライアンスは直交的である：文法は形式について、論理は意味について、コンプライアンスはルールについてである。不適切に選ばれたパスは重複する（例えば「スタイル」と「トーン」は大部分が重複する）ため、パスごとの呼び出し予算を無駄にする。

各パスのスコープを狭く保つ

各パスは集中した指示のほぼ1ページ以下のプロンプトを持つべきである。指示が数ページにわたるパスは実際には複数のパスが1つになっているもので、さらに分割するべきである。

散文ではなく構造化レポートを生成する

すべてのパスは、パイプラインが自由テキスト解析なしに発見事項に対応できるよう、構造化レポート（ツール使用または JSON スキーマ）を生成するべきである。文法パスは {issue, location, severity} のリストを返す。論理パスは {claim, status, evidence} のリストを返す。コンプライアンスパスは {rule_id, satisfied, explanation} のリストを返す。

発見事項をアーティファクトに統合する

専門化パスは通常、アーティファクトとすべてのパスのレポートを受け取り、修正バージョンを生成する最終修正パスに供給される。これはレビュアーパス自体とは異なり、別の呼び出しとして書かれるべきである。

パス順序付け — 依存関係による順序付け（構造 → 内容 → スタイル）

パスの順序を正しく設定することはパスを選択することと同様に重要である。誤った順序は後続のパスによって無効化される発見事項へのパス予算を無駄にする。

依存関係優先の順序付け

最初に構造パスを実行し（アーティファクトはそもそも正しい形を持っているか？）、次に内容パス（書かれていることは正確か？）、次にスタイルまたはコンプライアンスパス（ルールを満たしているか？）。この順序を逆にすると——例えば構造パスより前にコンプライアンスパスを実行する——構造パスが完全に拒否するアーティファクトをコンプライアンスパスがレビューするリスクがあり、コンプライアンスの作業が無駄になる。

ハードフェイラー時の早期終了

構造パスが「これはそもそも有効な契約ではない」と返した場合、内容パスを実行しないこと。ハードフェイラー時の早期終了は、エージェンティックループ内のリトライまたは中止の判断に相当するシーケンシングである——最安の作業は前のステップが既に答えを決定したためにスキップする作業である。

パス間の連鎖を許可する

一部のパスは前のパスの出力を入力として必要とする。「事実検証」パスは「主張抽出」パスが最初に主張を列挙する必要がある。「赤線レビュー」パスは「差分抽出」パスが最初に変更を列挙する必要がある。厳密な線形チェーンではなくパイプライン DAG がこれらの依存関係をきれいに表現する。

安全な場合は直交パスを並列化する

真に独立したパスは並列で実行できる。文法パスは論理パスの出力に依存せず、逆も同様である；同時に実行することで集約結果を変えずにウォールクロックレイテンシを削減する。

コスト品質トレードオフ — Multi-Instance vs 単一高コスト呼び出しの経済性

Multi-instance アーキテクチャは単位コストを N 倍にする。アンサンブルに手を伸ばす前に、すべての CCA-F アーキテクトは単一の高コスト呼び出し——より良いコンテキスト、より良い例、より厳密なツールスキーマ、より高性能なモデル——が品質基準をより安価に満たせるかどうかを問うべきである。

3つの予算上の問い

1. 品質のヘッドルーム — 単一呼び出しは既に閾値に近いか、それとも遠く下回っているか？閾値をはるかに下回る呼び出しのアンサンブルはやはり閾値以下のままである。閾値に近い呼び出しのアンサンブルが超えるための後押しになる。
2. コストのヘッドルーム — 下流の判断は N 倍の呼び出しコストを正当化するほど価値があるか？無料ニュースレターが使う $0.001 の分類は5インスタンスのアンサンブルを支えられない；$10,000 の法的申請をゲートする $0.001 の分類は明らかに支えられる。
3. レイテンシのヘッドルーム — ユーザーは待てるか？Multi-instance は通常並列（最遅の呼び出しを超えるレイテンシ増加なし）だが、multi-pass は順次（全パスのレイテンシ合計）。レイテンシ感度の高いコンテキストでは、multi-pass はそのコスト表が示す以上に高コストである。

コストレバーとしてのバッチ処理

レイテンシ感度が低い multi-instance パイプラインでは、Message Batches API が呼び出し単位コストをほぼ半分（現在の価格設定で 50% 割引）に削減する。5インスタンスアンサンブルのインスタンスがすべて1つのバッチジョブとして送信される場合、2.5インスタンスの同期アンサンブルに近いコストになる。バッチの結果は最大 24 時間かかる可能性があるため、パイプラインがユーザー向けリクエスト内に存在する場合はバッチは適切でない。

対案設計としての単一高コスト呼び出し

より豊富なコンテキスト、より多くの例、より厳密な JSON スキーマ（strict ツール使用）、より高性能なモデル（Sonnet ティアではなく Opus ティア）を持つ単一呼び出しが、同等のコストで5インスタンスアンサンブルに勝つことがある。試験では N サンプルアンサンブルをデフォルトにする前にこの対案設計を検討するアーキテクトが評価される。

信頼度集約 — インスタンスまたはパスにわたる信頼シグナルの結合

アンサンブルまたは multi-pass パイプラインは最終回答以上のものを生成する——単一呼び出しが報告できるよりも豊富な信頼シグナルも生成する。

信頼度としての一致率

単純多数決アンサンブルでは、勝利した回答に投票したインスタンスの割合が信頼度の使用可能なプロキシとなる。5分の5の一致は強い信頼度を示す。5分の3は弱い信頼度であり、人間によるレビューを促すべきである。このプロキシはモデル非依存である——モデル自体が較正された信頼スコアを生成しない場合でも機能する。

インスタンスごとのスコアによる重み付き信頼度

各インスタンスが信頼スコアを返す場合、最終的な信頼度は勝利した票の重み付き平均として計算できる。これは一致率単独より情報量が多いが、モデルが較正されたスコアを生成する必要がある。

Multi-Pass の信頼度は連言的

Multi-pass パイプラインでは、アーティファクトが合格するためにすべてのパスが承認する必要がある。全体的な信頼度は、パスごとの信頼度の合計ではなく積（または最小値）である。コンプライアンスパスが 70% の信頼度で構造パスが 99% の信頼度の場合、パイプライン信頼度は最大 70% である。

大きさよりも較正が重要

信頼スコアは較正されている場合にのみ有用である——0.8 の信頼度は 80% の経験的精度に対応するべきである。Claude の生の信頼スコアはしばしば較正が不十分であり、ルーティング判断を行う前にアプリケーション側での較正（例えばホールドアウト検証セットを通じて）が必要である。

不一致処理 — インスタンス票が大きく分かれる場合のエスカレーション

Multi-instance パイプラインは不一致シグナルにおいて最も価値がある。インスタンスが一致する場合、パイプラインはスムーズに通過する；インスタンスが不一致の場合、パイプラインは特別な処理を必要とする真の不確実性を浮かび上がらせた。

エスカレーションの閾値

典型的な本番閾値：

• 全会一致 — 自動的に回答を受け入れる。
• 超多数 （例：5のうち4）— 受け入れるが定期監査のためにログに記録する。
• 過半数 （例：5のうち3）— 人間レビューまたは高性能モデルにエスカレートする。
• 過半数なし — 人間レビューに回す；自動的に解決しない。

エスカレーション先

• 人間レビュアー — 高リスク業務の標準的なエスカレーション先。
• より大きなモデル — 争われた入力を Sonnet ではなく Opus で実行することで不一致が解消されることがある（常に Opus で実行するのに比べて小さなコスト）。
• 拡張思考バリアント — より深い熟慮を促す拡張思考システムプロンプトで同一入力を実行することで不一致が解消されることがある。
• コンテキスト追加リトライ — より多くのコンテキスト（ソース文書、標準的な例）を提供することで、5のうち3が5のうち5に変わることが多い。

不一致ログはそれ自体が製品である

すべての不一致は、プロンプト、例、またはスキーマが改善を必要とする可能性があるシグナルである。不一致トレースをアーカイブする本番パイプラインにはプロンプト改善のフィードバックループがある。これが Anthropic のエスカレーションガイダンスが定期的なレビューのために完全なコンテキストとともに不一致のログ記録を強調する理由である。

温度変動 — インスタンス間の多様性のための異なる温度設定の使用

N 個のインスタンスすべてを温度 0 で実行すると N 個のほぼ同一の回答が得られ、アンサンブルの目的が無意味になる。温度変動は多数決が意味を持つほど多様な出力を生成するための主要なレバーである。

温度と多様性の曲線

温度 0 では、Claude の出力は可能な限り決定論的である——アンサンブルインスタンスは同一の回答に収束する。中程度の温度（約 0.5）では、各出力の品質を維持しながら投票が有益になるほど十分に出力が変動する。非常に高い温度（1.0 以上）では、出力が不規則になり品質が多様性の上昇より速く低下する。

実践的な温度スケジュール

• すべてのインスタンスを 0.5〜0.7 — シンプル、効果的、コミュニティで報告されているデフォルト。
• 段階的な温度 （例：0.3、0.5、0.7、0.9、1.1）— 幅広いスタイルの選択肢が欲しいクリエイティブなタスクに有用。
• 温度 0 + シードの変動 — サポートされている場合；緊密に制御された多様性を提供する。常に利用可能とは限らない。

温度は品質レバーではない

温度を上げても Claude がよりスマートになるわけではない；Claude の出力がより多様になる。Multi-instance アーキテクチャにおける温度の役割は、投票が有益になるほど十分な多様性を生成することに限られる。シードの変動なしの低温度はアンサンブルを無効にし；品質ガードなしの高温度はアンサンブルを台無しにする。

ツール使用との温度の組み合わせ

strict ツール使用によって抽出が強制される場合、スキーマは固定されるが、スキーマ内の値は依然として温度によって変動する。温度 0.5 での5インスタンス抽出アンサンブルでも5つの有効な JSON オブジェクトが生成される；投票はその後、5つのオブジェクトにわたってフィールドごとに実行される。

Multi-Instance と Multi-Pass の組み合わせ

2つのファミリーは相補的であり、頻繁に組み合わされる。Multi-pass パイプラインの重要パスはしばしば multi-instance アンサンブルとして実行され、重要でないパスは単一呼び出しのままとなる。

パイプライン例

契約レビューパイプライン：

1. 構造パス（単一呼び出し、安価）。
2. 内容パス（単一の高コスト呼び出し）。
3. コンプライアンスパス（フィールドレベルの投票による5インスタンスアンサンブル、コンプライアンスエラーが高リスクでアンサンブルが単一呼び出しの分散から保護するため）。
4. 修正パス（単一呼び出し、前のすべてのパスレポートを消費）。

このハイブリッドは最も重要な箇所でのみ N 倍の呼び出しコストを費やす。

なぜ常にすべてのパスをアンサンブルにしないのか

Multi-instance コストは N に対して線形にスケールするため、multi-pass パイプラインのすべてのパスをアンサンブルにするとコストがパスごとの N 値の積で乗算される。5インスタンスずつの3パスパイプラインはアーティファクトごとに15回の呼び出し予算を消費する。アーキテクトは単一呼び出しの分散が支配的なリスクであるパスのみをアンサンブルにする。

レビューアーキテクチャの可観測性

レビューパイプラインの可観測性は、エージェンティックループの可観測性のスーパーセットである。すべてのインスタンスの出力、すべてのパスの出力、すべての投票結果、すべての不一致トレースがアーカイブ可能でなければならない。

ログに記録するもの

• インスタンスごとの出力（完全な JSON またはテキスト）。
• インスタンスごとの信頼スコア（生成された場合）。
• フィールドごとの集約された投票結果。
• パスごとのレポート（構造化された発見事項）。
• パス依存関係トレース（どのパスが、どの順序で、どの入力で実行されたか）。
• 不一致トレース（インスタンス ID、温度、発散した出力）と再現するのに十分なコンテキスト。

ログ記録が第一級の関心事である理由

レビューパイプラインはしばしば監査される。法的レビューパイプラインは条項が承認された理由を説明できなければならない。医療トリアージパイプラインはノートが処置方針 X にルートされた理由を説明できなければならない。パイプラインの出力は最終判定だけではない——それを正当化する推論の証跡を伴った最終判定である。

やさしい解説: Multi-Instance・Multi-Pass レビューアーキテクチャの全体像をカバーする3つの異なる類比

類比1：医師の合議体 — 高リスク診断のための Multi-Instance アンサンブル

曖昧な診断を持つ患者を想像してほしい。一人の医師によるスキャンの読影は 85% 正確かもしれない——通常は正しく、時々間違える。高リスクなケースでは、病院は互いに相談せずに同じスキャンを各自がレビューする5人の独立した医師からなる合議体を開催する。5人のうち4人が「良性」と言い；1人が「悪性」と言う。合議体は今、多数決の回答と明確な不一致シグナルの両方を持っている。全員が同意していれば症例は終結していた；1人が異議を唱えたため、合議体は生検にエスカレートする。これは縮小版の multi-instance アーキテクチャである。スキャンは入力である。各医師は Claude インスタンスである。医師間の分散は多様性である——すべての医師が同じプログラムで訓練された場合、エラーは相関しており、合議体が提供するリフトは少なくなる（同一モデルの judge 問題）。タイブレークまたはエスカレートのルールは不一致処理である。生検はエスカレーションターゲットである。Multi-instance レビューは、ほぼすべての点で、同一のアーティファクトを見る独立したレビュアーのパネルである。

類比2：原稿の編集プロセス — Multi-Pass 順次専門化レビュー

出版社の編集プロセスを経る本の原稿を想像してほしい。担当編集者が最初に読み、「そもそもこれは正しい本か——一貫性はあるか、構造は機能するか、ステークスは明確か？」と問う。原稿が担当編集を通過すれば、コピーエディターが次に読み、「事実は正しいか、主張は引用されているか、論理は健全か？」と問う。コピー編集を通過すれば、文体エディターがスタイルと声のために読む。それを通過すれば、校正者が最後にタイポと書式のために読む。各編集者は狭く専門化された仕事を持つ。誰も一度にすべての種類の編集者であろうとしない——それが各自の観点において優れている理由である。これは縮小版の multi-pass アーキテクチャである。原稿はアーティファクトである。各編集者は専門化された Claude パスである。前の編集者がサインオフする前に後の編集者に渡すことは無駄である——構造的に書き直される原稿のタイポを修正する校正者は作業が無駄になる——これがパス順序付けが重要な理由である。ハードフェイラーでの早期終了は、担当編集者が救うことができない原稿を拒否することである；その上で文体エディターを実行する意味はない。Multi-pass レビューは、非常に正確には、本の出版編集スタックである。

類比3：航空機のコックピットチェックリスト — 両ファミリーを合わせると単独より優れている理由

航空安全は単一のパイロットが単一のチェックリストを読むことに依存しない。離陸前に機長と副操縦士は一連のチェックリスト——天気、燃料、重量バランス、システム——を実行し、各パイロットが独立して読み確認する。順次チェックリストは multi-pass アーキテクチャである：各チェックリストは異なる観点をカバーする専門化パスで、依存関係の順序で実行される（エンジン始動前の重量バランス前の燃料）。各チェックリストでの二パイロットのクロスチェックは2インスタンスの multi-instance アーキテクチャである：両パイロットが独立して燃料量を読み一致すれば、単一パイロットの読みより高い信頼度を持つ。不一致の場合、エスカレートする（一緒に再確認し、地上運航に相談する）。航空安全は multi-pass シーケンシングと multi-instance クロスチェックを組み合わせたリアルワールドの標準的な例であり、経済的ロジック（両ファミリーは単一のパイロットが単一のチェックリストを読むよりコストがかかり、高リスクタスクではどちらもその価値がある）は高リスク Claude パイプラインにそのまま転用できる。

どの類比がどの試験問題に適合するか

• multi-instance アンサンブル、投票、judge パターンに関する問題 → 医師の合議体の類比。
• multi-pass パイプライン、専門化パス、シーケンシングに関する問題 → 原稿編集の類比。
• 両ファミリーの組み合わせとコスト品質トレードオフに関する問題 → 航空機コックピットの類比。

一般的な試験の落とし穴

CCA-F Domain 4 は multi-instance・multi-pass レビューに関して5つの繰り返す落とし穴パターンを常に利用する。5つすべてがコミュニティの合格報告でもっともらしい引っかけ選択肢として偽装されて出現する。

落とし穴1：Multi-Instance を正確さの保証として扱う

Multi-instance は分散を低減するが、相関エラーは低減しない。基礎となる Claude モデルが特定の入力に体系的な盲点を持つ場合、アンサンブル内のすべてのインスタンスがその盲点を共有し、すべてのインスタンスが同じ誤回答を返す。引っかけ選択肢はアンサンブルを「保証付きで正確」または「モデルエラーに免疫がある」として枠組みする；どちらの枠組みも間違いである。正しい枠組みは、アンサンブルがランダムエラーの分散の低減のために N 倍のコストを交換するということである。

落とし穴2：独立性を主張する同一モデルの judge

生成者と judge の両方が同じモデルである judge-model パイプラインは相関エラーリスクを持つ。Claude が法的フレーズを一貫して誤読する場合、Claude の judge は同じエラーを見逃す。試験は、この制限を認識して異なるモデルの judge（利用可能な場合）、高リスク業務では人間参加型 judge、または「judge が N 個の候補出力をレビューする」アンサンブル形式に手を伸ばす受験者を評価する。

落とし穴3：Multi-Pass のレイテンシの過小評価

Multi-pass は順次実行されるため、レイテンシは線形に積み上がる。パスごとに2秒の4パスパイプラインは、バッチングやユーザー向けレンダリングの前に8秒かかる。低レイテンシのチャットワークフローに multi-pass を使用する引っかけ選択肢は通常間違いである。試験はレイテンシ感度の高い業務を単一呼び出し（おそらく strict ツールスキーマで）に、レイテンシ非感度の業務を multi-pass パイプラインにルートする受験者を評価する。

落とし穴4：構造化抽出のためのオブジェクト全体の投票

5つのインスタンスがそれぞれ10フィールドの JSON オブジェクトを返す場合、オブジェクト全体の投票は任意の1つのフィールドで不一致のあるオブジェクトのすべての正しいフィールドを捨てる。フィールドレベルの投票は最大の情報を保持する。アンサンブル抽出を「多数決 JSON オブジェクトを選ぶ」と説明する引っかけ選択肢は微妙に間違いである。正しい集約器はフィールドごとの投票である。

落とし穴5：より良い単一呼び出しを最初に試さずにコスト感度の高いパイプラインでアンサンブルする

Multi-instance はコストを N 倍にする。より厳密なスキーマまたはより多くの例を持つ温度 0 での単一呼び出しが既に品質基準を満たせるなら、アンサンブルは無駄なコストである。試験は、より単純な介入が試みられたか除外されたかを示すことでアンサンブルを正当化するアーキテクトを評価する。単一呼び出しの改善を最初に使い切らずにアンサンブルに飛びつく引っかけ選択肢は通常間違いである。

実践アンカー

Multi-instance・multi-pass の概念は CCA-F の6つのシナリオのうち2つで最も多く出現する。

Structured Data Extraction シナリオ

このシナリオでは、Claude が非構造化テキスト——請求書、申請フォーム、法的申請、臨床記録——から構造化フィールド（エンティティ、日付、金額、分類ラベル）を抽出する。単一呼び出しの分散は、特にエッジケース入力において、しばしば支配的なエラーソースとなる。温度変動を伴う multi-instance アンサンブルを正しく指定できるか、オブジェクト全体の投票ではなくフィールドレベルの投票を適用できるか、同一モデル judge の相関エラー制限を認識できるか、不一致を多数決でサイレントに解決するのではなく人間レビューにルートできるかをテストする問題が出る。strict ツール使用は、各インスタンスがスキーマ有効なオブジェクトを返すことを保証するために、ほぼ常に同じパイプラインで使用される。

Multi-Agent Research System シナリオ

このシナリオでは、コーディネーターエージェントがサブエージェントをディスパッチしてサブ質問を調査し、その発見事項を最終レポートに合成する。Multi-pass レビューは合成段階で出現する：構造パス（レポートに必要なすべてのセクションがあるか？）、事実パス（主張はサブエージェントの発見事項で裏付けられているか？）、一貫性パス（合成はスムーズに流れるか？）が順次実行された後にレポートがユーザーに返される。重要なパス（例えば事実確認）は multi-instance アンサンブルである可能性がある。依存関係によるパスの順序付け、構造パスの失敗での早期終了、重要なパスのみのアンサンブル、コーディネーターのエスカレーションロジックを通じた不一致の浮かび上がりをテストする問題が出る。

FAQ — Multi-Instance レビューのよくある質問

Multi-Instance と Multi-Pass レビューアーキテクチャの違いは何か？

Multi-instance は同一の入力に同一のプロンプトで N 個の並列 Claude 呼び出しを実行し、投票、平均化、または judge によって出力を集約する。変動の軸は Claude 自身のランダム性（インスタンス間の温度変動）である。Multi-pass は異なるプロンプトで同一のアーティファクトに N 個の順次 Claude 呼び出しを実行し、各パスがより狭いレビュー観点（構造、内容、コンプライアンス）を適用する。変動の軸はレビューの角度である。Multi-instance は1つの判断の分散を低減し；multi-pass は広い判断をより狭いサブ判断に分解する。両ファミリーは相補的——multi-pass パイプラインは重要なパスをアンサンブルにできる——が、異なる問題を解決し、試験でしばしば混同される。

単純な多数決ではなく judge モデルをいつ使うべきか？

review タスクが genuinely 生成タスクより簡単な場合——例えば、草案されたサマリーが7つの必要な点をカバーしているかを確認することは、サマリーを書くことより簡単——judge モデルを使用すること。タスクが基本的に分類（スパム/非スパム、12択のカテゴリ）であり、任意の単一インスタンスが合理的な精度を持つ場合は単純多数決を使用すること。judge はコールコスト（judge 呼び出し自体が Claude 呼び出し）を追加し、両方が同一モデルを使用する場合は生成者の相関エラーを共有するため、投票の万能の代替品ではない。相関エラーリスクが高い場合は、異なるモデルの judge または人間参加型 judge に手を伸ばすこと。

Multi-Instance アンサンブルで実行するインスタンスの数（N）をどのように決定するか？

二値および小カテゴリ問題でのタイが不可能になるよう奇数 N（3、5、7）を選ぶこと。中程度の信頼度タスクでは N = 3 から始め、単一呼び出しが閾値をはるかに下回る場合は N = 5 または N = 7 にスケールアップすること。N = 7 を超えると限界品質向上が急落し、コストは線形にスケールし続ける。下流の判断が非常に高リスク（医療、法的、規制）の場合、N を高くプッシュするのではなく、N = 5 インスタンスが不一致時に人間レビュアーに供給するハイブリッドを検討すること。

Multi-Pass パスを並列または順次に実行すべきか？

後のパスが前のパスの出力に依存する場合は常に順次で——構造的に無効なアーティファクトに対する内容レビューは無駄であるため、内容パスより前に構造パスが必要である。パスが真に独立している場合は並列で——同一文書の文法パスと論理パスはお互いに依存せず、同時に実行することでウォールクロックレイテンシを削減できる。厳密なチェーンではなく DAG としてパイプラインをモデル化すること；DAG は必須の順次依存関係と安全な並列の機会の両方を捉える。

Multi-Instance アンサンブル内の不一致をどのように処理するか？

一致率によるエスカレーション閾値を定義すること：全会一致の一致は自動的に受け入れ、超多数は監査ログで受け入れ、過半数は人間レビューまたはより大きなモデルにエスカレート、過半数なしは常にエスカレート。複数択を取ることで不一致をサイレントに解決しないこと——それはアンサンブルが生成する最も価値あるシグナルを捨てる。すべての不一致トレース（すべてのインスタンス出力、温度、信頼スコア）をログに記録し、プロンプトまたはスキーマが時間をかけて改善できるようにすること。インスタンスが不一致の場合にエスカレーションパスを省略する CCA-F シナリオの回答は、集約ロジックの残りが正しくても通常間違いである。

参考資料

• Claude 4 prompting best practices: https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/claude-4-best-practices
• Chain complex prompts for stronger performance: https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/chain-prompts
• Increase output consistency — structured outputs: https://docs.anthropic.com/en/docs/test-and-evaluate/strengthen-guardrails/increase-consistency
• Batch processing — Message Batches API: https://docs.anthropic.com/en/docs/build-with-claude/batch-processing
• Building effective agents — escalation and human-in-the-loop: https://docs.anthropic.com/en/docs/build-with-claude/agentic-loop

関連する ExamLab トピック：抽出品質のための検証・リトライ・フィードバックループ、明示的基準プロンプト設計、出力一貫性のための few-shot プロンプティング、人間レビューワークフローと信頼度較正。