はじめに # これは、「面白そう」と感じたアーキテクチャや技術スタックを、まずはあれこれ試しながら作ってみたプロトタイピングの記録です。 前回は、AWS LambdaとSSMセッションマネージャーによるサーバーレスGPU起動ブローカーを構築しました。 （詳細は 前回の記事 を参照してください） これにより、ポート開放ゼロかつSSH秘密鍵不要で、世界中の最安スポットGPUをわずか数秒で探索・選定し、安全に直結できる環境が完成しました。 しかし、前回の構成を実践していく中で、もう1つ避けて通れない重要な課題が浮き彫りになります。 「マルチリージョン展開に必要なS3・ECR・セキュリティグループ・IAMロール・起動構成・Lambda関数を、手動や場当たり的なシェルスクリプトで管理し続けるのは辛い」 今回の構成では、東京（ap-northeast-1）に加えて海外4リージョン（バージニア、オハイオ、オレゴン、フランクフルト）の計5リージョンを調達先として扱います。これらのリージョンに手動で設定を入れると、設定漏れやタイプミスの温床になります。使わなくなった際の環境破棄や、別アカウントへの再現も極めて困難になります。 複数リージョンに分散配置するGPU実行基盤を、不要になったら丸ごと消せるエフェメラルなIaCとしてTerraformで組めば、管理や片付けが大幅に楽になります。 そこで今回は、 静的インフラ基盤のすべてをTerraformで一括コード化（IaC化） することにしました。 --> Information 📚 関連する過去の検証記事 第1回 : AWS×UserDataでvLLMを自動起動！停止時コストほぼゼロのローカルLLM環境 第2回 : 自前vLLMをOpen WebUI経由でVS Code（Cline）に接続！トークンフリーで開発する 第3回 : EC2スポットインスタンス×vLLMでGPUコストを大幅削減する 第4回 : EC2スポット×vLLMをSSMでセキュア化！ポート開放ゼロで繋ぐ 第5回 : vLLM起動をAWS Lambda化！最安スポット探索と自動フォールバック 1. Terraform化における「役割分担（スコープ設計）」 # 📌 このセクションの要点 「常に存在する静的基盤」と「作業時だけ使い捨てるGPU」を明確に分離します。動的なGPU起動・停止までTerraformで管理しようとせず、ブローカー基盤までをTerraformで作り、GPUのオンデマンド調達はLambdaに任せる設計がベストプラクティスです。 本検証では、「常に存在するインフラ」と「作業時だけ使い捨てるGPU」を明確に分離しています。そのため、Terraformの管理範囲を以下のように切り分けるのがベストプラクティスです。 カテゴリ リソース 管理ツール ライフサイクル・費用感 静的基盤 S3, ECR（+レプリケーション）, IAM, 各リージョンSG, Launch Template, Lambda Terraform 常時存在（使わない時の待機費用はS3・ECRの数GB保管料数十円のみ） 動的エフェメラル 最適リージョンのリアルタイム探索, EC2スポット起動/破棄, SSMトンネル Lambda + CLI オンデマンド実行（作業中のみ $0.4〜0.6/h 課金） 「EC2スポットの起動・破棄」までをTerraformで管理しようとすると、動的なリージョン選定が難しくなります。また、状態ファイル（ tfstate ）のロックや同期で毎回1分以上のオーバーヘッドが発生します。 そのため、 「ブローカー基盤までをTerraformで作り、GPUの生成・破棄はブローカー（Lambda）に任せる」 という設計が最も軽快で堅牢です。 2. コンテナイメージのマルチリージョン配置（ECRクロスリージョンレプリケーション） # 第1回〜第5回で採用している通り、vLLMのコンテナイメージ（約13GB）は Amazon ECR に永続化し、EC2の起動時に同一リージョン内から高速・転送料無料でPullします。 調達候補となる各リージョン（バージニア、オレゴン、オハイオ、フランクフルトなど）においても、同様に 同一リージョン内のECRからイメージを取得できる状態 を整えておく必要があります。仮に東京のECRから他リージョンのEC2へ都度Pullしてしまうと、リージョン間データ転送料金が毎回発生するうえ、コンテナ起動時間も大幅に増大してしまうためです。 とはいえ、イメージを更新するたびに各リージョンのECRエンドポイントへ手動で docker push を繰り返すのは運用負荷が高く、非効率です。 そこで、Amazon ECRがネイティブで備えている クロスリージョンレプリケーション（Cross-Region Replication） を採用します。Terraformでこの設定（ aws_ecr_replication_configuration ）を宣言しておきます。これにより、東京のECRに1回Pushするだけで、AWSバックボーン経由で全候補リージョンへ自動複製されます。 以下は、東京リージョンでのECRリポジトリ作成、旧世代イメージの自動削除ポリシー、および他4リージョンへの自動レプリケーションを定義したTerraformコードです。 ecr.tf（クリックで展開） # terraform/ecr.tf # 東京（プライマリ）リージョンの ECR リポジトリ resource "aws_ecr_repository" "vllm" { name = var.ecr_repository_name image_tag_mutability = "MUTABLE" tags = { Project = "vllm-ephemeral" } } # 古いタグの自動削除ポリシー（無駄なストレージ課金を防止） resource "aws_ecr_lifecycle_policy" "vllm_lifecycle" { repository = aws_ecr_repository.vllm.name policy = jsonencode({ rules = [{ rulePriority = 1 description = "最新イメージのみ保持し、旧世代は30日で失効" selection = { tagStatus = "any", countType = "sinceImagePushed", countUnit = "days", countNumber = 30 } action = { type = "expire" } }] }) } # ★マルチリージョン・クロスリージョン自動レプリケーション resource "aws_ecr_replication_configuration" "vllm_replication" { replication_configuration { rule { dynamic "destination" { for_each = [for r in var.target_regions : r if r != var.primary_region] content { region = destination.value registry_id = data.aws_caller_identity.current.account_id } } } } } --> Information 💡 S3のモデル重み同期について（マルチリージョン配置の検討） コンテナイメージと同様に、S3に格納するモデル重み（約15GB）についても候補リージョンへの分散配置が考えられます。 S3クロスリージョンレプリケーション（CRR）を利用する場合 : 全リージョンに重みを事前同期しておくことで、起動時のダウンロード時間を最短化し、同一リージョン内通信（無料）に抑制可能。一方で、複数リージョンにモデルを保持し続けるとS3保管料がリージョン数分発生するため、旧バケットの定期削除やGlacierへの退避など、ストレージ管理の併用が有効。 東京S3から都度クロスリージョン取得する場合 : モデル保管料は東京の1バケット分で済む一方、海外リージョン起動時にクロスリージョン転送料（1回約220円）とネットワーク遅延が発生。 本システムでは、頻繁に利用する主要リージョンにはS3バケットを準備し、必要に応じて初期同期しておく構成を推奨しています。 3. ゼロインバウンドSG ＆ 最小権限IAM # 第4回で解説した「インバウンドルール0件のセキュリティグループ」と、EC2およびLambdaに必要なIAMロールを一括で定義します。 セキュリティグループ（全リージョンへの一括プロビジョニング） # Terraformのマルチプロバイダ機能（ providers = { aws = ... } ）やモジュールループを活用します。これにより、全リージョンへインバウンド0件のセキュリティグループを展開できます。 security_groups.tf（クリックで展開） # 各リージョン向けのセキュリティグループ（インバウンドルールなし、アウトバウンド全開放） resource "aws_security_group" "vllm_sg" { name = "vllm-ssm-isolated-sg" description = "Zero-inbound security group for vLLM SSM port forwarding" vpc_id = data.aws_vpc.default.id # インバウンドルールは定義しない（完全閉塞） egress { description = "Allow all outbound traffic for SSM Agent and S3/ECR pull" from_port = 0 to_port = 0 protocol = "-1" cidr_blocks = ["0.0.0.0/0"] } tags = { Name = "vllm-ssm-isolated-sg" } } IAMロール（EC2用 ＆ Lambda用） # EC2インスタンスにはSSM通信・S3読み取り・ECR読み取りに必要な最小権限を付与し、Lambda関数にはマルチリージョンのEC2探索・起動に必要な権限を付与します。 iam.tf（クリックで展開） # EC2インスタンス用 IAMロール resource "aws_iam_role" "ec2_role" { name = "vllm-ssm-instance-role" assume_role_policy = jsonencode({ Version = "2012-10-17" Statement = [{ Action = "sts:AssumeRole" Effect = "Allow" Principal = { Service = "ec2.amazonaws.com" } }] }) } # SSMエージェント通信用ポリシー resource "aws_iam_role_policy_attachment" "ssm_core" { role = aws_iam_role.ec2_role.name policy_arn = "arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore" } # S3 & ECR 読み取りポリシー resource "aws_iam_role_policy_attachment" "s3_read" { role = aws_iam_role.ec2_role.name policy_arn = "arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess" } resource "aws_iam_role_policy_attachment" "ecr_read" { role = aws_iam_role.ec2_role.name policy_arn = "arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryReadOnly" } # EC2インスタンスプロファイル resource "aws_iam_instance_profile" "ec2_profile" { name = "vllm-ssm-instance-profile" role = aws_iam_role.ec2_role.name } # Lambda GPUブローカー用 IAMロール resource "aws_iam_role" "lambda_role" { name = "vllm-spot-broker-lambda-role" assume_role_policy = jsonencode({ Version = "2012-10-17" Statement = [{ Action = "sts:AssumeRole" Effect = "Allow" Principal = { Service = "lambda.amazonaws.com" } }] }) } resource "aws_iam_role_policy_attachment" "lambda_basic" { role = aws_iam_role.lambda_role.name policy_arn = "arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole" } # マルチリージョンでのスポット探索・EC2起動権限 resource "aws_iam_role_policy" "lambda_ec2_broker" { name = "VLLMBrokerEC2Policy" role = aws_iam_role.lambda_role.id policy = jsonencode({ Version = "2012-10-17" Statement = [ { Effect = "Allow" Action = [ "ec2:DescribeSpotPriceHistory", "ec2:DescribeSecurityGroups", "ec2:DescribeImages", "ec2:RunInstances", "ec2:CreateTags", "ssm:GetParameter", "iam:PassRole" ] Resource = "*" } ] }) } --> Information 💡 第4回・第5回のスクリプト環境から移行する場合の注意点 第4回や第5回の環境構築スクリプトを実行済みのAWS環境でTerraformを実行する場合に注意が必要です。同名のリソースが存在すると競合エラー（ EntityAlreadyExistsException 等）が発生します。その場合は terraform import で取り込むか、既存リソースを削除（または名前を変更）してから terraform apply を実行してください。 4. EC2起動テンプレート（Launch Template）とUserDataのテンプレート化 # 📌 このセクションの要点 第5回でS3へ切り離したUserData（ startup.sh ）をさらに一歩進めます。インスタンスタイプやEBS、IAMプロファイル、閉塞SG、UserDataブートストラップを EC2起動テンプレート（Launch Template） として一元管理します。これにより、Lambdaブローカーからハードウェア依存の記述を完全に切り離せます。 第5回では、110行を超えるUserDataスクリプトをS3バケットへ配置しました。EC2側にはS3から取得して実行する3行のブートストラップスクリプトを渡す構成としました。これにより、Lambdaコードの肥大化とUserDataの16KB上限問題を回避しました。 しかし、もう1つの課題が残っていました。 インスタンス仕様がLambdaコード内にハードコードされている ： インスタンスタイプ（ g6.xlarge ）、EBSボリューム（40GB gp3、削除保護オフ）、IAMインスタンスプロファイル、セキュリティグループ、スポット市場オプションなどのハードウェア構成が、依然としてLambdaのPythonコード内の辞書として記述されていました。 インスタンスのハードウェア構成やブートストラップ手順は、本来「静的なインフラ仕様」としてIaCで管理すべき領域です。 そこで本構成では、 aws_launch_template （EC2起動テンプレート） を導入します。これにより、ハードウェア定義とUserDataブートストラップを一括コード化します。 1. UserDataブートストラップのテンプレート（ userdata_bootstrap.sh ） # Terraformの templatefile 関数で動的パラメータ（リージョン、S3バケット名、ECRイメージ名）を注入できる極小シェルスクリプトを用意します。なお、Bash変数（ $LOG_FILE 等）は波括弧を付けずに記述することで、Terraformテンプレート展開時の変数名衝突を綺麗に回避しています。 templates/userdata_bootstrap.sh（クリックで展開） #!/bin/bash set -euo pipefail LOG_FILE="/var/log/userdata-bootstrap.log" exec > >(tee -a "$LOG_FILE" | logger -t user-data -s 2>/dev/console) 2>&1 AWS_REGION="${AWS_REGION}" S3_BUCKET="${S3_BUCKET_NAME}" DOCKER_IMAGE="${DOCKER_IMAGE}" echo "=== S3から起動スクリプト (startup.sh) を取得 ===" aws s3 cp "s3://$S3_BUCKET/scripts/startup.sh" /tmp/startup.sh --region "$AWS_REGION" chmod +x /tmp/startup.sh echo "=== startup.sh 実行 ===" /tmp/startup.sh "$AWS_REGION" "$S3_BUCKET" "$DOCKER_IMAGE" 2. 全リージョンへの起動テンプレート一括プロビジョニング（ launch_template.tf ） # EC2 Launch Templateは リージョン固有 のリソースです。東京だけに配置すると、海外リージョンでの起動時にテンプレートが見つかりません。そのため、Terraformを使って全候補リージョンへ同一名（ vllm-spot-template ）で一括展開します。 これにより、Lambdaブローカーがリアルタイム探索でどのリージョンを引き当てた場合でも、フォールバックなしに起動テンプレートから直接インスタンスを生成できます。 launch_template.tf（クリックで展開） # terraform/launch_template.tf # ============================================================================== # EC2 起動テンプレート（Launch Template）全候補リージョン一括プロビジョニング # EBS(40GB gp3)、IAMプロファイル、セキュリティグループ、UserData(S3ブートストラップ) # を全リージョンで共通のテンプレート名「vllm-spot-template」としてコード化する # ============================================================================== # 1. 東京リージョン (ap-northeast-1) resource "aws_launch_template" "lt_ap_northeast_1" { name = "vllm-spot-template" description = "vLLM Ephemeral Spot Node (g6.xlarge, NVIDIA L4 24GB) [ap-northeast-1]" instance_type = var.instance_type iam_instance_profile { name = aws_iam_instance_profile.ec2_profile.name } vpc_security_group_ids = [ aws_security_group.sg_ap_northeast_1.id ] block_device_mappings { device_name = "/dev/sda1" ebs { volume_size = 40 volume_type = "gp3" delete_on_termination = true } } instance_market_options { market_type = "spot" spot_options { spot_instance_type = "one-time" instance_interruption_behavior = "terminate" } } user_data = base64encode(templatefile("${path.module}/templates/userdata_bootstrap.sh", { AWS_REGION = "ap-northeast-1" S3_BUCKET_NAME = "my-vllm-models-hackathon-2026-${data.aws_caller_identity.current.account_id}-ap-northeast-1-an" DOCKER_IMAGE = "${data.aws_caller_identity.current.account_id}.dkr.ecr.ap-northeast-1.amazonaws.com/${var.ecr_repository_name}:latest" })) tag_specifications { resource_type = "instance" tags = { Name = "vllm-ssm-spot-node" Project = "vllm-ephemeral" MarketType = "spot" } } } # 2. バージニア北部リージョン (us-east-1) resource "aws_launch_template" "lt_us_east_1" { provider = aws.us_east_1 name = "vllm-spot-template" description = "vLLM Ephemeral Spot Node (g6.xlarge, NVIDIA L4 24GB) [us-east-1]" instance_type = var.instance_type iam_instance_profile { name = aws_iam_instance_profile.ec2_profile.name } vpc_security_group_ids = [ aws_security_group.sg_us_east_1.id ] block_device_mappings { device_name = "/dev/sda1" ebs { volume_size = 40 volume_type = "gp3" delete_on_termination = true } } instance_market_options { market_type = "spot" spot_options { spot_instance_type = "one-time" instance_interruption_behavior = "terminate" } } user_data = base64encode(templatefile("${path.module}/templates/userdata_bootstrap.sh", { AWS_REGION = "us-east-1" S3_BUCKET_NAME = "my-vllm-models-hackathon-2026-${data.aws_caller_identity.current.account_id}-us-east-1-an" DOCKER_IMAGE = "${data.aws_caller_identity.current.account_id}.dkr.ecr.us-east-1.amazonaws.com/${var.ecr_repository_name}:latest" })) tag_specifications { resource_type = "instance" tags = { Name = "vllm-ssm-spot-node" Project = "vllm-ephemeral" MarketType = "spot" } } } # 3. オハイオリージョン (us-east-2) resource "aws_launch_template" "lt_us_east_2" { provider = aws.us_east_2 name = "vllm-spot-template" description = "vLLM Ephemeral Spot Node (g6.xlarge, NVIDIA L4 24GB) [us-east-2]" instance_type = var.instance_type iam_instance_profile { name = aws_iam_instance_profile.ec2_profile.name } vpc_security_group_ids = [ aws_security_group.sg_us_east_2.id ] block_device_mappings { device_name = "/dev/sda1" ebs { volume_size = 40 volume_type = "gp3" delete_on_termination = true } } instance_market_options { market_type = "spot" spot_options { spot_instance_type = "one-time" instance_interruption_behavior = "terminate" } } user_data = base64encode(templatefile("${path.module}/templates/userdata_bootstrap.sh", { AWS_REGION = "us-east-2" S3_BUCKET_NAME = "my-vllm-models-hackathon-2026-${data.aws_caller_identity.current.account_id}-us-east-2-an" DOCKER_IMAGE = "${data.aws_caller_identity.current.account_id}.dkr.ecr.us-east-2.amazonaws.com/${var.ecr_repository_name}:latest" })) tag_specifications { resource_type = "instance" tags = { Name = "vllm-ssm-spot-node" Project = "vllm-ephemeral" MarketType = "spot" } } } # 4. オレゴンリージョン (us-west-2) resource "aws_launch_template" "lt_us_west_2" { provider = aws.us_west_2 name = "vllm-spot-template" description = "vLLM Ephemeral Spot Node (g6.xlarge, NVIDIA L4 24GB) [us-west-2]" instance_type = var.instance_type iam_instance_profile { name = aws_iam_instance_profile.ec2_profile.name } vpc_security_group_ids = [ aws_security_group.sg_us_west_2.id ] block_device_mappings { device_name = "/dev/sda1" ebs { volume_size = 40 volume_type = "gp3" delete_on_termination = true } } instance_market_options { market_type = "spot" spot_options { spot_instance_type = "one-time" instance_interruption_behavior = "terminate" } } user_data = base64encode(templatefile("${path.module}/templates/userdata_bootstrap.sh", { AWS_REGION = "us-west-2" S3_BUCKET_NAME = "my-vllm-models-hackathon-2026-${data.aws_caller_identity.current.account_id}-us-west-2-an" DOCKER_IMAGE = "${data.aws_caller_identity.current.account_id}.dkr.ecr.us-west-2.amazonaws.com/${var.ecr_repository_name}:latest" })) tag_specifications { resource_type = "instance" tags = { Name = "vllm-ssm-spot-node" Project = "vllm-ephemeral" MarketType = "spot" } } } # 5. フランクフルトリージョン (eu-central-1) resource "aws_launch_template" "lt_eu_central_1" { provider = aws.eu_central_1 name = "vllm-spot-template" description = "vLLM Ephemeral Spot Node (g6.xlarge, NVIDIA L4 24GB) [eu-central-1]" instance_type = var.instance_type iam_instance_profile { name = aws_iam_instance_profile.ec2_profile.name } vpc_security_group_ids = [ aws_security_group.sg_eu_central_1.id ] block_device_mappings { device_name = "/dev/sda1" ebs { volume_size = 40 volume_type = "gp3" delete_on_termination = true } } instance_market_options { market_type = "spot" spot_options { spot_instance_type = "one-time" instance_interruption_behavior = "terminate" } } user_data = base64encode(templatefile("${path.module}/templates/userdata_bootstrap.sh", { AWS_REGION = "eu-central-1" S3_BUCKET_NAME = "my-vllm-models-hackathon-2026-${data.aws_caller_identity.current.account_id}-eu-central-1-an" DOCKER_IMAGE = "${data.aws_caller_identity.current.account_id}.dkr.ecr.eu-central-1.amazonaws.com/${var.ecr_repository_name}:latest" })) tag_specifications { resource_type = "instance" tags = { Name = "vllm-ssm-spot-node" Project = "vllm-ephemeral" MarketType = "spot" } } } output "launch_template_ids" { value = { "ap-northeast-1" = aws_launch_template.lt_ap_northeast_1.id "us-east-1" = aws_launch_template.lt_us_east_1.id "us-east-2" = aws_launch_template.lt_us_east_2.id "us-west-2" = aws_launch_template.lt_us_west_2.id "eu-central-1" = aws_launch_template.lt_eu_central_1.id } description = "EC2 Launch Template IDs across all target regions" } output "launch_template_name" { value = "vllm-spot-template" description = "Common EC2 Launch Template Name across all target regions" } 起動テンプレートを全候補リージョンで同名（ vllm-spot-template ）としてTerraformで管理します。これにより、ハードウェア仕様の変更時もコードを修正して terraform apply するだけで、全リージョンへ一括反映されます。 5. Lambda関数の自動パッケージング ＆ デプロイ # 第5回で紹介したGPUブローカーのPythonスクリプト（ handler.py ）をデプロイします。Terraform標準の archive_file データソースを使い、自動でZIP化して展開します。 起動テンプレートの導入に伴い、Lambda関数の環境変数には LAUNCH_TEMPLATE_NAME を渡します。 lambda.tf（クリックで展開） # Pythonコードの自動ZIPパッケージング data "archive_file" "lambda_zip" { type = "zip" source_dir = "${path.module}/../lambda" output_path = "${path.module}/dist/lambda_function.zip" } # GPU起動ブローカー Lambda関数 resource "aws_lambda_function" "broker" { function_name = "vllm-spot-broker" runtime = "python3.12" handler = "handler.lambda_handler" role = aws_iam_role.lambda_role.arn timeout = 120 memory_size = 256 filename = data.archive_file.lambda_zip.output_path source_code_hash = data.archive_file.lambda_zip.output_base64sha256 environment { variables = { TARGET_REGIONS = join(",", var.target_regions) S3_BUCKET_NAME = "my-vllm-models-hackathon-2026-{account_id}-{region}-an" INSTANCE_PROFILE_NAME = aws_iam_instance_profile.ec2_profile.name ECR_REPOSITORY_NAME = aws_ecr_repository.vllm.name TAG_SERVER_NAME = "vllm-ssm-spot-node" SG_NAME = "vllm-ssm-isolated-sg" LAUNCH_TEMPLATE_NAME = aws_launch_template.vllm_spot_template.name } } tags = { Project = "vllm-ephemeral" } } Lambdaハンドラー側での呼び出し（起動処理の簡潔化） # 起動テンプレートが整ったことで、Lambda関数（ handler.py ）のインスタンス起動処理は極めて簡潔になります。 # Launch Template を指定して1行で起動 run_params = { "MinCount": 1, "MaxCount": 1, "LaunchTemplate": { "LaunchTemplateName": os.environ.get("LAUNCH_TEMPLATE_NAME"), "Version": "$Latest", }, } if target_ami: run_params["ImageId"] = target_ami ec2.run_instances(**run_params) 長大な BlockDeviceMappings や UserData などをPython側で構築する必要はありません。Lambdaの責務は「最適リージョンのリアルタイム探索と、テンプレートによるエフェメラル起動」のみに集中できます。 6. Terraformの実行（一括プロビジョニングと環境破棄） # ディレクトリ構成を整えたら、コマンド実行で全リソースをプロビジョニングできます。 cd terraform/ # 1. プロバイダ初期化 terraform init # 2. 静的基盤の全展開（S3・ECR・IAM・SG・Lambda） terraform apply -auto-approve Apply complete! Resources: 18 added, 0 changed, 0 destroyed. Outputs: broker_lambda_arn = "arn:aws:lambda:ap-northeast-1:123456789012:function:vllm-spot-broker" ecr_repository_url = "123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/vllm-openai" これにより、わずか数十秒でマルチリージョン展開に必要な基盤のすべてが整います。 日々のGPU起動・停止 # 静的基盤のデプロイ後は、日々のGPU起動・停止に第5回のスクリプト（ 01_start_vllm_ssm.sh / 02_stop_vllm_ssm.sh ）をそのまま使用します。 # GPUインスタンスの起動（Lambdaブローカー呼び出し & SSMトンネル確立） ./01_start_vllm_ssm.sh # 作業終了時のリソース破棄（SSM切断 & Lambda経由でのTerminate） ./02_stop_vllm_ssm.sh Terraform側でGPUインスタンス自体のライフサイクルは抱え込みません。動的な起動・停止をクライアントスクリプトに任せることで、 tfstate のロック待ちなしに迅速に推論環境を利用できます。 検証作業全体が終了し、クラウド上の静的基盤ごとすべてクリーンアップしたい場合のみ、 terraform destroy を実行します。 cd terraform/ terraform destroy -auto-approve --> 💡 発展：他ワークロードへの応用パターン 今回の検証ではvLLM（GPU推論）を題材としました。しかし、「Lambdaによるスポット探索・起動」と「SSMポートフォワーディング」の組み合わせは、他のワークロードにも幅広く応用可能です。 大規模コンパイル・ビルド環境 : 手元端末の負荷を軽減するため、多数のvCPUを持つコンピュート最適化インスタンス（例: c6i 系列）を必要な時間だけ立ち上げ、ビルド完了後に自動終了させる。 モデルのファインチューニングやバッチ学習 : 学習時のみ複数GPUインスタンスをスポット起動し、S3からデータセットを取得して学習し、生成された重みをS3へ保存した後にインスタンスを破棄する。 メモリ集約型のデータ処理 : ローカル環境ではメモリ不足になりやすい大規模データフレームの集計・分析時のみ、大容量メモリを搭載したインスタンス（例: r6i 系列）を一時的に利用する。 セキュアな一時開発環境（リモートDevbox） : インバウンドポートを開放せずにSSM経由で接続できるため、外部へのポート公開が制限されている環境でも、手元のVS Code等からセキュアに一時的な作業環境として利用できる。 「必要なタイミングだけクラウド上の適切なリソースを立ち上げ、完了後は確実に終了させる」というエフェメラルな運用は、コスト効率とセキュリティを両立させるアプローチとして幅広く活用できます。 まとめ # 本記事では、マルチリージョンにまたがるGPU推論基盤の静的リソースを Terraformで宣言的にコード化（IaC化） しました。 静的基盤と動的エフェメラルの役割分担 : 状態管理のオーバーヘッドを避け、静的基盤のみをTerraformに任せることで、軽快かつ堅牢なアーキテクチャを実現。 EC2起動テンプレート（Launch Template）の導入 : ハードウェア仕様や閉塞SG、UserDataブートストラップを一元的にコード化し、Lambda側からハードウェア依存コードを切り離し。 ECRクロスリージョン自動レプリケーション : 東京へ1回Pushするだけで全候補リージョンへAWSバックボーン経由で自動同期されるパイプラインを構築。 ゼロインバウンドSG ＆ 最小権限IAM : 受信ルール0件のセキュリティグループやSSM/ECR/S3接続に必要なIAMポリシーを一括定義。 Lambda自動デプロイと環境破棄 : Pythonコードの自動ZIP化からプロビジョニング、そして検証終了時の terraform destroy による確実なクリーンアップ性を確立。 手動セットアップや場当たり的なスクリプトを排除し、コードで再現可能なインフラ基盤が整ったことで、日々のLLM検証をより安全・確実に運用できるようになりました。

