public-apisで個人開発の無料APIを探す方法と選定基準

個人開発のアイデアを形にしようとしたとき、「外部データを扱う無料 API を組み込みたいが、どこから探せばよいか分からない」という悩みは珍しくありません。カテゴリ横断で「まず候補一覧を眺めたい」ニーズに対して、GitHub 上で圧倒的なスターを集めているのが本記事で扱う public-apis/public-apis です。

一方で、40 万を超えるスターの数字だけでは「今もメンテナンスされているのか」「40 万人が使い方に合意しているのか」までは判断できません。実際、README は 1 万行を超えるカタログで、初見では「どこから読めばよいか」「Auth / HTTPS / CORS の列を個人開発視点でどう読み解けばよいか」が分かりにくい構造になっています。

さらに、無料 API カタログというジャンルには類似リポジトリが複数存在します。JSON エンドポイントで機械的に検索できる public-api-lists、API に限定せず SaaS/PaaS の無料枠までカバーする ripienaar/free-for-dev など、目的次第で最適な選択肢が変わります。「どれを見るのが自分のケースに合っているか」を根拠を持って決められることが、時間を無駄にしない鍵です。

本記事では、public-apis/public-apis の README と公式検索サイト publicapi.dev を一次情報として、リポジトリの全体像・カテゴリ構造・テーブル 5 列の読み方・類似 OSS との棲み分けまでを整理します。技術検証や環境構築は行わず、公式ドキュメントに書かれている事実のみをベースに、初見のエンジニアが「採用可否」と「絞り込み手順」を短時間で判断できる材料をまとめます。

public-apis リポジトリの全体像とメンテナンス状況

まず、初見で最も気になる「リポジトリ自体が今も健全に更新されているのか」を、GitHub API の生値と README の記述で確認します。本記事の数値は執筆時点で GitHub API 経由で取得した値であり、リアルタイムのスター数・フォーク数とは差異が生じる可能性があります。

基本メタデータ

public-apis/public-apis の基本メタデータは以下のとおりです（GitHub リポジトリ の公開情報より）。

40 万を超えるスターは GitHub 全体でも屈指の規模で、無料 API カタログというジャンルでは事実上のデファクトです。主要言語が Python になっていますが、これは README を検証・整形するスクリプトが Python で書かれているためで、カタログ本体は Markdown ベースの README です。

archived（アーカイブ済み）でも fork（他リポジトリのフォーク）でも disabled（GitHub 側で無効化）でもなく、最終 push が執筆時点の直近日付になっている点は、「40 万スターだが放置されていないか」への直接的な回答になります。ライセンスは MIT なので、カタログ情報の再利用や派生プロジェクトの作成に対して開放的です（各 API 個別の利用規約はそれぞれの提供元に従う必要があります。この点は「コントリビュート方法とライセンス上の注意」の章で改めて触れます）。

メンテナンス体制と APILayer との関係

README の冒頭には、API プロバイダーである APILayer 社のスポンサー枠が配置されています。IPstack・Marketstack・Weatherstack・Numverify・Fixer・Aviationstack・Zenserp・Filestack・Screenshotlayer・Exchangerate Host・Mailboxlayer など、同社が提供する API 群が README トップに列挙されており、これらは商用サービスへの導線です。

一方、README の中盤以降に続く 50 カテゴリのカタログ本体は、コミュニティからの Pull Request によって追加・更新されています。README 内には Discord サーバーへのリンクも用意されており、更新方針や PR レビューに関する議論はコミュニティ側で行われる構造です。

つまり、リポジトリ全体は「上部の APILayer プロモーション枠」と「中盤以降のコミュニティメンテのカタログ本体」の二層構造になっています。個人開発者が本記事のテーマとして参照するのは主に後者で、上部のプロモーション枠は「同ジャンルの商用 API がまとまって紹介されているセクション」と割り切って読むと理解しやすくなります。

50 カテゴリの目次構造と代表カテゴリの探し方

public-apis の README は、「Index」節に配置された 50 カテゴリの目次から始まる構造になっています（README の Index 節）。

