Safe（旧Gnosis Safe）のモジュラー構成と採用判断｜法人・DAO・機関のマルチシグ標準基盤

法人・DAO・機関投資家が暗号資産を複数人の承認で共同管理する用途では、Safe（旧Gnosis Safe）が2026年8月時点でも事実上の標準であり、第一候補として検討を始めてよい基盤です。Safeのコントラクトでデプロイされたウォレットは5,700万件を超え、600億ドル超の資産を保全し、累計1兆ドルを超える取引を処理してきました（Safe公式サイト、2026年8月11日閲覧）。ただしこの評価には2つの条件が付きます。第一に、Safeが強いのは「複数人の合意をオンチェーンで強制する共同管理」であり、エンドユーザーへ大量配布するウォレットや、Bitcoin・SolanaなどEVM（Ethereum Virtual Machine：Ethereum系チェーンの実行環境）以外を含む鍵管理には別のスタックが向きます。第二に、2025年2月のBybit事件（約15億ドル相当の流出）で破られたのはSafeのコントラクトではなく、署名UIの供給網と署名者の検証運用でした。したがってSafeの採用判断は「どのコントラクトを使うか」だけでは完結せず、「署名者が何をどう検証するか」という運用設計まで含めて初めて成立します。

本記事は、Safeのモジュラー構成（本体・Module・Guard）、後付けできる機能、Bybit事件の教訓、向き不向きの判断、導入形態と設計論点までを、2026年8月時点の一次情報で整理します。スマートアカウント領域全体の俯瞰はAA完全マップ2026、他スタックとの横並び比較はSmart Walletスタック比較で扱っているため、本記事はSafeそのものの理解と採用判断に集中します。

Safeの現在地 — 旧Gnosis Safeとの関係と、いま誰が開発しているか

日本語の解説記事では「Gnosis Safe」の名称が今も多く使われていますが、これは旧称です。Safeは2017年にGnosisの共同創業者が作ったマルチシグ（複数の署名が揃って初めて実行される仕組み）ウォレットを起源とし、2018年に汎用のスマートアカウント基盤「Gnosis Safe」として公開されました。2022年にGnosisDAOの提案（GIP-29）を経てGnosisから独立し、1kx主導の1億ドルの資金調達とともに「Safe」へリブランドしました。以後はスイスのSafe Ecosystem FoundationとガバナンストークンSAFEを持つSafeDAOがエコシステムを統治しています（Safe Foundation: History of Safe）。

現在の製品群は、役割の異なる3つの名前で構成されます。

• Safe Smart Account：オンチェーンに展開されるコントラクト本体。資産と署名ルールを保持します。
• Safe{Wallet}：公式のWeb・モバイルUI。Smart Accountの作成・署名・管理を行います。
• Safe{Core}：開発者向けのSDK・インフラ群。自社アプリへの組み込みに使います。

開発体制も2025年に変わりました。Safe Ecosystem Foundationは2025年6月、商業子会社Safe Labsの設立を発表し、元Chief Product OfficerのRahul Rumalla氏をCEOとして、Safe{Wallet}を機関・企業向けに強化する方針を示しています（CoinDesk、2025年6月11日、Safe Labs）。個人の草の根プロジェクトではなく、財団・DAO・商業子会社の三層で継続開発される基盤である点は、長期運用する法人にとっての選定材料になります。

モジュラー構成の仕組み — 本体・Module・Guardの3層

Safe Smart Accountの中核は、シンプルなM-of-Nマルチシグです。署名権限を持つアドレス群（Owner）と、実行に必要な署名数（Threshold：しきい値）を設定し、しきい値分の署名が揃ったトランザクションだけがexecTransactionで実行されます。誰がいつ承認したかの証跡はチェーン上に残るため、承認プロセス自体が改ざん困難な監査ログになります。

「モジュラー」と呼ばれる理由は、このコアを変更せずに機能を足せる拡張ポイントが規格化されていることです。

