AIエージェントが「そもそも不要な手作業」を人に頼むのを機械で止める

この指示書が解く問題

「人の手作業を最小化せよ」というルールを持つAIエージェントに、こういうゲートを付けている現場は多い。

[手渡し判定]
- 品質理由: <なぜ人がやると品質が上がるのか>
- 試した自動化経路: <コマンド/API/ツール名を3つ以上・結果も>
- 未試行で却下した経路: <名前と、なぜ不可と判断したか>

このゲートは「不要な手渡し」を1件も止められない。 3項目はすべて 「その手作業をどう自動化するか」しか問わないからだ。エージェントは 「その手段を取るための代替経路」を誠実に3つ挙げ、満点で通過する。 「その手段がそもそも要るのか」は一度も問われない。

実際に起きた事故

エージェントが「CLI にログインして権限を照会したい」と考え、OAuth 承認を人に依頼した。 デバイスコードは15分で失効するのに、CLI 側は「Enter を押してください」で無期限に待つ実装だった。 プロセスが12時間固まり、その後も5回・75分ぶんのワンタイムコードを人が追う羽目になった。

後から読み取り専用のコマンドを1回打ったら exit 0。保存済み資格情報で目的は達成でき、 そのログインは最初から不要だった。しかも人が最初に頼んだ作業は既に完了しており、 その手渡しはエージェントが勝手に増やした副次タスクだった。 それでも3項目は埋まっていたので、ゲートは毎回 pass した。

---

手順1: 足す3項目（既存項目の「前」に置く。順序が本質）

[手渡し判定]
- 依頼元: <user依頼 | AI起案>
- 目的: <この手作業で最終的に何が分かる/できるようになるのか。手段ではなく結果>
- 目的の代替達成: <目的を手作業なしで満たせないか実際に試した「コマンド → 結果」。
                   無いなら 代替なし(理由: ...)>
- 品質理由: <既存>
- 試した自動化経路: <既存>
- 未試行で却下した経路: <既存>

なぜこの3つなのか

項目	止まる事故
依頼元	AIが自分で思いついた副次タスクのために人を動かす（最も頻度が高い）
目的	手段を目的と取り違え、その手段の代替だけを探す
目的の代替達成	「試したが不可」を書くだけで、1回も実行していない

「依頼元: AI起案」は無条件で block にする。 ここを「理由を書けば通る」にすると意味がない。 どれだけ丁寧な手順書を付けても、依頼されていない作業で人を動かしたら違反、と機械で言い切る。

目的は手段で書けないようにする。 「ログインする」「インストールする」「設定を追加する」で 終わる記述を弾く。目的の形に直すと、たいてい別経路が見える。上の事故も、 「アクセスできるか確かめる」と書けた時点で読み取り専用コマンドに行き着いた。

目的の代替達成には実行の痕跡を要求する。 → を含むか「代替なし(理由: ...)」の どちらかでなければ block。文字列の形で「実際に打ったか」を強制できる。

---

手順2: 実装（応答テキストを検査する stop hook）

既存のゲート関数の冒頭に3つの検査を足す。既存の検査より前に置くこと。

// 1. 依頼元
const origin = block.match(/依頼元:\s*([^\n]+)/)?.[1]?.trim() || '';
if (!origin) return { decision: 'block', reason: '依頼元がありません。' };
if (origin.includes('AI起案')) return { decision: 'block',
  reason: 'AI が起案した副次タスクを人に手渡しています。自分で完結させるか、落として報告だけにしてください。' };
if (!origin.includes('user依頼')) return { decision: 'block', reason: '依頼元は二択で書いてください。' };

// 2. 目的（「- 目的:」の箇条書きも拾う。「目的の代替達成:」は別キーなので一致しない）
const purpose = block.match(/^[\s>]*(?:[-*]\s*)?目的:\s*([^\n]+)/m)?.[1]?.trim() || '';
if (!purpose) return { decision: 'block', reason: '目的がありません。手段ではなく結果を書いてください。' };
if (/(ログイン|認証|インストール|設定を追加|セットアップ|有効化)(?:する|したい|してもらう)?$/.test(purpose))
  return { decision: 'block', reason: '目的が手段になっています。' };

// 3. 目的の代替達成
const altered = block.match(/目的の代替達成:\s*([^\n]+)/)?.[1]?.trim() || '';
if (!altered) return { decision: 'block', reason: '目的の代替達成がありません。' };
if (!altered.includes('→') && !altered.includes('代替なし(理由:'))
  return { decision: 'block', reason: '実行結果がありません。「<コマンド> → <結果>」の形で書いてください。' };

