この記事は Zenn に投稿した記事の転載です。
「役割ごとにエージェントを分ければ、記事の質も上がるしコストも下がるはずだ」——そう思って作った技術ブログの自動生成パイプラインは、実測したら逆だった。サブエージェントを11個から0個にしたら、トークンの総量はむしろ27.7%増えたのに、記事1本のコストは87.7%下がった。この記事は、コードを1行も書かない人間がClaude Codeのプロンプトだけでこのパイプラインを作り、実測値をもとに設計をひっくり返した実録である。
問題: エージェントを分けるほど良いと思い込んでいた
このパイプラインは、当社が複数のブログを無人生成するために、Claude Codeのプロンプトだけで組んだ社内システムである。プログラマーが書いたコードは1行もない。予約システム・ゲーム・メニューバーアプリも同じやり方で作っている。
技術ブログ版の最初の構成は、チーフ1体の下に専門役を並べた7エージェント編成だった。
-
chief（進行管理）
-
keyword（ネタ選定）
-
research（一次情報リサーチ）
-
outline（構成）
-
writer（執筆）
-
publish（入稿整形）
-
qa（採点・独立プロセス）
直感としては自然だった。人間のチームでも役割分担すれば専門性が上がる。「ネタ選定担当」と「執筆担当」を分ければ、それぞれが自分の仕事に集中できる——はずだった。
実測: 1本の記事に$41.7かかっていた正体
実際にこの7エージェント構成で完走した記事（ローカル画像生成をテーマにした実録記事・本文4,000字前後・図解2点・2026-07-14公開）のトークン内訳を数えたところ、次の数字が出た。
| 区分 | トークン |
|---|---|
| 親セッション | 737,594 |
| サブエージェント11個（合計） | 6,216,660 |
| 合計 | 6,954,254 |
この記事の最終出力（記事本文）はわずか約4,000トークン。つまり合計トークンは成果物の約1,738倍あった。さらに内訳を見ると、課金対象の79%（5,455,523トークン）が「キャッシュ読み直し」——つまり同じ文脈（共通のシステムプロンプト・スキル定義・役割定義）を、エージェントを跨ぐたびに毎回読み直していた分だった。
決定的だったのは設計そのものの前提である。各段は「順番に1つずつ」回すルールだった。つまり並列で議論も相互チェックもしていない。7体に分けても、判断しているのは同じモデルで、読んでいる素材も同じ。分割が生んでいたのはコストだけで、判断の質には何も寄与していなかった。
統合の結果: トークン27.7%増でも、コストは87.7%下がった
そこで7エージェント（別系統の版は9エージェント）構成を廃し、①ネタ選定→②一次情報→③構成→④執筆→⑤QA→⑥入稿を単一セッションが上から順に実行する「手順」に統合した。QAだけは独立プロセスとして残した（後述）。同じ記事1本を新旧両構成で完走させて比較した実測が下図である。
記事1本・完走同士の比較（2026-07-17・社内の実測記録より）
数字だけ見ると矛盾しているように見える。トークン総量は6,954,254→8,880,984で27.7%増えた。キャッシュ読みも5,455,523→8,457,896で55.0%増えた（全工程の文脈が1セッションに乗るぶん、むしろ累積する）。それでもコストは$41.68→$5.12へ87.7%下がった。
理由はキャッシュの「書き」と「読み」の価格差にある。エージェント境界を跨ぐたびに新しいコンテキストの再プリフィル（＝キャッシュ書き）が発生し、これが1,402,348→334,689トークンへ76.1%減った。社内の運用ログを試算すると、書き込みは読み直しのおよそ12.5倍高い換算になっていた（$3.75/M vs $0.30/M・Anthropic公式の価格表ではなく内部試算）。読みがどれだけ増えても、書きが76%減れば差し引きで勝つ、という計算である。
なぜ「書き」がこれほど高くつくのか。プロンプトキャッシュは、共通の前置き（共通のシステムプロンプト・スキル定義・役割定義）を一度プレフィルしてKVキャッシュに載せ、次回以降はそれを「読む」だけで済ませる仕組みだ。読みはキャッシュ済みの再利用なので安い。ところがサブエージェントを起動すると、親のKVキャッシュはそのまま引き継がれない。子は同じ共通前置きをもう一度読み込み直してキャッシュに「書き」直す——これが再プリフィルであり、キャッシュ書きが割高に課金される所以である。エージェント境界の数だけ、この高い書き直しが積み上がっていた。統合はこの書き直しの回数そのものを削る。
ただし正直に書くと、このコスト差の全部が統合の効果ではない。内部の見立てでは統合そのものが効いたのは約4割、残り約6割はモデル選択（Opus→Sonnet）による。「エージェントを消したら魔法のように安くなった」という話ではなく、「エージェント境界の再プリフィルコストを削った上で、さらにモデルも見直した」の合わせ技である。
それでも1つだけ、分けたまま残したもの
QAだけは統合せず、別プロセス（格安モデルによる独立採点）を維持した。理由は単純で、生成したモデルに自己採点させると、評価が生成の都合に引っ張られるからだ。「自分で書いた記事を自分で75点だと正直に採点できるか」という話であり、これは分割コストに見合う数少ない例外として扱っている。
ここから一般化できる判断基準は次の1文に尽きる。「その段は本当に並列で議論・相互チェックしているか、それとも順番に1つずつ回っているだけか」。後者であれば、エージェント境界はプレフィルコストを生むだけの装飾になる。前者（独立した目が必要な工程）であれば、コストを払ってでも分ける価値がある。
再現できる学び
自分のパイプラインで「役割ごとにエージェントを分けている」なら、まずその段が本当に並列で独立した判断をしているかを確認するとよい。していないなら、エージェント境界はコンテキストの再プリフィルを生むだけの、ただの高いファイル受け渡しである。各段が順番待ちで直列実行される設計では、分割はコストにしかならない。
各段を、次の2問で仕分けると判断が速い。
-
その段は同時並行で複数案を競わせているか？ — Noなら、分割は並列性を生んでおらず、境界の再プリフィルコストだけが残る。統合してよい。
-
その段には独立した検証者（生成側と利害が違う目）が要るか？ — Yesなら、QAのようにコストを払ってでも分ける価値がある。
2問とも No の段は統合する。どちらかが Yes の段だけ、境界を残す。逆に言えば、段どうしが本当に並行して走り、互いの中間結果を見て動的に分岐する設計——複数案を同時に走らせて優劣を競わせる、途中結果次第で次工程を切り替える——なら、境界はプレフィルコスト以上の仕事をしている。直列に1つずつ手渡すだけの段は統合し、並行・独立・動的分岐が本当に要る段だけ分ける。線引きはそこにある。
実際、この記事自体も「エージェントを増やせば賢くなる」という当初の直感が実測で覆された結果を書いている。分けることは無料ではない。