【CCA Foundations対策 / Claude API編 #11】ワークフロー設計パターン——並列・直列・評価ループ・ルーティング

Anthropic Academyの「Claude APIを使用した構築」コースをもとに解説しています。

#10まではツールの実装に集中してきた。今回から2回に分けて、複数のClaudeリクエストを組み合わせる「ワークフロー」と「エージェント」の設計に入る。

この記事でわかること：

ワークフローとエージェントの違い（概念整理）
並列化・直列・評価ループ・ルーティングの4パターンの仕組み
それぞれのパターンをどんな場面で使うか

ワークフローとは

ワークフローとは、あらかじめ決まった手順でClaudeを複数回呼び出す仕組みのこと。

「このタスクをこなすには、ステップ1でAをやって、ステップ2でBをやって……」という流れが事前にわかっている場合に使う。複雑なタスクを小さな処理に分解し、それぞれをClaudeに任せることで、1回のリクエストでは難しいことを実現できる。

エージェント（次回解説）との違いを先に整理しておく。

	ワークフロー	エージェント
処理の流れ	事前に決まっている	Claudeが実行時に決める
向いているタスク	手順が予測可能なもの	何を求められるか事前にわからないもの
信頼性	高い	低め（柔軟性と引き換え）
テストのしやすさ	各ステップを個別にテストできる	どの手順を踏むか予測しにくい

ワークフローは4つの主要パターンに分類できる。

パターン1：並列化ワークフロー

複数の独立した処理を同時に走らせて、最後に結果をまとめる。

どんな問題を解決するか

たとえば、素材選定システムを作るとする。アップロードされた部品の画像から、金属・ポリマー・セラミック・複合材など6種類の素材のどれが最適かをClaudeに選ばせたい。

1つのプロンプトで「6種類すべてを比較して最適な素材を選べ」と指示するのは難しい。Claudeが複数の基準を同時に処理しようとして、分析が粗くなる。

並列化の仕組み

同じ画像を6回送る
  ├─ リクエスト①：金属の基準で評価
  ├─ リクエスト②：ポリマーの基準で評価
  ├─ リクエスト③：セラミックの基準で評価
  ├─ リクエスト④：複合材の基準で評価
  ├─ リクエスト⑤：弾性体の基準で評価
  └─ リクエスト⑥：木材の基準で評価
          ↓
   6つの評価結果を集約
          ↓
   最適な素材を選定（最終リクエスト）

各リクエストは1種類の素材に特化したプロンプトを持つ。「この部品を金属として使った場合の適性を評価せよ」という、焦点が絞られた問いになる。

なぜこれが効くか

Claudeは1つの評価基準だけに集中できる
各リクエストのプロンプトを独立して改善できる
新しい素材カテゴリを追加するとき、既存のプロンプトに影響しない
リクエストを同時に送れるため、逐次処理より速い

ポイント： 並列化の各サブタスクは同一でなくていい。それぞれ異なるプロンプト・ツール・評価基準を持てる。重要なのは「独立して実行できること」。

パターン2：直列（チェーニング）ワークフロー

複数の処理を順番につなげて、前の出力を次の入力に使う。

どんな問題を解決するか

SNS向け動画スクリプトを自動生成するツールを作るとする。ユーザーがトピックを入力してから動画が投稿されるまでに、複数のステップが必要になる。

トレンドトピックを検索
      ↓
最も面白いトピックを選択（Claude）
      ↓
トピックをリサーチ（Claude）
      ↓
動画スクリプトを執筆（Claude）
      ↓
AIアバター + 音声合成で動画を生成
      ↓
SNSに投稿

各Claudeの呼び出しは前のステップの出力を受け取り、次のステップに渡す。

長いプロンプト問題の解決

チェーニングがとくに効力を発揮するのが「制約の多いコンテンツ生成」の場面。

たとえば、技術記事を生成するプロンプトに「AIが書いたと書かない」「絵文字を使わない」「砕けた表現を避ける」などの制約を大量に入れると、Claudeはどれかを守り忘れることがある。

チェーニングで解決するなら2ステップに分ける。

ステップ1： 制約なしで記事を生成する（多少ルール違反があってもよい）

ステップ2： 生成した記事を渡して「修正専用のリクエスト」を送る

修正してください：
1. AIが書いたことに言及している箇所を削除
2. 絵文字をすべて削除
3. カジュアルすぎる表現をテクニカルライターらしい文体に変更

ステップ2のClaudeは修正だけに集中できるため、長いプロンプトを渡すより精度が上がる。

パターン3：評価ループ（Evaluator-Optimizer）

生成 → 評価 → フィードバック → 再生成のサイクルを回す。

仕組み

入力
  ↓
生産者（Producer）：成果物を生成（Claude）
  ↓
評価者（Grader）：基準に照らして評価（Claude）
  ↓ NG
フィードバック → 生産者に戻す
  ↓ OK
出力

具体例：CADモデリング

部品の画像からCADファイルを生成するワークフローを想定する。

画像をClaudeに渡し、部品の形状を言語で説明させる
説明をもとに、CadQueryライブラリを使ってモデルをコーディングさせる
レンダリングを生成する
レンダリングと元画像を比較してClaudeに評価させる
問題があればフィードバックを返して②に戻す
問題がなければ出力する

