ビットコインのスクリプト言語とは何ですか？

ビットコインスクリプトは、ビットコインネットワーク上のあらゆる取引を制御するプログラミング言語です。これは、ビットコインがどのような条件下で支出できるかを正確に定義する、シンプルなスタックベースの言語であり、ネットワーク上のすべてのフルノードは、取引が検証されるたびにこのスクリプトを実行します。これがなければ、ビットコインは単なる数字の台帳に過ぎず、誰が何を所有しているかを強制する仕組みは存在しなくなるでしょう。

ほとんどのユーザーは、ビットコインのスクリプト言語を直接目にすることはありません。ウォレットが裏で処理を行っているからです。 しかし、BTCを送金したり受け取ったりするたびに、何千台ものコンピュータ上で2つの小さなプログラムが同時に実行され、支出条件が満たされているかどうかがチェックされています。その仕組みを理解することで、ビットコインがなぜ現在の構造になっているのか、またイーサリアムのようなプラットフォームと比較して何ができるか、何ができないかについて、多くのことが説明できます。

この記事では、ビットコインスクリプトの仕組みについて解説し、それが可能にする主なトランザクションの種類を順を追って説明するとともに、2021年にスクリプト層を近代化したTaprootアップグレードについて解説し、2026年6月時点でのcovenantオペコードをめぐる議論の現状についても取り上げます。

自己管理でビットコインを安全に管理しましょう Bitcoin.com ウォレットアプリ.

主なポイント

• ビットコインスクリプトは、ビットコインプロトコルに組み込まれたスタックベースのプログラミング言語であり、ビットコインの出力を使用できる条件を定義するものです。
• すべてのビットコイン取引には、受取人が設定するロック用スクリプト（ScriptPubKey）と、送金者が提供するロック解除用スクリプト（ScriptSig）という2つのスクリプトが含まれています。取引が有効となるためには、両方のスクリプトが正常に実行される必要があります。
• ビットコインスクリプトは、意図的にチューリング完全ではありません。ループがなく、実行間の永続的な状態も持たず、スクリプトサイズには厳しい制限が設けられています。これにより、すべてのスクリプトが確実に終了することが保証されており、これは制限ではなく、セキュリティ上の機能です。
• このスクリプト言語は、P2PK、P2PKH、P2SH、SegWit（P2WPKH/P2WSH）、Taproot（P2TR）という5つの主要な形式を経て進化してきました。それぞれの形式は、下位互換性を維持しつつ、実現可能な機能を拡張しています。
• Taproot（2021年11月）では、シュノール署名、プライバシー保護のためのMASTベースの支出パス、および将来のアップグレードをよりスムーズに行うためのメカニズムを組み込んだ改良版スクリプト言語「Tapscript」が導入されました。
• ビットコインスクリプトを基盤とした実世界のユースケースには、マルチシグネチャウォレット、タイムロック取引、ハッシュ・タイムロック契約（ライトニングの基盤）、エスクロー、およびディスクリート・ログ契約などがあります。
• イーサリアムのスマートコントラクトとは異なり、ビットコインスクリプトはステートレスです。つまり、各スクリプトは完全に隔離された状態で実行され、他のトランザクションに関する情報は一切持ちません。これは意図的なアーキテクチャ上の選択です。
• 2026年のビットコインスクリプト開発において最も活発な分野は、コヴェナント・オペコード、特にOP_CTV（BIP-119）とOP_CAT（BIP-347）です。これらにより、スクリプトは支出トランザクションの形式を制限できるようになります。いずれも、まだメインネットでは有効化されていません。

ビットコインスクリプトとは何ですか？

ビットコインスクリプトは、ビットコインプロトコルに組み込まれた、スタックベースのステートレスなスクリプト言語です。 ビットコインネットワーク上のすべてのトランザクション出力には、資金を支出するための条件を指定するロックスクリプト（ScriptPubKeyと呼ばれる）が含まれています。その資金を支出したい者は、その条件を満たすアンロックスクリプト（ScriptSig、またはSegWitおよびTaprootトランザクションではウィットネスデータと呼ばれる）を提供しなければなりません。

