Claude Code社内展開の30日プレイブック — チャンピオン1人から広げる進め方

Claude Code社内展開は告知より現場の1人から広がる

Claude Codeの社内展開は、告知だけではなかなか進みません。1人のエンジニアが自分の作業で使い続け、それを公開の場で見せることで広がります。Anthropicが公開するChampion kitは、この「チャンピオン」役を担うエンジニア向けに、何を共有し、どう質問に答え、30日でどう仲間を増やすかを具体的に示しています。

開発ツールの導入がロールアウト告知だけで進むことはめったにありません。誰か1人がそのツールをうまく使いこなし、それを隠さずに話し、周りが真似しやすい形にしたときに広がります。チャンピオンが共有する1つの実例は次に触る人の学習曲線を縮め、公開の場で答えた1つの質問はその人1人の経験をチーム全体の知識に変えます。この積み重ねは、小さな行動のわりに大きな効果を生みます。

この記事では、Champion kitの30日プレイブックを軸に、週ごとに何をするか、うまくいっている合図は何か、そしてよくあるつまずきをまとめます。対象は特定のチームやプロジェクトを持ち、すでにClaude Codeを自分の仕事で使っているエンジニアです。管理者向けの告知文はFAQ想定問答とプロンプトテンプレ集にあります。CLAUDE.md規約やレビュー体制はClaude Codeチーム導入ガイドの領分です。ここで扱うのは現場発の草の根展開です。

チャンピオン1人の負担は週にどれくらいか

チャンピオン役は追加の仕事ではなく、自分の作業に乗せる形で回します。Champion kitが示す時間配分は次の通りです。

ペアリングが発生しない週なら合計40分程度、詰まっている人への対応が重なる週でも最大70分程度で収まる設計です。この役割は既存業務の乗数であって、サポート担当への横滑りではありません。上長にもこの前提を先に伝えておくと、後から「兼務が重い」という話にならずに済みます。

実例はどこに投稿すると効くか

投稿先は、チームがすでに読んでいる場所を選びます。新しい行き先を作るより、普段の作業の導線上に置くほうが目に触れます。

プルリクエストは、レビュアーがすでに読んでいるコードで実演できる投稿先です。本来の業務で読むコードなので、追加の説明を探しに行く必要がありません。

1週目 — チャンネルを立ち上げ、自分の実例を見せる

最初の1週間でやることは、場所を作って自分の経験を置くことだけです。#claude-codeのようなチャンネルを作り、Quickstartのリンクと強い実例を1本ピン留めし、実例を2〜3本投稿します。

投稿する価値があるのは「結果」ではなく「明日ほかの人が真似できる技」です。結果の報告は読まれて終わりますが、技は広がります。

今日学んだこと: ディレクトリを@メンションできる。
@src/components/ を指定して、テストが無いものはどれか聞いたら
見落としていた2つが出てきた。

長いタスクが終わったらデスクトップ通知が来るようStop hookを設定した。
リファクタを走らせて離席し、終わったタイミングで通知が来た。
設定はスレッドに貼ってある。

デスクトップ通知の設定方法はClaude Code通知の設定にまとめています。

Plan modeを使った投稿も効果的です。Champion kitの例文は「Plan modeは変更案を先に並べるので、共有コードでも安心して使える」という趣旨で、まだ試していない同僚の不安を下げます。承認フローの詳細はClaude Code Planモード完全ガイドにあります。

投稿に「Shift+Tabを押す」とだけ書くと、同僚が迷うことがあります。Shift+Tabは権限モードを順に切り替えるキーで、押す回数は今のモード次第です。autoモードから始めると、最初の1回でdefaultに戻り、acceptEdits、planの順に進みます。planに入るとステータスバーに ⏸ plan mode on と出ます。

迷わせたくないときは、起動時に指定する方法を添えます。

claude --permission-mode plan

claude --help のv2.1.289では、--permission-mode に渡せる値は acceptEdits / auto / bypassPermissions / manual / dontAsk / plan の6つです。セッション中なら、プロンプトの先頭に /plan を付けると、その1回だけ計画から始められます。

1週目の目標達成の目安は、誰かがリアクションか返信をつけ、チャンネルで最低1件の質問が出ることです。反応がゼロのまま1週間が終わったら、投稿の頻度ではなく「その実例が同僚の日常業務と重なっているか」を見直します。

2週目 — リズムを作り、質問に公開で答える

2週目の主眼は継続性です。毎週金曜に「今週Claudeが助けてくれたことは?」と投げるだけの雑談スレッドを始め、準備や資料は要りません。スクリーンショットと一言で十分です。

質問への回答は説明よりプロンプトそのものを渡します。「どうやってそのレースコンディションを見つけたんですか」と聞かれたら、「@tests/scheduler.test.tsのテストが不安定なので原因を調べて、と頼んだら未joinのPromiseが2つ見つかりました。同じ言い回しを試してみてください」と、実際に使った文言で返します。ドキュメントへのリンクより、いま詰まっている1点を外す一言のほうが効きます。

