Claude Codeの許可ダイアログ｜権限の範囲を読む

「許可しますか？」——AIに作業を任せていると、この確認画面が何度も出ます。内容をよく読まずにEnterを押してしまった経験は、多くの方にあるはずです。

結論から言うと、ここで押している「はい」は「はい／いいえ」の2択ではありません。許可には「この1回だけ」「この種類ぜんぶ」「この作業ぜんぶ」という3段階の範囲があります。そして事故の多くは、AIが何をするか分からないことではなく、自分がどの段を押したのか覚えていないところから起きます。

株式会社Fyveは、AIに無人で作業をさせる仕組みを自社で運用しています。この記事では、実際に「押した段と与えた権限がズレる」不具合が直近2回の更新で複数修正された事実を公式の記録で確認したうえで、私が自分の運用でどこに線を引いているかまでお伝えします。

結論：AIの許可は「はい／いいえ」ではなく、3段階の範囲で決まる

AIに作業を任せる道具の多くは、ファイルを書き換える・コマンドを実行するといった副作用のある操作の前に、確認画面（許可ダイアログ）を出します。ここで見落とされがちなのが、選択肢が「許可する」「許可しない」の2つではないという点です。

実際には、許可を出す範囲に目盛りがあります。

許可の3段階

1段目と3段目では、与えている権限の広さがまったく違います。1段目は「この1ファイルを1回書き換えてよい」ですが、3段目は「この作業が終わるまで、書き換えについては何も聞かない」です。

それでも画面上では、どちらもキーを1回押すだけで選べます。押す手間が同じで、結果の重さが違う——これが許可ダイアログという画面の構造的な難しさです。

「目盛りを読み違えさせる不具合」が実際に起きていた

ここまでは考え方の話ですが、直近の更新で「押したつもりの段」と「実際に与えた権限」がズレる不具合が、実際に複数修正されています。

私はこれを、開発元が公開しているClaude Codeの変更履歴（GitHubのanthropics/claude-codeリポジトリのCHANGELOG）から直接確認しました。以下の引用はすべて原文のままです。

確認できた修正：2つの版で7項目

2.1.235と2.1.236という連続する2つの版に、許可のしくみに関する修正が計7項目ありました。性質で2つに分けられます。

① 承認画面が、実際に与える権限と食い違っていた（4項目）

4つ目は特に象徴的です。画面が出ていないのに、押したキーが承認になっていた——読む読まない以前に、読む対象が存在しないまま同意が成立していたことになります。

② 許可の効き方・範囲の強制に関する修正（3項目）

①が「同意の入口」の問題なら、②は「同意した後の効き方」の問題です。禁止したはずの指定が、名前を変えるだけで回避できていたという項目は、設定を書いて安心していた人ほど影響を受けます。

公開日の確定方法（変更履歴には日付が書かれていない）

実務上の注意点をひとつ。このCHANGELOGには各版の日付が書かれていません。「いつの話か」を知りたいときは、配布元の公開時刻を見るのが確実です。

npmのレジストリが各版の公開時刻を持っているので、私はそこを直接確認しました。

• 2.1.234 — 2026-08-17T18:19:13Z（日本時間 8月18日 3:19）
• 2.1.235 — 2026-08-18T18:24:10Z（日本時間 8月19日 3:24）
• 2.1.236 — 2026-08-19T18:45:14Z（日本時間 8月20日 3:45）

つまり上記の修正は、いずれもここ2日の間に配布されたものです。「バージョン番号は見たが、それがいつのものか分からない」という状況は、更新の速い道具では頻繁に起きます。配布元の公開時刻を見る癖をつけておくと、話の鮮度を自分で判定できます。

読者特典・無料ダウンロードClaudeのこの5つの設定、今すぐ見直した方がいい無料でダウンロード →↓

なぜ「押す前に読む」が効くのか

AIに仕事を任せるのが怖い、という相談をよく受けます。しかし内容を聞いていくと、不安の中身は「AIが勝手に何かをするのではないか」という漠然としたものであることが大半です。

