Claude CodeでOpusとSonnetを使い分ける — 60+スキルで実践したルーティング設計

60以上のスキルを破綻させない5つの設計原則

Claude CodeにはAgent Skills（エージェントスキル）という仕組みがあります。YAMLフロントマター付きのMarkdownファイルを1つ書くだけで、AIの振る舞いを定義できる機能です。最初の数個は直感で作れます。「コードレビュー用」「コミット用」「実装用」——用途ごとにスキルを分ければいい、それだけの話です。

しかし10個、30個、60個と増えるにつれて、設計判断が積み重なっていきます。「このスキルはOpus（高性能モデル）とSonnet（高速モデル）のどちらで動かすべきか？」「レビュー系スキルにBash実行を許可すべきか？」「スキル同士をどう連携させるか？」——こうした問いに、毎回その場で判断していては一貫性が保てません。

私は現在、65個のClaude Codeスキルを運用しています。この記事では、その過程で見えてきた5つの設計原則を共有します。

1. モデル選択は「判断」vs「実行」で分ける — Opusは設計判断、Sonnetは実装実行
2. allowed-toolsで安全境界を作る — ツール制限でスキルの責務を定義する
3. パイプラインは明示的に繋ぐ — スキル連携を暗黙にしない
4. ルーティングテーブルで迷わせない — 意図→スキルの対応表を用意する
5. コンテキストサイズは用途で決める — デフォルトは標準、必要なときだけ1M

Zenn上にはClaude Codeスキルの設計に関する記事がいくつか存在します。本記事の特徴は、5原則という再利用可能なフレームワークと、各原則に至るまでの失敗→改善のストーリーにあります。「こうしている」だけでなく「こうしていなかったときに何が起きたか」を含めて記録します。

スキルが増えると起きる問題

「とりあえずOpus」がコストを膨らませる

モデル選択を直感に頼ると、Opusの過剰使用でコストとレイテンシが膨らみます。

スキルを作るとき、最初に悩むのがモデル選択です。Claude Codeでは、スキルごとに使用するモデルを指定できます。

判断に迷ったとき、「とりあえずOpus（高性能モデル）にしておこう」という選択をしがちです。高性能なほうが安全だろう、という考えです。しかし実際に運用してみると、Opusが本当に必要な場面は全体の20〜30%程度でした。残りの70〜80%はSonnetで十分な品質が出ます。OpusはSonnetの約5倍のトークン単価であり、レイテンシも2〜3倍かかります。「とりあえずOpus」は、コストとレイテンシの両方を無駄に増やしていたのです。

責務の重複がツール制限の甘さを生む

スキル間の責務が曖昧だと、ツール制限が甘くなり、スキルがスコープ外の作業をしてしまいます。

もう1つの問題は、スキル間の責務が曖昧になることです。たとえばcode-review（コードレビュー）とarch-review（アーキテクチャレビュー）の境界はどこでしょうか。どちらも「コードを見て問題を指摘する」という点では同じです。

さらに厄介なのが、レビュー系スキルにツール制限をかけていない場合の事故です。レビューを依頼したはずなのに、AIがコードを直接修正してしまう。レビューの目的は「問題を指摘すること」であって「勝手に直すこと」ではありません。

パイプラインが暗黙だと手順が属人化する

スキルの使用順序が明示されていないと、手順の飛ばしやスキル間のデータ断絶が発生します。

スキルが増えると「どの順番で使えばいいか」が分からなくなります。新機能を実装するとき、ブランチを切ってからコードを書いて、品質チェックをして、PRを出す——この手順は頭の中にあっても、スキルの連携として明示されていなければ毎回迷いが生じます。

スキル名を覚えきれない

スキルが65個を超えると、名前と用途の対応を人間が記憶するのは現実的ではなくなります。

65個ものスキルがあると、名前を覚えるのが現実的ではなくなります。「レビューのスキルって/reviewだっけ？/code-reviewだっけ？」という迷いが頻繁に起きるようになりました。

こうした問題を解決するために、私は5つの設計原則を定めました。以下で1つずつ解説します。

原則1: モデル選択は「判断」vs「実行」で分ける

Opusは「Should we?」、Sonnetは「How to?」

モデル選択の基準はシンプルです。「Should we?（すべきか？）」と問う場面ではOpus、「How to?（どうやるか？）」と問う場面ではSonnetを使います。

具体的には次のような分け方です。

Opusを使う場面（判断・設計）:

