【2026年最新】Claude Skills 完全ガイド｜法人・チーム導入7パターン+運用設計

Claude Skillsとは何か — 法人活用の全体像

「毎回同じ手順書をチャットに貼り付けるのが面倒で」——ある研修先の情報システム部長がそう言って苦笑いしたのを覚えています。ChatGPTやClaude Codeを導入して数週間、担当者ごとにプロンプトの書き方がバラバラになってしまい、「ノウハウが個人に閉じている」という悩みが生まれていたのです。

そのときに紹介したのが、Claude Skillsという仕組みです。端的にいえば、「AIへの指示書をチームで共有できる仕組み」で、繰り返し使う手順・チェックリスト・プロンプトをSKILL.mdファイルにまとめておくと、/スキル名 と入力するだけでClaudeがその手順を実行してくれます。

この記事では、Claude Skillsの仕様（2026年6月時点・Anthropic公式code.claude.comより）を正確に説明しながら、法人がチームで運用するための7パターンの自作Skill実例、Managed Settingsを使った全社配布手順、失敗パターンの回避策、そしてTCO試算まで一気に解説します。

Claude Codeをチームに導入済みの方はもちろん、これから検討している経営者・情報システム担当者にも「今日から使える」内容にまとめました。ぜひ最後まで読んでください。

AIエージェントの基本概念や法人AI導入の全体像については、AI導入戦略完全ガイドで体系的にまとめています。Claude Skillsはその「ツール活用」レイヤーに位置する実践スキルです。

Claude Codeの基本的な導入ステップについては、Claude Code完全ガイドで体系的にまとめています。Skillsはその「次のステップ」として位置づけてください。

SKILL.mdの構造と必須フィールド — 公式仕様を正確に理解する

Claude Skillsを作るには、SKILL.mdという名前のファイルを1つ作るだけです。構造はシンプルで、「YAMLフロントマター（設定）」と「Markdownの本文（手順・指示書）」の2パートに分かれます。

（参照: Anthropic公式 code.claude.com/docs/en/skills、参照日: 2026-06-04）

---
name: コードレビュー
description: コードレビューを実行する。コードの変更について聞かれたとき、またはレビューを依頼されたときに使う。
allowed-tools: Read Grep Bash(git diff *)
disable-model-invocation: false
---

## レビュー手順

1. `git diff HEAD` で変更内容を確認する
2. セキュリティ上の問題がないか確認する
3. コーディング規約への準拠を確認する
4. 改善提案を番号付きリストで出力する

YAMLフロントマターの全フィールド一覧

公式ドキュメント（code.claude.com/docs/en/skills、参照日: 2026-06-04）に記載されているフロントマターフィールドは以下の通りです。

スキルのコマンド名はディレクトリ名から決まる

重要な点として、タイプして呼び出すコマンド名はディレクトリ名から決まります（プラグインroot SKILL.mdを除く）。フロントマターのnameフィールドは表示名であり、呼び出し名ではありません。

~/.claude/skills/code-review/SKILL.md  →  /code-review で呼び出し
.claude/skills/meeting-notes/SKILL.md  →  /meeting-notes で呼び出し

動的コンテキスト注入 — スキルが実行前にデータを取得できる

SKILL.mdの中で !`コマンド` と書くと、Claudeに送られる前にシェルコマンドが実行され、その出力が埋め込まれます。これにより、スキル実行時の最新データをプロンプトに含められます。

---
description: 最新の未コミット変更を要約する
---

## 現在の変更内容
!`git diff HEAD`

## 指示
上記の変更を3つの箇条書きで要約し、リスクがあれば指摘してください。

スキルの保存場所と適用スコープ — 個人・プロジェクト・エンタープライズの3階層

Claude Skillsには3つの保存スコープがあります。法人導入では、この階層設計がチーム展開の核心になります。

優先順位は エンタープライズ > 個人 > プロジェクト です。同名スキルがある場合、上位スコープが上書きします。法人管理者の立場で考えると、全社で必ず守ってほしいスキル（セキュリティチェックなど）はManaged Settingsで配布し、プロジェクト固有のものは`.claude/skills/`にコミットするという使い分けが理想的です。

Managed Settingsでの全社配布手順（エンタープライズ向け）

エンタープライズスコープのスキル配布は、MDM（Mobile Device Management）やAnsibleを通じたManaged Settings経由で行います。具体的には、管理者が以下のステップで配布します。