この言語の構造は、1960年代に開発されたミニマリストなスタックベースのプログラミング言語「Forth」に由来しています。 Forthと同様に、Bitcoin Scriptは左から右へ読み進められ、スタックと呼ばれるデータ構造を操作し、演算子がオペランドの前に来るのではなく後に来る「逆ポーランド記法（RPN）」を採用しています。また、1回に1つの命令を実行し、ループは存在せず、実行間の永続的なメモリも保持しません。

プロトコルレベルでビットコインスクリプトについて学ぶ際、多くの人が最初に目にするのがこの最後の点です。つまり、この言語は意図的にチューリング完全ではないということです。チューリング完全な言語であれば、十分な時間とリソースさえあれば、あらゆる計算を実行することができます。一方、ビットコインスクリプトは設計上それができませんが、その選択の理由は、ネットワークの仕組みにとって極めて重要な意味を持っています。

ビットコインスクリプトの仕組み：スタックモデル

ビットコインスクリプトの仕組みを理解するには、スタックについて理解する必要があります。スタックとは、後入れ先出し（LIFO）の原則に基づいて動作するデータ構造です。 お皿が積み重なった様子を想像してみてください。お皿の追加や取り出しは、一番上からしか行えません。ビットコインスクリプトでは、データがスタックにプッシュされ、オペコード（操作コード）がスタックの最上部に置かれているデータを操作します。

ビットコインのノードが取引を検証する際、2つのスクリプトを順番に実行します：

1. ロック解除スクリプト（ScriptSig またはウィットネス） コインを支出する者によって提供される。これにより、通常はデジタル署名と公開鍵といったデータがスタックにプッシュされる。
2. ロック用スクリプト（ScriptPubKey） 出金の処理に関連付けられています。これには、スタック上のデータを操作し、出金条件が満たされているかどうかを検証するオペコードが含まれています。

スクリプトがエラーなく実行され、終了時にスタックにゼロ以外の値（TRUE）が残っている場合、そのトランザクションは有効となります。失敗した場合、またはFALSEが残った場合、そのトランザクションはノードによって拒否され、ブロックに組み込まれることはありません。

この実行は完全にステートレスです。スクリプトは、過去のトランザクションに関する情報を一切持たず、現在の残高も認識しておらず、スクリプトの実行終了後に引き継がれる記憶もありません。すべてのスクリプトは、毎回、ゼロから独立して実行されます。

ステップバイステップ：標準的な P2PKH トランザクション

Pay-to-Public-Key-Hash（P2PKH）は、2009年から使用されているビットコインの最初の取引タイプです。P2PKHアドレスは「1」で始まります。実際にScriptPubKeyとScriptSigがどのように記述されるかは以下の通りです：

スクリプトのロック解除（ScriptSig）：

<署名> <公開鍵>

ロック用スクリプト（ScriptPubKey）：

OP_DUP OP_HASH160 <公開鍵のハッシュ> OP_EQUALVERIFY OP_CHECKSIG

ノードが両方を連結してまとめて実行すると、スタックの操作は段階的に進行します：

• ScriptSig からの署名と公開鍵がスタックにプッシュされる
• OP_DUP スタックの先頭にある公開鍵を複製します
• OP_HASH160 重複データをハッシュ化（SHA-256の後にRIPEMD-160を適用）し、20バイトのハッシュ値を生成する
• ロックスクリプトからの公開鍵のハッシュがスタックにプッシュされる
• OP_EQUALVERIFY 2つのハッシュが一致するかどうかを確認します。一致しない場合、実行が停止し、トランザクションは失敗します。
• OP_CHECKSIG その署名が公開鍵に対して有効であることを確認する

すべての手順が正常に完了すると、スタックはTRUEで終了し、資金が解放されます。このプロセス全体はミリ秒単位で完了し、ネットワーク内のすべてのノードでまったく同じように実行されます。

ビットコインのオペコード解説

ビットコインのオペコードは、スクリプトを構成する個々のコマンドです。各オペコードは1バイトであり、256通りのオペコードスロットが存在します。そのうち、現在メインネット上で有効になっているのは約80個です。残りのオペコードは、予約済み、無効化されている、あるいはTapscriptの導入に伴い導入された前方互換性メカニズム「OP_SUCCESS」に割り当てられています。

