サブエージェントビルダー

サブエージェントのきっかけ・ツール・モデルを決め、そのままファイルとして持ち出します。

エージェントのプロンプトにはチームのレビューや開発の流儀が書かれます。ファイルはブラウザー内で作られ、送信されません。

実行できる範囲を絞る

サブエージェントビルダー について

サブエージェントは、独自の手順・独自のツール・多くは独自のモデルを持つ別の文脈です。読んだ内容が本体の会話に流れ込まないからこそ役に立ちます。その分離が割に合うかどうかを決める項目は二つ。説明文は仕事の委譲を起こすもので、ほかに定義したすべてのエージェントと競合します。曖昧なものは一度も発動しないか、際限なく発動します。ツール一覧は、狭いエージェントを狭いまま保つ最も安価な手段です。読むことと探すことしかできないエージェントは、勝手に編集を始めません。このビルダーはファイルを書き出し、その両方を点検します。多くの人が見落とす組み合わせ——読めないのに書ける——も含めてです。

機能

• 委譲を起こす句が説明文にあるかを確認
• ツールは記憶から入力するのではなく実際の一覧から選択
• 名前空間付きの MCP ツールも組み込みツールと同様に受け付け
• ファイルを書けるのに読めない場合に警告
• モデル選択を「どんなときに割に合うか」で説明
• プロジェクト用か個人用かと、それぞれのパス
• 継承のままなら model 項目は書き出しません
• そのまま使える .md ファイルとして保存

サブエージェントビルダー の使い方

1. エージェントに名前を付け、いつ仕事を任せるかを書きます
2. 必要なツールだけを選びます
3. モデルを選ぶか、セッションのものを継承させます
4. システムプロンプトを書き、ファイルを保存します

例

入力

tools: [Read, Grep, Glob]

出力

description: Checks a database migration for problems that only show up in production. Use proactively whenever a migration file is added.

「〜のときは自発的に使う」が、頼まれずとも動くエージェントを作ります。

よくあるエラーとトラブルシューティング

• エージェントに何も委譲されない。 — 説明文は「何を」だけでなく「いつ」を書く必要があります。「〜のときに使う」「〜のあと自発的に使う」を足すだけでたいてい直ります。
• 二つのエージェントが混同され続ける。 — 説明文が重なっています。それぞれが別の主題ではなく、別の状況を名指しするようにしてください。
• ツール名が不明として指摘される。 — ツール名は大文字小文字を区別し、先頭は大文字です。read ではなく Read。MCP ツールは mcp__サーバー__ツール の形で、そのまま受け付けられます。
• 想定外のものをエージェントが編集する。 — ツール一覧をもっと狭くしてください。Write も Edit も持たないエージェントは、プロンプトが何と言おうと何も変えられません。

よくある質問

その場でやるより、サブエージェントが向くのはどんなときですか。

大量に読んで少しだけ出す作業——コードベースの探索、多数のファイルの確認、調べもの——です。読んだものはすべてサブエージェント側の文脈に留まります。本体より狭いツールで走らせたいときにも使えます。

サブエージェントにはどのモデルが良いですか。

継承は良い既定値です。判断より確認が中心の機械的な処理には速くて安いモデルが、判断が要る仕事にはより高性能なモデルが向きます。得失は選択肢の横に書いてあります。

ツールは常に絞るべきですか。

絞るのは安上がりで、いつでも戻せます。プロンプトで頼むよりはるかに確実に、目的の狭いエージェントを狭いまま保てます。空のままなら全部を継承し、汎用のエージェントにはそれで十分です。

プロジェクト用と個人用のどちらにしますか。

プロジェクト用ならリポジトリと一緒に管理され、全員が同じものを使えます。個人用はプロジェクトをまたいで付いてきます。パスは選択に応じて更新されます。

スキルとはどう違いますか。

スキルは今の文脈に手順を足します。サブエージェントは別の場所で、自前の文脈と自前のツールで動き、結果を返します。やり方を変えたいならスキル、その作業を自分の会話から追い出したいならサブエージェントです。

関連ツール

• スキルビルダー — SKILL.md を作成し、frontmatter を入力しながら検証します。
• スラッシュコマンドビルダー — 引数とツール許可リストを備えた独自コマンドを作ります。
• 権限ルールテスター — 許可・確認・拒否のルールを実際のコマンドで試します。
• フックビルダー — settings.json のフックを作り、発火しないマッチャーを見つけます。
• プロジェクト指示ビルダー — 毎リクエストの費用に見合う CLAUDE.md を書きます。
• スキルリンター — SKILL.md を貼り付け、タスクに一致しない理由を確かめます。

AI・エージェントの他のツール

• スキルビルダー — SKILL.md を作成し、frontmatter を入力しながら検証します。
• スキルリンター — SKILL.md を貼り付け、タスクに一致しない理由を確かめます。
• スラッシュコマンドビルダー — 引数とツール許可リストを備えた独自コマンドを作ります。
• プロジェクト指示ビルダー — 毎リクエストの費用に見合う CLAUDE.md を書きます。
• プラグインマニフェスト — plugin.json を生成し、前提となるフォルダ構成を確認します。
• フックビルダー — settings.json のフックを作り、発火しないマッチャーを見つけます。
• 権限ルールテスター — 許可・確認・拒否のルールを実際のコマンドで試します。
• MCP サーバー設定 — stdio、HTTP、SSE 向けの MCP サーバー設定を生成します。
• MCP ツールスキーマ — ツールを定義し、strict モードを検証した JSON Schema を得ます。
• ツールスキーマ検証 — 定義を貼り付け、拒否される理由や誤呼び出しの原因を調べます。
• プロンプトテンプレート展開 — 一つのプロンプトを行の表に展開し、欠けている値を確認します。
• システムプロンプトリンター — 矛盾、効かない指示、未置換のプレースホルダーを見つけます。
• プロンプト差分 — 二つの版を単語単位で比較し、トークン差も表示します。
• Few-shot 例ビルダー — 入出力の組をタグ付き、JSON、会話形式の例に変換します。
• XML プロンプト構成 — 内容が外に漏れないタグでプロンプトの各節を囲みます。
• JSONL ビューア・検証 — JSONL ファイルを行単位で読み、絞り込み、検証します。
• 会話ログ変換 — メッセージ配列を読みやすい記録に変換し、元にも戻します。
• 学習データ検証 — 学習を途中で止めるエラーがないか chat 形式の JSONL を調べます。
• SSE ストリームビューア — 生のストリーミング応答から本文、ツール呼び出し、使用量を取り出します。
• コンテキストウィンドウ設計 — ウィンドウをプロンプト、ツール、履歴、応答に配分します。
• プロンプトキャッシュ設計 — キャッシュできる接頭辞が最長になるようブロックを並べ替えます。
• テキスト分割 — 実際の切れ目で分かれる重なり付きのチャンクに文書を分けます。
• エージェントループ費用 — 再送される履歴とキャッシュを含めてターンごとに費用を見積もります。
• バッチリクエストビルダー — 行の表をバッチ処理に変換し、各リクエストに一意の ID を付けます。

AI・エージェントのツールをすべて見る · すべてのツール