検証環境： Claude Code v2.1.104（2026-04-12時点）
Claude Codeの標準エージェントは構成や挙動がよく変わるため、どのバージョンで観察したかによって、本記事の結論（標準サブエージェントが汎用である、等）が当てはまらない場合があります。読む前にclaude --versionでお手元のバージョンと照らし合わせてください。
先に結論だけ
Claude Code公式が提供するサブエージェントは、どのドメインにも当てはまる汎用のものです。しかしあなたのドメインで必要なことを言葉にできるのは、そのドメインで日々仕事をしているあなた自身です。公式の汎用サブエージェントではフォローされない領域が、あなたのドメインにはあります。
はじめに
Claude Code公式のサブエージェントは便利です。ExploreやPlanは、一般的なコード探索や設計検討ではうまく動きます。しかし自分の仕事のドメインで使ってみると、何か足りないと感じる瞬間があります。
- 欲しい観点が拾われない
- 出力の細かさが合わない
- 判断基準が自分の業務とずれている
これは公式サブエージェントがあらゆるドメインで広く使えるよう設計されているためです。本記事ではその「何か足りない」の正体を整理し、ドメイン特化サブエージェントを自作する価値を考えます。裏付けには、技術執筆ドメイン向けの自作サブエージェント「documentation-researcher」を事例として用います。
本記事は次の道筋で進みます。
- 標準サブエージェントが汎用にならざるを得ない理由を説明する
- ドメインに特化したサブエージェントを自作すべきか、判断の目安を示す
- 実装例として
documentation-researcherを紹介する
なお本記事で言う「ドメイン」は、業界やジャンルではなく、日々の作業工程レベルの業務知識を指します（DDDで言うサブドメインに近い粒度です）。たとえば「技術執筆」全体ではなく、その中の「引用の信頼性階層チェック」のような、当事者が日々繰り返している特定の作業を想定しています。
標準サブエージェントは汎用品
公式が提供するサブエージェント一覧と共通点
Claude Codeが標準で提供するサブエージェントは、Explore・Plan・general-purpose・statusline-setup・Claude Code Guideなどです（公式ドキュメント）。並べてみると、どれも特定のドメインに寄らない汎用的な用途です。
- Explore：コードベースの探索
- Plan：実装計画の立案
- general-purpose：汎用タスクの委譲
- statusline-setup：ステータスライン設定の補助
- Claude Code Guide：Claude Code自体の使い方案内
作業工程ごとの観点、たとえば以下のようなものは標準には含まれていません。
- 技術記事の引用の信頼性階層チェック
- PRレビューコメントの粒度そろえ
- Claude Codeスキル定義のフロントマター検証
なぜ公式はドメイン特化を提供しないのか
以下は筆者の考察です。ドメインの数は事実上無限です。公式がすべてのドメインをカバーするのは、コスト面で現実的ではありません。結果として、公式が提供できるのは「どのドメインでも一定の価値を出せるもの」に限られます。
つまり、ドメイン特化の空白を埋める役割は、利用者側に残されています。
要求を言葉にできるのは当事者だけ
何が足りないかを知るのは当事者
自分のドメインで何が足りないかを言葉にできるのは、そのドメインで日々働いている当事者です。公式は全ドメインを広く浅くしか把握できませんが、あなたは自分のドメインの失敗事例・慣習・信頼性基準を深く知っています。
- どの情報源は信用できて、どれは危ういか
- どの細かさで証拠が必要か
- どの種類のバイアスに陥りやすいか
これらはドメイン内部にいないと蓄積しにくい知識であり、その偏りこそがドメイン特化サブエージェントを役立つものにします。
同じ方向の実装が複数ある
「自分のドメインに必要なサブエージェントを自作する」という方向は、すでに複数の実装者がたどっています。技術執筆・調査ドメインに絞っても、以下のような独立した実装が存在します。
- Technical Verifier：技術コンテンツの検証に特化したサブエージェント
- fact-checker：事実確認用のサブエージェント
各実装の中身には立ち入りません。ここで示したいのは、「特定ドメインならではの要求が実際にあり、複数の実装者が、それぞれ独立に同じ方向へ行き着いている」という事実です。
ケーススタディ：技術執筆ドメインのdocumentation-researcher
記事内の事実関係が外部情報源と整合しているかを検証するのが、筆者が技術執筆のために作ったdocumentation-researcherの役割です。出力の一例を筆者の別記事から引用します。
denyルールは、Bashツールに渡されるコマンド文字列に対するパターンマッチで動作します。公式ドキュメントでも、このパターンマッチについて以下のように警告されています。
Bash permission patterns that try to constrain command arguments are fragile.
（Bashの権限パターンでコマンド引数を制約しようとするのは脆弱です）
事実関係と公式ドキュメントの該当段落が一対一で紐づいています。以下では、この形を支える設計判断を見ていきます。
エージェント構成の概要
執筆・調査・検証の3エージェントは、以下のように役割を分担します。
技術執筆ドメインの固有要求
技術記事を書くドメインには、汎用調査エージェントでは満たせない特有の要求があります。
- 信頼性階層に従う：公式ドキュメントとブログ記事を同列に扱うと、裏付けが弱くなります。Tier 1（公式ドキュメント・ソースコード）からTier 4（匿名ユーザーの書き込み）までの階層を区別して使い分けます。
- 段落ごとに証拠を結びつける：長文をエージェントに与えると、エージェントは文書全体の論調から「根拠として成立している」と判断しがちです。このバイアスを避けるため、事実関係と一対一で対応する段落を要求します。
- 確証バイアスを構造的に入りにくくする：調査と検証を同一セッションで行うと、調査中に積み上げたコンテキストがバイアスとして働き、自分の結論に都合のよい証拠ばかりを集めたり、証拠を捏造したりします。調査と検証をそれぞれ独立させ、コンテキストを切り離すことでこのバイアスを抑えます。
これらは技術記事という特定ジャンルに固有の要求です。
設計判断：工程分離と多値出力
documentation-researcherは上記3要求のうち、とくに「確証バイアスの排除」に応えるため、2つの設計判断を取り入れています。
1段目は、検証工程の独立サブエージェント化です。調査と検証を同じサブエージェント内で連続させると、自分で集めた証拠を自分で評価することになり、確証バイアスが入りやすくなります。そこで検証工程を別サブエージェント（evidence-verifier）に分け、検証者が元の調査の経緯を見ずに評価する形にしました。2段に分けることで、バイアスを完全には消せなくても、入りにくい構造にしています。
2段目は、3値出力（verified / contradicted / unverifiable）です。2値（真・偽）ではなく3値を採るのは、「根拠が見つからない（unverifiable）」と「根拠と矛盾する（contradicted）」を区別するためです。
両者は記事執筆の判断がまったく異なります。
- 根拠が見つからない：その事実関係を書かない／限定詞をつける
- 根拠と矛盾する：記事を書き換える必要がある
2値にまとめてしまうと、この判断ができなくなります。
トレードオフ：コストと採算
3段階に分けると、追加のトークンと時間がかかります。すべての調査に使うのは過剰です。
- 根拠の信頼性が記事の中心になる場合：かけるコスト以上の価値があります
- 日常の探索・仮説出し：重すぎます
使い分けの線は「信頼性が記事の中心かどうか」で引きます。ここに明確な数値基準はありません。この線引き自体もドメイン当事者の仕事です。
あなたのドメインはあなたが一番強い
公式がドメイン特化を提供しないのは、価値がないからではなく、ドメインの数に限りがないからです。
あなたのドメイン知識は、汎用ツールの提供者より、あなた自身のほうが深く持っています。固有の要求を言語化できれば、コンパクトなサブエージェント定義で、公式の汎用サブエージェントではフォローされない価値を自分で作れます。
まずは日々の仕事のなかで、汎用サブエージェントを使っていて「何が足りない」と感じる点をメモするところから始めてみてください。そのメモが、あなた専用サブエージェントの起点になります。