Claude Code 企業導入のガードレール設計

最近は Claude Code を事務職や企画職の方にも配って、日々の作業を手伝ってもらう会社が増えてきましたよね

ただ、何の準備もせずにそのまま配ってしまうと、思わぬところで事故が起きやすいんです

例えば、認証情報の入ったファイルを読まれてしまったり、消したくないフォルダを巻き込んで操作されてしまったり、といった場面が考えられます

この記事では、Claude Code を一般の社員に配るときのガードレール設計を、情シスや管理者の目線で一通りまとめます、設定ファイルの中身も具体的なコード付きで紹介していきます

「会社で配る予定はないけど、個人で使っていて事故が心配」という慎重派の方にも、そのまま真似できる構成にしているので、肩の力を抜いて読んでみてください

Claude Code のセキュリティの全体像はClaude Code Desktop 初心者向けセキュリティ5選、設定ファイルそのものの整理はClaude Code 設定ファイル早見表でも扱っているので、土台から知りたい方は合わせてどうぞ

なぜ「初期設定なしで配る」と事故るのか

Claude Code は、お願いした内容に応じて自分でファイルを読み書きしたり、裏でコマンド(プログラム命令)を実行したりできます

この自走できる力が便利さの源なんですが、配り方を間違えると、同じ力がそのままリスクにもなります

とくに、コマンドや設定ファイルに慣れていない方が使う場合、こんな場面が起こりがちです

• パスワードやAPIキーの入った .env ファイルを読み込んで、その中身が会話履歴に残ってしまう
• デスクトップやドキュメントなど、消したくないフォルダの中で作業させてしまい、関係ないファイルまで巻き込む
• 「許可をバイパス」する設定をうっかり有効にして、確認なしで何でも実行できる状態になる
• 認証情報をそのまま Git にコミットして、社外に出してはいけない情報が共有リポジトリに載る

どれも「使う人が気をつければ防げる」と言えなくはないんですが、毎回・全員が気をつけ続けるのは現実的じゃないですよね

AIならではの落とし穴もある

ここまでは、普通のソフトでも起こりそうな事故の話でした、ただ、AIを使う以上は、AIならではのリスクも頭に入れておきたいところです

1つめが プロンプトインジェクション です、これは、AIに読ませた文章(PDF・メール・Webページなど)の中に、こっそり別の命令が仕込まれていて、AIがそれを指示として受け取り、変な動きをしてしまう手口です

押さえておきたいのは、AIにとって文章は「情報」であると同時に「命令」にもなりうるという点です、ここが、普通のシステムを入れるときとの大きな違いになります

2つめが 権限の渡しすぎ です、AIの回答がただ間違っているだけなら、人が気づいて止められます、でも、ファイルの削除・メール送信・外部への公開といった「実際に動く権限」まで渡していると、先ほどのプロンプトインジェクションと組み合わさったときに、そのまま実害につながってしまいます

対策の考え方はシンプルで、人と同じようにAIにも必要最小限の権限だけ渡す、そして消す・送るといった大事な操作の前には人が確認する、この2つです、このあと出てくる permissions の deny(禁止)と ask(都度確認)が、まさにこれを設定で実現する道具になります

3つめが コネクターやMCPの扱い です、Google DriveやSlackをつなぐコネクター、外部のツールとつなぐ MCP(外部連携の共通規格)は便利なんですが、つなぎ先の権限設定が雑だと、AI経由で本来見えてはいけない情報まで引き出せてしまいます

つなぐときは、読み込み(閲覧)は許可しても、書き込みは安易に許可しないというふうに、できることを分けて考えるのがおすすめです

だからこそ、使う人の注意力に頼らず、仕組み側であらかじめ守るという発想が大事になります

ハーネス(枠組み)で守るという考え方

ここで言うハーネスは、使う人を包む安全の枠組みくらいに考えてください、車のシートベルトのように、意識しなくても勝手に守ってくれる仕掛けのことです

具体的には、管理者があらかじめ設定ファイルや作業フォルダを用意しておき、使う人はその枠の中で操作する、という形を作ります