一方で、実際に起きる事故はもっと具体的です。自分が過去に何を許可したのか把握していない状態で、許可だけが積み上がっていく。そして、いつか許可の範囲に入る操作が実行される。このとき、AIはルール違反をしていません。許された範囲の中で動いているだけです。

だとすれば、防ぎ方も「任せない」ではありません。許可の範囲を読む癖をつけることと、渡す段をあらかじめ低くしておくことの2つです。前者は今日から、後者は仕組みの設計で対応します。

そして今回の修正が示しているのは、もうひとつ重要な点です。読もうとしても読めない場面が現実に存在した——画面が出ないまま承認になる、中身が省略されたまま表示される、閉じるつもりの操作が承認になる。だからこそ、道具の側の修正を取り込むこと（＝更新を当てること）も、読む癖と同じくらい実質的な対策になります。

AIエージェントに業務を任せるときの権限設計そのものについては、別の記事で体系的に整理しています。

Claude CodeAIエージェントの権限管理｜業務導入で押さえる3層設計

「はい」を押す前に読む4つの手順

実務で使える形に落とします。難しいことはしません。押す前に増える確認は1行分です。

手順1：何に対する許可かを読む

まず、対象を見ます。「ファイルを編集していいか」ではなく、どのファイルを編集していいかです。コマンド実行なら、コマンド名だけでなく引数まで見ます。

ここで役に立つのが、今回の修正のうち「中身を全部表示できないときは『今後は聞かない』を出さない」という変更です。裏を返せば、中身が全部見えている画面でしか、広い許可は出すべきでないという設計思想が明文化されたことになります。表示が省略されている画面で広い許可を出さない——これは覚えておく価値があります。

手順2：範囲を3段階で見分ける

次に、選ぼうとしている選択肢が3段階のどれかを確認します。文言は道具によって違いますが、判定は「次に同じことが起きたとき、また聞かれるか」で見分けられます。

• また聞かれる → 1段目（この1回だけ）
• 同じ種類は聞かれない → 2段目（この種類ぜんぶ）
• 作業が終わるまで聞かれない → 3段目（この作業ぜんぶ）

迷ったら1段目を選びます。もう一度聞かれるだけで、失うものはありません。

手順3：「今後は聞かない」は中身が全部見えているときだけ押す

「今後は聞かない」は、その場の手間を減らす代わりに、将来の確認機会をまとめて放棄する選択肢です。押すなら、次の2つが揃っているときに限ります。

• いま画面に出ている中身が省略なく全部見えている
• 同じ種類の操作が今後何度も出てくると分かっている

逆に、1回しか出てこない操作に対して「今後は聞かない」を押す理由はありません。手間は変わらず、範囲だけが広がります。

手順4：出した許可がどこに記録されるかを開く

ここが最も抜けやすい手順です。多くの道具は、一度出した許可を設定ファイルに書き込んで永続化します。つまり、その場の判断が翌日以降も効き続けます。

一度でよいので、その記録を開いて自分が過去に何を許してきたかを一覧で見てください。想定より広い指定が残っていることが珍しくありません。棚卸しの結果、要らない行を消すだけでも範囲は締まります。

棚卸しの判断は、1行ごとに次の3つを聞くだけで足ります。

• いつ、なぜ許したか思い出せるか — 思い出せない行は、その時点で「読まずに押した」ものです
• 今も同じ作業を続けているか — 終わった案件のために出した許可が残っていることが多くあります
• この1行が最悪の場合に何を許すか — 「たぶん大丈夫」ではなく、範囲の端を見ます

消して困ったら、また聞かれるだけです。許可の棚卸しは、消しすぎても実害が出ない珍しい作業なので、迷ったら消す側に倒して構いません。

なお、許可の設定は「書けば効く」とは限らず、書き方によっては黙って無視されることがあります。この落とし穴は別記事で詳しく扱っています。

Claude CodeClaude Codeの権限ルールの罠｜黙って効かない指定

私の運用では、どこに線を引いているか

