上位モデルだけが出せる「良い出力」の差は、モデル名そのものより、確認・検証・失敗時の直し方といった暗黙の作法にあることが多いです。
📑目次
Claude Code を日常利用する開発者にとって重要なのは、枠や実験機能の可用性が変わっても、その作法を Agent Skills と役割分割（サブエージェント／エージェントチーム）として残し、Opus や Sonnet 中心の運用へ移せることです。
本記事では、次の一次情報を根拠に整理します。
- Claude Code 公式の agent teams と costs
- Anthropic の Skills 発表
- 配布可能なチームパッケージ（ccteams / GitHub toffyui/ccteams）
扱う内容は次のとおりです。
- 比較表
- 有効化条件
- コスト制約
- 書き起こし手順
- チェックリスト
発見経路としての人気シグナルは文脈に留め、事実は一次情報で裏取りしています。
手段の一覧：何をコード化するか
| 手段 | 何をコード化するか | 通信 | コスト感 | 公式有効化 |
|---|---|---|---|---|
| Agent Skills | 手順・失敗カタログ・検証レシピ（SKILL.md など） | 必要時ロード | ベース文脈を肥大化させにくい | 製品機能（apps / Code / API） |
| Subagents | 役割・tools・model を定義し結果を親へ返す | 親へレポート | 比較的低い | 標準の委任パターン |
| Agent teams | 独立セッションの協調・共有タスク | 相互メッセージ可 | 高い（計画モードで約7倍の目安） | CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1（既定オフ） |
| チーム配布（例: ccteams） | 複数 subagent + オーケストレーション + playbook を一括適用 | CLI / プラグイン | パッケージ＋各エージェント消費 | npm ccteams 0.2.2 / GitHub toffyui/ccteams |
出典
出典（2026年7月時点）:
読み方の要点
- Skills は「作法」の器
- subagents は結果要約向きの委任
- agent teams は相互検証が必要な並列
- ccteams のような配布物は構成の再利用手段
最初からチームを増やす前に、何を SKILL.md に落とすかを決めると、コストと再現性のバランスが取りやすくなります。
なぜ「働き方」をコード化するのか
モデル枠より先に再現手順を持つ
結論から言うと、「より賢いモデルを使う」前に、再現可能な手順と役割定義があるかを確認する方が、モデル枠の変動に強いです。
上位モデルが暗黙にやっていることは、次のように分解できます。
- 目標の圧縮
- 根拠確認
- 仮説と検証
- 失敗時の手戻り
- 報告の正直さ
これらをチャット履歴だけに残すと、別モデルや別セッションへ移した瞬間に再現が崩れます。
Skills が担う「作法」の器
Anthropic の Skills は、手順・スクリプト・資源をフォルダ単位でパッケージし、必要なときだけロードする仕組みです。
公式には次のように定義されています。
- composable（組み合わせ可能）
- portable（apps / Claude Code / API で同形式）
- efficient（必要な部分だけ読み込み）
- powerful（実行コードを含められる）
常時読み込む CLAUDE.md を肥大化させず、検証コマンドや禁止パターンを SKILL.md 側に寄せると、中位モデルでも同じゲートを通せます。
実務での skill 化の流れ
実務では、一度だけ上位モデルにゴール圧縮・検証手順・失敗カタログを書かせ、人間がレビューしてから skill 化する流れが扱いやすいです。
スキルはコード実行を伴い得るため、信頼できない配布元の skill をそのまま入れるのは供給網リスクです。公式の安全注意とも一致するので、配布元の信頼が確認できるまで導入を見送る判断が妥当です。
Subagents と Agent teams の公式な違い
比較の分岐点
並列化には少なくとも二つの系統があります。分岐点は、通信が「親だけ」か「相互」かです。公式ドキュメントの比較を要約すると次のようになります。
| 観点 | Subagents | Agent teams |
|---|---|---|
| コンテキスト | 独自窓だが結果は呼び出し元へ | 完全に独立したセッション |
| 通信 | メインへ報告のみ | チームメイト同士が直接メッセージ |
| 調整 | メインが管理 | 共有タスクリスト＋自己クレーム |
| 向く仕事 | 結果だけ欲しい焦点タスク | 議論・相互検証が要る複雑作業 |
| トークン | 相対的に低い | 相対的に高い |
出典：Claude Code agent teams（2026年7月時点）
有効化
Agent teams は既定で無効です。次のいずれかで有効化します。
settings.jsonの"env": { "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1" }- 環境変数
CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1
有効化後は、自然言語でタスクと役割を指定して起動します。公式例では、UX / アーキテクチャ / 悪魔の代弁者のような複数役を同時に立てる使い方が示されています。
実験的制限と向き不向き
実験的機能としての制限も押さえておく必要があります。
- セッション再開（
/resume//rewind）で in-process のチームメイトは復元されない - ネスト不可
- 1セッション1チーム
- リード固定
- 権限はスポーン時にリードから継承
同一ファイルの同時編集や、依存が詰まりやすい直列タスクには向きません。相互通信が不要なら、チーム規模を広げず subagents に限定する方が安全で安い選択になります。
コストと運用制約 — チームを増やす前に見る数字
計画モードの倍率
並列は速度と引き換えにトークンを増やします。公式の costs ページは、agent teams が計画モード時に標準セッションの約 7倍 のトークンになる可能性を明記しています。各メイトが独立インスタンスと文脈を持つためです。
運用の目安
公式が示す運用の目安は次のとおりです。
- チームメイトには Sonnet を優先し、チームは小さく保つ
- spawn プロンプトは短く焦点を絞る（メイトは CLAUDE.md / MCP / skills を自動ロードし得る）
- 完了後はシャットダウンする
- 機能は既定オフのまま、必要なときだけ有効化する
エンタープライズ平均の目安として、1人あたり約 $13/稼働日、$150–250/月、90%は $30/稼働日未満という数字も公式に示されています。計画用のアンカーであり保証ではありません。
追加のレバーは次のとおりです。
- 単純な subagent を
model: haikuに固定する - Skills/hooks で冗長処理をオフロードする
/usageで監視する
読者アクション
読者アクションとしては、まず 3人以内の研究・レビュー用途で試し、実装並列はファイル衝突を避けて所有範囲を分割するのが現実的です。計画モードを全メイトに広げたまま長時間回すと、コストが先に跳ねやすいです。
実践 — 働き方を Skills / チーム定義に落とす手順
移管の5手順
発見記事が示す「作法の移管」を、公式機能と配布可能な成果物に接続する手順は次のとおりです。
- 一度だけ上位モデルに書かせる
ゴール圧縮、検証手順、失敗カタログ、報告フォーマットを書き起こし、人間がレビューして SKILL.md 候補にする。 - project / user skills に配置する
常時 CLAUDE.md を肥大化させず、必要時ロードにする（Skills の progressive load と整合）。 - 役割ごとに subagent を分離する
tools / model / description を役割に合わせる。例: レビューは上位モデル、実装は Sonnet、単純整形は Haiku。 - 相互議論が必要なら agent teams を有効化する
実験フラグを入れ、共有タスクと計画承認を使う。不要なら subagents に戻す。 - 構成を再利用するなら配布手段を評価する
例:npm install -g ccteams→ccteams list→ccteams use <team>。適用後に Claude Code を再起動する。プラグイン経由なら/plugin marketplace add toffyui/ccteamsなどの手順がある。
配布パッケージ（ccteams）の位置づけ
ccteams（npm 0.2.2）は Claude Code 向けの Agent-Team Package Manager として公開されています。
- 複数 subagent とオーケストレーションを
.claude/配下へ一括適用する - CLI と
/ccteams:*系のプラグインコマンドで運用する --agent-teamsで実験フラグを書き込む経路もドキュメントにある
適用前の注意点
注意点もあります。
- monorepo では subagent の効き方がプロジェクト全体に広がることがあり、手書きの
.claude設定と衝突し得る - Skills / agents はファイル配置やコード実行を伴う
- ライセンスと上書き範囲、配布元の信頼性、衝突リスクを確認する
導入判断チェックリスト
- Skills に「成功条件・禁止パターン・検証コマンド」が書いてある
- subagent の model / tools が役割に対して過剰でない
- agent teams が本当に相互通信を必要としている（不要なら subagent）
-
CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMSを有効化した理由を1行で説明できる - チームサイズ・計画モード・シャットダウン方針を決めた
-
/usageまたは課金画面でベースラインを取る小パイロットがある - 配布物（自作 or パッケージ）のライセンスと上書き範囲を確認した
失敗しやすい点:
- 同一ファイルを複数メイトに編集させる（衝突リスク）
- タスク完了フラグが遅れ依存が詰まる
- 再開後に存在しないメイトへメッセージする
これらは公式の制限（再開不可・タスク遅延・1セッション1チーム）と直結します。
関連して、次の記事も併せて参照できます。
- 指示とガードと検証を分離する設計は エージェントLoopを安全に回すハーネス設計
- 外ループの適用判断は ループエンジニアリング入門
- 長期記憶と人間向けノートの分離は 人間向けVaultとAI向けメモリ層を分ける
よくある質問（FAQ）
Q1. Agent teams と subagents はどちらを先に使うべき？
結果要約だけで足りるなら subagents です。仮説の相互反証や横断レビューが必要なら teams を検討します（公式比較表）。
Q2. 有効化しないと何も起きない？
既定はオフです。CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 が無いとチームは組まれません。
Q3. コストが跳ねやすい条件は？
メイト数の増加と plan mode です。公式は約7倍の目安と、Sonnet / 小チーム / 早期シャットダウンを推奨しています。
Q4. Skills だけで十分では？
Skills は「作法」の器です。並列実行と役割分離は subagent / teams 側です。両方を組み合わせるのが実務的です。
Q5. 第三者のチームパッケージを入れてよいか？
Skills / agents はコード実行やファイル配置を伴います。一次リポジトリ・ライセンス・衝突ガードを確認し、信頼できる配布元に限定してください。
関連記事:
- herdrとは？tmux比較で分かるAIエージェント用マルチプレクサの選び方
- Gemma 4 同名アップデート解説｜FA4・ツール呼び出し・再取得手順
- AIネイティブ組織の見極め方｜Enabled・Ready・Nativeと実務チェック
まとめ
frontier の優位を「モデル名」ではなく「検証可能な働き方」に変換し、Skills と役割分割で Opus / Sonnet 運用に載せるのが本筋です。
今日できる次アクション:
- チェックリストの上から3項目を実施する
- 小規模レビューチームで公式フラグを試験する
/usageでコストを見てから本採用する
相互通信が要らない作業に agent teams を使わないこと、計画モードの倍率を先に測ることが、失敗コストを下げます。
関連する新しい記事:
- Obsidian 視覚化の選び方｜Graph Canvas 比較 – This published update adds current operational context for 働き方をOpusへ移すエージェント運用.
- Kimi K3の導入判断｜料金・ベンチ・API注意点 – This published update adds current operational context for 働き方をOpusへ移すエージェント運用.
著者
krona23
IT業界20年以上の実務経験を持ち、日本国内有数のPVを誇る大規模Webサービスで事業部長・CTOを複数社で歴任。Windows/iOS/Android/Webと技術の変遷を経験し、現在はAIネイティブへの変革に注力。DevGENTでは、AIコードエディタ・自動化ツール・LLMの実践的な使い方を日英西3言語で発信中。
コメントを残す