AxonHub レビュー：SDK を変えずに 100+ モデルを呼ぶ Go 製 AI ゲートウェイ

AxonHub が埋めようとしているのは SDK とベンダーの結合点

README はこのプロジェクトの目的を「AI ゲートウェイ、让你无需改动一行代码即可切换模型供应商」と表現している。問題設定は 4 つに整理されている。ベンダーロックイン、複数ベンダーを 1 つの API 形式で扱う統合の複雑さ、リクエスト追跡の欠如、コスト管理である。

対象読者は、OpenAI SDK や Anthropic SDK をすでにアプリケーションに組み込んでいて、モデルの切り替えのたびにコードを書き換えたくない開発者だ。SDK の選択とモデルの選択を分離したい、という動機が中心にある。逆に、最初から単一ベンダーの SDK だけを使い続ける前提なら、間に何かを挟む理由は薄い。

ここで注意したいのは、AxonHub がモデルそのものを提供するわけではない点だ。README のスポンサー欄には APIKEY.FUN、Infistar.cc、七牛云 AI、FennoAI といった中継サービスが並んでおり、AxonHub はそれらの上流に対してリクエストを変換して送る位置づけになる。つまり導入すると、アプリケーション、AxonHub、上流ベンダーの 3 層になる。この 1 層の追加が何と引き換えに妥当なのかを判断するのが、採用検討の実質的な中身である。

プロトコル変換ゲートウェイとしてのデータフロー

README のアーキテクチャ図（docs/axonhub-architecture-light.svg）と機能表から読み取れる範囲では、AxonHub はクライアントから受け取ったリクエストを、選択されたチャネル（上流プロバイダ）が解釈できる形式に変換して転送する。機能表の 1 行目は「用 OpenAI SDK 调用 Claude，或用 Anthropic SDK 调用 GPT」であり、SDK 側のプロトコルとベンダー側のプロトコルを独立に扱う設計だと分かる。

この変換を成立させるには、リクエストの形式だけでなく、ストリーミングのチャンク、ツール呼び出し、トークン数の集計といった要素もベンダー間で対応付ける必要がある。README が「线程级可观测性的完整请求时间线」と書いているのは、この変換過程を含めたリクエスト単位の記録を指す。コスト追跡の説明でも「输入、输出、缓存 Token——全部追踪」とあり、変換後のリクエストからトークン内訳を拾っていることがうかがえる。

ロードバランシングについては「<100ms 自动故障转移」と記載されている。ただしこの数値がどの条件下で測定されたものかは README には書かれていない。上流のタイムアウト検出から別チャネルへの再送までの時間なのか、ヘルスチェックの間隔なのかは特定できない。ここは導入前に自分で確かめるべき箇所である。

動かすまでに何をするか

README は Docker 対応をバッジで示しており、Go のバージョンバッジも掲げている。ただし、クイックスタートの具体的なコマンド列は与えられた README の抜粋には含まれていない。したがって、ここで書けるのは「何を確認すべきか」までである。

リポジトリの構成から確実に言えるのは次の点だ。第一に、default branch が unstable であり、main ではない。クローンする場合はブランチを明示する必要がある。第二に、最新リリースは v1.0.0-beta10（2026-09-06）で、beta が 10 回積み上がっている。タグを指定して取得するほうが、unstable ブランチを追うより再現性が高い。第三に、設定はおそらくチャネル（上流プロバイダ）とモデルのマッピング、そして API キーを登録する形になる。README の機能表が「渠道（チャネル）」という語を使っているため、この語が設定上の概念名である可能性が高い。

導入時の現実的な手順は、docs/zh/index.md を起点に、api-reference/openai-api.md、guides/tracing.md、guides/permissions.md、guides/load-balance.md、guides/cost-tracking.md の順に読むことになる。README の機能表はこれら 5 つのドキュメントにリンクしている。設定キーの正確な名前はこれらのドキュメント側にしかない。

beta が 10 版続いているという事実の重み

このプロジェクトの最も重要な制約は、機能の不足ではなく成熟度の表示方法にある。v1.0.0-beta8、beta9、beta10 が 2026-09-02、09-03、09-06 と、4 日間に 3 版出ている。活発であることの証拠ではあるが、同時にインターフェースが固まっていないことの証拠でもある。

ゲートウェイはアプリケーションの認証経路に置かれる。ここが変わると、アプリ側の設定も追随して変わる。beta の間に設定キーやエンドポイントのパスが変われば、そのたびに修正が発生する。README の機能表がリンクするドキュメントのパス（docs/zh/guides/...）も、beta の間は動く可能性がある。

ライセンスも確認が必要だ。GitHub 上の表示は NOASSERTION であり、これは SPDX の識別子として認識されなかったことを意味する。MIT や Apache-2.0 のような既知の条項ではないため、README や LICENSE ファイルの原文を読んで、再配布や商用利用の条件を自分で判断する必要がある。ここで法的な助言はできない。

LiteLLM との違いはどこにあるか

同じ問題領域には LiteLLM がある。Python 製で、100 以上のモデルに対して OpenAI 互換のインターフェースを提供する点は共通している。違いは実装言語と、何を主目的に据えるかにある。

