「進めない先へ進んで空転する」を弾くガードが、代わりに全部の委譲を殺すのを防ぐ

AI エージェントに実装を委譲していると、進めないと分かっている先へ進んで時間だけ溶かす失敗が出る。 典型は、サブのコーディング CLI（gemini-cli / qwen 系）へフォールバックしたとき:

Error executing tool write_file: Path not in workspace: Attempted path "<別ツリー>"
resolves outside the allowed workspace directories: <起動時の cwd>

これを延々と繰り返してタイムアウト上限まで走り、出力ゼロで終わる。実測では 1 回あたり 18 分。

この指示書は、その欠陥を弾くガードの入れ方と、ガードそのものが事故になるのを防ぐ検証手順を書く。 後者が本題。素直に実装すると、高確率で「全部の委譲が落ちる」状態を作り込む。

---

1. まず原因を正しく掴む（ここを間違えると直らない）

多くのコーディング CLI は 許可ワークスペースの root が「起動時の cwd」ただ1つで、 それを広げるオプション（--include-directories 等）を渡していない限り、cwd の外は読み書きできない。

つまり欠陥の条件は「cwd が変なところ」ではなく:

cwd と、指示が読み書きしようとする対象パスが、別のツリーに分かれている

確認手順（推測で実装に入らない）:

1. 同じ cwd で「その中だけを読む」指示を 1 回投げる → 正常終了するはず。これで「cwd 自体が悪い」説が死ぬ。
2. 失敗した実行のログから Path not in workspace の行を拾い、拒否された実パスと 許可されていた root を読む。2 つが別ツリーなら確定。
3. フォールバック呼び出しの引数を組み立てている関数を読み、範囲を広げるフラグが 渡っていないことを確認する。

---

2. ガードの設計

起動する前に弾く。中身は 2 つの純関数に分ける（テストしやすくするため）。

pathsOutsideCwd(instructionText, cwd) -> string[]
  指示文に出てくる絶対パスのうち cwd の外にあるものを列挙

hasTargetInsideCwd(instructionText, cwd) -> boolean
  指示文が cwd の中の対象にも触れているか

呼び出し側:

const outside = allowOverrideFlag ? [] : pathsOutsideCwd(instruction, cwd);
// 外を参照していても、中に作業対象があるなら通す（次章の理由）
const blocked = outside.length && !hasTargetInsideCwd(instruction, cwd) ? outside : [];
if (blocked.length) {
  // cwd 単独スコープの CLI 系バックエンドだけ候補から外す。
  // API 直叩き系（ファイルを渡す方式）は影響を受けないので残す。
  backends = backends.filter(b => !isCwdScopedCli(b));
}

実装の細かい罠:

• 前方一致で内外を判定しない。 C:\repo\main-backup を C:\repo\main の内側と誤判定する。 必ず区切り文字を付けて比較する（root + sep で startsWith）。
• 素の / 始まりを絶対パスとして拾わない。URL やコマンドラインフラグと区別できない。 ドライブ付き（X:\）と ~/ 始まりだけを見る。
• http:// https:// を含む文字列は除外する。
• 大小を無視する OS では正規化して重複を潰す。
• 文末の句読点（…/x.js。 …/x.js,）を切り落とす。
• 相対パスを「作業対象」と数えるのは cwd の下に実在するときだけ。架空のパスで素通りさせない。
• 人が承知で押し切るフラグを必ず 1 つ残す（--allow-outside-workspace 等）。

---

3. ここが本題 — ガードは「通す側」を実測するまで完成ではない

素直に実装すると、次の 2 つを踏む。どちらも「直った」と報告した後に本番を壊す。

罠 A: 判定の入力が「組み立て後の文字列」になっている

多くの委譲ツールは、人が書いた指示の前に文脈（プロジェクトの記憶・規約・過去の失敗集）を自動で連結してから サブ CLI に渡す。この連結後の文字列を判定に使うと、文脈側に必ず含まれる設定ディレクトリのパス （~/.config/... ~/.<tool>/... など）が毎回「cwd の外」として検出される。

結果、あらゆる委譲がフォールバックを失う。サブ CLI が唯一の実行手段になっている機体では、 夜間バッチごと全滅する。

対策: 判定に使うのは人が書いた指示そのもの。連結前の変数を使う。 コード上は prompt（連結後）と instruction（生）のように別変数になっていることが多い。

罠 B: 「外を参照している」だけで弾いている

指示文が説明のために外部パスを 1 行引用しただけでも落ちる。仕様書には参照先を書くのが普通なので、 これも実質的に全滅コースになる。

対策: 弾く条件を 「外を参照していて、かつ cwd の中に作業対象が 1 つも無い」 まで狭める。

検証は必ず 2 本立てる（対照群）

	入力	期待
A: 弾くべき	欠陥の再現ケース（対象が全部 cwd の外）	即座に 1 行報告して終了
B: 通すべき	日常の指示（cwd の中に対象がある）	素通りしてサブ CLI が実際に完走

B を実物で通すまで完了にしない。 B は所要秒数で判別できる。弾かれていれば即座に返る＝実行していない。 実測例: A は 1090 秒 → 30 秒、B は素通りして 96 秒で完走。

---

4. 起きなかったことを残す

弾いた結果「何も実行しなかった」は、放っておくと記録が何も残らない。 後日「その時間、何をしていたのか」が追えなくなるので、利用ログへ 1 行だけ追記する。

{"t":"…","provider":"fallback","model":"none","out":0,"status":1,
 "secs":38.995,"abort":"outside_workspace","outsidePaths":["…"]}

既存の記録関数が引数の形を変えていて任意キーを書けないことがある。その場合は記録関数を通さず ログへ直接 1 行追記する（無理に共通化して書けないキーを諦めない）。

---

5. ガードのメッセージに入れる要素

1 行で、次の 4 つを必ず含める。これが無いと人が自力で直せない。

• なぜ止めたか（外を参照していて中に対象が無い）
• 今の cwd
• 引っかかった実パスの例（2〜3 件）
• 回避策（cwd を共通の親へ広げる / 指示に全文を同梱する / 押し切るフラグ）

---

6. チェックリスト

• 「cwd 自体が悪い」説を、同じ cwd の読み取り専用指示 1 回で否定した
• 判定の入力が連結前の指示文になっている
• 弾く条件が「外を参照 かつ 中に対象が無い」まで狭い
• 前方一致の罠（main と main-backup）を潰した
• 押し切るフラグがある
• A（弾く）と B（通す）の両方を実物で 1 回ずつ流した
• 弾いたときログに 1 行残る
• メッセージに cwd・実パス・回避策が入っている