【ITニュース解説】Removing 11,005 Lines: Why We Replaced Our Custom LLM Manager with Portkey

あるプロジェクトで、大規模言語モデル（LLM）と呼ばれるAI、具体的にはChatGPTのような対話型AIをシステムに組み込む際の経験が語られている。このプロジェクトでは、AIを活用した「観測プラットフォーム」を開発しており、複数の異なるLLMプロバイダー（例えばOpenAIのGPTシリーズ、AnthropicのClaude、あるいは自社で動かすローカルモデルなど）と連携する必要があった。

当初、開発チームは、この複数のLLMとのやり取りを効率的に管理するため、「カスタムLLMマネージャー」という独自のソフトウェアを自社で開発した。このマネージャーには、どのLLMを使うかを選んだり（プロバイダーのルーティング）、それぞれのLLMから返ってくる情報の形式を統一したり（レスポンスの正規化）、エラーが起きたときの処理や、通信が混雑したときに自動で再試行する仕組み（リトライロジック）、さらにはシステムの状態を監視する機能（オブザーバビリティ）などが含まれていた。

しかし、このカスタムLLMマネージャーは、想像以上に複雑なものとなっていった。各LLMプロバイダーごとに異なる接続方法やデータの形式に対応するための個別のコードが必要になり、エラー処理や再試行、通信制限（レートリミット）への対応、システム障害時の自動切り替え（サーキットブレーカー）など、さまざまな機能を自作しなければならなかった。結果として、このマネージャーのコードは合計で膨大な量に膨れ上がり、その保守と管理がチームにとって大きな負担となっていた。特定のモデルを選択するロジックや、失敗した処理を指数関数的に待ち時間を延ばして再試行するロジックなど、高度な機能も自作しており、テストも非常に複雑になっていたのである。

そこでチームは、この状況を改善するために、「Portkey」という外部の専門ツールを導入することを決断した。Portkeyは、LLMとの連携に必要な上記の複雑な機能を、すでに全て備えている「LLMゲートウェイ」と呼ばれる種類のソフトウェアである。ゲートウェイとは、システムと外部サービス（この場合はLLMプロバイダー）の間の交通整理役のようなもので、さまざまな接続の複雑さを一手に引き受けてくれる。

Portkeyの導入は非常にスムーズで、わずか1日で完了したという。それまで自作していた数千行の複雑なコードが、Portkeyへのシンプルな呼び出しに置き換えられた。例えば、システムからPortkeyに対して「このLLMを使って、この内容で生成してほしい」と一度指示を出すだけで、Portkeyが裏で適切なLLMプロバイダーを選び、通信し、結果を統一された形式で返してくれるようになった。PortkeyはDockerという技術を使って簡単に動かすことができ、HTTPヘッダーに少し情報を加えるだけで、どのLLMを使うかをPortkeyに指示できるようになった。また、異なるLLMから返されるレスポンスの形式も、Portkeyが全てOpenAIが定める統一された形式に変換してくれるため、システムの他の部分は形式の違いを意識する必要がなくなった。

この変更によって、開発プロセスにも大きな改善が見られた。それまで各LLMプロバイダーの特性を模擬するのに複雑なテストコードを書いていたが、Portkeyを導入した後は、Portkeyへのシンプルな通信を模擬するだけで良くなったため、テストの複雑性が70%も削減された。これにより、より広範囲で信頼性の高いテストが実施できるようになり、以前はスキップされていた統合テストも全て実行できるようになった。

さらに、Portkeyの導入は運用面でも多くのメリットをもたらした。Portkeyには、LLMへのリクエストやレスポンスの履歴、処理にかかった時間、発生したエラーなどを自動的に記録・監視する機能が組み込まれており、システムの状況を把握しやすくなった。また、自動での再試行や、LLMサービスが一時的に停止した場合に別のサービスに切り替えるサーキットブレーカー機能、コストの追跡、同じリクエストに対する応答を一時的に保存して再利用するキャッシュ機能なども提供され、システムの信頼性とパフォーマンスが大幅に向上した。実際、LLMからの応答速度（レイテンシ）は平均で38%改善し、エラー率は65%も削減された。

この経験からチームはいくつかの重要な教訓を得た。一つは、「インフラストラクチャは差別化要因ではない」ということである。LLMとの連携を管理するゲートウェイのような部分は、あくまでシステムを動かすための「配管」のようなものであり、そのシステムが提供する独自の価値（例：AIによる異常検知やダッシュボード生成）とは異なる。そのため、このような基盤となる部分は、自作するのではなく、Portkeyのようなすでに成熟していて信頼性の高い外部ツールを利用するべきだと学んだ。

二つ目の教訓は、「コードの削減自体が大きな機能改善である」という点だ。今回の移行で11,005行ものコードが削除され、正味で5,348行のコードが減った。これにより、開発者が覚えなければならないコードの量が減り、システムの保守作業が楽になり、新しいメンバーがプロジェクトに参加した際の学習コストも下がった。結果として、新しい機能をより早く開発・リリースできるようになった。

三つ目の教訓は、「成熟した外部ツールを使うことで、よりイノベーションに集中できる」ことだ。PortkeyがLLMとの基本的な連携部分を全て引き受けてくれるようになったことで、開発チームはAIの能力を最大限に引き出すためのより高度な技術（プロンプトの工夫や複数のAIモデルの組み合わせなど）に集中できるようになった。

最終的に、このプロジェクトでは11,005行のコードが削除され、関連するファイルの47個が消滅し、テストの複雑性は70%も減った。ビルド時間やDockerイメージのサイズも大幅に削減され、多くの不要なソフトウェアパッケージも削除された。Portkeyを導入した後のLLM連携に関するコードはわずか473行となり、元々のコード量から95%もの削減を達成した。

この経験は、「作るべきか、買うべきか」というエンジニアリングにおける重要な判断を示している。コアではないインフラの部分に関しては、Portkeyのような成熟した専門ツールを導入することで、開発の速度と品質を両立させながら、エンジニアリングリソースをより本質的な価値創造に集中できるという結論に至った。削除された11,000行以上のコードは、単なる行数ではなく、将来発生する可能性のあったバグや、メンテナンスの負担、新しい開発者が学ぶべき複雑さそのものが消滅したことを意味している。時には、「何を作らないか」を知ることが、最大の成果を生み出すのである。