マルチシグ（複数署名）とは｜法人の送付承認を「1人の鍵」にしない仕組み

ステーブルコインの送付を社内で検討すると、必ず「誰がボタンを押せば送れるのか」という問いに行き着きます。結論から言うと、マルチシグ（複数署名）は、送付の実行に「N人中M人」の署名をそろえることを求める仕組みです。1本の秘密鍵が漏れても、1人が不在でも、送付の判断が1人に集まらないように設計できます。本記事は、経理・内部統制の担当者が「送付を誰がどう承認するか」を考えるための基礎を整理します。鍵を自社で持つか事業者に預けるかという前段の分岐は法人のウォレットとカストディの基礎で扱っています。

なお、本記事で引用するethereum.org（日本語版）、金融庁の事務ガイドライン、米国立標準技術研究所（NIST）の公表資料は、2026年9月26日に確認したものです。

マルチシグとは——「N人中M人」がそろわないと送れない仕組み

ethereum.orgの用語集は、マルチシグ（マルチシグネチャ）を「トランザクションを実行するために複数の署名または承認を必要とする」ウォレットやアカウントと説明しています。ここでいう署名とは、秘密鍵（残高を動かす権限を示す暗号の鍵）を使って、送付の指示に電子的な裏書きをすることです。

同サイトのスマートコントラクトのセキュリティのページは、マルチシグネチャ・アカウントは複数の主体が所有し、トランザクションの実行には最小限の数（例として5つ中3つ）の署名が必要になると説明しています。たとえば「3人中2人」と決めれば、3人がそれぞれ別の鍵を持ち、そのうち2人の署名がそろった時点で初めて送付が実行されます。

図: 「3人中2人」のマルチシグで送付が実行されるまで（当サイト作成・役職は例）

仕組みの置き場所も押さえておきます。ethereum.orgのアカウントのページは、アカウントを、秘密鍵を持つ人が制御する「外部所有アカウント（EOA）」と、コードによって制御される「コントラクト・アカウント」の2種類に分けています。前者は鍵1本で送付が完結する形です。マルチシグは、後者のようにスマートコントラクト（ブロックチェーン上で動くプログラム）のウォレットとして実装される場合があり、「何人の署名で送れるか」というルールがプログラムに書き込まれます。プログラムの性質はスマートコントラクトとはで整理しています。

紙の決裁・ネットバンキングの承認と、何が同じで何が違うか

発想は、紙の稟議で起案者と決裁者を分けることや、法人向けインターネットバンキングで振込の起票者と承認者を分ける設定と同じです。職務分掌（1つの取引を1人で完結させない分担）を、担当者の善意ではなく仕組みで担保するという点が共通しています。

違いは、承認を強制するものと、事故が起きた後の扱いです。

最後の行が決定的です。オンチェーンの送付は、確定すれば送った側の都合では取り消せません（オンチェーンの送付に「組戻し」はない）。だからこそ、事後の手当てではなく「送る前に複数人がそろう」ことに重みがあります。

運用で効き目が変わる3つの論点

マルチシグは、入れれば安全になる設備ではありません。効き目は運用で決まります。

第一に、署名者と鍵の置き場所が偏ると意味が薄れます。 3人中2人にしても、3人が同じ課に属し、鍵を同じ金庫や同じPCで保管していれば、1つの部署の判断や1か所の事故で要件がそろってしまいます。金融庁の事務ガイドライン（17 電子決済手段等取引業者関係）Ⅱ－２－２－５－２⑶③も、登録業者の監督上の着眼点として、複数の秘密鍵等を用いる場合には「各秘密鍵等の保管場所を分けて管理しているか」を挙げています。事業会社への義務ではありませんが、署名者を異なる部署から選び、保管場所を分けるという設計の目安になります。

第二に、退職・異動のたびに署名者の入れ替えが必要です。 鍵は人に紐づくため、署名者が抜ければ、その鍵を外して後任の鍵を登録する手続きが要ります。これを怠ると、退職者の鍵が有効なまま残るか、有効な署名者が足りなくなります。