1. 各スキルのSKILL.mdファイルと設定を準備する
2. MDM/Ansible経由でエンドユーザーのマシンにSKILL.mdを配置する
3. Managed Settingsのsettings.jsonでskilOverridesや権限設定を行う
4. ユーザーはClaude Codeを再起動せずにスキルが反映される（ディレクトリ変更はライブ検知される）

Managed Settingsの重要な特徴は、ユーザー側から上書きできない点です。エンタープライズスキルは個人スコープより強制力があるため、セキュリティポリシーや必須チェックリストの配布に適しています。

（参照: code.claude.com/docs/en/skills#share-skills、参照日: 2026-06-04）

法人7業務の自作Skill — コピペですぐ使えるSKILL.md

ここからが記事のメインです。100社以上のAI研修・導入支援を通じて、法人でよく求められる7業務のSKILL.mdテンプレートを作成しました。それぞれそのままコピーして使えるSKILL.mdとして記載しています。

事例区分: 想定シナリオ
以下は100社以上の研修経験をもとに構成した典型的な業務シナリオです。架空の数字・社名は含まれていません。

パターン1: コードレビュー用Skill

エンジニアチームで最も需要が高いのがコードレビューSkillです。Gitの差分を自動取得してレビューする仕組みです。

---
name: コードレビュー
description: コードの変更をレビューする。コードレビューを依頼されたとき、変更点について聞かれたとき、または「/code-review」を入力したときに使う。
allowed-tools: Read Grep Bash(git diff *) Bash(git log *)
disable-model-invocation: false
---

## 現在の変更内容
!`git diff HEAD`

## ログ（直近5件）
!`git log --oneline -5`

## レビュー手順

1. 変更内容を把握する（セキュリティ・可読性・保守性の3軸で評価）
2. 以下のカテゴリで問題を分類する:
   - CRITICAL: セキュリティ脆弱性・データ損失リスク（即座に修正が必要）
   - HIGH: バグの可能性・パフォーマンス問題（マージ前に修正推奨）
   - MEDIUM: コード品質・可読性（改善を推奨）
   - LOW: スタイル・命名規則（余裕があれば対応）
3. 各問題について、問題箇所（ファイル名+行数）・問題の内容・修正案を示す
4. 全体評価（LGTM / 修正後LGTM / 要修正）を最後に1行で示す

パターン2: セキュリティ監査用Skill

情報システム部門からの要望で最も多いのが、コードのセキュリティチェックです。スキルをdisable-model-invocationにして、手動でしか実行できないようにするのがポイントです。

---
name: セキュリティ監査
description: コードベースのセキュリティ問題を監査する
allowed-tools: Read Grep Bash(find *) Bash(git diff *)
disable-model-invocation: true
---

## セキュリティ監査チェックリスト

以下の観点でコードを検査してください。問題があれば重大度（CRITICAL/HIGH/MEDIUM）と修正方法を示してください。

### 1. 認証・認可
- [ ] APIキーやパスワードがハードコードされていないか
- [ ] 環境変数経由でシークレットを扱っているか
- [ ] 適切な認証・権限チェックがあるか

### 2. インジェクション脆弱性
- [ ] SQLインジェクション対策（プリペアドステートメント使用）
- [ ] コマンドインジェクション対策（入力値サニタイズ）
- [ ] XSS対策（出力エスケープ）

### 3. データ保護
- [ ] 個人情報・機密情報の適切な暗号化
- [ ] ログへの機密情報出力がないか
- [ ] 不要なデータ保持がないか

### 4. 依存関係
- [ ] 既知の脆弱性がある依存関係がないか
- [ ] 不審なサードパーティライブラリがないか

まず `git diff HEAD` で変更範囲を確認し、影響範囲を絞ってから詳細チェックを行ってください。

パターン3: 議事録作成用Skill

会議の文字起こしや要点メモから、構造化された議事録を作成するSkillです。顧問先の管理部門で特に好評でした。

---
name: 議事録作成
description: 会議の文字起こし・メモから議事録を作成する。「議事録作ってほしい」「MTGの内容をまとめて」と言われたときに使う。
argument-hint: [テキストファイルパスまたはメモの内容]
---

## 議事録作成ガイドライン

$ARGUMENTS に記載の会議内容から、以下のフォーマットで議事録を作成してください。

### 出力フォーマット

# [会議名] 議事録

**日時**: [日時を抽出、不明な場合は「要確認」]
**出席者**: [出席者名を列挙]
**ファシリテーター**: [不明な場合は省略]

## 決定事項
（箇条書き。「〜することが決定」「〜で合意」の形で簡潔に）

