Claude Code社内展開のFAQとプロンプトテンプレ集
Claude Codeを社内に展開するときに聞かれる質問への一言回答と、インストール後の1本目のプロンプトとして配れるテンプレートを、公式Communications kitからまとめます。
このFAQとプロンプトテンプレ集でできること
Claude Codeの社内展開では、告知の直後に同じ質問が何件も届き、インストールした人の大半が「で、何を頼めばいいのか」で止まります。AnthropicのCommunications kitは、この2つの詰まりに対して、そのまま貼れる一言回答と、配布用のプロンプトテンプレートを用意しています。この記事ではその中身を、社内Slackやメールにそのまま流用できる形でまとめます。
チャンネル運営や30日単位の展開計画、セキュリティ懸念への回答は別記事に譲り、ここでは「聞かれたら何を返すか」と「最初に何を打ち込ませるか」に絞ります。この2つさえ手元にあれば、告知した本人が質問攻めで身動きが取れなくなる事態を避けられ、聞かれるたびに同じ説明を書き直す手間も要らなくなります。
この2種類の資料が効くタイミングは限られています。告知の直後48時間、つまり最初にインストールした人たちが「使ってみたが何をすればいいか分からない」状態にいる短い窓です。この窓を逃すと、インストールしたまま放置されるアカウントが積み上がり、後から個別に掘り起こすコストのほうが高くつきます。
よくある質問
インストール後に届く質問の大半は、次の6パターンに収まります。個別に文面を考える代わりに、この6問への回答をあらかじめ社内Wikiか固定メッセージに用意しておけば、同じ説明を繰り返す時間をほぼゼロにできます。
VS Codeで使えますか
使えます。VS Code拡張とJetBrainsプラグインがあり、ターミナル版と同じ機能をエディタに埋め込んだ形で使えます。詳しい導入手順はClaude Code VS Code拡張機能の使い方にまとめています。
事前に何か設定する必要がありますか
ありません。インストール後、任意のリポジトリでclaudeと実行するだけです。最初に/initを1回実行すれば、そのリポジトリの規約を読み込んだ状態になります。
自分のコードはどこへ送られますか
CLIはターミナル上で動作し、推論のためのやり取りはAnthropicのAPIに直接送られます。第三者のサーバーを経由しません。Enterpriseプランでは、コードやプロンプトはモデルの学習には使われません(データの扱いはData usageに契約形態別の詳細があります)。この質問を深掘りしたい場合や、セキュリティレビューでさらに突っ込まれた場合の答え方はClaude Code社内展開の懸念とセキュリティへの回答集にまとめています。
リポジトリ全体を勝手に読まれますか
アクセスを与えた範囲だけを読みます。作業ディレクトリ内のファイル読み取りは確認なしに進みますが、ファイルの編集や読み取り専用でないシェルコマンドの実行、作業ディレクトリの外側にあるファイルの読み取りは承認が必要です。lsやcatのような読み取り専用の組み込みコマンドは確認なしで動作し、これを制限したい場合はサンドボックスのdenyReadルールで絞り込めます。「うちのモノレポの一部だけに触らせたい」という質問が来たときも、この仕組みで範囲を絞れると答えられます。
Copilotと何が違いますか
Copilotは行単位の補完が中心です。Claude Codeはファイルを読み、コマンドを実行し、複数ファイルにまたがる変更を行うエージェントです。単純な入力補完ではなく、タスクを最後まで進める前提の設計です。この違いを言葉で説明するより、実際に「このバグを直して」と頼んで動きを見せるほうが早く伝わります。
最初は何を試せばいいですか
面倒だからと後回しにしているバグが一番向いています。「[ファイル]のテストが不安定なので原因を調べて直して」のように、実在する自分のタスクを渡すのが最短です。新規に何かを作る作業より、すでにある不具合を調べさせる作業のほうが、Claude Codeがコードベースを読みに行く様子が見えるぶん信頼を作りやすい傾向があります。
元のCommunications kitのFAQは、Slackにそのまま貼れる一言回答として作られています。配布するときは元の一言に近い形へ削って構いません。長い説明を読ませることが目的ではなく、質問した人がその場で疑問を解消できることが目的だからです。
配布する前に、次の3点だけ確認しておくと展開初日の混乱を防げます。
- インストールコマンドを自分たちのネットワーク環境で1台試しておく(プロキシやファイアウォールの問題は全員が同時に踏む前に見つかる)
- 質問の受け皿になるチャンネルを先に作り、FAQのリンクをそこに固定しておく
- 最初の48時間、誰がこのFAQへの質問に目を配るかを決めておく
配布用プロンプトテンプレート
インストールしたものの何を頼めばいいか分からない人には、説明より実際に打ち込めるプロンプトを渡すほうが効きます。表中の角括弧[ ]は、渡す相手のリポジトリにある実在のファイル名・モジュール名・issue番号に置き換えてから渡します。
| やりたいこと | プロンプト |
|---|---|
| バグを直す | プロンプト「[ファイル]のテストが落ちている、原因を調べて直して」 |
| コードを理解する | プロンプト「[モジュール]がどう動くか説明して、エントリーポイントも教えて」 |
| 安全にリファクタする | プロンプト「[モジュール]を[目的]のためにリファクタして、レビューできるようPlan modeを使って」 |
| テストを書く | プロンプト「[ファイル]のテストを、[シナリオ]周りの境界値も含めて書いて」 |
| コミット前にレビューする | プロンプト「今のdiffを見て、リスクがありそうな箇所を教えて」 |
| PRを開く | プロンプト「[issue]を直して、Conventional Commits形式でコミットし、要約付きのPRを開いて」 |
| Skillを作る | プロンプト「コミット前にテストとlintを走らせる/shipというSkillを作って」 |
| スタックトレースを調べる | プロンプト「このスタックトレースから根本原因を見つけて、その場しのぎの対処はしないで」 |
「安全にリファクタする」の行にあるPlan modeは、変更前に何をするかを提案させ、承認してから実行させる仕組みです。使い方の詳細はClaude Code Planモード完全ガイド、「コードを理解する」の行のようなCLAUDE.mdの前提知識を厚くしたい場合はClaude Code memoryの三層構造を参照してください。
8つのテンプレートを一度に全部渡す必要はありません。相手がまだ何も試していないなら「バグを直す」か「コードを理解する」の2つだけで十分です。逆に、すでに何度か使っていて次のステップに進みたそうな人には「Skillを作る」や「PRを開く」のような、日常のワークフローに踏み込むテンプレートのほうが響きます。相手が今どの段階にいるかで渡すテンプレを変えるだけで、同じ表がずっと使い回せます。
テンプレをそのまま使わないほうがいい理由
Communications kit自身が明記している通り、これらの文面は下書きであって完成品ではありません。プレースホルダーを埋めるだけでなく、文体も自社の言葉に書き直すことが前提です。展開を後押しするのは、いかにも自社の誰かが書いたと分かる文面であって、外部のテンプレをそのまま貼った文面ではありません。
同じ理由で、FAQの回答も一言で終わらせず、自分たちの契約形態(Team・Enterpriseの別やZero Data Retentionの有無など)に合わせて数値や条件を書き換えてから配布します。テンプレはゼロから書く手間を省くための土台であり、正確さの最終確認を代替するものではありません。
例えば「コードはどこへ送られますか」への回答は、Zero Data Retentionを契約している組織なら「サーバー側にデータは残りません」という一文を付け加えると正確になりますし、個人プランを併用しているメンバーがいる組織なら、学習利用の設定が個人アカウントごとに異なる旨も添えておくと誤解を防げます。この書き換え作業は展開の担当者が1回やれば済み、以降は同じFAQページを使い回せます。
誰がこのFAQとテンプレを管理するか
告知を送った本人がすべての質問に答え続けるのは長続きしません。Champion kitが勧めるように、展開の初期に育った現場のチャンピオンにFAQページの更新権限を渡し、新しい質問が出るたびに追記してもらう運用が現実的です。管理者はセキュリティや契約条件のような、チャンピオンの裁量を超える項目だけを確定させ、それ以外の日常的な質問への追記はチャンピオンに任せるという役割分担が、Communications kitとChampion kitの両方に共通する前提です。この線引きを最初にはっきりさせておかないと、チャンピオンが答えていい範囲まで管理者が抱え込み、せっかくの分担が機能しなくなります。チャンピオンの育て方そのものはClaude Code社内展開の30日プレイブックにまとめています。
プロンプトは、渡す側がプレースホルダーを埋めた状態で相手に届けるほど効果が上がります。相手はコピーして貼るだけで最初の1回を体験できるので、表を見せられただけの状態より試される確率が上がります。逆に、プレースホルダーを埋めないまま「これを参考にしてください」と表ごと渡すと、結局は各自が自分のタスクに合わせて考え直す手間が発生し、テンプレートを配った意味が薄れます。
配布後に来る追加の質問への線引き
FAQと配布用プロンプトを送った後も、個別の質問はゼロにはなりません。ここで管理者が全部を拾いに行くと、告知した本人がまた質問攻めに逆戻りします。目安になるのは、質問の性質がチャンピオンの裁量で答えられる範囲か、契約条件やセキュリティ判断が絡む範囲かという線引きです。
- 「このプロンプトを自分のタスク向けに書き換えたい」「Skillの中身を直したい」のような使い方の相談は、現場のチャンピオンが日常的に拾える範囲です
- 「監査ログはどこに残るか」「特定のリポジトリだけアクセスを制限したい」のような契約・セキュリティに踏み込む質問は、管理者が確定させる範囲として残します
- 判断に迷う質問が出た場合は、いったんチャンピオンが預かり、管理者に確認してからFAQへ追記する運用にすると、同じ質問が二度目に来たときはチャンピオンだけで完結します
この線引きをFAQページの冒頭に一言添えておくだけで、「これは誰に聞けばいいのか」という余計な往復を減らせます。