反復精錬と段階的改善

**反復精錬（iterative refinement）**とは、単に「許容できる」最初の Claude 出力を、連続したレビューと改訂サイクルを通じて本番品質の成果物へと高める技法である。CCA-F（Claude Certified Architect — Foundations）試験のタスクステートメント3.5「段階的改善のための反復精錬テクニックの適用」は、Domain 3（Claude Code 設定とワークフロー、試験全体の20%）に属し、コード生成と Claude Code のシナリオおよび構造化データ抽出シナリオで重点的にテストされる。「Claude を知っている」が精錬ループを設計したことのない受験者が、精錬ループを設計した経験のある受験者に点数を奪われる、密かに難しい領域の一つだ。

本章節では CCA-F 受験者がアーキテクチャレベルで設計できることを期待されるすべての表面を順に解説する。ドラフト・レビュー・改訂サイクル、反復が一発勝負のプロンプティングより優れる理由、精錬ループの構造、自己批評プロンプティング、基準駆動レビューパス、差分ベース編集とフルリライトの比較、収束検出、ループ内の人間、既存出力の精錬と最初からの再生成の判断、反復バジェット、そして失敗テストが精錬シグナルとなる CI/CD における自動精錬——以上を網羅する。トラップのまとめ・実践アンカー・6問のFAQで、各抽象概念を精錬ワークフローを行使する試験シナリオに結びつける。

反復精錬の概念 — コードとコンテンツへのドラフト・レビュー・改訂サイクルの適用

反復精錬とは、Claude の最初の出力（ドラフト）を最終成果物としてではなく出発点として扱い、1回以上の明示的なレビューと改訂パスを通じて改善するワークフローパターンだ。各パスは特定の批評レンズ——正確性・スタイル・網羅性・構造——を適用し、フィードバックを取り込んだ新しい改訂を生成する。このワークフローは「最初の草稿を出荷しないライター」のプログラム的な同等物だ。

すべての CCA-F 受験者が内在化すべき正典的な3フェーズサイクルは次の通りだ：

1. ドラフト — Claude がタスクプロンプトに対して最初の出力を生成する。品質は「批評できる程度に十分」であり、「出荷できる程度に十分」ではない。
2. レビュー — Claude（または人間、または自動チェック）が明示的な基準に対してドラフトを評価し、構造化フィードバックを生成する：何が間違っているか、何が欠けているか、何が弱いか。
3. 改訂 — Claude がフィードバックに対処するためドラフトを書き直しまたは編集し、改善された改訂を得る。収束基準が満たされるまでサイクルが繰り返される。

反復精錬はコード（ドラフト関数 → 要件に対するレビュー → 改訂）とコンテンツ（ドラフト文書 → スタイルガイドに対するレビュー → 改訂）に同一に適用される。試験は両方を同じパターンのインスタンスとして扱う。

精錬がチェーニングとエージェンティックループとどう異なるか

反復精錬は構造的に他の2つの CCA-F パターンと隣接しているが、同じではない。

• プロンプトチェーニング（タスク1.4、1.6）はタスクを逐次サブタスクに分解し、それぞれが異なる成果物を生成する（計画、次にドラフト、次にサマリー）。チェーニングはパイプラインを前に進む。
• エージェンティックループ（タスク1.1）は Claude がアクションを提案しシステムが観察結果を返すことでツール呼び出しを反復する。ループは世界から新しい情報を収集することで前に進む。
• 反復精錬（タスク3.5）は同じ成果物——同じ関数・同じ抽出・同じ文書——を反復し、段階的に改善する。成果物は変わらず、ターンをまたいでその品質だけが変化する。

この3つのパターンを混同することは Domain 3 の一般的なトラップだ。システムが新しい成果物を生成するならチェーニング。システムが新しい事実を収集するためにツールを呼び出すならループ。システムが品質基準に対して同じ成果物を再編集するなら精錬。

なぜ反復するのか？一発勝負の出力とフィードバックによる複合的改善

反復がなぜ機能するかの直感は、大規模言語モデルに関する2つの観察に根ざしている。まず、単一の前向きパスは手元のプロンプトに対するモデルの最善の推測しか表現できない——そのレビューがまだ存在しないため自身のレビューを参照できない。次に、以前のドラフトがコンテキストウィンドウに存在する場合、Claude は生成中には見えなかった欠陥を表面化するために異なる認知レンズ（評価者、生成者ではなく）を適用できる。

複合的改善の議論

