VOICEVOX EngineとLambda Web Adapterでサーバレスずんだもんを開発した話

サーバレスずんだもんなのだ

ふと「APIでずんだもんとおしゃべりしたいのだ」という発想が頭に浮かびました。浮かんでしまったのです。

最初に引っかかったのはコストです。VOICEVOX:ずんだもんをAWSのEC2やFargateで常時起動しておくと、音声合成リクエストが1件も来ない深夜でも課金されます。月数千円から数万円という固定費が、ずんだもんがしゃべってくれるかどうかに関係なく発生し続けます。「それはちょっと、もったいないのだ」と、ずんだもんに言われた気がしました。

そこで目をつけたのが、お馴染みのAWS Lambdaです。Lambdaはリクエストが来た瞬間だけ起動して処理し、その時間だけ課金されます。リクエストが来なければ一切課金されません。「サーバレスずんだもん」は、使った分だけ料金が発生する、呼ばれたときだけ元気よく起動する音声合成バックエンドであるべきです。これを実現できれば、AIエージェントと組み合わせるなど、様々なケースにおいて、維持費が最小で済みます。

ただし、VOICEVOX ENGINEは元々Webサーバとして常駐するプロセスです。Lambdaは関数単位で起動するイベント駆動型の実行環境です。この二つを組み合わせるには、もう一つ仕掛けが必要でした。今回、その役を担うのがLambda Web Adapter（LWA）です。

本記事では、VOICEVOX ENGINEの公式コンテナをLambdaで動かし、API Gateway上で動かすまで手順を、実際に直面した課題も含めて解説します。

VOICEVOXの利用時は「VOICEVOX:ずんだもん」等のクレジット表記が必要です。
詳しくはVOICEVOXの公式ページから利用規約をご確認ください。

アーキテクチャ

ずんだもんとおしゃべりするのにARM64（Graviton）を選ぶのは、コストとパフォーマンスの両面での合理的な選択です。x86_64と比べて約20%安価なうえ、CPUバウンドな音声合成処理でも性能上で優位だと考えられます。

UI
  └── API Gateway（REST API / ストリーミング統合）
        └── Lambda関数（ARM64 / コンテナイメージ）
              ├── Lambda Web Adapter（Lambda Extension）
              └── VOICEVOX ENGINE（FastAPI / port 50021）

Lambda Web Adapter とは

Lambda Web Adapter（LWA）は、AWSが開発するオープンソースのツールです。GitHubリポジトリ（awslabs/aws-lambda-web-adapter）で公開されており、2026年3月にv1.0.0がリリース（GA）されました。

通常、Lambda関数を書くにはLambda固有のハンドラシグネチャ（def handler(event, context) など）に従う必要があります。既存のWebアプリをそのままデプロイしたいときは、このシグネチャに合わせてコードを書き換えるか、変換レイヤを自前で実装するかの二択を迫られます。LWAを使うと、Dockerfileに1行追加するだけで、この課題を解決できます。

COPY --from=public.ecr.aws/awsguru/aws-lambda-adapter:1.0.0 \
    /lambda-adapter /opt/extensions/lambda-adapter

LWAの仕組み

LWAはLambda Extension（拡張機能）として動作します。API GatewayやALBからイベントを受け取ると、それを通常のHTTP リクエストに変換し、コンテナ内で起動しているWebサーバのプロセスにフォワードします。Webサーバ側はLambda Extensionの存在を意識する必要がなく、ローカルやサーバで動かすときと同じコードのまま応答を返すだけです。

API Gateway イベント
  └── Lambda ランタイム
        └── Lambda Web Adapter（Extension）
              ↓ HTTP リクエストに変換
              └── 既存の Web サーバー（FastAPI, Flask, Express.js, Spring Boot...）

LWAのメリット

まず、既存コードへの変更がほぼ不要である点が大きいです。FastAPIやFlaskで書いたアプリがそのまま動きます。本来コンテナのメリットであるポータビリティをLambdaでも活かすことができ、同じDockerイメージをLambda、EC2、Fargate、ローカル等で共通して動かせます。

また、LWAはレスポンスストリーミングに対応しています。API GatewayのREST APIで使えるresponse-streaming-invocations URIと組み合わせることで、音声データのような大きなバイナリレスポンスをチャンク転送できます。これが今回の構成でresponse_streamモードを選ぶ理由です。

