Claude CodeのAgent Skillsとは？使い方・設計・活用パターンを徹底解説

「Claude Codeに、いつも自分がやっている開発ルーチンを覚えさせたい」「プロジェクトごとのやり方を、エージェントにちゃんと守らせたい」──そんなニーズに応えるのが、Claude Codeで使える「Skills（Agent Skills）」です。

Skillsは、指示書となるSKILL.md、補助スクリプト、テンプレート、補足ドキュメントなどを1つのフォルダにまとめ、Claude Codeから再利用できるようにする仕組みです。2025年12月にオープンスタンダードとして公開された「Agent Skills」標準に基づいており、20以上のツールでSKILL.mdフォーマットを共有できます。


2026年3月時点では、/batch・/claude-api・/simplifyといったバンドルスキルに加え、effortフロントマターによる推論深度制御、動的コンテキスト注入、Pluginsによるスキルのパッケージ配布など、実務運用を支える機能が充実しています。
本記事では、Claude CodeにおけるSkillsの仕組み、SKILL.mdの設計、ZOZO・クラスメソッドなどの国内活用事例、他ツール比較、料金まで解説します。

Claude CodeにおけるAgent Skills

Agent Skillsは、2025年12月にAnthropicがオープンスタンダードとして公開したスキル定義フォーマットです。

agentskills.ioで仕様が管理されており、2026年3月時点ではClaude Codeだけでなく、GitHub CopilotのCoding Agent、Codex CLI、Gemini CLI、Cursor、Antigravity IDEなど20以上のツールがSKILL.mdフォーマットに対応しています。

Claude Codeは、この標準に沿ったスキルフォルダをローカル環境（~/.claude/skills/ やリポジトリ内の .claude/skills/）から検出し、開発タスクに応じて自動的に利用します。

なお、以前は「カスタムコマンド」（.claude/commands/配下のMarkdownファイル）と「Skills」が別の仕組みでしたが、現在はSkillsに統合されています。既存のカスタムコマンドファイルはそのまま動作しますが、新規作成時はSkills形式（.claude/skills/スキル名/SKILL.md）が推奨です。

Claude Codeまわりの構成要素（AGENTS.md・CLAUDE.md・SKILL.md・MCPなど）

Claude Codeまわりの主な構成要素をまとめると、次のようになります。

AGENTS.md

Codex CLI や Copilot Coding Agent、Gemini CLI など、複数のエージェントから共通で参照できる「上位ガイドライン」用フォーマットです。

Claude Code自体は現状「CLAUDE.md」を読む前提ですが、「AGENTS.md」を「CLAUDE.md」のシンボリックリンクにする、あるいは「CLAUDE.md」から「@AGENTS.md」のように参照することで、「1つのガイドラインを複数エージェントで共有する」という運用もできます。

【関連記事】
AI開発の新常識「agents.md」とは？AIの性能を引き出す書き方を徹底解説

CLAUDE.md

Claude Code向けのプロジェクトガイドです。

「このリポジトリでは、こういう前提・コマンド・禁止事項で動いてほしい」というルールや、レビュー方針などを記述します。プロジェクトルートや「.claude/CLAUDE.md」、グローバル設定として「~/.claude/CLAUDE.md」を置くパターンがあります。

SKILL.md（Agent Skills）

テスト実行・リリース準備・リファクタリングなど、まとまったタスクのワークフローを定義するレシピです。

入力・出力・手順・制約・例を構造化して書き、「~/.claude/skills/スキル名/SKILL.md」や「.claude/skills/スキル名/SKILL.md」として配置します。1つのディレクトリが1つのスキルに対応します。

【関連記事】
Agent Skills(Claude Skills)とは？作成手順や使い方、料金を徹底解説！

MCP（Model Context Protocol）

データベースやチケット管理などの外部システムを「ツール」として公開するためのプロトコルです。

Agent Skillsからは、MCP経由で公開されたツールやClaude Codeのツール群を組み合わせて利用し、より複雑なワークフローを自動化できます。

【関連記事】
MCPとは？使い方・料金体系を徹底解説！

Plugins

Skills・Agents・Hooks・MCPサーバーを1つのパッケージにまとめて配布できる仕組みです。

個別のSkillsだけでなく、関連するサブエージェントやフック、MCPサーバー定義をまとめて「このプラグインを入れれば一式揃う」という形で共有できます。プラグイン内のスキルはplugin-name:skill-nameという名前空間で管理されるため、プロジェクトのスキルと名前が衝突しません。

プロンプト

「いまこの会話で何をしてほしいか」を伝える、その瞬間の要求です。
Claude Codeは、「CLAUDE.md」や「SKILL.md」の内容を前提に、開発者のプロンプトを踏まえてどのスキルをどう使うかを自動的に判断します。

実際のフローとしては、次のように整理しておくとイメージしやすくなります。

