無料LLM APIの集約にFreeLLMAPIが選ばれる理由｜規約と限界

主要な AI ラボがどこも無料枠を用意した結果、無料で叩ける LLM API の選択肢はここ 1 年で大きく増えました。ところが 1 社ぶんの無料枠は、日次のリクエスト数もトークン数も小さく、コーディングエージェントを 1 日回せば使い切ってしまう程度の容量しかありません。「無料枠があるのに実用にならない」という中途半端な状態が、いま多くの検証環境で起きています。

かといって複数社の無料枠を手作業で束ねるのは、思っている以上に割に合いません。プロバイダーごとに SDK が違い、認証方式が違い、レート制限の数え方が違い、エラーの返し方も違います。10 社そろえれば管理対象が 10 倍になり、しかも無料枠の条件はしばしば予告なく変わります。増えた選択肢が、そのまま増えた管理コストとして返ってくる構図です。

tashfeenahmed/freellmapi（以下 FreeLLMAPI）は、この問題に「34 プロバイダーの無料枠を 1 つの OpenAI 互換エンドポイントの背後に集約する」というアプローチで応えるセルフホスト型ルーターです。キー単位でレート制限を追跡し、上限に達したモデルからは自動でフェイルオーバーすることで、束ねた無料枠を上限内に収めながら使い切る設計になっています。

ただし、このカテゴリの OSS は FreeLLMAPI だけではありません。機能一覧を並べても選定はできず、読者が本当に知りたいのは「この構成を自分の用途で使ってよいのか」という一点に集約されます。本記事では機能紹介ではなく、（1）プロバイダー規約に照らしてどこまで許されるのか、（2）無料枠ゆえの限界は何か、（3）週次で変わる無料枠にツール側が追従し続けられるのか、そして（4）類似 OSS とどう使い分けるのか、という 4 つの判断材料を整理します。

なお本記事は、FreeLLMAPI の README・公式ドキュメント・公式サイト、および GitHub API から取得したリポジトリメタデータをもとにした整理であり、インストールや実行による動作検証は行っていません。数値は特記のない限り 2026 年 9 月 7 日時点のものです。

FreeLLMAPIとは｜34社の無料LLM枠を1つのOpenAI互換エンドポイントに集約するOSS

リポジトリの基本情報と健全性

採用を検討するうえで、まず確認しておきたいのがリポジトリの状態です。GitHub API から取得した基本情報は次のとおりです。

作成からおよそ 4 か月半で 24,500 スターを超えており、最終 push は本記事の調査日前日にあたる 2026 年 9 月 6 日です。その 2 日前の 2026 年 9 月 4 日に v0.9.7 がリリースされていることからも、開発は止まっていないと判断できます。ライセンスは MIT で明示されており、ライセンス未設定のリポジトリにありがちな利用条件の不透明さはありません。

一方で、バージョンが v0.9.7、つまり v1.0 に到達していない点は判断材料として押さえておく必要があります。API・設定ファイルの仕様に破壊的変更が入りうる段階であり、自動更新やスクリプトから継続的に呼び出す構成にする場合は、バージョン固定と変更追随の手間を見込んでおくのが安全です。

「無料枠を積み上げる」という発想

FreeLLMAPI が扱う規模は、README によれば 34 プロバイダー・474 モデルファミリ・635 の無料エンドポイント（内訳は chat 584、embeddings 41、transcription 7、video 3）で、月間およそ 74 億トークンに相当するとされています。

README の "Why this exists" には、この設計の出発点が明快に書かれています。個々の無料枠は単体では「おもちゃ（a toy）」に過ぎないが、積み上げれば実用的な推論容量になる。ただし手作業で積み上げると、34 個の SDK・34 個のレート制限・34 か所の故障点を抱え込むことになる、という問題設定です。つまり FreeLLMAPI が提供しているのは「無料の LLM」ではなく、「無料枠を束ねたときに発生する管理コストを引き受けるレイヤー」だと理解すると、後続の設計判断が読み解きやすくなります。

