もし金庫にドアがなかったら...

前章で、私たちは完璧なRESTful APIを設計しました： DELETE /users/123 (ID123の会員を削除)

このURL設計は非常に標準的で美しいものです。 しかし考えてみてください、もしこのURLがインターネット上に公開されていたら、どんな結果になるでしょうか？

誰もがブラウザやPostmanにこのURLを入力して送信するだけで、ID123の会員はデータベースから即座に消えてしまいます。 もしハッカーが1から10000までループするスクリプトを書いて、DELETEリクエストを狂ったように送信したら、あなたの会社は3分で倒産してしまうでしょう。

これがAPI開発初心者が犯しがちな致命的なミスです：「無防備なAPI（Unprotected API）」。 APIを作るだけでは不十分で、APIの前に厳格な警備員を配置し、「あなたは誰か？この操作を行う権限があるか？」を確認させる必要があります。

この保護メカニズムは、ソフトウェア工学では**認証（Authentication）と認可（Authorization）**と呼ばれています。

警備員の通行証：APIトークンとは？

コンサート会場や会社のビルに入る時、毎回身分証明書を警備員に見せることはしません。 通常の方法は：入り口で身分証明書（ログインIDとパスワード）を提示し、警備員が確認した後、「通行証（IDカード）」を発行します。 その後、建物内を移動する際はこの通行証を首から下げていれば、警備員は通行証を見て通過を許可します。

APIの世界では、この通行証がトークンです。

トークンの仕組み

  1. ログイン段階：フロントエンドがユーザーのIDとパスワードPOST /loginをバックエンドAPIに送信。
  2. 発行段階：バックエンドがパスワードを確認後、長く偽造不可能なランダム文字列（例：eyJhbGciOiJIUzI1NiIsInR5...）を生成。これがトークンです。バックエンドはこのトークンをフロントエンドに返します。
  3. 首から下げる：フロントエンドはトークンを取得後、こっそり保存します（通常はLocalStorageに保存）。
  4. リクエスト送信：以後、フロントエンドがAPIを呼び出す際（例：DELETE /users/123）、自動的にこのトークンをHTTPリクエストの**ヘッダー（Headers）**に含めます。

具体的には、フロントエンドからのリクエストは以下のようになります：

DELETE /users/123 HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5...

(Authorization: Bearerに注目。これは業界標準の「IDカード提示」方法です)

バックエンドの警備員がリクエスト内の正しいトークンを確認すると、削除操作を許可します。トークンがない場合、またはトークンが偽物・期限切れの場合、バックエンドは容赦なく**401 Unauthorized（未認証）**を返し、リクエストを門前払いします！

現代の主流技術：JWT（JSON Web Token）

前述のランダム文字列トークンにおいて、現在世界で最も主流な技術がJWT（「ジョット」と発音）です。

従来のトークンは単なる無意味なランダム文字列で、バックエンドの警備員はこの文字列を受け取ると、データベースに問い合わせる必要がありました：「このランダム文字列は誰のものか？彼の権��は？」これはデータベースに大きな負担をかけます。

**JWTは「履歴書付きの偽造防止通行証」**です。 JWT文字列をデコードすると（jwt.ioウェブサイトで試せます）、実際にはJSON形式のデータが含まれていることがわかります：

{
  "user_id": 123,
  "role": "admin",
  "exp": 1718900000
}
  • user_id：この人物のID。
  • role：彼の身分は管理者（admin）か一般ユーザー（user）か。
  • exp（Expiration）：この通行証の有効期限。

最も驚くべきは、JWTの末尾にバックエンドサーバーの**「デジタル署名」**が付いていることです。 もしハッカーが中間の内容を改ざんしようとすると（例えば自分のroleをuserからadminに変更）、デジタル署名が即座に無効になります。バックエンドの警備員が署名の破損を検出すると、即座にゴミ箱行きです。

Vibe Prompt実践：Postmanで保護されたAPIをテストする

他人（または自分で作成した）の保護されたAPIを接続する際、以前のように単純にURLをブラウザに貼り付けてEnterを押すことはできません。ブラウザはトークンを自動的に付加してくれないからです。 Postmanを使用する必要があります！

【Postman認証テストチュートリアル】

  1. まずPostmanでログインAPI（POST /login）を呼び出し、返されたJWT文字列を取得。
  2. 長いJWT文字列をコピー。
  3. Postmanで新しいタブを開き、保護されたAPI（例：GET /my-profile）を呼び出す準備。
  4. URL入力欄の下にある**Authorization（認証）**タブをクリック。
  5. 左側のTypeドロップダウンからBearer Tokenを選択（これが最も一般的な標準です）。
  6. 右側のToken欄に、先ほどコピーしたJWT文字列を貼り付け。
  7. Send（送信）を押す。

