Pattern: Evaluator-Optimizer

このページは 参照パターン です。 ontology や principles のページが「PCE 2.0 で何が存在し、どういう原理で動くか」を定義するのに対して、 pattern pages は「それらをどういう topology で組むと実務上扱いやすいか」を示します。

ここで扱う Evaluator-Optimizer は、 ある output candidate を一度で決め切らず、contract に従って反復的に改善する ときの基本パターンです。ただし PCE 2.0 では、単なる “作って、採点して、直す” ではない。それは、

何を fixed subject とするか

どの criteria が current か

どの evaluator が blocking で、どれが advisory か

どこで stop し、どこで escalate し、どこで human review に返すか

いつ old verdict が stale になるか

までを explicit に持つ governed loop である。

パターンの要約

Evaluator-Optimizer pattern

Evaluator-Optimizer pattern とは、ある process frame の内部で、ある subject を bounded に固定したうえで、 optimizer が candidate を生成し、 evaluator が eval contract に基づいてその candidate の adequacy を判定し、その verdict と change request をもとに optimizer が次の candidate を生成する、という 反復改善ループ である。

それは単なる retry ではなく、 fixed objective、explicit subject binding、evaluation axes、blocking vs advisory separation、iteration budget、staleness rules、acceptance gate、fallback / escalate / rollback path を持つ。

より短く言えば、Evaluator-Optimizer pattern とは 「何をよくしたいのかを先に固定し、その固定された subject に対して、候補生成と評価を bounded に往復させる進め方」 である。

ここで重要なのは、optimizer が “自由に賢く頑張る actor” ではなく、 現在の subject を current contract に近づける bounded executor だという点である。同様に evaluator は、単に点数をつける存在ではなく、 今の candidate を current path に残してよいかを判断する adequacy gate である。

どんなときに向いているか

Evaluator-Optimizer pattern が向いているのは、次のような場面である。

1. 改善対象が bounded に固定できるとき

例:

PR patch candidate
review package
migration plan draft
runbook draft
recommendation memo
memory candidate durable-form

何を良くしたいのかが明確であるほど、この pattern は強い。

2. 評価基準がある程度 explicit なとき

例:

tests pass
scope respected
required evidence attached
rollback note present
rubric fields complete
memory candidate has provenance

criteria が曖昧すぎると、optimizer は moving target を追い始めやすい。

3. 一回で出すより反復で quality が上がるとき

特に AI / tool-assisted execution では、

first draft is cheap
later refinement is useful
evaluator can localize defects
loop cost is acceptable

という条件がよくある。このとき Evaluator-Optimizer は非常に有効である。

4. output の shape は固定だが中身の adequacy が揺れるとき

たとえば PR patch や recommendation memo のように、返すものの型は決まっているが、その quality や grounding が不足しがちな仕事に向く。

5. “よさそう” をそのまま採用すると危険なとき

review、approval、memory promotion の前段で candidate を iterative に hardened したい場合に向く。

どんなときに向いていないか

逆に、次のような場合は Evaluator-Optimizer pattern をそのまま使わない方がよい。

1. そもそも問いが固まっていないとき

research 初期のように、まだ何を問うべきか自体が揺れているなら、まず question freeze や Branch and Join が必要である。 moving target に対して optimizer loop を回すと、「何か良さそうなもの」ができるだけで終わりやすい。

2. 比較そのものが重要なとき

複数案を並べて比較しないと決められない場合は、 single candidate を改善し続けるより parallel / comparative pattern の方が自然である。

3. 評価基準が evaluator の頭の中にしかないとき

contract が implicit なまま loop を回すと、

criteria drift
optimizer overfitting to evaluator quirks
arbitrary “もう十分” judgment

が起きやすい。

4. one-shot deterministic check で十分なとき

単なる schema validation や deterministic compile check なら、 iterative optimizer loop は過剰である。

5. high-cost mutation を毎回伴うとき