第三に、M/Nを厳しくしすぎると支払が止まります。 代表的な設定で比べると次のとおりです。

登録業者に預ける場合は「二層」で考えます

日本の事業会社がまず接するのは、登録を受けた事業者の口座を通じた形です。この場合、自社がマルチシグを組むわけではありません。論点は二層に分かれます。

業者側の層について、同ガイドラインⅡ－２－２－５は「電子決済手段の流出リスクへの対応」を登録業者の監督上の着眼点として整理しています。その中には、移転時に複数の担当者が関与する体制、権限者以外が署名できない秘密鍵等の管理、複数の秘密鍵等を用いた電子署名を必要とする等の措置、秘密鍵等のバックアップ、移転手続を内部監査の対象とすることなどが挙げられています。いずれも登録業者に向けられた着眼点です。

見落とされやすいのは自社側の層です。業者がどれほど厳重に鍵を管理していても、自社の管理画面で担当者1人が送付を指示できる設定なら、社内の職務分掌は担保されていません。起票者と承認者を分ける機能、金額に応じて承認者を増やす機能、送付先の事前登録制の有無は事業者ごとに異なるため、書面で確認します。

なお、鍵の管理方式として、マルチシグとは別にMPC（マルチパーティ計算）という言葉を目にすることがあります。NISTは、MPCの原理を応用し、署名などの暗号処理に対する信頼を複数の当事者に分散させる「しきい値方式（threshold schemes）」の標準化プロジェクトを進めています。業者に質問するときは、方式の名前より「1人・1か所で送付が完結しないか」を軸にするのが実務的です。

事案：海外の工場建設を請け負う中堅建設会社

以下は公表資料をもとに構成した想定事案です。実在の企業・案件ではありません。

①既存事業と既存ユーザー——国内の工場・倉庫の建設を主力とする、従業員500人規模の建設会社です。顧客は国内の製造業で、近年は顧客の東南アジア拠点の工場建設も請け負い、設計・施工監理料を海外の施主から銀行送金で受け取っています。

②やろうとしていること——海外の施主1社から、施工監理料の一部をステーブルコインで支払いたいと打診がありました。受け取り方の確認は別に進めるとして、今回の論点は「受け取った残高を、誰の承認で動かすか」です。対象は、円に換えて自社の銀行口座に出金する操作と、出金先・送付先の登録を変える操作の2つです。役員会が付けた条件は、担当者1人の操作で残高を動かせる状態にしないことでした。

③登録業者との役割分担——受け取りと出金は、登録を受けた事業者の法人口座を通じて行う前提にします。秘密鍵の保管・署名・流出対策は事業者の管理の範囲です。自社で鍵を持ってマルチシグを組む案も検討しましたが、署名者の入れ替えや鍵の保管を担う体制が社内にないため見送り、その理由を検討記録に残しました。自社が担うのは、管理画面の承認者設定と社内規程の整備です。

④社内・社外への説明の具体像——社内では、経理規程の権限表に2行を足します。換金・出金は経理担当が起票して経理課長が承認し、出金先・送付先の登録変更は影響が最も大きい操作として、財務部長と管理本部長の2人の承認を要するものとします。管理画面でそこまで設定できない場合は、社内の書面決裁を先に通すことを規程に書きます。人事には、異動・退職時の承認権限の解除を手続きに加えてもらいます。社外では、施主に回答文書で「登録済みの受取アドレス以外には支払わないでほしい」「アドレスを変更する場合は書面で通知する」の2点を伝えます。監査法人には、管理画面の承認記録と事業者の取引履歴をどう突き合わせて保存するかを期末前に説明し、登録業者には承認者設定の機能を書面で確認します。

稟議の前に決めておくこと

事案の建設会社が権限表に落とし込んだのは、次の確認事項です。

用語に迷ったら用語集もあわせてご覧ください。マルチシグを理解する目的は、暗号の仕組みを説明できるようになることではありません。自社の残高を動かすのに誰と誰がそろう必要があるのかを、権限表に一行ずつ書けるようにすることです。そこまで書ければ、仕組みを自社で組むのか、業者の管理画面で組むのかは、その先の選択になります。