クレカ不要の無料LLM APIを実運用する — レート制限の読み方とフォールバック設計

個人開発やプロトタイプでLLMを使いたいとき、最初の障壁は技術ではなく「支払い情報の登録」だったりします。とりあえず試したいだけなのにクレジットカードを求められる、社用カードは通したくない、うっかり従量課金が爆発するのが怖い——そんな理由で手が止まるのはもったいない。

幸い2026年現在、クレジットカード登録なしで使えるLLM APIの無料枠は珍しくなくなりました。ただし「無料枠があるらしい」で終わらせると、実際に動かした瞬間に 429 Too Many Requests に殴られて終わります。この記事では、無料枠を実運用に耐える形で使うために、レート制限の読み方と、複数プロバイダを束ねるフォールバック設計を整理します。

「無料枠でどこまで行けるのか」の現実感

先に結論を書くと、個人の実験・プロトタイプ・社内ツール程度なら、無料枠だけで十分に回ります。一方で、不特定多数に公開するサービスのバックエンドを無料枠だけで支えるのは現実的ではありません。無料枠は「安いプラン」ではなく「予告なく変わる恩恵」だからです。

この前提を置いた上で、無料枠が向いている用途は次のあたりです。

アイデア検証、プロンプトの試行錯誤
個人用の自動化スクリプト、定期バッチ、要約パイプライン
開発中のアプリのバックエンド（本番前）
低頻度・非同期でよい社内向けツール

逆に、レイテンシSLAが必要、機密データを扱う、月間リクエストが数十万規模、といった条件がひとつでも入るなら、素直に有料プランを検討したほうが総コストは安くつきます。

プロバイダを比較する軸は「モデル名」ではない

無料LLM APIの比較記事はたいてい「使えるモデル一覧」で終わりますが、実運用で効いてくるのはむしろ次の5点です。

レート制限の構造（後述。単一の数字ではありません）
OpenAI互換APIかどうか — 互換なら差し替えが数行で済みます
データの取り扱い — 無料枠は入力データを学習に利用する規約になっていることがあります
モデルの入れ替わり頻度 — 無料枠のモデルは予告なく終了・置換されがちです
可用性の実感値 — 無料枠は混雑時に真っ先に絞られます

特に2番目は設計に直結します。主要な無料プロバイダの多くがOpenAI互換のエンドポイントを提供しているため、クライアント側を互換インターフェースに寄せておくだけで、後述のフォールバックが「ベースURLとAPIキーとモデル名の差し替え」に単純化できます。ここを最初にやっておくかどうかで、後の作業量が一桁変わります。

クレカ不要で使える主要プロバイダの傾向

調査時点で、クレジットカード登録なしに使える代表的な選択肢には次のようなものがあります（具体的な制限値は頻繁に変わるため、必ず公式ドキュメントで確認してください）。

プロバイダ	特徴
高速推論系サービス	独自ハードで推論が非常に速い。オープンウェイト系モデル中心で、分あたりトークン数が比較的潤沢
大手クラウドのAI API	無料枠が用意されており、マルチモーダル対応も含めて機能が広い
GPUベンダー系の推論サービス	多数のオープンモデルをホスト。検証用途に向く
モデルアグリゲータ／ルーター	1つのキーで多数のモデルにアクセスでき、無料枠のモデルも選べる
無料APIゲートウェイ系	OpenAI互換で複数モデルをまとめて提供する

さらに、無料で使えるLLM APIを収集・一覧化したディレクトリ的なサイトやリポジトリも複数存在し、200を超えるエンドポイントがまとめられています。ただし、この手の一覧は鮮度が命です。掲載されていても既に終了している、無料枠が有料化された、といったケースは日常茶飯事なので、一覧は「候補を知る入口」として使い、採用判断は必ず一次情報で行うのが安全です。

重要なのは、どれか1社を選ぶことではなく、2〜3社を同時に用意しておくことです。理由は次のセクションにつながります。

レート制限は「1つの数字」ではない

無料枠の紹介記事では「毎分3万トークンまで無料」のように単一の数字が強調されがちですが、実際のレート制限はたいてい複数の軸の論理積です。

RPM（requests per minute）— 分あたりのリクエスト数
TPM（tokens per minute）— 分あたりのトークン数（入力＋出力の合算が普通）
RPD / TPD — 日あたりの上限。これが実質的な天井になることが多い
同時実行数 — 並列リクエストの本数
モデル単位の制限 — 大きいモデルほど厳しい

つまり「毎分3万トークン」を謳っていても、RPMが小さければ短いリクエストを大量に投げる用途では先にRPMで詰まります。逆に長文要約のような用途ではTPMが先に効きます。自分のワークロードがどの軸に当たるのかを最初に見積もるのが、無料枠を使いこなす最初のコツです。

もうひとつ見落としがちなのが、日次上限のリセット時刻です。UTC基準でリセットされることが多く、日本時間の午前中に上限に当たると夕方まで回復しない、という事故が起きます。バッチ処理を組むときはリセット時刻を意識してスケジュールしましょう。

そして、429が返ってきたときは推測でリトライせず、Retry-After ヘッダや x-ratelimit-* 系のレスポンスヘッダを読むこと。多くのプロバイダが残量とリセットまでの秒数を返しており、これを使うだけでリトライの精度が段違いになります。

フォールバック構成の組み方

