2026年、無料の為替レートAPIを比較する方法

ほとんどの無料為替レートAPIは表面上似通って見える — JSON、ベアラートークン、通貨は100種類ほど。実際のプロジェクトで問題になる違いは、ある日次フィックスと次のフィックスの間、制限に達したときのエラーメッセージ、そして深夜3時にコードが信頼せざるを得ないフィールドの中に現れる。ブランドのランキングではなく、軸で選ぶこと。

なぜ軸がランキングに勝るのか

ランク付けされたAPIリストは、著者がそれを書いた日にどれを好んだかを教えてくれるだけだ。軸ごとの分解は、どれが自分のプロジェクトに合うかを教えてくれる。1日1回の参照データしか消費しないダッシュボードと、日中ずっと価格を提示する旅行アプリとでは、必要なものが異なる。

以下の6つの軸は、ほぼすべてのFX統合で出てくる問いをカバーしている。順番に検討していけば、たいていのプロジェクトは終わる前に明確な答えを得られるはずだ。

軸1: 無料の月間クォータとレート制限

クォータは、プロトタイプを作り、小規模な本番ワークロードを無料で動かせるか、それとも1週間で壁にぶつかるかを左右する。レート制限は、初日からリトライロジックを書かずにバッチジョブでコールをバーストできるかを左右する。

ECBは自身の参照レートを無料かつクォータなしで公表している。トレードオフは、それが開発者向けAPIではなく生のXMLフィードであり、営業日ごとに1回しか更新されないことだ。オープンソースのFrankfurterプロジェクトは、ECBデータをキー不要・強制クォータなしのJSON APIでラップしているが、1日1回の更新頻度は引き継いでいる。

もう一つ、キー不要の第3のカテゴリを知っておく価値がある：fawazahmed0/exchange-apiのような、コミュニティ運営でCDNホスティングの静的JSONプロジェクトだ。リクエストに応答するサーバーはそもそも存在せず、jsDelivrやCloudflare Pagesから配信されるバージョン管理されたJSONファイルがあるだけで、毎日更新され、200種類以上の通貨（一般的な暗号通貨を含む）をCC0パブリックドメインライセンスでカバーし、キーも強制レート制限もない。トレードオフはアーキテクチャ上のものだ — sourceや鮮度メタデータがなく、換算エンドポイントもなく、ライブの日中更新もなく、ミラーがダウンしたときに責任を負う単一の主体もない — このプロジェクト自身のドキュメントも、まさにその理由から2つのCDNホスト間でフォールバックを組むことを推奨している。

キー不要の出発点として、exchangerate.devはIPアドレスごとに上限を設けた匿名コールを受け付ける。カード不要で/signupから取得できる無料キーを使うと、月10,000コール、毎分12リクエストまで上がる。

軸2: 日中の鮮度

これは、何かが壊れるまでほとんどの開発者が考えない軸だ。ECB参照フィックスは営業日ごとにCET16:00頃に公表される — それ以降、市場は動き続けるがフィックスは翌営業日まで更新されない。そのフィックスのみをソースとするAPIは、午後の残り、夜間、週末を通じて前日のレートを返し続ける。

1日1回のクローズレートしか消費しないパイプラインならそれで問題ない。しかし、消費者向けアプリ、eコマースサイト、あるいは「latest」が現在の市場を意味すると期待するあらゆるコードにとっては、そのレートが日中の変動を反映しているのか、最大24時間前のフィックスなのかを知る必要がある。

exchangerate.devには取引週を通じて約60秒ごとに更新されるliveソースがある。あるペアがそのソースから来ている場合、market_sessionは現在のセッション状態（open、weekendなど）を教え、data_updated_atはレートが最後に動いた正確な時刻を確認させてくれる。

軸3: 鮮度メタデータ

レートはただの数値だ。その数値が3分前のスポット集約なのか、昨日の朝の参照フィックスなのかを知ることで、それを責任を持ってどう扱えるかが変わる。

ほとんどのAPIはタイムスタンプを返す。それはレスポンスがいつ構築されたかを教えるだけで、元のデータがいつ最後に動いたかは教えない。exchangerate.devは、合わせて本当の問いに答える2つのフィールドを返す：

• source：live（集約スポット）、ecb_daily（ECB参照フィックス）、fred_daily（米連邦準備制度の日次系列）のいずれか。
• market_session：open、weekend、interbank_closedのいずれか。銀行間取引週の状態を示す。
• data_updated_at：元のレートが最後に書き込まれた時刻。レスポンスが構築された時刻であるtimestampとは別。
• is_forward_filled：履歴およびレンジのレスポンスで、trueはその日にレートが公表されず、前の値が持ち越されたことを意味する。

timestampではなくdata_updated_atを確認するキャッシュ層は、ユーザーに古いデータを配信することを避けつつ、不要な上流コールも避けられる。

軸4: 履歴の深さ

日次履歴は、データセットをバックフィルできるか、過去1年のチャートを作れるか、10年分のレートで回帰分析を回せるかを左右する。無料APIの中には履歴を90日に制限しているものもあれば、より深い履歴を有料プランの背後に置いているものもある。

exchangerate.devは無料枠でも1999年までの日次履歴を公開している。単一の日付指定パス/v1/2024-01-15/USDはその日のレートを返す。start_dateとend_dateパラメータを持つ/v1/rangeエンドポイントは、1回のコールで完全な系列を返す。これらの履歴データの裏付けとなるのはECBのEXRシリーズとFREDデータであり、カバレッジはそれらの機関が公表してきた内容と一致する。

軸5: 組み込みの換算エンドポイント

多くのAPIはレートの表を返し、掛け算は呼び出し側に任せる。単一ペアならそれで問題ないが、バッチ換算ジョブやカート合計額を換算するチェックアウトフローには、算術ヘルパーではなく換算のプリミティブが必要だ。

GET /v1/convert/USD/EUR/100は1回のコールでrate、converted、derivedを返す。POST /v1/convertエンドポイントは1回のリクエストでバッチ換算を処理する。互いに直接クォートされていないペアである三角測量クロスも、サーバー側で処理される。

軸6: エージェントとMCP対応

LLMエージェントやAIアシスタントがAPIを確実に呼び出すには、構造化されたツール定義が必要だ。生のREST APIではそのグルーコードを自分で書く必要があるが、MCPサーバーはツール定義をAPIと一緒に出荷する。

exchangerate.devはhttps://api.exchangerate.dev/v1/mcp（サーバー名exchangerate-dev）でModel Context Protocolサーバーを稼働している。5つのツールを公開する：list_currencies、get_rate、convert、get_range、search_docs（FAQ検索）。ツールはREST APIと同じ月間クォータと毎分制限を共有するため、別途追跡すべき課金はない。

6つの軸を並べて見る

自分に合うものを選ぶ

プロジェクトが1日1回のクローズレートしか必要とせず、鮮度メタデータも不要で、生のECB XMLフィードを取得することを気にしないなら、Frankfurterは無料でかなりの範囲をカバーする。よく保守されたオープンソースプロジェクトであり、妥当な出発点だ。

日中の鮮度（ECBフィックスの時点だけでなく、日中動くレート）が必要な場合、レスポンスにsourceとmarket_sessionが欲しい場合、ECBフィードから簡単に得られる範囲を超える履歴が必要な場合、あるいはFXツールを呼び出すLLMエージェントを構築している場合は、exchangerate.devがそうしたケース向けに設計されている。無料枠にカードは不要で、MCPサーバーも含まれる。