DApps（分散型アプリケーション）
スマートコントラクトを頭脳、分散ストレージを記憶、ブラウザ拡張のウォレットを鍵として組み合わせると、特定の企業のサーバーに依存しないアプリケーション、DAppsが生まれます。
DAppsとは:アーキテクチャと従来Webアプリとの違い
DApp（Decentralized Application、分散型アプリ）は、バックエンドのロジックを中央サーバーではなくスマートコントラクトに置いたアプリケーションです。典型的な構成は4層に分かれます。
- フロントエンド: ユーザーが触れる画面部分。通常のWeb技術（HTML/CSS/JS）で作られ、IPFSのような分散ストレージに置かれることもある。
- ウォレット: 秘密鍵を保管し、ユーザーの意思をトランザクションの署名として表明する仲介役。
- スマートコントラクト: ビジネスロジックと状態（残高・所有権など）を担う、ブロックチェーン上で実行されるプログラム。
- 分散ストレージ: 画像・動画・メタデータなど、コントラクトに置くには高コストな大きいデータの保存先。
従来のWebアプリとの決定的な違いは、「アプリの中核ロジックとデータを、運営者が勝手に変更・停止・削除できない」点にあります。普通のアプリはサーバーの持ち主がルールで、規約変更もアカウント凍結も一存で行えます。DAppでは、コントラクトのルールは公開・自動執行され、資産やデータの所有権はユーザーの鍵に紐づきます。運営者が消えてもコントラクトは動き続けます。
| 観点 | 従来のWebアプリ | DApp |
|---|---|---|
| バックエンド | 運営者が管理する中央サーバー | ブロックチェーン上のスマートコントラクト |
| データの所有権 | サービス運営者のデータベースに帰属 | ユーザーの鍵に紐づき本人がコントロール |
| 認証方式 | ID・パスワード、OAuthなど | ウォレットによる秘密鍵署名 |
| 停止・変更の可否 | 運営者の一存で規約変更・凍結・停止が可能 | 公開・自動執行され、運営者が消えても稼働継続 |
| 実行環境 | 運営者のクラウド／サーバー | ネットワーク上の全ノードが同一ロジックを検証・実行 |
| 処理コストの負担 | 運営者が負担（広告・課金モデル等で回収） | 利用者がガス代を都度負担 |
ウォレット接続とトランザクション署名の流れ
DAppにログインIDやパスワードはありません。代わりに使うのがウォレット（MetaMaskなどのブラウザ拡張やアプリ）です。典型的なユーザーフローは次のようになります。
- 接続: DAppの「Connect Wallet」ボタンを押すと、ウォレットが起動し、ユーザーが接続を承認する。これによりDAppはユーザーの公開アドレス（＝アカウント）を知る。パスワードの送信は一切ない。
- 操作の要求: ユーザーが「トークンを交換」などの操作を行うと、DAppはその内容を含むトランザクション案を組み立ててウォレットに渡す。
- 署名の確認: ウォレットが「何が起きるか」「ガス代はいくらか」を表示し、ユーザーが内容を確認して秘密鍵で署名する。鍵がウォレットの外に出ることはない。
- 送信と確定: 署名済みトランザクションがネットワークへ送信され、分散合意によってブロックに取り込まれると、コントラクトの状態が更新され、操作が確定する。
この「サービスに預けるのではなく、自分の鍵で署名する」モデルは、DIDの考え方とも地続きです。
データの置き場所:IPFSとArweave
スマートコントラクトのストレージは1バイトあたりのガス代が非常に高いため、画像・動画・メタデータのような大きなデータはブロックチェーン外に置くのが一般的です。代表格がIPFSとArweaveで、性質は対照的です。
IPFS（InterPlanetary File System）は、データの内容そのものから求めたハッシュ値（CID）をアドレスとするコンテンツアドレス方式のP2Pファイルシステムで、内部の探索にはKademlia系のDHTを用います。ただしIPFS自体は永続保存を保証しません。誰かが該当データをピン留め（pinning）して保持し続けない限り、参照するノードが減ればデータは失われ得ます。コントラクトが記録するのはCIDへの参照だけなので、内容そのものの可用性は別途確保する必要があります。
Arweaveは対照的に、一度の支払いで恒久的な保存を目指す設計です。アップロード時に将来の保存コスト低下を織り込んだ料金を先払いし、それを原資とするエンドウメント（基金）によってネットワーク参加者が長期的にデータを複製・保持し続けるインセンティブを作ります。「継続課金のピン留め」対「先払いの永続保存」という設計思想の違いが、両者を使い分ける基準になります。DAppのフロントエンド自体をIPFSやArweaveにホストし、ドメインではなくコンテンツハッシュで参照させる構成も広がっています。
オンチェーンデータの検索:インデクシングとThe Graph
スマートコントラクトは「ある関数を呼んで現在の状態を1件読む」のは得意ですが、「このアドレスが過去に行った全取引」「あるNFTコレクションの現在の全保有者」のような横断的な検索は苦手です。ブロックチェーンのノードは台帳であって検索インデックスではないため、素朴に実装すると全ブロックを走査する必要があり非現実的です。
この問題を解く仕組みがThe Graphに代表される分散型インデクシングです。開発者はコントラクトが発するイベントログをどう構造化データに変換するかを「サブグラフ」として定義し、ネットワーク上のインデクサーがそれに従ってブロックを継続的に処理し、GraphQLで問い合わせ可能な形にします。インデクサー・キュレーター・デリゲーターがステークと手数料で経済的にインセンティブ付けされる点が、単一企業のAPIサーバーによる中央集権的なインデックスとの違いです。とはいえ実務では、小規模なDAppが自前のバックエンドでeth_getLogsによるログ収集キャッシュを運用する、いわば中間的な妥協も広く行われています。
代表的なカテゴリ
- DeFi（分散型金融）: 分散型取引所（多くはAMM＝一定積の公式などでオンチェーンに価格を作る方式）、担保を要求するレンディング、デリバティブなど、仲介者なしの金融サービス。
- NFTマーケットプレイス: ERC-721/ERC-1155規格などでデジタルアートやコレクティブルの所有権を発行・売買する場。メタデータをオンチェーンに置くかIPFSなどオフチェーンに置くかは、永続性とコストのトレードオフになる設計判断。
- DAO（分散型自律組織）: トークン保有者の投票でルールや資金を運営する組織。投票自体はガス代節約のためオフチェーンで行い、実行だけをオンチェーンで行うハイブリッド方式も普及している。トレジャリー（資金庫）はマルチシグやコントラクトで管理されるのが一般的。
- ブロックチェーンゲーム: ゲーム内アイテムをNFTとして所有する試み。「複数のゲームをまたいでアイテムを持ち運ぶ」という理想はしばしば語られるが、実際にそれを実現しているタイトルは限定的で、多くは単一ゲーム内の所有権証明にとどまっているのが実情。
課題:UX・ガス代、そして「分散化の程度」というスペクトラム
DAppsはまだ発展途上で、普及には超えるべきハードルがあります。
- UX（使い勝手）: ウォレットの導入、秘密鍵やシードフレーズの自己管理、操作ごとの署名確認は、一般利用者には依然として敷居が高い。誤操作が資産の喪失に直結するシビアさもある。
- ガス代: ネットワークが混雑するとガス代が高騰し、少額の取引が割に合わなくなる。
- スケーラビリティとL2: ブロックチェーン本体（L1）は処理能力に限りがあります。取引を本体の外でまとめて処理し、結果だけをL1に記録するL2（レイヤー2）、とりわけロールアップが主流の解決策です。多数の取引を1つに圧縮し、L1の安全性を借りつつ手数料と混雑を大幅に軽減します。
「分散化の程度」は0か100かではない
「DAppはすべてが分散化されている」というのはよくある誤解です。実際には、フロントエンドのホスティング、データ保存、インデクシング／検索層、ガバナンス、コア・ロジックという複数の軸それぞれが、独立して中央集権寄りにも分散寄りにもなり得ます。フロントエンドが結局は中央のクラウドやドメインに置かれていたり、価格情報を単一のオラクルに頼っていたりと、「どこかに中央集権が残る」ケースは珍しくありません。
こうした現状を指して「Web2.5」と呼ぶこともあります。また、立ち上げ当初は開発チームが鍵やガバナンスを集中管理し、実績とコミュニティが育つにつれて段階的にDAOへ権限移譲していくプログレッシブ・ディセントラライゼーション（漸進的分散化）という設計方針も広く採用されています。真の分散化と実用性のバランスは、今なお設計者の腕の見せどころです。
DAppsは、本サイトで見てきたP2P・分散合意・鍵管理・スマートコントラクトといった要素技術が一つのアプリケーションとして結実した姿です。技術の総合力が問われる、分散システムの最前線と言えるでしょう。