対応プロバイダーには Google、Groq、Cerebras、OpenCode Zen、Mistral、OpenRouter、Cloudflare、Cohere、Z.ai（Zhipu）、NVIDIA、HuggingFace、ModelScope などが並び、README にはこれに加えて「22 more free providers」と記載されています。さらに、llama.cpp・LM Studio・vLLM・ローカルの Ollama・リモートゲートウェイといった任意の OpenAI 互換エンドポイントを、カスタムプロバイダーとして chat / embedding / image / audio 向けに登録できます。ローカルモデルと無料枠を同じチェーンに並べられる点は、検証環境の構成自由度に効いてきます。

無料LLM APIを個別に使うと詰まる3つのポイント

集約ツールというカテゴリが必要になる理由は、一般的な運用で詰まるポイントを並べると見えてきます。大きく 3 つあります。

1つ目は、プロバイダーごとに接続の作法が違うことです。 OpenAI 互換をうたっていても、認証ヘッダの形式、ストリーミングのチャンク構造、ツール呼び出しの表現、エラーコードの意味づけは各社で微妙に異なります。1 社ぶんのアダプタを書くのは難しくありませんが、これが 10 社・20 社と増えると、モデルを 1 つ差し替えるたびに動作確認の範囲が広がっていきます。

2つ目は、レート制限が多層で管理しきれないことです。 無料枠の上限は 1 分あたりのリクエスト数（RPM）、1 日あたりのリクエスト数（RPD）、1 分あたりのトークン数（TPM）、1 日あたりのトークン数（TPD）といった複数の軸で設定されており、しかもプロバイダーごとに採用している軸が違います。さらに同一プロバイダーでも API キーごとにカウンタが分かれるため、「いまどのキーがどの上限に何割近づいているか」を人手で把握するのは現実的ではありません。上限を超えれば 429 が返り、リトライの設計まで自前で持つ必要が出てきます。

3つ目は、無料枠そのものが予告なく変わることです。 新しいモデルが無料枠に加わることもあれば、既存モデルが有料に移ることも、統合ごと打ち切られることもあります。手元のモデル一覧が古いまま運用を続けると、原因の分かりにくい 429 や認証エラーとして表面化します。この 3 つ目は、後述する署名付きカタログの話に直結する、このカテゴリの構造的な弱点です。

裏を返せば、集約ツールを評価するときは「対応プロバイダー数」よりも、この 3 点にどう答えているかを見るほうが判断の精度が上がります。

FreeLLMAPIの仕組み｜ルーター・レート制限台帳・暗号化キーストア

公式の Architecture & internals には、内部構造がコンポーネント単位で説明されています。ここが本記事でもっとも技術的に踏み込む部分です。

1リクエストが流れる経路

公式ドキュメントによれば、リクエストは次の順に処理されます。

1. OpenAI SDK・curl・任意の OpenAI 互換クライアントが、Bearer freellmapi-… を添えて Express プロキシ（既定ポート 3001）の /v1/chat/completions を叩く
2. ルーターが「健全なキーを持っていて、かつすべてのレート制限内にある」最優先モデルを選ぶ
3. 対象プロバイダーのキーをメモリ内で復号し、プロバイダー SDK を呼ぶ
4. 429 や 5xx が返った場合はそのキーをクールダウンさせ、チェーン内の次のモデルへ再試行する

呼び出し側から見ると、モデル指定は auto のような抽象名で済み、実際にどのプロバイダーが応答したかはレスポンスに付与される X-Routed-Via: <platform>/<model> ヘッダで確認できます。ブラックボックスにせず経路を可視化している点は、検証用途では扱いやすい設計です。

README の "Using the API" には、Python から呼び出す例が掲載されています。

from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:3001/v1",
    api_key="freellmapi-your-unified-key",
)

resp = client.chat.completions.create(
    model="auto",  # let the router pick; or "auto:fast", "auto:smart", a profile, or a model id
    messages=[{"role": "user", "content": "Summarise the fall of Rome in one sentence."}],
)
print(resp.choices[0].message.content)
print("Routed via:", resp.headers.get("x-routed-via"))

出典: https://github.com/tashfeenahmed/freellmapi#using-the-api （README からの引用、改変なし）

base_url をローカルのルーターに向け、統合キーを渡すだけで、既存の OpenAI SDK のコードがそのまま動く形になっています。

