AI Agentに本番権限を渡さず、仕事を完遂させるには？

自由に動かすのも、毎回止めるのも、どちらも足りない

AI AgentにBackendを触らせると、設計はすぐに二つの極端に寄る。本番で自由に実行させれば危険だ。かといって、すべての変更でHuman Approvalを待つと、Agentのループは切れる。考える → 試す → 観測する → 直す、という一連の仕事が成立しない。

必要なのは「権限を与える／与えない」の二択ではない。Agentの自律性と、Production Safetyを同時に成立させる実行境界だ。

「Sandbox」という言葉では足りなかった

この問題を「Sandboxを作る」と捉えると、すぐに本番コピーやブランチ、Promoteといったインフラ運用の話になる。しかし人間が欲しいのは環境の管理ではない。本番が勝手に変わらない安心と、試した結果を見て判断できる材料だ。

LUNOではこれを単一のSandbox機能として扱わない。Agent Execution Safety / Agent Governanceとして整理している。ユーザー向けにはSandboxという語を出さず、検証プロジェクトや変更計画として見せる。

Same Agent. Same MCP. Different authority boundary.

同じAgent、同じMCPでも、実行面によってauthorityが変わる。ツールを増やしてsandbox専用APIを覚えさせるのではなく、境界だけを変える。

三つの実行面

全体の流れはこうなる。

Intent → Change Plan → Verification / Canary → Evidence → Human Approval → Production

ここでの実行面は三つある。

Production Governance。Agentはdiscover / dry-run / proposeまで進める。高リスクな本番変更をAgentが直接executeしない。Change Planを経て、Human Approvalのあとに本番へ進む。

Production Canary。本番環境の一時リソースに対して、実際のmutation経路を一度だけ通す。顧客の既存IDやpublish、webhookはfail-closed。サーバが作った一時リソースだけをallowlistで許可し、観測したらarchiveする。本番本体のexecuteではない。

Verification Project。本番データのコピーではない。適用予定のChange Planを、Agentがexecute → observe → retryするための別プロジェクトだ。必要最小限のForm / Master / synthetic draftだけをmaterializeする。

CanaryとVerificationは別物

Canaryは「本番でしか分からない副作用」を最小単位で見る。同じDB、同じ制約、同じmutation経路を、一時リソースだけで通す。

Verificationは「承認待ちでセッションが死なない」ための試行場だ。Agentは検証側で一周回し、観測結果をEvidenceとして残す。

混ぜてはいけない。CanaryはVerificationの別名ではなく、Verificationは本番クローンでもない。両方を経ても、公開ドメインの最終確認はpreviewや人間の確認が残る。

sideEffectsとrecoverabilityは契約になる

dry-runが「成功しました」だけで終わるなら、人間は影響範囲を判断できない。だからgatedな変更では、サーバがsideEffects[]とrecoverabilityを返す。

sideEffectsは、次に何が起きうるかをAgentと人間が共有するための配列だ。recoverabilityは「失敗したら全部戻せます」という約束ではない。automaticに戻せるもの、人手で戻すもの、戻せないものを先に明示する。

Agentが送ってきた副作用の自己申告は信じない。サーバ側のdry-run結果が正本になる。

Verificationの成功は本番許可ではない

VerificationでうまくいったことはEvidenceだ。Production Approvalではない。自動promoteしない。

人間は「提案を信じて承認する」のではなく、「試した結果を見て承認する」。それでも本番への権限はHuman側に残る。Agent autonomyを高めることと、本番権限を無制限に渡すことは同じではない。

Same Agent. Same MCP. Different authority boundary.

Productionでは提案まで。Verificationでは最後まで実行できる。MCP toolは同じで、authority boundaryだけが違う。

これが重要なのは、Agent runtimeごとに別のsandbox APIを覚えさせないからだ。prompt burdenを増やさず、実行面の設計で安全性を取る。

Agent LoopとHuman Governanceをつなぐ

人間の役割は実装者から、承認者・監督者へ移る。Agentの失敗は本番事故ではなく、検証コストになる。

ループは非同期でよい。人間がAgentセッションに張り付く必要はない。完了だけのイベントを全部通知にするとInboxが壊れるので、Attentionが必要なものだけを通知し、判断はChange Planに、履歴はActivityに分離する。通知の詳細は別記事の主題になる。

いま言える核心は短い。AI Agentに本番権限を丸ごと渡さなくても、Verification / Canary / Human Approvalで仕事を完遂させられる。自律性はGovernanceの内側に閉じ込める。権限を足す製品ではない。