指示ではなく境界：自律型AIエージェントの制御をいかに維持するか

AIエージェントが自律的になるほど、私たちは慣れた方法でそれらを管理しようとする——プロンプトにルールを書く：「これに触るな」「そこだけで作業しろ」「決してこれをしてはならない」。3つの並列エージェントによる 実験 の間、私はこの方法が破綻する事例と、別の方法が機能する事例の生きたコレクションを2日間で集めた。本記事の主張は単純だ：指示とはエージェントがある確率で従う依頼であり、境界とは従順さに依存しないシステムの性質である。エージェントが1体で監視下で動いていた頃、その違いは文体上のものに見えた。エージェントが多数になると、それはアーキテクチャ上のものになった。

あるセッションでの5つのインシデント

以下の事例はすべてこのブログでのある作業セッションで起きた——記録されており、それぞれがテキストによる管理が失敗する異なる仕方を示している。

指示はなかった——事故が起きた。 エージェントは自分のタスクの準備中に、 git stash 共有ディレクトリで実行し、自分のタスクとは無関係な私の未コミットファイルをstashに持ち去った。誰も何も「違反」していない：禁止が単に存在しなかったのだ。これは指示の根本的な性質である——それらは事故の後に書かれる。エージェントがしてはならないことの完全なリストを書くことは不可能だ。

指示はあった——そして機能しなかった。 最初の事故の後、私はエージェントに明示的なルールを追加した：「厳密に自分の作業ディレクトリ内で作業せよ」。それでもエージェントの1体はメインカタログでgitコマンドを実行した——単に絶対パスでそこを参照しただけだ。悪意でも愚かさでもない：モデルは確率的であり、テキストルールの遵守もまた、コンテキストの長さと実行回数に掛け合わされた確率である。

技術的な境界は静かに機能した。 同じ実験で、最も予想される事故——「1体のエージェントが全員のブランチを切り替えた」——は一度も起きなかった。エージェントが慎重だったからではなく、 git worktree が物理的に1つのブランチを2つの作業コピーにチェックアウトすることを許さないからだ。保護はツールに組み込まれている。覚える必要も、従う必要もない——ただそこにある。

指示が境界にあるべき場所に置かれていた。 最も不快な発見：このブログの本番環境はプロンプトの一行で守られていた。masterへのpushは自動デプロイを起動し、各エージェントとそれを隔てていたのは「git pushするな」というテキストだけだった。それは持ちこたえた——しかしこれは運であって制御ではない：ここでの本当の境界はアクセス権、protected branch、書き込み権限のないトークンである。依頼が錠前の場所に立っていた。

エージェント自体の上にある境界。 セッション中に2度、実行環境が被験エージェントではなく私のメインアシスタントを停止した：権限分類器が本番サーバーへのSSHと未コミット変更の一括削除をブロックした——形式的にはタスクから導かれるが、明示的な人間の「はい」を必要とする操作だ。両方のブロックは正しかった。そしてどちらも、計画通りに行動しているとまったく誠実に信じていたエージェントの「規律」の上に起きた。

原則は新しくない——新しいのは対象だけ

工学はLLMよりずっと前にこの教訓を通過している。トヨタの生産システムではこの原則は poka-yokeと呼ばれる：ミスを防ぐのはプロセスの装置であり、作業者の警戒心ではない。正しい向きでしか挿入できない部品は、「正しく挿入せよ」というポスターより信頼できる。プラットフォームエンジニアリングでは同じものをguardrailsと呼び、セキュリティではdefense in depthと呼ぶ。どこでも同じ考えだ： 作業者が読んで、理解して、忘れなかったことに頼るな——誤った操作が不可能か高コストになるようにせよ。

“指示は依頼である。境界はシステムの性質である。依頼に支えられた制御は制御ではなく、累積効果を伴う運である。”

– 並列エージェントとの2日間の作業からの主要な結論