各 iteration が expensive or risky なら、 bounded prototype や review-before-apply を入れた方がよい。

Evaluator-Optimizer は何ではないか

誤解を避けるために、先に輪郭をはっきりさせておく。

1. 単なる retry loop ではない

失敗したらもう一回、では不十分である。 PCE 2.0 の Evaluator-Optimizer は、

subject
contract
evidence
requested changes
stale invalidation
stop rule

を持つ。

2. 単なる self-reflection ではない

同じ model が “自分で考え直す” こと自体はありうる。しかし pattern の本質は role separation にある。

optimizer role
evaluator role
approver / acceptance role

を少なくとも conceptually 分けなければならない。

3. 単なる approval ではない

evaluator が pass を出しても、それで current truth になるわけではない。特に high-impact output では、later な Approval や Human Oversight が必要になる。

4. 単なる parallel candidate generation ではない

複数 candidate を並行に作る場合もあるが、それは hybrid with Pattern: Parallel である。 Evaluator-Optimizer pattern の中心は one current candidate that gets iteratively refined にある。

5. 単なる “品質を上げる方法” ではない

この pattern の価値は quality だけではない。何が current candidate で、何が still not admissible なのかを process 上で明示できることが重要である。

核となる topology

もっとも基本的な形は、次のように書ける。

frame / subject freeze
  -> optimizer proposes candidate_0
  -> evaluator judges candidate_0
  -> if fail or refine:
       optimizer proposes candidate_1
  -> evaluator judges candidate_1
  -> ...
  -> accept / escalate / rollback / abandon

実務では、次のように現れることが多い。

question / output contract freeze
  -> first draft / first patch / first candidate
  -> evaluation
  -> requested changes
  -> revised candidate
  -> re-evaluation
  -> approval / promotion / close

ここで重要なのは、first draft より前に 何を固定するのか があることだ。それがない loop は、実質的には wandering generation になりやすい。

まず subject を固定しなければならない

Evaluator-Optimizer pattern の最重要条件は、 何を改善対象としているのかを fixed subject として binding すること である。

固定すべきもの

subject kind 例: artifact patch, recommendation memo, memory candidate
current scope
current goal slice
expected output shape
evaluation axes
stop / escalate conditions

固定しないと何が起こるか

optimizer が別の問題を解き始める
evaluator が毎回違うものを見ている
later candidate が earlier candidate と比較できない
“改善した” の意味が失われる

これは research や PR review で特に起きやすい。だから PCE 2.0 では、loop の前に question freeze / output contract freeze を置く方がよい。

Evaluator と optimizer は actor ではなく role として理解する

実務では、

AI optimizer + human evaluator
AI optimizer + AI evaluator + human approver
human optimizer + AI evaluator
same human alternating roles
same model alternating roles under different contexts

のすべてがありうる。

そのため PCE 2.0 では、Evaluator-Optimizer をまず role topology として理解するのがよい。

Optimizer role

candidate を作る
requested changes を取り込む
current contract に近づける
stop condition を検知したら止まる / escalate する

Evaluator role

candidate を current contract に照らして判断する
pass / fail / insufficient / conditional / escalate を返す
missing evidence と criteria violation を区別する
current subject から外れた drift を検知する

Approval / acceptance role

evaluate 結果を踏まえて next legal transition を開く
high-impact path では human or retained authority が持つことが多い

この role separation を explicit にすると、 same model を使う場合でも self-approval を避けやすくなる。

Evaluator-Optimizer は often sequential shell の中にある

この pattern は、しばしば larger sequential frame の内部に埋め込まれる。

典型構造

frame definition
  -> subject freeze
  -> evaluator-optimizer loop
  -> acceptance / approval
  -> promotion / merge / close

つまり loop 自体は iterative でも、その外側は often Pattern: Sequential である。

この構造が useful なのは、

question freeze を先に置ける
final approval を loop の外に retain できる
rollback anchor を取りやすい
memory writing を later に分離しやすい

