安全性と使いやすさの綱引きは、Web3のほぼすべての設計判断を規定する。確認画面を増やす、ハードウェアウォレットでの署名を求める、出金に待ち時間を設ける――安全策を一つ加えるたびに使い勝手は下がる。逆に、ワンクリックで取引できる、承認を保存しておく、画面を簡略化する――便利にするたびに攻撃される隙が生まれうる。これは「解決すべき問題」ではなく、「付き合い続けなければならない性質」であり、その中でどこに立つかがプロジェクトのユーザー層、リスクの姿、そして最終的な成否を決める。
「自分で管理する」ことの矛盾
セルフカストディ（自己管理）はWeb3の思想的な基盤である。銀行のような仲介者に頼らず自分で資産を管理できることこそが、分散型金融を従来の銀行と区別する核心だ。しかしセルフカストディは、安全を守る責任をすべてユーザーに負わせる。そして統計的に言えば、人間はセキュリティが苦手だ。
ブロックチェーンの分析企業による調査では、スマートコントラクトへの攻撃よりも、人的なミスのほうが暗号資産の損失原因として多いことがわかっている。紙に書いたシードフレーズは火事や引っ越しで失われる。ハードウェアウォレットは紛失される。詐欺サイトが本物そっくりに作られ、ユーザーは悪意ある取引にうっかり署名してしまう。セルフカストディのモデルは、大多数の人が持ち合わせていない水準のセキュリティ意識を前提にしている。
矛盾はここにある。セルフカストディを手軽にしようとすると、往々にして安全性が犠牲になるのだ。端末に秘密鍵を保存するウォレットは、専用のハードウェア署名デバイスを使うものより便利だが、マルウェアに狙われやすい。トークンの承認を記憶してくれるプロトコルは操作の手間を省くが、承認が残り続ける限り資産がさらされ続ける。安全と便利の綱引きは、仕組みの根幹に織り込まれている。
プロジェクトごとに異なる「線引き」
安全性を最優先にする場合
Gnosis Safe（現Safe）のように、すべての取引に複数人の署名を求め、支出上限を設定し、各署名者にハードウェアウォレットの使用を推奨するプロジェクトがある。設定は複雑で、取引には署名者間の調整が必要で、簡単な操作でも通常のウォレットより大幅に時間がかかる。
このアプローチはDAO（分散型の自治組織）の資金管理や機関投資家の資産保管など、守るべき価値が手間を正当化する場面に向いている。しかし、すぐに反応してほしい一般向けアプリには向かない。
使いやすさを最優先にする場合
反対の極にはFriend.techのようなアプリがあった。登録時にウォレットを自動で作成し、秘密鍵をサーバー側で管理する方式だ。ユーザーはウォレットの存在を意識することなくトークンの売買ができた。まるでWeb2のアプリを使っているのと同じ感覚だった。
安全面の代償は大きい。秘密鍵の管理をアプリの運営者に委ねることは、中央集権的な障害点を自ら作ることになる。サーバーが攻撃されれば全ユーザーのウォレットが危険にさらされる。手軽さは本物だったが、管理リスクも本物だった。暗号資産に慣れていないユーザーの取り込みには成功したが、セキュリティを重視するコミュニティからは批判を浴びた。
段階的にセキュリティを高める方式
最も有望なアプローチは「段階的セキュリティ」だ。最初はシンプルで安全性の低い状態から始め、ユーザーの関与度や資産額の増加に応じて保護を徐々に厚くしていく。新規ユーザーはパスキー認証（指紋や顔認証）で使えるスマートウォレットと、信頼できる人を通じた復旧機能からスタートする。残高が増えたらアプリがハードウェアウォレットの追加を提案する。一定額を超えたら複数署名の構成を推奨する。
この仕組みは従来の金融と似ている。銀行口座を開くのは簡単だ。貸金庫にアクセスするには追加の本人確認がいる。大口送金には追加の確認が入る。安全策は最初から最大限に盛り込むのではなく、リスクに応じて段階を踏む。
スマートコントラクトにも同じジレンマがある
安全性と使いやすさの綱引きは、ウォレットだけでなく、ユーザーが操作するスマートコントラクトにも及ぶ。プロトコル設計者は、コントラクトにどこまで安全装置を組み込むかを決める際に同じ緊張と向き合う。
運営方針の変更に待機期間（タイムロック）を設ければ、ユーザーは変更内容を確認する時間を得られるが、プロトコルの進化は遅れ、先回り取引の機会を生む。出金に遅延を設ければフラッシュローン攻撃（一瞬で巨額を借り入れて悪用する手口）から守れるが、すぐに資金を使いたいユーザーは困る。預入上限を設ければ未発見の脆弱性による壊滅的損失を防げるが、資金効率は下がる。
コントラクト自体を変更不能（イミュータブル）にすれば最大の安全性が得られる――開発者ですらコードを書き換えられない。しかし脆弱性が見つかっても修正できない。更新可能にすれば問題への対応はできるが、更新権限を持つ者が悪意ある変更を加えないという信頼が必要になる。どの選択も、安全と便利のスペクトラム上の位置取りを表している。
DeFiでの被害の歴史は、このバランスを誤るコストを物語っている。組み合わせの自由さ（コンポーザビリティ）と資金効率を優先したプロトコル――フラッシュローン、無制限の承認、複雑な連携を許容するもの――が攻撃の主な標的となってきた。制限の多い設計のプロトコルは被害が少ないが、預かる資金も利用者も少ない。
「トークン承認」に見る縮図
トークン承認は、安全と便利のジレンマを最も凝縮した形で表している。DeFiプロトコルを使う際、ユーザーはまず「このコントラクトがあなたのトークンを使ってよい」という許可を出す必要がある。便利さを優先するなら「無制限」の金額を承認する。一度やれば二度目はない。安全を優先するなら「必要な金額だけ」を毎回承認する。操作のたびに一手間増えるが、許可が残り続けることはない。
無制限の承認は常に存在する攻撃の窓口だ。承認先のコントラクトが攻撃されたり、未知の脆弱性を含んでいた場合、攻撃者はユーザーのトークン残高を丸ごと抜き取れる。忘れた承認を整理するためだけにRevoke.cashのようなツールが存在する。本来あってはならないカテゴリのツールだ。
業界はパーミット方式（EIP-2612）に向かいつつある。署名ベースで、手数料不要の、使い切りの承認を可能にする仕組みだ。一回ごとの操作の手軽さと、許可が残らない安全性を両立する。しかし普及は道半ばであり、古いプロトコルの多くは依然として従来の承認方式に頼っている。
最適な立ち位置はケースバイケース
安全と便利のスペクトラム上で最適な位置は、文脈によって変わる。一般ユーザー向けのアプリは使いやすさを標準にし、安全機能は希望者だけが有効にすべきだ。大きな資産を扱う金融インフラは安全性を標準にし、熟練者向けに操作を効率化する道を用意すべきである。
多くのプロジェクトが犯す間違いは、すべてのユーザーに同じ安全態勢を適用することだ。5ドルの交換にハードウェアウォレットの確認を求めるDeFiプロトコルは一般ユーザーを失う。500万ドルのポジションにワンクリック取引を許す同じプロトコルは機関投資家を失う。「状況に応じた安全対策」――手間の重さがリスクにさらされる金額に応じて変わる方式――が最も合理的だ。
アカウント抽象化（スマートコントラクト型ウォレット）は、この「状況適応型セキュリティ」を技術的に実現する鍵になる。取引の金額、送金先、時間帯などに応じて異なるルールを自動適用できるのだ。たとえば100ドル以下の交換はパスキー確認だけで済ませ、1万ドル以上の取引はハードウェアウォレットの署名と15分の待機を求める。一律に最大限の手間を求めるのではなく、必要なだけの安全策をユーザーが体感できる。
まとめ
- 安全性と使いやすさの綱引きはWeb3の構造的な性質であり、セルフカストディと自由参加型システムの設計に織り込まれている
- スマートコントラクトへの攻撃よりも人的ミスのほうが暗号資産の損失原因として多いが、セルフカストディのモデルは高いセキュリティ能力を前提にしている
- 段階的セキュリティ――シンプルに始め、リスク増大に応じて保護を追加する方式――は従来の金融の手法に倣い、最初の障壁を下げる
- トークン承認は問題の縮図である。無制限の承認は便利だが常時攻撃可能な状態を生む
- アカウント抽象化により、取引額に応じて手間が変わる「状況適応型」の安全策が実現可能になりつつある
安全と便利の緊張が完全に解消されることはない。ユーザーに資産の直接管理を委ねるシステムの本質的な性質だからだ。成功するプロジェクトは、この現実を受け入れたうえで、どちらかの極端に倒れるのではなく、意識的に設計する。目標はジレンマの消去ではなく、ユーザーごと、取引ごと、場面ごとに、最適な立ち位置を見極めることだ。