LLM レスポンスハンドリングにおける Chain of Responsibility パターン

バヴコード（vibe coding）プラットフォームの開発を始めた際、LLM とのワークを行うためのライブラリである Mozaik を開発しました。すぐに複数の LLM プロバイダーへの対応が必要となり、それぞれのリクエストとレスポンス形式の違いに直面しました。コードの散漫さを避けるために、LLM から返ってくる異なるレスポンスを処理する際に Chain of Responsibility パターンを採用しました。 代替分岐ロジックではなく、各レスポンスは小さなハンドラたちのチェーンを流れを通じて処理されます。各ハンドラは単一の事項を確認し（構造化された出力、ツール呼び出し、テキスト、空のレスポンスなど）、そのものごとを処理するか、または次の段階へ転送します。 これにより、レスポンス処理が明示的かつ組み可能になります： 各ハンドラは単一責任を持つ ハンドラは隔離して容易にテスト可能 既存のロジックに触れずに新しいレスポンスタイプを追加可能 構造化された出力検証は、特別なケースではなくチェーン内の単なるハンドラです。

While building a vibe coding platform, I started building Mozaik, a library for working with LLMs. Very soon, a need emerged to handle multiple LLM providers - and with that, different request and response formats. To avoid messy code, I applied the Chain of Responsibility design pattern to handle the different responses coming back from an LLM. Instead of branching logic, each response flows through a chain of small handlers. Each handler checks one thing (structured output, tool call, plain text, empty response) and either handles it or forwards it. This keeps response handling explicit and composable: each handler has a single responsibility handlers are easy to test in isolation new response types can be added without touching existing logic Structured output validation is just another handler in the chain, not a special case.