1. Claude Codeが、グローバル／プロジェクトの「CLAUDE.md」を読み、プロジェクトの前提・ルールを把握する。
   「AGENTS.md」を使っている場合は、「CLAUDE.md」を「AGENTS.md」のシンボリックリンクにするなどの運用で、共通ガイドラインを共有します。
   
   

2. 開発者のプロンプトに応じて、「~/.claude/skills」や「.claude/skills」配下の SKILL.md から、適切なスキルが自動的に選ばれます。
   
   

3. 必要に応じて MCP 経由のツールやシェルスクリプトを呼び出しながら、SKILL.md に書かれた手順どおりにタスクを進めます。

という構造で押さえておけば十分です。

Claude CodeでSkillsを使う手順

Claude CodeでSkillsを活用するにあたっては、「Claude Codeが問題なく使えていること」を前提に、あとはプロジェクト側でスキルフォルダをどう用意するかを押さえておけば十分です。

ここでは、そのための最低限の前提と、リポジトリ内での準備方法を整理します。

プロジェクト内にスキルフォルダを置く

Claude Codeで使うSkillsは、配置場所に応じて適用範囲が変わります。以下の表で整理しました。

頻繁に使う汎用スキルはPersonal（~/.claude/skills/）に、特定プロジェクト専用のスキルはProject（.claude/skills/）に配置するのが基本です。同じ名前のスキルが複数レベルに存在する場合は、Enterprise > Personal > Projectの優先順位で上位が適用されます。

また、モノレポのサブディレクトリで作業しているとき、そのサブディレクトリ内の.claude/skills/も自動検出されます。たとえばpackages/frontend/配下のファイルを編集している場合、packages/frontend/.claude/skills/のスキルも自動的に読み込まれます。

プロジェクト内での典型的な構成は、次のようなイメージです。

repo-root/
  .claude/
    skills/
      webapp-testing/
        SKILL.md
        run_local_tests.sh
        fixtures/
          sample.json
      docs-refactor/
        SKILL.md
  CLAUDE.md
  src/
  tests/
  ...

このように、リポジトリの直下に .claude/skills フォルダを置き、その配下に「スキルごとのサブフォルダ」を作るイメージです。

ポイントは次の通りです。

• スキルは、リポジトリごとにローカル配置する（プロジェクト単位で完結させる）
• スキルフォルダには、必要最低限のファイルだけを入れる（巨大なアセットは避ける）
• CLAUDE.mdと合わせてコミットし、レビュー対象に含める

グローバルな「デフォルトインストールパス」を前提にするのではなく、
「このリポジトリの中に、このプロジェクト専用のスキルがある」という形にしておくと、安全かつ再現性が高くなります。

バンドルスキル（組み込みスキル）

2026年3月時点で、Claude Codeには以下のバンドルスキルが標準搭載されています。インストール不要で、どのプロジェクトでもすぐに利用できます。

バンドルスキルは、ビルトインコマンド（/init や /clear など）とは異なり、プロンプトベースで動作します。つまり、内部でサブエージェントを生成したり、複数ファイルを読み込んだりといった柔軟な処理が可能です。

自分で作ったカスタムスキルと同じ仕組みで動いているため、バンドルスキルのSKILL.mdを読むと、自作スキルの設計の参考にもなります。

--add-dirによる追加ディレクトリ読み込み

Claude Codeの起動時に --add-dir オプションで追加ディレクトリを指定すると、そのディレクトリ内の .claude/skills/ も自動的に読み込まれます。

たとえば、共通のスキルセットを別リポジトリで管理している場合、--add-dir で参照するだけで、プロジェクト側にスキルをコピーせずに利用できます。モノレポ内のサブディレクトリにある .claude/skills/ も自動検出されるため、パッケージごとにスキルを配置する運用も可能です。

Claude Code×Skillsの基本ワークフロー

ここでは、Claude CodeでSkillsを使うときの典型的な流れを、ざっくりと整理します。

1. プロジェクトを準備する

まず、開発者側で次のような準備を行います。

• CLAUDE.mdをプロジェクトルートに追加し、プロジェクトの前提やコマンドを記述する
• プロジェクト内の 「.claude/skills」フォルダを作成し、スキルフォルダとSKILL.mdを用意する
• 必要に応じて、テストスクリプトやフィクスチャを配置する

CLAUDE.mdは、「プロジェクト専用のREADMEを、Claude向けに書き直したもの」と考えるとイメージしやすいです。

2. Claude Codeからリポジトリを開く

次に、Claude Codeを起動し、対象のリポジトリを開きます。

• VS Code拡張や専用クライアントから、作業したいリポジトリに接続する
• 最初のロード時に、ClaudeがCLAUDE.mdなどを読み込んでコンテキストを構築する
• 「.claude/skills」フォルダ内のスキルは、Progressive Disclosure（段階的開示）という仕組みで効率的に読み込まれる

この段階では、まだ特定のスキルが強制的に呼ばれているわけではなく、「候補として存在している」状態です。

