Claude Code社内展開のFAQとプロンプトテンプレ集
Claude Codeを社内に展開するときに聞かれる質問への一言回答と、インストール後の1本目のプロンプトとして配れるテンプレートを、公式Communications kitからまとめます。
このFAQとプロンプトテンプレ集でできること
Claude Codeの社内展開では、告知の直後に同じ質問が何件も届き、インストールした人の多くが「で、何を頼めばいいのか」で手が止まります。AnthropicのCommunications kitは、この2つの詰まりに対して、そのまま貼れる一言回答と配布用のプロンプトテンプレートを用意しています。この記事では、その中身に権限とデータ保持の公式仕様も補足し、社内Slackやメールで流用できる形にします。
告知メールやパイロットDMの文面はClaude Code導入アナウンス文とパイロットDMのテンプレートにあります。ここでは「聞かれたら何を返すか」と「最初に何を打ち込ませるか」を扱います。
配布前に決めておく3点
kitの「送信前チェックリスト」は6項目で、うち3つがFAQの運用に直結します。
FAQを流す前の準備
- 1
質問の受け皿を作る
#claude-codeのようなチャンネルを先に作り、FAQのリンクをそこに固定します。質問の置き場が決まっていれば、DMやスレッドに散らばりません。 - 2
インストールを1台で試す
自社のネットワーク環境で、インストールコマンドを少なくとも1台で通しておきます。プロキシやファイアウォールの問題を、全員が同時に踏む前に見つけるためです。
- 3
最初の48時間の担当者を決める
kitは「最初の48時間にチャンネルの担当者を置く」ことを勧め、答えのない質問が勢いを止めると書いています。
残りの3項目は、データの扱いを説明するリンクの用意、自社コードベースの実在するバグやファイルから選んだ最初のタスク、告知に名前を出す経営層のスポンサーです。
よくある質問
kitのFAQ表は6問で、答えは一言に収めてあります。ここではそれぞれに、公式の権限・データ仕様から分かる補足を付けます。
VS Codeで使えますか
使えます。VS Code拡張とJetBrainsプラグインがあり、kitによればターミナル版と同じ機能をエディタに埋め込んだ形です。導入手順はClaude Code VS Code拡張機能の使い方にあります。
事前に何か設定する必要がありますか
ありません。インストール後、任意のリポジトリでclaudeを実行します。最初に/initを1回実行すると、ビルドコマンドや規約をまとめたCLAUDE.mdが書かれ、以後のセッションはそれを自動で読みます。kitのSlack向け告知文は、クイックスタートとVS Codeのページ、1時間の無料コースへのリンクも添えています。
自分のコードはどこへ送られますか
CLIはターミナルで動き、推論のために文脈をAnthropicのAPIへ送ります。学習に使われるかどうかはプランで分かれます。
コードとプロンプトの学習利用と保持期間
Free・Pro・Max
学習への利用は設定で選びます。許可すると保持は5年、許可しないと30日です。Claude Codeをこれらのアカウントで使う場合も同じです。
Team・Enterprise・API
顧客が学習提供を選ばない限り、Claude Codeに送ったコードやプロンプトで生成モデルは学習されません。標準の保持期間は30日です。
Zero Data Retentionは標準のEnterpriseには含まれません。Claude for Enterpriseの適格なアカウントに対し、アカウントチームが資格を確認したうえで組織ごとに有効にします。適用範囲にも条件があり、メンバーが個人アカウントや別組織のAPIキーでサインインしたセッションは対象外です。また、AnthropicのダイレクトなプラットフォームだけがZDRの対象で、Bedrockなどは各社の方針に従います。社内の回答は、自社がどの契約にいるかで書き換えます。個人プランを併用するメンバーがいる組織は、上の左側の条件が個人アカウントに適用される点も添えておくと誤解を防げます。セキュリティレビューで深掘りされたときはClaude Code社内展開の懸念とセキュリティへの回答集が使えます。
リポジトリ全体を勝手に読まれますか
起動したディレクトリ(作業ディレクトリ)と追加したディレクトリの中のファイル読み取りは、確認なしで進みます。Manualモードでは、ファイルの編集は確認が要り、lsやcatなど組み込みの読み取り専用コマンド以外のシェル実行も確認が要ります。追加のディレクトリには、--add-dirで起動時に、またはセッション中に/add-dirで加えます。
承認の出し方は--permission-modeで選べます。v2.1.287のclaude --helpでは選択肢が次の6つです。
--permission-mode <mode> (choices: "acceptEdits", "auto",
"bypassPermissions", "manual",
"dontAsk", "plan")「うちのモノレポの一部だけに触らせたい」という要望には、2系統の設定が絡みます。ReadやEditツールの範囲はpermissionsのdenyルールで絞ります。このルールは、Bashで動くcat、head、tail、sed、teeのような認識されたファイル系コマンドにも効きます。一方、PythonやNodeのスクリプトが自分でファイルを開く場合は対象外です。そこはサンドボックスのdenyReadでOS側から絞ります。サンドボックスは既定でオフで、/sandboxを実行するかsandbox.enabledをtrueにして有効にします。有効にしても、denyReadはReadツールを止めません。認証情報ファイルまで対象にする設定はsandbox.filesystem.denyReadで解説しています。
Copilotと何が違いますか
kitの一言回答は、Copilotは行を補完し、Claude Codeはファイルを読み、コマンドを実行し、複数ファイルを編集するエージェントだというものです。言葉で説明するより、実際に「このバグを直して」と頼んで動きを見せるほうが伝わります。
最初は何を試せばいいですか
先送りにしている面倒なバグが向いています。kitの例は「[ファイル]のテストが不安定なので原因を調べて」で、自分のコードベースの実在するファイルに差し替えて渡します。
どのモデルを選べばいいですか
kitのFAQ表には無く、Tips集にある質問です。Sonnetが日常の機能追加・バグ修正・テスト・レビュー向けの既定、Opusが大規模なリファクタや難しいデバッグ向け、Haikuが短い質問や機械的な編集向けです。Fableは最難関で長時間のタスク向けで、既定にはならないため/model fableで選びます。
社内のセキュリティやバイオ分野の担当者からは、モデルが途中で切り替わるのかという質問も出ます。サイバーセキュリティやバイオ分野の内容は、Fableでは自動的にOpusへフォールバックします。Opus 5.5・Sonnet 5.5・Opus 5でも検査が働き、該当する内容は同じ系列の前のモデルへ切り替わります。ただしOpus 5とSonnet 5.5では、バイオ分野の該当内容は拒否されます。
配布用プロンプトテンプレート
インストールしたものの何を頼めばいいか分からない人には、説明より実際に打ち込めるプロンプトを渡すほうが効きます。表中の角括弧[ ]は、渡す相手のリポジトリにある実在のファイル名・モジュール名・issue番号に置き換えてから渡します。
| やりたいこと | プロンプト |
|---|---|
| バグを直す | プロンプト「[ファイル]のテストが落ちている、原因を調べて直して」 |
| コードを理解する | プロンプト「[モジュール]がどう動くか説明して、エントリーポイントも教えて」 |
| 安全にリファクタする | プロンプト「[モジュール]を[目的]のためにリファクタして、レビューできるようPlan modeを使って」 |
| テストを書く | プロンプト「[ファイル]のテストを、[シナリオ]周りの境界値も含めて書いて」 |
| コミット前にレビューする | プロンプト「今のdiffを見て、リスクがありそうな箇所を教えて」 |
| PRを開く | プロンプト「[issue]を直して、Conventional Commits形式でコミットし、要約付きのPRを開いて」 |
| Skillを作る | プロンプト「コミット前にテストとlintを走らせる/shipというSkillを作って」 |
| スタックトレースを調べる | プロンプト「このスタックトレースから根本原因を見つけて、その場しのぎの対処はしないで」 |
「安全にリファクタする」のPlan modeは、Shift+Tabで「plan」と表示されるまで切り替えると入れます。ソースを編集せずに、何をするつもりかを先に示させるモードです。kitのパイロット向け文面も、複数ファイルにまたがる最初の変更でこれを試すよう勧めています。使い方はClaude Code Planモード完全ガイドにあります。「コードを理解する」の前提知識を厚くする方法はClaude Code memoryの三層構造です。
8つを一度に渡す必要はありません。まだ何も試していない人には「バグを直す」と「コードを理解する」の2つで足ります。何度か使った人には「Skillを作る」や「PRを開く」のように、日常の作業に踏み込むテンプレートが合います。
質問が落ち着いたあとに流すTips
FAQと最初のプロンプトの次は、kitのTipsキャンペーンが使えます。Slackに貼れる短い文面が、定着させたい機能ごとに用意されています。区分は次の順です。始め方、プロジェクトの記憶(/initとCLAUDE.md、@参照)、制御と安全(権限モード、/rewind)、外部ツール接続(MCP)、自動化(SkillとHooks)、日々の開発(画像、Git)、共有(プラグイン)、セキュリティ。
各文面は「きっかけ、得られること、いま試すこと、ドキュメントへのリンク」の型で、順序の指定はありません。kitは週に1〜2本のペースを勧め、自分のチームに足りない機能に合うものだけを選んでよいとしています。
権限モードの回は、展開の初期に効く内容です。Shift+Tabの標準の巡回はManual、acceptEdits、planの順で、kitのこの回も3つを紹介しています(autoなどは有効なときに巡回へ加わります)。Manualが編集とほとんどのシェルコマンドの前に確認し、acceptEditsがファイル編集と一般的なファイル操作コマンドを通し、planがソースを編集せずに調べて提案します。定着の習慣としてkitが挙げるのは、複数ファイルに触る作業をplanで始めること、/initを早めに実行すること、コミット前にdiffを読むこと、重要な経路の変更を検証することの4つです。
テンプレをそのまま使わない理由
kitの冒頭には注記があり、ここにある文面はすべて下書きだと書かれています。自社の言葉で書き直し、例のタスクを自分のコードベースの実在するバグやモジュールに差し替え、[角括弧]のプレースホルダーを埋めてから送ります。導入を後押しするのは、社内の誰かが書いたと分かる告知だからです。
FAQの回答も同じです。TeamかEnterpriseか、Zero Data Retentionがあるかといった自社の契約に合わせて、条件を書き換えてから配ります。プロンプトは、プレースホルダーを埋めた状態で渡せば、相手はコピーして貼るだけで最初の1回を体験できます。表ごと渡すと、各自が自分のタスクに合わせて考え直す手間が残ります。
kitの末尾には、Claude Codeは更新が頻繁なので、社内に配る前にバージョン固有の記述を公式ドキュメントと照らすよう書かれています。このFAQの権限・モデルまわりの記述も、配る前に最新のページで見直します。
配布後の質問を誰が拾うか
FAQとプロンプトを送った後も、個別の質問は続きます。管理者が全部を拾うと、告知した本人がまた質問攻めに戻ります。分け方の目安は、使い方の相談か、契約やセキュリティの判断かです。
- 「このプロンプトを自分のタスク向けに書き換えたい」「Skillの中身を直したい」のような使い方の相談は、現場でよく使っている人が拾えます
- 「監査ログはどこに残るか」「特定のリポジトリだけアクセスを制限したい」のような契約・セキュリティの質問は、管理者が答えを確定させます
- 判断に迷う質問は、いったん現場の担当が預かり、管理者に確認してからFAQへ追記すると、二度目からは現場だけで完結します
パイロット群を先に走らせる展開では、kitのパイロット向け文面が参考になります。少なくとも1つの実タスクに使ってもらい、うまくいった点・邪魔だった点・意外だった点をパイロット専用チャンネルに書いてもらう依頼で、その声が全社展開の進め方を決める、という段取りです。
この分け方をFAQの冒頭に一言添えておくと、「誰に聞けばいいのか」という往復が減ります。現場でよく使う人にFAQの更新を任せる運用の作り方はClaude Code社内展開の30日プレイブックにまとめています。