ルーティング戦略とキー単位のクォータ台帳

ルーティングは 6 つの戦略が用意されており、モデルごとのライブな速度・能力・信頼性スコアでフォールバックチェーンを順位付けします。auto:fast や auto:smart のようにリクエストごとに戦略を切り替えられるほか、コーディング用・ビジョン用といった名前付きのチェーンをプロファイルとして定義し、auto:<profile> の形で指定できます。

無料枠集約の中核にあたるのが、レート制限の台帳です。公式ドキュメントによれば、FreeLLMAPI は (platform, model, key) の組み合わせごとに RPM / RPD / TPM / TPD のカウンタを保持し、プロバイダーが報告する上限値を学習しながら、常に上限内に収まるようリクエストを配分します。実装は server/src/services/ratelimit.ts にあり、SQLite に裏付けられたインメモリのカウンタとして動作し、429 を受けたキーはクールダウン対象になります。前述した「レート制限が多層で管理しきれない」という問題に対する、直接的な回答がここに置かれています。

このほか、複数プロバイダーに同一モデルが存在する場合に 1 エントリへ畳み込み、グループ内で厳格にフェイルオーバーする「統合モデル」、会話を 30 分間同一モデルに固定するスティッキーセッション、モデルが切り替わる際に文脈を維持するためのコンパクトな引き継ぎノートといった仕組みが用意されています。

キーの暗号化と出口の一本化

セキュリティ面では、プロバイダーの API キーを SQLite 内に AES-256-GCM のエンベロープ暗号化で保存し、リクエストごとにメモリ上で復号する構成が採られています。アプリケーション側から見える資格情報は freellmapi-… という統合トークン 1 本のみで、34 社ぶんの生キーがアプリの設定ファイルや環境変数に散らばらない設計です。キーの棚卸しという観点では、この「出口の一本化」は運用負荷を下げる方向に働きます。

動作環境は Node 20 以上が動くところであれば、Windows・macOS・Linux サーバーに加えて Raspberry Pi のような小型 ARM ボードも対象とされています。PM2 や systemd の配下でアイドル時およそ 40 MB RSS という数値が README に示されており、常駐させても負担の小さい規模です。

OpenAI互換だけではない対応サーフェス（Anthropic Messages・Gemini・Ollama）

採用判断で見落としやすいのが、「手持ちのクライアントがそのまま繋がるか」という適合性の問題です。ここは手順ではなく、互換性の地図として押さえておくと判断が早くなります。

3系統のワイヤ形式に対応する

FreeLLMAPI は OpenAI 互換のエンドポイント群を一通り備えています。/v1/chat/completions のほか、Codex CLI が必要とする /v1/responses、エディタのゴーストテキスト補完で使われる /v1/completions、/v1/images/generations、/v1/videos/generations、/v1/audio/speech、/v1/audio/transcriptions、/v1/embeddings、/v1/models が対象で、ストリーミング・非ストリーミングの双方に対応します。

注目したいのは、OpenAI 形式以外のワイヤ形式にも応答する点です。/v1/messages が Anthropic の Messages API 形式を話すため、Claude Code や公式 Anthropic SDK をそのまま無料プールに向けられます。Gemini CLI 向けにはネイティブの /v1beta（generateContent・ストリーミング・トークンカウント・models）が用意され、Zed や JetBrains AI に対してはオプトインの Ollama エミュレーションを経由して接続する形が公式に案内されています。クライアント側の対応状況ごとに接続経路が用意されているため、「使いたいツールが OpenAI 互換設定を持っているか」に縛られにくい構成です。

対応クライアントの詳細は、公式の Clients & coding agents にツール別のレシピとしてまとめられています。

設定生成とゼロ永続化ランチャー

各クライアントの設定は、コマンドから生成できるようになっています。README には次の例が掲載されています。

npx freellmapi setup-claude --url http://localhost:3001 --api-key <unified-key>

出典: https://github.com/tashfeenahmed/freellmapi#works-with-open… （README からの引用、改変なし）

