ゼロから分かるDeFi入門── 2026年版完全ガイド

分散型金融という言葉は広く知られるようになりましたが、その中身を仕組みの水準で説明できる人はそれほど多くありません。値動きの話題が先行し、何がどう動いているのかという部分は飛ばされがちです。

本稿は、金融システムに関わる技術者に向けた入門です。個別のサービスを紹介するのではなく、構成要素を分解して、それぞれが従来の金融インフラの何を置き換えようとしているのか、そして何がまだ解けていないのかを整理します。

DeFi を構成する三つの層

分散型金融は、大きく三つの層で理解できます。最下層が決済レイヤで、資産の保有と移転を記録する基盤です。中間が資産レイヤで、ネイティブ資産に加えて、法定通貨に価値を連動させた資産や、他の資産を裏付けとする派生的な資産が置かれます。

最上層がアプリケーションレイヤで、交換、貸借、デリバティブといった金融機能を実装したコントラクト群が並びます。従来の金融では別々の主体が担っていた機能が、同じ基盤の上でプログラムとして実装され、互いに呼び出し合える点が構造的な特徴です。

この構成可能性が、利点であると同時にリスクの源にもなります。あるコントラクトの不具合が、それを利用する別のコントラクトへ連鎖する経路が存在するためです。

自動マーケットメイクという発想

分散型取引所の中核にあるのが、注文板を持たない交換の仕組みです。売り注文と買い注文を突き合わせるのではなく、二種類の資産を蓄えた資金プールを用意し、数式に基づいて交換比率を決めます。

もっとも単純な設計では、プール内の二資産の数量の積を一定に保ちます。片方を投入すると、積が保たれるようにもう片方が払い出され、その結果として価格が動きます。常に取引相手が存在するという性質が、流動性の薄い資産でも交換を可能にしました。

// 積一定型の交換。手数料を差し引いた入力に対して出力を決める。
// 取引規模が大きいほど不利な比率になる（スリッページ）。
function getAmountOut(uint256 amountIn, uint256 reserveIn, uint256 reserveOut)
    internal pure returns (uint256)
{
    require(amountIn > 0 && reserveIn > 0 && reserveOut > 0, "invalid");
    uint256 amountInWithFee = amountIn * 997;              // 手数料 0.3%
    uint256 numerator = amountInWithFee * reserveOut;
    uint256 denominator = reserveIn * 1000 + amountInWithFee;
    return numerator / denominator;
}

資金を提供する側には手数料収入が入りますが、価格が変動すると、単に資産を保有していた場合と比べて価値が目減りする現象が生じます。手数料収入がこの目減りを上回るかどうかが、資金提供の採算を決めます。

貸借と清算の仕組み

分散型の貸借では、借り手の信用力を審査する代わりに、借入額を上回る担保を預けさせます。担保価値が一定の水準を割り込むと、第三者が担保を売却して債務を返済し、その対価として報酬を受け取ります。

この清算処理が機能するには、担保の価値を正確に知る必要があります。ここで使われるのが外部の価格情報を供給する仕組みで、実務上もっとも狙われやすい箇所でもあります。価格情報を一時的に歪められると、本来なら清算されない担保が清算されたり、その逆が起きたりします。

対策として、複数の情報源を組み合わせる、一定期間の平均値を使う、急激な変動時には処理を止めるといった設計が用いられます。価格情報の設計が担保付き貸借の安全性を決めるという点は、金融システムの実装者にとって示唆的です。

ステーブルコインが接点になる

分散型金融の取引の多くは、法定通貨に価値を連動させた資産を介して行われます。値動きの大きいネイティブ資産だけでは、貸借や決済の基準になりにくいためです。このステーブルコインが、従来の金融と分散型の仕組みをつなぐ接点になっています。

設計は大きく二つに分かれます。発行体が同額の準備資産を保有する裏付け型と、他の資産を過剰担保として発行する担保型です。前者は準備資産の実在と流動性が信頼の根拠であり、後者は担保価値の変動と清算の機能が前提になります。

