Claude Code を社内に広げて定着させる進め方：少人数で試し、設定と手順をそろえてから全員に配る

Claude Code を会社で契約して、席を配った。ところが、しばらくたっても毎日使っているのは一部の人だけ。使っている人も、それぞれが自分のやり方で指示を書き、自分の設定で動かしている。誰がどれくらい使っていて、費用に見合っているのかも分からない。

ツールを配ることと、会社の仕事のやり方として定着させることの間には、いくつかの段階があります。この記事は、Claude Code の導入を任された開発の責任者や、情報システムの担当者に向けて書いています。次のことを順にまとめます。

• 「定着した」と言える状態とは何か
• 段階1：少人数で試し、基準になる数字をとる
• 段階2：会社の設定を決めて、全員に配る
• 段階3：チームの手順を、リポジトリに残す
• 段階4：全員に広げ、使われ方と費用を見る
• 段階ごとのチェックリスト

どのプランで契約するかは「Claude を法人で契約するには」に、情報漏えいを防ぐ設定と社内ルールのひな形は「Claude Code を会社で安全に使う」にまとめています。この記事では、契約したあとの広げ方と続け方に絞ります。事実は Anthropic の公式ドキュメント（Claude Code Docs）で確かめ、本文にリンクしています。機能や画面は変わりやすいため、2026年11月時点の内容です。

「定着した」と言える状態

最初に、どこを目指すのかを決めておきます。クリーヴァでは、次の3つがそろった状態を「定着した」と考えています。

1. 全員の設定が、会社の決めた形にそろっている。使ってよい操作、読ませてはいけないファイルなどが、一人ひとりの設定ではなく、会社の設定として配られている。
2. チームの手順がリポジトリに書いてあり、新しく入った人も同じやり方で始められる。テストの動かし方、守るべき決まり、よく使う作業の手順が、Claude Code が読める形で残っている。
3. 使われ方と費用が見えていて、次の判断ができる。誰がどれくらい使っているか、費用はいくらか、広げるべきか絞るべきかを、数字で話せる。

席を配っただけでは、このどれもそろいません。逆に、この3つがそろっていれば、担当者が替わっても、人が増えても、同じ形で使い続けられます。

段階1：少人数で試し、基準になる数字をとる

公式も「小さく始める」ことを勧めている

Anthropic の「Manage costs effectively」では、企業での導入の平均として、利用した日の開発者1人あたり約13ドル、1人あたり月150〜250ドルという数字を示しています。利用者の90%は、利用した日の費用が30ドル未満に収まるとしています。そのうえで、自社の費用を見積もるには、小さなパイロットのグループから始め、追跡の仕組みで基準になる数字をとってから広げるよう勧めています。

この数字は一般的な定価での目安で、使い方によって大きく変わります。Team や Enterprise のプランでは、席ごとの使える量の中で使う形になるため、ドルの金額がそのまま請求されるわけではありません。それでも、「どれくらい使うと、どれくらいかかるのか」を自社の使い方で確かめてから広げる、という順番は、どのプランでも同じです。

試すメンバーと、試す仕事の選び方

パイロットのメンバーは、次のような人を混ぜると、全員に広げたときにつまずく所が先に見えます。

• 新しいツールを試すのが好きで、使い方を言葉にできる人
• 毎日コードを書くが、AI のツールにはまだ慣れていない人
• コードのレビューや、リリースの判断をする人

試す仕事は、練習用の題材ではなく、実際のリポジトリの、実際の仕事にします。テストの追加、小さな不具合の修正、既存のコードの読み解きなど、結果を人が確かめやすい仕事から始めると、良し悪しを判断しやすくなります。

試している間に記録すること

• うまくいった頼み方と、うまくいかなかった頼み方
• 何度も同じ説明をしたこと（あとで CLAUDE.md に書く候補）
• 毎回同じ手順を踏んだ作業（あとで skill にする候補）
• 止めたかった操作、読ませたくなかったファイル（あとで会社の設定にする候補）
• 使った量と費用

この記録が、段階2と段階3の材料になります。

