フィジカル AI 時代に向けた、AWS IoT Greengrass における巨大ファイル配信手法
2026-02-03 | Author : 松下 享平 (AWS Community HERO)
はじめに
こんにちは、松下 (ニックネーム：Max) です。
AI/IoT プラットフォームを提供している 株式会社ソラコム で、テクノロジー・エバンジェリストをしています。また、AWS のユーザーグループ「JAWS-UG」では IoT 専門支部 に所属しており、IoT の普及に尽力しています。
AWS re:Invent 2025 では「Designing Local Generative AI Inference with AWS IoT Greengrass」というセッションで、ローカル環境における生成 AI 利用のポイントを解説する機会をいただきました。エッジ/ローカルデバイスでの生成 AI の必要性やフィジカルAIとの考え方等、セッション全体は 動画 や AWS Builder Center での解説記事 をご覧いただくとして、ここで１つ注目するのは「巨大ファイルの配信」です。
本記事では、この巨大ファイル配信を AWS IoT Greengrass (以下、IoT Greengrass) で実装する考え方をご紹介します。
※ 本記事で解説する AWS IoT Greengrass は V2 を対象としています。また、制約などの情報は 2025 年 12 月初旬現在です。
X ポスト » | Facebook シェア » | はてブ »
builders.flash メールメンバー登録
builders.flash メールメンバー登録で、毎月の最新アップデート情報とともに、AWS を無料でお試しいただけるクレジットコードを受け取ることができます。
巨大ファイル配信と AWS IoT Greengrass
生成 AI を動かすためには基盤モデルが必要ですが、ファイルサイズは数 GB を軽く超えます。例えば画像とテキストの両方を統合的に処理できる軽量なビジョン言語モデル （VLM） である SmolVLM でも 1 GB、ロボット制御のためのオープンソースのビジョン言語・行動モデル （VLA） の OpenVLA は 15 GB を超えます。
従来の IoT 向けファームウェア （数十MB規模） と比べると桁違いです。量子化等でファイルサイズを削減 できますが、精度劣化や削減量の限界点があります。そのため、生成 AI をエッジデバイスで用いる場合、この巨大ファイルの適切な配信・管理が IoT 開発における考慮ポイントです。
一方で、エッジデバイスはメモリーやストレージサイズが限られており、遠隔地で再起動などのメンテナンスが困難な現場に多いです。安定稼働のためには、ファイルの使用容量や運用管理を適切に行う必要がありますが、ゼロから管理の仕組みを構築するのは手間がかかります。
その手間を軽減できるのが AWS IoT Greengrass です。Linux 等の汎用 OS が動作するリッチなデバイスに対し、アプリケーションやファイルの更新、各種設定の管理を AWS クラウドを通じて遠隔で実現できます。
AWS IoT Greengrass における、3 つのファイル配信手法
IoT Greengrass でファイル配信を実施する場合、以下の 3 つの方法が考えられます。
- アーティファクト
- コンテナ同梱
- 実行時セットアップ
手法 1 : アーティファクト
IoT Greengrass にはアーティファクトがあり、標準的なファイル配信手法として最初に検討すべきです。アーティファクトとは、ファイルを Amazon Simple Storage Service (Amazon S3) に配置し、IoT Greengrass のデプロイ時にデバイスにコピー・展開する仕組みです。IoT Greengrass のレシピで以下のようにしてデプロイすると、デバイスへファイルが配信・展開されます。
AWS IoT Greengrass のアーティファクト指定の例
# (yaml) AWS IoT Greengrass レシピの抜粋
Manifests:
- Artifacts:
- Uri: s3://iot-greengrass-artifact-example-pheezu3u/Qwen3VL-2B-quantized.zip
Unarchive: ZIPZIP ファイル指定時の展開の例
上記の通り、ZIP 展開にも対応しています。デバイス側には、以下の通り展開されています。
# ls -lFh /greengrass/v2/packages/artifacts/com.soracom-max0.artifact-example0/1.0.1/
total 1.2G
-r--r----- 1 ggc_user ggc_group 1.2G Dec 19 15:57 Qwen3VL-2B-quantized.zip
# ls -lFh /greengrass/v2/packages/artifacts-unarchived/com.soracom-max0.artifact-example0/1.0.1/Qwen3VL-2B-quantized/
total 1.3G
-r--r----- 1 ggc_user ggc_group 264M Dec 19 15:57 mmproj-Qwen3VL-2B-Instruct-Q4_K_M.gguf
-r--r----- 1 ggc_user ggc_group 970M Dec 19 15:57 Qwen3VL-2B-Instruct-IQ4_XS.gguf展開が不要、もしくは展開前の ZIP ファイルは artifacts/ ディレクトリに、展開後のファイルは artifacts-unarchived/ に配置されます。デバイス上でのパスは {artifacts:path} や {artifacts:decompressedPath} という、レシピ変数 （プレースホルダ） で参照できます。
完全にマネージドであるため、ファイル操作の心配が無いのが利点です。しかし扱えるファイルサイズが 最大で 2 GB という制約 があります。この制約はファイル毎ではなく、レシピに登録したアーティファクトすべての合算値です。
ファイルサイズのチェック
ファイルサイズはレシピ作成時にチェックされます。
# (yaml) AWS IoT Greengrass レシピの抜粋 / 2 つのファイル合計が 2.0 GB を超える指定
Manifests:
- Artifacts:
- Uri: s3://iot-greengrass-artifact-example-pheezu3u/1.0GB.file
- Uri: s3://iot-greengrass-artifact-example-pheezu3u/1.1GB.file合計 2GB を超えるファイルを指定した場合
上記のように、合計 2 GB を超えるファイルを指定すると、レシピ作成時にエラーとなります。
2 GB を超えるなら、別の手法になります。
手法 2 : コンテナ同梱
IoT Greengrass は Docker コンテナを実行できます。そこで、コンテナ内に配信ファイルを同梱するというのがこの手法です。コンテナの配信は Amazon Elastic Container Registry (Amazon ECR) を用いるため、アーティファクトの制限から外れ、2 GB 以上のファイルでもデバイスに配信できます。Dockerfile の例は以下の通りです。 hf コマンドで HuggingFace 上の基盤モデル (例では ma2shita/gripper_awsreinvent25_wb3-act-a-steps10K) を取得しています。
Dockerfile の例
# syntax=docker/dockerfile:1
FROM python:3.10-slim
ENV PIP_NO_CACHE_DIR=1 PYTHONUNBUFFERED=1 PIP_DISABLE_PIP_VERSION_CHECK=1 HF_HUB_DISABLE_TELEMETRY=1
RUN apt-get update && apt-get upgrade -y && pip install "huggingface_hub[cli]"
RUN hf download --repo-type model --revision main ma2shita/gripper_awsreinvent25_wb3-act-a-steps10K
COPY runner.sh /myapp/
CMD ["bash", "/myapp/runner.sh"]docker build で作成したイメージを Amazon ECR にプッシュしておきます。その後、IoT Greengrass のレシピでコンテナを指定してデプロイすると、デバイスへコンテナが配信・実行されます。
AWS IoT Greengrass レシピの抜粋
この時、同時に aws.greengrass.TokenExchangeService と aws.greengrass.DockerApplicationManager というコンポーネント （アプリケーションとほぼ同義） も必要になります。この依存関係については Amazon ECR のプライベートイメージから Docker コンテナを実行 をご覧ください。
# (yaml) AWS IoT Greengrass レシピの抜粋
Manifests:
- Artifacts:
- Uri: docker:XXXXXXXXXXXX.dkr.ecr.REGION.amazonaws.com/iot-greengrass/container-example:v1
Lifecycle:
run:
Script: docker run --name infer_runner0 --rm XXXXXXXXXXXX.dkr.ecr.REGION.amazonaws.com/iot-greengrass/container-example:v1
shutdown:
Script: docker stop --timeout 3 infer_runner0 || true ; docker rm --force infer_runner0 || true
Docker コンテナの起動
デバイス上では Docker コンテナが起動している状態になります。
# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
acfa8fee59b2 XXXXXXXXXXXX.dkr.ecr.REGION.amazonaws.com/iot-greengrass/container-example:v1 "bash /myapp/infer_r…" About a minute ago Up About a minute infer_runner0前述の通り、アーティファクトの制限を超えたファイルサイズを扱えるのが利点です。また、開発やテストもコンテナの知識が利用できるため、導入の敷居が低いという点も挙げられます。デバイスが持つセンサーやカメラといった周辺機器も、 run 内の docker run 時に --device /dev/video0 としてコンテナ内に引き渡せますので、容易に利用できるかと思います。
制約は Amazon ECR に依存します。特に コンテナ 1 レイヤーあたり 50 GB という制限 が、気を付けるポイントです。マルチステージ ビルド を用いて、セットアップと基盤モデルを同梱する操作のレイヤーを分離しつつ、全体のイメージサイズをコンパクト化する手法が効果的でしょう。また、レイヤーのサイズは docker history <IMAGE> で確認ができます。エラーは Amazon ECR への push 時に発生するので、IoT Greengrass の運用サイクルへの影響はありません。
基盤モデルを同梱する操作のレイヤーが 50 GB を超えることになるなら、いよいよ次の手法となります。
手法 3 : 実行時セットアップ
これまでは IoT Greengrass のデプロイ時に配信する仕組みでした。この手法は、デプロイ後のアプリケーションの実行時に、自身を構成する仕組みです。AWS IoT Greengrass では、コンポーネントの起動時や再起動時に実行するコマンドをライフサイクルとして定義できます。例えば以下のようにレシピで install を指定しておくと、コンポーネント起動前の実行を制御できます。
# (yaml) AWS IoT Greengrass レシピの抜粋
Manifests:
- Artifacts:
- Uri: s3://iot-greengrass-artifact-example-pheezu3u/installer.sh
- Uri: s3://iot-greengrass-artifact-example-pheezu3u/runner.sh
Lifecycle:
install:
Script: /bin/bash {artifacts:path}/installer.sh
run:
Script: /bin/bash {artifacts:path}/runner.shライフサイクルを利用して、希望のタイミングで基盤モデルのダウンロードを含む環境構築を行うというのが、この手法です。ライフサイクルの種類は IoT Greengrass のレシピリファレンス をご覧ください。
IoT Greengrass はライフサイクルまでが管理対象で、ライフサイクルの中での実行内容自体は管理外です。よって AWS のサービスに起因する制約はありません。代わりに、ファイルの更新や削除といった運用管理は自身で行う必要があります。
とはいえ、IoT Greengrass の実行状態やログは AWS マネジメントコンソールを通じて確認できるため、何が起こっているかは追跡可能です。
ちなみに : Amazon SageMaker AI Edge Manager
少し前の情報になりますが、このような AI モデル管理は Amazon SageMaker AI Edge Manager という方法もありましたが、現在は AWS IoT Greengrass に引き継がれており、IoT デバイスの管理は AWS IoT Greengrass 一択となっています。
まとめ
GB 級の巨大ファイルを AWS IoT Greengrass で扱う３つの手法を解説しました。私のおすすめとしては、開発やテストの容易性と比較的制約が少ない「コンテナ同梱」です。
生成 AI をエッジデバイスで動かす需要が高まっています。よくあるのが「どの基盤モデルが優れているか？」という議論ですが、AI の本質は「どう進化し続けられるか」です。その点、AWS IoT Greengrass はデバイス上の AI を更新＝進化可能にする仕組みとして、今後さらに重要性を増すでしょう。
IoT Greengrass の学びの入り口には、チュートリアル や ワークショップ があります。ぜひ取り組んでみてください！
筆者プロフィール
松下 享平 (まつした こうへい)
株式会社ソラコム テクノロジー・エバンジェリスト / AWS Community Hero
IoT の活用事例やデモを通じて、IoT を世に広める講演や執筆を行う。登壇回数は延べ 500 以上、共著に『IoT エンジニア養成読本』(技術評論社) 等。1978 年生まれ、静岡育ち。座右の銘は「論よりコード」。JAWS-UG IoT 専門支部所属、AWS ヒーロー (2020 年受賞)