オペコードは、いくつかのカテゴリに分類されます：

• データプッシュ命令コード 公開鍵、署名、ハッシュなどの値をスタックにプッシュする
• 算術オペコード 加算、減算、および比較演算を実行します。なお、乗算と除算は使用できません。
• 暗号化オペコード ハッシュ処理には OP_SHA256、OP_HASH160、OP_SHA1 を、署名検証には OP_CHECKSIG を含みます
• フロー制御オペコード 条件分岐ロジックの有効化：OP_IF、OP_ELSE、OP_ENDIF、OP_NOTIF
• スタック操作オペコード OP_DUP（先頭のアイテムを複製する）、OP_DROP（先頭のアイテムを削除する）、OP_SWAP（先頭の2つのアイテムを入れ替える）などが含まれる

2010年、元の実装に脆弱性が発見されたことを受け、サトシ・ナカモトによっていくつかのオペコードが無効化されました。これには、OP_CAT（スタック上の2つの項目を連結する）、OP_MUL（乗算）、およびOP_DIV（除算）が含まれます。 これらの機能の欠如は、ビットコインスクリプトで表現できる内容に長期的な影響を与えており、2026年に最も活発に議論されているビットコインのアップグレード提案のいくつかは、これらのうちいくつかを再有効化するかどうかが焦点となっています。

16進数値や説明を含む完全なオペコードリファレンスについては、 ビットコイン・ウィキのスクリプトページ これが最も信頼できる情報源です。

「非チューリング完全」がなぜ長所なのか

一般的な説明では、ビットコインスクリプトにはループがないため、スクリプトは確実に終了し、ネットワークが無限実行から保護されているとされています。これは正確ですが、本質を十分に捉えていません。

より根本的な議論は、攻撃対象領域（アタックサーフェス）に関するものです。チューリング完全な言語は、任意の計算を表現することができます。その表現力こそが、バグが潜む場所でもあるのです。イーサリアムのSolidityは、歴史上最も多額の損害をもたらしたソフトウェアの脆弱性をいくつか生み出してきました。 2016年のDAOハッキング事件では、スマートコントラクトの再入（reentrancy）の脆弱性が悪用され、当時の価格で約6,000万ドルの損失が発生し、最終的にはイーサリアムネットワークの物議を醸したハードフォークにつながりました。DeFiエコシステム全体では、数年にわたりスマートコントラクトの脆弱性を悪用した攻撃により、数億ドルが流出しています。

ビットコインスクリプトでは、この種の攻撃は構造的に不可能です。他のスクリプトを呼び出したり、条件が変わるまでループを繰り返したり、トランザクション間で状態を保持したりするようなビットコインスクリプトを書くことはできません。 すべてのスクリプトは、範囲が限定され、必ず終了し、検証可能なプログラムです。スクリプトの最大サイズは10,000バイトです。スクリプト1つあたりの「push」以外のオペコードの最大数は201個です。バリデーターは、スクリプトを実行する前に、常に最悪ケースの実行コストを計算することができます。

数千億ドルの価値を持つネットワークにとって、その予測可能性は、犠牲にする柔軟性よりもはるかに価値がある。 イーサリアムは、ガス制限を設けることで無制限の計算という問題を解決しており、実行された各オペコードに対してユーザーに課金し、予算が尽きたスクリプトを停止させる。これは機能するが、それ自体に複雑さや障害の原因をもたらす。ビットコインは、設計上、この問題を完全に回避している。

とはいえ、「チューリング完全ではない」からといって、「複雑な論理処理ができない」という意味ではありません。ビットコインスクリプトは、複数当事者による支出要件、時間に基づく条件、ハッシュのプリイメージの開示、およびこれらすべての組み合わせをサポートしています。1日あたり数百万件の支払いを処理するライトニングネットワークは、完全にビットコインスクリプトのプリミティブに基づいて構築されています。

スクリプトの種類：P2PKHからTaprootへの進化

ビットコインのスクリプト層は2009年以来、著しく進化してきました。各アップグレードでは新しいトランザクション形式が導入される一方で、それ以前のすべてのバージョンとの下位互換性が維持されています。

P2PK（Pay-to-Public-Key、2009年）

