Claude Codeの禁止事項と社内ルールの作り方 — 法人利用で最初に決める線引き

禁止事項は「機械で強制」と「文書で明文化」の2つに分ける

禁止事項をひとつのリストで作ろうとすると、必ず膨大になり、そして守られません。実務では、まず機械的に強制できる禁止と、人の判断に委ねて文書で示す禁止の2つに分けます。前者は設定で確実に守らせ、後者はルール文書と研修で浸透させる。この役割分担が出発点です。

機械で防げるものを、文書のお願いで済ませないのが鉄則です。「.envは触らないよう気をつけましょう」と書くより、設定で触れなくする方が確実です。逆に、判断が絡む「何を入力してよいか」は設定では表現しきれないため、文書と研修で共有します。

機械的に禁止すべきこと（permissionsで強制する）

Claude Codeには、特定の操作を禁止（deny）したり、実行前に確認を求めたり（ask）するpermissions設定があります。最低限、機械で禁止しておきたいのは次の操作です。

• 秘密情報ファイルへのアクセス — .env および .env.*（APIキー・パスワードを置くファイル）の読み書きを一切禁止する。AIに秘密情報を「見せない」構造にすれば、生成物やログへの混入を根本から防げます
• 削除・破壊系のコマンド — rm -rf などの削除や、shred・mkfs・dd といった破壊的コマンドを禁止、または毎回確認（ask）にする
• 管理者権限コマンド — sudo など権限昇格を伴うコマンドは禁止する
• 社外への公開操作 — パブリックリポジトリへのpushなど、外部公開を伴う操作は確認を挟む運用にする

文書で明文化すべきこと（人の判断に委ねる禁止）

設定では表現しきれない、判断を伴う禁止はルール文書で示します。中心になるのは「入力してよい情報・いけない情報」の線引きです。入力してはいけない情報を、自社の情報区分に対応させて明文化します。

1. 1顧客・取引先から預かった個人情報や機密情報（第三者への守秘義務があるもの）
2. 2未公開の財務情報・M&A・人事情報など、社外秘の経営情報
3. 3他社との契約で秘密保持義務を負っている情報
4. 4パスワード・APIキー・認証情報（設定でも防ぐが、ルールでも重ねて示す）

あわせて、行動としての禁止も文書に入れます。たとえば「AIの出力を無確認のまま社外に提出しない」「個人契約のAIアカウントで業務データを扱わない」といった、設定ではブロックできない運用上の線引きです。

社内ルール（利用ガイドライン）に入れる最小セット

禁止事項を整理したら、利用ガイドラインという1つの文書にまとめます。当社が支援先と一緒に作るガイドラインの最小セットは次のとおりです。

1. 1利用してよいツールと契約プラン — 使ってよいAIツールと、業務利用が許可されたプランの一覧
2. 2入力してよい情報・いけない情報 — 上の情報区分に対応させた線引き
3. 3必須の初期設定 — 学習利用オフ、permissions設定、モデル・プラン設定など、全アカウントで統一する設定
4. 4成果物の取り扱い — AIの出力を社外に出す前のレビュー・確認ルール
5. 5インシデント時の報告フロー — 誤送信・誤公開に気づいたとき、誰にどう報告するか

ありがちな失敗と、その避け方

• 禁止リストだけが長大になる — すべてを文書の禁止で守ろうとすると膨れ上がり、誰も読まなくなります。機械で強制できるものは設定へ逃がし、文書は判断が必要なものに絞ります
• 「原則禁止」で止めてしまう — 全面禁止は一見安全ですが、社員が個人アカウントで隠れて使う「野良AI利用」を生み、かえって管理不能になります。線引きを示して正規のルートで使わせる方が安全です
• 作って終わりにする — ツールもモデルも数ヶ月で変わります。ガイドラインは半年〜1年ごとに見直す前提で、更新の担当者と時期を決めておきます

まず何から作るか

完璧なガイドラインを最初から目指す必要はありません。最初の1枚は、次の3つだけで十分に機能します。

1. 1機械で強制する禁止（.envアクセス禁止・削除系コマンドの制御）をpermissionsで設定する
2. 2入力してはいけない情報を3〜5行で明文化する
3. 3困ったときの相談先（社内の誰か）を1行決める

この最小セットから始め、運用しながら育てるのが、遠回りに見えて最も早く定着します。禁止事項の設計から全社展開までを一緒に進める支援は、Claude Code法人研修・導入伴走支援で行っています。