Claude CodeのProgressive Disclosureは、次のように動作します。

1. セッション開始時に、各スキルのSKILL.mdからフロントマター（nameとdescription）だけがコンテキストに読み込まれる
2. 開発者の指示内容と各スキルのdescriptionを照合し、関連性が高いスキルが選ばれる
3. 選ばれたスキルのSKILL.md本文（手順・制約・例など）が初めてフルに読み込まれ、実行に移る

この仕組みにより、スキルの数が増えてもコンテキストウィンドウを圧迫せず、必要なスキルだけが適切なタイミングで展開されます。スキルのdescriptionを具体的かつ簡潔に書くことが重要なのは、この段階的な読み込みの仕組みがあるためです。

3. 会話の中でスキルを呼び出す

開発者は、普段どおりClaude Codeに指示を出していきます。

• 「このリポジトリでユニットテストを走らせて、失敗したテストを要約して」
• 「いつものリリース手順に沿って、変更点のチェックリストを出して」
• 「このモジュールに新機能を追加するための実装方針と差分を提案して」

Claude Codeは、上記のProgressive Disclosureを経て、タスクに最適なスキルのフルコンテンツを読み込み、SKILL.mdに書かれた手順に従って実行します。

SKILL.mdのフロントマターにuser-invocableフィールドを設定しておけば、スラッシュコマンド（/スキル名）として明示的に呼び出すこともできます。

この場合、Claude Codeはdescriptionの照合をスキップして、指定されたスキルを直接実行します。

4. 実行結果をレビューし、改善していく

スキルが動くと、テスト結果やログの要約、生成されたコードの差分などが返ってきます。

• Claudeから提案された手順やコマンドを確認する
• 変更されたファイルの差分をレビューし、必要に応じて修正する
• スキルの指示やスクリプトが微妙な場合は、SKILL.mdやスクリプトの内容を調整し、再度試す

この「スキル側を少しずつチューニングしていく」サイクルを回すことで、自分のチームにフィットしたSkillsセットが育っていきます。

Claude Code向けSkill設計のベストプラクティス

Claude Codeで使うSkillsは、「コードをさわるエージェント」に直接権限を渡すことになるため、設計が重要です。ここでは、SKILL.md・フォルダ構成・CLAUDE.mdとの役割分担という3つの観点で整理します。

SKILL.mdに書くべき項目

すべてのスキルには、SKILL.mdが必須です。
Agent Skillsの仕様では、この1ファイルに「メタ情報（フロントマター）」と「手順書（本文）」をまとめておく前提になっています。

例として、「このリポジトリのWebアプリに対して自動テストを実行し、失敗したテストを要約する」用途のスキル（Web App Testing）の記述例は次のとおりです。

---
name: webapp-testing
description: Run focused tests against this web application and summarize failures for the developer.
---

# Web App Testing Skill

## Purpose
Run the project's automated tests in a safe, repeatable way and summarize any failing cases.

## Inputs
- Test code and configuration files in this repository
- The branch or test scope specified by the developer
- Any test commands, flags, or environment variables described in CLAUDE.md

## Outputs
- A summary of the test run
- A list of failing tests (file names, test names, error messages)
- Suggested next actions or potential fixes when appropriate

## Steps
1. Read `CLAUDE.md` to understand how to run the test suite.
2. Run the tests locally, keeping the scope narrow enough to finish in a reasonable time.
3. Collect failing tests and list them with file paths, test names, and relevant output.
4. Group failures by root cause and propose next steps to the developer.

## Safety and constraints
- Do not modify files outside the project root.
- Avoid running extremely long or full-regression suites unless explicitly requested.
- Confirm with the developer before running tests that depend on external services or networks.

## Examples
- "Run the unit tests for this repository and summarize only the failing tests."
- "Use the Web App Testing skill to investigate why the CI test job is failing."

押さえておきたいポイントは次のとおりです。

• フロントマターのnameとdescriptionは短く、具体的に書く
  → 「どんなタスクのときに使うべきか」が分かるようにする
  
  
• 本文では、目的・入力・出力・手順・制約・例を見出しで分ける
  → 人間が読んでも「業務手順書」として成立するレベルで整理する
  
  
• 長い説明文よりも、箇条書きベースで段階的に書く
  → Claude側がステップを抽出しやすくなる

SKILL.mdの高度なフロントマター設定

先ほどの例ではnameとdescriptionだけを使いましたが、Agent Skills標準では、スキルの挙動をより細かく制御するためのフロントマターフィールドが用意されています。

以下の表に、Claude Codeで利用できる主なフロントマターフィールドを整理しました。基本のnameとdescriptionに加えて、スキルの呼び出し方法や実行環境、セキュリティ制約を宣言的に設定できます。

特に押さえておきたいのは、disable-model-invocationとuser-invocableの使い分けです。

disable-model-invocation: true を設定すると、Claudeが自動的にそのスキルを読み込むことを完全にブロックし、開発者が /スキル名 で明示的に呼び出した場合だけ実行されます。

