a close up of a computer screen with code on it Photo by Patrick Martin on Unsplash

Claude Code の Skills・Subagents・Agent Teams をどう使い分けるか — 実体験ベースの整理

「Claude Code に Skills と Subagents と Agent Teams があるのは知ってるけど、結局どれをいつ使えばいいの?」

この疑問、最近めちゃくちゃ聞かれる。 そして正直に告白すると、僕も2026年に入ってからしばらくは混乱していた。 SubAgents、Skills、Agent Teams、ハーネスエンジニアリング…言葉だけが先行して、頭の中で整理できていない時期があった。

この記事では、Claude Code を日常的に使っている立場から、3つの機能の 役割の違い使い分け を整理する。 公式ドキュメントの定義をベースにしつつ、「僕がどう使い分けているか」という実体験を織り込んで書いていく。

ちなみに、僕のスタンスは2026年に入ってから完全に変わった。 昔は「コードを自分で書いてからAIに見てもらう」だったのが、今は 「まず Claude Code にやらせてみよう」 が口癖になっている。 だからこそ、Skills や Subagents の使い分けは死活問題だ。

まず全体像 — 3つの機能は「何を任せるか」が違う

最初に結論から言う。 3つの機能はそれぞれ別の問題を解決するためにある。

  • Skills: Claude に「やり方の手順書」を渡す機能。SKILL.md という1ファイルで定義する
  • Subagents: Claude に「専門の助手」を持たせる機能。独立したコンテキストで動く
  • Agent Teams: 複数の Claude Code セッションが「チームとして並行で動く」機能

ざっくり言うと、Skills は 参考書、Subagents は 専門家、Agent Teams は チーム編成 だ。 よく似ているけど、解こうとしている問題が違う。

ここまで掴めたら、それぞれを1つずつ掘り下げていく。

Skills — 「やり方を教える」プロンプトのテンプレート集

Skills は2025年12月に Anthropic がオープンスタンダードとして公開した仕組みだ。 Claude Code 公式ドキュメントの Skills ページ によると、Skills は SKILL.md ファイルを置くだけで Claude に新しい能力を追加できる。

SKILL.md の中身

Skills の本体は、シンプルな Markdown ファイル1枚だ。 YAML フロントマターで「いつ使うか」を定義し、本文で「何をするか」を書く。

---
name: explain-code
description: コードを図解と例えで説明する。コードの仕組みを聞かれたとき、コードベースを教えるとき、「これってどう動くの?」と聞かれたときに使う
---
 
コードを説明するときは必ず以下を含める:
1. **例えから始める**: 日常生活のものに例える
2. **図を描く**: ASCII art でフロー・構造・関係を示す
3. **コードを順を追って説明する**
4. **落とし穴を1つ指摘する**: よくある誤解は何か

これだけで /explain-code という slash command が使えるようになる。 あるいは「このコードどう動く?」と聞いたときに Claude が自動で発動する。

Skills が置ける場所

公式ドキュメントによれば、Skills は4つの場所に置ける。

  • エンタープライズ: 組織全体に配布
  • 個人: ~/.claude/skills/<skill-name>/SKILL.md — 全プロジェクト共通
  • プロジェクト: .claude/skills/<skill-name>/SKILL.md — そのリポジトリ専用
  • プラグイン: <plugin>/skills/<skill-name>/SKILL.md

優先順位は エンタープライズ > 個人 > プロジェクト。 プラグインは namespace で衝突回避される。

僕の使い方 — Skills は「同じ作業の再現」に強い

僕が Skills を一番使うのは、繰り返し発生する作業の手順を固定化したいとき だ。

たとえば僕がよく使うのは /commit という Skills で、git diff を見て規約に沿ったコミットメッセージを作って commit までやってくれる。 毎回「ステージされてる差分を見て、Conventional Commits 形式で、英語で、本文は要点だけ…」と指示を書くのは無理がある。 SKILL.md にその手順を1回書いておけば、/commit を叩くだけで同じ品質のコミットが再現できる。

Skills の強みは「軽くて速い」こと。 ファイル1枚で済むので、書き捨てでも、本格運用でも、同じ書き方で済む。