• アーキテクチャ設計（/plan）
• コードレビュー（/code-review）
• 品質ゲート判定（/gate）
• 大きなIssueの分解（/agent-split）
• PRのレビューとマージ判定（/agent-lead）

Sonnetを使う場面（実行・実装）:

• コード実装（/engineer）
• バグの切り分けと修正（/debugger）
• コミット（/commit）
• PR作成（/create-pr）
• ブラウザ操作（/chrome、/agent-browser）

この基準の背景にある考え方は、「判断ミスのコストが高い場面だけOpusを使う」です。設計判断を間違えると、その後の実装がすべてやり直しになります。一方、コミットメッセージの生成やブランチの作成は、間違えてもすぐ修正できます。コストの非対称性を基準にモデルを選ぶのです。

この原則に至るまでの失敗

原則1を定める前、/debuggerをOpusで動かしていた時期がありました。「バグの原因特定には高い推論能力が必要だろう」という直感からです。

実際には、バグの切り分け作業の大半は「ログを読む」「変数を出力する」「条件を絞り込む」といった実行寄りのタスクでした。Opusの推論能力が活きる場面はごく一部で、大半の時間はSonnetで十分な作業にOpusのコストとレイテンシを払っていたことになります。

/debuggerをSonnetに切り替えた結果、体感の応答速度は明らかに向上しました。品質面での劣化はほぼ感じません。ただし、バグの原因が設計上の問題に起因する場合——たとえば「そもそもこのモジュール分割が間違っている」という判断が必要なケース——では、Sonnetが見当違いの修正を提案することがありました。

この経験からエスカレーションルールが生まれました。

5カテゴリ65スキルの分類マップ

私のスキルは以下のカテゴリに分類されています（Private・未分類含む）。

カテゴリ	スキル数	主要モデル	代表的なスキル
設計・判断系	12	Opus	plan, code-review, arch-review, design
実行・実装系	10	Sonnet	engineer, debugger, chrome
コンテンツ系	6	Sonnet	seo, aieo, imagen-prompt
チーム	1	Opus	team
ワークフロー	19	混在	kickoff, ship, gate, issue-work
Private	13	混在	（非公開）
その他（未分類）	4	—	quick-impl, split-issue 等

設計・判断系はすべてOpusです。これらのスキルは「何をすべきか」「この設計は正しいか」を判断する役割を持ちます。実行・実装系はすべてSonnetです。「指示された内容を正確に実行する」ことが求められるため、高速なSonnetが適しています。

ワークフロー系は混在しています。/gate（品質ゲート）のように判断を含むものはOpus、/kickoff（ブランチ作成）のように実行に特化したものはSonnetです。

エスカレーションルール — Sonnetが判断に迷ったらOpusへ

モデル選択は静的なものだけでは不十分です。Sonnetスキルの実行中に、想定外の設計判断が必要になることがあります。たとえば/engineerでコード実装中に「このモジュールの責務分割をどうするか」という問いに直面するケースです。

この場合のルールを明文化しています。「Sonnetスキル実行中に設計判断・アーキテクチャ選択が必要と感じたら、/planへの切り替えを提案する」。AIに判断を委ねるのではなく、適切なモデルに切り替える仕組みを持つことが重要です。

実運用での体感としては、エスカレーションが発生するのは月に数回程度です。不要なエスカレーションも含まれますが、設計判断をSonnetに無理にさせて後から手戻りするよりは、多少の誤検知があってもOpusに切り替えるほうがトータルのコストは低いと感じています。

原則2: allowed-toolsで安全境界を作る

ツール制限の4パターン

Claude Codeのスキルでは、allowed-tools（許可ツール）というフロントマターで、スキルが使えるツールを制限できます。

Claude Codeのallowed-toolsには2つの重要な挙動があります。まず、allowed-toolsを省略した場合、ツールが使えなくなるわけではなく、全ツールが承認ベースで使用可能になります。次に、allowed-toolsを明示的に指定した場合、そのツールは承認なしで使用可能になります。つまり利便性のためにガードレール（承認ダイアログ）を外す行為でもあるため、必要最小限のツールだけを指定する必要があります。

この仕組みを理解した上で、私は4つのパターンに整理しています。

パターン1: レビュー系（プロンプトによる行動制御）

---
name: code-review
model: claude-opus-4-6[1m]
# allowed-tools 省略 = 全ツール使用可能（承認ベース）
# プロンプトで「分析・指摘のみ行い、コードを変更しない」と指示
---

