サーバーレスアーキテクチャ入門｜AWS Lambdaで「サーバー管理」という重力から解放されたエンジニアの話

2025年11月7日2025年11月25日

深夜3時、振動するスマートフォンとサーバー室の幻影

エンジニアとして働き始めて数年が経った頃のことです。
私の枕元には、常に社用携帯が置かれていました。着信音量は最大。いつ鳴るかわからないその黒い板は、私にとって時限爆弾のようなものでした。

「〇〇サーバーのCPU使用率が90%を超えました」
「ディスク容量が逼迫しています」
「プロセスがダウンしました」

監視システムからの自動音声電話が鳴るたびに、飛び起きてPCを開く。SSHで黒い画面に入り、ログを追いかけ、プロセスを再起動する。
酷いときはタクシーを飛ばしてデータセンターに向かうこともありました。キンキンに冷えたサーバー室で、ファンの轟音を聞きながら物理マシンのランプを見つめる。
「私は、コードを書いて世の中を便利にしたかったはずなのに、なんで鉄の箱のお守りをしているんだろう」
そんな虚無感に襲われる夜が、何度もありました。

サーバーは、動いて当たり前。落ちれば罵倒される。
OSのパッチ当て、ミドルウェアのアップデート、セキュリティ対策、スケーリング設計。
アプリケーションを動かすための「土台」を守るだけで、私たちのリソースの半分以上が溶けていく。それがかつての当たり前でした。

そんな私のエンジニア人生を劇的に変えたのが、「サーバーレス」という概念、そして「AWS Lambda」との出会いです。

「サーバーを管理しなくていい？そんな魔法みたいな話があるかよ」
最初はそう思いました。また新しいバズワードが出ただけだろうと。
でも、実際に触ってみて、その考えは吹き飛びました。

OSのインストールも、パッチ当ても、オートスケールの設定もいらない。
ただ、実行したい「コード」を書くだけ。
あとはアクセスが来れば勝手に起動し、終われば勝手に消える。
しかも、使った分だけしかお金がかからない。

「これだ。これでやっと、私たちは『作りたいもの』に集中できる」

サーバーという重力から解放されたあの瞬間の高揚感は、今でも忘れられません。

サーバー管理に疲弊していた私が、どうやってサーバーレスアーキテクチャを学び、AWS Lambdaを実務や副業で使いこなすようになったのか。その全貌を、泥臭い失敗談とともに書き残しておきます。
教科書的な機能説明ではありません。現場で汗をかいて得た、エンジニアの生存戦略としての「サーバーレス入門」です。

深夜の寝室で、枕元のスマホが鳴り響き、飛び起きてPCを開くエンジニア。画面にはサーバーのアラートが表示されており、疲労困憊している様子の線画イラスト

そもそも「サーバーレス」って何？サーバーがないわけじゃない

「サーバーレス（Serverless）」という言葉は、少し誤解を招きやすい言葉です。
「サーバーがない」わけではありません。私たちのコードが動く以上、物理的なサーバーは世界のどこか（AWSのデータセンター）に確実に存在しています。

じゃあ何がないのか。
それは、「私たちが管理すべきサーバー」です。

レストランで例える「自炊」と「外食」

従来のサーバー構築（EC2など）は、「自炊」に似ています。
食材（コード）を買ってくるだけでなく、キッチン（サーバー）を用意し、コンロの火加減（CPU/メモリ）を調整し、調理器具を洗い（メンテナンス）、生ゴミを処理する（ログ管理）必要があります。料理を作る以外の「家事」が山積みです。

対してサーバーレスは、「レストランでの外食」です。
あなたは「注文（コード）」を出すだけ。
厨房の設備や、ガス代、皿洗いのことは、全部お店（AWS）がやってくれます。
お客さんが100人来ても、お店側が勝手にスタッフを増やして対応してくれる（オートスケール）。
あなたは料理の味（アプリケーションのロジック）だけに集中すればいいのです。

この「管理からの解放」こそが、サーバーレスの本質であり、私たちエンジニアが手に入れる最大のメリットです。

AWS Lambdaの基本：イベント駆動という考え方

