モジュラーアカウントアブストラクションとは
執筆者 Logan Ross
Modular AAは、モジュール化されたスマートアカウントの普及を目指すムーブメントです。目標は、アカウントをユーザーがカスタマイズできるようにし、開発者が文脈に応じた自己完結型のアカウント機能を構築できるようにすることです。
モジュール式スマートコントラクトアカウント(SCA)により、ビルダーはアカウントへの便利な新しい拡張機能を作成できます。例としては以下が挙げられます。
- ソーシャルリカバリー - 信頼できるデバイスや友人がアカウントへのアクセスを失った際の復旧を助けられるようにする機能
- 利用限度額 - アプリが指定された限度額までユーザーに代わってトークンを使用できるようにする機能
- パスキー対応 - FaceIDなどの生体認証でログインできる機能
モジュール性を標準化することで、カウンターパーティリスクを大幅に削減でき、シンプルで安全なweb3ユーザー体験につながります。
ERC-4337標準は、実装することでユーザーが秘密鍵ではなくスマートコントラクトを主要なアカウントタイプとして持てるようにするインフラストラクチャコンポーネントとコーディング規格を定めています。従来、主要なアカウントタイプはEOA(エンドユーザーアカウント)でしたが、これはSCAとは異なりカスタムの検証・実行ロジックを持ちません。
この記事では、モジュラーアカウント抽象化の概要、それが可能にすること、既存の標準と実装について説明します。
モジュール式スマートアカウントウォレットを埋め込むことで、シードフレーズもガスも不要なオンボーディングをweb3アプリに実現し、垂直統合されたAAインフラストラクチャでスケールできます。
モジュール式スマートコントラクトアカウントにはどのような種類があるか
スマートコントラクトアカウントは本質的にはスマートコントラクトであり、アップグレード可能、拡張可能、そして継承可能です。SCAの実装によって、プラグイン/モジュールの追加を許可するかどうかが異なります。この記事で扱うモジュラーAAの2つの概念は、ERC-6900とSAFE Modulesです。
1. ERC-6900: モジュール式スマートコントラクトアカウントとプラグイン
ERC-6900の目的は、標準的なAccountとModuleの実装間のインターフェースセットを定義することです。この提案は、アカウント実装間を切り替える際の開発者体験、Moduleの相互運用性、データポータビリティの向上を目指しています。
この標準はERC-2535にインスパイアされていますが、開発者にDiamondパターンに従うことを要求しません。
モジュール式スマートコントラクトアカウント向けのERC-6900プラグインとは何か
ERC-6900が定義するプラグインの種類とは
この標準によると、プラグインは3種類に分類されます。
- 検証スキーム - モジュール式スマートコントラクトアカウント(MSCA)がトランザクションを代理承認する条件を定義する
- 実行ロジック - 実行時に処理される任意のロジック
- フック - ユーザーオペレーションの実行前後に実行される任意のロジックをトリガーできる

この標準はさらに以下を定義しています。
- MSCA向けのValidation、Execution、Hookプラグインの実装方法
- 準拠したアカウント実装がプラグインを追加、削除、更新、検査する方法
- FunctionReferenceのようなヘルパー型