単一パスの出力が品質 q（0〜1に正規化）を持つとする。レビューパスは通常、残りの欠陥の一部 d（d = 0.5 とする）を表面化し、q + d·(1 − q) の品質の改訂をもたらす。第2パスは複合する。n ラウンド後、品質は漸近的に1に収束する。実際的な意味は、クリーンな数学的証明ではなく工学的な経験則だ——各パスは前のパスが見逃したものの約半分をキャプチャするため、2〜3パスは通常1回のパスを大幅に上回り、それ以降のパスは収穫逓減を示す。

より良い最初のプロンプトを書けばよいのではないか？

経験豊富な受験者は、十分によく作られたプロンプトが精錬を不要にすると主張することがある。その議論には部分的な価値がある——より厳密なプロンプトは q を上げる——しかし構造的な事実を無視する。生成と評価は異なる認知操作を使用する。レビューが実際のドラフトに依存するため、プロンプトはレビューレンズを完全に事前指定できない。もっともらしいが間違った事実を自信を持って主張する出力は生成では防ぐのが難しいが、レビューでは些細に発見できる。精錬は良いプロンプティングの代わりではない——それは異なる種類の作業だ。

精錬が価値がない場合

精錬はただではない。各パスはトークン・レイテンシ・場合によってはヒューマンレビュー時間のコストがかかる。次の場合は精錬をスキップする。

• タスクが定型的で単一パスの品質が一貫して要求されるしきい値を超えている。
• 欠陥が下流で発見された場合、出力全体を再生成するのが安価だ。
• レイテンシが制約条件であり「今すぐに十分良い」が「10秒後にはより良い」に勝る。
• 下流の消費者（他のエージェント、構造化スキーマ）がいずれにせよ欠陥をキャッチする。

精錬ループの構造 — 出力・評価基準・ギャップ特定・ターゲット編集

精錬ループには4つのアーキテクチャ部品がある。いずれかが欠けると、改善しないループまたは終了できないループが生成される。

1. 現在の出力

精錬中の成果物。ターン1では、タスクプロンプトから生成された最初のドラフトだ。ターン n では、ターン n-1 の改訂ステップの出力だ。精錬ループは常に最新の改訂で動作し、元のドラフトではない。

2. 評価基準

出力をレビューする次元の明示的なリスト。コードの例：要件に対する正確性、テストカバレッジ、スタイルガイドへの準拠、TODO プレースホルダーの不在、エッジケースの処理。抽出の例：スキーマ適合性、ソースドキュメントのカバレッジ、各フィールドの確信度、曖昧なケースのフラグ立て。基準は明示的でなければならない——名前のない基準を持つレビューパスは汎用的な「これは良いか？」に退化し、Claude は汎用的な肯定でしか答えられない。

3. ギャップ特定

現在の出力が満たしていないものの構造化された列挙。ギャップリストはできる限り具体的であるべきだ——「関数は空の入力リストを処理しない」は有用だが、「エラー処理が改善できる」はそうではない。Claude がギャップリストを生成する場合、各エントリが特定の基準に結びついた番号付きリストとして出力するようプロンプトする。

4. ターゲット編集

ギャップリストを取り込む改訂ステップ。2つの実行戦略が適用される。フルリライト（Claude が修正を適用して成果物全体を再生成する）または差分ベース編集（Claude が変更のみを生成し、システムが現在の出力に適用する）。差分ベース編集はトークン消費を削減し、変更を局所化し、ドラフトの正しい部分を保持するため、長い成果物には常に好ましい。

自己批評パターン — Claude が自身の出力の弱点を特定するようプロンプトする

自己批評パターンでは Claude を自身のレビュアーとして使用する。ドラフトを生成した後、Claude が基準リストに対するドラフトの弱点を列挙するよう再プロンプトし、その批評の出力が改訂パスに供給される。

自己批評がなぜ機能するか

ドラフト生成プロンプトは Claude を一貫した自信のある成果物を生成する方向に偏らせる。その偏りは生成者を批評者として不適にする——尋問するのではなく合理化する傾向がある。Claude を明らかに異なる役割で再プロンプトする（「あなたは今、厳格なコードレビュアーだ；見つけられるすべての欠陥をリストアップしてほしい」）と、生成の立場が生じた欠陥を表面化できる評価的立場が有効になる。Claude は新しいプロンプトが批評を主要タスクとする場合、自身の以前の出力の欠陥を特定できる。

3ターン自己批評テンプレート

1. ターン1（生成）：「<要件>を満たす Python 関数を書いてください。」
2. ターン2（批評）：「厳格なコードレビュアーとして行動してください。ターン1の関数と元の要件を提示します。特定できるすべての欠陥を重大度順にリストアップしてください：正確性のバグ、欠けているエッジケース、スタイル違反、不明確な名前。具体的に；行番号を参照してください。」
3. ターン3（改訂）：「上記の批評を使用して関数を修正してください。リストアップされたすべての欠陥を修正してください。元の要件が指定していない新しい動作を導入しないでください。」

