AI開発のたびに「承認します」と打つのをやめた

※「ChatGPTと育てる、自分専用AI基盤」Season 1 第10回です。

前回は、複数のChatGPTを同時に動かして開発を並列化したら、working tree、mainへのmerge、そして「誰の仕事か」という責任範囲まで普通に衝突した話を書きました。

→ 第9回：複数のChatGPTに同じシステムを開発させたら、普通に衝突した

Workspaceを分け、component leaseを入れ、mainへのmergeやdeployのような共有状態の変更を一つずつ通し、別Chatのworkspaceは「見えるけれど勝手には触れない」にする。

ここまでやると、複数のChatGPTをかなり安全に並列で動かせるようになりました。

ところが、並列化が進むと今度は私のところで詰まりました。

PRができる。テストが通る。次のPRもできる。別のworkspaceでも作業が終わる。そしてChatGPTが止まります。

「承認してください」

また別のPRが止まります。

「承認してください」

私は画面に向かって、「承認します」と何度も打つことになりました。

安全のために人間を残したはずなのに、気づけば人間が「承認」という文字列を返すだけの装置になっていました。

これは、何か違う。

そこで作ったのがStanding Delegationです。

最初は、毎回止まる方が安心だった
「承認をなくす」のではなく、「本当に承認が必要な場所」を決める
テストが落ちたからといって、人間へ戻ってこなくていい
それでも、人間から外さなかったものがある
「standard mergeなら全部勝手にやってよい」でもない
candidate deployも、戻せるなら途中で止めない
並列開発では、この差がさらに大きかった
文章で決めただけでは不安なので、Authorityも機械化した
人間は減った。でも、消えてはいない
続き：AIに「承認」ボタンを作る
連載ナビ

最初は、毎回止まる方が安心だった

第4回でGitHub Pull Requestを境界にした頃は、むしろ毎回止まることに意味がありました。AIがコードを直せるようになったばかりです。mainへ勝手に入ってほしくない。本番へ勝手に出してほしくない。

だから、変更→テスト→PR→人間が確認→承認→mergeという流れはかなり合理的でした。

ところが開発が進むと、PRの中身も変わってきます。小さな修正をisolated workspaceで行い、Ruff、mypy、pytest、Quality Gateを通し、exact HEADを固定し、staleなら止める。candidate deployもLast Known Goodとrollbackを持つ。

つまり、以前よりかなり多くの安全確認が人間の注意力ではなくシステム側へ移っていました。

それなのに、最後だけ毎回「この普通の変更を進めていいですか？」と聞かれる。しかも私が返す答えは、ほぼ毎回同じです。

「承認します」

安全確認をしているというより、儀式になり始めていました。

「承認をなくす」のではなく、「本当に承認が必要な場所」を決める

2026年8月14日、方針を変えました。

考え方はかなり単純です。

安全で、可逆で、すでに目的と範囲が決まっている作業なら、毎回聞かずに進める。

ただし、危険な境界まで一緒に開けるわけではありません。この方針をStanding DelegationとしてVaultに残しました。

対象になったのは、状態確認、isolated workspace作成、leased scope内の修正、テスト、修復、Quality Gate、commit、guarded branchへのpush、PR作成、ordinaryなguarded merge、candidate deploy、health確認、既存rollback経路などです。

以前なら途中の何か所かでChatGPTが私へ戻ってきました。Standing Delegationの後は、既存の安全機構が通っている限り、次の本当の人間境界まで進めてよいことにしました。

テストが落ちたからといって、人間へ戻ってこなくていい

この変更で地味に大きかったのが、失敗時の扱いです。

以前はテストが落ちると、「失敗しました。どうしますか？」と人間に返ってくることがありました。でも、原因が普通の実装ミスなら、そこで私に聞いても仕方がありません。

そこで、失敗したらまずAI側で、エラーを見る、原因を考える、leased scopeの中で修正する、focused testをやり直す、必要ならFull Quality Gateへ戻る、ところまで続けます。

人間へ戻るのは、安全な修復経路がなくなった時、失敗予算を使い切った時、あるいはprotected boundaryへ到達した時です。

「エラーが起きたら人間を呼ぶ」から、「人間にしか決められないことが起きたら人間を呼ぶ」へ変えたわけです。

それでも、人間から外さなかったものがある

Standing Delegationを作ったからといって、何でもAIに任せるようにしたわけではありません。むしろ、ここで人間が必要な場所をはっきりさせました。

secretやAPI key、SSH keyの作成・変更・削除、arbitrary root shell、firewallやnetwork trustの変更、security boundaryを弱める変更、destructiveなproduction DB操作、production dataの不可逆削除、Quality Gateやprotected branchを迂回する操作、rollbackが現実的に用意できない操作、私が最初に与えた開発目的そのものを大きく変える判断などです。

