CIP-113はCardano DeFiをどう変えるのか──資産の管理権限と、実用化に必要な対応

Cardanoでトークンを発行することと、そのトークンを金融サービスで使えるようにすることは、別の課題です。発行者が移転条件を設定できる資産を、ウォレットで表示し、DEXで交換し、融資の担保として扱う。その一連の利用をつなぐために、CIP-113は何を共通化し、何を個々の実装に委ねるのでしょうか。

日本時間2026年9月30日、プログラマブルトークンの規格案CIP-113が、Cardanoの改善提案を管理するCIPsリポジトリにマージされました。Adam Dean氏は、Activeへの道に向けた次の一歩としてこれを祝福し、Charles Hoskinson氏も複雑な資産発行におけるCardanoの可能性を評価しています。マージの記録と照合すると、今回の節目は仕様文書の統合です。

続いて、Cardano PRIMEは支援するすべてのアプリにCIP-113を採用する方針を表明し、Minswapは対応コントラクトを試験中と発表しました。規格を整える議論から、実際のアプリに組み込む議論へと進み始めています。PRIME公式投稿、Minswap公式投稿

ここで問いたいのは、管理ルールを持つ資産を、CardanoのDeFiでどう使えるようにするのかです。発行者の権限、利用者の操作、金融アプリの設計をつなげて見ると、CIP-113の意味が見えてきます。

マージで決まったことと、これから確認すること

PR #444のマージ時刻は、UTCで9月29日16時58分、日本時間で9月30日1時58分です。ただし、10月1日の確認時点でCIP-113本文のStatusはProposedのままでした。マージによってCardanoの台帳が更新されたり、すべてのウォレットやDEXが一斉に対応したりしたわけではありません。

Activeへの受け入れ条件には、Previewテストネットとメインネットでのトークン発行、エンドツーエンドのテスト、広く使われるウォレットでの残高表示と送金が挙げられています。確認した文書のチェック欄は未記入でした。これは文書上の達成記録を示すもので、実装や試験が何も存在しないという意味ではありません。CIP-113仕様・Path to Active

SIPOはすでに、9月30日のSignalでマージの経緯と基本構造を整理し、2025年3月のCIP-143解説でも凍結・差し押さえの概念実証を紹介しています。本稿では、その先にあるアプリへの統合と権限の設計を掘り下げます。

ネイティブトークンに「移転の条件」を重ねる

通常のCardanoネイティブトークンは、発行・焼却の条件を設定できますが、発行後のすべての移転に対して、発行者の任意の検証ルールをそのまま強制できるわけではありません。CIP-113は、所有者が変わる際にスクリプトの検証を必要とする仕組みを、既存のCardanoの機能で構成します。

台帳上の資産は引き続きネイティブトークンです。違いは、資産を置くアドレスと、それを動かす際の検証にあります。共通の支払いスクリプトと、持ち主を識別する資格情報を組み合わせたアドレスにトークンを置きます。仕様は、この持ち主ごとのUTxOの集合を「スマートウォレット」と呼んでいます。

UTxOは、まだ使われていない取引の出力です。Cardanoでは、送金時に既存のUTxOを使い、新しいUTxOを作ります。CIP-113では、その処理に共通基盤の検証とトークンごとの移転ルールを組み込みます。持ち主の識別にはステーク資格情報の欄を使いますが、そこに置くものは鍵やスクリプトであり、必ずしも通常のステーキング用の鍵に限定されません。

これにより、許可された相手への移転、特定の条件での送金停止などを設計できます。規制対応型のステーブルコインやトークン化証券への利用が想定される理由です。ただし、第三者操作の内容と実行権限は個別ルールによって異なります。CIP-113対応という表示だけで、すべての資産が同じ権限を持つとは判断できません。CIP-113仕様・基本構造とサブスタンダード

ハードフォーク不要でも、アプリ側の対応は必要です

利用者にとっての利点は、資産ごとにまったく別の操作体系を覚える負担を減らせる可能性があることです。共通の登録情報やアドレスの構造を利用できれば、ウォレットや金融アプリは、それぞれの資産を扱うための土台を共有できます。その上で個別の管理ルールに対応していくことになります。

