0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@kinoko999in株式会社ONE WEDGE

コーダーだった私が開発1年目でバックエンドに体当たりした話 〜後編：すべてが繋がった瞬間〜

0
Last updated at Posted at 2026-06-04

🕒 読了目安：約 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のストックが社内にあったため、それに差し替えて解決しました。

🔚 「完成」

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

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

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

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

🏢 所属会社

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

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

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?