ここは、効率化のために消してはいけない境界です。

Standing Delegationの一番大事なところは、AIへ自由を与えたことではありません。人間の承認を、価値のある承認に戻したことです。

「standard mergeなら全部勝手にやってよい」でもない

GitHub mergeもstanding delegationの対象にしましたが、会話で毎回承認しなくてよいだけで、guard自体は残っています。

merge前にはrepository/base branch、exact base SHA、exact head SHA、preview fingerprint、required checks、mergeable state、conflictの有無、changed pathのrisk、stale previewではないことを確認します。どれかが変われば止まります。

つまり、「人間が見ていないから緩くする」ではなく、「機械で確認できることは機械へ移す」という変更でした。

candidate deployも、戻せるなら途中で止めない

review済みのrelease pathがあり、Last Known Goodがあり、health checkがあり、rollback経路がある。その範囲のordinaryなcandidate更新なら、毎回「candidateへ出してよいですか？」と聞かなくてよい。

出す。確認する。壊れていれば戻す。ここまでを一つの開発作業として扱います。

もちろんproduction-impactingで不可逆な操作は別です。ここでも線引きはAIか人間かではなく、戻せるか、影響範囲が限定されているか、現在状態を機械的に確認できるかでした。

並列開発では、この差がさらに大きかった

第9回のようにWorkspaceが複数になると、この変更の効果は大きくなります。

Workspace Aがtest中。Workspace BがPR-ready。Workspace Cが修復中。この全部が、私の「承認します」を待って止まるなら、AIを三つ並べても意味がありません。

逆に、routineな可逆処理はそれぞれが進み、shared mainの確定や本当に危険な操作だけが制御されるなら、並列化の意味が出てきます。

ここでようやく、人間が作業queueの中央に居座らなくてもよくなりました。

文章で決めただけでは不安なので、Authorityも機械化した

Standing Delegationは最初、Owner decisionとpolicyとして始まりました。ただ、AIができることが増えるほど、「これはstanding delegationの範囲だと思います」という自然言語の解釈だけに頼るのも危険です。

そこで後には、CapabilityごとにAuthorityを機械的に扱う層も作りました。

大まかには、A0=読み取り中心、A1=local/reversible、A2=bounded external action、A3=protected Owner gateという分類です。未知のCapabilityは、勝手に低リスク扱いせずA3側へ倒します。

実運用のdogfoodでは、A1のsandbox.pythonはOwner interventionなしで成功しました。一方、A3として扱ったprotectedなDevelopment pushは、exact targetとaction ID、contract SHA、replay fingerprintまで持つOwner decision packetを作り、実行せずに止まりました。

A2についても、scope外、stale、rate超過、cost超過、kill switch OFFといった条件でfail closedするrehearsalを行っています。当時productionではA2を0のままにし、仕組みだけを先に検証しました。

これは、Standing Delegationを「AIへの信頼」から、機械で狭められた権限空間へ変えていく作業でした。

人間は減った。でも、消えてはいない

Standing Delegationを入れる前は、人間が途中の作業に何度も呼び戻されていました。入れた後は、かなりの部分をAI側で連続して進められるようになります。

でも、Human-in-the-loopをなくしたわけではありません。むしろ、人間が残る場所が明確になりました。

機械で確認できる、戻せる、scopeが決まっているなら続ける。秘密・権限・不可逆・目的変更なら人間へ戻す。

この方が、自分にはずっと使いやすかったです。

「全部自動化する」より、人間を、本当に意味のあるところだけに残す。

これがStanding Delegationでやりたかったことでした。

ただ、ここまで承認回数を減らしても、完全にはなくなりません。本当に人間が必要な境界では、やはり承認が必要です。

そして、そのたびに次の問題が気になりました。

本当に承認が必要なのは分かった。でも、毎回長い承認文を入力する必要はあるのか？

そこで次に作ったのが、ChatGPT上のInteractive Approval UIでした。

続き：AIに「承認」ボタンを作る

第11回では、@@INLINE0@@ボタンや@@INLINE1@@ボタンをChatGPT上に出すInteractive Control UIを作った話を扱っています。

ただし、ボタンを押したらそのままdeployやmergeが実行される仕組みにはしませんでした。

UIは人間の意思を入力する場所であって、Authorityそのものではない。

ここを分けたことが、Season 1で最後に作った重要な境界になります。

→ 第11回：AIに「承認」ボタンを作った。でも、ボタンに権限は渡さなかった