LightAccount（Alchemy）とは｜2026年に採用してよい条件とModular Account v2との使い分け

LightAccountは、Alchemy（米国のブロックチェーン開発基盤事業者）が公開している、監査済み・最小構成のERC-4337準拠スマートアカウント（コントラクトで実装するアカウント）です。結論から言うと、2026年8月時点でも「単一オーナーで、パスキーやセッションキーなどの機能拡張を使わない」用途なら本番採用に耐えます。この結論は、Quantstampによる2回の監査を経ていることと、Alchemyが現在も監査済み・本番対応のアカウントとして案内を続けていることに基づきます。なお、集計サイトBundleBearではAlchemy系factory（アカウントを決められた手順で量産デプロイする生成コントラクト）経由の累計デプロイが約1,374万件と追跡対象で最大ですが（BundleBear、2026年8月12日閲覧）、これはLightAccountを含むAlchemy系実装全体の累計値であり、LightAccount単体の稼働実績を示す数値ではありません。ただし、Alchemy自身の推奨アカウントはすでにModular Account v2（以下MAv2）へ移っており、EIP-7702（EOA＝秘密鍵で直接操作する従来型アカウントに、スマートアカウントの機能を委任する規格）の委任先としてAlchemyが提供するのもMAv2だけです（Alchemy: Choosing a Smart Account）。したがって2026年の新規案件では、LightAccountを「Alchemyの標準」として選ぶのではなく、要件が最小構成で足りると確認できた場合に限って選ぶのが妥当な判断です。

本記事は、この判断を自社で再現できるように、LightAccountの設計と現在の位置づけ、選ぶ条件と選ばない条件、Alchemyスタックで運用した場合の費用の実額構造、ロックインの実像と移行経路、実装前の確認点を、2026年8月時点の一次情報に基づいて整理します。前提となるERC-4337の全体構造（EntryPoint・Bundler・Smart Account）はERC-4337の事業者向け解説で、他社実装を含めた横比較はスマートコントラクトウォレットのスタック比較 2026で扱っているため、本記事はLightAccountの採用判断に集中します。

LightAccountの設計 — SimpleAccountから何を変えた実装か

LightAccountは、ERC-4337のリファレンス実装であるeth-infinitism（Ethereum Foundation系の開発チーム）のSimpleAccountを土台に、本番運用に必要な改良を加えた実装です（GitHub: alchemyplatform/light-account）。主な改良点は次の3つです。

• ストレージの名前空間分離（namespaced storage）：コントラクトの保存領域を専用の名前空間に隔離し、実装をアップグレードした際にデータ配置が衝突する事故を防ぎます。
• オーナー変更（transferOwnership）：アカウントの所有権を別の鍵や認証基盤へ移せます。特定の認証プロバイダに利用者が縛られないための仕組みです。
• ERC-1271対応：コントラクトアカウントとしての署名検証標準に対応し、ECDSA署名（秘密鍵による通常の署名）との切り替えができます。

アップグレードはUUPS方式（実装コントラクトを後から差し替えられるproxy構成）で、Soladyのライブラリを使って実装されています。ライセンスはGPL-3.0のオープンソースです。監査はQuantstampが2024年1月と2024年4月の2回実施しています（Alchemy: Light Account Docs）。

変種（variant）と対応するEntryPoint（ERC-4337の共通実行コントラクト）のバージョンは次のとおりです。

一方、LightAccountにないものを把握することが採用判断の中心になります。モジュール追加の仕組み（ERC-6900等）を持たないため、セッションキー（期限や権限を絞った一時鍵）、WebAuthn/パスキーによるログイン、支出上限などの権限管理は後から足せません。これらは意図的に削られており、その分だけコードが小さく、監査済みの範囲で挙動が固定されているのがLightAccountの価値です。

2026年時点の位置づけ — 公式推奨はModular Account v2へ、ただし廃止ではない

