AWS Lambda入門：最初の関数とトリガー4種（API Gateway/S3/cron/SQS）の選び方

「サーバー、用意しなくていいよ。コードだけ置いて」

そう言われて、初めてLambdaに関数を1個アップロードしたとき、正直ピンときませんでした。動かすボタンがない。URLもない。じゃあ、これいつ動くの？と。

答えは「誰かが叩いたとき」でした。Lambdaは自分から動きません。HTTPリクエストが来た、ファイルがアップされた、毎朝9時になった——そういうきっかけ（トリガー）があって初めて起きる仕組みです。ここを理解しないまま関数だけ作ると、「デプロイしたのに何も起きない」で必ず詰まります。僕もそこで半日溶かしました。

この記事は、Lambdaを初めて触る人向けです。最初の関数をデプロイするまでの最短手順と、トリガー4種類（API Gateway / S3 / EventBridge(cron) / SQS）の使い分け、料金の考え方までを一気にやります。コールドスタート対策やIAMの細かい設計、本番運用の話は深くやりません。そこは姉妹記事のAWS Lambda実装の勘所に送ります。まずは「初めてのLambdaとトリガー選び」に集中します。

この記事の要点

• Lambdaは自分からは動かない。「いつ動くか」を決めるのがトリガー。ここが入門の山場。
• トリガーは大きく3タイプ。同期（API Gateway＝呼んだ人が返事を待つ）、非同期（S3・EventBridgeで投げっぱなし）、ポーリング（SQSでキューを取りに行く）。
• 最初の関数は管理コンソールから5分でデプロイできる。手順を覚えるならCLIのほうが後で楽。
• 料金は「呼ばれた回数 × 実行時間 × メモリ」。毎月100万回までは無料枠があり、入門中はほぼ0円。
• やりたいことから逆引きで選ぶ：HTTPで叩きたい→API Gateway、ファイル起点→S3、定期実行→cron、大量処理を取りこぼさず→SQS。

そもそもLambdaって何なのか

Lambdaを一言でいうと、**「呼ばれたときだけ動く、置きっぱなしの関数」**です。

普通のサーバーは、リクエストが来ても来なくても24時間立ちっぱなしです。コンビニのバイトを、お客が一人も来ない深夜でもレジに立たせ続けるようなもの。当然、その分のお金がかかります。

Lambdaは違います。お客が来た瞬間だけバイトを呼んで、対応が終わったら帰す。呼ばれていない時間はお金がかからない。だから「たまにしか動かないけど、確実に処理したい」仕事と相性が抜群です。

具体的にはこんな粒度の仕事に向きます。

• 決済サービスやフォームから飛んでくる通知（Webhook）を受ける
• 画像がアップロードされたら自動でサムネイルを作る
• 毎朝9時に売上を集計してSlackに流す
• 注文が殺到しても、1件ずつ落ち着いて処理する

逆に、常に高速応答が必要なメインのWebサイトや、何時間も回り続けるバッチ処理には向きません。Lambdaには実行時間の上限（最大15分）があるからです。「短い・単発・たまに」が得意領域だと覚えておけば、選定で外しません。

最初の関数をデプロイする（最短ルート）

理屈より、まず1個動かしましょう。やることはたった2つ。関数を書くことと、Lambdaに置くことです。

関数の中身はこれだけ。Node.jsで、受け取ったイベントに「こんにちは」を返すだけの最小コードです。AWSの管理コンソールで新規関数を作ると、最初からエディタにサンプルが入っているので、それを次の内容に書き換えます。

// index.mjs
// Lambdaは「handler」という名前の関数を入口として呼ぶ
export const handler = async (event) => {
  // event には「誰がどう呼んだか」の情報がJSONで入ってくる
  console.log("呼ばれた！中身はこれ:", JSON.stringify(event));

  // 呼び出し元（API Gatewayなど）が読める形で返す
  return {
    statusCode: 200,
    headers: { "content-type": "application/json" },
    body: JSON.stringify({ message: "こんにちは、Lambda" }),
  };
};

ポイントはhandlerという名前です。Lambdaは「どの関数から始めればいいか」を、この名前で判断します。設定欄にindex.handler（ファイル名.関数名）と書いてあるはずなので、そこと一致していればOK。

コンソールなら、コードを貼って「Deploy」を押し、「Test」タブで適当なイベントを作って実行すれば、もう動きます。statusCode: 200が返ってくれば成功です。

手順を残すならCLIで

ただ、コンソールのポチポチ作業は手順が記録に残りません。「あの設定どこで変えたっけ」が必ず起きます。チームでやるなら、最初からCLIに慣れておくほうが結局ラクです。先ほどのコードをindex.mjsとして保存し、次を実行します。