段階2：会社の設定を決めて、全員に配る

一人ひとりの設定では、ルールを守れているか確かめられない

Claude Code の設定には、本人だけに効く設定、リポジトリに置いてチームに効く設定、会社が配る設定（managed settings）があります。公式の「Best practices for Claude Code」では、会社が配る設定は、個人の設定ファイルでは上書きできないため、セキュリティの担当が決めた方針を置ける唯一の場所だと説明しています。

設定の配り方は4つ

「Set up Claude Code for your organization」では、会社の設定を届ける方法として、次の4つを優先度の高い順に挙げています。

サーバーから配る設定は、Claude Code の起動時に取得され、使っている間も1時間ごとに更新されます。端末を管理する仕組みを用意しなくても届けられますが、Claude の管理画面から配るには Team か Enterprise のプランが必要です（Configure server-managed settings）。

また、許可や拒否のリストのような項目は、すべての設定の内容が合わさって効きます。公式の説明では、開発者は会社のリストに足すことはできても、外すことはできないとされています。会社として「読ませない」と決めたファイルは、本人の設定で読めるようにはなりません。

何を会社の設定にするか

会社の設定には、例外なく守りたいことだけを置きます。公式のベストプラクティスでも、強制する決まりは少なく保つよう勧めています。強制する決まりは、まれに意図しない場面で止まることがあり、誰かが手入れし続ける必要があるからです。

会社の設定の候補になるのは、たとえば次のようなものです。

• 本番の鍵や秘密の情報が入ったファイルを読ませない
• 確認なしで動いてはいけない操作（本番への反映、外部への送信など）
• 使ってよい外部の接続先（MCP サーバー）やプラグインの範囲
• 確認を飛ばすモードを使えないようにする

具体的な書き方と、そのまま使える例は「Claude Code を会社で安全に使う」にまとめています。

届いているかを確かめる

設定を配ったら、開発者に Claude Code の中で /status を実行してもらいます。公式の手順では、Status のタブの「Setting sources」の行に、会社の設定（Enterprise managed settings）と、どの届け方が効いているかが表示されます。全員に広げる前に、パイロットのメンバーの端末で確かめておきます。

段階3：チームの手順を、リポジトリに残す

CLAUDE.md は短く、チームで共有する

「How Claude remembers your project」によると、リポジトリの直下などに置く CLAUDE.md は、ソースコードと一緒に管理され、チーム全員に共有される指示です。個人の好みは、リポジトリに入れない CLAUDE.local.md に分けます。

CLAUDE.md は毎回の作業で読み込まれるため、公式のベストプラクティスでは、コードを読めば分かることは書かず、Claude Code が自分では分からないことだけを書くよう勧めています。挙げられているのは、たとえば次のようなことです。

• 作業を確かめる方法（テスト、型の確認、静的解析のコマンドと、1つのテストだけを動かす方法）
• コードを見ると誤解しやすい所（まねしてはいけない古い書き方、使われていないように見えて使われているフォルダ）
• リポジトリに書かれていない決めごと（エラー処理の決まり、リリースのやり方）
• すでに2回以上、直したこと

段階1で記録した「何度も同じ説明をしたこと」が、ここに入ります。

チームの手順は skill にする

リリースの手順や障害対応の手順のように、チームごとのやり方は、skill として .claude/skills/<名前>/SKILL.md に残せます。公式の説明では、skill は名前と説明だけが毎回読み込まれ、中身は必要なときだけ読まれるため、長い手順を CLAUDE.md に書くより軽く済みます。リリースのように副作用のある手順は、Claude Code が自分で始めず、人が呼び出したときだけ動くように設定できます。

段階1で記録した「毎回同じ手順を踏んだ作業」が、skill の候補です。

「必ず守ること」は、指示ではなく仕組みで止める

公式のベストプラクティスは、Claude Code への指示を2種類に分けています。

• Claude が読んで判断するもの：依頼の文、CLAUDE.md、skill。ほとんどの場合は従いますが、従うことが保証されているわけではありません。
• Claude Code が必ず実行するもの：hook（決まったタイミングで動く処理）、拒否のルール、会社の設定。モデルの判断にかかわらず、毎回適用されます。

