Claude Codeの社内展開｜社内データの扱い・設定配布・ルール雛形

Claude Codeを配っても、誰がどのファイルを変更してよいかが曖昧なままでは、チームで使い続けられません。最初に決めるのは、練習する作業と、変更を確認する人です。権限設定を手がかりに、段階的に広げる順番を考えます。

権限設定から、社内で許す操作を決める

原文“Control what Claude Code can access and do with fine-grained permission rules, modes, and managed policies.”

日本語訳細かな権限ルール、動作モード、管理ポリシーを使って、Claude Codeがアクセスできる対象と実行できる操作を制御します。

社内展開では、全員へ配る前に、対象リポジトリと許可する操作をチーム単位で決めます。たとえば、コードを読む作業と、変更を書き込む作業は分けて設計します。

Claude Codeを社内へ広げる順番はどうしますか？

既存コードの読解から始め、Plan mode、限定修正、テストの順に権限を広げます。

非エンジニアが文書やデータを扱う場合は、コード編集と同じ権限を渡しません。対象フォルダ、許可するコマンド、出力形式、レビュー担当を用途ごとに限定します。

TechWorkerは、Claude Codeの利用状況をどう見ていますか？

2026年9月14日〜30日の記録では、API料金に換算した利用量を日別に把握していました。

2026年9月14日〜30日の記録では、TechWorker代表の古野がClaude Codeを使っていました。用途は、自社サービスの開発、メディアの改修、営業資料の作成、毎朝の自動の集計です。

この期間の契約は、個人向けプランのMax 20x（月200ドル）で、超過分の従量設定（extra usage）も有効でした。

利用量は、日によって大きく変わります。代表の端末の利用記録を集計ツール（ccusage）でAPI料金に換算すると、次のとおりでした。

• 2026年9月14日〜30日の17日間で、約3,000ドル分です。
• 1日平均では、約180ドル分です。
• 少ない日は約4ドル分、多い日は約850ドル分でした。200倍以上の開きです。

換算額は、実際の請求額とは異なります。定額の範囲内の利用には、追加の支払いは発生しません。

料金表示とSlack通知は、当時の運用例です。現在の運用を示す記録ではありません。組織への展開では、個人向け契約の記録と、会社契約の管理者レポートを区別します。

社内展開でも、利用状況を数字で追える状態が必要です。公式の監査手段は、手順4で整理します。

全社展開は、どんな手順で進めますか？

契約とデータ方針、設定配布、利用ルール、監査、段階展開の5つを、この順で進めます。

手順1　契約とデータ方針を決める

最初の分岐は契約形態です。個人向けプラン（Free・Pro・Max）は消費者向け規約で提供されます。ユーザー自身の設定次第で、データが学習に使われる場合があります。

業務コードを扱う以上、商用条項が適用され、管理機能を持つ会社契約に統一するのが出発点です。選択肢はClaude for Teams、Claude for Enterprise、Claude Console（API課金）です。比較は、下の表にまとめました。

既存のクラウド契約を活かす経路もあります。Amazon Bedrock、Google Cloud、Microsoft Foundry経由です。

データの取扱いは、公式ドキュメントが商用プラン向けに次のとおり明記しています。

• モデル学習：組織が明示的にオプトインしない限り、コードやプロンプトを学習に使いません。
• サーバー側の保持：契約、利用経路、モデルで条件が異なります。Enterpriseのカスタム保持は最短30日です。データを保持しない設定（Zero Data Retention、ZDR）は適格な構成に限られ、対象モデルによっては30日保持が必要です。契約画面と現行の対象モデル一覧を確認します。
• 端末のローカル保存：セッション記録が~/.claude/projects/に、既定で30日保存されます。保存期間は設定（cleanupPeriodDays）で調整できます。
• フィードバック送信：/feedbackで送った会話履歴は、5年間保持されます。環境変数で無効化できます。
• 運用情報の送信（テレメトリ）：コード・プロンプト・ファイルパスは含まれません。環境変数で送信を停止できます。

