Claude Code Skill 企業運用ガイド2026｜階層解決(user/team/org)と applied_skills 監査ログ

Claude CodeのSkill機能（Agent Skills）は、エージェントに「特定の業務を行うための手順書とツールの組み合わせ」を渡すための仕組みです。個人開発者が自分のSkillを書いて使うのは簡単ですが、企業がSkillを組織全体で運用しようとすると、「誰のSkillが優先されるか」「組織のポリシーをどう強制するか」「誰がいつどのSkillを使ったかをどう監査するか」という課題に直面します。本記事では、企業がClaude Code Skillをエンタープライズで運用するための階層解決・監査ログ・配布フローを、実装現場の知見をもとに整理します。

Claude Code Skillとは何か（簡単な復習）

Skillは、特定タスクのためにエージェントに渡す手順書（SKILL.md）と関連リソース（スクリプト・テンプレート・参考ドキュメント）の組み合わせです。エージェントはユーザーの要求に応じて関連するSkillを自動的に選択・適用し、Skillに記述された手順に沿って作業を進めます。

Anthropic公式の汎用Skill（PDF・PowerPoint・Excel・Word操作など）に加えて、社内独自のSkill（社内システム操作・業務テンプレート・社内ガイドライン適用など）を作って配布することで、企業特有の業務を高品質に自動化できます。

企業導入で直面する3つの構造的課題

課題1：Skillの「重複」と「衝突」

個人が自分の好みでSkillを書くと、組織内で似たようなSkillが複数生まれます。「議事録要約」のSkillが営業部門・人事部門・開発部門で別々に存在し、品質や出力フォーマットがバラバラになります。

課題2：組織ポリシーとの整合

個人が書いたSkillが、組織のセキュリティポリシー・ブランドガイドライン・コーディング規約に違反することがあります。特に「破壊的なツールを呼ぶSkill」「機密情報を外部APIに送るSkill」は、組織として強制的にブロックする必要があります。

課題3：監査対応

「誰がいつどのSkillを使ったか」が追跡できなければ、内部統制・コンプライアンス対応で破綻します。Skillが業務上の意思決定に関与した場合、その記録が必須要件になります。

Skill階層解決：user > team > org の3層モデル

これらの課題を解決する基本パターンが、Skillの階層解決です。同じ目的のSkillが複数の階層に存在するとき、優先順位を明確に決めます。

3層モデルの基本ルール

• org（組織）：組織全体に配布される基本Skill。セキュリティ・ブランド・コンプライアンスの最低基準を満たす
• team（チーム）：チーム固有の業務に最適化されたSkill。orgのSkillを上書きできるが、orgの最低基準は守る
• user（個人）：個人の作業効率を上げるSkill。team/orgのSkillを上書きできるが、組織が禁じるツール呼び出しはできない

解決の優先順位は「user > team > org」が基本ですが、組織として「絶対に上書きさせない」項目（例：禁止コマンドの一覧、機密情報送信の禁止、ログ送信の強制）はorg層で固定します。

renueの実装パターン

私たちrenueでは、各エージェント実行時にこの3層解決ロジックが走り、最終的に適用されたSkill一覧（applied_skills）が当該Agent Runの監査ログに記録されます。これにより、後から「このRunでどのSkillが適用されたか」を完全に追跡できます。

applied_skills 監査ログの設計

Agent Runごとに「適用されたSkill」を記録することで、次のような問いに答えられるようになります。

• 誰がどのSkillを最も使っているか
• 特定のSkillはどの部門で使われているか
• 禁止すべきSkillが実際に使われていないか
• 失敗したRunで共通して使われているSkillはあるか
• 監査時に「このRunの判断根拠は何か」を遡及できるか

監査ログに含めるべき項目

• skill_name：Skill名
• skill_version：バージョン番号
• scope：user / team / org のいずれか
• declared_tools：そのSkillが宣言しているツール一覧
• actual_tools_used：そのSkillの実行中に実際に呼ばれたツール
• resolution_decision：階層解決でなぜこのSkillが選ばれたか

Skill配布フローの設計

orgレベルのSkillは、組織として一元配布する必要があります。配布フローは次の3パターンがあります。

