OP_CAT これは、スタック上の2つのデータを1つに結合するビットコインのオペコードであり、現在、ビットコイン開発において最も長く続いている議論の1つの対象となっている。 これはビットコインの初期コードに含まれていたが、セキュリティ上の懸念から2010年にサトシ・ナカモトによって削除され、ここ数年は、ビットコイン上でスマートコントラクトに似た新たな動作を実現する可能性を秘めたソフトフォーク案（BIP 347）として提案され続けてきた。 2026年7月現在、ビットコインのメインネットでは有効になっていないが、ビットコインに関連するいくつかのネットワークではすでに稼働しており、そこでひっそりと公開ストレステストが行われている。
OP_CATを理解する価値がある理由は、単にそのコードだけではありません。その背景には、変更が安全かどうかを議論するビットコイン・コアの開発者たち、復活を求めるロビー活動のために数千万ドルを調達したミーム発祥のNFTプロジェクト、そしてすでにOP_CATを実用化している急成長中のサイドチェーンといった、さまざまな関係者が関わっているからです。 このガイドでは、OP_CATの機能、無効化された理由、それがもたらす可能性、そして現在の状況について詳しく解説します。
マルチチェーンを使用する Bitcoin.com ウォレットアプリ、ビットコインや暗号資産の送金、受け取り、購入、売却、取引、利用、管理を安全かつ簡単に行えるサービスとして、何百万人ものユーザーから信頼されています。
主なポイント
- OP_CAT（「operation concatenate」の略）は、ビットコインのスタック上にある2つのデータ項目を1つの項目に結合します。これがこの関数の全機能です。
- これはビットコインの初期のコードで有効になっていましたが、サービス拒否攻撃のリスクを理由に、2010年にサトシ・ナカモトによって無効化されました。
- これを復活させる提案であるBIP 347は、イーサン・ハイルマンとアルミン・サボウリによって作成され、2024年4月にBIP番号が割り当てられました。
- OP_CAT自体はコヴェナントではありませんが、他のオペコードと組み合わせることで、ヴォールトを含むコヴェナントのような支出制限を構築するために使用できます。
- 2026年半ばの時点で、OP_CATはビットコインのメインネットではまだ有効化されていません。 ビットコインの次期コンセンサス・ソフトフォークの現在の有力候補は、OP_CTV（BIP 119）とOP_CHECKSIGFROMSTACK（BIP 348）であり、OP_CAT単独ではありません。
- OP_CATは、ビットコインと連携したサイドチェーンであるFractal Bitcoinですでに実装されており、CAT20トークン規格を支えています。また、Liquid Networkやビットコインキャッシュ上でも長年にわたり稼働しており、これまでに既知の脆弱性は報告されていません。
- Taproot Wizardsが立ち上げた「Quantum Cats」というビットコインNFTプロジェクトは、OP_CATへの対応をミームキャンペーンへと発展させ、OP_CAT関連の開発に向けて3,700万ドル以上の資金を調達した。
OP_CATの仕組み
OP_CATを理解する最もわかりやすい方法は、ビットコインのスクリプトシステムを小さな積み木のようなものとしてイメージすることです。すべてのビットコイン取引の基盤となるプログラミング言語「ビットコインスクリプト」は、スタックベースの言語です。データはスタックにプッシュされ、オペコードはスタックの最上部に積まれたデータに対して処理を行い、その結果によって取引の有効性が決まります。
OP_CAT は、そのスタックの一番上にある 2 つの項目を取り出し、それらを連結します。つまり、それらを端と端を繋いで 1 つの結合された項目にし、それをスタックの一番上に戻します。 スタックに「1」と「2」が格納されている場合、OP_CATを実行すると、両方が取り除かれ、「12」に置き換えられます。公式仕様書によると、 BIP 347, OP_CAT は x1 || x2 をスタックにプッシュします。ここで、二重パイプ記号は連結を表します。
ただし、1つ重要な制限があります。スタック上の値が2つ未満の場合、あるいはそれらを結合した結果、ビットコインのスクリプト要素の最大サイズである520バイトを超える値が生成される場合、OP_CATは失敗します。このバイト数の上限は、このオペコードの歴史において非常に重要な意味を持っています。これについては後ほど詳しく説明します。
単に2つのデータ文字列を結合するだけでは、それほど強力な機能には聞こえないかもしれません。しかし、ビットコインのスクリプト言語には、スタック上の値を結合するための汎用的な方法がこれまで存在せず、その欠如が、開発者がビットコインのトランザクションに直接組み込める機能の幅を制限してきました。 Bitcoin Optechが解説する, ビットコインのTapscriptには、スタック上のオブジェクトを組み合わせる汎用的な方法が欠けており、これがTapscriptの表現力を制限しているほか、とりわけ、Tapscript内で直接マークル木やその他のハッシュ化されたデータ構造を構築・評価する機能を妨げている。OP_CATは、この特定の欠点を解消するために提案された修正案である。
なぜ2010年にOP_CATが無効化されたのか？
OP_CATは、ビットコインの最初のリリースに含まれていた機能の一つでした。2010年、サトシ・ナカモトは、OP_MUL、OP_DIV、OP_ORなど他のいくつかのオペコードとともに、これを削除しました。 公式の理由としては、サービス拒否（DoS）のリスクが挙げられました。OP_CATを繰り返し使用するスクリプトは、理論上、指数関数的に増加するデータを生成する可能性があり、そのデータ量は、検証を試みるノードの動作を遅らせたり、クラッシュさせたりするほど大きくなる恐れがあったからです。
当時、ビットコインのスタック上の単一項目のサイズに厳格な制限は設けられていませんでした。つまり、悪意のあるスクリプトが、ネットワークを停滞させるほどデータ量の多い文字列が生成されるまで、値を連結し続けることが可能だったのです。 OP_CATやその他の無効化されたオペコードを削除したのは、まだ発展途上だったネットワークにとって必要のない機能よりも、ネットワークの安定性を優先した保守的な措置でした。
2021年11月、ビットコインがTaprootアップグレードを有効にしたことで状況は一変しました。Taprootでは、独自のルールを持つ新しいスクリプトコンテキスト「Tapscript」が導入され、そのルールの一つとして、スタック内の単一項目のサイズを520バイトに制限するものが設けられました。このバイト制限により、当初の攻撃経路は直接的に封じ込められました。 スクリプトは依然としてOP_CATを呼び出すことができますが、2010年にサトシが懸念していたようなリソース枯渇問題を引き起こすほど大きな値を生成することは決してありません。この技術的な詳細こそが、OP_CATを復活させる道を開いたものであり、その適用範囲はビットコインスクリプト全体ではなく、Tapscriptに限定されています。
OP_CATはコヴナントなのでしょうか？
いいえ、それだけでは不十分です。これは、OP_CATに関して最もよく誤解されている点の一つです。ビットコインの用語でいう「コヴェナント」とは、未使用のトランザクション出力（UTXO）が将来どのように使用されるかに対する制限のことです。 通常のビットコインスクリプトでは、通常は署名を検証することで、その支出が「現時点で」承認されているかどうかしか確認できません。一方、コヴナントはさらに一歩進んで、支出が承認されているかどうかだけでなく、その結果として生成される取引が特定の条件セットを満たしているかどうかも確認します。
OP_CAT には、トランザクションデータを検査するための組み込みの仕組みは含まれていません。このオペコードが提供するのは、スタック上のデータ断片を結合する方法であり、その結合されたデータに対して署名を検証する他のオペコードと組み合わせて初めて、コヴェナントにおいて有用となります。 BIP 347そのものは、次のように明記している OP_CATは、Tapscriptでの再活性化が提案されているものの、コヴナントそのものではありません。これを、署名検証オペコードと組み合わせることで、コヴナントのような動作をエミュレートできる構成要素として説明する方がより正確です。
これが重要なのは、OP_CATの柔軟性こそが、この機能を興味深いと同時に物議を醸すものにしているからです。OP_CAT自体はコヴェナントではないかもしれませんが、シュノール署名の仕組み上の特異性により、コヴェナントをエミュレートすることが可能です。 トランザクション自体だけでなく、任意のデータに対して署名を検証する「CheckSigFromStack（CSFS）」というオペコードと組み合わせることで、OP_CATは、専用のコヴェナント用オペコードが作成するように設計されたのと同じ種類の支出制限を構築するために利用できます。
OP_CATにはどのような用途があるのでしょうか？
OP_CATは、適用範囲が限定された機能というよりは汎用的なプリミティブであるため、開発者たちはこれに関する幅広い活用案を提案しています。最も頻繁に議論されているものには、次のようなものがあります：
- 金庫室。 「ヴォールト」とは、資金の移動を行う前に、複数の手順（多くの場合、別々の取引やブロックにまたがる）を必要とする契約の一種です。これにより、所有者が不正な支出に気づき、それを阻止するための時間が確保されるため、コールドストレージや共同管理の仕組みが強化されます。
- 曖昧さを排除する契約。 これにより、ライトニング・ネットワークなどの決済チャネルにおいて、古くなった、あるいは不正なチャネル状態をブロードキャストしようとする当事者にペナルティを課すことができ、オフチェーン決済システムのセキュリティが強化される。
- 木のサイン。 OP_CAT を使用すると、署名者の数に応じてサイズが対数的にしか増えないコンパクトなマルチシグネチャスクリプトが可能になります。つまり、1キロバイト未満のトランザクションでも、理論上は数百万もの公開鍵にわたる支出条件をサポートできることになります。
- マークルツリーの構築と検証。 マークルツリーの構築と検証には、基本的に値の連結とハッシュ化が必要となるため、OP_CATはビットコインスクリプトに、これをネイティブに実行するために欠けていた要素を提供します。
- ポスト量子署名。 OP_CAT を使用すると、ラムポート署名を有効にすることができます。ラムポート署名は、スタック上の値をハッシュ化し、連結する機能さえあればよいという特性から、量子コンピュータによる攻撃に対して耐性があると見なされている署名方式です。
- トークン化された資産とクロスチェーン・ブリッジ。 より表現力豊かなスクリプトを可能にすることで、OP_CATは、ビットコインと互換性のあるチェーン上でのトークン発行や、ビットコインと他のネットワーク間の信頼依存度を最小限に抑えたブリッジの実現を支援できる可能性があります。
ここでも、トレードオフについて率直に述べておく価値があります。OP_CATを上記のすべてにおいて有用なものにしているその柔軟性こそが、一部のビットコイン開発者に慎重さを抱かせている理由でもあります。 OP_CATは特定の用途に特化したものではなく汎用的なものであるため、開発者が「広大な設計空間」と呼ぶような可能性を広げてしまいます。つまり、将来的に他のオペコードとどのような形で組み合わされるかをすべて予測することが難しくなるということです。この不確実性こそが、現在進行中の議論の核心であり、単なる副次的な問題ではありません。
OP_CAT 対 OP_CTV：2つの主要なコヴナント提案の比較
OP_CATは通常、開発者のジェレミー・ルービンがBIP 119で提案したOP_CTV（OP_CheckTemplateVerify）と併せて議論されます。どちらもビットコインに何らかの形の契約機能を持たせることを目的としていますが、その設計アプローチはほぼ正反対です。
実際の違いは、その適用範囲にあります。OP_CTV を使用すると、トランザクションの出力は、バージョン、ロックタイム、出力、入力数などの詳細を含め、将来行われる特定の 1 つの支出トランザクションに対してのみコミットすることができます。テンプレートと一致すれば、支出は成立します。 一致しなければ、処理は実行されません。この限定性は意図的なものです。CTVは非再帰的であり、つまり、CTVによってコミットされたトランザクションは、恒久的な制約の連鎖を生み出すような形で、それ自体がさらなる制限を課すことはできません。支持者たちは、これをより安全で、範囲が限定された形のコヴナントであると考えています。
OP_CATはこれとは正反対の考え方を採用しています。特定の1つの問題を解決するのではなく、開発者に柔軟なプリミティブを提供し、その上に機能を構築できるようにするものです。 CTVが特定のユースケースを実現するために慎重に範囲が限定されたオペコードであるのに対し、OP_CATはスタック上での文字列連結というプリミティブであり、これはもともとビットコインのスクリプト言語に存在していましたが、2010年にサービス拒否（DoS）攻撃の懸念から無効化されました。しかし、Taproot導入後のスクリプトサイズ制限の下では、そのような懸念はもはや当てはまりません。 この柔軟性こそが、OP_CATが再帰的なコヴェナントをサポートすることを可能にしています。再帰的なコヴェナントとは、ある制限が連鎖的に別の制限を生み出す仕組みであり、これはOP_CTVが意図的に回避している特性です。
OP_CATは今日、ビットコインで利用可能ですか？
ビットコインのメインネット上ではありません。BIP 347は仕様書として「Complete」ステータスに達しており、これは提案自体が完成し、明確に定義されていることを意味します。これは実装とは別の話であり、実装するには、より広範なビットコインコミュニティやノード運営者がソフトフォークを通じて実際にこれを有効にする必要があります。
2026年半ばの時点で、OP_CATはビットコインの次期コンセンサス変更の最有力候補ではありません。 その地位は現在、OP_CTVと、それに付随するOP_CHECKSIGFROMSTACK（BIP 348）が占めている。OP_CHECKSIGFROMSTACKは、スクリプトが署名を、支出取引自体だけでなく任意のデータに対して検証できるようにする関連するオペコードである。ある報告によると、 最新のビットコインBIPリファレンスガイド, 2026年半ばの時点で、次期コンセンサス・ソフトフォークの有力候補となっているのは、コヴェナント提案であるBIP 119（OP_CHECKTEMPLATEVERIFY）とBIP 348 （OP_CHECKSIGFROMSTACK）が有力な候補として挙げられています。これらは、ボールトやチャネルファクトリー、より効率的なレイヤー2プロトコルに向けた新たなスクリプト機能を実現するものと見込まれていますが、有効化のスケジュールは未定であり、コミュニティのコンセンサスもまだ形成途上です。
OP_CTVは、OP_CATよりも有効化プロセスがさらに進んでいます。開発者たちは、 具体的なシグナリングパラメータ BIP9方式のソフトフォークについては、シグナリング開始日を2026年3月30日、1年間のタイムアウト期間を2027年3月30日までとし、最小アクティベーション高を2027年5月頃、各2週間の難易度期間におけるマイナーのシグナリング閾値を90％とする。 これにより、CTVは2021年にTaprootを有効化したのと同じようなメカニズムを経ることになるが、開発者コミュニティ内でコヴナント提案をめぐる意見の対立が依然として続いていることを考えると、90％の閾値に達することは決して保証されていない。
だからといって、OP_CATが廃れたわけではない。つまり、2026年に予定されている「次の」ソフトフォークに関する議論は、現時点では別の2つのオペコードを中心に展開されており、OP_CATの今後の進路（もしあるとすれば）は、まずそのCTVとCSFSをめぐる議論がどのように展開されるかに左右される可能性が高いということだ。
OP_CATはすでに他の場所で稼働中
OP_CATはビットコインのメインネットでの実装を待っているものの、テストされていないわけではない。ここ数年、いくつかのビットコイン関連ネットワークにおいて、ひっそりと本番環境で稼働し続けている。
- リキッド・ネットワーク。 Blockstreamのフェデレーテッド・サイドチェーンは、ローンチ当初からOP_CATが有効化されており、BIP 347が策定される何年も前から、より広範なビットコイン・エコシステムに実環境でのテストベッドを提供してきました。
- ビットコインキャッシュとビットコインSV。 両ネットワークとも、プロトコルのアップグレードの際にOP_CATを再導入しており、このオペコード自体に起因する既知の脆弱性は報告されていないまま、これらのチェーン上で取引の処理が行われてきた。
- フラクタル・ビットコイン。 これは現在最も活発に運用されている展開です。Fractalは、Bitcoin Coreのソフトウェアを用いて構築され、ビットコインとマージマイニングを行うビットコイン準拠のサイドチェーンであり、2024年9月9日にメインネットを立ち上げ、開始当初からOP_CATが有効化されています。
Fractalは、「これがビットコイン上で実際にどのような形になるのか」という疑問に対する最も明確な答えであるため、詳しく見てみる価値があります。 Fractalのローンチ以来、OP_CATを活用してビットコインのソフトウェアを基盤としたスマートコントラクトを構築する新しいプロトコルが登場しています。その中には、ビットコインネイティブユーザーの間で大きな関心を集めているCATプロトコルや、OP_CATを用いてネットワークの機能を拡張するその他の新たな標準規格も含まれています。
その代表的な例が、OP_CATの利点を最大限に活用するために特別に構築された代替可能トークン規格「CAT20」です。によると、 Fractal Bitcoinの公式ドキュメント, CAT20はマイナーによって完全に検証され、スマートコントラクト、具体的には再帰的契約（recursive covenants）を用いて動作します。これらはベースレイヤーにおいてビットコイン独自のスクリプト言語によって完全に実行されるため、外部やサードパーティによる検証に依存するトークン規格とは一線を画しています。 実際には、CAT20トークンの展開、鋳造、および転送は、一連のOP_CAT操作を通じて行われます。これらの操作により単一のデータ文字列が構築され、それがブロックチェーン上に直接記録されます。その検証は、独立したオフチェーンのインデックスサービスではなく、ネットワークのセキュリティを確保しているのと同じマイナーによって行われます。
「Quantum Cats」の物語：ミーム・キャンペーンがOP_CATをどのように前進させたか
オペコードの提案のほとんどは、メーリングリストやGitHubのスレッドの範囲にとどまります。しかし、OP_CATはそうではありませんでした。その主な理由は、「Taproot Wizards」というビットコイン・オーディナルズ・プロジェクトの存在でした。
2024年1月、Taproot Wizardsは「Quantum Cats」と名付けられた3,333点のNFTスタイルのコレクションをリリースしました。このコレクションは、OP_CATの再活性化に向けた世論の支持を集めることを唯一の目的として制作されました。 「Quantum Cats」は、OP_CATによって、ビットコインやビットコインベースの資産をビットコインのレイヤー2チェーンへ移動させ、そこでより複雑な取引に参加できるような、許可不要のブリッジを構築することを目指していました。 ミントの参加資格を得るためには、参加者は実際の技術提案について学び、その復活を公に提唱する必要があり、それによって、本来ならかなり堅苦しいBIPの議論が、現実的な利害が絡むコミュニティキャンペーンへと変貌を遂げました。
このコレクション自体は、連結処理の実演としても機能していました。各「Quantum Cat」は、1つの静的な画像ではなく、複数の別々のファイルを参照しており、時間の経過とともに新しいファイルが公開されるにつれて猫の姿が変化していきます。これは、別々のデータ断片をつなぎ合わせるというOP_CATの動作を、まさに反映したものです。
このキャンペーンは十分な成果を上げ、多額の資金調達につながりました。Taproot Wizardsは2023年に750万ドルを調達し、続いて2025年2月には3,000万ドルの資金調達ラウンドを実施しましたが、いずれもOP_CATエコシステムの開発に明確に充てられることが明記されていました。 共同創業者のウディ・ウェルトハイマー氏は、このプロジェクトがビットコインの未来としてOP_CATに焦点を当てていると説明し、調達した資金は社内開発と、このオペコードを基盤に開発を行う外部チームの支援の両方に充てられると述べた。 サザビーズで行われた「ジェネシス・キャット」という1点のQuantum Catのオークションは25万4,000ドルで落札され、わずか4バイトのオペコードを巡るこのキャンペーンが、どれほど大きな文化的影響力を獲得したかを浮き彫りにした。
ビットコインをめぐる技術的な議論が、必ずしも技術的な範囲にとどまるわけではないということを、改めて思い起こさせてくれる。ミームやアート、そしてお金は、プロトコルに関する議論をより広い視野へと広げるための手段として繰り返し活用されてきたが、OP_CATはその傾向を示す最近の最も明確な例の一つである。
結論
OP_CATが行うことは単純明快です。ビットコインのスタック上にある2つのデータを1つに結合するだけです。この機能が重要なのは、もしビットコインコミュニティがOP_CATの復活に合意すれば、より安全なコールドストレージ・ヴォールトから、ポスト量子署名、さらにはビットコインネイティブのトークンに至るまで、この単一の関数がもたらす可能性のすべてにあるのです。 2026年7月現在、その合意には至っていません。 BIP 347は、ビットコインの次期コンセンサス・ソフトフォークの候補として、OP_CTVやOP_CHECKSIGFROMSTACKに次ぐ位置にある完成済みの仕様書です。一方、OP_CATはFractal BitcoinやLiquid、その他のビットコイン関連ネットワーク上で、何事もなく静かに稼働し続けています。 今後何が起ころうとも、OP_CATをめぐる議論は、わずかでもシンプルなコードが、開発者、アーティスト、投資家を同時に惹きつけることができることをすでに示している。