Index に列挙されているカテゴリは、Animals / Anime / Anti-Malware / Art & Design / Authentication & Authorization / Blockchain / Books / Business / Calendar / Cloud Storage & File Sharing / Continuous Integration / Cryptocurrency / Currency Exchange / Data Validation / Development / Dictionaries / Documents & Productivity / Email / Entertainment / Environment / Events / Finance / Food & Drink / Games & Comics / Geocoding / Government / Health / Jobs / Machine Learning / Music / News / Open Data / Open Source Projects / Patent / Personality / Phone / Photography / Programming / Science & Math / Security / Shopping / Social / Sports & Fitness / Test Data / Text Analysis / Tracking / Transportation / URL Shorteners / Vehicle / Video / Weather の 50 領域です。

個人開発でよく参照されるカテゴリを、ユースケース別に整理すると次のようになります。

目次と各カテゴリのテーブルは相互リンクで結ばれており、各カテゴリの末尾には「⬆ Back to Index」というリンクが配置されています。これによって、1 万行を超える README でも「Index → カテゴリ → Back to Index → 別カテゴリ」の往復で目的の領域まで素早く辿れる構造になっています。

ブラウザ上で README を直接読む場合、Ctrl+F（macOS では Cmd+F）でカテゴリ名や API 名を検索するのが最短ルートです。ただし、テーブルが横に長く 1 画面に収まらないため、後述の publicapi.dev を併用すると、条件による絞り込みが格段に楽になります。

Auth / HTTPS / CORS 列の読み方と個人開発向けの絞り込み手順

各カテゴリのテーブルは、API / Description / Auth / HTTPS / CORS の 5 列構成で統一されています。本記事の独自価値の中心は、この 5 列を個人開発の視点で「どう読み、どう絞り込むか」です。ここでは README のカテゴリテーブルから、READMEに掲載されている実例の一つとして Animals カテゴリの先頭数行の記法を参考に整理します（実際のテーブル記法・列構成は public-apis/public-apis の README を参照してください）。

各列の意味は次のとおりです。

Auth 列の分類と用途別の選び方

Auth 列は個人開発における「取り組みやすさ」の指標です。値の代表例と、絞り込み方の考え方を整理します。

• No: 認証情報なしで呼び出せる API。個人開発の試作段階では最短ルート。プロトタイプで API 呼び出しの繋ぎ込みそのものを検証したい段階では、まず Auth No の API に絞ると、認証情報取得のオーバーヘッドをゼロにできる
• apiKey: 事前に発行された API キーをクエリまたはヘッダーに付与する方式。多くの無料 API はこのパターンで、無料枠の範囲内でも本人確認としてキー発行が必要
• OAuth: OAuth 2.0 のフロー（Authorization Code / Client Credentials 等）が必要。個人開発でも扱えるが、リダイレクト URI の登録やトークン管理が必要になるため、プロトタイプ段階のハードルは高め
• X-Mashape-Key: 旧 Mashape（現 RapidAPI）経由での認証。呼び出し側は RapidAPI のダッシュボード経由でキーを取得する

絞り込みのステップとして「まず Auth No で試作を進め、機能が形になった段階で apiKey を含む候補に広げ、本番運用や継続的な利用が必要なタイミングで OAuth の API も検討する」という段階的アプローチを取ると、認証情報の取得や設定に費やす時間を最小化できます。

HTTPS / CORS 列で見るべきポイント

HTTPS と CORS の 2 列は、実装フェーズと運用フェーズの両方で意味を持ちます。

• HTTPS No の扱い: 平文 HTTP でしか提供されていない API は、混在コンテンツ（Mixed Content）警告や、ブラウザ側のセキュリティポリシーによる呼び出し失敗のリスクがあります。個人開発でも本番公開する Web アプリからは、原則として HTTPS Yes の API のみを利用する運用が安全です
• CORS Yes の重要性: ブラウザから直接 API を呼び出す構成（SPA・静的サイト・サーバーレスフロントエンド）では、CORS が許可されているかどうかが決定的な違いを生みます。CORS No の API を使う場合はサーバー側でプロキシを立てる必要があり、実装コストが跳ね上がります
• CORS Unknown の扱い: 明示的な調査が行われていないケース。ブラウザから直叩きしたいユースケースでは、まず Yes の API を優先し、Unknown は補助候補として扱うのが安全です

