1. はじめに：便利な道具ほど「どこまで任せるか」が問われる

第4回までで、Claude Codeを使い始めるためのフォルダ、ターミナル、Gitという土台を整えました。第5回となる本記事は、第2章（事前準備と安全）の真ん中にあたります。テーマは、Claude Codeに対する権限管理です。

Claude Codeは、コードベースを読み、ファイルを編集し、コマンドを実行できるエージェント型のAIです。利用形態は一つではなく、ターミナル（CLI）、VSCodeやJetBrainsなどのIDE拡張、デスクトップアプリ、ブラウザ版（claude.ai/code）など複数の入り口が用意されています。動作する場所も、自分のパソコンに限らず、クラウド上のサンドボックス環境を経由するケースまで広がりつつあります。

どの利用形態でも共通しているのは、Claude Codeが「指示を受けて、実際にファイルやコマンドに作用する」という点です。これは便利さの源泉であり、同時にリスクの源泉でもあります。AIに「この変更を進めていいですか」と毎回聞かれるのが面倒だからと、何も考えずに承認を押し続けると、ある日、意図しないファイルが書き換わったり、消えていたりすることが起こり得ます。

本記事では、Claude Codeに用意されている権限モードと、設定ファイルでの細やかな許可・拒否の仕組みを、Python経験者の非エンジニア向けに整理します。AIにどこまで操作を許すかを、自分の意思で選べるようになるのがゴールです。なお、操作例はCLI（ターミナル）版を前提に示しますが、権限モードとsettings.jsonという土台の考え方は、IDE拡張やデスクトップアプリでも基本的に共通です。

2. この記事のゴール

本記事を読み終えると、次のことができるようになります。

• Claude Codeの主な権限モード（default、acceptEdits、plan、auto、bypassPermissions）の違いを説明できる
• Shift+Tab で権限モードを切り替えられる
• /permissions コマンドで現在のルールを確認できる
• settings.json の allow／deny／ask ルールの考え方を理解する
• 研究・教育・医療業務での安全な初期設定の方針を持てる

なお、本記事はClaude Codeの権限管理の「考え方」を整理することを主眼とします。具体的な仕様・コマンド名・既定値は短期間で更新されます。実際に設定する前に、必ず公式ドキュメントで最新情報を確認してください。

3. 権限管理がなぜ重要か：AIに任せた一行が、戻れない結果を生む

Claude Codeはファイル編集とコマンド実行ができる、いわゆるエージェント型のAIです。チャット欄で対話する通常のClaude（Web版）や ChatGPT と決定的に違うのは、出力がテキストで終わらず、実際に作業環境に変更を加えられる点にあります。

具体的には、Claude Codeは指示に応じて、ファイルの新規作成、既存ファイルの編集、フォルダの作成・移動・削除、シェルコマンドの実行、外部ツールの呼び出しなどを行えます。便利な反面、誤った操作が一度走ってしまうと、Gitでコミットしていなければ復元が難しい変更も発生します。

実際、権限プロンプトをすべて無効化するモードを使った場合に、意図しないファイル変更を経験した利用者が一定数いることが指摘されています。これは「AIが悪意を持って動いた」というよりも、「指示の解釈ずれ」「想定外のコマンド実行」「セッション乗っ取り」など複数の要因が重なって起こる、現実的なリスクです。

権限管理の目的は、AIを縛り上げて使いにくくすることではありません。どこを自由に任せ、どこで一度立ち止まらせるかを自分で設計し、事故の入り口に蓋をしておくことです。

4. 5つの権限モード：何を自動で許し、何を聞き返すか

Claude Codeには複数の権限モードがあります。公式ドキュメントの表記をもとに、現時点で覚えておきたい5つを整理します。本記事執筆時点（2026年6月）の表記であり、最新の仕様は公式の「Choose a permission mode」ページを参照してください。

4.1. defaultモード：標準。慎重に聞き返す

既定の権限モードです。ファイルの書き込み（編集・新規作成）や、シェルコマンドの実行のたびに、ユーザーに承認を求めます。読み取りは原則として自由に行えますが、書き換えや実行は一つひとつ確認するという、最も保守的な振る舞いです。