• Module（モジュール）：enableModuleで登録された外部コントラクトで、通常の署名チェックを経ずに、定義済みのロジックに従ってSafeからトランザクションを実行できます（execTransactionFromModule）。後述するSpending LimitやRecoveryはこの仕組みで実装されています。公式ドキュメントは「Moduleは任意のトランザクションを実行できるためセキュリティリスクになり得る。信頼でき監査されたModuleだけを追加すべきで、悪意のあるModuleはSafeを乗っ取り得る」と明確に警告しています（Safe Docs: Safe Modules）。
• Guard（ガード）：バージョン1.3.0で導入された検証フックで、すべてのトランザクションの実行前（checkTransaction）と実行後（checkAfterExecution）に追加チェックを差し込めます。送金先の許可リストや金額上限の強制に使われます。一方で、Guardに不具合があるとSafe全体のトランザクションが実行不能（DoS：サービス不能）になり得るため、Guard自体の監査と復旧手段の設計が必要です（Safe Docs: Safe Guards）。

この2層には長らく構造的な穴がありました。Moduleが実行するトランザクションはGuardの検証を通らないという点です。2025年7月22日にリリースされたSafe v1.5.0は、これを塞ぐModule Guardsを導入し、Module発のトランザクションにも統制ルールを強制できるようにしました。v1.5.0はCertoraとAckeeの監査を経て公開され、対応ネットワークでデプロイに利用できます。ただし既存のSafeが自動で新バージョンに更新されるわけではなく、Module Guardsを使うにはv1.5.0でのデプロイまたは明示的な移行が必要です（Safe Foundation: Introducing Safe v1.5.0）。

Moduleで何を後付けできるか — 公式Moduleと外部エコシステム

公式リポジトリ（safe-fndn/safe-modules）で保守されている主なModuleは次のとおりです。

• Allowance Module（Spending Limit）：指定したアドレスに、トークンごと・期間ごとの上限額まで、他の署名者の承認なしで送金できる権限を与えます。上限は1回限りか、日次・週次・月次でリセットされる設定を選べます（Safe Help: Spending Limits）。「日常の運用送金は少人数で速く、大口はしきい値どおり厳格に」という二段構えを、規程ではなくコントラクトで強制できます。
• Social Recovery Module：事前に指定したGuardian（復旧承認者）の合意と待機期間を経て、Ownerを差し替えます。鍵紛失への保険であると同時に、乗っ取り経路にもなり得るため待機期間の設計が重要です。設計パターンはSocial Recoveryの実装パターンで詳述しています。
• Safe 4337 Module：ERC-4337（AA〈Account Abstraction：アカウントアブストラクション〉の標準規格の一つ。コントラクト型アカウントを標準化された経路で動かす）の実行経路をSafeに後付けし、ガス代肩代わりなどAA系インフラと接続します。規格自体はERC-4337の事業者向け解説を参照してください。
• Passkey Module：パスキー（顔・指紋などの生体認証を使うFIDO2ベースの認証鍵）をOwnerとして使えるようにします。署名者の端末・鍵管理のUXを変える選択肢で、詳細はパスキー×ERC-4337の解説で扱っています。

公式Module以外にも2つの供給源があります。DAO運用では、Gnosis Guildが保守するZodiacシリーズ（投票結果のオンチェーン実行、遅延実行など）が広く使われています（gnosisguild/zodiac）。またSafeはRhinestone・Pimlicoと共同開発したSafe7579アダプタにより、モジュール規格ERC-7579に準拠して開発された外部Moduleを取り込む経路も整備しています（Safe Docs: Safe and ERC-7579）。

モジュラー構成の実務上の価値は、最初は素のマルチシグとして開始し、統制要件が固まった段階で必要な機能だけを足せることです。コアは長期の実戦投入と監査を経た共通部分のまま、自社固有の要件はModule単位で追加・監査すればよく、全体を作り直す再設計を避けられます。裏返せば、Moduleは前述のとおりSafeの全権を握り得る存在なので、「便利だから入れる」ではなく、導入審査・監査・Module Guardによる制約を前提に運用する必要があります。