LWAを使ってもLambdaの従量課金モデルはそのまま維持されるため、気になるコストの面でも安心できます。Fargateのように最低起動単位の固定費が発生するわけではありません。「使った分だけ」という特性を損なわずに既存のWebアプリをLambdaで動かせます。

LWAとVOICEVOX ENGINEの相性

VOICEVOX ENGINEの実態はHTTPサーバです。公式 GitHub の READMEには「実態はHTTPサーバなので、リクエストを送信すればテキスト音声合成できます」と明記されています。ソースコードを見ると、application.pyでFastAPIインスタンスを生成し、run.pyで uvicorn.run(app, ...)を呼び出す構成になっています。HTTPリクエストを受信できるサーバである以上、LWAとの相性は原理的に問題ありません。

前提条件

ずんだもんとおしゃべりするための開発環境を揃えます。

• AWS CLI v2 インストール・認証済み
• Docker buildx インストール済み
• API Gateway REST API（RegionalまたはPrivateエンドポイント）を作成済み
• インターネット接続あり

今回、AWSのリージョンはus-east-1を指定しています。東京リージョンの場合はap-northeast-1で読み替えてください。

構築手順

前提の確認と環境変数の設定

1. ツールのバージョン確認

まずツールのバージョンとAWSとの認証を確認します。

aws --version
# 期待: aws-cli/2.x.x 以上

docker buildx version
# 期待: github.com/docker/buildx v0.10.0 以上

aws sts get-caller-identity
# 期待: Account / UserId / Arn が返る

2. 環境変数を設定

続いて、以降のステップで繰り返し使う環境変数をまとめて設定します。REST_API_IDだけは次の確認コマンドで実際の値を拾ってから差し替えてください。

export AWS_REGION=us-east-1
export AWS_ACCOUNT_ID=$(aws sts get-caller-identity \
  --query Account --output text)
export ECR_REPO_NAME=voicevox-tts
export LAMBDA_FUNC_NAME=voicevox-tts
export LAMBDA_ROLE_NAME=voicevox-lambda-role
export IMAGE_URI="${AWS_ACCOUNT_ID}.dkr.ecr.${AWS_REGION}.amazonaws.com/${ECR_REPO_NAME}:latest"

export REST_API_ID=a1b2c3d4e5   # Step 3 で確認する
export STAGE_NAME=prod

echo "Account     : ${AWS_ACCOUNT_ID}"
echo "Region      : ${AWS_REGION}"
echo "Image URI   : ${IMAGE_URI}"
echo "REST API ID : ${REST_API_ID}"
echo "Stage       : ${STAGE_NAME}"

3. 既存REST API IDの確認

既存の REST API IDは以下で確認できます。

aws apigateway get-rest-apis \
  --region "${AWS_REGION}" \
  --query 'items[].{id:id,name:name,endpoint:endpointConfiguration.types}' \
  --output table

AWSリソースの作成

IAMロールとECRリポジトリを作成します。Trust PolicyはLambdaが AssumeRoleするために必要な最小構成です。

4. Lambda実行ロール用Trust Policyファイルの作成

cat > /tmp/lambda-trust-policy.json << 'EOF'
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "Service": "lambda.amazonaws.com" },
      "Action": "sts:AssumeRole"
    }
  ]
}
EOF

5. IAMロールの作成

aws iam create-role \
  --role-name "${LAMBDA_ROLE_NAME}" \
  --assume-role-policy-document file:///tmp/lambda-trust-policy.json \
  --region "${AWS_REGION}"

6. CloudWatch Logs書き込み権限のアタッチ

aws iam attach-role-policy \
  --role-name "${LAMBDA_ROLE_NAME}" \
  --policy-arn arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole

7. IAM ロールARNの取得と変数への保存

export LAMBDA_ROLE_ARN=$(aws iam get-role \
  --role-name "${LAMBDA_ROLE_NAME}" \
  --query Role.Arn \
  --output text)

echo "Role ARN: ${LAMBDA_ROLE_ARN}"

8. ECR リポジトリの作成

scanOnPush=true にしておくと、プッシュのたびに脆弱性スキャンが走って安心です。

aws ecr create-repository \
  --repository-name "${ECR_REPO_NAME}" \
  --region "${AWS_REGION}" \
  --image-scanning-configuration scanOnPush=true

Dockerfileの作成

Lambda関数でVOICEVOXを動かし、LWAを実行するためのDockerfileを作ります。このDockerfileで、Lambda固有の課題に対処していきます。