アマゾン ウェブ サービス ジャパン（以下、AWS ジャパン）が実施する「 生成 AI 実用化推進プログラム 」は、生成 AI の活用を支援する取り組みです。お客様のニーズに合わせ、カスタムモデルによる課題解決に取り組む方向けの「モデルカスタマイズコース」、公開モデルによるビジネス課題解決を狙う方向けの「モデル活用コース」をご用意しております。 その「生成 AI 実用化推進プログラム」の参加者や、GENIAC（Generative AI Accelerator Challenge）の関係者、生成 AI に関心を持つ企業が一堂に会する「生成 AI Frontier Meetup」が、2026 年 8 月 27 日に開催されました。2024 年 11 月の 第 1 回 、2025 年 2 月の 第 2 回 、2025 年 4 月の 第 3 回 、2025 年 8 月の 第 4 回 、2025 年 11 月の 第 5 回 、2026 年 2 月の 第 6 回 、2026 年 5 月の 第 7 回 に続き、今回が第 8 回となります。本記事では、イベントの模様をレポートします。 本イベントの司会進行は、AWS ジャパン 戦略事業開発本部 プリンシパル 戦略事業開発マネージャー 塚本 陽子が務め、全体を通じて登壇者の紹介やセッションの案内を行いました。 開会のご挨拶 イベントの冒頭では、塚本が開会の挨拶を行いました。 塚本はまず、AI を取り巻く環境の急速な変化について言及。日本政府が AI と半導体を含む戦略分野へ 2040 年までに官民累計 370 兆円超を投資する方針を示したことや、自律型エージェントを運用するインフラが整いつつある現状を説明しました。 一方で、S&P Global の調査を踏まえ、AI 実証実験の 46% が現場ニーズとのミスマッチや組織的な準備・運用体制の不足で本番導入前に打ち切られている課題もあると指摘。AWS はこのギャップを埋めるべく、構築から運用、セキュリティまで包括的なサポートを強化してきたと語りました。加えて、OpenAI 社との連携拡大や Amazon Quick のような自律型エージェントの進化についても触れました。 続いて、「LLM 開発支援プログラム」や「生成 AI 実用化推進プログラム」、「フィジカル AI 開発支援プログラム」など AWS のこれまでの支援実績の歩みを振り返りました。経済産業省と NEDO が主導する「GENIAC」プロジェクトへの継続的な支援実績を報告するとともに、今後は「フィジカル AI 開発支援プログラム」を「生成 AI 実用化推進プログラム」へ統合して窓口を一本化し、より柔軟な開発支援を提供していく方針を示しました。 最後に、本ミートアップを通じた AI 活用の加速に期待を寄せて挨拶を締めくくりました。 AWS セッション AWS セッションの前半パートでは、ゲストスピーカーである Weights & Biases Japan AI ソリューションエンジニア 山本 祐也 氏（写真上）が登壇。後半パートでは、AWS ジャパン プリンシパル スタートアップ ソリューションアーキテクト 針原 佳貴（写真下）をモデレーターに、対談形式でセッションが行われました。 山本氏はまず、ディープラーニングの実験管理ツールを提供する同社の歩みを紹介した上で、3 年以上にわたり運営を続けている日本語 LLM リーダーボード「Nejumi」の取り組みについて語りました。「Nejumi」は日本経済新聞社の「AI モデルスコア」にもデータ提供を行うなど、国内の生成 AI 開発における重要な指標となっています。山本氏は「網羅的かつ継続的に評価を続けること自体が業界貢献になる」と、その意義を強調しました。 続いて、LLM 評価トレンドの変遷を解説しました。2023 年から 2024 年頃は人間が比較採点する形式が主流でしたが、AI が高度化するにつれて人間の採点限界を超えてきています。そのため、API の利用実績をベースにした OpenRouter や、多面的に測定する Artificial Analysis など多様な手法が登場しています。 一方で、現在の評価における大きな壁として「ベンチマークのデータ汚染」と「評価コストの爆発」を挙げました。特にエージェント機能の評価においては、1 つのモデルの評価だけで最大 100 万円規模の費用が発生する「ベンチマーク破産」のリスクに言及。同社では、難易度を分散させたハイローミックス設計を行うことや、トレースデータを分析して極端に負荷のかかるタスクを特定・改善することで、コストと信頼性を両立させている旨を解説しました。 対談パートでは、針原からの問いかけに応じる形で、日本語モデルの現状や実践的な評価設計について議論を行いました。山本氏は、米中モデルが先行する中でも国内モデルは着実に進化していると言及。一般的なビジネスユースケースでは十分な実用性を備えていることに加え、データ主権を守る「ソブリン AI」としての需要も高まっていると説明しました。AWS 側からも、 Amazon Bedrock Marketplace 等を通じた国内モデルの普及支援の重要性が語られました。 さらに議論は、製造やロボティクスといった物理空間で動作する「フィジカル AI」の領域にも波及。実世界でのタスク遂行に向けたモデル開発や、現場導入を見据えた評価の重要性についても意見が交わされました。 最後に山本氏は Weights & Biases 社のサポート体制に言及。「基盤モデルの開発だけでなく、Claude Code や Codex などの API 利用のトレースまで幅広くカバーしている」と語り、あらゆるフェーズの生成 AI 開発者を支援する姿勢を示してセッションを終えました。 カスタマー事例 ここからは、生成 AI 実用化推進プログラムに参加する各社の代表者が登壇し、自社の取り組みを紹介しました。AWS ジャパン サービス & テクノロジー事業統括本部 AI Specialist SA の鯨田 連也（写真右）と Senior GenAI / Agentic AI Sales Manager の官能 翔一（写真左）がモデレーターを務め、登壇者に質問を投げかけつつ進行しました。 株式会社みずほフィナンシャルグループ デジタル戦略部 テクノロジー第二チーム ヴァイスプレジデントの皆川 拓 氏は、同行が推進する「みずほ LLM」の開発と実務活用の取り組みを紹介しました。 独自 LLM を開発する背景として「データの機密性・主権の確保」「金融規制・法令対応の担保」「専門業務への適用・競争力の源泉化」の 3 点を提示。AWS 上に構築された基盤「みずほWiz Base」を軸に、内製開発体制で迅速な実装を進めている体制を説明しました。 開発プロセスにおいては、行内資料等を活用した追加学習によって金融基礎知識の正答率を約 9 割まで高めた後、実務適用フェーズへと移行。融資判断など複雑な業務に対応すべく、社内有識者の知見をもとに確認論点や次アクションを評価するデータセットを作成し、ファインチューニングや RAG を組み合わせて精度を向上させている現状を解説しました。 今後は行員が実際にモデルを試用できる環境を整え、現場のフィードバックを反映した改善を継続するほか、独自 LLM を組み込んだ安全かつ高効率な AI エージェントの技術検証を進めていくと展望を語りました。 株式会社Sapeet AI Solution 事業部 Senior Project Manager / Senior Systems Architect の村上 大昌 氏は、仰星監査法人における「監査リスク分析 AI」の開発事例をもとに、ノーコードからコードベースへの移行戦略と実践知見を語りました。 立ち上げフェーズではノーコードツールの Dify と Amazon Bedrock を採用し、非エンジニアも巻き込んだ迅速なプロトタイピングにより作業時間 87% 削減を達成。しかし、プロダクトの成長に伴い「ワークフロー肥大化による見通しの悪化」「複数人開発におけるコンフリクトやバージョン管理の難しさ」「標準チャット UI の表現力の限界」という 3 つの課題に直面しました。 そこで同社はコードベースへの移行を決断。実行基盤に Amazon Bedrock AgentCore 、エージェントのワークフロー記述に Strands Agents を採用しました。Dify の資産を活かした設計により実質 2 週間という短期間で移行を完了し、業務に最適化したダッシュボード UI も実現しました。 村上氏は「フェーズに応じた適切な技術選択が重要」と強調。初期に求められるスピード感と成長後の拡張性・保守性を両立させる実践的なアプローチを示しました。 株式会社rh labo R&D部 プロダクトマネージャーの金田 洋平 氏は、既設の防犯カメラと生成 AI を活用し、賃貸住宅のゴミ置き場における放置・散乱問題の解決に挑む取り組みを発表しました。 ゴミ出しのルール違反は物件の資産価値や入居率に直結する一方、従来は定期巡回や通報頼みで対応が後手に回る課題がありました。そこで同社は、防犯カメラ画像を Amazon EventBridge や Amazon ECS を介して取得し、Dify と Amazon Bedrock を連携させて画像解析・Slack 通知を行う仕組みを構築。個人情報保護法への配慮として Amazon Rekognition を前段に配置し、人物が写り込んだ画像を除外する設計を施しました。 運用においては「誤検知しても人に無駄な通知が飛ばない」設計思想を徹底。前日画像と比較する 2 段階判定や AI の確信度スコアを活用することで、PoC において誤アラート率を 0.41% まで抑え込み、低コストでの本番稼働を実現しました。 金田氏は、本取り組みによりゴミ問題の発生率や放置日数が指標化できたと説明。「今後は注意喚起や回収手配までを AI エージェント化し、より自律的な課題解決を進めたい」と展望を語りました。 株式会社BTM DX推進事業 ITエンジニアリング事業部 部長補佐の瀬崎 優太朗 氏は、「非エンジニアでもできる障害調査」をテーマに、AI エージェントを活用したシステム運用保守の効率化ソリューションを紹介しました。 システム障害の問い合わせ対応では、その連絡を受けた非エンジニア（営業やカスタマーサポート）と技術チーム間で複数回のやり取りが発生し、解決までに多くの時間とコミュニケーションコストを要する課題がありました。 同社はこれを解消すべく、チャットツールから自然言語で入力するだけで、AI エージェントが Amazon CloudWatch Logs や Amazon Aurora を直接調査・要約して即座に返答する仕組みを構築。電話対応中に約 1 分で一次回答できる体制を整え、調査工数を最大 95% 削減しました。 システム基盤には Amazon Bedrock AgentCore  を採用して疎結合な運用管理を実現。破壊的 SQL の実行を遮断するツール側の制限や各種ガードレールを組み合わせた「多層防御」により、安全性を確保しています。瀬崎氏は「専門知識を要する調査を AI が代替することで属人化を解消できる」と語り、さらなる業務改善を進める姿勢を示しました。 クロージング クロージングでは塚本より、次回の「生成 AI Frontier Meetup」が、2026 年 11 月 10 日に開催予定であることを説明しました。加えて、生成 AI 関連の開発・運用において参考になる技術ブログも紹介しました。 Bedrock Managed Knowledge Base を MCP Tool として利用する際のテナント分離・アクセス制御まとめ   Amazon Bedrock Managed Knowledge Base は、フルマネージドで RAG を実現するためのサービスで、 AgentCore Gateway のネイティブコネクタとして MCP Tool 化し、Agent から利用することも可能です。 Amazon Bedrock AgentCore で Agent をプロダクション利用する際の実装ノウハウ   AWS Summit Japan 2026 にて、「Bedrock AgentCore で実現する AI エージェントの最前線」というタイトルでブース（A105）を出展させていただき、ブース展示用に AWS Specialist Agent を開発しました。これは、AWS に関することなら何でも解説できる Agent で、Amazon Bedrock AgentCore の機能や、AWS Summit New York City 2026 で公開された新機能をフル活用しています。 Secure AI agents with Policy and Lambda interceptors in Amazon Bedrock AgentCore gateway 非決定論的に動作する Agent に対して、実行可能なツールやアクセス可能なデータを制御することは重要な課題です。本記事 (Global Blog) では、Amazon Bedrock AgentCore を利用し、ユーザーやロール、テナント属性に応じたツールアクセス制御 (Fine-grained access control) に加えて、テナント境界を越えたデータアクセスを防ぐための最小権限設計など、セキュアな Agent の実現方法を解説しています。 参加者交流会の様子 ネットワーキングの時間では、各セッションで議論されたテーマを踏まえ、参加者同士が知見を共有し合う熱気あふれる交流が行われました。業界の垣根を越えて「学びと繋がり」を深める本イベントらしい活気にあふれ、新たな共創の可能性を感じさせる場となりました。 会場内には、技術的な相談に応じる「Ask an Expert」コーナーや、各種の疑問を気軽に相談できる「よろず相談」コーナーも設けられ、参加者の方々の質問に回答いたしました。 おわりに 第 8 回を迎えた本イベントでは、生成 AI の最新技術トレンドや実践的な評価手法について深い知見が共有されたほか、参加者の方々がネットワークを広げる貴重な機会となりました。AWS ジャパンは、今後もコミュニティの活性化や技術支援を通じて企業の生成 AI 活用を後押しし、その実用化と発展に貢献してまいります。

