--- 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. # マルチシグ署名者のローテーション > 教育目的の情報であり、投資、法律、セキュリティに関する助言ではありません。署名者ローテーションの誤りは、制御権の移転、保留中の承認の無効化、またはマルチシグアカウントの永久的なロックにつながる可能性があります。 ## 直接の答え マルチシグ署名者のローテーションは、トランザクションの承認権を持つアカウントを変更します。通常、新しいウォレットアドレスや資産移転は不要で、権限の強いトランザクションによってアカウントの所有者集合と、場合によっては承認しきい値を変更します。実装ごとに仕組みが異なるため、画面のラベルが権限を正しく表していると決めつけず、デプロイ済みコントラクトと現在のオンチェーン状態を確認してください。 安全なローテーションでは、まず各新規署名者の制御を証明し、変更中を通じて実行可能かつ集中していないクォーラムを維持し、旧署名者を削除して最終状態をオンチェーンで確認します。実行前に必要なクォーラムを失うと通常の所有者変更が不可能になり得ます。利便性のためにしきい値を下げると、乗っ取り可能な時間帯が生じます。 担当者、署名デバイス、秘密鍵、オンチェーン所有者アドレスは別々の記録です。正確なアドレス、管理者、独立した管理領域、バックアップ状態、ローテーション理由を記録してください。正当なローテーションでシードフレーズや秘密鍵の開示を求めることはありません。 ## 仕組み 1. **現在の権限を棚卸しする。** 独立に検証したチェーンとアカウントアドレスから、デプロイ済み実装、所有者一覧、しきい値、nonce、有効なモジュール、guard、fallback handler、復旧経路、timelock を読み取ります。モジュールや復旧機構は通常の所有者しきい値を経ずに実行できる場合があり、制限的な guard は本来有効なローテーションを拒否する場合があります。 2. **署名前に目標状態を定義する。** 変更後の正確な所有者集合としきい値を記録します。しきい値が所有者数を超えず、少なくとも同数の独立した署名者が稼働し続けることを確認します。全デバイスを同じ人物、パスワード保管庫、クラウドアカウント、または管理者が制御するなら、地理的に離れていても独立ではありません。 3. **新規署名者を登録して認証する。** 想定した保管環境で新しい鍵を生成または復元し、信頼できるデバイス上でアドレスを確認し、合意したチャレンジまたはテスト署名で制御を証明します。別の認証済み経路でもアドレスを確認し、コピーされたチャット文面やウォレット画面だけに依存しないでください。 4. **安全な中間状態を保つ順序を選ぶ。** 所有者を原子的に交換できるコントラクトがあります。たとえば Safe は `swapOwner` を公開し、`addOwnerWithThreshold`、`removeOwner`、`changeThreshold` も公開しています。複数のトランザクションが必要な実装では、各手順後の所有者集合としきい値を分析します。進行中の侵害によってその順序が危険になる場合を除き、削除前に能力を追加して検証します。 5. **正確なトランザクションをデコードしてシミュレーションする。** chain ID、アカウントアドレス、target、関数セレクター、新旧所有者アドレス、変更後のしきい値、nonce、value、操作種別を独立に確認します。`delegatecall`、バッチ処理、モジュール変更、guard 変更は、それぞれ別の高リスク効果として扱います。全署名者が同じデコード済み payload とトランザクションハッシュを承認する必要があります。 6. **既存の権限で実行する。** 文書化された復旧経路に別の定めがない限り、現在の有効なクォーラムがローテーションを承認します。緊急時は認証済み連絡先だけで調整し、侵害されていない署名者を使用します。通常クォーラムも事前設定済み復旧権限も利用できない場合、標準の所有者管理呼び出しではアクセスを復元できません。 7. **変更を検証して完了する。** 確認後、所有者集合としきい値を直接照会し、必要に応じて発行イベントまたは trace を調べ、旧アドレスが認可されていないことを確認します。新規署名者に、意図したしきい値を必要とする承認済みの低リスクまたはゼロ価値トランザクションへ参加してもらいます。保留中のトランザクションを確認し、旧署名者のオフチェーンアクセスとバックアップを失効させ、提案、署名、トランザクションハッシュ、ブロック、最終状態を保存します。 ## 実例 `3-of-5` アカウントの所有者を `A`、`B`、`C`、`D`、`E` とし、`B` を `F` に交換するとします。チームはまず、`F` が提案された正確なアドレスを制御し、他の所有者から独立していることを確認します。互換性のある Safe デプロイでは `swapOwner(prevOwner, B, F)` を用意します。この呼び出し自体が Safe トランザクションであるため、現在の所有者集合から `3` 件の有効な確認が必要です。デコード結果では所有者数が `5`、しきい値が `3` のままになる必要があります。 トランザクション確認後、チームは `getOwners` と `getThreshold` を読み、`B` がなく `F` が存在することを確認し、`F` とほかの二人の所有者で承認済みの `0` 価値テストを実行します。保留中のトランザクションも見直します。削除後は `B` の署名や事前承認が所有者チェックを満たさない可能性があるため、影響する提案は実行可能だと決めつけず、取り消すか再作成する必要があります。 `B` が侵害された可能性がある場合、チームはその署名者に削除の承認を求めません。侵害されていないほかの三人の所有者が交換を実行し、その後にモジュール、復旧権限、allowance、session key、実行済みトランザクションを調べます。`B` を削除しても過去の操作は戻らず、別経路で付与された権限も失効しないためです。利用可能な未侵害所有者が `3` 人未満なら、以前に設定した復旧または管理経路だけが助けになる可能性があります。シードフレーズの共有や、依頼していない「復旧」サービスへの信頼はクォーラムの代わりになりません。 ## リスクと対策 - **アカウントまたはアドレスの誤り。** chain ID、マルチシグアドレス、実装、新規所有者アドレスを独立したデバイスと情報源で確認します。アドレスポイズニングやコピー誤りは攻撃者に制御権を与えます。 - **クォーラム喪失。** すべての中間状態をモデル化します。所有者を早く削除しすぎる、利用可能な署名者数を超えてしきい値を上げる、相関する複数デバイスを同時に交換する、といった操作でアカウントが利用不能になります。 - **一時的な集中。** 低いしきい値や新規署名者により、少数の当事者だけでアカウントを制御できる時間帯が生じます。対応している場合は原子的交換を優先し、手続きを簡単にするためだけにしきい値を下げないでください。 - **相関した保管。** 異なるアドレスでも、シード、デバイス、バックアップ、通信、管理者が同じ障害領域を共有すれば独立ではありません。秘密を集中させずに復旧をテストします。 - **隠れた権限。** モジュール、guard、fallback handler、session key、timelock、復旧コントラクトは所有者経路を迂回または阻止できます。ローテーション前後に棚卸しして確認します。 - **侵害署名者との競争。** 削除が確定する前に、疑わしい署名者が先回りし、資産を移動し、設定を変更し、別のトランザクションを承認する可能性があります。インシデント手順、適切な場合のプライベート送信、継続的な状態監視を用い、提出済みトランザクションが競争に勝ったと決めつけないでください。 - **古い保留承認。** 所有者やしきい値の変更により、収集済み署名が無効になったり、十分な承認の条件が変わったりします。最終状態に対して待機中の全トランザクションを再評価し、古い提案を取り消します。 - **誤った完了判定。** 画面の成功通知は意図した状態の証明ではありません。必要な確認方針を満たすまで待ち、コントラクト状態を読み、トランザクションの payload、イベント、実行結果を確認します。 - **不完全なオフボーディング。** オンチェーン所有者を削除しても、複製された鍵、組織アクセス、relayer 認証情報、パスワード保管庫の項目、他のコントラクトやチェーンの権限は消えません。それぞれを失効させ、監査記録を残します。 ## よくある誤解 - **「ローテーションとは全資産を新しいウォレットへ移すことだ。」** 多くのスマートアカウント型マルチシグは、同じアカウントアドレスで所有者を更新します。移行は別の操作で、特定の実装やインシデント計画でのみ必要になる場合があります。 - **「新規署名者を先に追加すれば常に安全だ。」** 可用性は守れますが、認可された集合を一時的に広げる可能性があります。侵害が進行中なら、原子的交換や別の緊急順序の方が安全な場合があります。 - **「`3-of-5` しきい値なら、指定された三人の誰でも利用できる。」** コントラクトが数えるのは有効な所有者アカウントであり、人、部署、デバイスではありません。共有保管やアクセス不能な鍵は実効的な独立性と可用性を下げます。 - **「侵害された所有者を削除すれば被害は元に戻る。」** 確認後、その所有者経路の将来利用は防げますが、実行済みトランザクションや別の場所で作成された権限は取り消されません。 - **「ウォレット画面だけで十分な証拠になる。」** 画面やインデックスサービスは古い、誤設定、または悪意ある可能性があります。トランザクションをデコードし、独立に検証した endpoint から最終コントラクト状態を読みます。 - **「クォーラムがなくてもサポートがウォレットをリセットできる。」** 自己管理型マルチシグには、オンチェーンに符号化済みか事前設定済みの権限経路しかありません。有効なクォーラムや復旧経路がなければ、アクセスは永久に失われる可能性があります。 ## 関連トピック - [ハードウェアウォレット](/ja/crypto/hardware-wallet/) - [マルチシグウォレット](/ja/crypto/multisig-wallet/) - [秘密鍵管理](/ja/crypto/private-key-management/) - [スマートアカウント所有者の復旧リスク](/ja/crypto/smart-account-owner-recovery-risk/) - [トランザクションシミュレーション](/ja/crypto/transaction-simulation/) ## 出典 - [Safe スマートアカウントの仕組み](https://docs.safe.global/advanced/smart-account-overview) - Safe Documentation（参照日: 2026-08-21） - [addOwnerWithThreshold](https://docs.safe.global/reference-smart-account/owners/addOwnerWithThreshold) - Safe Documentation（参照日: 2026-08-21） - [removeOwner](https://docs.safe.global/reference-smart-account/owners/removeOwner) - Safe Documentation（参照日: 2026-08-21） - [swapOwner](https://docs.safe.global/reference-smart-account/owners/swapOwner) - Safe Documentation（参照日: 2026-08-21） - [changeThreshold](https://docs.safe.global/reference-smart-account/owners/changeThreshold) - Safe Documentation（参照日: 2026-08-21） - [OwnerManager.sol](https://github.com/safe-fndn/safe-smart-account/blob/main/contracts/base/OwnerManager.sol) - Safe Ecosystem Foundation（参照日: 2026-08-21） - [鍵管理の推奨事項：パート 1 - 一般](https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final) - NIST（参照日: 2026-08-21） Source: https://wiki.fcontext.com/ja/crypto/multisig-signer-rotation/index.mdx