【AWS】『AWS Toolkit for VSCode』でLambda開発してみよう！

自己紹介

こんにちは、2025/3からクラウド戦略チームに参画した佐藤です。
AWSやPythonなどをメインに興味のあることを情報発信できればと思っておりますので、よろしくお願いいたします。

はじめに

昨今のテキストエディタ、あるいはIDE環境といえば真っ先に思いつくのが Visual Studio Code（以後VSCode） なのではないでしょうか。実際私も新しいPCの環境セットアップの中に必ずVSCodeの導入というものがあります。
本記事ではそんなVSCodeでAWSを便利に活用するために提供されている『AWS Toolkit for VSCode』の中でも特に Lambda の開発に絞ってお話していきたいと思います。

従来の Lambda 開発

Lambda 関数を作成する際に皆さんはどのようにして開発を行っていたでしょうか？
私は以下のような形で開発を行うことが多かったです。

このフローではローカルで開発したものを Lambda 上に持ってくる形になります。つまり、ローカル環境では期待通りに動くようにしておくことで、AWS 起因のエラー以外は 起きないようにしておこうという考えです。

ここで Lambda コンソール上で無理やり開発してしまうと、逐一 CloudWatchLogs でログを確認し、コードを修正し、と開発するのは非常に大変だと個人的には思います。したがって、Lambda でテストしてコードに問題がある場合は、ローカルの開発環境に戻ってコードを書き換えていきます。そうすることで、Lambda 関数に書かれているコードとローカルにあるコードに不整合が起きることを防ぐことにもつながります。

ただし、昨今のアジャイル開発の流れからコード修正の頻度が増えるにつれ、ローカル環境とクラウド環境の不整合や、開発時に VSCode （ローカル）とマネジメントコンソール（Lambda）の行き来が頻発することによる生産性の低下が問題になります。

これらの問題を解決するため、AWS Toolkit および AWS SAM を活用していきましょう！

AWS Toolkit で Lambda 開発！

AWS Toolkit で Lambda 開発を行うことで、以下のようなサイクルで開発を行うことができます。このようにすることで、マネジメントコンソールと VSCode を行き来する回数が格段に減り、開発時のストレスを低減することが期待できます。

AWS Toolkit で Lambda 関数をローカル開発するには SAM が不可欠です。
少し面倒ですが、SAM を導入しておいてください。
https://docs.aws.amazon.com/ja_jp/serverless-application-model/latest/developerguide/install-sam-cli.html

AWS SAM を使用してテンプレートからアプリケーションを作成

SAM テンプレートを使用して Lambda の作成を行うことができます。
AWS Toolkit のExplorer > Lambdaを右クリックし、Create Lambda SAM Applicationをクリックします。

ランタイムを選択します。今回は Python3.13 を使用します。

使用するテンプレートを選択します。

アプリを作成するディレクトリを選択します。

後ほど説明ありますが、日本語が含まれるパスを選択しないでください

アプリの名前を入力します。

ターミナルに以下のような出力がされ、指定したアプリ名でフォルダが作成されていることを確認します。

AWS Toolkit の Application Builder を開くと、作成したアプリが追加されています。
フォルダの二つ目のアイコン（Open with Infrastructure Composer）を開くと、作成するリソースを視覚的に確認できます。
今回は API Gateway は不要なので、消しておきます。

HelloWorldFunctionの</>マークをクリックするとコードを確認することができます。

関数の名前を変えてみましょう。
先ほどの Infrastructure Composer から HelloWorldFunction をダブルクリックします。
LogicalIdを変更して保存すると、自動的に Application Builder 内の名前も変更されます。

せっかくなのでコードをおいているフォルダ名も変更しましょう。
hello_worldという名前のフォルダを別の名前に変更します。

Infrastructure Composer からSource pathを変更し、保存します。

AWS SAM でビルド

さて、アプリを構築していきましょう！
Application Builder のアプリフォルダにある3つ目のアイコン（Build SAM Template）をクリックします。

Specify build flagを選択します。

今回は Lambda と VSCode に注視するため各オプションについて深く触れませんが、画像の通り有効化します。
(処理の高速化やコンテナとして Lambda をデプロイするなど)

OKをクリックすると自動的にターミナルが起動し、画像のように表示されればビルドは成功です。
うまくいかない場合は Docker が原因の可能性があるので確認してみてください。

開発と実行

Application Builder の▷ボタンをクリックすると、画面のような表示がされ、マネジメントコンソール上でテストする際と似たような設定項目が表示されます。今回は Payload なしで実行してみましょう。

初回はコンテナの起動に時間がかかりますが、画像のような形でログが出力されます

コードを編集してみましょう。（</>マークをクリックしてコードを編集してファイル保存）
今回はカンマ区切りに入力された数字をすべて足して出力するといったものを作ってみようと思います。

def lambda_handler(event, context):
    result = 0
    for i in event['data'].split(','):
        result += int(i)
    return result

再度▷ボタンをクリックし今度は Payload に以下のような入力を与えてあげます。

{
  "data": "1,2,3,4,5"
}

上記でInvokeするとターミナルが起動し、ログが出力されます。
REPORTが表示されるのが非常に便利ですね、タイムアウト値の参考にしたり、コールドスタートの影響を予測するのに役立ちそうです。

外部モジュールを利用する

さきほど、python の繰り返し処理を使って合計値を求めましたが、実際リストの合計を出力させるのには numpy を利用することが一般的かと思います。
以下のように書いたほうがなんかかっこいいですよね。

