Claude Code Agent Teams に記事を丸投げしたら、自分では書かない構成が返ってきた

レビューで殴られた話

ども！最近レビューで「伝え方がよくねえ」と言われて凹んでいる龍ちゃんです。

最近こんなレビューをもらいまして。一番刺さったのがこれです。

「誰に向けて書かれているのかわからない、読む気が失せる」
「結論までが長い、知らない単語への配慮もない」

まあ自覚はあるんですよね。自分のブログ、どちらかといえばメモに近い。やったことをまとめて出してるだけで、読者を考えたことなんてないですねw。

というわけで、「伝え方」の部分をまるっきりAIに丸投げできないかなと思っていたんです。検証した内容とか調べた内容を参照して、あとは伝わりやすく再構築してもらう。そういう仕組みがあれば最高なのに。

で、ちょうど Agent Teams がリリースされたんですよね。エージェント同士が協業してくれる仕組み。4人のAIチームを作ってブログ執筆を丸投げしてみました。ちなみにこの記事自体が、そのチームで書かれています。

先に結果だけ
トークンはバカ食いする。でも走り書きを共有するだけで、自分では構成しないようなストーリーラインのブログが出てくる。技術を列挙するだけだった構成が、読者への共感から入る構成に変わった。人間が手を入れるのは最後の20%だけ。

なぜ Agent Teams だったのか

サブエージェントでは足りなかった

これまで Claude Code のサブエージェントで「Opus で考え、Sonnet で動かす」構成を作ってきました（前回記事参照）。

これ自体は上手くいったんですが、サブエージェントは「結果を返すだけ」なんですよね。結果を受け取って、それを加味して次に何をするか考えて、また別のサブエージェントに投げる。オーケストレーションは全部人間の仕事でした。

言ってみれば「タスク委託」はできるけど「業務委託」ができない。個別の作業は任せられても、自分でプロセス全体を回す必要がありました。

僕がやりたかったのは、書く人・読む人・直す人が互いにツッコミ合う構成。でもそれにはチームメイト同士が直接やり取りする必要がある。サブエージェントでは無理な話です。

サブエージェントでネストができれば！って思っていたんですが、公式にネスト不可が明記されています。

Subagents cannot spawn other subagents.
出典: Create custom subagents

Agent Teams ならチームメイト同士が直接通信できる。チームメイトが独自のチームを作ることはできないんですが、ネストしなくても協調が成り立つ仕組みです。

で、公式ドキュメントを読んでいたら「コードを書かないタスクから始めろ」と書いてあるんですよね。推奨ユースケースの1番目も「Research and review」。ブログ執筆チームはまさにこのど真ん中でした。

ブログ執筆って「書く→ツッコむ→直す」の往復が本質なので、これはもう Agent Teams でやるしかないなと。というわけで実際にやってみました。

執筆チームの設計

チーム構成（4人 + リード）

Agent Teams 自体にはこういった役割のエージェントが用意されているわけではなく、全部自分で設計したものです。作ったチームがこれ。

メンバー	モデル	役割	なぜこの役割にしたか
writer	Opus	龍ちゃん風で記事を書く唯一の担当	文体の一貫性を守りたかった。複数人が書くとトーンがブレる
reader	Sonnet	想定読者としてツッコむ	レビューで「読者の気持ちがわかっていない」と言われた。それを直接解決する役
editor	Sonnet	AIっぽさ検出・主張のブレ監視	AIが書くと「典型的なAI構造」になりがち。それを見張る人が必要
researcher	Sonnet	技術的な裏取り（WebSearch）	「ネスト不可は本当か？」みたいな事実確認を自律的にやってほしかった

writer だけ Opus で、他は Sonnet。前回記事の「Opus で考え、Sonnet で動かす」構成をそのまま踏襲しています。

ポイントは reader です。読者を置いてけぼりにする傾向があるなら、AIに読者をやってもらおうと。せっかくならレビューをくれた人の主張や感覚を参考にして、プロンプトを設計しました。

実際にこんなツッコミが来ます。

「この3つのポイントは、誰にとって嬉しい情報ですか？」

こういうのが容赦なく飛んでくる。特徴は 修正案を出さず、問いだけ投げる こと。修正案まで出すと、観点＋文体なのでコンテキストが圧迫されます。結果として writer の文体が崩れるんですよね。reader は「ここで離脱する」「この単語わからん」と問いを投げて、修正は writer が自分の言葉でやる。

ワークフロー

全体の流れはこうなっています。

人間が手を入れる4つのタイミング

最初は「全部丸投げ」のつもりだったんですが、暴走しました。 チームが走り書きを受け取った後、アウトライン確認もなしに執筆まで一気に突っ走ったんですよね。出来上がったものを見たら方向性がズレていて、全部やり直し。フィードバックのループも、打ち切りを設定しないと reader と editor が永遠にツッコミ合って終わらない。