この3ターンの形が最小の自己批評ループだ。同じ形は4、5ターンまたはそれ以上に拡張できるが、収穫逓減は急に現れる。

自己批評は明示的な指示を必要とする

自己批評は自動的には起こらない。明示的な批評プロンプトなしに、Claude は自身の以前の出力を自発的に尋問しない——コンテキストとして以前の出力を扱い、前に進む。「Claude が自然に反復する」と想定する受験者は、実際には何も精錬しないワークフローを設計する。試験はディストラクターの解答でこの想定を利用する。

基準駆動精錬 — レビューパスに明示的な品質次元を指定する

明示的な基準のないレビューパスは曖昧なフィードバックを生成するレビューパスだ。基準駆動精錬は出力が評価される次元を事前にコミットし、レビューパスが構造化されたアクション可能なギャップリストを生成することを保証する。

有用なレビューを生む基準の書き方

良い基準には3つの性質がある。具体的——「関数は空の入力・null の入力・10,000要素を超える入力を処理する」、「関数は堅牢だ」ではなく。テスト可能——レビュアーはさらなる解釈なしに各基準に対して yes か no で答えられる。独立——各基準は品質の異なる軸に対処し、単一の欠陥が複数の基準を同時に発火しない。

一般的な CCA-F シナリオの基準ソース

• コード生成と Claude Code：要件カバレッジ、テストカバレッジ（テストが存在する場合）、スタイルガイド準拠、エラー処理、型アノテーション、docstring の存在、TODO とプレースホルダーの不在、セキュリティアンチパターン（ハードコードされたシークレット、SQL インジェクション）、ユースケースに関連するパフォーマンス懸念。
• 構造化データ抽出：スキーマ適合性、すべての必須フィールドの存在、不確かな抽出への確信度タグ付け、曖昧なソースパッセージの処理、捏造された値ではなく明示的な null/unknown マーカー。
• マルチエージェント研究システム：引用カバレッジ、出典の多様性、クレームと出典の追跡可能性、支持されていない主張の不在、宣言された聴衆に対する可読性。

重み付けされた基準

すべての基準が等しいわけではない。正確性のバグはスタイル違反より重い。スキーマに適合しない抽出は確信度が欠けているフィールドより重い。重大度（致命的・重大・軽微）で基準違反を報告するよう評価者にプロンプトし、改訂ステップが致命的なものを最初に対処するようプロンプトする。すべてのギャップを等しく扱うループは、正確性のバグが残存する間に化粧的な問題にターンを費やす。

差分ベース精錬 — フルリライトではなく最小限の変更を適用する

精錬中の成果物が長い場合（300行のファイル、2,000語の文書、50フィールドの抽出）、各パスでフルの改訂済み成果物を生成するよう Claude に求めることはトークンを無駄にし、リスクを生む。差分ベース精錬パターンは Claude が変更のみを出力するよう制約する。

フルリライトが長い成果物でリスクがある理由

フルリライトの改訂パスは、ドラフトの正しい部分を退行させる可能性がある。Claude は300行のファイルの147行目がすでに正しかったことを知らない。ファイル全体を再生成するよう求められた場合、147行目を言い換えまたは再構造化し、退行を導入する可能性がある。差分ベース編集は、変更されていない部分を文字通り手付かずにすることで、この失敗モードを回避する。

Claude が生成できる差分形式

• ユニファイド差分（パッチ形式）：行番号とコンテキストを持つ古典的な diff -u 出力。機械的に適用可能。ターゲットがファイルでパッチ適用ステップが利用可能な場合に最適。
• 自然言語編集指示：「authenticate 関数で、if user.token: という行を if user.token and not user.token.expired: に置き換えてください；logout では42行目の後に session.clear() を追加してください。」後続の適用ステップ（別の Claude ターン、または人間、または Edit 組み込みツール）が必要。
• 構造化編集ブロック：各編集を path・line_range・old_content・new_content とともにリストする JSON または XML 構造。プログラム的な適用が最も容易。

Claude Code の組み込み Edit ツールは自然言語または構造化された編集仕様を直接消費する。精錬が Claude Code 内で起こる場合、差分ベースパターンがネイティブの形だ。

フルリライトが許容される場合

短い成果物（500トークン未満のドラフト）、数回の編集として表現できない深い構造的見直しを必要とする成果物、または「ドラフトの大部分が間違っている」と Claude がすでに特定した成果物——これらすべては合理的に差分ではなく再生成を呼ぶ。判断はコンテキスト依存であり、試験は正しく選択できるかをテストする。

収束検出 — さらなる反復が収穫逓減をもたらす時点を知る

