【ITニュース解説】Day 23: LLM Manager Service Layer Refactor - Consolidating Multi-Model AI Integration

Day 23では、大規模言語モデル（LLM）を管理するサービスのコードを根本的に改善する作業に集中的に取り組んだ。これは「リファクタリング」と呼ばれるもので、プログラムの機能を変更せずに、その内部構造を改善し、将来の変更や保守を容易にすることを目的としている。この日の作業は、複数のAIモデルを統合する際の課題を解決し、今後の開発のための強固な基盤を築く上で非常に重要だった。

これまでの開発では、22日間という短い期間で機能を次々と追加していった結果、「技術的負債」が大きく積み重なっていた。技術的負債とは、急いで開発を進めるために、一時しのぎのコードを書いたり、将来的な拡張性を考慮しなかったりすることで、後になってシステムの変更や機能追加が困難になる問題である。具体的には、LLMを呼び出すためのコードが、元の実装、簡略版、そして一部だけEffect-TSという新しい技術を使ったもの、さらにはUI関連のコード内にも重複して存在し、3種類以上の方法でLLMが呼ばれる状態だった。その結果、特定のAIモデル（GPTやClaude）へのルーティング機能が壊れており、ローカルモデルしか正しく動作しなかった。さらに、システム全体の統合テストでは、応答に25秒以上もかかり、タイムアウトしてしまうという深刻なパフォーマンス問題も抱えていた。

このパフォーマンス問題への対応は、朝から始まった。統合テストが25秒以上かかる原因を調査したところ、AIに与える指示文、つまり「プロンプト」が非常に長くなっていたことが判明した。診断用の情報をAIに生成させる際のプロンプトは、9,000文字以上にも及ぶ詳細な指示を含んでいた。この冗長なプロンプトは、AIが情報を処理する時間を大幅に増やし、結果としてシステムの応答を遅らせていたのである。

この問題の解決策は、プロンプトを大幅に簡素化することだった。長すぎる指示を削り、AIに本当に必要な情報と、具体的な出力形式だけを伝えるように修正した。例えば、以前は過剰に詳細なSQL生成のルールを記述していたが、修正後は「OpenTelemetryトレース用のClickHouse SQLを生成する」「エラーや高レイテンシーに焦点を当てる」「生のSQLのみで、マークダウンは不要」といった、短く明確な指示に絞り込んだ。この「プロンプト最適化」と呼ばれる改善によって、システムの応答時間は25秒以上からわずか2〜3秒へと劇的に短縮され、非常に大きな効果を上げた。プロンプトの長さや内容がAIモデルのパフォーマンスと品質に直接影響を与えるという重要な教訓が得られた瞬間だった。

午後は、この日の主要な成果である、LLM関連のコードを一つの統一された「サービスレイヤー」に統合する作業、つまりリファクタリングに費やされた。以前は、LLMを管理するコードがさまざまな場所に散らばっており、それぞれが異なる設定方法、エラーの扱い方、モデルの選択ロジック、そして外部APIとの通信方法を持っていた。これでは、新しい機能を追加したり、既存のバグを修正したりするのが非常に困難だった。コードが複雑で理解しにくく、メンテナンスも大変な「スパゲッティコード」に近い状態と言える。

この課題を解決するために採用されたのが、「Effect-TS」という技術を使った「Layerアーキテクチャ」である。Effect-TSは、TypeScriptというプログラミング言語で、並行処理やエラー処理、そして依存性注入といった複雑な処理を、型安全かつ構造的に記述するための強力なツールである。Layerアーキテクチャは、システムを構成する各部品（サービス）が、他の部品にどのように依存しているかを明確にし、それらの依存関係を外部から「注入」する「依存性注入（Dependency Injection）」という設計パターンを効果的に実現する。これにより、各サービスが独立性を保ちながら機能し、テストの際に実際のサービスを、動作をシミュレートする「モック」に簡単に置き換えることが可能になる。

具体的には、LLMマネージャー全体がEffect-TSのLayerとして再構築された。これにより、AIモデルを選び、実行し、結果を検証するといった一連の処理が、統一されたEffect-TSのパターンで記述された。例えば、複数のAIモデルに対して並行して分析を依頼し、その結果を統合するといった複雑なワークフローも、Effect-TSの強力な機能（並行処理、タイムアウト、リトライ、エラーハンドリング）を使って、簡潔で信頼性の高いコードで実装できるようになった。