Bybit事件が示したこと — 破られたのはコントラクトではなく署名の運用

Safeの採用を検討する際に避けて通れないのが、2025年2月21日に発生したBybitからの約15億ドル相当の暗号資産流出です。FBIは2025年2月26日、北朝鮮の攻撃グループ（TraderTraitor）によるものと公表しました（FBI IC3 PSA、2025年2月26日）。

攻撃の経路は、Bybit側が依頼したSygniaのフォレンジック調査と、Safe側の調査を踏まえた声明で次のように特定されています。Safe{Wallet}開発者の端末が侵害された後、2025年2月19日、Safe{Wallet}の配信インフラ（AWS S3）上のJavaScriptに悪性コードが注入されました。このコードはBybitのSafeが署名する時だけ動作し、画面には正規のトランザクションを表示しながら、ハードウェアウォレットには別の内容——SafeのProxyが参照するコントラクト実装を攻撃者のものへ差し替える操作——を署名させました。実行の約2分後、攻撃者は痕跡を消すため悪性コードを削除しています（Sygnia: Investigation into the Bybit Hack）。

採用判断の観点で重要なのは、何が破られ、何が破られなかったかの切り分けです。

• 破られなかったもの：Safeのオンチェーンコントラクト。コントラクトの脆弱性は突かれておらず、M-of-Nの署名ルールは設計どおり動作しました。攻撃者はしきい値分の「正規の署名」を集めることに成功したのです。
• 破られたもの：署名UIの供給網（フロントエンドのサプライチェーン）と、署名者側の検証運用。署名者は画面表示を信頼し、ハードウェアウォレット上で実際の署名内容を検証できていませんでした。内容を実質確認できないまま署名する、いわゆるblind signingの問題です。

Safe側は2025年2月28日にSafe Ecosystem Foundationとして声明を出し、インフラの再構築と段階的な復旧、攻撃経路の排除を発表しました（Safe Ecosystem Foundation声明、2025年2月28日）。2026年8月時点では、署名前にトランザクションを解析してリスクを警告する企業向けのSafe Shieldも提供されています（Safe Shield、2026年8月11日閲覧）。

この事件をSafeの採用可否に直結させるのは短絡ですが、「監査済みコントラクトを使えば安全」という前提が崩れたことは採用側の設計要件に反映する必要があります。具体的には次の3点です。

• UIと独立した検証経路を署名手順に組み込む：署名対象のトランザクションハッシュとcalldata（実行内容のデータ）を、署名UIとは別の経路・ツールで検証してから署名する手順を、大口送金の必須ステップにします。
• 実装変更を伴う操作は特別扱いする：コントラクト実装の差し替えやModule追加など、Safeの権限構造そのものを変えるトランザクションは、金額ゼロでも最上位の承認プロセスに載せます。
• 署名者の訓練を統制の一部として扱う：M-of-Nの承認は、各署名者が「何に署名しているか」を検証できて初めて機能します。署名者ごとの検証手順書と定期訓練は、しきい値の設定と同格の統制要素です。

採用判断 — Safeが向くケース、別スタックが向くケース

Safeが向くのは、複数人の合意をオンチェーンで強制したい共同管理です。

• 法人・DAOのトレジャリー（資金庫）管理：職務分離や二重承認といった内部統制の要件を、社内規程ではなくコントラクトで強制でき、承認証跡がチェーン上に残ります。DAOでは投票結果の執行をZodiac系Moduleで接続する構成が定着しています。
• プロトコル・プロダクトの管理者権限の分散：コントラクトのアップグレード権限やパラメータ変更権限を単一の鍵に置かず、Safe経由の複数人承認に載せる用途です。
• 大口保有者の自衛的な共同管理：複数端末・複数人でのしきい値管理と復旧設計を、個人でも機関に近い水準で組めます。

一方、次の要件が主なら別のスタックから検討すべきです。