ほとんどのことは前者で十分です。一方で、「生成されたファイルは手で直さない」「ファイルを作ったら必ずこのスクリプトを通す」のように、例外なく守らせたいことは、後者の仕組みで止めます。CLAUDE.md の同じ行をいくら強い言葉で書き直しても守られないときは、hook に移すサインだとされています。

「終わったか」を確かめる手段を渡す

公式のベストプラクティスでは、Claude Code は作業が終わったように見えたところで止まるため、合否が返ってくる確かめ方（テスト、ビルドの結果、静的解析など）を渡すよう勧めています。確かめ方があれば、Claude Code が自分で直して、もう一度確かめるところまで進められます。

チームで使うなら、この確かめ方をそろえておくことが大切です。人によってテストを動かしたり動かさなかったりすると、同じ Claude Code でも、できあがるものの品質がばらつきます。

複数のリポジトリで使う手順は、プラグインで配る

CLAUDE.md や skill はリポジトリごとに置くものです。複数のリポジトリや部署で同じ手順を使う場合は、プラグインとしてまとめて配る方法があります。公式の「Manage Claude Code plugins for your organization」では、会社の設定で、プラグインの置き場所（マーケットプレイス）を全員の端末に登録し、使うプラグインを指定して、全員の端末に入れられると説明しています。利用者が自分で追加できるプラグインの置き場所を、会社として認めたものだけに絞ることもできます。

最初からプラグインにする必要はありません。まずは1つのリポジトリの skill として使ってみて、ほかのチームでも同じ手順が必要になった段階で、プラグインにまとめるのが無理のない順番です。

AI が書いたコードのレビューを仕組みにする

使う人が増えると、AI が書いたコードの量も増えます。確かめる人と基準が追いつかないと、品質への不安から、使うこと自体が止まってしまいます。

Team と Enterprise のプランには、GitHub のプルリクエストを Claude が確かめる「Code Review」があります。公式の説明では、複数のエージェントが変更と周りのコードを読み、論理の誤りやセキュリティの弱点などを探し、確かめたうえで、該当する行にコメントを付けます。既定では、見た目の好みではなく、本番で問題になる誤りに絞って指摘します。レビューがプルリクエストを承認したり、止めたりすることはなく、マージの判断はチームに残ります。何を指摘させるかは、リポジトリに置く REVIEW.md や CLAUDE.md で調整できます。

使うには、Claude の組織のオーナーが設定し、Claude の GitHub アプリを入れる必要があります。費用は「Code Review costs and usage」によると、プランに含まれる量とは別に、追加の利用（usage credits）として会社に請求されます。リポジトリを追加したときの既定の設定は、プッシュのたびにレビューが動く設定で、レビューの回数がいちばん多くなります。プルリクエストを作ったときに1回だけ、コメントで頼んだときだけ、という設定もあるため、最初は回数の少ない設定から始めると、費用の見通しを立てやすくなります。

公式の注意書きにあるとおり、AI によるレビューは誤りを見落とすことがあり、指摘がないことは、コードに問題がないことを意味しません。人のレビューを置き換えるものではなく、人が見る前に、明らかな誤りを減らす仕組みとして使うのがよいと考えています。Code Review を使わない場合でも、どのプランでも Claude Code のセッションの中で /code-review を実行して、自分の変更を確かめることもできます。

段階4：全員に広げ、使われ方と費用を見る

使われ方は、管理画面で見られる

「Track team usage with analytics」によると、Team と Enterprise のプランでは、管理者とオーナーが Claude Code の分析画面を見られます。表示されるのは、たとえば次のような数字です。

プルリクエストに関する数字は、公開ベータの機能で、Claude のオーナーが分析の設定を有効にし、GitHub の管理者が Claude の GitHub アプリを入れる必要があります。公式の説明では、これらの数字は、Claude Code が関わったと確信が持てるものだけを数えた、控えめな数字だとされています。

数字の見方の注意

