Fragments を採用する前に読む、E2B サンドボックスと Next.js 14 の境界線

Fragments が埋めるのは「生成」と「実行」の間の隙間

LLM にコードを書かせる部分は、今やどのプロバイダの API でも数行で済む。難しいのはその次で、生成された Python や Next.js のコードを、ホスト環境を壊さずに動かし、結果を UI に返すところだ。Fragments はこの後半部分を引き受けるテンプレートである。README は Anthropic の Claude Artifacts、Vercel の v0、GPT Engineer を例に挙げ、それらと同種のアプリをオープンソースで組むための土台だと説明している。対象読者は、チャット UI とコード実行を自前で持たないと業務に組み込めない開発者だ。SaaS のコード生成ツールでは、生成物を社内のデータや npm パッケージに触らせられない。Fragments はその境界を自分で引けるようにする。

実行はサンドボックス、UI はストリーミングという役割分担

構成は Next.js 14 の App Router と Server Actions を軸に、shadcn/ui と TailwindCSS で画面を作り、Vercel AI SDK でモデル出力を受け取る。生成コードの実行は E2B SDK が担当し、README はこれを「AI が生成したコードを安全に実行する」ためのものと位置づけている。データの流れは素直だ。ユーザーの指示が LLM に渡り、返ってきたコードが E2B のサンドボックスに送られ、実行結果がストリーミングで UI に戻る。npm と pip のパッケージをインストールできると README にあり、Python インタプリタ、Next.js、Vue.js、Streamlit、Gradio のスタックが同梱されている。ここで効くのはペルソナという概念で、lib/templates.json に「どの依存関係を入れたサンドボックスを、どのファイル名で、どのポートで起動するか」を宣言する。LLM への追加指示もこのファイルに書ける。実行環境の定義がコードではなく設定ファイルに寄っている点は、レビューしやすさの面で素直な設計だ。

起動までの手順と、環境変数で決まる機能の有効範囲

README の手順は git clone の後、cd fragments、npm i、.env.local の作成、npm run dev という流れになる。必須は E2B_API_KEY と、利用する LLM プロバイダのキー（OPENAI_API_KEY、ANTHROPIC_API_KEY、GROQ_API_KEY、FIREWORKS_API_KEY、TOGETHER_API_KEY、GOOGLE_AI_API_KEY、MISTRAL_API_KEY、XAI_API_KEY など）だ。任意の変数が機能の境界を決めている点は見落としやすい。KV_REST_API_URL と KV_REST_API_TOKEN を入れると短縮 URL とレート制限が有効になり、SUPABASE_URL と SUPABASE_ANON_KEY で認証、NEXT_PUBLIC_POSTHOG_KEY で解析が乗る。逆に NEXT_PUBLIC_NO_API_KEY_INPUT や NEXT_PUBLIC_NO_BASE_URL_INPUT をコメント解除すると、チャット画面からユーザーが自分のキーやベース URL を入力する欄が消える。NEXT_PUBLIC_HIDE_LOCAL_MODELS はローカルモデルを一覧から隠す。自前のサービスとして公開するなら、この3つを有効にして入力を閉じるのが自然な運用だろう。レート制限は RATE_LIMIT_MAX_REQUESTS と RATE_LIMIT_WINDOW で調整する。

ペルソナ追加は E2B CLI に依存する

対応スタックを増やす手順は README に具体的に書かれている。E2B CLI をインストールしてログインし、sandbox-templates/ 配下にフォルダを作り、e2b template init で e2b.Dockerfile を生成する。Dockerfile を編集したら e2b.toml に start_cmd を書き、e2b template build --name <template-name> でビルドする。README の例では Streamlit 向けに python:3.19-slim をベースにし、start_cmd は cd /home/user && streamlit run app.py となっている。ビルド完了後、lib/templates.json にキー、name、lib の依存配列、file、instructions、port を登録する。ここで注意したいのは、この手順が E2B CLI と E2B 側のビルド環境に強く依存していることだ。サンドボックスのイメージ管理はリポジトリ内で完結せず、外部サービス側の成果物として存在する。CI に組み込むなら e2b template build をどこで走らせるかを先に決めておく必要がある。