LiteLLM は Python のライブラリとしてアプリケーション内に組み込む使い方が中心で、SDK の呼び出しをラップする。AxonHub は Go 製の独立したゲートウェイで、アプリケーションの外にプロセスとして立てる。この違いは、既存コードへの侵入度に直結する。LiteLLM を組み込む場合はアプリ側の依存関係とコードに手が入る。AxonHub の場合はアプリは base URL を向け先を変えるだけで、SDK の呼び出しコードには触らない。

もう一つの違いは、AxonHub が RBAC とコスト追跡を README の主要機能として前面に出している点だ。LiteLLM にも予算管理やキー管理はあるが、AxonHub の機能表は「企业级 RBAC」「实时成本追踪」を独立した行として並べている。チーム単位のアクセス制御と利用量の按分を最初から要件に含めるなら、AxonHub の設計思想のほうが近い。逆に、単一プロセス内で完結させたい、Python の依存関係を増やしたくないという理由で LiteLLM を選ぶケースも当然ある。

このゲートウェイが不要になる場面

AxonHub を挟むと、リクエストの経路に 1 ホップ増える。上流ベンダーがすでに OpenAI 互換のエンドポイントを提供している場合、変換の必要性は小さくなる。たとえば上流が OpenAI 形式をそのまま受け付けるなら、AxonHub が担うのは変換ではなく、ルーティング、追跡、コスト集計だけになる。

その 3 つが不要なら、AxonHub は不要だ。具体的には、モデルを 1 社しか使わない、利用量の按分を必要とするチームが存在しない、リクエストの追跡はアプリ側のログで足りる、という条件が揃うケースである。この場合、ゲートウェイの運用（プロセスの監視、設定の更新、beta 間の追随）だけが残る。

もう一つの失敗モードは、上流のレート制限やエラー形式の差異を AxonHub が完全には吸収できない場合だ。README は failover を訴求しているが、どのエラーコードを failover のトリガーとするか、再試行が何回まで許されるかは抜粋からは分からない。上流が返すエラーの意味がベンダーごとに違う場合、変換層がそれを正しく分類できるかは別の問題である。

維持コストとアップグレードの見通し

4 日で 3 版というリリース間隔は、追随コストを考えるうえで無視できない。beta を固定して使うなら、アップグレードは自分のタイミングで行える。unstable ブランチを追うなら、変更に常に晒される。README が default branch を unstable にしている以上、タグ運用を前提にしたほうが安全だ。

ドキュメントは中国語、英語、日本語の 3 言語が用意されている（README 冒頭の言語リンク）。日本語の README が存在するため、設定の意味を日本語で確認できる範囲は広い。ただし、機能表からリンクされているドキュメントの日本語版がどこまで揃っているかは、与えられた資料からは判断できない。

ライセンスについては前述のとおり NOASSERTION であり、これは「ライセンスがない」という意味ではない。GitHub が SPDX として認識しなかった、というだけである。fork して改変し、社内で再配布するような使い方を想定するなら、LICENSE ファイルの原文を読む作業を先に済ませておきたい。

導入を決める前に確かめる 3 点

第一に、failover のトリガー条件と再試行回数。README の「<100ms 自动故障转移」は訴求文であり、条件が書かれていない。自前の上流を 2 つ登録し、片方を意図的に落として、もう片方に切り替わるまでと、その間にクライアントが受け取る応答を確認する。

第二に、変換の網羅性。OpenAI SDK から Anthropic 系のモデルを呼ぶとき、ツール呼び出しとストリーミングが期待どおりに動くか。README は「零代码改动」を掲げているが、これは呼び出し側のコードを変えないという意味であり、すべての機能が透過的に動くという意味ではない。

第三に、コスト追跡の数値が上流の請求と一致するか。README はキャッシュトークンまで追跡すると書いている。キャッシュの課金体系はベンダーごとに異なるため、集計値と実際の請求額を 1 か月分突き合わせる価値がある。この 3 点が自前のリクエストで確認できるまでは、本番の経路に AxonHub を置かず、検証用の base URL として並行に立てておく判断が現実的だ。

編集部の結論

採用を検討すべきなのは、OpenAI SDK や Anthropic SDK を前提に書かれたアプリケーションを複数抱え、モデルベンダーの切り替えをコード変更なしで行いたいチームである。逆に、単一ベンダーしか使わず、SDK の呼び出し箇所が数か所しかない小規模なコードベースでは、ゲートウェイを 1 段挟む運用コストのほうが大きい。導入前に確認すべきは、ライセンス条項（NOASSERTION のため GitHub 上の表示だけでは判断できない）、default branch が unstable である点、そして最新リリースが v1.0.0-beta10 である点の 3 つ。安定版のタグが打たれるまでは、本番の認証経路に置くのではなく、社内の検証環境で OpenAI 互換エンドポイントの変換結果を自前のリクエストで確かめる段階に留めるのが妥当だ。

公式情報源

1. Issues
2. looplj/axonhub on GitHub
3. Project website
4. README
5. Releases