## アクションアイテム
| 担当者 | タスク内容 | 期限 |
|--------|-----------|------|
| [名前] | [タスク] | [期限] |

## 議論サマリー
（トピック別に3〜5行で要約）

## 次回予定
（次回会議の日時・テーマがあれば記載）

### 注意事項
- 決定事項とアクションアイテムは必ず明確に分ける
- 期限が不明なアクションアイテムには「要確認」と記載する
- 固有名詞（人名・企業名・製品名）は原文のまま使用する

パターン4: 経営資料・レポート作成用Skill

---
name: 経営レポート
description: データや情報から経営者・役員向けのレポートを作成する。エグゼクティブサマリー・KPIレポート・取締役会資料の作成を依頼されたときに使う。
allowed-tools: Read
disable-model-invocation: true
---

## 経営レポート作成ガイドライン

$ARGUMENTS のデータ・情報を元に、経営者・役員が5分で理解できるレポートを作成してください。

### 必須構成

**エグゼクティブサマリー**（最大3文）
- 最も重要な結論から書く（詳細は後ろ）
- 具体的な数字を必ず含める
- 推奨アクションを最後に1文で示す

**現状分析**（数字ベース）
- KPI実績 vs 目標（表形式）
- 前期比・前年同期比を必ず含める
- アウトライヤー（特異値）に注釈

**課題と機会**
- 課題: 最大3項目（重要度順）
- 機会: 最大3項目（ROI期待値順）

**推奨アクション**
- 即実施（今週）: 1〜2項目
- 短期（1ヶ月以内）: 2〜3項目
- 中期（四半期以内）: 1〜2項目

### 文体ルール
- 体言止めで簡潔に
- 業界用語・略語には初出時に説明を追加
- 主観的評価より客観的データを優先

パターン5: 採用・HR用Skill

---
name: 採用支援
description: 採用業務（求人票・面接質問・評価シート作成）を支援する。採用、JD（ジョブディスクリプション）、面接について聞かれたときに使う。
---

## 採用支援ガイドライン

**実行できるタスク**:
1. 求人票（JD）の作成・改善
2. 面接質問リストの作成（ポジション別）
3. 評価シートの設計
4. 採用基準の言語化支援
5. オファーレター文案作成

### 求人票作成の注意事項
- 必要要件と歓迎要件を明確に分ける
- 業務内容を「具体的な行動」レベルで記述（「〜を担当」ではなく「〜を毎週実施する」）
- 男女雇用機会均等法・労働基準法に留意した表現を使う
- 「やりがい」「成長」などの曖昧表現より、具体的な環境・制度を記述する

### 面接質問設計の原則
- STAR法（Situation/Task/Action/Result）を基本フレームにする
- 各能力要件につき最低2問の行動質問を設計する
- YES/NOで答えられる質問は避ける
- 法的にアウトな質問（家族構成、宗教、政治観など）は含めない

依頼内容を教えてください（ポジション名・必要スキル・チーム規模など）。

パターン6: 法務・契約レビュー用Skill

---
name: 契約レビュー
description: 契約書・利用規約・NDAのリスクチェックと改善提案を行う。「契約書を見てほしい」「利用規約のリスクは？」と聞かれたときに使う。
allowed-tools: Read
model: claude-opus-4-5
effort: high
disable-model-invocation: true
---

## 契約書レビューガイドライン

⚠️ **重要**: このスキルはリスクの洗い出しを支援するものです。最終的な法的判断は必ず法律の専門家（弁護士・司法書士）に相談してください。

### レビュー手順

1. **基本情報の確認**
   - 当事者名・契約期間・主たる義務を把握する

2. **リスク観点でのチェック**
   - 免責条項・損害賠償の上限設定
   - 知的財産権の帰属（生成AI使用時に特に重要）
   - 解除条件・解除後の義務
   - 秘密保持義務の範囲と期間
   - 準拠法・管轄裁判所

3. **AI関連条項の特別チェック**（2026年現在の重要事項）
   - 生成AIツールの使用可否が明示されているか
   - AI生成コンテンツの著作権帰属
   - AIによる個人データ処理に関するDPIA義務

4. **出力フォーマット**
   - 🔴 高リスク: 即修正が必要な条項
   - 🟡 要確認: 交渉余地のある条項
   - 🟢 問題なし: 問題のない条項
   - 📝 推奨修正案: 各問題箇所への代替文案

パターン7: 営業・提案用Skill

