Claude Codeのナレッジ管理 — 個人のプロンプトを組織の資産に変える置き場所の設計

なぜ個人のプロンプト集は資産にならないのか

研修先でよく見かけるのが、「うまくいったプロンプト集」というメモやスプレッドシートです。作った本人は熱心で、中身も悪くありません。それでも、数ヶ月後には開かれなくなっているという声を多くいただきます。

うまくいった工夫が個人の手元で止まっているのは、組織にとって単純にもったいない状態です。同じ壁に別の人がもう一度ぶつかり、同じ時間をかけて同じ答えにたどり着くことになります。

止まる理由は、だいたい次の3つに整理できます。どれも中身の質ではなく、置き場所と仕組みの問題です。

• 探されない — 保存先が個人のメモやチャット履歴なので、必要な瞬間に他の人が辿り着けない
• 更新されない — 手順や前提が変わっても直す人が決まっておらず、古い版が残り続ける
• 発動しない — 保存してあっても、使うたびに人が「あれを使おう」と思い出して貼り付ける必要がある

置き場所は2つの軸で決まる — 「射程」と「発動」

Claude Codeには、指示や知識を書いておける場所が複数あります。CLAUDE.md、Skills、メモリ、設定ファイル、参照用のドキュメント。迷うのは機能の理解ではなく、目の前の1つをどこに書くかという一点です。

判断はシンプルで、次の2つの質問に答えるだけで置き場所はほぼ一意に決まります。

1. 1誰に届けばよいか（射程） — 自分だけか、このプロジェクトを触る全員か、全社か
2. 2いつ読ませたいか（発動） — 毎回必ず効かせたいか、特定の作業のときだけでよいか

この2軸で考えると、「とりあえずCLAUDE.mdに全部書く」という失敗を避けられます。CLAUDE.mdは毎回読み込まれるため、特定業務の手順まで積み上げると、常に読む量が増えて肝心の指示が薄まります。

公式ドキュメントもCLAUDE.mdは200行未満を目安としています。一方でSkillは、いつ使うかの説明文だけが常に読まれ、本文は実際に使われるときまで読み込まれません。長い手順書ほどSkill側に置くほうが軽く済みます。

置き場所の地図 — 何をどこに置くか

2軸で振り分けた結果を表にまとめます（仕様は2026年8月時点の公式ドキュメントで確認）。まずはこの表のとおりに置いてみて、運用しながら調整するのが実務的です。

表のうち最も判断を間違えやすいのが、CLAUDE.mdとSkillの線引きです。目安は「毎回効いていないと困るか」。全ての作業に関わる約束事はCLAUDE.mdへ、特定の作業のときだけ必要な手順はSkillへ置きます。

プロンプトは「ライブラリ」にせず「手順」にする

プロンプトの資産化でいちばん多い誤解が、プロンプト集を作ることをゴールにしてしまうことです。ツールに整然と並べても、使う側の動作は「探して・コピーして・状況に合わせて書き換える」のままで、手間はほとんど減りません。

資産になるのは、Claudeが自分で読みに行ける形に変換したときです。同じ内容でも、置き方を変えるだけで人の手間が消えます。

• Skillにする — 「この業務の話題になったら、この手順で進める」という手順書として置く。呼び出しを人が覚えていなくてよいのが最大の利点
• サブエージェントにする — 調査やレビューのように役割が独立している仕事は、専任役として切り出す。詳しくはサブエージェントの作り方へ
• CLAUDE.mdの1行にする — 「毎回この形式で書く」のような普遍的な約束事は、手順ではなくルールとして常時読ませる

変換の判断基準も明快です。1回きりの工夫は書き残さず、3回繰り返したものだけを手順にします。最初から網羅しようとすると、使われない手順書だけが増えていきます。

すでにスラッシュコマンドとしてプロンプトを貯めている場合も、慌てて作り直す必要はありません。コマンドとSkillは同じ仕組みに統合されており、公式は新規作成をSkill側で行うことを推奨しています（2026年8月時点）。呼び出し方は同じなので、移し替えは順次で構いません。

