# [ERC1775] アプリ専用鍵「App Key」の仕組みを理解しよう！

> Ethereumブロックチェーンにおいて、スケーラビリティやプライバシーを向上させるためのアプリケーションでは、ユーザーが大量の署名操作を行う必要があります。

- URL: https://cardene.dev/articles/14e6316fc4dec45b9d55
- 公開日: 2025-08-08
- 更新日: 2025-08-08
- トピック: Blockchain
- タグ: ethereum, solidity, smartcontract, ブロックチェーン

## はじめに

『DApps開発入門』という本や色々記事を書いているかるでねです。

https://amzn.asia/d/gxvJ0Pw

今回は、ユーザーがアプリごとに自動で専用の鍵を使い分けられるようにすることで、異なるサービス間での行動が結び付けられにくくなり、プライバシーを保ちながら手間なく署名操作を行えるようにする仕組みを提案している**ERC1775**についてまとめていきます！

:::message
以下にまとめられているものを翻訳・要約・補足しながらまとめていきます。
:::

https://eips.ethereum.org/EIPS/eip-1775

他にも様々なEIPについてまとめています。

https://cardene.notion.site/ERC-EIP-2a03fa3ea33d43baa9ed82288f98d4a9?pvs=4

## 概要

Ethereumブロックチェーンにおいて、スケーラビリティやプライバシーを向上させるためのアプリケーションでは、ユーザーが大量の署名操作を行う必要があります。
これに加えて、アプリケーションの状態を監視し、特定のタイミングで自動的に署名を実行する（例えばステートの承認や出金への異議申し立てなど）ことも求められます。

しかし現在のウォレットのアカウント管理方式では、こうしたWeb3アプリケーションの理想的な体験を提供するうえで、ユーザー体験（UX）やセキュリティ、プライバシーの面で多くの制約が存在しています。

**ERC1775**では、新たなアカウントの概念として「**アプリケーション専用キー（App Keys）**」を導入することを提案しています。
これは特定のアプリごとに専用のアカウントを生成・使用する仕組みであり、各アプリケーション間でアカウントを分離することにより、プライバシーの向上が期待できます。

また、App Keyは通常のメインアカウントとは異なり、より緩やかなセキュリティポリシー（例えばユーザーの手動確認を求めずに署名可能）を適用できます。
さらに、トランザクションを署名しても即時にブロードキャストしないといった柔軟な挙動も可能になります。

これにより、これまでにないユーザー体験とアプリ設計が可能になり、暗号資産を活用した新しいWeb3アプリケーションの発展に寄与します。

一般的に、ユーザーのウォレットでは大部分の資産が「**メインアカウント**」に保管されています。
これらのアカウントは高いセキュリティが求められるため、第三者への委任や自動処理には向いていません。
その結果、ユーザーがすべての署名を手動で確認する必要があり、アプリケーション側の設計が大きく制限されます。

また、多くのユーザーは複数のアプリケーション間で同じアカウントを使い回す傾向があり、これがプライバシーやセキュリティのリスクにつながっています。

この問題を解決するために、**ERC1775**ではアプリごとに専用のアカウント（App Key）を導入するという新しいアプローチを提示します。
App Keyはユーザーの秘密鍵（ルート秘密鍵、あるいはそこから派生させた任意の秘密鍵）から、特定のアプリ（ドメイン）専用に導出されます。
この導出プロセスは再現性があり、ユーザーがウォレットを復元する時にも、対応するアプリケーションを再び使えば同じApp Keyを自動的に再生成することができます。

さらに、App Keyは**ERC2255**で導入された`requestPermission`モデルを利用して、各アプリに応じた署名権限やセキュリティレベルを設定することができます。
これにより、ユーザーはメインアカウントの安全性を損なうことなく、信頼できるアプリに限定的な操作権限を委任できるようになります。

:::message
**ERC2255**については以下の記事を参考にしてください。
:::

[\[ERC2255\] Web3アプリの権限リクエストの仕組みを理解しよう！](/articles/e5c2ac6c5d3e2e4520f6)

## 動機

これまでに、Ethereumのアカウント構造には**BIP32**、**BIP44**、**SLIP44**といったHD（階層的決定性）ウォレットの標準が導入されており、ウォレット開発者の間でもある程度の合意が得られています。
さらに**ERC1102**によって、アプリへの自動アカウント接続が禁止され、ユーザーのプライバシーが一定程度保護されるようになりました。

:::message
**BIP32**については以下の記事を参考にしてください。
:::

[\[BIP32\] 階層的に鍵を導出するHDウォレットの仕組みを理解しよう！](/articles/9d4376d124d2f50778c2)

:::message
**BIP44**については以下の記事を参考にしてください。
:::

[\[BIP44\] 階層型ウォレット構造の仕組みを理解しよう！](/articles/031a610d87ac89b71617)