レビュー系スキルでは、allowed-toolsによる制限ではなくプロンプトで行動を制御します。「コードの読み取りと分析だけに専念し、ファイルを変更しないこと」と明記することで、レビューに専念させます。

ただしプロンプトによる行動制御はソフトな制約です。コンテキストが長くなると遵守率が下がることがあります。レビュー系でallowed-toolsを使わない理由は、レビュー中にBashでテスト実行やビルド確認が必要になる場面があるためです。この利便性とリスクのトレードオフを理解した上で選択しています。

パターン2: 実装系（全ツール許可）

---
name: engineer
model: claude-sonnet-4-6[1m]
# allowed-tools 省略 = 全ツール使用可能（通常の承認フロー）
---

実装系スキルにはすべてのツールを許可します。コードの読み書き、Bash実行、ファイル検索——実装に必要なすべての操作を制限なく実行できます。

パターン3: ワークフロー系（Bash + Read）

---
name: commit
model: claude-sonnet-4-6
allowed-tools: Bash, Read, Glob, Grep
# Edit/Write がないのでコード変更不可
---

ワークフロー系スキルにはBashとRead系ツールのみを許可します。git操作やファイル読み取りはできますが、コードの直接変更はできません。

パターン4: コンテンツ系（Read + Write）

---
name: note-draft
model: claude-sonnet-4-6
allowed-tools: Read, Write
# Bash がないので環境アクセス不可
---

コンテンツ系スキルにはReadとWriteのみを許可します。記事生成スキルがシステムコマンドを実行する必要はないからです。

この原則に至るまでの失敗

allowed-toolsの設計が固まる前、/commitスキルにEdit/Writeを含む全ツールを許可していた時期がありました。すると/commitがコミット前に「ついでに」コードのフォーマットを修正したり、typoを直したりする現象が発生しました。

コミットスキルの責務は「変更をコミットすること」であって「コードを修正すること」ではありません。しかし全ツールが使えるスキルは、善意でスコープ外の作業をしてしまいます。Edit/Writeを外してBash + Read系のみにした結果、この問題は完全に解消しました。

もう1つの事例は、コンテンツ系スキルでBashを許可していたケースです。記事執筆スキルがBash経由でcurlコマンドを実行し、外部APIからデータを取得しようとした事故がありました。記事生成に外部通信は不要です。Bashを外してRead + Writeのみにしたことで、スキルの行動範囲が明確になりました。

こうした経験を通じて、「スキルに与えるツールは、そのスキルの責務の輪郭を定義する」という認識に至りました。

プロンプト制御 vs ツール制限の使い分け

スキルの責務制御には2つのアプローチがあります。プロンプトによる行動制御（レビュー系のように「何をすべきか」を指示で制御）と、allowed-toolsによるツール制限（ワークフロー系のように使えるツール自体を絞る）です。

制御方式	強度	柔軟性	適するスキル
プロンプト制御	ソフト（遵守率に依存）	高い（状況に応じた判断が可能）	レビュー系、実装系
ツール制限	ハード（物理的に使用不可）	低い（例外を許容できない）	ワークフロー系、コンテンツ系

どちらも「このスキルは何をする責任があり、何をしてはいけないか」を明示する設計ツールです。ハードに制限できるならツール制限、柔軟性が必要ならプロンプト制御。迷ったらツール制限を優先するほうが安全です。

原則3: パイプラインは明示的に繋ぐ

12のワークフローチェーン

スキルは単体で使うだけでなく、複数のスキルを連携させる「パイプライン」として使うと真価を発揮します。ただし、この連携を暗黙的にしてはいけません。

私は12のワークフローチェーン（スキル連携パターン）を明示的に定義しています。代表的なものを紹介します。

新機能開発パイプライン:

/kickoff → /engineer → /gate → /ship

ブランチ作成 → コード実装 → 品質チェック → コミット&PR作成。新機能を追加する際の標準フローです。

バグ修正パイプライン:

/debugger → /engineer → /gate → /ship

バグの切り分け → 修正実装 → 品質チェック → コミット&PR作成。デバッグと修正を分離しています。

設計からの実装パイプライン:

/plan → /kickoff → /engineer → /code-review → /ship

設計検討 → ブランチ作成 → 実装 → レビュー → コミット&PR作成。リスクの高い変更に使います。