ここからは自社の実運用の話です。私は、AIが無人で記事を執筆し、審査を通ったものだけを自動で公開する仕組みを運用しています。人が見ていない時間に動くので、許可の設計は最初から「事故が起きても致命傷にならない形」で組んでいます。

鍵の側で段を下げる（作れるが、書き換えられない）

いちばん効いているのは、AIに渡すAPIキーの権限を必要な分だけに絞ることです。この用途のキーには、記事の読み取り・新規作成・画像アップロードだけを許可し、既存記事の更新と削除は許可していません。

この設計だと、AIが誤作動してもできるのは「余計なものを増やすこと」だけです。既存の記事を壊すことは、指示の書き間違いでも、想定外の挙動でも、構造的に起こりません。増えたものは後から消せますが、消えたものは戻せない——だから非対称なリスクの側だけを鍵で塞ぎます。

これは前述の「3段階」を、画面ではなく鍵の側で1段下げているのと同じことです。画面で正しく選ぶ努力に頼らず、そもそも上の段を選べなくしておく。運用としてはこちらのほうが確実です。

頼むだけでは守られない——境界は仕組みで強制する

もうひとつは、書き込んでよい場所の制限です。この仕組みでは、AIが書き出してよい領域を1つのフォルダに限定しています。

重要なのは、これを指示文で「ここ以外に書かないでください」とお願いしていない点です。実行を包んでいるスクリプトの側で、指定フォルダ以外への変更は保存対象から外し、次回起動時に破棄するようにしています。破棄が発生したら通知が飛びます。

この形にしたのは、過去に指示文だけで境界を守らせようとして、実際に想定外の場所へ書き込みが発生したからです。指示は守られないことがありますが、仕組みは守られないことがありません。無人運用でdeny側から設計する考え方は、別記事で詳しく書いています。

Claude CodeClaude Codeのdeny設定の書き方｜無人運用の事故防止

止まり方を設計しておくと、壊れた日に「何も起きない」

最後に、直近で実際に起きたことを書きます。

この仕組みでは、公開の前に執筆したのとは別のプロセスでAIによる審査を挟んでいます。審査に通ったものだけを公開し、審査結果が取得できなかった場合は公開せず下書きとして保存する設計です。判断できないときは公開しない、という方向に倒しています。

そして本記事を書いている2026年8月20日時点で、この審査プロセスは4日連続で認証エラーにより起動できていません。結果どうなったかというと、記事は1本も公開されず、下書きが積み上がっています。

これは運用としては明確な不具合で、認証を通し直す必要があります。ただし起きたことは「何も公開されなかった」であって、「審査を通らないものが公開された」ではありません。壊れた場所が、壊れたときに安全な側へ倒れました。

許可の設計で最終的に効くのは、この「壊れたときにどちらへ倒れるか」だと考えています。うまく動いているときの挙動は、どんな設計でも大差ありません。差が出るのは、想定していなかったことが起きた日です。

これはAI開発ツールだけの話ではない

ここまでClaude Codeの画面を例に書いてきましたが、3段階の範囲と、許可が積み上がる問題は、AIの道具に固有のものではありません。すでに全員が同じ構造の画面を毎日押しています。

同じ構造をしている身近な許可画面

とくに外部サービスの連携（OAuth）は、AIの許可ダイアログと構造が最も近いと考えています。一度押すと記録として残り続け、範囲は「読み取りだけ」から「編集・削除まで」まで幅があり、そしてほとんどの人が一度も棚卸しをしていません。

AI関連のサービスが増えるほど、この連携画面を押す回数も増えます。「AIツールを試したが結局使わなかった」というとき、使うのをやめても連携は残っています。手順4の棚卸しは、AIの道具の設定ファイルだけでなく、こちらにも同じように効きます。

逆に言えば、この記事の4手順は新しく覚えることではありません。スマホの権限画面で多くの人が自然にやっている「今回のみ」を選ぶ判断を、AIの作業画面でも同じようにやるだけです。

組織で使うなら、個人の判断に任せない層を作る