まずは、先ほど示したLWAを実行するための行を書きます。

次に、Lambdaのコンテナ実行環境では、ホームディレクトリの/home/sbx_user1051が読み取り専用です。VOICEVOX ENGINEはデフォルトで設定やキャッシュをホームディレクトリ以下に書き込もうとするため、そのまま起動するとパーミッションエラーが発生します。そこで、HOMEとXDG_*系の環境変数で/tmp以下を指定することで回避します。Lambda環境で書き込めるパスは/tmpだけです。

また、VOICEVOXの公式コンテナのデフォルトENTRYPOINTはgosu userを呼びますが、Lambdaの実行環境では/etc/passwdに該当ユーザのエントリを持っていないため失敗します。これを回避するための行を追加します。

9. プロジェクトディレクトリの作成と移動

mkdir -p ~/voicevox-lambda && cd ~/voicevox-lambda

10.Dockerfile の作成

VOICEVOXのバージョンは記事執筆時点のものですので、お読みになる時点の最新バージョンに置き換えてください。

cat > Dockerfile << 'DOCKEREOF'
# syntax=docker/dockerfile:1.4

# 公式 VOICEVOX ENGINE（ARM64 + CPU + Ubuntu 22.04, バージョン固定）
FROM voicevox/voicevox_engine:cpu-ubuntu22.04-0.25.1

# Lambda Web Adapterを追加
COPY --from=public.ecr.aws/awsguru/aws-lambda-adapter:1.0.0 \
    /lambda-adapter /opt/extensions/lambda-adapter

# Lambda では /home/sbx_user1051 が読み取り専用のため
# VOICEVOX ENGINE の書き込みをすべて /tmp 以下に向ける
ENV HOME=/tmp
ENV XDG_DATA_HOME=/tmp/xdg_data
ENV XDG_CACHE_HOME=/tmp/xdg_cache
ENV XDG_CONFIG_HOME=/tmp/xdg_config

# Lambda Web Adapter の設定
ENV AWS_LWA_PORT=50021
ENV AWS_LWA_INVOKE_MODE=response_stream
ENV AWS_LWA_READINESS_CHECK_PATH=/version
ENV AWS_LWA_READINESS_CHECK_PORT=50021
ENV AWS_LWA_ASYNC_INIT=true

# gosu user の失敗を回避する
CMD ["/opt/voicevox_engine/run", "--host", "0.0.0.0"]
DOCKEREOF

コンテナイメージのビルドとECRへのプッシュ

docker buildx buildを実行すると、初回はVOICEVOX公式コンテナのpullが発生するため、回線速度次第ですが、作業時間として10分〜30分を見込んでおきます。

11. ECRへのDocker認証

aws ecr get-login-password --region "${AWS_REGION}" \
  | docker login --username AWS --password-stdin \
    "${AWS_ACCOUNT_ID}.dkr.ecr.${AWS_REGION}.amazonaws.com"

12. ARM64対応Buildxビルダーの作成

docker buildx create \
  --name voicevox-arm64-builder \
  --platform linux/arm64 \
  --use

13. イメージのビルドとECRへの直接プッシュ

初回は10分〜30分かかります。

docker buildx build \
  --platform linux/arm64 \
  --tag "${IMAGE_URI}" \
  --push \
  --provenance=false \
  --sbom=false \
  .

14.プッシュ済みイメージの形式確認

imageManifestMediaTypeが application/vnd.docker.distribution.manifest.v2+jsonであることを確認してから次に進みます。

aws ecr describe-images \
  --repository-name "${ECR_REPO_NAME}" \
  --region "${AWS_REGION}" \
  --query 'imageDetails[0].{mediaType:imageManifestMediaType,size:imageSizeInBytes,pushed:imagePushedAt}' \
  --output table

# 期待: application/vnd.docker.distribution.manifest.v2+json

Lambda関数の作成と設定

メモリは3008MBで、タイムアウトは120秒に設定していますが、長い文章を読ませたい場合は伸ばしましょう。

15. Lambda 関数の作成

aws lambda create-function \
  --function-name "${LAMBDA_FUNC_NAME}" \
  --package-type Image \
  --code "ImageUri=${IMAGE_URI}" \
  --role "${LAMBDA_ROLE_ARN}" \
  --architectures arm64 \
  --memory-size 3008 \
  --timeout 120 \
  --region "${AWS_REGION}"

16. デプロイ完了を待機

以下のコマンドの実行が終われば、デプロイが完了しています。

