2026年に入って、Claude Codeで開発を回している会社は急増しました。でも社内のエンジニアに聞くと、ほとんどが「素のClaude Codeをそのまま使っている」状態なんです。これがチャンスです。私が3週間ほど試して気づいた、サブエージェント設計を売る副業の作り方を、コード例つきで書いていきます。
読み終わる頃には、あなたが明日から「.claude/agents/ ディレクトリ一式を納品する個人事業主」として動き出せる解像度になっているはずです。
結論:Claude Codeのサブエージェント設計は2026年の隠れた高単価ニッチ
先に結論から。Claude Codeのサブエージェント(subagent)を顧客企業の開発フローに合わせて設計・納品する副業は、競合がまだ少なく、技術的な参入障壁が低いわりに単価が崩れにくい領域です。
理由は3つあります。
1つ目。サブエージェントは2025年後半から本格的に普及した機能で、まだ「設計の型」が市場に出回りきっていません。2つ目。納品物が .claude/agents/*.md という小さなテキストファイル群なので、検収が早く、リピート保守につながりやすい。3つ目。AIライティングやAI画像のような「誰でもできる」領域とは違って、Claude Codeを実務で使い込んだ人にしか書けない仕様書になります。
半信半疑だった私も、自分の本業リポジトリで4つのサブエージェントを組み込んだ瞬間、「これ、社内に1人もいない会社の方が多いな」と確信しました。
そもそもサブエージェントとは何か(30秒で復習)
Claude Code 2.1系で標準搭載されているサブエージェントは、メインセッションから呼び出される「専門特化のClaudeインスタンス」です。
.claude/agents/ 配下に置いたMarkdownファイルがその実体で、YAMLフロントマターでツール権限・使用モデル・呼び出しトリガーを宣言します。メインのClaudeが「これはコードレビュー案件だな」と判断すると、code-reviewerサブエージェントに作業を委譲し、結果のサマリだけ返してきます。
海外の技術ブログでもこの設計思想は繰り返し説明されていて、要点は「親セッションは細部の情報で汚染させず、専門タスクは別コンテキストの子インスタンスに丸投げする」というシンプルな分業です。Anthropic公式ドキュメントの記述に従えば、各サブエージェントは独立したコンテキストウィンドウ・独自のシステムプロンプト・ツール許可リストを持ちます。
ここまで聞いて「あ、これは社内のシニアエンジニアが片手間で書くと雑になるやつだ」と感じたら、あなたには商機があります。
なぜ2026年に「設計を売る副業」が成立するのか
中小〜中堅エンジニア組織が直面している3つの困りごと
私が直近で話を聞いた範囲(SaaS系の小規模開発チーム数社)に共通していたのは、こんな悩みでした。
- Claude Codeを導入したものの、各エンジニアが好き勝手にOpusを叩いていてトークン代が読めない
- レビュー観点が属人化していて、Claudeのレビュー結果も人によってブレる
- セキュリティ的に「Bashを誰に許可するか」のルールが曖昧で、CTOが怖がっている
このうち2つ目と3つ目は、まさにサブエージェント設計で解決する領域です。1つ目も、model: haiku をyamlに固定したサブエージェントを配るだけで一気に静まる。
海外のFinOps Foundationの2026年レポートでも、AI関連のクラウドコスト管理が98%の組織で課題になっていると報告されています。日本の中小企業でも、この「コスト見える化」のニーズは半年遅れで確実に来ます。
競合がまだ少ない理由
この領域、プロンプトエンジニアリングの副業勢から見ると「コードが絡むので踏み込みにくい」、受託開発の副業勢から見ると「コードを書く案件ではないので地味」というポジションにあります。
ちょうど両者のエアポケットなんですよね。だから、Claude Codeを毎日触っていて、かつクライアントの開発フローをヒアリングできる個人エンジニアにとっては、しばらく独占に近い状態が続きそうです。
納品物のサンプル:code-reviewerサブエージェントの最小構成
話を具体に落とします。私がテンプレとして使っている、納品用のcode-reviewerサブエージェントの骨格はこんな感じです。
---
name: code-reviewer
description: Pull Request相当の差分を厳格にレビューする。セキュリティとAPI後方互換性を重点的に。
tools:
- Read
- Grep
- Glob
model: claude-sonnet-4-5
---
あなたはシニアコードレビュアーです。以下の観点で差分をレビューしてください。
1. セキュリティ: SQLインジェクション、認証バイパス、秘匿情報のログ出力
2. API後方互換性: 既存エンドポイントのレスポンス形状の破壊変更
3. テスト網羅: 追加された分岐に対するテストの有無
4. パフォーマンス: N+1クエリ、不要な同期処理
出力フォーマットは必ず以下に従う:
- BLOCKER / WARN / NIT の3段階
- 該当ファイル名と行番号
- 修正提案のコード(可能なら)
Write/Edit/Bashツールは使用しない。読み取り専用で判定のみ行うこと。ポイントは tools を Read Grep Glob の3つに絞っていること。これでサブエージェントが勝手にコードを書き換える事故を防げます。クライアントのCTOが安心するのはここです。
このファイル1つだけでも価値はありますが、実際の納品ではこれを3〜5本セットで提供します。test-writer、migration-checker、release-notes-writerあたりが定番。
YAML設計で押さえる4つの勘所
- modelを必ず固定する: 指定しないとデフォルトの高価モデルが走り、月末に請求書を見て泣くケースが本当にあります。
- toolsは最小権限で: code-reviewerにEditは不要。release-notes-writerにBashは不要。
- descriptionは「いつ起動するか」を書く: ここがメインClaudeの委譲判断に使われます。
- 出力フォーマットを定義する: 後段のCI連携を見越して、BLOCKER/WARNのような機械処理可能なラベルを必ず入れる。
副業として受注するまでの流れ
私が組み立てている動線は、わりとシンプルです。
ステップ1:自分のGitHubに公開レポジトリで「.claude/agents」サンプルを置く
最大の営業ツールがこれ。技術系副業の発注者は、X(旧Twitter)のフォロワー数より「動くサンプルがあるGitHub」を信用します。
3〜5本のサブエージェントを、業界別(Webサービス向け / API開発向け / データ基盤向け)に切って公開しておく。READMEには「導入することで何が変わるか」を、実行ログのスクショつきで載せます。
ステップ2:ヒアリングシートを1枚で完結させる
初回ミーティングで聞くのは多くて10項目です。使用言語・フレームワーク、レビュー観点で優先したいもの、現状のClaude Code使用状況、コスト懸念、Bash許可範囲、CIとの接続有無、機密ファイルのパス、納期、予算感、月額保守の意向。
ここを1枚で済ませると、見積りスピードで他の副業勢に勝てます。
ステップ3:見積りは「初期設計+月額チューニング」の二段構え
相場感を捏造はできないので一般論として書きますが、初期設計はパッケージとして固定価格で出し、月額チューニングはサブエージェントの追加・修正本数で従量にするのが揉めにくい型です。納品物が .md ファイル数本という性質上、買い切りだけだと安く見られがち。月額保守をセットにすることで「設計者として継続関与する」体制を作れます。
3週間試して感じた、思わぬ落とし穴
良いことばかり書いても胡散臭いので、自分が踏んだ穴を3つ共有します。
1つ目は **「サブエージェント間でツール権限が衝突する」**問題。release-notes-writerにWrite権限を与えて、code-reviewerにはRead-onlyにしたら、両方を順番に呼ぶフローでメインClaudeが混乱しました。設計時に呼び出し順序とハンドオフを図にしておかないと事故ります。
2つ目は **「クライアントの社内Gitポリシーに .claude/ が含まれない」**問題。.gitignore の例外設定を最初に依頼しないと、せっかく納品したファイルがコミットされず誰も使わない、という間抜けなことになります。
3つ目は **「descriptionの書き方ひとつで委譲確率が変わる」**問題。これ、地味ですが効きます。「コードをレビューします」より「PR相当の差分を厳格にレビュー。セキュリティと後方互換性を重点的に」のほうが、メインClaudeが正確に判定してくれる体感がありました。
まとめ:今日からやる4つのアクション
ここまで読んだあなたが、今日この瞬間からできることを4つに絞ります。
- 自分の本業リポジトリに
.claude/agents/code-reviewer.mdを1本作って動かす。まずは自分で価値を実感する。 - GitHubに
claude-agents-starterのような公開リポジトリを作り、3本のサブエージェントをサンプル公開する。営業資料を兼ねる。 - ヒアリングシート10項目をNotionかGoogleドキュメントで作る。初回ミーティング用。
- クラウドソーシングではなく、知人経由のエンジニアコミュニティで1件目を取りに行く。この領域はまだ案件名がついていないので、検索流入より口コミの方が早い。
Claude Codeを毎日触っているあなたなら、最初のサブエージェントは今日中に書けます。年内には設計者として名前が知られる側に回れる可能性が、まだ残っているニッチです。
参考リンク
- Tembo.io - Claude Code Subagents: A 2026 Practical Guide — サブエージェントの設計思想と実装パターン
- ComputingForGeeks - Claude Code Subagents: The Complete Guide — frontmatterスキーマと委譲挙動の検証
- Digital Applied - Build a Claude Code Custom Subagent Step-by-Step — code-reviewerの実装例
- CloudZero - Claude Code Agents In 2026 — 2026年のAIコスト管理動向
- Nimbalyst - Claude Code Subagents: A Practical 2026 Guide — サブエージェントとparallel sessionsの使い分け