• エンドユーザーへ大量配布するウォレット：ユーザーごとにマルチシグのしきい値管理は過剰で、求められるのはガス代肩代わりやパスキー認証などのUXです。ERC-4337ネイティブ系（Kernel（ZeroDev）の採用判断）や、既存EOAを拡張するEIP-7702（EIP-7702の事業者向け解説）を含めた比較はSmart Walletスタック比較を参照してください。
• Bitcoin・Solanaなど非EVMチェーンを含む鍵管理：SafeはEVM系チェーンに展開されるコントラクトであり、非EVMチェーンには適用できません。チェーン横断で鍵の単一障害点をなくしたい場合は、オフチェーンで署名を分散するMPC（Multi-Party Computation：複数参加者による分散計算）系の基盤が対象になります。
• 高頻度・低レイテンシの自動執行が主目的：人間の署名収集が律速になります。Allowance Moduleで少額高頻度の経路を切り出す緩和はできますが、全体が高頻度ならアカウント構造の設計から見直すべきです。

なお、SafeとMPCは排他ではありません。MPCで分散管理する鍵をSafeのOwnerに据えれば、「人の合意（オフチェーン）」と「オンチェーンの強制」を重ねた二重統制になります。組み合わせの設計はMPC×AAの解説で扱っています。また、日本の事業者が他者の暗号資産をSafeで共同管理する構成を組む場合、構成次第で資金決済法上のカストディ（暗号資産の管理）該当性の論点が生じます。技術構成と規制の対応関係はAAの規制該当性で整理していますが、該当性の判断自体は弁護士等の専門家の領域です。

導入形態と設計論点 — そのまま使うか、Moduleを作るか

導入形態は、自社でどこまで開発するかで3段階に分かれます。

費用面では、Safeのコントラクトはオープンソース（LGPL-3.0）で、プロトコル利用料はなく、必要なのはデプロイと実行のガス代です。Safe{Wallet}の基本機能は無料で使え、企業向けにはSafe Shieldなどの追加サービスが展開されています（2026年8月時点）。カスタムModuleを開発する形態Cでは、Moduleがコアと同等の権限を持ち得る以上、コントラクト監査の費用と期間を初期計画に含めるべきです。

形態にかかわらず、設計段階で決めるべき論点は4つあります。

• しきい値（M-of-N）の設計：「1人欠員でも業務が継続できるか」「1人の不正・侵害では資産が動かないか」「鍵管理と署名収集の運用コストに耐えられるか」の3軸で決めます。たとえば2-of-3は手軽ですが、1人の退職・事故で残り2人が全権を持ち職務分離が崩れます。Nを増やすほど安全側に倒れる一方、署名収集の所要時間と鍵管理端末の数が運用負荷になります。
• Moduleの権限台帳と棚卸し：「どのModuleが、どの条件で、何を実行できるか」を一覧化し、導入時の審査と定期的な棚卸しを運用に組み込みます。v1.5.0以降であれば、Module Guardで上限や許可リストをコントラクト側からも強制できます。
• Recoveryの待機期間：短すぎると鍵漏洩時に攻撃者のOwner差し替えが完了してしまい、長すぎると正規の鍵紛失時に資産が長期間動かせません。Guardianの構成・人数と、Recovery発動を即時検知する通知体制をセットで設計します。
• 署名検証の運用：前章のBybit事件の教訓です。独立経路でのトランザクション検証、実装変更操作の特別扱い、署名者訓練を、技術構成と同じ設計書に載せます。

よくある質問

署名者の1人が退職したり鍵を紛失したりしたらどうなりますか？

残りの署名者だけでしきい値を満たせる場合は、Owner（署名権限者）の交代自体を通常のSafeトランザクション（swapOwner）として実行でき、資産を動かさずに署名者を入れ替えられます。満たせない場合は、事前にRecovery Moduleなどの復旧手段を設定していない限り、そのSafeの資産は動かせなくなります。このため設計時点で「1人欠けてもしきい値に届く」構成（例：2-of-3ではなく3-of-5）にしておくことが原則です。

1人で使う場合でもSafeを選ぶ意味はありますか？

