ビットコインには「Script」と呼ばれるプログラミング言語が備わっており、単純な送金だけでなく「特定の条件が満たされたときだけコインを使える」という条件付き取引を記述できます。しかし従来のScriptには制限が多く、複雑な条件を実装するとトランザクションサイズが大きくなり手数料が増大する問題がありました。
Taprootアップグレードで導入されたTapscript（BIP342）とMASTの概念は、この問題を根本的に解決するアプローチです。複数の条件分岐を持つスクリプトをMerkleツリーとして格納し、実際に使用する条件のみをブロックチェーンに公開することで、効率性とプライバシーを同時に向上させます。
本記事では、従来のビットコインScriptの限界から始め、MASITとTapscriptがどのようにその限界を乗り越えるのかを、具体的な利用シナリオを交えながら解説していきます。
1. ビットコインScriptの基本：スタックベースの言語
1-1. Scriptとはどのような言語か
ビットコインのScriptはForth言語に影響を受けたスタックベースのプログラミング言語です。「スタックベース」とは、命令が積み重なったデータ構造（スタック）を操作することで計算を行う方式です。Turingは完全ではなく（ループ命令がない）、意図的にシンプルに設計されています。これはビットコインの設計哲学である「シンプルさと予測可能性の重視」を反映しています。
典型的なビットコイントランザクションでは、コインを受け取る側が「ロッキングスクリプト（scriptPubKey）」で「この条件を満たした人だけが使える」という条件を設定し、送金する際に「アンロッキングスクリプト（scriptSig）」でその条件を満たすことを証明します。最も一般的なパターンはP2PKH（Pay-to-Public-Key-Hash）で、「公開鍵のハッシュが一致し、かつ有効な署名がある」という条件です。
1-2. マルチシグとP2SHの仕組み
「M-of-N マルチシグ」はビットコインの重要な機能の一つです。「3人のうち2人の署名があれば使える」という条件を、OP_CHECKMULTISIGという命令で実現できます。ただし、マルチシグを直接使うと（ bare multisig）アドレスとして機能しないため、実際にはP2SH（Pay-to-Script-Hash）という仕組みで包んで使います。
P2SHではスクリプト全体のハッシュ値がアドレスになり（3で始まるアドレス）、送金時に実際のスクリプトを提示します。しかしP2SHにも問題があります。コインを使用する際、設定した条件（スクリプト）全体をブロックチェーンに公開しなければならないため、「3-of-5マルチシグを使っている」という情報が誰でも確認できてしまいます。また、使用しなかった代替条件があっても、それをすべてトランザクションに含める必要があり、無駄なデータが増えてしまいます。
2. MASITの概念：必要な条件だけを公開する
2-1. Merkleツリーによるスクリプト格納
MAST（Merklized Abstract Syntax Trees）は、複数のスクリプト（条件）をMerkleツリーの葉（leaf）として格納し、実際に使用する条件のみをMerkleパスとともに公開する仕組みです。Merkleツリーは暗号学的ハッシュ関数を使って構築された木構造で、任意の葉の存在をルートハッシュから効率的に証明できます。
具体例を挙げてみましょう。「条件A（Alice単独）、条件B（Bob単独）、条件C（Alice+Bob合同）」という三つの条件があるとします。MASITでは、これら三つの条件をMerkleツリーの葉として格納し、そのルートハッシュをコミットメントとしてブロックチェーンに記録します。実際にAliceが単独でコインを使う場合、条件AとMerkleパスを提示するだけで十分です。条件BとCが存在するという事実は公開されません。
2-2. Taprootの実装：MASITと鍵集約の組み合わせ
Taprootにおける実際のMASIT実装（BIP341）では、MerkleツリーのルートハッシュをSchnorr署名の公開鍵に「ツイーク（tweak）」として組み込みます。最終的なP2TRアウトプット公開鍵はQ = P + Hash(P || root) × Gとして計算されます（Pは内部公開鍵、rootはスクリプトツリーのルートハッシュ、Gは楕円曲線基点）。
この設計により、スクリプトパスを使う場合は内部公開鍵PとMerkleパスを公開することで、特定のスクリプトがコミットされていたことを証明できます。キーパスを使う場合は、スクリプトの存在自体を公開せずにQに対応する署名を提示するだけです。
3. Tapscript詳細：Script言語の進化
3-1. Tapscript（BIP342）の主要変更点
TapscriptはTaprootのスクリプトパスで使用されるScript言語の改訂版です。BIP342で定義されており、従来のScriptとの主な違いは次の点にあります。
まず、署名検証命令がSchnorr署名に対応しました。OP_CHECKSIGおよびOP_CHECKSIGADDはSchnorr署名を受け入れ、ECDSAは受け入れません（P2TRスクリプトパスの場合）。OP_CHECKSIGADDは新しい命令で、マルチシグを効率的に実装するためのものです。
次に、OP_CHECKMULTISIGが削除されました。代わりにOP_CHECKSIGADDを組み合わせることで同等のマルチシグ機能を実現しますが、バッチ検証との互換性が高い実装になっています。
3-2. OP_SUCCESSと将来拡張性の確保
Tapscriptで最も重要な設計上の特徴の一つが「OP_SUCCESS」命令群です。0x50〜0xfeの範囲の未定義命令コードをOP_SUCCESSとして扱い、これらが含まれるスクリプトは無条件に「成功」として評価されます。
これは一見セキュリティ上の問題に思えるかもしれませんが、実際には巧みな設計です。OP_SUCCESSが含まれるP2TRアウトプットは、アップグレード済みノードからは将来の命令として扱われます。新しい命令（例えばOP_CHECKTEMPLATEVERIFYやOP_CAT）をソフトフォークで追加する際、OP_SUCCESSコードにその命令を割り当てることで、古いノードの動作を変えずに新機能を追加できます。
4. 実際の利用シナリオ：Tapscript/MASITが役立つケース
4-1. 企業のビットコイン資産管理
企業がビットコインを管理する場合、セキュリティのために複数の鍵を必要とするマルチシグ設定が一般的です。例えば「CFO・CEO・外部セキュリティ担当の3人のうち2人の署名が必要」というポリシーを実装できます。さらに「30日間誰も署名しない場合は特定の復旧アドレスに送金できる」というタイムロック条件を追加することも可能です。
MASITを使えば、通常の送金時（条件A：CFO+CEOの2-of-2）のトランザクションには復旧条件（条件B）の情報が一切含まれません。内部の資金管理ポリシーがブロックチェーン上に公開されることなく、外部からは普通の2人のマルチシグトランザクションとしか見えません。
4-2. Lightning Networkのチャネル管理
Lightning Networkのペイメントチャネルは、Taprootを使うことで大幅に効率化されます。チャネルの正常クローズ（cooperative close）と強制クローズ（unilateral close）という二つの条件をMASITに格納することで、正常クローズ時は単純なSchnorr署名（MuSig2による鍵集約）で処理でき、ブロックチェーン上にLightning特有のデータが公開されません。
これにより、Lightning Networkのオープン/クローズトランザクションが通常の送金トランザクションと区別できなくなり、Lightning Networkの普及がプライバシー問題を引き起こさない設計が実現します。
5. Taproot Asset Protocol：さらなる拡張
5-1. TaprootベースのトークンプロトコルTAP
Lightning Labs（Lightning Networkの主要開発企業）が開発した「Taproot Assets Protocol（TAP、旧称Taro）」は、Taprootを利用してビットコインブロックチェーン上で代替可能トークン・非代替性トークン（NFT）を発行・転送できるプロトコルです。
TAPはTaprootのMASIT構造を活用して、アセット情報をビットコインのUTXO（未使用トランザクションアウトプット）に埋め込みます。アセットの全状態はオフチェーン（クライアントサイド検証）で管理され、オンチェーンには最小限のコミットメントのみ記録するため、ビットコインブロックチェーンへの負荷を最小限に抑えます。
5-2. HTLC（ハッシュタイムロックコントラクト）の改善
HTLC（Hash Time-Locked Contract）はLightning Networkでルーティングに使われる重要なスクリプト構造です。「ハッシュ値のプリイメージ（元の値）を提示できる場合、またはタイムアウト後に送金者に返金する」という条件を実装します。
TapscriptとMASITを使ったHTLCは、正常なルーティング（プリイメージ提示）の場合はMASITの「成功」パスが選ばれ、タイムアウトの場合は「失敗」パスが選ばれます。各パスは独立してチェーン上に記録されるため、成功したHTLCのトランザクションは通常の送金と区別できません。これはLightning Networkのプライバシーにとって重要な改善です。
6. 開発者視点：Tapscriptでできることとできないこと
6-1. 現時点でのScriptの制限
Tapscriptはビットコインのスクリプト能力を大幅に向上させましたが、依然としていくつかの制限があります。イーサリアムのようなチューリング完全なスクリプト（任意の計算が可能）はビットコインの設計哲学に反するため、導入されていません。Scriptにはループ命令がなく、実行ステップ数には上限があります。
また、スタックのサイズや入力数にも制限があります。現在のTaprootスクリプトでは、スクリプトごとに最大520バイトのスタック要素、最大1,000要素のスタックサイズが制限として設けられています。これらの制限はセキュリティとシンプルさを保つための意図的な設計です。
6-2. 提案中の将来拡張：OP_CATとCovenant
ビットコインのScript機能をさらに拡張するいくつかの提案が活発に議論されています。注目すべき提案の一つが「OP_CAT」の復活です。OP_CATはスタック上の二つの要素を連結する命令で、SegWitより前から存在しましたが、スタックオーバーフロー攻撃のリスクから無効化されていました。Tapscriptのフレームワーク（OP_SUCCESSによる安全なソフトフォーク）を使ってOP_CATを再導入することが提案されており、2024年にはBIP347として正式提案されました。
「コベナント（Covenant）」と呼ばれる概念も重要です。コベナントはビットコインの使われ方に「制約」をかける仕組みで、例えば「このコインはAアドレスからBアドレスへの送金にしか使えない」という制限を付けることができます。OP_CHECKTEMPLATEVERIFY（OP_CTV、BIP119）やOP_VAULT（BIP345）などが提案されており、ビットコインのカストディや金庫（vault）機能を改善できると期待されています。
まとめ
TapscriptとMASITは、ビットコインのスマートコントラクット能力をプライバシーと効率性を維持しながら拡張するための巧みな設計です。従来のScriptでは露出せざるを得なかった条件情報をMerkleツリーに隠蔽し、必要なときだけ公開する仕組みは、企業のビットコイン管理からLightning Networkのルーティングまで、幅広い用途に応用できます。
さらに、OP_SUCCESSによる将来拡張性の確保により、OP_CATやコベナントなどの新機能をソフトフォークで安全に追加する道が開かれています。ビットコインのスクリプト能力は今後も着実に進化していくと考えられます。
よくある質問（FAQ）
- Q. TapscriptはEVM（イーサリアム仮想マシン）と同じようなものですか？
- A. 根本的に異なります。EVMはチューリング完全で任意のプログラムを実行できますが、TapscriptはチューリングP完全ではなくループも持たない、意図的に制限されたスクリプト言語です。ビットコインは「プログラマブルなお金」よりも「確実な決済基盤」を優先する設計哲学を持っています。
- Q. MASITの条件は何個まで設定できますか？
- A. 技術的には非常に多くの条件をMerkleツリーに格納できます。Merkleツリーの葉の数に厳密な上限はなく、2の128乗まで格納できる設計です。実用的には、ツリーが深くなるほど「Merkleパス」の証明データが大きくなるため、手数料が増加します。一般的な用途では10〜20条件程度が現実的と言えます。
- Q. 古いP2SHのマルチシグウォレットをTaprootに移行すべきですか？
- A. Taprootへの移行はプライバシーと手数料削減のメリットがありますが、移行コスト（トランザクション手数料）がかかります。大きな金額を長期保有する場合は移行を検討する価値がありますが、少額や頻繁に使うウォレットは状況に応じて判断してください。
免責事項
※本記事は情報提供を目的としており、投資を推奨するものではありません。暗号資産への投資は元本割れのリスクがあります。投資判断はご自身の責任で行ってください。