:::message
**SLIP44**については以下の記事を参考にしてください。
:::

[\[SLIP0044\] HDウォレットで通貨を分けて管理する仕組みを理解しよう！](/articles/cfbb0cbee7062553e599)

:::message
**ERC1102**については以下の記事を参考にしてください。
:::

[\[ERC1102\] Ethereumアカウントを安全にサイトに接続する仕組みを理解しよう！](/articles/3d1c6d38f21c0289b07e)

しかし、それでもなお以下のような問題が未解決のままです。

* 各アプリで異なるアカウントを自動的かつ簡単に使い分けられない。
* アプリの操作に対して、常に高セキュリティの署名確認が求められる。
* 匿名性を向上させるための「**使い捨てアカウント（throwable key）**」が活用しにくい。
* 署名のみを行ってブロードキャストせずに後で送信する、という柔軟な処理ができない。
* 全てのアカウントが復元可能であることを前提にした設計が難しい。

これらの課題を解決するために、App Keyという新しいアカウントタイプを導入することを提案しています。

App Keyは、既存のメインアカウントと併用する形で設計され、アプリ開発者がより柔軟かつ安全にアカウント管理や署名処理を実装できるようになります。
例えば、事前に署名したメッセージを後から送信するといった新しい設計パターンも可能になります。
これにより、ユーザー体験の大幅な向上が見込まれ、これまで困難だった新しいWeb3アプリの構築が現実のものとなります。

## 仕様

### アプリケーションとは何か

**ERC1775**における「**アプリケーション**」とは、ウォレットに対して特定の暗号鍵（App Key）のアクセスをリクエストするウェブサイトやサービスを指します。
これらのアプリケーションは、Ethereumベースに限らず、アイデンティティ管理や署名が必要なさまざまな暗号技術を活用するものを含みます。

アプリケーションは、ユーザーのウォレットと接続された後、そのアプリ専用のアカウントへのアクセスを要求することができます。

### アプリ専用鍵（Private App Key）の生成アルゴリズム

App Keyは、以下の条件を満たすように設計されています。

* ユーザーが選択した特定のアカウントに基づいて一意に決定される。
* アカウントを切り替えることで別のApp Keyが生成されるため、アプリ間でのアカウント分離が可能。
* 各アプリごとに固有の鍵が生成される。
* ユーザーのニーモニック（復元フレーズ）とアプリの識別名だけで再生成できる。

この仕組みにより、App Keyはプライバシーを強化し、アプリごとの完全な鍵の分離と復元を実現します。

### ペルソナとしてのアカウント切り替え

App Keyは、ユーザーが選択したアカウントをもとに導出されます。
そのため、同じニーモニックから生成された複数のアカウントを使い分けることで、「**ペルソナ**」を分離できます。
例えば、1つのアプリに対して「**個人用ペルソナ**」と「**業務用ペルソナ**」を別々に持ち、それぞれ異なるアカウントからApp Keyを生成することで、同一人物であることを隠しながら同じサービスを使うことが可能になります。

アプリケーション側はこれらを識別できないため、ユーザーは用途に応じて完全に独立した操作を行うことができます。

なお、ペルソナの管理や生成方法については**ERC1775**では定義せず、別途提案予定の仕様に委ねられています。

### アプリケーションの一意な識別子

各アプリケーションは、「**オリジン**」と呼ばれるドメイン名によって一意に識別されます。
これは通常のDNSドメイン名だけでなく、Ethereum Name Service（ENS）や将来的にはIPFSやSwarmのアドレスも対象となります。

例えば、IPFS上のアプリであれば、`ens://ipfs.example.eth` のようにENSドメインとプロトコルプレフィックスを組み合わせて使用することが想定されています。

### App Keyの生成処理（技術詳細）

App Keyは、選択されたアカウントの秘密鍵（privKey）とアプリケーションのオリジン（originString）を連結し、`keccak256`ハッシュ関数に通すことで生成されます。
具体的には以下のような形式です。

```javascript
const appKeyPrivKey = keccak256(privKey + originString);
```

この処理により、アプリケーションごとに異なる秘密鍵が得られ、アカウントごとの分離も自然に実現されます。

さらにこの仕組みは、ウォレットプロバイダ経由でRPCメソッドとしてアプリから呼び出すことができます。

```javascript
const appKey = await provider.send({
  method: 'wallet_getAppKeyForAccount',
  params: [address1]
});
```

MetaMaskなどでの実装例も存在しており、既存ウォレットとの統合が視野に入っています。

### HDウォレットとの関係と注意点

このApp Keyの生成方式は、BIP32準拠の階層的決定性（HD）ウォレットとは互換性がありません。
つまり、BIP32のような階層構造を持つ鍵の拡張（extended public key）や非ハードニング派生などは直接使用できません。

