脱・属人プログラム — 学習ノート（管理人向け）
— 社員が間違えても事故らない、権限のつくり方
社員に配ると「うっかり顧客フォルダを開く」「よくわからないまま許可を押し続ける」が必ず起きます。これを気合いでなく仕組みで止める設計。読むのは管理人だけでOK——社員側の手順は今までどおり、何も変わりません。
2026.08.11 作成 ／ 公式ドキュメントで確認（code.claude.com/docs）
CHAPTER 1
会社導入でいちばん混ざりやすいのが、第二の脳（共有脳・CLAUDE.md）と権限設定の関係です。この2つは目的がまったく違います。
| 第二の脳（共有脳・CLAUDE.md） | 権限設定（deny） | |
|---|---|---|
| 扱うもの | AIに何を知らせるか（賢さ・資産） | AIに何をさせないか（ガードレール） |
| 効き方 | お願い（AIが読んで従おうとする） | 強制（AIの意思と関係なく止まる） |
| 破られ方 | AIが読み飛ばす・忘れる | 破れない（機械的に拒否される） |
| 失敗すると | 退職で知見が消える | 顧客情報が漏れる |
CLAUDE.md shape what Claude tries to do, but they don't change what Claude Code allows.
権限ルールを執行するのはClaude Code本体であって、AIモデルではない。プロンプトやCLAUDE.mdの指示は「AIが何をしようとするか」を変えるが、「何が許されるか」は変えない。
だから共有脳の整備（GitHub Organization・shared-brain）をどれだけ丁寧にやっても、セキュリティは1ミリも強くなりません。別の階の話なので、分けて設計します。共有脳の設計は教材「複数人・複数PCで第二の脳を運用するコツ」、権限はこのページ、という住み分けです。
CHAPTER 2
Claude Codeの設定が入る「箱」は3つあります。個人で使っているうちは、ほぼ全部が真ん中の「個人の箱」に入っています。
| 箱 | 場所（Windows） | 誰が触れる | 用途 |
|---|---|---|---|
| 会社の箱 | 管理画面（推奨） または C:\Program Files\ClaudeCode\managed-settings.json | 管理人だけ | 絶対に触らせない禁止事項 |
| 個人の箱 | C:\Users\<名前>\.claude\settings.json | 本人 | 本人の許可・作業フォルダ |
| プロジェクトの箱 | 各フォルダの .claude/settings.json | チーム（PRレビュー付き） | 案件ごとの許可 |
つまり会社導入とは、個人の箱に入っている禁止事項を、社員が消せない箱へ移し替える作業です。ゼロから新しいルールを発明するわけではありません。すでに個人で運用している人は、その設定の大半がそのまま会社ルールとして通用します。
permissions.allow and permissions.deny merge entries from all sources, so developers can extend managed lists but not remove from them.
allow（許可）とdeny（禁止）のリストは、3つの箱すべての内容が合算される。だから社員は会社のリストを「足す」ことはできるが、「消す」ことはできない。
これが「遮断しつつ、必要なら広げられる」の正体です。
CHAPTER 3
| 方法 | 必要なもの | 向いている会社 |
|---|---|---|
| 管理画面に貼る （サーバー管理設定） | Team / Enterprise プラン ＋ Owner権限 | 情シスがいない・PCがバラバラな中小企業はこれ |
| PCに直接配置 （レジストリ／ファイル） | PC一括管理（MDM）の仕組み | PC管理が整っている会社 |
管理画面に貼る方式なら、JSONを保存するだけで、社員のPCは起動時と1時間ごとに自動で受け取ります。配布作業はゼロ。USBを配ったり、一台ずつ設定して回る必要はありません。
社員のPCで /status と打ってもらい、Enterprise managed settings という表示が出れば届いています。出なければ配信されていません。
CHAPTER 4
まずはこれだけで始めます。欲張らないのがコツです。
FIG. 会社の箱に貼る最小セット（フォルダのパスは自社のものに置き換える）
// で始めています。これが無い **/.env は「その社員がいま開いているフォルダの配下」しか守りません——デスクトップや別ドライブに置いた .env は素通りします（公式のdeny表に明記）。//**/ と書いて初めて「そのPC全体（全ドライブ）」が対象になります。C:\Users\… → /c/Users/… の形に直されます。特定のドライブだけなら //c/**/.env、全ドライブなら //**/.env。フォルダを名指しする //h/マイドライブ/** が同じ形なのも、この理由です。設定を書く前に、この違いを押さえてください。上から順に判定され、最初に当たったものが勝ちます（公式仕様）。
| 種類 | 意味 | たとえると |
|---|---|---|
| deny（禁止） | 何があっても実行させない | 溶接して閉じたドア。通したければ溶接を外す（＝管理人が設定を書き換える）しかない |
| ask（確認） | 実行しようとするたびに人に確認が出る | 守衛付きのドア。人がOKすれば通れる |
| allow（許可） | 確認なしで実行してよい | 開けっ放しのドア |
① 機密フォルダ・秘密ファイルの封印（deny）— いちばん効く
個人でやっている封印と中身は同じです。すでに自分のPCで設定している人は、そのリストをそのまま流用して構いません。実際に起きる事故のほとんどはここ——AIが探し物をしている途中で顧客フォルダを通過する、というパターンです。会社導入で最初にやるべきはこれです。
② 外部送信コマンドは「禁止」ではなく「確認」（curl・wget）
社内のデータを外部のサーバーへ送れるコマンドです。ただしcurl・wgetはもともと自動では許可されず、毎回確認が出ます。問題は、社員が確認画面で「今後は聞かない」を押すと許可リストに入り、以後ずっと無確認になることです。
一方で curl * | bash*（ネットから拾ったスクリプトをそのまま実行する形）だけはdenyで完全に止めます。危険な形だけを名指しで禁止し、通常の使い方は確認で通す——これが実運用で機能している型です。
③ 個人アカウントでのログイン禁止
これが無いと、社員が自分のプライベートなClaudeアカウントでログインして会社の仕事ができてしまいます。そのとき起きることは3つ：
④ 抜け道封じ — 保険として1行
Claude Codeには「Bypass permissions（バイパス）」という、確認も安全チェックも行わないモードがあります。ただし普通に使っている限り、まず踏みません：
止まらなくなるのは「名指ししていないすべての操作」の方です。確認という安全網が丸ごと外れ、設定フォルダへの書き込みまで自動承認されます。公式も「隔離されたコンテナ・VMでのみ使うこと」と警告しています。
社員が画面で切り替えられるモードです。日本語だけで説明すると画面と突き合わせられないので、英語表記もそのまま覚えてください。
| 日本語 | 画面の表記 | 設定に書く値 | 確認は出る？ |
|---|---|---|---|
| 手動 | Manual | default | 毎回すべて出る |
| 編集おまかせ | Edit automatically | acceptEdits | ファイル編集だけ出ない |
| 計画 | Plan | plan | 読むだけ・変更前に計画を出す |
| 自動承認 | Auto | auto | 出ない。ただし別のAIが実行前に審査する |
| （一覧に出ない） | Bypass permissions | bypassPermissions | 出ない・審査もなし。起動時に専用フラグが必要 |
"disableAutoMode": "disable" を会社の箱に足せますが、既定になるものを封じると社員は確認だらけに戻るので、初期は封じないことをお勧めします。封じる代わりに「会社が信頼している範囲（社内のGitHub組織名・信頼するドメイン等）を判定AIに教える」設定もあり、そちらの方が筋がよいです。CHAPTER 5
MCP＝AIに外部サービス（Notion・Slack・社内システム等）をつなぐ仕組み。放っておくと、社員が任意のサービスを勝手に接続できます。会社としては「承認したものだけ使える」カタログ制が現実的です。
allowは普通「社員が足せる」側ですが、MCPだけは allowManagedMcpServersOnly で例外的に締められます。
serverName（サーバー名）での指定はセキュリティ上の制御ではない」。名前は利用者が自分で好きに付けるラベルなので、誰でも別のサーバーを github と名付けられるからです。serverUrl）またはコマンド（serverCommand）で書いてください。CHAPTER 6
アーティファクト＝Claude Codeが作る「見せるためのWebページ」。表・グラフ・チェックリストのように、文字で読むより見たほうが早い出力をページにして、claude.ai のURLで開けるようにする仕組みです。スマホからも開けるので、社員が自発的に使い始めます。
| プラン | Shareで選べる範囲 |
|---|---|
| Team・Enterprise | 社内の特定の人／組織全員。公開リンクは既定でオフ——Ownerが開けるまで選択肢に出ない |
| Pro・Max | 公開リンクだけ。社内共有という選択肢がない |
個人プランのほうが危ない、という逆転が起きます。 会社の資料をPro/Maxの個人アカウントで扱わない理由が、ここにもあります。
| 設定 | 場所 | 判断 |
|---|---|---|
| Artifacts（機能そのもの） | Settings > Claude Code > Capabilities | Teamは既定ON。使わせてよい |
| External sharing ＝公開リンクの許可 | 同上・Artifactsの下 | 既定OFFのまま。これが最大の防御 |
| Enable artifact connectors | Settings > Capabilities | 使う予定がなければOFF |
公開・共有・削除は監査ログに claude_artifact_* として残ります。保持期間は Settings > Data & privacy controls で、非公開分と共有分を別々に設定できます。完全に使わせないなら組織トグルをOFFにするか permissions.deny に Artifact を入れますが、塞ぐ方向は原則すすめません——社員が自分で工夫を始めた芽を潰すことになります。
同じページでも開く人によって見えるものが変わり、投稿・更新のような操作も押した人のアカウントで実行されます。分からないうちは Enable artifact connectors をOFFにしておくのが安全です。
CHAPTER 7
うっかりミスは確実に防げます。本気で回避しようとする人は止まりません。 それ以上の壁が必要なら、PCを会社の管理下（MDM）に置く話になります。まずは前者で十分、というのが中小企業の現実解です。
コマンドの動きをOSごと隔離するサンドボックスという強力な機能がありますが、公式にmacOS・Linux・WSL2のみ対応／ネイティブWindowsは非対応と書かれています。Windows中心の会社では当面使えません。
→ 代わりに禁止リスト（deny）＋「そもそも機密データを作業PCの見える場所に置かない」の2段構えで守ります。
Claude Codeは書き込みは起動したフォルダとその配下に限られますが、読み取りは承認プロンプトが出れば外もできます。さらに ls・cat のような読み取り専用コマンドはもっと広く動きます。
CHAPTER 8
既存の導入ロードマップ（契約→導入→GitHub→初期設定プロンプト）はそのままです。その前後に、管理人だけがやるステップを足します。
| STEP | 誰が | やること |
|---|---|---|
| 0 新規 | 管理人 | ①Team契約するか決める（会社の箱はTeam専用） ②見せてはいけないフォルダを列挙する ③外部送信（curl等）を許すか決める |
| 1 | 各自 | 契約とアカウント |
| 2 | 各自 | Claude Codeを入れて起動 |
| 3 | 各自 | GitHubアカウントを作る |
| 4 | 各自 | 完全版初期設定プロンプトを貼る（個人の箱が整う） |
| 5 新規 | 管理人 | 会社の箱にJSONを配る → 社員1人の /status で届いたか確認 |
| 6 新規 | 管理人 | 3か月後に点検：/permissions で許可の積み上がりを見る／よく使うコマンドを会社のallowへ昇格 |
| 広げたい範囲 | やり方 |
|---|---|
| その案件だけ | プロジェクトの箱に追記 → PRレビュー（誰がいつ何を許可したかGitに残る） |
| 自分だけ | 個人の箱に追記（申請不要） |
| 会社全体 | 管理人が会社の箱に追記 |
※ここで足せるのはallow（許可）までです。会社の箱のdenyに一致する操作は、どの階層でallowを書いても開きません。開ける必要が出たら、管理人がdenyの行そのものを見直します。
allowManagedPermissionRulesOnly）もありますが、初期は入れないでください。社員が何もできず、申請だらけになって導入自体が失敗します。使うのは事故が起きてからで十分です。禁止リストは一度作れば終わりですが、許可リストは放っておくと勝手に増えます。「これ実行していい？」に社員が「はい、今後も」を押すたびに1行増えるためです。1年運用したPCを点検したら数百行になり、ユーザーフォルダが丸ごと許可に入っていた実例があります（ダウンロード・各種ツールの鍵まで読める状態）。
増えた許可を消すのは大仕事なので、塞ぐときは許可を減らすのではなく、会社の箱のdeny側に足すのが確実です（denyは許可より強く、後から書いても効きます）。詳しくは教材「AIの第二の脳を作る」のセキュリティ章へ。
APPENDIX