棚卸しの手順 — 散らばったナレッジを集める4ステップ

何をどこに置くかが決まったら、次は現状の棚卸しです。想像で「うちに必要なナレッジ」を考えるのではなく、実際の依頼から出発するのが失敗しないコツです。

1. 1直近2週間の依頼をそのまま書き出す — 記憶ではなく実際の履歴から拾う。理想の業務ではなく現実の業務が対象
2. 2繰り返しているものだけ残す — 3回以上登場したテーマが候補。1回きりのものは捨てる
3. 32軸で振り分ける — 「誰に届けばよいか」「いつ効いてほしいか」で、上の表の置き場所へ割り当てる
4. 41つずつ実際に使わせて直す — 書いて終わりにせず、Claudeに使わせて詰まった箇所をその場で修正する

全社へ配る — 個人の設定を組織の標準にする

自分のPCの中だけにあるものは、まだ資産ではありません。ここを越えられるかどうかが、個人の効率化と組織の仕組み化の分かれ目です。配布の手段は主に次のとおりです。

• リポジトリにコミットする — プロジェクトのCLAUDE.mdやSkillをリポジトリに含めれば、取得した全員に同じ状態が届く。最も手軽で確実な第一歩
• プラグインとして配る — スキルや設定をまとめて配布・更新できる仕組み。プロジェクトの設定ファイルに配布元を書いておけば、メンバーがそのフォルダを信頼した時点で自動的に入る。詳しくはClaude Codeのプラグイン入門へ
• 設定ファイルの階層で配る — 権限や制約は個人の善意ではなく設定で揃える。実例はpermissions設定レシピ集へ
• 組織レベルに置く — 管理者が端末へ配置する組織レベルの指示・設定は、個人の設定では外せない。全社に必ず効かせたい方針だけを、ここに絞って置く

Claude Codeの外にも、組織全体に効かせる指示の置き場所があります。claude.aiのTeamプランには管理者が全員に効かせる「組織の指示」があり、書き方は組織の指示に何を書くかで解説しています。配ったのに使われないという段階の課題はClaudeが社内で使われない理由もあわせてご覧ください。

腐らせない3つのルール

ナレッジは作った瞬間から古くなります。更新の仕組みまで設計して、はじめて資産と呼べます。運用で効くルールは次の3つです。

1. 1正本を1つに決める — 同じ事実を2箇所に書かない。良かれと思ってコピーした瞬間から、片方だけ直される分岐事故が始まる
2. 2更新する人を決める — ファイルごとに責任者を置く。「気づいた人が直す」は、実務では「誰も直さない」と同じ意味になる
3. 3事故から書く — 想像で書いたルールは守られない。実際に失敗したときに1行足すほうが、精度も定着も高い

1つ目は仕様の面でも効いてきます。階層の違うCLAUDE.mdは、どれかが上書きされるのではなく全部つなげて読み込まれます。同じ内容を2箇所に書けば二重に読まれ、やがて片方だけが直されて食い違います。

あわせて、四半期に一度は「もう使っていないもの」を消す時間を取ってください。読ませる量が増えるほど1件ずつの指示は効きにくくなります。何を読ませ何を読ませないかの考え方はコンテキストエンジニアリングの原則にまとめています。

研修・導入支援では、この設計から一緒に作ります

ナレッジの資産化でつまずく理由は、機能の理解不足ではなく自社の業務をどう切り分けるかが決まらないことにあります。どの業務を手順にするか、どこまでを個人の裁量に残すかは、業務を知っている人と一緒に決めるのがいちばん早い方法です。

AI OrchestraのClaude Code研修・導入支援では、業務の棚卸しからCLAUDE.md・Skillの設計、チームへの配布と更新の運用ルールづくりまで伴走しています。「一部の人だけが速い状態」から抜け出したい企業様は、お気軽にご相談ください。