こんにちは。Engineering Officeのアクセシビリティアドボケート、辻勝利です。 6月のある朝、私は名古屋のあるビルの一室で、植木鉢を両手で抱え、聞こえてくる水の音を頼りに歩いていました。隣では竹中さんが猫の鳴き声を追いかけ、浜谷さんは焼き網の上で肉が焼ける音に、息を詰めて耳をすませています。三人が手にしていたのは、どれも映像のない、「音」だけで遊ぶゲームでした。 傍から見たら、なかなか不思議な大人三人組だったと思います。でもその場にいた私たちは、ただただ夢中でした。目で何かを確かめるのではなく、耳をすませて、音だけを頼りに遊ぶ。その新鮮さに、すっかり夢中になっていたのです。 私たちが訪れていたのは、「オーディオゲームセンター」という展示でした。映像ではなく「音」からゲームをつくり、音だけで遊ぶ——そんなユニークな作品が集まった場所です。名古屋で開かれていることを知り、出張のついでに同僚を誘って足を運んでみました。 制限時間内に、音だけを頼りに花へ水をあげる「はなちゃんを救え」。会場で最初に夢中になった作品です。 この記事では、その朝のことを書いてみたいと思います。 なぜ、この三人で行こうと思ったのか 少しだけ、前日の話をさせてください。私と竹中さんは名古屋で仕事があり、前日から出張していました。 せっかく名古屋まで足を運ぶのだから、この出張をアクセシビリティの活動にもつなげられないか——そう考えていたときに、ちょうどオーディオゲームセンターの展示が名古屋で開かれていることを知りました。アクセシビリティのアドボケートとして、これはぜひこの耳で確かめておきたい展示です。そう考えた私は、竹中さんに加えて、名古屋オフィスで働く浜谷さんにも声をかけました。浜谷さんは、ドライバーに向けたサウンド設計を仕事にされている方です。「音」を扱うプロと一緒に、音のゲームを体験できる。これ以上ない組み合わせだと思いました。 正直に打ち明けると、この「お誘い」には、私なりの小さな狙いもありました。 アクセシビリティのアドボケートとして、私が会社のなかで担いたい役割は、製品やサービスを使いやすくすることだけではありません。その手前にある、「アクセシビリティの文化」そのものを社内に少しずつ根づかせていくことだと考えています。 そのためには、ガイドラインやチェックリストと向き合う時間だけでなく、まだ見たこと・触れたことのない領域のアクセシビリティに、同僚たちが自然と出会えるきっかけをつくりたい。そんな思いが、以前からずっとありました。今回の展示は、そのきっかけにぴったりだと感じたのです。 「音」を共通言語にして遊んだ、あの日の記憶 この場所に同僚を連れて行きたかった理由は、もうひとつあります。それは、私自身の忘れられない原体験です。 ずいぶん前のことになりますが、私はかつて東京で、「オーディオゲームをつくるハッカソン」に参加したことがありました。視覚障害のある人も、目の見える人も、一緒になって音だけのゲームをつくり、その場で遊ぶ。そんなイベントでした。 そこで私が感じたのは、なんとも言えない心地よさでした。その場には、難しい「アクセシビリティ」の話は、ほとんど出てこなかったのです。「視覚障害者のために」とか「配慮しなければ」といった肩に力の入った言葉ではなく、ただ純粋に、「音を中心にしたゲームって面白いよね」という一点で人が集まっていました。 「音」という共通言語の前では、目が見えるかどうかは、その場の主役ではありませんでした。みんなが同じように耳をすませ、同じように戸惑い、同じように笑う。あの対等でフラットな空気が、私にはとても新鮮で、心地よかったのです。 この感覚を、ぜひ同僚にも味わってほしい。難しい理屈ではなく、まず「面白い」から入ってもらえる体験として——そう思ったことが、今回のお誘いの根っこにありました。 当日、私たちを夢中にさせた作品たち さて、当日の会場には、いくつもの作品が展示されていました。どれも、思わず「お、これは!」と声が出てしまうような、ユニークなものばかりです。 1つめは、 植木鉢を抱えて、音を頼りに水を探すゲーム 。鉢を持って歩き回り、聞こえてくる音を手がかりに、水のありかを探し当てます。制限時間内に花へ十分なお水をあげられるかは、私たちの耳と方向感覚にかかっています。冒頭で私が抱えていたのが、この鉢でした。 2つめは、 音だけで進行する人狼ゲーム 。誰が人狼なのか、表情ではなく声と音だけで推理していく緊張感がありました。それぞれのプレーヤーには、小さなスピーカーを通して別々の振動が伝えられ、どんな振動が届いたのかを話し合いながら、誰が人狼なのかを推理していきます。自分に届いた振動のリズムを、そのまま声に出してしまわないよう気をつけながら、慎重に人狼を探しました。 声と音だけで人狼を推理する「サウンドウルフ」と、鳴き声から動物を当てるクイズ。プレーヤーには小さなスピーカーから別々の振動が届きます。 3つめは、 猫の鳴き声を頼りに、迷路の中で猫を探して捕まえるゲーム 。「ニャー」という声を追いかけて夢中になっている竹中さんの様子が、その声の弾み方から伝わってきて、なんとも微笑ましく感じました。見つけたと思った猫が、ふっと別の方向へ鳴きながら逃げていく。その手応えのなさに、私は昔飼っていたやんちゃな犬のことを思い出しました。 「Echolocation Maze ― 迷路でねこ探し」。アルミのフレームの中に入り、耳をすませて猫を探しているところ。目ではなく、音に集中する時間です。 4つめは、 音を頼りに、ちょうどよい焼き加減を狙って焼肉を焼くゲーム 。お肉が焼ける音の変化だけで、食べごろを見極める。サウンド設計を仕事にしている浜谷さんが、ここでいちばん真剣になっているのが、その張りつめた集中ぶりから伝わってきました。三人で同時にお肉を取り出すとボーナス点がもらえることもあって、それぞれが真剣にタイミングを見計らいながらゲームを進めました。 お肉が焼ける音の変化だけで、食べごろを見極める焼肉ゲーム。サウンド設計が本職の浜谷さんが、いちばん真剣に聞き入っていました。 そしてもうひとつ、ゲームというより、 動かすと振動に合わせて笑い出す提灯のおもちゃ もありました。手のなかで震えながら笑う提灯に、思わずこちらまで笑ってしまいました。子どもの頃に遊んだ「笑い袋」を思い出すような、ちょっと懐かしい作品です。 どの作品も、目で見て楽しむものではありません。耳をすませ、手で感じ、音の変化に身をゆだねて遊ぶ。気がつけば三人とも、すっかり童心に返って盛り上がっていました。 「面白い」が、いちばん最初にあっていい 会場を出たあと、私はふと、あの東京のハッカソンで感じた心地よさが、そのままここにもあったことに気づきました。 この朝、私たちは一度も、肩肘張った「アクセシビリティ」の話をしませんでした。ただ、音のゲームが面白くて、三人で笑い合っていただけです。目が見える二人と、見えない私とが、まったく同じスタートラインで戸惑い、同じように夢中になれる。そういう体験を、言葉ではなく、身体で分かち合えたことが、私にはとても嬉しかったのです。 アクセシビリティというテーマは、ともすると「正しさ」や「やらなければいけないこと」として語られがちです。それももちろん大切なことです。でも、その入り口に、こんなふうに「ただ純粋に面白い」という体験があってもいいはずだと、あらためて思いました。難しい話の前に、まず一緒に楽しんでしまう。そこから自然と、「音だけでこんなに遊べるんだ」「目に頼らない世界にも、こんな豊かさがあるんだ」という気づきが生まれていく。 これからも私は、社内のいろんな人と、こういう「触れるきっかけ」を少しずつ増やしていきたいと思っています。難しい顔で身構える前に、まず一緒に耳をすませて、笑ってしまう。アクセシビリティの文化は、案外そういう楽しい時間の積み重ねから根づいていくのかもしれない——名古屋出張の締めくくりに、そんなことを思ったのでした。 もうひとつの出会い ― 鼓動を伝えるモビリティ「QUENELLE」 会場には、オーディオゲームとは別に、もうひとつ強く印象に残った展示がありました。「QUENELLE（くねる）」という、小型EVのコンセプト作品です。 これは、乗る人の鼓動を読み取り、それを音や光、振動として映し出す乗り物でした。乗り物を「操作する道具」としてではなく、感覚でつながる相手のように感じさせてくれる——そんな試みです。私も実際にまたがらせてもらいました。 「QUENELLE」にまたがらせてもらいました。なお、同席されたスタッフの方など、ご本人の同意を確認できていない方のお顔は画像処理をしています。 鼓動を音・光・振動で映し出す、小型EVのコンセプト作品。乗り物を「操作する道具」から「ともにある存在」へと近づけようとする試みです。 ドライバーに向けたサウンド設計を仕事にする浜谷さんが、この作品の前で何を感じていたのか。それは、次の感想に譲りたいと思います。 一緒に行った二人から 最後に、同行してくれた二人に、当日の感想を一言ずつ書いてもらいました。 現地に行くまでは「音のゲーム」というものがまったく想像できず、どちらかといえば、見た目には地味で質素な作品をイメージしていました。でも、実際にプレーしてみると、自分自身が夢中になって遊んでしまうほど面白くて驚きました。子どもから大人まで、幅広い世代の人たちが一緒に楽しめる——オーディオゲームには、そんな可能性があると感じました。（竹中） 車を運転中のドライバーは、とても不自由です。ずっと前を見ていないといけないし、好きに動くこともできない。ほとんど唯一の愉しみは「音」ですが、音楽を流すか、ラジオを聴くか、同乗者とのお喋りか。それって数十年前からほとんど何も変わっていない。「音を愉しむ」って、もっと自由で、色んな可能性があるんじゃないか?と、ずっと考えていました。一緒に体験したオーディオゲームセンターの作品は、自分の中にあった漠然とした仮説を、確信へと一歩近づけてくれました。（浜谷） 目を使わずに「音」だけで遊ぶ時間は、私にとって、アクセシビリティの新しい入り口を確かめ直す時間でもありました。もし機会があれば、ぜひ一度、耳だけを頼りに遊んでみてください。きっと、思っているよりずっと豊かな世界が広がっています。 参考リンク オーディオゲームセンター: https://artscape.jp/exhibitions/64694/ オーディオゲームをつくるハッカソン（CCBT）: https://ccbt.rekibun.or.jp/events/audiogamecenter_ccbt_hackathon

