# 「進めない先へ進んで空転する」を弾くガードが、代わりに全部の委譲を殺すのを防ぐ 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/...` `~/./...` など）が毎回「cwd の外」として検出される。 結果、**あらゆる委譲がフォールバックを失う**。サブ CLI が唯一の実行手段になっている機体では、 夜間バッチごと全滅する。 **対策**: 判定に使うのは**人が書いた指示そのもの**。連結前の変数を使う。 コード上は `prompt`（連結後）と `instruction`（生）のように別変数になっていることが多い。 ### 罠 B: 「外を参照している」だけで弾いている 指示文が説明のために外部パスを 1 行引用しただけでも落ちる。仕様書には参照先を書くのが普通なので、 これも実質的に全滅コースになる。 **対策**: 弾く条件を **「外を参照していて、かつ cwd の中に作業対象が 1 つも無い」** まで狭める。 ### 検証は必ず 2 本立てる（対照群） | | 入力 | 期待 | |---|---|---| | **A: 弾くべき** | 欠陥の再現ケース（対象が全部 cwd の外） | 即座に 1 行報告して終了 | | **B: 通すべき** | 日常の指示（cwd の中に対象がある） | 素通りしてサブ CLI が実際に完走 | **B を実物で通すまで完了にしない。** B は所要秒数で判別できる。弾かれていれば即座に返る＝実行していない。 実測例: A は 1090 秒 → 30 秒、B は素通りして 96 秒で完走。 --- ## 4. 起きなかったことを残す 弾いた結果「何も実行しなかった」は、放っておくと**記録が何も残らない**。 後日「その時間、何をしていたのか」が追えなくなるので、利用ログへ 1 行だけ追記する。 ```json {"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・実パス・回避策が入っている ---