前回との接続とこの講義の役割
前回のK-04では、通信の両端で必ずシリアライズとデシリアライズが起きることを確認しました。今回は、その通信に「誰の依頼か」という身元情報を載せる仕組みを見ます。ここまでのAPIは、誰でも呼べる前提で話してきました。しかし現実の外部サービスは、契約した相手だけが使えるように守られています。その守りを通り抜けるための身分証を扱うのが、この講義です。
このスライドのポイント
- K-04では通信の両端で必ずシリアライズ／デシリアライズが起きることを確認した
- ここまでのAPIは「誰でも呼べる」前提で話してきた
- 現実の外部サービスは、契約した人だけが使えるように守られている
- 今回はその守りを通る「身分証」を扱う
認証付きAPIとAPIキーの定義
認証付きAPIとは、リクエストに身元情報を含め、サーバーが誰の依頼かを識別してから処理するAPIです。身元情報の運び方は、D-07で見たAuthorizationヘッダーに載せるトークンや、Cookieが代表的です。ここで新しく登場するのがAPIキーです。APIキーとは、主にプログラム同士の呼び出しで使う識別キーで、外部APIを利用するときに発行されます。なお、認証の仕組みそのものの内部構造は、後のカテゴリQで詳しく扱います。ここでは「毎回のリクエストに身分証を載せる」という構図をつかんでください。
このスライドのポイント
- 認証付きAPI＝リクエストに身元情報を含め、サーバーが誰の依頼かを識別してから処理するAPI
- 身元情報の運び方: D-07で見たAuthorizationヘッダーのトークン、またはCookie
- APIキー＝主にプログラム同士の呼び出しで使う識別キー（外部API利用時に発行される）
- 認証の仕組みそのものの内部は、後のカテゴリQで扱う
なぜ必要か
この仕組みを知らないと、外部APIを使うときに返ってくる401、つまり認証されていないという応答を解決できません。さらに深刻なのが、APIキーの扱いです。キーをコードに直接書き込み、そのままGitHubへ公開してしまう事故は、B-09で予告した最悪のパターンそのものです。公開されたキーは他人に使われ、料金の請求やデータの流出につながります。身分証は、載せ方だけでなく、しまい方まで含めて初めて安全になります。
このスライドのポイント
- 知らないと外部API利用時の401（認証されていない）を解決できない
- より深刻: APIキーをコードに直書きしてGitHubへ公開する事故（B-09で予告した最悪パターン）
- 公開されたキーは他人に使われ、料金請求やデータ流出につながる
- 身分証は「載せ方」だけでなく「しまい方」まで含めて初めて安全になる
認証付きAPIの2つの場面
認証付きAPIには、大きく2つの場面があります。1つ目は、利用者から自作APIへの呼び出しで、Cookieやトークンによってサーバーがログイン中のユーザーを識別します。2つ目は、自分のサーバーから外部APIへの呼び出しで、APIキーによって契約者としての自分を識別してもらいます。どちらも「誰か」を証明する点は同じですが、証明する相手と手段が違います。そして、これらのキーやトークンの置き場所は、B-09で学んだ環境変数です。
このスライドのポイント
- 場面①: 利用者→自作API。Cookieやトークンでログイン中のユーザーを識別
- 場面②: 自分のサーバー→外部API。APIキーで契約者としての自分を識別してもらう
- どちらも「誰か」を証明するが、相手と手段が違う
- キーやトークンの置き場所は、B-09で学んだ環境変数
外部APIを呼ぶ処理の流れ
具体例として、領収書の文字起こしを頼むOCRサービスの外部APIを呼ぶ場面を考えます。まず、APIキーはコードに書かず、環境変数から読み込みます。次に、そのキーをAuthorizationヘッダーに載せて、自分のサーバー側からリクエストを送ります。ここで重要なのは、必ずサーバー側から呼ぶという点です。もしフロントエンドから呼ぶと、キーが利用者のブラウザに渡り、誰にでも見えてしまいます。これは、I-01やI-09で学んだ「フロントに置いたものは利用者に見える」という教訓の、そのままの応用です。
このスライドのポイント
- 例: 領収書の文字起こしを頼むOCRサービスの外部APIを呼ぶ
- ①APIキーは環境変数から読み込む ②Authorizationヘッダーに載せる ③自分のサーバー側から送る
- フロントから呼ぶとキーが利用者のブラウザに渡り、誰にでも見える
- これはI-01・I-09の「フロントに置いたものは利用者に見える」の応用
技術サンプルカード
サンプルは、外部APIを呼び出す擬似リクエストです。1行目でメソッドとパスとHTTPのバージョンを、続いてどのサービスかを示すHostを書きます。注目すべきはAuthorizationヘッダーで、Bearerに続く値がAPIキーです。この値はダミーであり、実際にはコードへ直書きせず、環境変数から読み込んでサーバー側で組み立てます。読み方の要点は2つ、キーは必ずサーバー側の環境変数から取り出すこと、そしてフロントには絶対に置かないことです。
このスライドのポイント
- 種別: http
- 目的: 外部APIを呼ぶときにAPIキーをどこにどう載せるかを確認する
- サンプル本体:
混同しやすい概念
混同しやすいのが、利用者の認証とAPIキーの違いです。利用者の認証は、人間がログインして本人であることを示すものです。一方APIキーは、プログラムがサービスの契約者であることを示す身分証です。どちらも「誰か」を識別する点では同じですが、識別する対象が人間かプログラムかという違いがあります。この2つを混ぜて考えると、置き場所や渡し方の判断を誤りやすくなります。
このスライドのポイント
- 利用者の認証（人間のログイン） vs APIキー（プログラムの身分証）
バイブコーディングでの確認点
バイブコーディングで外部APIを組み込ませたら、監査すべき点が3つあります。1つ目、キーは環境変数に置かれているか。2つ目、呼び出しはサーバー側から行われているか。3つ目、キーが漏れたときの再発行の手順を把握しているか。この3点は、AIが生成したコードを人間が確認するときの合言葉です。特に、キーがフロント側のコードに紛れ込んでいないかは、公開前に必ず目視してください。
このスライドのポイント
- 外部API組み込みの監査3点:
一問一答とまとめ
最後に一問一答です。APIキーを置いてよいのは、フロントとサーバーのどちらでしょうか。（間）。答えは、サーバーです。環境変数に置き、サーバー側から使います。フロントは利用者に見えるため、絶対に置いてはいけません。30秒まとめとして、認証付きAPIは毎回のリクエストに身分証を載せる仕組みであり、その身分証であるキーはサーバー側の環境変数で守るのが原則です。次回のK-06では、この認証を含めて、外部APIを使う一連の流れを6段階で追います。関連資料は「環境変数・APIキー管理入門」と「AIアプリのセキュリティ超入門」です。
このスライドのポイント
- 一問一答: 「APIキーを置いてよいのはフロントとサーバーのどちら？」→ 答: サーバー（環境変数で。フロントは利用者に見える）
- 30秒まとめ: 認証付きAPIは毎回のリクエストに身分証を載せる仕組み。キーはサーバー側の環境変数で守るのが原則
- 次回K-06: 外部APIを使う一連の流れを6段階で追う
- 関連資料: 「環境変数・APIキー管理入門」「AIアプリのセキュリティ超入門」
