SkillをそのままSubagentに使わせると、2つの指示が衝突しませんか？
衝突しない。両者は異なる層で機能しているからだ。Skillは「この種のタスクはどんな手順に従うべきか」を定義するものであり、その定義自体は中立的で特定の実行環境に縛られていない。Subagentが提供するのは「実行の空間と権限の範囲」だ。あるSubagentがあるSkillを使う時、それはその独立したインスタンスが自身のコンテキストの中でその手順指示を適用しているにすぎない——同じレシピを異なるキッチンで作れるようなもので、キッチンが変わったからといってレシピ自体が矛盾するわけではない。
本当に注意すべきは別のことだ。Subagentは自身のツール権限範囲を持っており、Skillに記述された手順がSubagentに許可されていないツールを必要とする場合、その手順は行き詰まる。これは「2つの指示が衝突している」のではなく、権限範囲が噛み合っていないということだ。設計時にはSubagentのツール権限がSkillが実際に使う操作をカバーしているか確認する必要がある。
なぜAnthropicは「どうやるかを知る」と「誰がやるか」を2つの独立した仕組みに分けたのですか？全部Subagentに統合すればよかったのでは？
手順の知識を各Subagentに直接書き込んでしまうと、大量の重複が生じる。複数の異なるSubagentが同じコードレビュー基準に従う必要がある場合、同じ内容を各Subagentの設定にコピー＆ペーストしなければならず、その基準が更新されるたびに複数箇所を同期して直す必要があり、どこか1つを直し忘れやすい。
知識を独立したSkillとして抽出することの利点は、それが「持ち運び可能」になることだ。基準を一度書けば、メインの会話でも、このSubagentでも、あのSubagentでも使え、更新時は1箇所だけ変更すればよい。これはソフトウェア工学における「同じことを繰り返すな」という原則と同じ論理である。Anthropic公式ドキュメントもこの役割分担を「Skillは持ち運び可能な専門知識を提供し、Subagentは独立した実行空間を提供する」と明確に説明しており、これは意図的に直交する2つの仕組みとして設計されたものであり、重ねただけの機能ではない。
固定の手順があるのに、Skillにまとめる必要もSubagentを使う必要もないのはどんな場合ですか？
これが人生でせいぜい1、2回しか行わないことであったり、手順は原則固定だが毎回の詳細のばらつきが大きすぎて汎用的な手順に抽象化しにくい場合は、1つの明確なプロンプトで直接伝える方がかえって効率的かもしれない。Skillにまとめる価値は「今後繰り返し使う」ことにある。繰り返し使う見込みがないなら、Skill.mdを書きdescriptionの発動条件を設計する初期投資が、節約できる時間を上回るかもしれない。
同様に、そのタスクが生む中間プロセスが少なく、メインの会話に表示されても構わないなら、Subagentを使うのはやりすぎだ。独立したインスタンスを起動すること自体に一定の調整コストがあり、隔離が不要なほどシンプルなタスクなら、メインの会話で直接処理する方が単純だ。判断基準はシンプルだ。まず「これは繰り返すか」を問い、次に「これの実行は隔離が必要か」を問う。どちらも当てはまらないなら、最もシンプルな方法がたいてい最良の方法である。
完全な初心者ですが、先にSkillを学ぶべきですか、それとも先にSubagentを学ぶべきですか？
まずSkillから始めることをお勧めする。Skillのメンタルモデルはよりシンプルだ——繰り返しClaudeに伝えている手順を書き留めるだけで、「独立したインスタンス」「コンテキストの隔離」といった追加の理解を必要とする概念は関わってこない。学習のハードルがはるかに低く、日常の繰り返し作業（決まった形式のレポート、決まった手順のデータ整理）のほとんどはSkillだけで解決でき、必ずしもSubagentを使う必要はない。
Subagentの価値は、実際に「作業量が多すぎてメインの会話がパンクする」または「複数の独立したタスクを同時並行で処理する必要がある」という状況に直面して初めて実感できるものだ。学ぶために学ぶのではなく、まずSkillに慣れておき、ある日、特定のタスクが生むノイズでメインの会話が長く乱雑になってきたと気づいたら、それが自然にSubagentを理解すべきタイミングであり、最初から両方を同時に学ぼうとするべきではない。
Skillが何かはすでに理解しているはずだ——決まった手順が書かれたSKILL.mdで、状況が一致すれば自動的に適用される。しばらく使っていると、初心者は次の疑問にぶつかることが多い。複雑な複数ステップの作業をClaudeにさせたく、その過程で現在の会話を汚したくない場合、SkillとSubagentのどちらを使うべきか？答えはどちらか一方ではなく、両者がそもそも異なる問題を解決するものだと理解することであり、成熟した使い方の多くは実際に両者を組み合わせている。
Skillは持ち運び可能な知識であり、「このタスクはどんな手順や基準に従うべきか」を定義する。Skill自体には独立した実行環境がなく、それを呼び出した相手のコンテキストの中で動作する——メインの会話が呼び出せばメインの会話のコンテキストで、Subagentが呼び出せばそのSubagent自身のコンテキストで動く。これが公式がSkillを「持ち運び可能な専門知識」と表現する理由でもある。同じコードレビュー基準を、メインの会話でも、どのSubagentでも使うことができ、実行環境ごとに別々に書く必要がない。
Subagentは独立したClaudeインスタンスで、自身のコンテキストウィンドウとツール権限を持つ。これはSkillとは全く異なる問題を解決する。大量の中間プロセス（数十のファイルを調べたり、大量の検索コマンドを実行したりする）を生む作業だが最終的な結論だけが重要な場合、その作業をSubagentに任せれば、そのノイズはSubagent自身のコンテキストにとどまり、メインの会話のスペースを消費しない。これは複数の独立したタスクを並行処理する必要がある時に特に効果的だ——例えば4つの異なるモジュールのセキュリティを同時に監査する場合、4つのSubagentがそれぞれ同じ「セキュリティ監査」Skillを携えて分担して進め、互いのコンテキストを汚さない。
公式ドキュメントはこの役割分担を明確に述べている。Skillは「何をすべきか」を定義し、Subagentは「誰が、どの隔離範囲内で行うか」を定義する——両者は競合する選択肢ではなく、補完し合う関係にある。よくある組み合わせパターンは、コードレビューを行うSubagentに「特定のプログラミング言語のベストプラクティス」Skillを携えさせてレビューを実行させることだ。これによりSubagentの独立性（メインの会話を汚さない）とSkillの持ち運び可能な専門知識（同じ基準を他のSubagentやメインの会話で繰り返し使える）の両方を同時に得られる。
あなたの問いが「これはどんな固定の手順や基準に従うべきか」であれば、答えは通常Skillだ。あなたの問いが「これを実行すると見たくない大量の中間ノイズが発生するか、メインの会話から隔離する必要があるか」であれば、答えは通常Subagentだ。両方の問いが当てはまる場合——固定の基準があり、かつ隔離実行が必要な場合——答えは両方を一緒に使うことだ。基準をSkillとして書き、実行時にSubagentがそのSkillを携えて動かす。
隔離すべき作業をメインの会話に残しておくと、大量の中間プロセスでメインのコンテキストが埋め尽くされ、以降のすべてのターンがこの不要なノイズを引きずり続けることになる——実質的で継続的なトークンの無駄だ。逆に、独立した実行環境を必要としない単純なタスクを無理にSubagentにまとめてしまうと、独立したインスタンスを起動する余分なオーバーヘッドを払うことになる。本当に節約になるのは、そのタスクに「固定の基準があるか」と「隔離が必要か」を先に考えてからSkill、Subagent、あるいは両方を使うか決めることであり、複雑そうなタスクに出会うたびに反射的にSubagentへ丸投げしたり、毎回Skillを書けば済むと考えたりすることではない。