エージェントハーネス設計 v6 — 分岐の根拠と評価の独立性¶
2026-09-13 起草。v6 は v5 に品質規律を足す加法レイヤである。 v5 の投入の形（Orca supervised loop・起動コマンド・model / effort・端末寿命）は不変とし、 指示書・設計書・報告書・レビューへ、分岐の根拠と検証の不足を明示する規律を追加する。 正典の優先順位は ユーザー指示 > AGENTS.md > 本設計 > プラグイン既定。
0. 読めた範囲と読めていない範囲¶
素材は masa_wunder 氏の次の2記事の公開部と、2026-09-11〜13に確認した開発記録である。 有料本文は未読。以下は公開部の要約であり、非公開の実装や設計パターンを再現したものではない。
| 記事 | 公開部で読めた主張（要約） | 読めていない範囲 |
|---|---|---|
| エージェントと共創する上でのおすすめ設計パターン | 曖昧な分岐をエージェントが確定してから進むと手戻りになる。着手前の認識合わせが必要 | 2プラグイン / 4スキルの中身と設計パターン本文 |
| 評価関数を作れ | AIの自己採点と人の評価にはずれがある。成果物を読み直し、違いを言葉にして評価基準を点検する | 有料本文16,800字・30画像と配布物 |
§3は、この主張を手掛かりにGrecoの記録から導いた運用上の裁定である。 記事の提案そのもの、または効果が検証済みの手法とは認定しない。
1. 実測 — 草案を記録と突き合わせる¶
以下はGit履歴と既存のレビュー証跡の再照合であり、本書の作成時に実機障害を再実行した結果ではない。
verdict名は各レビュー用ワークツリーの .worker-specs/ にあるローカル証跡を指す。
これらは通常コミットされないため、別環境への引継ぎ時はコーディネーターが証跡を添付する。
commit SHAは git show <sha> で追える。対象期間前のE4 R1〜R4（9/10）も比較元として含めた。
1-1. 未検証の前提で進んだ事例¶
| 事例 | 前提と外部検証で分かったこと | 追跡先 |
|---|---|---|
| 接続テストの単一in-flight制約 | 草案は複数結果のrouting問題を回避できるとしたが、QA-Bは遅延結果と現在の結果の同着で、一致結果も照合待ちになることを再現した | review-sol/.worker-specs/qa-jwnet-b-report.md B-01、監査head 743b02e8 |
| wl-hjlm R1→R3のログ説明 | 大文字の状態表示とdaemonログ、さらに手動CLI専用の完了行を混ぜていた。R2指示書にも混在があり、レビュアがその前提を指摘した | PR #790、f447ebfc → 597e9ea2、review-wl-hjlm-r2-verdict.md |
| E4のV7資格情報手順 | R3時点でも登録時のパスワード供給と昇格指定が不足していた。Register-ScheduledTask のPrincipal parameter setには -Password がないという照合で修正へ戻した |
PR #787、3a21e835、review-e4-r3-verdict.md P2-F2 |
| wl-97sfの未回答分岐 | R32のバイト数等を質問したが、回答時にはdispatchが閉じていたとレビュー指示に記録されている。質問と完了の順序を検証対象にした | PR #792、8d51ffb3、review-sol/.worker-specs/review-wl-97sf.md「既知の経緯」 |
草案のKEK事故は「秘密値が会話へ流入し即ローテーションした」というコーディネーターの記録として扱う。
事故経路の独立再検証は行っておらず、秘密値や会話原文は転記しない。
草案にある本番UIのA/B/C確認、Q4からV6への前提変更の詳細も、本書では独立実測の件数に含めない。
資料不在時に公式資料を取得して取得元とSHA-256を残す作法は、wl-3d3rの報告と
review-wl-3d3r-verdict.md（PR #792、a3b57212）で確認できる。
1-2. 緑の検査が見落としていたもの¶
| 事例 | 従来の確認 | 独立検証・履歴で分かったことと追跡先 |
|---|---|---|
| E4 R5のV7待機 | 提供ハーネスで6ケース成功・旧版の失敗を報告 | 実行日時が常に6秒後、旧版の結果も完了後に実行中へ逆行していた。レビュアが同一の状態機械を新旧へ適用し、旧版の2境界を赤にした。review-e4-r5-verdict.md、9e01617d |
| Gateway F1のタイマーとI/O | 期限配線の検査がローカルで緑でもCIでフレーク | 仮想時計と実ファイルI/Oの同期を修正し、配線を外す変異の歯と全パッケージ並列5回を独立確認した。PR #793、c3a008e5、review-wl-bi5l-verdict.md |
| D31の通常結果 | 修正前のAPIテストはHR1/HR2/E01の明細なし不受理を検査 | a3b57212 の親ではR31パーサ分岐もR31正常結果のAPIテストもない。同commitで7機能の合成R31をアップロード・保存済みの両経路へ追加した。PR #792、review-wl-3d3r-verdict.md |
| mig252 proofの日付 | 通常の実行では緑 | 旧版は実日付2026-09-11に [NG]=1。固定過去日のfixtureへ変更後は実日付と翌日の検査が緑、旧年へ戻す変異は赤。PR #789、8aea9b99、review-wl-j4t6-verdict.md |
D31について「8月から1か月見逃した」とする草案の期間は確認できないため採用しない。
明細なし不受理テストの追加は 0411c89a（2026-09-10）、R31正常結果の追加は a3b57212（9/12）。
確認した範囲はこの結果経路であり、D31の要求生成テスト全体に正常系がなかったという意味ではない。
また、mig252の「364日緑」は全日検査の実績ではないので用いない。
1-3. 初回判定の再集計¶
2026-09-13の起草時点で、対象をE4 / wl-hjlm / wl-rk0c / wl-j4t6 / wl-bi5lの5スライスに固定し、
review-* ワークツリーの review-*-verdict.md の最終非空行を読んだ。
R番号を省略したファイルはR1として数え、コピーは重複加算しない。
本表の出典は review-sol / review-lyra の両ワークツリーの verdict（いずれも git 管理外）である。
| スライス | R1 | 確認できた続き | 最終行の出典（.worker-specs/） |
|---|---|---|---|
| E4（#787） | BLOCK | R2/R3/R4 BLOCK → R5 APPROVE | review-lyra: review-e4-verdict.md、review-e4-r2-verdict.md〜review-e4-r5-verdict.md |
| wl-hjlm（#790） | BLOCK | R2 BLOCK → R3 APPROVE | review-lyra: review-wl-hjlm-verdict.md、review-wl-hjlm-r2-verdict.md、review-wl-hjlm-r3-verdict.md |
| wl-rk0c（#791） | BLOCK | R2もBLOCK。R3以降の判定はこの集計に含めない | review-sol: review-wl-rk0c-verdict.md、review-lyra: review-wl-rk0c-r2-verdict.md |
| wl-j4t6（#789） | APPROVE | R1で承認（非阻害の補足所見あり） | review-lyra: review-wl-j4t6-verdict.md |
| wl-bi5l（#793） | APPROVE | R1で承認 | review-lyra: review-wl-bi5l-verdict.md |
R1 APPROVEは2/5、BLOCKは3/5。草案の「R1 APPROVEはゼロ」と「wl-rk0cはR2で承認」は撤回する。 この小さな選定標本からモデル間の優劣や、独立レビューがなければ全件出荷されたという反実仮想は導けない。
2. v5のどこに穴があったか¶
- 指示書の前提が未検証でも作業が始まる。 文書系eval-loopはv3で導入済みだが、分岐の根拠と実施記録が指示書ごとに揃っていない。
- 質問の送信と回答の消費が揃わない。 dispatch終了後の回答は、その作業の判断に使えない。送った事実だけで完了に進めてはならない。
- 歯の要求が案件ごとの手書き。 変異の本数、赤の根拠、レビュアの独立再現を共通化する必要がある。
- テスト数だけでは欠落が見えない。 正常系・異常系・境界を契約ごとに分けないと、結果の受理経路が空でも緑になる。
- 手順に環境前提が埋まる。 シェル・TTY・資料の所在を手順の入力として明示する必要がある。
これは投入機構の変更理由ではなく、指示・報告・評価の接続を補う理由である。
3. 差分 — v6で足す7点¶
3-1. 指示書に「分岐と裁定」を置く¶
コーディネーターは既決の分岐を「分岐 / 裁定 / 根拠」の表にし、根拠に [実測] / [仕様] / [仮説] を付ける。 [実測]はコマンド・観測日・SHAや証跡、[仕様]は一次資料の節、[仮説]は未確認の前提と検証方法を添える。 [仮説]の前提はレビュー指示で必ず検証対象にする。 根拠を添えられない断定を決定事項にしない。
仕様が沈黙した分岐は、まず既存の共通制約へ寄せ、裁定と根拠を報告書へ残す。 推測値を仕様値と認定しない。fail-closed（拒否・保留側）で安全に進められる範囲に限って先へ進む。 権限の拡大・不可逆操作など、人の判断が必要な依存作業は回答まで保留する。 具体的な骨格はワーカー指示書テンプレートを使う。
3-2. questionをdispatch内で完結させる¶
質問はworker_doneより前に送り、回答を待ち、裁定へ反映してから完了する。
ここでのquestionはOrcaの質問メッセージ（orca orchestration send --type question）であり、
OpenCodeのTUI対話ツールではない。permission.question: deny は変更しない。
実行コマンド・ID・capabilityは注入されたlifecycle preambleを正典とする。
preambleが orca orchestration ask を指定する場合はそれを使い、timeout / 切断後も
同じmessage IDの ask --resume で待つ。send --type question の送信成功は回答の受領ではない。
単なる未着やtimeoutを、承認・不在の確定・worker_done --outcome failed の理由にしない。
待てない状況でも、§3-1の既存制約で安全に裁定できる範囲だけ進め、報告書の
「未回答のまま裁定した分岐」に質問、採った判断、根拠、残る確認を列挙する。
判断必須の作業は保留し、独立した作業を進める。コーディネーターは既存の
check --wait --types worker_done,escalation,question で質問を受け、
check --wait が返るたびに worker-release の前に scripts/orca-check-messages.sh <run-id> を
実行して要回答を先に読む。<run-id> は orca orchestration run-current --json
または直前の check の result.runId から得る。
2026-09-13、wl-b3rz のワーカーは規約どおり worker_done より前に question と escalation を送ったが、
コーディネーターは heartbeat に埋もれたそれに気づかず、dispatch を release した後に発見して
返信できなかった（前ラウンド報告書 .worker-specs/wl-b3rz-report.md「文書eval-loop・未回答のまま裁定した分岐」、
escalation msg_9060f922a9af）。運用の注意書きだけでは同じことが起きるため、
コーディネーターは check の返す FIFO バッチ全体から要回答（question / escalation）だけを
先頭に分離表示する scripts/orca-check-messages.sh を使う（heartbeat は件数だけ。読むだけで --ack はしない）。
2026-09-13 の取りこぼしは「question が heartbeat に埋もれた」という症状ではなく、
次の連鎖が根因だった（[実測]: コーディネーターが同日に特定）。
check --wait --json は keepalive の JSON 行を stderr に 15 秒ごとに出す
（[仕様]: orca orchestration check --help に明記。「Filter with jq "select(._keepalive|not)" when merging streams」）。
コーディネーターが習慣で 2>&1 を付けて stderr を stdout に混ぜたため、
受け取った stdout が「JSON + keepalive の混在」になり json.load が壊れた
（[実測]: 2>/dev/null では 1,679 bytes・json.load 成功・messages: 1。
2>&1 では JSON と keepalive が交互に出て壊れる）。
「--wait は使えない」と誤認して 45〜60 秒間隔のポーリングへ退避し、
間隔を空けたぶん応答が遅れた。メッセージ自体は落ちていない。
Orca は durable FIFO で、未 ack の Delivery は再配信される
（[仕様]: check --help「A bound Run replays the same Delivery until --ack」。
--wait なしの check も最古の未 ack FIFO バッチ全体を返す）。
実際に起きたのは「受け取った配信を読まず・処理せず・ack せずに放置した」ことであり、
未 ack のバッチを処理しないまま別の判定材料（報告書ファイルの存在・推測で読んだ JSON フィールド）に頼った。
「ポーリングだからメッセージが落ちる」という因果は正典に残さない。
残すと、未 ack バッチの処理・再配信を再び見落とす。
代替として報告書ファイルの存在を完了判定に使ったが、これは誤りである
（ワーカーは「報告書を書く → ゲート → push → worker_done」の順なので、
ファイル出現は完了より早い）。worker-show / worker-list の JSON も推測でキーを読み、
返ってきた None を「稼働中」と誤読した。
Orca の通知機構自体は正常だった（メッセージは 19 件すべてキューに残っていた）。
正しい呼び方は 2>/dev/null で stdout だけを解釈すること。
完了の判定は worker_done だけ
（[仕様]: guide「A valid worker_done settles the Task and Dispatch automatically」）。
報告書ファイルの存在を根拠にしない。
コーディネーターの手順は 3 行である。
1. scripts/orca-wait.sh <run-id> を待機に使う（check --wait の正しい呼び出し）。
2. 返ったら scripts/orca-check-messages.sh <run-id> で要回答を先に読む。
3. 処理して --ack を渡して再武装する。worker-release は ack より前
（[仕様]: guide の正典形は reply → worker-release → check --ack <delivery_id> --wait … の順）。
Run には active な --wait を 1 本しか張れない。2 本目の check --wait は
ok:false / error.code='waiter_exists' で返り、プロセスの RC は 1 になる
（[実測]: {"ok":false,"error":{"code":"waiter_exists","message":"Run … already has an active actionable waiter."}}）。
待機は 1 本だけ張り、前面の確認は check --peek。2 本目の --wait は張らない。
--peek は active な waiter がある状態でも RC=0 で通り、未読メッセージを消費せずに返す
（[実測]: peek rc=0 / ok:true / messages 2 件（heartbeat）/ deliveryId は None）。
scripts/orca-wait.sh は waiter_exists を専用 RC=6 と人向け説明
（既に待機が張られている・前面では --peek を使う）で返し、他の失敗と区別する。
待機の継続は背景で単独コマンドとして起動する。
別コマンドの中に & で埋め込んだ背景化は、コーディネーターの実行環境（tool runner / PTY 経由）では
親シェルの終了で待機プロセスが死ぬことが実測されている（追送【7】。bash 一般の性質として転記しない）。
呼び出し元の寿命と waiter の寿命は別である。
クライアントが終了してもサーバ側 waiter は --timeout-ms まで残る（[実測]: 追送【5】）。
前面へ戻ったことを waiter 消滅と誤解して張り直さない（張り直すと waiter_exists で拒否される）。
reset の scope は --all | --tasks | --messages だけで
（[実測]: orca orchestration reset --help）、waiter 専用の解除は無い。推測で解除手段を作らない。
wrapper の引数は位置引数である。正しい形は
scripts/orca-wait.sh <run-id> <timeout-ms> <delivery-id>
（timeout を省くなら第 2 引数を空文字）。
scripts/orca-wait.sh run_review --ack delivery-previous のように低レベルのフラグを渡してはならない
（[実測]: --timeout-ms --ack という壊れた argv を生む）。
guide の低レベル check --ack と wrapper の引数形式を区別する。
実行例（1 行ずつ）:
1. 起動: scripts/orca-wait.sh <run-id> 900000 を背景で単独コマンドとして起動する（別コマンドの中に埋め込まない）。
2. 戻り値の読取: RC=0 なら要約を読み scripts/orca-check-messages.sh <run-id> で要回答を先に読む。
RC=6 なら前面は check --peek。それ以外の非 0 は失敗として調査する。
3. 処理後の再武装: 処理して得た delivery id を第 3 引数に渡して張り直す
（scripts/orca-wait.sh <run-id> 900000 <delivery-id>。timeout を省くなら第 2 引数を空文字にする）。
未 ack のバッチは --wait でも直ちに再配信される（[実測]: 追送【6】）。
--types は起床条件であって返却バッチを絞らない
（[仕様]: check --help「--types is the wake condition for --wait; a returned Delivery is always the whole FIFO batch」）。
空でないバッチを未処理のまま再武装すると、同じバッチを受け取って回り続ける。
受信したら必ず処理（要回答の読取・--ack）してから再武装する。
クライアントが死んだ後も残っていた waiter（orphan waiter）は wake を吸収する。
R5 レビュー中、レビュアの question を orphan waiter が受け取り、聞いている人が居なかった。
メッセージ自体は失われていない（後から --peek で 4 件すべて確認できた。[実測]: コーディネーター実測）。
ターンの先頭で必ず --peek を打つ。waiter の有無に関わらず。
これは「メッセージは落ちていない／読まなかっただけ」を裏付ける実例である。
ターンを終える前に orca orchestration worker-list --terminal-state reclaimable が
0 件であることを確認する（[仕様]: guide の完了会計「do not end the coordinator turn until it returns none」。
0 件でなければ各行の projection.nextAction.argv をそのまま実行する）。
worker-list の実フィールドは dispatchStatus / workerState / terminalState
（[実測]: 生 JSON の行キーを確認した。projection.liveness.status という形ではなかった）。
推測でキーを読まない。初見の JSON は 1 行ダンプしてから読む。
worker-list はページングされる。既定で最大 100 行までしか返らず、
page.hasMore が true なら opaque な page.nextCursor をそのまま渡して辿る
（[実測]: worker-list --help「Returns at most 100 local rows by default; Continue with the opaque page.nextCursor value unchanged」。
R5 レビューでは --limit 1 で total: 375 / scope.source: all だった）。
部分ページに対象行が無いことを「不在」と判断しない。scope.source も確認する。
端末会計・Task 状態・agent の生死は三者別である
（[実測]: R5 レビューの worker-show --dispatch ctx_e3120e20a00a では
worker.state=ready / Dispatch=dispatched / projection.liveness.verdict=live / 端末=retained がすべて別だった）。
workerState や terminalState を稼働判定に流用しない。
個別 Dispatch の観測は worker-show --dispatch <id> で行い、観測するフィールドは
dispatch.status・observation.status
（guide は PTY の生死としており agent の生死とは区別する）・
projection.liveness.verdict・dispatch.lastHeartbeatAt である
（[実測]: 4 フィールドの存在を worker-show の実応答で確認）。
本変更で足した機構は §3-2 の読取スクリプトと待機スクリプトの 2 本で、
CI ラチェット・OS 通知は含まない。
3-3. コーディネーターの文書にも評価を通す¶
設計書・計画書もeval-loopを通す。 v3の文書系品質ループを使い、fork版を既定、 閾値は 80（100 点満点。eval-loop 既定の 70 より厳しく取る。v3 の「8/10 目安」と同値）、最大2周とする。 較正 1 回目（§6-6）までは eval-loop が現行既定である。評価対象は元の依頼・一次資料・受入条件であり、計画の実行率だけで採点しない。 コーディネーターが評価結果と修正を記録し、閾値未達なら未解決点を判断へ戻す。 コードの機械ゲートをスコアで置換しない。
レビュー指示には 「指示書自体の事実誤認も所見にしてよい」 を常設する。 対象コードと同じように、コーディネーターの前提も実測・仕様・仮説と照合する。 レビュー指示書テンプレートにこの確認を含める。
3-4. 変異表を報告書の必須節にする¶
変異表は 最低3本、列は 変異 / 期待 / 赤の実測 / 復元後の緑。 実測にはコマンド・RC・失敗テスト名または検査名を付け、復元をバイト比較やdiffで確認する。 赤くならなかった変異も省かず、未検出の契約として所見に残す。 文書の変異なら既存のリンク・アンカー・文書ラチェットへ当て、検査がないことを正直に記録する。
レビュアは実装者のハーネスを信用せず、最低1ケースを独立に組む。 同じ期待値と状態モデルを新旧へ適用し、非現実的なモック応答で赤を作っていないかを確かめる。 変異の本数は網羅の証明ではない。
3-5. 未検査の象限を宣言する¶
報告書とPR本文に、契約ごとの正常系 / 異常系 / 境界の有無と欠けている象限を書く。 検査名・証跡を対応付け、「該当なし」は理由を添える。単に総テスト数を示して代替しない。 JWNETの要求レイアウトごとの正常結果往復を機械検査する案は候補であり、本変更では実装しない。 PRは既存どおりコーディネーターが作成し、ワーカー報告からこの表を転記する。
3-6. レビューの往復を記録する¶
スライスごとに対象SHA・各Rの判定・差し戻し理由（仕様の裏取り不足 / 歯の欠落 / 前提の断定等）を記録し、月次で見る。 担当と置き場所は未確定（§5）。R1を含むレビュー実施回数と初回承認率を分け、未完了スライスは承認までの回数へ混ぜない。 §1-3ではE4=5回、wl-hjlm=3回、wl-j4t6=1回、wl-bi5l=1回、wl-rk0cは確認済み2回で未承認である。 再レビューの原因が範囲拡大や別CI障害なら、それも分類する。
これはずれを観察する補助指標であり「唯一の定量指標」ではない。 回数だけを減らすために所見を抑えたり、スコアで承認を代替したりしない。 集計の保存場所と自動化は§5の未確定事項とする。
3-7. 利用者へ手順を渡す前に実行環境を確認する¶
手順の実行経路（端末か ! 経由か）、TTYの有無、シェルを確認する。
既に分かっている場合は再質問せず前提を手順へ書き、未確定なら必要な点を1問で確認する。
非対話経路では対応する入力方法を確かめ、秘密値をコマンド履歴・stdout・チャットへ出さない形にする。
秘密値が会話へ流入したら即ローテーションし、事故記録には値を残さない。
PSK・加入者番号・EDI利用確認キー・KEK、個人IP、GCPプロジェクト番号の実値を仕様書・報告書へ書かない。
4. 変えないもの¶
- v5のOrca supervised loop、起動コマンド、model / effort、端末寿命。 投入機構は v5 を維持し、レビューの配置・並行数だけは AGENTS.md の新規定を適用する。
- コーディネーター（設計・ゲート）/ 実装ワーカー / 独立レビュアの役割分担とRouting節のモデル指定。
- APPROVE + CI全緑 + base-currentのマージゲート、BLOCK時の同ブランチへの差し戻し、mainマージの人間ゲート。
pnpm verify、migration変更時のproof全流し、業務フロー変更時のS1と変異による歯の検証。- ワーカーはbdを操作せず、報告書の後にpreambleの権限で
worker_doneを1回送る規約。 - OpenCodeの
model:とpermissionブロック。質問の具体的な実行経路はpreambleに従う。
5. 未確定¶
- 有料本文の2プラグイン / 4スキルの内容と§3との関係。読めた時点で比較し、変更が必要なら根拠付きで改訂する。
- §3-6の保存場所（issue notes等）と月次集計の実装。ワーカーによるbd更新は解禁しない。
- 質問の即時表示、テンプレート必須節、変異表の記入・独立性をどこまで機械化するか。
本変更で足した機構は §3-2 の読取スクリプト（
scripts/orca-check-messages.sh）と 待機スクリプト（scripts/orca-wait.sh）の 2 本で、CI ラチェット・OS 通知は含まない。 - 待機の自動再武装（タイムアウト時の再
waitを誰が回すか）は未確定。現状は呼び側がorca-wait.shを回し直す。 - 本規律で手戻りが減るか。§1の小標本は現状の観測であり、導入効果は継続記録して判断する。
6. 評価関数の較正 — オラクルが人しかいない領域を測る¶
素材は rlquiz の実装ソース（MIT。出所 https://github.com/AI-Driven-R-D-Dept/rlquiz。
ユーザー提供の rlquiz-main.zip を展開したもので、展開先はセッション用の一時領域で永続しない。
読んだ実体は SKILL.md 全98行・README・SPEC・assets である）と
eval-loop プラグインの実装（~/.claude/plugins/cache/eval-loop/eval-loop/0.1.0/skills/ 配下。
run-eval-loop/SKILL.md 全354行・assign-eval-loop-evaluator/SKILL.md 全94行を読んだ）である。
記事の有料本文は §0 のとおり未読で、以下は実装ソースの契約と Greco の記録の突き合わせである。
rlquiz / akapen の導入は wl-4j5j / wl-tizx で行う（いずれも 2026-09-13 時点で open）。
本設計はその完了を判断の起点とする。
6-1. 枠組みの訂正¶
「AI の自己採点 90 点・人は 30 点」（記事「評価関数を作れ」AIの自己採点『90点』は、人が見ると『30点』のことも
https://note.com/masa_wunder/n/n344036762607 のタイトルが指すずれ）はコードの正しさの問題ではない。
コードには機械オラクル（pnpm verify の lint / arch / typecheck / test / build / semgrep / gitleaks、
migration 変更時の docker proof 全流し、CI の機械ゲート、報告書の変異表）があり、最も守られている領域である（§4）。
記事が指すのはオラクルが人しかいない領域で、AGENTS.md はそこにだけ eval-loop を当てている
（AGENTS.md:61「eval-loop（品質スコアループ）は文書系成果物のみ」）。
§3 の枠組み（指示・報告・評価の接続の規律）は直さない。§3 は指示・報告・評価の接続全般（工程の規律）を担い、
§3-3（文書への評価）は §3 に残す。§6 は評価基準そのものの較正を担う。
6-2. eval-loop の実装の実測¶
- criteria はオーケストレーターが決める（
run-eval-loop/SKILL.md:25「オーケストレーターがタスクに応じて設定」）。 - threshold の既定は 70（
run-eval-loop/SKILL.md:6の argument-hint と:26の表）。 - 評価者は
agent: general-purpose/model: opusの subagent （assign-eval-loop-evaluator/SKILL.md:7-8）。成果物の絶対品質を 100 点満点で採点し、scoreはquality.overallと一意に同値とする（同 SKILL.md:54-58）。 - 人の ○× ゲートが無い。
run-eval-loop/SKILL.md（354行）に「人」「human」「承認」の一致は無く （grep RC=1・2026-09-13 実測）、assign-eval-loop-evaluator/SKILL.md（94行）にも人の承認・○×の記述は無い。
6-3. rlquiz の成立条件のうち我々に欠けている 4 点¶
rlquiz SKILL.md「成立条件」（同 SKILL.md:21-29）・「手順」（同 SKILL.md:31-52）との突き合わせ。
| rlquiz の条件 | 我々の現状 |
|---|---|
| (1) 開票はメモ優先・点は従。単発の強判定はノイズを含む（SKILL.md:27。README「何がうれしいのか」節「なぜ数字よりメモなのか」に対照問への最強判定の実測あり） | eval-loop の評価者は数値スコアに加えて定性的な notes（未実装項目のメモ）・feedback（具体的な改善指示。合格でも残る改善余地を記載）を返す（assign-eval-loop-evaluator/SKILL.md:76・:78・:92・:94。run-eval-loop/SKILL.md:130-131・:344 で次の計画へ反映）。欠けているのは人が書いたメモを受け取る工程である |
| (2) 対照問（差が無いはずの 2 案）でノイズ床を測る（SKILL.md:29。README 同節「なぜ対照問を入れるのか」） | 我々では CI の赤を「実バグ / ノイズ」に分ける台帳（wl-ikij。2026-09-13 時点で open）。実例: 2026-09-12〜13 に同一フレークで 3 回赤を踏み、そのたびにゼロから調査した（wl-b3rz R2 指示書の記録。対応の修正は wl-bi5l） |
| (3) 人の ○× を経てから条文化（SKILL.md:51 手順 7。README 同節「なぜ人の ○× を挟むのか」） | AGENTS.md の不変条件は我々の rubric そのものなのに、コーディネーターが書いてマージしている。改訂案は人の ○× を得るまで確定しない。ただし ○× 待ちを理由に他の作業を止めない（SKILL.md:51） |
| (4) 反映後に fresh 実行者で dry run し「変わった点 / 変わらなかった点」を出してから締める（SKILL.md:52 手順 8。README 同節「なぜ最後に dry run するのか」。次ラウンドに入るかは人が決める） | 現状は「AGENTS.md に書きました」で締めている |
6-4. 我々が既に持つ対応物¶
- 「歯」（変異）は、差分の分離を機械検証する思想（rlquiz SKILL.md:26 成立条件 4「差分の分離を機械検証」）と同じである。 §3-4 の変異表がその運用である。
- 別ワークツリーの別モデルのレビュアは、rlquiz の fresh 採点者（SKILL.md:35 手順 3。 文脈なし・rubric と素材だけで予測する）に相当する。ただし対象が「成果物の正しさ」であって 「人に見せる前の問いの質」ではない点が §7 の preflight と違う。
6-5. rlquiz を使うときの禁則¶
封印予測を作る fresh 採点者に人の過去回答を渡さない（rlquiz SKILL.md:35 手順 3
「人の過去回答（answers.json・台帳）を絶対に渡さない — rubric の予測でなく人の癖の予測になる」）。
agent の予測を見せた瞬間に測定が死ぬ盲検が成立条件である（同 SKILL.md:19）。
akapen の回答ログ（推奨案と人が選んだ案の対）は較正の素材になるが、封印を作る subagent には
開催 dir と rubric と素材だけを渡す運用にする（草案 .worker-specs/akapen-integration-design-draft.md:75-83）。
6-6. eval-loop の扱い¶
「較正 1 回目」とは wl-4j5j（rlquiz 初回開催）の完了時点を指す。実施者はコーディネーター。
eval-loop はやめない。未較正の状態で正典を変えず、較正 1 回目の後に判断する。
設計書・指示書に対する preflight（§7-5）との置換・併存もそのときに決める（§3-3 の既定どおり、それまでは eval-loop が現行既定）。 判断（2026-09-15・禹さん）: 併存。 eval-loop で中身を 80 点採点し、人に見せる設計はその後に akapen の試問を通す（wl-4j5j 完了・較正 2 回目は wl-k46e）。
7. 実装前の人間ゲート（akapen）¶
本節は採用時に適用する条件の事前合意であり、wl-tizx の採用判断まで発火しない。
素材はコーディネーターの草案 .worker-specs/akapen-integration-design-draft.md（全113行）と
akapen の実装ソース（MIT。出所 https://github.com/AI-Driven-R-D-Dept/akapen。
実体は /Users/kyoei-woo/Projects/skills/akapen/akapen/plugins/akapen/skills/akapen/SKILL.md ほか。
SKILL.md 全89行・references/preflight.md 全61行・
references/reply-format.md 全37行を読んだ）である。
草案を 3 ファイルと突き合わせ、禁則・手順の記述に矛盾はなかった。
以下は草案を本設計の書き方（実測 / 仕様の印付け）へ直したもので、草案の行番号を出典に残す。
akapen の導入自体は本設計に含めない（追跡は wl-tizx。2026-09-13 時点で open）。
7-1. 現行の人への確認手段は「作った後」か「ターミナルの文字」¶
| 現行の手段 | 位置 | 形 | 出典 |
|---|---|---|---|
| main マージの人間ゲート | 作った後 | diff（人間承認 PR） | AGENTS.md:598「作業は develop のみ。main は本番で常に人間ゲート」 |
human-reviewed ラベル（prod-critical） |
作った後 | diff | AGENTS.md:240・258（main マージ時のみ必須） |
OpenCode の質問ツール deny / Orca の question |
作る前 | ターミナルの文字 | .opencode/opencode.json:19 の question: deny と .opencode/agent/implementer.md:78-79（TUI 質問と Orca question は別物） |
decision issue + bd defer |
作る前 | bd の本文 | .beads/PRIME.md:61-62（聞き忘れ防止。再開は bd undefer） |
実例（wl-jufs。2026-09-13 時点で open。表題と note を beads DB から読み取りのみで確認）:
JWNET 本番業務 UI 設計（27 機能の配置・受信箱・送信キュー・マニフェスト詳細の JWNET セクション）で、
199 行の markdown の設計書とターミナルの A/B/C 選択肢で確認し、4 画面とも絵を一度も見ていない
（草案 :23-25 の記録。草案はコーディネーターの記録であり、回答原文の独立実測ではない）。
7-2. akapen の禁則の読み替え表¶
SKILL.md「最重要禁則」（同 SKILL.md:14-24）を我々の実測に当てて読む。
特に「事実を人に聞かない — 各問に file:line か実行結果の引用」は §1 の未検証前提（§1-1）の再発防止であり、
引用を添えられない問いは人への質問ではなく自分の宿題である（草案 :26-28）。
| akapen の禁則 | 我々での意味 | 出典 |
|---|---|---|
事実を人に聞かない（各問に file:line か実行結果） |
引用を添えられない問いは出さない | SKILL.md:19 |
| 選択肢の対立軸は両方絵にする | A/B/C をテキストで出す現行の確認では、人は想像で補えずお任せに倒れる。UI は絵にする | SKILL.md:18 |
| 「決めてほしいこと」は 3±1 問 | 判断コストが本体。各問に未選択 = お任せ +（推奨）を明記し、未回答でも進められる形にする | SKILL.md:20 |
| 現物と乖離したモックを描かない | 既存画面に足すなら現行 UI の忠実な再現 | SKILL.md:21 |
| 正解が一意で自己検証できることは聞かない | 機械オラクルがある領域（コードの正しさ）は聞かない | SKILL.md:22 |
| 長文の読み物を要約したシートに組み直さない | 訂正対象の本文が人の目から消える。長文は指摘・添削モードで原稿そのものを見せる | SKILL.md:23 |
| 赤ペン回答が届く前に実装を始めない | 確認ゲートの意味が消える。待つ間は別作業をする | SKILL.md:16 |
| 試問（preflight）を文脈ゼロの subagent で | 我々の別ワークツリー・別モデルのレビュアと同思想。対象が「人に見せる前の問いの質」 | SKILL.md:48 手順 5・references/preflight.md |
7-3. 発火条件（コーディネーターだけが akapen を出す）¶
ワーカーは人と話さない（従来どおり orchestration の question でコーディネーターに聞く）。
表は草案 :47-61 の提案である。
| 発火条件 | モード | 出す単位 |
|---|---|---|
apps/web/src/pages/** に新規画面、または既存画面のレイアウトが変わるスライス |
標準 | 実装指示書を書く前 |
docs/superpowers/specs/*.md の新規設計書（方式・画面構成を含むもの） |
標準 | 設計書を書いた後・ワーカー投入の前 |
| ADR（方式転換級） | 標準 | ADR を書く前 |
docs/operations-manual/**・画面文言・利用者向け手順 |
添削 | 下書き → 人が直接書き換え |
| 長文の設計書・runbook・週次レポートへの指摘 | 指摘 | 原稿そのままに指摘 |
モードの決め方は返すものの形で決める（SKILL.md:34。人が指摘・注文を返すなら指摘、本文を書き換えるなら添削、それ以外は標準）。
回答は 3 モード共通の固定形【赤ペン回答】で 1 つの読み方で済む（references/reply-format.md:1-4。
1 行目と末尾は全モード必須・不変で、空の節は出さない。同ファイル :30-37）。
差さないところ（明示）
- コードの正しさ（verify ゲート・proof・CI・変異が正典。SKILL.md:22 と同旨）
- ワーカー → コーディネーターの質問（orchestration
question。§3-2 の経路） - 排他 1 択・多数アイテムの一括検収（SKILL.md:24 が対象外と明記）
- main マージの人間ゲート（置き換えない。akapen は前倒しであって代替ではない。草案
:61）
7-4. waste-link 固有の制約（4 つ。草案 :63-73）¶
- 秘密をシート・開催 dir に載せない。 シートは repo に残る（
./akapen/*.html）。 JWNET の加入者番号・EDI 利用確認キー・事前登録マニフェスト番号・PSK・KEK・個人 IP・GCP プロジェクト番号は 実値を載せない。画面の再現は fixture / 合成値で行う。gitleaks は./akapen/も走査する。 - シートの commit と反映後のコードの commit を分ける。 akapen SKILL.md の手順 9 も「反映後の原稿・コードの commit は人に確認してから」と分けている（SKILL.md:56）。 シートは「なぜこの設計か」の記録として残し（同 SKILL.md:56）、反映後のコードは従来どおりワーカーが行う。
- decision issue と二重管理しない。 人への判断待ちは従来どおり decision issue で構造化し、 シートのパスをその issue の notes に紐付ける（issue = 追跡、シート = 判断の現物）。
./akapen/は git 管理下に置く（.gitignoreに入れない。SKILL.md:56「HTML は消さずに残す」）。 ただし./akapen/mock/に置くモックも同じ秘密規律（1.）に従う。
7-5. preflight と eval-loop の比較¶
akapen の preflight（文脈ゼロ subagent に出す 5 問）は、我々の eval-loop より用途に合う（草案 :85-97）。
| eval-loop | akapen preflight | |
|---|---|---|
| 返るもの | 数値スコア + AI の定性 feedback（assign-eval-loop-evaluator/SKILL.md:54-58 の score 同値 + :76 の notes・:78 の feedback） |
落ちた問いと理由の列挙（preflight.md:39-45 の判定表） |
| 基準 | オーケストレーター（コーディネーター）が決める（run-eval-loop/SKILL.md:25） |
5 問固定（弁別・引用・実質1択・音読・内輪語。preflight.md:13-17。渡すのはシートのパスと読者宣言 1 行だけ） |
| 打ち切り | 閾値超え（AI が宣言） | 2 巡で打ち切り。残ったのが重大なら書き直し（preflight.md:47-54） |
| 人の位置 | 無し（§6-2） | シートを見る人が最終 |
設計書・指示書に対しては eval-loop より preflight を既定にする方向で検討する（草案 :96-97）。
AGENTS.md:61 の「eval-loop は文書系成果物のみ」をこの 5 問へ置き換えるかは、較正 1 回目（§6-6）の後に判断する。
それまでは §3-3 の既定どおり eval-loop が現行既定である。
7-6. 未確定¶
- 記事本文（有料・未読）が示す設計パターンと §7-3 の発火条件が食い違う可能性。本文を読めたら差し替える（草案
:111、§5）。 - preflight を eval-loop の置換にするか併存にするか（§6-6。較正 1 回目の後に判断）。
- akapen のシートが増えたときの置き場所（
./akapen/直下か機能別サブディレクトリか。草案:113。 SKILL.md 手順 6 は./akapen/<topic>-01.htmlへの保存を指定。SKILL.md:49-51）。