企業のWeb3ウォレット管理｜権限・復旧・担当者交代で決めること

「担当者が休んだら、会社のウォレットを誰が動かせる？」

実証を急ぐうちに、一人の担当者だけが操作と管理を抱えていませんか。

取引の承認、秘密情報の保管、担当者交代の手順が曖昧なままだと、不在や退職のたびに業務が止まりかねません。

日常の取引を動かす権限と、権限を変更・復旧する仕組みを分けて設計しましょう。

この記事では企画・管理・情報システム担当者が一緒に確認できるよう、用途、責任者、承認方法、記録、引き継ぎを整理します。

後半の業務フローと確認表を使い、製品を選ぶ前に決めることを洗い出せます。

ウォレット・アカウント・秘密鍵の違い

ウォレットは、ブロックチェーン上のアカウントを操作するための道具です。

残高の確認や取引への署名などに使います。

アドレスは送付先などを識別する情報であり、秘密鍵は署名に使う秘密の情報です。

画面を開くためのログイン情報と、取引を動かす権限を、同じものとして扱わないようにしましょう。^[1]

秘密鍵を利用する方式では、その管理が取引の安全性に直結します。

ウォレットによっては、シークレットリカバリーフレーズやシードフレーズと呼ばれる情報から鍵を復元します。

こうした復旧情報も、通常の業務資料やチャットに貼り付けてよい情報ではありません。^[2]

ログインできる人と、資産を動かせる人を確かめる

社内のアカウント管理では、退職者のログインを停止すれば対応が終わる場合があります。

一方、ウォレットでは画面へのアクセスを止めても、別の端末などで利用できる秘密鍵や署名権限が残っていれば、十分な対処にならない可能性があります。

導入時には、管理画面の利用者、署名するアカウント、鍵の保管先、管理権限を変更できる人を一覧にします。

委託先が管理する部分も含め、どこを自社で変更できるかを確認してください。

保管方式を名前だけで判断しない

利用者側が鍵を管理する方式と、サービス提供者などに管理を委ねる方式では、復旧や本人確認、利用停止への対応が異なります。

さらに、複数の関係者や技術を組み合わせる構成もあります。

比較するときは「誰が最終的に取引を成立させられるか」「自社だけで復旧できるか」「提供者が停止したらどうなるか」を質問します。

「法人向け」「安全」という名称だけでは、自社の承認ルールに合うかは判断できません。

最初に作るのはウォレットの管理台帳

複数のウォレットを使い始める前に、用途と責任者を記録します。

台帳の目的は秘密情報を一か所に集めることではなく、どの仕組みを誰が管理し、変更時に何を確認するかを共有することです。

秘密鍵や復旧フレーズそのものは載せません。

台帳の項目	記録する内容の例
用途	実証用、特典配布用、サービス運営用など
対象	ネットワーク、アドレス、扱うトークンや権限
責任者	業務責任者、技術担当、代替担当
取引の条件	承認者、署名者、上限や対象先のルール
管理の仕組み	鍵の保管方式、署名に必要な条件、委託範囲
復旧の方針	手順書の保管先、実施する担当、確認した日
点検と変更	最終点検日、権限変更の記録、次回確認日

保有するトークンだけでなく、NFTの発行権限やスマートコントラクトの管理権限なども対象にします。

残高が少ないアカウントであっても、重要な設定を変更できるなら、影響の大きい管理対象です。

実証用と本番用の用途は分けて考えます。

検証のために接続するサービスが増える環境に、本番で必要な権限をまとめて持たせない構成を検討すると、点検する範囲を整理できます。

取引を動かす前の承認と署名を設計する

社内承認とブロックチェーン上の署名は別の確認

社内の稟議で承認されていても、署名時の宛先や数量が異なっていれば、承認した内容とは違う取引が成立する可能性があります。

反対に、技術上は実行できても、社内の権限規程に沿わない操作も起こり得ます。

申請には、目的、宛先、ネットワーク、対象トークン、数量、実行期限を記載します。

署名する担当者は、その申請とウォレットに表示された内容を照合します。

作成した人だけで確認を完結させず、別の担当者が相手先や条件を確認できる流れを設計しましょう。

以下の図は、通常の取引に対する社内の役割を整理した例です。

会社の規模に合わせて兼務はできますが、どの確認を省略しないかを明確にします。

参考：Safe公式資料・RecoveryHub公式案内。

マルチシグで解決できる範囲を理解する

マルチシグは、複数の署名を取引の実行条件にする仕組みです。

たとえばSafeでは、登録した署名者と、実行に必要な署名数を設定する構成が案内されています。