学習を始めたばかりの方、機密性の高いコードを扱う場面、AIの提案の方向性にまだ自信が持てない場面では、このモードを使い続けるのが安全です。

4.2. acceptEditsモード：作業ディレクトリ内の編集を自動承認

作業ディレクトリ（およびadditionalDirectories設定で追加したフォルダ）の中でのファイル作成・編集を、いちいち聞かずに進めるモードです。あわせて、mkdir、touch、rm、rmdir、mv、cp、sed といった、ファイル操作系のコマンドも自動承認の対象に入ります。一方で、自動承認の対象外となるパス（保護パスや作業範囲の外）への書き込み、ネットワーク通信を伴うコマンドなどは、引き続き個別の承認を求められます。

進む方向が固まったあとの定型的な編集作業や、テストを書き足していくフェーズで使うと、リズムよく作業を進められます。

4.3. planモード：書かずに、計画だけ出させる

Claude Codeにコードベースを読ませ、提案する変更内容の「計画」だけを出させるモードです。ファイルの読み込みや、シェルコマンドによる探索は行いますが、ソースを書き換えることはしません。

大きな変更を始める前に「まず計画を見たい」という場面で重宝します。AIの理解が自分の意図と合っているかを、実際の編集を始める前に確認できます。第14回（小さなPythonアプリ開発）でも、最初のステップでこのモードを使う前提で進めます。

4.4. autoモード：別のAIが事前にチェックして自動承認

比較的新しく追加された、自動承認の中間的なモードです（公式ドキュメント上では現時点でも研究プレビュー、research previewとして提供されています）。Anthropic Engineeringの公開情報によれば、承認が必要な操作が走る直前に、別のClaudeモデル（執筆時点ではClaude Sonnet 4.6）が分類器（classifier）としてその操作を評価し、安全と判断されたものだけを自動承認します。プロンプトをすべて飛ばすbypassPermissionsとは違い、各操作にチェックの一段が挟まる点が特徴です。

対象プランはMax・Team・Enterpriseで、Free・Proプランでは利用できません。Team・Enterpriseでは、利用者がオンにできるようになる前に管理者が有効化する操作を行う必要があります。これらの条件や仕様は変わり得るため、利用前に必ず公式ドキュメントで現状を確認してください。

4.5. bypassPermissionsモード：すべての承認を飛ばす

すべての権限プロンプトと安全チェックを無効化し、Claude Codeに完全自動で動かせるモードです。CLIフラグとしては --dangerously-skip-permissions として知られています。名前のとおり「危険を承知で承認を飛ばす」という位置づけです。

このモードでは、AIの解釈違いやプロンプトの誘導によって、意図しないファイル削除・上書き、外部ネットワークへの送信、認証情報の露出といった事故が起こり得ます。起動のたびに警告ダイアログが表示されるのは、この危険性を踏まえてのことです。

業務・研究用の実環境で常用するモードではありません。利用する場合は、Dockerコンテナ・隔離されたVM・CIパイプラインなど、ホスト環境を傷つけない閉じた場所に限定するのが妥当です。本シリーズの読者層であれば、当面は「使わない」が標準的な選択です。

5. Shift+Tabでモードを切り替える：いま自分がどのモードかを意識する

Claude Codeのセッション中は、Shift+Tabを押すたびに権限モードが順番に切り替わります。標準の循環は次のとおりです。

• default → acceptEdits → plan → default …

autoモードは、利用条件を満たすアカウントで初めてShift+Tabを押したときに、組み込みの確認ダイアログを経て循環に追加されます。bypassPermissionsは、明示的に --permission-mode bypassPermissions もしくは --dangerously-skip-permissions（両者は等価で、即座にこのモードで起動する）といったフラグで起動した場合にだけ、循環に現れます。なお、--allow-dangerously-skip-permissionsというフラグもあり、こちらはbypassPermissionsを循環の選択肢として追加するだけで、起動時点では有効化されません。いずれにせよ、意図的にそのモードを選んだときにしか入らない設計になっています。

