any-llm はプロバイダ切り替えのどこを消し、どこを残すのか

any-llm が消そうとしているのは API キーの管理ではない

複数プロバイダを併用するコードは、たいてい同じ形の分岐で汚れていく。OpenAI は openai パッケージ、Anthropic は anthropic パッケージ、Mistral は mistralai パッケージを呼び、それぞれでクライアントの生成方法、メッセージの渡し方、レスポンスの取り出し方が違う。any-llm が対象にするのはこの部分である。README の Quickstart では、model と provider を指定して completion を呼び、response.choices[0].message.content を読む。プロバイダを変えるときは provider の文字列と API キーを変えるだけで、呼び出し側のコードは触らない。想定読者は、プロトタイプで複数モデルを試す個人開発者と、モデルを差し替えながら動かすツールを保守するチームである。README は自社の any-agent がこの SDK を使っていると述べている。API キーの保管や予算管理は対象外で、そこは Otari Gateway として別リポジトリに切り出されている。

公式 SDK を包む薄さが設計の中心にある

any-llm は独自の HTTP クライアントを持たず、各プロバイダの公式 SDK を土台にする。README の利点の一項にも、公式 SDK を利用することで互換性を最大限に保つとある。この選択は、プロバイダが新機能を出したときに SDK 側の追随が必要になる代わりに、認証や再試行、ストリーミングの挙動が各社の実装と一致しやすいという意味を持つ。導入は extras で行う。pip install 'any-llm-sdk[openai]' のようにプロバイダ名を指定し、複数なら [mistral,ollama]、全部なら [all] を渡す。API キーは環境変数で読ませるのが基本で、MISTRAL_API_KEY、OPENAI_API_KEY、ANTHROPIC_API_KEY といった名前は各プロバイダの慣例に従う。コード内で api_key を直接渡す経路も用意されている。抽象化の層が薄いぶん、プロバイダ固有の挙動が完全に消えるわけではない点は、後述する制約に直結する。

completion 関数と AnyLLM クラスは接続の持ち方で選ぶ

同じことをする入口が二つある。any_llm.completion は関数呼び出しごとにクライアントを新しく作るステートレスな経路で、スクリプトやノートブック、単発のリクエストに向く。AnyLLM.create("mistral", api_key=...) はクライアントを保持して再利用する経路で、README の表では接続プールを使う本番アプリ向けとされている。両者はストリーミング、ツール呼び出し、Responses API など同じ機能をサポートすると README は説明する。つまり選定基準は機能差ではなく、リクエストの反復回数と接続の寿命である。モデルの指定にも二通りあり、provider="mistral" と model="mistral-small-latest" を分けて渡す形が推奨として先に示され、model="mistral:mistral-small-latest" という provider_id:model_id の結合形式も代替として用意されている。分離形式のほうが、provider を設定値から差し込むコードと相性がよい。

LiteLLM からの移行は import とモデル文字列の置換で足りる

README は LiteLLM 利用者向けの節を設けている。API キーと環境変数はそのまま使えると明記され、作業は extras 付きのインストール、import 文の変更、モデル文字列の変更の三つに絞られる。具体例では from litellm import completion を from any_llm import completion に変え、model="openai/gpt-4o" を model="openai:gpt-4o" に書き換える。区切り文字がスラッシュからコロンに変わる点が見落としやすい箇所で、既存のモデル文字列を一括置換する前に docs.mozilla.ai/any-llm/providers/ の対応表で自分の文字列を確認する必要がある。README はプロキシも追加設定も不要だと述べている。ただし設計の方向は同じではない。any-llm は公式 SDK を包むことを明示しており、独自の変換層でプロバイダ差を吸収する approach とは、差分が表面化する場所が異なる。

抽象化が埋めない差分はどこに残るか

any-llm はプロバイダ差を消すのではなく、呼び出しの形を揃える。公式 SDK をそのまま土台にする以上、SDK が対応していない機能や、プロバイダ固有のパラメータは抽象化の外に落ちる。README が挙げる機能は completion、ストリーミング、ツール、Responses API であり、それ以外の固有 API については対応範囲を確認する必要がある。Responses API もすべてのプロバイダで使えるわけではなく、README は OpenAI スタイルの Responses API を実装しているプロバイダ向けだと限定している。つまり、あるプロバイダでしか使えない機能に依存するアプリでは、any-llm を挟む意味が薄れるか、結局その SDK を直接呼ぶコードが併存することになる。抽象化の対象外だと判断する基準を先に決めておかないと、統一インターフェースのつもりが二重管理になる。

一覧にない OpenAI 互換サーバーは専用エントリを作らない

自前のゲートウェイやローカルの OpenAI 互換サーバーを使っている場合、any-llm はプロバイダ登録を増やすのではなく、Custom OpenAI-compatible Endpoints として扱う。README は、一覧にない OpenAI 互換のゲートウェイやローカルサーバーには専用のプロバイダエントリは不要だと述べ、詳細を docs.mozilla.ai/any-llm/quickstart の該当節に委ねている。この判断は、プロバイダ数を増やすほどテストと保守の対象が広がるという事実を反映している。Ollama のようなローカル実行も extras の一つとして扱われ、pip install 'any-llm-sdk[mistral,ollama]' のようにクラウドとローカルを同じ依存指定の中で並べられる。プロバイダの追加がコード変更ではなく extras とエンドポイント設定で済む範囲に収まっているかが、採用判断の分かれ目になる。

Apache-2.0 とリリース頻度が示す保守コスト

ライセンスは Apache-2.0 で、特許許諾条項を含む寛容なライセンスとして知られる。派生物の配布時にライセンス表示と変更点の明示が求められる点は、社内ツールに組み込んで再配布する場合に関係する。ここは法務判断の領域なので、実際の適用は自組織の法務に確認してほしい。保守の面では、リポジトリはアーカイブされておらず、1.27.1 が 2026-09-04、1.27.0 が 2026-09-03、1.26.0 が 2026-08-17 と、マイナーリリースが短い間隔で続いている。活発であることは事実として確認できるが、この間隔は追従側にもコストを課す。プロバイダ SDK の更新に合わせて any-llm も動くため、依存を固定しない運用では、ある日突然プロバイダ SDK のメジャー更新が混ざる可能性がある。pip の制約ファイルで any-llm-sdk と各プロバイダ SDK のバージョンを同時に固定し、更新はテスト付きで行う形が現実的である。

編集部の結論

複数の LLM プロバイダをまたぐ Python アプリで、プロバイダ固有 SDK の呼び出し差分をアプリ側から追い出したいなら any-llm は候補になる。とくに any-agent のように同じ呼び出しを多数のモデルで回すツールでは、provider 文字列の差し替えで済む利点が大きい。逆に、単一プロバイダしか使わず、その SDK の固有機能を深く使う設計なら、間に一枚挟む価値は薄い。導入前に確認すべきは、自分のモデル文字列が docs.mozilla.ai/any-llm/providers/ の対応表に載っているか、そして使いたい機能が抽象化の対象内かどうかである。any-llm はプロバイダ差分をゼロにはしない。どの差分を自分で持ち、どの差分を SDK に預けるかを決めるための道具として読むのが正しい。

公式情報源

1. License: Apache-2.0
2. mozilla-ai/any-llm on GitHub
3. Project website
4. README
5. Releases