aws lambda wait function-active \
  --function-name "${LAMBDA_FUNC_NAME}" \
  --region "${AWS_REGION}"

17. Lambdaの設定確認

aws lambda get-function-configuration \
  --function-name "${LAMBDA_FUNC_NAME}" \
  --region "${AWS_REGION}" \
  --query '{memory:MemorySize,timeout:Timeout,arch:Architectures,state:State}' \
  --output table

18. ARNの取得と変数への保存

ARNを変数に保存して、以降の手順で使用できるようにします。

export LAMBDA_ARN=$(aws lambda get-function-configuration \
  --function-name "${LAMBDA_FUNC_NAME}" \
  --query FunctionArn \
  --output text \
  --region "${AWS_REGION}")

echo "Lambda ARN: ${LAMBDA_ARN}"

API Gatewayへの統合

/response-streaming-invocationsを使うことで、API Gatewayはresponse_streamモードのLWAに接続します。

今回API Gatewayに登録するパスは/version、/speakers、/audio_query、/synthesisの4つです。VOICEVOX ENGINEが持つエンドポイントはもっとたくさんありますが、テキストを渡して.wavを受け取るという最小限のユースケースに絞って4つにしました。

19. ルートとなるリソースIDの取得

export ROOT_RESOURCE_ID=$(aws apigateway get-resources \
  --rest-api-id "${REST_API_ID}" \
  --region "${AWS_REGION}" \
  --query 'items[?path==`/`].id' \
  --output text)

echo "Root resource ID: ${ROOT_RESOURCE_ID}"

20. Streaming URIの構築

Lambda関数のARNを使ってストリーミング用のURIを作ります。

export STREAMING_URI="arn:aws:apigateway:${AWS_REGION}:lambda:path/2021-11-15/functions/${LAMBDA_ARN}/response-streaming-invocations"

echo "Streaming URI: ${STREAMING_URI}"

21. /versionリソースの追加（GET、ストリーミング）

/versionは単純にエンジンのバージョン文字列を返すエンドポイントです。今回はDockerfileでAWS_LWA_READINESS_CHECK_PATH=/versionと設定しているため、LWAがVOICEVOX ENGINEの起動を確認するヘルスチェックのターゲットにもなっています。

export VER_RESOURCE_ID=$(aws apigateway create-resource \
  --rest-api-id "${REST_API_ID}" \
  --parent-id "${ROOT_RESOURCE_ID}" \
  --path-part "version" \
  --region "${AWS_REGION}" \
  --query id --output text)

echo "version resource ID: ${VER_RESOURCE_ID}"

aws apigateway put-method \
  --rest-api-id "${REST_API_ID}" \
  --resource-id "${VER_RESOURCE_ID}" \
  --http-method GET \
  --authorization-type NONE \
  --region "${AWS_REGION}"

aws apigateway put-integration \
  --rest-api-id "${REST_API_ID}" \
  --resource-id "${VER_RESOURCE_ID}" \
  --http-method GET \
  --type AWS_PROXY \
  --integration-http-method POST \
  --uri "${STREAMING_URI}" \
  --timeout-in-millis 29000 \
  --response-transfer-mode STREAM \
  --region "${AWS_REGION}"

22. /speakers リソースの追加（GET、ストリーミング）

/speakersは利用可能な話者の一覧を返します。ずんだもんはspeaker=3です。

export SPK_RESOURCE_ID=$(aws apigateway create-resource \
  --rest-api-id "${REST_API_ID}" \
  --parent-id "${ROOT_RESOURCE_ID}" \
  --path-part "speakers" \
  --region "${AWS_REGION}" \
  --query id --output text)

echo "speakers resource ID: ${SPK_RESOURCE_ID}"

aws apigateway put-method \
  --rest-api-id "${REST_API_ID}" \
  --resource-id "${SPK_RESOURCE_ID}" \
  --http-method GET \
  --authorization-type NONE \
  --region "${AWS_REGION}"

aws apigateway put-integration \
  --rest-api-id "${REST_API_ID}" \
  --resource-id "${SPK_RESOURCE_ID}" \
  --http-method GET \
  --type AWS_PROXY \
  --integration-http-method POST \
  --uri "${STREAMING_URI}" \
  --timeout-in-millis 60000 \
  --response-transfer-mode STREAM \
  --region "${AWS_REGION}"

23. /audio_query リソースの追加（POST、ストリーミング）