このサービスレイヤーの統合によって、いくつかの重要な成果が達成された。まず、約800行ものコードが削除され、およそ50%の重複が解消されたことで、コードベースが大幅に簡素化された。以前は動作しなかった複数のAIモデルへのルーティング機能も修正され、すべてのモデルが適切に選択されるようになった。Effect-TSによって、予測不能なAIの応答に対するタイムアウト処理や、ネットワークエラー時のリトライ処理、そして構造化されたエラーハンドリングが実装され、システムの信頼性が向上した。さらに、TypeScriptの型安全性が向上し、コンパイルエラーが解消されたほか、Layerアーキテクチャのおかげで、モック（模擬的な代替部品）を使ったテストが容易になり、179個中178個のテストが安定して合格するようになった。

夕方には、将来のテスト戦略を文書化するための「ADR-015」という記録が作成された。ADR（Architectural Decision Record）は、システムの設計に関する重要な決定とその理由を記録する文書である。この文書では、AIシステムのテストには、実行速度や精度、コストのバランスを考慮した多段階のアプローチが必要であると提案された。また、この日の作業を通じて、AIの診断機能を検証するための新しいテストスイートが6つ追加された。これらのテストは、UIからAIへのクエリ生成、そしてその実行に至るまで、診断パイプライン全体の検証を目的としている。

さらに、システムの継続的インテグレーション・継続的デプロイメント（CI/CD）パイプラインで問題となっていた、LLMマネージャー部分の低いテストカバレッジも改善された。テストカバレッジとは、テストによって実行されるコードの割合を示す指標である。以前はほぼ0%だったカバレッジが、この日の作業で42.33%まで大幅に向上し、合計39個の新しい単体テストが追加された。これらのテストは、設定管理、モデルのメタデータ追跡、APIクライアントの動作、そしてインテリジェントなモデル選択ロジックといった主要な機能に焦点を当てていた。

この日の開発を通じて、いくつかの重要な教訓が得られた。一つは「イノベーションの前に統合を」というものだ。AIシステムでは、技術的負債が非常に速いペースで蓄積されるため、新しい機能を追加する前に、既存のコードの重複を解消し、構造を統一することが、複雑さを減らし、隠れたバグを修正し、パフォーマンスを改善する上で不可欠であると再認識した。二つ目は、Effect-TSのLayerパターンがAIシステムのオーケストレーション（複数の処理の連携と管理）に非常に有効であるという点だ。このパターンは、型安全性、タイムアウト処理、構造化されたエラー管理を提供し、複雑なAIワークフローをエレガントに記述することを可能にする。三つ目は、AIシステムのテストには、速度、精度、コストのバランスをとるための複数の戦略が必要であること。そして最後に、プロンプトの最適化がパフォーマンスに絶大な影響を与えるという事実だ。冗長な指示は応答速度を低下させるだけでなく、AIの出力品質にも悪影響を及ぼす。

Day 23の作業の結果、プロジェクトは30日間の開発期間のうち78%が完了し、最終週を非常に良い技術的な状態で迎えられることになった。LLM統合アーキテクチャは統一され、応答時間は3秒未満に短縮され、包括的なテスト戦略が確立され、ほとんどすべてのテストが安定して合格するようになった。LLMマネージャーのテストカバレッジも目標を大幅に上回った。この日の作業は、新機能の追加ではなく、アーキテクチャの改善に焦点を当てることで、今後の開発の安定性と効率性を大きく高めるものだった。最終週は、本番環境へのデプロイ自動化、パフォーマンス監視の統合、ドキュメント作成、そしてデモの準備に集中する予定である。

AIシステム開発における重要なポイントは、技術的負債を早期に解消し、Effect-TSのLayerのような堅牢なパターンを用いて依存性を管理し、戦略的にテストを計画・実行し、プロンプトを常に最適化し、そしてシステムのあらゆる側面を継続的に監視することである。これらは、安定した高品質なAIシステムを構築するために不可欠な要素だ。