国内では資金決済法の改正により電子決済手段としての位置づけが整理され、銀行や信託会社が発行に関与する枠組みが用意されました。金融機関にとっては、分散型の仕組み全体に関わるより、この領域から接点を持つほうが制度との整合を取りやすくなります。

典型的なリスクと事故の型

この分野で報告される損失事例には、いくつかの繰り返される型があります。第一がコントラクトの不具合で、権限管理の設定漏れや、計算順序の誤りに起因するものが多く見られます。第二が価格情報の操作で、流動性の薄い資産の価格を一時的に動かして不当な清算や借入を成立させる手口です。

第三が、複数のコントラクトを組み合わせた際に生じる想定外の相互作用です。個々のコントラクトは正しく動いていても、組み合わせると意図しない状態を作れる場合があります。単体の監査では検出できないこの種の問題が、構成可能性の代償として存在します。

第四が、運用主体の権限に関わるものです。アップグレード可能な設計では、更新権限を持つ主体が事実上すべてを変更できます。技術的には分散していても、権限が集中していれば従来の信頼構造と変わりません。

従来の金融と何が違うのか

技術的な差異よりも、責任の所在の違いが本質的です。従来の金融では、事故が起きたときに責任を負う主体が明確に存在し、規制と補償の枠組みが用意されています。分散型の仕組みでは、コントラクトの不具合による損失を誰が負うのかが曖昧なまま残ることがあります。

もう一つが、可逆性です。誤った送金や不正な取引を事後に取り消す手段が、原則として存在しません。従来の決済網が持つ組戻しや異議申立ての仕組みは、利便性の裏返しとして事故からの回復手段でもありました。

一方で、取引記録が公開されているという性質は、従来にない透明性をもたらしました。誰がどれだけの資産を持ち、どの契約がどう動いたかを第三者が検証できます。この性質は、規制当局の監督手法にも影響を与えつつあります。

金融機関の立場からどう見るか

既存の金融機関がこの領域に関わる場合、技術をそのまま持ち込むのではなく、要素を切り出して評価するほうが実務的です。参考になるのは、担保管理の自動化、決済の即時完了、そして取引記録の透明性という三点です。

逆に、そのまま採用しにくいのが、匿名の参加者を前提とした設計と、不可逆な取引です。顧客確認の義務がある以上、参加者の識別は必要であり、誤りを訂正する手段も要ります。この差を埋める設計が、許可型の基盤で試みられている取り組みの中心にあります。

調査を始める場合は、まず小規模な検証環境で仕組みを動かし、清算やオラクルの挙動を実際に観察するところから入ると、資料を読むだけでは分からない性質が見えてきます。テストネット上でコントラクトを読み、状態変化を追う作業は、仕様書を読む何倍かの理解につながります。

監督の側でも動きがあります。取引記録が公開されているという性質を利用し、資金の流れを分析して不正な取引や制裁対象との関連を検出する手法が実務で用いられるようになりました。透明性が監督の道具になるという構図は、従来の金融にはなかった特徴です。金融機関がこの領域に接点を持つ場合、こうした分析能力を自前で持つかどうかも検討事項になります。

まとめ

分散型金融は、決済・資産・アプリケーションの三層で構成され、注文板を持たない交換と過剰担保による貸借を中核としています。技術的な新規性より、責任の所在と可逆性の欠如が従来の金融との本質的な差であり、そこを踏まえたうえで、担保管理の自動化や決済の即時性といった要素を個別に評価するのが金融機関にとって現実的な向き合い方になります。

金融テクノロジー総合研究所では、分散型台帳を用いた金融インフラの調査、スマートコントラクトの監査、許可型基盤の設計・実装を受託しています。調査の段階からご相談いただけます。お問い合わせよりご連絡ください。

FTL の技術スタックと受託開発の進め方は FTLの技術とは？にまとめています。