Day 6・外とつながる — Web・API
API（受付窓口・メニュー越しに頼む）
APIは「決まった頼み方の窓口」。厨房の中を知らなくても、メニュー越しに頼める。
厨房に直接入れないから、窓口がある
お客さんは厨房に勝手に入って自分で料理を作りませんよね。代わりに『メニュー』と『受付（ウェイター）』を通して頼みます。この『決まった頼み方の窓口』が [[apclienrequest API です。APIがあるおかげで、厨房の中身（作り方）を知らなくても、メニューに載っている頼み方さえ守れば料理を受け取れます。
たとえるなら
APIはレストランの『メニュー＋受付窓口』です。メニューには『頼めるもの一覧』と『頼むときのお約束（例：ステーキは焼き加減を指定）』が書いてあります。あなたは厨房の設備も、シェフの手順も知らなくていい。メニュー通りに頼めば、ちゃんと出てきます。
ここで効いてくるのが『決まった頼み方』という点です。窓口は気まぐれではなく、いつも同じ形式で受け付けます。だから、あなたのアプリも、別の会社のアプリも、同じ窓口に同じ形で頼めば同じように使えます。この『共通のお約束』こそがAPIの価値です。
窓口が無い世界
使いたい機能ごとに厨房の内部構造を全部理解しないといけない。相手が作り方を変えたら自分のアプリも壊れる。
APIがある世界
メニュー（決まった頼み方）だけ知ればいい。厨房が中で作り方を変えても、メニューが同じなら自分は困らない。
世の中はAPIだらけ
- 地図を表示したい → 地図サービスのAPIに『この場所の地図ちょうだい』と頼む。
- 天気を出したい → 天気サービスのAPIに『東京の天気ちょうだい』と頼む。
- 支払いをしたい → 決済サービスのAPIに『この金額を処理して』と頼む。
つまりアプリ開発の多くは『自分で全部作る』のではなく『良い窓口（API）を上手に組み合わせる』ことです。レストランで言えば、自分の店で全部の食材を育てるのではなく、良い仕入れ先に注文して組み合わせるイメージです。
AIもAPI越しに使う
実は、あなたがアプリからAIを呼び出すときも、多くはAI提供元のAPIという窓口越しに頼んでいます。『この文章を要約して』という [[prompclienrequest を窓口に渡し、要約が返ってくる——リクエストとレスポンスの一往復そのものです。だからAIを組み込む＝APIの使い方を知ること、でもあります。
あなたのアプリ
│ APIの窓口に頼む: 「東京の天気ちょうだい」
▼
天気サービス（厨房の中は知らなくてよい）
│ 調べる
▼
返ってくる: 「晴れ、32度」（JSON形式）なぜ基礎を知ると強いのか
APIが『決まった頼み方の窓口』だとわかると、AIに『この地図APIを使って表示して』のように具体的に頼めます。また、うまく動かないとき『窓口に渡している中身が間違っていないか』『窓口が返してきた中身は何か』と、確認すべき場所が見えてきます。
つまずきポイント
外部のAPIには『1分間に何回まで』のような利用回数の制限や、有料/無料の区別があることがあります。AIに『このAPIの利用制限や料金の前提を教えて』と一度確認しておくと、後で慌てずに済みます。数値は必ず公式の情報で確かめましょう。
読んでも腑に落ちない所は、AIに噛み砕いてもらいましょう。
理解度チェック
答えられれば、面接で説明できる状態に一歩近づきます。
APIを一言でたとえると、最も近いのはどれ？
APIがあることの利点として正しいのはどれ？
「アプリからAIを使うのもAPIの一種」と言えるのはなぜですか。
記述式です。まず自分の言葉で答えを考えてから、模範解答を開いて自己採点してください。