本記事は、2026 年 6 月 22 日に公開された Run isolated sandboxes with full lifecycle control: AWS Lambda introduces MicroVMs を翻訳したものです。翻訳は Solutions Architect の齋藤 拓巳が担当しました。 本日、AWS Lambda MicroVMs を発表します。これは AWS Lambda 内の新しいサーバーレスコンピューティングプリミティブで、ユーザーや AI が生成したコードを分離されたステートフルな実行環境で実行できます。 仮想マシンレベルの分離、ほぼ瞬時の起動と再開、環境のライフサイクルと状態の直接制御が可能で、インフラストラクチャの管理や複雑な仮想化技術の専門知識は不要です。 Lambda MicroVMs は Firecracker を基盤としています。これは、月間 15 兆回を超える Lambda 関数の呼び出しを支えてきた軽量仮想化技術と同じものです。 この機能が求められる背景 ここ数年、新しい種類のマルチテナントアプリケーションが登場しています。これらのアプリケーションはすべて、エンドユーザーごとに専用の実行環境を提供し、アプリケーション開発者が書いていないコードを安全に実行する必要があるという共通点を持っています。AI コーディングアシスタント、インタラクティブなコード環境、データ分析プラットフォーム、脆弱性スキャナー、ユーザー提供のスクリプトを実行するゲームサーバーなどがこのパターンに該当します。現在この機能を構築するには、難しい選択を迫られます。仮想マシンは強力な分離を提供しますが、起動に数分かかります。コンテナは数秒で起動しますが、カーネル共有アーキテクチャのため、信頼できないコードを安全に封じ込めるには大規模なカスタムのセキュリティ強化が必要です。Functions as a Service はイベント駆動型のリクエスト・レスポンスワークロードに最適化されていますが、ユーザーとのインタラクション間で環境の状態を保持する必要がある長時間実行のインタラクティブセッション向けには設計されていません。その結果、開発者はパフォーマンスと分離のトレードオフを受け入れるか、エンドユーザーに低レイテンシーの体験を提供しながら分離された実行を実現するために、カスタム仮想化インフラストラクチャの構築と運用に多大なエンジニアリングリソースを投資するかの選択を迫られます。これは深い専門知識を必要とし、本来構築しようとしているプロダクトからエンジニアリング時間を奪う取り組みです。 Lambda MicroVMs は、まさにこのギャップを埋めるために専用設計されています。 各 MicroVM は、単一のエンドユーザーまたはセッションに対して独自の分離された環境を提供し、高速に起動し、セッションの間メモリとディスクの状態を保持し、ユーザーが離席した際には低コストのアイドル状態に一時停止します。 同じ Firecracker テクノロジーが既に AWS Lambda Functions の基盤となっているため、このスタックを大規模に運用してきたサービスの運用成熟度をそのまま活用できます。 試してみましょう まず、AWS Lambda コンソールに移動すると、左側のナビゲーションメニューに Lambda MicroVMs が表示されるようになっています。最初に MicroVM イメージを作成する必要があります。 Flask ウェブアプリとその Dockerfile を zip ファイルにパッケージ化し、 Amazon Simple Storage Service (Amazon S3) バケットにアップロードしました。 Flask API – app.py import logging from flask import Flask, jsonify app = Flask(__name__) logging.basicConfig(level=logging.INFO) @app.route("/") def hello(): app.logger.info("Received request to hello world endpoint") return jsonify(message="Hello, World!") if __name__ == "__main__": app.run(host="0.0.0.0", port=5000) Dockerfile FROM public.ecr.aws/lambda/microvms:al2023-minimal RUN dnf install -y python3 python3-pip && dnf clean all WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY app.py . EXPOSE 5000 CMD ["gunicorn", "--bind", "0.0.0.0:5000", "app:app"] 以下のコマンドを使用して MicroVM イメージを作成しました。 aws lambda-microvms create-microvm-image \ --code-artifact uri= --name \ --base-image-arn arn:aws:lambda:us-east-1:aws:microvm-image:al2023-1 \ --build-role-arn 上の画像のように、AWS コンソールで MicroVM Image を作成することもできます。 コマンドを実行すると、Lambda が zip を取得し、Dockerfile を実行し、アプリケーションを初期化して、実行中のディスクとメモリの状態の Firecracker スナップショットを取得しました。 ビルドログは /aws/lambda/microvms/ 配下の Amazon CloudWatch にリアルタイムでストリーミングされ、イメージの準備が完了すると、 Amazon Resource Name (ARN) とバージョン番号とともにコンソールに表示されました。 aws lambda-microvms run-microvm \ --image-identifier arn:aws:lambda:::microvm-image:my-image \ --execution-role-arn arn:aws:iam:::role/MicroVMExecutionRole \ --idle-policy '{"maxIdleDurationSeconds":900,"suspendedDurationSeconds":300,"autoResumeEnabled":true}' 起動は AWS コンソールまたは CLI からも行えます。 ここでは、イメージ ARN と、15 分間操作がないと自動的にサスペンドし、次のリクエストを受信すると自動的にレジュームするよう設定したアイドルポリシーを渡しました。 ネットワークの設定は不要です。 Lambda は MicroVM に一意の ID を割り当て、専用のエンドポイント URL を返し、新しい MicroVM を起動します。この MicroVM はスナップショットからレジュームされるため、Flask アプリはすでに実行された状態になっています。 実際、起動が完了した瞬間には Flask アプリはすでに動作していました。 たった 1 回の API 呼び出しで、完全に初期化されブートストラップされたコンピューティング環境が手に入ります。 トラフィックを送信するために、CLI で短期間有効な認証トークンを生成し、 X-aws-proxy-auth ヘッダーを使用して通常の HTTPS リクエストに添付しました。 リクエストはすぐに Flask アプリに到達しました。 その後、MicroVM をサスペンドのしきい値を超えてアイドル状態にしたところ、MicroVM はサスペンドされ、メモリとディスクの状態がスナップショットとして保存されました。 次に別のリクエストを送信すると、アプリケーションの状態が完全に保持されたまま再開されました。 クライアント側からは、一時停止が発生したことはまったくわかりませんでした。 仕組み 内部的には、Lambda MicroVMs は、これまで単一の AWS コンピューティングサービスでは同時に提供されていなかった 3 つの機能を実現しています。 1 つ目は、Firecracker による仮想マシンレベルの分離です。 各セッションは専用の MicroVM で実行され、ユーザー間でカーネルやリソースが共有されることはありません。 そのため、あるユーザーが提供した信頼されていないコードはそのユーザーの実行環境内に封じ込められ、他の環境や基盤システムへのアクセスはできません。 2 つ目は、高速な起動と再開です。 このモデルは「イメージを作成してから起動する」方式です。Dockerfile と Amazon S3 に zip アーティファクトとしてパッケージ化されたコードを提供して MicroVM Image を作成すると、Lambda が Dockerfile を実行し、アプリケーションを初期化し、実行中の環境のメモリとディスクの状態の Firecracker スナップショットを取得します。 そのイメージから起動される後続のすべての MicroVM は、コールドブートではなく事前に初期化されたスナップショットから再開されるため、起動とアイドル状態からの再開の両方でほぼ瞬時の起動レイテンシーを実現します。 数ギガバイト規模のインタラクティブセッションでも、エンドユーザーが快適に操作できるほど素早くオンラインに復帰します。 3 つ目は、ステートフルな実行です。 実行中の MicroVM は、ユーザーのセッション全体を通じてメモリ、ディスク、実行中のプロセスを保持します。 アイドル期間中、MicroVM はメモリとディスクの状態をそのまま維持したままサスペンドでき、トラフィックが到着すると再開されます。 インストール済みのパッケージ、ロード済みのモデル、作業中のファイルセットは、ユーザーがセッションを再開した際にすぐに利用可能です。 MicroVM は最大 8 時間の合計実行時間をサポートし、設定可能なアイドル時間の後に自動的にサスペンドできるため、数分で完了するソフトウェア脆弱性スキャン、数時間実行されるデータ分析アプリケーション、長時間のアイドル期間を伴うインタラクティブなコーディングセッションなど、多様なプロダクトを簡単に構築できます。 Lambda MicroVMs は事前に初期化されたスナップショットから起動されるため、初期化時に一意のコンテンツを生成したり、ネットワーク接続を確立したり、一時的なデータをロードしたりするアプリケーションでは、互換性のためにサービスが提供するフックとの統合が必要になる場合があります。 Lambda MicroVMs は AWS Lambda 内の新しいリソースであり、独自の API を備えています。 Lambda Functions は引き続きイベント駆動型のリクエスト・レスポンスワークロードに最適な選択肢であり、Lambda MicroVMs はマルチテナントアプリケーション向けに特化して構築されています。具体的には、各エンドユーザーやセッションに対して、ユーザーまたは AI が生成したコードを実行するための独立した分離環境を提供する必要があるアプリケーションに適しています。 この 2 つは互いを補完する関係にあります。 イベント駆動型のバックボーンに Lambda Functions を使用しているアプリケーションは、信頼できないコードを分離して実行する必要があるステップで Lambda MicroVMs を呼び出すことができます。 お客様がアプリケーションを持ち込み、サービスが実行環境を提供します。 提供開始 AWS Lambda MicroVMs は、米国東部 (バージニア北部、オハイオ)、米国西部 (オレゴン)、欧州 (アイルランド)、アジアパシフィック (東京) の各 リージョン で本日より利用可能です。ARM64 アーキテクチャ上で、MicroVM あたり最大 16 vCPU、32 GB のメモリ、32 GB のディスクを提供します。 アイドル状態の MicroVM は、API 呼び出しによる明示的なサスペンド、またはライフサイクルポリシーによる自動サスペンドが可能で、完全な状態を保持したまま高速に再開できるため、実行コストを削減できます。 料金の詳細は AWS Lambda の料金ページ をご覧ください。 開始するには、 AWS Lambda コンソール にアクセスするか、 Lambda MicroVMs 製品ページ で詳細をご確認ください。 ドキュメントについては、 Lambda MicroVMs デベロッパーガイド を参照してください。 著者について Micah Walter Micah Walter は、ニューヨーク市地域およびその他の地域のエンタープライズのお客様を支援するシニアソリューションアーキテクトです。クラウドへの移行のあらゆる段階で、エグゼクティブ、エンジニア、アーキテクトに対してアドバイスを行っており、サステナビリティと実践的な設計に深く注力しています。余暇には、アウトドアや写真撮影、家中を走り回る子どもたちを追いかけて楽しんでいます。 翻訳者について 齋藤 拓巳 ソリューションアーキテクトとして幅広いお客様の AWS 導入支援を担当しています。AWS Lambda や Amazon API Gateway などのサーバレスのサービスが好きです。

こんにちは。LINEアプリ開発SBU AIディベロッパーエクスペリエンスチームの onevcat（王 巍）です。最近は、AI エージェントを開発・検証のループに組み込むためのツールづくりに取り組んでい...