ハクソク

世界を動かす技術を、日本語で。

Show HN: GoModel – GoによるオープンソースのAIゲートウェイ

2日前原文(github.com)

概要

GoModelは、Go製の高性能AIゲートウェイ。 OpenAI互換APIで複数プロバイダーを統合管理可能。 Dockerですぐ導入、環境変数ベースのシンプル設定。 キャッシュ機能によるコスト削減と高速化。 セキュリティ・認証も柔軟に対応。

GoModel：AIゲートウェイの全体像

  • Go言語で開発された高性能AIゲートウェイ。
  • OpenAI、Anthropic、Gemini、xAI、Groq、OpenRouter、Z.ai、Azure OpenAI、Oracle、Ollamaなど多数のAIプロバイダーに1つのAPIで対応。
  • OpenAI互換APIでアプリ側の実装変更不要。
  • Dockerイメージは約17MBと超軽量。
  • 環境変数中心の設定で、柔軟かつ簡単に運用。
  • モデル切り替え・プロバイダー追加も容易。

クイックスタート：AIゲートウェイのデプロイ

  • Dockerコマンド一発でGoModelを起動。
    • 例：docker run --rm -p 8080:8080 -e OPENAI_API_KEY="your-openai-key" enterpilot/gomodel
  • 必要なプロバイダーのAPIキーやBASE_URLのみ指定（最低1つ必須）。
  • セキュリティ上の注意点：
    • コマンドラインの-eで秘密情報を渡すのは非推奨。
    • 本番環境では--env-file .envでAPIキーを管理推奨。

API利用例

  • curlコマンドでAPI呼び出し：
    • curl http://localhost:8080/v1/chat/completions ...
  • GoModelは自動で利用可能なプロバイダーを判別。

サポートされるLLMプロバイダーと機能一覧

  • 主要プロバイダーごとにAPIキーまたはBASE_URLを設定。
  • チャット、埋め込み、ファイル、バッチ処理、パススルーなど機能ごとに対応状況を明示。
    • 例：OpenAIは全機能対応、Anthropicは一部機能非対応。
  • 複数インスタンス登録も環境変数のサフィックスで可能。

代替セットアップ方法

  • Go 1.26.2+でソースから起動可能。
    • .envファイル作成しAPIキーを記入。
    • make runでサーバ起動。
  • Docker Composeによるインフラ一式の立ち上げもサポート。
    • Redis, PostgreSQL, MongoDB, Adminer, Prometheusなどと連携。

主要サービスURL

  • GoModel API: http://localhost:8080
  • Adminer(DB UI): http://localhost:8081
  • Prometheus: http://localhost:9090

OpenAI互換APIエンドポイント

  • /v1/chat/completions: チャット補完（ストリーミング対応）
  • /v1/responses: OpenAIレスポンスAPI
  • /v1/embeddings: テキスト埋め込み
  • /v1/files: ファイルアップロード・管理
  • /v1/batches: バッチ処理
  • /p/{provider}/...: プロバイダーネイティブパススルー
  • /admin/api/v1/: 利用状況や監査ログ等の管理API

設定・認証・セキュリティ

  • 環境変数とconfig.yamlで柔軟に設定可能。
  • GOMODEL_MASTER_KEYを設定しない場合、APIは無認証で危険。
    • 本番では強力なキーの設定を強く推奨。
  • ストレージはsqlite/postgresql/mongodbから選択。

レスポンスキャッシュ機能

  • 2層キャッシュでAPIコストと応答遅延を削減。
    • Layer 1: 完全一致キャッシュ（高速・サブミリ秒）
    • Layer 2: セマンティックキャッシュ（埋め込み＋KNN検索で類似質問もキャッシュヒット）
  • Cache-Controlヘッダーでキャッシュバイパスも可能。
  • 対応ベクトルDB: qdrant, pgvector, pinecone, weaviate。

今後のロードマップ（0.2.0まで）

  • インテリジェントルーティング対応。
  • プロバイダー追加：Cohere, Command A, Operational, DeepSeek V3など。
  • ユーザー/キー単位の予算管理。
  • モデル単価編集・コスト追跡の充実。
  • ガードレール機能の強化。
  • 全プロバイダーへのパススルー対応。

