第1回で、接続・データとコンプライアンス・費用・社内展開という4つの論点を挙げました。前回までの3回で、設定・データの扱い・費用の3つを実在する設定名と数字で埋めています。残るは最後の1つ、社内展開です。
このコースは、変更管理や段階導入の一般論を新しく書き起こしません。パイロットの評価とGo/No-Go判断は段階的展開と本格運用に、非患者情報からの拡大や組織のインシデント対応の型は段階導入と説明責任にまとまっています。ここで扱うのは、Claude Code固有の展開の仕組みだけです。
ㅤ
試行から全社へ: 公式の3つのガイド
Claude Codeの公式ドキュメントには、社内展開のための独立したガイドが3種類あります。それぞれ対象とする読み手が違い、そのまま試行から全社展開までの3段階に対応します。
champion-kit: 芽生えを育てる
すでに使っている個々のエンジニアが社内に広めるための30日プレイブック
admin-setup: 土台を決める
提供形態・設定配布・強制項目を選ぶ意思決定マップ。前回までに決めた内容をここで固定する
communications-kit: 号令をかける
告知文・浸透キャンペーン・FAQ集。全社展開を管理職とエンジニアリードに向けて進める
この順番を飛ばし、設定も推進役も決めないまま全社へ号令をかけると、最初のトラブル対応と設定の未整備が同時に押し寄せ、失速しやすくなります。号令をかける前に、communications-kitは6つの項目を揃えるよう挙げています。
補足
号令の前に揃える6項目
#claude-codeチャンネルの作成とリンク- 手元の環境で最低1台、インストール手順を試し済みであること
- セキュリティとデータの扱いを説明するリンクの用意
- 具体的で成功しやすい最初のタスクを1つ選んでおくこと
- 最初の48時間のチャンネル担当者
- 告知に名前を貸すC-suiteのスポンサー
公式ガイドは、経営層から発信した展開のほうが最初の週の定着率が高い傾向がある、とも述べています(この一文自体の裏付けとなる数値は示されていません)。
ㅤ
利用ガイドライン: 何を入れてよいか、どこまで任せるか
号令をかける前に、決めた設定を全社員が読める言葉に落とし込みます。技術者向けの設定ファイルではなく、迷ったときに立ち返る1枚です。
Manualモードが既定で、編集や実行には都度の承認が要ること。一括承認モードを組織として認めるかは、[管理者が決める設定](/learn/claude-code-org/02-managed-settings)で決めた値がそのまま答えになる
個人情報は入れない、契約書は法務確認後、のように現場の言葉で。前提となる保持期間やZero Data Retentionの有無は[データの扱いと監査に答える](/learn/claude-code-org/03-data-and-audit)で決まっている
承認済み以外のMCPサーバーや外部ツールを勝手に追加しない、という1行。設定キーの名前を全員が知る必要はない
社内AI利用ガイドラインそのものの書き方、つまり用途の3分類・許可ツールリスト・見直しサイクルという型は、組織のAI利用ルールを作るにまとまっています。ここではその型に、Claude Code固有の3点を足すだけです。
ㅤ
推進役: 各部署の相談窓口
号令をかけても、最初の相談を受け止める人がいなければ利用は広がりません。champion-kitはすでに使っている個々のエンジニアが社内に広める前提で書かれていますが、発想はどの部署にも応用できます。
各部署から、すでに触っている1人を推進役に指名します。渡すのは次の3点です。
推進役に渡す3点
相談窓口
部署ごとにチャンネルを作り、最初の48時間の担当者を決めておく
最初の1件
具体的で成功しやすい最初のタスクを1つ選んでおく
エスカレーション先
設定やデータ範囲で判断に迷ったら、情シスとセキュリティのどちらに聞くかを決めておく
推進役は技術サポート窓口ではありません。「これは訊いていいのか」を最初に聞かれる人という役割です。
ㅤ
利用状況のレポート: 分析ダッシュボードで見えるもの
展開したあとは、定着したかどうかを数字で確認します。
採用率・日次アクティブユーザー・セッション数。Team/Enterpriseで利用できる
Claude Codeが関わったPRの件数と行数、上位貢献者(リーダーボード)。GitHub連携が必要で、Zero Data Retentionを有効にした組織では使えない
CSVでの書き出しに加え、Enterpriseプランのみユーザー単位の利用量・費用をEnterprise Analytics APIで取得できる
補足
この数字は控えめに出ている
PRへの貢献度は、マージ日の21日前から2日後までのセッションを対象にし、開発者が20%を超えて書き換えたコードは集計から除外されます。公式ドキュメントも、この仕組みは意図的に控えめで実際の影響を過小評価していると明記しています。経営層への報告では、この数字を上限ではなく下限として扱うとよいでしょう。
ㅤ
バージョンアップへの追従: リリースチャネルと自動更新
最後に、社内に配ったClaude Code自体をどう更新し続けるかを決めます。autoUpdatesChannelという設定キーで、2つのチャネルを選べます。
stable と latest、どちらを既定にするか
既定(未設定時)。常に最新版に追従する。検証の手間は組織側が持つ
目安1週間遅れのバージョンに固定し、重大な不具合が出たリリースは飛ばす。先に検証してから広げたい組織向け
切り替えは/configの画面か、CLIでclaude install stableまたはclaude install latestを実行するだけです。
自動更新そのものを止めたい場合は環境変数を使います。DISABLE_AUTOUPDATER=1は自動更新だけを止め、claude updateでの手動更新は残します。自社の配布経路以外での更新を一切禁じたいなら、より強いDISABLE_UPDATES=1を使います。展開の初期に決めて終わりにせず、大型リリースが出るたびに一度見直す運用にしておくと、ガイドラインが古いまま放置されずに済みます。
ㅤ
今日のまとめ
3行で振り返ります。
- 全社展開は、champion-kitで芽生えを育て、admin-setupで土台を決め、communications-kitで号令をかけるという3段階で進むと迷いにくい
- 利用ガイドラインと推進役は、前回までに決めた設定を現場の言葉に翻訳したもの
- レポートと更新チャネルは、展開して終わりにしないための2つの継続点検
5回にわたって、接続・データとコンプライアンス・費用・社内展開という4つの論点を、実在する設定名と数字で埋めてきました。導入相談で聞かれた質問には、これでそのまま答えられるはずです。
チーム単位での日々の運用、設定の共有・並行作業・GitHub Actions・レビュー規約は、Claude Codeをチームで回すで扱っています。管理者の目線から現場の目線に降りて、続けて見てみてください。このコースで出てきた設定キーが、どのファイルに書かれ、どんな優先順位で効くかを詳しく知りたければ、settings.json 設定の置き場所と効く順番も参考になります。
セルフチェック
1. 公式の3つの導入ガイドのうち、告知文・浸透キャンペーン・FAQ集をまとめているのはどれですか?
2. 分析ダッシュボードの貢献度指標について、正しい説明はどれですか?
3. 自動更新を止める2つの環境変数の違いとして正しいのはどれですか?