この記事で紹介するガードレールは、おおまかに次の6つです、上から順に効果が広いものになっています

1. managed-settings.json で、上書きできない管理ポリシーを配る
2. settings.json の permissions で、できる操作とできない操作を線引きする
3. セキュリティ系プラグインで、書かれたコードを自動でチェックする
4. 作業フォルダの固定で、どこでも実行できる状態を避ける
5. .gitignore の標準配布で、認証情報をうっかり共有させない
6. 初期CLAUDE.md の配布で、社内ルールを最初から読ませる

ここまでやると「ちょっと過剰かな」と感じる場面もあると思います、ただ、事故が心配な環境なら、最初は厚めに守っておいて、慣れてきたら緩めるくらいがちょうどいいんじゃないでしょうか

1. managed-settings.json で上書きできないポリシーを配る

ガードレールの土台になるのが managed-settings.json です、これは管理者が配る「上から決めた設定」で、使う人が自分の設定で上書きできないのが大きな特徴です

Intune や Jamf といった MDM(端末を一括管理する仕組み)を使って、全社員のパソコンに同じファイルを配る、という運用が想定されています

置き場所はOSごとに決まっている

managed-settings.json は、置く場所がOSごとに決まっています、2026年6月時点の公式ドキュメントだと次の通りです

同じ場所に managed-settings.d というフォルダを作って、複数の設定ファイルに分けて置くこともできます、チームごとにポリシーの断片を分担したいときに便利です

中身は通常のsettings.jsonと同じ書き方

ありがたいことに、ファイルの中身は普通の settings.json と同じ書き方で大丈夫です、管理者として「これだけは守らせたい」という最小限のポリシーから始めるのがおすすめです

{
  "permissions": {
    "disableBypassPermissionsMode": "disable",
    "deny": [
      "Read(.env)",
      "Read(**/.env)",
      "Read(**/.env.*)",
      "Read(**/*.pem)",
      "Read(**/*.key)",
      "Read(**/id_rsa)",
      "Read(**/credentials.json)"
    ]
  }
}

この例だと、認証情報が入りがちなファイルの読み込みをまとめて禁止しつつ、確認なしで何でも実行する「許可をバイパス」モードも封じています、それぞれの中身はこのあとの章で順番に説明します

managed-settings.json に書いた内容は、使う人の設定では上書きできません、なので本当に外してほしくない守りだけをここに集約するのがコツです

読み込み禁止が効く範囲には条件がある

ここで、配る前に押さえておきたい条件が2つあります、どちらも公式ドキュメントに明記されているもので、知らないと「守ったつもり」になりやすいところです

1つめが どこまでのフォルダが対象になるか です、Read(.env) や Read(**/.env) のような書き方が止めるのは、起動したフォルダとその配下にある .env だけです、親フォルダや別プロジェクトの .env は対象外になります

先頭を // にすると、パソコン全体を対象にできます、全社ポリシーとして「どこに置いてある .env でも読ませない」を徹底したいなら、こちらの書き方にしてください、逆に、次の章で紹介する作業フォルダの固定とセットにする前提なら、上の相対的な書き方でも狙いどおりに働きます

2つめが 誰の読み書きを止められるか です、Read と Edit の禁止が効くのは、Claude 自身のファイル操作と、Claude が把握しているファイル系コマンド(cat・head・tail・sed など)までになります

とはいえ、これは「deny が無意味」という話ではありません、うっかり読ませてしまう事故はこれで大きく減らせますし、非エンジニアに配る前提ならスクリプトを書いて回避する場面自体が多くありません、どこまで守れているかを情シス側が正確に把握しておくための条件、と捉えてください

設定の優先順位を押さえておく

Claude Code の設定は何層かに分かれていて、ぶつかったときにどれが勝つかが決まっています、優先順位は上が強いです

大事なのは、禁止(deny)はどの層から付けても効くという点です、ある層で禁止したものは、別の層で許可しても解除されません

つまり管理者は、managed の層で禁止を盛っておけば、使う人がどんな設定をしても穴が開かない、という安心感が得られます

