【ITニュース解説】I Kept Rebuilding LLM Provider Setup - So I Built a Small Go Gateway

AI機能をアプリケーションに組み込む際、多くの開発者は本質的ではない繰り返し作業に直面する。これは、革新的なAIのアイデアを思いつき、その機能がユーザーに本当に役立つのかを検証しようとする段階で特に顕著になる問題だ。具体的には、どのAIプロバイダーの認証キーを使えばよいのかを探したり、利用したいモデルの名前がまだ有効かを確認したり、ストリーミング形式と非ストリーミング形式の応答の違いを比較したり、あるいはアプリケーションをデプロイした環境からAIプロバイダーに接続できるかを確認したりする作業がこれにあたる。これらの作業自体は決して難しいものではないが、本来の目的である「ユーザーに価値を提供する機能の検証」から開発者の注意を逸らし、エネルギーを消耗させてしまう。開発者は、何度も同じような設定作業を繰り返すことにストレスを感じる。

このような繰り返しの摩擦を解消するため、「Go-Ai」という小さなHTTPゲートウェイが開発された。Go-Aiは、アプリケーションのバックエンドがAIプロバイダーに直接リクエストを送る代わりに、Go-Aiにチャットの完了リクエストを送信する。これにより、Go-AiがAIプロバイダー側の詳細な処理、例えば認証情報の管理やモデル名の解決、複数のプロバイダー間の差異の吸収といった複雑な部分をまとめて引き受ける。アプリケーション開発者は、Go-Aiという安定した窓口を通して、安心してAI機能を利用できるようになる。このゲートウェイは、汎用的なAIプラットフォームや、高度なエージェント機能、あるいはアプリケーションそのものを代替するものではなく、あくまでアプリケーションとAIプロバイダーの間に立つ、明確に限定された役割を持つ。

Go-Aiの開発は、Go言語の学習機会としても活用された。長年その良さを耳にしながらも、本格的に取り組むきっかけがなかったGo言語を、HTTP通信、設定管理、ストリーミング処理、そして明確なエラー処理を持つコンパクトなサービスとして構築することで、実用的な問題解決を通して学ぶことができた。これはGo言語が他の選択肢よりも優れているという主張ではなく、この特定の課題を解決する上で実用的な選択だった。

具体的な開発現場での課題として、チャット、ストリーミング、音声といった機能を製品に組み込むたびに、どの認証キーをどの環境で使うか、アプリケーションのサーバーがAIプロバイダーに接続できるか、以前使っていたモデル名がまだ有効か、といった確認作業が繰り返し発生していた。機能そのものの開発はそれほど難しくなかったのに、その周囲の設定が常に開発の障壁となっていた。アプリケーションが求めていたのは、AIモデルに質問を投げかけ、時にはストリーミングで回答を受け取り、そして特定のプロバイダーに縛られないモデル名で利用できることだった。

最初は一つのアプリケーションだけでAI機能を使う場合、AIプロバイダーが提供するSDK（開発キット）を直接使う方法で問題ないことが多い。しかし、複数のアプリケーションでAIを利用するようになると、認証情報を安全に管理する場所が必要になり、AIプロバイダー側のモデル名が変更された際に複数のアプリケーションのコードを修正する必要が生じたり、デプロイ環境や地域によってプロバイダーの利用可否が変わったりといった問題が浮上する。新しいアプリケーションを開発するたびに、これらの制約を個別に解決するのは非効率である。Go-Aiを導入する前は、各アプリケーションがそれぞれプロバイダーの設定を抱えていたが、Go-Aiの導入後は、プロバイダーに関する懸念がGo-Aiという一つの場所に集約され、アプリケーションは本来の製品機能の開発に集中できるようになった。

この領域にはLiteLLM、LangChain、Vercel AI SDKなど、すでに強力なソリューションが存在する。これらのツールは幅広い機能や複雑な連携が必要な場合には非常に有効であり、そのような要件がある際には積極的に利用するべきである。しかし、Go-Aiはそれら全てを置き換えることを目指しているわけではない。Go-Aiは、より広範なフレームワークやゲートウェイを学ぶよりも、必要な機能に絞り込み、リクエストからレスポンスまで一連の流れを追跡しやすく、自身のアプリケーションの隣に手軽にデプロイできるサービスを目指した。