大切なのは、いま自分がどのモードでAIとやり取りしているかを意識することです。重要な変更を始める前に、画面表示で現在のモードを確認する癖をつけてください。「いつの間にかacceptEditsになっていて、確認なしに次々書き換えられた」という事故は、ほとんどがこの意識のズレから生まれます。

5.1. /permissionsとsettings.json：細やかなルールで設計する

モード切り替えは「ざっくりした方針」を決める仕組みです。一方で、具体的に「このコマンドだけは自動で許す」「このコマンドは必ず聞き返す」「このコマンドは絶対に通さない」というルールも、自分のプロジェクトに合わせて設定できます。これを担うのが、/permissionsコマンドと settings.jsonです。

5.2. /permissionsで現状を可視化する

Claude Codeのセッション中に /permissions と入力すると、いま有効になっているルールの一覧、現在のモード、各ルールがどの設定ファイルから来ているかが表示されます。設定が増えてきて「なぜこのコマンドが自動承認になっているのだろう」と迷ったときは、まず/permissionsで全体像を確認します。

5.3. settings.jsonのallow／deny／ask

具体的なルールは、settings.jsonのpermissionsセクションで定義します。骨組みはこのような形です。

{
  "permissions": {
    "defaultMode": "default",
    "allow": [
      "Bash(git status)",
      "Bash(git diff)",
      "Bash(pytest:*)"
    ],
    "deny": [
      "Bash(rm -rf:*)",
      "Bash(curl:*)"
    ],
    "ask": [
      "Bash(git push:*)"
    ]
  }
}

意味は名前のとおりです。allowに書いたものは確認なしに通り、denyは問答無用で止め、askは毎回確認を求めます。

記法はツール名(指定子)の形を取ります。Bashだけと書くとすべてのBashコマンドが対象になり、Bash(npm install)のように書けばその完全一致だけ、Bash(npm run:*)のようにコロンと*を組み合わせれば前方一致のワイルドカードとして働きます。

6. 評価の優先順位はdeny＞ask＞allow

ルールが競合した場合、優先順位はdeny＞ask＞allowの順です。denyはあらゆるallowを覆し、絶対に通させない壁として働きます。たとえば、ユーザー設定でBashすべてをallowにしていても、プロジェクト設定でBash(curl:*)をdenyに入れておけば、そのプロジェクトではcurlは通りません。

この「拒否優先」の仕組みは、安全側に倒して使うときに非常に有効です。「面倒だから全部allowにしておこう」と考えるよりも、「危ない種類のコマンドだけdenyにしておく」方が、事故の確率を確実に下げられます。

7. 設定の階層：どこに書いたルールがどこで効くか

Claude Codeの設定は、複数の場所に分かれて存在します。本記事執筆時点（2026年6月）では、優先度の高い順に次の五階層です。

• Managed（組織管理）：所属組織のIT部門がMDM等で配布する設定。利用者は上書きできない最上位
• CLIフラグ：claude起動時に渡すコマンドラインオプション（例：--permission-mode plan）
• Local（ローカル）：.claude/settings.local.json。プロジェクト内に置く個人設定で、既定でGitの追跡対象外
• Project（プロジェクト）：.claude/settings.json。プロジェクトに置き、Gitでチーム共有する設定
• User（ユーザー）：~/.claude/settings.json。自分のホーム配下に置く、全プロジェクト共通の個人設定

同じ項目が複数階層で指定された場合、原則として上位が下位を上書きします。Managedはあらゆる下位設定を覆す最上位であり、利用者側の--permission-modeなどのCLIフラグでさえ無効化される設計です。ただし権限ルールの配列（allow／deny／ask）は例外で、各階層の内容が合成（マージ）されて評価されます。上位で許可されたコマンドが下位で拒否されていれば、優先順位ルールに従って結局拒否されます。

非エンジニア向けの実用的な使い分けとしては、まず日常的に意識するのはLocal・Project・Userの三層です。~/.claude/settings.jsonに「すべてのプロジェクトで通したい安全側のdeny」を置き、プロジェクト固有のルールは.claude/settings.json（チームで共有する場合）または.claude/settings.local.json（自分のマシンだけに置きたい場合）に分けて書くのが基本です。組織のPCを使っている場合は、Managed設定の存在を頭の片隅に置いておくと、「なぜか自分の設定が効かない」という事象の原因に早く気づけます。

