🕒 読了目安：約 5 分

💬 この記事でわかること

初めてバックエンド実装に触れたときのリアルなつまずき
Lambda / API Gateway / Slack連携のざっくりした仕組み
バラバラだった知識が繋がる瞬間

💻 実行環境 / 前提条件

フロントエンドエンジニア1年目
使用技術：Vue.js / AWS（Lambda, API Gateway, S3, CloudFront）
以前の環境：ウォーターフォールでコーダーとしてwebサイト制作
現在の環境：スクラム開発
バックエンド・インフラ経験ほぼなし

0. 十秒でわかる、使ったもの

API Gateway
　→ フロントからのリクエストを受け取る「入り口」を作る
Lambda（Python）
　→ 受け取ったデータを処理する「中身のロジック」を実装
Slack API（Incoming Webhook）
　→ 処理した内容をSlackに通知する仕組みを作る
S3
　→ フロントのファイル（ビルドしたもの）を置く場所
CloudFront
　→ S3に置いたファイルを外部からアクセスできるように配信する
WAF
　→ 社内からしかアクセスできないようにIP制限をかける

1. はじめに

中編では、「他の人が開発できる状態を整えること」に全力を使いました。
そしてようやく、フロントの実装も進み始めます。

ここからが自分の担当。 バックエンドの実装です。

正直、この時点でもまだ分かっていませんでした。
「APIって何を作るの？」というレベルです。

2. Lambdaって何？から始まった

まず取り組んだのが、APIの中身となる処理です。今回は AWS の Lambda を使うことになりました。
Lambdaとは「必要なときだけ動くコンピューター」みたいなもの、と先輩に教えてもらいました。

普段は動いていない
リクエストが来たときだけ起動する
処理が終わると止まる

いわゆる「コールドスタンバイ」ということ。昔勉強した基本情報技術者試験の知識がここで出てきます。

ただ、もう一つ分からなかったことがあります。

「LambdaをPythonで書く」ってどういうこと？

...「Lambdaって何かのツールじゃないの？」
...「Pythonで書くってどういうこと？」

という状態です。

自分なりに理解したこと

あとから整理してみると、こういう関係でした。
👉 「LambdaをPythonで書く」 = 「AWS上のコンピューターでPythonのコードを動かす」

フロント → ブラウザで動く
バックエンド → よく分からないけどどこかで動く

でも実際は、
👉 フロントがリクエストを送る
👉 API Gatewayが受け取る
👉 Lambda（＝AWSのコンピューター）が起動する
👉 その中でPythonのコードが実行される

という流れでした。

3. とりあえず動くものを作る

いきなり完璧なものを作ることは、私の技術力では不可能だったので、
まずは 「フロントから送った値を受け取って、返すだけ」 の最小構成をAIに聞きながら作りました。

import json

def lambda_handler(event, context):
    body = json.loads(event.get('body', '{}'))

    visitor_name = body.get('name', '名無し')

    return {
        'statusCode': 200,
        'body': json.dumps({
            'message': f'{visitor_name}様、受付を受理しました。'
        })
    }

当時つまずいたポイント

そもそも前提として、私はこのとき、Pythonを全く書いたことがありませんでした。
インデントでなんかするんだよね、ぐらいの知識。フロントエンドしか触ってこなかったので、

文法も分からない
書き方も分からない
何が普通なのかも分からない

という状態です。
そんな中でこのコードを書いていたので、
今見るとシンプルな処理でも、当時は分からないことだらけでした。

eventって何？

def lambda_handler(event, context):
👉 event = フロントから送られてきたデータ

…と言われても、
「どこにあるの？」
「どういう形で入ってるの？」

と、全くイメージができませんでした。

.get()って何？
visitor_name = body.get('name', '名無し')
👉 キーがなかったときにデフォルト値を返してくれる書き方

などなど......今思えば小さなことなんですが、

eventって何？
bodyって何？
JSONって何？
なんで文字列なの？
.get()って何？

と、一行ごとに引っかかってAIに解説してもらっての繰り返しでした。

それでも「動いた」ことの価値

それでも、"とりあえず動いた"
という事実がめちゃくちゃ大きかったです。

完全に理解しているわけではない、でも動く、だから少しずつ理解できる

この 「小さく動かす → 理解する」 の流れが、
結果的に一番効率よかったと感じています。

4. API Gatewayで「通信」の壁にぶつかる

次にやったのが、フロントとLambdaを繋ぐ部分です。
ここで登場したのが API Gateway。
「エンドポイントを作る」必要があると教えてもらっても意味が分かりませんでしたが

👉 フロントはURLに対してリクエストを送る
👉 そのURLの先でLambdaが動く

という仕組みでした。

