前回との接続とこの講義の役割
A-02では、APIを「画面を持たない接続口」と一言だけ紹介して、そのまま通り過ぎました。カテゴリKでは、その全体をあらためて正面から扱います。そして大事な事実があります。J-04で作ったルートは、実はもうAPIそのものでした。まったく新しいものを学ぶのではなく、すでに自分が作っていたものに、正しい名前と輪郭を与えるところから始めます。
このスライドのポイント
- A-02では「APIは画面を持たない接続口」と一言だけ紹介して通り過ぎた
- カテゴリKで、その全体をあらためて正式に扱う
- J-04で作ったルートは、実はもうAPIそのものだった
APIの定義と2つの方向
APIとは、ソフトウェア同士が、決められた形式で機能やデータをやり取りする接点のことです。決められた形式とは、何を渡すか、何が返るか、どう呼ぶか、という取り決めを指します。APIには2つの方向があります。一つは自作APIで、自分のサーバーが提供する窓口です。J-04で作ったルート群がこれにあたります。もう一つは外部APIで、他社サービスの窓口を自分が利用する方向です。天気や決済、地図といった機能を借りるときに使います。
このスライドのポイント
- API＝ソフトウェア同士が、決められた形式で機能やデータをやり取りする接点
- 決められた形式＝何を渡すか・何が返るか・どう呼ぶか
- 自作API＝自分のサーバーが提供する窓口（J-04のルート群）
- 外部API＝他社サービスの窓口を自分が利用する（天気・決済・地図など）
なぜこの区別が必要か
この2方向の区別を知らないと、開発の会話についていけません。「APIを叩く」「APIを生やす」といった言い回しは、AIやエンジニアの日常語です。自作の話なのか外部利用の話なのかを区別しないまま進めると、同じAPIという言葉を互いに別の意味で使ってしまい、話がかみ合わなくなります。まずは、いまどちらの方向の話をしているのかを意識することが出発点になります。
このスライドのポイント
- 「APIを叩く」「APIを生やす」はAI・エンジニアの日常語
- 自作か外部利用かを区別しないと会話がかみ合わない
- 同じ「API」を互いに別の意味で使ってしまう
全体構造——一つのアプリが両方を担う
全体の構造を見ます。中央に自分のアプリを置いてください。左側では、フロントエンドが自分のアプリの自作APIを呼び出します。右側では、自分のサーバーが他社の外部APIを呼び出します。つまり一つのアプリが、呼ばれる側と呼ぶ側の両方を同時に担うのです。D-01で学んだ「役割は入れ替わる」という見方が、ここでもそのまま当てはまります。
このスライドのポイント
- 中央に自分のアプリ
- 左: フロントエンド（I章）が自作APIを呼ぶ
- 右: 自分のサーバーが外部APIを呼ぶ
- 一つのアプリが「呼ばれる側」と「呼ぶ側」を同時に担う（D-01「役割は入れ替わる」の再演）
処理の流れ——経費アプリの例
経費アプリで具体的に見てみます。利用者が申請を送ると、フロントエンドが自作APIを呼び、その申請を保存します。このとき自分のアプリは、呼ばれる側、つまり提供者です。一方、領収書の文字起こしを外部のOCRサービスに頼むときは、自分のサーバーがその外部APIを呼びます。このとき自分のアプリは、呼ぶ側、つまり利用者です。同じ一つのアプリが、提供側と利用側を兼ねているのがわかります。
このスライドのポイント
- フロント→自作API: 申請を保存（このとき自分のアプリは提供者）
- サーバー→外部API: 領収書の文字起こしをOCRサービスに依頼（このとき自分のアプリは利用者）
- 1つのアプリが提供側と利用側を兼ねる
技術サンプル: 双方向図とAPIの3点セット
07のサンプルは、いま見た双方向の関係を一枚の図にまとめたものです。左のフロントは自作APIを呼び、右のサーバーは外部APIを呼びます。どちらのAPIを見るときも、確認する点は共通しています。何を渡すか、何が返るか、どう呼ぶか、というAPIの3点セットです。この3つを押さえれば、初めて出会うAPIでも落ち着いて読み解けるようになります。
このスライドのポイント
- 種別: diagram
- 目的: 自作APIと外部APIの双方向関係と、APIを読むときの共通の3点を1枚で確認する
- サンプル本体:
混同しやすい概念——APIとサーバー
混同しやすいのが、APIとサーバーの違いです。APIは窓口の仕様、つまりどう呼べば何が返るか、という取り決めのことです。これに対してサーバーは、その窓口を実際に動かしている実体です。仕様と実装は、切り分けて考える必要があります。同じ仕様の窓口を、別のサーバーで動かすこともできます。レストランにたとえるなら、メニューがAPI、料理を作る厨房がサーバーにあたります。
このスライドのポイント
- API＝窓口の「仕様」（どう呼べば何が返るかの取り決め）
- サーバー＝その窓口を動かす「実体」
- 仕様と実装は別物
バイブコーディングでの確認点
バイブコーディングでの確認点です。外部APIをAIに組み込ませる前に、必ずその実在を確かめてください。AIは、それらしく見えるだけで実在しないAPIを生成してしまうことがあります。A-06で学んだハルシネーションが、外部連携ではとくに表れやすい場面です。AIへの質問例は、「この外部APIは実在しますか。公式ドキュメントはどこにありますか」です。
このスライドのポイント
- 外部APIをAIに組み込ませる前に「実在するか」を必ず確認
- AIは、それらしいだけで実在しないAPIを生成することがある（A-06のハルシネーション）
- 外部連携はハルシネーションが最も表れやすい場面
- 質問例: 「この外部APIは実在しますか。公式ドキュメントはどこにありますか」
一問一答とまとめ
最後に一問一答です。J-04で作ったルート群は、カテゴリKの言葉で言うと何でしょうか。……答えは、自作API、つまり自分が提供する窓口です。30秒まとめです。APIはソフトウェア同士の決められた接点であり、自分が提供する自作APIと、他社を利用する外部APIの2方向があります。そして一つのアプリは、その両方を兼ねます。次回は、その窓口の約束事であるAPI契約を扱います。関連資料は「API連携 超入門」と「API連携ワード100」です。
このスライドのポイント
- 一問一答: 「J-04で作ったルート群は、Kの言葉で言うと？」→ 自作API（自分が提供する窓口）
- 30秒まとめ: APIは決められた形式でやり取りする接点。自作APIと外部APIの2方向があり、1つのアプリは両方を兼ねる
- 次回: 窓口の約束事＝API契約へ
- 関連資料: 「API連携 超入門」「API連携ワード100」
