CORE FEATURE
単体＝動かない ／ フルハーネス＝動く
同一の1文プロンプトによる対照
モデル本体は選ぶことしかできない。長時間走るエージェントの最終品質は、計画・生成・評価をどう分離し、どこに証拠と拒否権を置くかという周辺＝ハーネスの設計でほぼ決まる。
モデル本体は改変できず、選ぶことしかできない。品質を決めるのは周辺6層の設計であり、どの層がどの失敗を担当しているかを積層図で確認する。
単発プロンプト運用の失敗は2系統に分かれ、片方だけがモデル世代の交代で消えた。自分が踏んでいるのがどちらかを、この対比で切り分ける。
分離の根拠は「別のAIだから客観的」ではない。立場が採点をどう歪めるかを5要因の対比表で確かめ、「生成器を厳しくすればよい」という代案がどこへ収束するかを追う。
※「GANは数万回規模で学習を回す」という対比は機械学習一般の相場感であり、原典由来の数値ではない。
同一の1文プロンプトを単体エージェントとフルハーネスに投げた対照を見る。時間とコストの差そのものではなく、中核機能の成否と失敗の可視性がどちら側にあるかを図で確認する。
※倍率「18倍」「22倍」は表示値（20分→6時間・$9→$200）からの導出値。記事本文の表現は "over 20x"。使用モデル世代は原文に記載がない。
依頼からPASSまでの経路と、NEEDS_WORK時にジェネレーターへ帰還する反復をフロー図で追う。分けるのは役割・文脈・権限の3つで、受け渡しはすべてファイル名で確認できる。
※「16機能・10スプリント」はレトロゲームメーカー1件の実績値であり、標準構成として一般化できる数字ではない。プランナーのツール構成は原典に確認できないため図に載せていない。
評価器を成立させるのはプロンプトの文言ではなく、文脈・権限・証拠・デフォルト判定の4つの構造である。各条件がどの失敗を潰すか、そして出力が「次の指示」として着手できる粒度になっているかを図で確認する。
| 契約基準 | エバリュエーターの実際の指摘（場所＋観測の粒度） |
|---|---|
| 矩形塗りつぶしツール | ドラッグの始点と終点にしかタイルが置かれない。fillRectangle 関数は存在するが、mouseUp で正しくトリガーされていない |
| エンティティ削除 | Delete キーのハンドラが selection と selectedEntityId の両方を要求するが、エンティティのクリックでは selectedEntityId しか設定されない |
| フレーム並び替え | FastAPI が 'reorder' を frame_id（整数）としてマッチさせ、422 を返す |
※3件ともフルハーネス実験（レトロゲームメーカー）のスプリント3で検出。いずれも「実物を操作して観測→コードを追って原因特定」の順序でしか出ない指摘で、コードを眺めるだけのレビューでは出ない。
| hook | 見張る操作 | ゲートの動作 |
|---|---|---|
| track-read.sh | 証拠の読み取り（Read） | screenshots/ 配下の証拠を Read したことを記録する |
| verify-gate.sh | 結果ファイルへの書き込み（Write/Edit） | 証拠の読み取り記録が空なら、合格判定の書き込みを拒否する |
※このhookは教材でありセキュリティ境界ではない（Bash経由で回避可・パス一致はbasenameのみ）。あわせて、テストの削除・編集は明文で禁止する。
テストで判定できない品質は、4軸への分解と配点の偏らせ方で初めて採点可能になる。どの軸を重くし、何を減点対象に明記し、どこで総合点による救済を断つかを、採点表と配点原則の表から判断する。
※しきい値の数値（3/3/4/4）と採点例A/B/Cは原文著者によるfew-shotの作例。記事は "Each criterion had a hard threshold" とのみ述べており、数値の裏付けは原典にない。
| 軸 | 判定する問い | 配点の扱い |
|---|---|---|
| Design Quality（デザインの質） | 部品の寄せ集めではなく、一体感のある全体になっているか | 重く配点する（モデルが苦手な軸） |
| Originality（独自性） | テンプレートやライブラリのデフォルトを超えた、カスタムな判断の証拠があるか | 重く配点し、AI生成の兆候に減点を課す |
| Craft（作りの丁寧さ） | タイポグラフィの階層・余白の一貫性・色の調和・コントラスト比が保たれているか | 軽く配点する（創造性チェックではなく能力チェック。デフォルトで得意） |
| Functionality（機能性） | 美しさと独立に、目的が伝わり、主要アクションが見つかり、タスクを完了できるか | 軽く配点する（デフォルトで得意） |
| 配点の原則 | 具体操作 | 封じる失敗 |
|---|---|---|
| (a) 重みは苦手な軸へ寄せる | Design QualityとOriginalityを重く、CraftとFunctionalityを軽く配点する | 放っておいてもできることへの配点で、品質が上がった気になる |
| (b) モデルの初期値そのものを減点対象に明記する | 「白カードに紫のグラデーション」を減点対象として書き込む。この減点でジェネレーターはリスクを取るようになった | LLMは平均に回帰する。平均そのものを罰しないと平均から離れない |
| (c) 1軸でもしきい値未満なら全体を不合格にする | 合計点が高くても、1軸がしきい値未満ならNEEDS_WORKに倒す | 「見た目は良いが動かない」を平均点で救済してしまう |
| 自ドメイン翻訳 | 質（Design Quality） | 独自性（Originality） | 丁寧さ（Craft） | 機能性（Functionality） |
|---|---|---|---|---|
| 資料・スライド | 論旨が1本通っているか | テンプレ構成の写しでないか | 図解比率・表記統一・余白 | 読者が意思決定できるか |
| 議事録 | 会議の流れを再構成できるか | 要約が定型句に逃げていないか | 表記・氏名・用語の正確性 | 決定事項とネクストアクションが実行可能か |
| 分析レポート | 問い→分析→示唆が繋がっているか | このデータ固有の発見があるか | 数値の桁・出典・定義の一貫性 | 次に打つ手が決まるか |
| 記事 | 主張が最後まで折れていないか | AI文体（「〜ではないでしょうか」で終わる文）を減点できているか | 事実・リンク・表記の正確性 | 読者が行動を変えられるか |
※軸名は変えず、中身を差し替えるのが翻訳の原則。このドメイン別の読み替えとWeb/UI以外の減点語彙は原文著者の翻案であり、原典由来ではない。原典の4軸はフロントエンドデザイン用に作られたもの。
作った直後の評価器は必ず甘く、その甘さは本物の問題を見つけた上で合理化して握り潰すという質のものになる。だから打ち手は検出能力ではなく判定基準側に置く。自分の評価器が診断軸のどこにいるかを図から特定する。
※「指摘3〜7個が適正」「15個以上は厳しすぎ」のレンジは原文著者の実務目安であり、原典に根拠はない。Anthropicはこの調整に「何ラウンドも費やした」と述べるのみで、具体的な回数の記載もない。
| ずれの向き | 観測される症状 | 対処の向き |
|---|---|---|
| 甘い（リーニエンシー） | 本物の問題を正しく検出した上で、「意図的な設計かもしれない」「MVPとしては許容範囲」と合理化して見逃す | 検出側ではなく判定基準側を締める（下表の5手段） |
| 厳しすぎ（逆振れ） | 些末な指摘の山になり、ジェネレーターが中核の破綻に着手できない。既知の良品にNEEDS_WORKが返る | しきい値を下げ、良品の採点例を追加する |
| 締める手段 | 具体操作 | 封じる漏れ方 |
|---|---|---|
| Few-shotキャリブレーション | 点数内訳付きの採点例を評価者プロンプトに埋め込む | 「この出来なら4点」という基準のぶれ |
| 例の固定 | 採点例を固定し、セッション間で差し替えない | スコアドリフト（回ごとの基準ずれ） |
| 合理化の禁止明文化 | 「たぶん動くと仮定していることに気づいたら止まって証拠を探せ」を明示的に書く | 「意図的かもしれない」で通す逃げ |
| デフォルトFAIL | 全基準をpasses:falseから始め、迷ったら不合格に倒す | 証拠の不在を合格理由にする判定 |
| ハードしきい値 | 1軸でも下回れば総合点にかかわらず不合格にする | 平均点による救済 |
コストの約9割はジェネレーターが占め、評価を削るのはコスト削減としてほぼ無意味になる。どの部品が削減ダイヤルになり得るのかを、構成比・収束カーブと下の対照表から判断する。
※比率とダイヤル論はDAW案件1件の実測に基づく。ジェネレーター比率91.3%は内訳表からの再計算値（原文の本文表記91.5%と微差があるため、表からの再計算値を採用）。
| 部品（ダイヤル候補） | 実測値 | 運用判断 |
|---|---|---|
| ジェネレーターの反復回数 | 反復は5〜15回。方向転換は9回目→10回目のように後半で非線形に起きる。各サイクルは評価器が実物を操作するため実時間を消費する | 唯一の削減ダイヤル。ただし早期に打ち切ると「無難で綺麗なもの」で終わる |
| QA（エバリュエーター） | 1ラウンド$3〜4で、$71.08のビルドの品質を保証する。QA時間は3ラウンドを通じてほぼ一定（8.8→6.8→9.6分） | 固定費に近く、削ってもコスト総額はほとんど動かない |
| プランナー | 4.7分／$0.46（総コストの0.4%）で、短い依頼を実装可能な仕様に展開する | 原典が「最も安く、最も効果が大きい部品」と位置づける。削減候補にしない |
エバリュエーターの価値は、タスク難易度とモデル能力の差で決まる。境界は世代ごとに外側へ移動するが、消えるわけではない。自分のタスクが境界のどちら側にあるか、次のモデル更新でどの部品を外して検証すべきかを図から判断する。
※原文の主張は「境界の外側への移動」であり、エバリュエーターが要らなくなったという主張ではない。以前は検査が必要だったタスクの一部が、ジェネレーター単独の守備範囲に入った、と述べている。棚卸し手順・エージェント増の否定・適用範囲の限界・原典の締め（要旨）は上図内に記載。