8. 研究・教育現場での初期設定の方針

ここまでの仕組みを踏まえ、ファーマAIラボの読者層（薬剤師・薬学研究者・大学教員等）を想定した、初期設定の方針を整理します。あくまで一例として捉え、所属機関のポリシーと合わせて調整してください。

• 標準モードはdefaultのまま運用する：少なくとも最初の数週間は、毎回の確認プロンプトに付き合う。確認を「読むべきもの」として扱う癖をつける
• bypassPermissionsは使わない：研究・教育・業務に使う環境で常用するメリットより、事故のリスクが大きい
• ユーザー設定で危険なコマンドをdenyに入れる：例としてBash(rm -rf:*)、Bash(curl:*)、Bash(wget:*)、Bash(sudo:*)など、復元困難・外部実行・管理者権限のたぐい。なお、Bashルールの記法はサブコマンド単位で評価されるため、パイプ（|）や&&を含む複合パターンは使わず、コマンドごとに分けて書きます
• 複合コマンドでの抜け道を意識する：cd:*のような汎用コマンドをallowに入れると、cd ... && rm -rf ...のような連結でdenyを回避できる挙動が報告されています。最終的には「自動承認に頼り切らず、危険操作のたびに人間の判断を残す」のが本筋です
• 外部送信系のコマンドはaskにする：git push:*などは自動承認にせず、毎回内容を確認してから進める
• 機密データのフォルダではClaude Codeを起動しない：第4回で扱った「起動するフォルダ＝AIの作業対象」という原則を、権限管理と組み合わせて運用する

組織として一律にbypassPermissionsを禁止したい場合は、Managed設定（IT部門が配布する管理者設定）のpermissionsセクションに"disableBypassPermissionsMode": "disable"を入れる手段が公式に用意されています。これを入れると、bypassPermissionsモードと--dangerously-skip-permissionsフラグの双方が無効化されます。研究室や所属機関でClaude Codeの利用ルールを策定する際は、選択肢のひとつとして検討する価値があります。

具体的なAPIキー・個人情報・研究データの守り方は、次回（第6回）で集中的に扱います。本記事の段階では、「権限モードとsettings.jsonで、AIにどこまで任せるかを設計できる」という認識を持っていれば十分です。

9. よくあるつまずきとその対処

権限管理を始めるときに、多くの方がつまずく点を挙げておきます。

• 承認プロンプトを読まずに押してしまう：プロンプトの内容（実行されるコマンド、対象ファイル、想定される変更）を一度読む癖をつけます。読まずに承認するのは、紙の同意書にサインする前に内容を確認しないのと同じです
• 気づかぬうちにacceptEditsになっている：Shift+Tabは気軽に押せるショートカットです。重要な操作の前に、画面上の現在モード表示を一度確認します
• ルールを書いたのに効かない：/permissionsでルールの出所と評価順を確認します。複数階層の設定が合成された結果、denyが勝っているケースが大半です
• ワイルドカードの書き方で迷う：完全一致のBash(npm install)と、前方一致のBash(npm run:*)の違いを意識します。「自動で許してよい範囲はどこまでか」を明文化することが、設計の出発点になります

これらは、すべて「いま自分がどの権限で、何を許しているか」を意識できれば自然と回避できる類のつまずきです。最初は手間に感じても、土台が固まれば後の作業がずっと楽になります。

10. 薬剤師・研究者にとっての「権限」の感覚

薬剤師業務には、調剤・監査・服薬指導といった工程ごとの確認ステップがあり、誰がどこまで判断できるかが明確に決まっています。研究現場でも、データの取扱権限・実験操作の承認・倫理委員会の審査といった、段階的な権限設計が存在します。Claude Codeの権限モードとsettings.jsonは、これと同じ構造を、AI操作に対して持ち込む仕組みです。

たとえば、患者情報や未公開研究データが含まれるフォルダで、何の制限もなくAIにファイル編集を許すのは、無資格者に薬歴へのフルアクセスを与えるようなものです。逆に、すべての確認を手作業で行うのは、定型作業の効率化という本来の目的を損ないます。「何を自動化し、何を人間の判断に残すか」を、薬剤師・研究者としての感覚で設計する。これが、AIを業務に取り込むときに本当に問われる力です。

