wormhole

採用判断としては、Go で複数の LLM 提供元にまたがるバックエンドを作るなら wormhole は確認する価値があります。ただし現時点の根拠はほぼ公式 GitHub リポジトリの記述だけで、注目度も実用性の検証もサンプルがかなり少ないため、完成度の高い定番というよりは、先行的に自分で評価する対象として見るのが安全です。

実際の役割として、これはチャットアプリでもワークフロー自動化基盤でもありません。より正確には、Go 向けのマルチ LLM 抽象化レイヤー、またはゲートウェイ SDK に近いです。OpenAI、Anthropic、Gemini、Ollama、OpenRouter へのアクセスを共通化し、適応的なレート制御と並行処理制御を打ち出しています。社内 AI サービス、API プロキシ、バッチ処理を作るチームにとっては、統一された呼び出しコードや切り替えやすい構成が主な成果物になります。

導入ハードルとコストについては、証拠から言えるのは「オープンソース」で「複数プロバイダ対応」という点までです。公式料金、ホスティング課金、独自の API 料金上乗せを示す情報は見当たらないため、本体の価格を断定すべきではありません。保守的に言えば、SDK 自体はオープンソースとして使う前提に見え、実コストは接続先モデル API の利用料が中心になるはずですが、これは公式価格情報ではなく保守的推定です。また、Go 実装、鍵管理、監視、障害対応を自前でこなせることが前提です。

向いているのは、Go サービス内で複数モデルを統一的に扱いたい開発者や、ソースを読んで検証できる技術チームです。向いていないのは、すぐ使える完成品を求める非技術チームや、多数の本番導入実績を重視する調達側です。議論の質という意味では、evidenceSources はほぼリポジトリ情報のみで、実測、詳しいチュートリアル、長文レビュー、第三者比較は確認できません。GitHub の少数 star は注目の証拠にはなっても、使いやすさや成熟度の証拠にはなりません。外部検証が乏しいため、能力評価は慎重に行うべきです。