終了しない精錬ループは、反復制限のないエージェンティックループと同様にバジェットを消費する。収束検出は、ループが抽出できる改善をすべて抽出したと判断し停止すべきである仕組みだ。

4つの収束シグナル

1. 空のギャップリスト — レビューパスが基準違反なしと報告する。これが最もクリーンな終了シグナルであり、ほとんどの精錬ループが最初にターゲットとすべきものだ。
2. 些細なギャップリスト — レビュアーがしきい値以下の軽微な重大度のギャップのみを返す。完璧さが要求されず時間が重要な場合に適切。
3. 繰り返されるギャップリスト — 2つの連続するレビューパスが同じギャップリストを生成し、改訂ステップが進捗していないことを示す。ハードストップとして扱い、エスカレート（人間レビュー、再生成、または許可）する。
4. 収穫逓減デルタ — 2つの連続する改訂間の意味的距離がしきい値を下回る。実際には測定が難しいが、成果物が構造化されている（JSON、コード）場合と差分サイズをプロキシとして使える場合に有用。

収束検出が重要な理由

終了テストがなければ、ループは反復バジェットが尽きるまで実行される（収束が実際に早く起こった場合は無駄）か、レビュアーがたまたま空のギャップリストを返すまで実行される（信頼性が低い；Claude は時に空のギャップリストを時期尚早に返し、時に決して返さない）。明示的な収束テストにより終了が決定論的になる。

複合終了

本番の精錬ループは通常、収束シグナルをハードな反復制限と組み合わせる。ループはどちらか早く発火した方で停止する：レビュアーが「ギャップなし」と言う、ギャップリストが2パスにわたって変化しない、または反復バジェットが上限に達する。このベルトとサスペンダーのアプローチは、早期終了とランナウェイ消費の両方を回避する。

ループ内の人間 — 反復間のレビュアーフィードバックの取り込み

すべての精錬パスが自動化される必要はない。ループ内の人間の精錬は、タスクがそれを必要とする場合に Claude の自己批評の代わりに人間の判断を代入し、ターン間に人間のレビュアーを挿入する。

人間のレビューが自己批評より優れる場合

• 新規または曖昧な要件：「正しい」がプロンプトで完全に指定されておらず、Claude が欠如している標準に対してテストできない。
• 法的・医療的・安全性が重要な出力：欠落した欠陥のコストが人間の時間のコストを超える。
• 主観的な品質次元 — トーン・ブランドボイス・審美的判断——人間の好みが正解となる。
• 敵対的な設定：Claude が特定の答えに対して予測可能に偏っており、外部修正を必要とする。

アーキテクチャ

ループの形は自己批評と同一だが、Claude-as-reviewer ターンを human-as-reviewer ステップで置き換える。人間がギャップリストを生成し（多くの場合フリーテキストで、時に構造化フォームを通じて）、Claude が改訂ターンでそれを消費する。Claude Code の plan mode はこのパターンのネイティブなインスタンスだ：Claude が計画を生成し、人間が承認または改訂し、Claude が実行または再計画する。

コストとレイテンシのトレードオフ

ループ内の人間の精錬は、レビュアーの可用性に応じてレイテンシを秒から時間に倍増させる可能性がある。高スループットのワークフローではこれは致命的なコストだ。高リスクのワークフローでは割安だ。アーキテクチャはリスクが正当化する場合のみ人間のレビューを選択し、残りは自動化すべきだ。

精錬 vs 再生成 — 既存出力を精錬するか最初からやり直すかの判断

精錬は常に正しい選択ではない。場合によっては、欠陥のあるドラフトへの正しい対応は、それを捨てて、より良いプロンプトで最初から再生成することだ。

ドラフトが精錬可能なサイン

• ドラフトの大部分が基準を満たしており、ギャップは局所的で特定可能だ。
• 失敗は特定の場所にある（間違ったブランチ、欠けているエッジケース、タイポ）、全体的なアプローチではない。
• プロンプトとドラフトを合わせてもコンテキストバジェット内に余裕で収まる。
• レビュアーは具体的な編集としてギャップを明示できる。

ドラフトを再生成すべきサイン

• 全体的なアプローチが間違っている。根本的に欠陥のあるアプローチを微調整する精錬は、洗練された間違った答えを生成する。
• ギャップリストが「このセクションを書き直す」または「この関数全体が間違った形だ」というエントリで支配されている。
• ドラフトが収束せずに複数の精錬パスを蓄積した。サンクコストバイアスがアーキテクトを精錬し続けるよう誘発するが、再生成の方が速く完了する。
• プロンプト自体が問題だった。より良いプロンプトが、壊れたドラフトで5つの精錬ターンが生成できるものより、はるかに良いドラフトを1パスで生成するかもしれない。

教訓付き再生成パターン