一方、user-invocable: false にすると、スラッシュコマンドメニューには表示されなくなりますが、Claudeは自動的に読み込むことができます。「バックグラウンドで参照してほしいが、ユーザーに直接呼ばせたくない」場合に使います。

effortフィールドを使うと、スキルごとに推論の深さを制御できます。ファイルリネームのような機械的な操作ならlowに設定してトークン消費を抑え、複雑なコードレビューにはhighやmax（Opus 4.6専用）を指定して精度を上げる、といった使い分けが可能です。

context: forkを指定すると、そのスキルはメインの会話とは別のサブエージェントプロセスとして実行されるため、メインのコンテキストウィンドウを消費せずに独立して作業を進められます。agentフィールドでサブエージェントのタイプ（Explore、Plan、general-purpose）を指定することもできます。

SKILL.md内で使える文字列置換変数

SKILL.mdの本文では、以下の変数を使ってスラッシュコマンドの引数やセッション情報を動的に参照できます。

たとえば「/webapp-testing src/auth」と実行すると、SKILL.md内の$ARGUMENTS部分が「src/auth」に置き換わり、テスト対象を動的に指定できます。

「${CLAUDE_SKILL_DIR}」を使えば、スキルフォルダ内のスクリプトやテンプレートを相対パスではなく絶対パスで参照でき、どのディレクトリから呼び出しても正しく動作します。

動的コンテキスト注入とultrathink

SKILL.mdの本文では、シェルコマンドの実行結果をスキルの内容に埋め込む「動的コンテキスト注入」が使えます。

SKILL.md内に !`コマンド` と記述すると、スキルが読み込まれる前にそのコマンドが実行され、出力結果でプレースホルダーが置き換わります。たとえば !`gh pr diff` と書いておけば、PRの差分がスキルの本文に自動挿入された状態でClaudeに渡されます。

これは前処理であり、Claudeが実行するものではありません。Claudeは最終的に組み立てられた結果だけを受け取ります。PRレビューやデプロイ前チェックなど、外部の最新状態をスキルに取り込みたいケースで有効です。

また、SKILL.mdの本文中に「ultrathink」というキーワードを含めると、そのスキルの実行時に拡張思考（Extended Thinking）が有効になります。複雑な設計判断やコードの全体構造を踏まえた分析が必要なスキルで活用できます。

フォルダ構成とスクリプト・フィクスチャ設計

SKILL.mdだけでもシンプルなスキルは作れますが、実務ではスクリプトやフィクスチャを組み合わせることで、より再現性の高いワークフローになります。

フォルダ構成の例をもう少し細かく見ると、次のようなパターンが考えられます。

repo-root/
├── .claude/
│   └── skills/
│       ├── webapp-testing/
│       │   ├── SKILL.md              (required: スキルの定義)
│       │   ├── run_local_tests.sh    (optional: テスト実行用スクリプト)
│       │   └── fixtures/
│       │       └── sample-user.json  (optional: 安全なサンプルデータ)
│       └── docs-refactor/
│           ├── SKILL.md              (required: スキルの定義)
│           └── patterns.md           (optional: リファクタリング方針メモ)
├── CLAUDE.md                         (optional: プロジェクト全体の前提・コマンド)
├── src/                              (アプリ本体)
└── tests/                            (テストコード)

構成を考えるときのポイントは、次の通りです。

• スキルフォルダは「1タスク＝1フォルダ」が基本
  → テスト、リファクタリング、ドキュメント整形などで分ける
  
  

• スクリプトは、小さく・決定的な挙動にする
  → 実行するたびに結果がブレないようにする
  
  

• 巨大なデータやバイナリは入れない
  → スキルの読み込みが重くならないようにする
  
  

• 入出力フォーマット（テキスト・JSON・JUnitレポートなど）は、SKILL.md側に明記する

Anthropicやコミュニティのベストプラクティスでは、「スキルフォルダは小さく保ち、SKILL.mdと最小限のスクリプト・フィクスチャだけを入れる」ことが強調されています。

大きなデータセットや長大なログは、別の場所で管理し、必要に応じて切り出した断片だけをフィクスチャとして置いておく方が安全です。

CLAUDE.mdとの役割分担

Claude Codeでは、CLAUDE.mdが非常に重要な役割を持ちます。

Anthropicのエンジニアリングガイドでは、「プロジェクトのスコープ・コマンド・テスト方針・注意点などをまとめた、Claude向けのプロジェクトガイド」として整理されています。

典型的なCLAUDE.mdには、次のような内容を含めます。

• Scope（どこまで操作してよいか）
• Common Commands（アプリ起動・テスト実行・ビルドなどの標準コマンド）
• Code Style（コーディング規約、PRポリシーなど）
• Testing Expectations（テスト戦略、期待する実行時間など）
• Review Rules（レビュー時の観点、ブランチ戦略など）