ただし、得られたApp Keyを初期エントロピーとして、独自にHDウォレットツリーを派生させることは可能です。
これにより、ハードニングされた鍵や通常の鍵を必要に応じて生成できるため、機能面での制約は最小限に抑えられています。

## 補足

### アプリケーション間での鍵の共有

**ERC1775**この提案は基本的にアプリケーションごとに専用の鍵（App Key）を生成する仕様ですが、ドメイン間で鍵を共有したいというニーズにも対応可能です。
例えば、あるアプリケーションが別のドメイン上で動作する「**署名専用サービス**」に署名処理を委託する場合、両者は相互通信によって鍵を活用できます。

このような設計により、署名戦略を動的に切り替えることも可能になります。
例えば、あるドメインが「**署名用ライブラリの静的ハッシュ**」に対応する安全な実装を提供していれば、それを別ドメインのアプリが使用して署名処理を委託するという構成も安全に成り立ちます。
これは、内部の監査済みライブラリを呼び出すのと同じような安全性を確保できます。

このように、App Keyの導入は新たな署名戦略の柔軟な実装を可能にし、ドメイン間での機能連携を促進する設計にもなっています。

### プライバシーと資金移動の追跡

App Keyを用いた署名は、トランザクションの送信を伴わない限り、資金移動を発生させません。
したがって、アプリケーションが署名のみを必要とするケースでは、アプリごとに異なる鍵を使うことで高いプライバシーを確保できます。
しかもこれは、すべてのウォレットで再現可能な単純な鍵生成ルールによって実現されます。

ただし、App Keyを使って実際にETHなどの資金を送受信する場合、資金の流れ（トレイル）によって個人のアカウントが特定される可能性があります。
そのため、プライバシーを完全に担保するためには、ミキサー（匿名送金サービス）やリング署名のような匿名資金供給手段と併用することが推奨されます。

仮に匿名性が完全でない場合でも、アプリごとに個別の鍵を作成・復元できる仕組みがあること自体が、セキュリティと使いやすさの両立に大きく貢献します。

## 互換性

ウォレット開発の観点からは、App Keyは既存のアカウントとは完全に別の空間で管理されるため、互換性の問題は生じにくいと考えられます。
App Keyはメインアカウントと共存可能であり、これまで通りのウォレット体験を壊すことなく、新たな機能性を追加できます。

一方で、アプリケーション側が「**メインアカウントとユーザーを結びつける前提**」で設計されていた場合、App Keyをどのように活用するかを再検討する必要があります。
例えば、ユーザーの識別にメインアカウントを使用していた場合、それをApp Keyに置き換えることで、より柔軟なアプリ設計やプライバシー強化が可能になるかもしれません。

### 実装状況

App Keyの初期実装は、MetaMaskの標準的なソフトウェアウォレットアカウント（ハードウェアウォレットではない）に対して、すでに試験的に導入されています。
実装は以下で確認できます。