署名者が３つ、必要な署名数が２つなら、所定の２つの署名がそろうことが実行条件になります。^[3]

ただし、複数の署名者が同じ誤った宛先を承認すれば、誤りを防げるとは限りません。

また、別々のアカウントでも同じ人がすべてを管理していれば、組織としての役割分担は実現できていません。

必要な署名数だけでなく、担当者の独立性、保管場所、休日や不在時の対応を合わせて考えます。

条件を厳しくしすぎて業務が止まる場合と、少人数で重要な操作ができすぎる場合の両方を確認してください。

製品によっては、署名以外の管理モジュールや委任機能を追加できます。

通常の署名条件を見ただけで全体の権限を把握したつもりにならず、例外的に取引や設定変更を可能にする仕組みも導入担当者へ確認します。

署名直前に使う照合表

申請書に承認が付いていても、署名画面で同じ内容を確認できなければ、そのまま実行しません。

次の表を申請記録と並べると、何を確認したかを後から追いやすくなります。

数値や宛先をコピーしただけで照合を省略せず、内容が変わった場合は再承認に戻します。

照合項目	記録する内容	実行を止める例
目的と操作	送信・利用許可・権限変更などの区分	申請の目的と署名画面の操作が違う
対象と数量	ネットワーク、対象資産、送信先、数量	想定外のネットワークや宛先になっている
許可と負担	与える権限の範囲、手数料の扱い	説明できない権限や想定外の負担がある
承認と実行結果	承認者・署名者・実行日時・確認結果	必要な承認や独立した確認が揃わない

画面で意味を確かめられない項目は、空欄のまま実行へ進めず、技術担当者や契約先へ確認する対象にします。

台帳には確認結果と手順書の所在を記録し、秘密鍵や復旧フレーズは書き込みません。

通常取引の記録と秘密情報の保管を混在させないようにします。

復旧は事前に用意する業務

「復旧できる」とは何が戻ることか

端末の故障、担当者の退職、秘密情報の紛失、秘密情報の流出は、異なる事象です。

同じ手順で解決できるとは限りません。

端末を交換すれば済むのか、署名者を入れ替えるのか、アカウント自体を移行するのかを分けて考えます。

特に秘密鍵や復旧フレーズを失った場合、一般的なパスワード再発行のように戻せるとは限りません。

採用した方式に復旧機能があるか、事前設定が必要か、どの関係者の協力が必要かを確かめます。^[1]

通常の署名者と、復旧を実行する人を見直す

SafeのRecoveryHubには、事前に設定した復旧担当のアカウントが、署名者や必要署名数の変更を提案する仕組みがあります。

提案から実行までの待機期間があり、条件を満たす既存の署名者が拒否することもできます。

これは、復旧の設定と運用を前もって用意する必要がある具体例です。^[4]

この機能がすべてのウォレットに備わっているわけではありません。

また、復旧できる権限は強い権限でもあります。

復旧担当の保護、提案を見つける監視、望まない変更を止める手順まで含めて検討します。

通常の取引は複数人で承認するのに、復旧を１人で自由に進められる構成では、日常の管理ルールを迂回する経路が残ることがあります。

通常時と復旧時を別々の表にして照合すると、見落としを減らせます。

参考：Safe公式資料・RecoveryHub公式案内。

復旧訓練では秘密情報を配らない

訓練では、連絡先が使えること、担当者が手順書を見つけられること、必要な承認を取れることを確認します。

検証用の環境や影響を限定した方法を使い、本番の秘密情報を会議資料やスクリーンショットに残さないようにします。

記録するのは、実施日、参加者、確認した範囲、かかった時間、解決できなかった項目です。

「復旧できた」という結果だけでなく、何を失った想定で、どの機能を確認したのかを残すと、次の担当者が判断できます。

取引先への送付と外部サービス接続で確認すること

宛先・ネットワーク・数量を組み合わせて照合する

宛先のアドレスは、請求や契約などの業務上の相手と結び付けて確認します。

メッセージで突然通知された変更をそのまま採用せず、既知の連絡経路で照合するルールを設けると、なりすましへの対処を組み込めます。

アドレスだけでなく、ネットワーク、対象トークン、数量、必要な手数料も確認します。

少額で試す場合でも、それだけで相手先やサービス全体の信頼性が確認できたとは扱わないようにします。

一度成立した取引を、銀行振込の組戻しと同じ感覚で取り消せるとは限りません。

送付前に宛先と取引内容を確かめることが必要です。^[2]

接続解除とトークンの利用許可を区別する