パターン1：CLIによる手動同期

社員が`renue skills add`のようなコマンドを実行することで、最新の組織SkillをローカルにDLします。手軽に始められますが、社員ごとにバージョンがずれやすいのが弱点です。

パターン2：自動同期（フック型）

Claude Code起動時のフックでSkillの差分を自動同期します。バージョンずれを防げる一方、起動時間が伸びる可能性があります。

パターン3：中央サーバ参照型

Skillをローカルに置かず、エージェント実行時に中央サーバから動的に取得します。バージョン管理が容易ですが、オフライン時に動かなくなります。

多くの企業では、パターン1（手動同期）から始めて、利用が広がった段階でパターン2（自動同期）に進化させるのが現実的です。

Skill品質を担保する5つの実務ルール

1. SKILL.mdは1ページに収める：長すぎるSKILL.mdはエージェントが要点を選びにくい
2. 説明文に「いつ使うか」を明示する：エージェントはSkill選択時に「いつ使うか」を判断するため、ここの品質が選択精度を決める
3. declared_toolsを正直に書く：実際に呼ぶツールを宣言しないと、ガバナンスが効かない
4. Skill間の依存を最小化する：Skill同士が依存し合うと、更新・テスト・配布が困難になる
5. 変更履歴を残す：誰がいつ何を変えたかを記録することが、組織展開の前提になる

Skill運用で陥りやすい4つの落とし穴

1. 落とし穴1：個人がSkillを自由に書ける状態を放置する。重複・衝突・品質ばらつきが量産されます。
2. 落とし穴2：階層解決を実装しないままSkillを増やす。どのSkillが優先されるかが不明確になり、デバッグ困難になります。
3. 落とし穴3：監査ログを取らない。本番化フェーズで監査要件を満たせず、稼働停止になります。
4. 落とし穴4：org層のSkillに「最低基準」だけでなく「具体業務」まで詰め込む。orgが肥大化し、team/userの自由度が失われます。orgは最低基準、team/userは具体業務、と役割分担します。

renueがSkill運用で徹底している3原則

1. 階層解決は最初から実装する：user > team > org の優先順位とorg側の絶対基準を設計の最初に決める
2. applied_skillsを必ず監査ログに残す：Skillの選択結果をAgent Runと紐付けて永続化する
3. org層のSkillは「最低基準」に絞る：禁止事項・必須項目だけをorgで持ち、具体業務はteam/userに委ねる

FAQ

Q1. Claude Code SkillとMCPサーバはどう違いますか？

Skillは「手順書とリソース」、MCPは「ツールのインターフェース」です。Skillは「議事録要約の進め方」を記述し、MCPは「議事録を取得するAPIを呼ぶツール」を提供します。両者は補完関係にあり、組み合わせて使うのが基本です。

Q2. 個人Skillと組織Skillはどう住み分けるべきですか？

個人Skillは「自分の業務効率を上げる」もの、組織Skillは「組織の品質基準とガバナンスを守る」ものです。住み分けの軸は「他人に強制したいか」で、強制したいなら組織Skill、自分だけで使うなら個人Skillです。

Q3. Skillはどのくらいの粒度で作るべきですか？

1Skill=1業務目的が原則です。「議事録要約」「契約書レビュー」「請求書ドラフト」のように業務単位で切り、1つのSkillに複数の目的を詰め込まないようにします。粒度が細かすぎる場合は後で統合できますが、肥大化したSkillを分割するのは難易度が高いので、最初は細かめに作るのが無難です。

Q4. Skillの管理は誰の責任ですか？

org層は情報システム部門・CISO配下、team層は各部門のDX推進担当、user層は個人、という3層で管理責任を分ける設計が一般的です。org層をCISOが管理することで、セキュリティ・コンプライアンスの統制が効きます。

Q5. Skillの活用はどう測れば良いですか？

「Skill別の使用回数」「Skill別の平均トークン消費」「Skill別の成功/失敗率」「Skill別のユーザー数」の4軸が基本です。これらのメトリクスをダッシュボード化することで、価値の高いSkillに投資を集中できます。