# AIエージェントが「そもそも不要な手作業」を人に頼むのを機械で止める ## この指示書が解く問題 「人の手作業を最小化せよ」というルールを持つAIエージェントに、こういうゲートを付けている現場は多い。 [手渡し判定] - 品質理由: <なぜ人がやると品質が上がるのか> - 試した自動化経路: <コマンド/API/ツール名を3つ以上・結果も> - 未試行で却下した経路: <名前と、なぜ不可と判断したか> **このゲートは「不要な手渡し」を1件も止められない。** 3項目はすべて 「**その手作業をどう自動化するか**」しか問わないからだ。エージェントは 「その手段を取るための代替経路」を誠実に3つ挙げ、満点で通過する。 **「その手段がそもそも要るのか」は一度も問われない。** ### 実際に起きた事故 エージェントが「CLI にログインして権限を照会したい」と考え、OAuth 承認を人に依頼した。 デバイスコードは15分で失効するのに、CLI 側は「Enter を押してください」で無期限に待つ実装だった。 プロセスが12時間固まり、その後も5回・75分ぶんのワンタイムコードを人が追う羽目になった。 後から読み取り専用のコマンドを**1回**打ったら exit 0。保存済み資格情報で目的は達成でき、 **そのログインは最初から不要**だった。しかも人が最初に頼んだ作業は既に完了しており、 その手渡しは**エージェントが勝手に増やした副次タスク**だった。 それでも3項目は埋まっていたので、ゲートは毎回 pass した。 --- ## 手順1: 足す3項目（既存項目の「前」に置く。順序が本質） [手渡し判定] - 依頼元: - 目的: <この手作業で最終的に何が分かる/できるようになるのか。手段ではなく結果> - 目的の代替達成: <目的を手作業なしで満たせないか実際に試した「コマンド → 結果」。 無いなら 代替なし(理由: ...)> - 品質理由: <既存> - 試した自動化経路: <既存> - 未試行で却下した経路: <既存> ### なぜこの3つなのか | 項目 | 止まる事故 | |---|---| | 依頼元 | AIが自分で思いついた副次タスクのために人を動かす（最も頻度が高い） | | 目的 | 手段を目的と取り違え、その手段の代替だけを探す | | 目的の代替達成 | 「試したが不可」を**書くだけ**で、1回も実行していない | **「依頼元: AI起案」は無条件で block にする。** ここを「理由を書けば通る」にすると意味がない。 どれだけ丁寧な手順書を付けても、依頼されていない作業で人を動かしたら違反、と機械で言い切る。 **目的は手段で書けないようにする。** 「ログインする」「インストールする」「設定を追加する」で 終わる記述を弾く。目的の形に直すと、たいてい別経路が見える。上の事故も、 「アクセスできるか確かめる」と書けた時点で読み取り専用コマンドに行き着いた。 **目的の代替達成には実行の痕跡を要求する。** `→` を含むか「代替なし(理由: ...)」の どちらかでなければ block。文字列の形で「実際に打ったか」を強制できる。 --- ## 手順2: 実装（応答テキストを検査する stop hook） 既存のゲート関数の**冒頭**に3つの検査を足す。既存の検査より前に置くこと。 ```js // 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=&body=&labels=<ラベル> これに「ラベル付き PR を CI 通過後に自動マージする」ワークフローを組み合わせると、 **人の操作は「Create pull request を1回押す」だけ**になる。 デスクトップにこの URL のショートカットを1つ置けば、探す手間もゼロになる。 作る前に、そのワークフローの**除外パス**を必ず読む。CI 定義・秘密情報・環境ファイルなどを 含む変更は自動マージの対象外にしてあるのが普通で、そこに当たるなら最初から人のマージを前提に書く。 --- ## つまずいた時の判断順 1. その手作業の**目的**を、手段でない言葉で1行書けるか？ 2. 書いた目的を、**読み取り専用のコマンド1本**で満たせないか？（実際に打つ） 3. その作業は**人が頼んだこと**か？ 自分が思いついた副次タスクではないか？ 4. 人に頼むとして、**期限のある承認**（ワンタイムコード等）を含むか？ 含むなら、人が画面の前にいる時だけ起動する形にする。不在の間に再発行を繰り返しても1回も通らない。 5. クリック数は**1回**まで減らしたか？ **「どう自動化するか」を考える前に「そもそも要るか」を問う。** 順序を逆にすると、 誠実に代替経路を3つ挙げながら、丸ごと不要な作業を人に押し付けることになる。 ---