パーミッションプロンプト・Sandbox・Checkpoint：AIエージェントの実行境界を理解する
約16分developer-tools
#パーミッションプロンプト#サンドボックス#チェックポイント#ワークツリー隔離#コンテキスト消費#AIコーディングツール#用語集
※ 編集方針：以下の業務状況と人物は、用語の理解を助けるための仮想のシナリオです。実際の著者の経験や特定の企業の出来事を再現したものではありません。
新しいチームで、200個以上のレガシー決済モジュールファイルをAIエージェントを使って新しいSDKに移行する状況を想定してみましょう。
月曜日の朝、エージェントに「決済モジュール全体を新しいSDKの構文に書き換えて」と指示しました。数分もしないうちに画面が停止しました。
AIが突然停止して承認を求めてくるとき、パーミッションプロンプトの正体
text
1다음 명령을 실행하시겠습니까?2 rm -rf ./legacy-payment/*.old34[y/n]
ファイルを削除するという要求は、ケースの担当者にとっても予想外のことでした。移行スクリプトを書いてほしいと頼んだだけで、何かを削除するように指示した覚えはなかったからです。
公式ドキュメントを調べてみると、その理由が書かれていました。ファイルの削除、外部ネットワークの呼び出し、システム設定の変更など、取り消すのが面倒な作業は、エージェントが自ら判断して一時停止し、人間に確認を求めるように設計されていました。AIが気を遣っているのではなく、リスクが一定の基準を超えた瞬間に、自動的に人間のチェックを通すように作られた仕組みだったのです。
承認要求を拒否して理由を問い直したところ、今回は削除の代わりにファイル拡張子を
.old に変更するだけの方法で進行しました。ファイルを削除することなく作業は完了しました。問題はその次でした。承認したコマンドが実際に実行される前に、もう一つのレイヤーを経由していることに気づきました。
rmコマンドを承認したのにファイルが無事なとき、サンドボックスが果たす役割
同じチームの同僚の過去のPRをチェックしていたところ、
.claude/settings.json にこのような設定があるのを見つけました。json
1{2 "sandbox": {3 "bash": "restricted",4 "network": "deny"5 }
同僚に尋ねると、この設定のおかげでエージェントが実行するコマンドが、実際のプロジェクトフォルダではなく、隔離された一時的な環境でまず実行されるとのことでした。結果の安全性が確認されて初めて、実際のファイルに反映される仕組みでした。
模擬口座でまず送金を試してみて、問題がないときだけ実際の口座に送るような手順です。コマンド自体はそのまま実行されますが、実際のリソースに届く前に、安全な部屋で一度フィルタリングされるわけです。
そのおかげで、移行スクリプトが途中で誤ったパスを削除してしまっても、実際に消失したファイルは1つもありませんでした。火曜日がそうして過ぎ去り、水曜日にはスクリプトを半分ほど元に戻したい状況が発生しました。
移行を半分ほどやり直したいとき、チェックポイントに戻る方法
決済モジュールのうちの1つを、誤った方向に修正しすぎてしまったことに後から気づきました。元に戻そうと画面を見ると、エージェントが自らこのようなメッセージを表示しているのが目に留まりました。
text
1Checkpoint saved: before-refactor-payment-v2217 files changed
ケースの担当者が復元機能を要求したわけではなかったのですが、大きな変更作業の直前ごとに、このような保存ポイントが自動的に残されていました。作業規模が大きくなるたびに、戻るべき地点をあらかじめ記録しておく仕組みなので、「ここに戻して」と伝えるだけで、その時点のコードに正確に復元されました。
チェックポイントがなければ、誤った部分だけを手動で選び出しながら元に戻さなければならなかったでしょう。多くの時間を取られたはずの作業が、コマンド1行で完了しました。
決済モジュールは整理されましたが、木曜日になると別の問題が発生しました。通知モジュールも一緒に修正しなければならないのですが、決済モジュールのブランチがまだ完了していない状態でした。
2つのブランチを同時に編集する必要があるとき、ワークツリー隔離が必要な理由
以前似たような状況で残しておいたメモがないか探していると、プロジェクトフォルダの横に見慣れないディレクトリがあるのを見つけました。
bash
1$ ls ../2payment-migration/3payment-migration-notify/ # 지난달에 만들어놓고 잊고 있던 폴더
1か月前、同じように2つの作業を同時に進行する必要があったときに作成し、すっかり忘れていた作業スペースでした。同じリポジトリであってもブランチごとにフォルダ自体を分けておけば、一方の作業ファイルがもう一方に混ざることは一切ありません。
同じ家の中にもう一つ部屋を作り、引っ越しをすることなく別のプロジェクトをその部屋で進めるようなものです。リポジトリを丸ごと複製する必要なく、フォルダをもう一つ開くだけで、別のブランチをその場ですぐに作業することができました。
通知モジュール用のフォルダを新しく開き、決済モジュールの作業を妨げることなく並行して進めました。そうして1週間をほぼ使い切りましたが、金曜日の午後になると、エージェントが少しおかしな動きをし始めました。
エージェントが先ほど言ったことを何度も忘れてしまうとき、コンテキスト消費のサイン
月曜日に決めた命名規則をもう一度説明してほしいと頼むと、すでに何度も教えた内容を初めて聞くかのように聞き返してきました。一度ならまだしも、同じようなことが何度も繰り返されました。
text
1Compacting conversation...2Compacting conversation...3Compacting conversation...
画面の隅に表示されるこのメッセージが、毎回度を超えるほど頻繁に出ていることに気づいて初めて、合点がいきました。1週間分の会話とファイル内容が蓄積したことで、エージェントが一度に保持できる記憶の限界に近づいていたのです。限界に達すると、古い詳細内容から要約したり押し出したりしてスペースを確保します。その過程で、初期の細かい規則が薄れてしまいます。
机の上に資料を積み重ねていくと、ある時点で古い書類から箱にしまって片付けることになります。すべて消えてしまうわけではありませんが、今すぐ目に見える場所からは押し出されてしまいます。
1週間を締めくくるにあたり、命名規則をルールファイルに改めて書き留め、翌週は新しいセッションで開始することにしました。記憶が薄れるのを防ぐことはできなくても、重要なルールは毎回口頭で説明する代わりにファイルに書き残しておけばよいのだと学びました。
よくある質問
パーミッションプロンプトが表示されるたびに、無条件で承認しても大丈夫ですか？
いいえ。削除や外部呼び出しなど、取り消しが困難な作業ほど、なぜ必要なのかをもう一度確認する方が安全です。ただし、繰り返される慣れた作業であれば、設定で特定のコマンドを事前許可しておき、毎回尋ねられないようにすることも可能です。
ワークツリーを複数作成すると、その分ディスク容量は増えますか？
ファイルを完全に複製するよりは増加量を抑えられます。ただし、ブランチごとに個別のフォルダが作成される仕組みであるため、完全に無料（容量ゼロ）というわけではありません。作業が終わったワークツリーは定期的に整理することをおすすめします。
コンテキストが消費されると、以前の作業内容は完全に失われてしまいますか？
完全に消失するというよりは、要約されたり後ろに押し出されたりするイメージに近いです。ただし、詳細な条件や細かいルールなど、要約の過程で抜け落ちやすい内容は、ルールファイルやメモに別途残しておくのが安全です。
AIコーディングツール用語集シリーズの第2編です。次回予告 · 第3編 エージェントを終了したのにターミナルで何かが動き続けているとき：ゾンビタスク・孤児プロセス・エージェントスウォーム・バイナリ・依存関係
参考・根拠
関連記事
サブエージェント・フック・スラッシュコマンド：AIコーディングツールでよく使われる拡張概念
AIコーディングツールの使用中に出会う「サブエージェント」「フック」「スラッシュコマンド」を、架空の業務シナリオを交えて分かりやすく解説します。
Kill Switch・Backoff・Runtime：実行を停止し復旧するための基本機能
AIコーディングツールを使っていると遭遇する、キルスイッチ、バックオフ、リポジトリなどの5つの用語を、仮想の業務シナリオを通じてわかりやすく解説します。
Drift・環境変数・PATH：マシンごとに開発環境が異なる理由
AIコーディングツールを使用する中で直面する、ドリフト、ウォーターマーク、環境変数などの5つの用語を、仮想的な業務シナリオを通して解説します。