setup-claude のほか setup-codex・setup-aider・setup-dsh など計 14 種のジェネレータがあり、いずれも --dry-run に対応し、既存の設定ファイルはタイムスタンプ付きでバックアップしたうえでマージされると説明されています。設定ファイルに資格情報を書き込みたくない場合は、freellmapi launch（Claude Code 向け）や freellmapi launch-codex（Codex 向け）というランチャーが用意されており、子プロセスにのみ資格情報を注入します。設定ファイルへ秘密情報を残さないという方針が、ツール側に組み込まれている点は評価できるところです。

特徴的な機能

機能を網羅すると論点がぼやけるため、設計思想が表れているものに絞ると次のようになります。

• fusion: 仮想モデル fusion を指定すると、複数の異なる無料モデルへプロンプトを並列にファンアウトし、judge モデルがドラフトを 1 つの回答に統合します。単体では非力な無料モデルを、数で補う発想です
• ツール呼び出しのレスキュー: プレーンテキストとして返ってきたツール呼び出しを、実際の tool_calls へ復元します。ツール対応の品質がプロバイダー間でばらつくことへの対処です
• プロンプト圧縮（オプトイン）: プロンプトの重複排除、ツール出力のフィルタ、繰り返し JSON のコンパクト化、古い文脈の切り詰めを、キャッシュ参照とルーティングの前段で行います
• MCP サーバー: /mcp 経由で、エージェント自身が利用可能なモデル・プロバイダーの健全性・ルーティング戦略を内省できます
• 管理ダッシュボード: React 製の UI でキー管理・チェーンの並べ替え・プレイグラウンド・p50/p95/TTFT の分析を行えます。日本語を含む 60 言語に対応しています

署名付きモデルカタログの自動更新とオープンコアの課金設計

先ほど「無料枠は予告なく変わる」を、このカテゴリの構造的な弱点として挙げました。FreeLLMAPI の特徴が最も出ているのが、この問題への回答です。

1日2回、Ed25519署名付きで届くカタログ

ルーターは、モデルカタログを公式サイトから 1 日 2 回同期します。新しいモデルの追加、クォータの変更、プロバイダー固有の不具合修正が、git pull やアップデート作業なしにローカルの DB へ反映される仕組みです。ダウンロードしたカタログはピン留めされた Ed25519 鍵で検証してから適用されるため、配信経路が汚染された場合の影響を抑える設計になっています。

適用範囲も限定されており、ユーザー自身が設定した有効・無効の切り替えや、登録したカスタムプロバイダーはカタログ更新で書き換えられません。またカタログサーバーはユーザーのプロンプト・出力・プロバイダーキーを一切参照しないと明記されており、ルーター本体は完全なセルフホストのまま維持されます。

「モデル一覧の鮮度をどう保つか」という運用課題を、利用者の手作業ではなく配信基盤側に寄せた設計であり、無料枠集約というカテゴリの弱点に対する構造的な対処と言えます。

無料とライブフィードの差は「到着の速さ」

無料インストールの場合も、同じ署名付きカタログを受け取ります。ただし取得するのは月次のスナップショットで、モデルがライブフィードに到着してから 30 日後にスナップショットへ入る仕組みです。公式サイトの表記では、無料ビルドは現時点でおよそ 303 モデルぶん遅れているとされています。

重要なのは、公式が「何も期限切れにならず、何も機能制限されない。到着が遅いだけ」と説明している点です。無料のままでも動作に制限はかからず、差が出るのは新しいモデルを試せるようになるタイミングだけ、という整理になっています。最新モデルを追いかける用途でなければ、無料のままで支障が出る場面は限られます。

MITのルーター本体 + 有料のライブフィードという設計

有料プランにあたる Premium は、年額 19 ドルまたは 49 ドルの買い切り（ライフタイム）で、fla_ から始まるキー 1 つで自分が動かす全ルーター（デスクトップ・自宅サーバー・Raspberry Pi など）をカバーします。Stripe による決済とセルフサービスでの解約に対応していると案内されています。

