「導入は決まったが、誰がどう社内に広げるのか」でつまずく相談が多い。ライセンスは配ったのに使う人が増えない、逆に一部の人が勝手に使い始めて誰も全体を把握していない——どちらも同じ問題の裏表で、「展開の進め方」を決めずにアカウントだけ配った結果だ。
面白いことに、Anthropic自身の公式ドキュメントにも、この2つの進め方がそれぞれ別のページとして存在する。情シス・管理者向けの組織セットアップガイドと、現場のエンジニア向けのチャンピオンキットだ。前者は権限・設定・監視をどう固めるかという統制の型、後者は一人のエンジニアがどう同僚に広げるかという普及の型で、書かれている前提も対象読者もまったく違う。どちらから手をつけるべきかを、2つの公式ドキュメントに沿って比較する。
選択肢を並べる:2つの型
管理者主導型(Top-down)。 組織セットアップガイドは「管理者が展開にあたって決めるべきことの地図」という位置づけで、①どのAPIプロバイダーを使うか②設定をどう端末に届けるか(管理コンソール・MDM・ファイル配布)③何を許可・拒否するか(権限ルール・サンドボックス・MCPサーバー制限)④利用状況をどう可視化するか(分析ダッシュボード・コスト管理)⑤データの取り扱いをどう確認するか、という5つの決定事項を順に並べている。展開の規模を問わず「まず決めるべきこと」として整理されており、現場の利用実態が先にあることは前提にしていない。
現場主導型(Bottom-up)。 チャンピオンキットは対象読者が明確に違う。「すでにClaude Codeを使っていて、チームに広げたい一人のエンジニア」向けに書かれたページで、管理者権限も予算も前提にしない。冒頭の一文がこのページの立場を要約している。
Adoption of a developer tool rarely happens because of a rollout announcement. It happens because someone on the team begins using the tool well, talks about it openly, and makes it easy for others to follow. (開発ツールの定着は、展開のお知らせによって起きることはめったにない。誰かがそのツールをうまく使い始め、それを公然と話し、他の人が後に続きやすくすることによって起きる。)
チャンピオンの役割は「発見を共有する」「質問される人になる」「輪を広げる」の3つに整理されており、想定される負荷も具体的だ。週あたり、成果やプロンプトの投稿に約15分、共有チャンネルでの質問対応に約20分、週次の共有スレッド運営に約5分——「通常の業務時間に収まる範囲」であることが明記されている。展開の進め方として30日間のプレイブックも用意されている。
| 週 | やること | うまくいっているサイン |
|---|---|---|
| 1週目 | チャンネルを作り、Quickstartを固定し、自分の実例を2〜3件投稿する | 誰かが反応するか、チャンネルで質問が出る |
| 2週目 | 週次の共有スレッドを始め、質問には公開の場で答え、カスタムスキルやCLAUDE.mdの一例を共有する | 自分以外の誰かが自分の実例を投稿する |
| 3週目 | 2〜3件のペア作業を行い、よくある質問をFAQにまとめる | 同じ人が繰り返し使うようになる(一度試して終わりでない) |
| 4週目 | 次のチャンピオンを見つけ、うまくいっている点・いない点を上長や管理者に共有する | チャンネルの質問に自分以外の人が答えるようになる |
判断を左右する軸
| 軸 | 管理者主導型 | 現場主導型 |
|---|---|---|
| 始めるのに必要な権限 | 管理コンソールへのアクセス(Team/Enterprise契約が前提) | 特別な権限は不要。個人がその日から始められる |
| 主導する立場 | 情シス・DX推進・管理者 | 現場のいちエンジニア |
| 最初の手応えが出るまで | 5つの決定事項をすべて詰めてから配布するため時間がかかりやすい | 30日プレイブックの設計上、1〜2週目で最初の反応が出る想定 |
| 広がり方の性質 | トップダウンの強制力はあるが、使うかどうかは各自の判断に委ねられる | 「同僚が実際に使っている実例」を起点にした口コミに近い広がり方 |
| 抜け落ちやすいリスク | ライセンスだけ配って誰も使わない「配ったのに広がらない」状態 | 統制のないまま利用が先行する「誰が何にどう使っているか把握できない」状態 |
現場主導型の「口コミに近い広がり方」は、以前の記事で扱ったMicrosoft社内の実証研究とも符合する。数万人規模の追跡調査でも、最初の利用は社内の口コミ経由で広がり、定着は役職より「導入前の活動量」と相関していた。チャンピオンキットが管理者ではなく現場のエンジニアに向けて書かれているのは、この広がり方の性質を踏まえた設計だと読める。
一方で、Claude Codeの生みの親であるBoris Cherny氏が示した組織のAI導入成熟度モデルが指摘するように、一人が使いこなせても組織全体は変わらない。チャンピオン1人の周りに輪が広がっても、それが「一部の人だけが使いこなすチーム」で止まってしまうなら、管理者主導型が担う権限設計・利用状況の可視化がどこかで必要になる。
詰まりやすい箇所
管理者主導型だけで進めて、誰も使わない。 権限ルールとmanaged settingsを完璧に整えてから展開しても、現場が「なぜ使うといいのか」を実感していなければアカウントは配られるだけで終わる。管理設定をどこまで強制するかの考え方は以前の記事にまとめてあるが、これは「何を許可するか」の設計であって「使いたくなるきっかけ」を作る設計ではない。
現場主導型だけで進めて、無統制になる。 チャンピオンキット自身も、セキュリティやデータ取り扱いについて聞かれたら「管理者に確認してほしい、チャンピオンが即興で答えるべきではない」と明記している。つまりチャンピオンキットは、管理者側の設定がすでにある前提で書かれたページであり、現場の普及だけで完結する設計にはなっていない。
「展開プロジェクト」を大掛かりに構える。 チャンピオンキット側の时間配分(週15〜20分程度)が示すように、現場主導型はそもそも専任の推進担当や正式なプログラムを前提にしていない。中小企業が最初につまずきやすいのは、逆に「きちんとした展開計画」を作ろうとして着手が遅れることだ。
自社で判断する基準
中小企業にとって現実的な順序は、どちらか一方を選ぶことではなく、着手の順番を決めることだ。最初に必要なのは現場主導型——小さく試して使う人を1人作り、その人が同僚に広げる30日間を経験することで、初めて「何を許可し何を制限すべきか」の実像が見えてくる。管理者主導型の5つの決定事項は、この実像ができてから詰める方が手戻りが少ない。ただし例外として、権限ルール(何を許可・拒否するか)の最低限の設計だけは、現場利用が広がる前に並行して決めておく必要がある。ここを後回しにすると、無統制な利用が先に広がってから統制をかけ直す、いちばん手間のかかる順序になる。
自社の規模・体制でどちらから着手すべきか、権限設計をどこまで並行して固めるべきか整理したい場合は、パイロット・構築のフェーズで一緒に検討できる。まずは30分の無料診断から相談してほしい。