一方で、これは対応作業がなくなることを意味しません。参照実装は、既存のウォレット、エクスプローラー、DEXに統合作業が必要だと明記しています。ウォレットは共通スクリプトの下にある資産から持ち主の残高を読み取り、正しいアドレスと必要な検証を含む取引を組み立てる必要があります。参照実装README

DEXも、通常のトークン送金に項目を一つ追加すれば済むとは限りません。プログラマブルトークンを保持するアドレス、アプリ自身が操作を承認する仕組み、登録情報の参照、トークン固有の検証を、取引の構築に組み込む必要があります。参照実装・統合ガイド

Minswapの「試験中」という発表は、この接続部分が開発の対象になっていることを示します。ただし、発表だけではメインネットでの公開完了、対応資産の範囲、利用条件や手数料まで確認できません。対応方針、試験、本番稼働を段階ごとに見る必要があります。

資産を動かす権限と、仕組みを更新する権限

CIP-113の権限を読む際は、現在の操作だけでなく、後から何を変更できるかも確認したいところです。少なくとも次の三つを分けると整理できます。

操作	確認する権限・条件	利用者にとっての意味
通常の移転	持ち主の承認と、トークンの移転ルール	自分の操作でも、資産の条件により移転が拒否されることがあります
第三者による操作	個別ルールが許す操作と、その実行権限	持ち主の承認を伴わない操作が、どこまで認められるかを確認します
共通の検証基盤の更新	デプロイ時に設定される更新権限	トークンを置き直さずに、検証の一部を変更できる設計です

三つ目は、今回の仕様で読み落としたくない点です。共通基盤の一部の検証ロジックは更新可能ですが、更新権限を誰に持たせるかはCIP-113で一律に決めていません。単独の鍵、複数署名、ガバナンスの仕組み、その他のスクリプトによるルールが認められ、実装者は採用した方式を文書化する必要があります。

したがって、CIP-113対応だけを根拠に、更新が必ずCardanoのガバナンスで決まると考えることはできません。確認すべき対象は、そのトークンが利用する基盤のデプロイと、その更新権限です。

また、何でも更新できるわけではありません。仕様は、スマートウォレットの支払い資格情報と個々のトークンの発行ポリシーを固定し、変更可能な検証ロジックと区別しています。更新権限の交代には、候補の指名と別の取引での昇格、引き継ぐ側の承認なども求めています。こうした構造は、修正可能性と資産の識別を両立させるための設計です。CIP-113仕様・Protocol upgradability

担保や流動性プールに入った資産は、誰のルールで動くのか

ここからは、具体的な利用場面で考えます。凍結や差し押さえが可能なトークンを、利用者が融資アプリに担保として預けたとします。発行者がその資産に管理操作を行える場合、融資アプリは、担保の価値や売却の可否だけでなく、担保を移動できる条件も設計に取り込む必要があります。

これは仮定した利用例です。特定の融資アプリで損失が発生したことを示すものではありません。CIP-113の仕様も、担保を受け入れる前にサブスタンダードを確認し、第三者操作が担保に影響し得ることを検討するよう求めています。CIP-113仕様・Lending Protocols

DEXの流動性プールにも同じ問いがあります。複数の利用者が提供した資産をまとめて扱う場所で、一つの資産に第三者操作が行われたとき、プールの処理や参加者の持ち分をどう扱うのでしょうか。取引の検証に対応するだけでは、この運用上の問いは解けません。

参照実装の権限に関する文書は、スクリプトで所有される資産について、それが個人のスマートコントラクトウォレットなのか、DEX・融資プール・エスクローなのかを、資格情報だけでは区別できないと説明しています。どの持ち主を第三者操作の対象にするかは、個別ルールで設計する必要があります。

同文書は、スクリプトが所有する資産の取り出しに対し、対象となるプロトコルの許可リストや、そのスクリプトの同意を要求する設計パターンを示しています。ただし、これは個別実装への指針です。すべてのCIP-113トークンで標準的に保証される仕組みではありません。移転を拒否する凍結と、第三者が資産を取り出す操作も、権限の性質が異なります。参照実装・権限の適用範囲

SIPOの見方では、ここに規格をそろえる価値と、実装ごとの差が同時に表れます。共通の仕組みで接続できても、担保やプールで安全に扱える条件は資産ごとに確認する必要があります。

複数資産をまとめると、移転ルールも重なります

