論文概要（Abstract）
本論文は、LLMが生成したコードをFunction-as-a-Service（FaaS）プラットフォーム上で自動的にデプロイ・実行するフレームワーク「LLM4FaaS」を提案している。著者らによると、LLMは自然言語からのコード生成能力に優れるものの、生成コードの実行環境の構築・デプロイは依然として技術的障壁が高い。FaaSの高い抽象度を活用することで、この障壁を解消し、非技術ユーザーでもカスタムアプリケーションを構築できる仕組みを実現している。評価実験では、LLM4FaaSが71.47%の自動デプロイ成功率を達成し、FaaSを使わないベースライン（43.48%）および既存LLMプラットフォーム（14.55%）を大幅に上回ったと報告されている。
本記事は Zenn記事: Malleable Softwareとは何か——LLM時代の動的ソフトウェアとその実現要件 の深掘り記事です。元論文は arXiv:2502.14450 で公開されています。
情報源
- arXiv ID: 2502.14450
- URL: https://arxiv.org/abs/2502.14450
- 著者: Minghe Wang, Tobias Pfandzelter, Trever Schirmer, David Bermbach
- 発表年: 2025年（IEEE/ACM 18th International Conference on Utility and Cloud Computing, UCC 2025に採択）
- 分野: cs.SE（Software Engineering）, cs.DC（Distributed Computing）
背景と動機（Background & Motivation）
LLMの進化により、自然言語からコードを生成する能力は飛躍的に向上した。しかし、著者らが指摘する重要な問題がある。コードを生成できることと、そのコードを実行・デプロイできることは別の課題である。
非技術ユーザーがLLMでコードを生成できたとしても、以下の技術的障壁が残る。
- サーバー管理: 生成コードを実行するためのサーバー環境の構築
- 依存関係の解決: ライブラリのインストール・バージョン管理
- デプロイメント: コードのパッケージング・公開・運用
- コマンドライン操作: ターミナル操作は非技術ユーザーにとって高い障壁
この問題は、Malleable Softwareの文脈で重要である。Zenn記事で紹介されているVibe codingやSoftware for Oneの概念は、非技術ユーザーがソフトウェアを自作できる可能性を示唆するが、「作ったコードを動かす」ステップが欠落している。LLM4FaaSは、この「ラストマイル問題」に対する技術的解決策を提案している。
主要な貢献（Key Contributions）
- 貢献1: LLMが生成したコードをFaaSプラットフォーム上で自動的にデプロイするエンドツーエンドのパイプラインの設計と実装
- 貢献2: 自動デプロイ成功率71.47%の達成。非FaaSベースライン（43.48%）の1.64倍、既存プラットフォーム（14.55%）の4.91倍の性能向上
- 貢献3: デプロイ失敗の原因分析と、LLM生成コードの自動修正メカニズムの提案
技術的詳細（Technical Details）
アーキテクチャ
LLM4FaaSのアーキテクチャは、以下の4段階パイプラインで構成される。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
┌─────────────────────────────────────────────────────┐
│ LLM4FaaS Pipeline │
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ Step 1 │ │ Step 2 │ │ Step 3 │ │
│ │ NL→Code │──>│ Code→ │──>│ Package │ │
│ │Generation│ │Validation│ │ & Deploy │ │
│ └──────────┘ └──────────┘ └──────────┘ │
│ │ │ │
│ ▼ ▼ │
│ ┌──────────┐ ┌──────────┐ │
│ │ Step 2b │ │ Step 4 │ │
│ │ Auto-Fix │ │ Test & │ │
│ │ (Retry) │ │ Verify │ │
│ └──────────┘ └──────────┘ │
└─────────────────────────────────────────────────────┘
Step 1: 自然言語→コード生成: ユーザーの自然言語による要求をLLMがFaaS互換のコードに変換する。FaaS関数は通常、HTTPリクエストを受け取り、レスポンスを返す単一関数の形式をとるため、LLMの生成対象が明確に制約される。
Step 2: コード検証: 生成されたコードの構文チェック、依存関係の解析、FaaS関数としての形式的正しさを検証する。
Step 3: パッケージング＆デプロイ: 依存関係を含むデプロイパッケージを自動生成し、FaaSプラットフォームにデプロイする。
Step 4: テスト＆検証: デプロイされた関数に対してテストリクエストを送信し、期待通りの動作を確認する。
FaaSの利点
著者らは、FaaSプラットフォームが非技術ユーザー向けのコード実行基盤として適している理由を以下のように論じている。
\[\text{Deployment Complexity}_{\text{FaaS}} \ll \text{Deployment Complexity}_{\text{Traditional}}\]FaaSの主要な利点を以下に整理する。
| 観点 | 従来型デプロイ | FaaSデプロイ |
|---|---|---|
| サーバー管理 | 必要（OS設定、パッチ適用） | 不要 |
| スケーリング | 手動設定が必要 | 自動スケーリング |
| 課金モデル | 常時稼働コスト | 実行時間のみ課金 |
| デプロイ操作 | CLI / CI/CD設定が必要 | API呼び出し1回 |
| 依存関係 | 手動インストール | レイヤー/パッケージで自動 |
自動修正メカニズム
デプロイが失敗した場合、LLM4FaaSはエラーメッセージをLLMにフィードバックし、コードの自動修正を試みる。著者らはこの「フィードバックループ」が成功率の向上に寄与したと報告している。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
async def deploy_with_retry(
user_request: str,
llm_client: LLMClient,
faas_platform: FaaSPlatform,
max_retries: int = 3,
) -> DeployResult:
"""自動修正付きデプロイパイプライン
Args:
user_request: ユーザーの自然言語リクエスト
llm_client: LLMクライアント
faas_platform: FaaSプラットフォーム
max_retries: 最大リトライ回数
"""
code = await llm_client.generate_code(user_request)
for attempt in range(max_retries):
# デプロイ試行
result = await faas_platform.deploy(code)
if result.success:
return DeployResult(
success=True,
url=result.endpoint_url,
attempts=attempt + 1,
)
# エラーフィードバックによる自動修正
error_context = f"Error: {result.error}\nCode: {code}"
code = await llm_client.fix_code(error_context)
return DeployResult(success=False, attempts=max_retries)
実験結果（Results）
デプロイ成功率の比較
著者らは3つの条件で評価を実施したと報告している。
| 条件 | デプロイ成功率 | 説明 |
|---|---|---|
| LLM4FaaS | 71.47% | FaaS + 自動修正パイプライン |
| 非FaaSベースライン | 43.48% | LLM生成コードをローカル実行 |
| 既存LLMプラットフォーム | 14.55% | ChatGPT等のコード実行機能 |
著者らによると、LLM4FaaSの成功率向上の主要因は、(1) FaaSの単純化されたデプロイモデル、(2) エラーフィードバックによる自動修正、(3) 依存関係の自動解決、の3点である。
失敗原因の分析
論文では、デプロイ失敗の28.53%の原因を以下のように分類している。
- 依存関係エラー: 約40%。LLMが存在しないライブラリやバージョンを指定するケース
- ランタイムエラー: 約30%。コードの論理的誤りによる実行時エラー
- タイムアウト: 約15%。FaaS関数のタイムアウト制限を超過
- 形式エラー: 約15%。FaaS関数として不正な形式のコード
実装のポイント（Implementation）
LLM4FaaSの実装において重要なポイントを以下に整理する。
FaaS関数テンプレートの活用: LLMに対するプロンプトにFaaS関数のテンプレートを含めることで、生成コードの形式的正しさを向上させる。
依存関係の明示的宣言: requirements.txtやpackage.jsonの自動生成をパイプラインに含める。LLMは依存関係の宣言を忘れがちであるため、コード分析による依存関係の自動抽出機能が重要である。
エラーメッセージの構造化: LLMにフィードバックするエラーメッセージは、エラー種別・発生箇所・スタックトレースを構造化した形式で提供すると、修正精度が向上すると著者らは報告している。
実運用への応用（Practical Applications）
Malleable Softwareとの関連
本論文の最大の意義は、Malleable Softwareの「ラストマイル問題」に対する技術的解決策を提示している点にある。Zenn記事で紹介されているVibe codingは「コードを作る」部分に焦点を当てているが、LLM4FaaSは「作ったコードを動かす」部分を自動化する。
この2つを組み合わせることで、非技術ユーザーが「自然言語で指示 → コード生成 → 自動デプロイ → 動作確認」の一連のフローを完結できる可能性がある。
Software for Oneへの適用
Kevin Rooseが提唱する「Software for One」の概念では、個人用のソフトウェアを手軽に作成できることが重要である。FaaSの従量課金モデルは、利用頻度の低い個人用ツールのホスティングに適しており、LLM4FaaSのアプローチはSoftware for Oneの実現基盤として有望である。
関連研究（Related Work）
- GPT-Engineer: LLMを使ったプロジェクト全体の自動生成ツール。LLM4FaaSとの違いは、GPT-Engineerがローカル実行を前提とするのに対し、LLM4FaaSはクラウドデプロイまでを自動化している点
- Replit / Bolt: WebベースのVibe codingプラットフォーム。LLM4FaaSはFaaS特化の設計により、APIバックエンド等のサーバーサイド機能の自動デプロイに強みを持つ
- AWS Lambda / Google Cloud Functions: FaaSプラットフォームの代表例。LLM4FaaSはこれらのプラットフォーム上で動作し、プラットフォーム固有のデプロイ作業を抽象化している
まとめと今後の展望
LLM4FaaSは、LLM生成コードの自動デプロイという「ラストマイル問題」に対して、FaaSの高い抽象度を活用した解決策を提示した研究である。71.47%の自動デプロイ成功率は、非技術ユーザーによるソフトウェア開発の実現可能性を示している。
Malleable Softwareの文脈では、LLM4FaaSのアプローチは、ユーザーがカスタマイズしたソフトウェアを即座にデプロイ・実行できるインフラ層として位置づけられる。Zenn記事で紹介されているInk & Switchの「Gentle Slope」パターンの最終段階——ユーザーが修正したコードを実際に動作させる——を技術的に支える仕組みとして注目に値する。
今後の課題として、セキュリティ（生成コードの安全性検証）、マルチ関数の連携（複数FaaS関数の自動オーケストレーション）、コスト最適化（不要な関数の自動削除）が挙げられる。
参考文献
- arXiv: https://arxiv.org/abs/2502.14450
- 会議: IEEE/ACM 18th International Conference on Utility and Cloud Computing (UCC 2025)
- Related Zenn article: https://zenn.dev/0h_n0/articles/c0712fa2cd13b2