2. permissions で操作範囲を線引きする

次は、Claude Code が「何をしていいか」を細かく決める permissions の話です、ガードレールの中でも一番こまかく効くところです

permissions は3つのリストでできています、それぞれの役割はこんな感じです

判定の順番は deny → ask → allow です、最初に deny にあたれば、後ろで allow に書いてあっても禁止が優先されます、なので禁止したいものは deny に書くのが確実です

危険なコマンドを deny で止める

まず止めておきたいのが、影響範囲の大きいコマンドです、ファイルを一括で消すような命令や、ネットへ自由にアクセスする命令を deny に入れておきます

{
  "permissions": {
    "deny": [
      "Bash(rm *)",
      "Bash(curl *)",
      "Bash(wget *)",
      "Bash(git push *)"
    ],
    "defaultMode": "default"
  }
}

Bash というのは、Claude が裏で実行するコマンド(プログラム命令)のことです、ここでは削除の rm、勝手なダウンロードに使われがちな curl と wget、共有リポジトリへの送信になる git push を止めています

ここで大事なのが Bash(rm *) の書き方です、コマンドの照合は前方一致なので、この形だと rm で始まるコマンドをまとめて止められます

WebFetch でアクセス先のドメインを絞る

WebFetch は、Claude がWebページを読みにいく機能です、ここを野放しにすると、どこへでも情報を取りにいけてしまうので、許可するドメインだけ絞るやり方が安心です

{
  "permissions": {
    "allow": [
      "WebFetch(domain:docs.claude.com)",
      "WebFetch(domain:github.com)"
    ],
    "deny": [
      "WebFetch"
    ]
  }
}

書き方は WebFetch(domain:許可したいドメイン) です、この例だと、ドキュメントとGitHub以外への読み込みを止めつつ、業務で必要なところだけ通せます

「許可をバイパス」モードを封じる

Claude Code には、確認をすっ飛ばして次々に実行する「許可をバイパス」モードがあります、便利ではあるんですが、慣れていない方が使うと、止める間もなく操作が進んでしまう危険があります

これを管理者側で封じるのが disableBypassPermissionsMode です、値を “disable” にすると、設定からもコマンドからもこのモードが使えなくなります

{
  "permissions": {
    "disableBypassPermissionsMode": "disable"
  }
}

さらに徹底したいなら、allowManagedPermissionRulesOnly を true にすると、許可・確認・禁止のルールを管理者の設定だけに限定できます、使う人が勝手に許可を増やすのを防げます

「自動モード」を許すかどうかも情シスが決める

「許可をバイパス」と混同されやすいのが 自動モード です、たしかに別物なんですが、安全側のモードだから止めなくていい、と考えるのは正確ではありません

公式ドキュメントのモード一覧を見ると、自動モードで確認なしに実行される範囲は すべて(裏で安全チェックが走る)と書かれています、確認を挟まずに動ける範囲そのものは広いということです

その「裏の安全チェック」を担当しているのは、分類器と呼ばれる判定用のモデルです、あらかじめ決めた許可リストと突き合わせているわけではなく、依頼の内容から外れた操作・見覚えのない接続先・読み込んだ文章に誘導された気配がある操作などを、その都度モデルが判断して止めています

そのうえで、管理者として確実に言えることが1つあります、deny はどのモードでも効くという点です、なので deny に書いた操作は、自動モードでも実行されません

裏を返すと、deny に挙げていない操作は確認なしで走りうるということでもあります、だからこそ、自動モードを許す運用にするなら、deny の作り込みが前提になります

ジャベ雄

自動モードは「確認が減るモード」であって「安全なモード」ではない、と分けて覚えるのがよさそうです

止める判断をした場合は、管理者側で permissions.disableAutoMode を “disable” にすると、組織単位で自動モードを使えなくできます、書き方は「許可をバイパス」を封じるときと同じで、managed-settings.json に並べて書けます

{
  "permissions": {
    "disableBypassPermissionsMode": "disable",
    "disableAutoMode": "disable"
  }
}

