Session Key（セッションキー）の設計｜毎回のウォレット署名なしで安全に操作を任せる仕組みと2026年の実装

セッションキー（Session Key）は、有効期限・呼び出せるコントラクトと関数・金額や回数の上限を絞った一時的な鍵をユーザーのウォレット（スマートアカウント）に登録し、その範囲内に限って、アプリが毎回の署名確認なしにトランザクションを実行できるようにする仕組みです。ゲームの1操作ごと、DEX（分散型取引所）の承認→スワップごとにウォレットの確認画面が開いて利用者が離脱する「連続署名」の問題への実用解で、Web2でいえばスコープと有効期限を絞ったAPIキーの発行に近い考え方です。決定的な違いは、制約を守らせる場所がアプリのサーバではなく、ユーザーのアカウント側のコントラクトである点にあります。アプリ側が侵害されても、登録時に定めた範囲を超える操作はオンチェーンの検証で拒否されます。

2026年8月時点では、主要な既製の選択肢が揃い、検証ロジックを自前で書く前に、まず既製実装の適合性を評価できる段階になっています。ZeroDevのPermissions、RhinestoneとBiconomyが共同開発したSmart Sessionsといった既製モジュールに加え、MetaMaskのAdvanced Permissions（ERC-7715）やCoinbaseのSpend Permissionsのように、ウォレット側が許可の付与画面まで含めて提供する形も使えるようになりました。一方で、権限の絞り方を誤ると、鍵の漏洩がそのまま資産流出につながります。設計の中心は「どの操作を許可するか」ではなく「何を許可してはいけないか」です。本記事は、仕組み、権限設計の4軸、実装の選択肢、失敗パターン、失効設計、導入判断までを2026年8月時点の一次情報で整理します。スマートアカウント領域の全体像はAA完全マップ2026、前提となるERC-4337の基礎はERC-4337の事業者向け解説を参照してください。

セッションキーが解決する問題 — どの署名を消してよいか

ブロックチェーンのアカウントは、初期状態では「秘密鍵による署名＝全権」です。残高全額の送金も、ゲーム内のボタン1回分の操作も、同じ重さの署名を要求します。このため標準的なウォレット接続のままでは、ゲームの戦闘・アイテム操作のたび、DEXでのトークン承認→スワップ→ステーキングの各段階、オークションの入札のたびに確認画面が開き、操作のテンポが崩れて利用者が離脱します。

対策は「署名を全部なくす」ことではなく、操作を2種類に分けることです。

• 消してよい署名：ユーザーが最初に範囲へ同意した後の、同じ範囲内での繰り返し操作。ゲーム内アクション、承認済み戦略での自動売買、定額のサブスクリプション決済などが該当します。
• 残すべき署名：資産の移転、権限の変更、許可範囲そのものの拡大。これらはセッションキーの権限外に置き、都度マスター鍵（アカウントの本来の署名手段）で署名させます。

なお、「1回の操作で複数のトランザクションが必要」なだけであれば、セッションキーではなくバッチ実行（複数の呼び出しを1署名にまとめる仕組み）で足りることがあります。バッチが解決するのは「1回の意思決定に署名が複数回要る」問題、セッションキーが解決するのは「一定期間、繰り返し操作のたびに署名が要る」問題です。前者の設計はバッチトランザクションの設計で扱っています。2026年時点でセッションキーの適用先はゲームやDEXにとどまらず、AIエージェントによる取引の自動化やオンチェーンのサブスクリプション決済が、ウォレット各社の公式ドキュメントでも主要ユースケースとして扱われています（ZeroDev Docs: Permissions、MetaMask: Introducing Advanced Permissions、2026年4月）。

仕組み — スマートアカウントに「制約付きの鍵」を登録する

セッションキーは、アカウントがコントラクトであることを前提にした機能です。EOA（Externally Owned Account：秘密鍵1本で直接操作する従来型アカウント）は「正しい署名なら何でも実行する」以上のルールを持てないため、EOA単体では権限を絞った鍵を作れません。コントラクト型のアカウント（ERC-4337系のスマートアカウント、または後述のEIP-7702で実行を委任したEOA）が前提になります。

典型的な流れは3段階です。