ブロック170におけるサトシからハル・フィニーへの支払いをはじめ、初期のビットコイン取引で使用されていた元の形式。資金は、公開鍵のハッシュではなく、公開鍵そのものに直接紐付けられていた。 現在では、送金前に公開鍵がオンチェーン上で公開されてしまうため、新しい取引ではほとんど使用されていません。これは、事前に鍵をハッシュ化する場合に比べてセキュリティ上の脆弱性が高いと考えられているためです。

P2PKH（Pay-to-Public-Key-Hash、2009年）

10年以上にわたり標準形式として採用されてきた。P2PKHは、鍵そのものではなく公開鍵のハッシュに資金を紐づけることで、支出の瞬間まで公開鍵を非公開に保ち、20バイトという短いアドレスを生成する。また、「1」で始まるすべてのアドレスの基礎となっている。 Unchainedのオンチェーンデータ（2026年4月）によると、P2PKHアドレスには現在、採掘済みのビットコイン供給量の約43％が保有されています。

P2SH（Pay-to-Script-Hash、2012年、BIP 16）

2012年4月1日にソフトフォークを通じて導入されたP2SHは、複雑な支出スクリプトの負担を送信者から受信者へと移行させました。P2SHでは、出力に完全なロックスクリプトを埋め込む代わりに、「リディームスクリプト」の20バイトのハッシュに対するコミットを出力します。 完全なスクリプトが明らかになるのは、コインが使用されたときだけです。これにより、マルチシグが一般ユーザーにとっても実用的なものとなりました。つまり、3つの公開鍵のうち2つが必要となるマルチシグの設定において、支払い時に送信者が3つの公開鍵すべてを確認する必要がなくなったのです。P2SHアドレスの先頭は「3」で始まります。

プロトコルレベルでのP2SH検証の仕組みに関する詳細な解説については、 developer.bitcoin.orgのトランザクションガイド Redeemスクリプトの仕組みを段階的に解説します。

P2WPKH および P2WSH（ネイティブ SegWit、2017年、BIP 141）

2017年8月、ブロック481,824で有効化されたSegregated Witness（SegWit）は、署名データをトランザクションの本文から切り離し、独立したウィットネス構造に移しました。ウィットネスデータには75%のウェイト割引が適用されるため、SegWitトランザクションは大幅に安価になります。 ある報告によると、標準的な単一入力・2出力のP2WPKHトランザクションのウェイトは約141仮想バイトであるのに対し、同等のP2PKHトランザクションのウェイトは226仮想バイトである。 Sparkによるビットコインアドレスの種類に関する分析 2026年3月から。SegWitは、ライトニングネットワークの導入に不可欠だったトランザクションの改ざん可能性の問題も解決しました。ネイティブのSegWitアドレスは「bc1q」で始まります。

P2TR（Pay-to-Taproot、2021年、BIP 340/341/342）

Taprootは2021年11月、ブロック709,632で有効化され、SegWit以来、ビットコインのスクリプト層における最も重要なアップグレードとなりました。これにより、シュノール署名、MASTをサポートする新しい出力タイプ、および更新されたスクリプト言語であるTapscriptが導入されました。 Taprootのアドレスは「bc1p.」で始まります。

TaprootとTapscript：2021年にビットコインのスクリプト言語がどのように変化したか

Taprootは単一の変更ではありません。これは、一体となって設計され、同時に有効化された3つのビットコイン改善提案（BIP）です。

BIP 340：シュノール署名

ビットコインは当初、ECDSA（楕円曲線デジタル署名アルゴリズム）を採用していました。サトシがこれを選んだ理由の一つは、当時シュノール署名が特許で保護されていたためでした。その特許は2008年に失効し、Taprootによってようやくシュノール署名がプロトコルに導入されました。

シュノール署名は64バイトと、ECDSAの71～73バイトに比べてサイズが小さい。 さらに重要な点として、シュノル署名はMuSig2と呼ばれる方式による鍵の集約をサポートしています。鍵の集約により、複数の署名者は各自の鍵と署名を1つの集約鍵および署名に統合することができ、これはオンチェーン上では通常の単一署名による支払いと見分けがつきません。 Taprootの協調型キーパスを通じて支出を行う2-of-3マルチシグウォレットは、ブロックチェーン上では標準的な支払いと全く同じように見えます。これは、複雑なカストディ契約の下でビットコインを保有している人にとって、真のプライバシー上の利点となります。