つまり、個人開発向けの絞り込み手順は「Auth = No（または apiKey）」「HTTPS = Yes」「CORS = Yes（ブラウザ直叩き要件がある場合）」の 3 条件で候補を絞り、そこから Description で用途を確認し、API 名のリンク先で最新の利用規約・レート制限を確認する流れになります。

publicapi.dev（検索用サイト）の使いどころ

README 単体でも探索は可能ですが、公式に用意されている検索用の Web サイトが publicapi.dev です。カテゴリ別の API 件数を表示し、HTTPS / CORS といったタグでの絞り込み UI を備えているため、前章で整理した絞り込み手順を GUI で実行できます。

publicapi.dev では、カテゴリ別の API 件数がトップページで俯瞰できるようになっています。掲載時点の代表的な件数の例として、Development が 192 件、Games & Comics が 108 件、Geocoding が 101 件、Government が 88 件、Transportation が 73 件、Cryptocurrency が 69 件、Finance が 68 件、Documents & Productivity が 54 件といった規模感が確認できます（詳細な件数は publicapi.dev の最新表示に従ってください）。カテゴリごとの API 数を可視化することで、「どのユースケースに候補が集中しているか」を短時間で掴めます。

Ctrl+F での README 内検索と publicapi.dev の使い分けの目安は次のとおりです。

publicapi.dev には「What is an API key?」「Cross-Origin Resource Sharing (CORS)」といった短い解説記事も併設されており、Auth や CORS といった専門用語をキャッチアップしたい初見のエンジニアには入り口として親切です。加えて、/submit フォームからの API 登録受付もあり、GitHub Pull Request と並んでカタログへのコントリビュート経路として機能しています。

類似 OSS との棲み分け（public-api-lists / free-for-dev）

無料 API・無料開発リソースのカタログというジャンルには、public-apis 以外にも用途特化型の OSS が存在します。ここでは代表的な 2 件を取り上げ、目的別の棲み分けを整理します。

public-api-lists/public-api-lists との違い

public-api-lists/public-api-lists は、public-apis と同じ「無料 API カタログ」ジャンルの OSS です。執筆時点でスター数 15.6k・MIT ライセンス・掲載 API 数 730+・48 カテゴリを謳っています（数値の詳細は同リポジトリの README の最新値に従ってください）。

public-apis との最大の差分は次のとおりです。

「掲載規模の広さ・指名検索での見つけやすさ」を優先するなら public-apis、「自作ツールから機械的に API 一覧を取得したい」「タグや条件で JSON レスポンスを扱いたい」なら public-api-lists が優位、という棲み分けになります。両者は排他的ではなく、たとえば「まず public-apis で候補を眺め、選定ロジックを自動化する段になったら public-api-lists の JSON エンドポイントに切り替える」といった併用も自然です。

ripienaar/free-for-dev との違い

もう一つの代表的な OSS が ripienaar/free-for-dev です。こちらは「開発者向けの無料枠一覧」で、対象範囲が API に限定されず、SaaS/PaaS/IaaS・CDN・データベース・監視・CI/CD・ドメイン等の無料枠までカバーしています。無料 SaaS 一覧というジャンルでの位置づけや選定理由については、秋霜堂 技術ブログのfree-for-devの紹介記事で詳しく整理しています。

public-apis と free-for-dev の棲み分けは、「何を探しているか」で明確に分かれます。

• API に絞って探したい → public-apis（本記事で扱っているカタログ）
• 開発・運用に使える無料枠を横断的に探したい（CDN の無料枠、監視 SaaS の無料枠、無料 DB ホスティング等） → free-for-dev