• 発行：アプリが一時鍵（キーペア）を生成し、「この公開鍵に、この有効期限・この呼び出し先・この上限」という許可内容を提示します。ユーザーはマスター鍵で1回だけ署名し、許可をアカウントに登録します。マスター鍵がpasskey（生体認証で使うFIDO2ベースの鍵）である構成はパスキーウォレットの解説で扱っています。
• 利用：以後アプリは、UserOperation（ERC-4337における実行要求の単位）をセッションキーで署名して送ります。アカウント側の検証モジュールが「登録済みの鍵か」「許可範囲内か」を検証し、範囲内なら実行、範囲外なら拒否します。ユーザーへの確認画面は出ません。
• 失効：有効期限が切れると鍵は自動的に使えなくなります。期限前でも、ユーザーまたはアプリが失効操作を行えば無効化できます。

有効期限は実装ごとの独自機能ではなく、標準仕様のレベルで扱われています。ERC-4337（Final）は、アカウントの署名検証が返すvalidationDataにvalidAfter/validUntil（それぞれ6バイトのタイムスタンプ、validUntil=0は無期限）を含める形式を定義しており、期間外のUserOperationはEntryPoint（ERC-4337の中継コントラクト）とBundler（UserOperationをまとめてチェーンに送る事業者）の検証で弾かれます（ERC-4337）。

また、2025年5月7日に有効化されたEthereumのPectraアップグレードに含まれるEIP-7702により、既存のEOAもアドレスを変えずにスマートコントラクトへ実行を委任できるようになりました。委任先のコントラクトがセッションキー用の検証モジュールを備えていれば、MetaMaskのような既存EOAウォレットのユーザーにも同じ体験を提供できます（EIP-7702）。EIP-7702自体の解説はEIP-7702の事業者向け解説を参照してください。

権限設計の4軸 — 期限・呼び出し先・量・署名

セッションキーの安全性は、発行時にどれだけ権限を絞れるかで決まります。主要な実装が提供する制約は、次の4軸に整理できます。実装例の列は、ZeroDevのPermissions（Kernel向け）とSmart Sessions（ERC-7579準拠アカウント向け）で実際に提供されているポリシーです（ZeroDev Docs: Permissions、erc7579/smartsessions、いずれも2026年8月11日閲覧）。

4軸目は見落とされやすい論点です。スマートアカウントはERC-1271（コントラクトによる署名検証の標準）を通じて「トランザクションではない署名」も行えるため、セッションキーがこの署名まで無制限にできると、マーケットプレイスの売り注文やオフチェーンの許可メッセージを勝手に作られる経路が残ります。トランザクションの呼び出し先だけ絞って安心しない、が原則です。

期限と量の具体値は、ユースケースの1単位に合わせて最短にします。ゲームなら1プレイセッション、自動売買なら戦略の実行期間、サブスクリプションなら請求周期が単位です。「切れたら再署名1回で再発行できる」体験を前提に短く設定し、長寿命の鍵を作らないことが、後述する失効設計の負担も減らします。

2026年の実装ランドスケープ — 自前実装は最後の選択肢

セッションキーの検証ロジック（署名検証、ポリシー評価、失効管理）は、脆弱性が入りやすい典型部位です。2026年8月時点では次のような既製の選択肢が揃っており、自前でValidatorを書くのは、既製モジュールが対応しない特殊要件がある場合の最後の選択肢と考えるべきです。

出典：ZeroDev Docs: Permissions、erc7579/smartsessions、MetaMask Docs: Advanced Permissions、coinbase/spend-permissions、Base Docs: Spend Permissions、Cartridge Docs: Controller（いずれも2026年8月11日閲覧）。

この一覧は、2024年から2026年にかけて起きた構図の変化を反映しています。以前の「アプリごとに独自のセッションキーValidatorを実装する」段階から、（1）ERC-7579準拠の共通モジュールとして標準化する流れ（Smart Sessions）、（2）ウォレット側が許可の要求・付与・表示まで標準化する流れ（ERC-7715）へ、と重心が移りました。ERC-7715は、アプリがウォレットへ実行許可を要求するwallet_requestExecutionPermissionsと、失効・照会用のメソッド群を定義するJSON-RPC標準で、委任の実行にはERC-7710（コントラクトからの権限委任の標準）を組み合わせます。両ERCとも2026年8月時点ではDraft段階ですが（ERC-7715、ERC-7710）、MetaMaskは2026年4月にこれらへ準拠したAdvanced Permissionsの提供を開始しています（MetaMask: Introducing Advanced Permissions）。