からである。

評価は “スコア” ではなく “verdict + requested changes” であるべき

Evaluator-Optimizer pattern を実務で使うなら、 evaluator の output は単なる numeric score より、 process-usable verdict に近い方がよい。

evaluator output に最低限ほしいもの

verdict
- pass
- fail
- insufficient_evidence
- conditional_pass
- escalate
reasons
requested changes
still-open risks
currentness / freshness note
invalidation conditions

なぜ score だけでは弱いか

score が 72 -> 81 -> 84 と上がっても、

何がまだ blocking なのか
何が current scope violation なのか
何を直せば next iteration が成立するのか

が分からないからである。

PCE 2.0 的には evaluator は optimization target function ではなく admissibility-oriented critic として理解した方がよい。

requested changes は change delta である

evaluator が返す requested changes は、単なる prose comment ではなく、 later optimizer が消費できる bounded change request である方が強い。

望ましい requested changes

target field / scope が明確
why current candidate is insufficient が明確
which contract clause is unmet かが明確
if possible, evidence gap と content defect を分ける
what remains unchanged / still valid かが分かる

避けたい requested changes

もっとよくして
なんか弱い
念のため見直して
全部再検討

後者は human どうしでもノイズが大きいが、AI optimizer に対しては特に危険である。 current valid core まで捨てさせてしまうからだ。

pass と acceptance は同じではない

Evaluator-Optimizer pattern の最重要 distinction の一つがこれである。

Evaluator pass

current contract に照らして candidate が十分だ、という adequacy judgment

Acceptance / approval

その candidate を next process path に進めてよい、という ratification

この distinction を失うと、

AI evaluator pass = merge 可能
local rubric pass = canonical memory write 可能
prototype looked good = adopt 可能

のような Corrupt Success が起きやすい。

したがって高インパクトな output では、loop の外に approval / promotion / close gate を残すべきである。

outcome と process を両方見る必要がある

Evaluator-Optimizer pattern は、artifact quality だけに使うべきではない。 PCE 2.0 では evaluator は必要に応じて

outcome
process

の両軸を見る。

outcome evaluator が見るもの

correctness
completeness
requirement fit
performance
format validity

process evaluator が見るもの

scope respected
required evidence present
stale context not used
prohibited capability not used
rollback path explained
current approval dependencies acknowledged

この distinction を入れると、 “内容は正しそうだが process が危ない” という candidate を loop 内で止めやすくなる。

iteration budget を持つべきである

Evaluator-Optimizer pattern は便利だが、無限ループになりやすい。そのため PCE 2.0 では、iteration budget を explicit に持つべきである。

代表的な budget

max iterations
max wall-clock time
max optimizer cost
max evaluator cost
max acceptable drift from original subject
max unresolved issue count

なぜ必要か

予算がないと、

micro-optimization が続く
evaluator gaming が始まる
“もう少し良くなるかも” を止められない
human oversight が later に過負荷になる

loop は bounded でなければならない。

stop / escalate / rollback の条件

Evaluator-Optimizer pattern は “改善する限り回す” だけではない。止めるべき局面がある。

stop / accept

candidate passes required evaluators
no blocking issue remains
residual risks are acceptable for next gate

stop / insufficient evidence

content defect ではなく evidence gap が大きい
optimizer では埋められない missing input がある

escalate

current scope では解けない conflict がある
evaluator verdicts が conflict している
risk / authority issue が local loop を超える
recommendation or patch requires scope widening

rollback

iterations introduced drift
later evidence invalidates current candidate lineage
old approval / eval assumptions were attached to stale candidate versions

abandon / reframe

fixed subject itself was wrong
criteria are unstable
further optimization no longer reduces the right uncertainty

つまり loop は improve-or-die ではなく improve-or-stop-or-escalate-or-reframe である。

stale invalidation が重要である

