この記事の要点（2026年6月）: Claude Code Workflow のAPIで「39記事へのCTA（記事末尾の誘導文）一括追加」を1本のWorkflowに任せたところ、116エージェントが起動し、4.28Mトークン・5時間17分を消費した（実測。出典は内部ログ）。原因は、本来「単一エージェントのbashループ」で済む順次処理のフェーズに、並列処理と同じ粒度の設計（1エージェント/本）を採用したこと。並列フェーズだけWorkflowのparallel()に任せ、順次フェーズをbashループに切り替える理想設計なら約40エージェント・745Kトークン・約$4.47で済んだ計算になる。コスト差は5.7倍。この記事は、その線引きをどう設計すればいいかを実測ベースでまとめたものだ。
Workflowで「全部やる」が、なぜ高くつくのか
Claude Code の Workflow API を使い始めると、最初に魅力的に見えるのは「複数のタスクをまとめて自動化できる」点だ。記事を39本まとめて編集し、はてな・Zenn・Qiitaへ順に公開する——そんな一連の流れを1本のWorkflowに書けば、あとは走らせるだけで終わる。便利に見える。
ところが、この「全部やる」が落とし穴になる。Workflowに任せる処理には、性質の異なる2種類が混ざっているからだ。
- 並列処理: 39本の記事をそれぞれ独立に編集する。1本の処理が他の本に依存しない
- 順次処理: はてなに1本ずつ公開する。APIのレート制限や公開順序の都合で、1件ずつ直列に進める必要がある
この2つを同じ粒度で設計すると——つまりどちらも「1タスク = 1エージェント」で組むと——順次処理の側でエージェント起動コストが線形に積み上がる。これが今回の体験で起きたことだ。
結論を先に言う。並列処理にはWorkflowのparallel()、順次処理には単一エージェントのbashループを使う。この使い分けを設計段階で意識できているかどうかで、コストが数倍変わる。
何をして、何が起きたか
2026-06-20、私は39本の記事に「次の問い予告型」のZenn Book CTA（記事末尾の誘導文）を一括追加するWorkflowを実行した。各記事のテーマに合わせてCTA文面を生成し、ソースファイル・はてな投稿用entry・Zenn投稿用contentの3か所を編集し、そのまま各プラットフォームへ公開するところまでを1本のWorkflowにまとめた。
走らせた結果が、これだ（実測値。出典は内部ログ）。
| 指標 | 実測値 |
|---|---|
| 実行時間 | 5時間17分（19,052,752ms） |
| トークン消費 | 4,283,366（4.28Mトークン） |
| 起動エージェント数 | 116 |
| ツール使用回数 | 510回 |
CTAの一括追加という、見た目には単純な作業だ。それが5時間を超え、4.28Mトークンを消費した。「うまく自動化できた」と思った直後に、数値を見て手が止まった。
Workflowの構成は、5つのフェーズに分かれていた（出典: 内部ログ）。
-
Phase 1（CTA編集）: 39記事を
parallel()で同時処理。各エージェントが記事を読み、テーマに合ったCTAを生成して3か所のファイルを編集 - Phase 2（はてな公開）: 1エージェント × 38本を順次ループ
- Phase 3（Zenn push）: 単一エージェントでgit push
- Phase 4（Qiita公開）: 1エージェント × 37本を順次ループ
- Phase 5（コミット）: 単一エージェント
はてな38本・Qiita37本と39本から差があるのは、Zennのみ公開・クロスポスト除外などプラットフォームごとの公開対象が異なるためだ。
問題はPhase 2とPhase 4にある。
なぜエージェントが116本になったのか
「複数の記事を順番に公開する」と聞くと、直感的には「1本ずつ処理するエージェントを並べればいい」と考えてしまう。私もそう設計した。Phase 2では「1エージェントが1本を公開する」を38本ぶん、Phase 4では同じく37本ぶん繰り返した。
ここに、エージェント起動コストの構造的な落とし穴がある。
Claude Code のサブエージェントは、それぞれが独立したコンテキストウィンドウを持って起動する。1本のエージェントを立ち上げるたびに、そのエージェントは自分の役割・手順・前提を一から読み込む。1件の公開作業そのものは軽くても、その前段の「起動して文脈を整える」コストが毎回かかる。
Phase 2の38本とPhase 4の37本で、合計75回ぶんの起動コストが積み上がった。Phase 1の並列39本や各フェーズの管理エージェントと合わせると、起動したエージェントは116本にのぼった。
これは、別記事で「サブエージェント委任税」として書いた構造とまったく同じものだ。1タスクごとにエージェントを起動すると、起動コストがタスク数に比例して線形に積み上がる。委任税の記事ではネタ帳1件のクイックキャプチャで「COO直接実行が8秒、エージェント委任が約1分」という差を実測したが、今回はそれが75件ぶん積み上がった格好になる。
順次処理では、この起動コストが毎回発生する。これがコストを膨らませた正体だ。
補足: 「116エージェントは39本同時処理という特殊ケースでは？普通はそうならない」と感じる読者もいるだろう。確かに件数の大きさは特殊だ。だが「1件ごとにエージェントを起動すると起動コストが件数に比例する」という構造自体は、件数が3本でも300本でも変わらない普遍的なものだ。件数が増えるほど、設計ミスの代償が大きく見えるだけである。
なぜ「並列か、順次か」でフェーズの実装を分けるべきなのか
では、どう設計すればよかったのか。原則はシンプルだ。フェーズの性質（並列か順次か）で、実装方式を分ける。「これは各タスクが互いに依存しないか」という問いが判断の基準になる。
| フェーズの性質 | 適切な実装 | 理由 |
|---|---|---|
| 並列処理（各タスクが独立） | Workflowのparallel()
|
エージェントが真に並行動作し、処理時間が圧縮される |
| 順次処理（1件ずつ直列） | 単一エージェントのbashループ | エージェント起動コストが1回だけで済む |
並列処理にはWorkflowのparallel()を使う
Phase 1のCTA編集は、39本がそれぞれ独立している。A記事のCTA生成はB記事の結果を必要としない。こういう「各タスクが互いに依存しない」処理こそ、Workflowのparallel()が真価を発揮する場面だ。
39本を1本ずつ直列にやれば39倍の時間がかかるが、parallel()なら同時に走る。起動コストは39本ぶんかかるものの、それと引き換えに処理時間が劇的に圧縮される。並列フェーズでは、この時間短縮がコストに見合う。bashループで39本を直列処理していたら、それこそ何時間も待つことになっていただろう。
順次処理には単一エージェントのbashループを使う
一方、Phase 2のはてな公開は事情が違う。1件ずつ直列に進めるしかない処理だ（公開APIのレート制限や順序の都合がある）。どうせ直列なら、エージェントを何本も起動する意味がない。
ここは「1本のエージェントを起動し、そのエージェントの中でbashループを回して38本を順に公開する」のが正しい。エージェントの起動コストは1回で済み、ループ自体はシェルが回すのでほぼタダだ。Phase 4のQiita公開も同じく、1エージェントのbashループに畳める。
順次処理でエージェントを件数ぶん起動するのは、シェルのforループで済む処理に毎回プロセスを立ち上げ直すようなものだ。直列なら、文脈を持ったエージェントは1本いれば足りる。
ここで「bashループで十分なら、そもそもWorkflowを使う意味は？」と思うかもしれない。意味があるのは並列フェーズだ。Phase 1の39本同時処理は、bashループでは直列にしかならず、何時間もかかる。Workflowの
parallel()はそこでこそ効く。Workflowは「並列を圧縮する道具」であって、「順次処理を肩代わりする道具」ではない、と捉えるとよい。
理想設計との比較: コストは5.7倍違った
実際の設計と、原則どおりに組み直した理想設計を、フェーズ別に並べるとこうなる。
| フェーズ | 実際の設計 | 理想設計 |
|---|---|---|
| Phase 1: CTA編集（並列・39本） |
parallel() で39エージェント |
parallel() で39エージェント（変更なし） |
| Phase 2: はてな公開（順次・38本） | 1エージェント × 38本 | 1エージェントのbashループ |
| Phase 4: Qiita公開（順次・37本） | 1エージェント × 37本 | 1エージェントのbashループ |
| 起動エージェント総数 | 116本 | 約43本（Phase1:39 + Phase2〜5:各1） |
並列フェーズ（Phase 1）はそのままで正しい。変えるべきは順次フェーズ（Phase 2・4）の75本を、それぞれ1エージェントのbashループに畳むことだ。これだけで起動エージェントは116本から約43本（Phase1:39本 + Phase2〜5:各1本）まで減る。
コストに換算すると、こうなる（試算。出典は後述）。
| 実際の設計 | 理想設計 | |
|---|---|---|
| トークン消費 | 4,283,366（4.28M） | 約745,000 |
| 概算コスト | 約$25.70 | 約$4.47 |
コスト差は5.7倍。同じ成果物（39本へのCTA追加と公開）を得るのに、設計の線引きひとつで6分の1近くまで圧縮できた計算になる。
コスト試算の前提を明示しておく。トークン単価は Sonnet 4.6 の $3/MTok（入力）・$15/MTok（出力）、入出力比を3:1と想定した。4,283,366トークンを3:1で按分すると入力 約321万・出力 約107万トークンで、概算 約$25.70。理想設計の745,000トークンを同じ比率・単価で計算すると 約$4.47（いずれも2026-06-20時点の単価による試算であり、実際の課金額とは差が出うる）。
Workflowは「並列フェーズ専用の道具」——設計の線引きでコストが5.7倍変わる
Workflowは並列フェーズを圧縮する道具であって、順次フェーズを肩代わりする道具ではない。
今回の体験から取り出せる設計原則は、この一文に尽きる。
-
並列処理（各タスクが独立）→ Workflowの
parallel()。起動コストと引き換えに処理時間を圧縮する - 順次処理（1件ずつ直列）→ 単一エージェントのbashループ。起動コストを1回に抑える
「Workflowで全部やる」は、並列と順次を同じ粒度で設計してしまうと逆コストになる。私はそれを、事後の数値（116エージェント・4.28Mトークン・5.7倍）で初めて思い知った。
理想を言えば、この線引きは設計段階で意識したい。フェーズを書き出したら、それぞれに「これは並列か、順次か」と一度問う。並列ならparallel()、順次ならbashループ。その一手間が、コストを数倍ぶん左右する。
一点、補足しておきたい。今回のWorkflowを依頼したときの指示は「39本の記事に同様に反映しておいて」というシンプルなものだった。「順次処理は単一エージェントのbashループで」とは一言も言っていない。
この線引きは、ユーザーが指示に含める必要のある知識ではない。 Workflowを実装する側——エージェントでもエンジニアでも——がデフォルトで判断すべきことだ。依頼者が「並列か順次か」を設計レベルで意識して指示しなければ効率的な実装にならないなら、それは実装の側の設計力の問題だ。
言い換えると、今回の体験は「こう指示すれば良かった」という話ではなく、「Workflowを書く側がこの判断を持っていなかった」という話になる。
なお、今回の実行では Qiita 公開時にレート制限（HTTP 429）も別途起きていたが、それはまた別のテーマなので本記事では扱わない。順次公開の設計には、起動コストとは別にレート制限への配慮も要る——という宿題だけ置いておく。
Workflowのフェーズ設計で「どこを並列にし、どこを順次に畳むか」を整理すると、次の問いが出てくる——そもそもこのWorkflowを動かしている複数のエージェントを、どう組織として設計し、どう運用に乗せたのか。
並列・順次の線引きは「チームが動いている」前提の話だ。私はその前段階――エージェント構成を組み、それを日々の自動化に乗せていく過程――を Zenn Book にまとめている。Vol.1では役割設計・委任ルール・CLAUDE.mdの書き方を、Vol.2では運用・自動化・Routinesの組み方（今回のようなWorkflowをどこに置くか、を含む）を扱っている。
関連記事: Claude Codeのサブエージェント委任税（エージェント起動コストの構造を、別の角度から分析した記事）
この記事は はてなブログ からのクロスポストです。