/audio_queryは、テキストを渡し、AudioQuery（速さ・ピッチ・イントネーションなどのパラメータを持つ JSON）を生成するために使用します。

export AQ_RESOURCE_ID=$(aws apigateway create-resource \
  --rest-api-id "${REST_API_ID}" \
  --parent-id "${ROOT_RESOURCE_ID}" \
  --path-part "audio_query" \
  --region "${AWS_REGION}" \
  --query id --output text)

echo "audio_query resource ID: ${AQ_RESOURCE_ID}"

aws apigateway put-method \
  --rest-api-id "${REST_API_ID}" \
  --resource-id "${AQ_RESOURCE_ID}" \
  --http-method POST \
  --authorization-type NONE \
  --region "${AWS_REGION}"

aws apigateway put-integration \
  --rest-api-id "${REST_API_ID}" \
  --resource-id "${AQ_RESOURCE_ID}" \
  --http-method POST \
  --type AWS_PROXY \
  --integration-http-method POST \
  --uri "${STREAMING_URI}" \
  --timeout-in-millis 60000 \
  --response-transfer-mode STREAM \
  --region "${AWS_REGION}"

24. /synthesis リソースの追加（POST、ストリーミング）

/synthesisは、AudioQueryをして.wavを得るために使用します。

export SYN_RESOURCE_ID=$(aws apigateway create-resource \
  --rest-api-id "${REST_API_ID}" \
  --parent-id "${ROOT_RESOURCE_ID}" \
  --path-part "synthesis" \
  --region "${AWS_REGION}" \
  --query id --output text)

echo "synthesis resource ID: ${SYN_RESOURCE_ID}"

aws apigateway put-method \
  --rest-api-id "${REST_API_ID}" \
  --resource-id "${SYN_RESOURCE_ID}" \
  --http-method POST \
  --authorization-type NONE \
  --region "${AWS_REGION}"

aws apigateway put-integration \
  --rest-api-id "${REST_API_ID}" \
  --resource-id "${SYN_RESOURCE_ID}" \
  --http-method POST \
  --type AWS_PROXY \
  --integration-http-method POST \
  --uri "${STREAMING_URI}" \
  --timeout-in-millis 60000 \
  --response-transfer-mode STREAM \
  --region "${AWS_REGION}"

25. LambdaへのAPI Gateway実行権限の付与（4リソース分）

4つのリソースに対して権限を付与していきます。

# GET /version 用
aws lambda add-permission \
  --function-name "${LAMBDA_FUNC_NAME}" \
  --action lambda:InvokeFunction \
  --statement-id AllowAPIGatewayVersion \
  --principal apigateway.amazonaws.com \
  --source-arn "arn:aws:execute-api:${AWS_REGION}:${AWS_ACCOUNT_ID}:${REST_API_ID}/*/GET/version" \
  --region "${AWS_REGION}"

# GET /speakers 用
aws lambda add-permission \
  --function-name "${LAMBDA_FUNC_NAME}" \
  --action lambda:InvokeFunction \
  --statement-id AllowAPIGatewaySpeakers \
  --principal apigateway.amazonaws.com \
  --source-arn "arn:aws:execute-api:${AWS_REGION}:${AWS_ACCOUNT_ID}:${REST_API_ID}/*/GET/speakers" \
  --region "${AWS_REGION}"

# POST /audio_query 用
aws lambda add-permission \
  --function-name "${LAMBDA_FUNC_NAME}" \
  --action lambda:InvokeFunction \
  --statement-id AllowAPIGatewayAudioQuery \
  --principal apigateway.amazonaws.com \
  --source-arn "arn:aws:execute-api:${AWS_REGION}:${AWS_ACCOUNT_ID}:${REST_API_ID}/*/POST/audio_query" \
  --region "${AWS_REGION}"

# POST /synthesis 用
aws lambda add-permission \
  --function-name "${LAMBDA_FUNC_NAME}" \
  --action lambda:InvokeFunction \
  --statement-id AllowAPIGatewaySynthesis \
  --principal apigateway.amazonaws.com \
  --source-arn "arn:aws:execute-api:${AWS_REGION}:${AWS_ACCOUNT_ID}:${REST_API_ID}/*/POST/synthesis" \
  --region "${AWS_REGION}"

26. ステージへのデプロイ

最後は、API Gatewayにステージをデプロイします。

aws apigateway create-deployment \
  --rest-api-id "${REST_API_ID}" \
  --stage-name "${STAGE_NAME}" \
  --region "${AWS_REGION}"