あります。Safeは1-of-1（署名者1人）でも利用でき、その場合でも、後からOwnerの追加やしきい値の変更を資産を移動せずに行えます。将来の共同管理化や組織化を見込む段階で、最初からSafe上に資産を置いておくと、管理体制の移行がアドレス変更なしで完結します。ただし1-of-1のままでは単一鍵の障害点はEOA（秘密鍵で直接操作する従来型アカウント）と同じなので、ハードウェアウォレットの利用や早期の複数人化が前提です。

利用に費用はかかりますか？

Safeのコントラクトとプロトコルの利用自体に手数料はなく、必要なのはSmart Accountのデプロイ（初回作成）と各トランザクション実行のガス代です。公式UIのSafe{Wallet}は基本機能を無料で使えます。企業向けには、署名前のリスク解析を行うSafe Shieldなどのサービスが提供されています（2026年8月11日時点。提供条件・料金は変わり得るため、契約前に公式サイトで最新の内容を確認してください）。

関連記事

Safeを構成要素として使う・比較する：

• AA完全マップ2026 — スマートアカウント領域の全体俯瞰と本記事の位置づけ
• Smart Walletスタック比較2026 — Safe / Kernel / その他実装の横並び比較
• Kernel（ZeroDev）の採用判断 — エンドユーザー向けUXが主目的の場合の対抗スタック
• MPC×AAの整理 — MPCで管理する鍵をSafeのOwnerにする併用構成

個別の設計論点を深掘りする：

• Social Recoveryの実装パターン — Guardian構成と待機期間の設計
• AAセキュリティリスク — スマートアカウント側の攻撃ベクトルと監査観点
• AAの規制該当性 — 共同管理構成とカストディ該当性の論点

XTELAが支援できる範囲

Safeの導入は、コントラクトの選定よりも「どの統制を人の合意に置き、どの制約をオンチェーンに強制し、署名者が何を検証するか」という設計の比重が大きい仕事です。XTELAは、要件整理とSafe/MPC/ERC-4337系スタックの比較選定、しきい値・Module構成・Recovery設計のレビュー、Safe{Core} SDKを使った業務統合やカスタムModuleの設計・実装、監査前の設計レビュー、署名検証手順を含む運用設計の技術文書化まで、Web3サービスの技術面を支援しています。カストディ該当性など法令・会計・税務の判断は弁護士等の専門家の領域として切り分けたうえで、その検討に必要な技術構成の整理を支援します。

マルチシグ・スマートウォレット設計について相談する

主要参考資料

• Safe公式サイト（2026年8月11日閲覧）
• Safe Docs: Safe Modules（2026年8月11日閲覧）
• Safe Docs: Safe Guards（2026年8月11日閲覧）
• Safe Foundation: Introducing Safe v1.5.0（2025年7月22日）
• safe-fndn/safe-modules（公式Moduleリポジトリ）
• Safe Help: Set up and use Spending Limits（2026年8月11日閲覧）
• Safe Docs: Safe and ERC-7579（2026年8月11日閲覧）
• Gnosis Guild: Zodiac
• Sygnia: Investigation into the Bybit Hack（2025年）
• FBI IC3: North Korea Responsible for $1.5 Billion Bybit Hack（2025年2月26日）
• Safe Ecosystem Foundation: Statement（2025年2月28日）
• Safe Shield（2026年8月11日閲覧）
• Safe Foundation: History of Safe
• GnosisDAO: GIP-29 — Spin-off safeDAO and Launch SAFE Token（2022年2月）
• CoinDesk: Safe Establishes New Development Firm（2025年6月11日）

本記事の前提

本記事は2026年8月11日時点で確認した一次情報に基づく技術・事業設計上の論点整理であり、投資助言・法的助言ではありません。Safeの製品構成、バージョン、提供条件、統計値は今後変わり得ます。導入判断の際は最新の公式ドキュメントを確認し、カストディ該当性など法令・会計・税務の判断は有資格の専門家に相談してください。