Claude Codeの社内展開｜セキュリティ・管理機能・配布設計

Claude Codeの社内展開で、情シスは何を押さえるべきか？

論点はアカウント・データ取扱い・設定配布・利用ルール・監査・展開順序の6つ。この順に決めれば抜けなく設計できる。

Claude Codeは、ターミナルやIDEから使うエージェント型のコーディングツールです。チャット画面にテキストを打つだけのAIと違い、リポジトリのファイルを読み、編集し、コマンドを実行するところまで踏み込みます。だから社内展開の設計も「入力してよい情報のルールを決めて終わり」にはなりません。誰のアカウントで使うのか、送信されたコードはどう扱われるのか、端末ごとの設定をどう統一するのか、利用状況をどう監査するのか——展開前に決めるべき論点を、先に地図として持っておきます。

アカウントと権限はどう設計するか？

会社契約（Team・Enterprise・API）に統一して一元管理する。統制要件が重い組織はSSO対応のEnterpriseが軸になる。

最初の分岐は契約形態です。個人向けプラン（Free・Pro・Max）は消費者向け規約で提供され、ユーザー自身の設定次第でデータが学習に使われる場合があります。業務コードを扱う以上、商用条項が適用され管理機能を持つ会社契約——Claude for Teams、Claude for Enterprise、またはClaude Console（API課金）——に統一するのが出発点です。Anthropic公式ドキュメント（2026年8月時点）に基づき、3つの選択肢を比較します。

公式ドキュメントは、既存のクラウド契約を活かす経路——Amazon Bedrock、Google Cloud、Microsoft Foundry経由での利用——も案内しています。認証と課金をクラウド側に寄せたい組織の選択肢になります。さらに「野良利用」対策として、管理ポリシー設定のforceLoginMethod・forceLoginOrgUUIDを配布すると、自社組織以外のアカウントでのログインを制限できます（公式ドキュメントより・2026年8月時点）。

ツール自体の権限も承認制が土台です。Claude Codeは既定で読み取り専用として動作し、ファイル編集やコマンド実行には明示的な承認が求められます。ls・cat・git statusのような読み取り専用コマンドは承認なしで実行され、頻用する安全なコマンドはユーザー・リポジトリ・組織単位で許可リスト化できます。認証情報はmacOSでは暗号化されたKeychainに保存されます。この「既定は閉じていて、開ける範囲を組織が決める」構造が、社内展開の設計余地そのものです。導入手順そのものはClaude Codeの導入方法で解説しています。

入力したコードやデータはどう扱われるのか？

商用プランでは入力したコードやプロンプトは既定で学習に使われない。サーバー側の保持は標準30日と公式に明記されている。

情シスが経営や法務から必ず聞かれるのがこの論点です。Anthropicの公式ドキュメント（2026年8月時点）は、プラン別のポリシーを明記しています。要点は「商用プランなら既定で学習利用なし」「保持は標準30日」「ただし端末のローカル保存は自社の管理範囲」の3つです。

個人向けプラン（Free・Pro・Max）は事情が異なります。ユーザーが学習利用を許可する設定にしている場合、そのデータは新しいモデルの学習に使われ、保持期間も長くなります（公式ドキュメントより・2026年8月時点）。つまり「会社は商用プランだから安心」でも、社員が個人アカウントで業務コードを入力していれば統制の外です。契約の一本化とログイン制限（前節）をセットで設計する理由がここにあります。

設定はどう標準化し、全社に配布するか？

managed-settings.jsonを配布すれば、ユーザーが上書きできないポリシーを全端末に強制できる。優先順位は管理設定が最上位。

Claude Codeの設定は階層構造になっており、どの層に何を書くかで「会社が強制する部分」と「チーム・個人に委ねる部分」を切り分けられます。公式ドキュメント（2026年8月時点）が定める階層は次のとおりです。

統制の要は最上位のmanaged-settings.jsonです。ここに書いたポリシーはユーザー側のどの設定でも上書きできないため、MDMやソフトウェア配布の仕組みで全端末に配置すれば、それが全社標準になります。書く内容の中心はpermissions（許可ルール）です。allow（許可）・deny（拒否）・ask（都度確認）でツールやコマンド単位の挙動を指定でき、たとえば「Read(./.env)」で認証情報ファイルの読み取りを、「Bash(curl *)」で外部への送信コマンドを組織として禁止できます。curlやwgetのようなWebからコンテンツを取得するコマンドは、そもそも既定で自動承認されない設計です（公式ドキュメントより・2026年8月時点）。

一方、チームごとの開発ルール——テストコマンドの許可、プロジェクト固有の環境変数など——はリポジトリの.claude/settings.jsonにコミットして共有します。公式ドキュメントも、承認済みの許可設定をバージョン管理で共有し、組織標準はmanaged settingsで強制する、という役割分担を推奨しています。「会社が守るべき線」と「チームが速く動くための線」を別の層に書けることが、この仕組みの設計上の価値です。