中間の道：ドラフトを捨てるが、レビューパスが生成したギャップリストを保持する。ギャップリストを使用して再生成パスのプロンプトを強化する。これにより、失敗した試みから抽出された情報を保持しながら、壊れたドラフトを編集するサンクコストの罠を回避する。

試験がこの選択をテストする場合

CCA-F シナリオ問題は、アーキテクトが改善なしに多くのターンにわたって出力を精錬してきたシナリオを説明し、次に何をすべきかを尋ねる場合がある。正解は通常「精錬パスが表面化したものに基づいてより強いプロンプトで再生成する」だ。ディストラクターは「別の精錬パスを追加する」または「温度を上げる」を提案する——どちらも誤り。

反復バジェット — 無限精錬ループを防ぐための最大ラウンド制限の設定

エージェンティックループに反復制限が必要なのと同様、精錬ループにも必要だ。制限がなければ、収束テストが発火しないループはトークンバジェットまたは API バジェットが尽きるまで実行される。

典型的な反復バジェット

• 短いコード生成：2〜3パス。各パスは通常、残りの欠陥表面の半分をキャプチャする；3パス後、収穫逓減は重い。
• 長文書精錬：3〜5パス、多くの場合基準グループで分割（最初のパスは正確性をカバー、2番目はスタイル、3番目はフロー）。
• 構造化抽出バリデーション：バリデーション失敗で1〜2回の再試行パス、その後エスカレート。2回の再試行パスを生き残った抽出エラーは通常、さらなる精錬で解決できない。

バジェットが収束とは別である理由

収束テストは改善が起こっておりプラトーになった場合にループを停止させる。バジェットは改善が全く起こらない場合にループを停止させる。両方が必要だ：収束だけでは病理学的な非終了ループを見逃す；バジェットだけではすでに収束したループでターンを無駄にする。

ビジネスレベルのバジェット

本番では、反復バジェットはエンジニアリングのデフォルトではなくビジネスコストエンベロープに結びつけるべきだ。1日10,000件の文書を精錬するコンテンツ生成パイプラインは各5パスを払えない。週に1つの出力を生成する法的契約精錬ループは15パスを払える。アーキテクトはデプロイの経済からバジェットを選ぶ。

CI/CD における精錬 — 精錬シグナルとしての自動テスト失敗

CCA-F の CI/CD シナリオは精錬パターンを内側から外側に変える。人間または Claude レビュアーがギャップリストを生成するのではなく、自動テストスイートがそれを生成する。失敗したテストが改訂パスを駆動する構造化批評になる。

パターン

1. Claude Code がコード変更を生成する（ドラフト）。
2. テストランナーが実行し、名前付き失敗と診断出力を持つ合格/失敗レポートを生成する。
3. すべてのテストが合格した場合、ループは終了する。テストが失敗した場合、失敗出力が構造化批評として Claude にフィードバックされる。
4. Claude が失敗したテストに対処する改訂された変更を生成する。
5. テストランナーが再実行する。すべてのテストが合格するかまたは反復バジェットが尽きるまでループが続く。

これはレビュアーが npm test または pytest で置き換えられた自己批評パターンとアーキテクチャ的に同一だ。利点は大きい：テストは客観的で高速で、実行をまたいで同じギャップリストを生成する。欠点は、テストがテストするものだけをカバーするということだ——テストが合格するが、テストカバレッジ外で退行を導入する変更は時期尚早に収束する。

非インタラクティブモードが必要

CI/CD は Claude Code を非インタラクティブに実行する。つまり -p フラグ（非インタラクティブ / プリントモード）を使用しなければならない。Plan mode とインタラクティブプロンプトは自動化パイプラインと互換性がない——パイプラインには承認プロンプトに応答できる人間がいない。-p フラグなしで CI/CD 精錬ループを提案する受験者は実行できない設計を生成する。

CI での権限スコーピング

CI 環境には厳密にスコープされたツール権限が必要だ。CI で実行される精錬ループは、必要なツール（制限されたコマンド許可リストを持つ Read、Edit、Bash）のみにアクセスでき、ワークスペース外のネットワークまたはファイルシステムアクセスは絶対に持つべきでない。これは精錬アーキテクチャと交差する一般的な CI/CD セキュリティ原則だ。

やさしい解説: 精錬の抽象的な仕組みは、受験者がすでに知っている物理的なプロセスに固定することで直感的になる。3つの全く異なる類比で反復精錬の全領域をカバーする。

Analogy 1: 編集者の赤ペン — 基準駆動レビュー

