Claude Code×MCPの権限設定でよくある失敗5つと回避策｜最小権限の実践【2026】

「AIエージェントにファイル操作やコマンド実行を任せたいが、情報漏洩や取り返しのつかない操作が怖い」「最小権限にすべきとは聞くが、具体的に何をどう設定すればいいのか分からない」——Claude CodeとMCPを業務に組み込むとき、最初にぶつかる壁が権限設定だ。

先に結論を述べる。権限設定の失敗は、その大半が5つのパターンに集約される。ワイルドカードで広く許可しすぎる、逆に絞りすぎて開発が止まる、MCPサーバーを丸ごと信頼する、シークレットの読み取りを放置する、そして「監査ログがある」と思い込む、の5つだ。

本記事は、Claude CodeとMCPを本番業務で常用している当社の settings.json の実際の設定値と、実際に操作がブロックされた経験をもとに、各失敗の原因と回避策を整理する。仕様の記述は2026年6月7日時点の公式ドキュメントで裏取りした。AIエージェントの基礎はAIエージェントとは？仕組み・種類・できること徹底解説を参照してほしい。

Claude Code×MCPの権限設定でよくある失敗は5つ。(1)ワイルドカードで広く許可する（Bash(git *) は git reset --hard まで通す）、(2)最初に絞りすぎて開発が止まる（rm系のdenyで依存関係の入れ直しが手動になる）、(3)MCPサーバーを丸ごと信頼する（ツール単位で絞らない）、(4).envなどシークレットの読み取りを放置する、(5)「監査ログがある」と思い込む（Claude Code単体に一元的な監査ログはない）。回避の原則は「不可逆操作はdeny・参照系は許可・書き込み系は都度確認」の3原則である（当社の本番運用より・2026年6月時点）。

権限設定でよくある失敗5つ（早見表）

Claude Codeの権限設定とは、設定ファイル settings.json に deny（禁止）・ask（都度確認）・allow（許可）のルールを宣言し、AIエージェントが実行できる操作を制御する仕組みである。ルールは deny → ask → allow の順に評価され、最初にマッチしたルールが適用されるため、denyが常に最優先になる（出典1）。なお、Claude CodeにMCPサーバーを繋ぐ手順そのものはClaude CodeとMCPを連携して外部ツールに繋ぐ実践ガイドで解説しており、本記事は「繋いだ後」の権限設計を扱う。

まず5つの失敗の全体像を一覧で押さえる。詳しい原因と回避策は次のセクションで一つずつ掘り下げる。

#	失敗	何が起きるか	回避策の核
1	ワイルドカードで広く許可	git * が git reset --hard まで通す	不可逆操作を個別にdeny
2	最初に絞りすぎる	rm系denyで依存関係の入れ直しが手動化	denyは不可逆操作に絞る
3	MCPサーバーを丸ごと信頼	破壊的ツールまで無確認で動く	ツール単位で許可・read系先行
4	シークレット読み取り放置	.envやAPIキーをAIが読める	Read(.env) 系をdeny
5	「監査ログがある」と思い込む	事後に操作を追えない	MCP側ログとtranscriptの突合

各失敗の原因と回避策

各失敗を「原因 → 実例 → 回避策」の順で整理した。思い当たる項目から確認してほしい。

失敗1：ワイルドカードで広く許可してしまう

Bash(git *) のような1行は便利に見える。しかし公式仕様では、単一の * はスペースを含む任意の文字列にマッチする。つまり git log だけでなく、git reset --hard や git push --force のような不可逆操作まで暗黙のうちに許可される（出典1）。実際に git reset --hard が実行され、未コミットの数時間分の作業が失われたという報告が公式リポジトリのIssueにも上がっている（出典5・外部事例）。

回避策は、広い許可を使うなら不可逆操作を個別にdenyへ明記しておくことだ。当社の本番設定では git push --force・git reset --hard・git clean -f・git branch -D・rm -rf 系などを明示的にブロックしている。なお、コマンドの引数を細かく制約するパターンは公式ドキュメント自身が「壊れやすい」と注意している。たとえば外部送信が心配な curl や wget は、引数で縛るよりdenyにしてドメイン許可型のWebFetchへ寄せる方が確実だ（出典1）。

失敗2：最初に絞りすぎて開発が止まる

セキュリティ解説の多くは「絞れ」としか言わないが、絞りすぎには実害がある。当社では rm -rf 系をdenyに入れているため rm -rf node_modules までブロックされ、依存関係を入れ直すたびに手動操作が必要になっている。運用担当（宮嶋）の実感でも、開発のリズムを崩すブロックは積み重なるとストレスが大きい。