* [eth-simple-keyring 実装コード（GitHub）](https://github.com/MetaMask/eth-simple-keyring/blob/6d12bd9d73adcccbe0b0c7e32a99d279085e2934/index.js#L139-L152)

また、MetaMaskのプラグイン機能（Snaps）と併用できるフォークも公開されており、将来的な標準化や拡張性を見据えた取り組みが進められています。

* [MetaMask Snaps Beta（GitHub）](https://github.com/MetaMask/metamask-snaps-beta)
* [Snaps Plugin API ドキュメント](https://github.com/MetaMask/metamask-snaps-beta/wiki/Plugin-API)

これらの実装は、実際にApp Keyを使った新しいウォレット体験が可能であることを示しており、今後の普及に向けた基盤となっています。

## Example Use Cases

App Keyの仕組みは、アプリケーションごとに独立した暗号鍵を持つことで、従来のアカウント管理では難しかった柔軟な運用や設計を可能にします。
ここでは、App Keyが有効に活用できる代表的なユースケースを紹介します。

### ブロードキャストしない署名の活用

App Keyを用いることで、トランザクションを「**署名はするがすぐには送信しない**」という運用が可能になります。
これはMetaMaskに対して寄せられたリクエスト（[Issue #3475](https://github.com/MetaMask/metamask-extension/issues/3475)）にもあるように、署名済みトランザクションをユーザーが後から手動で送信したいというニーズに応えるものです。

この仕組みは、将来のオフチェーン処理やバッチ送信にも活用でき、より高度なユーザー操作やアプリ設計が可能になります。

### トークンコントラクトの署名操作

ERCトークンコントラクト（[**EIP85**](https://github.com/ethereum/EIPs/issues/85)）などでは、トークンのTransfer操作や許可（approve）操作など、多数の署名操作が必要になります。
App Keyを使えば、ユーザーのメインアカウントを使用せずにこれらを処理でき、UXとセキュリティの分離が実現されます。

### DAppsのためのデフォルトアカウント

アプリケーションが接続する際の「**デフォルトアカウント**」をアプリケーションごとに分けたいという要望は以前から存在しており、その議論は[Ethereum Magicians](https://ethereum-magicians.org/t/default-accounts-for-dapps/904)でも行われています。
App Keyはこのニーズを満たし、各アプリに対して一貫した専用アカウントを提供する手段となります。

### ウォレット用途以外での鍵の活用

[**ERC1581**](https://eips.ethereum.org/EIPS/eip-1581)では、ウォレットや資金操作以外の目的でBIP32から導出された鍵を使用することが提案されています。
App Keyはまさにこの思想と合致し、認証や識別、非資金的な署名など、幅広い用途に対応できます。

### ステートチャネルの署名用アカウント

ステートチャネルなどのL2ソリューションでは、オフチェーンでの継続的な署名処理が不可欠です。
App Keyを活用することで、ユーザーのメインアカウントのセキュリティを維持しつつ、専用アカウントでオフチェーンの署名を安全に処理することが可能になります。

### プライバシー重視のアプリケーション

App Keyはアプリごとに異なる鍵を生成するため、ユーザーの行動が複数のアプリ間でリンクされにくくなります。
これは、ZKやミキサーのようなプライバシーソリューションと組み合わせて使うことで、さらに高い匿名性と秘匿性を実現できます。

### 非カストディアルなクロスチェーン取引

App Keyは、特定のアプリケーションにだけ一時的な鍵を委任し、クロスチェーン取引を自動的に処理させるような設計にも向いています。
これにより、中央管理者を介さずにアセットをやり取りする安全な仕組みを構築できます。

## References

**ERC1775**は、既存のウォレット標準や関連するEIP群に基づいて設計されています。

### 階層的決定性ウォレットとニーモニック

* **BIP32**
    * HD（Hierarchical Deterministic）ウォレットの基本設計。
* **BIP39**
    * ニーモニックによる鍵の生成方法。
* **SLIP44**
    * BIP44におけるコインタイプの割り当て。

:::message
**BIP39**については以下の記事を参考にしてください。
:::

[\[BIP39\] 単語でウォレットを復元する仕組みを理解しよう！](/articles/58f7c40a8441cadc608f)

### Ethereumのための導出パス設計

* **Issue #84 / #85**
    * Ethereum向けHDウォレットのアドレス階層に関する議論
* **ERC600 / EIP601**
    * Ethereum用にHDウォレット階層を整理するための提案

:::message
**EIP85**については以下の記事を参考にしてください。
:::

[\[EIP85\] トークンアドレスからHDウォレットパスを導く仕組みを理解しよう！](/articles/af5d53ac31897721b225)

:::message
**ERC600**については以下の記事を参考にしてください。
:::

[\[ERC600\] BIP32の仕組みをEthereumに適用する仕組みを理解しよう！](/articles/1a0a0e50c77c7c3be091)

:::message
**ERC601**については以下の記事を参考にしてください。
:::

[\[ERC601\] Bitcoinを参考にした新しいEthereumのウォレット生成の仕組みを理解しよう！](/articles/a29e84d0c12815d2ef9d)

### App Keyに関連する過去提案と議論

* **EIP1102**
    * アプリによるアカウントアクセスの事前承認モデルの導入。
* **EIP1581**
    * BIP-32からの鍵の非ウォレット利用についての提案と議論。
* **SLIP13**
    * 決定性階層を使った認証プロトコルの提案。
* **Meta: we should value privacy more**
    * プライバシーを重視すべきというコミュニティ内での提言

これらの提案や仕様は、App Keyの設計思想を技術的に裏付ける土台となっています。

## 引用

Vincent Eli (@Bunjin), Dan Finlay (@DanFinlay), "ERC-1775: App Keys, application specific wallet accounts [DRAFT]," Ethereum Improvement Proposals, no. 1775, February 2019. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-1775.

## 最後に

今回は「ユーザーがアプリごとに自動で専用の鍵を使い分けられるようにすることで、異なるサービス間での行動が結び付けられにくくなり、プライバシーを保ちながら手間なく署名操作を行えるようにする仕組みを提案している**ERC1775**」についてまとめてきました！
いかがだったでしょうか？

質問などがある方は以下のTwitterのDMなどからお気軽に質問してください！

[Twitter @cardene777](https://twitter.com/cardene777)

他の媒体でも情報発信しているのでぜひ他も見ていってください！

https://chaldene.net/

https://zenn.dev/heku

https://cardene.substack.com/

https://mirror.xyz/0xcE77b9fCd390847627c84359fC1Bc02fC78f0e58

https://cardene.notion.site/ERC-EIP-2a03fa3ea33d43baa9ed82288f98d4a9?pvs=4