# 1. コードをzipに固める
zip function.zip index.mjs

# 2. Lambda関数を新規作成（roleは事前に作った実行ロールのARN）
aws lambda create-function \
  --function-name my-first-lambda \
  --runtime nodejs24.x \
  --handler index.handler \
  --zip-file fileb://function.zip \
  --role arn:aws:iam::123456789012:role/my-lambda-role \
  --region ap-northeast-1

# 3. コードを直したら、作り直さずに更新だけする
aws lambda update-function-code \
  --function-name my-first-lambda \
  --zip-file fileb://function.zip \
  --region ap-northeast-1

実行ロール（--roleに渡すもの）は「この関数がAWSで何をしてよいか」の権限表です。最初はCloudWatch Logsへの書き込みだけで十分。権限を絞る考え方はAWS IAMガイドにまとめてあります。アカウントIDやリージョンは自分の環境に置き換えてください。

ここまでで関数はできました。でも、まだ「誰も呼んでいない」状態です。次が本題のトリガーです。

トリガー4種類の使い分け

冒頭で詰まった「いつ動くの？」の答えがここです。トリガーは「Lambdaを起こすきっかけ」で、種類によって呼ばれ方そのものが違います。ここを混同すると、エラーの読み方を間違えます。

まず全体像を表で押さえましょう。

トリガー	きっかけ	呼ばれ方	代表的な用途
API Gateway	HTTPリクエストが来た	同期（呼んだ人が返事を待つ）	Webhook受信、軽いJSON API
S3	ファイルがアップ/削除された	非同期（投げっぱなし）	画像処理、CSV取り込み
EventBridge (cron)	決めた時刻・間隔になった	非同期（投げっぱなし）	定期集計、定期通知、ヘルスチェック
SQS	キューにメッセージが溜まった	ポーリング（Lambdaが取りに行く）	大量処理、失敗時の再試行

「呼ばれ方」の3タイプの違いが、入門でいちばん大事なので個別に説明します。

API Gateway（同期）— HTTPで叩きたいとき

スマホアプリや他社サービスから、URLを叩いてその場で結果がほしい。そういうときはAPI Gatewayです。

これは同期呼び出し。呼んだ側がLambdaの返事を待ちます。電話で問い合わせて、相手の回答を受話器を持ったまま待つイメージ。だからLambdaの戻り値はstatusCode・headers・bodyの形にしないと、相手は「500エラー」しか受け取れません。先ほどの最初の関数がこの形だったのは、API Gatewayにつなぐ前提だったからです。

つなぎ方と認証・CORS・レート制限の設計はAWS API Gatewayの記事で詳しくやっています。

S3 / EventBridge（非同期）— 投げっぱなしでいいとき

「ファイルがアップされたらサムネイルを作る」「毎朝9時に集計する」。こういう仕事は、誰かが結果を待っているわけではありません。

これが非同期呼び出しです。S3やEventBridgeは「やっといて」とLambdaにイベントをポンと渡したら、もう返事を待ちません。郵便ポストに手紙を入れたら、配達完了を待たずに立ち去るのと同じ。

ここで初心者が驚くのが、非同期は失敗すると勝手にリトライされることです。同じ画像処理が2回走ったり、集計メールが2通来たりする。だから非同期トリガーの関数は「2回呼ばれても壊れない（冪等＝べきとう）」ように作るのが鉄則です。S3トリガーの具体例はAWS S3の記事にあります。

EventBridgeのcron（定期実行）は、こんな式で「毎日午前0時（UTC）」のように指定します。

# 毎日 UTC 0:00（日本時間 午前9時）に実行
cron(0 0 * * ? *)

# 5分ごとに実行
rate(5 minutes)

日本時間で考えるときはUTCとの9時間差に注意。「朝9時に動かしたい」なら式は0 0（UTC0時）です。ここ、僕は最初9時のつもりで0 9と書いて、夕方6時に動いて焦りました。

SQS（ポーリング）— 大量に来ても取りこぼしたくないとき

注文が一気に1万件来た。API Gatewayで全部同期に受けると、Lambdaが同時に大量起動して下流のDBが悲鳴を上げます。

そこでSQS（メッセージのキュー＝行列）を間に挟みます。来たメッセージはいったんキューに並べ、Lambdaが自分のペースで取りに行く。これがポーリング型です。レジに行列ができても、店員が1人ずつ呼んでさばくのと同じ。混んでも取りこぼさず、処理速度も自分で調整できます。

仕組み上、SQSトリガーだけは「イベントソースマッピング」という別の設定でつなぎます。これは「キューを定期的にのぞいて、メッセージがあればLambdaに渡す」という橋渡し役です。コンソールやCLIで関数とキューを紐づけると有効になります。

