AIエージェント日次速報 2026年9月20日版 AIに「進んでいい」を渡す前に。7つのエージェントで承認境界を設計する

AIに作業を任せるとき、怖いのは失敗したコマンドだけではない。下書きを保存するつもりの依頼が、そのまま公開や送信まで進むことがある。しかも画面には「完了」としか出ず、どの境界を越えたのか、誰が許可したのか、戻せるのかが後から分からない。確認作業が最後に集中し、任せた時間が監査の時間へ変わる。

この問題は、AIを止めるか自由にするかの二択では片付かない。読み取り、調査、テスト、下書きは進め、外部送信や公開、削除、課金、デプロイの直前で止める。その線を技術的な制限と承認手続きに分け、無人実行では確認できなければ拒否する。直近三日は前提、証拠、分割と統合を見てきた。今日は、実行を続けてよい場所と、必ず人へ戻す場所を七つの公式資料から読む...

サマリー

AIエージェントに任せる範囲と、人間の承認が必要な境界の設計について、7つの公式資料をもとに話します。OpenAI Codexのサンドボックスと承認ポリシー、Claude Codeの権限機能を例に、物理的なアクセス制限と実行許可を分ける考え方を説明します。Google AntigravityのプランニングモードやManusの承認待ち、Gensparkのテストランを通じて、計画確認や安全なシミュレーションで速度と安全性を両立する方法を示します。さらに、無人時は拒否をデフォルトにし、OpenClawの考え方に沿って承認を具体的な実行文脈に限定すること、承認境界カードで停止地点を明記する実践案を紹介します。

AIエージェントの承認境界を二層で設計する

あの、AIに仕事を頼んだとき、下書きをほぞろしておいてって言っただけなのに、なんか勝手に外部へ送信されてしまった、みたいな。

ああ、ありますね。

そういう日合わせを書いた経験、あなたにもありませんか?

ええ。画面に表示されるのは、「完了しました。」っていう無機質の文字だけで、あの、一体AIがどの境界を超えたのか、後からは全くわからないんですよね。

そうなんですよ。AIの暴走は確かに怖いんですけど、かといって毎回毎回確認の通知が来るのも、それはそれで疲れるじゃないですか。

確かに。仕事が進まなくなっちゃいますからね。

ええ。なので、あなたも情報型で本来の仕事が進まないと感じているなら、今回の深掘りは必要です。

はい。

今回のミッションは、AIエージェントの承認境界の設計なんですが。

ええと、とあるITエンジニアが7つの公式資料を分析した日時速報、これですね?

そうです。これを情報源にして、AIに作業を任せる際、どこまで自動で進めて、どこで止めるべきかを探っていきます。

よし、これを紐解いていきましょうか。

はい。私たちはつい、AIの運用を完全に止めるか、それとも自由に動かすか、みたいな二択で考えがちなんですけど。

極端になりがちですよね。

そうなんです。でもここで非常に興味深いのは、オープンAIのコーデックスですね。この公式資料では、これを根本から変えるアプローチをとっているんです。

と言いますと?

システムをですね、完全に2つの層に分けていて。

2つの層ですか?それってつまり、AIが物理的にアクセスできる空間の制限と、実際に作業を実行する許可を別々に管理するってことですか?

いや、まさにその通りです。あの物理的にシステムへ触れられる範囲を制限するサンドボックスと、

はいはい、サンドボックス。

その境界を越える前に確認を求める承認ポリシーですね。これを分けて設計しているんですよ。

なるほど。それって新人社員に例えるなら、金庫の鍵は渡さずに資料室の鍵だけ渡すっていうのがサンドボックスで。

ええ。

社外にメールを送る前には必ず私の犯行をもらいに来させるのが承認プロセスみたいなものですよね。

いや、完璧な理解です。

そういえば資料にあったクロードコードのディナイ・アスク・アラウっていう権限機能もまさにその思想ですよね。

ええ、そうです。犯行を押し間違えたとしても最初から金庫の鍵を持っていなければ致命傷にはならないんですよ。

確かに。

AIの気をつけますっていう言葉をただ信じるんじゃなくて、システムの外側から絶対的なルールで縛っている点が重要なんですよね。