Evaluator-Optimizer pattern では、old evaluator verdicts や old candidate assumptions が stale になりやすい。これを明示しないと危険である。

stale になる典型条件

candidate changed materially
source evidence changed
spec / scope changed
branch comparison context changed
new human-side information arrived
new failure / counterexample arrived

stale にすべきもの

old evaluator pass
old optimization request
old approval candidacy
old compiled context
old recommendation confidence

この invalidation を explicit にしないと、 “前に pass したから今回もほぼ pass” という危険な shortcut が起きる。

Corrupt Success の典型発生点

Evaluator-Optimizer pattern は、一見 quality を上げる pattern に見える。しかし実際には Corrupt Success を生みやすい場でもある。

1. Evaluator gaming

optimizer が evaluator の rubric の癖を学び、真の adequacy ではなく evaluator pass を最適化する。

2. Criteria drift

evaluator の requested changes が iteration のたびに変わり、何を目指していたのかが失われる。

3. Scope drift

改善の途中で subject が silently 広がる。

4. Evidence laundering

useful-looking candidate だが required evidence が弱いのに、 loop の成功 narrative で押し切る。

outcome だけ改善し、approval dependencies や rollback note や provenance を忘れる。

6. Pass = approval collapse

evaluator pass をそのまま merge / promotion / close に読み替える。

このため Evaluator-Optimizer pattern では、 evaluation と approval の separation が特に重要になる。

human oversight はどこに置くべきか

この patternは fully automated に見えやすいが、 PCE 2.0 では human oversight の境界を明示した方がよい。

human が retain しやすい場所

subject freeze
criteria freeze or rubric approval
high-impact acceptance
scope widening
exception approval
durable memory write
incident / rollback decision

human が必ずしも持たなくてよい場所

local candidate generation
deterministic checks
advisory review pass
bounded formatting or structuring improvements

つまり Human Oversight は、 loop 全体を人間が回すことではなく、 which transitions are too strong to leave entirely inside the loop を explicit にすることである。

典型的な変種

Evaluator-Optimizer pattern は一つではない。少なくとも次の変種がある。

1. Single evaluator, single optimizer

最も基本形。 one optimizer, one evaluator, one candidate chain。

2. Multi-evaluator, single optimizer

optimizer は一人だが、evaluator が複数いる。

例:

CI evaluator (blocking)
AI reviewer (advisory)
human reviewer (blocking/process-aware)

実務ではこれがかなり多い。

3. Single evaluator, multi-candidate optimizer

optimizer が同時に複数 candidate を出し、evaluator が比較する。これは parallel hybrid である。

4. Cascaded evaluator-optimizer

粗い evaluator -> fine evaluator のように段階的に loop をかける。大きな review burden を減らしたいときに useful。

5. Human-overseen evaluator-optimizer

AI optimizer + AI evaluator で preliminary loop を回し、 final acceptance だけ human が見る。高リスク path で多い。

どこで parallel と併用するか

Evaluator-Optimizer pattern は often Pattern: Parallel と組み合わせて使われる。

parallel を使う典型例

optimizer candidates A / B を並行に作る
multiple evaluators が独立に verdict を返す
one branch は outcome checks、another branch は governance checks を行う

ただし中心は loop である

parallel を使っても、最終的に one current candidate を refinement するなら、 core pattern は evaluator-optimizer のままである。

どこで sequential と併用するか

こちらはさらに一般的である。多くの場合、Evaluator-Optimizer pattern は Pattern: Sequential の middle stage として現れる。

典型構造

freeze question / output contract
  -> evaluator-optimizer loop
  -> approval
  -> promotion / merge / close

つまり loop の前後に

framing
approval
memory writing
closure

が来る。

何を output として残すべきか

この pattern の output は final candidate だけではない。 PCE 2.0 では、少なくとも次が valuable になりうる。

1. Candidate chain

candidate_0, candidate_1, … の lineage

2. Evaluation deltas

各 iteration の verdict と requested changes

