ビットコインのTaprootアップグレードは、Schnorr署名（BIP340）・Taproot本体（BIP341）・Tapscript（BIP342）の三つのBIPで構成されています。このうちTapscriptとMASTは、ビットコインのスクリプト（取引条件を記述するプログラム）の効率性・プライバシー・拡張性を根本から改善する技術です。
従来のビットコインスクリプトは表現力に限界があり、複雑な条件を記述するとトランザクションが肥大化するという問題がありました。Tapscriptは新しいスクリプトバージョン（Script version 1）として、これらの問題を解消する設計になっています。
本記事では、TapscriptとMASTの技術的な仕組み・具体的なユースケース・将来の拡張可能性について詳しく解説していきます。
1. ビットコインスクリプトの基礎
1-1. Scriptとは何か
ビットコインの各UTXO（未使用トランザクション出力）には、「このコインを使用できる条件」を記述したスクリプト（locking script / scriptPubKey）が付随しています。コインを使う際には、この条件を満たすデータ（unlocking script / scriptSig）を提示します。
最も単純な例はP2PKH（Pay to Public Key Hash）で、「この公開鍵に対応する秘密鍵で署名を作れること」が使用条件です。より複雑な例ではP2SH（Pay to Script Hash）を使い、マルチシグや時限条件などを組み合わせたスクリプトを記述できます。
1-2. 従来スクリプトの限界
従来のビットコインスクリプトには主に三つの問題がありました。まず、すべての条件をオンチェーンに公開する必要があること。次に、使われない条件も含めてブロックに格納されるためデータ量が増大すること。そして、スクリプトのバージョン管理が不十分で新機能追加が困難だったことです。
例えば「通常時はAとBの2署名、緊急時はAのみと1週間のタイムロック、最終手段はCのみと1年のタイムロック」という三つの条件を持つコントラクトを作成すると、これらすべてがブロックチェーン上に記録されます。実際には最初の条件しか使わなかった場合でも、他の二つの条件が公開されてしまいます。
2. MAST（Merkelized Abstract Syntax Trees）の仕組み
2-1. マークルツリーの基礎
マークルツリーは、データを効率的に管理・証明するための二分木構造です。葉ノード（leaf）に各データのハッシュを配置し、二つのハッシュを結合してその上位ノードのハッシュを計算する操作を繰り返してルートハッシュを求めます。
重要な性質は、特定のデータがツリーに含まれることを「マークル証明」で効率的に証明できることです。データが2^n個ある場合、n+1個のハッシュ値（マークルパス）を提示するだけで包含証明が完成します。データ全体を公開する必要はありません。
2-2. TaprootにおけるMASTの実装
Taproot（BIP341）では、複数のスクリプト条件（スクリプトリーフ）をマークルツリーに格納し、そのルートハッシュと内部公開鍵（internal key）を組み合わせてTaproot出力を作成します。
具体的には以下の手順で行われます。まず各スクリプト条件をリーフとして格納し、マークルツリーを構築してルートハッシュtを得ます。次に t と内部公開鍵P_internalを使って調整値を計算し、最終的なTaproot公開鍵Q = P_internal + t・Gを求めます。このQがアドレスとして使用されます。
使用時には、実際に使うスクリプト条件・それがマークルツリーに含まれていることを示すマークルパス・内部公開鍵P_internalを提示します。他のスクリプト条件はマークルパスから存在が推測できるだけで内容は公開されません。
3. Tapscriptの詳細仕様
3-1. BIP342の主な変更点
Tapscript（BIP342）は従来のビットコインスクリプトからいくつかの重要な変更を加えています。
- OP_CHECKSIG・OP_CHECKSIGVERIFYの動作変更：Schnorr署名を検証するよう変更。引数は公開鍵のみ（ハッシュではなく）
- OP_CHECKMULTISIG廃止：従来のマルチシグオペコードは使用不可。代わりにOP_CHECKSIGADDを使用
- OP_CHECKSIGADDの追加：署名検証成功時にカウンタをインクリメントする新しいオペコード
- スクリプトサイズ制限の変更：スクリプト全体のサイズ上限が拡大
- OP_SUCCESSの定義：将来の機能追加のための予約スロット
3-2. OP_CHECKSIGADDによるマルチシグの新実装
従来のOP_CHECKMULTISIGはスタックに署名と公開鍵のリストを受け取り、まとめて検証する一発操作でした。Tapscriptではこれを廃止し、OP_CHECKSIGADDで一つずつ検証します。
例えば2-of-3マルチシグは、Tapscript上では各公開鍵を順番にOP_CHECKSIGとOP_CHECKSIGADDで検証し、成功数をカウントして閾値と比較するという形で記述します。各署名を独立して検証するため、バッチ検証との相性が良く、わずかにトランザクションサイズを削減できます。
4. OP_SUCCESSと将来の拡張性
4-1. OP_SUCCESSとは何か
Tapscriptには複数の範囲でOP_SUCCESSという特殊なオペコードが多数定義されています。これらは現時点では「スクリプトの残りを無条件にtrueとする」動作をします。
将来のソフトフォークで、これらのOP_SUCCESSオペコードに新しい意味（機能）を割り当てることができます。アップグレード後のノードは新しいオペコードの正しい動作を実行し、未アップグレードのノードは依然として「無条件true」として処理するため、ソフトフォークが成立します。
4-2. OP_CATとコベナンツへの道
OP_CATはスタックの二要素を連結するオペコードで、2010年に無効化されました。Tapscriptのフレームワークでは、OP_SUCCESSスロットにOP_CATの機能を割り当てるソフトフォーク提案（BIP347）が活発に議論されています。
OP_CATが復活すると、スクリプト内でデータを柔軟に操作できるようになり、コベナンツ（Covenant：特定の条件を満たすトランザクションにのみ資金を使用させる制約）が実現可能になります。「このコインは必ず特定のアドレスに送らなければならない」といった制約を表現できるようになります。
5. Taproot KeyPath SpendとScriptPath Spend
5-1. KeyPath Spendの仕組み
Taproot出力には二つの使用方法があります。まずKeyPath Spend（鍵パス支払い）は、Taproot公開鍵Qに対応するSchnorr署名のみで使用する方法です。MASTのスクリプト部分は一切公開されません。
これはスクリプト条件が存在する場合でも、参加者全員が協力できる状況であれば最もプライベートかつ安価な方法です。例えばマルチシグ参加者が全員合意してMuSig2署名を作成すればKeyPath Spendが可能です。ブロックチェーンには単純なP2TRへの支払いと区別のつかない署名のみが記録されます。
5-2. ScriptPath Spendの仕組み
ScriptPath Spend（スクリプトパス支払い）は、マークルツリー内のスクリプト条件を実際に実行して使用する方法です。参加者間で合意が取れない場合（例：チャネルの一方的クローズ）や、KeyPath Spendが不可能な状況で使用されます。
必要な提示データは、実行するスクリプト・スクリプトリーフのバージョンとコントロールブロック（マークルパスと内部公開鍵）・スクリプトを満たすデータの三部構成です。他のスクリプト条件の内容はマークルパスからは推測できないため、プライバシーが保護されます。
6. Tapscriptの実際の活用事例
6-1. Discreet Log Contracts（DLC）
DLC（Discrete Log Contracts）は、オラクルを使ってビットコイン上で条件付き決済を実現するプロトコルです。例えば「2026年末のビットコイン価格が一定以上であればAがBに1BTCを支払う」という契約をトラストレスに実現できます。
Taprootのおかげで、DLCのトランザクションが通常の送金と外観上区別できなくなりました。また、MuSig2による鍵集約でDLCのセットアップコスト（トランザクション手数料）も削減されています。
6-2. Ark（非インタラクティブチャネル）
Arkはビットコインのスケーリング技術の一つで、複数ユーザーが一つのUTXOを共有するVTXO（Virtual UTXO）を使います。TaprootとMASTを活用することで、定期的なバッチ処理によりオフチェーン資産をオンチェーンに決済するという新しいLayer2アーキテクチャを実現しています。2024〜2025年にかけてメインネット実装が進んでいます。
7. Tapscriptの制限事項と今後の課題
7-1. チューリング完全ではないことの意図
TapscriptはEthereumのSolidityのようなチューリング完全なプログラミング言語ではありません。ループ・再帰・状態の永続化などはサポートされておらず、スクリプトの実行は必ず終了します。
これは意図的な設計選択です。チューリング完全性はDoS攻撃のリスクや、スクリプト動作の複雑さによるセキュリティ検証困難を招きます。ビットコインは「予測可能で安全なスクリプト」を重視しており、複雑なロジックはLayer2（Lightning等）に委ねるという哲学を維持しています。
7-2. クロスインプット署名集約（CISA）の将来
現在のSchnorr署名集約は一つのトランザクション内の複数インプット署名を集約することができません（インプットをまたぐ集約には追加の技術的解決が必要）。CISA（Cross-Input Signature Aggregation）はこれを可能にする提案で、実現すれば複数インプットのトランザクション手数料をさらに大幅削減できます。実装には追加のソフトフォークが必要であり、2026年時点では研究段階にあります。
まとめ
TapscriptとMASTは、ビットコインのスクリプトシステムを次の世代へ進化させる技術です。マークルツリーによる条件の効率的管理はプライバシーとコスト両面で改善をもたらし、OP_SUCCESSによる将来の拡張スロットはビットコインが長期的にアップグレードし続けられる基盤を提供しています。DLC・Ark・PTLCなどの応用技術との組み合わせにより、ビットコインのスマートコントラクト的な活用範囲は着実に広がっています。
よくある質問
Q1. MASTを使うと手数料はどれくらい安くなりますか？
条件の数と複雑さによって異なりますが、3〜5条件のスクリプトでScriptPath Spendを使う場合、従来のP2SHマルチシグと比較して20〜50%程度のwitnessデータ削減が期待できます。KeyPath Spend（全員協力時）ならスクリプト条件がまったくオンチェーンに公開されないため、最大のコスト削減効果が得られます。
Q2. Tapscriptのマークルツリーは何層まで作れますか？
BIP341では最大128階層（depth）のマークルツリーが許容されています。これにより2の128乗種類の条件分岐を表現できます。実用上は数十条件以下の構成が一般的であり、ツリーの深さ制限が問題になることはほとんどないと考えられます。
Q3. OP_CATのソフトフォーク提案はいつ実現しそうですか？
2026年3月時点では、BIP347（OP_CAT）はBitcoin Coreの議論段階にあり、マージの時期は不透明です。ビットコインのコンセンサス変更は慎重なプロセスを踏むため、数年単位の議論期間が必要と考えられます。開発動向を追うにはBitcoin Opcodeのメーリングリストやdelving.bitcoinが参考になります。
※本記事は情報提供を目的としており、投資を推奨するものではありません。暗号資産への投資は元本割れのリスクがあります。投資判断はご自身の責任で行ってください。