Skills・サブエージェント・プラグインで社内ナレッジを資産化する

Claude Code & Cowork 業務実装マスター【企業のAI内製・自動化】

0 / 11 完了（0%）

「あの人にしかできない」「マニュアルはあるが誰も読まない」——AI活用が進むほど、社内には個人の頭の中だけにある業務知識が増えていきます。せっかくClaudeで業務を自動化しても、その手順が一人のチャット履歴に埋もれていては、組織の資産にはなりません。

Claude Codeには、この「属人化」を構造的に解決するための拡張機能が4つ用意されています。Skills・Subagents・Hooks・Pluginsです。本レッスンでは、2026年6月時点の最新仕様にもとづいて、それぞれの違いと使い分け、そして社内で共有・運用していく具体的な方法を解説します。

結論：4つは「役割」が違う。混同しないことが第一歩

まず押さえるべきは、この4つは競合する選択肢ではなく、レイヤーの異なる部品だということです。ひとことで言えば、Skills・Subagents・Hooksが「中身（機能）」、Pluginsが「配る箱（配布単位）」です。

機能	役割（ひとことで）	使いどころ
Skills	説明文マッチで自動起動する手順・ワークフロー	「請求書を処理して」と言うだけで社内ルール通りの手順が走る
Subagents	独立コンテキストで処理し要約だけ返す	大量ファイルの調査や下調べを任せ、メインの会話を汚さない
Hooks	ライフサイクルイベントで発火する決定論的な制御点	「コミット前に必ずテスト」「設定変更時に承認」を強制する
Plugins	上記を束ねてバージョン付きで1コマンド導入できる配布層	整備した部品一式を全社へ配り、更新も一括管理する

Skills：手順書を「読まれるもの」から「自動で動くもの」へ

Skillsは、AIが文脈を見て自動的に呼び出すオンデマンドの手順書です。各Skillには「いつ使うか」を書いた説明文（description）があり、ユーザーの依頼内容とマッチすると自動で起動します。「経費精算の進め方」「広報チェックの観点」といった暗黙知を1つのSkillに落とし込めば、新人が何も知らなくても、依頼するだけでベテランと同じ手順が再現されます。

ポイントは、Skillは指示書（テキスト）であって、コードを書ける人だけのものではないということ。業務を一番よく知っている現場担当者が「正しいやり方」を言語化する——それがそのまま全社の標準動作になります。

Subagents：メインを汚さずに重い処理を任せる

Subagentsは、独立したコンテキスト（作業スペース）で動き、結果の要約だけを返すサブの担当者です。たとえば「過去3年分の契約書から自動更新条項を抽出して」のような重い調査を任せると、Subagentが大量のファイルを読み込んで処理し、本体の会話には結論だけが戻ります。

メリットは2つ。メインの会話が長大なログで埋まらないこと、そして調査・実装・レビューといった役割を分業できることです。これにより、複雑な業務でも見通しよく、再現性の高い形で進められます。

Hooks：「人間のルール」をAIに強制する制御点

SkillsやSubagentsがAIの判断に委ねる部分だとすれば、Hooksは判断を挟まず必ず実行される決定論的なルールです。ファイル編集の直前（PreToolUse）、セッション開始時（SessionStart）といったライフサイクルの特定イベントで発火し、コマンド実行や承認フローを差し込めます。

企業統制の観点では、これが要になります。「設定変更があれば必ず承認を求める（ConfigChangeフック）」「危険な操作の前にログを残す」といったガードレールを、AIの気まぐれに左右されず仕組みとして担保できるからです。

Plugins：整えた部品を「1コマンドで全社配布」

ここまでの3つ（とMCP定義・スラッシュコマンド）を束ねてバージョン付きで配る単位がPluginsです。公式・コミュニティのマーケットに加え、企業は社内プライベートマーケットを運用できます。導入は /plugin marketplace add 組織名/リポジトリ名 のように、社内のGitリポジトリを登録するだけ。あとは各メンバーがコマンド一発でインストールでき、更新も一元管理されます。

作り方の最小手順