一方、Skills側のSKILL.mdは、「特定のタスクをどう進めるか」にフォーカスします。

• CLAUDE.md
  → 「このリポジトリ全体で、どういう前提・ルールで動いてほしいか」
  
  

• SKILL.md
  → 「その中で、テスト実行・リファクタリング・リリース準備などをどう進めるか」

この役割分担を意識しておくと、CLAUDE.mdとSKILL.mdが重複したり、どちらか一方が肥大化したりするのを防ぎやすくなります。

Claude Codeならではのユースケース

ここからは、Claude Codeだからこそ相性が良いSkillsのユースケースをいくつか紹介します。

「自分の現場だと何からスキル化すべきか」をイメージするためのヒントとして読んでみてください。

1. テスト実行・エラー調査スキル

もっとも分かりやすいのが、「テスト実行や失敗時の調査」をスキルとして切り出すパターンです。

このスキルでは、例えば次のようなことを担当させます。

• プロジェクト標準のテストコマンドでテストを実行する
• 失敗したテストだけを抽出し、テスト名・ファイル名・メッセージを一覧化する
• よくある失敗パターン（タイムアウト・依存関係エラーなど）をグルーピングして要約する
• 必要に応じて、関連するソースコードや設定ファイルを参照し、次の一手を提案する

CIで落ちたテストの再現や、ローカルでのデバッグ開始までの「最初の数十分」を、大きく圧縮できるパターンです。

2. モノレポ探索・リファクタリング支援スキル

モノレポや大規模なコードベースでは、「どこから読めばいいのか」「どこを直せば影響が最小か」といった把握に時間がかかりがちです。

ここでは、次のようなスキルを用意しておくと便利です。

• レイヤー構造や依存関係をまとめたガイドを参照しながら、影響範囲を示すスキル
• 既存のリファクタリング方針やアンチパターン集をもとに、改善案を提案するスキル
• 変更予定モジュールに関するテストやドキュメントを洗い出し、事前にチェックリスト化するスキル

これらのスキルを組み合わせることで、

• 「この機能を改修するときは、まずここを見て、こういうテストを走らせる」
• 「この依存関係は触らない方がよい」

といった「暗黙知」をClaude Codeに共有しやすくなります。

3. リリース・運用タスクの半自動化スキル

もうひとつ典型的なのが、「リリース前後の定型作業」をスキル化するパターンです。

例えば、次のようなタスクをまとめておきます。

• リリースノートの草案作成（コミットやPRログをもとに要約）
• 変更点のリスク整理（Breaking changeがありそうな箇所の洗い出し）
• 必須チェックリスト（テスト完了・ドキュメント更新・設定の反映など）の確認
• 運用ドキュメントやRunbookの更新支援

リリース作業は「だいたい同じことを毎回やっている」一方で、人的ミスが起きやすい領域です。
Skillsとして切り出しておくことで、メンバーが変わっても最低限の品質ラインを維持しやすくなります。

国内外の企業活用事例

上記のパターンを実際に活用している企業の事例を紹介します。スキル化による具体的な効果が報告されているケースです。

ZOZOテクノロジーズ：レガシーコード調査の大幅短縮

ZOZOテクノロジーズでは、Claude Codeを活用してレガシーコードの調査を大幅に効率化しています。従来は2〜5日かかっていた大規模コードベースの影響範囲調査を、CLAUDE.mdとスキルの組み合わせで数時間に短縮しました。

スキルとしては「指定モジュールの依存関係を洗い出し、影響範囲をリストアップする」というパターンが基本で、プロジェクト固有のアーキテクチャ情報をCLAUDE.mdに記述しておくことで、Claudeが適切なコンテキストを持った状態で調査を進められるようにしています。

参考: Agent Skills導入で既存コード調査のリードタイムを2〜5日から数時間へ短縮 - ZOZO TECH BLOG

クラスメソッド：AWSコスト分析のワンコマンド化

クラスメソッドでは、AWSのコスト分析をClaude Codeのスキルとして整備し、ワンコマンドで実行できるようにしています。CUR 2.0のParquetデータをDuckDBでクエリし、CloudTrailでリソース作成者を特定、改善提案までを一気通貫で処理するワークフローです。

従来は手作業でダッシュボードを確認し、スプレッドシートにまとめていた作業が、/aws-cost-analysis コマンド1つで完結するようになりました。

参考: Claude CodeのSkillで複数AWSアカウントのコストを一括分析してみた - DevelopersIO

thoughtbot：2週間スプリントでのSkills活用

米国のソフトウェアコンサルティング企業thoughtbotでは、2週間スプリントの開発サイクルにClaude CodeのSkillsを組み込んでいます。クライアントのRailsプロトタイプをテスト付きのプロダクション品質コードとして構築した事例では、CLAUDE.mdによるコンテキスト管理とスキルの組み合わせが成果を上げています。

参考: Claude Code: Production ready code in a two-week sprint - thoughtbot