どのスマートアカウント実装を土台に選ぶかは別の意思決定です。Kernelを含むスタック選定はKernel（ZeroDev）の採用判断とBiconomyの採用判断、横並びの比較はSmart Walletスタック比較2026で扱っています。

失敗パターン — 何を許可してはいけないか

セッションキーの事故は、暗号の破綻ではなく権限設計の穴から起きます。設計レビューで実際に問題になりやすいパターンを挙げます。

• 資産移転・許可設定の関数を許可リストに入れる：ERC-20のtransfer()やapprove()、NFTの移転関数をセッションキーで呼べるようにすると、鍵の漏洩がそのまま資産流出になります。特にapprove()は、攻撃者が自分のコントラクトへ許可を付けさせて後から全額引き出す経路を開くため、原則としてセッションキーの権限外に置きます。
• 関数だけ絞って引数を絞らない：「自社コントラクトのswap()だけ許可」でも、宛先や金額が引数で自由に指定できるなら悪用余地が残ります。Call Policy / Action Policyの引数条件まで使って、値の範囲ごと縛ります。
• 1回あたりの上限だけで累積・回数の上限がない：1回10ドルまでの制限は、1万回実行できれば意味を持ちません。回数制限（Rate Limit）または期間あたりの累積上限を必ず併用します。
• アカウントが既に持っている許可（allowance）を見落とす：セッションキー経由の呼び出しは、コントラクトから見ればアカウント本人の実行です。ユーザーが過去にDEX等へ与えたトークンの利用許可も、その許可を使う呼び出しがセッションキーの範囲に入っていれば行使できます。Coinbaseは2025年2月の設計解説で、この「既存状態の悪用」と、ERC-4337のPaymaster（ガス代を肩代わりする仕組み）向けの許可枠をスパム的な呼び出しで消費され得る問題を、セッションキーの構造的な弱点として挙げています（Base: From Session Keys to Sub Accounts、2025年2月27日）。許可リストの評価は「この関数は安全か」ではなく「このアカウントが持つ状態・残高・許可を、この関数から動かせるか」で行います。
• 権限内容をユーザーに説明できない：コントラクトアドレスと関数セレクタの羅列は、利用者には判断できません。同じBaseの解説はこれを理由の一つとして、コントラクト・関数の許可リスト方式ではなく、アプリ専用のサブアカウントに「期間あたりいくらまで」という予算だけを渡すSub Accounts + Spend Permissions方式を採っています。ERC-7715も、ウォレットが人間に読める形で許可内容を表示することを前提にした設計です。どの方式でも、ユーザーに提示する説明が実際の権限と一致していることが信頼の条件になります。
• セッションキー自体の保管が甘い：ブラウザ内で使う鍵をlocalStorageに平文で置けば、スクリプト注入で盗まれます。Web Crypto APIの取り出し不可（non-extractable）な鍵として生成・保管するのが基本です。アプリのサーバ側で鍵を預かる構成は、事業者がユーザー資産を動かせる権限を持つことを意味し、技術的なリスクに加えて、構成次第では暗号資産のカストディ（他人のための管理）該当性という規制上の論点も生じます。該当性の判断は弁護士等の専門家の領域ですが、論点の整理はAAの規制該当性で扱っています。

スマートアカウント全体の攻撃面（Bundler・Paymaster・アカウント本体）はAAセキュリティリスクで整理しています。セッションキーはそのうち「アカウントの検証ロジック」に権限を追加する行為なので、追加した分だけ攻撃面が広がる、という前提で設計します。

失効（リボーク）の設計 — 期限切れを基本に、即時失効を備える

失効の設計は発行と同じ重さで扱います。柱は3つです。

