【Day3】クラウドプラクティショナー取得後の第一歩！サーバーレス読書記録アプリを1週間で作ってみた

はじめに

Day2では、アーキテクチャ構成図を作成した上で、データの保存先であるDynamoDBと、処理を行うLambda関数を構築しました。

今回（Day3）は、このLambda関数をインターネット経由で呼び出せるようにするため、API Gatewayを構築していきます。構成図でいうと、③（API Gateway）の部分にあたります。

1週間の開発ロードマップ

• Day 1: AWSアカウント開設・初期の安全対策・設計
• Day 2: データベース設計とAWS Lambda構築（バックエンド）
• Day 3: API GatewayによるAPI公開と疎通確認 👈 今ここ！
• Day 4: React (Vite) を用いたフロントエンド実装
• Day 5: S3 + CloudFrontによるデプロイ・公開
• Day 6: E2Eテスト・エラーハンドリング・構成図作成
• Day 7: Qiita記事執筆と全体振り返り

この記事でやることは次の4つです。

1. API Gatewayの作成
2. URLパス（リソース）の作成
3. Lambdaとの紐づけ（メソッドの作成）
4. インターネットへの公開（デプロイ）＋疎通確認

1. API Gatewayとは

CLFの座学で「API Gatewayはリクエストの受付窓口」という説明を覚えていましたが、実際に手を動かしてみると、「インターネット（ブラウザ）」と「Lambda（プログラム）」の間を取り持つ翻訳係という感覚のほうがしっくりきました。

Lambda単体はインターネットに直接公開されていないため、外部からHTTPリクエストで呼び出せるようにするには、API Gatewayで「入り口（URL）」を作ってあげる必要があります。

ステップ1：APIの作成

1. 検索バーで「API Gateway」と検索して開きます。
2. 画面の「APIを作成」ボタンをクリックします。
3. いくつか種類が並んでいますが、今回は「REST API」（※名前に「プライベート」と付いていない方）を探し、「構築」をクリックします。
4. 「新しいAPI」を選び、API名に BookLogAPI と入力します。APIエンドポイントタイプは「リージョン」のままで、右下の「APIを作成」をクリックします。

💡 つまずきメモ：「REST API」と「REST API プライベート」を間違えそうになった
API Gatewayの作成画面には似た名前の選択肢がいくつか並んでいます。「プライベート」と付いている方はVPC内からのみアクセスできる設定のため、今回のように外部（ブラウザ）から直接呼び出したい構成では、プライベートが付いていない通常の「REST API」を選ぶのが正解です。

2. URLパス（リソース）の作成

APIという「建物」ができたので、次はその中に /books という「部屋（パス）」を作っていきます。

ステップ2：URLパス（リソース）の作成

1. 左側のメニューに / という文字が選ばれた状態になっているので、右側の「リソースを作成」ボタンをクリックします。

2. リソースパスは/のままで、右側にあるリソース名に books と入力します（パスが /books になります）。

3. その下にある「CORS (Cross Origin Resource Sharing)」のスイッチをオン（有効）にします。

4. 「リソースを作成」をクリックします。

   

💡 CORSって何？
Day2でLambdaのコード側にもCORSヘッダーを仕込みましたが、API Gateway側でもこの設定が必要です。ブラウザは「異なるドメインからのアクセス」をセキュリティ上ブロックする仕組みを持っているため、Day4で作るReact（別ドメインで動く画面）からこのAPIを呼び出せるように、あらかじめ許可しておく必要があります。

3. Lambdaと紐づける（メソッドの作成）

「部屋」ができたので、その部屋に来たリクエストを、どのプログラム（Lambda）に処理させるかを設定します。

ステップ3：Lambdaと紐づける（メソッドの作成）

1. 作成された /books をクリックして選択した状態で、「メソッドを作成」ボタンをクリックします。