ここで確認しておきたいのは、課金対象がカタログ配信に限定されており、ルーター本体は MIT ライセンスで永続的に無料である点です。公式の説明によれば、その収益が日次のモデルテストとカタログ整備の原資になるとされています。無料枠を追跡し続けるには、プロバイダー各社の仕様変更を継続的に検証する人的コストが発生します。そのコストの回収経路をコードの機能制限ではなくデータ配信に置いたことは、OSS としての持続可能性を評価するうえで見るべき点です。逆に言えば、このカタログ配信が止まればツールの価値は大きく損なわれるため、プロジェクトの継続性はカタログ運用の継続性とほぼ同義になります。

価格・モデル一覧の最新情報は、FreeLLMAPI の公式サイトおよびモデルカタログのページで確認できます。なお公式サイトの表記（605 models）と README のカタログ数値（474 モデルファミリ / 635 エンドポイント）は集計単位が異なるため、比較する際は注意が必要です。

採用前に確認すべき限界とプロバイダー規約

FreeLLMAPI の公式ドキュメントは、自らの限界と規約上の位置づけを比較的率直に開示しています。採用可否の判断では、機能一覧よりもこちらを先に読むほうが結論が早く出ます。

公式が明示する6つの限界

公式ドキュメントの Limitations には、次の 6 点が挙げられています。

1. 上限になるのはモデルクラスではなく、クォータと可用性。カタログにはフロンティア級のモデルも無料枠として載りますが、それらは日次許容量が最小で、待ち行列が最長で、短い予告で撤去や有料化がされやすい行でもあります。得られないのは「モデルの性能」ではなく「持続的なアクセス」だと説明されています
2. 1 日が進むにつれて実効知能が下がる。上位モデルほど日次上限が低いため、上限に達するとルーターは優先度チェーンを下って小型・低性能なモデルへ落ちていきます。カウンタは UTC 0 時にリセットされます
3. レイテンシのばらつきが大きい。Cerebras や Groq のように極めて高速なプロバイダーもあれば、そうでないプロバイダーもあり、そのときに空いているほうが使われます
4. 無料枠は予告なく変わる。カタログ更新が届くまでのあいだ、429 や認証エラーが表面化します。ライブフィードで数日、無料インストールでは 30 日の遅延があります
5. 定義上 SLA がない。信頼性が必要な場面では、契約付きの有料プロバイダーを使うよう明記されています
6. ローカルファースト。マルチテナント認証を持たないため、自分用に動かし、インターネットへ露出させないことが前提とされています

2 番目の「時間帯によって実効知能が変動する」という性質は、評価やベンチマークの再現性を必要とする用途と根本的に相性が悪い点に注意が必要です。同じプロンプトを同じ設定で投げても、応答したモデルが違えば結果は変わります。

プロバイダー別ToSレビュー（2026年5月時点）

無料枠を束ねる構成でもっとも気になるのが、各プロバイダーの利用規約に照らして許容されるのかという点です。FreeLLMAPI の公式ドキュメントには、セルフホスト・単一ユーザー・個人利用という前提で 14 プロバイダーの規約を再レビューした表が掲載されています（2026 年 5 月時点）。

Cohere が ❌ Avoid と判定されている点、Google Gemini・NVIDIA NIM・GitHub Models・Cloudflare・Z.ai が ⚠️ に置かれている点は、実際に使うプロバイダーを選ぶ段階で効いてきます。とくに NVIDIA NIM と GitHub Models は、規約上「評価・実験・プロトタイピング」に用途が限定されており、たとえ技術的に接続できても、業務のワークロードを継続的に流す使い方は想定されていません。

同ドキュメントには、守るべき経験則として「プロバイダーごとに 1 アカウント」「再販しない」「エンドポイントを他人と共有しない」「有料の本番バックエンド代わりに無料枠を叩き続けない」の 4 点も挙げられています。また、2026 年 4 月のレビュー以降、Moonshot が有料のみに移行したこと、MiniMax が OpenRouter 経由のルートに置き換えられたことも記載されており、規約と提供状況が継続的に変動していることが読み取れます。

ここで必ず併記しておくべきなのは、この表が公式ドキュメント自身の但し書きどおり情報提供であって法的助言ではないという点です。判定は 2026 年 5 月時点のものであり、各プロバイダーの規約は改定されます。実際に使う前には、自分が契約するプロバイダーの最新の ToS を自ら読んで判断する必要があります。

