Claude Codeのworkflowオーケストレーションを使ってみた——エージェントに「議論」させて深掘りする
はじめに
Claude Codeを使っていると、ある時から「単発の指示」では物足りなくなってきます。
簡単な実装やリファクタリングなら、Claudeに一言投げれば十分です。でも、「この方針で本当に正しいのか、別の角度からも検証してほしい」とか、「一つのテーマを多方向から深掘りして、結論まで持っていきたい」という場面では、1人のClaudeと1往復ずつ会話するやり方だと、どうしても視点が一方向に偏りがちでした。
そんな悩みに刺さったのが、Claude Codeの workflowオーケストレーション という機能です。これは、複数のサブエージェントをスクリプトで決定論的に動かし、役割分担させながら一つのゴールに向かわせる仕組みです。
この記事は「新機能の紹介」ではなく、実際に自分のブログ運営と技術検討で回してみた体験記です。良かった点だけでなく、Maxプランの5時間枠を2〜3往復で使い切ってしまったというコスト面の現実も含めて、正直にまとめます。
この記事で持ち帰れること
- workflowオーケストレーションが「エージェント同士の会話」とどう違うのか、その実態
- 「発案→検証→提案書作成」「議論→指摘→深掘り」を実際に回した体験
- コストがどれくらい重いのか（具体的な使用感）
- いつ使うべきで、いつ使うべきでないのかの判断軸
workflowオーケストレーションとは何か
まず、よくある誤解を解いておきます。
「複数のエージェントを動かす」と聞くと、AI同士がチャットで雑談しながら議論を深めていくようなイメージを持つかもしれません。私も最初はそう思っていました。
実際は少し違います。workflowオーケストレーションの正体は、どのエージェントに・何を・どの順番でやらせるかをコードで記述する仕組みです。自由なおしゃべりではなく、前段のエージェントの成果物を、次段のエージェントの入力として渡していくパイプラインに近いものです。
ざっくり言うと、こういうことができます。
- fan-out（並列展開）: 同じテーマを複数のエージェントに別々の視点から同時に調べさせる
- pipeline（多段処理）: 発案 → 検証 → 提案、のように成果物を順に受け渡す
- 合議パネル: N人のエージェントに独立して案を出させ、別のエージェントが採点・統合する
- 敵対的検証（adversarial verify）: ある主張に対して、複数のエージェントに「これを論破してみろ」と指示し、過半数が論破できなければ本物とみなす
つまり「会話」というより、役割を持った専門家チームに、決められた段取りで仕事を回していくイメージです。ここを理解しておくと、後で「なぜコストが跳ね上がるのか」も腑に落ちます。
「会話」ではなく「段取り」
エージェント同士が自由に喋るのではなく、1段ごとに成果物が確定し、それが次の入力になる。だからこそ結果が安定し、再現性もある。一方で、段数とエージェント数の掛け算でコストが膨らむ、という裏返しの性質も持っています。
実際に試したこと①：ブログ運営の意思決定を「議論→指摘→深掘り」で回す
最初に試したのは、このブログの運営に関する意思決定でした。
私のブログは過去にGoogle AdSenseの審査で「有用性の低いコンテンツ」として不合格になった経緯があり、記事の品質基準を見直したり、テーマの取捨選択をしたりする判断が常に発生します。こうした、正解が一つに決まらず、トレードオフのある判断こそ、多角的な検討が効くと考えました。
そこで、おおよそ次のような段取りを組みました。
- 議論役: 「この記事群はAdSense的にどう評価されるか」を複数のエージェントに別観点で評価させる（独自性・読者価値・重複の観点など）
- 指摘役: 出てきた評価に対して、別のエージェントが「その判断の弱点・見落とし」を突っ込む
- 深掘り役: 指摘を踏まえて、最終的に「どの記事をどう改善すべきか」を具体策まで落とす
面白かったのは、1人のClaudeに順番に聞いていたときには出てこなかった反論が、指摘役を独立させることで出てきたことです。同じモデルでも、役割を分けて独立に走らせると、視点が混ざらない。一人で考えていると無意識に避けてしまう自案へのダメ出しを、構造的に強制できるのが大きい収穫でした。
実際に試したこと②：技術設計を「発案→検証→提案書作成」で回す
次に試したのが、技術的な設計・アーキテクチャの検討です。
このブログはNext.js + 静的エクスポートで運用していて、ホスティングをS3 + CloudFrontからCloudflare Pagesへ移行した経緯があります。こうした、複数の選択肢があり、後から変えにくい意思決定も、workflowと相性が良いテーマです。
組んだ段取りはこうです。
- 発案役: 課題に対して、複数のエージェントがそれぞれ違う前提で設計案を出す（コスト最優先・運用ラク最優先・移行リスク最小、など角度を変える）
- 検証役: 各案に対して「本当にその想定で動くのか」「見落としている制約はないか」を独立に検証する
- 提案書化: 検証を通った案を、判断材料が揃った提案書の形にまとめる
ここで効いたのが、角度を変えて複数案を出させるという発案の作り方です。1人に「最適な設計を考えて」と頼むと、最初に思いついた案を磨く方向に進みがちです。でも、最初からコスト最優先の人・運用ラク最優先の人を別々に走らせると、トレードオフが可視化され、自分が本当は何を優先したいのかがはっきりしました。
最終的に出てきた提案書は、自分一人で書いた検討メモよりも、反論への耐性が高いものになっていました。これは「いざ深掘りしたいとき」に確かに有用だと感じた瞬間です。
ハマったこと：コストがとにかく重い
ここからが、これから試す人に一番伝えたい現実です。
workflowオーケストレーションは、とにかくコストが高い。
私はClaude Maxプランを使っていますが、Maxには5時間ごとの利用枠（一定時間でリセットされる使用上限）があります。普段の単発のコーディング作業なら、この枠を意識することはほとんどありません。
ところが、上で書いたような段取りを 2〜3往復ほど回しただけで、この5時間枠を使い切ってしまいました。
理由は、仕組みを理解していれば当然です。workflowは 段数 × 1段あたりのエージェント数の掛け算で動きます。たとえば3つの観点をそれぞれ3人で検証するだけで、1往復に9エージェント。それを多段で、しかも各エージェントがコードベースを読んだり長文を生成したりすれば、消費量は単発の指示とは桁が変わります。
合議パネルや敵対的検証は、わざと冗長に複数の視点を走らせて結論の信頼性を上げる手法なので、品質と引き換えにコストを払っているわけです。「便利だから」と気軽に多用すると、肝心なときに枠が残っていない、という事態になりかねません。
コスト感のまとめ
- 単発の指示：日常作業ではほぼ枠を気にしなくてよい
- workflowオーケストレーション：2〜3往復でMaxの5時間枠を使い切る規模感
- エージェント数 × 段数で消費が膨らむため、何人に・何段走らせるかを最初に見積もる意識が必要
使い所の判断軸
体験を踏まえて、私なりの使う・使わないを分ける判断軸を整理します。
使うべき場面
- 正解が一つに決まらない、トレードオフのある意思決定（設計の選択、運用方針、テーマの取捨選択）
- 後から変えにくい・やり直しコストが高い判断（アーキテクチャ、移行先の選定）
- 自分一人だと視点が偏る／自分の案にダメ出しできないと感じるテーマ
- 結論の信頼性を、多少コストを払ってでも上げたいとき
使わないほうがよい場面
- 答えが一つに決まる単純なタスク（普通に1往復で頼めば十分）
- 急いでいて、5時間枠を温存しておきたいとき
- まだテーマがふわふわしていて、何を検証すべきか自分でも整理できていないとき（先に普通の壁打ちで論点を絞るべき）
要するに、いざ深掘りしたい・ここは外したくない、という勝負どころに集中投下するのが正解だと感じました。日常の作業に常用するツールではなく、ここぞという1回のための武器です。
まとめ
Claude Codeのworkflowオーケストレーションを、ブログ運営の意思決定と技術設計の検討で実際に回してみました。
- 実態は「エージェント同士の自由な会話」ではなく、役割分担した成果物の受け渡し（段取り）
- 「発案→検証→提案」「議論→指摘→深掘り」のように、多方向から一つの結論に追い込めるのが最大の価値
- 役割を独立させることで、一人では避けがちな自案へのダメ出しを構造的に強制できる
- 一方でコストは重く、Maxの5時間枠を2〜3往復で使い切る規模感。使い所は選ぶ必要がある
「便利だから常用」ではなく、深掘りしたい勝負どころに絞って投下する。この距離感さえ守れば、いざというときに非常に頼れる機能です。気になっている方は、まず小さな段取り（2段・各2エージェントくらい）から、枠の消費を観察しつつ試してみることをおすすめします。