サーバーレスの中核を担うのが、AWS Lambda（ラムダ）です。
これは「関数（Function）」単位でコードを実行できるサービスです。
Webサーバーのように常時起動してリクエストを待ち受けるのではなく、「何かが起きたとき（イベント）」だけ起動して、処理が終わったら即終了する。これが最大の特徴です。

「何かが起きたとき」とは？

Lambdaを起動するスイッチ（トリガー）は、AWSの中に無数に用意されています。

API Gateway: ユーザーがURLにアクセスしたとき（Web APIとして動く）
S3: ファイルがアップロードされたとき（画像のリサイズ処理など）
DynamoDB: データベースにデータが書き込まれたとき（通知を送るなど）
EventBridge: 定期的な時間になったとき（バッチ処理）

「画像がアップロードされたら、自動的にサムネイルを作りたい」
昔なら、常駐プログラムを作ってフォルダを監視させて…と面倒な実装が必要でしたが、Lambdaなら「画像処理のコード」をS3のイベントに紐付けるだけ。
この「イベント駆動（Event Driven）」という考え方が身につくと、システムの作り方がガラリと変わります。

お財布に優しい「従量課金」

Lambdaの料金体系も革命的でした。
「リクエスト数」と「実行時間（ミリ秒単位）」での課金です。
サーバーを立てっぱなしだと、夜中の誰も使っていない時間帯もお金がかかりますが、Lambdaは動いている間しかお金がかかりません。
月間100万リクエストまでの無料利用枠（これは永遠に続きます）があるので、個人の副業レベルや開発環境なら、実質タダで運用できることも珍しくありません。
「ポートフォリオを作りたいけどサーバー代が怖い」という初心者エンジニアにとって、これ以上の選択肢はないでしょう。

レストランの厨房で、シェフ（AWS）が注文に応じて手際よく料理を作り、客（エンジニア）は食べることに集中している比喩的なイラスト。背景にはサーバーラックが見え隠れしている

【実践】AWSコンソールで「Hello World」を叫ぶ

理屈はこれくらいにして、実際に触ってみましょう。
AWSのアカウントは持っている前提で進めますが、まだの方はぜひ作ってみてください。最初の1年は多くのサービスが無料で使えます。

1. 関数の作成

AWSマネジメントコンソールにログインし、検索窓に「Lambda」と入力してサービスを開きます。
オレンジ色の「関数の作成」ボタンをクリック。

オプション: 「一から作成」を選択
関数名: MyFirstFunction など適当に
ランタイム: ここでは Node.js 20.x を選びます（PythonやGoでもOKですが、Webエンジニアに馴染み深いJSでいきます）
アーキテクチャ: x86_64 でOK

「関数の作成」ボタンを押すと、数秒で画面が切り替わります。
これだけで、あなたのコードが動く環境が爆誕しました。OSのセットアップもSSHの設定も一切なし。これがサーバーレスのスピード感です。

2. コードの編集とテスト

画面を下にスクロールすると、「コードソース」というエディタ画面があります。
デフォルトで以下のようなコードが入っているはずです。

export const handler = async (event) => {
  const response = {
    statusCode: 200,
    body: JSON.stringify('Hello from Lambda!'),
  };
  return response;
};

この handler という関数が、Lambdaが呼び出された時に実行される入り口です。
試しにメッセージを変えてみましょう。

export const handler = async (event) => {
  console.log("イベントを受け取りました:", JSON.stringify(event));
  const response = {
    statusCode: 200,
    body: JSON.stringify('サーバーレスの世界へようこそ！'),
  };
  return response;
};

書き換えたら「Deploy」ボタンを押して保存します。
次に「Test」タブを開き、適当なイベント名（testなど）をつけて「保存」→「テスト」をクリック。

画面に緑色のボックスで「実行結果: 成功」と表示されればOKです。
ログ出力の中に「サーバーレスの世界へようこそ！」の文字が見えるはずです。
たったこれだけ。自分の書いたコードが、AWSの巨大なインフラの上で動き出した瞬間です。

AWSマネジメントコンソールのLambda画面を見ながら、コードを修正し、「Test」ボタンを押して成功の緑色表示が出た瞬間に喜んでいるエンジニアの手元の線画イラスト

【応用】API Gatewayと連携してWeb APIを作る

Lambda単体では、インターネットから直接アクセスすることができません。
そこで登場するのが「Amazon API Gateway」です。これをLambdaの前に置くことで、普通のWeb API（URL）として叩けるようになります。