ステップ4が「評価者」の役割。自分が作ったものを自分では評価させず、独立したインスタンスに評価させるのがポイント。

注意点

評価ループは出力が評価基準を満たすまでループし続けるため、終了条件を明確に設計する必要がある。最大試行回数を設けないと、無限ループに近い状態になる可能性がある。

パターン4：ルーティングワークフロー

入力を分類して、カテゴリに対応した専用パイプラインに振り分ける。

どんな問題を解決するか

SNS動画スクリプト生成ツールに戻ろう。「プログラミング入門」というトピックと「サーフィン」というトピックでは、最適なスクリプトのトーンが全く異なる。プログラミングなら教育コンテンツ風、サーフィンならエンターテイメント風が適している。

汎用プロンプト1本でどちらにも対応しようとすると、どちらも中途半端になる。

ルーティングの仕組み

ユーザーのトピック入力
      ↓
ルーター（Claude）：カテゴリを判定
  - Educational
  - Entertainment
  - Comedy
  - Personal vlog
  - Reviews
  - Storytelling
      ↓
カテゴリに対応する専用プロンプトを選択
      ↓
専用プロンプトでスクリプト生成（Claude）

重要： ルーティングでは入力は1つのパイプラインだけに送られる。並列化（全員に送る）とは逆の発想。

ルーターとしてのClaudeの信頼性

分類ステップにClaudeを使うとき、カテゴリの定義が曖昧だと誤分類が増える。各カテゴリを明確に定義し、few-shotで例を示すと精度が上がる。分類ステップ自体をEvalで測定しておくと安心。

4パターンの使い分け

パターン	向いているケース
並列化	複数の独立した評価を同時に行いたい
直列（チェーニング）	タスクを順番に積み上げる必要がある、長い制約リストを処理したい
評価ループ	一定の品質基準を満たすまで繰り返し改善したい
ルーティング	入力の種類によって処理を分けたい

これらのパターンは組み合わせて使える。たとえば「ルーティングで入力を分類 → 各パイプラインで直列処理 → 評価ループで品質チェック」というような複合設計も可能。

📋 試験ガイドより
公式試験ガイドのDomain 1（Agentic Architecture & Orchestration）では「Multi-agent orchestration: Coordinator-subagent patterns, task decomposition, parallel subagent execution, iterative refinement loops」が明示的にIn-Scope Topicsとして記載されている。また、テクノロジー一覧には「Prompt chaining — Sequential task decomposition into focused passes」も含まれており、ワークフローパターンの使い分けが設計判断力として問われる。

よくある誤解まとめ

誤解	実際
ワークフローはエージェントの劣化版	ワークフローは信頼性・テストのしやすさで優れている。プロダクション環境ではワークフローを優先する
並列化すれば常に速くなる	並列化の目的は速度だけでなく「集中した評価」にある。独立性がない処理に適用しても効果は薄い
チェーニングは手間が増えるだけ	制約の多い生成タスクや長いプロンプト問題はチェーニングで精度が上がる。1回で済ませようとすると品質が下がる
評価ループはいつでも使える	終了条件（最大試行回数など）を設定しないと無限ループになるリスクがある
ルーティングは並列化の変種	ルーティングは「1つのパイプラインだけに送る」設計。全パイプラインに送る並列化とは逆の発想
ワークフローは1つだけ選ぶ	複数のパターンを組み合わせて設計できる（例：ルーティング → チェーニング → 評価ループ）

設計の判断基準

場面	やりがちな選択	正しい選択	判断の根拠
複数の素材を比較評価したい	1つのプロンプトに全基準を詰め込む	素材ごとに独立したリクエストを並列で送り最後に集約する	Claudeは複数の基準を同時に処理するより1つに集中した方が精度が高い
制約の多い文章を生成したい	制約をすべてプロンプトに詰め込んで1回で生成する	生成と修正を2ステップに分けてチェーニングする	Claudeは生成と制約遵守を同時に処理するとどちらかを守り忘れる
生成物の品質を担保したい	人手で確認する	独立した評価インスタンスにフィードバックさせる評価ループを設ける	生成したインスタンス自身は自分のミスに気づきにくい。独立した評価者を設けることで品質が上がる
入力の種類によって処理を変えたい	汎用プロンプト1本でカバーしようとする	ルーターで入力を分類して専用パイプラインに振り分ける	汎用プロンプトは「どちらにも中途半端」になる。専用化することで各カテゴリの精度が上がる

まとめ

ワークフローは「手順が事前にわかるタスク」に使う。信頼性が高くテストしやすい
並列化：複数の独立した評価を同時に走らせて最後に集約する
チェーニング：処理を順番につなげる。制約の多い生成タスクや長いプロンプト問題に効く
評価ループ：生産 → 評価 → フィードバックのサイクルで品質を担保する。終了条件の設計が重要
ルーティング：入力を分類して専用パイプラインに振り分ける。全員に送る並列化とは逆の設計
4パターンは組み合わせて使える

次回はエージェントの設計——ツールの抽象化・環境観察・ワークフローとの使い分けを解説する。

← #10：Tool Useの応用——複数ツールの管理と組み込みツール｜ #12：エージェントの設計——ツール抽象化・環境観察・ワークフローとの使い分け →