2. 以下の通りに設定します。

   • メソッドタイプ: ANY（これでGETもPOSTも受け付けられます）
   • 統合タイプ: Lambda 関数
   • Lambda プロキシ統合: スイッチをオンにする（※超重要です！）
   • Lambda 関数: 入力欄をクリックして BookLogFunction を選ぶ

3. 右下の「メソッドを作成」をクリックします。

⚠️ 注意ポイント：「Lambdaプロキシ統合」を必ずオンにする
このスイッチをオンにし忘れると、API GatewayからLambdaに渡されるデータの形式が変わってしまい、Day2で書いた event.httpMethod や event.body が正しく取得できずエラーになります。Day2のコードは「プロキシ統合」がオンである前提で書いているため、ここは必ずチェックしておきましょう。

4. インターネットに公開（デプロイ）

設定した内容は、この時点ではまだ「下書き」の状態です。実際にURLとして使えるようにするには、デプロイという作業が必要です。

ステップ4：インターネットに公開（デプロイ）

1. 画面右上にあるオレンジ色の「APIをデプロイ」ボタンをクリックします。

2. ステージの選択で「新しいステージ」を選び、ステージ名に dev と入力します。

3. 「デプロイ」をクリックします。

   

画面上部に「URL の呼び出し（Invoke URL）」（https://xxxxxxx.execute-api.ap-northeast-1.amazonaws.com/dev のようなURL）が表示されれば大成功です！

この発行されたURLと、末尾に /books をつけたものが、後日ReactからアクセスするURLになります。

5. 疎通確認（APIのテスト）

無事にURLが発行され、フロントエンドとバックエンドを繋ぐ「架け橋」がインターネット上に開通しました。Reactの実装に入る前に、発行したAPIが正しくDynamoDBへデータを保存できるか、疎通確認（テスト）を行っておきます。普段使っているVSCodeのターミナルを使うのが一番手軽です。

テスト1：データを保存するテスト（POST）

VSCodeのターミナルを開き、以下の curl コマンドのURL部分を、自分で発行した「Invoke URL + /books」に置き換えて実行します。

curl -X POST https://ご自身のAPIのURL/dev/books \
-H "Content-Type: application/json" \
-d "{\"title\":\"AWSの基本\",\"author\":\"山田太郎\",\"status\":\"completed\",\"rating\":5,\"memo\":\"初めてのAPIテスト\"}"

成功すると、ターミナルに {"message":"保存に成功しました！", "item":{...}} というメッセージが返ってきます。

テスト2：データを取得するテスト（GET）

POSTが成功したら、今度はブラウザのアドレスバーに https://ご自身のAPIのURL/dev/books を直接入力してアクセスしてみます。

先ほど登録した本のデータが、文字の羅列（JSON形式）として画面に表示されれば、APIとデータベースの連携は完璧に成功しています。

💡 補足：DynamoDB側からも確認できる
AWSコンソールのDynamoDBの画面で「項目の探索」を開くと、curlで送ったデータが実際に保存されていることを目視でも確認できます。API Gateway → Lambda → DynamoDBという一連の流れが、頭の中だけでなく画面上でも繋がって見えるので、これまでの成果を可視化して見ることができます。

Next Action（Day4に進む前に）

ここまで完了したら、次に進むために以下を確認します。

• API Gateway（BookLogAPI）が作成されている
• /books リソースが作成され、CORSが有効になっている
• ANY メソッドが BookLogFunction と紐づいており、Lambdaプロキシ統合がオンになっている
• APIが dev ステージにデプロイされ、Invoke URLが発行されている
• curlでのPOSTテスト、ブラウザでのGETテストの両方に成功している

これで、Day3（API Gatewayの構築と疎通確認）は完了です。APIのテストが成功したら、バックエンド側のAWS構築はひと段落です。

次回（Day4）は、いよいよReact (Vite) を用いたフロントエンド実装に入ります。普段の業務で触れているReactやJavaScriptの基礎知識を、この自作APIと連携させて「目に見えるアプリ」へと組み上げていきます。