この手順に従えば、Postmanが自動的にAuthorization: Bearer [Token]をリクエストヘッダーに追加し、バックエンドの警備チェックを通過できます！

APIの設計とセキュリティ保護を理解したことで、あなたは現実世界のAPIを接続する能力を身につけました。 しかし、プロジェクト開発の初期段階で、バックエンドエンジニアがまだAPIを作成していない場合、フロントエンドエンジニアはただ座って待つしかないのでしょうか？ 次の章では、Vibe Codingを使用して**「偽のAPIサーバー（Mock API）」**を5分で構築する方法を教え、あなたの開発進捗が他人に阻まれることがないようにします！

🎁 [VIP限定ボーナス] API高度なデバッグ術とWebhookリバースエンジニアリング

受託市場で最も儲かる案件は「ゼロからウェブサイトを作る」ことではなく、「AシステムとBシステムを連携させる」ことです。 例：顧客が自社のERPシステムとLINE公式アカウントを連携させたい場合。 この時、APIとWebhookの概念が、10万円から始まるこのような案件を受注するための核心的な武器となります。

1. APIエラーメッセージを読むスキル（手探り状態からの脱却）

PostmanでAPIを呼び出して赤いErrorが返ってきた時、すぐにCursorに聞く前に、自分でステータスコードを解釈するスキルを身につけましょう：

  • 401 Unauthorized：90%の確率でHeadersにBearer Tokenが含まれていないか、トークンの有効期限が切れています。再ログインして新しいトークンを取得しましょう！
  • 403 Forbidden：トークンはあるが権限が不足しています。例：一般ユーザーが/api/admin/delete_userを呼び出そうとした場合。
  • 422 Unprocessable Entity：送信したデータ形式が間違っています。例：バックエンドが{"age": 25}を要求しているのに、文字列{"age": "二十五"}を送信した場合。JSON Bodyを注意深く確認しましょう！
  • CORS Error（フロント���ンドの悪夢）：ブラウザで他人のAPIを呼び出した時、赤いCORSエラーが表示された場合。これは相手のサーバーがあなたのドメインからのアクセスを許可していないことを意味します。解決策：バックエンドにcorsパッケージを追加するか、Next.jsのRoute Handlersを使用してプロキシ層を中継します。

2. Webhookとは？（APIの逆操作）

従来のAPIは「あなたが他人に問い合わせる」ものです。 例：5分ごとに/api/check-paymentを呼び出して緑界科技に「この注文は顧客が支払い済みか？」と問い合わせます。これはサーバーリソースを非常に浪費します。

Webhookは「他人があなたに通知する」ものです。 あなたがAPI（例：/api/webhook/ecpay）を作成し、このURLを緑界に登録します。 顧客の支払いが成功した瞬間、緑界が「自動的」にあなたのこのAPIを呼び出し、「支払い成功！注文番号は12345」と通知します。 これが**Webhook（ネットフック）**と呼ばれるもので、現代のSaaSサービス間で最も主流な通信方法です（LINE Bot、Stripe、緑界、GitHub Actionsなど全てがWebhookに依存しています）。

3. Vibe Coding実践：ワンクリックでWebhookレシーバーを生成

Webhook��開発する際、「他人があなたを呼び出す」ため、Postmanで自分でテストすることができません。この時、強力なCursorが再び力を発揮します。

✅ Vibe Promptデモ：

「LINE公式アカウントのWebhookメッセージを受信するNode.jsルートが必要です。

  1. パスはPOST /api/webhook/line。
  2. LINE Signatureを検証するセキュリティロジックを実装し、このリクエストが本当にLINE公式から送信されたことを確認してください。
  3. ユーザーのテキストメッセージを受信したら、まずconsole.logで内容を出力するだけで結構です。
  4. 最後に、必ず200 OKをLINEサーバーに返してください。そうしないとLINEは送信失敗と判断します。」

この概念を理解したことで、あなたは全世界の全てのSaaSシステムの経絡を打ち通す能力を身につけました。企業から見たシステム統合の達人になる準備はできていますか？

完全なチュートリアルをロック解除

このチャプターは有料コンテンツです。プロジェクトに参加して、10以上の神レベルのPromptや実際のソースコード例を含む、5000字以上の深い分析をロック解除してください！

💳 支払いプランを見る (NT$ 99)すでに購入済みですか？ここをクリックしてログイン