3. Invalidation records

どの old verdict / context が stale になったか

4. Final accepted candidate

next gate に進む candidate

5. Productive failure note

loop が abandon / reframe した理由

6. Memory candidates

reusable requested-change patterns, checklist updates, anti-patterns

この pattern は later learning を豊かにしやすい。単なる one-shot generation より、何が効いて何が効かなかったかが残りやすいからである。

典型的な成功パターン

Evaluator-Optimizer pattern がうまく機能しているときは、次の特徴がある。

1. subject が fixed されている

何を改善しているかがぶれない。

2. evaluator verdict が actionable

requested changes が bounded で、optimizer が次に何を直せばよいか分かる。

3. blocking と advisory が分かれている

all feedback が equal ではない。

4. pass と approval が分離している

evaluator pass をそのまま adoption にしない。

5. stale invalidation が explicit

new evidence / new candidate で old verdict を invalid にできる。

6. iteration budget が bounded

“永遠に改善” にならない。

典型的なアンチパターン

この pattern の壊れ方も典型的である。

1. Moving-target loop

criteria が iteration のたびに変わる。

2. Unbounded nitpicking

大きな blocking issue がないのに endless refinement が続く。

3. Self-approval collapse

same actor / same model が evaluation と acceptance を silently collapse する。

4. Evidence-free polishing

内容がきれいになるだけで、grounding や provenance は増えていない。

outcome score だけ上げて、scope / gate / authority failure を見ない。

6. Lost lineage

current candidate がどの prior candidate / feedback から来たか later に追えない。

7. Retry disguised as optimization

毎回ほぼ最初からやり直していて、candidate refinement になっていない。

このパターンに向くケース

PCE 2.0 の case pages の中では、次が特に Evaluator-Optimizer pattern に向いている。

強く向く

PR Review の request-changes loop
Human-AI Handoff の bounded patch refinement
Research Loop の recommendation memo refinement

部分的に向く

Feature Delivery の implementation -> review loop
Bug Triage の duplicate / insufficient-evidence classification refinement

つまりこの pattern は、 subject は fixed だが first pass では quality / sufficiency が足りない ときに特に有効である。

参考スキーマ

実装や docs 化に使いやすい最小 pattern schema を置いておく。

evaluator_optimizer_pattern:
  pattern_id:
  frame_ref:
  subject_kind:
  subject_scope:
  objective:
  frozen_contracts:
    eval_contract_refs:
    required_evidence_floor:
    required_output_contract:
    approval_requirements:
  optimizer:
    actor_ref:
    bundle_ref:
    capability_scope_ref:
    expected_candidate_kind:
  evaluators:
    - actor_ref:
      bundle_ref:
      contract_ref:
      blocking_mode:
        # blocking | advisory
      evaluation_axes:
        - outcome
        - process
  iteration_policy:
    max_iterations:
    max_cost:
    max_wall_clock:
    improvement_threshold:
    stop_on_scope_conflict:
    stop_on_missing_evidence:
    stop_on_staleness:
  accept_exit:
    next_transition:
  fail_exit:
    next_transition:
  escalate_path:
  rollback_anchor_policy:
  memory_policy:

iteration record を separately 持つなら、次のようにも置ける。

optimization_iteration:
  iteration_id:
  pattern_ref:
  candidate_delta_ref:
  evaluator_results:
    - evaluator_ref:
      verdict:
      requested_changes:
      evidence_gaps:
      risks:
      stale_conditions:
  aggregated_status:
    # continue | accept_ready | insufficient_evidence | escalate | rollback | abandon
  next_action:
  invalidated_refs:
  provenance:

この schema で重要なのは、loop を

fixed subject
evaluator set
requested changes
stop rules
approval separation
staleness

を持つものとして表現している点である。

小さな例

negative total hotfix の AI patch refinement を evaluator-optimizer で回す最小例を書く。