2026 年 8 月 31 日、AWS ジャパンは「フィジカル AI 開発支援プログラム by AWS ジャパン」の最終成果発表会を AWS 麻布台ヒルズオフィスで開催しました。 1 月 27 日に発表 し、 51 社 ( うち半数以上がスタートアップ ) を採択、 3 月 3 日のキックオフ から約 6 ヶ月支援してきました。 6 ヶ月をふりかえって プログラムでは、フィジカル AI 領域スペシャリストによる技術支援、コスト最適化支援、ロボティクス・生成 AI コミュニティ形成、Go-To-Market 支援の 4 つの柱で参画企業への支援を行いました。アマゾングループが世界 300 以上の施設で約 100 万台のロボットを運用してきた経験も、この 4 つの柱の設計に反映しています。 技術支援の中心は、アカウント担当とスペシャリスト Solutions Architect (SA) チームによる個別の伴走です。週次の定例を設けたり、開発の現場まで伺った企業もありました。あわせて Prototyping & AI Customer Engineering (PACE) チームによるプロトタイピング支援やサンプルコード Physical AI Scaffolding Kit (PASK) の公開、 生成 AI イノベーションセンター (GenAIIC) による支援も進めています。 コスト最適化の面では、開発の初期段階での試行錯誤がしやすいよう総額 600 万 US ドル規模の AWS クレジットをご用意しました。 コミュニティ形成では、 Physical AI on AWS のアーキテクチャ や NVIDIA Robotics Solutions 、グローバルトレンドとロボットに関する勉強会と、 コミュニティミートアップ を開催しました。 Go-to-market の面では、AWS Summit Japan 2026 でのデモ展示など、採択企業の露出と連携の機会づくりを行いました。参加企業からは、AWS 経由で紹介した顧客との商談につながったという声もいただいています。 以下では、8 月 31 日最終成果発表会について、第一部 (記者向け成果発表会)・第二部 (参加企業向け成果発表会) にわけて紹介します。 記者向け成果発表会 冒頭、AWS ジャパン 代表執行役員社長の白幡 晶彦が登壇し、プログラムを総括しました。 AWS ジャパンは、日本への投資を「技術」「信頼性」「人と社会」の 3 本柱で進めており、本プログラムはその 1 つ目である技術への投資の中核にあたります。今年 1 月には「日本のために、社会のために、その先へ」という目標を掲げました。日本はロボティクスで世界をリードしてきており、ハードウェア設計、精密制御、製造技術には数十年の蓄積があります。この強みに生成 AI を掛け合わせることが日本にとって最大の機会であり、世界に対する最大の競争力になる。この領域は日本政府も重要施策のひとつとして位置づけており、AWS はクラウドでフィジカル AI の実用化を支えていると話しました。 そのうえで、フィジカル AI による日本の社会課題解決に不可欠な要素を 3 つ挙げました。1 つ目はスピードです。採択した 51 社のうち半数以上がスタートアップで、完璧な計画を立ててから動くのではなく、仮説を立てて試し、学んで改善するサイクルを高速に回す機動力が社会実装を牽引しています。ハードウェアの開発から手がける企業も複数ありました。2 つ目は現場の力です。テクノロジーだけでは現場で役に立つロボットは生まれません。物流や建設、製造の現場で数十年にわたり蓄積されてきた知見とデータ、そしてスケールが、スタートアップの機動力と組み合わさることで一気に前へ進みます。3 つ目はクラウドです。基盤モデルの学習、大量のデータの収集と前処理、何百通りものシミュレーションを並列で走らせることをオンプレミスだけで行うのは、時間もコストも現実的ではありません。必要なときに必要な規模の計算資源を確保できることは、フィジカル AI の開発において選択肢のひとつではなく不可欠である、と述べました。 最後に「日本発のフィジカル AI イノベーションが、ここから生まれることを期待しています」と締めました。 各社の取り組み 13 プロジェクト・14 社が成果を発表しました。以下社名 敬称略、五十音順。文中の専門用語と固有名は末尾の注釈にまとめています。 株式会社アトム — 日本発のヒューマノイドメーカーを目指すスタートアップです。歩行と全身の制御をシミュレーター※1 の上で学習させ、実機で通常歩行と早歩きを確認しました。あわせて、人が遠隔操作した動きを記録し、そのデータから研究開発用途の自社モデル※2 を学習させて、荷物の仕分け作業などで一定の精度に到達。人の視点で撮影した映像のみを用いる学習は難航しましたが、遠隔操作のデータに加えることで学習が進むことを確認し、現在その精度を検証しています。8 月 28 日には物流作業を対象に 24 時間の連続稼働デモを実施しました。AWS は計算リソースの計画と提供、フィジカル AI チームとの技術ディスカッションで支援しています。今後は 200 台規模のロボットと 30 万時間のデータ、数十億パラメーターの基盤モデルという規模で、台数・データ量・モデルの規模を増やせば性能が向上するのかを検証する計画です。同社はこれを、日本で初めてのロボット基盤モデルのスケーリング則の証明と位置づけています。 オムロン サイニックエックス株式会社 — オムロングループで先端技術の研究開発を担う会社です。今回は、フィジカル AI の土台にあたる研究の成果を発表しました。現在のフィジカル AI 開発では、AI の能力評価、動作データの準備、大規模モデルの構築に多くの人手と計算資源が必要です。そのハードルを下げるため、「理解・行動・振り返り」に対応する 3 つの成果を示しました。1 つ目は、AI がどの程度まで動画を正しく理解できるかを測る評価用ベンチマークの開発です。規模の大きいモデルでも時間の前後関係を取り違えやすく、しかも自身が生成した誤りには気づけないことが明らかになっています。2 つ目は、規模の小さいモデルでも言葉を理解する能力を活かしてロボットを動作させる手法。3 つ目は、動作中の失敗をその場で検出して理由を出力し、その失敗を活かして精度を自己改善する仕組みです。この 3 つは「状況を理解する」「行動を生成する」「振り返る」という一連のループの各工程に対応しており、ループとしてつなぐことで動作の精度が自ら上がり、モデルの軽量化によって速く安く回せるようになる、という構想が示されました。AWS からは高性能な GPU リソースの提供と、AWS 環境を利用するための補助 (コンソールの操作ガイド、GPU をまとまった期間確実に予約できる Amazon EC2 Capacity Blocks for ML の活用提案) を受けており、約 3 ヶ月の利用を通じて特許・論文を 3 件投稿しました。インスタンスの確保からセットアップまでを通した支援やガイダンスの充実があれば研究開発をさらに加速できる、という要望もあわせて示されました。 株式会社ZEALS — ヒューマノイド本体から専用のソフトウェア基盤、動作用のモデルまでを自社で開発するスタートアップです。3 月の採択時点ではソフトウェアに特化し、他社製の機体を活用していました。現場のデータを取得するには現場に入れる身体が必要ですが、日本の狭い廊下を通れ、人と同じ空間で安全に動き、現場が導入できる価格の機体は、当時中国にもアメリカにも見つからず、自社開発に踏み切りました。8 月にローンチした準国産コンパクトヒューマノイド「D1」は、全高 129.3〜159.3cm、走行ベース幅 48cm で、2 本の腕を備えます。機体に加え、会話や自律移動を支える「Omakase OS」、物の操作を担う AI と学習・改善を支えるモデル・データ基盤「Omakase Zen」を揃え、現場データの収集から学習・評価、現場への再投入までを回す土台が整いました。AWS はモデル開発に使うデータ処理基盤の構築、学習の分散処理への対応、データ変換の高速化を支援しており、データ変換は 10 倍に高速化しています。発表会の直前には病院で 3 日間の実証を行い、自律移動、受付前での案内、配茶機の操作、ドアの開閉を D1 が実行しました。2026 年度は販売台数ではなく現場での稼働時間を指標に置き、100 台の量産と 10,000 時間の稼働を掲げました。 株式会社ダイフク・株式会社JDSC — 物流現場の完全無人化に向けて、マテリアルハンドリングのリーディングカンパニーと、AX・データ活用を手がける企業が共同で取り組みました。物流では入荷から出荷まで各工程に人の判断と手作業が残っており、加えて事前に登録したものしか扱えず、品目が変わるたびに設定を作り直す必要があることが、完全無人化の障壁の一つになっています。今回取り組んだのは、ロボットの基本動作と安全条件をあらかじめ用意しておき、作業手順は事前に定義しない方式です。「棚 A の 3 段目に品を 2 個補充して」という作業者の言葉を AI がその場で作業単位に分解し、各段階で成否を判定して失敗した部分のみを再実行します。学習は Amazon SageMaker AI、検証済みアセットの展開は CI/CD で自動化し、シミュレーションでの検証サイクルを高速に回す構成を AWS 上に構築しました。検証では、指示に沿って仕分け先を判断するタスクを対象に、シミュレーション環境において、学習していない商品と仕分け先の組み合わせでも 100 回中 97 回、適切な仕分けまで成功しました。物流における完全無人化の実現に向け、今後は実機での検証を含むフィジカル AI の研究開発を進めていきます。 株式会社竹中工務店 — 日本建設業連合会の長期ビジョンでは、建設業の技能労働者が 2035 年度に 129 万人不足すると見込まれる一方、建設投資額は拡大が見込まれています。この人手不足を補う手段のひとつとして、建設業に特化したモデル※2 を開発し、塗装作業への適用可能性を検証しました。難所はデータでした。建設現場で使う道具の 3D データが存在しないため、道具の 3D データを自社で用意し、実際の現場を撮影した映像から三次元で再現したデータと組み合わせて「壁をローラーで塗装する」作業の学習データを構築しています。遠隔からデータを収集できる環境も整えました。AWS 上に構築したシミュレーション環境のなかに、収集から公開モデル※3 の調整、検証までを一貫して行う仕組みを構築しました。シミュレーション上での塗装動作 (物体操作の部分) の精度は現時点で 10〜15% 程度で、移動をともなう動作は検証中です。残る課題は、学習データが不足していて収集も難しいこと、そして検証と、シミュレーションで学習した動きを実機で通用させること※4 です。今後は建設技能労働者を支援するロボットの実現に向けて、言語モデルを介した人とロボットの会話にも取り組む方針です。 Telexistence 株式会社 — ロボットの基盤モデルを自社で開発するスタートアップです。基盤モデルには、言語モデルを土台にする方式と、動画生成モデルを土台に世界の動き方そのものを学習する方式※5 の 2 系統があり、同社は両方を開発しています。今回は後者を実機に載る形で確かめるため、10 億パラメータの軽量なモデルを自社開発しました。Amazon の研究チーム (Frontier AI & Robotics) の成果も取り込んでいます。AWS 上には、データの蓄積から学習、構成とデータの指紋を記録して再現性を担保するチェックポイント管理、学習を止めずにシミュレーション上で性能を測る評価までをつないだ仕組みを構築。設計の異なるモデルを同時に学習させ、条件を揃えて比較できるようにしたことが検証速度に直結したとのことです。結果として、大量のロボット動作データによる事前の学習を経ていない自社モデルの成功率が 86% となり、事前学習を済ませた公開モデル※6 の 80%、同じモデルを事前学習なしで初期化した場合の 50% に対して、事前学習済みのモデルと同等の水準に到達しました。大量のロボット動作データに依存せずに動作するモデルを構築できれば、開発の初期投資を抑えられます。 株式会社野村総合研究所 — フィジカル AI という言葉が広まる前からロボティクスに取り組んでおり、環境や用途に応じて適切な技術を選定できることを強みに挙げています。2025 年 10 月から 12 月には成田空港にお土産販売のロボット店舗を出店し、完全無人での販売を実施した実績があります。今回は 3 つのアプローチを並行して探索しました。実機を使った学習ではペットボトルのピッキングに成功。実環境を再現したシミュレーションで学習させて実機を動かす手法※7 では、映像の質感が実環境と異なるという課題を改善し、シミュレーション上で学習したモデルで実機を動かせる可能性が見えています。3 つ目は人の一人称視点で作業を記録したデータを用いる方法で、人の作業データからロボットのモデルを構築できることを確認しています。将来的には、現場スタッフの作業データによってロボットを導入できる状態を目指しています。データ収集からチーム内でのデータ共有、モデルの訓練と評価までを AWS 上に構築し、必要な計算資源を短期間で確保できたとのことです。 株式会社Highlanders — 四足歩行ロボットとヒューマノイドを、機体から AI、量産までを一体で開発する 2023 年創業のスタートアップです。危険・過酷な現場の「移動」を四足歩行ロボット「HLQ PRO」で置き換え、その先の「作業」をヒューマノイド「N」で担う二本立ての事業を掲げ、機械設計、電装・制御、通信・クラウド、AI、量産・品質までを同じチームで手がけています。今回は、自社開発のモデル「Kepler」を支える一連の仕組みを AWS 上に構築しました。「Kepler」は、ロボットが周囲を捉えて次に起きることを予測し、行動を決める 100 億パラメータのモデルで、じっくり計画を立てる層と素早く反応する層を組み合わせ、量産で集まるデータをもとに自ら改善していく構成です。AWS 上には、遠隔操作などで生まれる大量のロボット動作データを集約して整える処理、実機での収録だけでは足りない例外的な状況をシミュレーター※1 の並列実行で補って学習用のデータを生成する処理、AWS ParallelCluster による大規模な GPU クラスタでモデルを学習させる処理までをつなぎ、学習を 24 時間 365 日動かし続ける体制を実現しています。構築にあたっては AWS の Solutions Architect とフィジカル AI の専門チームが議論に加わりました。あわせて 2026 年 6 月 25 日・26 日の AWS Summit Japan では、四足歩行ロボット「HLQ PRO」の実機による実演デモを行いました。 FastLabel 株式会社 — AI 開発用のデータを専門に扱う会社です。フィジカル AI でも、学習データを増やせば性能が伸びるという関係が示されつつありますが、ロボットを実際に動かして集めるデータは容易には増やせません。そこで、シミュレーター※1 上で作成した少量の動きのデータを大量に増やし、実データと混ぜて学習データセットを作る仕組みを構築し、その効果を検証しました。遠隔操作により作成した 90 パターンの動きを約 100 倍に拡張し、不正な動作や失敗を除いて 10,000 パターンを取得。シミュレーション上で条件をランダムに変えることで、規模だけでなく多様性も確保しました。実データのみで学習した場合と比べ、データを収集した環境での作業成功率が平均 14.2% 向上し、データを収集した環境とは異なる環境でも、対象物に手を伸ばす動作の達成率が改善して汎化性の向上が確認されています。学習したときの環境から条件が変わると精度が落ちるという、現場導入の障害となる課題に対して改善が見られたことになります。一方で、シミュレーションデータの量が最も多い条件では成功率が下がっており、シミュレーション環境への過適合の可能性が残るとして、現在も分析と検証が進められています。データ構築の費用と性能の関係も定量化され、シミュレーションによってデータ収集のコストを下げられる可能性が示されました。学習は AWS 上の GPU インスタンスで行い、AWS からはシミュレーション技術の知見と計算リソースの提供を受けています。 株式会社豆蔵 — システム工学・ソフトウェア工学・ロボット工学を強みとし、ソフトウェアから AI、機構、電気までを自社で手がける技術者集団です。産業向けに開発してきた「ヒューマノイドロボットでの板金整列アプリ」について、これまで対応できていなかった 2 つのテーマに取り組みました。上半身は、遠隔操作で 359 パターンの動きを収集してモデル※2 に学習させました。ただし映像だけを頼りにした制御では衝突が発生したため、力の強さを測るセンサーを使って柔らかく当てる制御を追加しています。無作為に積まれた部品から 1 枚を取り出す動作はモデルでは成功率が低かったため、取り出しは従来のプログラム、整列はモデルという分担にして、整列の成功率は板金の上下整列で 85%、左右整列で 80% を達成。下半身は、メーカー標準の制御では実現できなかったしゃがみ動作・前傾動作を、シミュレーション上での強化学習によって独自に実現しました。全身の制御も、作業に必要な 10 の関節に絞ることで 43 パターンの動きで実現しています。全身の関節すべてを使って同じことを行う場合には一般に 2,000 パターン以上が必要とされる (NVIDIA Isaac GR00T の FAQ による目安) ので、学習に必要なデータを大幅に減らせたことになります。公開モデル※3 の調整は約 8 時間、下半身の強化学習は約 32 時間で、いずれも AWS 上の GPU インスタンスで回しました。すべてをモデルで解決せず、従来のプログラムと相互に補完するハイブリッド構成が現実的だという結論は、産業での実用を前提に置いた発表でした。 株式会社MW — 住宅そのものを開発し、そこに AI とロボットを組み込む会社です。照明やエアコンの制御は同社のスマートホーム基盤「MW intelligence」によって自動化できていますが、物理的な作業をともなう家事は依然として人の時間を奪っています。ここを自動化するために開発しているのが、住宅に組み込むガントリー型の半人型ロボット「MW bot」です。人のように動きながら、家具のように暮らしに溶け込みます。家事は手順の決まっていない非定型の作業なので、そのためのモデル※2 を自社で開発しています。データ収集の専用拠点を設け、年間 5 万時間規模の家事データの収集を開始しました。最終的には 2.5 PB の学習データを集める予定です。本プログラムではモデルの追加学習までを実施し、日次で集まるデータを Amazon S3 に蓄積し、Amazon SageMaker HyperPod で学習したモデルを実機で検証して次の学習に戻す循環を構築しています。今後は大量の学習データの管理と、大規模なモデル学習の面で AWS との連携を深めていく方針です。 株式会社メルカリ — 越境取引の拡大にともない、海外へ発送する商品をいったん国内の自社倉庫に集めて検品する作業が増え続けています。検品は倉庫の他の工程に比べて約 10〜60 倍の時間を要し、ロボットを投入したときの効果が最も大きい工程です。今回はこの検品・出品作業の自動化に取り組みました。いまのロボットを動かすモデル※2 には、力加減の制御が難しい、カメラの位置が変わると精度が落ちる、学習データを集めるのが困難という 3 つの限界があります。それぞれに対して、力の強さを測るセンサーと触った感触を捉えるセンサーをモデルに統合する、どの位置から撮った映像でも学習したときの視点に投影しなおしてからモデルに入力する、力加減や触感も一緒に記録できる専用の収集機器で人の作業を取り込む、という 3 つの手法でモデルの開発に取り組んでいます。まずは同じカテゴリのなかでばらつきが小さい靴の検品に注力し、箱を開けて靴を取り出し、全面を確認して戻し、箱を閉じて元の位置に戻すまでの 9 工程を対象としました。学習は AWS 上の分散学習で進め、立ち上げをスムーズに行えたとのことです。靴の検品については 2026 年度中の実証実験に向けて製品設計を進めている段階で、2028 年には自社倉庫の約 20% を自動化し、社内コストを年間最大 2 億円削減する計画です。 株式会社リコー — 現場の文書の AI 化から始め、定型業務、非定型業務へと AI の適用範囲を広げ、その 4 段目として現場作業への実装を掲げています。課題として置かれたのは、ロボットの行動データが質・量・多様性のいずれの面でも不足していること、さらにロボットの機種 (アーム型や人型など本体の構成) が変わるたびにデータ収集と学習を繰り返す必要があり、それが規模の拡大と普及の足かせになっている点でした。そこで、公開されているモデルを土台に、機種に依存しない共通の動作表現をいったん学習し、機種ごとに差し替えるのは出力側だけにする方式を検証しています。AWS 上に GPU サーバー 5 台の学習環境を構築し、1 回の試行を約 4 日、モデル改良を週 1 サイクル回せる体制を確立しました。結果として、ひとつの共通表現をもとに 3 種類のロボットをシミュレーション上で動作させられることを確認し、うち 1 機種は実機でも自社部品のピックアンドプレースを実行できることを確認しました。あわせて公開ベンチマークでの評価では、モデルの規模※8 を約 3 分の 1 に抑えても性能が保たれることを示しました。同じ性能を小さなモデルで出せれば、ロボット側に載せる計算資源の選択肢が広がります。本プログラムでの実施範囲は技術の蓄積までで、共通の動作表現を用いたモデルの使いこなしと改良のノウハウを獲得した段階です。今後は自社工場での事例づくりを進めたうえで、お客様との共創に移り、自社とお客様の環境に適したハードウェアへ広げていく方針です。 注釈 ※1 シミュレーター: NVIDIA Isaac Sim / Isaac Lab。ロボットと現場をソフトウェア上に再現し、実機を損傷させずに大量の試行を行える環境です。アトムはこれに MuJoCo を併用しています。 ※2 ロボットを動かすモデル: 正式には Vision-Language-Action (VLA) モデル。カメラの映像と人の言葉を受け取り、ロボットの動きを直接出力するモデルを指します。 ※3 公開モデル (竹中工務店・豆蔵): NVIDIA Isaac GR00T。NVIDIA が公開しているロボット向けの基盤モデルで、各社が自社の作業に合わせて調整のうえ利用します。 ※4 シミュレーションで学習した動きを実機で通用させること: Sim2Real と呼ばれます。シミュレーション上では成功しても、摩擦や照明などの条件の違いにより実機では動作しないことが多く、フィジカル AI 共通の課題です。 ※5 動画生成モデルを土台に世界の動き方そのものを学習する方式: World Action Model と呼ばれる系統で、Diffusion Transformer と呼ばれる構造を用います。言語モデルを土台にする方式と比べ、時間の流れを扱いやすい一方で、推論にかかる計算コストが大きくなります。 ※6 事前学習を済ませた公開モデル (Telexistence): Physical Intelligence の π0.5。大量のロボット動作データで事前に学習された基盤モデルです。 ※7 実環境を再現したシミュレーションで学習させて実機を動かす手法: real2sim2real と呼ばれます。 ※8 モデルの規模: パラメータ数で表します。今回は共通の動作表現を用いない 70 億パラメータのモデル (81.3pt) と、20 億パラメータのモデルに共通の動作表現を加えたもの (81.5pt) を、ロボット操作の公開ベンチマーク LIBERO-10 で比較しています。 総括 13 プロジェクトの発表のあと、AWS ジャパン プリンシパル スタートアップ ソリューションアーキテクトの針原 佳貴がまとめを話しました。 AWS ジャパンの生成 AI 開発支援は、2023 年に日本のスタートアップから「日本語に特化した基盤モデル・大規模言語モデルを自社で開発したい」という声を受け、4 つの柱で LLM 開発支援プログラムを立ち上げ、国内 17 社のモデル開発を支援したことから始まりました。その後、モデル開発だけでなく利活用を支援する生成 AI 実用化推進プログラムやグローバルのアクセラレータでも支援を行い、並行して経済産業省 GENIAC に採択されたお客様の基盤モデル開発を支えるなど、官民で連携した取り組みを続けてきました。 フィジカル AI 開発支援プログラムは、その延長線上にあります。昨年秋ごろからスタートアップの皆様と話すなかで、日本にも画像や動画を扱う基盤モデルの開発実績があり、現場のデータを使えば国産の VLA を作れるのではないか、ただしスタートアップ単独では難しいので AWS からの支援があると嬉しい、という声をいただいたことが出発点でした。お客様のニーズから逆算してプログラムを設計し、1 月に発表、3 月から半年間の開発を進めてきたことになります。プログラム期間中に AWS 社内でもフィジカル AI のワークロードを支援する体制が手厚くなったため、今後は生成 AI 実用化推進プログラムの枠組みのなかでフィジカル AI の支援を続けていきます。 閉会後は、ロボット展示会場へ移動しました。展示したのは 2 機です。 ZEALS の準国産コンパクトヒューマノイド「D1」は、病院・商業施設・物流施設・製造現場などへの導入を前提に設計された機体で、日本の病院の廊下を通れるコンパクトさと、人がぶつかっても安全な柔軟さが特徴です。 Highlanders のヒューマノイド「N」は、人向けの設備や道具をそのまま扱える身体と 5 指ハンドを備え、製造や物流の現場での軽作業を想定しています。いずれも動作に必要なデータ処理とモデル開発に AWS のクラウドをご活用いただいています。 参加企業向け成果発表会 参加企業向けの成果発表会では、冒頭 AWS ジャパンの針原と、経済産業省 商務情報政策局 AI 産業戦略課 課長補佐の秋元氏による挨拶の後、AWS ジャパンの木村がモデレーターを務め、以下の企業の成果が発表されました。以下社名 敬称略、五十音順。 株式会社アイシン／ブレインズテクノロジー株式会社 株式会社ACCESS 株式会社APTO SCSK株式会社 株式会社Enactic 株式会社カミナシ カラクリ株式会社・Upstage Co., Ltd.・株式会社ジェイテクト クラスメソッド株式会社 大日本印刷株式会社 株式会社PKSHA Technology 株式会社MIXI 三菱電機株式会社 Muso Action株式会社 株式会社メルカリ 得られた知見 3 月のキックオフの時点では、現場のデータを使って国産の VLA を作れるのか、作れたとして現場で使えるのかが、まだ見通せていませんでした。第一部の発表を通して見えたことを、白幡が挙げた 3 つの要素に沿って整理します。 まずスピードです。アトム、ZEALS、Highlanders、MW と、自社ハードウェアの開発から取り組んだ企業が複数ありました。ZEALS は 3 月時点では他社製の機体を活用していましたが、8 月に「D1」をローンチし、発表会の直前には病院での実証まで行いました。アトムは発表会の 3 日前に、物流作業で 24 時間の連続稼働デモを実施しています。速く回すには、安く早く測れることが前提になります。オムロン サイニックエックスは動作中の失敗をその場で検出して次の動作に反映するループを設計し、Telexistence は設計の異なるモデルを同時に学習させて条件を揃えて比較できるようにしたうえで、学習を止めずにシミュレーション上で評価を回す仕組みを組みました。FastLabel はデータ構築の費用と性能の関係まで定量化し、リコーは 1 回の試行を約 4 日に収めてモデル改良を週 1 サイクル回せる体制を作りました。何を測れば「できた」と言えるのかを先に決めて評価側を作り込むことが、複数の発表で共通していました。 次に現場の力です。技術だけでは足りないという認識が、具体的な形で出てきました。竹中工務店は、建設現場で使う道具の 3D データが世の中に存在しないという壁にぶつかり、自分たちで用意しています。メルカリは自社倉庫を実証環境として使い、他の工程の約 10〜60 倍の時間がかかる検品を対象に選びました。そして AI だけで解こうとしない判断も共通していました。ロボットの基本動作と安全条件を用意したうえで、手順の組み立てと各段階の成否判定をモデルに任せたダイフク・JDSC、古典的なロボット制御と AI を組み合わせて従来は難しかった柔軟な作業に取り組んだ野村総合研究所、取り出しは従来のプログラム・整列はモデルという分担にした豆蔵。とくに豆蔵は、学習した環境と実際に動かす環境が同じでないと成功率が落ちる、対象物がカメラから見えなくなると動作が破綻する、複数の作業を学習させると成功率が下がるといった限界を挙げたうえで、90 点でも許される作業やリトライできる作業がモデルに向く、という切り分けの基準まで示しました。どこを学習に任せ、どこを作り込み、どうつなぐかが、そのままシステムの構成を決めます。 そしてクラウドです。計算の規模で制約を押し返した例が並びました。Telexistence は複数 GPU での分散学習で軽量モデルを学習させ、FastLabel は 90 パターンの動きを 10,000 パターンに拡張してタスク成功率を平均 14.2% 改善しました。MW は年間 5 万時間規模で集まる家事のデータを日次で蓄積して学習に回す循環を組み、リコーは GPU サーバー 5 台の学習環境で 1 試行を約 4 日に収めています。必要な規模を必要なときだけ確保する使い方も見られ、オムロン サイニックエックスは GPU をまとまった期間確実に予約できる仕組みを使って 3 ヶ月分の計算資源を確保しました。 3 要素の外側では、コミュニティが具体的な成果につながりました。野村総合研究所からは、勉強会での最新情報の共有が助かったという声をいただきました。豆蔵は、類似の取り組みを行う参加企業とのコミュニティが形成されて情報交換ができたこと、相互に得意分野を活かした協業関係の構築が進んでいること、AWS から紹介した顧客との商談につながったことを挙げています。 これから フィジカル AI の開発支援は今回で終了ではありません。お客様からいただいたご要望を踏まえ、 生成 AI 実用化推進プログラム に統合して引き継ぎます。 3 月のキックオフイベントで、私たちは日本発のフィジカル AI イノベーションが生まれる大きな可能性があるとお話ししました。6 ヶ月後の今日、第一部と第二部をあわせて 26 のプロジェクトと、実際に現場で動くロボットを紹介できることとなりました。ものづくりと現場の技術に生成 AI を掛け合わせるという道筋が見えたことが、このプログラムの成果です。AWS は引き続き、日本のお客様とともにこの領域に取り組んでまいります。 関連リンク プログラム発表 / キックオフ Physical AI Scaffolding Kit 生成 AI 実用化推進プログラム 木村 公哉（Kimura, Koya） アマゾン ウェブ サービス ジャパン合同会社 スタートアップ事業本部 技術統括部 シニアスタートアップソリューションアーキテクト 2023 年よりディープテックスタートアップを担当。支援プログラムの立ち上げなどに尽力し、2025 年よりフィジカル AI をはじめとしたロボティクス関連領域にも支援を拡大。2026 年 1 月に「フィジカル AI 開発支援プログラム by AWS ジャパン」を発足。VC・政府とのディスカッションを通じ、フィジカル AI・ディープテック領域のエコシステム形成にも取り組んでいる。 針原 佳貴（Haribara, Yoshitaka） アマゾン ウェブ サービス ジャパン合同会社 スタートアップ事業本部 技術統括部 プリンシパル スタートアップ ソリューションアーキテクト AWS Japan にて、ユニコーン企業を含む生成 AI スタートアップ企業を中心に 2019 年頃から技術支援を担当。2020 年よりマルチモーダル生成 AI 技術に携わり、生成 AI 大喜利「写真で一言 ボケて電笑戦」を企画・開催、広告賞である ACC ブロンズを受賞。2023 年の「AWS LLM 開発支援プログラム」立ち上げ、2024 年に発表された Amazon Bedrock Marketplace への日本発の基盤モデルのクラウド公開、2026 年発表の「フィジカル AI 開発支援プログラム」などを通じて、日本国内の生成 AI 技術発展に携わる。 生成 AI 分野に加え、日本におけるクラウド量子コンピューティングサービス Amazon Braket の普及や、量子スタートアップ・ハードウェア開発コミュニティとの連携により国産量子コンピュータのクラウド公開にも尽力。2024 年 11 月より、大阪大学 量子情報・量子生命研究センター 招へい准教授。東京大学 大学院 情報理工学系研究科 博士課程修了。博士 (情報理工学)。