コミュニティと開発者情報

  • Discordコミュニティでユーザー同士の交流。
  • オープンソースで活発な開発。
  • **Jakub（ワルシャワ拠点のソロファウンダー）**が中心となり開発継続中。
  • GoModelは軽量・可搬性・運用のしやすさが特徴。
  • LiteLLMの供給チェーン攻撃を受けて、代替案として注目度上昇中。

公式サイト・フィードバック

GoModelの特徴まとめ

  • 超軽量・高速・多機能なAIゲートウェイ。
  • OpenAI互換APIで複数AIプロバイダーを一元管理。
  • 環境変数ベースの簡単設定・Docker即導入。
  • セマンティックキャッシュ等でコスト削減と高効率運用。
  • セキュリティ・運用性・拡張性重視の設計。

Hackerたちの意見

統一されたAPIってあるの？いくつかのプロバイダーと連携するための統一ライブラリを使ってみたけど、温度設定や推論の努力、ツール選択モードの設定など、結局はプロバイダーごとの特有の作業をしなきゃいけない場面があるんだよね。理想は、プロキシやライブラリが本当に統一されたAPIを提供してくれて、一度統合すればあとはプロバイダーのクセに悩まされることがないって感じなんだけど。あと、litellmみたいにオープンソースの rug pullをする予定はあるの？
└
1. はい、OpenAI互換のAPIがあって、Postelの法則を考慮してGoModelを開発しています：https://gomodel.enterpilot.io/docs/about/technical-philosoph... 。2. オープンソースとライセンスについては、こちらで透明に私たちのアプローチを説明しています：https://gomodel.enterpilot.io/docs/about/license
こういうライブラリって一時的な現象なのかな？プロバイダーが今までに単一のAPIに落ち着いてないのが不思議だよね。もちろん、顧客が他に移行しやすくなるのは望んでないだろうけど、もし独自のAPIがビジネスプランの重要な部分だったら、そもそも成功しないと思うんだよね。（互換性レイヤーについてだけ聞いてるけど、他のトラッキング機能は、たとえ一つのクラウドLLM APIしかなくても役立つと思う。）
└
プロバイダー自身も、自分たちのエコシステム内ですらこれを整理できてないみたい。しかも、みんなめちゃくちゃ忙しいし。例えば、`Claude code`は、Maxサブスクリプションをサポートするために、特定のベータヘッダーを2つ設定する必要があったりする。MaxプランのOAuthトークンは、APIキーの見た目とは違うんだよね。似てるけど、ツールが事前に検証する特定のプレフィックスがある。今のところ、同じプロバイダー内でもほとんど機能してない状態だよ。
└
ここ数年、複数のプロバイダーに対する抽象レイヤーを維持してきたんだ - https://llm.datasette.io/ 標準を定義するための最善の努力はOpenAIのハーモニー/レスポンスだと思うけど - https://developers.openai.com/cookbook/articles/openai-harmo... - あんまり普及してないね。古いOpenAIのチャットコンプリートは、ほとんどアドホックな標準で、ほぼすべてのプロバイダーがそれのクローンを提供してるけど、正式な仕様がないからイライラする違いが出てくるんだよね。主要な問題は、プロバイダーがまだ新しいものを発明しているから、標準にコミットするのが難しいってこと。次の機能セットをカバーできないかもしれないから。2025年は特に混乱していて、みんなが微妙に異なる形でAPIに推論メカニズムを追加してた。ツールコールやレスポンススキーマ（混乱を招くことに、これらは必ずしも同じものではない）もかなりのばらつきがあった。例えば、いくつかのプロバイダーは同じレスポンス内で複数のツールコールを許可してる。私の予想では、これらのAPIの形がまだ不安定だから、しばらくは抽象レイヤーが必要だと思う。みんなが賛同できる標準をサポートするには、将来の製品の選択肢をあまり制限しない形での標準が必要だからね。
└
完全にめちゃくちゃだね。この手のツールの一番の難点はメンテナンスだよ。互換性のないAPIだけじゃなくて、メッセージの構造にも関わってくるし。信頼できるツールコールを実現するには、各モデルごとにかなりの労力とテストが必要なんだ。LiteLLMのコミット履歴やオープンな問題/PRを見てみて。Geminiのための信頼できるマルチターンツールコールにまだ苦労してるし、Kimiはハードコーディングされたルールが必要だから、K2.6はリストにないから現在サポートされてないし、そんな感じだよ。基本的なOpenAI/Anthropicのプロトコルを実装するのは簡単だけど、その時点でAIゲートウェイの構築が終わったように感じる。でも、実際はそうじゃない。バグや変更、各プロバイダーやモデルの特性に常に対処する長い旅の始まりに過ぎないんだ。
同じようなgolangのゲートウェイを作ったんだけど、しっかりしたAPIゲートウェイ機能が重要だって理解してる。https://sbproxy.dev - エンジンは完全にオープンソースだよ。golangがゲートウェイに面白い理由の一つは、コンパイル時にサプライチェーンを明確にコントロールできることなんだ。LiteLLMみたいなツールでは、サプライチェーン攻撃がランタイムでより影響を与えることがあるから、コンパイルされたバイナリが役立つんだよね。
└
SHOW HNで見せる価値があるかも。
AIプロキシを作って維持してきたけど、モデルやプロバイダーのリリースごとに入力と出力の構造が不一致になるのがちょっと面倒なんだよね。新しいモデルの統合に24時間未満のターンアラウンドがないなら、そのプロジェクトはちゃんとメンテされてないと思う。今のところ、ガバナンスが一番の懸念事項で、適切なログ記録や、検査やDLPタイプの脅威軽減を提供するサードパーティサービスとの統合が必要だよね。
└
LiteLLMのサプライチェーンインシデントを考えると、脅威の軽減とガバナンスは確かに大きな懸念事項だね。
いい感じだね、オープンソースにして共有してくれてありがとう。私はGoに全力投球してて、https://housecat.com/のシステム全体にAIを統合してるんだ。今はこれに慣れてて満足してるよ：https://github.com/boldsoftware/shelley -- LLMゲートウェイ付きの完全Goベースのコーディングエージェント。https://github.com/maragudk/gai -- Anthropic / OpenAI / Googleの周りにGoインターフェースを提供してる。これもリストに追加するし、bifrostも調べてみるよ。他にGoベースのAI / LLMツールでおすすめのものがあったら教えてほしいな。特にClaude Codeのサブスクリプションに対応するハーネスのサポートを追加してほしいってリクエストに賛成するよ。
└
これから数日間じっくり見てみるつもりだけど、Claude CodeがサブスクリプションなしではOpenClawと正式に動かなくなったことを考えると、ちょっと難しいかも。
└
私はこれを個人プロジェクトで使ってるよ。いくつかの機能はライセンスが必要だけど、プロバイダープロキシやログ、メトリクスなどの基本機能は無料版でカバーされてるよ。 https://github.com/maximhq/bifrost
└
GoとAIに全力投球してるなら、これをチェックしてみるといいかも： https://github.com/ewhauser/gbash これはGoで実装されたjust-bashみたいなバリアントだよ。フルサンドボックスソリューションなしでエージェントに管理されたbashツールを提供するのに便利。
└
> GoベースのAIやLLMツールで、他に満足してる人いる？私もADK、CUE、Dagger（全部Goで作られてる）を使って作ったのがあるよ；CLI、TUI、VSCodeインターフェースもある。これは私の個人的なカスタムスタックで、まだドキュメントを書く必要があるんだ。私のお気に入りの機能はDaggerによって動いていて、タイムトラベルできるサンドボックス、フォーク、どんな時でもシェルにジャンプ、任意のポイント間の差分が取れるんだ。良いエントリポイントのフォルダはこちら： https://github.com/hofstadter-io/hof/tree/_next/lib/agent
└
Fence（https://github.com/Use-Tusk/fence）をGoで作ったんだ。CLIエージェント（実際にはどんなコマンドでも）用の軽量プロセスサンドボックスで、ファイルシステムとネットワークの制限があるよ。もしShelleyにサンドボックス機能を追加したいなら、Goライブラリとしても利用可能だよ。
└
こんにちは、GAIの作者です。気に入ってもらえて嬉しいです！自分自身でもクライアントのプロジェクトと合わせてたくさん使ってるけど、他に誰か使ってるかはわからなかったんだ。:D 実際、ゲートウェイが必ずしも必要ないように作ろうとしてるよ。コストとトークンの追跡はOpenTelemetryを通じて行われてるし、フォールバックやリトライは新しい「ロバスト」パッケージで処理してる。他にも計画があるんだ。もし何か見たい機能があったら、いつでもリポジトリに問題を報告してね。:-)
すごい作品ですね！シェアしてくれてありがとう！APIプロバイダーからのアップストリームの変更にどうやって対応するつもりですか？私も似たようなことを実装したことがあるんですが、Goでの最大の問題は、プロバイダーがSDKを提供していないことが多いことです（JavaScriptやPythonと比べて）。各リリースごとに最新の状態を保つのが大変なんですよね。
└
litellmみたいなVCの支援がないとほぼ不可能だね。
└
ほとんどのAPIは何らかのドキュメントを提供してるよ。Swaggerなら、そのドキュメントからアプリケーションを更新できるよ。
└
まず、GoModelは柔軟性を持つように設計されてるんだ。追加のフィールドを加えると、それを適切な場所に通そうとする（ポステルの法則）。だから、ちょっとしたAPIレベルの変更があっても、GoModelはコードを変更せずに対応できる可能性が高いよ。それに、プロバイダーのAPIフォーマットの変更も少なくなってきてるかも。通常は、月に数行のコードを追加するだけで済むんだ。私は毎日LLMを使ってるから、そういう変更には気づいてるし、いくつかのニュースもフォローしてる。もしものために、GoModelにはリクエストを元のフォーマットでプロバイダーに転送するパススルーAPIも含まれてる。これは、AIプロバイダーが契約を大きく変更したときに役立つかもしれないね。それに、公式SDKもバグがないわけじゃないから、余分なレイヤーをスキップしてAPIに直接アクセスする方が、GoModelには逆に良いかもしれない。
わあ、これめっちゃいいね！この「コンパクト」な感じ、好きだな。Traefikを思い出すよ。ほんとに期待できそう！一つ問題があるとすれば、LiteLLMのキー作成はプロバイダーで直接作るより簡単だけど、チームメンバーやテスト環境の管理が楽になるから、もしVault経由でキーを生成できたら完璧だし、色々と楽になるんだけどね。あなたのロードマップには必要なものが見えるけど、完了トラフィックを検査・デバッグできるサービスとの統合が欠けてるのが気になるし、個々のエンドユーザーからの使用状況をヘッダーを通じて追跡できるかどうかもわからない。ありがとう、頑張ってね！
└
「...個々のエンドユーザーからの使用状況をヘッダーを通じて追跡できるかどうかもわからない」とのことですが、現在、私たちはUser-Pathsという統一された概念を持っています。特定のヘッダーを追加するか、APIキーにUser-Pathを割り当てると、これに基づいて使用状況を追跡できます。User-Pathはエンドユーザー、内部ユーザー、またはサービスのいずれかです。例：/client1/app1 /agents/agent1 /team2/john /team2/adam これで大丈夫ですか？ https://gomodel.enterpilot.io/docs/features/user-path 追記：Vault統合についてのフィードバック、ありがとう。メモしました。
このアプリがRESTコールを通じて自分をさらけ出してるなら、誰がGoで書かれてることを気にするんだろう？潜在的な貢献者には重要かもしれないけど、大半の関心はユーザーから来ると思う。
└
サプライチェーンにおける燃料費みたいなもんだね。お店でリンゴを買うとき、油の価格なんて考えないよね。でも、トラックがもっと安くて効率的、あるいは税金が少ない何かで動いてたら、棚のリンゴももっと安くなるはずだよ。
すごくスムーズで軽量だね！一番の疑問は、上流のAPIの進化についてなんだけど。各プロバイダーのアップデートについていくのは、フルタイムの仕事みたいに感じるよ。こういう常に変わるプロトコルの追跡をどうやって自動化したり管理してるの？
└
今、フルタイムでそれに取り組んでるよ。特に動画や音声、画像モデルとのインタラクションに関しては、結構大変かも。何が起こっているのかを把握しつつ、日々新しいことを追加しようとしてる。さらに大きな挑戦は、クラウドプラットフォームやPrometheus、OAuth、Datadog、ボールト、DLPソフトウェアとの統合をもっと密にすることかもしれないね。
いい仕事だね。プロンプトにタイムスタンプやセッションIDが含まれているとき、キャッシュキーはどうしてるの？ハッシュ化する前に揮発性フィールドを取り除くためにRegexを使ってるの？それとも、ユーザーに安定しているものを最初に宣言させてるの？自分のプロジェクトで両方試したけど、どちらもきれいにはならなかったよ。
└
ありがとう。今のところ、キャッシュ用にどのフィールドが「安定」かを宣言する設定はないんだ。ユーザーが異なるセッションIDを提供する場合でも、キーが一致することを望むケースを想定してるってことだよね？合ってる？