どちらが正解というものではなく、事務職や企画職の方に配る前提なら「自動モードも止めておく」、ある程度分かっている人が使うなら「deny を固めたうえで自動モードは許す」といった具合に、情シスが判断する対象の1つとして扱ってください

permissions まわりをもう少しじっくり知りたい方は、Claude Code 設定ファイル早見表で各ファイルの役割を確認しておくと、どこに何を書けばいいか迷わなくなります

3. セキュリティ系プラグインで自動チェックを足す

設定で操作を縛るだけでなく、書かれたコードそのものを自動でチェックする仕組みも入れておくと安心です、ここで役立つのが公式のセキュリティ系プラグインです

2026年5月に公開された security-guidance は、Claude が書いたコードに危なっかしいパターンが混じっていないかを自動で見てくれるプラグインです、たとえば外部からの入力をそのまま実行してしまう書き方などを拾ってくれます

導入は Claude Code Desktop のプラグイン画面から数クリックで済みます、無料で、どのプランでも使えて、入れたあとは自動で動いてくれるので、配る側としても手間がかからないのが嬉しいところです

security-guidance の検出パターンや、deny リストとの組み合わせ方はsecurity-guidance とは 使い方と運用のコツでくわしくまとめているので、入れる前にざっと目を通しておくと運用イメージがつかみやすいです

プラグインの配布元を管理者で固定する

プラグイン自体は便利なんですが、誰がどこから入れられるかを野放しにすると、出どころの怪しいものが混ざる心配もあります

会社で配るなら、managed-settings.json 側で「入れていいプラグインの棚」を絞っておくのがおすすめです、公式の棚だけ許可しておけば、使う人は安心して選べます

4. 作業フォルダを固定して「どこでも実行」を避ける

地味ですが効くのが、作業する場所をあらかじめ決めておくという対策です

Claude Code は、起動した場所のフォルダを起点に動きます、なので、もしデスクトップやドキュメントの直下で起動してしまうと、大事なファイルが並ぶ場所で操作が走ることになります

そこで、MDM で全社員のパソコンに 所定の作業フォルダ を自動で作っておく、という手を打ちます、たとえばこんな構成です

C:\Users\(ユーザー名)\ClaudeWork\
  ├─ .gitignore        ← 認証情報を除外するリスト
  ├─ CLAUDE.md         ← 社内ルールを書いた初期ファイル
  └─ work\             ← ここで作業する

このフォルダの中で作業してもらうように案内しておけば、関係ないファイルを巻き込むリスクをぐっと減らせます、後で出てくる .gitignore や CLAUDE.md も、最初からこの中に置いておけます

さらに、Claude が触れてよいフォルダを設定で限定したいときは、additionalDirectories という項目で、追加で使ってよい場所をリスト化できます、明示した場所以外には基本的に手を出させない、という運用も組み立てられます

5. .gitignore を標準配布して認証情報を守る

つづいて、.gitignore の標準配布です、これは認証情報のうっかり共有を防ぐための、地味だけど大事な一手です

.gitignore は、Git に「このファイルは管理しないでね(=共有リポジトリにもアップしないでね)」と伝えるためのリストです、ここに書いたファイルは、コミットの対象から外れます

パスワードやAPIキーが入る .env などをここに書いておけば、Git 経由で社外に出てしまう事故を防げます、配布する雛形はこんな内容で十分です

# 認証情報
.env
.env.*
*.pem
*.key
id_rsa
credentials.json

# ローカル設定
.claude/settings.local.json

# 一時ファイル
*.log
tmp/

ポイントは、これを全員に同じ内容で配ることです、一人ひとりに「.gitignore を書いてね」とお願いしても抜けが出ますが、雛形を配ってしまえば、最初から同じ守りが効きます

📚 Claude・生成AIを学べる本PR

実践Claude Code入門

西見公宏・吉田真吾・大嶋勇樹

Amazonで見る楽天で見る

Claude CodeによるAI駆動開発入門

平川知秀

Amazonで見る楽天で見る

開発効率をアップする! Claude Code 実用入門

