現在のOpenRouterを用いた独自のAI実装を、よりメンテナンス性が高く多機能なLLM統合ライブラリ(特に echo-labs/prism)へリプレースするかどうかを検討します。
背景
現状は OpenRouterClient を自前で実装し、JSONのパースやリトライロジックを手動で管理しています。
特に評価機能(AIEvaluationService)では、全コードの半分以上がJSONのデコードや修復ロジックに割かれており、保守コストが高い状態です。
リプレースのメリット
- 構造化出力(Structured Output)の簡素化: Schema定義のみでバリデーション済みのオブジェクトを取得可能になり、複雑なパース/修復ロジックを廃止できます。
- ストリーミング対応: 対戦相手のAIの応答を逐次表示(タイピングエフェクト)することが容易になり、UXが向上します。
- ツール利用(Tool Calling): 将来的にAIが動的にデータを検索したり、特定のロジックを実行したりする拡張が容易になります。
- プロバイダーの柔軟性: OpenRouter以外のプロバイダー(Azure OpenAI, AWS Bedrock等)への切り替えが抽象化されます。
移行ロードマップ(案)
- フェーズ1: 論題提案機能(
TopicGeneratorService)の移行(低リスク・高恩恵)
- フェーズ2: ディベート対戦機能(
AIService)の移行とストリーミング対応(UX向上)
- フェーズ3: 判定機能(
AIEvaluationService)の移行(コードの大幅削減)
概算工数
- 3〜5人日程度(逐次表示、プロンプト調整、テスト修正込み)
本件は技術的負債の解消と将来的な拡張性(AI Agent化等)を目的とした検討タスクです。
現在のOpenRouterを用いた独自のAI実装を、よりメンテナンス性が高く多機能なLLM統合ライブラリ(特に
echo-labs/prism)へリプレースするかどうかを検討します。背景
現状は
OpenRouterClientを自前で実装し、JSONのパースやリトライロジックを手動で管理しています。特に評価機能(
AIEvaluationService)では、全コードの半分以上がJSONのデコードや修復ロジックに割かれており、保守コストが高い状態です。リプレースのメリット
移行ロードマップ(案)
TopicGeneratorService)の移行(低リスク・高恩恵)AIService)の移行とストリーミング対応(UX向上)AIEvaluationService)の移行(コードの大幅削減)概算工数
本件は技術的負債の解消と将来的な拡張性(AI Agent化等)を目的とした検討タスクです。