---
title: "セッションキーウォレット"
description: "スマートアカウントのセッションキーが限定的な権限を委任する仕組み、強制すべき制約、検証・失効・漏えい対応の方法を解説します。"
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# セッションキーウォレット
> 教育目的の情報であり、投資助言ではありません。漏えいした、または権限が広すぎるセッションキーは、取り消せないデジタル資産の損失を招く可能性があります。
## 直接の答え
ウォレットのセッションキーは通常、補助的な署名鍵、またはその鍵に結び付けられた委任資格情報であり、スマートアカウントは定められたルールの範囲内でのみ受け入れます。ルールでは、時間、対象コントラクト、関数セレクター、トークン量、取引回数などを制限できます。主署名者による毎回の承認を求めずに、アプリが反復操作を行えるようにすることが目的です。
「セッションキー」は設計パターンであり、イーサリアムの統一規格ではありません。ERC-4337 はプログラム可能なアカウント検証と期限付きの `UserOperation` 検証を提供し、ERC-7579 などのモジュラーアカウント方式はバリデーター、エグゼキューター、フックを組み込めます。鍵で何ができるかを最終的に決めるのは、ウォレットにデプロイされたアカウントとモジュールのコードです。期限だけでセッションが安全になるわけではなく、ブラウザー上のコピーを削除しても、オンチェーン登録済みの権限や期限内の委任が失効するとは限りません。
## 仕組み
一般的な流れは 5 段階です。
1. 所有者は端末上で新しい鍵ペアを作成するか、セッション署名者を識別する資格情報を承認します。設計上アプリのサーバーを信頼できるカストディアンと明示していない限り、セッション秘密鍵をサーバーへ送ってはいけません。
2. 所有者はメインウォレットでポリシーを承認します。鍵とポリシーをオンチェーンに登録する方式もあれば、操作の到着時にアカウントが検証する署名済み委任を使う方式もあります。
3. アプリは操作を作成し、セッションキーで署名します。ERC-4337 の流れでは、アカウントの `validateUserOp` ロジックが署名とポリシーを検査します。バンドラーによるシミュレーションは受け入れ可否の検査であり、実行や安全性の証明ではありません。
4. アカウントは実行前にすべての制約を強制する必要があります。有効な権限は `A_effective = K ∩ P ∩ S` と要約できます。鍵の保有（`K`）、設定済みポリシー（`P`）、現在のアカウントまたはチェーン状態（`S`）のすべてが操作を許可しなければなりません。
5. セッションは、期限切れ、nonce または割当量の消尽、明示的な失効、モジュール削除、その他の実装固有の無効化経路によって終了します。正しいチェーンで最終的なアカウント状態を確認します。
セッションを承認する前に、次を確認します。
- チェーン ID、スマートアカウントのアドレス、アカウント実装、バリデーターまたはモジュールのアドレス。
- セッション公開鍵または資格情報の識別子と、秘密情報の保存場所。
- 許可されるすべての対象、関数セレクター、トークン、受取人ルール、ネイティブ資産額の上限、各回または累積の支出上限。
- `validAfter`、`validUntil`、nonce ルール、利用回数、および時間がブロックのタイムスタンプと別の情報源のどちらで測られるか。
- 明示的に必要でない限り、バッチ、ネストされた呼び出し、`delegatecall`、トークン承認、モジュールのインストール、アカウントのアップグレード、ERC-1271 メッセージ署名が禁止されているか。
- 誰がセッションを失効できるか、所有者が独立した復旧経路を保っているか、失効に Gas や稼働中のバンドラーまたは paymaster が必要か。
ポリシーは、実際に実行される操作を検査する必要があります。外側のバッチ対象だけを調べると内側の呼び出しが無制限になり得ます。関数と値を無視して受取人だけを調べても同じです。制限を適用するコードがすべての実行経路を網羅して初めて、その制限には意味があります。
## 例
ゲーム用ウォレットが、24 時間有効なセッションを作ります。検証済みのゲームコントラクトだけを呼び出せるようにし、`delegatecall` とトークン承認を禁止し、各呼び出しにおけるネイティブ資産額を `0.02 ETH`、累積支出を `20 USDC` に制限します。ゲームは所有者に繰り返し確認を求めず許可済みの操作を送信できますが、無関係な NFT を移転する要求は検証に失敗しなければなりません。
使用前に、所有者はアカウント、チェーン、モジュール、セッション公開鍵、期限、上限、失効方法を記録します。少額の操作を一件試し、デコードされた呼び出しとアカウントイベントを確認した後、失効も別にテストします。これで設定経路は確認できますが、モジュールに脆弱性がないことや、侵害された端末が残りの上限まで使えないことまでは証明できません。
## リスクと対策
- **広すぎるポリシー：** ワイルドカードの対象、無制限のセレクターやトークン承認、バッチ、`delegatecall` は、「限定」鍵を所有者に近い権限へ変えかねません。明示的な許可リストを使い、管理操作を拒否します。
- **鍵の窃取：** ブラウザーの保存領域、ログ、バックアップ、拡張機能、マルウェア、共用端末からセッションキーが漏れることがあります。対応していればハードウェア保護または隔離保存を優先し、期限を短く、累積上限を低くします。
- **強制ロジックの欠陥：** アカウント、バリデーター、エグゼキューター、フックが呼び出しを誤ってデコードしたり、別の実行経路を見落としたりする可能性があります。検証済みデプロイ、レビュー済みコード、監査、回避ケースのテストを利用します。
- **リプレイと文脈の混同：** nonce 処理が弱い、または意図したチェーン、アカウント、モジュール、ポリシーへの結び付けが欠けると、別の文脈で再利用されることがあります。正確な署名ドメインとオンチェーンのリプレイ防止を確認します。
- **期限に関する思い込み：** `validUntil` は一件の ERC-4337 操作を制限しても、登録済み鍵、トークン承認枠、別の委任を自動的に削除しない場合があります。期限後に各権限の実際の状態を確認します。
- **失効の失敗：** ローカルデータの削除は秘密のコピーを一つ消すだけです。アカウントの文書化された経路で失効し、オンチェーン結果を確認します。十分な Gas と所有者管理の予備経路を維持します。
- **アップグレード可能または悪意あるモジュール：** モジュールは強い実行権限を持つことがあり、アップグレードでポリシーの挙動も変わり得ます。所有者、アップグレード遅延、停止権限、実装アドレス、モジュール削除手順を確認します。
- **Gas とスポンサーの悪用：** セッションがアカウント資金を Gas に消費したり、paymaster に拒否されると使えなくなったりする場合があります。可能なら手数料の挙動を制限し、独立した送信経路を残します。
セッションキーの漏えいが疑われる場合は、対象アプリの使用を止め、セッション識別子と関連トランザクションハッシュを保存し、清潔な所有者管理端末から鍵を失効または無効化します。その後、対応するすべてのチェーンで保留中と最近の操作、トークン承認、インストール済みモジュール、アカウントのアップグレード、残高を調べます。アカウントまたはモジュールの設計上、失効が信頼できない場合に限って残存資産を移します。未検証の「復旧」サイトへ急ぐと損失が拡大しかねません。
## よくある誤解
- **「セッションキーは資産を動かせない。」** 強制されるポリシーが許すあらゆる操作を実行でき、送金、スワップ、承認、署名が含まれる場合があります。
- **「ERC-4337 がセッションキーの権限を定義している。」** ERC-4337 はアカウント検証と実行の枠組みを提供しますが、セッションポリシーはウォレットまたはモジュール固有です。
- **「短い期限なら最大損失も限定される。」** 損失は一回の上限、累積上限、呼び出し頻度、Gas、承認、価格、到達可能なすべての実行経路にも左右されます。
- **「ログアウトすれば鍵は失効する。」** ログアウトでローカルコピーが消えても、オンチェーン登録や署名済み委任が無効になった証明にはなりません。
- **「シミュレーション成功は操作が安全という意味だ。」** 現在の検証が操作を受け入れることは示せますが、利用者の意図、将来の取り込み、実行成功、ファイナリティ、モジュールに脆弱性がないことは証明しません。
## 関連トピック
- [アカウント抽象化](/ja/crypto/account-abstraction/)
- [ERC-4337 Paymaster のリスク](/ja/crypto/erc4337-paymaster-risk/)
- [秘密鍵の管理](/ja/crypto/private-key-management/)
- [トランザクションシミュレーション](/ja/crypto/transaction-simulation/)
- [ウォレット署名](/ja/crypto/wallet-signature/)
## 出典
- [Session Keys & Delegation](https://docs.erc4337.io/smart-accounts/session-keys-and-delegation.html) - ERC-4337 Documentation（参照日：2026-08-21）
- [ERC-4337: Account Abstraction Using Alt Mempool](https://eips.ethereum.org/EIPS/eip-4337) - Ethereum Improvement Proposals（参照日：2026-08-21）
- [ERC-7579: Minimal Modular Smart Accounts](https://eips.ethereum.org/EIPS/eip-7579) - Ethereum Improvement Proposals（参照日：2026-08-21）
- [Safe Modules](https://docs.safe.global/advanced/smart-account-modules) - Safe Docs（参照日：2026-08-21）
Source: https://wiki.fcontext.com/ja/crypto/session-key-wallet/index.mdx