27. エンドポイントURLを変数に保存

API GatewayのエンドポイントのURLは以下の形式となりますので、変数に保存しておきます。

export API_BASE_URL="https://${REST_API_ID}.execute-api.${AWS_REGION}.amazonaws.com/${STAGE_NAME}"

echo "API Base URL: ${API_BASE_URL}"

動作確認

デプロイが完了したので、動作を確認します。

28. バージョン確認（エンジン起動と疎通確認）

記事執筆時点のバージョンで、公式コンテナはイメージサイズが約1.79GBあり、Init Durationが100〜200秒に及ぶのではないかと考えられました。LWAが /versionの応答を確認してからLambdaがリクエストを受け付ける仕組みのため、--max-time 250で余裕を持たせています。

curl -s --max-time 250 "${API_BASE_URL}/version"

# 期待: "0.25.1"

29. 利用可能なスピーカーの確認

curl -s --max-time 30 "${API_BASE_URL}/speakers" \
  | python3 -c \
    "import json,sys; [print(s['speaker_uuid'][:8], s['name'], [st['id'] for st in s['styles']]) for s in json.load(sys.stdin)]"

30. AudioQueryの取得

ENCODED_TEXT=$(python3 -c \
  'import urllib.parse; print(urllib.parse.quote("こんにちは、ずんだもんなのだ"))')

curl -s --max-time 30 -X POST \
  "${API_BASE_URL}/audio_query?text=${ENCODED_TEXT}&speaker=3" \
  -o audio_query.json

# 取得できているか確認
head -c 200 audio_query.json && echo

31. 音声合成と.wavファイルへの保存

curl -s --max-time 60 -X POST \
  "${API_BASE_URL}/synthesis?speaker=3" \
  -H "Content-Type: application/json" \
  -d @audio_query.json \
  --output output.wav

32. 音声を再生

ずんだもんの声が聞こえたら成功です。

# macOSでの再生確認
afplay output.wav

# Linuxでの再生確認
aplay output.wav

以下の動画は、ずんだもんにしゃべってもらった時の様子です。

AWS Lambda Web Adapterを使って、VOICEVOX:ずんだもんをLambda上に召喚することに成功しました。これにより、ずんだもんMCP Serverも実現できます。夢が広がってきましたね。 https://t.co/KV5zEqm2K9 pic.twitter.com/cn6xJBXTIu

— nasuuu (@nasuvit_z) April 14, 2026

まとめ

従量課金のサーバレスずんだもんは、リクエストが来た時だけ起動し、音声を返します。アクセスのない深夜は一切課金されず、月々の維持費はほぼゼロに近くなります。サーバサイドで起動する場合、従来はコンテナを常時起動する必要があると考えられ、コストに不安がありましたが、今回の構成は十分に現実的な選択肢です。

この構成の立役者がLambda Web Adapterでした。LWAを使えば、Lambdaのためにコードを書き直す必要がありません。とても簡単に、ずんだもんとサーバレスの世界でおしゃべりすることができるようになります。

Lambdaで動くようになったことで、AIエージェントとも簡単に統合できるようになります。LLMが返したテキストをずんだもんの声で読み上げるだけです。MCPとしてエンドポイントを呼び出せば実現できます。AIエージェントの要求は散発的であることが多いため、呼ばれた分だけ課金されるこの構成との相性は、悪くないどころかむしろ理想的です。

このように、サーバレスずんだもんは、呼ばれた時しか起動しません。完成した時は、良い仕組みができたものだと思いました。しかし、この記事を書き終えようとしている今、「呼ばれた時だけ起動するずんだもん」という表現を読み返すと、何か心に引っ掛かるものがあります。キャラクターには大事にしたいイメージがあります。単に技術的に説明して終わると「寂しいのだ。もっと呼び出してほしいのだ。」と言われそうな気がしたのです。開発中、特にテスト中には、ずんだもんの声で癒され、QOLが上がっていた気がします。この仕組みを応用させて、もっと色んな場面でおしゃべりできるようにしていかなければならないと思えたのです。このような感覚は大事にしたいものです。

この記事は「サーバレスになったずんだもんは、より幅広い場面で、みんなとおしゃべりできるようになるのだ」とまとめることにしたいと思います。その場面は、きっとAIエージェントによって拡散的に広がっていくでしょう。この記事で、そのきっかけを与えることができたでしょうか。

参考文献