ガードレールと権限モデル

サブエージェントを作成し呼び出す方法は第4章で実際に手を動かしながら習得する。しかしその前に、「このエージェントは何をしてよく、何をしてはいけないか」を先に定めておかなければ、実習中も実務でも事故が起きる。本章では、第2章で少し触れた「ガードレール」を実際にどう設計するかを扱う。

なぜガードレールが必要なのか

第2章では、ハーネスを「馬が思うままにどの方向にも走り出さないよう抑える馬具」に例えた。ガードレールは、その馬具の中でも特に「この方向へは絶対に行ってはならない」という柵に当たる。サブエージェントがファイルを読んで要約する程度であればミスをしても元に戻しやすいが、ファイルを削除したりコミット・デプロイまで自動で行うようになると、一つのミスが取り返しのつかない結果につながる。

問題は、「能力」と「リスク」が同じ方向に大きくなることである。エージェントにより多くのツール・より広い権限を与えるほど処理できる仕事は増えるが、誤った判断をしたときの被害範囲も同時に広がる。ガードレールはこの二つを切り分ける。「できること」は広く開けておきつつ、「人の確認なしに実行してよいこと」は狭く制限するのである。

危険な作業を3段階に分類する

すべての作業を同じ強度で統制すると、実務で使えないほど遅くなってしまう。実際には、作業を元に戻せる度合いに応じて3段階に分け、それぞれ異なる扱いをするのが現実的である。

この3段階分類は、本ハンドブックが参照したワークスペース文書の実際の規則とも一致する。第5章で扱った/syncパイプラインが.pem・.key・.envのような機微なファイルをコミット直前に遮断する「Sensitive File Guard」や、強制プッシュ・--no-verifyを明示的に禁止する規則が、まさに破壊的作業段階に当たるガードレールである。

最小権限の原則 — toolsフィールド

第4章§2の実習で作成したreviewerサブエージェントのfrontmatterを思い出してみよう。tools: Read, Grepのように、許可するツールを明示的に列挙した。これがサブエージェント単位の最小権限の原則である。reviewerにはそもそもWriteツールがないため、プロンプトがどれほど曖昧に解釈されても、ファイルを修正する手段自体が存在しない。

この原則を実際の事故シナリオで見てみると、なぜ重要なのかが明確になる。もしreviewerにWrite権限まで習慣的に開放していたとすると、「このファイルをレビューして改善して」というやや曖昧な依頼を受けた際に、reviewerが「改善」を「直接修正」と解釈し、原本を上書きしてしまう可能性もある。toolsフィールドで権限をあらかじめ狭めておけば、こうした解釈の食い違いがそもそも事故につながらない。プロンプトの品質に頼るのではなく、構造的に防ぐのである。

人による承認ゲート

第2章では、オーケストレーターを「ユーザーとの確認が必要な地点(ゲート)で進行を止める役割」と定義した。ガードレール設計で最も重要な問いは、「そのゲートを正確にどこに置くか」である。頻繁に止まりすぎるとエージェントに仕事を任せる意味がなくなり、止まらなさすぎると破壊的作業まで静かに通り過ぎてしまう。

実務で検証された基準は単純である。§2の「破壊的/外部影響」段階に当たる作業の直前では必ず止まり、それより下の段階は事後レビューで十分とする。例えば/syncパイプラインはコミット・プッシュ・PR作成までは自動で進めるが、PRを実際にマージしたりプロダクションにデプロイしたりする段階では別途人の承認を要求するよう設計されている。「どこまでは信頼して任せ、どこからは必ず人が見るか」という境界線を明示的に引いておくことが、ゲート設計の核心である。

分離 — worktreeとsandbox

第4章§2の上級シナリオ(P-1)で、「同じWorkspaceに複数のエージェントを割り当てると認知的重複(cognitive overlap)が生じうる」と警告した。これもガードレールの一形態である。複数のエージェントが同じファイル・同じgit履歴を同時に触ると、一つのエージェントのミスが他のエージェントの作業コンテキストまで汚染しかねない。

worktree(分離されたgit作業ディレクトリ)や別のsandbox環境で各エージェントを実行すれば、たとえ一つのエージェントが誤った判断をしても、その影響が自分の作業空間の外に漏れ出ることはない。複数のエージェントを並列で動かすときは、「同じ空間を共有させるか、物理的に分けるか」を常に先に決めておかなければならない。

監査ログと可観測性

ガードレールが事前予防だとすれば、監査ログは事後追跡である。完璧なガードレールは存在しないため、事故が起きたときに「いつ、どのエージェントが、どのツールで、何をしたか」を遡って確認できる最小限の記録が必ず必要となる。第5章で扱ったmemory/MEMORY.mdがセッション間のコンテキストを記録する用途であれば、TaskCompletedフックで実行されるaudit.tsのような監査スクリプトは、「規則に反する変更がなかったか」を毎回機械的に検査する可観測性の装置である。参考までに、このワークスペースのフック配線（2026-08-24時点）を整理すると、PreToolUseではgateguard-fact-force.ts（Edit|Write|MultiEdit）とagent-model-gate.ts（Agent）が、PostToolUse（Write|Edit）とTeammateIdleではpost-write-lifecycle-check.tsが動作し、audit.tsはタスク完了時点（TaskCompleted）で実行される。