Subagents — 「専門の助手」を持たせる

次が Subagents(サブエージェント)だ。 2025年7月にリリースされた機能で、Claude Code の中で 特定タスク専用のミニ Claude を動かせる仕組み。

Claude Code 公式ドキュメントの Subagents ページ によると、Subagents は以下のような特徴を持つ。

  • 各サブエージェントが 独自のコンテキストウィンドウ を持つ
  • 独自のシステムプロンプト・ツール権限 を設定できる
  • メインの会話とは切り離された環境で動く
  • 結果だけがメイン会話に返ってくる

Skills との一番大きな違い

Skills は「メインの Claude に手順書を渡す」仕組み。 Subagents は「別の Claude を呼んで、その結果を受け取る」仕組み。

文法上の違いは小さく見えるけど、運用上の違いは大きい。

| | Skills | Subagents | |---|---|---| | 動く場所 | メインの会話の中 | 独立したコンテキスト | | コンテキスト消費 | メイン会話を圧迫する | メイン会話を圧迫しない | | ツール権限 | メインと共有 | 個別に制限可能 | | 主な用途 | 「やり方」を教える | 「仕事」を任せる |

僕の使い方 — Subagents は「探索と調査」に強い

僕が Subagents を一番ありがたく感じるのは、コードベースの探索と調査 をやってもらうときだ。

たとえば、よく知らないリポジトリで「この API エンドポイントが呼ばれている場所を全部洗い出して」と頼むとする。 これをメインの Claude にやらせると、Read や Grep の結果でメイン会話のコンテキストがあっという間に膨れ上がる。

そこで Explore 系の Subagent に丸投げする。 Subagent が独自のコンテキストの中で grep を回し、ファイルを読み、整理して、結果のサマリだけ をメイン会話に返してくれる。 僕の手元には「結論」だけが残るので、そのまま実装フェーズに集中できる。

これが「コンテキストを節約する」という Subagent の本質的な価値だ。

Skills と Subagents は組み合わせられる

もう1つ重要なのは、Skills と Subagents は対立する概念ではなく 組み合わせて使える という点だ。

公式ドキュメントによれば、SKILL.md に context: forkagent を指定すると、その Skill を Subagent の中で実行できる。

---
name: deep-research
description: トピックを徹底的にリサーチする
context: fork
agent: Explore
---
 
$ARGUMENTS について徹底的に調査:
1. Glob と Grep で関連ファイルを探す
2. コードを読んで分析する
3. ファイル参照を含めて結果をサマライズ

これで「Skills という手順書」を「Subagent という別空間」で実行できる。 2つの機能は競合するんじゃなくて、レイヤーが違うものなんだと理解できると、迷いが減る。

Agent Teams — 「複数の Claude を編成して動かす」

3つ目が Agent Teams だ。 ここがいちばん新しい話で、2026年初頭に登場した概念。

公式の Subagents ドキュメントには、こう書かれている。

If you need multiple agents working in parallel and communicating with each other, see agent teams instead. Subagents work within a single session; agent teams coordinate across separate sessions. (複数のエージェントが並行して動き、互いに通信する必要があるなら Agent Teams を見てほしい。Subagents は1つのセッション内で動くが、Agent Teams は別々のセッション間で連携する)

つまり、Subagents の上位互換ではない。 Subagents は1セッション内のサブプロセス、Agent Teams は セッションをまたいだチーム連携 だ。

Subagents との違いを1行で

| | Subagents | Agent Teams | |---|---|---| | 単位 | 1つの Claude Code セッションの中 | 複数の Claude Code セッション | | 通信 | 親→子(結果が返る) | 横方向(チームメイト同士) | | 適した用途 | 1つの仕事を専門化 | 並行プロジェクトの分業 |

僕の使い方 — まだ模索中

正直に書くと、Agent Teams については僕もまだ実験中だ。 1人開発の延長線で使う場面は多くない。

たとえば「フロントエンドの修正」と「バックエンドの修正」を同時並行で進めたいときに、別セッションのチームメイトとして動かす、みたいな使い方が想定されている。