1. トリガーの追加

Lambdaの画面の上部にある図（デザイナー）から「+ トリガーを追加」をクリックします。
プルダウンから「API Gateway」を選択。

Intent: 「APIを作成する」
APIタイプ: 「HTTP API」（REST APIより簡単で安いです）
セキュリティ: 今回はテストなので「オープン」

「追加」を押すと、API GatewayのエンドポイントURLが発行されます。

2. ブラウザからアクセス

発行されたURLをクリックしてみてください。
ブラウザの画面に サーバーレスの世界へようこそ！ と表示されましたか？

おめでとうございます。あなたは今、サーバーを一台も立ち上げることなく、世界中からアクセス可能なWeb APIを構築しました。
これをReactやVue.jsなどのフロントエンドから叩けば、立派なWebアプリケーションのバックエンドになります。
DBが必要ならDynamoDBを足せばいい。認証が必要ならCognitoを使えばいい。
レゴブロックのように必要なパーツを足していくだけで、サービスが出来上がっていく。この感覚を一度味わうと、もうEC2には戻れなくなります。

PC画面に表示されたブラウザで、自作したAPIのURLにアクセスし、期待通りのメッセージが表示されているのを見て、満足げにコーヒーを飲んでいるエンジニアの線画イラスト

サーバーレスの「落とし穴」と、現場で踏んだ地雷

「サーバーレス最高！全部のシステムをこれにしよう！」
…と、テンションが上がる気持ちはわかりますが、ちょっと待ってください。
光があれば影があります。私も数々の地雷を踏み抜き、痛い目を見てきました。
現場で直面する「サーバーレスの闇」についても、正直にお話しします。

1. コールドスタートの遅延

Lambdaは「使われないときは寝ている」状態です。
久しぶりにアクセスがあると、寝起きで準備をする時間が必要になります。これを「コールドスタート」と呼びます。
言語やコードサイズにもよりますが、数秒待たされることがあります。
Webサイトの表示で3秒も待たされたら、ユーザーは帰ってしまいますよね。
JavaやC#は起動が遅く、Node.jsやPythonは比較的早いですが、それでもゼロではありません。
対策としては、「Provisioned Concurrency（準備済み同時実行数）」という機能でお金を払って起こしておくか、定期的にPingを送って起こし続ける（Keep Warm）などのハックが必要になります。

2. 開発とデバッグの難しさ

ローカル環境（自分のPC）で開発しているときは良くても、いざAWSに上げると動かない、ということがよくあります。権限周り（IAM）のエラーだったり、ライブラリのバージョン違いだったり。
ログを確認するためにCloudWatch Logsを見に行くのですが、これがまた検索しにくい。
「ローカルでサクサク開発してデバッグ」という体験を得るためには、AWS SAMやServerless Frameworkといった周辺ツールの習得が必須になります。

3. 恐怖の「無限ループ」と高額請求

これが一番怖いです。実話です。
ある案件で、「S3にファイルが置かれたらLambdaを動かして、処理結果を同じS3バケットに書き込む」という処理を作りました。
何が起きたかわかりますか？

S3にファイルを置く
Lambdaが起動する
LambdaがS3にファイルを書き込む
その書き込みを検知して、またLambdaが起動する
以下、無限ループ

気づいた時には、数万回の実行ログと、顔面蒼白になるような請求額予測が並んでいました。
AWSには予算アラート（Budget）という機能があります。これを絶対に、絶対に設定してください。「月1000円超えたらメール通知」これだけで命拾いします。

PC画面に表示されたAWSのコスト管理画面で、グラフが垂直に跳ね上がっているのを見て、顔面蒼白になり冷や汗をかいているエンジニアの線画イラスト

開発効率を爆上げするツールたち：IaCの導入

AWSコンソール画面でポチポチ設定するのは、勉強にはいいですが、実務ではNGです。
「間違って設定を消しちゃった」「本番環境と検証環境の設定が微妙に違う」といった事故が必ず起きるからです。

サーバーレス開発では、インフラの設定もコードで書く「IaC（Infrastructure as Code）」が基本です。

Serverless Framework