プラグイン用ディレクトリを作り、.claude-plugin/plugin.json にマニフェスト（名前・説明・バージョン）を書く
skills/ にSkill、必要なら agents/ にSubagent、hooks/ にHook定義を置く
--plugin-dir オプションでローカル読み込みし、手元で動作テストする
修正したら /reload-plugins で再起動せずに反映して確認する
マーケット用リポジトリの marketplace.json に登録し、社内に配布する

このように、個人が試して良かったものを、検証してから全社の標準に昇格させる流れが、コマンド操作だけで完結します。

属人化を防ぐ運用設計：「資産化」の本質はここ

機能をそろえても、運用が個人任せでは元の木阿弥です。ナレッジを本当に資産にするための運用ルールを3つ挙げます。

正本はGitで管理する：SkillやPluginの中身はリポジトリで一元管理し、誰が・いつ・何を変えたかを履歴で残す。チャット履歴に閉じ込めない。
レビューを経て昇格させる：個人の便利ツールを、内容を確認したうえで社内マーケットに公開する。「動けばいい」から「組織の標準」への関門を設ける。
オーナーとバージョンを明示する：各Pluginに責任者とバージョンを付け、陳腐化したものは更新・廃止する。放置されたSkillはむしろリスクになる。

統制面の補足として、Claude CodeはエンタープライズプランでOSレベルのサンドボックスbash・ネットワーク隔離・MCP許可リスト・監査ログを備えます。一方、非エンジニア向けのClaude Coworkは活動が監査ログに記録されない点に注意が必要です。統制設計ではClaude CodeとCoworkを分けて扱うのが2026年6月時点の正しい設計です（詳細は別レッスン・コラムで解説します）。

よくある質問

SkillsとSubagentsは結局どう使い分ければいい？

「決まった手順を自動で正しく走らせたい」ならSkills、「重い調査や下処理を分業させ、メインの会話を軽く保ちたい」ならSubagentsです。実務では両者を組み合わせ、Skillの中からSubagentに調査を投げる、といった構成もよく使われます。

プログラミングができないと作れませんか？

Skill自体は手順を書いた指示書なので、業務を理解している人なら作成・改善できます。ただしHooksやPluginの配布まわりはエンジニア的な作業を含むため、現場が中身を言語化し、情シス/DXが配布・統制を担う役割分担が現実的です。

社内マーケットは何で作るのですか？

特別な基盤は不要で、社内のGitリポジトリ（GitHub等）に marketplace.json を置けば成立します。メンバーは /plugin marketplace add で登録するだけ。既存の開発資産管理の延長で運用できます。

導入した部品が古くなったらどうする？

Pluginにはバージョンとオーナーを付けて管理します。更新時はリポジトリを直し、各メンバーは /reload-plugins や再インストールで最新版を取得します。陳腐化したものは廃止フローに乗せ、放置しないことが重要です。

まとめ

Skills（自動起動の手順）・Subagents（独立処理）・Hooks（制御点）・Plugins（配布単位）。この4層を理解すれば、AI活用は「個人の便利技」から組織の再現可能な資産へと変わります。鍵は、機能をそろえることではなく、Gitでの一元管理・レビュー昇格・オーナー明示という運用ルールを最初に決めることです。

次のステップ

まずは自部署で「一番属人化している業務」を1つ選び、その手順をSkillとしてClaude Codeに言語化してみてください。学習を体系的に進めたい方は企業のClaude業務自動化コースで、関連レッスンを順に学べます。基礎から固めたい方は Claude Codeの最新機能コースもおすすめです。

拡張機能の全体像をさらに深掘りしたい方は Plugins/Skills/Agents徹底解説、企業導入の進め方はエンタープライズ導入ガイドを参照してください。すぐ使えるテンプレートはプロンプト集に、用語の確認は用語集にまとめています。

実務で使えるテンプレートを手元に置きたい方は、メール購読で「業務で使えるプロンプト50選PDF」を無料配布中です。自社に合わせた拡張機能の設計や全社展開でお困りの場合は、株式会社LUCRISのClaude導入支援でも、内製化と統制設計のご相談を承っています。

このコース「Claude Code & Cowork 業務実装マスター【企業のAI内製・自動化】」の全レッスン