Enterprise Governance
Claude社内利用ガイドライン｜安全運用を定着させる作り方
Claudeの社内利用ガイドラインは、抽象的な「機密情報を入れない」で終わらせません。誰が、どの契約と機能を、どの業務で使い、何を入力せず、どの操作で承認を受け、何を記録するかまで定めます。公式の商用条件とセキュリティ情報を確認し、自社の責任範囲へ翻訳します。
結論：製品禁止リストではなく、業務の判断ルールを作る
利用ガイドラインの目的は、社員を萎縮させることでも、AIの安全性を保証することでもありません。許可された入口と禁止された使い方を分け、迷った時に相談でき、事故時に止められる状態を作ることです。個人向けアカウント、会社契約、API、Claude Code、クラウド経由では条件が異なるため、「Claude」という一語で同じ扱いにしません。
最初に対象を固定します。対象部署、契約プラン、管理者、利用機能、接続可能なデータ、MCPや外部ツール、利用端末、対象外の個人アカウントを一覧にします。公式条件が変わる可能性を前提に、確認日、出典URL、次回レビュー日も記録します。
ガイドラインに必要な10項目
- 目的：下書き、要約、調査、開発など許可用途を具体化する
- 対象：利用者、部署、アカウント、プラン、端末を限定する
- 入力禁止情報：秘密鍵、認証情報、未公開個人情報、契約上送信できない資料を例示する
- データ最小化：匿名化、仮名化、必要部分だけの抽出を標準にする
- 人間確認：外部送信、公開、契約、本番変更、採用・評価の承認者を決める
- 権限：ファイル、シェル、ネットワーク、MCP、外部サービスの境界を決める
- 記録：利用目的、モデル、入力区分、出力利用、承認、事故を残す
- 例外申請：通常ルールを超える場合の申請先、期限、取り消し条件を決める
- 事故対応：停止、証跡保全、報告、顧客連絡、再開承認を定める
- 更新：製品・契約・法令・業務変更時の責任者と周期を決める
入力禁止情報は具体例で示す
「機密情報禁止」だけでは、社員ごとの判断がばらつきます。APIキー、パスワード、秘密鍵、本人確認書類、未公開の人事評価、医療・金融情報、顧客との契約で外部処理を禁じた資料、公開前のM&A情報など、自社の情報分類に沿った例を示します。入力可否が不明な資料は送信せず、情報所有者へ確認する停止線を置きます。
一方、禁止だけでなく安全な代替も書きます。氏名を顧客Aへ置換する、本文全体ではなく必要な段落だけ使う、架空データでプロンプトを検証する、承認済みの社内検索基盤を使う、といった方法です。現場が仕事を続けられる代替がなければ、非公式利用が増えます。
契約・データ利用・保持を確認する
AnthropicのCommercial Termsは商用サービスの契約条件を定め、公式Trust Centerはセキュリティとコンプライアンス資料の入口を提供します。ただし、公式情報の存在だけで自社利用が適法・安全と確定するわけではありません。契約主体、対象サービス、データ処理条件、保持、学習利用、サブプロセッサー、リージョン、削除、監査資料へのアクセスを契約単位で確認します。
Webチャット、API、Claude Code、AWSやGoogle Cloud経由を混同しないでください。請求元とデータ経路が変われば、社内台帳、委託先管理、DPA、アクセス制御も見直します。記事や古い社内資料の記述ではなく、契約時点の公式文書と管理画面を正本にします。
人間確認と権限を分けて設計する
出力を読むレビューと、ツール実行を許可する権限は別です。文章が自然でも根拠が誤っている場合があり、操作前の承認があっても実行後の差分確認は必要です。顧客への送信、Web公開、支払い、削除、権限変更、本番デプロイ、法務・人事判断は、影響に応じた承認者を定めます。
Claude CodeやMCPを使う場合は、作業ディレクトリ、読み書き、シェル、ネットワーク、接続先、秘密情報を最小権限にします。便利だから常時許可するのではなく、業務ごとに許可し、期限付き例外とします。承認疲れを避けるため、低リスクの反復操作と高リスク操作を区別します。
記録と事故対応
利用ログは入力本文を無制限に保存せず、目的、情報区分、利用サービス、モデル、出力の利用先、承認者、例外番号を必要範囲で記録します。ログ自体に個人情報や秘密が集まるため、閲覧権限、保持期間、削除、監査目的を定めます。モデル提供側のログと、自社端末・プロキシ・業務システムのログを混同しないことも重要です。
誤送信、機密入力、意図しない外部通信、危険なコード実行を見つけた時は、利用停止、認証情報の失効、証跡保全、責任者への報告、影響範囲の特定を順に行います。原因確認前にログを削除したり、同じ操作を再現したりしません。再開条件は、原因、是正、対象者への周知、技術的な防止策、責任者承認が揃うことです。
運用開始の手順
短い規程と詳しい手順書を分ける
全社員向けガイドラインは、許可された入口、禁止情報、要承認業務、相談先、事故時の連絡を一読できる長さにします。モデル別の料金、画面操作、設定値、接続手順は更新頻度が高いため、別の運用手順書に分けます。規程本文へ細かな製品仕様を固定すると、更新漏れが古い指示を残します。
各文書には所有者、承認者、版、施行日、次回見直し日、変更履歴を付けます。社員が古いPDFを参照しないよう正本URLを一つにし、重要変更は対象者へ通知します。研修ではルールを読み上げるだけでなく、入力してよい例、止める例、承認を求める例を使って判断を練習し、理解度と質問を次の改訂へ反映します。
- 利用実態を聞き取り、無許可利用を責めずに入口を把握する
- 代表業務を3件に絞り、許可・禁止・要承認を分類する
- 小規模な対象者で試行し、迷った事例と失敗を記録する
- 相談窓口と24時間以内などの回答目標を決める
- 月次で例外、事故、利用量、レビュー負荷を確認する
- 四半期または重要変更時に公式条件をreadbackして改訂する
ガイドラインを定着させる更新手順
公開後は、問い合わせ、ヒヤリハット、機能変更、契約変更を更新トリガーにします。変更案、影響する業務、承認者、施行日、旧ルールとの差分を記録し、利用者へ具体例とともに伝えます。定期レビューだけでなく、重大な仕様変更時に臨時確認できる担当も決めてください。
よくある質問
社内利用を一律禁止すべきですか？
一律禁止だけでは利用実態を見えにくくします。承認済みの入口、許可用途、禁止情報、相談方法を用意します。
誰が作りますか？
業務責任者、情報システム、セキュリティ、法務・個人情報担当、現場利用者が参加し、最終責任者を一人明示します。
どのくらいの頻度で更新しますか？
定期レビューに加え、モデル、プラン、データ条件、接続機能、法令、事故が変わった時に臨時更新します。
社員教育だけで十分ですか？
十分ではありません。管理されたアカウント、最小権限、ログ、承認、停止手順など技術・運用面の統制も必要です。
公式情報
データと契約の入口は企業利用のセキュリティ確認、操作権限はClaude Codeの権限設定も参照してください。
次の一歩
Miraigentの無料診断では、現行ルールと実際の業務を照合し、許可・禁止・承認・停止条件を整理します。