公式ディスクレーマーが引く線

README の Disclaimer は、このプロジェクトの位置づけを明確に規定しています。要約すると、本プロジェクトは個人的な実験と学習のためのものであって本番用途ではないこと、無料枠は開発者がプロトタイプを作れるように存在するのであって安定してサポートされた推論基盤ではないこと、この上に実物を作るなら出荷前に有料 API へ差し替えるべきこと、そして各上流プロバイダーとの関係はアカウント作成時に受諾した条項に支配され、トラフィックが本プロジェクト経由になってもその条項は適用され、遵守の責任は利用者にあること、の 4 点です。

機能面の未対応項目も公式に列挙されています。モデレーション用の /v1/moderations、1 リクエストで複数補完を返す n > 1、そしてユーザー単位の課金とマルチテナント認証です。最後の項目は実装の遅れではなく、単一ユーザー前提という設計上の選択として説明されており、この点が次に述べる類似 OSS との違いに直結します。

類似OSSとの違い｜LiteLLM・one-api・OmniRoute・9router

「OpenAI 互換の 1 エンドポイントに複数プロバイダーを束ねる」という枠組み自体は、すでに複数の OSS が実現しています。用途ごとの使い分けを整理します。

5つのOSSの位置づけを比較する

数値はいずれも 2026 年 9 月 7 日時点のものです。なお README 自身は OpenRouter・LiteLLM・Portkey との機能比較を掲載していますが、OpenRouter と Portkey は OSS ではなくホスト型サービスであるため、本記事の類似 OSS 比較からは外しています。

LiteLLMとの違い

LiteLLM は、有料 API を含む多数のプロバイダーを OpenAI 形式で呼び出せるようにするゲートウェイで、仮想キーの発行、チームや部門ごとの予算管理、ガードレール、ロードバランス、監査といった本番運用の統制に重心があります。日本語での導入事例も複数公開されており、比較検討の情報は集めやすい部類です。

一方で LiteLLM は、「無料枠の在庫を追跡してフェイルオーバーする」という用途に最適化されているわけではありません。FreeLLMAPI 側の差分は、(platform, model, key) 単位で 4 種のクォータを持つ台帳と、無料枠の変動に追随する署名付きカタログ更新です。チームで本番運用するなら LiteLLM、個人が無料枠を使い切る用途なら FreeLLMAPI という整理が、選定の出発点になります。

one-apiとの違い

one-api は、LLM API の管理と二次配布を主眼に置いたシステムです。トークンの発行、ユーザー管理、課金といった機能を備えており、複数の利用者へ API を提供する運営者向けの設計になっています。

FreeLLMAPI はこの点で正反対です。マルチテナント認証を持たないことを設計上の選択として明言しており、公式ドキュメントも「エンドポイントを他人と共有しない」ことを前提としています。共有・再配布を行いたいのであれば、FreeLLMAPI は候補から外れます。

OmniRoute・9routerとの違い

OmniRoute と 9router は、いずれも同じカテゴリのローカル AI ゲートウェイです。

プロバイダーの網羅性という点では OmniRoute が上回り、352 プロバイダー・1200 以上のモデルを 1 エンドポイントに集約します。単純に選択肢の広さを求めるなら、こちらのほうが要件に合う場面があります。9router は、トークン消費を抑える機能と OAuth によるサブスクリプション接続に特徴があり、Claude Code や Cursor など複数のコーディングツールを併用している場合の使い勝手に軸足があります。

これらに対する FreeLLMAPI 固有の差分は、次の 3 点に集約されます。

1. Ed25519 署名付きモデルカタログを 1 日 2 回自動同期すること（無料枠の変動追随を配信基盤側で解く）
2. プロバイダー別の ToS レビューを公式に公開していること（規約上の線引きを利用者任せにしない）
3. (platform, model, key) 単位で RPM / RPD / TPM / TPD の 4 種クォータ台帳を持つこと

プロバイダー数や対応クライアント数で比べると FreeLLMAPI が突出しているわけではありません。差が出るのは「無料枠を継続的に使い続けたときに壊れにくいか」「規約上の判断材料が揃っているか」という運用面の観点です。