計画レビューとテストランで速度と安全性を両立

なるほどな。でも触ってはいけない境界線が引けたとして、次に気になるのは、いつどうやって確認するかですよね。

そうですね。そこが次の壁になります。

いくら安全でも毎回犯行を求められたらそれはそれで地獄というか。

ですよね。そこでGoogleアンティグラビティのプランニングモードが参考になるんです。

プランニングモード?

はい。彼らはコードを書いた後じゃなくて、計画段階でレビューを求める仕組みを提案しているんです。

実行する前に計画を見るんですね?

ええ。また、マヌスの事例でも、ウェイティング、つまり承認待ちの状態をシステムエラーや作業完了と混同してはいけないと警告しています。

ちょっと待ってください。でも作業する前にいちいち計画をレビューしていたら、AIの圧倒的な速さっていう最大のメリットが死んでしまいませんか?

ああ、そこはすごく鋭い指摘です。

はい。

そのスピードか安全かというジレンマを解消するのが、ゲンスパークのテストランみたいなアプローチなんですよ。

テストランっていうことは、本番環境の前に一度試すっていうことですか?

その通りです。実際のデータ変更とか外部への送信を一切起こさない安全なシミュレーション環境で一度AIを走らせるんです。

なるほど。つまり舞台のリハーサルみたいなものですね?

ええ。

リハーサルなら何を間違えても本番には影響しないから、AIを全力のスピードで走らせておいて、私はその結果だけを安全な場所で確認すればいいと。

はい、そうです。これなら圧倒的なスピードと安全性を両立できますよね。見事な仕組みです。

無人時の拒否と限定的な承認

テスト環境で確認するのはすごく納得です。でも夜間とかあなたが画面を見ていないときに、AIが承認を求めてきたら、そういうときはどうすべきなんでしょう?

まあ、そこはハーメスエージェントが明確な答えを出していますね。

何ですか?

無人時で確認ができない場合は、許可ではなく拒否をデフォルトにすべきだと。

ああ、なるほど。

はい。

我慢を見ていないときは拒否にするのはわかります。でも私たちがデスクにいて、実際に承認ボタンを押すときはどうなるんでしょう?つまりこれってどういう意味があるんでしょうか?

と言いますと?

気をつけないと、その1回の承認がAIへの白紙こぎってになっちゃう危険がありますよね。何でもやっていいよ、みたいな。

いや、まさにそこがオープンクローが解決しようとしている脆弱性なんです。

ああ、オープンクロー。

これを全体像と結びつけて考えるとですね、一度の承認を何でもOKの免罪符にしちゃいけないんですよ。

はいはい。

彼らの設計思想では、承認は実行するディレクトリーとか引数といった具体的な実行文脈と厳密に紐づけられなきゃいけないとしています。

つまり、AIにファイルを削除してもいいよっていうBIPの全アクセスパスを渡すんじゃなくて。

そうじゃなくて。

今この特定のフォルダーの中にあるこの一時ファイルだけを削除していいよっていう1回きりの使い捨てチケットを渡すようなイメージですね。

その例えは分かりやすいですね。まさにその通りです。

この条件、この場所だから許可したっていう厳密な使い捨てチケットの記録を残すことが未来の事故を防ぐ鍵になるんです。

承認境界カードで停止地点を明記する

なるほどな。じゃあ今日からすぐに使える実践的なアイディアとして、情報源では承認境界カードの導入を提案していますね。

ええ、これはいいアイディアですよ。

明日の仕事からAIへの依頼時に、どこまで自動で進めて何の直前で止まるかをAI自身に明記させる小さな受領書のようなものです。

そうですね。そのカードに空欄があるならAIは作業を完了してはいけないと。人間が見るべき場所を狭く、でも曖昧にしないための素晴らしい仕組みです。

ここからが本当に面白いところなんですが、私たちがAIを使いこなす未来では、いかに賢くAIに指示を出すかよりも、いかに美しくAIの限界を設計するか。

ええ、限界の設計ですね。

それがあなたの最も強力なスキルになるのかもしれません。さて、あなたは今日、AIのどこに線を引きますか?