---
name: 営業提案
description: 営業資料・提案書・フォローアップメールの作成を支援する。提案書、営業メール、商談準備について聞かれたときに使う。
argument-hint: [顧客名または案件概要]
---

## 営業支援ガイドライン

**実行できるタスク**:
1. 提案書（PowerPoint骨子）の作成
2. フォローアップメールの文案
3. 商談前のリサーチ質問リスト
4. 価値提案（バリュープロポジション）の言語化
5. 反論予測と回答準備

### 提案書作成の基本構成
1. 相手の課題認識（ヒアリング内容を整理）
2. 現状のギャップ（Before）
3. 解決後のイメージ（After）
4. 提案内容と実績
5. 期待成果（数値で示す）
6. 導入スケジュールと費用
7. 次のアクション

### 重要な注意事項
- 相手企業のHPや公開情報で下調べしてから書く
- 「御社の課題」を主語に置く（自社自慢より相手視点）
- 数字の根拠がないものは「想定」と明示する
- 決裁者の名前・役職を正確に記載する

$ARGUMENTS の情報を元に作成します。詳細を教えてください。

5ステップ実装フロー — 今日から始める法人導入

「ガイドを読んでいざ始めようとすると、どこから手をつければいいか分からない」という声をよく聞きます。そこで、法人がClaude Skillsを導入する際の実践的な5ステップを整理しました。チームで展開する前に、まず担当者が1人で試して動作を確認するフローです。

1. 個人スコープで1本試作する（15分）
   mkdir -p ~/.claude/skills/test-skill でディレクトリを作成し、上記のパターン1（コードレビュー）のSKILL.mdをそのまま貼り付けます。Claude Codeを起動し、/test-skill（またはディレクトリ名）と入力して動作を確認します。
2. 業務に合わせてカスタマイズする（30分〜1時間）
   試作スキルのdescription・本文の手順を自社業務に合わせて調整します。最も重要なのはdescriptionの精度です。Claudeがどんな依頼に対して自動発動するかがここで決まります。「〜を依頼されたとき」「〜について聞かれたとき」の形式で具体的に書くのがコツです。
3. プロジェクトスコープに移してチームで共有する（1〜2時間）
   動作確認が取れたスキルを .claude/skills/スキル名/SKILL.md としてプロジェクトのリポジトリにコミットします。Gitで管理することで、スキルのバージョン管理とチームメンバーへの配布が同時に実現できます。README.mdにスキルの使い方を記載することも忘れずに。
4. スキルの使い方をチームに周知する（ハーフデイ研修推奨）
   スキルを作っても、メンバーが使い方を知らなければ宝の持ち腐れです。/スキル名 の呼び出し方、自動発動の仕組み、$ARGUMENTSでの引数渡しを30分のランチ勉強会で共有するだけで定着率が大きく変わります。
5. Managed Settingsで全社展開する（IT部門と連携）
   組織全体で必須のスキル（セキュリティ監査・コーディング規約など）はMDM/Ansible経由でManaged Settings配布します。ユーザーが上書きできないため、コンプライアンス必須のポリシーを確実に適用できます。

失敗パターン4選と回避策

実際にClaude Skillsを法人導入した際によく見かける失敗パターンをまとめました。事前に知っておけば確実に回避できます。

失敗1: トリガーが競合して意図しないスキルが発動する

❌ よくある間違い: 複数のスキルに「〜してほしい」「チェックしてほしい」のような曖昧なdescriptionをつけると、Claudeが誤ったスキルを選択します。

⭕ 正しいアプローチ: descriptionには具体的なユースケースを書きます。「コードの変更についてレビューを依頼されたとき」と「請求書のフォーマットをチェックしてほしいと言われたとき」のように、業務ドメインを明確にするのが重要です。また、副作用のある操作（デプロイ・送信など）はdisable-model-invocation: trueで必ず手動発動に限定してください。

なぜ重要か: Claudeが誤ったスキルを自動発動すると、意図しない操作が実行される可能性があります。特に本番環境への操作を含むスキルは手動限定にする設計を徹底してください。

失敗2: プロジェクト共有後に一部メンバーにスキルが反映されない

❌ よくある間違い: .claude/skills/をGitにコミットしたのに、新しく参加したメンバーのClaude Codeにスキルが表示されない。

⭕ 正しいアプローチ: スキルはセッション起動時にディレクトリが存在していれば自動で検知されます。新規メンバーはGit cloneしてから一度Claude Codeを起動し直すことで反映されます。また、新しいトップレベルのskillsディレクトリを追加した場合（既存セッション中に追加した場合）は、Claude Codeの再起動が必要です。編集はライブ反映されますが、ディレクトリ新規作成には再起動が必要という点を周知してください。