新聞社のニュースルームを思い浮かべてほしい。記者が記事の原稿を提出する（Claude のドラフト）。コピーエディターが赤ペンと印刷されたスタイルガイド（明示的な評価基準）を持ち、すべての違反をマークする：弱いリード、受動態、匿名の情報源、ファクトチェックが必要（ギャップリスト）。記者がマークアップに対して書き直し（改訂パス）、新しいドラフトを提出する。コピーエディターが再びペンを持つ。2、3回目までに赤いマークは少なくなる——記事が収束した。5回目までに、コピーエディターはマークするものを発明しなければならない（収穫逓減）。スタイルガイドのないニュースルームは「これはもっと良くできる」と余白に書くコピーエディターを生み出し、記者に何も伝えない。明示的な基準リストこそが、曖昧な「より良くしてほしい」を実際に終了するループに変換する。これが基準駆動精錬の形だ：ギャップリストが赤ペンであり、基準リストがスタイルガイドであり、改訂パスがマークアップに対して書き直す記者だ。

Analogy 2: 轆轤の陶芸家 — 段階的な成形と収束

轆轤の陶芸家は一度の動作で最終的な壺を生み出すことはない。粗い塊から始め（ドラフト——構造的には大まかだが粗い）、連続したパスを通じて形成する：壁を引き上げ、首を細め、口を洗練し、表面を滑らかにする。各パスはわずかな材料を除去し、壺を完成した形に近づける。陶芸家はさらなる成形が害を与えるポイントを触感で知る——粘土は「収束」しており、別のパスで壁が薄くなりすぎたり、対称性が台無しになったりする（収穫逓減）。最初の塊が中心からずれていれば、どれほど形成しても救われない；陶芸家はそれを投げ戻し再開する（再生成）。陶芸家は作業中に粘土が乾くため反復バジェットを尊重する——陶芸家が満足しているかどうかにかかわらず、セッションがどれだけ続けられるかについてのハード制限がある。これが収束検出と反復バジェットを持つ精錬ループの形だ：ドラフトが粗い塊であり、各パスが成形ステップであり、収束が触感的な「準備ができた」瞬間であり、乾く粘土が終了を強制する反復バジェットだ。

Analogy 3: 工房の治具 — テンプレートに対する繰り返し測定

引き出し前板を作る家具職人は各カットの後、罫書き治具に対して作業を確認する。治具はスペックをエンコードする——引き出しは正方形でなければならず、角は正確に90度で、表面は面一でなければならない。職人はカットし、治具に対して部品を当て、ギャップを発見し（ギャップリスト）、問題の角をトリミングし（ターゲット編集）、再確認する。部品が治具に隙間なく収まったとき、収束した。職人が部品がすでに適合した後もトリミングを続けると、オーバーシュートする——引き出しが小さすぎる（過剰精錬による劣化）。治具はオプションではない；治具なしに職人は各カットで推測しており、引き出しは適合しないか、または永遠にトリミングされ続ける。明示的な基準なしで精錬を説明する CCA-F の解答は、治具なしの職人だ：反復しているが、いつ完了したかを知る方法がない。評価基準が治具であり、ギャップリストが測定された不一致であり、収束が部品がぐらつきなしに収まる瞬間だ。

どの類比がどの試験問題に合うか

• 基準駆動レビューについての問題 → 編集者の赤ペンの類比。
• 収束と収穫逓減についての問題 → 轆轤の陶芸家の類比。
• 明示的な評価基準が必須についての問題 → 工房の治具の類比。

よくある試験のトラップ

CCA-F Domain 3 は反復精錬に関して5つの繰り返し発生するトラップパターンを一貫して利用する。5つすべてがコミュニティの合格レポートに現れ、もっともらしいディストラクターの選択肢として偽装されている。

トラップ 1: 精錬と温度上昇の混同

一部のディストラクターは「より多様で精錬された出力を生成するために温度を上げる」と提案する。これは誤りだ。温度はサンプリングのランダム性を制御し、出力品質を制御しない——高い温度はより多様な最初のパスの出力を生み、より精錬されたものを生まない。実際、高い温度は各パスがわずかに異なるドラフトを生成するため精錬を劣化させることが多く、ターンをまたいでギャップリストを追跡することが難しくなる。反復精錬は、パラメータチューニングではなく、レビューと改訂のための明示的な再プロンプティングを必要とする。

トラップ 2: 自己批評が自動的だと想定する

一般的なトラップは、精錬を「会話が続くにつれて Claude は自然に自身の出力を批評する」と組み立てる。これは誤りだ。名前のある基準を持つ評価者の役割に Claude を置く明示的なプロンプトなしに、Claude は以前の出力をコンテキストとして扱い前に進む——自発的に尋問しない。自己批評は批評プロンプトを持つ専用ターンを必要とする。

トラップ 3: 精錬ループに反復バジェットなし

