マルチシグの進化版？個人にも嬉しい機能を備えた「疑似コベナンツ」ベースのウォレットがこれからのトレンド

加藤規新 • 2026年10月28日

ビットコインを手元でどう保管するかは常に悩ましい問題ですが、最近ではColdcardのシード生成の脆弱性やハードウェアウォレットの流通経路でのサプライチェーン攻撃といった事件がより一層議論を混迷させています。極論だと、Glacier ProtocolというPCを2台利用するいにしえの（非常に手間のかかる）保管方法を真剣に再検討する意見すら散見されます。

Glacier Protocolについてはこちら。簡単に言えばPCを使ったエアギャップ運用です

似たようなことをするだけならSeedSignerは非常に近いですし、エアギャップ運用は様々なハードウェアウォレットやスマートフォンで実践できます。それでもあえてできる限り（ウォレットの使い勝手は正直悪い）Bitcoin Coreだけに攻撃表面を絞りたいという人がいるほど疑心暗鬼が広がっています。

しかし、これは私の観測範囲では最近のウォレットのトレンドとは逆行しているように思います。むしろ、ここ数年でだんだん増えてきたのは事前署名トランザクションや署名付与サーバーを組み合わせることで「疑似コベナンツ」を導入し、ユーザー体験を大きく損なわずにセキュリティと機能性を改善するウォレットです。

コベナンツについては大石さんの記事をご覧ください。なお、2026年現在まだBitcoin Scriptにはコベナンツ用の関数が導入されていないので、今回紹介するように擬似的にしか実現できません

今日はそのようなウォレットを「疑似コベナンツ」ベースのウォレットとしていくつかの類型に整理し、それぞれがどのような特徴を持っていて、今後どのように広がっていくのか検討します。

類型①　署名付与サーバーと協力してプログラマビリティを実現

まず１つ目の類型はユーザーが「署名付与サーバー」と呼ぶべきサーバーとの2-of-2マルチシグを構築し、署名付与サーバーは任意の条件が満たされない限り署名しないというものです。

図ではBlockstream Appを例にとって2FA（二段階認証）としているが、サーバーではそれ以外にも検証する条件を自由に設定できる

昔からモバイル用のウォレットとしてBlockstream Green（今はBlockstream App）を利用されている読者もいらっしゃるかと思いますが、あれもユーザーの端末とBlockstreamのサーバーとで2-of-2マルチシグを実装することで、送金時の二段階認証（認証をパスしないとBlockstreamが署名してくれない）を実現したりしています。

Blockstreamのウェブサイトより引用。ユーザーの鍵をもう１つ加えて2-of-3にすることでいつでも単独退出できるほか、2-of-2のままでも45日間送金（更新）しないとユーザーの鍵単独で動かせるようになる。逆に言えば2-of-2を利用し続けるのに45日に1トランザクションは必要

この類型は、署名付与サーバーが署名するときの条件を自由に定めることができるのが何よりの長所で、ビットコイン単体では実現できないような精緻なウォレットのコントロールができます。例えばBitkeyでは１日あたりの送金金額に上限を設けて、この上限以内であればモバイルアプリ内の鍵と署名付与サーバーの2つの署名で送金できますが、この上限を超える送金にはハードウェアウォレット内の鍵による署名を必須にすることができます。これによって決済用ウォレットのチャージなど日常的な利用シーンでは安全に保管しているハードウェアを取り出すことなく利用できるという、利便性のメリットがあります。

AreaBitcoinのサイトから引用。Bitkeyは日常の利用はMobile KeyとServer Keyで、高額の利用にはServer Keyは使用できないよう（＝Hardware Keyが必須）に設定できる

Nunchukというマルチシグサービスでも、Nunchuk側での署名付与に待ち時間や一定期間内の送金上限を設定できたり、トランザクションの事前スケジュールなどが機能として提供されています。

あるいは、ArkadeなどのArk実装では送金の二重支払いを防止しつつ即時決済を提供する方法として、オペレーターが署名付与サーバーを運用し、Arkade内のすべての送金をユーザーとともに署名します。Arkadeの場合、このサーバーの実行環境の工夫などにより、ユーザーと共謀しての二重支払いも防げるとされています。（実質的にはユーザーによる監視も必要だと思いますが）

オペレーターが共同署名することによって、他のユーザーの視点ではAliceやBob単独での不正が防げる。オペレーターがAliceやBobと共謀しない方法は別途用意する必要がある

サーバーではありませんが、一部のハードウェアウォレットにも似た機能が入っていて（例えばColdcardやFoundation Passport）、Bitcoin Scriptで記述できないような署名条件をウォレットに課すことができたりします。ただし、ハードウェアウォレットの場合はインターネットに接続しておらず、信用できる時計もついていないので機能性の面では署名付与サーバーに劣ります。シードフレーズを復元すれば迂回もできてしまうので、使い所は限られるかもしれません。