BIP 341：Pay-to-Taproot および MAST

P2TRでは、2つの支出経路を持つ新しい出力タイプを導入します：

• A キーパス シュノール署名を使用して処理する。これは、すべての当事者が合意し、最も単純で安価な方法を希望する場合に用いられる。
• A スクリプトのパス MAST（Merkelized Abstract Syntax Tree。これはTaprootにおける同概念の実装である）を使用して支出を行う

MASTでは、単一の出力がマークルルートを通じて、複数の支出スクリプトからなるツリーにコミットすることができます。支出を行う際、オンチェーンで公開されるのは、実際に使用された特定の条件のみです。ツリー内のその他のすべての可能な支出パスは、永久に非公開のままとなります。 「通常通り支出できる」「6か月後に3人の受託者のうち2人が支出できる」「2年後にリカバリーキーで支出できる」といった複雑な支出ポリシーを設定したユーザーの場合、実際に実行された経路のみがブロックチェーン上に記録されます。

2024年時点で、ビットコイン取引におけるTaprootのシェアは約42%にまで拡大していた。Sparkが2026年3月に引用したGlassnodeのデータによると、この拡大は主にOrdinalsやBRC-20のインスクリプション活動によるものである。 それ以降、その割合は市場の状況に応じて変動してきたが、現在では主要なウォレットや取引所において、このインフラが標準となっている。 Bitcoin OptechのTaprootトピックページ Taprootをめぐるプロトコルの開発状況を追跡しています。

BIP 342: Tapscript

Tapscriptは、Taproot内のスクリプトパスでの支出に使用される、更新されたスクリプト言語です。従来のBitcoin Scriptとほとんどのオペコードを共有していますが、いくつかの重要な変更が加えられています：

• OP_CHECKMULTISIG そして OP_CHECKMULTISIGVERIFY は非推奨となっています。以前のマルチシグ・オペコードには、回避策としてダミーの要素をスタックにプッシュする必要があったという癖がありました。Tapscriptではこれを削除し、代わりに OP_CHECKSIGADD, これはシュノール署名を1つずつ検証し、その回数を累積していくものです。これにより、しきい値マルチシグ方式の実装がより簡潔になり、実行コストも削減されます。
• MASTリーフごとのスクリプトサイズ制限が撤廃されました。Taprootブランチ内の個々のスクリプトは、任意の大きさまで設定可能です。
• OP_SUCCESS オペコード これは最も先見性のある変更点です。従来のスクリプトでは、未定義のオペコードに遭遇するとスクリプトは失敗します。一方、Tapscriptでは、OP_SUCCESS範囲のオペコードは、無条件にスクリプトを成功させます。 今後のソフトフォークでは、これらのオペコードがいつ成功するかについて制約を追加することで、実際の動作を割り当てることが可能になります。その際、新しいスクリプトバージョンの導入や、エコシステム全体にわたる完全な再展開サイクルを必要としません。ビットコインのスクリプトレイヤーには、プロトコルの歴史上かつてないほどクリーンな形で、新たな機能が追加されることになります。

ミニスクリプト

Tapscriptと並んで、Miniscriptという関連プロジェクトが開発者にとってますます重要になってきています。Miniscriptは、ビットコインスクリプトのサブセットを構造化された方法で記述するもので、分析可能、組み合わせ可能、かつ汎用的に署名可能です。 生のScriptは手作業での構築が必要で監査が困難であるのに対し、Miniscriptのスクリプトは正しさを自動的に検証でき、より大規模なポリシーに組み合わせて利用することが可能です。これはScriptの機能範囲を拡張するものではありませんが、ウォレットやカストディツールを開発する開発者にとって、既存の機能を格段に利用しやすくするものです。

ビットコインスクリプトが実現するもの：実社会での活用事例

現在、ビットコインのメインネットでは以下のトランザクションタイプが有効となっており、これらはすべてビットコインスクリプトのプリミティブに基づいて構築されています：