import numpy as np

def lambda_handler(event, context):
    return int(np.sum(list(map(int, event['data'].split(',')))))

そこで、標準モジュールではないモジュールの利用方法も確認してみましょう。
作成されたアプリフォルダ（もともとhello_worldだった場所）にrequirements.txtがあるため、そこに必要なモジュールを追加します。
今回は画像のように numpy を追記します。

処理時間について
今回の場合は Duration （処理時間）は for 文に軍配が上がっていますね。試しに少しローカルで実行時間の比較をしてみましたが、足し算を行う数字の数が増えれば増えるほど numpy のほうが処理時間が早くなりそうです。今回のように5つ程度であれば for 文の方が早い場合があるようです。

#	Init Duration	Duration
for文	0.21ms	11931.86ms
numpy	0.09ms	18421.84ms

レイヤーを作成するのってちょっとめんどくさかったりするので、コンテナで Lambda を作ると、この辺は楽ですね。

Lambda をデプロイ！

では実際に Lambda をデプロイしてみましょう！
Application Builder の4つ目のアイコン「Deploy SAM Application」をクリックします。

同期かどうかを選択できます。
今回は開発環境なのでSyncを選択します。本番環境などの不用意に変更させたくない環境ではDeployを選択しましょう。

リージョンを選択します。

スタック名を指定します。

AWS SAM が情報を保存する S3 バケットを選択、または作成します。
今回は既存バケットがないので新規作成します。

最後にオプションを選択します。
Watchオプションを有効化しておくことで、コードの変更を監視し、自動的にデプロイすることが可能です。

UnicodeError が発生した場合
パスに日本語が含まれていると、samconfig.tomlファイルに文字化けした絶対パスが追加されている可能性があります。
パスを英語にして文字化けしている部分を書き換えてあげるのが無難かと思います。

同期だけど開発環境であってるよね？という旨のポップアップが表示されるのでOKを押します。

。。。
。。。

さて、完了するのを待っているとどうやら実行に失敗してしまったようです。
エラーメッセージを確認すると、CloudFormation がROLLBACK_COMPLETEに遷移してしまっていることがわかります。
ではなぜロールバックしてしまったのかを確認します。
ターミナルのログに Cloudformation スタックのステータス遷移のログが出力されています。

確認すると、削除した API Gateway の情報がテンプレートのOutputsで参照されてしまっていることが原因だとわかります。今回のエラーメッセージには出ていませんが、HelloWorldFunctionRoleもないことがわかるので、こちらも併せて修正しておきましょう。

再度デプロイしてみましょう。
その前に先ほどロールバックしてしまったスタックを削除するため、以下のコマンドを実行します。

sam delete --stack-name <スタック名> --profile <プロファイル名>

それではもう一度デプロイします。
無事成功したようです！

コードを編集してみましょう！

import numpy as np

def lambda_handler(event, context):
    return int(np.sum(list(map(int, event['data'].split(','))))) ** 2

上記のように変更して保存してみます。

保存をしたタイミングでSAM Syncターミナルが動きます。
マネジメントコンソールからも確認すると変更が適用されていることがわかります。

これでローカル環境とAWS上でコードの整合性がとれなくなる問題が一気に解決します！感動！

Lambda をテスト

デプロイ完了後に当然 AWS 上でも正常に機能するかのテストを行う必要があります。
よくある IAM Role に権限が足りなかったなどの AWS 上固有のエラーを防ぐためです。
なんと！これも VSCode 上から可能です！

Application Builder の Lambda 関数を開くと、雲マークの ARN が追加されています。

右クリックすると画像のようなメニューが表示されます。

Invoke in the cloudをクリックすると、呼び出しメニューが開くので、サンプルイベントを入力しRemote Invokeをクリックします。

ターミナルが起動しログが表示されます。
2乗するように変更していたので225が出力されていますね。

Search Logボタンをクリックすることでログを検索することも可能です！

Live Tail

2025/03/04に AWS Lambda adds support for Amazon CloudWatch Logs Live Tail in VS Code IDE が発表されました。
せっかくの機会なので試してみましょう！
AWS Toolkit の Explorer または Application Builder から Tail Logs をクリックします。

先ほどと同様の手順で関数を呼び出してみると、開かれたテキストファイルに自動的に、AWS試験風に言うと「ほぼリアルタイム」にログが書き込まれます。
もちろんマネジメントコンソール上から実行しても同様に書き込まれます。

設定時にフィルタリングも可能なため、エラーログのみ吐かせるなど用途は多そうです。

終わりに

今回は前々からもっと効率いい方法あるのはわかってるんだけど、結局毎回従来の方法で開発をしてしまっていた Lambda 関数を VSCode を使用して効率的に開発する方法についてまとめてみました。

特にPCのメモリを圧迫している Chrome と VSCode のメモリ使用量を減らせるんじゃないかというすごく私的なメリットがあったりします（笑）
導入も簡単ですので、ぜひ使ってみてはいかがでしょうか！

それでは、よい Lambda ライフを過ごしましょう！
（作ったものでいらないものは削除をお忘れなく！）

弊社では一緒に働く仲間を募集中です！

現在、様々な職種を募集しております。
カジュアル面談も可能ですので、ご連絡お待ちしております！

募集内容等詳細は、是非採用サイトをご確認ください。
https://engineer.po-holdings.co.jp/