採用判断で最も重要な変化は、Alchemy自身の推奨がLightAccountからMAv2へ移ったことです。公式ドキュメントのアカウント選定ページは、MAv2を「最も機能が充実し効率的なスマートアカウント」として第一に推奨し、LightAccountは「その他のアカウント」の位置づけで、最小構成を優先する場合の選択肢として案内されています（Choosing a Smart Account、2026年8月12日閲覧）。

この変化は次の事実からも確認できます。

• 機能追加リリースの停止：LightAccountのGitHub上のリリースは2024年4月30日のv2.0.0が最新で、以降2026年8月時点まで新バージョンは出ていません（GitHub Releases）。リポジトリの保守自体は継続していますが、機能投資の対象はMAv2です。
• EIP-7702対応の非対称：AlchemyのWallet APIsではEIP-7702による委任が標準の動作モードになっており、委任先としてサポートされるコントラクトはMAv2のみです（How EIP-7702 works、2026年8月12日閲覧）。LightAccountはfactoryでデプロイする従来型のERC-4337アカウントであり、7702の委任先にはなりません。
• EntryPoint v0.8向け実装の不在：2025年3月に公開されたEntryPoint v0.8に対応するLightAccountのリリースは、2026年8月時点で存在しません。対応はv0.6とv0.7に限られます。

一方で、AlchemyはLightAccountの廃止や非推奨化を告知しておらず、監査済み・本番対応のアカウントとして案内を続けています。確認できる事実を整理すると、「最新リリースは2024年4月30日のv2.0.0」「公式Docsは監査済み・本番対応としての案内を継続」「アカウント選定ページ上は最小構成を優先する場合・後方互換のための選択肢という扱い」「EntryPoint v0.8向けリリースは不在」となります。これらを踏まえた本記事の評価としては、LightAccountは機能追加が事実上止まった安定実装——「終わった実装」ではなく「変化しない実装」——であり、新機能が必要になった時点でMAv2側にしか道がない、という非対称を理解した上で選ぶものと位置づけられます。

採用判断 — LightAccountを選ぶ条件、選ばない条件

判断の分岐は「軽さ」ではなく「要件が将来変わるかどうか」に置くのが実務的です。ガス効率はどちらも高水準で、MAv2はデプロイ10万gas未満とAlchemyが説明しているため（Modular Account V2 Overview）、ガスだけを理由にLightAccountを選ぶ状況はほぼありません。

LightAccountが合理的なのは、たとえば取引の実行主体が事業者側にあり、ユーザーごとのアカウントは資産の入れ物として最小限の機能で足りるケース（ポイント・NFT配布、B2B SaaSのバックエンド組み込みなど）です。逆に、コンシューマ向けウォレットのように認証手段やユーザー体験を継続的に改善していく前提のプロダクトでは、最初からモジュール機構を持つアカウントを選ぶ方が、後述する移行コストを払わずに済みます。

費用 — Alchemyスタックで運用した場合の実額構造

LightAccountをAlchemyのスタック（Bundler＝取引データを束ねてチェーンへ送る中継ノード、Gas Manager、SDK）で運用する場合、費用は3層に分かれます。金額はいずれも2026年8月12日閲覧時点の公表値です。