「Claude が出力が十分に良いと言った時に終了する」と精錬ループを説明する解答は不完全だ。自身の収束についての Claude の判断は信頼できない；反復バジェットのない精錬ループは病理学的な入力で無制限に実行できる。すべての本番精錬ループは収束テストに加えてハードな反復制限を必要とする。

トラップ 4: 長い成果物のフルリライト精錬

成果物が300行のファイルまたは2,000語の文書の場合、フルリライト精錬はトークンを無駄にし、正しい部分を退行させるリスクがある。差分ベースまたはターゲット編集精錬が正しい形だ。「すべての精錬パスでフルファイルを再生成する」と提案するディストラクターは長い成果物では誤りだ。

トラップ 5: -p フラグなしで CI/CD に精錬を適用する

CI/CD は非インタラクティブだ。失敗したテストによって駆動される精錬ループは、プロンプトに応答できる人間のいない自動化パイプラインで実行される。-p（プリント / 非インタラクティブ）フラグが必須だ。-p フラグなしで CI/CD 精錬パイプラインを説明する解答はアーキテクチャ的に壊れている——パイプラインはインタラクティブな入力を待ってハングするかエラーになる。

トラップ 6: Plan mode のユニバーサルな安全メカニズムとしての使用

Plan mode はループ内の人間の精錬の特定のインスタンスであり、リスクが高いまたは曖昧なタスクに適切だ。ユニバーサルなデフォルトではない。すべてのタスクに plan mode を適用するとレイテンシが追加され、非インタラクティブパイプラインが壊れる。試験は plan mode を無差別に使用する設計を減点する。

実践アンカー

反復精錬の概念は6つの CCA-F シナリオのうち2つに最も強く現れる。以下をこのタスク領域のシナリオクラスター問題のアーキテクチャの骨格として扱う。

Claude Code によるコード生成シナリオ

このシナリオでは、Claude Code が要件に対するコード変更を生成する。精錬ワークフローは：Claude がドラフトを生成し、レビューパス（自己批評またはテスト駆動）が欠陥を表面化し、Claude が改訂する。長いファイルで差分ベース編集を正しく適用するか、テストが存在する場合に失敗テストを精錬シグナルとして使用するか、反復バジェットを含めるか、精錬（同じファイルを編集する）とチェーニング（別のテストファイルを生成してから実装する）を区別するかをテストする問題を予期する。3ターンの自己批評テンプレート——生成、名前のある基準で批評、改訂——が、シナリオにループを駆動する自動テストがない場合のデフォルトの解答形だ。

構造化データ抽出シナリオ

このシナリオでは、Claude が非構造化文書から構造化スキーマにフィールドを抽出する。精錬ワークフローは：Claude が最初の抽出を生成し、バリデーションステップ（スキーマチェック、ソースに対するレビュー）が欠落・誤った・または低確信度のフィールドを特定し、Claude が改訂する。フリーテキストレビューではなく構造化批評（フィールドごとのギャップリスト）を使用するか、改訂パスのためのコンテキストにソース文書を保持するか、エスカレートする前に再試行を1〜2パスに制限するか、精錬とバリデーション再試行ループ（タスク4.4）を区別するかをテストする問題を予期する。一般的なトラップ：ソースが実際にフィールドを欠いている場合に終了しない抽出の精錬ループ。正解：精錬を続けるのではなくフィールドを unknown/null としてマークする。

継続的インテグレーションのための Claude Code シナリオ

主要な重みはタスク3.6にあるが、このシナリオは精錬と直接交差する：すべてのプルリクエストで Claude Code を実行する CI パイプラインは通常、失敗したテストがギャップリストとなる自動化精錬ループを実装する。-p フラグ・反復バジェット・権限スコーピング・Claude が修正できないテスト失敗の正しい処理（インフラストラクチャエラー、環境の違い）——これらは精錬しようとするのではなく表面化すべきだ——をテストする問題を予期する。

FAQ — 反復精錬 上位6問

Claude のコンテキストにおける反復精錬とは正確に何か？

反復精錬とは、Claude が最初の出力（ドラフト）を生成し、明示的な基準に対してそれを評価してギャップリストを生成し、ギャップに対処するよう出力を改訂する——収束シグナルが発火するかまたは反復バジェットが尽きるまでレビュー・改訂サイクルを繰り返す——ワークフローパターンだ。このパターンはコード・構造化抽出・長文コンテンツに適用される。エージェンティックループ（新しい情報を収集するためにツール呼び出しを反復する）とプロンプトチェーニング（逐次ステップにわたって別々の成果物を生成する）とはアーキテクチャ的に異なる。反復精錬は同じ成果物で動作し続ける；品質のみがターンをまたいで変化する。