UTxOは、複数の資産を一緒に保持できます。プログラマブルトークンを一つのUTxOにまとめた場合、そのUTxOを通常の移転経路で使うには、含まれるトークンのルールを満たす必要があります。ある資産の移転が拒否されると、同じUTxOにある別の資産も、その経路では動かしにくくなることがあります。

重要なのは、影響の範囲です。これは資産を同じUTxOにまとめた場合の問題であり、同じウォレットに届いたトークンが、別々のUTxOにある全資産を自動的に止めるという話ではありません。参照実装の統合ガイドは、ウォレットの資産選択やお釣りの作成時に、知らないプログラマブルトークンを他の資産と安易に統合しないことなどを示しています。統合ガイド・UTxO hygiene and anti-injection

この課題に対する仕組みの一つが、unfrackingです。持ち主を変えずに、自分が所有するUTxOの資産を組み直し、対象のポリシーのトークンを分離する経路です。参照実装のIssue #63は、この仕組みによる緩和を記録してクローズされています。Issue #63の対応記録

ただし、一律に使える救済手段とは言えません。仕様では、持ち主の承認に加え、対象トークンのunfracking用スクリプトの実行が必要です。発行者がこの経路を明示的に許可しない場合は利用できません。ウォレットの対応と、トークン側のルールを組み合わせて確認する必要があります。CIP-113仕様・UnfrackingAct

複数資産を一緒に使うDeFiでは、「規格に対応した」という一点に加えて、異なる管理ルールを持つ資産同士を組み合わせたときの挙動が、実用化の確認項目になります。

標準化が開く入口と、運用で確かめる条件

PRIMEの採用方針は、共通の規格をアプリ開発の前提にする動きです。ウォレットや金融アプリが対応の土台を共有できれば、個別の資産やサービスを接続する負担が減る可能性があります。これはSIPOの期待であり、開発工数がどれだけ減るかを実測した結果ではありません。

同じように、手数料や処理の効率も、実際の取引で確かめる必要があります。CIP-113の取引には追加のスクリプト実行があり、参照するポリシーやUTxOの数で負担が変わります。統合ガイドは、現実的な取引サイズで実行予算を測るよう求めています。規格の統一だけを根拠に、すべての取引が安く速くなるとは言えません。

参照実装READMEは、専門家による監査を受け、指摘事項を解消または設計上の残る制約として明示したと説明しています。ただし、監査だけで本番の安全性を保証するものではないとも明記しています。監査対象の実装、使う個別ルール、実際に配備する版を対応づけて確認することが、次の判断材料になります。

また、トークンの残高が多数のUTxOに分かれていれば、すべてを一つの取引で差し押さえられるとは限りません。参照実装のIssue #71は、複数取引になる制約と、強い差し押さえ保証が必要な個別実装で先に凍結する設計を検討すべきことを記録しています。機能の有無と、その機能を実際の運用で完遂する手順は、別に確認する必要があります。Issue #71

今後の進展を見る際には、次の点が判断に役立ちます。

確認対象	見たい証拠
本番の資産発行	ネットワーク、発行ポリシー、利用する基盤の識別情報、取引記録
ウォレット	残高表示と送金に加え、個別ルールや操作権限の説明、資産をまとめる際の処理
DEX・融資アプリ	対応版と対応資産、預入・交換・引出・清算の挙動、管理操作が行われた場合の扱い
権限と更新	第三者操作の内容と実行者、共通基盤の更新方式、個別ルールの変更可能性
運用と検証	監査対象の版、複数資産での試験、手数料や実行予算、停止や更新の手順

CIP-113のマージで、資産に管理ルールを持たせるための共通の仕様が、CIPsリポジトリに収まりました。その価値は、発行された資産を、異なるウォレットや金融アプリで利用できる形へつなぐところにあります。実用化の進展は、発行の記録に加え、利用者が何をできるか、誰がどの権限を持つか、アプリ同士がどこまで接続できるかで見えてきます。

透明性メモ

本稿は2026年10月1日に、マージ記録、仕様文書、参照実装の文書とIssue、公式X投稿を確認して作成しました。参照実装の解説には、コミット6b75ba3の文書を用いています。仕様と参照実装は別の成果物として扱い、細部の一致、コントラクトの実行、本番取引の動作や手数料まで独立に検証したものではありません。融資と流動性プールの例は、設計上の意味を説明する仮定です。