> For the complete documentation index, see [llms.txt](https://docs.chiliz.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.chiliz.com/jp/kaihatsu/joukyu/account-abstraction.md).

# Account Abstraction を使う

BiconomyのAbstractJSとMEEを使ってChiliz Chainでaccount abstractionを実装する: gasless transaction、batched transactionやcross-chain transaction、そしてdAppのUXを向上させるSmart Account。

## Account Abstractionとは？

Account Abstractionは、ユーザーがsmart contractをアカウントとして利用できるようにするブロックチェーン技術であり、アカウントを完全にプログラム可能なものにします。

これは、ユーザーアカウントをより柔軟かつ機能的にし、ユーザーエクスペリエンスを向上させることを目的としています。

## Chiliz Chainの開発者にとって何を意味するのか？

AAを実装することで、開発者はプロジェクトのユーザーエクスペリエンスを向上させることができます。Chiliz Chainとのやり取りがシンプルになれば、より使いやすいアプリになります。

## Chiliz ChainでBiconomyを使う

[Biconomy](https://www.biconomy.io/)は、**MEE**（Modular Execution Environment）と**AbstractJS** SDKを中核とするフルスタックのAccount Abstractionツールキットを提供しています。Chiliz Chainは[MainnetとSpicy Testnetの両方](https://docs.biconomy.io/contracts-and-audits/supported-chains)でサポートされています。

Biconomyのスタックを使えば、ユーザーに次の機能を提供できます:

* Gasless transaction
* Batched transactionおよびcross-chain transaction
* Smart contract wallet（social loginを含む）
* session key、account recoveryなどのモジュール

### なぜ従来のAccount AbstractionモデルではなくMEEなのか？

Biconomyの以前のスタックは、チェーンごとに個別のBundlerおよびPaymasterインフラに依存する従来の**ERC-4337**モデルの上に構築されていました。その後、Biconomyは完全なERC-4337との互換性を保ちつつ、その主な制限を取り除いた**MEE**へと移行しました。その理由については、Biconomyの[MEE vs ERC-4337](https://docs.biconomy.io/new/learn-about-biconomy/mee-vs-4337)の比較で説明されています:

* **動的なコンポーザビリティ**: ERC-4337はすべてのcall dataを事前に把握しておく必要がある静的なbatchingしか許容しません。MEEでは、各ステップが前のステップの出力を参照できます（条件付きロジックや実行時の値）。
* **ネイティブなcross-chainオーケストレーション**: チェーンごとに個別のtransactionと署名を行う代わりに、MEEは複雑なマルチチェーンのフローを1つの署名で認可します。
* **ユニバーサルなgas抽象化**: ユーザーはチェーンごとにgasを管理するのではなく、あるチェーンのトークンを使って任意のサポート対象チェーンでgasを支払うことができます。
* **自動化**: MEEはERC-4337にはないスケジュール実行や定期実行をサポートしています。
* **デフォルトでのEOAサポート**: smart contract wallet（またはEIP-7702）は厳密には必要ありません。

### Chiliz Chainでのgasless transaction

AAの最もインパクトのある用途の1つは、ユーザーがあなたのdAppとやり取りするためだけにCHZを保有する必要をなくすことです。**スポンサー付き（gasless）transaction**では、アプリケーションがユーザーに代わってgasを負担するため、オンボーディングにあたってユーザーがまずCHZを入手する必要がなくなります。MEEのユニバーサルなgas抽象化と組み合わせれば、gasをチェーンのネイティブアセットではなく別のトークンで支払うこともできます。有効化の方法については、Biconomyの[gas sponsorship](https://docs.biconomy.io/gasless-apps/sponsorship)ガイドをご覧ください。

### はじめに

[Biconomyダッシュボード](https://dashboard.biconomy.io/)にサインインし、プロジェクトを作成します。各プロジェクトでは、アプリで使用する認証情報が得られます:

* **API Key**（例: `mee_LDxnuNsXYfvNUGsz6sJbHn`）
* **Project ID**（例: `1sp767r4-5rrs-9o1s-3s6s-4s0r6nrq3647`）

AbstractJSと[viem](https://viem.sh/)をインストールします:

```bash
npm install @biconomy/abstractjs viem
```

続いて、NexusアカウントとMEEクライアントを作成し、チェーン設定をChiliz Chainに向けます。Chiliz ChainのIDは次のとおりです:

* `Chiliz Mainnet = 88888`
* `Chiliz Spicy Testnet = 88882`

```typescript
import { createMeeClient, toMultichainNexusAccount, getMEEVersion, MEEVersion } from "@biconomy/abstractjs";
import { http } from "viem";
import { privateKeyToAccount } from "viem/accounts";
import { chiliz, spicy } from "viem/chains";

const eoa = privateKeyToAccount("0xYOUR_PRIVATE_KEY");

// Create a Nexus account configured for Chiliz Chain (and Spicy Testnet)
const orchestrator = await toMultichainNexusAccount({
  chainConfigurations: [
    { chain: chiliz, transport: http(), version: getMEEVersion(MEEVersion.V2_1_0) },
    { chain: spicy, transport: http(), version: getMEEVersion(MEEVersion.V2_1_0) },
  ],
  signer: eoa,
});

// Create the MEE client using your Biconomy dashboard API key
const meeClient = await createMeeClient({
  account: orchestrator,
  apiKey: "mee_LDxnuNsXYfvNUGsz6sJbHn",
});
```

注: BiconomyのSDKは進化し続けているため、最新かつ完全な例については、Biconomyの[Setting up AbstractJS](https://docs.biconomy.io/new/getting-started/set-up-abstractjs)ガイドと[introduction](https://docs.biconomy.io/overview/introduction)を参照してください。


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.chiliz.com/jp/kaihatsu/joukyu/account-abstraction.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.