@claude自律パイプライン:

/agent-split → /agent-impl → /agent-lead

Issue分解 → 自動実装 → PRレビュー&マージ判定。人間の介入を最小化した自律フローです。

Issue駆動（単発自動）:

/issue-work

1つのスキルで解析から実装、検証、PR作成まで完結します。パイプラインを1スキルに凝縮したパターンです。

これらのチェーンを定義する意義は「次に何をすべきか」を明確にすることです。各スキルの完了時に「次のステップはこれです」と提案できるようになります。

この原則に至るまでの失敗

パイプラインを明示化する前は、スキルの使用順序が完全に暗黙知でした。自分の頭の中には「実装→品質チェック→コミット」という流れがあっても、それがどこにも書かれていない。すると2つの問題が起きました。

1つ目は手順の飛ばしです。急いでいるときに/gate（品質チェック）を飛ばして直接/shipしてしまい、テストが壊れたままPRを出したことがあります。パイプラインが明示されていれば「gateを通過していない」と気づけます。

2つ目はスキル間のデータ受け渡しの断絶です。/planで設計した内容が/engineerに伝わらず、設計と実装が乖離するケースがありました。パイプラインを明示化してからは、各スキルの出力が次のスキルの入力になることを意識した設計ができるようになりました。

パイプライン設計の実践Tips

パイプラインを運用する中で見えてきた知見を3つ紹介します。

途中からの再開: パイプラインは必ずしも先頭から実行する必要はありません。たとえば実装済みのコードに対して/gate → /shipだけを実行することもあります。各スキルが独立して動作可能であることが、パイプラインの柔軟性を支えています。

No-Goからの復帰: /gateでNo-Go判定が出た場合、/engineerに戻って修正し、再度/gateを実行します。このループは手動で回しています。自動リトライにしなかった理由は、No-Goの原因が設計レベルの問題である場合に/planへのエスカレーションが必要になるためです。

パイプラインの凝縮: /issue-workのように、複数ステップを1スキルに凝縮するパターンも有効です。ただしこれは「パイプラインが十分に安定してから」行うべきで、最初から凝縮すると個別ステップのデバッグが困難になります。

gate — 並列オーケストレーションの実装

パイプラインの中でも特に面白い設計が/gate（品質ゲート）スキルです。このスキルは「スキルがスキルを呼ぶ」パターンを実装しています。

/gateはOpusで動作し、以下の5つのサブチェックを並列に起動します。

1. コード品質チェック
2. TypeScript静的解析
3. 重複コード検出
4. 設計原則の遵守確認
5. シークレット（API キーやパスワード）の検出

各サブチェックの結果を統合し、Go（コミット可）またはNo-Go（修正必要）を判定します。このパターンのポイントは、オーケストレーター（指揮者）としてのスキルをOpusで動かし、個々のチェッカーは軽量なSonnetで動かすことです。判断の統合はOpus、個別の検査はSonnet——原則1の「判断vs実行」がここでも適用されています。

実装としては、/gateのSKILL.md内でサブエージェントの起動指示を記述しています。各チェッカーはサブエージェントとして並列実行され、結果が/gateに戻ってきます。

原則4: ルーティングテーブルで迷わせない

33行のインテント→スキル対応表

65個のスキルがあると、「どのスキルを使えばいいか」という問題が生まれます。スキルの名前と用途をすべて覚えるのは現実的ではありません。

この問題を解決するのがルーティングテーブル（意図→スキル対応表）です。私はCLAUDE.md（Claude Codeの設定ファイル）に33行の対応表を定義しています。

| ユーザーの意図 | 推奨スキル | 備考 |
|--------------|-----------|------|
| 機能を実装したい | /engineer | iOSの場合は /ios-engineer |
| バグを直したい | /debugger | 切り分け後の修正は /engineer へ |
| コードをレビューしてほしい | /code-review | アーキテクチャ観点は /arch-review |
| 設計を相談したい | /plan | リスクの高い変更は必須 |
| コミットしたい | /commit | PRまで一括なら /ship |
| 品質チェックしたい | /gate | セキュリティは /secret-scan |
| 次に着手するIssueを選びたい | /issue-next | Issue整理は /issue-triage |

この対応表があることで、ユーザーはスキル名を知らなくても、自然言語で意図を伝えるだけで適切なスキルが提案されます。「機能を実装したい」と言えば/engineerが、「コードをレビューしてほしい」と言えば/code-reviewが候補として挙がります。

