Claude Skillsで暗黙知を実行可能な手順に変える——属人化対策としてのSkills活用

手順を書いた分だけ属人化は薄まっているはずだ、と思いたくなる。実際には、書いた手順書は更新されないまま古びていき、探す手間を嫌った本人たちが「聞いた方が早い」に回帰していく。言語化それ自体は、属人化を解消する条件のごく一部でしかない。

この記事では、なぜマニュアル化だけでは属人化が解消しきれないのかを整理したうえで、Anthropicが提供するClaude Skillsという仕組みが「書いた手順を実行させる」という一段先の対策になりうる理由と、暗黙知をSkillに落とし込む具体的な手順を紹介する。

• 属人化対策が「マニュアル止まり」で終わる構造的な理由
• Claude Skillsがプロンプトやカスタム指示と何が違うのか
• 暗黙知をSkillに落とし込む3つのステップ
• 個人利用からチーム展開に広げるときの落とし穴

マニュアルを書いても、属人化が解消しない理由

ドキュメント蓄積システムを導入すれば、属人化の問題は片づくはずだった。そう考えて何かしらのナレッジベースを整備した組織は少なくないだろう。

導入した直後は機能しているように見える。しかし更新責任者を誰も引き受けていなければ内容は実態とずれていき、新しく入ったメンバーはどこに何が書いてあるのか探す場所すら分からない。ベテランのメンバーほど「直接聞いた方が早い」という経験則に戻っていく。ナレッジの入力・更新が「誰かの追加業務」である限り、業務が忙しいときほど後回しにされ、知識は結局のところ個人の頭の中にとどまり続ける。

属人化そのものがなぜ起きるのかという構造は、姉妹記事「属人化はなぜ起きる？」で標準化・人的な仕組み・制度設計・AI活用という4層に分けて整理した。この記事が焦点を当てるのは、その4層目にあたる「AIに手順を実行させる」という実装レイヤーである。

Claude Skillsは何が違うのか

Claude Skills（オープン規格としては「Agent Skills」）は、Anthropicが2025年10月に発表した仕組みで、業務の手順・判断基準・テンプレートを1つのフォルダにまとめ、Claudeに再利用可能な形で教える機能である。中心になるのはSKILL.mdというファイルで、YAML形式のメタデータとMarkdown本文で構成される（基本的な仕組み・自作の手順は「Claude Code Skillとは？使い方をやさしく解説」で個別に扱った。ここでは属人化対策として使う場合の勘所に絞る）。

プロンプトが「その場限りの即興指示」だとすれば、Skillは「一度登録すれば繰り返し使える業務ナレッジ」としてAIが自動的に参照する点が違う。手順書やガイドラインをSkill化すると、誰が使っても同じ水準でアウトプットできるようになる。ノウハウを言語化するという目的自体は従来のマニュアル整備と変わらない。違うのは、言語化した手順をAI自身が読み込み、実行するところまで仕組みに組み込まれている点である。

機能	役割	適用タイミング
カスタム指示	Claudeの基本性格設定	全会話で常時
Projects	案件ごとの作業デスク	プロジェクト内で常時
Skills	業務マニュアル	関連タスク時に自動
MCP	外部ツールとの接続口	ツール呼び出し時

MCPとSkillsは組み合わせて力を発揮する。「外部からデータを取得する」役割をMCPが担い、「取得したデータをガイドラインに沿って加工する」役割をSkillsが担う分担が典型である。

多数のSkillを登録してもコンテキストを圧迫しない仕組み

Skillは3段階の**段階的開示（プログレッシブ・ディスクロージャー）**で読み込まれる。①メタデータ（name/descriptionのみ、約100トークン/スキル）は常時、②SKILL.md本文（5,000トークン未満が目安）は関連タスクのときだけ、③スクリプトやテンプレートは実際に使用するときだけ読み込まれる。この設計のおかげで、多数のSkillを登録してもコンテキストウィンドウを圧迫しない。裏を返せば、descriptionの書き方（何をするか、いつ使うかを具体的なキーワードとともに書くこと）が、そのSkillが実際に「発見される」かどうかを左右する。