他のAgent Skills実装との違い・使い分け

Claude CodeのSkillsは、2025年12月にオープンスタンダードとして公開されたAgent Skills標準（agentskills.io）に基づいています。2026年3月時点では20以上のツールがこの標準に対応しており、SKILL.mdフォーマットを共有できます。

ただし、同じSKILL.mdを読むといっても、各ツールの「紐づくエージェント」や得意領域には明確な違いがあります。ここでは主要ツールごとの特徴と、Claude Codeとの使い分けを整理します。

GitHub Copilot Coding Agent

GitHub Copilot Coding Agentは、GitHub Actionsとの統合が最大の強みです。Issueをアサインすると自動でブランチ作成→実装→PR作成まで進み、SKILL.mdに定義したワークフローをCI/CDパイプライン内で実行できます。

Claude Codeとの違いは、CopilotがGitHub上の非同期ワークフロー（Issue→PR→マージ）に最適化されているのに対し、Claude Codeはターミナルでの対話的な開発に特化している点です。GitHub中心のチームでCI連携を重視するならCopilot、ローカル開発での柔軟な操作を求めるならClaude Codeが適しています。

Codex CLI

OpenAI Codex CLIは、サンドボックス環境での安全な実行と、マルチファイル編集に強みを持つCLIツールです。SKILL.mdフォーマットに対応しており、agents.mdとの連携もサポートしています。

Claude Codeとの違いは、Codex CLIがサンドボックスでの隔離実行を前提としているのに対し、Claude Codeはローカル環境で直接ファイルを操作する点です。セキュリティポリシーが厳格な環境ではCodex CLIのサンドボックスが有利ですが、実際のプロジェクト環境でテスト実行やビルドまで含めた一気通貫の作業にはClaude Codeが向いています。

Gemini CLI

Gemini CLIは、GoogleのGeminiモデルをターミナルから利用するCLIツールで、Agent Skills標準にも対応しています。Googleエコシステム（GCP、Firebase、Android Studio等）との連携に強みがあり、100万トークン超のコンテキストウィンドウを活かした大規模コードベースの一括処理が特徴です。

Claude Codeとの違いは、Gemini CLIがGCPネイティブ環境で力を発揮するのに対し、Claude CodeはCLAUDE.mdによるプロジェクトカスタマイズの深さとMCP連携の柔軟さが強みです。

Cursor

Cursorは、VS Codeフォークのエディタ型AIコーディングツールで、.cursor/rules/にルールファイルを配置する独自の仕組みを持っています。Agent Skills標準のSKILL.mdも読み込み可能ですが、主にエディタUI上のインライン補完やチャットパネルでの対話に最適化されています。

Claude Codeとの違いは、CursorがGUIベースのエディタ体験に寄せているのに対し、Claude Codeはターミナルファーストでシェルスクリプトやパイプラインとの親和性が高い点です。

比較表

以下の表で、主要ツールの特徴を比較しました。自分のワークフローに合ったツール選定の参考にしてください。

実務で選ぶ際のポイントは、「どこで作業するか」と「どのエコシステムに依存しているか」です。GitHub ActionsでCI/CDを回しているチームならCopilot、GCPネイティブならGemini CLI、ターミナルでの対話的開発ならClaude Codeが最もスムーズです。SKILL.mdフォーマットが共通なので、複数ツールの併用もしやすい設計になっています。

Claude Code×Skillsの運用とガバナンス

コードを扱うエージェントに権限を渡す以上、運用とガバナンスの設計は欠かせません。ここでは、個人・チーム・組織それぞれのレイヤーで意識しておきたいポイントを簡単にまとめます。

個人環境で試すときのポイント

個人でSkillsを試す段階では、次のようなガイドラインを置いておくと安全です。

• 最初は小さなリポジトリやサンプルプロジェクトで試す
• 破壊的な操作（削除・リネームなど）が必要なスキルは、最初から作らない
• 変更内容は必ず差分を確認し、手動でコミットする
• 不安なスクリプトは、まず自分で単体実行して挙動を確認する

このフェーズでは、「とりあえず便利かどうか」「どのくらい手間が減るか」を感覚的につかむのが目的です。

チーム導入時のルールづくり

チームで本格的に使い始めるときは、次のようなルール化があると運用しやすくなります。

• 「.claude/skills」 や 「~/.claude/skills」 配下の変更も、通常のコードレビュー対象に含める
• SKILL.mdやスクリプトには、作成者・オーナーを明記する
• CLAUDE.md・スキルの変更は、必ずPull Request経由で行う
• 定期的にスキル一覧を棚卸しし、重複・陳腐化したものを整理する

Anthropicのエンジニアリングガイドやコミュニティの事例でも、CLAUDE.mdやSkills関連ファイルを通常のリポジトリ運用の一部として扱い、バージョン管理とレビューを徹底することが推奨されています。