外部サービスを使う際には、トークンを動かす許可を与える操作が必要になる場合があります。

MetaMaskの公式説明では、ウォレットをサービスから切断する操作と、トークンの利用許可を取り消す操作は区別されています。

切断だけでは、すでに与えた許可が残る場合があります。^[5]

業務では、接続したサービス名だけでなく、何の許可を、どの範囲で与えたかを記録します。

検証が終わったサービスや、使わなくなった許可は定期的に見直します。

署名画面に表示される内容が分からない場合は、承認したまま調べ始めないようにします。

技術担当者などが内容を確認し、社内で認めた操作かを判断する手順を設けてください。

秘密情報の流出はパスワード変更だけで扱わない

アプリを開くためのパスワードを変えても、流出した秘密鍵そのものが無効になるわけではありません。

秘密情報の流出と、特定のサービスへの許可の問題を区別して対応する必要があります。^[2][6]

異常を疑ったときは、追加の署名や入金を急がず、決めておいた責任者へ連絡します。

影響する権限、未実行の取引、管理先を調べ、採用方式に応じた権限変更や移行を専門担当者と判断します。

知らない相手の「復旧サポート」に秘密情報を渡さないことも共有しておきましょう。

担当者が交代するときの確認表

担当者交代は、アカウント名簿を書き換えるだけでは終わりません。

ウォレット本体、関連サービス、バックアップ、復旧に関わる権限を対象にします。

対象	交代時に確認すること
管理画面	旧担当者の権限解除、新担当者と代替担当の登録
署名者	旧アカウントの扱い、必要署名数、実行可能な状態
復旧の担当	復旧権限、待機期間、通知・監視をする人
端末・保管物	管理端末、機器、バックアップの所在と扱い
外部サービス	接続先、APIなどのアクセス権、残っている許可
運用の記録	取引履歴、未処理の申請、委託先との連絡経路

旧担当者が秘密鍵を保持し得る構成では、共有パスワードの変更で済ませず、その権限を無効にできる方法や新しい管理先への移行を検討します。

引き継ぐべき業務記録と、そのまま引き継ぐべきでない秘密情報を分けて扱います。

交代後には、新しい体制で必要な操作ができるかを確認します。

旧担当者のアクセスを消した結果、残った署名者だけでは実行条件を満たせなくなる構成にも注意してください。

小さく始めるための導入手順

管理の点検は、定期的な確認だけでなく、新しいサービスの利用、担当者交代、外部委託の変更、権限設定の変更があった際にも行います。

対象と責任者を台帳に戻しておくことで、変更が重なっても現在の状態を把握できます。

企業のウォレット管理についてよくある質問

マルチシグにすれば、管理ルールは不要ですか？

不要にはなりません。

複数の署名を必要とする構成でも、誤った取引内容を全員が承認する可能性があります。

申請内容との照合、署名者の役割分担、復旧権限の管理を合わせて設計します。

復旧フレーズを社内の共有フォルダに保存してもよいですか？

通常の共有資料として扱うことは避けます。

閲覧や同期によって秘密情報が広がる可能性があるためです。

採用方式に応じて保管・アクセス・復旧の手順を定め、台帳には秘密情報そのものではなく、管理責任者と手順書の所在を記録します。^[2]

ウォレットの接続を切れば、外部サービスの権限も消えますか？

接続解除だけではトークンの利用許可が残る場合があります。

どのサービスにどの許可を与えたかを確認し、必要に応じて許可の取り消しを行う手順を用意してください。^[5]

製品選びの前に、権限と復旧を言葉にする

企業でのWeb3ウォレット管理は、取引の申請から署名、記録、復旧、担当者交代までをつなげる仕事です。

誰が何をできるかを見える形にし、例外時にも業務を戻せることを確かめてから、利用する範囲を広げていきましょう。

事業での活用についてはOMKのWeb3事業、基本的な注意点はよくある質問・リスク説明もご覧ください。

参考資料

1. ethereum.org｜Ethereum wallets ↩
2. ethereum.org｜Ethereum security and scam prevention ↩
3. Safe Docs｜Glossary — Multi-signature / Owner / Threshold ↩
4. Safe Knowledge Base｜Account recovery with Safe{RecoveryHub} ↩
5. MetaMask Help Center｜How to disconnect a wallet from a dapp ↩
6. Revoke.cash｜Frequently asked questions ↩

確認日：2026年９月14日。

機能・条件は変更される場合があります。

本文の設計表・運営例・図解は、出典を示した事実を踏まえたOMK編集部の整理です。