AIエージェントではこの古い原則が3つの理由でより鋭くなる。エージェントは多い——指示の失敗確率は各エージェントの各実行ごとに掛け合わされる。エージェントは速い——「誤り始めた」から「壊し切った」まで数秒で、人間は介入する間もない。そしてエージェントは字義通りだが信頼できない：彼らはどんなジュニアよりも熱心にプロンプトのテキストを実行し、それでも確率的に——そしてスケールでの確率的なルール遵守は違反を保証する。

境界は実際にどう見えるか

このセッションの後に私が構築した層——ファイルシステムから検証まで：

• ファイルシステム： 各エージェントに独自の作業コピー（git worktree、 Anthropicが推奨 する並列セッション用で、Claude Codeには組み込み）、そしてOSレベルではサンドボックス： Claude Codeのsandboxing はOSの標準プリミティブでファイルシステムとネットワークを分離する——Anthropicによれば、これにより彼らの内部権限リクエストが84%削減され、成功したprompt-injectionは内部に閉じ込められたままになる。
• 書き込み権限： prod 和 master 靠权限保护，而不是靠提示词——受保护分支、无 push 权限的令牌、为 agent 分配独立账号。可以在提示词里请求保留，但只能作为第二层。
• Runtime： worktree 不会隔离数据库、端口和容器——它们对所有副本都是共享的。运行测试和服务器的 agent 需要一次性资源：临时数据库、自己的端口、每个 agent 一个容器。
• 操作许可： 不可逆操作需经过确认或分类器——就像 Claude Code 中的 auto mode，它评估每个操作，而不是要么什么都问、要么什么都不问。这是一道只有人类明确决定才能移动的边界。
• 基于产物的验证： 不要相信 agent 的自我报告，而要相信磁盘上的痕迹。我那个卡住的 agent 在界面上看起来还在工作；诊断依据是二十分钟内它的副本里没有出现新文件。提交到自己的分支也是同样的思路：结果要能经受住故障和 agent 的乐观。

这套方案中的指令并没有消失——它们变成了最后一层，而不是第一层。提示词里的“在自己的目录里工作”仍然有用：它能降低尝试的频率。但在尝试和事故之间，应该有一道边界，而不是希望。

诚实的保留意见

边界不是绝对的：沙箱会被绕过，分类器会出错，已发布的绕过分析也经常表明这一点。因此边界是分层构建的——安全领域的一切都是如此。而且边界在起步时比指令更贵：配置 worktree、权限和沙箱要花几小时，在提示词里写一行只要几秒。不对称之处在另一方面：边界只需付一次成本，指令则要在每次运行时承担失败的概率。对我来说，配置隔离在第一次重启实验时就回本了，那次实验没有出现任何冲突。

结论

本系列的问题是：如何在不失去控制的情况下把 AI agent 融入实际工作。本文的答案是：控制不在于写给 agent 的内容，而在于围绕它构建的机制。在往提示词里再加一句“永远不要做 X”之前，值得先问自己：能不能让 X 在技术上不可能？如果可以——那才是应该投入精力的正确位置。让提示词去请求；禁止应该由系统来完成。

来源与参考

• Making Claude Code more secure and autonomous with sandboxing (Anthropic Engineering) ——在操作系统层面隔离文件系统和网络；84% 这一数字的来源。
• How we contain Claude across products (Anthropic Engineering, 2026) ——agent 产品中执行边界的整体设计。
• How we built Claude Code auto mode (Anthropic Engineering) ——权限分类器作为“什么都问”和“什么都不问”之间的边界。
• Poka-Yoke (Lean Enterprise Institute) ——通过流程设计防止错误的经典原则。
• git-worktree 和 git-stash ——Git 官方文档：工作副本机制与共享 stash。
• Claude Code: Best practices for agentic coding (Anthropic Engineering) ——为并行会话使用 worktree 的建议。
• Как честно сравнить LLM на своём коде: эксперимент с тремя моделями Claude ——本系列的上一篇文章：汇集了所述事故的实验。