API とは実際のところ何なのか
を考える一番すっきりした方法は、あるプログラムが別のプログラムに提供する、リクエストのメニューとして捉えることだ。
レストランは、あなたが厨房に入って料理をすることを許さない。代わりにメニューを渡してくる。これが注文できるもの、これが注文の仕方、これが返ってくるもの、というわけだ。厨房がどう動いているかを知る必要はない。必要なのはメニューだけである。API はまさにそれだ——ある会社が「これが、あなたが私たちのサービスに対して行ってよいリクエストです。そして、それぞれが何を返すかはこうです」と言っているのである。
AI が「天気 API を呼び出す」コードを書くとき、それはそのメニューから注文を出しているのだ。この都市の予報をくれ、と。天気会社のサーバーが作業をして、答えを返してくる。あなたのアプリは、彼らのデータベースもコードも一切見ない。ただ料理を受け取るだけである。
┌──────────────┐ リクエスト: GET /forecast?city=London ┌──────────────┐
│ あなたの │ ────────────────────────────────────────▶ │ API │
│ アプリ │ │エンドポイント│
│(クライアント)│ ◀──────────────────────────────────────── │ (サーバー) │
└──────────────┘ レスポンス: { "temp": 14, ... } (JSON) └──────────────┘
メニューから 仕事をして、
注文する 料理を出す
ここで重要なのは考え方の転換だ。API は契約である。相手の会社は、あなたが特定の方法で尋ねれば、特定の形で答えを返すと約束している。あなたの仕事——そして AI の仕事——は、正しく尋ね、答えを正しく読むことだ。API のバグのほとんどは、どちらかがこの契約を破ることで起きる。