というわけで、人間の介入タイミングを設計しないとダメだとわかりました。まぁそんな甘い話はないですよね…ここが一番実用的な話だと思います。

1. 最初の情報提供

検証したこと・詰まったこと・改善することを走り書きで共有します。構成もSEOも考えなくていい。チームが分析した後に「この情報が足りない」とフィードバックが来ることがあるので、足りない分を追加で出す。一番大事なのは、自分がやったこと・感じたことを素直に出すこと。ここで足りない情報があると判断されれば追加を求められるように設計しています。

2. アウトライン承認

チームがアウトラインを作った段階で一旦止めて確認します。ここで方向性がズレていたら、後の執筆が全部やり直しになる。逆に言えば、ここさえ押さえれば後は安心して任せられます。

3. 完成記事の確認 + 残り20%の熱量注入

チームが書き終えたら内容を確認して、ブログ掲載用の情報（画像、リンク、補足）を追加する。そして 自分の思い・熱量が足りない部分を加筆する。80%の構成はチームが作ってくれるんですが、残り20%は自分で入れないとダメなんですよね。ここは後で詳しく話します。

4. 別セッションでの再レビュー

Agent Teams のセッションを切った後に、改めて読者目線でレビューをかけます。理由は課題パートで詳しく話しますが、チーム内の reader は徐々に初見じゃなくなるので。だんだん甘くなるのが面白いんですよね。

実際にチームが動いた様子

走り書きを投げた

実際に僕が投げた走り書きがこれです。

というかおれは気になったことを検証だけしていきたい。もちろんブログを書くこと自体は好きなんだけど、想定読者とか考えるとちょっと頭が痛くなってくる
最近レビューで「やっている検証自体はすごくいいけど、伝え方がよくねえ」「龍ちゃんは僕みたいなドーパミン中毒者の気持ちがわかっていない」って言われた
というわけで僕はやったことと・検証コード・調べた内容を共有するだけでブログが出来上がったら最高だなって思うんだよねというわけでやってみる！

こんな感じの走り書きがしばらく続きます。構成もSEOも何も考えてない。前半はもはや愚痴です…ただやったことや考えたこと、頭の中に思いついた関連する情報をやみくもに突っ込んだ感じです。

チームがやったこと

走り書きを投げた後の動きがこれです。

researcher が最初に動いたのは裏取り。「サブエージェントのネスト不可って本当に公式で明記されてる？」を確認しにいって、公式ドキュメントの原文を引っ張ってきた。さらに「公式がコードを書かないタスクから始めろと推奨している」という記述を見つけてきたんですが、これは僕自身知らなかった情報でした。セクション1に書いた「ブログ執筆チームはまさにこのど真ん中」って話は、researcher が見つけてくれたおかげで書けています。

reader は容赦なかったですね。「Before/After の具体性がゼロ。『構成が読者目線になった』って言われても、実際にどう変わったのか見えない。読者は『本当に？見せてよ』と思う」とツッコんできた。あと「読者の集中力は3秒だと思え、冒頭で掴めなかったら終わり」とも。

editor は一段引いた視点で「技術解説が長すぎると “伝え方が下手” 問題の再現になってしまう」と指摘してきました。これ刺さりましたね。「伝え方がダメ」を解決する記事なのに、記事自体の伝え方がダメだったら本末転倒じゃないですか。

Before/After: フィードバックで何が変わったか

reader と editor のフィードバックを経て、構成がどう変わったかを見せます。

Before（最初の構成案）

Agent Teams の技術紹介（Subagentsとの比較表がメイン）
設計（チーム構成 + ワークフロー + セットアップ方法が本編の中）
実際の動き
良かった点 / 課題 / Subagentsとの使い分け（箇条書き3ブロック並列）
まとめ: 「完全自動ではないが、トレードオフは要検討」

技術ブログ書いたことある人なら「あー、自分もこう書くわ」って思いません？というか過去のブログがまさにこれですね。自分がやったことを順番に並べて、最後に感想。まさに「読者置き去り型」の構成です。

After（フィードバック反映後）

痛みから入る（レビュー指摘）→ TL;DR
なぜ Agent Teams か（動機ベース。比較表は公式リンクで済ませる）
設計 + 人間が手を入れる4つのタイミング（セットアップは末尾に移動）
実際の動き + Before/After 比較 + お気持ちログ
ぶっちゃけどうだったか（「一番効いたこと」軸で流れ語り）
まとめ: 「80%は任せられる。残り20%の熱量こそが記事の核」

全部、reader と editor のツッコミがきっかけで変わっています。自分ひとりでは「技術比較表から入る」構成に疑問すら持たなかったと思います。

writer のお気持ちログ

ここでちょっと変わった仕掛けの話をさせてください。