マルチシグネチャ（マルチシグ）ウォレット 支出を承認するには、M-of-Nの秘密鍵が必要となります。 企業の財務部門では、出金に際して5人中3人の承認を必要とする場合があります。夫婦では、共同の貯蓄口座に対して2人中2人の承認を採用する場合もあります。TaprootとSchnorr鍵の集約技術により、協力型のマルチシグ取引は、オンチェーン上では標準的な単一署名取引と見分けがつかなくなりました。

タイムロック取引 OP_CHECKLOCKTIMEVERIFY（CheckLockTimeVerify、またはCLTV）およびOP_CHECKSEQUENCEVERIFY（CheckSequenceVerify、またはCSV）を使用することで、特定のブロック高または経過時間になる前に資金が移動されるのを防ぐことができます。 主な用途としては、相続計画、従業員のトークン権利確定スケジュール、強制貯蓄メカニズム、およびライトニングネットワークのチャネル内で使用されるペナルティ取引などが挙げられます。

ハッシュ・タイムロック契約（HTLC） ハッシュの原像要件とタイムロックを組み合わせたものです。支出条件は次のように機能します。このブロック高に達する前に、このハッシュの原像を開示しなければ、資金は送信者に返還されます。HTLCはライトニングネットワークの中核となるプリミティブであり、直接的な関係を持たない当事者間のチャネルチェーンを横断して、信頼不要な支払いのルーティングを可能にします。

エスクロー この仕組みでは、資金がP2SHまたはTaprootスクリプトにロックされ、解放には複数の当事者の合意が必要となります。通常、決定権を持つ鍵を第三者の仲裁人が保持しています。

Discreet Log Contracts（DLC） オラクルベースのシュノール・アダプター署名を使用することで、価格フィードやイベントの結果といった実世界のデータに基づいて決済される金融契約を可能にし、オラクルが資金を保管する必要をなくします。DLCはビットコインのメインネット上で稼働しており、ビットコインで決済されるオプションや先物商品に利用されています。

ビットコインのスクリプトとイーサリアムのスマートコントラクトの比較

ビットコインのスクリプトとイーサリアムのソリディティは、いずれも資金の移動が可能な条件を定義していますが、そのアーキテクチャ上の選択は根本的に異なります。この違いは、各ネットワークが受け入れたトレードオフについて多くのことを説明してくれるため、両者を直接比較してみる価値があります。

根本的な違いは、ステート（状態）の有無にあります。イーサリアムのスマートコントラクトは、トランザクションを超えて保持されるデータを保存・変更するため、貸付プロトコル、分散型取引所、オンチェーンガバナンス、トークン規格などが可能になります。ビットコインのスクリプトには、これに相当する機能はありません。各スクリプトは、他のトランザクションに関する情報を一切持たない孤立した環境で実行されます。

これは意図的なアーキテクチャ上の選択であり、埋めるべき欠陥というわけではありません。ビットコインのスクリプト層は、ビットコインを大規模かつ予測可能かつ安全に支出するための条件を強制するという、ある特定の目的のために設計されました。 その役割において、ステートレス性は強みとなります。攻撃対象領域が狭く、何百万もの独立したバリデーター間で実行が決定論的であり、プロトコルレベルにはステートフルな契約が存在しないため、プロトコルレベルでのスマートコントラクトの悪用というカテゴリーは存在しません。

ビットコインの上にさらなるプログラム可能性を求めるプロジェクトは、レイヤー構造で構築されています。ライトニング・ネットワークは決済を処理し、DLCプロトコルは外部データを参照する金融契約を扱います。ArkやLiquid Networkのようなレイヤー2システムは、それぞれ異なるスケーラビリティの要件に対応しています。これらはいずれも、ベースレイヤーのスクリプトモデルを変更する必要はありません。

「コヴナント」をめぐる議論：ビットコインのスクリプトにどのような変化が生じるのか

ビットコインスクリプトの進化は、常に緩やかで保守的なものでした。現在、最も活発に開発が進められている分野は「コヴナント・オペコード」です。これは、スクリプトがアウトプットの支出者を制限するだけでなく、その結果として生成されるトランザクションがどのような形式でなければならないかを規定できるようにする提案です。これは、スクリプトの表現力を大きく拡張するものです。

