Claude Codeの作業フォルダ外の読み取り｜許可4択の意味
「AIに仕事を任せたいが、どこまで見られるのかが分からない」「作業フォルダの外を1回読ませたいだけなのに、ずっと許可することになるのではないか」——AIに作業を渡すとき、多くの方が最初にここで引っかかります。
結論から言うと、Claude Code はバージョン 2.1.284 で、作業フォルダの外を読もうとしたときの確認画面に「今回だけ許す。ただし次回も聞く」という4つ目の選択肢を追加しました。それまでは「ずっと許す」「これから塞ぐ」「次回また聞く」の3択しかなく、この1回の読み取りだけを通す手がありませんでした。
株式会社Fyveは、自社の定型業務をAIに無人で実行させる仕組みを社内で運用しています。この記事では公式の変更履歴・パッケージの公開時刻・報告側の記録を一次で突き合わせたうえで、4つの選択肢がそれぞれ何を意味するのか、そして「AIに何を見せるか」の境界をどこに引くのかを整理します。
結論：作業フォルダ外の読み取り許可は、3択から4択になった
Claude Code の auto モードは、作業フォルダ（working directories）の外にあるファイルを読もうとしたとき、確認画面を出します。2.1.284 で、この画面の選択肢が1つ増えました。
公式の変更履歴（CHANGELOG）の該当行は、次の1行です。
Added a "Yes, but ask again next time" answer to auto mode's prompt before a read outside the working directories, so you can allow that one read and still be asked about later ones
訳すと「auto モードが作業フォルダ外の読み取り前に出す確認へ『はい、ただし次回も聞く』という回答を追加した。これによりその1回の読み取りだけを許可しつつ、以降の読み取りについては引き続き確認を受けられる」となります。
4つの選択肢が、それぞれ何を決めているか
重要なのは、この画面が「今回の読み取りを通すか」と「今後の方針をどうするか」という2つの別の問いを同時に処理していることです。4つの選択肢は、この2軸の組み合わせとして整理できます。
選択肢 | 今回の読み取り | 今後の方針 | 選ぶ場面 |
|---|---|---|---|
1. ずっと許可する | 通る | 今後は聞かれない（許可で確定） | 毎日必ず読む場所が決まっているとき |
2. これから塞ぐ | 止まる | 今後は全プロジェクトで拒否（設定に書かれる） | 外を読ませる予定が一切ないとき |
3. 次回また聞く | 止まる | 未確定（次も聞かれる） | 今回は読ませたくないが方針も決めたくないとき |
4. 今回だけ許す（新） | 通る | 未確定（次も聞かれる） | この1件だけ読ませたいとき |
増えたのは4番です。1番と4番はどちらも「今回は通る」ですが、1番は将来の確認機会をまとめて放棄し、4番は放棄しません。この差は、1回のキー操作の違いに見えて、運用上はまったく別のものです。
いつ入ったのか——変更履歴には日付が書かれていない
Claude Code の変更履歴には、各バージョンの公開日が記載されていません。そのため日付は別の一次記録から取る必要があります。
私はパッケージレジストリ（npm）の公開時刻を直接参照しました。2.1.284 の公開時刻は協定世界時 2026年9月28日 17時11分59秒です。日本時間に直すと2026年9月29日 午前2時11分で、本記事の公開日と同日の未明にあたります。
この変更を「9月28日のリリース」と書いている情報を見かけたら、それは協定世界時での表記です。日本時間では日付が1日ずれます。リリース直後の記事を読むときは、どちらの時刻系で書かれているかを確認してください。
なぜ「3択」で詰まっていたのか
4つ目が追加された背景には、3番目の選択肢が抱えていた問題があります。ここは公式の変更履歴には書かれていないため、報告側の一次記録を見る必要があります。
「次回また聞く」は、先送りではなく拒否だった
公式リポジトリに 2026年9月23日（日本時間）、この確認画面についての不具合報告が起票されています。ラベルは bug、has repro（再現手順あり）、area:permissions。報告者の環境は CLI 2.1.272、macOS、auto モードです。
報告の中心はこの一点です。3番目の「No, ask again next time」は、言葉の上では「今は決めない、また後で聞いて」と読めるのに、実際には今回の読み取りも拒否していた。報告者はこの選択肢を同じセッション内で3回選び、3回とも読み取りが通らなかったと記録しています。
そのとき AI 側が受け取るのは「ユーザーは作業フォルダ外のこの読み取りを許可しませんでした」という拒否の通知です。つまりユーザーは「保留」を押したつもりで、実際には「却下」を押していたことになります。
そして報告書はこう指摘しています。「この1回の読み取りを、全体方針を決めずに許可する選択肢が存在しない」。読み取りを完了させる道は1番（＝ずっと許可）しかなく、それは方針の恒久的な確定を伴う——だから「怖いので塞ぐ」か「仕方なく全部許す」の二択に追い込まれていたわけです。
同じ画面の中で、説明と挙動が食い違っていた
報告にはもう1つ、見落としやすい指摘があります。この確認画面の説明文自身が「auto モードとサンドボックスは作業フォルダの外を確認なしで読む」と書いているのに、実際にはその読み取りが確認待ちで止まっていた、という点です。
同じ画面の中で「既定は許可」と書きながら、挙動は「方針が決まるまで拒否」になっていた。読者が画面の文言を信じて操作すると、必ず期待と結果がずれます。
公式が「直した」と書いているのは、4つ目の追加だけ
ここは正確に書く必要があります。報告書が求めていた対応は2つでした。①3番目の表示を実際の挙動に合わせて書き直す（「この読み取りを拒否し、次回また聞く」とする）②「この読み取りだけ許可」という4つ目を用意する。
2.1.284 の変更履歴に書かれているのは、このうち②だけです。3番目の表示を直したという記述はありません。そしてこの報告は、本記事の執筆時点で未解決（open）のままです。
したがって「報告から6日で公式が修正した」とまとめるのは、事実より1歩踏み込みすぎです。正確には、報告から約5日20時間後に、報告が求めた2点のうち1点にあたる変更が入った——そして公式の記録は、その変更とこの報告を結びつけてはいません。時期が重なっているだけです。
実務上の含意は小さくありません。3番目の選択肢は、今もラベルと挙動がずれている可能性があります。押すなら「これは拒否だ」と理解して押してください。「保留」だと思って押すと、AI の作業はそこで止まります。
読み取りの境界は、一度では入らなかった——27日間で8つの変更
この確認画面の話は、実は「新機能が1つ増えた」という話ではありません。作業フォルダ外の読み取りを止める仕組みそのものが、入ってから1か月のあいだに繰り返し直され続けてきた——その最新の1手が4つ目の選択肢です。
私は公式の変更履歴の全文を対象に、この機能の設定キー名と「作業フォルダの外」に言及する行を洗い出しました。日付はすべてパッケージレジストリの公開時刻から日本時間に直したものです。
版 | 公開（日本時間） | 内容 | 種別 |
|---|---|---|---|
2.1.257 | 2026-09-02 | 境界が入った。auto モードで最初に作業フォルダ外のファイルを読む前に1回だけ確認を出し、以後の読み取りを塞ぐ選択肢を用意した | 追加 |
2.1.260 | 2026-09-04 | macOS で、塞ぐ設定が必要なものまで隠していた（サンドボックス内の git から利用者の git 設定が見えない／作業コピーを分離したサブエージェントが自分の作業コピーを見られない） | 修正 |
2.1.269 | 2026-09-12 | シェルコマンド経由の書き出し先の抜け。出力を複製して保存するコマンドの宛先に書き込みチェックが効かず、その許可が作業フォルダ外の宛先までカバーしていた | 修正 |
2.1.271 | 2026-09-15 | すり抜け①。ディレクトリ移動を2回含む・サブシェルを含む・移動とコマンドを連結したシェルコマンドが、確認を飛ばしていた | 修正 |
2.1.273 | 2026-09-16 | すり抜け②。権限チェッカーが完全に解析しきれないシェルコマンドが、確認を飛ばしていた | 修正 |
2.1.273 | 2026-09-16 | すり抜け③。設定で指定された記憶用ディレクトリが、塞ぐ設定を有効にしていても読み込まれ・想起され・索引され・記憶の抽出に使われていた | 修正 |
2.1.281 | 2026-09-24 | 組織が配布するポリシーの側から、この設定を管理できるようになった（利用者の判断に任せない層ができた） | 追加 |
2.1.284 | 2026-09-29 | 「今回だけ許す」が4つ目の選択肢として入った | 追加 |
27日間で修正5件・追加3件（境界の導入を含む）。この並びから読めることは3つあります。
読めること①：直しの中身は、ほぼ全部「すり抜けの塞ぎ」だった
5件の修正のうち3件（2.1.271・2.1.273 の2件）は、いずれも「止めるつもりだったのに止まっていなかった」類のものです。しかも抜け道の形が具体的です。ディレクトリ移動を2回はさむ、サブシェルで包む、コマンドを連結する、解析しきれない書き方をする——境界を宣言しただけでは、その周りを回る道が残っていたということです。
これは AI 固有の話ではありません。入力を検査して弾く仕組みは、検査の網の目をすり抜ける表現が必ず後から見つかります。境界は、作った時点が完成ではなく、運用しながら穴を塞ぎ続ける対象です。
読めること②：塞ぎすぎると仕事が止まる、も同時に起きていた
見落としやすいのが 2.1.260 の修正です。これは「すり抜け」ではなく逆方向の事故——塞ぐ設定が、業務に必要なものまで隠してしまっていたケースです。
境界を厳しくすると「必要なのに見えない」が起きます。そして「見えない」は、たいていはっきりしたエラーではなく、静かな不調として現れます。設定が読めていない、記録が参照できていない、といった形です。だから境界を締めた直後は、締めたことで何が見えなくなったかを確認する工程が要ります。
読めること③：だから境界は1枚では持たない
ここが実務上いちばん大事な結論です。読み取りの境界を1枚の設定に賭けると、その1枚に穴が空いた日に何も残りません。27日で5回直されたという事実が、1枚に賭けるリスクの実測値です。
私の運用では、この種の境界を「ツールの設定」「実行を包む仕組み」「そもそも置き場所を分ける」の3層で持っています。詳細は後述します。
なお「塞ぐ側」の書き方そのものについては、別記事で詳しく扱っています。
なぜ「読み取り」は、書き込みより軽く見られるのか
ここまで読んで「読むだけなら害はないのでは」と感じた方もいるはずです。実際、権限の設計は「書き換える」「コマンドを実行する」「外部と通信する」といった副作用のある操作に注意が向きがちです。読み取りには副作用がないので、優先度が下がります。
しかし、機密という観点では逆です。情報が外に出るのは、書かれた瞬間ではなく読まれた瞬間です。読み取りは元のファイルを1文字も変えませんが、その中身は AI に渡る文脈に載り、以降の応答の材料になります。書き込みは「戻せる」ことが多いのに対し、読まれたという事実は取り消せません。
だから「AIに何をさせるか」を設計しているだけでは足りません。並べて「AIに何を見せるか」を設計する必要があります。作業フォルダの外にあるものほど、この問いの対象になります。ホームディレクトリ配下には、たいてい各種ツールの設定ファイル、認証情報、個人的なメモ、別の仕事のファイルが同居しているからです。
報告に残っていた、読み取りと書き込みの非対称
先ほどの不具合報告には、本題の脇にもう1つの観測が記録されています。同じセッション内で、作業フォルダの外に新しいファイルを2つ作る操作は、確認画面が一切出ずに通ったというものです。読み取りは全体方針の決定を求められて止まるのに、書き出しは静かに通った、という非対称です。
ここは慎重に扱ってください。これは 2.1.272 の時点での観測であり、現在の版で同じかどうかは私も確認していません。この記事を書いている環境の Claude Code は 2.1.209（日本時間 2026年7月14日公開＝77日前）で、4つ目の選択肢も入っていません。手元で再現して確かめたわけではないので、断定はしません。
それでも、この観測から引き出せる問いは有効です。あなたの環境で「読み取りは確認される」ことを確認したとして、「書き出し」はどうなっていますか。確認が出る操作だけを見て安心すると、確認が出ない側が見えなくなります。
私の運用では、境界をどう持っているか
ここからは自社の運用です。私たちは定型業務の一部を、人が見ていない時間帯に AI に実行させています。この仕組みを作るときに決めたことを、3層に分けて書きます。
第1層：書き出してよい場所を、実行を包む側で強制する
無人で動かす仕組みでは、AI が書き出してよい領域を1つのフォルダに限定しています。重要なのは、これを指示文で「ここ以外に書かないでください」とお願いしていない点です。
実行を包んでいるスクリプトの側で、指定フォルダ以外への変更は保存の対象から外し、次回起動時に破棄します。破棄が起きたら通知が飛びます。この形にしたのは、以前に指示文だけで境界を守らせようとして、想定外の場所への書き込みが実際に起きたからです。
指示は守られないことがありますが、実行を包む仕組みは迂回されません。
第2層：しかし、この層は読み取りを止めない
そして今回の話が刺さるのがここです。「書き出しを1フォルダに閉じる」という守りは、読み取りには一切効きません。保存の対象を絞るという発想は、出ていくものを見ているので、入ってくるものを見ていないのです。
つまり私の第1層は、境界の半分しか作っていませんでした。作業フォルダ外の読み取りに確認が入る仕組み（2.1.257 以降）と、その1回だけを通せる選択肢（2.1.284）は、ちょうどこの空いていた半分に対応します。だから今回の変更を「地味な選択肢追加」として流すわけにはいきませんでした。
第3層：見せてはいけないものを、4分類で先に決めておく
3層目は設定でもスクリプトでもなく、判断の基準です。私たちは「これは外に出さない」という対象を、公開物を作るすべての工程が参照する1枚の規範として持っています。分類は4つです。
- 取引先が特定できるもの：社名・サイト・案件金額・担当者名。業種と地域の組み合わせで特定できてしまう書き方も含みます
- 自社の未公開の数字：売上・顧客数・未発表の計画
- 認証情報と内部の構造：APIキー・トークン・端末の識別子・内部のファイルパス・環境変数の中身
- 第三者の個人情報：本人以外の実名・連絡先
この4分類を持っている意味は、「読ませてよい場所」を判断するときの基準になることです。AI に見せる範囲を広げるかどうかを、そのつど感覚で決めずに済みます。そして分類のうち機械で判定できるもの（認証情報の形・内部パスの形・連絡先の形）は、人の目に頼らず自動で検出するようにしています。
AI に渡す機密を環境変数の側で分離する考え方は、別記事で扱っています。
4択を使い分ける——今日から組める手順
ここまでの整理をふまえて、実際の運用手順に落とします。
手順1：まず版を上げる
4つ目の選択肢は 2.1.284 以降にしか存在しません。これが第1段です。先ほど書いたとおり、この記事を書いている環境は 2.1.209 で、77日分の更新が入っていません。手元の版を確認して、古ければ更新してください。
確認画面に選択肢が3つしか出ないなら、版が古いということです。その状態では「今回だけ」は選べないので、後述の手順3は成立しません。
手順2：「ずっと許可」に入れていい場所の条件を決める
1番（ずっと許可）は、将来の確認機会をまとめて放棄する選択です。押してよいのは、次の3つが揃うときだけにしています。
- 毎日必ず読む場所である（1回しか読まないものに恒久の許可を出す理由はありません。手間は変わらず、範囲だけ広がります）
- その場所の中身を自分が把握している（何が入っているか分からない場所に恒久の許可は出せません）
- 上の4分類に該当するものが入っていない（認証情報や取引先の資料が混ざる場所は対象外）
この3条件を通る場所は、実際にはかなり少ないはずです。少ないのが正常です。
手順3：既定の反射を「今回だけ」にする
4番が入ったことの実務的な意味は、迷ったときの既定手が用意されたことです。従来は迷ったときの安全側（3番）を押すと作業が止まってしまい、作業を進めるには恒久の許可を出すしかありませんでした。今は「今回だけ通して、方針は持ち越す」が選べます。
私は「1件ずつ判断する」を既定にして、同じ場所が3回以上出てきたら手順2の3条件に照らすという運用にしています。3回出てくる場所は定常的に必要な場所なので、そこで初めて恒久の許可を検討する、という順番です。
手順4：塞ぐと決めたら、その場の操作で終わらせず設定に固定する
2番（これから塞ぐ）を選ぶと、その判断は設定ファイルに書き込まれ、全プロジェクトに効きます。逆に言えば、設定ファイルを直接書けば、確認画面を待たずに最初から塞げます。
対象の設定キーは permissions.blockReadsOutsideWorkingDirectories です。無人で回す仕組みや、機密を扱う作業では、この設定を最初から入れておくほうが確実です。その場の判断に頼らず、選べる選択肢そのものを減らしておくという考え方です。
なお 2.1.281 以降は、組織が配布するポリシーの側からこの設定を管理できます。複数人で使うなら、個人の操作に任せない層をここに置くのが筋です。
手順5：月1で「ずっと許可」に入れた場所を見直す
恒久の許可は、出した瞬間だけでなく、その後もずっと効き続けます。だから出した許可がどこに記録されているかを開いて確認する工程が要ります。私は月1回、設定に溜まった許可を読み直しています。
見直すときの問いは1つでよいです。「この許可を今日はじめて出すとして、出すか」。出さないなら消します。
確認画面そのものの読み方——今どの段を押そうとしているのかを見分ける方法は、別記事で詳しく扱っています。
同じ版で「いくら使ったか」も見えるようになった
2.1.284 には、権限とは別系統ですが、同じ「把握」の話につながる変更がもう1つ入っています。使った金額が、金額そのものとして表示されるようになりました。
公式の記述では、利用量の確認画面とステータス行に「今月の利用額／上限額」の形でドル額が出るようになり、ステータス行の利用制限の情報にも、使用額・上限額・対象期間の3項目が追加されています。
従来は上限に対する割合の表示が中心で、いくら使ったのかは自分で換算する必要がありました。金額が直接出るようになると、「高かった日に何をしていたか」を後から照合できます。
ただし条件があります。公式の記述は「ゲートウェイがこの版以降で動いている場合」という限定を明示しています。組織の共通基盤を経由して使っている場合は、手元の版を上げただけでは出ない可能性があります。出なければ基盤側の版を確認してください。
権限と費用を並べると、AIに任せる範囲の設計は「何を許し、いくら払っているか」という1つの問いになります。どちらも、見えていなければ判断できません。今回の版は、その両方を少しだけ見えるようにした版でした。
よくある質問
Q1. 「今回だけ許す」を選ぶと、次に同じファイルを読むときも聞かれますか
はい。公式の記述は「その1回の読み取りを許可しつつ、以降の読み取りについては引き続き確認を受けられる」としています。方針を確定させないのがこの選択肢の役割なので、次も確認が出ます。同じ場所が何度も出てくるなら、それは恒久の許可を検討する合図です。
Q2. 3番目の「次回また聞く」は、もう使わなくてよいですか
使う場面はあります。「今回は読ませたくないが、今後を塞ぐとまでは決めたくない」ときです。ただし本記事で触れたとおり、この選択肢はラベルが「保留」に見えて実際は「拒否」です。押すと AI の作業はそこで止まります。作業を続けたいなら4番です。
Q3. 作業フォルダの外を読ませないと、仕事になりません
その場合は、読ませたい場所を作業フォルダに加えるのが本筋です。境界の外から都度読ませ続けるよりも、「この仕事の作業範囲はここまで」と宣言してしまったほうが、範囲が明示的になります。境界の外に対する例外を積み上げると、最終的に境界がなくなります。
Q4. うちは非エンジニアです。設定ファイルを触るのは不安です
設定ファイルを書かなくても、確認画面の4択を使い分けるだけで実務は回ります。覚えることは1つで、迷ったら「今回だけ」を押すです。恒久の許可（1番）と恒久の拒否（2番）は、判断に自信があるときだけにしてください。
Q5. 読み取りを塞ぐと、AIの精度が落ちませんか
落ちる場合はあります。本記事で挙げた 2.1.260 の修正は、まさに「塞いだことで必要なものまで見えなくなった」事例でした。だから締めたあとに何が見えなくなったかを確認する工程を入れてください。締める・測る・調整する、の順です。一度締めて放置するのがいちばん危ないです。
Q6. 組織で複数人が使っています。全員に同じ設定を守らせられますか
2.1.281 以降、組織が配布するポリシーの側からこの設定を扱えます。個人の操作に任せない層を作れるということです。全員に「気をつけてください」と伝えるより、選べる選択肢を先に減らすほうが確実です。これは AI に限らず、権限設計の一般原則です。
Q7. この記事の内容は、手元で検証されていますか
いいえ。正直に書きます。この記事の環境は 2.1.209 で、4つ目の選択肢は入っていません。書いているのは「公式の変更履歴・パッケージの公開時刻・公開された不具合報告という一次記録から読み取れること」であり、「押してみたらこう動いた」ではありません。挙動の細部は、更新後にご自身の環境で確認してください。
まとめ
作業フォルダ外の読み取り許可は、2.1.284 で3択から4択になりました。増えたのは「今回だけ許して、方針は持ち越す」という選択肢で、これは怖さを1回分に分割できるようになったということです。
実務として押さえるのは次の5点です。
- 4択は「今回通すか」と「今後どうするか」の2軸。1番と4番の差は将来の確認機会を放棄するかどうか
- 3番目はラベルが「保留」に見えて挙動は「拒否」。報告は未解決のままで、表示が直ったとは書かれていない
- この境界は27日で5回直されている。すり抜ける書き方が次々見つかった。1枚の設定に賭けない
- 締めすぎる事故も同時に起きていた。締めたあとに何が見えなくなったかを測る
- 読み取りは取り消せない。「何をさせるか」と並べて「何を見せるか」を設計する
そして今回いちばん効いたのは、自分の守りの穴が見えたことでした。無人で回す仕組みで書き出しは実行を包む側で強制していたのに、読み取りは何も見ていなかった。境界は出ていくものと入ってくるものの両方で持たないと、半分しか作っていないことになります。
株式会社Fyveは、AIに業務を任せる範囲の設計と、その境界を仕組みとして強制する実装を、自社で運用しながら検証しています。
Claudeのこの5つの設定、今すぐ見直した方がいい
共有・学習・入力・権限・委任。事故が起きるのはこの5つだけ（全28ページ）
2026年7月、Claudeの共有チャットがGoogle検索から読める状態になっていました。原因は設定そのものではなく、自分が過去に共有したものを覚えていないことでした。共有リンクの棚卸しから、学習をオフにしても残る例外条項、Claude Codeの権限モードまで、今日30分で確認できる形にまとめています。
- 見落としやすい共有リストは3つある（3つ目は画面の下）
- 学習をオフにしても残る、公式の例外条項
- 権限モード6つの違いと、Shift+Tabでの切り替え方
- 私が実際に禁止しているコマンド23行を全文公開
メールアドレス登録で他にも様々な資料を閲覧できます
＋8PDF 17点・合計440ページ ＋ すぐ使えるzip素材 3点
どれも登録後の受け取りページから、まとめてダウンロードできます。
毎週配信の無料ニュースレター「AIネイティブ超研究」の購読特典です。メール登録後すぐ、受け取りページのご案内が届きます。そこにはこの資料に加えて、過去の特典もすべてまとめて置いてあります。あわせて、AI活用に関するお知らせやお役に立てそうなご案内をお送りすることがあります。解除はいつでも1クリック。
御社の業務に合わせたClaude Code導入支援
「AIツールを導入したが、現場で使われない」を終わらせる。
業務課題のヒアリングから設計、ハンズオン実践、運用定着まで一貫して支援します。