「フロントからLambdaを直接呼べばいいんじゃないの？」
と思っていたので、
「なんで間にAPI Gatewayが必要なの？」
という状態です。

あとから整理すると、
API GatewayはフロントとLambdaの間に立つ受付窓口のようなものでした。

フロントはLambdaの存在を知らなくても、
https://xxxxx.execute-api.ap-northeast-1.amazonaws.com/...

のようなURLに対してリクエストを送ればいい。
すると、

フロント
↓
API Gateway
↓
Lambda

という流れで処理が実行されます。つまり、
👉 フロントはURLに対してリクエストを送るだけ
👉 その先で何を動かすかはAPI Gateway側が管理する

ということでした。

嬉しかった瞬間

実際にAPI GatewayとLambdaを紐付けて、フロントから送信ボタンを押したときにLambdaが実行されるログを見た瞬間はかなり感動しました。

それまでの私は、「APIは誰かが作るもの」「エンドポイントは最初から存在するもの」
だと思っていました。

このあたりから少しずつ、
「画面の向こう側で何が起きているのか」
が見えるようになってきた気がします。

5. Slack連携で「外の世界」と繋がる

次にSlackへの通知です。
ここでまた新しい壁が出てきます。

Slack API？
admin権限がないと作れない？

今回は Incoming Webhook を使って比較的シンプルに実装できました。

発行されたURLに対してPOSTするだけ
JSON形式でメッセージを送る

とはいえ、
「外部サービスと繋ぐ」という経験自体が初めて
だったので、かなり手探りでした。

6. S3 + CloudFrontでWebアプリを公開する

Slack連携までできて、ローカルでは一通り動く状態になりました。
ただ、このままでは実際の受付では使えません。

👉 iPadからアクセスできるようにする必要があります。

そこで行ったのが、Webアプリの公開です。
構成はシンプルでこんな感じです。

S3：フロントのファイルを置く場所（原本）
CloudFront：それを配信するためのサーバー

手順①：S3にビルドしたファイルを配置

まずは、Vueで作ったフロントエンドをビルドします。
npm run build

すると、dist フォルダが生成されます。
👉 この中身が実際に公開されるファイル
これをそのままS3にアップロードしました。

手順②：CloudFrontと紐付ける

次に、S3をCloudFrontと紐付けます。
👉 CloudFrontを通すことで、外部からアクセスできるURLが発行される
ここでアクセス制限も設定

さらに今回は社内用ツールなので、
👉 誰でもアクセスできる状態はNG

そのため、

WAFでIP制限をかける
特定の環境からのみアクセス可能にする

といった設定もここで行いました。

7. すべてが繋がった瞬間

そしてついに、その瞬間が来ます。

フロントで情報を入力して送信。
　↓
API Gatewayにリクエストが飛ぶ
　↓
Lambdaが起動して処理される
　↓
Slackに通知が届く

このとき初めて、

フロントが何をしているのか
APIが何をしているのか
バックエンドがどう動いているのか

すべてが一本の線として理解できました。

8. 最後の最後で詰まった話

一通り実装が終わり、

「よし、完成！」
……と思ったのですが、最後の最後で思わぬところに落とし穴がありました。

iPadで動かない
実際に受付に設置する予定のiPadでアクセスしてみると、

そもそもサイトが表示されない。

最初は、

CORSの設定？
HTTPS？
CloudFrontの設定？

と、完全にソフトウェア側の問題を疑っていました。
でも調べていくと、原因は全く別のところにありました。

原因：iPadが古すぎた

結論から言うと、

👉 iPadのOS・ブラウザが古すぎて、サイトに対応していなかった
というものでした。

さらに追い打ちで、
👉 Wi-Fiの対応規格も古くて、新しいネットワークに接続できない

という問題まで発覚。
技術だけじゃ解決できない問題

今まで意識していたのは、

コード
インフラ
通信

といった“ソフトウェアの世界”だけでした。

でも実際のプロダクトでは、

👉 「どの端末で動かすか」も含めて考えないといけない

ということです。

結果：物理で解決

最終的には、
比較的新しめのiPadのストックが社内にあったため、それに差し替えて解決しました。

🔚 「完成」

数ヶ月前の自分は、
「フォーム（フロント）作れば終わりでしょ？」
と思っていました。

今回の開発を通して、
フロント
バックエンド
インフラ
外部連携

そして最後に、実際に使う環境
まで含めて、初めて「完成」になるんだと実感しました。

↓入り口に置かれたタブレット

🏢 所属会社

日々、Web開発をしながら学んだことを発信しています。
この記事も、実際の業務経験をもとにまとめました！

会社サイトはこちら👇
https://onewedge.co.jp/