並列化

課題

独立したサブタスクを順次実行すると時間が無駄になり、また、難易度の高いタスクを1回だけ試行した結果は信頼性に欠ける場合があります。

適用対象

サブタスクが独立している場合（セクショニング）、または同じタスクを複数回試行することで確信度やカバレッジが向上する場合（ボーティング）に、並列化を使用します。

解決策

非推奨のケース

• サブタスクが互いの出力に依存している場合（この場合はチェーニングを行います）。
• コストに余裕がなく、1回の呼び出しで十分な場合。
• 結果を有意義に集約できない場合。

テクノロジー

事例

• 多数のドキュメントを一度に要約し、その後、要約をマージする。
• メインの応答と並行して安全性チェックを実行する。
• 回答を複数回サンプリングし、多数決をとる。

KPI

順次実行と比較したレイテンシ削減率

呼び出しを並行して実行することで節約される実時間。このパターンの本質です。

集約品質

並列出力をマージしても正確性が維持されるかどうか。難しいのはファンアウトではなく、結合（ジョイン）の部分です。

並行実行コスト

すべての並列ブランチにおける総トークン数。速度と引き換えにコストを支払うことになるため、倍率に注意してください。

レート制限 / スロットリング発生率

並列呼び出しがプロバイダーのレート制限に達する頻度。制限に達すると、暗黙的に順次実行に切り替わるか、呼び出しが失敗します。

観察された失敗パターン

• 集約エラー：個々の並列結果は正しいものの、結合方法が誤っている（二重カウント、矛盾など）。
• レート制限により、意図した並列処理が低速な順次呼び出しに戻ってしまう。
• 予期せぬコスト：1つの結果しか使用しない場合でも、N個の並列ブランチにはN倍のコストがかかります。
• 部分的な失敗の処理：1つのブランチが失敗した際に、アグリゲーターが処理をブロックするか、あるいはエラーを暗黙的に無視してドロップしてしまう。

得られた教訓

• 最初に集約ステップを設計してください。作業を分割することよりも、結果を適切に結合することの方が困難です。
• バッチ処理やバックオフを使用してプロバイダーのレート制限を遵守してください。さもないと、並列処理のメリットが失われます。
• 独立したサブタスクのみを並列化してください。依存関係がある場合は、いずれにせよ順次実行せざるを得なくなります。
• 本番環境で発生する前に、部分的な失敗をどのように処理するかを明示的に決定しておいてください。

FAQ

セクショニングとボーティングの違いは何ですか？

セクショニングは1つのタスクを異なる独立したサブタスクに分割します。ボーティングは、信頼性を高めるために同じタスクを複数回実行して集約します。

ボーティングを行えば、常に品質が向上しますか？

試行結果にばらつきが生じるタスクでは向上することが多いですが、コストが倍増します。1回の試行ではリスクが伴う、極めて重要なステップに限定して使用してください。

並列処理の結果はどのように結合すればよいですか？

ユースケースに応じて、セクションを結合する、多数決をとる、検出結果の和集合をとる、または判定モデルを使用して統合します。

参考文献

• Anthropic — Building Effective Agents (2024)

関連パターン