「AI向けの特別なファイル」ではなく、「チーム全員が読む前提のドキュメント＆スクリプト」として扱うと、品質を維持しやすくなります。

チーム規模が大きくなると、Skillsに加えてAgent Teams（複数のClaude Codeエージェントを協調動作させる仕組み）を組み合わせる運用パターンも出てきます。スキルで標準化した手順をAgent Teamsで並列実行するという構成です。

セキュリティと権限設計

Claude Codeでは、スキルの実行権限を3段階で制御できます。組織のセキュリティ要件に合わせて、適切なレベルを選択してください。

1. Skillツール自体の無効化

settings.jsonで permissions.deny に "Skill" を追加すると、スキルの実行機能そのものを無効化できます。開発環境ごとに制御でき、組織管理者がenterprise設定で一括適用することも可能です。

2. スキル単位の許可・拒否パターン

settings.jsonの permissions.allow / permissions.deny で、特定のスキルだけを許可または拒否するパターン指定ができます。構文はSkill(name)で完全一致、Skill(name *)でプレフィックスマッチです。たとえばSkill(batch)を許可リストに入れ、それ以外を拒否することで、チームが承認済みのスキルだけを利用可能にできます。

3. disable-model-invocationによる手動限定

SKILL.mdのフロントマターで disable-model-invocation: true を設定すると、Claudeの自動読み込みをブロックし、開発者が /スキル名 で明示的に呼び出した場合だけ実行されます。機密性の高い操作を含むスキルや、本番環境に影響するスキルに適しています。

これら3つの制限方法に加えて、以下の運用ガイドラインも併せて整備しておくことを推奨します。

• 外部から持ち込んだスキルやスクリプトは、必ず内容をレビューしてから使う
• スキルが触れるファイルパスやディレクトリを明示し、それ以外には触れないように書く
• 機密情報（シークレット、認証情報）は、SKILL.mdやスクリプト内に直接書かない
• 本番環境用スキルと検証用スキルは、リポジトリやブランチを分けるなどして明確に区別する
• SKILL.md のフロントマターで allowed-tools を指定し、「このスキル実行中に利用してよいツール」をホワイトリスト方式で制限する
• context: forkでサブエージェント実行する場合も、allowed-toolsで権限を絞り、メインプロセスと同等の制約を適用する

全体的な設計としては、settings.jsonでグローバルな権限制御を行いつつ、スキル単位ではフロントマターのallowed-toolsとdisable-model-invocationで個別に制限をかける、という多層防御が推奨されます。

よくあるハマりどころ・アンチパターン

Claude Code×Skillsを試し始めた時に、特に起きやすい失敗パターンをいくつか挙げておきます。

• 1つのSKILL.mdに「あれもこれも」詰め込みすぎる
  → テスト／リリース／リファクタリングなどは、原則「1タスク＝1スキル」に分ける。
  
  
• グローバルなSkillsにプロジェクト固有の前提を書いてしまう
  → プロジェクト固有の前提は 「.claude/skills」側に寄せ、汎用化できる部分だけ 「~/.claude/skills」 に切り出す。
  
  
• CLAUDE.mdとSKILL.mdの役割がごちゃごちゃになる
  → CLAUDE.mdには「リポジトリ全体の前提・ルール」、SKILL.mdには「そのタスクの手順・制約」だけを書く。
  
  
• スキルの変更がレビューされない
  → 通常のコードと同様、Skills配下の変更もPull Request経由でレビューするルールを明文化しておく。
  
  
• フロントマターを設定せず、descriptionが曖昧なまま運用する
  → Progressive Disclosureはdescriptionを基に照合するため、曖昧な説明だと意図しないスキルが選ばれたり、必要なスキルが見落とされたりする原因になる。

こうしたアンチパターンを最初に共有しておくだけでも、「スキルがカオスになって維持できない」という事態をかなり防ぎやすくなります。

AIエージェントの「スキル設計」を業務プロセスにも応用するなら

Claude Code Skillsで得られる「AIに再現性のある行動をさせるための構造設計」の考え方は、コーディング以外の業務にもそのまま応用できます。承認ワークフロー・データ集計・レポート生成など、社内の定型業務もルールを定義してAIに任せる時代に入っています。

AI総合研究所のAI業務自動化ガイドでは、どの業務領域からAI化を始めるべきか、導入パターンと効果測定の枠組みを体系的にまとめています。スキル設計の経験を活かして、開発チームの枠を超えた業務自動化を検討してみてください。

AIコーディングの知見を業務全体に拡張

スキル設計の考え方を業務自動化にも

Claude Code Skillsで開発を構造化したように、業務プロセスもAIで体系的に自動化できます。どの領域から始めるべきかをまとめた無料ガイドです。

▶ 無料でダウンロード

Claude Code Skillsの料金