実践してわかったこと

Skillという仕組みの説明を聞いただけでは、それがどれほどのものか判断がつかない。私自身、この記事を書いているwrite-blogリポジトリで、実際にSkillを運用しながらそのことを確かめてきた。

この記事も含め、write-blogでの執筆作業では、日本語の文章リズムに関する規範をcognitive-rhythm-writingというSkillとして蓄積している。緩急のある読みやすい文章とは何か、緊張をどう管理するか、といった感覚に頼りがちな基準を、執筆後に一つずつ点検できる手順として言語化したものだ。このSkillを呼び出すようになってから、文章の読みやすさ・引きつけ方が体感ではっきり変わった。以前は「良い文章」の基準を毎回思い出しながら書いていたが、いまはセッションが変わっても同じ水準の点検が自動的にかかる。

同じ効果は、文章以外の資料作成でも起きている。プレゼンテーション資料の作成にはPowerPoint用のSkillを使っており、決まったフォーマット・トーンでの出力を毎回一から指示し直す必要がなくなった。ほかにも定型業務に合わせたSkillをいくつか運用しているが、そのすべてを手書きしたわけではない。Skillの作成自体をClaudeに依頼し、対話形式のヒアリングを受けながらSKILL.mdのたたき台を作らせている。最初から完璧な設計を狙うのではなく、使いながら育てるという前提に立つと、着手のハードルは大きく下がる。

write-blogリポジトリ自体も、記事執筆・投稿・内部リンク管理・タスク管理といった運営ノウハウを.claude/skills/配下に蓄積し続けている実践例である。「タスクに気づいたら都度docs/todo.mdに追記する」「投稿前は必ず内部リンク候補を確認する」といった、以前はその都度思い出したり伝えたりする必要があった判断基準が、いまではSkillとして常に参照される状態になっている。

暗黙知をSkillに落とし込む3つのステップ

1. 繰り返し起きている「同じ質問」「同じ指示」を洗い出す：自分やチームが同じ説明を何度もしている場面を挙げる。そこが最初にSkill化すべき候補になる。
2. 最小構成で言語化し、Claudeに作らせる：手書きで全部を書き切ろうとせず、nameとdescriptionだけの最小構成から始める。SKILL.md自体の作成をClaudeに依頼し、対話でヒアリングを受けながら形にする方法も有効である。
3. 使いながら育て、使われなくなったら削除する：作って終わりにせず、実際の運用を通じてトリガーの精度を上げたり、不要な部分を削ったりする。月1回程度の見直しで十分であり、使われなくなったSkillは放置せず削除する（残しておくとかえって精度を下げる要因になる）。

個人利用からチーム展開に広げるときの落とし穴

個人で使う分には、プロジェクトスコープ（.claude/skills/）や個人スコープ（~/.claude/skills/）で十分に回る。チーム・全社に広げる段階では、エンタープライズスコープ（Managed Settings経由で組織内全ユーザーに配布し、上書き不可）が加わる。優先順位はエンタープライズ＞個人＞プロジェクトで、同名のSkillは上位が下位を上書きする。

よくある質問

プロンプトやカスタム指示と何が違いますか？

カスタム指示は人格・トーンの常時設定、Projectsは案件ごとの作業デスク、Skillsは関連タスクのときにAIが自動的に参照する業務マニュアル、という役割分担になっている。プロンプトが毎回の即興指示であるのに対し、Skillsは一度登録すれば繰り返し使える蓄積型のノウハウという違いがある。

セキュリティ面で気をつけることはありますか？

Skillはコード実行環境で動作するため、信頼できないソースのSkill導入はソフトウェアのインストールと同等のリスクを伴う。社内で配布する場合も、APIキーやパスワードなどの機密情報を直書きせず、環境変数やシークレット管理の仕組みを使うことが前提になる。

まとめ

→ このブログを書いている人について

関連記事