社内利用ルールには何を書くか？（雛形）

対象アカウント・入力情報・権限設定・レビュー・報告の5点を最低限明文化する。雛形を土台に自社の機密区分へ合わせる。

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

• 対象アカウント：会社が発行したTeam／Enterprise／Consoleアカウントのみ利用可。個人プランのアカウントで業務コード・業務情報を入力することを禁止する。
• 入力してよい情報：自社リポジトリのコードおよび社内ドキュメントのうち、機密区分○以下。顧客から預かったコード・データは事前承認制とする。
• 入力禁止情報：認証情報（APIキー・パスワード・秘密鍵）、顧客・従業員の個人情報、未公表の経営情報。
• 権限設定：会社標準の管理ポリシー設定（managed-settings.json）を削除・回避しない。deny設定の変更は情シスの承認制とする。
• 実行の承認：ファイル削除・外部送信を伴う操作は、内容を確認してから承認する。自動承認モードの利用は許可されたリポジトリに限る。
• MCPサーバー・拡張：外部ツール連携（MCPサーバー等）は会社が承認したもののみ導入可とする。
• 成果物の扱い：AIが生成したコードは必ず人がレビューしてからマージする。ライセンス・脆弱性の確認は既存の開発プロセスに従う。
• インシデント報告：機密情報の誤入力や不審な挙動は○○（窓口）へ即時報告する。会話履歴を外部送信するコマンド（/feedback等）の利用は運用ルールに従う。

利用状況はどう監査・モニタリングするか？

OpenTelemetryのメトリクス出力と管理者向け分析ダッシュボードの2層で、利用量・コスト・定着度を継続的に監視できる。

展開して終わりではなく、利用状況を数字で追える状態を先に作ります。公式に用意された監査手段は2層あります（Anthropic公式ドキュメントより・2026年8月時点）。

1層目はOpenTelemetryによるメトリクス出力です。環境変数CLAUDE_CODE_ENABLE_TELEMETRYを有効にすると、セッション数・トークン使用量・コスト（USD）・編集されたコード行数・コミット数などのメトリクスを、OTLP形式などで自社の監視基盤（Datadog、Grafana等のOpenTelemetry対応基盤）へ送れます。この設定自体をmanaged-settings.jsonのenvで全端末に固定すれば、監査基盤への出力を組織として強制できます。プロンプトや応答の本文、ツールの入出力は既定で記録されず（REDACTED）、含めるには明示的なオプトインが必要という設計も、公式ドキュメントに明記されています。

2層目は管理者向けの分析ダッシュボードです。Team・Enterpriseプランではclaude.ai上のダッシュボードをAdmin・Ownerロールが閲覧でき、受け入れられたコード行数、提案の受け入れ率、日次アクティブユーザー・セッション数、上位利用者のリーダーボード、CSVエクスポートが提供されます。GitHub連携を有効化すると、マージされたPRのうちClaude Codeが関与したものを識別する貢献度メトリクス（公開ベータ）も使えます。Console（API）利用の場合はConsole側のダッシュボードで、ユーザー別の支出や利用状況を追えます。トークン消費とコストの設計はClaude Codeの料金・コスト管理で詳しく扱っています。

全社展開はどの順番で進めるか？

パイロットで設定と運用を固めてから全社へ広げる。監査を先に有効化しておくことが、統制と定着を両立させる鍵になる。

ここまでの論点を、実行の順番に並べ直します。一斉開放は統制も定着も中途半端になります。次の5段階で進めるのが現実的です。

1. 契約とデータ方針を決める。Team／Enterprise／Console／クラウド経由のいずれかを選び、ZDRの要否、機密リポジトリの扱いを法務・セキュリティと合意する。
2. パイロットチームで標準設定を作る。開発1〜2チーム＋情シスで小さく使い、permissionsのdeny／allowの標準セット、プロジェクト設定の書き方を実地で固める。
3. 管理ポリシーを配布する。固めた標準をmanaged-settings.jsonに落とし、MDM等で対象端末へ配布。ログイン制限（forceLoginOrgUUID）もここで適用する。
4. 監査を先に有効化する。OpenTelemetryの出力先とダッシュボードの閲覧体制を整えてから、招待範囲を広げる。数字が見えない状態で人数だけ増やさない。
5. 教育とセットで全社へ広げる。利用ルールの周知と操作研修を対にして展開する。エンジニア以外への広げ方は非エンジニアのClaude Code活用、他社の進め方はClaude Codeの導入事例が参考になります。

導入の初期設定・インストール手順から固めたい場合は、Claude Codeの導入方法から読み進めてください。展開の設計と教育をまとめて外部の伴走で進めたい場合は、TechWorkerのClaude Code研修で情シス向けの設定設計と現場向けハンズオンを一体で提供しています。

よくある質問