2026年のFrankfurter API代替案：開発者のための正直な比較

Frankfurter API の代替案を探しているなら、すでにそれを使って何かをリリースしている可能性が高いでしょう。Frankfurter は、ある世代の個人プロジェクトにとって標準的な無料為替レート API です。API キー不要、登録不要、クォータなし、きれいな REST インターフェース、そして一晩で読み切れるオープンソースのコード。ところが何かが変わります——コンプライアンス上の疑問、週末だけ出るバグ、日中レートを必要とする顧客——そして他に何があるのかと考え始めるわけです。

このガイドは、その判断を正直に見つめ直すものです。2026 年の Frankfurter が実際に何をするのか（比較記事の多くは古い情報のままです）、チームを離脱させる 5 つの具体的な限界、そして現実的な 3 つの道筋——セルフホストする、キー付きの商用 API に移る、ハイブリッドで運用する——を扱います。最後に移行のコード例を載せています。

2026年の Frankfurter は実際どういうものか

「無料通貨 API のおすすめ」系の記事はいまだにほぼすべてが、Frankfurter を「ECB のレート、約 30 通貨、週末データなし」と説明しています。それは何年も事実でしたが、もう正確ではありません。

frankfurter.dev の v2 API は 84 の中央銀行の日次レートを追跡し、201 通貨をカバーし、履歴は 1948 年まで遡ります。商用利用も本当に無料で、認証は不要、月間・日次のクォータは公表されておらず、JSON に加えて CSV と NDJSON の出力も備えます。OpenAPI 仕様、llms.txt、エージェント向けの MCP サーバーもあります。Docker でセルフホストも可能です。

これは各種まとめ記事が認めている以上に強力なプロダクトであり、はっきり言っておく価値があります。多くのプロジェクトにとって Frankfurter は正解であり、移行すべきではありません。 家計簿トラッカー、通貨のリファレンスページ、1 日 1 回レートを確定する請求書ツール、10 年分の月次平均を取得するデータ分析ノートブックを作っているなら、Frankfurter はそれを立派にこなし、しかも無料です。

この記事の残りは、それでは足りないケースについてです。

チームが Frankfurter API の代替案を探し始める5つの限界

1. 日次の参照レートはライブのレートではない

これは構造的な限界で、欠陥ではありません——データソースがそういうものだというだけです。中央銀行の参照レートは営業日ごとに 1 回公表されます。たとえば ECB は、各営業日の中央ヨーロッパ時間 16:00 頃にユーロ参照レートを公表します。Frankfurter はその数値を忠実に公開しています。

つまり、09:00 に取得したレートと 15:00 に取得したレートは、その間に市場が 1.2% 動いていても同じ数字です。表示専用のコンバーターなら誰も気づきません。しかし決済ページ、支払い額の計算、あるいは顧客があなたの数値を Google と見比べるような場面では、その遅延はサポートチケットになります。

日中に動くレートが必要なら、参照レートのソースではなく市場データのソースが必要です。Finexly API は市場時間中は毎分更新され、170 以上の通貨をカバーします。これは同じものの改良版ではなく、別のデータモデルです。この違いは為替レート API はどこからデータを得ているのかで詳しく説明しています。

2. 週末と祝日の行が存在しない

中央銀行は土曜・日曜・国の祝日には公表しません。したがって 2026-08-23 を照会しても有用なものは返らず、1 か月の時系列はおよそ 21 行であって 31 行ではありません。

どのチームも同じ形でつまずきます。夜間ジョブが日曜に走り、空またはずれた結果を受け取り、クラッシュするか——さらに悪いことに——静かに null を元帳に書き込むのです。中央銀行由来の日次レートの上に構築するなら、明示的な前方補完のポリシーが必要で、しかもそれを文書化する必要があります。「直近に公表されたレートを使う」と「その行を飛ばす」とでは、出来上がる財務諸表が変わるからです。

3. ブレンドされたレートは公表後に変わりうる

デフォルトでは、Frankfurter は寄与するすべてのプロバイダのレートをブレンドします。その帰結について、公式 FAQ は清々しいほど率直です。新しいデータが入るにつれて末尾の小数桁が動くことがあり、コンプライアンス目的なら特定のプロバイダに絞るべきだ、と。

一般用途としては完全に妥当な設計です。問題になるのは、レートを保存してユーザーに表示し、後で再取得と突き合わせる場合です。監査人に説明するのが非常に難しい微小な差異が見つかります。Frankfurter 側の対処は、ブレンドを受け入れるのではなく providers=ECB（またはあなたを規制する当局）を渡すことです。自分のシステム側の対処は、取引時点で実際に使ったレートを永続化し、二度と再導出しないことです。この原則はどのプロバイダにも当てはまり、為替レートと税務申告のガイドで扱っています。

4. API キーがない＝クォータもなく、可視性もない

「API キー不要」は Frankfurter の最良の特徴であり、同時に最も過小評価されたリスクです。キーがないということは：