ここまでは個人が押す画面の話でした。しかし従業員がそれぞれAIの道具を使い始めると、「押す前に読む」を全員に徹底させる方法がないという問題が出てきます。

実は今回確認した修正のうち1件は、まさにこの層に関するものでした。組織側が配布する設定（managed settings）の承認画面が、起動時に表示されないまま最初のキー入力を承認として受け取っていた、という項目です。

ここから読み取れるのは、こうした道具には個人が押す許可の上に、組織が事前に決めておく層が存在するということです。実務的な意味は大きく、次のように役割が分かれます。

この分け方の要点は、いちばん危ない判断を、いちばん忙しい人に押させないことです。「機密ファイルを読ませない」「本番環境に触らせない」といった絶対に譲れない線は上の層で塞ぎ、その場の判断に残すのは、判断してよい範囲のものだけにします。

中小企業でAIの利用を広げるとき、最初に作るべきルールは「AIを使ってよい／いけない」という利用可否ではなく、この3層のどこに何を置くかの整理だと私たちは考えています。使ってよいかを議論している間にも、現場では毎日この画面が押されているためです。

よくある3つの誤解

「自動モードにしたら、許可の話は関係ない？」

関係します。むしろ自動モードのほうが、事前に出しておいた許可の範囲がそのまま効くぶん重要になります。

実際、今回確認した2.1.236の修正には、自動モードに関するものが2件含まれていました。ひとつは自動モード中に一部の事前許可をいったん脇に置いて同じ基準で判定するという変更、もうひとつは安全確認に使う状態チェックが設定次第で誤報していたという修正です。自動化した先でも、範囲の話は消えません。

承認を人が挟むこと自体の限界については、こちらで詳しく扱っています。

Claude CodeClaude Code auto modeが既定に｜承認の限界

「全部いちいち確認すれば安全では？」

これは逆効果になることがあります。確認の回数が多すぎると、内容を読まずに通す儀式になるからです。1日に何十回も同じ画面が出れば、人はそれを読まなくなります。

現実的な着地は、回数を減らして、1回あたりを本当に読むことです。そのために、頻出する安全な操作は範囲を決めて事前に許可し、危険な操作だけを確認に残す。全部確認するのではなく、確認の密度を上げます。

「設定ファイルに書いておけば安心では？」

書き方が正しければ効きます。ただし前述のとおり、書いたつもりで照合されていない指定が存在します。加えて今回の2.1.236では、読み取り禁止の指定がファイル名の変更で回避できていたという修正も入りました。

つまり、設定は「書いて終わり」ではなく効いていることを確かめる対象です。禁止したはずの操作を実際に試して止まることを確認する、という一手間が要ります。

まとめ：押す前に増えるのは1行分の確認だけ

要点を整理します。

• AIの許可は「はい／いいえ」ではなく、この1回だけ／この種類ぜんぶ／この作業ぜんぶの3段階
• 直近2回の更新で、承認画面と実際の権限が食い違う不具合が4項目、範囲の効き方に関する修正が3項目公式に修正された（日本時間 8月19日・8月20日配布）
• 押す前の確認は4つ——対象を読む／段を見分ける／中身が全部見えているときだけ広く許す／記録を開いて棚卸しする
• いちばん確実なのは、画面で正しく選ぶ努力に頼らず、鍵や仕組みの側であらかじめ段を下げておくこと
• 設計の良し悪しが出るのは平常時ではなく、壊れた日にどちらへ倒れるか

AIに任せるかどうかは、多くの場合「丸ごと渡す」か「渡さない」かの2択で語られます。しかし実際の運用では、その間にいくつもの段があります。今回、その段を読み違えさせる不具合が現実に修正されたことは、段そのものが実在するという何よりの証拠です。

私たちは、こうした権限設計から実際の運用構築まで、中小企業の現場に合わせて伴走しています。AIにどこまで任せてよいかの線引きや、無人で動かす仕組みの安全な組み方について相談したい方は、株式会社FyveのClaude Code支援サービスもご覧ください。「どこまで任せてよいか分からない」という段階からで問題ありません。