FreeLLMAPIの採用を検討できる場面と避けるべき場面

ここまでの整理を、採用判断の形に落とします。

検討できる場面

• 個人の技術検証やプロトタイプで、複数モデルの応答を横断的に試したい場合
• コーディングエージェント（Claude Code・Codex CLI・Aider など）を、有料プランの契約前に試用したい場合
• 新しいモデルが出るたびに感触を掴んでおきたく、そのための素振り環境が欲しい場合
• 同一プロンプトを複数モデルへ投げて出力を比較したい場合（fusion が該当します）
• ローカルモデル（llama.cpp・LM Studio・vLLM・Ollama）と無料枠を同じチェーンに並べて扱いたい場合

いずれも単一ユーザー・非本番という前提の上に成り立っています。

避けるべき場面

• 本番サービスのバックエンドとして使う場合（公式が明確に否定しています）
• チームで共有したり、社内へ配布したりする場合（マルチテナント認証がありません）
• SLA や再現性が必要な評価・ベンチマークを行う場合（時間帯によって応答モデルが変わります）
• ToS 判定が ⚠️ または ❌ のプロバイダーに依存する構成を組む場合
• 顧客データや機微情報を含むワークロードを扱う場合

採用前に確認する5項目

最後に、判断を進めるためのチェックリストとして次の 5 項目を挙げておきます。

1. その用途は、個人の実験・学習の範囲に収まっているか
2. 使う予定のプロバイダーについて、公式の ToS 判定を確認したうえで、最新の規約本文を自分で読んだか
3. 1 日の後半に実効的なモデル性能が落ちても、作業として許容できるか
4. カタログが 30 日遅れることを許容できるか。許容できない場合、Premium の費用を負担する前提を置けるか
5. v1.0 未満のプロジェクトであることを踏まえ、破壊的変更に追随する手間を見込めるか

このうち 2 番目は、技術的な適合性とは独立した確認事項です。ツールが接続できることと、規約上その使い方が許されていることは別問題であり、後者の判断は利用者側に残ります。

まとめ

FreeLLMAPI は、34 プロバイダーの無料枠を 1 つの OpenAI 互換エンドポイントに集約し、キー単位のクォータ台帳と自動フェイルオーバーで上限内に収めるセルフホスト型ルーターです。MIT ライセンスで公開され、2026 年 9 月 7 日時点でスター 24,573、最終 push は前日（2026 年 9 月 6 日）という活発な状態にあります。

一方で、この構成が提供するのは推論容量であって、モデル品質でも可用性でもありません。無料枠を束ねても、フロンティア級モデルへの持続的なアクセスは得られず、1 日の後半には実効的な性能が落ち、SLA は定義上存在しません。無料枠の集約は「量」を増やす手段であり、「質」や「安定性」を買う手段ではない、という理解が採用判断の前提になります。

選定の判断軸として、本記事で整理した 4 点を振り返っておきます。

1. 規約: 公式が公開する 14 プロバイダーの ToS レビューを起点に、使うプロバイダーごとに最新の規約を自分で確認する
2. 限界: クォータと可用性が上限であること、時間帯で実効性能が変動すること、SLA がないことを許容できるか
3. カタログ鮮度: 無料は 30 日遅れ。最新モデルを追う必要があるなら Premium の費用を織り込む
4. 類似 OSS の使い分け: チームの本番運用なら LiteLLM、二次配布なら one-api、プロバイダー網羅性なら OmniRoute、コーディングツールの併用なら 9router、無料枠の追随性と規約情報を重視するなら FreeLLMAPI

公式ドキュメントは、限界も規約上のリスクも自ら開示しています。その率直さ自体が、このプロジェクトを評価するうえでの材料になります。用途が個人の検証に収まり、上記 4 点を確認したうえであれば、有力な候補として検討できるでしょう。実際の導入判断にあたっては、FreeLLMAPI の README と公式ドキュメントを最新の状態で確認することをおすすめします。

関連情報

LLM を組み込んだ機能開発や、検証環境から本番環境への移行設計をご検討中の方は、お問い合わせフォーム からご相談ください。技術選定が固まっていない検討段階からのご相談も承っています。