AIがコマンド実行で出すエラーは、サンドボックスの制限とは限りません。Claude Code・Codexの仕組み、エラー文の早見表、切り分け手順と解除前のチェックリストで見分け方を解説します。
AIコーディングツールに作業を任せていると、コマンドがエラーで止まる場面によく出会います。そのとき反射的に「サンドボックス(AIの操作範囲を制限する隔離された実行環境)のせいだ」と考えて制限を外してしまうと、本来守るべき安全策を無駄に緩めることになりかねません。この記事では、原因を見分けるコツを、Claude CodeとCodexの公式ドキュメント(2026年10月時点)で確認した仕組みとあわせて解説します。サンドボックスそのものの基礎はサンドボックスとは?(その1)、許可設定の運用はサンドボックスの実践編(その2)をご覧ください。
「エラーが出た=サンドボックスのせい」とは限らない
AIが実行したコマンドが失敗したとき、原因の候補は大きく3つあります。1つ目はサンドボックスによる本物の制限、2つ目は接続先のサーバーや回線の一時的な不調、3つ目はツールそのものが隔離環境の中では正しく動かないという相性の問題です。対処法がまったく違うため、まず「どれに当たるか」を見極めます。
運営者自身も混同したことがあります。ある作業でAPI(外部サービスと情報をやり取りする窓口)から情報を取得しようとした際、成功するときと「接続が途中で切れた」というエラーで失敗するときがありました。制限を疑いましたが、実際は接続先との通信が不安定だっただけで、時間を置いて再実行すると成功しました。逆に別の場面では「操作が許可されていません」という明確なエラーが出ており、こちらは正真正銘、実行環境の制限によるものでした。
AIコーディングツールのサンドボックスは何を止めているか
見分け方の前提として、代表的なツールのサンドボックスが「何を制限し、止めたときにどう振る舞うか」を押さえておきましょう。設定項目は更新が多いため、導入時点の公式資料もあわせて確認してください。
Claude Codeの場合
Anthropic社のClaude Codeでは、サンドボックスは初期状態ではオフで、「/sandbox」というコマンドや設定ファイルで有効にします。対象はAIが実行するシェルコマンド(文字で打ち込む命令)とそこから起動される処理で、ファイルの読み書きやWeb閲覧などの組み込み機能は、サンドボックスではなく許可ルールで管理されます。
- 書き込み:作業中のフォルダ、専用の一時フォルダ、追加を許可したフォルダだけ。それ以外への書き込みは拒否されます。
- 読み取り:初期状態ではパソコンの大部分を読めます。
- 通信:直接の外部接続はできず、パソコン内の中継役(プロキシ)を通ります。許可済みの接続先は最初は空で、新しい接続先が必要になると初回に確認画面が出ます。
- 止めたときの振る舞い:通信を止めた場合は、止めた接続先の名前がコマンドの結果に表示されます。AIが「サンドボックスの外で再実行したい」と判断した場合、通常の許可モードでは「Bash command (unsandboxed)」という確認画面が出ます。外での再実行を禁止する設定もあります。
仕組みはOSの機能を使っており、macOSでは「Seatbelt」、LinuxとWSL2(Windows上でLinuxを動かす仕組み)では「bubblewrap」が使われます。WSL2を使わないWindowsでは、コマンドはサンドボックスなしで実行されると説明されています。
Codexの場合
OpenAI社のCodexでは、サンドボックスの強さを3段階から選びます。「read-only」はファイルを読めるが編集やコマンド実行には承認が必要、「workspace-write」は作業フォルダ内の編集と日常的なコマンド実行ができる標準的なモード、「danger-full-access」は制限なしです。これとは別に「承認ポリシー」があり、境界を越えるときに確認を求めるか(on-request)、求めないか(never)を決めます。
公式ドキュメントでは、標準のworkspace-writeモードでは通信は設定で有効にしない限りオフで、作業フォルダの外の編集や通信が必要なコマンドには承認を求めるとされています。変更履歴を管理する「.git」フォルダなどは読み取り専用で保護されます。
どちらも「書き込み範囲」と「通信先」を制限し、境界を越えるときは確認画面で人間に判断を求めます。確認画面や「許可されていない」系のエラーはサンドボックスが働いたサイン、確認画面も出ずたまにしか起きないエラーは別の原因を疑うサインです。
本物の制限と一時的な不調を見分ける特徴
本物のサンドボックス拒否の特徴
本物の制限は、「Operation not permitted(操作が許可されていません)」「Read-only file system(読み取り専用のファイルシステム)」のように、権限そのものを否定する文言が出るのが典型です。決められた範囲の外にあるフォルダへの書き込みや、許可されていない接続先への通信など、境界線を踏み越えようとしたときに起きます。最大の特徴は、何度再試行しても同じ場所で同じように失敗することです。
一時的な通信不調の特徴
「接続が途中で切れた」「想定より少ないデータしか受け取れなかった」「時間切れ」といったエラーは、通信そのものの不調であることが大半です。再試行するとあっさり成功することが多く、成功と失敗が混ざるのが特徴です。
注意:通信エラーに見えるサンドボックス拒否もある
ややこしいのは、サンドボックスが通信を止めたときに、一見ただの通信エラーに見える文言が出る場合があることです。Claude Codeの公式ドキュメントによると、中継役を使わないツール(データベースへの接続ツールなど)は、許可済みの接続先でもサンドボックス内からは接続できず、「接続先の名前を解決できない」といった名前解決のエラーとして表れることがあります。そのため、文言だけでなく「毎回起きるか」をあわせて見ることが重要です。
エラー文の典型例(早見表)
以下は、Claude Codeの公式ドキュメントと、通信ツールcurlの公式エラー一覧で確認できた代表的な文言です。表示はツールや環境で変わるため、目安としてご覧ください。
英語の原文(例) | 意味 | 疑うべき原因 |
|---|---|---|
Operation not permitted | 操作が許可されていない | サンドボックスの制限の可能性が高い(macOSでの書き込み拒否など) |
Read-only file system | 読み取り専用の場所に書き込もうとした | サンドボックスの制限の可能性が高い(Linux・WSL2での書き込み拒否など) |
Could not resolve host | 接続先の名前を解決できない | サンドボックスの通信制限、またはネットワーク・入力ミス。毎回起きるかで判断 |
Network is unreachable | ネットワークに到達できない | Linux・WSL2でのサンドボックスの通信制限、または回線の問題 |
403(中継役からの応答) | 接続を拒否された | 許可されていない接続先への通信をサンドボックスが止めた可能性 |
Partial file / transfer closed | データの受け取りが途中で終わった | 一時的な通信不調の可能性が高い。時間を置いて再試行 |
Operation timeout / timed out | 時間切れ | 接続先の混雑や回線の不調の可能性が高い |
見分けるための実践手順
迷ったときは、次の順番で切り分けると判断しやすくなります。
- 同じ操作をもう一度試す:時間を少し置いて再実行し、成功すれば一時的な不調だった可能性が高いと判断できます。
- 確認画面が出ていないか見る:通信先の許可や「サンドボックスの外で実行してよいか」を尋ねる画面が出ていれば、サンドボックスが働いています。
- エラー文を読む:「許可されていない」「読み取り専用」など権限に関する言葉か、「接続」「時間切れ」など通信の言葉かを見比べます。英語でも、早見表の単語が含まれているかを探すだけで十分です。
- 何が止められたかを特定する:どのフォルダへの書き込みか、どの接続先への通信かを確認します。Claude Codeでは、止めた接続先の名前が結果に表示されます。
- 毎回同じ理由で失敗する場合だけ制限を疑う:ここで初めて、許可を広げるべきかを検討します。
AIとのやり取りのイメージ
AIがエラーで止まっても、すぐに「制限を外して」と指示しないことがポイントです。まず「同じ操作をもう一度試して」と伝えます。失敗が続く場合は「エラー文をそのまま見せて、何が拒否されたのか説明して」と尋ねます。そのうえで、権限に関する拒否だと分かったら「なぜこの制限が必要なのか、外すと何ができるようになるのか」を説明させ、納得してから判断します。AIに原因の仮説を言葉にさせるだけで、思い込みによる解除を減らせます。
解除しても直らない「ツールとの相性問題」
3つ目の原因が、外部の専門ツールが隔離環境の内部構造と根本的に相性が悪いケースです。この場合、制限を外しても外さなくても同じエラーで止まり続けることがあり、解除を繰り返しても解決しません。
Claude Codeの公式ドキュメントでも、サンドボックスと相性の悪い例が挙げられています。たとえば、仮想的な実行環境を作るDocker、テストツールが使う監視機能watchman、macOSで暗号化通信の確認に失敗することがあるGitHub CLIなどのツール、アプリを開く「open」コマンドなどです。特定のコマンドだけをサンドボックスの外で動かす設定(excludedCommands)も案内されていますが、外に出したコマンドは制限なしで動くため、対象は狭く絞る必要があります。
相性問題が疑われるときは、闇雲に解除を試すより早めに見切りをつけ、エラー内容を記録したうえで、人間が自分の画面で直接実行する、別のツールに置き換えるといった手段を検討するほうが早く進めます。
安易な解除が危険な理由と、解除前のチェックリスト
一度「制限を外したら直った」という経験をすると、原因を確かめる前に外す癖がつきがちです。これは、AIの誤操作を止める安全装置を自分の手で無効化する行為です。Claude Codeの公式ドキュメントも、サンドボックスはリスクを減らすものの完全な隔離ではなく、広すぎる接続先や書き込み範囲の許可は情報流出などにつながりうると注意しています。
解除を判断する前に、次の点を確認しましょう。
- まったく同じ操作を、時間を置いて再試行したか。
- エラー文に「許可されていません」「読み取り専用」など権限に関する文言が含まれているか。
- 止められたのはどのフォルダ・どの接続先か、具体的に説明できるか。
- その操作は読み取りだけか、ファイルの変更・削除・外部への送信を伴うか。
- 制限を外す範囲を、そのコマンドやその接続先だけに絞れるか。
- 過去に同じ理由で解除した記録が残っているか。
読み取りだけの操作なら、まず時間を置いた再試行を優先します。変更や送信を伴う操作なら、より慎重に原因を見極めてから判断してください。
記録とチームでの運用
実際に制限を外した場合は、「いつ、何のために、どの制限を外したか」を簡単にでも記録しておきます。記録がないと、一度きりの判断がなし崩し的に「いつもの対応」として定着してしまいます。複数人で使う場合は特に重要で、記録がないまま解除が積み重なると「なぜこの制限が外れているのか誰も説明できない」状態に陥ります。
よくある質問
エラーが英語で読めません。どうすればよいですか?
「not permitted」「denied」「read-only」が含まれていれば権限の問題、「timed out」「connection」「closed」が中心なら通信の問題、と単語を手がかりにします。AIに日本語で説明させるのも有効です。
確認画面が出たら、すぐに許可してよいですか?
確認画面は、サンドボックスが境界を越える操作を検知したサインです。どの接続先・どのコマンドを許可するのかを読み、必要なものだけを許可してください。迷ったらAIに理由を説明させましょう。
まとめ
- コマンドのエラーの原因は、サンドボックスの制限、一時的な通信不調、ツールとの相性問題の3つに分けて考える。
- Claude CodeもCodexも、書き込み範囲と通信先を制限し、境界を越えるときは確認画面で人間に判断を求める。
- 本物の制限は「Operation not permitted」など権限に関する文言が多く、何度試しても同じように失敗する。
- 通信エラーに見えるサンドボックス拒否もあるため、文言と「毎回起きるか」をセットで見る。
- 解除しても直らない相性問題は、早めに見切りをつけて別の手段を検討する。
- 解除前にチェックリストで確認し、外すなら範囲を絞って記録を残す。
