re:Invent 2025: LocalStackによるサーバーレス開発のローカル環境構築
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
re:Invent 2025 の書き起こし記事については、こちらの Spreadsheet に情報をまとめています。合わせてご確認ください
📖re:Invent 2025: AWS re:Invent 2025 - Developing Serverless Applications Locally with AWS and LocalStack (CNS415)
この動画では、LocalStackとAWSのパートナーシップによるサーバーレス開発の改善について解説しています。LocalStackは120以上のAWSサービスをローカルで実行できるDockerベースのサンドボックスで、クラウドへのデプロイ前にローカルでテストが可能です。サーバーレス開発者が直面する課題として、クラウドでのテストによる遅延、ツール間のコンテキストスイッチング、設定の複雑さ、統合テストの困難さが挙げられます。これらに対し、9月にローンチされたAWS Toolkit for VS CodeとLocalStackの統合により、IDEから直接LocalStackをセットアップでき、ワンクリックでローカルとクラウドを切り替え、ブレークポイントデバッグも可能になりました。デモではSAMテンプレートを使ったデプロイとリモートデバッグが紹介され、Step FunctionsのTest State APIやLambda managed instancesなど、AWSとの同日リリースの実績も示されました。
※ こちらは既存の講演の内容を最大限維持しつつ自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますのでご留意下さい。
本編
LocalStackの概要とAWSサービスへの追従戦略
それでは、ここに来られて嬉しく思います。私たちのプレゼンテーションにお越しいただきありがとうございます。LocalStackとローカルマシン上でのサーバーレスアプリケーション開発について少しお話しさせていただきます。 では、アジェンダに入る前に、簡単に挙手をお願いできますか。LocalStackについて聞いたことがある方、もしかしたら使ったことがある方はいらっしゃいますか。なるほど、ここにいる方の約半分くらいですね、素晴らしいです。比較的ハイレベルな内容にしていきますし、最近行っているAWSとのパートナーシップについても少しお話ししたいと思います。これは皆さんと共有できることを本当に楽しみにしています。これが今日進めていくアジェンダです。ここであまり時間をかけすぎないようにします。早速本題に入りましょう。
それでは一般的に、LocalStackとは何でしょうか。私たちは、ローカルのAWSサンドボックスを想像してみてください。クラウド環境に接続することなく、またはクラウドに接続する前に、ローカルマシン上でアプリケーションを開発およびテストする能力を提供します。ここでご覧いただいているのは、いわば従来のワークフローです。ローカル環境から始めて、ローカルテストを行い、おそらくIDE統合を行い、それからCI/CD環境でいくつかのテストを実行し、そして最後に、開発しているアプリケーションに満足したら、実際のクラウドに変更をプッシュします。ここで得られるメリットとしては、ローカルで実行することで即座にフィードバックループが得られ、すべての変更をクラウドにプッシュする必要がないということです。CI/CDプロセスで実行される完全に分離されたテストサンドボックスがあるので、お互いの変更を上書きすることがなく、そして再び、ローカルで行った変更に満足したら、自信を持って本番環境にデプロイできます。
現在、私たちのスタックには100以上のAWSサービスがあります。この時点で120だと思います。Lambda、SQS、DynamoDB、IAMなど、あらゆるものがあります。また、既存のほとんどのInfrastructure as Codeツール、Terraform、CDKなど、そういったものとも統合しています。ですから、私たちは本当に開発者がいる場所で開発者に会い、アプリケーションをローカルで実行できるようにすることを心がけています。では、一般的にどのように動作するのでしょうか。基本的には、コンテナとして起動するDockerイメージです。つまり、基本的にCLIをインストールして、LocalStack startと入力すると起動し、ターミナルにこのバナーが表示されます。そして2つ目は、単にそれと対話するだけです。これは基本的にAWSエンドポイントURLをlocalhostに設定するだけで、あとはもう準備完了です。AWS CLIとすべてのネイティブツールをそのまま使用できます。
よく受ける質問の1つは、AWSの驚異的なペースとそこから生まれる素晴らしいイノベーションに、私たちはどのように実際に追いついているのかということです。今年のre:Inventでもすでに多くの発表を聞きました。私たちのブースを訪れるほぼすべての人がこの質問をします。基本的には、いくつかの要因の組み合わせに集約されます。まず第一に、私たちは多くの内部ツールを構築してきました。その1つはASF、AWS Server Frameworkと呼ばれるもので、API仕様の自動スクレイピングを多く行っています。AWSサービスに新しい変更が出てきたときは常に検出しています。2つ目は、社内に非常に才能のあるエンジニアリングコミュニティがあり、オープンソースコミュニティもあります。多くの人々がこれらのエミュレータを構築するために懸命に取り組んでいます。これは本当に驚異的な努力です。そして3つ目は、今日お話しすることでもありますが、特にAWSとのパートナーシップがますます増えており、同日リリースを実現し、AWSがリリースした時点で、これらの素晴らしい新機能をすべてローカル開発者エクスペリエンスで実際に利用できるようにしています。
サーバーレス開発者が直面する4つの課題とAWS Toolkit統合による解決策
それでは、Shridharに引き継ぎます。彼がAWSの視点から、サーバーレス開発者の課題について少し共有します。ありがとうございます、Waldemar。LocalStackの機能とそれがどのようにAWSサービスに追いついているかについて議論してきましたが、私たちの焦点を移したいと思います。後ろで大きな音楽が流れているので、もしフィードバック音が聞こえたら、それは私ではないことをご理解ください。サーバーレスアプリケーションを構築する際にサーバーレス開発者が直面する、サーバーレス開発者の課題に焦点を移すべきです。これらの課題は、私たちが協力して取り組んでいる痛点を表しています。AWSサーバーレスチームは取り組んできており、私は特に開発者エクスペリエンスの改善に注力しています。だからこそ、このパートナーシップは非常に価値があるのです。
それでは課題から始めましょう。これを4つの主要な領域に分けて説明します。これらは開発者の日常業務に影響を与えるものです。これらの課題は、生産性、コード品質、開発者の満足度、そして運用効率などを含むアプリケーション全体の品質に大きな影響を与えます。それでは、次のスライドでそれぞれを詳しく見ていきましょう。最初はクラウドでのテストです。クラウドベースの検証は物事を遅くします。イテレーションサイクルを遅くしてしまうんです。AWSの調査によると、開発者はクラウドではなく、ローカルデバイス上でテストやコードを書くことに相当な時間を費やしています。つまり、開発者ができるだけ早く、自分が構築しているものや、それがどのように見えるかを確認できる段階に到達させることが重要だということです。本番環境にデプロイする場合、コードを変更するたびに完全なサイクルを経る必要があります。つまり、検証、テスト、デプロイを経なければならず、フィードバックループは数時間に及ぶこともあります。これは開発者の生産性とイノベーションの速度を劇的に低下させます。これは明らかに良いことではありません。
本来は素早いテストであるべきものが、通常は長いプロセスになってしまい、開発者は実際の検証に頼るのではなく、変更をまとめて行ったり、推測に基づいて作業したりすることを余儀なくされます。
2つ目の課題はツール間のコンテキストスイッチングです。異なるツール間を常に切り替えることには、大きな認知的オーバーヘッドが伴います。開発者は日常的にIDE、CLI、リソースエミュレーターの間を移動します。これが断片化されたワークフローを生み出し、コンテキストスイッチのたびに構築しようとしているものが中断されます。フローが中断され、生産性が低下するんです。複数のツールを管理することで、エラーの可能性が高まり、大きな精神的負荷も生じます。これは特にサーバーレス開発で顕著です。サーバーレス開発では複数のサービス、例えばLambda、SQS、EventBridge、API Gatewayなど、様々なサービスを扱います。常に多数のサービスを一緒に扱うことになり、この課題が最も顕著になります。
次は設定の複雑さです。ローカルサービス統合テストのためのポートマッピングやコード編集は、ローカル環境とクラウド環境の間に不整合を生み出します。開発者はローカルテスト用とクラウドテスト用に別々の設定のコピーを維持しなければならず、これが皆さんもどこかで遭遇したことがある典型的な「私のマシンでは動く」問題につながります。これらの手動設定はエラーが発生しやすいだけでなく、時間がかかり、アプリケーションが進化して大きくなるにつれて、継続的なメンテナンスサイクルが必要になります。
そして最後、これはサーバーレス開発者にとって非常に重要だと強調したいのですが、統合です。先ほど複数のサービスについて触れました。統合テストは難しいんです。はっきり言って。DynamoDB、S3、SQSとのAWSサービス統合のコンテキストでLambda関数をトラブルシューティングするには、複雑なセットアップが必要です。イベント駆動型アーキテクチャは特にローカルでテストするのが困難で、結局開発者は本番環境でテストするアプローチに頼ることになります。そして、それに頼るべきではないことは皆さんご存知の通りです。サービス統合の隠れた複雑さは、関数コード自体よりもはるかに大きく、これが大きなテストギャップを生み出しています。
それでは、課題を理解したところで、 LocalStackとAWSが共同で開発したソリューションを見ていきましょう。AWSとLocalStackのコラボレーションは、シームレスな統合を通じてこれらすべての課題に対処し、 両方の世界の良いところを組み合わせています。次のスライドでは、これがローカルIDEでの作業体験をどのように簡素化するかについてお話しします。詳しく知りたい方はQRコードをスキャンしてください。
AWS Toolkit for VS Codeは、現在LocalStackと直接統合されています。この統合は9月にローンチしました。これにより、統一された開発体験が実現されます。この統合により、完全なAWSサービス統合を備えたLambda関数のローカルテストが可能になります。クラウド環境とローカル環境の間で一貫した動作を提供し、さまざまなサービス統合やサービス接続の手動設定が不要になります。その結果、開発サイクルが加速されます。コンテキストスイッチングが減少し、統合テストサイクルが簡素化され、さらにコード品質の確認にも役立ちます。つまり、実際に本番環境、統合テスト、あるいはステージング環境に送る前に、コードが高品質であることを確認できるのです。
それでは、具体的なメリットについてもっと詳しく見ていきましょう。これらの課題への対処についてお話ししましたが、 それについて説明します。Visual Studio Code IDEで直接、ワンクリックでLocalStackをセットアップできます。つまり、複雑なDockerコマンドや設定ファイルは不要です。すべて自動で処理されます。2つ目は、エミュレートされたすべてのリソースにVS Code IDEから直接アクセスできることです。これは、複数の ツールやインターフェース間でコンテキストを切り替えることなく、開発環境にとどまることができることを意味します。
また、シンプルなクリックでローカルリソースとクラウドリソースを簡単に切り替えることができ、ローカルでテストしてからクラウドにデプロイすることがシームレスになります。クラウドにデプロイしてからテストするのではなく、です。つまり、ここでパラダイムを逆転させているわけです。そして最も重要なのは、劇的に高速なローカルフィードバックループが得られることです。クラウドでテストするのに数分かかっていた変更が、ローカルでは数秒で検証できます。 これにより、開発速度が大幅に向上します。
VS Code統合のライブデモとAWSとのパートナーシップの今後
それでは、Valdemarが説明するライブデモを簡単に見ていきましょう。
素晴らしい、Shridharさん、本当にありがとうございます。私たちがここでブースに、いやスタンドに立って、LocalStackとしてAWS LambdaチームのPMと一緒にいられることを、これ以上ないほど嬉しく思っていることを強調したいと思います。ですので、この統合について話せることは私たち全員にとって本当にエキサイティングなことです。実際のライブデモをお見せできればよかったのですが、これから再生するのは録画されたビデオです。そして私がそれについて説明していきます。約3分間のビデオで、何が起こっているのか見ていきましょう。基本的にここでお見せするのは、Peterが話していたVS Code統合で、シンプルなサンプルアプリケーションをデプロイし、AWS Toolkitを介してLocalStack上で完全に実行し、最後にはIDEから直接ブレークポイントデバッグができることもお見せします。
それでは、このビデオを開始して、少し説明していきます。かなり速いのは分かっていますが、とにかく飛び込んで何をするのか見てみましょう。ここで見ているのは、LocalStack HelloWorldという新しいプロジェクトを作成しているところです。これは実際にはSAM、Serverless Application Modelテンプレートで、基本的にはSAM経由で直接デプロイできるCloudFormationテンプレートをレンダリングしています。素晴らしいのは、これをそのまま取ってAWSに対してデプロイすることもできて、完全に動作するということです。でもここでやろうとしているのは、実際にSAMデプロイを実行して、LocalStackプロファイルを指定することです。LocalStackプロファイルは、他のものと同じローカルのAWSプロファイルです。唯一の違いは、実際にエンドポイントをlocalhostに定義していることです。文字通り、それが唯一の違いです。
SAMデプロイを実行して、リージョン、スタック名、そして基本的な情報といったいくつかのパラメータを指定します。これはすべて標準的なAWSデプロイメントですよね？でも繰り返しますが、デプロイは実際にLocalStackに対して行われています。ここでスタックリソースが見えますが、かなり速くて、数秒ですべてがデプロイされます。そして今、完全にローカルで実行されているLambda関数を持つAPI Gatewayがデプロイされているのが分かります。これは私たちのウェブアプリapp.localstack.cloudで、試してみたい方はぜひどうぞ。これはちょっとAWSコンソールのようなもので、ローカルでリソースをブラウズできます。そしてこれがここで作成されたLambda関数です。そして今、実際に呼び出しを行っています。画面の下部でcurlコマンドが見えますが、curlを実行しているだけで、amazonaws.comをlocalhost.localstack.cloudに置き換えているだけです。それ以外は全く同じ種類のエンドポイントで、呼び出しが実行されたのが分かります。
これはDynamoDBに接続するAPI Gateway Lambda呼び出しの完全なラウンドトリップです。今、Lambdaでいくつかの変更を行っていて、ここで返ってくるメッセージを変更して、もう一度SAMデプロイを行います。つまり、これは基本的にIDEで行われた変更を再デプロイしているだけです。そして再び数秒かかるだけです。CloudFormationの更新を行っていて、すぐに完了するはずです。そしてもう一度curlコマンドを実行して、更新された出力を表示します。
さて、ここまで見てきたものはかなり、まあ基本的なもので、ある意味これは単なるLocalStackの基礎です。でも今からエキサイティングな部分が来ます。LocalStackに詳しい方々にとっては、ここでお見せするのはAWS Toolkitのリモートデバッグ機能です。つまり、ツールキットが提供するのは実質的にリモートデバッグで、Lambdaコード内に直接ブレークポイントを設定でき、右側にリモートデバッグ設定が見えます。これはAWSに対しても使えますし、LocalStackに対してもネイティブに同じ体験ができます。つまり、文字通り同じ体験が得られるということです。ローカルエンドポイントがあり、リモート呼び出しを行うと、実際にそこでブレークポイントにヒットします。変更を加えることができ、コードをステップオーバーできます。日々の作業で慣れている通常のデバッグ体験そのものです。それが、そして最後に更新された出力が見えます。
さて、これで簡単なウォークスルーは終わりです。ビデオはかなり速かったことは承知していますが、AWS ToolkitとLocalStackを使った体験について、少しでも垣間見ていただけたのではないかと思います。そして、Shridharが言ったように、もうdocker composeファイルを設定したり、複雑なセットアップをしたりする必要はありません、ということは言及しておく価値があります。すべて完全に統合されていて、その意味ではターンキーソリューションとなっています。では、それを踏まえて、AWSとのパートナーシップやコラボレーションについて改めて触れて締めくくりたいと思います。これは私たちにとって、オープンソースコミュニティとビジネスの両方を成長させていく上で、本当にエキサイティングなことなんです。私たちは過去にもいくつか、確か半年ほど前だったと思いますが、LocalStackとのStep Functions testingの統合もローンチしています。
実は最近、Step Functionsにいくつかの機能が追加されました。Test State API、JSON Pathサポート、そして変数です。Step Functionsを時々使っている方、あるいは定期的に使っている方にとって、これらはAWSがしばらく前にリリースした本当にキラー機能なんですが、私たちは基本的にAWSと一緒に同日ローンチを実現できたんです。つまり、私たちはAWSの方々と非常に緊密に連携して、リリースされるすべての素晴らしい機能を、皆さんに即座に利用できるようにしているんです。Test State APIは実際、非常に最近のもので、re:Inventだったと思います、数週間前ですね、そう、数週間前です。
これは、ツールキット以外にも、パートナーシップがどんどん形になってきている別の例です。そして、これからもっと出てきます。実際、re:Inventで文字通り、Lambda managed instancesに関するローンチがありました。もしアナウンスをご覧になっていなければ、チェックしてみてください。私たちもそこでブログ記事を公開しましたが、これもまた、AWSと非常に緊密に連携することで実現できた同日ローンチでした。
私たちが継続的に注力している2つ目の部分は、パリティの向上です。デプロイするどんなスタックでも、ローカルエミュレーターに期待される高い忠実度を確実に持つようにしたいんです。私たちは、チームやコミュニティと一緒に懸命に取り組んで、これがクラウド環境の高忠実度なデジタルツインになるようにしています。
そして3つ目は、開発者体験に関するもので、これは大きなトピックになってきています。AIも、クラウドアプリケーションを構築する日々の生活に入り込んできています。そこで私たちは、エミュレーターの上に開発者体験機能を構築して、より多くのデバッグ機能、スタックへのより深いインサイト、例えばIAMポリシーをデバッグする機能などを提供しています。AIは、アプリケーション開発の新しい手段としても登場してきており、私たちは、エージェントコーディングに使えるセキュアなローカルサンドボックスを持っています。
それでは、このセッションを締めくくりたいと思います。あと数分ありますが、ぜひお伝えしたいことがあります。ぜひ私たちのブース1626にお立ち寄りください。ちょうどあちらです、Radiusブースのすぐ後ろにあります。LocalStackブースがあります。ライブデモをお見せして、AWS Toolkitの統合についてもご紹介します。チームがそこにいて、皆さんのご質問にお答えします。また、ぜひフィードバックをいただいて、LocalStackの次に何が登場するのかをご覧いただければと思います。
また、ぜひフィードバックをお寄せください。それは素晴らしいことです。アプリにはセッションのフィードバックを提供する方法がありますので、もし改善できることや学べることがあれば、皆さんが共有してくださるフィードバックをいつでも歓迎します。それでは、これで締めくくりたいと思います。改めてご清聴いただき、ここにお越しいただき本当にありがとうございました。ローカルクラウド開発で次に来るすべてのことを、私はとても楽しみにしています。皆さん、ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用し、元動画の情報をできる限り維持しつつ自動で作成しています。
Discussion