失敗3: バージョン管理をせず古いスキルが本番で動き続ける

❌ よくある間違い: スキルをファイルとして各自のマシンに手動コピーで配布すると、誰かが更新しても全員に伝わらず、古い手順で動き続けるメンバーが出てきます。

⭕ 正しいアプローチ: プロジェクトスキル（.claude/skills/）はGitで管理し、変更はPRを通じてレビューしてからmainにマージします。スキルの変更履歴をコミットメッセージに残すことで、どのバージョンから何が変わったかが追跡できます。スキルのファイルには更新日・変更内容をコメントとして記載する運用も有効です。

失敗4: 機密情報をSKILL.mdに直接書いてしまう

❌ よくある間違い: データベースの接続文字列・APIキー・社内システムのパスワードをSKILL.md本文に直書きし、そのままGitにコミットする。

⭕ 正しいアプローチ: 機密情報は必ず環境変数か秘密管理ツール（Vault等）から読み込む設計にします。SKILL.md本文には${DB_HOST}のような変数を使い、実際の値はマシンの環境変数として設定します。また、SKILL.mdをGitにコミットする前にgit secretsやgitleaksでスキャンする習慣をつけてください。.claude/skills/ディレクトリは.gitignoreから除外しないよう注意が必要ですが、機密値を含むファイルは必ず.gitignoreに追加します。

チーム共有・運用設計のベストプラクティス

100社以上への導入経験から、Claude Skillsのチーム運用で成功している企業には共通のパターンがあります。

スキルの命名規則を統一する

ディレクトリ名がコマンド名になるため、チーム内で命名規則を決めることが重要です。推奨するのは「動詞-対象」形式です。

• review-code（コードレビュー）
• write-meeting-notes（議事録作成）
• check-security（セキュリティチェック）
• draft-proposal（提案書作成）

英語小文字 + ハイフン区切りで統一するだけで、スキル一覧の視認性が大きく改善します。

スキルをREADMEに索引化する

スキルの数が増えてくると、何があるかわからなくなります。.claude/skills/README.md（またはリポジトリのREADME）に索引テーブルを作ると便利です。

## 利用可能なClaudeスキル一覧

| コマンド | 用途 | スコープ |
|---------|------|---------|
| /review-code | Gitの差分をコードレビュー | プロジェクト |
| /check-security | セキュリティ脆弱性の確認（手動のみ） | プロジェクト |
| /write-meeting-notes | 議事録作成 | プロジェクト |
| /draft-proposal | 提案書骨子の作成 | 全社共通 |

定期的なスキルレビューをサイクルに組み込む

スキルは作りっぱなしにするのではなく、四半期ごとに有効性を確認します。「使われていないスキル」「descriptionを修正したらよく使われるようになったスキル」「業務変更で廃止すべきスキル」を識別するために、Claudeのセッションログやチームへの簡単なヒアリングを活用してください。

サブスキルの設計パターン（大規模チーム向け）

大規模チームでは、スキルを「親スキル + 子スキル」の階層で設計すると管理しやすくなります。たとえばquality-gateという親スキルが呼ばれたとき、内部でコードレビュー・セキュリティ監査・テストカバレッジチェックを順番に実行するような設計です。context: forkを使ってサブエージェントに各チェックを並列で実行させることも可能です。

チーム全体のAI活用計画については、Claude Codeチームプラン完全ガイドで詳しく解説しています。

TCO試算 — 個人・小規模チーム・大規模チームの費用対効果

Claude Skillsの導入コストと効果を、3つの規模で整理します。数値は一般的な企業での想定値であり、自社環境によって変動します（架空の確定数値ではなく参考レンジとして参照してください）。

事例区分: 想定シナリオ
以下は100社以上の研修経験をもとに構成した典型的な試算シナリオです。実際の効果は業務内容・チームスキルによって大きく異なります。

特に大規模チームでの効果として見落とされがちなのが、新人教育コストの削減です。業務標準手順をSkillとして定義しておけば、新人がClaude Codeを使うだけで自然にベストプラクティスに従った仕事ができます。「OJTの型」をSkillとして言語化するという活用方法は、多くの企業で好評でした。

セキュリティ設定と権限管理 — 法人導入の必須確認事項