• アプリケーション単位のクォータがありません。今まさに雑なループで叩いている誰かも含め、インターネット全体と公開のレートリミッタを共有します。
• 利用のテレメトリがありません。先週火曜に呼び出し量が 3 倍になったと教えてくれるダッシュボードは存在しません。
• サポート関係がありません。ステータスページと GitHub の Issue トラッカーはあり、多くの無料サービスより手厚いくらいですが、SLA はなく、呼び出せる担当者もいません。

プロジェクト自身の案内も明確です。大量利用ならレスポンスをキャッシュするか、セルフホストするか、データセットを直接参照せよ、と。これは正直な助言であり、同時に多くのチームが Frankfurter API の代替案を評価し始める瞬間でもあります。データが間違っているからではなく、契約の裏付けのない本番依存を抱えてしまったからです。

5. 変換用エンドポイントがない

Frankfurter はこれを意図的に文書化しています。レートを取得して掛ければよい、と。たしかに 3 行のコードです。

しかしその 3 行は、コードベースの 6 か所で微妙に違う書き方をされ、そのうち 1 か所では掛けるべきところで割っているものです。専用の convert エンドポイントは技術的必然ではありません。丸めと方向のルールの実装をちょうど 1 つに保つための手段です。EUR→USD と USD→EUR が 0.3% ずれるバグを出した経験があれば、これが重要な理由はわかるはずです。この地雷原の残りは通貨の丸めと小数桁のガイドで扱っています。

Frankfurter API の代替案を比較する

以下の無料枠の内容は、執筆時点で各プロバイダが公開していたものです。採用を決める前にご自身で確認してください——無料枠はドキュメントより頻繁に変わります。

目立つ点が 2 つあります。第一に、クォータで Frankfurter に勝てるところはありません。そもそもクォータが存在しないからです。日次レートに対する純粋な呼び出し量が制約なら、答えはよそで小さいクォータを買うことではなく、Frankfurter をセルフホストすることです。第二に、有料の選択肢は同じデータを見栄えよく包んで売っているのではありません。売っているのは異なる更新頻度とサポート関係です。そのどちらもあなたの課題でないなら、乗り換えは後退です。

いくつかは通貨 API の比較とリアルタイム為替レート API の比較で並べて解説しています。

選択肢1：Frankfurter をセルフホストする

最も使われていない答えです。Frankfurter は Docker イメージを公開しており、自分で動かせば本番チームが本当に心配する 2 点——共有レートリミッタと統制の欠如——が消えます。

docker run -d -p 8080:8080 --name frankfurter \
  lineofflight/frankfurter

得られるもの：無制限の内部呼び出し、自分で握る可用性、そしてプロバイダを固定できること。引き受けるもの：コンテナ、データベース、監視、そして銀行休業日に上流の収集が壊れたことに気づく担当者。これは実在するコストです——他人がすでに書いたコードに対して適用した、自作か購入かの分析そのものの議論です。

セルフホストが正解なのは、量が多く、レイテンシ要件が厳しく、日次の参照レートで本当に足りる場合です。日中レートが必要という問題にはまったく効きません——同じ日次データの自前コピーを動かすだけになります。

選択肢2：日中レートを持つキー付き API に移る

ここへ来た理由がレートの鮮度、エキゾチック通貨ペアのカバー、あるいはメールに返信してくれる相手が必要、というものなら、キー付きの商用 API が正直な答えです。

同じ処理を両者で書くとこうなります。まず Frankfurter：

curl "https://api.frankfurter.dev/v2/rate/USD/EUR"

そして Finexly の等価な書き方：

curl -H "Authorization: Bearer YOUR_API_KEY" \
  "https://api.finexly.com/v1/rate?from=USD&to=EUR"

{ "pair": "USD_EUR", "rate": 0.9215 }

エンドポイントの対応表

形が最も変わるのは複数ペアの呼び出しです。Frankfurter は 1 つの基準通貨と相手通貨のリストを使いますが、Finexly は明示的な BASE_QUOTE ペアのリストを取ります。おかげでクロス計算なしに、同一リクエストで USD_EUR と GBP_JPY を取得できます。

移行用のラッパー

新しいクライアントをコードベース中に撒き散らさないでください。両方を 1 つのインターフェースの背後に置けば、戻すのは設定変更だけで済みます：

import os
import requests

FINEXLY_KEY = os.environ["FINEXLY_API_KEY"]

def get_rate(base: str, quote: str, provider: str = "finexly") -> float:
    """Return the mid-market rate for base->quote."""
    if provider == "frankfurter":
        r = requests.get(
            f"https://api.frankfurter.dev/v2/rate/{base}/{quote}",
            timeout=5,
        )
        r.raise_for_status()
        return float(r.json()["rate"])

    r = requests.get(
        "https://api.finexly.com/v1/rate",
        params={"from": base, "to": quote},
        headers={"Authorization": f"Bearer {FINEXLY_KEY}"},
        timeout=5,
    )
    r.raise_for_status()
    return float(r.json()["rate"])

print(get_rate("USD", "EUR"))

