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

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

2026年4月21日原文(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と正式に動かなくなったことを考えると、ちょっと難しいかも。

Hacker Newsで議論の続きを見る