CLAUDE.mdに書くべきメタ情報

ルーティングテーブルをスキルファイル内ではなくCLAUDE.mdに書くのには理由があります。CLAUDE.mdはClaude Codeが常に読み込む設定ファイルです。スキルファイルはそのスキルが呼び出されたときだけ読み込まれます。

CLAUDE.mdに書くべき情報は3つです。

• ルーティングテーブル: どのスキルをいつ使うか
• ワークフローチェーン: スキルの連携パターン
• エスカレーションルール: モデル切り替えの条件

これらはすべて「スキル横断的な情報」です。個々のスキルの中に書いても、そのスキルが呼び出されないと参照されません。常に参照可能なCLAUDE.mdに置くことで、スキル選択の段階から適切な判断ができるようになります。

スキル本体には「そのスキルが何をするか」だけを書きます。「いつ使うか」「他のスキルとどう連携するか」はCLAUDE.mdの責務です。この責務分離が、スキルの数が増えても管理を破綻させないコツです。

なお、この手法にもスケーラビリティの限界はあります。ルーティングテーブルが33行でも既にそれなりの長さであり、CLAUDE.mdに書くメタ情報が増えるほどセッション開始時のトークン消費も増加します。100スキルを超える規模になった場合は、プロジェクト別CLAUDE.mdへの分離や、ルーティングテーブルの階層化を検討する必要があるでしょう。

原則5: コンテキストサイズは用途で決める

標準 vs 1Mコンテキストの使い分け

Claude Codeでは、スキルごとにコンテキストウィンドウ（AIが一度に読み込める情報量）のサイズを選択できます。標準コンテキストと1M（100万トークン）の2択です。

結論から言えば、ほとんどのスキルは標準で十分です。1Mコンテキストが必要なのは、コードベース全体を俯瞰する必要がある限定的な場面のみです。

標準コンテキストで十分なスキル:

• /ask（質問応答）
• /commit（コミット）
• /kickoff（ブランチ作成）
• /create-pr（PR作成）
• /imagen-prompt（画像生成プロンプト作成）

これらのスキルは、局所的な情報だけで処理が完結します。コミットメッセージの生成にコードベース全体の知識は不要です。

1Mコンテキストが必要なスキル:

• /plan（アーキテクチャ設計）
• /code-review（包括的レビュー）
• /engineer（大規模実装）
• /issue-work（Issue全体の解析→実装→検証）
• /agent-split（大きなIssueの分解）

これらのスキルは、コードベースの複数箇所を横断的に参照する必要があります。

この原則に至るまでの失敗

初期の頃、すべてのスキルを1Mコンテキストで動かしていた時期がありました。「大は小を兼ねる」という発想です。

しかし、3つの問題が表面化しました。

• レイテンシの増加: 1Mコンテキストのスキルは、標準コンテキストと比較して初回応答が明らかに遅くなります。/commitのような「すぐ終わってほしい」スキルで数秒余計に待たされるのは、体感として大きなストレスでした。
• コンパクション（圧縮）の頻発: 1Mコンテキストでも、長時間のセッションではコンテキストが埋まります。コンパクションが発生すると会話の前半部分が要約されてしまい、スキルのプロンプトで指示した行動制約の遵守率が下がります。特にレビュー系スキルで「コードを変更しない」という指示がコンパクション後に無視されるケースを経験しました。
• コスト増: コンテキストサイズが大きいほどAPI利用料が増加します。65スキルすべてを1Mにすると、月額のコスト差は無視できない水準になりました。

これらの経験から、「デフォルトは標準、必要なときだけ1M」という原則に切り替えました。

コンテキストサイズの判断基準

判断基準を整理すると以下のようになります。

判断ポイント	標準コンテキスト	1Mコンテキスト
参照するファイル数	1〜3ファイル	5ファイル以上
タスクの性質	局所的な操作	横断的な分析・設計
セッションの長さ	短い（1-2ターン）	長い（多ターンの対話）
速度の重要性	高い（即座に完了してほしい）	低い（品質優先）

迷ったら標準から始めて、コンテキスト不足で品質が下がったときに1Mへ切り替えるのが安全です。モデル選択と同様、「デフォルトは軽量、必要なときだけリッチに」という原則がここでも適用されます。

コンパクション対策

コンテキストサイズの設計と密接に関わるのがコンパクション（コンテキスト圧縮）への対策です。

