「AIと長くやり取りしていると、だんだん話がかみ合わなくなる」。Claude Code に限らず、AIを仕事で使っている人なら覚えがあるかもしれません。
原因のひとつは、会話にたまっていく情報そのものです。Claude Code のサブエージェントは、そこを分けて片づけるための仕組み。結論から言うと、見るところは3つです。何を分けるのか、どう作るのか、そして分けないほうがいい場面。3つ目は、この記事の旧版が逆のことを書いていたところでもあります。
※この記事は2026年9月時点の情報です。仕様や画面は変わることがあります。
※2026年9月追記（この記事の書き直しについて）
この記事は2025年8月18日に公開したものです。当時の本文には、筆者がサブエージェントを入れて「開発フローが一変した」と書いた体験の節と、「第三者の口コミ・評判」という見出しが入っていました。どちらも実際の出来事や、実在する人の発言ではありません。記事と関係のない講座やレンタルサーバーの宣伝も入っていました。ぜんぶ削除して、Anthropic の公式ドキュメントと技術ブログを読み直した内容に差し替えました。
なお、この記事は公式の記載をもとにまとめたものです。編集部の使用感は入れていません。
コンテキストエンジニアリングって、要するに何？
Anthropic は2025年9月29日の技術ブログで、この言葉を取り上げています。AIにとってコンテキスト（会話や資料として渡している情報のまとまり）は限りのある資源だ、という考え方です。
同じブログは「context rot」という現象も紹介しています。コンテキストの量が増えるほど、その中の情報を正確に思い出す力が下がる。下がり方に差はあっても、どのモデルにも出る性質だと書かれています。
だから大事なのは、たくさん渡すことではありません。ブログの言い方を借りると、望む結果につながりやすい中身の濃い情報を、できるだけ少なくそろえること。会議と同じですね。資料を全部机に積むより、今日決めることに要る3枚だけ渡したほうが話は早いです。
サブエージェントは「別室で調べて、要点だけ持ち帰る係」
公式ドキュメントの説明では、サブエージェントは特定の仕事を受け持つ専用のAIアシスタントです。それぞれが自分専用のコンテキストウィンドウで動き、専用の指示、使える道具、権限を持ちます。
ポイントは、戻ってくるものです。途中で出た検索結果やログ、二度と見ないファイルの中身は、サブエージェントの側に置いたまま。メインの会話には要点だけが返ってきます。Anthropic のブログには、サブエージェントを使う構成の一般論として、1つのサブエージェントが数万トークン以上を使って調べることがあっても、返すのは1,000〜2,000トークン程度の要約であることが多い、とあります。
社内にたとえるなら、「この件、過去の資料を全部見て、結論を3行で教えて」と若手に頼むのに近い。調べた紙の山は、若手の机に置いたままでいいわけです。
向いている仕事
公式ドキュメントが「最も効果的な用途の1つ」として挙げているのは、出力が大量に出る作業の切り離しです。例として、テストの実行、ドキュメントの取得、ログファイルの処理が並んでいます。
- テストを全部走らせて、失敗したものとエラーだけ報告させる
- 互いに関係しない調べものを、何本か同時に進めさせる
- 使える道具や権限を絞って、読むだけの係にする
作り方は「Claude に頼む」だけ
サブエージェントの正体は、設定を書いた Markdown ファイルです。冒頭に名前と説明を書き（必須はこの2つだけ）、必要なら使える道具や使うモデルも書きます。その下に指示を書きます。
置き場所は2つ。そのプロジェクトだけで使うなら .claude/agents/、自分のPCのどのプロジェクトでも使うなら ~/.claude/agents/ です。
ここは旧版の時点から変わった点があります。v2.1.198 以降、/agents コマンドは作成用の対話画面を開かなくなりました。いまはClaude に「こういうサブエージェントを作って」と頼むか、ファイルを自分で書くのが公式の案内です。ファイルの形式や置き場所は変わっていません。
公式の例を短くして日本語にすると、頼み方はこんな形です。
~/.claude/agents/ に、ファイルを読んで読みやすさや性能の改善点を提案する code-improver というサブエージェントを作って。読むだけにして。
できたら「code-improver を使って、このプロジェクトの改善点を出して」のように名前を出して頼めば、そのサブエージェントに仕事が回ります。
分けないほうがいい場面
旧版はここを逆に書いていました。「仕様の調査、実装、テストを別々の係に分ければうまくいく」という流れです。
ところが公式ドキュメントは、計画、実装、テストのように、いくつもの段階が大事な前提を共有する仕事はメインの会話で、と書いています。ほかにメインの会話が向いているのは、次のような場合です。
- 何度もやり取りしながら直していく仕事
- すぐ終わる、的をしぼった変更
- 待ち時間を短くしたいとき（会話を引き継がずに新しく始まるサブエージェントは、前提を集め直すぶん時間がかかることがある）
費用の話も書いておきます。英語版の公式ドキュメントには、サブエージェントも自分でリクエストを送り、メインの会話と同じ利用上限にカウントされるとあります。何本も同時に走らせれば、そのぶん上限に早く近づくわけです。「分ければ得」とは限りません。
線引きは単純でいいと思います。途中経過を自分が見なくていい仕事だけ、別室に出す。途中経過こそ見たい仕事は、手元に置く。
まとめ
- AIにとって情報は限りある資源。量が増えると、中の情報を正確に思い出す力が下がる
- サブエージェントは専用のコンテキストで作業し、要点だけを返す
- 向いているのは、テスト実行やログ処理のように出力が大量に出る作業
- 作るときは Claude に頼むか、ファイルを自分で書く（v2.1.198 以降、/agents の対話画面はない）
- 計画・実装・テストのように前提を共有する仕事は、メインの会話でやる
- サブエージェントの利用も、メインと同じ上限にカウントされる
いまの使い方で困っていないなら、無理に作る必要はありません。「調べものの途中経過で会話が埋まってしまう」と感じたときに、まず1つだけ試してみてください。