• API利用料（コンピュートユニット課金）：無料プランは月3,000万CU（コンピュートユニット：API呼び出しの計算量単位）まで。従量プラン（Pay-as-you-go）は最初の月3億CUまで100万CUあたり0.45ドル、超過分は0.40ドルです（Alchemy Pricing）。
• ガススポンサー手数料：Gas Manager（Alchemyのガス肩代わり基盤）でガス代を事業者負担にする場合、mainnetでは肩代わりしたガス代の8%が手数料として上乗せされます（従量プラン。無料プランはmainnetのスポンサー不可、testnetは全プラン無料。Gas Manager FAQs）。
• ガス実費：ERC-4337経由の取引はEntryPointでの検証・精算処理のぶんEOA直接送信よりガスを消費します。ウォレット開発元Ambireが自社実装で測定した例では、同一チェーン（Optimism）のUSDC送金1件あたり、EOA直接送信（ガスをETHで支払い）が約4.5万gas、ERC-4337でスポンサー（Gas Tank）経由が約13.3万gas、ERC-20トークンでガスを支払う構成が約14.0万gasでした（Ambire: ERC-4337 Gas Overhead Analysis、2026年4月28日公開）。これはAmbire実装での測定値でありLightAccount固有のベンチマークではありませんが、ERC-4337経由ではEOA直接送信の概ね3倍前後のガスを見込む、という規模感の目安になります。1取引あたりの実額は対象チェーンのgas priceとETH価格に依存するため、採用検討時は想定チェーンの実勢値で試算してください。

費用設計の実務では、「誰のガスをどこまで肩代わりし、どう回収するか」の設計が金額を左右します。負担類型と2026年時点の実勢データはガスレストランザクションの経済性で詳しく扱っています。

ロックインの実像 — コントラクト層は開いており、縛りはインフラ層に生じる

「Alchemy製のアカウントを使うとAlchemyに縛られるのか」という懸念には、層を分けて答える必要があります。

コントラクト層：標準準拠のオープンソースで、構造的なロックインはない

LightAccountはGPL-3.0で公開されたERC-4337標準準拠のコントラクトです。EntryPointはパブリックな共通コントラクトなので、デプロイ済みのLightAccountはAlchemy以外のBundler（Pimlico等）からも標準RPC（eth_sendUserOperation）で実行できます。オーナー権はtransferOwnershipで別の鍵や認証基盤へ移せるため、認証プロバイダの変更もアカウントを作り直さずに行えます。

注意点はUUPSアップグレード権限です。実装の差し替え権限はオーナーが持つため、これは「Alchemyから離脱する逃げ道」であると同時に、オーナー鍵が漏えいすると実装ごと差し替えられるリスクでもあります。オーナー鍵の管理体制（誰がどの環境で保管し、変更時に誰が承認するか）は、コントラクト選定と同じ重みで設計してください。

インフラ層：実際の移行コストはSDKとポリシー運用の再構築

実務でロックインとして効いてくるのは、Bundler・Gas Manager・SDKといったインフラ側です。Bundler RPC自体はERC-4337の標準メソッドなので切り替え可能ですが、Alchemy SDKの抽象（クライアント初期化、署名フロー、ガススポンサーの組み込み）を使い込んでいるほど、他社への切り替え時に書き換えが必要になります。また、Gas Managerのスポンサーポリシー（対象コントラクト・回数・期間の条件設定）やダッシュボードでの運用手順は他社に持ち出せないため、同等のポリシーを移行先で再構築することになります。

まとめると、資産の入れ物であるアカウントを維持したままインフラだけを替えられるのがERC-4337標準準拠の利点であり、LightAccountを選んでもコントラクト層の退路は確保されています。切り替えコストを最小にしたい場合は、SDKの抽象へ依存する箇所を自社コード側で薄くラップしておくのが実務的な対策です。

実装前に確認する4点

• EntryPointバージョンの整合：LightAccount v1.1.0はEntryPoint v0.6、v2.0.0はv0.7に対応します。利用するBundlerが対応するEntryPointと、アカウント側の対応バージョンを最初に揃えてください。v0.8向けのLightAccountは2026年8月時点で存在しません。
• アドレスの決定性とfactoryの固定：アカウントアドレスはfactoryとsalt（生成時の識別値）から決定的に導出されます。複数チェーンで同一アドレスを使う設計なら、factoryのアドレスと初期化パラメータを全チェーンで固定する必要があります。
• オーナー変更の運用手順：transferOwnershipは資産の支配権そのものを移す操作です。移転先アドレスの検証、移転実行、移転後の動作確認までを手順化してから本番運用に入れてください。
• ガススポンサーの開放範囲：Gas Managerのポリシーは対象コントラクト・回数・期間を最小から始め、不正利用による予算超過を防ぐ設計にします。具体的な攻撃類型と対策はガスレスの経済性で扱っています。