長いセッションでコンテキストが上限に近づくと、Claude Codeは自動的にコンパクションを実行します。このとき、会話の前半が要約されるため、スキルのプロンプトに書いた制約や指示が失われるリスクがあります。

対策として有効だったのは以下の2点です。

重要な制約はプロンプトの冒頭に書く。コンパクション時に要約される優先度は、会話の中盤＞冒頭です。スキルの行動制約（「コードを変更しない」など）はプロンプトの最初に配置することで、コンパクション後も保持されやすくなります。

1タスク1セッションを心がける。コンテキストが膨らむ前にタスクを完了し、次のタスクは新しいセッションで開始する。これはコンテキストサイズの選択よりも効果的なコンパクション対策でした。

付録: SKILL.mdの実例

ここまでの5原則がどう反映されるか、実際のスキルファイルを1つ掲載します。/commitスキルのSKILL.md（サニタイズ済み）です。

---
name: commit
model: claude-sonnet-4-6
allowed-tools: Bash, Read, Glob, Grep
description: "変更をコミット。差分を分析し、リポジトリのスタイルに合わせたコミットメッセージを自動生成する。"
---

# /commit — コミットスキル

## 役割

ステージングされた変更（または未ステージの変更）を分析し、
リポジトリのコミット履歴のスタイルに合わせたコミットメッセージを
自動生成してコミットする。

## 手順

1. `git status` で変更状態を確認
2. `git diff --staged` でステージング済みの差分を確認
   - ステージングがなければ `git diff` で未ステージの差分を確認
3. `git log --oneline -10` で直近のコミットメッセージのスタイルを把握
4. 差分の内容を分析し、コミットメッセージを生成
5. ユーザーに確認を求めてからコミットを実行

## コミットメッセージのルール

- 1行目: 変更の要約（50文字以内推奨）
- 空行
- 本文: 変更の「なぜ」を説明（必要な場合のみ）
- リポジトリの既存スタイル（prefix、言語）に合わせる

## 制約

- **コードの変更は行わない**。コミット対象の差分に問題を見つけても、
  指摘のみ行いコードは修正しない
- フォーマット修正、typo修正などの「ついで作業」は禁止
- .env、credentials.json 等の機密ファイルが含まれていたら警告する

このスキルに5原則がどう反映されているか確認します。

• 原則1（モデル選択）: Sonnetを指定。コミットは「How to?」の実行タスク
• 原則2（allowed-tools）: Bash, Read, Glob, Grepのみ。Edit/Writeがないのでコード変更が物理的に不可能
• 原則3（パイプライン）: 新機能開発チェーンの/gateの次に位置する。前段の品質チェックを通過したコードをコミットする役割
• 原則4（ルーティング）: CLAUDE.mdのルーティングテーブルに「コミットしたい → /commit」と記載
• 原則5（コンテキスト）: 標準コンテキスト。差分とログだけで処理が完結するため1Mは不要

まとめ: まず3つから始めよう

65個のスキルを運用してきた経験から、5つの設計原則をまとめました。

1. モデル選択は「判断」vs「実行」で分ける — Opusは「すべきか？」、Sonnetは「どうやるか？」
2. allowed-toolsで安全境界を作る — ツール制限はスキルの責務定義そのもの
3. パイプラインは明示的に繋ぐ — 「次に何をすべきか」を定義する
4. ルーティングテーブルで迷わせない — 意図→スキルの対応表をCLAUDE.mdに置く
5. コンテキストサイズは用途で決める — デフォルトは標準、必要なときだけ1M

なお、本記事ではClaude Codeのスキルに焦点を絞りました。Claude Codeにはスキルとは別にサブエージェント（agents/）という仕組みもあります。判断基準を簡潔に述べると、スキルは「メイン会話内でコンテキストを共有して実行」、サブエージェントは「分離されたコンテキストで独立実行」です。定型的な読み取り専用タスク（レビュー等）を繰り返す場合にサブエージェントが適しています。詳細は別の機会に紹介します。

ただし、65個のスキルを最初から作る必要はありません。私自身も最初は/engineer（実装）、/commit（コミット）、/code-review（レビュー）の3つから始めました。必要を感じたときに、この5原則に沿って少しずつ追加していけば、スキルの数が増えても一貫した体系を維持できます。

Claude Code Agent Skillsの公式ドキュメントも合わせて参照してください。スキルのフロントマター仕様や設定方法の詳細が記載されています。