Moveプログラミング言語において、「能力（Abilities）」は型の振る舞いを決定する重要な仕組みです。Sui Moveでは、この能力システムがオブジェクトモデルと深く結びついており、スマートコントラクトの安全性と表現力の両立を実現しています。
能力システムを正しく理解することは、Move開発者にとって避けて通れない基礎知識です。誤った能力設定は、意図しないコピーや消失を招く可能性があり、デジタル資産の安全な管理に直接影響します。
本記事では、copy・drop・store・keyという4つの能力の意味と制約、そしてそれらを組み合わせたリソース設計のベストプラクティスについて詳しく解説します。実際のコード例も交えながら、実践的な理解を目指します。
1. Moveの能力システムとは何か
1-1. 能力が必要な理由
Moveは、デジタル資産を安全に扱うために設計されています。従来の言語では、整数や文字列は自由にコピー・削除できますが、資産を表す型まで同様に扱うと二重支払いや不正な消去が起こりえます。
Moveの能力システムはこの問題に対処するために設計されています。型に付与した能力によって、その型の値がコピーできるのか、削除できるのか、ストレージに保存できるのか、グローバルに参照できるのかを明示的に宣言します。能力のない操作はコンパイルエラーとなり、実行前に安全性が保証されます。
1-2. 4つの能力の一覧
Moveには以下の4つの能力があります。
- copy：値をコピーできる
- drop：値を暗黙的に廃棄できる（スコープを抜けたときに自動消去）
- store：グローバルストレージや他の構造体に格納できる
- key：グローバルストレージのキーとして使える（Suiではオブジェクトの識別子となる）
これらの能力は組み合わせて使うことができ、その組み合わせによって型の性質が決まります。
2. copy能力：複製の制御
2-1. copyが許可する操作
copy能力を持つ型は、その値を複製することができます。数値型（u8, u64, u128）やブール型はデフォルトでcopy能力を持ちます。カスタム構造体にcopyを付与することも可能ですが、資産を表す型には通常付与しません。
copy能力を持つ型の値は、関数に渡した後も元の変数が有効なままです。参照渡しではなく値のコピーが行われます。これはPrimitive型（プリミティブ型）として扱いたいユーティリティ型に向いています。
2-2. 資産型にcopyを付与してはならない理由
仮想通貨やNFTのような資産を表す型にcopyを付与すると、その値を無限に複製できてしまいます。これは二重支払い問題の根本原因になります。Moveの設計思想では、資産型にはcopyを付与しないことが原則です。
SuiのCoin型はcopyなしで定義されており、転送時には元の所有者からCoinが削除され、受取人のCoinが生成されます。この設計によって、資産の総量保存が型システムによって保証されます。
3. drop能力：廃棄の制御
3-1. dropの意味と動作
drop能力を持つ型は、スコープを抜けたときに自動的に廃棄されます。これはRustのDropトレイトに似た概念です。数値型やブール型は自動的にdrop能力を持ちます。
drop能力のない型は、スコープを抜ける前に明示的に転送・消費・保存のいずれかを行う必要があります。もし処理せずにスコープを抜けようとすると、コンパイルエラーが発生します。
3-2. 資産の消失防止とdrop
資産型にdropを付与しないことで、「うっかり消えてしまう」ことを防げます。例えば、関数内でCoinを受け取ったのに、どこにも転送せず返しもしなければコンパイルエラーになります。これは開発者のミスによる資産消失を防ぐ重要な安全機構です。
一方、内部で使うカウンターや一時的なデータ構造など、資産を表さない型にはdropを付与して問題ありません。アプリケーションの設計に応じて適切に使い分けることが重要です。
4. store能力：ストレージへの格納
4-1. storeが制御するもの
store能力を持つ型は、グローバルストレージや別の構造体のフィールドに格納できます。逆にstoreのない型は、それ単体でオブジェクトのフィールドになれません。
Suiでは、オブジェクトのフィールドに格納される型にはstore能力が必要です。これにより、どのような型がチェーンに永続化できるかを明示的に制御できます。
4-2. keyとstoreの関係
Suiでオブジェクトを定義するにはkey + storeの両方が必要です。keyだけではオブジェクトとして扱われますが、他のオブジェクトのフィールドに入れることはできません（Suiのバージョンによって扱いが異なる場合があります）。
keyのみでstoreのない型は「soulbound（魂に縛られた）」オブジェクトとして機能します。これは転送できないNFTや、特定アドレスに紐付いた永続データの表現に利用できます。ソウルバウンドトークン（SBT）の実装において、このパターンが活用される場合があります。
5. key能力：グローバル識別子
5-1. keyがSuiのオブジェクト定義に必須な理由
Suiでは、key能力を持つ型がオブジェクトとして扱われます。オブジェクトは一意のIDを持ち、チェーン全体でアドレスによって参照できます。key能力のない型は、単なる値として別のオブジェクトのフィールドに入れるかスタック上に保持するかのどちらかしかできません。
key能力を持つ構造体には、最初のフィールドとしてid: UIDを宣言する必要があります。このUIDがオブジェクトのグローバルな識別子となり、転送や所有権確認に使われます。
5-2. UIDの生成と管理
UIDはobject::new(ctx)関数によって生成されます。同じUIDは絶対に2つ存在できないことがシステムによって保証されており、これがオブジェクトの一意性の核心です。
オブジェクトを削除する場合はobject::delete(id)を呼ぶ必要があります。UIDはdrop能力を持たないため、明示的な削除なしにオブジェクトを廃棄することはできません。これにより、オブジェクトの「行方不明」を防いでいます。
6. 能力の組み合わせと実践的な型設計
6-1. 主要パターンとその使い分け
能力の組み合わせによって、以下のような型のカテゴリが生まれます。
- copy + drop + store：プリミティブ型相当。アドレスや数値など
- store のみ：他の構造体のフィールドになれるが、転送やコピーはできない内部データ
- key + store：通常のオブジェクト。転送・共有・ラップが可能な標準的なNFTやCoin
- key のみ（store なし）：ソウルバウンドオブジェクト。転送不可のIDや資格情報
- 能力なし：純粋なリソース。明示的な消費が必要で最も制約が厳しい
6-2. 実際の設計における注意点
型設計において最も注意すべきは「必要最小限の能力だけを付与する」という原則です。余分な能力を付与すると、意図しない操作が可能になります。
例えば、NFTのメタデータ構造体にcopyを付与してしまうと、メタデータが無制限にコピーされる可能性があります。また、重要なゲームアイテムにdropを付与すると、誤ってアイテムが消滅するコードをコンパイラが通してしまいます。設計段階で各型の能力を慎重に検討することが、安全なスマートコントラクト開発の第一歩です。
7. AptosのMove能力システムとの比較
7-1. 基本的な互換性
Aptosも同じ4つの能力システムを採用しています。ただし、Aptosにはkeyの意味が若干異なり、グローバルストレージのアカウントリソースとしての格納を意味します。Suiのようにオブジェクトに一意のUID（オブジェクトID）が付与されるわけではありません。
この違いによって、AptosとSuiで同じ名前の能力を持っていても、実際の動作には差異があります。特にkeyの扱いは、両チェーンのストレージモデルの根本的な違いを反映しています。
7-2. 能力システムの進化の可能性
Move言語は現在も進化しています。Sui Moveは独自の機能追加を続けており、将来的には能力システムにも変更が加えられる可能性があります。開発者は公式ドキュメントや変更ログを定期的に確認することをお勧めします。
また、Move 2.0に向けた取り組みも進んでいると報告されており、モジュールシステムや型システムの拡張が議論されています。こうした言語レベルの進化が、将来のスマートコントラクト開発にどう影響するかを注視することが大切です。
まとめ
Sui Moveの能力システムは、copy・drop・store・keyという4つの能力によって型の振る舞いをコンパイル時に制御する仕組みです。この設計によって、資産の二重支払いや不正な消滅をコードレベルで防止しています。
適切な能力設計はスマートコントラクトの安全性に直結するため、開発者は各能力の意味を正確に理解した上で型を設計することが重要です。特に資産型にはcopyとdropを付与しないことが鉄則であり、keyとstoreの組み合わせによってオブジェクトの振る舞いを細かく制御できます。
Move能力システムへの深い理解は、Suiエコシステムでの開発品質を大きく左右します。本記事の内容を基に、安全で効率的なスマートコントラクト設計を進めていただければ幸いです。
よくある質問（FAQ）
- copy能力とstore能力の違いは何ですか？
- copy能力は値をその場で複製できることを意味し、store能力はグローバルストレージや他の構造体のフィールドに格納できることを意味します。別々の概念であり、どちらか一方だけを持つ型も存在します。資産型の設計では通常、storeは必要でもcopyは不要なケースが多いです。
- key能力だけを持つ「ソウルバウンド」オブジェクトは実用的ですか？
- はい、特定のユースケースで非常に有用です。転送不可のメンバーシップ証明、KYC（本人確認）証明書、ゲームのキャラクターバッジなど、特定のアドレスに永続的に紐付けたい情報の表現に活用されています。Web3のアイデンティティ管理においても注目されている設計パターンです。
- 能力のない型（純粋なリソース）を使う場面はありますか？
- あります。例えば、関数内で必ず消費されることを強制したい一時的な証明書や、特定の条件下でのみ生成・消費されるべき権限オブジェクトなどに使われます。能力がないため、コンパイラが「必ず使われること」を強制し、開発者の意図通りの制御フローが保証されます。
※本記事は情報提供を目的としており、投資を推奨するものではありません。暗号資産への投資は元本割れのリスクがあります。投資判断はご自身の責任で行ってください。