老舗のフレームワークです。serverless.yml というファイルに設定を書くだけで、デプロイまで一発でやってくれます。プラグインも豊富で、私も長年愛用していましたが、最近は有料化の動きもあり、移行が進んでいます。

AWS SAM (Serverless Application Model)

AWS純正のツールです。CloudFormationというAWSの構成管理機能を拡張したもので、AWSとの親和性が最強です。
ローカルでLambdaを動かしてテストする機能も充実しており、今から始めるならこれが無難な選択肢でしょう。

AWS CDK (Cloud Development Kit)

今、一番ホットなのがこれです。
TypeScriptやPythonなど、普段使い慣れたプログラミング言語でインフラを定義できます。
YAMLやJSONといった設定ファイルを書かなくていい。エディタの補完機能も効く。
「インフラもアプリも同じ言語で書ける」というのは、エンジニアにとって革命的でした。学習コストは少し高いですが、覚える価値は十分にあります。

副業エンジニアとしての「サーバーレス戦略」

ここからは、フリーランスや副業エンジニアとして、どうやってサーバーレススキルを「お金」に変えていくか、という生々しい話をします。

「サーバー代、かかりませんよ」という殺し文句

個人商店や中小企業の案件で、Webシステムを提案するとき。
「サーバー代で月々5000円かかります」と言うのと、
「アクセスが少ないうちは、サーバー代はほぼ無料です」と言うの。
どちらが刺さるでしょうか？圧倒的に後者です。

サーバーレスアーキテクチャを提案できることは、クライアントのランニングコストを下げるという強力な付加価値になります。
「初期開発費は少しかかりますが、運用の手間とコストは激減します」という提案は、予算にシビアなクライアントほど響きます。

バッチ処理や便利ツールでの活用

Webアプリ全体をサーバーレスで作らなくても、部分的な導入で価値が出せます。

お問い合わせフォーム: サーバーを立てずに、API Gateway + Lambda + SES（メール送信）で作る。
定期的なデータ集計: EventBridge + Lambdaで、毎晩データベースを集計してSlackに通知するボットを作る。
画像リサイズ: ECサイトなどで、商品画像がアップされたら自動でスマホ用サイズにリサイズする。

こうした「ちょっとした機能」をサクッと作れるようになると、案件の幅が一気に広がります。
「あ、それならLambdaで安く作れますよ」と言えるエンジニアは、現場で重宝されるのです。

ポートフォリオとしての価値

転職活動や案件獲得の際、ポートフォリオとしてWebアプリを見せることがあると思います。
その時、「Herokuで動かしてます」よりも、「AWS LambdaとDynamoDBでサーバーレス構成で動かしてます。IaCはCDKです」と言えた方が、技術力の証明になります。
「モダンな技術への感度が高い」「インフラコストの感覚がある」という評価に繋がるからです。

オンラインミーティングの画面越しに、エンジニアがクライアントに対して「サーバーコストがほぼゼロになるプラン」を提案し、クライアントが興味津々で身を乗り出している様子の線画イラスト

FAQ：初心者が抱えるモヤモヤ

Q. 言語は何を選べばいいですか？
A. 普段使っている言語でOKですが、Lambdaの起動速度（コールドスタート）や情報の多さを考えると、Node.js (JavaScript/TypeScript) か Python がおすすめです。特にPythonは機械学習系ライブラリとの相性も良く、データ処理系のLambdaでよく使われます。

Q. データベースはどうすればいいですか？
A. 相性がいいのは Amazon DynamoDB です。接続数の制限などを気にせず、Lambdaのスケーリングに合わせて自動で拡張してくれます。ただ、NoSQLなので設計に癖があります。RDBを使いたい場合は、RDS Proxyなどを挟む必要がありますが、少し構成が複雑になります。

Q. ログはどうやって見るんですか？
A. AWSの CloudWatch Logs に自動的に出力されます。ただ、ブラウザで見ると少し辛いので、エラー監視にはSentryなどを導入したり、ログをDatadogに流したりするのが一般的です。

Q. ずっと動き続ける処理は作れますか？
A. Lambdaには「最大15分」という実行時間の制限があります。なので、常駐プロセスや長時間のバッチ処理には向きません。そういう場合は、AWS Fargate（コンテナ）やAWS Batchを使うのが正解です。適材適所です。