Go-Aiが適さないケースも明確に定義されている。例えば、一つのアプリケーションで一つのAIプロバイダーのみを利用し、そのプロバイダーのSDKで十分な場合。あるいは、ゲートウェイ側で高度なエージェントの実行環境、ツール実行機能、記憶機能、RAG（検索拡張生成）パイプラインが必要な場合。さらに、マネージドサービス（SaaS）、管理ダッシュボード、課金システムといった機能が必要な場合も、Go-Aiは適切な選択肢ではない。Go-Aiはあくまで、開発者が自分で運用する小さなサービスである。

Go-Aiは、アプリケーションのバックエンドからOpenAI互換のチャットリクエストを受け取る。この際、アプリケーションはAIプロバイダー固有のモデル名ではなく、Go-Ai内部で定義された「ローカルエイリアス」を使ってモデルを指定する。Go-Aiはそのエイリアスを解決し、実際のリクエストを適切なAIプロバイダーに転送する。これにより、プロバイダーの認証情報はGo-Aiというサーバーサイドの一箇所に集約され、AIプロバイダー側のモデル名が変更されても、アプリケーション側のコードを大幅に修正する必要がなくなる。アプリケーションは、ユーザーのセッション管理、入力値の検証、リクエスト数の制限、データベースアクセス、そして応答形式の決定といった、本来の責務に集中できる。音声機能についても同様の原則が適用され、音声認識（Speech-to-text）と音声合成（Text-to-speech）はそれぞれ独立したプロキシルートとして提供される。アプリケーションが、チャットの応答を音声で出力するかどうかを決定するのであり、Go-Aiがチャットをリアルタイム音声に自動的に変換するような機能は持たない。

ツール呼び出し機能の扱いも、Go-Aiの設計思想をよく表している。Go-AiはOpenAI互換のツール関連ペイロードをそのままAIプロバイダーとアプリケーション間で透過的に通過させるが、ツールそのものの実行は行わない。なぜなら、ツールを実行する際に必要となるユーザー情報、そのユーザーが許可されている操作、アクセス可能なデータ範囲、そしてその操作が引き起こすシステムへの影響といった文脈（コンテキスト）は、呼び出し元のアプリケーションが最もよく理解しているからである。ゲートウェイはプロバイダー側の詳細を扱い、アプリケーションがビジネス上の判断や承認に必要なコンテキストを保持するという明確な境界が存在する。実際には、アプリケーションがツール呼び出しの指示を受け取ると、ユーザーと引数を検証し、自身の信頼されたシステムに対して作業を実行し、その結果をAIに返すという流れになる。また、プロバイダーの認証情報やシークレットは、必ず信頼されたサーバー側の設定として保持され、ユーザーのブラウザから直接Go-Aiゲートウェイに接続されることはない。

Go-AiはGitHubで公開されているプロジェクトであり、ホストされた製品ではない。既存のバックエンドアプリケーションの隣で実行し、その小さな境界が自身のプロジェクトに役立つかどうかを試すことができる。Docker Composeを利用すれば、簡単にGo-Aiを起動できる。提供されている環境変数の例をコピーし、自身のシークレットと必要なAIプロバイダーのキーを設定するだけで、手軽に試用を開始できる。認証情報などの重要なデータは、バージョン管理システムには決して含めてはならない。

このGo-Aiを開発する過程で、意図的に実装しなかった機能も明確にされている。これには、エージェントの実行環境、ツール実行機能、記憶管理、RAGパイプライン、永続的な状態の保存、広範な耐障害性システム（サーキットブレーカーやリトライ機能など）、そして完全なOpenAI APIの模倣、管理ダッシュボード、課金レイヤーなどが含まれる。これらの機能がないことは、それらが重要ではないということではなく、「スコープの規律」を示している。将来的に、もしアプリケーションがより高度なオーケストレーションや、豊富なクライアントSDK、課金機能、広範なプロバイダー管理を必要とするようになった場合、Go-Aiを無理に拡張するのではなく、その目的に合った別のツールを選択すべきであるという考えに基づいている。

このプロジェクトから得られた最も大きな成果は、次のプロジェクトでAIプロバイダーの設定に関する判断を繰り返す必要がなくなったことである。Go-Aiという一つのサービス境界と、プロバイダー側の認証情報を管理する一箇所ができたことで、複数のコードベースに分散していた設定作業が不要になった。また、Go言語の学習においても、HTTPエラーの適切な処理方法、ストリーミングの維持方法、状態をローカルに保持するべき場所、そして責任を曖昧にしない方法など、実践的な知識を身につける良い機会となった。Go-Aiの今後の焦点は、安易に機能を追加することではなく、その明確な境界を信頼性の高い状態に保ち、ドキュメントを分かりやすく整備することである。そして、この小さな形が適切でなくなるようなケースから学び、必要に応じて改善していくことが目指されている。