AWS Lambda(Python3.12)でGemini APIを利用しようとした際、gRPC周りのライブラリ不整合で激しくハマったので備忘録として残します。
この記事でわかること
- Gemini API (google-generativeai) 使用時に発生するGLIBCXXエラーの原因
- AWS Lambda Layer（zip形式）でライブラリ管理が困難な理由
- Dockerコンテナイメージを用いたデプロイによる根本的な解決手順
[現象] デプロイ後に発生するImportError
AWS Lambdaに google-generativeai をインストールしたLayerを紐付け、いざ実行すると以下のエラーが発生してLambdaが停止します。
ImportError: /lib64/libstdc++.so.6: version 'GLIBCXX_3.4.26' not found (required by /var/task/grpc/_cython/cygrpc.cpython-312-x86_64-linux-gnu.so)[環境] 発生時の構成
| ランタイム | Python 3.12 (Amazon Linux 2023) |
| 使用ライブラリ | google-generativeai / grpcio |
| デプロイ方式 | zip形式 (Lambda Layer) |
[原因] OS共有ライブラリのバージョン不整合
このエラーの根本原因は、Gemini SDKが依存している「gRPC」のバイナリが、Lambdaの標準実行環境（Amazon Linux 2023）にプリインストールされている libstdc++ よりも新しいバージョンを要求していることにあります。
通常、pipでインストールされるgRPCのビルド済みバイナリ（Wheel）は、特定のGLIBCXXバージョンを前提としています。しかし、Lambdaのランタイム環境はセキュリティと安定性の観点からOSライブラリが固定されており、ユーザーが /lib64/ 以下の共有ライブラリを直接更新することはできません。
[解決策] Dockerコンテナイメージによるデプロイへの移行
この問題を解決する最も確実な方法は、Lambda Layer (zip) 方式を諦め、Dockerコンテナイメージとしてデプロイすることです。コンテナ方式であれば、ビルド環境と実行環境を完全に一致させることができます。
1. Dockerfileの作成
AWS公式のLambdaベースイメージを使用します。これにより、ローカルでビルドしたバイナリがそのままLambda環境で動作することが保証されます。
FROM public.ecr.aws/lambda/python:3.12
# ライブラリのインストール
RUN pip install --no-cache-dir google-generativeai
# アプリケーションコードのコピー
COPY app.py .
# ハンドラの設定
CMD ["app.lambda_handler"]2. デプロイの手順
- 上記のDockerfileをビルドし、Amazon ECRにプッシュします。
- AWS Lambdaの管理画面から「関数の作成」→「コンテナイメージ」を選択します。
- プッシュしたECRイメージを指定して関数を作成します。
まとめ
Gemini APIやその他の高度なAIライブラリ（gRPC依存系）をAWS Lambdaで動かす際、zip形式のデプロイは共有ライブラリの壁にぶつかりやすいです。最初からDockerコンテナ形式を採用することで、環境差異による不毛なエラーを回避し、スムーズに開発を進めることができます。
