「Google Maps APIを使って…」「APIにリクエストを送ってデータを取得して…」といった会話を聞いて、急に難しく感じたことがあるかもしれません。
API（Application Programming Interface）は、仕組みが分かるとむしろ“とても親切で便利な窓口”だと分かります。
今回は専門用語はいったん横に置き、誰でもイメージできるレストランに例えて、APIを直感的に理解していきます。読み終える頃には「なるほど、APIってそういうことか」とスッキリするはずです。
APIは「レストランのウェイター（＝注文の窓口）」です
結論から言います。APIを理解する近道は、レストランの流れを思い浮かべることです。
レストランで料理を注文するとします。席に座り、メニューを見て「ハンバーグが食べたい」と決めました。
ここで、あなたがいきなり厨房に入ってシェフに直接「ハンバーグ作ってください！」とは言いません（普通は止められます）。
そこで登場するのがウェイターです。
- あなたはウェイターに「ハンバーグを1つお願いします」と伝えます
- ウェイターがその内容を厨房へ届けます
- 厨房でシェフが料理を作ります
- できあがった料理が席に運ばれてきます
この「注文を受け取り、厨房とやり取りして、結果を返してくれる存在」。これがAPIのイメージにとても近い。
図解で整理すると、対応関係が一気にクリアになります
- お客さん：ユーザー（が操作するアプリ）
- 注文：リクエスト（欲しいデータや処理のお願い）
- ウェイター／注文の窓口：API（お願いの受け付け役・決まった手順）
- 厨房（調理するところ）：サーバー（処理を実行する側）
- 料理：レスポンス（返ってくるデータや結果）
- （補足）食材庫・レシピ帳：データベース（情報を保管している場所）
ポイントは、APIが「何でもできる魔法」ではなく、“決められた注文の出し方で、決められた範囲のことをお願いできる窓口”という点。
APIは「無料とは限らない（課金されることがある）」です
レストランで料理を頼むと、基本的には料金が発生しますよね。
APIも同じで、使うほどコストがかかる性質があります。そのため、多くのAPIは課金体系を持っています。
レストランの比喩で言うなら、こんなイメージです。
- 1回注文するごとに料金がかかる（＝1リクエストごとの従量課金）
- 高級な料理ほど値段が高い（＝高度な機能・高精度データほど高額）
- 無料の試食がある（＝無料枠・トライアル。ただし上限あり）
- 混雑時は注文数に制限がかかる（＝レート制限。払い方やプランで上限が変わることも）
つまり、APIは便利な一方で、「どれだけ使うといくらになるか」を意識しておかないと、想定外の請求につながることがあります。
初学者のうちは、まず「無料枠があるか」「上限（回数・データ量）がどこか」を軽く確認するだけでも十分に安全です。
＊API（Application Programming Interface）
