APIとは?意味と使われ方を例えで簡単に解説

「API連携で実装します」「APIで取得できます」と耳にする。でもAPIって何?を、レストランのたとえで一気にスッキリさせます。

APIとは?意味と使われ方を例えで簡単に解説のイメージ画像
Photo by Godfrey Atima on Pexels
この記事の目次 18
  1. まず、APIは何の略?
  2. レストランで全部理解する
  3. 具体例:天気予報API
  4. 似たような身近なAPI
  5. APIで何が便利になる?
  6. 実際に、どこでAPIが動いているのか
  7. APIを「作る側」から見ると
  8. APIキーの扱いを間違えると事故になる
  9. REST API、SOAP API、GraphQL...の違い
  10. Webhook:呼ぶのではなく、呼ばれる
  11. APIが変わると、こちらも壊れる
  12. API利用には「鍵」が必要なことが多い
  13. APIが止まると、何が起きる?
  14. よくある誤解
  15. APIを使ってみたい人が最初に触るもの
  16. 使う前に確認しておくこと
  17. 「API連携できます」と言われたら確認すること
  18. まとめ

「APIで取得できます」「API連携が必要です」みたいな話、IT系の人から1日に何度も聞きます。

でも、

「APIって結局なに?」「アプリと何が違うの?」

をスッキリ説明できる人、技術者でも意外と少ない(ちゃんと説明するのは難しい)。

たとえ話で行きます。

API(エーピーアイ)とは、「あるシステムが、外部から呼ばれた時に決まった動きをする"窓口"」のこと。
例えるなら レストランの「メニュー」と「ウェイター」。
お客(あなたのアプリ)は、メニュー(API仕様)を見て、ウェイター(API)に「ハンバーグください」と頼むと、キッチン(システム内部)がハンバーグを作って届けてくれる、というイメージ。

まず、APIは何の略?

APIは Application Programming Interface の略。

日本語に直訳すると「アプリケーション同士をつなぐための窓口」。

ややこしいので、**「システムとシステムをつなぐ約束ごと」**と覚えるのが実用的。

レストランで全部理解する

具体例にいきます。

あなたがレストランに行ったとします:

  1. メニュー(API仕様)を見る
  2. ウェイター(API)に注文を伝える:「ハンバーグください」
  3. ウェイターがキッチン(システム内部)に伝える
  4. キッチンが料理を作る
  5. ウェイターが料理を持ってくる

ポイントは、

  • あなたはキッチンに直接行かない(キッチンの中身は見えない)
  • メニューにある料理しか頼めない(API仕様に書かれてることだけ可能)
  • 「ハンバーグください」と頼めば必ずハンバーグが来る(決まった動き)

これがAPIの本質。「中身は見せないけど、決まった頼み方をすれば決まった結果を返してくれる窓口」。

✓

ここだけ覚える

API = 「システムの窓口」
外から決まった頼み方をすると、決まった結果が返ってくる。中身(キッチン)は隠されている。

具体例:天気予報API

1. 頼む あなたのアプリ 「東京の明日の天気ちょうだい」
→
2. 受け取って処理する 天気予報API 窓口。中でどう調べているかは見せない
→
3. 返す 答えのデータ 「晴れ / 最高28度 / 降水確率10%」

APIとは、中身を見せずに「頼む・返す」だけをやりとりする窓口のこと。厨房に入らなくても料理が出てくるのと同じ

天気予報APIのやりとり。頼んで、返ってくるだけ

実際のAPIの例を見ます。

「気象庁の天気予報API」というのがあって、URLにアクセスすると、天気の情報がJSON(データのフォーマット)で返ってきます:

https://www.jma.go.jp/bosai/forecast/data/forecast/130000.json

これにアクセスすると、東京の天気が返ってくる。「東京の天気くれ」とAPIに頼むと、データが返ってくる。

これを使って、

  • スマホの天気アプリ
  • 天気を表示する家電
  • 旅行サイトの「明日の旅行先の天気」表示