プロバイダ追加の実装は createOpenAI の互換レイヤー

LLM プロバイダの追加は lib/models.ts の providerConfigs にエントリを足す。README の Fireworks の例では createOpenAI に apiKey と baseURL（https://api.fireworks.ai/inference/v1）を渡す形になっており、OpenAI 互換のエンドポイントを前提とした抽象化だと分かる。構造化出力の既定モードは getDefaultMode 関数で分岐させ、Fireworks なら 'json' を返す例が示されている。モデル自体の追加は lib/models.json（本文中では lib/models.ts へのリンクと併記されている）に id、name、provider、providerId を並べる。ロゴは public/thirdparty/logos に置く。OpenAI 互換でない API を持つプロバイダを足す場合は、この互換レイヤーに合わせるための変換コードを自分で書くことになる。README はそこまでは示していない。

サンドボックス前提が合わないケース

Fragments の中心は E2B サンドボックスであり、これは外部サービスだ。生成コードを自社ネットワークの外に出せない規制下の案件では、この構成自体が成立しない。E2B を自前のコンテナ実行基盤に差し替えることは理論上可能だが、README にその手順はなく、Server Actions からサンドボックスを呼ぶ部分を書き直す作業になる。もうひとつの制約は生成物の性質で、対応スタックが Python インタプリタ、Next.js、Vue.js、Streamlit、Gradio に限られる。ネイティブビルドや GPU を使うワークロードは、ペルソナを自作しても E2B 側のイメージ制約に当たる。Morph の Apply モデルによるコード編集連携は既定で有効と README にあり、MORPH_API_KEY を設定する形になっている。この連携を外したい場合の手順は README には書かれていないので、依存を減らしたいチームは該当コードを読んで判断する必要がある。

比較対象としての OpenHands と、設計思想の違い

同じ「AI にコードを書かせて実行する」領域には OpenHands（旧 OpenDevin）がある。こちらはエージェントがシェルやファイルシステムを操作してタスクを完遂することを主目的にした環境で、利用者はゴールを渡す。Fragments は逆で、生成されたコードそのものを成果物として画面に表示し、ユーザーがコピーしたりプレビューしたりする体験を設計の中心に置く。Claude Artifacts や v0 に近い。つまり Fragments は「コードを見せるアプリ」を作るためのテンプレートであって、バックグラウンドで長時間動くエージェントを組むためのフレームワークではない。どちらを選ぶかは、成果物が人間の目に触れるかどうかで決まる。

ライセンスと保守の見積もり

ライセンスは Apache-2.0 で、改変と再配布、商用利用が可能な条項を含む。ただしこれは Fragments のコードに対するもので、E2B API と各 LLM プロバイダの利用は別契約になる。README は E2B の API キー取得と MORPH_API_KEY（既定で有効）を前提にしており、これら外部依存の料金と可用性はリポジトリの管理外だ。保守の観点では、依存が Next.js 14、Vercel AI SDK、shadcn/ui、TailwindCSS と更新の速い層に集中している。プロバイダ追加が createOpenAI の互換レイヤーに乗っているため、上流の AI SDK がインターフェースを変えたときの影響は lib/models.ts に集約される。逆に E2B のテンプレート仕様が変われば sandbox-templates/ と e2b.toml の両方に手が入る。リリースは取得できておらず、バージョン番号による追跡はできない。導入時は main ブランチのコミットを固定してから始めるのが現実的だ。

編集部の結論

自前のコード生成 UI を持ちたいが、実行環境の分離まで作りたくないチームには向いている。逆に、生成コードを自社インフラ内だけで完結させたい、あるいは E2B 以外の実行基盤をすでに持っている場合は、サンドボックス層がまるごと置き換え対象になるため採用理由が薄い。導入前に確認すべきは、lib/templates.json に定義されたペルソナと自社ユースケースの対応、および E2B テンプレートのビルド手順が CI に組み込めるかどうかの2点。Apache-2.0 なので改変と再配布は可能だが、E2B の API キーと LLM プロバイダの課金は別契約として乗る。

公式情報源

1. e2b-dev/fragments on GitHub
2. Issues
3. License: Apache-2.0
4. Project website
5. README