AWS Lambda + DockerでLibreOffice実行：10GB時代の文書変換新時代

Posted at 2025-10-30

はじめに

「AWS Lambdaって軽量でシンプルな処理専用でしょ？」

そんな従来の常識が、今では通用しません。2020年のコンテナサポート開始と制限の大幅緩和により、LibreOfficeのような重いアプリケーションも実用レベルで動作する時代になりました。

本記事では、実際の導入事例を基に、AWS LambdaでのLibreOffice実行がどう進化してきたかを解説します。

AWS Lambdaの劇的な進化

かつての制約（2020年以前）

項目	制限値
メモリ	最大3GB
デプロイパッケージ	250MB
エフェメラルストレージ（/tmp）	512MB
実行時間	最大15分

現在の制限（2025年時点）

項目	制限値	変更倍率
メモリ	最大10,240MB（10GB） 🚀	約3.3倍
コンテナイメージ	最大10GB 🚀	約40倍
エフェメラルストレージ	最大10GB 🚀	約20倍
実行時間	最大15分	変更なし

この約40倍の容量拡張により、従来は不可能だった処理が現実的になりました。

実装アプローチの変遷：実体験から学ぶ

第1世代：Lambda Layerアプローチ（～2020年）

当時の開発者が直面した課題

サイズ制約との格闘
- LibreOffice本体（約360MB）vs Lambda制限（250MB）
- 複雑な圧縮・ストリッピング作業が必要
パフォーマンス問題
- 実行時の展開処理で10秒の遅延
- 1,200MBものメモリ消費
日本語フォントの悪夢
- Amazon Linux 2環境での日本語フォント対応は困難
- 複雑なfont-cache生成処理が必要

実装例（当時）

# 圧縮されたLibreOfficeを実行時に展開
curl -L https://github.com/.../lo.tar.gz -o /tmp/lo.tar.gz
cd /tmp && tar -xf lo.tar.gz

# 日本語フォント用のfont-cache生成
mkdir -p /tmp/cache/fontconfig
fc-cache /tmp/.fonts

第2世代：Dockerコンテナアプローチ（2020年～）

解決された課題

✅ サイズ制約：10GBまで対応可能
✅ パフォーマンス：初回30秒、以降3秒で安定
✅ メモリ効率：400MB程度に大幅削減
✅ 日本語フォント：完全解決

日本語フォント問題の完全解決

従来の課題

「LibreOfficeはOSのフォントを参照します。
Lambdaのランタイムには当然載っていません。」
（実体験記事より）

Docker方式での解決

# 日本語フォントを事前インストール
RUN yum -y install ipa-gothic-fonts ipa-mincho-fonts \
    ipa-pgothic-fonts ipa-pmincho-fonts

解決のポイント

実行時の動的フォント処理が不要
ローカル環境との表示結果が一致
複雑なfont-cache生成処理が不要

詳細な実装例

Debian/Ubuntu系

# 日本語フォントのインストール
RUN apt-get install -y --no-install-recommends fonts-noto-cjk
RUN fc-cache -fv

現在の実装パターン

パターン1：フルカスタムDocker実装

FROM public.ecr.aws/lambda/python:3.8

# 基本パッケージ
RUN yum -y install wget tar gzip

# 日本語フォント
RUN yum -y install ipa-gothic-fonts ipa-mincho-fonts \
    ipa-pgothic-fonts ipa-pmincho-fonts

# LibreOfficeのダウンロード・インストール
RUN wget [LibreOfficeのURL]
RUN tar -xzf [ファイル名]
RUN yum -y localinstall *.rpm

COPY app.py ${LAMBDA_TASK_ROOT}
CMD [ "app.handler" ]

メリット

✅ 完全にカスタマイズ可能
✅ 最小限のリソース使用（メモリ400MB程度）
✅ 長期運用でのコスト最適化

デメリット

❌ メンテナンス負荷が高い
❌ 初期構築の複雑さ

パターン2：コミュニティライブラリ（@shelf/aws-lambda-libreoffice）

FROM public.ecr.aws/shelf/lambda-libreoffice-base:7.6-node20-x86_64
COPY ./ ${LAMBDA_TASK_ROOT}/
CMD [ "handler.handler" ]

import {convertTo} from '@shelf/aws-lambda-libreoffice';

export const handler = async () => {
    return convertTo('document.docx', 'pdf');
};

メリット

✅ LibreOffice 7.6ベース（最新）
✅ CJKフォント対応済み
✅ TypeScript対応
✅ 実装が最も簡単

デメリット

❌ リソース消費が大きい（3GB以上）
❌ カスタマイズの自由度が低い

パフォーマンス比較

アプローチ	初回実行時間	2回目以降	メモリ使用量	推奨設定メモリ	日本語対応	実装難易度
Lambda Layer（旧方式）	10秒	3-5秒	1,200MB	1,500MB	困難	高
カスタムDocker	30秒	3秒	400MB	512MB-1GB	要設定	中
@shelf/aws-lambda-libreoffice	45秒以上	不明	不明	3,008MB以上	対応済み	最低

注意事項

初回実行（コールドスタート）は全ての方式で時間がかかる
ウォームアップ後は大幅に改善される
サードパーティライブラリはリソース消費が大きい

コスト試算

参考値（実体験記事より）

100万ドキュメント変換: 約150ドル
主要コスト要因: Lambda実行時間
備考: S3コストの方が高くなる場合もある

従来サーバー運用との比較

サーバー維持費用が不要
使用時のみ課金
ピークタイム対応のスケーリングが自動

Lambdaの適用範囲拡大

従来：軽量処理専用

APIエンドポイント
簡単なデータ変換
イベント処理

現在：重い処理も対応

✅ ドキュメント変換（LibreOffice）
✅ 機械学習推論
✅ メディア処理・変換
✅ ETLジョブ
✅ 財務計算

設計思想の変化

従来: 「軽量・高頻度・短時間」専用
現在: 「軽量から重量まで・必要時のみ・中程度実行時間」対応

なぜこの進化が重要なのか

サーバーレスの適用範囲拡大
従来はEC2やECSが必要だった処理も、Lambdaで「使った分だけ課金」で実現可能
運用負荷の削減
LibreOfficeをサーバで動かす場合の「ゾンビプロセス」や「メモリリーク」の問題が解消
コスト効率
100万ドキュメントあたり約150ドルという破格のコスト実現

まとめ

AWS Lambdaは「シンプルな処理専用」から「サーバーレスで実行できるあらゆる処理」へと大きく進化しました。

現在の状況

LibreOfficeのような重いアプリケーションが実用レベルで動作
日本語フォント問題も完全解決
運用負荷とコストの大幅削減を実現

今後の検討指針
多くの企業が「まずはLambdaで検討し、制約に当たったら他のサービス」という設計アプローチを採用する時代になっています。

従来サーバーで運用していた文書変換処理も、Lambda + Docker方式への移行を真剣に検討すべき時期が来ているのではないでしょうか。

実装選択の指針

用途	おすすめアプローチ	理由
プロトタイプ・検証	@shelf/aws-lambda-libreoffice	開発速度最優先
本格運用・コスト重視	カスタムDocker	リソース効率最優先
中規模運用	要件に応じて選択	バランス重視