など、たくさんのサービスが裏で動いています。

似たような身近なAPI

「あなたが知らないだけで、毎日APIに支えられて生きている」と言っても過言じゃありません:

サービス 裏で使われているAPI
Google Maps を埋め込んだサイト Google Maps API
X(旧Twitter)やInstagramの埋め込み X API/InstagramのAPI
Suica残高をアプリで見る JR東のAPI
株価表示アプリ 証券会社や金融データのAPI
ChatGPTを組み込んだ自社サービス OpenAI API

APIで何が便利になる?

「自分で全部作らなくていい」のが最大のメリット。

たとえばあなたが旅行サイトを作る時、

  • APIがない世界:天気予報を自分で観測しなきゃ → 不可能
  • APIがある世界:気象庁のAPIに「明日の沖縄の天気くれ」と頼むだけ → 一瞬で天気表示できる

つまり、他社の機能や情報を「お借りして」自分のサービスに組み込めるのがAPI。

実際に、どこでAPIが動いているのか

普段使っているサービスの裏で、どのAPIが呼ばれているかを知ると一気に身近になります。

見えている画面 裏で呼ばれているAPI
飲食店サイトの地図 地図サービスのAPI(Google Maps など)
ネットショップの「カードで支払う」 決済代行会社のAPI
「Googleでログイン」ボタン 認証のAPI(OAuth)
天気アプリ 気象データのAPI
乗換案内 鉄道各社の時刻・遅延情報のAPI
ECサイトの「配送状況を確認」 配送会社の追跡API
経理ソフトの「銀行明細を取り込む」 銀行のAPI

つまり、1つのアプリは自社で全部作っているわけではなく、他社の機能を借りて組み立てられています。地図を1から作る会社はありません。「作らずに借りる」ための仕組みがAPI、と考えると本質に近い。

APIを「作る側」から見ると

自社のデータをAPIとして公開する側にも、はっきりした理由があります。

  1. 他社に使ってもらうと、自社サービスが広がる。決済APIを提供すれば、それを組み込んだ店が増えるほど手数料収入も増える
  2. 問い合わせが減る。「データをCSVでください」という依頼に毎回対応する代わりに、APIを1つ用意すれば済む
  3. 自社の別サービスからも使える。アプリ・Web・社内システムが同じAPIを叩けば、作り直しが減る
i

「APIエコノミー」という言い方

APIを通じて機能を貸し借りし、それ自体が経済圏になっている状態をAPIエコノミーと呼びます。決済・地図・認証・生成AI——いま伸びている分野の多くは、単体の製品ではなくAPIとして売られています。「サービスを売る」から「機能を貸す」へ、というビジネスの形の変化がここに表れています。

APIキーの扱いを間違えると事故になる

APIを使うには鍵(APIキー)が要ります。これはパスワードと同じ扱いのものです。

  • キーが漏れると、他人があなたの名前でAPIを使えます。従量課金なら請求はあなたに来ます
  • 実際、GitHubに公開したコードにキーを書いたまま上げてしまい、高額請求が発生する事故は繰り返し起きています
  • 対策は基本的なことばかりで、コードに直接書かない・環境変数に入れる・使う場所を制限する・定期的に作り直す
!

生成AIのAPIは、桁が大きくなりやすい

地図や天気のAPIと違い、生成AIのAPIは1回あたりの単価が高いうえ、プログラムのループでうっかり大量に呼び出すと一晩で数万円ということが起こりえます。上限額のアラート設定を最初にやっておくのが鉄則です。

REST API、SOAP API、GraphQL...の違い

APIの世界にはいくつか種類があります。違いは「頼み方のルール」だけです。

REST API

いまの主流

  • URLで頼みを表現する
  • シンプルで分かりやすい
  • 2010年代以降の事実上の標準
GraphQL