11. 第5回のまとめ：AIに任せる範囲を、自分の意思で決める

本記事では、Claude Codeの権限管理を扱いました。要点は次のとおりです。

• 権限モードは5つ：default、acceptEdits、plan、auto、bypassPermissions
• 標準のShift+Tab循環は default → acceptEdits → plan
• bypassPermissionsは、隔離環境以外では原則使わない
• /permissionsで現状を確認し、settings.jsonのallow／deny／askで細かく設計する
• ルール優先順位はdeny＞ask＞allow。安全側はdenyに倒すのが基本
• 設定階層はManaged ＞ CLIフラグ ＞ Local ＞ Project ＞ User。権限ルールの配列は合成されて評価される

権限管理は、AIを縛るためのものではなく、AIを安心して任せられる範囲を広げるための土台です。最初の数週間だけ少し丁寧に向き合えば、その後の作業はずっと安全に、ずっと速くなります。

12. 次回予告

第6回は「APIキー・個人情報・研究データを守るための注意点」です。Claude Codeを業務・研究・教育で使ううえで「絶対に渡してはいけないもの」を整理し、.gitignore・環境変数・匿名化といった具体的な情報管理の手法を、薬学・医療・教育の文脈に即して解説します。本記事で設計した権限の枠組みを、データ保護の側からも固める回です。

13. 公式ドキュメント参照のリマインド

Claude Codeの権限モード・設定項目・既定の挙動は短期間で更新されます。本記事の内容は2026年6月時点の情報を基に執筆していますが、実際に設定を変更する前に、必ずAnthropic公式ドキュメント（https://code.claude.com/docs/en/permission-modes、https://code.claude.com/docs/en/permissions、https://code.claude.com/docs/en/settings）で最新の表記・既定値・モード名を確認してください。

参考文献・関連リンク

• Anthropic公式：Choose a permission mode（https://code.claude.com/docs/en/permission-modes）
• Anthropic公式：Configure permissions（https://code.claude.com/docs/en/permissions）
• Anthropic公式：Claude Code settings（https://code.claude.com/docs/en/settings）
• Anthropic公式ブログ：Auto mode for Claude Code（https://claude.com/blog/auto-mode）
• Anthropic Engineering：How we built Claude Code auto mode（https://www.anthropic.com/engineering/claude-code-auto-mode）
• 本シリーズ第4回：Python経験者がつまずきやすいフォルダ・ターミナル・Git
• 本シリーズ第6回（次回）：APIキー・個人情報・研究データを守るための注意点
• 本シリーズ第12回：CLAUDE.mdで作業ルールを伝える

本記事の位置づけに関する注記

本記事は、Anthropicが公開しているClaude Code関連情報を参考に、Python学習経験のある非エンジニア向けに筆者が独自に構成・解説したものです。AnthropicまたはClaude Codeの公式記事ではありません。仕様、料金、対応環境、利用条件は変更される可能性があるため、最新情報は公式ドキュメントをご確認ください。

制作ノート

本シリーズの記事およびサンプルコードは、Claude Code／Claude Opus 4.7を活用して執筆しています。AI生成情報については、公式ドキュメント・公式ブログ等の一次情報で裏取りした上で掲載しています。読者の皆さまにおかれましても、AIを使って成果物を公開する際は、AI関与の透明化を推奨します。

免責事項

本記事は生成AIを活用して作成しています。内容については十分に精査しておりますが、誤りが含まれる可能性があります。また、Claude Codeおよび関連サービスの仕様・料金・既定の挙動は変更される場合があります。最新かつ正確な情報は必ず公式ドキュメントをご確認ください。お気づきの点がございましたら、コメントにてご指摘いただけますと幸いです。なお、本記事の内容に基づいて生じたいかなる損害についても、当サイトは責任を負いかねます。

本記事に関連するおすすめ書籍をご紹介します。　Amazonでこの関連書籍「現場で活用するためのAIエージェント実践入門」を見る