ただ、ハーネスエンジニアリングという言葉が出てきたあたりから、エージェント側の進化スピードが速すぎて、ベストプラクティスが固まる前に次の概念が出てくる感覚がある。 「変化についていくのがやっと」というのが正直なところ。

ここは批判的な意見にも触れておくと、Agent Teams は便利な反面、コーディネーションコストが高い という指摘もある。 セッション間の同期、メッセージの取りこぼし、ファイル競合。 1人で扱える複雑度を超えると一気に管理コストが跳ね上がるので、僕は 「Subagents で足りるなら Subagents で済ませる」 を基本方針にしている。

使い分けの判断フロー

ここまで読んで「で、結局どう選べばいいの?」となるはず。 僕の頭の中の判断フローを書き出してみる。

  • 同じ作業を再現したい → Skills(SKILL.md を1枚書く)
  • メイン会話のコンテキストを汚したくない → Subagents(fork する)
  • 複数セッションで分業したい → Agent Teams
  • Skills の中で別コンテキストを使いたい → Skills + context: fork + Subagent

一番ハマりやすいのは、「全部 Subagent でやろうとする」 パターン。 Subagent は強力だけど、毎回呼ぶとオーバーヘッドが大きい。 「同じ手順を再現したいだけ」なら Skills で十分。

逆に、「Skills だけでなんとかしようとする」 のもしんどい。 コードベース全体の調査みたいな重い作業を Skills でメイン会話に押し込むと、コンテキストがすぐに尽きる。

このバランスを取るのが、今のところエンジニアの腕の見せどころだと感じている。

課題 — 急ぎすぎる進化と「ハーネスエンジニアリング」

ここまで便利な機能群を紹介してきたけど、現実には課題もある。

最大の課題は 進化が速すぎる ことだ。 2025年に Subagents、12月に Skills、2026年に入って Agent Teams…と、半年ごとに新しい概念が登場している。 昨日まで「Subagent でやれ」と言われていたものが、今日は「Skill で十分」になり、明日は「Agent Team が良い」と言われるかもしれない。

実際、エンジニア界隈では「ハーネスエンジニアリング」という新しい言葉も生まれている。 コーディングエージェント単体の話ではなく、エージェント全体の制御と設計 を扱う領域だ。 変化のスピードに、僕自身もついていくのがやっとという感覚がある。

それでも、僕はこの3つの機能を使うのをやめない。 ツールの使い方が変わると、仕事の考え方そのものが変わる。 「まず Claude にやらせてみよう」という思考の転換は、僕にとっては不可逆だった。

課題を理解した上で、自分の作業に合った使い分けを少しずつ調整していく。 それが現時点でのベストプラクティスだと思う。

まとめ

Claude Code の Skills・Subagents・Agent Teams の整理を振り返る。

  • Skills は「やり方を教える」テンプレート。SKILL.md を1枚書くだけで /skill-name が使える
  • Subagents は「独立した助手」。.claude/agents/ にエージェントを定義し、独自のコンテキストとツール権限で動かせる
  • Agent Teams は「複数セッションのチーム連携」。並行プロジェクトや分業に向いている
  • 3つは競合せず、組み合わせて使える(Skills + context: fork + Subagent など)

具体的なアクションを3つ挙げておく。

  • まず Skills を1つ作ってみる: ~/.claude/skills/my-first-skill/SKILL.md に description と本文を書くだけで slash command が動く → Skills 公式ドキュメント
  • 重い調査は Subagent に丸投げする: Explore 系の subagent を呼んで、結果のサマリだけ受け取る運用を試す → Subagents 公式ドキュメント
  • 判断フローを自分用に書き出す: 「再現したい→Skills、コンテキスト守りたい→Subagent、分業したい→Agent Teams」を付箋やメモに書いて手元に置く

進化が速い分野だからこそ、定義の整理が効いてくる。 明日また新しい機能が出ても、「Skills の系譜なのか、Subagent の系譜なのか、Agent Team の系譜なのか」を最初に問えば、迷子にならずに済む。

参考リンク