つまり、public-apis は「アプリケーションが呼び出す外部データソース」を探すためのカタログ、free-for-dev は「アプリケーションを動かすためのインフラ・運用サービス」を探すためのカタログ、と役割が分かれています。個人開発では両者を組み合わせることが多く、「どの API を叩くか」を public-apis で決め、「どこにデプロイするか・どの監視サービスを使うか」を free-for-dev で決める、という併用が現実的です。

参考: 機械可読を意識した新しい潮流

補助的な情報として、tools-collection/apis-collection のように「Human readable / Machine readable / AI readable」の 3 つのフォーマットを掲げるカタログ OSS も登場しています。AI エージェントによる自動的な API 検索・呼び出しを見据えた設計で、認知度としては前述 2 件より小さいものの、機械可読路線の一つの方向性として押さえておくと選択肢が広がります。

コントリビュート方法とライセンス上の注意

public-apis にリストされていない無料 API を発見した場合や、自分が公開している無料 API を掲載してもらいたい場合は、Pull Request 経由でのコントリビュートが可能です。手順の詳細は公式のCONTRIBUTING.mdにまとめられており、追加項目のフォーマット（テーブル列の順序・記法）や、レビュー時に確認される観点がガイド化されています。

また、README の「Get Involved」節では、CONTRIBUTING.md への案内に加えて、davemachado/public-api（public-apis の一部データを機械的に扱うための派生プロジェクト）や、Issues・Pull Requests・LICENSE へのリンクが集約されています。カタログを利用するだけでなく「エコシステム側から関わりたい」場合の入口として参照できます。

ライセンス面では、カタログ本体は MIT ライセンスで提供されています。カタログの情報自体は商用利用を含めて再利用可能ですが、掲載されている個別の API を利用する際には、各 API 提供元の利用規約・レート制限・商用利用の可否をそれぞれ確認する必要があります。特に無料枠のみで運用したいケースでは、想定利用量が無料枠の上限を超えていないか、API プロバイダーごとに個別に確認するのが安全です。

まとめ

本記事では、GitHub で 40 万を超えるスターを持つ無料 API カタログ public-apis/public-apis を、初見のエンジニアが個人開発で使うための読み解き方として整理しました。要点は次のとおりです。

• リポジトリ本体は健全にメンテナンスされている: 執筆時点で archived=false / fork=false / disabled=false、直近の push も 2026-08-19 で、MIT ライセンス・コミュニティ + APILayer スポンサー枠の二層構造で運営されている
• 50 カテゴリの目次カタログとして使える: README の Index → カテゴリ → 「⬆ Back to Index」の往復で 1 万行超のカタログを短時間で横断できる
• 絞り込みは Auth / HTTPS / CORS の 3 列がキー: 個人開発では「Auth = No」「HTTPS = Yes」「CORS = Yes（ブラウザ直叩き時）」を条件に絞り込むと、試作段階のオーバーヘッドを最小化できる
• 検索は publicapi.dev、機械処理は public-api-lists: 目視での探索と絞り込みは公式検索サイト、JSON エンドポイントによる機械処理は public-api-lists に切り替えると効率が良い
• 役割の分かれる類似 OSS を併用する: 「外部データを叩く API」は public-apis、「インフラ・運用サービスの無料枠」は free-for-dev と、役割で使い分けるのが現実的

「40 万スターだが、自分のプロジェクトに採用してよいか」「類似 OSS とどう違うか」「READMEをどこから読めばよいか」に対する判断材料が揃えば、あとは Description と API 名のリンク先ドキュメントを追いかけるだけで、無料 API の選定作業をシャープに進められます。

開発体制のご相談

OSS の技術選定や外部 API 連携を含む個人向けサービス・業務システムの開発体制についてご検討中の方は、お問い合わせフォーム からご相談ください。要件整理の段階からお伺いいたします。

フリーランス・複業案件をお探しの方へ

OSS や外部 API を活用した開発案件をお探しのエンジニアの方は、フリーランス向けの案件マッチングサービス Workee をご覧ください。案件検索とエントリーができます。