Windows で無人 LLM CLI に長いプロンプトを渡すと spawn ENAMETOOLONG で即死する

症状

Node.js から無人の LLM CLI（<自作の委譲ツール> のように、コーディングエージェント CLI を -p <prompt> --model <model> の形で呼ぶラッパー）を child_process.spawn で起動すると、プロンプト本文が長い（数万字クラス）ときだけ起動直後に落ちる。エラーは Error: spawn ENAMETOOLONG (errno: -4064, syscall: 'spawn')。子プロセスは1行も出力せず、stdout・stderr ともに空のまま exit code 1 で終わる。短いプロンプトでは再現しないため、「たまに落ちる原因不明の委譲失敗」として見過ごされやすい。

実測: プロンプト本文 47,499 文字を argv に含めたところ、生成された引数文字列が 47,622 文字となり、Windows のコマンドライン長上限（約 32,767 文字）を超えて spawn システムコールがそもそも起動できずに失敗した。

原因

Windows は CreateProcess に渡せるコマンドライン全体の長さに約 32KB の上限がある。Node.js の child_process.spawn(cmd, args) は args を内部で1本のコマンドライン文字列に結合してから OS に渡すため、args の中にプロンプト全文のような長い文字列を含めると、上限超過時に ENAMETOOLONG で 子プロセスが起動する前に 失敗する。Unix 系では上限がずっと大きい（数MB）ため同じコードでも再現せず、開発機（Mac/Linux）では気づけない。

修正: プロンプトは argv でなく stdin で渡す

Before（argv にプロンプト本体を積む＝上限に当たる）:

const child = spawn(cliPath, ['-p', promptText, '--model', model]);

After（プロンプトは stdin へ、argv は固定長の短い引数だけにする）:

const child = spawn(cliPath, ['-p', '--model', model], {
  stdio: ['pipe', 'pipe', 'pipe'],
});
// stdin への書き込みエラー（子が早期終了した場合のEPIPE等）で
// プロセス全体を落とさないためのガード
child.stdin.on('error', () => {});
child.stdin.end(promptText);

これで argv は ['-p', '--model', model] のような数十文字に収まり、プロンプトが何文字あっても ENAMETOOLONG を起こさない。呼び出す CLI 側が -p 単体（引数なし）または標準入力を読む対応をしていることが前提なので、対象 CLI のヘルプで「stdin からプロンプトを読めるか」を先に確認すること。

回帰テストの書き方

--dry-run のようなモードを持つラッパーであれば、実際に子プロセスを起動せず「これから渡す argv」と「プロンプトの受け渡し経路」を出力させ、それを assert する。

// dry-run 出力例: { promptVia: 'stdin', promptChars: 40000, argv: [...] }
const result = buildSpawnPlan({ promptText: 'x'.repeat(40000), model: 'm' });
assert.equal(result.promptVia, 'stdin');
assert.ok(JSON.stringify(result.argv).length < 300);

「4万字クラスの長い指示を渡しても argv の JSON 化長が300字未満に収まる」ことをテストにしておけば、将来 argv 渡しに戻す変更が入っても即座に検知できる。

監視側の落とし穴: 単発の spawn 失敗が「healthy」に見える

委譲の成否を監視するヘルスチェックが「フォールバック経路（安いモデル等への切替）の低成果」を2件以上連続という閾値でしか検出していない設計だと、spawn 自体が失敗して0件しか実行されなかった単発の事故が「サンプル数不足」扱いになり、翌朝も healthy 判定のまま見過ごされる。spawn 失敗は成果物の質の問題ではなく起動の問題なので、閾値を待たずに1件で即座に別カテゴリとして検知すべきもの。

判定式（台帳の1行が以下を満たしたら即発火、severity: medium）:

provider === 'fallback'
  && out === 0
  && /syscall: 'spawn'|spawn E[A-Z]+|code: 'E[A-Z]{4,}'/.test(stderrTail)

台帳行の例:

{"provider":"fallback","out":0,"status":1,
 "stderrTail":"... { errno: -4064, code: 'ENAMETOOLONG', syscall: 'spawn' }"}

検証手順

1. dry-run: 上記のような長大プロンプトを渡して promptVia: 'stdin' と argv の短さを確認する。
2. 実起動 (E2E): 実際に長いプロンプト（数万字）で子 CLI を起動し、stdin 経由で応答が返ってくることを確認する（ENAMETOOLONG が再発しないこと）。
3. 実台帳での検知確認: 上の判定式が実際の履歴データ（過去の失敗事例を含む台帳）に対して1件から発火し、誤検知（正常応答をfalse positiveで拾う）がないことを確認する。