新しい流派

  • 欲しいデータを細かく指定できる
  • Facebookが作ったもの
  • 大規模サービスで人気上昇中

他にも SOAP、gRPC など色々ありますが、普通の人は「REST API」と「GraphQL」がある、と知っておけば十分。

Webhook:呼ぶのではなく、呼ばれる

APIとセットでよく出てくるのが Webhook(ウェブフック) です。向きが逆になるだけなのですが、これを知ると自動化の幅が一気に広がります。

API(こちらから聞く) 「新しい注文ある?」
「まだありません」
「今は?」「ありません」
何度も聞きに行く必要がある
向きが
逆
Webhook(あちらから来る) こちらは待つだけ
注文が入った瞬間に
向こうから通知が届く
無駄な問い合わせが要らない

「決済が完了したらSlackに通知」「フォームが送信されたらスプレッドシートに追記」——こうした自動化の裏はほぼWebhookです

APIは聞きに行く、Webhookは通知が来る

聞きに行く方式(ポーリング)だと、変化がないときも通信が発生します。1分ごとに確認すれば1日1,440回。ほとんどが空振りです。Webhookなら実際に起きたときだけなので、無駄がありません。

APIが変わると、こちらも壊れる

外部APIを使ううえで避けられないのが、相手側の変更です。

何が起きるか 影響
バージョンが上がる 古い版がいずれ止まる。移行の期限が通知される
項目が変わる 返ってくるデータの名前や形が変わり、こちらの処理が落ちる
料金体系が変わる 無料だったものが有料化。実例は多数
サービス自体が終わる 代替を探して作り直すしかない
!

「動いているから触らない」がいちばん危ない

APIを組み込んだ後、提供元からのお知らせを誰も読んでいないという状態はよくあります。ある日突然サービスが止まって、原因を探したら半年前に廃止予告が出ていた——これは実際に繰り返し起きています。使っているAPIの更新情報は、担当を決めて追う。地味ですが、これが一番効く対策です。

API利用には「鍵」が必要なことが多い

無料・無制限じゃありません。多くのAPIは、

  • APIキー:あなたのアプリの身分証明書
  • 利用回数制限:1時間に100回まで、など
  • 有料プラン:商用利用は月額○円

があります。シンプリでもPexelsというAPIを使って記事サムネを取得していますが、APIキーを登録して使ってます。

!

APIキーは絶対に公開しない

APIキーはパスワードと同じ。GitHubに上げちゃダメ、ブログに貼っちゃダメ。漏れると他人にAPIを使われ放題で、課金が爆発したり、利用停止になります。

APIが止まると、何が起きる?

APIは「見えない配管」なので、普段は意識しません。でも止まると一気に表面化します。

  • 地図APIが止まる → 飲食店サイトの地図だけ真っ白になる
  • 決済APIが止まる → ネットショップで「購入」を押しても進まない
  • ログインAPI(GoogleやXでログイン)が止まる → そのサービスにログインできなくなる

大事なのは、止まっているのはそのサイトではなく、借りている外部のサービスだということ。「このサイト壊れてる」と思っている現象の何割かは、裏で呼んでいるAPIが落ちているだけです。

!

便利さと引き換えに、依存が増える

APIを使うと開発は劇的に速くなりますが、そのサービスの都合に振り回されます。実際、無料だったAPIが突然有料化されたり、仕様変更で動かなくなったりすることは日常的に起きています。使う側は「相手が変えたら自分も直す」前提でいる必要があります。

よくある誤解

  • 「APIはプログラマーだけのもの」→ ✕。ノーコードツール(Zapierなど)は中身がAPIの呼び出しです。コードを書かなくてもAPIは使えます
  • 「APIを使うとデータが全部見られる」→ ✕。APIは公開すると決めた範囲だけを返します。むしろ「見せる範囲を絞るための窓口」です
  • 「APIは無料」→ △。無料枠があるものは多いですが、使う回数で課金されるのが一般的。地図や生成AIのAPIは規模が大きくなると相応の費用になります
  • 「API連携=データをコピーすること」→ △。基本は必要なときに聞きに行くしくみなので、元のデータに近い値が返ってきます。ただし、相手側がキャッシュ(一時保存)した値を返したり、こちらが取ってきたデータを保存して1日1回だけ同期したりする場合は、最新とは限りません。どのくらいの頻度で更新されるかは、APIの仕様で確認します