分析画面には、使った量の多い人を並べたランキングもあります。ただ、受け入れた行数やプルリクエストの数は、使った量を表すもので、コードの質や、仕事の成果をそのまま表すものではありません。クリーヴァでは、こうした数字を人の評価には使わず、次のような判断の材料にするのがよいと考えています。

• ほとんど使われていないチームがあれば、つまずいている所を聞きに行く
• 受け入れ率が低い場合は、CLAUDE.md や確かめ方が足りていないかを見直す
• 使う人が増えたのに、プルリクエストの流れが変わらない場合は、レビューが詰まっていないかを見る

費用は、席の使える量と上限で管理する

公式の「Manage costs effectively」によると、Team と Enterprise のプランでは、Claude Code の利用は席ごとの使える量から引かれます。この量は5時間ごとと1週間ごとに戻り、チャットや Cowork と共通です。量の大きさは、席の種類（Standard と Premium）で決まります。

使える量を超えて使えるようにするには、追加の利用（usage credits）を有効にし、会社全体、グループ、メンバーごとに支出の上限を決められます。メンバーごとの推定の支出は、分析の設定にある支出のレポートで確かめられます。

席の種類の違いと選び方は、「Claude を法人で契約するには」にまとめています。クリーヴァは Team プランを使い、毎日コードを書く担当には Premium、使う場面が限られる担当には Standard の席を割り当てています。

新しく入った人の始め方をそろえる

全員に広げるときは、新しく使い始める人の手順をそろえておきます。公式の手順では、次のようなものを共有するよう勧めています。

• Quickstart：インストールから、最初の作業までの流れ
• Common workflows：コードのレビュー、リファクタリング、不具合の調査などのよくある使い方
• Claude Academy の無料の講座（Claude Code 101、Claude Code in Action）

これに、自社の CLAUDE.md の場所、使ってよいプランと席、/status で会社の設定が届いているかを確かめる手順を足しておくと、問い合わせが減ります。

使い始めでよくあるのは、ログインの問題です。公式の手順では、アカウントを切り替えるには /logout のあとに /login を実行すること、会社のログインの選択肢が出ないときは claude update で更新することが挙げられています。また、「You haven’t been added to your organization yet」と表示される場合は、その人の席に Claude Code の利用が含まれていないため、管理画面で席を見直す必要があるとされています。こうした「最初の10分でつまずく所」を、始め方の資料に先に書いておきます。

段階ごとのチェックリスト

定着しないときに見直すこと

広げたあとで使われなくなったときは、次の点を見直します。

• 試した仕事が、実際の仕事とずれていなかったか。練習用の題材でうまくいっても、自社のリポジトリで同じようにいくとは限りません。
• CLAUDE.md が長くなりすぎていないか。毎回読み込まれるため、関係の薄い指示が増えると、肝心の指示が埋もれます。
• 確かめ方が渡されているか。テストや静的解析がない作業では、人が毎回すべてを確かめることになり、手間が減りません。
• 会社の設定が厳しすぎないか。強制する決まりが多すぎると、必要な作業まで止まり、使われなくなります。
• レビューの体制が追いついているか。AI が書いたコードが増えても、確かめる人と基準がなければ、品質への不安から使われなくなります。

おわりに

Claude Code を定着させるには、席を配ったあとに、少人数で試す、会社の設定を配る、チームの手順を残す、使われ方を見る、という4つの段階を順に進めることが近道です。公式のドキュメントも、小さなグループで基準の数字をとってから広げること、例外なく守ることは指示ではなく仕組みで止めること、CLAUDE.md は短く保つことを勧めています。

まずは、実際の仕事を題材に、少人数で2〜3の作業を試してみてください。そこで記録した「何度も説明したこと」と「止めたかった操作」が、チーム全体の CLAUDE.md と会社の設定の出発点になります。

• Claude を法人で契約するには：Team・Enterprise・API の違いと、Claude Code を会社で使うときの選び方
• Claude Code を会社で安全に使う：情報漏洩を防ぐ設定と社内ルール【2026年版】
• Claude Code を非エンジニアが業務で使う：できることと、エンジニアに頼るべき場面