Claude Skillsを法人で展開する際には、セキュリティ設定を適切に行う必要があります。セキュリティ設定の全体像については、Claude Codeセキュリティ設定完全ガイドを参照してください。

allowed-toolsの最小権限原則

allowed-toolsフィールドでは、スキルが必要とするツールだけを列挙する最小権限の原則を徹底します。

# NG: 広すぎる権限
allowed-tools: Bash

# OK: 必要な操作のみを明示
allowed-tools: Bash(git diff *) Bash(git log *) Read Grep

Bash(*)のようにワイルドカードを広く許可すると、スキル実行中にシステムへの任意コマンド実行を承認なしで許してしまいます。プロジェクトスキルのallowed-toolsはワークスペース信頼ダイアログを承認した後に有効になるため、リポジトリをcloneする前に必ずSKILL.mdの内容を確認してください。

disableSkillShellExecutionの活用

社内のセキュリティポリシーで動的コンテキスト注入（!`コマンド`）を禁止したい場合は、Managed SettingsでdisableSkillShellExecution: trueを設定します。これによりユーザー・プロジェクト・プラグインのスキルでのシェルコマンド実行が無効化されます（バンドルスキルとManaged Settingsスキルは影響を受けません）。

skillOverridesで個別スキルの表示制御

IT部門が全社配布スキルの一部をユーザーに使わせたくない場合、settings.jsonのskillOverridesで制御できます。

{
  "skillOverrides": {
    "deploy-production": "off",
    "admin-tools": "user-invocable-only"
  }
}

よくある質問（FAQ）

Q: SKILL.mdとCLAUDE.mdの使い分けは？

CLAUDE.mdは常にコンテキストに読み込まれる「常設の事実・ルール」、SKILL.mdは必要なときだけ読み込まれる「手順書・業務フロー」という使い分けが基本です。CLAUDE.mdが肥大化して「手順」が書かれていたら、それをSKILL.mdに分離するタイミングです。

Q: スキルの内容が古くなったときはどう更新する？

SKILL.mdファイルを直接編集するだけです。Claude Codeはスキルディレクトリの変更をライブ検知するため、セッションを再起動せずに即座に反映されます（ただし新規ディレクトリの追加は再起動が必要）。

Q: スキルを削除したらどうなる？

ディレクトリごと削除すればスキルは無効になります。現在のセッションではライブ検知により即座に非表示になります。過去のセッションログへの影響はありません。

Q: スキルのコンテキストはセッションをまたいで保持されるか？

スキルの定義（SKILL.mdの内容）は永続的に使えますが、スキルを実行した際のコンテキスト（会話履歴）は通常のセッション管理と同じです。スキルを呼び出すとその内容が会話に挿入され、セッション終了まで保持されます。

Q: プラグインとスキルの違いは？

スキルは単独のSKILL.mdファイル（またはディレクトリ）です。プラグインは複数のスキル・エージェント・MCPサーバー・フックをバンドルして配布できる仕組みで、より大規模な機能拡張向けです。小規模な業務テンプレート共有ならスキルで十分です。

まとめ：今日から始める3つのアクション

Claude Skillsは、法人でのAI活用を「個人ツール」から「チームのインフラ」へと転換する仕組みです。設定は難しくなく、SKILL.mdを1ファイル作るだけで始められます。

1. 今日やること: 上記のパターン1（コードレビュー）または3（議事録作成）のSKILL.mdを~/.claude/skills/に作成し、動作確認する
2. 今週中にやること: 自社の定型業務に合わせてSKILL.mdをカスタマイズし、.claude/skills/にコミットしてチームに共有する
3. 今月中にやること: 全社展開のためのManaged Settings設計をIT部門と協議し、コンプライアンス必須スキルの配布計画を立てる

Claude Code導入の次のステップとして、Claude Code完全ガイドもあわせてご参照ください。

参考・出典

• Extend Claude with skills — Claude Code Docs（Anthropic公式） — Anthropic（参照日: 2026-06-04）
• Settings — Claude Code Docs（Managed Settings） — Anthropic（参照日: 2026-06-04）
• Permissions — Claude Code Docs — Anthropic（参照日: 2026-06-04）

著者: 佐藤傑（さとう・すぐる）
株式会社Uravation代表取締役。X（@SuguruKun_ai）フォロワー約10万人。100社以上の企業向けAI研修・導入支援。著書『AIエージェント仕事術』（SBクリエイティブ）。SoftBank IT連載7回執筆（NewsPicks最大1,125ピックス）。
ご質問・ご相談はお問い合わせフォームからお気軽にどうぞ。