APIを使ってみたい人が最初に触るもの

プログラマーでなくても、APIの感覚をつかむ方法があります。

  1. ノーコードの自動化ツール。ZapierやMakeのようなサービスは、画面上で「AのときBする」をつなぐだけ。中身はAPIの呼び出しですが、コードは書きません
  2. スプレッドシートの関数。Google スプレッドシートには外部からデータを取ってくる関数があり、簡単なAPI連携ができます
  3. 公開APIを、ブラウザで叩いてみる。天気APIのURLをブラウザのアドレス欄に貼ると、生のデータがそのまま表示されます。これがAPIの返事の姿です

3つめは特におすすめで、「APIとは何か」が5秒で腑に落ちます。普段は整形されて画面に出ているものが、実は無骨なデータの塊として返ってきている——これを一度見ておくと、以降の理解がまるで違います。

i

JSONという形

APIが返すデータの多くはJSONという形式です。中括弧と「名前:値」が並んだだけの、人間にも読める書き方をしています。プログラム同士がやり取りするための、共通の書式だと思えば十分。細かい文法を覚えなくても、「こういう形で返ってくるんだな」と分かれば話についていけます。

使う前に確認しておくこと

外部のAPIに依存するということは、相手の都合に自分が縛られるということです。導入前に見ておく項目を挙げます。

確認すること なぜ
料金体系 無料枠を超えたらいくらか。従量課金なら上限を設定できるか
利用制限 1分あたり何回まで呼べるか(レート制限)。多いと設計が変わる
規約 取得したデータを保存していいか、再配布していいか
サポート期限 古い版がいつ止まるか。予告なく終わるサービスもある
障害情報の出し方 止まったときに状況を知る手段があるか

とくに 利用規約でのデータの扱いは見落とされがちです。「取ってきたデータを自社のデータベースに貯めてはいけない」と定めているAPIは珍しくありません。動くかどうかと、使っていいかどうかは別、というのはAPIの世界で繰り返し問題になるところです。

「API連携できます」と言われたら確認すること

サービス選定の場面で「APIがあるので連携できます」と言われることがあります。ここで止まらずに、もう一段聞いておくと後で困りません。

  1. 読み取りだけか、書き込みもできるか。データを取れるだけで、更新はできない仕様は珍しくありません
  2. 取れるのはどの項目か。「連携できる」と言われても、必要な項目が返ってこなければ意味がない
  3. リアルタイムか、日次か。1日1回の同期なら、当日の数字は見られません
  4. 追加費用がかかるか。API利用は上位プラン限定という料金設計が非常に多い

「APIがある」はできることの上限を示しているだけで、こちらがやりたいことができるとは限りません。実現したい業務を具体的に伝えて、それが可能かを確認する——ここまでやって初めて、判断材料になります。

まとめ

  • API = システム同士をつなぐ「窓口」、決まった頼み方をすると決まった結果が返ってくる
  • レストランのメニュー+ウェイターのイメージ
  • 天気予報、地図、SNS、決済、AI ─ 世の中の多くのサービスはAPIで連携している
  • APIがあるおかげで「他社の機能を借りて」自分のサービスを作れる
  • 種類はREST APIが主流、最近はGraphQLも増えている
  • APIキーは絶対に公開しないこと

クラウドやChatGPTと並んで、IT用語の中でも特に重要な概念です。技術者でなくても、ニュースで「APIが…」と聞いたとき、ぼんやりとイメージできるだけで世界が変わります。

この記事をシェア