反復精錬と単に温度を上げるかまたは同じプロンプトを再実行することとどう異なるか？

温度はサンプリングのランダム性を制御し、精錬を生まない。高い温度はより多様な最初のパスの出力を生み、より精錬されたものを生まない。間に批評ターンなしに同じプロンプトを2回実行すると、精錬されたものではなく2つの独立したドラフトが生成される。真の反復精錬は明示的なレビューステップを必要とする——名前のある基準を持つ評価者の役割に Claude を置く専用プロンプト、続いてギャップリストを消費する改訂プロンプト。これら2つの追加ターンなしに、何も精錬していない；2つのドラフトを生成した。

既存の出力を精錬するかまたは最初からやり直すかはいつ判断するか？

ドラフトが局所的な欠陥（欠けているエッジケース、間違ったブランチ、タイポ）を持つ大部分正確なものであり、全体的なアプローチが健全な場合は精錬する。アプローチ自体が間違っている場合、ギャップリストが「このセクションを書き直す」エントリで支配されている場合、複数の精錬パスが収束に失敗した場合、またはプロンプト自体が失敗したドラフトから得た教訓で強化できる場合は再生成する。有用な中間の道：ドラフトを捨てるがギャップリストを保持し、再生成プロンプトを強化するためにそれを使用する。サンクコストバイアスは、より良いプロンプトで再生成する方が速く完了する場合にアーキテクトを根本的に壊れたドラフトを精錬し続けるよう誘発することが多い。

精錬パスは通常どれくらいで十分か？

短いコード生成では、2〜3パスが典型的だ——各パスは通常、残りの欠陥表面の半分をキャプチャするため、3番目のパスは通常、重い収穫逓減にぶつかる。長文書精錬では、基準グループで分割した3〜5パス（正確性パス、次にスタイルパス、次にフローパス）がうまく機能する。構造化抽出バリデーションでは、エスカレートする前に1〜2回の再試行パス——2回の再試行を生き残った抽出エラーは通常、精錬が修正できるバグではなく欠落したソース情報の症状だ。すべての本番精錬ループは明示的な収束テスト（空または些細なギャップリスト）とハードな反復バジェットを組み合わせるべきだ。

CI/CD パイプラインで精錬をどのように実装するか？

パイプラインがインタラクティブプロンプトでハングしないよう -p（非インタラクティブ / プリント）フラグで Claude Code を実行する。失敗したテスト出力を構造化批評として使用する——各失敗テストが名前付き診断詳細を持つギャップだ。ランナウェイ CI ジョブを防ぐため厳密な反復バジェット（通常2〜4パス）を設定し、ツール権限を狭くスコープする（Read、Edit、コマンド許可リストを持つ Bash；必要でない限りネットワークアクセスなし）。Claude が対処できないテスト失敗（インフラストラクチャの差異、環境の問題）を、それらを精錬しようとしてターンを燃やすのではなく、ヒューマンインターベンションシグナルとして表面化する。Plan mode は非インタラクティブ CI と互換性がなく、そこで使用してはならない。

著者とレビュアーの両方として同じモデルを使用している場合、なぜ自己批評が機能するのか？

自己批評が機能するのは、生成と評価が同じモデルであっても異なる認知スタンスを呼び起こすからだ。ドラフト生成プロンプトは Claude を一貫した自信のある出力を生成する方向に偏らせる——その偏りは批評を積極的に抑制する。「厳格なレビュアーとして行動する；これらの名前のある基準に対するすべての欠陥をリストアップする」という明らかに異なる役割で Claude を再プロンプトすると、生成のスタンスが生じた欠陥を表面化できる評価的スタンスが有効になる。これは Claude が「リアルタイムで自身のミスに気づく」ということではない——異なるターンで異なる質問に答えている Claude だ。重要な実装の詳細は、批評プロンプトが明示的で基準駆動でなければならないことだ。曖昧な「これは良いか？」は汎用的な肯定を生む；具体的な「基準 X・Y・Z のすべての違反をリストアップする」はアクション可能なギャップリストを生む。

さらなる読み物

• Plan mode and iterative refinement — Claude Code Docs: https://docs.anthropic.com/en/docs/claude-code/plan-mode
• 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
• Handle tool calls — validation and retry loops: https://docs.anthropic.com/en/docs/agents-and-tools/tool-use/handle-tool-calls
• Integrate Claude Code into CI/CD pipelines: https://docs.anthropic.com/en/docs/claude-code/ci-cd
• Prompt engineering overview — Claude API Docs: https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/overview

関連 ExamLab 章節：Plan Mode vs 直接実行、抽出のためのバリデーション・再試行・フィードバックループ、強制とハンドオフを伴うマルチステップワークフロー、自律タスク実行のためのエージェンティックループ。