この週にカスタムSkillを1つ共有するのもおすすめです。.claude/skills/<name>/SKILL.mdはただのMarkdownなので、テストとlintをコミット前に走らせる/shipのようなSkillを投稿すれば、同僚はすぐに自分の環境へ取り込めます。SKILL.mdの書き方とfrontmatterの全項目はClaude Code Skills完全ガイドにまとめています。

Skillを書く時間がない週は、/team-onboarding が代わりになります。過去30日間のセッション、コマンド、MCPサーバーの利用履歴から、同僚が最初のメッセージとして貼れるMarkdownのガイドを作るコマンドです。長く使ったプロジェクトで実行し、できたガイドをチャンネルにピン留めします。所要は2分ほどです。Pro、Max、Team、Enterpriseのclaude.aiサブスクライバーなら、同僚がClaude Codeで直接開ける共有リンクも返ります。

2週目が回っているかどうかは、自分以外の誰かが、その人自身の実例をチャンネルに投稿するかで判断します。

3週目 — ペアリングとFAQへの集約

3週目は個別支援とナレッジの集約に充てます。詰まっている同僚に15分のペアリングを2〜3件提供します。プレゼンや資料より、本人のコードで1回成功体験を作るほうが説得力があります。

並行して、繰り返し聞かれる質問と回答を1つのピン留めメッセージにまとめます。Champion kitが挙げる典型的な質問は次のようなものです。

CLAUDE.mdに何を書き、どう育てるかの具体パターンはClaude CodeのCLAUDE.mdを実用に引き上げる10のパターンで扱っています。「セキュリティやデータの扱いはどうなっているか」という質問だけは、Champion kitも管理者へ回すよう明記しています。チャンピオンが即興で答える領域ではないためです。

うまくいっている合図: 一度試して終わりではなく、同じ顔ぶれが繰り返し使いに来ることです。

同僚が「使うかどうか」の段階を超えて「もっと使いこなすには」という段階に進んだら、チャンピオンの役目は入り口の案内までです。そこから先はQuickstartやCommon workflowsのような公式ドキュメントに橋渡しします。自分1人で全員のオンボーディングプログラムになろうとしないことが、この役割を軽く保つコツです。

4週目 — 次のチャンピオンに引き継ぐ

最終週の仕事は、自分を中心にした状態を終わらせることです。チャンネルで一番質問してきた同僚が、次のチャンピオン候補として最も自然です。その人にChampion kitのページを渡し、チャンネルの役割を分担します。

あわせて、うまくいったことと、うまくいかなかったことを上長か管理者に一言で共有します。プログラムを作る必要はなく、30日で見えた事実を渡すだけで十分です。

うまくいっている合図: 自分以外の人が、チャンネルの質問に答えるようになっていることです。ここまで来れば、この役割はいったん仕事を終えたと言えます。

管理者側から見れば、この段階は次のチャンピオンを公式に頼む好機でもあります。声のかけ方の文面はClaude Code社内展開のFAQ想定問答とプロンプトテンプレ集で扱っています。

そのまま貼れるクイックリファレンス

質問への回答に迷ったら、次の技だけをまとめたシートをチャンネルにピン留めしておくと便利です。Champion kitが「最初の1回を日常利用に変える」技として挙げているものです。

Claude Code社内展開でよくあるつまずき

30日プレイブックを実際に回すと、次のようなつまずきが繰り返し起こります。

• 投稿を清書してしまう: 長い書き込みは後で読もうと保存されて忘れられます。スクリーンショット+一言のほうがその場で試されます
• 一般的な例を使う: 抽象的なデモではなく、自分たちのコードベースにある実際のバグや退屈な作業を材料にします
• 質問に個別DMで答える: せっかくの回答が本人にしか届きません。公開チャンネルで答えれば、同じ疑問を持つ人全員に届きます
• セキュリティの質問に自己流で答える: 組織のデータ取り扱い方針はすでに管理者側で設定されています。チャンピオンが推測で答えると後から食い違いが出ます。セキュリティや懸念への回答の作り方はClaude Code社内展開の懸念とセキュリティへの回答集にまとめました
• 「一度試したら間違えた」を放置する: Champion kitはこの手の不満を、モデルの問題より文脈不足とみなします。@で関連ファイルを渡し、/initを実行し、実際のエラー出力を添えて同じプロンプトを再実行してもらいます
• 1人で続けようとする: 4週目に後継者を立てないと、その人が異動や多忙になった瞬間に活動が止まります

まとめ — このプレイブックが向いているチーム

このプレイブックは、Claude Codeをすでに自分の仕事で使っていて、チームにも広げたい1人のエンジニアに向いています。管理者からのトップダウンな展開と、現場発のこのボトムアップな動きは対立しません。むしろ両輪です。CLAUDE.md規約やレビュー体制のような制度設計はClaude Codeチーム導入ガイドが担い、このプレイブックは制度が固まる前の「誰も使い方を知らない」段階を埋めます。

30日という期間そのものに強い意味はありません。目安として使いつつ、各週の「うまくいっている合図」が出るまで足踏みしてから次に進むほうが、日付を守ることより効果があります。