本記事にはアフィリエイト広告（PR）を含む場合があります。
※本記事にはアフィリエイト広告（A8.net）を含みます。記載の内容は2026年8月時点で公開情報を確認した一般的な解説です。
ビットコインは単なるデジタル通貨の送受信システムではなく、実はプログラマブルな要素を持つネットワークです。ビットコインのトランザクションには「Script（スクリプト）」と呼ばれる独自のプログラミング言語が組み込まれており、送金条件をプログラムとして記述することができます。このScript言語の存在こそが、ビットコインを「プログラマブルマネー」たらしめている基盤と言えるでしょう。
ビットコインのScriptは、イーサリアムのSolidityのようなチューリング完全な言語とは異なり、意図的に機能が制限されたスタックベースの言語です。ループ（繰り返し処理）が存在せず、実行が必ず終了することが保証されています。この設計は、セキュリティと予測可能性を最優先するビットコインの哲学を反映したものです。
本記事では、ビットコインScriptの基本概念から、具体的なオペコード（命令）の仕組み、P2PKH・P2SH・SegWit・Taprootといった主要なスクリプトタイプ、そしてScript言語が持つ可能性と限界まで、包括的に解説していきます。ビットコインの技術的な仕組みに興味がある方にとって、Scriptの理解はプロトコルの本質に迫る重要なステップとなるでしょう。
目次
日本円の入出金に対応した国内の登録業者なら、購入から送金まで一つの口座で完結します。口座開設と維持の費用はかからず、取扱銘柄や手数料体系は公式サイトで確認できます。
口座開設の手順を見る（無料） →PR・GMOコイン（GMOコイン株式会社）。手数料や取扱銘柄は変更されることがあるため、最新の内容は公式サイトでご確認ください。暗号資産は価格変動が大きく、投資判断はご自身の責任でお願いします。
1. ビットコインScriptとは？基本概念の理解
1-1. Scriptの定義と目的
ビットコインScript（ビットコインスクリプト）は、ビットコインのトランザクションに組み込まれた軽量なプログラミング言語です。スクリプトの主な目的は、「ビットコインを使用（送金）するための条件」を定義することにあります。
従来の銀行送金では、「口座の持ち主が送金を指示する」という単純な認証モデルが使われています。ビットコインのScriptは、これをより柔軟にプログラムとして記述できるようにしたものです。最も基本的なスクリプトは「正しい秘密鍵を持っている人だけが送金できる」というものですが、Scriptの仕組みを使えば、以下のような条件も設定できます。
- 3人のうち2人が署名すれば送金可能（マルチシグ）
- 特定の時刻を過ぎたら送金可能（タイムロック）
- 特定のハッシュ値のプリイメージ（原像）を知っている人が送金可能（ハッシュロック）
- 上記の条件を組み合わせた複合条件
Scriptは、ビットコインのプロトコルの開始時（2009年のジェネシスブロック）から存在する機能であり、サトシ・ナカモトの設計に含まれていた要素です。
1-2. 設計思想：意図的な機能制限
ビットコインのScriptが持つ最も特徴的な設計思想は、「意図的に機能を制限している」という点です。
Scriptはチューリング不完全（Turing-Incomplete）な言語です。チューリング完全とは、理論上あらゆる計算を実行できる能力を持つことを指しますが、ScriptはJUMP命令（ループやgotoに相当する命令）を持たず、プログラムの実行が必ず有限のステップで終了することが保証されています。
この設計にはいくつかの重要な理由があります。
DoS攻撃の防止: チューリング完全な言語では、無限ループを含むプログラムを実行させることで、ノードのリソースを枯渇させるDoS攻撃が可能になります。Scriptではこのリスクが原理的に排除されています。
予測可能性: スクリプトの実行結果が常に予測可能であり、実行時間も有限であることが保証されています。これは、金融取引の基盤としての信頼性を担保する上で重要な性質です。
セキュリティ: 機能が限定されていることにより、攻撃面（Attack Surface）が小さくなります。複雑なプログラムほどバグや脆弱性が生じやすいため、意図的にシンプルに保つことでセキュリティを高めています。
検証の容易さ: スクリプトのサイズと実行ステップ数に上限があるため、すべてのノードが効率的にスクリプトを検証できます。
1-3. イーサリアムとの比較
ビットコインのScriptとイーサリアムのEVM（Ethereum Virtual Machine）/Solidityを比較すると、設計哲学の根本的な違いが見えてきます。
ビットコインScriptは「トランザクションの検証」に特化しており、スクリプトの実行結果は基本的にTRUE（有効）またはFALSE（無効）のいずれかです。一方、イーサリアムのEVMは「汎用的な計算」を行う仮想マシンであり、状態の変更、ストレージへの書き込み、複雑なロジックの実行が可能です。
ビットコインScriptでは状態を持たず（ステートレス）、各トランザクションは独立して検証されます。イーサリアムではグローバルな状態（ワールドステート）が存在し、スマートコントラクトの実行によって状態が遷移します。
この違いは、ビットコインが「デジタルゴールド」「安全な価値保存手段」を志向し、イーサリアムが「分散型コンピュータ」「プログラマブルプラットフォーム」を志向するという、両者の根本的な方向性の違いを反映しています。
2. UTXOモデルとスクリプトの関係
2-1. UTXOとは
ビットコインのScriptを理解するには、まず「UTXO（Unspent Transaction Output）」モデルを理解する必要があります。
UTXOとは「未使用のトランザクション出力」のことで、ビットコインネットワーク上でまだ使用（消費）されていないビットコインのことを指します。ビットコインのウォレットに表示される「残高」は、実際にはそのアドレスに関連するUTXOの合計額です。
銀行口座のように「残高」という数値が記録されるのではなく、ビットコインでは個々のUTXOが「コイン」のように存在しています。例えば、ウォレットの残高が1.5 BTCの場合、それは「1.0 BTCのUTXO」と「0.5 BTCのUTXO」で構成されているかもしれません。
トランザクションは、既存のUTXOを「入力（Input）」として消費し、新しいUTXOを「出力（Output）」として生成するプロセスです。入力の合計額と出力の合計額の差が、マイナー（現在はバリデーターやマイニングプールの報酬的な手数料）に支払うトランザクション手数料となります。
2-2. ScriptPubKeyとScriptSig
ビットコインのスクリプトは、トランザクションの出力と入力にそれぞれ配置される2つの部分で構成されています。
ScriptPubKey（出力スクリプト / ロッキングスクリプト）: トランザクションの出力（UTXO）に含まれるスクリプトで、「このビットコインを使うための条件」を定義します。名前の由来は、一般的にこのスクリプトが受取人の公開鍵（Public Key）のハッシュを含んでいることに基づいています。ロッキングスクリプト（Locking Script）とも呼ばれ、ビットコインに「鍵」をかける役割を果たします。
ScriptSig（入力スクリプト / アンロッキングスクリプト）: トランザクションの入力に含まれるスクリプトで、ScriptPubKeyで設定された条件を満たすための「証拠」（通常はデジタル署名と公開鍵）を提供します。アンロッキングスクリプト（Unlocking Script）とも呼ばれ、「鍵を開ける」役割を果たします。
トランザクションの検証時、ノードはScriptSigとScriptPubKeyを結合して実行します。具体的には、まずScriptSigが実行され、次にScriptPubKeyが実行されます。最終的にスタックの一番上にTRUE（非ゼロの値）が残っていれば、トランザクションは有効と判定されます。
2-3. トランザクション検証の流れ
具体的なトランザクション検証の流れを、最も一般的なP2PKH（Pay-to-Public-Key-Hash）スクリプトを例に見てみましょう。
ScriptPubKey（ロッキングスクリプト）:
OP_DUP OP_HASH160 <PubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
ScriptSig（アンロッキングスクリプト）:
<Signature> <PublicKey>
これらが結合されて以下の順序で実行されます。
<Signature> をスタックにプッシュ<PublicKey> をスタックにプッシュOP_DUP でスタックのトップの値（PublicKey）を複製OP_HASH160 で複製された公開鍵のハッシュ（RIPEMD160(SHA256(PublicKey))）を計算<PubKeyHash> をスタックにプッシュOP_EQUALVERIFY でスタックの上位2つの値（計算されたハッシュとPubKeyHash）が等しいか検証OP_CHECKSIG でスタックに残った署名と公開鍵を使って、トランザクションの署名を検証すべてのステップが成功し、最終的にスタックにTRUEが残っていれば、トランザクションは有効です。これにより、「正しい秘密鍵の持ち主のみがこのUTXOを使用できる」という条件が暗号学的に検証されたことになります。
3. スタックベースの実行モデル
3-1. スタックの基本
ビットコインScriptは「スタックベース」の実行モデルを採用しています。スタックとは、データを積み上げて管理するデータ構造で、「後入れ先出し（LIFO: Last In, First Out）」の原則に従います。
スタックの操作は基本的に2つです。
- プッシュ（Push）: データをスタックの一番上に積む
- ポップ（Pop）: スタックの一番上のデータを取り出す
ビットコインScriptの実行は、スクリプトの先頭から順番に命令（オペコード）を読み取り、1つずつ処理していきます。データ要素（署名や公開鍵など）が現れたらスタックにプッシュし、オペコードが現れたらスタックからデータを取り出して処理を行い、結果をスタックに戻します。
3-2. メインスタックとオルトスタック
ビットコインScriptには2つのスタックが存在します。
メインスタック: ほとんどすべての処理が行われる主要なスタックです。データのプッシュ、演算、検証はすべてメインスタック上で行われます。
オルトスタック（代替スタック）: 一時的なデータの退避に使用される補助的なスタックです。OP_TOALTSTACK（メインスタックからオルトスタックへ移動）とOP_FROMALTSTACK（オルトスタックからメインスタックへ移動）の2つのオペコードでアクセスします。
オルトスタックは、複雑なスクリプトでスタック内のデータを整理する際に便利です。例えば、複数のマルチシグ条件を検証する際に、途中の計算結果を一時的にオルトスタックに退避させ、別の検証を行った後に戻すといった使い方ができます。
3-3. スクリプトの実行例
簡単なスクリプトの実行例を追ってみましょう。以下のスクリプトは、「2 + 3 = 5」を検証するものです。
スクリプト: OP_2 OP_3 OP_ADD OP_5 OP_EQUAL
実行ステップ:
ステップ1: OP_2 → スタックに2をプッシュ。スタック: [2]
ステップ2: OP_3 → スタックに3をプッシュ。スタック: [2, 3]
ステップ3: OP_ADD → スタックから2つの値（2と3）をポップし、加算結果（5）をプッシュ。スタック: [5]
ステップ4: OP_5 → スタックに5をプッシュ。スタック: [5, 5]
ステップ5: OP_EQUAL → スタックから2つの値（5と5）をポップし、等しければTRUE（1）をプッシュ。スタック: [TRUE]
最終的にスタックの一番上にTRUEが残っているため、このスクリプトは成功と判定されます。
もちろん、実際のビットコインのスクリプトではこのような単純な算術ではなく、暗号学的な署名検証やハッシュ比較が行われます。しかし、基本的なスタック操作の仕組みは同じです。
この記事は要点を絞って書いていますが、暗号技術やコンセンサスの前提から順に追いたい場合は、章立てされた書籍のほうが理解が早く済みます。この分野は版によって扱う内容が大きく変わるので、目次と発行年を確認してから選んでください。
Amazonで関連書籍を見る →PR・Amazonアソシエイト（A8.net経由）。価格や在庫は変動します。
4. 主要なオペコード（命令）の解説
4-1. データプッシュ系オペコード
ビットコインScriptのオペコードのうち、最も頻繁に使われるのがデータをスタックにプッシュする命令です。
OP_0（OP_FALSE）: 空のバイト列をスタックにプッシュします。これはFALSE値としても機能します。
OP_1〜OP_16: 数値1〜16をスタックにプッシュします。小さな数値を効率的にプッシュするためのショートカットです。
OP_PUSHDATA1〜OP_PUSHDATA4: 任意のサイズのデータをスタックにプッシュします。署名データや公開鍵などの可変長データを扱う際に使用されます。
なお、スクリプト内で直接バイト列として記述されたデータ（署名、公開鍵、ハッシュなど）は、暗黙的にスタックにプッシュされます。
4-2. 暗号学系オペコード
ビットコインのセキュリティの根幹を支えるのが暗号学系のオペコードです。
OP_HASH160: スタックのトップの値をSHA-256でハッシュした後、さらにRIPEMD-160でハッシュします。ビットコインアドレスの生成に使われるダブルハッシュ処理です。
OP_SHA256: スタックのトップの値のSHA-256ハッシュを計算します。
OP_RIPEMD160: スタックのトップの値のRIPEMD-160ハッシュを計算します。
OP_CHECKSIG: スタックから公開鍵と署名を取り出し、トランザクションの署名を検証します。署名が有効であればTRUE、無効であればFALSEをプッシュします。ビットコインの所有権証明の核心となるオペコードです。
OP_CHECKMULTISIG: 複数の公開鍵と複数の署名を検証するマルチシグ用のオペコードです。m-of-n マルチシグ（n個の公開鍵のうちm個の署名が必要）を実現します。
4-3. フロー制御系オペコード
スクリプトの条件分岐を実現するオペコードです。
OP_IF / OP_ELSE / OP_ENDIF: 条件分岐を実現します。OP_IFはスタックのトップがTRUEの場合に次のブロックを実行し、FALSEの場合はOP_ELSEブロックを実行します。OP_ENDIFで条件分岐を終了します。
OP_VERIFY: スタックのトップがTRUEでなければ、スクリプトの実行を即座に失敗させます。条件チェックのショートカットとして使われます。
OP_RETURN: スクリプトの実行を即座に失敗させます。トランザクションの出力に任意のデータを埋め込む用途でも使われます。OP_RETURNを含む出力は「使用不可能な出力（provably unspendable output）」として扱われ、UTXOセットに含まれません。
4-4. タイムロック系オペコード
時間や高さに基づく送金条件を設定するオペコードです。
OP_CHECKLOCKTIMEVERIFY（CLTV / OP_HODL）: BIP 65で導入されたオペコードで、指定された時刻またはブロック高さに達するまで、UTXOの使用を禁止します。絶対的なタイムロック（特定の未来の時点まで送金を制限）を実現します。
OP_CHECKSEQUENCEVERIFY（CSV）: BIP 112で導入されたオペコードで、トランザクションの入力に含まれるシーケンス番号に基づく相対的なタイムロックを実現します。「この出力が作成されてからN ブロック（またはN 秒）経過しなければ使用できない」という条件を設定できます。
これらのタイムロックオペコードは、Lightning Networkなどのレイヤー2プロトコルの基盤技術として重要な役割を果たしています。
5. 標準スクリプトタイプの詳細
5-1. P2PKH（Pay-to-Public-Key-Hash）
P2PKH（Pay-to-Public-Key-Hash）は、ビットコインで最も長く使われてきた標準的なスクリプトタイプです。「公開鍵のハッシュに対して支払う」という意味で、ビットコインアドレスの「1」から始まるアドレス形式（Legacy Address）に対応しています。
P2PKHのスクリプト構造は以下の通りです。
ScriptPubKey（ロッキング）:
OP_DUP OP_HASH160 <20バイトの公開鍵ハッシュ> OP_EQUALVERIFY OP_CHECKSIG
ScriptSig（アンロッキング）:
<署名> <公開鍵>
P2PKHの仕組みは前述の「トランザクション検証の流れ」で解説した通りです。ポイントは、ScriptPubKeyに公開鍵そのものではなく、公開鍵のハッシュ（HASH160 = RIPEMD160(SHA256(pubkey))）が含まれている点です。これにより、以下のメリットがあります。
- アドレスのサイズが小さくなる（公開鍵は33バイト、ハッシュは20バイト）
- 量子コンピュータ攻撃に対する追加の防御層を提供する（公開鍵はトランザクション送信時にのみ公開される）
5-2. P2SH（Pay-to-Script-Hash）
P2SH（Pay-to-Script-Hash）は、BIP 16で2012年に導入されたスクリプトタイプで、ビットコインのプログラマビリティを大幅に拡張した重要な改善です。アドレスは「3」から始まります。
P2SHの革新的な点は、複雑なスクリプト（リディームスクリプト）のハッシュのみをScriptPubKeyに含め、実際のスクリプト内容はUTXOを使用する時（ScriptSig内）に提供する仕組みにあります。
ScriptPubKey（ロッキング）:
OP_HASH160 <20バイトのスクリプトハッシュ> OP_EQUAL
ScriptSig（アンロッキング）:
<スクリプトの引数...> <シリアライズされたリディームスクリプト>
P2SHにより、送金者はスクリプトの詳細を知る必要がなくなりました。送金者は単にP2SHアドレス（スクリプトのハッシュから生成）に送金するだけでよく、受取人が資金を使う際に実際のスクリプトを提示して条件を満たすことになります。
P2SHの代表的な利用例がマルチシグです。2-of-3マルチシグ（3つの鍵のうち2つの署名が必要）の場合、リディームスクリプトは以下のようになります。
OP_2 <PubKey1> <PubKey2> <PubKey3> OP_3 OP_CHECKMULTISIG
P2SHなしでは、送金者がこの複雑なスクリプトをScriptPubKeyに直接含める必要がありましたが、P2SHではスクリプトのハッシュ（固定20バイト）のみが含まれるため、送金の手間とコストが大幅に軽減されます。
5-3. P2WPKH / P2WSH（SegWit v0）
SegWit（Segregated Witness）の導入に伴い、新しいスクリプトタイプとしてP2WPKH（Pay-to-Witness-Public-Key-Hash）とP2WSH（Pay-to-Witness-Script-Hash）が追加されました。これらは「bc1q」から始まるBech32アドレス形式に対応しています。
P2WPKH: P2PKHのSegWit版です。スクリプトの構造はP2PKHと同様ですが、署名データ（Witness）がトランザクションの本体から分離されています。
ScriptPubKey: OP_0 <20バイトの公開鍵ハッシュ>
Witness（従来のScriptSigの代わり）: <署名> <公開鍵>
P2WSH: P2SHのSegWit版です。より大きなリディームスクリプトを効率的に扱えるように設計されています。
ScriptPubKey: OP_0 <32バイトのスクリプトハッシュ>
Witness: <スクリプトの引数...> <リディームスクリプト>
SegWitスクリプトの利点は後の章で詳しく解説します。
5-4. マルチシグスクリプトの仕組み
マルチシグ（Multisignature）スクリプトは、複数の署名者のうち一定数以上の署名がなければビットコインを使用できないように設定するスクリプトです。m-of-n マルチシグでは、n個の公開鍵が登録され、そのうちm個以上の対応する署名が必要です。
マルチシグは以下のような用途で広く利用されています。
- セキュリティ強化: 1つの秘密鍵が漏洩しても、他の鍵が安全であれば資金は保護される
- 組織の資金管理: 企業やDAOの資金を複数の管理者で管理する
- エスクロー（第三者預託）: 買い手、売り手、仲裁者の3者のうち2者の同意で取引を実行する
OP_CHECKMULTISIGオペコードには、サトシ・ナカモトの時代から存在するバグ（off-by-one error）があり、スタックから余分にダミー要素をポップしてしまいます。このため、ScriptSig/Witnessの先頭にダミーのOP_0を追加する必要があります。このバグは互換性の問題から修正されておらず、現在もそのまま残されています。
6. SegWitとScriptの進化
6-1. SegWitの概要
SegWit（Segregated Witness、分離型署名）は、2017年8月にBIP 141としてビットコインネットワークに導入されたソフトフォークアップグレードです。SegWitはビットコインの歴史において最も重要なプロトコル改善の一つとされています。
「Segregated Witness」の名前が示す通り、SegWitの核心は署名データ（Witness）をトランザクションの本体から「分離（Segregate）」することにあります。従来のトランザクションでは、署名データがScriptSig（入力スクリプト）内に含まれていましたが、SegWitでは署名データが別の構造（Witness）に移されます。
6-2. SegWitが解決した問題
SegWitの導入により、以下の重要な問題が解決されました。
トランザクションの展性（Malleability）の修正: SegWit以前は、署名データ（ScriptSig）がトランザクションIDの計算に含まれていたため、署名の形式を変更する（数学的には同等だが異なるバイト列に変換する）ことで、トランザクションの内容を変えずにトランザクションIDを変更できてしまう問題がありました。
この「トランザクション展性」問題は、Lightning Networkなどのレイヤー2プロトコルの実装を困難にしていました。Lightning Networkでは、署名前のトランザクションのIDを参照して次のトランザクションを構築する必要がありますが、署名後にIDが変わる可能性があると、チャネルの安全性を保証できないためです。
SegWitでは、署名データがWitnessに分離され、新しいトランザクションID（wtxid）の計算には含まれないため、トランザクション展性の問題が解消されました。
実質的なブロック容量の拡大: SegWitは「ウェイト」という新しい単位を導入しました。ブロックの上限は従来の1MB（100万バイト）から4MW（400万ウェイトユニット）に変更されました。通常のトランザクションデータは1バイト = 4ウェイトで計算されますが、Witnessデータは1バイト = 1ウェイトで計算されます。これにより、Witnessデータを含むSegWitトランザクションは、従来のトランザクションよりもウェイトあたりの実効データ量が大きくなり、ブロック容量が実質的に約1.7〜2倍に拡大しました。
スクリプトバージョニングの導入: SegWitは「Witnessバージョン」という概念を導入し、将来的にスクリプト仕様を拡張するための柔軟な枠組みを提供しました。SegWit v0（P2WPKH/P2WSH）に続いて、SegWit v1（Taproot）が導入されましたが、v2〜v16までのバージョン番号が将来の拡張のために予約されています。
6-3. SegWitの後方互換性
SegWitはソフトフォーク（後方互換性のあるアップグレード）として導入されたため、SegWitに対応していない古いノードでもネットワークに参加し続けることができます。
古いノードにとって、SegWitトランザクションのScriptPubKey（OP_0 <20バイトのハッシュ>）は「誰でも使用可能」に見えます。しかし、SegWit対応ノードは追加のルールを適用し、Witnessデータの検証を行います。古いノードがSegWitトランザクションを「有効」と判定してしまうことは、ネットワークの安全性を損なわないように設計されています（SegWit対応ノードが多数派であれば、不正なトランザクションはブロックに含まれない）。
この後方互換性を持つ設計は、「Any One Can Spend」パターンと呼ばれ、ソフトフォークの一般的な手法です。
7. TaprootとSchnorr署名｜Scriptの最新進化
7-1. Taprootの概要
Taproot（タップルート）は、2021年11月にSegWit v1として導入されたビットコインの大型アップグレードです。BIP 340（Schnorr署名）、BIP 341（Taproot）、BIP 342（Tapscript）の3つのBIPで構成されています。
Taprootの核心的なアイデアは、「ほとんどのトランザクションは参加者全員の合意（協調的なケース）で決済されるが、意見が分かれた場合（非協調的なケース）のためにスクリプトの条件を用意しておく」というものです。
Taprootアドレスは「bc1p」から始まるBech32mアドレス形式を使用します。
7-2. Schnorr署名の導入
Taproot以前のビットコインは、ECDSA（Elliptic Curve Digital Signature Algorithm）を使用していました。TaprootではSchnorr署名（BIP 340）が導入されました。
Schnorr署名がECDSAよりも優れている点は以下の通りです。
線形性（Linearity）: Schnorr署名の最も重要な特性は、署名の線形結合が可能な点です。複数の署名者の署名を数学的に「足し合わせる」ことで、1つの集約署名を生成できます。これにより、マルチシグのトランザクションが、通常の1つの署名によるトランザクションと同じサイズ・外見になります。
証明可能な安全性: Schnorr署名は、離散対数問題の困難性に基づく安全性が数学的に証明されています。ECDSAにはそのような形式的な安全性証明が存在しません。
非展性（Non-malleability）: Schnorr署名はECDSAと異なり、署名の展性がありません。つまり、有効な署名から別の有効な署名を生成することができません。
効率性: Schnorr署名はECDSA署名よりもバッチ検証（複数の署名を一度に検証）が効率的です。
7-3. MAST（Merkelized Abstract Syntax Trees）
Taprootには、MAST（Merkelized Abstract Syntax Trees）の概念が組み込まれています。MASTは、複数のスクリプト条件をマークルツリーの構造に整理する技術です。
従来のP2SHやP2WSHでは、UTXOを使用する際に、リディームスクリプトの全体を公開する必要がありました。例えば、10個の異なる条件（スクリプトパス）が存在する場合、そのうちの1つだけを満たす場合でも、10個すべてのスクリプトを公開しなければなりませんでした。
MASTでは、各スクリプト条件がマークルツリーのリーフ（葉）として配置されます。UTXOを使用する際には、使用するスクリプト条件（リーフ）と、そのリーフがマークルツリーに含まれていることを証明するマークルパス（兄弟ノードのハッシュ列）のみを公開すればよく、他のスクリプト条件を明かす必要がありません。
これにより、以下のメリットが得られます。
- プライバシーの向上: 使用されなかったスクリプト条件が公開されないため、UTXOに設定されていた全条件の詳細が外部に知られません
- トランザクションサイズの削減: 使用するパスに関連するデータのみを含むため、複雑なスクリプトのトランザクションサイズが大幅に削減されます
- スクリプトの柔軟性: 理論上、マークルツリーに大量のスクリプトパスを含めることが可能であり、複雑な条件設定をコスト効率よく実現できます
7-4. Taprootの実際のトランザクション構造
Taprootの出力（P2TR: Pay-to-Taproot）は、以下のように構成されています。
ScriptPubKey: OP_1 <32バイトの出力鍵（tweaked public key）>
この出力鍵は、「内部鍵（Internal Key）」と「スクリプトツリーのマークルルート」を組み合わせて生成されます。
UTXOを使用する方法は2つあります。
キーパス支出（Key Path Spend）: 内部鍵に対応するSchnorr署名を提供するだけで、スクリプトツリーを公開せずにUTXOを使用できます。外見上は通常の単一署名トランザクションと区別がつきません。MuSig2などの署名集約プロトコルを使えば、マルチシグでも1つの署名として表現できます。
スクリプトパス支出（Script Path Spend）: キーパス支出ができない場合（例えば、参加者の一部が協力しない場合）に、スクリプトツリーの特定のリーフ（スクリプト条件）を使用してUTXOを使用できます。マークルパスの証明とスクリプトの充足データを提供する必要があります。
8. Script言語の限界と将来の可能性
8-1. Scriptの現在の制限
ビットコインScriptには、セキュリティと安定性のために設けられた制限が存在します。
サイズ制限: P2SHのリディームスクリプトは最大520バイト、Witnessスクリプトは最大10,000バイトです。Taprootのスクリプトリーフはこの制限が緩和されていますが、トランザクション全体のサイズやウェイトには上限があります。
オペコード制限: 多数のオペコードが「無効化」されており、使用するとスクリプトが即座に失敗します。OP_CAT（連結）、OP_MUL（乗算）、OP_DIV（除算）などがこれに該当します。これらは2010年に発見された脆弱性への対応として無効化されました。
ループの不在: 前述の通り、Scriptにはループ構造がありません。この制限により、プログラムの実行ステップ数は必ず有限であることが保証されますが、反復処理が必要な複雑なロジックの実装は困難です。
状態の非保持: Scriptはステートレス（状態を持たない）であり、個々のトランザクションは他のトランザクションの結果に依存できません（UTXO参照を除く）。イーサリアムのスマートコントラクトのように、オンチェーンに状態を保持して更新する機能はありません。
8-2. OP_CATの復活とCovenant
ビットコインコミュニティで近年最も活発に議論されているScript言語の拡張提案の一つが、OP_CATの再有効化です。
OP_CATは、スタック上の2つのバイト列を連結（concatenate）するシンプルなオペコードです。2010年に他のオペコードとともに無効化されましたが、適切なサイズ制限を設けた上で再有効化すれば、ビットコインのプログラマビリティを大幅に拡張できるという主張がなされています。
OP_CATが注目される理由は、これが「Covenant（カヴナント）」と呼ばれる機能の実現に寄与する可能性があるためです。Covenantとは、UTXOの使用先を制限する条件のことで、「このビットコインは特定のアドレスにしか送金できない」といった制約を設定できます。現在のScriptではこのような制約を表現できませんが、OP_CATを使えばトランザクションの内部データにアクセスしてCovenantを実現できる可能性があります。
Covenantが実現すれば、ビットコイン上で以下のような機能が可能になると考えられています。
- Vault（金庫）: 引き出しに時間的な遅延を強制し、不正な引き出しを検知して資金を取り戻す仕組み
- より効率的なLayer 2プロトコル: Lightning Networkの改善や新しいL2設計の実現
- CTV（Check Template Verify）: トランザクションの出力テンプレートを制限することで、バッチ処理やVaultを実現するBIP 119提案
8-3. BitVMとビットコイン上のスマートコントラクト
2023年に発表されたBitVMは、ビットコインの既存のScript機能のみを使って、チューリング完全な計算の検証をビットコイン上で行うという画期的なアイデアです。
BitVMの基本的なアイデアは、「楽観的実行（Optimistic Execution）」に基づいています。計算自体はオフチェーンで行い、計算結果に対する不正を「チャレンジ-レスポンスプロトコル」を通じてビットコインのスクリプトで検証します。
具体的には、計算をロジックゲート（NAND回路）に分解し、各ゲートの入出力をビットコインのスクリプトで検証可能な形式に変換します。不正な計算結果が主張された場合、チャレンジャーが不正の箇所を特定し、ビットコインのスクリプトで不正を証明できます。
BitVMの発展形であるBitVM2は、より効率的なチャレンジプロトコルを導入し、実用的なビットコインL2（ZK Rollup等）の構築を目指しています。BitVMは、ビットコインのScript言語の表現力の限界を、巧みなプロトコル設計によって実質的に拡張するアプローチとして注目されています。
8-4. 今後提案されているScript拡張
ビットコインScriptの将来的な拡張に関して、いくつかの重要な提案が議論されています。
OP_CTV（BIP 119 / CheckTemplateVerify）: トランザクションの出力テンプレートをスクリプトで指定し、そのテンプレートに一致する場合のみトランザクションを有効とするオペコードです。Covenantの一形態であり、バッチトランザクションやVaultの実現を目指しています。
OP_VAULT（BIP 345）: Vaultパターンを直接サポートする専用のオペコード提案です。引き出しの遅延と取り消し機能を組み込みで提供します。
LNHANCE: OP_CHECKCONTRACTVERIFY（CCV）とOP_INTERNALKEY（IK）を組み合わせた提案で、Lightning Networkの改善やCovenantの実現を目指しています。
これらの提案は、ビットコインのスクリプト言語の表現力を拡張しつつ、ビットコインの安全性と安定性を維持するという難しいバランスを取ることが求められています。ビットコインコミュニティでは、新しいオペコードの導入に非常に慎重なスタンスが取られており、十分な議論と検証を経た上でのソフトフォークが必要とされています。
まとめ
本記事では、ビットコインScript言語について、基本概念からUTXOモデルとの関係、スタックベースの実行モデル、オペコードの詳細、標準スクリプトタイプ、SegWitとTaprootによる進化、そして将来の拡張可能性まで幅広く解説してきました。
ビットコインScriptは、チューリング不完全で機能が制限された言語ですが、その制限はセキュリティと予測可能性を最優先するビットコインの設計哲学に基づいています。P2PKHからP2SH、SegWit、そしてTaprootへと段階的に進化を遂げ、プライバシーの向上、トランザクション効率の改善、プログラマビリティの拡張が実現されてきました。
Schnorr署名の導入とMASTの実装により、Taprootはマルチシグやタイムロックを含む複雑な条件設定を、通常のトランザクションと外見上区別がつかない形で実現できるようになりました。さらに、OP_CATの再有効化やBitVMといった提案は、ビットコイン上でのより高度なプログラマビリティの実現を目指しています。
ビットコインScriptの理解は、ビットコインのセキュリティモデル、Lightning Networkの仕組み、そしてビットコインの将来の技術的方向性を理解するための重要な基盤となるでしょう。
よくある質問（FAQ）
Q1. ビットコインのScriptを直接書いて使うことはできますか？
技術的には可能ですが、一般のユーザーが直接Scriptを書く必要はほとんどありません。ウォレットソフトウェア（MetaMask、Electrum、Bitcoin Coreなど）が、適切なスクリプトを自動的に生成してくれます。開発者がカスタムスクリプトを作成する場合は、Bitcoin Coreのbitcoin-cliやBTCDなどのツール、またはbitcoinjs-libなどのライブラリを使用します。ただし、カスタムスクリプトの作成にはビットコインのプロトコルへの深い理解が必要であり、誤ったスクリプトは資金の永久ロスにつながる可能性があるため、十分な知識と経験が求められます。
Q2. OP_RETURNを使ったデータの埋め込みとは何ですか？
OP_RETURNは、トランザクションの出力に任意のデータ（最大80バイト）を埋め込む用途で広く利用されています。OP_RETURNを含む出力は「使用不可能」として扱われるため、UTXOセットを肥大化させません。これを活用して、タイムスタンプ証明（Proof of Existence）、NFTのメタデータ（Ordinalsプロトコル）、サイドチェーンのアンカリングなどが行われています。OP_RETURNに続くデータはビットコインのブロックチェーンに永続的に記録されるため、改ざん不可能なタイムスタンプとして機能します。
Q3. Taprootはすべてのビットコインウォレットで使えますか？
2026年時点で、主要なビットコインウォレットの多くがTaproot（P2TR）に対応していますが、すべてのウォレットが対応しているわけではありません。Bitcoin Core、Sparrow Wallet、BlueWallet、Trezor、Ledgerなどの主要なウォレットはTaprootに対応しています。Taprootアドレス（bc1pで始まる）を使用することで、トランザクション手数料の削減やプライバシーの向上が期待できます。新しいウォレットを作成する際はTaprootの対応を確認し、可能であればTaprootアドレスの使用を検討してみましょう。
Q4. ビットコインScriptとイーサリアムのSolidityではどちらが安全ですか？
一概にどちらが安全とは言えませんが、設計哲学が異なります。ビットコインScriptは機能が制限されているため、攻撃面が小さく、プログラムのバグが生じにくい傾向があります。一方、Solidityはチューリング完全であるため表現力が高いですが、リエントランシー攻撃やオーバーフロー問題など、Scriptでは原理的に発生しないタイプの脆弱性が存在します。ビットコインScriptの安全性は「できることを限定する」ことで実現されているのに対し、Solidityの安全性は「開発者の注意深いコーディングと監査」に依存している面が大きいと言えるでしょう。
Q5. Lightning NetworkとビットコインScriptの関係は何ですか？
Lightning Networkは、ビットコインScriptの機能（特にマルチシグ、タイムロック、ハッシュロック）を巧みに組み合わせて構築されたレイヤー2プロトコルです。具体的には、2-of-2マルチシグで資金をロックするファンディングトランザクション、OP_CHECKSEQUENCEVERIFYによる相対タイムロック、HTLC（Hash Time-Locked Contract）によるクロスチャネルのルーティングなどが、ScriptのオペコードによってChain上で強制可能な形で実装されています。SegWitによるトランザクション展性の修正は、Lightning Networkの安全な運用に不可欠な前提条件でした。
※本記事は情報提供を目的としており、投資を推奨するものではありません。暗号資産への投資は元本割れのリスクがあります。投資判断はご自身の責任で行ってください。
