AIエージェントの「委譲率」を正しく測る指標設計

監督AI（高性能・高コスト）が実装を安いエージェント（コード特化CLIなど）へ本当に渡せているかを、 毎日自動で測るための指標設計。素朴に作ると必ず嘘をつくので、3つの失敗パターンと対策を含む。

何のための指標か

「実装は安いエージェントに投げる」というルールは、実際に投げられているか測れないと守られない。 測定値を毎セッション開始時に監督へ突きつけ、閾値を割ったら警告（さらに割ったらツール使用をブロック）する、 という自己修正ループの心臓部が委譲率。

失敗1: 出力トークン比で測ると、完全に委譲しても十数%にしかならない

委譲率 = 委譲先の出力トークン / (委譲先 + 監督の出力トークン)

監督AIの「出力」にはツール呼び出しの往復・思考・進捗報告が全部含まれる。 実装本体を100%外に出しても、監督の会話量が支配的で比率は上がらない。

実測（同一期間・同一作業）: トークン比 18.2% / 行ベース 62.0%。 トークン比だけを見ると「まったく委譲していない」に見えるが、実態は実装の6割強を外部が書いている。

→ 「実装の実体」は行数で測る。

失敗2: 分母を「リポジトリに入った行」にすると常に100%に飽和する

委譲率 = 委譲先が書いた行 / git に landed した行   ← これは壊れる

委譲先は試行錯誤・書き直しをするため、書いた行 > 最終的に残った行。 実測: 委譲先 15,061 行 / landed 8,917 行 → クリップして常に 1.0。指標として無価値。

→ 分子と分母の母集団を揃える。 両方とも「エージェントが書いた行」にする:

委譲率(行) = 委譲先が書いた行 / (委譲先が書いた行 + 監督が手打ちした行)

• 委譲先が書いた行: セッションログ内のパッチ本文の + / - 行数（+++ --- @@ は除外）
• 監督が手打ちした行: 下記の通り、全ての書き込み経路を数える

失敗3: 監督側を「ファイル編集ツールの呼び出し」だけで数えると逆向きの嘘になる

編集専用ツール（Edit / Write 相当）の使用行数だけを数えると、監督の実作業が透明化して 「委譲率ほぼ100%」という都合の良い数字が出る。

実測した監督の出力内訳: ツール呼び出しのうち Bash 60% / Write 16% / Edit 6%。 自動承認モードでは監督はシェル経由（ヒアドキュメント、node -e、python -c、sed -i）で ファイルを書くことが多く、そこが最大の書き込み経路だった。

→ シェルのインラインプログラム本文の行数も監督の手打ちとして数える。

判定関数は1箇所に切り出して共有する。同じ判定を「委譲を促す警告フック」と「集計」が別々に持つと、 片方だけ直って静かにズレる。共有モジュールの例:

// inline-program.mjs — 警告フックと集計の両方がこれを呼ぶ
const EXCLUDED = /(?:委譲用CLIのファイル名|一時作業ディレクトリ名)/i;   // 委譲そのものはノーカウント
const MARKER = /(?:node\s+(?:-e|--eval)|python3?\s+-c|ruby\s+-e|perl\s+-e|<<\s*'?[A-Za-z_]*EOF\b)/i;

export function inlineProgram(command) {
  if (EXCLUDED.test(command)) return null;          // 委譲コマンド自体は除外
  const m = command.match(MARKER);
  if (!m) return null;
  const program = command.slice(m.index + m[0].length).trim();
  return { program, size: program.length, lines: program.split(/\r?\n/).length };
}

※ 警告フックは「大きい手打ちだけ叱る」ために文字数の足切りを持ってよいが、 集計側は足切りしない（小さい編集も実作業だから）。

実行時間: ログ解析は増分キャッシュにする

この種の集計はセッション開始フックから毎回走るため、遅さがそのまま全端末の待ち時間になる。 実測では行数集計の追加で 11.4秒 → 30.9秒 に悪化した。

エージェントのログは追記型でほとんど変化しないので、ファイル単位でパース結果をキャッシュする:

• キー = ファイルの絶対パス、検証 = (size, mtimeMs) の完全一致。一致したら読まない
• 期間フィルタ（例: 直近7日）が行単位の時刻で行われている集計は、日別の小計をキャッシュに持ち、 集計時に期間内の日付だけ合算する（ファイル単位で丸めると期間境界が狂う）
• 壊れたキャッシュは無視して作り直す。存在しないファイルのエントリは書き出し時に落とす
• キャッシュの読み書き失敗で本体を止めない（フックを壊さない）

実測: cold 20.5秒 / warm 6.8秒（キャッシュ導入前の 11.4 秒より速い）。ヒット 333 / ミス 3。

指標を差し替える時の安全策

委譲率が「閾値を割ったらツール使用をブロックする」判定に使われている場合、 定義変更と判定の切り替えを同時にやらない。

1. 新指標は**併記（参考値）**として先に出す
2. 数日並走させて旧指標との乖離を実データで見る
3. 納得してから判定を切り替える

未検証の指標をいきなり判定に使うと、誤判定で他の利用者の操作が突然拒否される。

検証チェックリスト（これを満たすまで完成としない）

• 分子・分母の両方が 0 でない実測値が出るか（片方 0 は判定バグ）
• 100% や 0% に貼り付いていないか（飽和は母集団ズレのサイン）
• 高速化した場合、出力される数値が変更前と完全一致するか（固定入力スナップショットで diff）
• 2回目の実行が目標時間以内か（1回目はキャッシュ生成で遅くてよい）
• 判定ロジックの共有関数が二重定義になっていないか

おまけ: 委譲そのものが静かに死ぬ

コード特化CLIをバックグラウンドで呼ぶ場合、標準入力を閉じないと入力待ちで永久に停止することがある （実測: 丸1日、出力0バイト・変更0件のまま生存していた）。

• 起動時に < /dev/null を付ける、またはタイムアウト付きのラッパー経由で呼ぶ
• 出力はパイプに流さずファイルへリダイレクトする（パイプはバッファされ、停止と実行中の区別がつかない）
• 返ってこない時はプロセスの生死とログ実体を見る。「長考中」と決めつけない