API は Application Programming Interface の略で、あるサービスの機能やデータを別のプログラムから使うための窓口です。人が画面のボタンを押す代わりに、プログラムが決まった形式で要求を送って処理させます。
実際に呼ぶとどうなるか
Web の API なら、URL に対して要求を送り、機械が読める形式で結果が返ってくる、というのが基本の形です。
curl -H "Authorization: Bearer アクセストークン" https://example.com/api/v1/users/123
返ってくるのは、たいていこういう構造化されたデータです。
{ "id": 123, "name": "yamada", "created_at": "2026-09-01T10:00:00Z" }
画面向けのHTMLではなく、プログラムが解釈しやすい形で返るのが画面との違いです。
実務で壊れるのはたいてい3つ
API 連携は、つないだ直後は動いていて、あとから静かに壊れます。原因はだいたい次のどれかです。
| 原因 | 何が起きるか | 先に確認すること |
|---|---|---|
| 認証の期限切れ | ある日から全部 401 になる | トークンの有効期間と、更新の仕組みがあるか |
| 利用制限に当たる | 混んだ時間だけ 429 が返る | 1分あたり・1日あたりの上限と、超えたときの挙動 |
| 提供側の仕様変更 | 項目が消える、型が変わる | バージョンの付け方と、廃止の告知をどこで受け取るか |
いちばん多いのは2つ目です。動作確認は少件数で行うのに、本番では件数が増えるため、テストでは再現しません。上限に当たったときに待って再試行するのか、諦めて記録するのかを、つなぐ時点で決めておきます。
「API」と「REST」と「GraphQL」の関係
この3つは並列ではありません。
つまり「REST か GraphQL か」は API を作るかどうかの話ではなく、作り方の選択です。どちらも API です。
押さえておきたい注意点
外部に公開する API では、認証とアクセス制御が甘いと、画面側でどれだけ権限を作り込んでも意味がなくなります。画面で隠しているだけの情報が、API では素通りで取れるという事故は起こりがちです。
確認するのは次の3点です。
- 認証方式と、権限が必要最小限に絞られているか
- 失敗したときに何が返るか（エラーの形式が決まっているか）
- 仕様が変わるときに、利用側がどう知るか
よく一緒に出てくる用語
- 設計の流儀としての REST API と GraphQL
- 呼び出し先を指す エンドポイント
- 通信を暗号化する HTTPS
- 送る側から通知する Webhook との違い