• 期限切れによる自動失効を基本にする：最も確実な失効は、失効操作が不要なことです。鍵を短命にしておけば、失効漏れ・失効遅延の問題自体が小さくなります。期限はERC-4337の検証（validUntil）で強制されるため、アプリ側の実装ミスで延命される余地がありません。
• ユーザー起点の即時失効を用意する：「ログアウト」「この端末の接続を解除」に相当する操作を、オンチェーンの失効（許可の削除）と紐付けます。ERC-7715準拠の構成ではwallet_revokeExecutionPermissionが失効用に定義されており、Spend Permissionsもユーザーによる取り消しを前提にしています。オンチェーン失効の反映までの時間差を埋めるため、アプリ側APIでも同時に拒否する二重化が実務的です。
• 異常検知時に止められる側を決めておく：不審な実行パターンを検知した際、アプリ側から止めるのか、ウォレット側から止めるのか、両方かを事前に決めます。サーバ側で鍵を保持する構成なら鍵の破棄で即座に止まりますが、前章のとおり保管リスクとのトレードオフです。ブラウザ側保管なら、アプリAPIの拒否とオンチェーン失効の組み合わせになります。

再発行はマスター鍵の署名を必須にします。セッションキーからセッションキーを発行できる設計（権限の連鎖）は、失効の追跡を困難にするため避けます。

導入判断 — モジュールを組み込むか、ウォレットの許可機構に乗るか

導入形態は、ユーザーがどのウォレットで来るかでほぼ決まります。

• 自社アプリにウォレットを埋め込む場合（ゲーム・コンシューマアプリ）：embedded wallet（アプリ内蔵型ウォレット）としてKernel等のスマートアカウントを組み込み、Permissions / Smart Sessionsで権限を設計する構成が標準です。ウォレットの対応状況に依存せず、発行から失効までのUXを自社で設計できます。完全オンチェーンゲームでStarknetを使う場合は、Cartridge Controllerがこの構成をゲーム向けに標準装備しています。
• ユーザーの既存ウォレットに接続してもらう場合：ウォレット側の許可機構に乗ります。MetaMaskユーザーにはAdvanced Permissions（MetaMask Smart Accountsが前提）、Base Accountのユーザーには Spend Permissions / Sub Accountsが使えます。ただしERC-7715はDraft段階で、対応ウォレットはまだ限られます（2026年8月時点）。対応外のウォレットのユーザーには従来どおり都度署名になる、という前提でフォールバックを設計します。
• 自前のValidator実装が正当化されるのは：既製モジュールが対応しないチェーンや、独自の検証要件がある場合に限られます。その場合、セッションキーのValidatorはアカウントの資産へ直接つながる部位なので、外部監査を前提に計画します。

逆に、セッションキーが答えにならないケースもあります。大口の資産移転を「便利にする」目的でセッションキーの上限を緩めるのは本末転倒で、それは残すべき署名です。また、複数人の承認を要する法人・DAOの資金管理は、単独の鍵の権限を絞る話ではなく承認フローの問題なので、Safeのモジュラー構成で扱うマルチシグ側の設計になります。

よくある質問

セッションキーをアプリに渡すことは、秘密鍵を渡すことと同じですか？

同じではありません。アプリに渡る（またはアプリが生成する）のはマスター鍵とは別の一時鍵で、ウォレットのアカウントに登録された許可範囲（有効期限・呼び出せるコントラクトと関数・金額や回数の上限）の中でしか使えません。マスター鍵自体はユーザーの手元を離れません。ただし、許可範囲を資産移転まで含めて緩く設定すれば実質的に全権を渡したのと同じになるため、「別の鍵だから安全」ではなく「範囲が狭いから安全」と理解するのが正確です。

MetaMaskのような普通のウォレット（EOA）でもセッションキーは使えますか？

EOAの秘密鍵は権限を絞れないため、EOA単体では使えません。使うには、2025年5月のPectraアップグレードで導入されたEIP-7702でEOAの実行をスマートコントラクトへ委任するか、ウォレットが提供するスマートアカウント機能を有効にする必要があります。MetaMaskの場合、2026年4月に提供が始まったAdvanced PermissionsがMetaMask Smart Accountsを前提にこれを実装しています（2026年8月時点）。

セッションキーが漏洩したら資産はどうなりますか？