writer エージェントには「フィードバックを受けたら、修正する前に素直な感想を書け」と指示してあります。面白かったんで共有します。

editor から「この記事の核は『丸投げしたい』と『全部は無理』の葛藤だ」と言われた後:

確かにそうだ。ツール紹介にしちゃダメなんだよな。「どこまで任せられて、どこで人間が入るべきか」に実体験で答える記事にする。

reader から「”今回の内容”リストが技術ドキュメントの目次に見える」と言われた後:

うわ、確かに。せっかく共感で掴んだのに「今日の授業内容はこちらです」は台無しだ。

editor から「セクション4が典型的なAI構造」と言われた後:

ぐぬぬ…これは痛い。「良かった点」「課題」「使い分け」の3ブロック、まさにAIが書きそうな構成だ。

修正の過程が可視化されるので、何がどう変わったかの記録にもなります。そしてこうやって記事のネタにもなる。一石二鳥の仕掛けでした。
今後はここに僕の人格を埋め込んで共感できるようにしてやる予定です…

ぶっちゃけどうだったか

一番効いたのは reader のツッコミ

正直、記事の骨格ができること自体は想定内だったんですよね。アウトライン作って、セクションごとに書いて、体裁を整える。これはAIに任せれば当然できる。

想定外だったのは、自分では絶対にやらない構成が出てきたこと。技術列挙から入る構成が、読者の痛みから入る構成に変わった。reader がいなかったら「技術比較表から始めよう」の構成に疑問すら持たなかったと思います。書いてる本人は文脈を全部知ってるから、何が伝わってないかわからない。そこに reader がいることで、構成自体が読者目線に変わった。

「読者の気持ちがわかっていない」というレビューの答えが、読者役エージェントという形で返ってきた感覚でした。

正直な課題

ただ、良いことばっかり書いてもしょうがないので。

トークンコストはめちゃめちゃ食います。 各チームメイトが独立した Claude インスタンスとして動くので、4エージェント + リードで理論上約4-5倍のトークン消費。トークン削減シリーズを書いてきた自分が言うのもアレなんですが、「伝え方」改善のコストとしては…まあ妥当かなと思うようにしています。

80%は任せられるけど、残り20%が大事。 構成もストーリーラインもきれいに作ってくれる。でも自分の思いや熱量は乗らないんですよね。「この機能ずっと待ってた」「ここで痛い目見た」みたいな温度感は、最後に自分で注入する必要がある。走り書きの質がそのまま記事の質に影響するので、検証したこと・感じたことを素直に出さないと、チームも薄い記事しか作れない。

一番時間がかかるのは最後の人間レビュー。 チームの出力をそのまま出せるわけじゃなくて、想定読者の主張と自分の意見を喧嘩させてブラッシュアップする作業が要る。しかもチーム内の reader は writer とのやり取りを重ねるうちにだんだん懐柔されていくんですよね。最初は容赦なくツッコんでたのに、後半は甘くなる。だからセッションを切って、フレッシュな視点で改めてレビューする必要がある。ここが結局一番手間がかかるところでした。

最後に一つ。Agent Teams は2026年2月5日リリースの research preview です。 正式リリースではないので、今後変更の可能性があります。

まとめ

「検証だけしたらブログが出来上がる」は実現できたか？

80%は任せられます。構成もストーリーラインもきれいに作ってくれる。

でも、自分の思いや熱量は乗らない。

だから残り20%は自分で書く。この20%がなかったら、きれいなだけの記事で終わる。

一番大事なのは、検証したこと・詰まったこと・改善すること。それを走り書きで共有すれば、「伝え方」はチームが整えてくれます。

完全自動で完璧な記事が出てくるわけじゃない。でも「ひとりで悩んで手が止まる」はあきらかに減りました。コストは高い。でも「伝え方がよくねえ」と言われ続けるよりはマシです。

この記事自体がその実験の成果物です。読んでどう感じたかが、この仕組みの評価そのもの。

ほなまた〜

やってみたい人向け: セットアップ

有効化

export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1

devcontainer で使う場合

{
    "remoteEnv": {
        "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
    }
}

設計Tips

article.md に書けるのは writer だけにする。 他のメンバーが直接記事を編集すると文体が崩れるし、ファイル競合も起きる。公式ベストプラクティスにも「ファイルの競合を避けろ」とある
broadcast は使わない。 チームメイトへの指示は全部個別メッセージ（write）で。broadcast だとメッセージが全メンバーに届くのでトークンが人数分かかる

注意点

VS Code 統合ターミナルでは Split Panes 非対応 → in-process モードで動く
Split Panes を使いたい場合は tmux または iTerm2 が必要
1セッションにつき1チーム
実験的機能。今後変更の可能性あり

Claude Code Agent Teams に記事を丸投げしたら、自分では書かない構成が返ってきた

レビューで殴られた話