大澤文孝

Amazonで見る

私のおすすめからランダムで3冊を表示しています

6. 初期CLAUDE.mdを配って社内ルールを読ませる

最後は 初期CLAUDE.md の配布です、ここまでが仕組みで縛る守りだったのに対し、これは「Claud に最初から読ませておく社内ルール」という、もう一段やわらかい守りになります

CLAUDE.md は、Claude Code が作業前に読み込む指示書のようなファイルです、ここに会社のルールや禁止事項を書いておくと、毎回それを踏まえて動いてくれます

配布する雛形には、作業フォルダの説明・やってほしくないこと・困ったときの相談先あたりを入れておくと親切です

# 社内Claude Code 利用ルール

## 作業する場所
- 作業は ClaudeWork\work フォルダの中で行ってください
- このフォルダの外にあるファイルは、勝手に触らないでください

## やってほしくないこと
- .env や鍵ファイル(*.pem / *.key)の中身を会話に出さない
- 共有リポジトリへの送信(git push)はしない
- 設定ファイルを書き換えるときは、内容を私(利用者)に見せてから書く

## 困ったとき
- 操作に迷ったら止まって、情報システム部に相談してください
- 連絡先: jyoshi@example.com

ここで1つ気をつけたいのは、CLAUDE.md はあくまで「お願い」であって、強制力はないという点です

本当に守らせたい禁止は、これまで紹介した managed-settings.json の deny で仕組みとして縛る、CLAUDE.md は方針や心構えを伝える、という役割分担で考えると分かりやすいです

入力していい情報・ダメな情報を3段階で決める

ここまでは「操作」を縛る守りでした、もう1つ、配る前に決めておきたいのが 何を入力していいか の線引きです、これは設定ファイルではなく、社内ルールとして決めておくものになります

細かく決めすぎると運用が回らなくなるので、ざっくり3段階に分けるのがおすすめです

真ん中の「条件つきでOK」は、入力した内容がモデルの学習に使われない契約で、かつアクセス権が守られている範囲で、という前提つきです、Anthropicの公式ドキュメントによると、2026年6月時点では、Team・Enterprise・API といった法人(コマーシャル)契約では、Claude Codeに送ったコードやプロンプトを既定でモデル学習には使わない、とされています(ただし管理者が Developer Partner Program などに自分から参加した場合は、学習の対象になりえます)

それと、学習とは別の話として、やり取りの履歴は手元のパソコンにしばらく残ります(既定で30日ほど)、なので「原則NG」のパスワードや鍵は、学習に使われるかどうか以前に、最初から入力させないのが基本です

この3段階は、先ほどの 初期CLAUDE.md に書いておくと、配るだけで全員に同じ基準が共有できます

ここは設定では止められないと割り切る

1つ、はっきりさせておきたいことがあります、この線引きは 設定で縛れる話ではないという点です

前に紹介した deny の読み込み禁止が止めてくれるのは、あくまで Claude が .env などのファイルを読みにいく動きです、使う人がパスワードを会話欄に直接打ち込む行為は、deny では止まりません

なので、配る前に打ち込んでしまったときの初動まで決めておくのがおすすめです、起きる前提で手順を用意しておくと、現場が慌てずに済みます

ジャベ雄

手元の平文記録は見落としがちです、鍵を替えて会話を消して終わり、にしないところが肝心です

設定のプライバシー画面で学習と位置情報を確認する

前の章は「契約として学習に使われるかどうか」という制度の話でした、ただ、個人プラン(Free・Pro・Max)の方が実際に学習を止めたいときは、設定画面のトグルを一度確認しておくのが早いです

場所は 設定 → プライバシー です、Claude Code Desktop の設定を開いて、左メニューの プライバシー を選ぶと、データの扱いに関する項目がまとまっています

この画面の「設定」という区画に、確認しておきたいトグルが2つ並んでいます

肝になるのが AIモデルの改善にご協力ください です、ここをオンにしていると、個人プランではチャットやコーディングセッションが将来のモデル学習に使われます(Claude Code 経由のやり取りも含みます)、オフにすると、それ以降の新しいやり取りは学習に使われなくなります

