前回の続き——「呼び方」から「呼ぶ手順の全体」へ
前回のK-05では、外部APIを呼ぶときにAPIキーで契約者を識別し、キーは環境変数に置いてサーバー側から使う、という点を確認しました。今回は視点を一段上げて、外部APIを利用する作業の全体を、最初から最後まで順番に見ていきます。一つの連携をどんな順序で組み立て、どこを確認すればよいのか。その手順を6つの段階に整理するのが、この講義の役割です。
このスライドのポイント
- K-05で学んだこと: 外部APIはAPIキーで契約者を識別する／キーは環境変数に置きサーバー側から使う
- 今回の役割: 呼び方の1点ではなく、外部APIを利用する「作業の全体」を最初から最後まで順に見る
- 一つの連携を、どんな順序で組み立て、どこを確認するかを6段階に整理する
外部API利用の6段階とレート制限
外部APIを利用する流れは、6つの段階に分けられます。第一に仕様確認、公式ドキュメントでK-02の契約を確かめます。第二に認証準備、キーを取得して環境変数へ置きます。第三に送信、D-03で学んだHTTPの形式で依頼を送ります。第四に応答解析、K-04のデシリアライズで受け取り、D-06の分類で結果を判断します。第五に失敗処理、J-08の流儀でエラーに備えます。第六に利用制限の把握です。ここで新しい用語、レート制限を定義します。レート制限とは、一定時間あたりの呼び出し回数の上限のことで、超えるとD-06の429が返ります。
このスライドのポイント
- 外部API利用は6段階に分けられる
なぜ6段階が必要か——「動くけれど脆い」連携を防ぐ
この6段階を意識しないと、どうなるでしょうか。AIに「この外部サービスと連携して」と頼んだきり、出てきたコードをそのまま使ってしまいがちです。その結果、キーの管理も、相手が落ちていたときの挙動も、呼びすぎたときの制限も、どれも考えられていない連携ができあがります。最初のデモでは動くので、問題に気づくのは公開後です。動くことと、安心して任せられることは別だという前提を、ここで持っておいてください。
このスライドのポイント
- 6段階を意識しないと起きること: AIに「連携して」と頼み、出力をそのまま使ってしまう
- 抜け落ちやすい点: キーの管理／相手が落ちたときの挙動／呼びすぎたときの制限
- 最初のデモでは動くため、問題に気づくのは公開後になりやすい
- 「動くこと」と「安心して任せられること」は別
6段階チェックリスト（構造）
6段階を表にまとめました。各段階には、確認すべきことと、これまでのどの講義とつながっているかを添えています。特に注目してほしいのは、第一段階の仕様確認です。ここはA-06で学んだハルシネーション対策の最前線にあたります。AIは、実在しないAPIや存在しないパラメータを、それらしく生成することがあります。呼び方を書き始める前に、公式ドキュメントでそのAPIとパラメータが本当に存在するかを確かめる。この一手間が、後の事故を大きく減らします。
具体例——気象APIの組み込みを6段階でなぞる
具体例として、気象APIの組み込みを6段階でなぞってみます。まず公式ドキュメントで契約と、そのAPIが実在することを確認します。次にキーを取得して環境変数へ置き、サーバー側から依頼を送ります。返ってきたJSONを解析し、失敗したときの処理を用意します。最後に第六段階、利用制限を調べたところ、呼び出しは一分間に六十回までだと分かったとします。すると、画面を開くたびに毎回呼ぶ設計は成り立ちません。I-10で学んだキャッシュで呼び出しを減らす、というように、制限を知った時点で設計そのものが変わるのです。
このスライドのポイント
- 気象APIを組み込む例
技術サンプルカード——6段階チェックリスト
スライドの表が、そのまま使える6段階チェックリストです。各段階に、自分へ問いかける確認の問いを一つずつ置いています。たとえば第一段階なら「このAPIとパラメータは公式ドキュメントに実在するか」、第六段階なら「呼び出し回数の上限はいくつで、それを超えない設計になっているか」といった具合です。上から順に問いに答えていけば、抜けのある連携を防げます。AIへの質問例はこうです。「この外部API連携を6段階で監査してください。特に失敗処理とレート制限の考慮はありますか」。
このスライドのポイント
- 種別: table
- 目的: 外部API連携を、抜けなく6段階で監査する
- サンプル本体:
混同しやすい点——自分の障害（500）と相手起因の障害・制限
混同しやすいのが、障害の原因がどちら側にあるかです。自分のサーバーの不具合で返る500と、外部API側の障害や制限で返るエラーは、区別して考える必要があります。D-06で学んだ原因の所在の話の、外部版です。相手起因の障害は、自分のコードをいくら直しても直りません。できるのは、待つ、呼び出しを減らす、あるいは代替手段を用意しておく、という設計だけです。まず、どちら側の問題かを切り分けることが出発点になります。
このスライドのポイント
- 自分のサーバーの不具合で返る500 と、外部API側の障害・制限で返るエラーは区別する
- D-06「原因の所在」の外部版
- 相手起因の障害はコードを直しても直らない → できるのは「待つ・減らす・代替を用意する」
バイブコーディングでの確認点——相手はいつか必ず落ちる
外部連携をAIに作らせたら、必ず一つ聞いてください。「外部APIが落ちているとき、このアプリはどう振る舞いますか」。依存している相手のサービスは、いつか必ず一度は落ちます。そのとき、アプリ全体が巻き込まれて止まってしまうのか、その機能だけを切り離して案内を出せるのか。ここが設計されているかどうかで、連携の堅さが決まります。相手が完璧に動き続ける前提のコードは、危ういのです。
このスライドのポイント
- 外部連携をAIに作らせたら必ず聞く: 「外部APIが落ちているとき、このアプリはどう振る舞いますか」
- 依存先のサービスは、いつか必ず一度は落ちる
- 見るべき点: アプリ全体が巻き込まれて止まるか、その機能だけ切り離して案内を出せるか
まとめと次回——429の意味とWebhookへ
最後に一問一答です。429というステータスコードが返ってきたとき、その原因は何でしょうか。（間）答えは、レート制限の超過です。呼びすぎているので、間隔を空けるか、呼び出す回数そのものを減らします。30秒でまとめます。外部APIの利用は、仕様確認、認証準備、送信、応答解析、失敗処理、利用制限の6段階で監査する。仕様確認はハルシネーション対策、利用制限は429への備えです。次回は連携の向きが逆になるWebhook、相手からこちらへ知らせが来る仕組みへ進みます。関連資料は「API連携 超入門」「AI利用料の見積もり入門」です。
このスライドのポイント
- 一問一答:「429が返ったときの原因は？」→ 答: レート制限の超過（呼びすぎ。間隔を空ける・回数を減らす）
- 30秒まとめ: 外部API利用は6段階（仕様確認・認証準備・送信・応答解析・失敗処理・利用制限）で監査する。①はハルシネーション対策、⑥は429への備え
- 次回: 連携の向きが逆になるWebhook（相手からこちらへ知らせが来る仕組み）
- 関連資料: 「API連携 超入門」「AI利用料の見積もり入門」