ここで、利用するモデルを含めた保持条件と機密リポジトリの扱いを、法務・セキュリティと合意します。

手順2　標準設定を作り、管理ポリシーを配布する

Claude Codeの設定は、階層構造です。優先順位の高い順に、次の5層があります。

• 管理ポリシー：managed-settings.jsonです。端末全体に適用され、上書きできません。
• コマンドライン引数：そのセッションだけの、一時的な上書きです。
• ローカル設定：.claude/settings.local.jsonです。本人と該当リポジトリに限り、Git管理外です。
• プロジェクト設定：.claude/settings.jsonです。リポジトリの全員にGitで共有します。
• ユーザー設定：~/.claude/settings.jsonです。本人の全プロジェクトに適用されます。

統制の要は、最上位のmanaged-settings.jsonです。MDMやソフトウェア配布の仕組みで全端末に配置すれば、それが全社標準になります。配置先は、macOSが/Library/Application Support/ClaudeCode/です。Linux・WSLは/etc/claude-code/です。

書く内容の中心は、permissions（許可ルール）です。allow（許可）・deny（拒否）・ask（都度確認）を、ツールやコマンド単位で指定できます。たとえば「Read(./.env)」で、認証情報ファイルの読み取りを禁止できます。「Bash(curl *)」は代表的なcurl呼び出しを止める補助規則ですが、絶対パスや別のシェル経由の実行までは止めないため、安全境界にはなりません。外部送信を強制的に制限する場合は、sandboxのネットワーク制御などを併用します。

Claude Codeは既定で読み取り専用です。ファイル編集やコマンド実行には、明示的な承認が求められます。

人が確認する工程の決め方は、AIに任せる業務の決め方（業務図ラボ）で扱っています。

野良利用への対策として、forceLoginMethodとforceLoginOrgUUIDを配布します。自社組織以外のアカウントでのログインを制限できます。

チームごとの開発ルールは、リポジトリの.claude/settings.jsonにコミットして共有します。会社が守る線と、チームが速く動くための線を、別の層に書けます。

手順3　社内の利用ルールを明文化する

技術的な統制と対になるのが、人が守る利用ルールです。次を叩き台に、自社の情報区分、開発規程、既存のAI利用ポリシーへ接続します。以下は雛形（例）です。そのまま規程として使わず、自社の環境に合わせて調整してください。

• 対象アカウント：会社が発行したTeam・Enterprise・Consoleのアカウントだけを使います。個人プランで業務コードや業務情報を入力することを禁止します。
• 入力してよい情報：自社リポジトリのコードと社内ドキュメントのうち、機密区分○以下です。顧客から預かったコードやデータは、事前承認制にします。
• 入力禁止情報：APIキー・パスワード・秘密鍵などの認証情報、顧客・従業員の個人情報、未公表の経営情報です。
• 権限設定：管理ポリシー設定を削除・回避しません。deny設定の変更は、情シスの承認制にします。
• 実行の承認：ファイル削除や外部送信を伴う操作は、内容を確認してから承認します。自動承認モードは、許可されたリポジトリに限ります。
• 成果物の扱い：AIが生成したコードは、人がレビューしてからマージします。ライセンスと脆弱性の確認は、既存の開発プロセスに従います。
• インシデント報告：機密情報の誤入力や不審な挙動は、窓口へ即時報告します。

ルールは禁止の羅列にせず、ここまでは使ってよいという許可の宣言として書きます。範囲が明確なほど、現場の利用は速くなり、統制も効きます。

手順4　監査を先に有効化する

公式に用意された監査手段は、2層あります。

1層目は、OpenTelemetryによるメトリクス出力です。環境変数CLAUDE_CODE_ENABLE_TELEMETRYを有効にします。セッション数、トークン使用量、コスト（USD）、編集されたコード行数、コミット数などを、自社の監視基盤へ送れます。送信先は、DatadogやGrafanaなど、OpenTelemetry対応の基盤です。

この設定をmanaged-settings.jsonのenvで固定すれば、出力を組織として強制できます。プロンプトや応答の本文、ツールの入出力は、既定で記録されません。含めるには、明示的なオプトインが必要です。