回避策は、当社が本番運用で行き着いた設計3原則に集約される。(1)不可逆操作（force push・rm -rf・DB削除など、後戻りできない操作）はすべてdeny、(2)参照系（読み取り・検索・一覧）は許可して生産性を確保し、書き込み系は都度確認、(3)未知のMCPサーバーは追加するまで一切動かない状態を保つ。「全部絞る」のではなく「戻れない操作だけ絞る」が現実的なバランスだ。

失敗3：MCPサーバーを丸ごと信頼してしまう

MCPツールの許可は mcp__サーバー名__ツール名 の形式で個別に指定でき、mcp__サーバー名__* と書くとそのサーバーの全ツールが一括許可になる（出典1）。後者は楽だが、サーバーに破壊的なツールが含まれていても無確認で動くようになる。MCPの公式仕様自体も、プロトコルレベルではセキュリティ原則を強制できないため、実装側が同意フローやアクセス制御を組み込むべきだと明記している（出典4）。安全性の確保は、使う側の設定に委ねられているのが現実だ。

回避策は、read系ツールのみ先行で許可し、書き込み系は必要になってから個別に追加することだ。当社ではDB系・GitHub系のMCPサーバーについて、一覧・取得・検索系のツールだけを許可リスト化し、書き込み系は開発に必要なものへ限定、DBプロジェクトの削除や一時停止のような破壊的ツールは明示的にdenyしている。

失敗4：シークレットの読み取りを放置する

プロジェクト直下の .env ファイルには、APIキーやDB接続文字列が平文で並んでいる。権限を設定しないままだと、AIが作業の流れで .env を読み、その内容を文脈として扱う経路が残る。情報漏洩リスクとして最初に塞ぐべき穴だ。

回避策はシンプルで、Read(.env) や Read(**/.env) をdenyに入れる。この1行で「AIがシークレットを読む」経路を仕組みとしてブロックできる。運用担当の実感としても、まず最初に入れて安心できる定番の設定だ。当社では加えて、認証データを書き換える系統のコマンドもdenyしている。

失敗5：「監査ログがある」と思い込む

「何かあってもログを見れば分かる」という前提は、Claude Code単体には当てはまらない。一元的な監査ログ機能はなく、手元に残るのはローカルのtranscript（セッション記録）だ。transcriptは ~/.claude/projects/ 配下にJSONL形式で保存されるが、既定では30日で自動削除される（出典2）。当社の運用でも、transcriptはデバッグや事後レビューには役立つ一方、日常的にセキュリティ監査する仕組みとしては成立しないというのが実感だ。

回避策は、どの記録がどこに残るかを設計段階で押さえておくことだ。ツール実行の記録はローカルのtranscript、ブロックされた操作はセッション内の表示、そしてDBやGitHubへの実際の変更はMCPサーバー側（各サービスのダッシュボードやログ）に残る。企業運用では、MCPサーバー側のログとtranscriptを突き合わせる前提で監査を設計するのが現実的だ。

なぜ自前の権限設計は失敗しやすいのか

理由の1つめは承認疲労だ。Anthropicの公式ブログによれば、Claude Codeのユーザーは権限確認プロンプトの93%を承認している（出典3）。確認が形骸化すると、危険な操作もスルーされやすい。allow/denyを事前に定義しておくことは、確認の連打から解放されながら危険な操作だけを確実に止める、生産性と安全の両立策になる。

2つめは順序の問題だ。多くの場合、デフォルト設定のまま使い始め、ヒヤリとしてから権限を考える。前述の通り、MCP仕様はプロトコルとしてセキュリティを強制しない（出典4）。最初の設計を誰かが肩代わりしてくれることはなく、後回しにした分だけ無防備な期間が延びる。

失敗しない最小権限の進め方

最小権限の設定は、次の3ステップで始めると失敗しにくい。

1. 不可逆操作のdenyリストから書く（force push・rm -rf・DB削除・シークレット読み取り）
2. 参照系（read系）のみallowにして運用を開始する
3. ブロックされて困った操作だけ、内容を確認して個別にallowへ追加する

最初から完璧な設定を目指す必要はない。「戻れない操作が止まる」状態さえ最初に作れば、設定は運用しながら育てられる。なお本記事は導入後の権限設計に絞っており、導入そのものの失敗パターンは社内AI導入でよくある失敗7つと回避策で扱っている。組織として導入を進める全体手順は中小企業が社内AIを導入する5ステップを参照してほしい。

権限設定の失敗は、知識の不足というより順序の問題で起きる。ワイルドカードの範囲を知らずに許可し、ヒヤリとしてから絞りすぎ、監査ログの不在に後から気づく——本記事の5つの失敗は、いずれも先回りで避けられる。まずは不可逆操作のdenyリストを書くところから始めてほしい。

---

権限設計を含めて社内AIの導入を進めたい方へ

権限設計は、社内AI導入の進め方全体の一部です。導入の手順は中小企業が社内AIを導入する5ステップ、管理のしやすさでツールを選ぶ視点は社内AIの管理機能比較も参考にしてください。

---