1. human freezes patch scope
2. AI patch optimizer produces candidate_0
3. CI evaluator says: tests fail on edge case
4. optimizer produces candidate_1 with test fix
5. human reviewer says: rollback note too weak
6. optimizer produces candidate_2 with stronger rollback note
7. new release evidence arrives; candidate_2 assumptions become stale
8. old evaluator pass is invalidated
9. loop reopens or escalates
10. final human approval decides whether candidate enters merge-ready path

この例で重要なのは、 quality improvement だけではなく

scope freeze
multi-evaluator loop
stale invalidation
final human approval

が明示されていることだ。

暫定的なまとめ

Evaluator-Optimizer pattern が言っていることは、最終的には次の一文に集約できる。

反復改善に価値があるのは、何を良くしたいのかが固定され、何をもって十分とするかが explicit で、old verdict が stale になれば invalidate され、final adoption が evaluator pass に自動 collapse しない場合に限る。

PCE 2.0 において Evaluator-Optimizer pattern は、単なる “作って直してを繰り返す” ではない。それは、bounded candidate refinement を process integrity と governance の中に収めるための基本パターンである。

だから Evaluator-Optimizer pattern は、単なる iterative prompt chaining ではない。それは、PCE 2.0 において fixed subject に対する候補生成と adequacy judgment を明示的な contract と stop rule のもとで往復させる反復改善パターン である。

Pattern: Evaluator-Optimizer

パターンの要約

どんなときに向いているか

1. 改善対象が bounded に固定できるとき

2. 評価基準がある程度 explicit なとき

3. 一回で出すより反復で quality が上がるとき

4. output の shape は固定だが中身の adequacy が揺れるとき

5. “よさそう” をそのまま採用すると危険なとき

どんなときに向いていないか

1. そもそも問いが固まっていないとき

2. 比較そのものが重要なとき

3. 評価基準が evaluator の頭の中にしかないとき

4. one-shot deterministic check で十分なとき

5. high-cost mutation を毎回伴うとき

Evaluator-Optimizer は何ではないか

1. 単なる retry loop ではない

2. 単なる self-reflection ではない

3. 単なる approval ではない

4. 単なる parallel candidate generation ではない

5. 単なる “品質を上げる方法” ではない

核となる topology

まず subject を固定しなければならない

固定すべきもの

固定しないと何が起こるか

Evaluator と optimizer は actor ではなく role として理解する

Optimizer role

Evaluator role

Approval / acceptance role

Evaluator-Optimizer は often sequential shell の中にある

典型構造

評価は “スコア” ではなく “verdict + requested changes” であるべき

evaluator output に最低限ほしいもの

なぜ score だけでは弱いか

requested changes は change delta である

望ましい requested changes

避けたい requested changes

pass と acceptance は同じではない

Evaluator pass

Acceptance / approval

outcome と process を両方見る必要がある

outcome evaluator が見るもの

process evaluator が見るもの

iteration budget を持つべきである

代表的な budget

なぜ必要か

stop / escalate / rollback の条件

stop / accept

stop / insufficient evidence

escalate

rollback

abandon / reframe

stale invalidation が重要である

stale になる典型条件

stale にすべきもの

Corrupt Success の典型発生点

1. Evaluator gaming

2. Criteria drift

3. Scope drift

4. Evidence laundering

5. Process-blind optimization

6. Pass = approval collapse

human oversight はどこに置くべきか

human が retain しやすい場所

human が必ずしも持たなくてよい場所

典型的な変種

1. Single evaluator, single optimizer

2. Multi-evaluator, single optimizer

3. Single evaluator, multi-candidate optimizer

4. Cascaded evaluator-optimizer

5. Human-overseen evaluator-optimizer

どこで parallel と併用するか

parallel を使う典型例

ただし中心は loop である

どこで sequential と併用するか

典型構造

何を output として残すべきか

1. Candidate chain

2. Evaluation deltas

3. Invalidation records

4. Final accepted candidate