攻撃者が実行できるのは、その鍵に登録された許可範囲内の操作だけです。被害の上限は、漏洩の時点ではなく発行の時点で決まります。有効期限が短く、呼び出せる関数が資産移転を含まず、金額・回数の上限が実害の出ない水準であれば、漏洩しても失うものは限定されます。逆にこのどれかが緩いと、その分がそのまま被害上限になります。漏洩に気づいた場合は、ユーザー起点のオンチェーン失効とアプリ側の拒否を即時に行います。

OAuthのアクセストークンと何が違いますか？

「限定した権限を一時的に委任する」という目的は同じで、スコープと有効期限を持つ点も共通です。違いは制約を強制する場所です。OAuthのトークンはリソースを持つサーバが検証するため、サーバの実装不備や侵害で制約が破られ得ます。セッションキーの制約はユーザーのアカウントコントラクトがオンチェーンで検証するため、アプリのサーバが侵害されても、登録済みの範囲を超える操作は実行されません。一方で、オンチェーンの許可は取り消すまで自律的に効き続けるため、失効設計の重要度はOAuthより高くなります。

関連記事

前提と全体像：

• AA完全マップ2026 — スマートアカウント領域の全体俯瞰と本記事の位置づけ
• ERC-4337の事業者向け解説 — UserOperation・EntryPoint・Bundlerの基礎
• EIP-7702の事業者向け解説 — 既存EOAにセッションキーを届けるための前提仕様

組み合わせる設計要素：

• パスキーウォレットの仕組み — マスター鍵側の認証方式
• バッチトランザクションの設計 — 「1回の意思決定を1署名にする」側の解法
• AAセキュリティリスク — アカウント・Bundler・Paymaster3層の攻撃面

実装スタックの選定：

• Kernel（ZeroDev）の採用判断 — Permissionsを含むスタックの評価
• Biconomyの採用判断 — Smart Sessions共同開発元のスタック
• Smart Walletスタック比較2026 — 横並びの選定基準

XTELAが支援できる範囲

セッションキーの導入は、SDKの組み込み作業よりも「どの操作を許可の外に置くか」「漏洩時の被害上限をいくらに設計するか」という権限設計の比重が大きい仕事です。XTELAは、対象プロダクトの操作分解と許可・非許可の設計、実装方式（既製モジュール／ウォレット許可機構／自前実装）の比較選定、許可リスト・上限・失効フローの設計レビュー、embedded walletを含む実装、監査前の設計整理まで、Web3サービスの技術面を支援しています。カストディ該当性など法令・会計・税務の判断は弁護士等の専門家の領域として切り分けたうえで、その検討に必要な技術構成の整理を支援します。

セッションキー・スマートウォレット設計について相談する

主要参考資料

• ERC-4337: Account Abstraction Using Alt Mempool（Final、2026年8月11日閲覧）
• EIP-7702: Set Code for EOAs（Final、2026年8月11日閲覧）
• ERC-7715: Request Permissions from Wallets（Draft、2026年8月11日閲覧）
• ERC-7710: Smart Contract Delegation（Draft、2026年8月11日閲覧）
• ERC-7579: Minimal Modular Smart Accounts（Draft、2026年8月11日閲覧）
• ZeroDev Docs: Permissions (Session Keys)（2026年8月11日閲覧）
• erc7579/smartsessions: SmartSession（Rhinestone × Biconomy、2026年8月11日閲覧）
• Rhinestone Docs: Smart Sessions Overview（2026年8月11日閲覧）
• MetaMask: Introducing Advanced Permissions（2026年4月）
• MetaMask Docs: Advanced Permissions (ERC-7715)（2026年8月11日閲覧）
• Base: From Session Keys to Sub Accounts（2025年2月27日）
• coinbase/spend-permissions（2026年8月11日閲覧）
• Base Docs: Spend Permissions（2026年8月11日閲覧）
• Cartridge Docs: Controller Overview（2026年8月11日閲覧）
• Starknet Blog: Cartridge Controller（2026年8月11日閲覧）

本記事の前提

本記事は2026年8月11日時点で確認した一次情報に基づく技術・事業設計上の論点整理であり、投資助言・法的助言ではありません。各実装の提供状況、対応チェーン、標準（ERC-7715等）のステータスは今後変わり得ます。導入判断の際は最新の公式ドキュメントを確認し、カストディ該当性など法令・会計・税務の判断は有資格の専門家に相談してください。