このような機能は各ウォレットがプロダクトとして提供する価値に直接つながっており、ユーザーにとって高い利便性を実現する要となっているといえます。また、事前署名サーバーによって提供できる機能はユーザーを囲い込む要素にもなるので、事業としてウォレットを運営する場合は大きな効果を発揮するでしょう。

類型②　事前署名トランザクションでVaultを実現

次のアプローチはセットアップや保管の手間が大きいので比較的珍しいものですが、実験的な構想がいくつか出てきています。事前署名トランザクション（Pre-signedトランザクション・プレサイントランザクション）を使って擬似的なコベナンツを実現するものです。

例えば、難解なものでいえば以前紹介したRevaultなどが該当するほか、広義には（すっかり聞かなくなってしまいましたが）DLCなども当てはまるかもしれません。

実用性には難があると思いますが、Revaultは事前署名トランザクションによって不正を防止しつつマルチシグウォレットに様々な使用条件のコベナンツを追加するコンセプトです

最近だとUmbrelの生みの親であるLuke Childs氏が「Anzen」という事前署名トランザクションベースのウォレットのコンセプトを発表しています。これは事前に１年分のビットコイン予算を見積もって、それを１ヶ月ごとに支払えるようになる１２個のトランザクションにし、事前に署名・保管しておくコンセプトです。コールドウォレットを頻繁に操作することなく、毎月スマホのホットウォレットに事前に決めた金額を入れて、使わなかった分はコールドウォレットに返還することでセキュリティリスクを限定しようという考えです。

Anzenのトランザクション構造を可視化。毎月、「その月の分をスマホで受け取る」か「Anzenを取り消す（全額金庫＝コールドウォレットに戻す）」の選択ができる。当然スマホから金庫にも送れるので、スマホに保管する金額を少なく抑えつつ、金庫を操作することなく毎月補充することができる

もちろん途中でAnzenをやめたいという場合も、ハードウェアウォレットとスマホの２つの鍵で署名する方法に加えて、どちらかが使えない場合も一定期間待つことで単独で動かすことができる仕組みが用意されています。

💡

余談ですが、Anzenは小切手のモデルに近いことに気づきました。小切手にはPost-dateといって、「この日以降に有効」という未来にしか受け取れないようにする機能があります。Anzenは、事前に次の12ヶ月分のお小遣いを小切手としてPost-datedな形で手元に保管するイメージそのものです。

この類型の長所はビットコイントランザクションを保管したり適切に配信するだけなので、外部のサービスにほとんど依存しないことです。その一方で、Bitcoin Scriptで実現できるような制御に限定されるため、ビットコインにコベナンツが導入されない限りは使える機能はだいだい出揃ってしまっている（発展可能性が少ない）印象です。

亜種　Miniscriptでビットコイン標準の機能を活用（疑似コベナンツではないが目的は近い）

最後に、こちらもBitcoin Scriptを使ったウォレットの話にはなってしまいますが、特にMiniscriptによってBitcoin Scriptの記述や検証が簡単になったことでLianaやNunchukなど疑似コベナンツとは言えませんが、目的は類型②で紹介したものに近い内容のウォレットがいくつか出てきています。

例えばLianaは相続を念頭に置いたウォレットで、所有者が一定期間ごとのリフレッシュトランザクションを実行しなければ、相続人や弁護士に渡した秘密鍵が有効になっていくようなウォレットをMiniscriptで定義しています。有効になった秘密鍵をどのように使うか（一定期間内の送金金額の制限など）に条件を課すことができないので疑似コベナンツではありませんが、このようなDegrading Multisig（劣化していくマルチシグ）はバックアップ目的でも一定数のユーザーに求められる機能だと思います。

まとめ

ビットコインウォレットは多種多様で必ずしも正解はありませんが、最近のトレンドとして署名付与サーバーとのマルチシグや、事前署名トランザクションの用意、Miniscriptの活用などによって「Bitcoin Scriptだけでは実現できない、疑似コベナンツともいうべき使用条件の限定」を機能として提供するウォレットが増えてきています。これはUX面でも大きな前進になりうるほか、セキュリティの強化にも役立つでしょう。5年後には何らかの形で使用条件を自分で定義できるウォレットが主流になっているかもしれません。

加藤規新

1994年生まれ、シカゴ大学でGISやコンピューターサイエンスを学び卒業。2016年末よりビットコインに関するリサーチや実験的な開発を行い、ビットコイン研究所では2019年より技術解説を担当。2024年11月からは日本ビットコイン産業株式会社取締役として、日本国内でのビットコインの普及を主に決済技術の側面から推進している。いまの関心事はインターネットの自由を守ること。