ERC-6900が定義するインターフェースの種類とは
ERC-6900仕様は、IPluginUpdate、IPluginLoupe、IStandardExecutorという3つの主要なインターフェースを定義しています。
1. IPluginUpdate
IPluginUpdateインターフェースは以下を定義します。
- プラグインアクションADD、REMOVE、REPLACE
- Validatorの種類とHookの種類
- 各種プラグインタイプを更新するためのユーザー定義struct
- プラグイン更新時に呼び出される標準化されたupdatePlugins関数と、更新後に発行されるExecutionPluginUpdateイベント
2. IPluginLoupe
IPluginLoupeはERC-2535にインスパイアされており、ERC-6900はdappや他のコントラクトがMSCAがサポートするプラグインを読み取る方法を定義しています。
3. IStandardExecutor
IStandardExecutorは、オープンエンドな実行を可能にするために、モジュール式スマートコントラクトアカウントが実装すべきインターフェースです。
2. SAFE modules
すべてのSAFEベースのアカウントはSAFE Modulesをサポートしています。高いセキュリティ基準を維持するため、SAFEチームは関心の分離パターンに従い、異なるモジュールタイプを実装しました。
- Modules - Safeスマートアカウントの名義でトランザクションを実行できるホワイトリスト化されたアドレス
- Guard - 実行されるトランザクションに対して追加のチェックを行うために設定できるコントラクト
- Fallback Handler - 任意の受信(読み取り)コールを処理するために設定できるコントラクト
詳細はSafeのモジュール式SCAアーキテクチャに関する記事を参照してください。
SAFE SCA Modulesとは何か
SAFEのModulesは、ユーザーのSAFEスマートコントラクトアカウント上でトランザクションを実行する権限を持つ個々のスマートコントラクトです。ModulesはexecTransactionFromModule関数を通じてSAFEアカウント上で任意のトランザクションを実行できます。SAFEアカウントの実装方法はSAFEチームが決定するため、プラグイン開発者はそのルールとガイドラインに従う必要があります。SAFE modulesは_SAFEアカウントとのみ互換性があります_。
モジュール開発者とユーザーの間には大きな信頼の前提があるため、実戦で検証されたmodulesほど採用され続ける可能性が高くなります。

SAFE SCA Guardsとは何か
Guardsは、受信するトランザクションに対して追加のセキュリティチェックを行うためにSAFEアカウントに設定できるスマートコントラクトです。トランザクションの実行前に、Guardはすべてのトランザクションパラメータとともに呼び出され、Guardがrevertしなければトランザクションは実行に進みます。
Guardは実行後にも再度呼び出され、状態変化のチェックや任意のロジックの実行を行います。
Guardsはトランザクション実行前後の状態チェックに適していることから、フックとしても捉えられます。

SAFE SCA Fallback Handlerとは何か
Fallback Handlerは、SAFEアカウントに対して行われるすべてのコールのうち、それが処理可能なものを実行します。これは、コントラクト署名(EIP-1271)のような業界標準への準拠に役立ちます。SAFEによれば、「プラグインはコアのSAFEコントラクトから完全に独立しており、それぞれ独自のストレージを保持する」とのことです。

結論
ERC-6900で説明され、Safe Modulesによって設計されたモジュラーアカウント抽象化は、開発者が構築でき、スマートコントラクトウォレットのユーザーが安全にインストールできるプラグインを通じて、スマートコントラクトアカウントの機能を拡張することを目指しています。
詳細については、ERC-4337教育センターをご覧いただくか、すぐに開発を始められるプラグアンドプレイのEmbedded Accountsをご確認ください。
関連する概要
ウォレット2026年9月2日
エージェントウォレット: AIエージェントのためのセッションと権限モデル
AIエージェントが秘密鍵を保持せずにスコープ化された取り消し可能なウォレットアクセスを得る仕組み: セッション、委任署名、即時失効。
ウォレット2026年7月29日
Cursorに秘密鍵を貼り付けるのをやめる:コーディングエージェントにウォレットを持たせる方法
秘密鍵を渡さずに、コーディングエージェントにウォレットを持たせる方法。Alchemy CLIのエージェントウォレットがスコープ付きセッションを使い、.envに秘密鍵を置かずにエージェントが取引できる仕組みを解説します。
ウォレット2026年6月24日
暗号資産Bundlerとは?
暗号資産のBundlerは、バッチ処理、MEV、ロールアップ、トークンローンチ、アカウントアブストラクションにわたって、複数のトランザクションや操作を1つのオンチェーン送信にまとめます。

ブロックチェーンで魔法を生み出す
Alchemyは、最も強力なweb3開発者向けプロダクトとツールを、豊富なリソース、コミュニティ、そして卓越したサポートと組み合わせて提供します。