【ITニュース解説】Logistics Hiring Scores Using Unified Node Backend Proxy with One API Key and Retries

大規模言語モデル（LLM）の活用が広がる中、これをシステムに組み込む際の設計は非常に重要だ。特に、OpenAIやAnthropic、Google Geminiといった外部のLLMサービスを安全かつ効率的に利用するためには、バックエンドプロキシの適切な設計が鍵となる。この記事では、物流業界の候補者採点システムを例にとり、Node.jsを用いたバックエンドプロキシの設計原則と実装のポイントを解説する。

システムがLLMサービスを利用する際、ブラウザやモバイルアプリなどのクライアントから直接LLMサービスと通信するのは危険が多い。LLMサービスの認証情報（APIキーなど）がクライアントに漏洩するリスクがあるためだ。そこで登場するのがバックエンドプロキシだ。このプロキシは、クライアントからのリクエストを受け取り、裏側で安全にLLMサービスと通信し、その結果をクライアントに返す役割を担う。

プロキシを導入する大きなメリットの一つは、クライアント側から見れば、たった一つのAPIキーと一つの統一されたエンドポイント（通信先URL）で済む点だ。クライアントは、プロキシのAPIキーを使ってプロキシにアクセスするだけでよく、OpenAI、Anthropic Claude、Google Geminiといった各LLMプロバイダー固有の認証情報やエンドポイントについて知る必要はない。これらの機密情報は全てバックエンドサーバー内部で管理され、クライアントからは見えないようにする。これにより、クライアント側の開発は簡素化され、セキュリティも向上する。

候補者採点システムのようなアプリケーションでは、LLMからの応答は単なるテキストではなく、特定の構造を持ったデータである必要がある。例えば、候補者のID、推薦の評価（進める、再検討、見送る）、各評価基準のスコアと根拠を示す証拠などが、決められたJSON形式で返されるべきだ。もしLLMが意図しない形式のデータを返したり、必要な情報が欠けていたりすれば、それは「部分的な成功」ではなく「無効なデータ」として扱われる。このため、プロキシはLLMからの応答を受け取った後、そのデータが事前に定義されたJSONスキーマ（JSONの構造や内容のルールを定義したもの）に厳密に適合しているか検証する必要がある。JSON Schemaのドラフト2020-12のような仕様を使うことで、オブジェクトの形状、必須プロパティ、数値の範囲などを厳密にチェックできる。プロバイダーによっては構造化出力を生成する機能があるが、それでも最終的なアプリケーション側での検証は不可欠だ。不正な出力は不正なものとして扱う。

システムは常に完璧に動作するわけではないため、エラーが発生した場合の適切な処理が求められる。特にLLMサービスとの通信では、一時的なネットワーク障害やレート制限（一定時間内のリクエスト数の上限）といった問題が起こり得る。このような「一時的な失敗」の場合のみ、リクエストを再度試行する（リトライする）べきだ。認証失敗や、LLMが常に無効な出力を返すような根本的な問題に対しては、無闇にリトライしてもコストや遅延が増えるだけで意味がない。リトライする際には、指数バックオフ（失敗するたびに次の試行までの待ち時間を長くする）やジッター（待ち時間に少しランダムな要素を加える）を組み合わせることで、多くのリクエストが同時にリトライしてサービスにさらなる負荷をかけるのを防ぐ。また、個々のリクエストにはエンドツーエンドの処理期限を設定し、その期限内にリトライを収めることで、システム全体の応答遅延を防ぐ必要がある。

アプリケーションコードの中に、OpenAIやAnthropicといった具体的なLLMプロバイダーのモデル名（例：gpt-4-turbo）を直接書くのは避けるべきだ。代わりに、「rubric-strict」や「rubric-fast」のような、提供する能力を表すエイリアス（別名）を用いる。そして、これらのエイリアスが実際にはどのプロバイダーのどのモデルに対応するかは、デプロイ時の設定でマップする。この方法により、例えば「rubric-strict」をより高性能な新しいモデルに切り替えたい場合でも、アプリケーションコードを変更することなく、設定ファイルを変えるだけで対応できるため、運用が非常に柔軟になる。

LLMサービスと連携する実装方法にはいくつか選択肢がある。各LLMプロバイダーが提供するSDK（ソフトウェア開発キット）を直接利用する方法はシンプルに始められるが、複数のプロバイダーを使う場合はそれぞれ異なるコードを書く必要がある。複数のLLMプロバイダーへのアクセスを単一のサービスとして提供してくれる外部のマネージドマルチプロバイダーゲートウェイは、APIキーが一つで済むことが多く、手軽に複数プロバイダーを利用できる。しかし、そのサービスが提供する機能や柔軟性に制約がある場合があるため、構造化された応答を確実に維持できるか、リトライに関する詳細な情報を提供してくれるかを確認する必要がある。完全に自社でプロキシを構築・運用するセルフホステッドルーティングプロキシは、ネットワーク制御や監査要件が厳格な場合に有効だが、パッチ適用、キャパシティ管理、秘密情報の更新、監視など、運用負荷が非常に高くなる。推奨されるのは、毎週のように新機能をリリースするような個人開発のSaaS（Software as a Service）の場合、構造化された応答を確実に維持し、リトライに関するメタデータ（情報）を提供してくれるのであれば、マネージドゲートウェイから始めることだ。そうでなければ、各プロバイダーのSDKを薄い内部アダプターで包み込む形が良い。汎用的なルーターを自前で構築するのは、その運用コストが本業の機能開発を圧迫するため避けるべきだ。交通手段としてのプロキシは外部に任せつつも、候補者の採点基準、スキーマ、検証、監査記録といった、ビジネスの核となる部分は自身でしっかりと管理する必要がある。

環境設定は、システム起動時に一度だけ読み込み、不正な設定があればすぐに失敗させるべきだ。本番環境では、APIキーなどの秘密情報は秘密情報マネージャー（Secret Manager）で安全に管理し、コードリポジトリ（Gitなど）に直接コミットしてはならない。また、ログの記録にも注意が必要だ。候補者の履歴書、プロンプトの内容、生の認証情報、LLMからの完全な応答といった機密情報は、デフォルトではログに残すべきではない。記録すべきは、利用したモデルのエイリアス、バージョン、スキーマのバージョン、応答時間、試行回数、検証結果、トークン使用量、リクエストIDなど、運用上必要な最小限の情報にとどめる。そして、システム変更時には、通常のケースだけでなく、空欄の職務経歴、矛盾した日付、無関係な指示が埋め込まれたレジュメ、不足している採点カテゴリなど、多様な「敵対的ケース」を含む評価セットで厳密なテストを行うことが不可欠だ。

バックエンドプロキシの設計は、一つの一貫したクライアント側の認証情報、明確な能力を表すエイリアス、バージョン管理されたスキーマ、そして明確なエラーカテゴリを核とする、最小限で堅牢な契約を目指すべきだ。この契約の背後にあるLLMプロバイダーやモデルは将来的に変更される可能性があるが、採点基準とそれを受け入れるためのテストは揺るがないものとして維持される。このアプローチにより、開発者はLLM連携の複雑さに囚われることなく、ビジネス価値の提供に集中できるだろう。