無料枠を実用にする本命がこれです。単一プロバイダに依存すると、レート制限・障害・モデル終了のいずれか一発で止まります。複数プロバイダを並べ、失敗したら次に流す構成にしておけば、無料枠のまま可用性を実用レベルまで引き上げられます。

設計の原則

優先順位をつける: 速度・品質・制限のバランスで1軍〜3軍を決める
同質なモデルを揃える: フォールバック先が極端に弱いと、落ちたときに出力品質が崩壊します
フォールバック契機を区別する: 429（レート制限）はリトライ価値あり、401（認証）は即座に次へ、500系は短いバックオフ後にリトライ
指数バックオフ＋ジッタ: 固定間隔リトライは同時多発時に自分で自分を殴ります
プロンプトを共通化する: プロバイダごとにプロンプトを分岐させると保守が破綻します

最小構成の例

考え方が伝わればよいので、素朴に書くとこうなります。

import time, random
from openai import OpenAI

# OpenAI互換エンドポイントを優先度順に並べる
PROVIDERS = [
    {"base_url": "https://api.provider-a.example/v1", "key": KEY_A, "model": "model-a"},
    {"base_url": "https://api.provider-b.example/v1", "key": KEY_B, "model": "model-b"},
    {"base_url": "https://api.provider-c.example/v1", "key": KEY_C, "model": "model-c"},
]

def chat(messages, max_retries=2):
    last_error = None
    for p in PROVIDERS:
        client = OpenAI(base_url=p["base_url"], api_key=p["key"])
        for attempt in range(max_retries):
            try:
                return client.chat.completions.create(
                    model=p["model"], messages=messages, timeout=30
                )
            except Exception as e:
                last_error = e
                status = getattr(e, "status_code", None)
                if status in (401, 403, 404):
                    break  # 設定の問題。リトライしても無駄なので次のプロバイダへ
                # 429 / 5xx: 指数バックオフ + ジッタ
                time.sleep((2 ** attempt) + random.random())
    raise RuntimeError(f"all providers failed: {last_error}")

これで十分動きますが、プロバイダが増えてきたらルーティング用のライブラリやゲートウェイを噛ませるほうが現実的です。フォールバック、リトライ、コスト計測、モデル名の正規化といった定型処理を設定ファイルで宣言でき、アプリ側のコードは単一のエンドポイントを向くだけになります。

落とし穴

コンテキスト長の差: フォールバック先のほうが短いと、長い入力で必ず失敗します。最小公倍数ではなく最小値に合わせて入力を切り詰めるか、長文時はプロバイダを選別する
機能の差: 関数呼び出し（tool use）、JSONモード、ストリーミングの対応可否はモデル・プロバイダで揃いません。使う機能に対応した組み合わせだけをフォールバック候補にする
無限リトライ: 全プロバイダが枯渇したときに素早く諦める設計にしておかないと、呼び出し元がタイムアウトまで固まります

無料枠を使い切らないための工夫

フォールバックは「上限に当たった後」の話ですが、そもそも上限に当たりにくくする工夫のほうが効果的です。

キャッシュする: 同じ入力に対する応答をローカルにキャッシュするだけで、開発中の消費は劇的に減ります。プロンプトのハッシュをキーにすれば十分
モデルを階層化する: 分類・抽出・整形のような単純タスクは小さいモデルに回し、生成品質が要るところだけ大きいモデルを使う
プロンプトを削る: 無料枠は入力トークンも消費します。冗長なfew-shotや貼りっぱなしのコンテキストは、そのまま制限の消費です
バッチと非同期化: リアルタイム性が不要な処理は日次バッチに寄せ、制限の谷間に流す
観測する: 消費トークン数とエラー種別をログに残す。どの軸で詰まっているか分からないと改善のしようがありません

注意しておくべきこと

最後に、無料枠を使う上での現実的なリスクを挙げておきます。

データの扱い: 無料枠では入力データがモデル改善に利用される規約になっていることがあります。個人情報や秘密情報を通すなら、規約の確認は必須です
商用利用の可否: 無料枠でも商用可のところ、不可のところがあります
SLAはない: 無料枠に可用性の保証はありません。止まっても文句は言えない前提で組む
仕様変更の速さ: 制限値もモデルラインナップも数ヶ月で変わります。数値をコードにハードコードせず設定に追い出しておく
キーの管理: 無料だからと気を抜かず、環境変数やシークレット管理に置く。リポジトリへの混入はよくある事故です

まとめ

クレジットカード不要の無料LLM APIは、2026年時点で選択肢が十分に揃っています。ただし価値を引き出せるかどうかは、プロバイダ選びよりも設計側にかかっています。

無料枠の制限は単一の数字ではなく、RPM・TPM・日次上限・同時実行数の組み合わせ。自分のワークロードがどの軸に当たるかを先に見積もる
クライアントをOpenAI互換に寄せ、2〜3社を優先度順に並べたフォールバックを組む。これだけで可用性が実用レベルに乗る
429は指数バックオフ＋ジッタで、認証エラーは即座に次へ。レスポンスヘッダの残量情報を活用する
キャッシュ・モデル階層化・プロンプト削減で、そもそも上限に当たりにくくする
無料枠はデータ利用規約とSLAなしの前提を受け入れた上で使う

「無料で使える」の先にある、「無料のまま落ちない」構成まで作り込んでおくと、個人開発の体験は驚くほど快適になります。まずは手元のスクリプトを互換インターフェースに寄せるところから始めてみてください。