踏んだ落とし穴

箇条書きを拾えない正規表現。 目的: を行頭アンカー ^目的: で書くと、実際の応答で多い - 目的: ... に一致せず、正しく書いた応答を block する。^[\s>]*(?:[-*]\s*)? を前置する。 一方で 目的の代替達成: を 目的: として誤検出しないことも必要だが、目的: はコロンが 直後に来るので別キーとは衝突しない。この2つは同時に満たせる。

---

手順3: 検証（ここを飛ばすと「直したつもり」になる）

1. 変更前に全体テストのベースラインを取る。 件数・pass・fail を控える。 これが無いと、後から出た失敗が自分のせいか元からかを切り分けられない。
2. 新しい必須項目を足すと、既存テストの fixture が項目を持たないので fail が増える。 これは想定内。テストを書き換えて通そうとしない。実装を先に確定させる。
3. fixture の追記はモデルに書かせず決定的な変換スクリプトで行う。 fixture 文字列は1文字ずれると別のテストが壊れる。「[手渡し判定]\n品質理由: を [手渡し判定]\n依頼元: ...\n目的: ...\n目的の代替達成: ...\n品質理由: に置換」のような 機械的な全置換にすると、置換件数が出るので取りこぼしも分かる。
4. 新しい検査ごとにblock する側と pass する側を両方テストする。 block 側だけ書くと、「全部 block する実装」でもテストが通ってしまう。
5. 変更後の全体テストをベースラインと突き合わせる。 失敗ファイル名が同じなら退行なし、と根拠付きで言える。

実測（この手順での結果）

	ベースライン	変更後
tests	2838	2847
pass	2827	2836
fail	5	5

失敗5件は前後で同じファイル群＝既存の失敗。追加した9件がそのまま pass に乗った。

---

手順4: 配布（ここを外すとルールは伝播しない）

ルール本文とゲート実装の両方を正本リポジトリに入れる。 片方だけだと、実装があってもルール文書に無い（人が読んでも分からない）か、 文書にあっても機械が止めない（結局守られない）。

配布コピーを直接編集しても無駄なことが多い。 「正本の zip を定期的に展開して上書き」という 配布方式だと、配布先での編集は次回同期で無言で巻き戻る。成功ログもエラーも出ないので 「直したのに効いていない」の典型原因になる。配布先が git リポジトリか（.git があるか）を 必ず確認してから作業場所を決める。

即効性が要るなら、「検証済みのファイルを配布コピーへ置いて当座を効かせる」＋ 「正本へ PR を出して恒久化する」の二段にする。当座の反映が次の同期で消えることを明示しておく。

---

手順5: 人に渡す1ステップを最小化する

PR 作成に API 認証が要り、エージェントに認証が無い場合、そこは人の操作になる。 だがクリック数は減らせる。

多くのホスティングサービスは、PR 作成画面をクエリパラメータで事前入力できる。

<ホスト>/compare/main...<ブランチ>?expand=1&title=<URLエンコード>&body=<URLエンコード>&labels=<ラベル>

これに「ラベル付き PR を CI 通過後に自動マージする」ワークフローを組み合わせると、 人の操作は「Create pull request を1回押す」だけになる。 デスクトップにこの URL のショートカットを1つ置けば、探す手間もゼロになる。

作る前に、そのワークフローの除外パスを必ず読む。CI 定義・秘密情報・環境ファイルなどを 含む変更は自動マージの対象外にしてあるのが普通で、そこに当たるなら最初から人のマージを前提に書く。

---

つまずいた時の判断順

1. その手作業の目的を、手段でない言葉で1行書けるか？
2. 書いた目的を、読み取り専用のコマンド1本で満たせないか？（実際に打つ）
3. その作業は人が頼んだことか？ 自分が思いついた副次タスクではないか？
4. 人に頼むとして、期限のある承認（ワンタイムコード等）を含むか？ 含むなら、人が画面の前にいる時だけ起動する形にする。不在の間に再発行を繰り返しても1回も通らない。
5. クリック数は1回まで減らしたか？

「どう自動化するか」を考える前に「そもそも要るか」を問う。 順序を逆にすると、 誠実に代替経路を3つ挙げながら、丸ごと不要な作業を人に押し付けることになる。