真似する価値のある細部が 2 つ。API キーは環境変数から取り、ソースには決して書きません——Finexly のドキュメントは、クエリパラメータで渡したキーがサーバーのアクセスログや HTTP Referrer ヘッダーから漏れうると注意しており、本番では Authorization ヘッダーが正道です。そして各呼び出しにタイムアウトを設けています。多くの HTTP クライアントの既定値は「永遠に待つ」だからです。

レスポンスヘッダーの X-RateLimit-Limit、X-RateLimit-Used、X-RateLimit-Units を監視すれば、クォータ消費をリアルタイムで把握できます。このテレメトリこそ、認証のない API からは得られないものであり、しばしばチームが移行する本当の理由になります。

選択肢3：ハイブリッド——片方をキャッシュし、もう片方にフォールバック

多くの本番システムが行き着くパターンです。主たるプロバイダを使い、積極的にキャッシュし、無料で認証不要の API を最後の手段として残します：

const CACHE = new Map();
const TTL_MS = 60_000;

async function getRate(base, quote) {
  const key = `${base}_${quote}`;
  const hit = CACHE.get(key);
  if (hit && Date.now() - hit.at < TTL_MS) return hit.rate;

  let rate;
  try {
    const res = await fetch(
      `https://api.finexly.com/v1/rate?from=${base}&to=${quote}`,
      { headers: { Authorization: `Bearer ${process.env.FINEXLY_API_KEY}` } }
    );
    if (!res.ok) throw new Error(`HTTP ${res.status}`);
    rate = (await res.json()).rate;
  } catch (err) {
    // Degrade to daily reference rates rather than failing the request
    const res = await fetch(`https://api.frankfurter.dev/v2/rate/${base}/${quote}`);
    rate = (await res.json()).rate;
  }

  CACHE.set(key, { rate, at: Date.now() });
  return rate;
}

月 1,000 リクエストの無料プランに 60 秒のキャッシュを載せれば、小規模アプリは余裕でまかなえます。呼び出し量がトラフィックではなく時間の関数になるからです。フォールバックしたレスポンスはログで印を付けておきましょう。昨日のレートへの静かな劣化が 1 週間気づかれない、という事態を防げます。TTL の選び方とリトライの挙動はキャッシュとエラー処理のガイドに詳しく書いています。

判断チェックリスト

上から順に見て、最初の「はい」で止まってください：

1. 取引時間中にレートが動く必要があるか？ → 参照レートではなく市場データ API が必要です。
2. 規制対象または監査対象のフローか？ → 特定のプロバイダに固定し、使ったレートを保存し、二度と再導出しない。
3. 呼び出し量は多いが日次レートで足りるか？ → Frankfurter をセルフホストする。
4. 壊れたときに応答してくれる相手が必要か？ → キーとサポート等級のある有料プランが必要です。
5. どれも当てはまらない？ → Frankfurter のままで。キャッシュし、週末の穴を処理し、時間は他に使いましょう。

Frankfurter API の代替案を探しに出たチームの多くは、ステップ 5 で、本当の問題がキャッシュの欠如と未処理の日曜日だったと気づきます。

よくある質問

Frankfurter API は本当に商用利用も無料ですか？ はい。プロジェクトは商用利用も無料で、月次・日次のクォータはないと明言しています——リクエスト制限は濫用防止のためだけです。引き換えに SLA もサポート契約もないため、リスクは利用者側が負います。

Frankfurter は ECB のレートだけですか？ もう違います。v2 API は 84 の中央銀行、201 通貨のデータをブレンドしており、providers パラメータで単一ソースに絞れます。広く出回っている「ECB のみ・30 通貨」という説明は旧バージョンのものです。

なぜ Frankfurter は週末にデータを返さないのですか？ 中央銀行が非営業日に参照レートを公表しないからです。中央銀行データに基づく API はどれも同じ穴を持ちます。直近に公表されたレートで前方補完するか、連続的に建値される市場データソースを使うかのどちらかです。

Frankfurter の最良の無料代替は何ですか？ 「無料」に何を求めるか次第です。無制限の日次レートなら Frankfurter に勝るものはありません——セルフホストしましょう。日中更新と本物の API キーを備えた無料枠なら、Finexly の無料プランが 170 以上の通貨で月 1,000 リクエストを提供します。全体像は無料通貨 API ガイドをご覧ください。

Frankfurter と有料 API を併用できますか？ できますし、理にかなった構成です。通常のトラフィックは主プロバイダに流し、エラー時に Frankfurter へフォールバックする——上のハイブリッド例の通りです。ただしフォールバックしたレスポンスは必ずログに残してください。鮮度の保証が異なるためです。

はじめる

作っているものに日次の参照レートで足りるなら、Frankfurter のままで結構です——良いプロジェクトですし、費用もかかりません。日中に動くレート、中央銀行の参照セットを超えるカバー範囲、あるいは実際に監視できる利用状況ヘッダーが必要なら、無料の Finexly API キーを取得してください——クレジットカードは不要です。170 以上の通貨で月 1,000 リクエストから始めて、成長に合わせてアップグレードできます。まずは料金ページでプランを比較するのもおすすめです。