本記事のサマリ
先日のClaude Code Meetup Tokyoにオンライン参加してきました！正直、Claude初心者の私にとっては「へぇ〜」の連続だったんですが、特に目からウロコだったのが「Subagentを積極的に使おう」と「/clearでタスク粒度を管理しよう」という話。この2つ、知ってるのと知らないのとで、開発効率が全然違うんですよね。せっかくなので、この記事で自分なりに整理してみようと思います！
はじめに：あのイベントで聞いた衝撃の話
Claude Code Meetup Tokyo、行ってきました。正直、AIコーディングツールなんて「補完が賢くなったやつでしょ？」くらいの認識だった私ですが、このイベントでその考えが完全にひっくり返りました。
発表者の方々が口を揃えて言っていたのが、「Subagentを使わないともったいない」「/clearコマンドを使ってタスクを区切ろう」という話。最初は「ふーん」程度だったんですが、家に帰ってから試してみたら、これがもう、衝撃的に便利で。
今まで私、Claude Codeで何か作るときって、ずっと同じ会話の中であれもこれもお願いしてました。そしたら途中から「あれ？なんか話が通じなくなってきたぞ？」ってなることが多くて。それって要は、コンテキストがごちゃごちゃになってたんですね。イベントでその理由を聞いて、ようやく腑に落ちました。
Subagentとは：独立したコンテキストを持つ専門AIエージェント
早速このSubagentなんですが、公式ドキュメントを見てみましょう。
簡単に言うと、Subagentって「特定の仕事に特化したClaude」を別に立ち上げられる機能なんです。それぞれが独立した記憶領域（コンテキストウィンドウ）を持ってるのがポイント。
これまでって、ずっと同じClaude（メインエージェント）とやり取りしてたじゃないですか。調査して、設計して、実装して、テストして、デバッグして...全部同じ会話の中で。そうすると、最初の方でやってた調査の細かい話とか、途中で読んだログとか、全部Claudeの記憶に残り続けちゃうんですよね。で、それが積もり積もって、「あれ？さっきと言ってること違くない？」みたいなことが起きる。
Subagentを使うと、これが解決できます。たとえば「バックエンドAPIの既存実装を調査する」専用のSubagentを立ち上げれば、そいつは調査だけに集中してくれる。調査が終わったら結果だけメインに報告して、細かい調査過程の記憶は全部そのSubagentと一緒に終了。すっきり！
Subagentを活用するメリット
Meetupでも強調されてたんですが、Subagentを使うメリットって大きく分けて3つあるんです。
記憶がパンクしなくなる
人間だって、あれもこれも覚えてると頭がパンクしますよね？Claudeも同じで、メインエージェントにあれこれ詰め込みすぎると、途中から「で、何の話だっけ？」状態になるんです。
Subagentを使えば、「このタスクに必要な情報だけ」を持った専用のClaude君が動いてくれるので、判断がブレにくくなります。人間で例えるなら、「とりあえず全部覚えといて」じゃなくて、「この件についてだけ調べておいて」ってお願いする感じですね。
本当の並列作業ができる
公式のベストプラクティスにも書いてあるんですが、Subagentって複数同時に動かせるんですよ。
たとえば、フロントエンドの実装を一つのSubagentに任せて、同時に別のSubagentでAPIの設計を進めて、さらに別のやつでDB周りを調査して...みたいなことができる。これ、一人で全部やろうとしたら絶対無理ですよね。
特化させることができる
これが個人的に一番面白いと思ったんですが、Subagentって「役割」を持たせられるんですね。コードレビュー専門、セキュリティチェック専門、パフォーマンス最適化専門...みたいな感じで。なので、色々な役割を持たされるよりも効率的に仕事をこなすことができます。
Subagentの具体的な使い方
さて、ここからが本題。Subagentの使い方です。
まずは /agentsコマンドを覚えよう
一番簡単なのは、/agentsコマンドを叩くこと。これでメニューが出てきて、今あるSubagentを確認したり、新しく作ったり、編集したりできます。直感的に使えるので、まずはこれを試してみるのがおすすめです。
自分だけのSubagentを作る
Subagentって、実はMarkdownファイルで作れるんです。保存場所は2箇所から選べます。
- プロジェクト専用にしたいなら →
.claude/agents/ - どのプロジェクトでも使いたいなら →
~/.claude/agents/
プロジェクト専用の方が優先されるので、「このプロジェクトだけ特別なルールがある」みたいな時に便利です。
ファイルの中身はこんな感じ↓
---
name: code-reviewer
description: Expert code reviewer. Use proactively after code changes.
tools: Read, Grep, Glob, Bash
model: sonnet
---
You are a senior code reviewer ensuring high standards of code quality and security.
When invoked:
1. Run git diff to see recent changes
2. Focus on modified files
3. Begin review immediately
Review checklist:
- Code is simple and readable
- Functions and variables are well-named
- No duplicated code
- Proper error handling
- No exposed secrets or API keys
Provide feedback organized by priority with specific examples.
ここで重要なのが toolsフィールド。これで「このSubagentに何をさせるか」を制限できるんです。コードレビュー専用なら、読み取りと検索だけできれば十分ですよね。編集権限まで渡す必要はない。こうやって権限を絞っておくと、意図しない変更を防げて安心です。
使い方は2パターン
Subagentの呼び出し方は2通りあります。
1. 明示的に指名する
「Use the code-reviewer subagent to review my recent changes」みたいに、はっきり名前を言って頼む方法。確実ですね。
2. 自動で選ばせる
Claudeが「あ、これコードレビューの話だな」って判断して、勝手に適切なSubagentを選んでくれるパターン。これが機能するには、descriptionを具体的に書いておくのがコツです。
/clearコマンドによるコンテキスト管理
Meetupでもう一つ強調されてたのが、この /clearコマンド。これ、知ってるのと知らないのとで全然違います。
コンテキストって、放っておくとパンパンになる
Claude Codeって、今までの会話、読んだファイル、実行したコマンドの結果...全部覚えてるんですよ。で、これが積もり積もると、「あれ？なんかちぐはぐなこと言い始めたぞ？」ってなる。容量にも限界があるし、処理も遅くなるし、トークンもバカ食いします。
公式も「こまめに使え」って言ってる
Anthropicの公式ベストプラクティスでも、「タスクの区切りで /clear 使おうね」って書いてあります。
理由は単純で、「前のタスクの細かい話、次のタスクには関係ないでしょ？」ってこと。ログイン機能を作った時の詳細なログとか、次にダッシュボード作る時には邪魔なだけですよね。
/clearと /compact、どう使い分ける？
似たようなコマンドで /compactってのもあるんですが、これは使い分けが必要です。
-
/clear→ 完全リセット。タスクが終わった時、全然違う作業に移る時に使う -
/compact→ 重要な情報は残しつつ、細かい履歴を圧縮。同じタスクを続けたいけど記憶を整理したい時に使う
私の場合、「この機能完成！」ってタイミングで /clear、作業中に「なんか重くなってきたな」って時に /compactって感じで使い分けてます。
実践的なワークフロー例
じゃあ実際、SubagentとClearを組み合わせてどう使うのか。私の場合はこんな感じです。
ステップ1：まず調査から入る
新しい機能を作る時、いきなりコード書き始めないで、まず調査用のSubagentを立ち上げます。
「Use a research subagent to investigate how authentication is currently implemented in this codebase」
こいつに既存のコードを読ませて、「今どうなってるか」を理解させる。調査が終わったら結果だけもらって、このSubagentはお疲れ様。
ステップ2：計画を練る
調査結果をもとに、メインセッションで「じゃあどう作る？」を考えます。この時、「think hard about the best approach for implementing OAuth2 integration」みたいに「think」って入れると、Claudeがじっくり考えてくれます。
計画ができたらMarkdownファイルかGitHub issueに書き出して、ここで一旦 /clear。実装に集中できる環境を作ります。
ステップ3：実装する
テストケースとか「こうなったらOK」ってゴールを先に決めてから、コードを書いていきます。必要なら、テスト専門とかセキュリティチェック専門のSubagentも使います。
一つの機能が完成したら、また /clear。次の機能に移る前にリセットすることで、前の機能の詳細が混ざらないようにします。
ステップ4：コミットして終わり
最後に動作確認して、GitのSubagentかレビューSubagentに、いい感じのコミットメッセージとPRを作ってもらって完成！
失敗から学ぶ：口頭指示だけでは機能しない
「Subagent使って」って言うだけじゃダメだった件
これ、めちゃくちゃ恥ずかしい話なんですけど、私も最初やらかしました。
Subagentって機能があるのを知って、「お、いいじゃん！」ってなった私は、Claudeにこう伝えたんです。
「この機能を実装して欲しい。まずPlanを立てて、そのPlanで出た機能をSubagentごとに作業分担して、その結果をmain agentがレビューだけするようにして」
...普通にチャットでね。
そしたらClaude君、「OK。今Subagentにお願いしたよ」って返してきて。「おー、やってくれるんだ！」って期待したんですが...
会話ログ見てると、どう見ても一人芝居。「Aさんの意見としては...」「Bさんの意見も踏まえると...」みたいな、完全に一人二役やってるだけでした。二人羽織かよ。
**正解は /agentsコマンドを使うこと。**これ使わないと、本当のSubagent機能は発動しません。口で言っただけじゃダメなんです。
この記事読んでる皆さんには、私と同じ回り道をして欲しくないので、声を大にして言います。必ず /agentsコマンドを使ってください！
この失敗、今思えば貴重な学びでした。AIって、正しいインターフェースで使わないと本来の力を発揮してくれないんですよね。
Subagent活用の実践パターン
パターン1：実装担当とレビュー担当を分ける
これ、めっちゃいいですよ。一つのSubagentにコード書かせて、別のSubagentでレビューさせる。ペアプロみたいな感じですね。
実装する方は「とにかく動くもの作る」に集中して、レビューする方は「セキュリティ大丈夫？保守しやすい？テストは？」って冷静にチェックする。それぞれ独立したコンテキストだから、実装側の思い込みに引っ張られないんですよね。
パターン2：Git Worktreeを使って本気の並列開発
複数の機能を同時に進めたい時、Git Worktreeが便利ですよね。
git worktree add ../project-feature-auth feature/oauth-integration
git worktree add ../project-feature-api feature/api-refactoring
# それぞれでClaude起動
cd ../project-feature-auth && claude
cd ../project-feature-api && claude
これで、認証機能とAPIリファクタリングを完全に別々に進められます。お互い邪魔し合わないので超快適。
パターン3：調査専門のやつを作っておく
大きいコードベースって、「このコード、なんでこうなってるんだ？」ってなりますよね。そういう時用に、調査専門のSubagentを作っておくと便利です。
こいつにプロジェクトの構造とか、使ってるパターンとか、既存のAPIとかを調べさせて、結果をドキュメントにまとめてもらう。新しい機能作る時は、この調査結果を見ながら「既存のコードの流儀」に合わせて実装できます。
チーム開発での活用方法
個人で使うのもいいんですが、チーム開発でも活用できます。
Subagentをチームで共有する
.claude/agents/ディレクトリをGitに入れちゃえば、チーム全員で同じSubagentが使えます。「うちのチームのコードレビュー基準はこれ！」とか「セキュリティチェックはこうやる！」みたいなのを、Subagentとして標準化しておけば、誰が書いても一定の品質を保てます。
カスタムコマンドも共有できる
.claude/commands/ディレクトリも同じで、プロジェクト固有のコマンドを作っておけます。デプロイの手順とか、テストの実行方法とか、繰り返しやる作業を標準化しておくと楽です。
仕様書ベースの開発と相性いい
先に仕様書をちゃんと書いて、それをもとにSubagentに実装させる流れが結構いいらしいです。EARS記法とか使って要件を明確にしておくと、さらに精度が上がるみたいですね。
まとめ：AIとの協業における新しいアプローチ
Claude Code Meetup Tokyoで聞いた「Subagentを使おう」「/clearでタスクを区切ろう」って話、最初は「ほほう」程度だったんですが、実際に使ってみたら全然違いました。
要は、「何を作るか」「なんで作るか」「どんな品質にするか」は人間が決めて、「じゃあどう実装するか」をSubagentとClaude Codeに任せる感じ。役割分担がはっきりしてる方が、お互いうまく回るんですよね。
コンテキスト管理って、地味だけどめちゃくちゃ大事です。適切なタイミングで /clearして、必要な時にSubagent使って...これやるだけで、Claudeとの付き合いが格段に良くなります。
私も、この使い方を知ってから開発がすごく楽しくなりました。「あー、こういう風にAIと協業すればいいのか」って腑に落ちました。
皆さんもぜひ試してみてください！絶対「もっと早く知りたかった...」ってなると思います。特に /agentsコマンド、ちゃんと使ってくださいね。口頭で指示するだけじゃダメですから！（実体験）笑
株式会社StellarCreate（stellar-create.co.jp）のエンジニアブログです。 プロダクト指向のフルスタックエンジニアを目指す方募集中です！ カジュアル面談で気軽に雑談しましょう！→ recruit.stellar-create.co.jp/
Discussion