Pro / Maxのサブスクリプション認証で使う限り、Skills機能自体に個別の追加料金はかかりません。通常の利用枠の中でSkillsが動作します。ただし、ANTHROPIC_API_KEYを設定してAPI認証で利用する場合はAPI使用料が発生します。Team / Enterpriseでは契約形態やextra usage設定によって課金条件が異なり、usage-based Enterpriseやextra usage有効時はAPIレート課金になります。

ただし、スキルの設計によってトークン消費量は大きく変わります。以下のポイントを意識すると、コストを最適化しやすくなります。

• SKILL.mdは500行以内を目安にする
  SKILL.mdの内容はコンテキストウィンドウに読み込まれるため、不必要に長いと他の情報を圧迫します。手順書として必要十分な分量に抑えましょう。
  
  

• CLAUDE.mdは200行未満を目標にする
  CLAUDE.mdはセッション開始時に毎回読み込まれます。公式の推奨は1ファイルあたり200行未満です。プロジェクトが成長するにつれて肥大化しやすいため、定期的に見直して不要な記述を削除します。
  
  

• modelフィールドでコストを制御する
  SKILL.mdのフロントマターで model: haiku を指定すると、そのスキルの実行にHaikuモデルが使われます。コードレビューやログ要約などの軽量タスクには十分な品質で、コストを大幅に抑えられます。
  
  

• context: forkでメインウィンドウを節約する
  サブエージェントとして独立実行することで、メインの会話のコンテキストウィンドウを消費せずにスキルを動かせます。長時間のテスト実行や大量ファイルの処理に有効です。
  
  

• effortフィールドで推論深度を調整する
  SKILL.mdのフロントマターで effort: low を指定すると、ファイルリネームやフォーマット変換といった機械的な処理でトークン消費を抑えられます。逆に、設計レビューのような高精度が求められるスキルには effort: high を設定します。

2026年3月時点では、Claude Codeの課金条件は認証方法と契約形態で異なります。Pro / Maxのサブスクリプション認証では追加の個別課金なしで使えますが、API認証や一部のTeam / Enterprise運用ではAPIレート課金が発生します。Skillsを多用する場合は、自社の契約形態とextra usage設定を先に確認しておくのが安全です。

Claude Code Skillsのまとめ

Claude CodeのSkills（Agent Skills）は、「賢いチャットボット」だったClaudeを、「プロジェクトの文脈とルールを理解した、再現性の高い開発メンバー」に近づけるための仕組みです。

• オープンスタンダードに基づくポータブルな設計
  SKILL.mdフォーマットはagentskills.ioで管理されるオープンスタンダードで、20以上のツールが対応。基本フォーマットは共有しやすい設計ですが、allowed-toolsやcontextなどClaude固有の拡張を使ったスキルは、他ツールでそのまま動くとは限りません
  
  

• バンドルスキル＋コンテキスト予算で実用的な運用
  /batch・/claude-api・/simplifyなど5つのバンドルスキルが標準搭載。Progressive Disclosureとコンテキスト予算（2%ルール）により、スキルの数が増えてもパフォーマンスを維持できる
  
  

• 企業導入で実証された定量効果
  ZOZOテクノロジーズではレガシーコード調査を2〜5日→数時間に短縮、クラスメソッドではAWSコスト分析をワンコマンド化。テスト自動化・リリース準備・コードレビューなど、開発現場の「いつもの作業」を再現性高く任せやすくなる
  
  

• Pro/Maxなら追加料金なしで始めやすい
  Pro / Maxのサブスクリプション認証では、Skills自体に個別の追加料金は不要。Team / Enterpriseは契約形態やextra usage設定によって課金条件が変わるため、settings.jsonやSKILL.mdによる制御とあわせて運用設計を固めると導入しやすい

導入判断で詰まる2つの論点

Skillsの導入を検討するときに迷いやすいのが、「何をスキル化するか」と「どこまでエージェントに任せるか」の2点です。

何をスキル化するかについては、「週に2回以上やっていて、毎回手順を思い出すところから始めている作業」が最有力候補です。テスト実行・リリースノート作成・コードレビューの初期チェックなど、手順が決まっていてミスが起きやすいタスクほどスキル化の投資対効果が高くなります。逆に、毎回異なる判断が必要な設計作業や、まだ手順が固まっていない探索的な開発はスキル化に向きません。

どこまで任せるかについては、段階的に権限を広げるのが安全です。まずはallowed-toolsをRead・Grep・Globに絞った「読み取り専用」のスキルから始め、結果が安定してきたらBashやEditを追加していく流れが実務では多く見られます。

開発チームの中で「毎回同じ説明を繰り返している」「新メンバーが入るたびに同じ手順書を渡している」という状況があるなら、それはスキル化すべきシグナルです。SKILL.mdに書き起こすことで、チーム全体の開発品質を属人化から切り離せます。

まずはバンドルスキル（/simplifyや/batch）を実際のプロジェクトで使ってみるところから始めてみてください。SKILL.mdの設計感覚をつかんだ上で、自チームの定型作業を1つスキル化するのが最も効率的な導入パスです。