やりたいことから逆引きする

迷ったら、トリガーから考えずやりたいことから選びます。

• 「外部からURLで叩きたい」「Webhookを受けたい」→ API Gateway
• 「ファイルが置かれたら処理したい」→ S3
• 「毎日/毎時、決まった時刻に動かしたい」→ EventBridge (cron)
• 「大量に来るデータを順番に・取りこぼさず処理したい」→ SQS

ひとつの関数に複数のトリガーをつけることもできます。たとえば「API Gatewayからも叩けるし、毎朝cronでも動く」関数はよくあります。ただし最初は1関数1トリガーで始めるほうが、エラーの原因を切り分けやすいです。欲張ると、どのトリガー経由で落ちたのか分からなくなります。

料金の考え方（入門中はほぼ0円）

「サーバーレスって高いんでしょ？」とよく聞かれますが、入門中はまず無料です。

Lambdaの料金は、ざっくり**「呼ばれた回数」×「実行時間」×「割り当てたメモリ」で決まります。立ちっぱなしの料金ではなく、動いた分だけ。そして毎月100万回のリクエスト**と一定の実行時間（GB秒）までは無料枠があります。個人の検証や小さな社内ツールなら、この枠で収まることがほとんどです。

注意すべきは、Lambda単体より周辺サービスで課金されがちな点です。

• API Gatewayのリクエスト課金
• CloudWatch Logsのログ保存料金（出しっぱなしで地味に溜まる）
• SQSやS3のリクエスト数
• 外部API呼び出しやデータ転送

僕が最初にうっかりしたのは、console.logを大量に出してCloudWatch Logsが膨らんでいたこと。金額は数十円でしたが、「Lambdaが原因じゃない」と気づくのに時間がかかりました。料金を見るときは、Lambda単体ではなく「この構成全体でどこに課金されるか」をセットで考えるのがコツです。本番運用での費用最適化は姉妹記事で扱います。

公式の最新仕様や料金は変わるので、着手前にAWS Lambda公式の入門ドキュメントを一度見ておくと安心です。この記事は2026年6月時点、Node.js 24ランタイム前提で書いています。

よくある質問

Q. Lambdaをデプロイしたのに何も起きません。 A. トリガーが設定されていない可能性が高いです。Lambdaは自分から動きません。コンソールの関数概要で「トリガーを追加」から、API GatewayやS3などのきっかけをつなげてください。テストだけなら「Test」タブから手動実行もできます。

Q. 同期と非同期、どう見分ければいいですか。 A. 「呼んだ人が返事を待つか」で決まります。HTTPで結果を返すAPI Gatewayは同期。ファイルアップや定期実行のように結果を待たないS3・EventBridgeは非同期です。非同期は失敗時に自動リトライされるので、2回動いても平気な作りにします。

Q. どのランタイム（言語）を選べばいいですか。 A. 初めてならNode.jsかPythonが情報量も多く無難です。この記事はNode.js 24で書いています。チームの得意言語に合わせて構いませんが、最初は1つに絞ったほうが学習が速いです。

Q. コンソールとCLI、どっちで始めるべき？ A. 「一度試すだけ」ならコンソールが速い。「チームで使う」「手順を残したい」ならCLIです。コンソール作業は記録が残らず、後から再現しにくいのが弱点です。

Q. 実行時間が長い処理もLambdaでできますか。 A. 上限は最大15分です。それを超える処理には向きません。長時間バッチはAWS BatchやECSなど別の選択肢を検討してください。Lambdaは「短い・単発」が得意領域です。

実際に試した結果

冒頭で「動かすボタンがない」と戸惑った僕ですが、トリガーの3タイプ（同期・非同期・ポーリング）を理解してからは、選定で迷わなくなりました。

実感として、入門でつまずくのはコードではなく**「いつ・どう呼ばれるか」**の部分です。最初の関数を作るだけなら5分。でも「デプロイしたのに無反応」「非同期で同じ処理が2回走った」「cronがUTCで9時間ずれた」——この3つは、知らないと必ず踏みます。逆に、ここさえ押さえれば、あとはやりたいことから逆引きでトリガーを選ぶだけです。

まずは最初の関数を1個デプロイし、API Gatewayをつないでブラウザから叩いてみてください。「自分のコードがURLで動いた」体験が、いちばんの理解の近道です。慣れてきたら、コールドスタートやIAM最小権限、本番運用の話をAWS Lambda実装の勘所で深掘りしてください。

AWS構成のレビューやCLAUDE.md、デプロイ承認の型をチームで整えたい場合は教材・テンプレートにまとめています。実リポジトリ前提で相談したいときは導入相談・研修もどうぞ。