2層目は、管理者向けの分析ダッシュボードです。Team・Enterpriseでは、claude.ai上のダッシュボードを管理者が閲覧できます。閲覧できるのは、AdminとOwnerのロールです。

• 受け入れられたコード行数と、提案の受け入れ率。
• 日次アクティブユーザー数と、セッション数。
• 上位利用者のリーダーボードと、CSVエクスポート。

GitHub連携を有効にすると、Claude Codeが関与したマージ済みPRを識別できます（公開ベータ）。Console（API）では、Console側でユーザー別の支出を追えます。

配布したポリシーが書き換えられていないかは、ConfigChangeフックで確認できます。セッション中の設定変更を、監視・ブロックする機能です。

手順5　パイロットから全社へ広げる

一斉開放は、統制も定着も中途半端になります。次の順で広げます。

1. 開発1〜2チームと情シスで、パイロットを始めます。permissionsのdeny・allowの標準セットと、プロジェクト設定の書き方を、実地で固めます。
2. 固めた標準をmanaged-settings.jsonに落とし、MDMなどで対象端末へ配布します。ログイン制限もここで適用します。
3. 監査の出力先とダッシュボードの閲覧体制を整えてから、招待範囲を広げます。
4. 利用ルールの周知と、操作研修を対にして、全社へ広げます。

エンジニア以外への広げ方は、非エンジニアのClaude Code活用が参考になります。トークン消費とコストの設計は、Claude Codeの料金・コスト管理で扱っています。

社内展開がうまくいかない例には、どんなものがありますか？

個人アカウントの混在、端末側の見落とし、設定の個別運用、一斉開放、監査なしの拡大が代表例です。

• 個人アカウントの業務利用を放置する。会社が商用プランでも、社員が個人アカウントで業務コードを入力していれば、統制の外です。契約の一本化と、ログイン制限をセットで設計します。
• サーバー側のポリシーだけで安心する。セッション記録は、ローカルにプレーンテキストで保存されます。ディスク暗号化、退職・端末返却時のデータ消去、保存期間の設定は、自社のエンドポイント管理の仕事です。
• 各自に設定させる。環境がバラバラになり、支援できなくなります。
• 一斉に開放する。統制も定着も中途半端になります。パイロットから始めます。
• 監査の指標を決めずに配布する。見るべき数字がなければ、広げてよいかを判断できません。

契約形態ごとの管理機能は、どう違いますか？

小規模はTeams、統制要件が重い組織はEnterprise、従量で管理したいならConsoleが向きます。

出典：Anthropic公式ドキュメント（2026年8月時点）。

次の一歩は、何から始めればよいですか？

契約形態とデータ方針を決め、下のチェックリストを埋めながらパイロットを始めます。

展開前に、次のチェックリスト（雛形）を埋めてください。

• □ 契約形態を決めた（Teams・Enterprise・Console・クラウド経由）
• □ 学習利用と保持期間のポリシーを確認し、社内に説明できる
• □ 個人アカウントでの業務利用を禁止し、ログイン制限を設定した
• □ permissionsのdeny・allow標準セットを定義した
• □ managed-settings.jsonの配布経路（MDMなど）を確認した
• □ 端末側のローカル保存（暗号化・退職時の消去）を運用に組み込んだ
• □ OpenTelemetry出力か、ダッシュボードの閲覧体制を整えた
• □ 利用ルールを文書化し、研修・周知の計画を立てた

展開の設計と教育を、外部の伴走で進めたい場合は、TechWorkerのClaude Code研修をご覧ください。情シス向けの設定設計と、現場向けのハンズオンを一体で提供しています。

出典と確認範囲

確認日：2026年10月6日。製品仕様、契約、助成要件は変更されるため、実施時点の公式情報を確認してください。

1. Configure permissions - Claude Code Docs
2. Claude Code settings
3. Enterpriseのカスタム保持設定
4. 対象モデルの保持条件
5. Claude Enterpriseの管理機能