よくある質問

すでにLightAccountで本番運用しています。Modular Account v2へ移行すべきですか？

直ちに移行する必要はありません。LightAccountはQuantstampの監査を経た安定実装で、対応するEntryPoint v0.6/v0.7は2026年8月時点で稼働を続けており、Alchemyも廃止を告知していません。移行を検討するのは、パスキーやセッションキーなどモジュール機能の要件が実際に生じたとき、またはEntryPoint v0.8以降への追従が必要になったときです。移行方法は既存アカウントの実装差し替え（UUPS方式のため技術的には可能ですが、ストレージ互換性の検証が前提です）か、新アカウント発行と資産移動のどちらかになり、いずれもユーザー影響の評価が必要です。

MultiOwnerLightAccountはどのような場合に使いますか？

単一鍵の紛失・漏えいに備えて、復旧用の第二オーナー（別デバイスの鍵や事業者側の鍵）を置きたい場合に使います。各オーナーは他オーナーの追加・削除を含む完全な権限を持つため、「一定額以上は複数承認」のような権限分離はできません。承認フローや支出上限が必要な場合は、MAv2のモジュール（multisig等）が対象になります。対応EntryPointはv0.7のみです。

関連記事

前提と全体像：

• アカウントアブストラクション（AA）完全マップ 2026 — AA全体の俯瞰と採用形態の判断軸
• ERC-4337の事業者向け解説 — EntryPoint・Bundler・Paymaster・Smart Accountの役割分担
• EIP-7702の事業者向け解説 — 既存EOAをスマート化する補完規格

比較・選定：

• スマートコントラクトウォレットのスタック比較 2026 — Safe・Kernel・Biconomy Nexus・Base Accountを含む横比較
• AA開発スタックの選定 — Bundler・Paymaster・SDKの組み合わせ比較
• Kernel（ZeroDev）の採用判断 — モジュール型の代表実装
• ガスレストランザクションの経済性 — ガス負担の類型と費用実勢

XTELAが支援できる範囲

スマートアカウントの選定は、認証手段・権限管理・移行可能性・費用の4点を自社要件に落とし込めれば大きく外しません。XTELAは、要件整理からLightAccount/MAv2/他社実装の比較選定、PoC実装、ガス費用の試算、既存アカウントからの移行設計まで、Web3サービスの技術面を支援しています。

スマートアカウント選定について相談する

主要参考資料

• ERC-4337: Account Abstraction Using Alt Mempool
• EIP-7702: Set Code for EOAs
• GitHub: alchemyplatform/light-account（GPL-3.0）
• GitHub: light-account Releases（v2.0.0、2024年4月30日）
• Alchemy: Light Account Docs（2026年8月12日閲覧）
• Alchemy: Choosing a Smart Account（2026年8月12日閲覧）
• Alchemy: Modular Account V2 Overview（2026年8月12日閲覧）
• Alchemy: How EIP-7702 works（2026年8月12日閲覧）
• Alchemy: Gas Manager FAQs（2026年8月12日閲覧）
• Alchemy: Pricing（2026年8月12日閲覧）
• BundleBear: Account Factory統計（2026年8月12日閲覧）
• Ambire: Is ERC-4337 Really Bloated? Real World Gas Analysis（2026年4月28日）

本記事の前提

本記事は2026年8月12日時点で確認した一次情報に基づく技術・事業設計上の論点整理であり、投資助言・法的助言ではありません。各社の料金、対応チェーン、実装のバージョン、利用統計は今後変わり得ます。採用判断の際は最新の公式ドキュメントを確認してください。