2026年6月時点での主な提案は以下の通りです：

• OP_CTV (BIP-119、CheckTemplateVerify)ジェレミー・ルービン氏が提案したこの提案は、UTXOを、トランザクションのバージョン、ロックタイム、入力数、シーケンス、出力数、および出力を含む、あらかじめ定められた特定の支出テンプレートにコミットする単一のオペコードを追加するものである。 この提案は設計上非再帰的であり、主要な提案の中で最も保守的なものと見なされており、主にボールト、輻輳制御、および特定のライトニングネットワークの改善を目的としています。2026年4月現在、OP_CTVについては「Speedy Trial」シグナリングウィンドウを規定した具体的な導入パラメータが提示されていますが、 BlockEdenによる2026年4月の契約条項分析.
• OP_CAT (BIP-347)、イーサン・ハイルマンとアルミン・サブーリによって提案されたこの機能は、2010年にサトシが無効化したオペコードを再び有効にするものである。OP_CATは2つのスタック項目を連結するもので、説明は単純だが、その影響は広範囲に及ぶ。シュノール署名と組み合わせることで、コヴナントのようなトランザクションの内部検証が可能になる。 2024年後半のsCryptによるオンチェーン分析によると、ビットコインのテストネットワーク「Signet」において、OP_CATはAPOやCTVのいずれよりもはるかに多くの開発者向けトランザクションを生成していた。OP_CATはすでにLiquid NetworkやFractal Bitcoinで稼働しており、これによる悪用事例は報告されていない。 BIP-347には公式の提案番号が割り当てられており、活発な研究も行われていますが、メインネットでの実装にはコミュニティの合意が必要であり、現時点ではその合意は形成されていません。
• LNHANCE OP_CTVをOP_CHECKSIGFROMSTACK（CSFS）およびOP_INTERNALKEYと組み合わせ、非対話型のチャネル開設や、より効率的な多者間チャネル管理など、ライトニングネットワークのチャネル構築における具体的な改善を目指しています。

2026年6月現在、これらはいずれもビットコインのメインネットでは有効化されていない。これら間の技術的な意見の相違は、概ね解決可能である。 より難しい問題は、実装の仕組みである。ビットコインのソフトフォークプロセスには広範な合意が必要であり、コヴェナントをめぐる議論には、過去の論争を呼んだアップグレードから残る緊張感が残っている。この議論から明らかなのは、ビットコインのスクリプト層には、その保守的な枠組みの中で成長する余地が十分にあるということだ。現在検討されているのは、スクリプト言語に将来性があるかどうかではなく、実施順序とコミュニティの合意についてである。

結論

ビットコインスクリプトは、ネットワーク上のあらゆる取引の根底にある目に見えないインフラストラクチャです。 ほとんどのユーザーは、これを直接目にすることはありません。ウォレットは、その仕組みを一切露呈させることなく、有効なスクリプトを構築し、署名し、ネットワークに送信します。しかし、あらゆる支払い、あらゆるライトニング・チャネル、あらゆるタイムロックされたプラン、あらゆるマルチシグ・ヴォールトは、2009年にプロトコルとともに導入された、スタックベースのビットコインスクリプト言語を通じて処理されています。

それ以来、スクリプト層は著しく発展し、P2SHによって複雑な送金が実用化され、SegWitによって手数料が削減されライトニングネットワークが実現し、Taprootによってシュノール署名、MASTに基づくプライバシー機能、そしてTapscriptの将来互換性のあるオペコード設計が導入されました。 現在活発に議論されているコヴナント提案は、次の可能性のある展開を示しています。2026年半ばの時点で、これらの提案のうちどれが実装されるのか、またそのスケジュールはどのようになるのかについては、依然として不透明な状況です。

スクリプトを理解するのに、開発者である必要はありません。ただし、ビットコインの保守性、意図的な制限、アップグレードのペースの遅さ、チューリング完全性を持たないことなどが、欠点ではないことを認識する必要があります。ビットコイン・スクリプトを予測可能にしている特性こそが、16年間にわたりコンセンサス層をクリーンな状態に保ってきた要因なのです。