同じプライバシー画面を下にスクロールすると あなたのデータ という区画もあります、ここから、これまでのデータのエクスポートや、共有したチャット・アーティファクトの管理ができます、共有したまま忘れていた履歴を見直したいときに開いてみてください

ジャベ雄

契約で守られていても、個人プランはトグル1つで扱いが変わります、配る前にこの画面をそろえておくと安心です

個人でも真似したい最小セット

ここまで会社向けの話をしてきましたが、「うちは会社じゃないし、そこまではいらないかな」という方も多いと思います

そこで、個人で使う慎重派の方が真似する価値のある最小セットを、3つに絞ってまとめておきます

• settings.json の deny に .env 系と危険コマンドを入れる:認証情報の読み込みと一括削除を止める、これだけで事故の多くが防げます
• .gitignore に認証情報を書く:Git を使うなら、.env や鍵ファイルを最初に除外しておく
• 作業フォルダを1つ決める:専用のフォルダの中だけで Claude Code を使うようにして、大事なファイルから離す

managed-settings.json や MDM 配布は会社向けの仕組みですが、個人なら自分の settings.json に同じ deny を書くだけで近い効果が得られます、管理者がいない分、自分が管理者のつもりで一度だけ設定しておく、というイメージです

設定が不安なら Claude 自身に頼む手もある

「設定ファイルを自分でいじるのは怖い」という方は、Claude 自身に書いてもらうのも手です、やりたいことを言葉で伝えれば、中身を用意してくれます

たとえば、こんな感じで頼んでみてください

このプロジェクトの settings.json を作りたいです。
次の方針でお願いします。

・.env や鍵ファイル(.pem / .key)の読み込みを deny で禁止
・rm の一括削除と git push を deny で禁止
・「許可をバイパス」モードは使えないようにする

書き込む前に、設定内容を一度わたしに見せてから保存してください。

最後の「書き込む前に見せてね」の一言がポイントです、内容を確認してから保存すれば、知らないうちに変な設定が入る心配もありません

よくある質問

まとめ

事務職や企画職の方に Claude Code を配るときは、使う人の注意力に頼らず、仕組みで守るのが基本でした

この記事で紹介したガードレールを、もう一度おさらいしておきます

• managed-settings.json:MDMで配る、上書きできない管理ポリシー
• permissions の deny:危険コマンドと認証情報の読み込みを止める
• セキュリティ系プラグイン:書かれたコードを自動でチェックする
• 作業フォルダの固定:どこでも実行できる状態を避ける
• .gitignore の標準配布:認証情報の共有を防ぐ
• 初期CLAUDE.md:社内ルールを最初から読ませる

あわせて、AIならではのリスク(プロンプトインジェクションや権限の渡しすぎ)を頭の片隅に置きつつ、入力していい情報の線引きを社内で決めておくと、守りがぐっと固くなります

それと、設定では止めきれない部分が2つありました、「自動モード」を許すかどうかの方針と、認証情報を打ち込んでしまったときの初動です、どちらも配ったあとに決めようとすると間に合わないので、配る前に情シス側で答えを出しておいてください

会社で配る予定がなくても、deny・.gitignore・作業フォルダの3つは個人でも真似する価値があります、慎重派の方ほど、最初に一度だけ仕込んでおくと、後がずっと気楽になりますよ

関連する話として、Claude Code Desktop 初心者向けセキュリティ5選では使い始めの守り方を、security-guidance とは 使い方と運用のコツではプラグインによる自動チェックをくわしく扱っています、合わせて読むと、自分の環境に合った守りを組み立てやすくなると思います

📚 Claude・生成AIを学べる本PR

実践Claude Code入門

西見公宏・吉田真吾・大嶋勇樹

Amazonで見る楽天で見る

Claude CodeによるAI駆動開発入門

平川知秀

Amazonで見る楽天で見る

開発効率をアップする! Claude Code 実用入門

大澤文孝

Amazonで見る

私のおすすめからランダムで3冊を表示しています