Skillsとサブエージェントで作業を分ける

このレッスンで学ぶこと

自動化を追加する前に、作業をなぜ繰り返すのか、どの情報を常に共有する必要があるのか、何を独立して調べられるのかを考えます。公式ドキュメントでは、CLAUDE.md はプロジェクト全体で常に参照する前提やルール、Skillは必要なときに使う手順、サブエージェントは独立したコンテキストと制限されたツールで行う専門タスクとして説明されています。

仕組みを増やすほど、読み込むコンテキスト、動作のばらつき、検証対象、利用コストも増えます。まずは手動で安定している小さな手順を対象にします。

1. 適切な仕組みを選ぶ

必要なこと	候補	設計上の確認
全セッションで共有する短い前提	`CLAUDE.md` / `AGENTS.md`	事実、規約、検証コマンドなど常に必要な情報か
繰り返す手順を必要時に使う	Skill	入力、手順、期待する出力、停止条件を明記できるか
独立した調査を別コンテキストで実行する	サブエージェント	読み取り専用など必要最小限のツールで完了するか
明示的なイベントで決定的な処理を実行する	Hook	処理が小さく、失敗時の挙動とログを把握できるか
外部ツールやデータへ接続する	MCP	サーバー、権限、ネットワーク、データ送信先を信頼できるか

似た仕組みを重ねる前に、既存のプロジェクト指示や組み込み機能で足りないか確認します。

2. Skillの仕様を先に書く

まだSkillファイルを作らず、以下を決めます。

目的： 何を繰り返し解決するか
入力： どの情報が与えられるか
手順： どの順番で調べ、実行するか
出力： どの形式で結果をまとめるか
制約： 変更・コマンド・外部アクセスの許可範囲
停止条件： 情報不足、権限不足、危険な操作でいつ止めるか
評価例： 成功する例、失敗を報告すべき例

手順が短くない場合でも、最初から複雑な自動実行を設定するのではなく、まず通常の依頼として複数回使い、抜けや例外を見つけます。

3. サブエージェントを最小範囲にする

サブエージェントは、メインの会話から分離した調査やレビューに向いています。例えば「変更せずに、関連するテストファイルと対象条件を一覧にして返す」のような作業です。複数エージェントに同じファイルを書かせたり、権限を無制限にしたりする必要はありません。

設計時には、タスク、利用可能なツール、アクセス可能な範囲、返却形式、失敗時の報告方法を明記します。分離されたコンテキストは情報共有の制約にもなります。必要なファイルや前提を与え、レポートの根拠を確認してください。

演習：ワークフローを設計する

チームで繰り返す「プルリクエスト前の確認」を例にします。まず現在の手順とレビュー指摘を集めて、常時必要なプロジェクトルール、任意で使うチェックリスト、独立して実行できる読み取り専用の調査を分類します。

Skill案を作る場合は、まだファイルを作らず、目的・入力・手順・出力・制約・停止条件・評価例を一枚にまとめます。サブエージェント案は、最初は変更権限を与えない調査タスクにします。

完了条件

どの機能を使うか、なぜそれが最小の仕組みか説明できる
入力・出力・権限・停止条件を定義した
失敗例を少なくとも一つ考えた
手動手順で検証する方法を決めた
実際のファイルや設定を変更する場合は、共有範囲を確認してから許可した

参考資料

公式ドキュメントの参照先を2026年10月18日に確認しました。機能、設定項目、利用条件は変更される場合があるため、実装前に現在の公式仕様を確認してください。

次に読む

HooksとMCPを安全に設計するで、自動実行と外部接続に伴うリスクを整理します。