Skip to content
Published on

分散・P2P コンテンツプロトコル 2026 — IPFS Helia / libp2p / BitTorrent v2 / WebTorrent / Hyperdrive / Iroh / Filecoin / Arweave / Storacha 徹底ガイド

🇰🇷KO🇺🇸EN🇯🇵JA
Split View필사 모드
Authors

プロローグ — 「分散」という言葉は隠しすぎる

2026 年に「分散コンテンツ」と言うと、人によって思い浮かべるものが全く違う。ある人は IPFS の CID(Content ID)を、別の人は Torrent の magnet リンクを、また別の人は Arweave の「永久保存」を、さらに別の人は Filecoin のストレージマーケットを想像する。そして誰かは Jack Dorsey の Web5 スライドを思い浮かべる — それは 2024〜25 年にほぼ止まったプロジェクトだ。

この記事は、それら全部を一枚の地図に並べる作業だ。どのプロトコルが生きていて、どれが死に(Beaker Browser、2022 RIP)、どれが名前を変えて(web3.storage → Storacha、2024)、どれが静かに開発を続けている(Iroh、Helia、Boxo)のか。

最初に核となるメッセージを置く。

  • IPFS は「プロトコル」、Helia はそのプロトコルのモダンな JS 実装である。混同してはいけない。
  • libp2p は IPFS から外に独立したネットワーキングスタック。
  • **BitTorrent v2(BEP 52)**は 2018 年の仕様だが、2026 年の今もまだ「ゆっくり普及」の段階。
  • WebTorrent はブラウザで Torrent を扱う事実上唯一の実用手段として生き残った。
  • Hyperdrive / Hypercore は Beaker ブラウザが死んだ後もライブラリとして生きている。
  • Iroh は Rust で書き直された IPFS — 「より軽く、より速く、モバイルに優しい」を狙う。
  • Filecoin / Arweave / Storj / Sia / Akord はそれぞれ異なる経済モデルで生き残っている。
  • Storacha(旧 web3.storage)、NFT.Storage は Protocol Labs 系の無料/低価格 IPFS ゲートウェイの後継。
  • Web5 はほぼ停滞。

ひとつずつ見ていこう。

第 1 章 · 2026 年の P2P コンテンツ地図 — 4 つの大分類

P2P コンテンツの世界を頭の中で整理する最も簡単な方法は、4 つの大分類だ。

+----------------------------------------------------------+
|             2026 P2P コンテンツ地図                       |
+----------------------------------------------------------+
| 1. IPFS 系(content-addressed, CID)                      |
|    - IPFS Helia (JS)                                     |
|    - Kubo (Go)                                           |
|    - Boxo(モジュール式ライブラリ)                       |
|    - Iroh(Rust 再構想)                                  |
|    - libp2p(ネットワーキングスタック)                   |
|                                                          |
| 2. Hyper 系(append-only logs)                           |
|    - Hypercore                                           |
|    - Hyperdrive                                          |
|    - Beaker Browser(RIP 2022)                           |
|    - Dat → Hyper リブランド                              |
|                                                          |
| 3. BitTorrent 系                                         |
|    - BitTorrent v1(1990s)                               |
|    - BitTorrent v2 / BEP 52(2018、ゆっくり普及)         |
|    - WebTorrent(ブラウザ JS)                            |
|                                                          |
| 4. Crypto storage 系(経済インセンティブ)                |
|    - Filecoin(検証可能なストレージマーケット)           |
|    - Arweave(永久保存)                                  |
|    - Storj DCS(S3 互換)                                 |
|    - Sia / Akord                                         |
|    - Banyan Storage(Filecoin 上)                        |
+----------------------------------------------------------+

この 4 つは補完関係にある。IPFS はアドレッシング・検索、BitTorrent は大容量配布、Hyper は append-only データストリーム、Crypto storage は永続性とインセンティブ — それぞれ得意分野が違う。

そして地図の端に少し外れて立っているもの:

  • ActivityPub — Mastodon が使うフェデレーション SNS プロトコル。厳密には P2P ではないが、「分散」の傘の下に並ぶ。
  • WebRTC データチャネル — ブラウザ間の直接通信。WebTorrent の基盤。
  • Tahoe-LAFS — 古い(2008 年〜)分散暗号化ストレージ。今も生きている。

第 2 章 · IPFS — Protocol Labs、進化中

**IPFS(InterPlanetary File System)**は 2014 年に Juan Benet が Protocol Labs で始めた、コンテンツアドレッシング型分散ファイルシステムのプロトコルである。

中核のアイデアを一行で:ファイルを場所(URL)で識別するのではなく、内容のハッシュ(CID)で識別しよう。

これがなぜ重要か:

  • 同じファイルなら同じ CID。キャッシュ・重複排除が自然に成立する。
  • CID が同じなら誰がホストしても同じファイル。ホストが消えても同じ CID が別ノードに残っていれば取得できる。
  • 改竄不能。CID 自体がハッシュなので、データが変わると CID も変わる。

2026 年の IPFS 実装

長年、IPFS の二大メジャー実装は **Kubo(Go、旧 go-ipfs)**と js-ipfs だった。2023 年に JS 側で大きな変化があった。

  • Kubo — 今も生きていて活発に開発され、サーバー・CLI の標準。
  • js-ipfs は事実上 EOL — 2023 年 8 月に Helia が登場して段階的に置き換わった。
  • Boxo — Kubo から切り出した Go 製モジュールライブラリ集。
  • Iroh — Rust で書き直された「lite IPFS」。Number 0(旧 n0)チームによる開発。

この変化の核心は、「単一の巨大な IPFS デーモン」から「必要な部分だけ取り出して使うライブラリ」への移行である。

IPFS はブロックチェーンではない

よく混同される点なので明示しておく。IPFS はブロックチェーンではない。コンセンサスアルゴリズムもトークンも、基本の IPFS プロトコルには存在しない。IPFS は単に DHT(分散ハッシュテーブル)ベースのファイル検索である。

Filecoin は同じ会社(Protocol Labs)から出ているが、Filecoin がブロックチェーン部分だ。IPFS は「アドレス体系」、Filecoin は「そのアドレスが誰のディスクに置かれているかをインセンティブ化するマーケット」。

第 3 章 · Helia(2023 年 8 月)— js-ipfs を置き換えるモダンクライアント

Helia は Protocol Labs と IPFS Foundation が 2023 年 8 月に公開した JavaScript 向けの新しい IPFS 実装である。js-ipfs の改良ではなく、ほぼ作り直しに近い。

なぜ書き直したか。js-ipfs が作られた頃(2016 年〜)から JS エコシステムが変わりすぎた。ES モジュール、TypeScript ファースト、Web Streams API、そして何よりバンドルサイズに敏感なフロントエンド。js-ipfs のコードは大きく、重く、密結合していた。

Helia の設計原則:

  • モジュール式 — 必要な部分だけ取り出す。フルノードを丸ごとインポートしない。
  • モダン JS — ESM、TypeScript ファースト、async iterators。
  • ブロック単位 API — 「ファイル」ではなく「ブロック」が一級市民。ファイル抽象(UnixFS)は別パッケージ。
  • トランスポート分離 — libp2p のどのトランスポートを使うか選択可能(WebRTC、WebTransport、WebSocket)。

シンプルな Helia の例:

import { createHelia } from 'helia'
import { unixfs } from '@helia/unixfs'

const helia = await createHelia()
const fs = unixfs(helia)

// アップロード
const encoder = new TextEncoder()
const cid = await fs.addBytes(encoder.encode('Hello Helia 2026'))
console.log('CID:', cid.toString())

// 読み出し
const decoder = new TextDecoder()
let content = ''
for await (const chunk of fs.cat(cid)) {
  content += decoder.decode(chunk)
}
console.log(content)

Helia を使うシナリオ:

  • ブラウザで直接 IPFS ノードを動かしたいとき — ipfs.io のようなゲートウェイに依存せず。
  • Node.js アプリで軽量な IPFS が必要なとき — Kubo デーモンを立てるのは大げさという場合。
  • モバイル PWA / Electron / Tauri アプリ — バンドルサイズが重要な環境。

第 4 章 · Boxo — モジュール式 IPFS ライブラリ(Go)

Boxo は 2023 年に Kubo から切り出された Go 用モジュールライブラリ集だ。名前は「箱の集まり」を意味する。

Helia が JS 側の「モジュール式 IPFS」だとすれば、Boxo は Go 側のそれだ。Kubo がフルノードのデーモンであるのに対し、Boxo は「Kubo が内部で使っている部品を外でも使えるように整理したもの」。

Boxo に含まれる部品の一部:

  • bitswap — ブロック交換プロトコル。
  • gateway — HTTP ゲートウェイ実装(/ipfs/CID)。
  • blockstore — ブロックストレージ抽象。
  • routing — DHT、delegated routing。
  • path resolution — IPLD パス解決。

いつ Boxo を使うか。自社サービスに IPFS の一部機能だけを組み込みたいとき。例:

  • 社内 CDN にコンテンツアドレッシングを追加。
  • HTTP ゲートウェイだけ独立に運用。
  • カスタム IPFS 応用ノード(データマーケット等)。

Boxo の登場は IPFS エコシステムが**「フルノード IPFS」から「ライブラリ化された IPFS」へ移行する流れ**を象徴している。

第 5 章 · libp2p — IPFS から飛び出したネットワーキングスタック

libp2p は元々 IPFS の一部だった。P2P ネットワーキングに必要なすべて — ピア発見、トランスポート、多重化、暗号化 — をまとめた、IPFS 内部用のライブラリ。これが良すぎて IPFS の外でも使いたいという需要が生まれ、別プロジェクトとして独立した。

2026 年現在、libp2p は IPFS からほぼ独立した P2P ネットワーキングの標準になっている。Ethereum 2.0(Lighthouse、Lodestar、Nimbus)、Polkadot/Substrate、Filecoin、Eth2 P2P、Iroh などが libp2p を使う。

libp2p のモジュール性

libp2p の核は「トランスポートとプロトコルを差し替えられる」こと:

  • Transports — TCP、QUIC、WebSocket、WebTransport、WebRTC、Bluetooth。
  • Security — Noise、TLS 1.3。
  • Muxers — yamux、mplex。
  • Discovery — mDNS、DHT、rendezvous、bootstrap。
  • Pubsub — gossipsub(Eth2 が使う)、floodsub。

JS の例 — Helia が内部で構成する libp2p ノードを簡略化した形:

import { createLibp2p } from 'libp2p'
import { webSockets } from '@libp2p/websockets'
import { webRTC } from '@libp2p/webrtc'
import { noise } from '@chainsafe/libp2p-noise'
import { yamux } from '@chainsafe/libp2p-yamux'

const node = await createLibp2p({
  transports: [webSockets(), webRTC()],
  connectionEncryption: [noise()],
  streamMuxers: [yamux()]
})

await node.start()
console.log('peer id:', node.peerId.toString())

libp2p を理解しておけば、IPFS だけでなくほぼ全てのモダン P2P システムの内部を理解できる。ほぼ標準だ。

第 6 章 · BitTorrent v2(BEP 52)— 2018 年の仕様、2026 年も普及が遅い

BitTorrent v2 は 2018 年に BEP 52 として仕様化された大規模アップグレードだ。主な変更点:

  • SHA-256 ハッシュ(v1 は SHA-1)。
  • Merkle ツリーベースのファイル検証 — ファイル単位で個別の Merkle ルートを持つ。
  • 重複データ排除 — 同じファイルが複数の Torrent に含まれていても 1 度だけダウンロード。
  • ハイブリッド Torrent — v1/v2 同時対応。

技術的に v2 は明らかな改良だ。しかし 2026 年の現在に至っても普及は非常に遅い。なぜか:

  • レガシー Torrent が多すぎる — 数十年分の v1 Torrent がトラッカーとインデックスサイトに積み上がっている。
  • クライアントの対応が遅かった — qBittorrent、Transmission などは段階的に対応したが、v1 フォールバックが普通。
  • ユーザーに「メリット」が見えにくい — v1 でも動く。

2026 年時点の v2 現実:

  • qBittorrent / Deluge / Transmission — v2 とハイブリッドをサポート。
  • uTorrent — メインラインは遅かったが対応済み。
  • WebTorrent — v2 サポートは部分的。
  • トラッカー側 — v2 インデックスは増えたが、v1 が圧倒的多数。

学ぶべき人:

  • Torrent クライアント開発者 — v2 の Merkle 検証は、データ完全性を保証する設計の良いケーススタディ。
  • 大容量ファイル配布インフラ(Linux ISO、公開データセット) — 最終的には v2 に向かう必要がある。

第 7 章 · WebTorrent — ブラウザ JS で Torrent

WebTorrent は Feross Aboukhadijeh が作った純粋 JS、ブラウザ親和的な Torrent クライアントだ。デスクトップ WebTorrent アプリもあるが、本領はブラウザ内・プラグインなしで Torrent を受け取れること。

どうやって? WebRTC

従来の Torrent は TCP/UDP を使う。ブラウザはどちらも直接は使えない。WebTorrent は WebRTC データチャネルをトランスポートとして利用するため、ブラウザ間 P2P が可能になる。

トレードオフ:

  • 従来の Torrent ピアとは直接通信できない — WebRTC 対応ピア(ハイブリッドクライアント)が必要。
  • WebRTC シグナリングサーバが必要 — 初回接続を仲介する誰かが必要。

シンプルな WebTorrent ブラウザ例:

import WebTorrent from 'webtorrent'

const client = new WebTorrent()
const magnetURI = 'magnet:?xt=urn:btih:...'

client.add(magnetURI, function (torrent) {
  torrent.files.forEach(function (file) {
    // video タグに直接ストリーミング
    file.appendTo('#player')
  })
})

WebTorrent が生き残った理由:

  • ブラウザ P2P 動画ストリーミングの事実上唯一の実用選択肢 — Twitter/X が一時検証し、ActivityPub 動画プラットフォームの PeerTube が積極利用。
  • Feross が継続してメンテナンスしている — 個人プロジェクト水準の安定性。

2026 年時点では WebRTC P2P 動画 / ライブ配信の事実上の標準ライブラリ。

第 8 章 · Hyperdrive + Hypercore — append-only ログ型ファイルシステム

Hypercore は append-only ログ(追加のみ可能なログ)のための P2P プロトコルだ。Hyperdrive はその上に構築されるファイルシステム抽象。

中核アイデア:

  • すべてのデータはログとして保存される。変更せず、末尾に新しいエントリを追加するだけ。
  • 各ログは公開鍵で識別される。鍵を持つ者が「書き込み」権限者。
  • 同じ鍵を知っていれば誰でも読み出し・複製できる。

これは IPFS と何が違うか。IPFS は「既に完成したデータのコンテンツアドレッシング」、**Hypercore は「時間とともに育つデータの P2P 複製」**だ。違う問題を解いている。

Hypercore が向くケース:

  • リアルタイム協調ドキュメント — 一方が書き、他方が追従。
  • append-only データセット — ログ、監査証跡、トレーディングデータ。
  • バージョン管理 — すべての変更がログに残るため自然。

JS API の例:

import Hypercore from 'hypercore'

const core = new Hypercore('./my-storage')
await core.ready()

await core.append('最初のエントリ')
await core.append('2 番目のエントリ')

console.log('ブロック数:', core.length)
const first = await core.get(0)
console.log(first.toString())

第 9 章 · Beaker Browser(RIP 2022)→ Dat → Hyper リブランド

Beaker Browser は 2016〜2022 年に存在した「P2P ウェブブラウザ」プロジェクトだった。普通のブラウザのように見えるが、dat:// プロトコルで P2P サイトをホスト・閲覧できた。フォルダを作って「publish」ボタンを押せばそれが P2P サイトになった。

2022 年に Beaker は公式に開発を停止した。しかしその基盤技術である Dat プロトコルは死ななかった — Hyper にリブランドされてライブラリとして生き続けている。

  • Dat プロトコル → Hyper(Hypercore、Hyperdrive など)
  • Beaker ブラウザは RIP、ただし Hyper エコシステムは小さなコミュニティとして維持。
  • Holepunch(Pear Runtime の親会社)— Hyper を活用して P2P アプリランタイム(Keet、Pear)を構築中。

Beaker が死んで Hyper だけが残るこのパターンは「ブラウザは死ぬがライブラリは生き残る」という P2P 史によくある結末だ。類似事例:

  • ZeroNet — ほぼ停止、ライブラリだけ。
  • Maelstrom(BitTorrent 社のブラウザ)— 早期に死去。
  • Beaker — 2022 RIP。

ブラウザベンダーの立場では、P2P 統合はあまりに深く入り込みすぎてセキュリティ・UX の負担が大きい。そのためライブラリに留まるのが現実的な均衡点だ。

第 10 章 · Iroh(Number 0)— Rust で書き直した IPFS

Iroh は Number 0(旧名 n0)チームが作る Rust ベースの IPFS 再構想だ。2022 年頃に開始、2024〜25 年に 1.0 に向けて速いペースで進化中。

中核メッセージ:「IPFS の良いアイデアは引き継ぎ、既存実装の重荷は捨てる」。

Iroh の差別化:

  • Rust — メモリ安全、高速バイナリ、組み込み/モバイル親和的。
  • バンドルサイズが小さい — フル Kubo は数十 MB、Iroh は遥かに軽量。
  • QUIC ファースト — トランスポートのデフォルトが QUIC(libp2p の旧 TCP 優先前提と異なる)。
  • 接続そのものに焦点 — 「2 つのデバイスを直接つなぐ」が最大目標。
  • Holepunching 重視 — NAT 越えの P2P を確実に通すエンジニアリングに投資。

Iroh は自らを**「ファイルを P2P で高速に動かすライブラリ」**と表現する。IPFS の思想は踏襲するが、IPFS メインスタックの全機能は実装しない。

Rust の例:

use iroh::Iroh;

#[tokio::main]
async fn main() -> anyhow::Result<()> {
    let iroh = Iroh::memory().await?;
    let blob = iroh.blobs().add_bytes(b"Hello Iroh 2026".to_vec()).await?;
    println!("hash: {}", blob.hash);
    Ok(())
}

Iroh を選ぶ場面:

  • モバイル/組み込みで P2P ファイル転送が必要なアプリ。
  • バンドルサイズが重要なデスクトップアプリ(Electron/Tauri)。
  • Rust バックエンドと一緒に動かしたいとき。

IPFS Kubo を選ぶ場面:

  • フル機能の IPFS ノードが必要(public gateway、pinning、IPNS、MFS など)。
  • 既存 IPFS ツール・サービスとの互換性が重要。

第 11 章 · Banyan Storage / Filecoin / Storj DCS / Arweave / Sia / Akord — Crypto ストレージの 5 つの流派

ここからは**「ファイルを誰がどう保管するか」の経済モデル**の話だ。P2P プロトコルはデータの保管場所までは定義しない — それは別の市場の問題だ。

Filecoin

Filecoin(Protocol Labs)は IPFS と同じ会社が作ったストレージマーケットのブロックチェーン。核となる仕組み:

  • ストレージプロバイダ(SP)がディスク容量をマーケットに掲示。
  • クライアントが「これだけ保存して」と取引。
  • SP は PoSt(Proof-of-Spacetime)、**PoRep(Proof-of-Replication)**で「本当に保管している」ことを定期的に証明。
  • 支払いはトークン(FIL)。

2024〜25 年の大きな変化は FVM(Filecoin Virtual Machine)— EVM 互換のスマートコントラクトが Filecoin 上で動くようになった。

Banyan Storage

Banyan Storage は Filecoin の上に乗る**「end-to-end 暗号化されたクラウドストレージ UX」**だ。一般ユーザーは Filecoin に直接触れず、Dropbox のような感覚で使える。バックエンドは Filecoin と IPFS。

Storj DCS(Decentralized Cloud Storage)

Storj は P2P 分散ストレージだが、S3 互換 APIを前面に押し出している。主要な工夫:

  • ファイルを約 80 個の断片に erasure coding して世界中のノードに分散。
  • その一部だけ集めれば復元可能。
  • トークン(STORJ)で支払えるが、クレジットカードも可。

Storj は **「S3 の代替」**に近いポジショニングで、開発者の移行を簡単にする方向で設計されている。

Arweave

Arweave は少し違う。キーワードは**「永久保存(permanent storage)」**。一度支払えば「200 年保証」を約束する。

  • データは blockweave という変則的ブロックチェーンに保存される。
  • マイナーは新しいブロックだけでなく過去ブロックの一部も同時に証明する必要がある(Proof of Access)。
  • 支払いは一括 — 「これだけトークンを払えば永久」。

NFT メタデータ、学術資料、失ってはいけないコンテンツによく使われる。

Sia / Akord

  • Sia — 古い(2014 年〜)分散ストレージ。独自トークン(SC)。ホストとレンターが直接契約。
  • Akord — Arweave の上に乗るユーザーフレンドリーな UI。家族写真の永久保存などの用途。

Veera Network

比較的新しい。P2P コンテンツ配信・CDN を狙う。まだメインストリーム到達前。

一行要約マトリクス

ソリューション一行
FilecoinIPFS とペアになったストレージマーケットブロックチェーン
BanyanFilecoin 上のユーザーフレンドリーなクラウド UX
StorjS3 互換の分散ストレージ
Arweave「永久保存」が核となる blockweave
Sia古参の P2P ストレージ、ホスト・レンター契約
AkordArweave 上の UI レイヤー

第 12 章 · Pintswap / Pollen — P2P の新興勢力

Pintswap は P2P トークンスワップのプロトコルだ。中央マッチングなしに、libp2p の上で OTC(店頭)取引を行う。「この価格で買う?」を P2P メッセージでやり取りし、署名だけオンチェーン。

Pollen Network は P2P CDN ビジョン。ユーザーデバイスのアイドル帯域を集めてコンテンツ配信網を作る。

どちらも 2026 年時点でメインストリームではないが、**「P2P インフラが dApp のサブレイヤーに入り込むパターン」**の例だ。

第 13 章 · web3.storage → Storacha リブランド(2024)

2020〜22 年に web3.storage と NFT.Storage は Protocol Labs が運営する**「ファイルを投げれば IPFS + Filecoin に自動保存してくれる無料/低価格サービス」**だった。NFT メタデータから学術データセットまで広く使われた。

2024 年に web3.storage は Storacha にリブランドされ、運営主体が分離された。主な変更点:

  • 名称変更 — web3.storage → Storacha。
  • UCAN(User Controlled Authorization Networks)ベースの権限 — トークンの代わりに分散型認可モデル。
  • w3up CLI — 新しいクライアント。

CLI の例:

# インストール
npm install -g @web3-storage/w3cli

# ログイン(メール)
w3 login your@email.com

# Space を作成
w3 space create my-space

# アップロード
w3 up ./my-file.png

運用面では今でも IPFS コンテンツをホストする最もアクセスしやすい選択肢の一つ。

第 14 章 · NFT.Storage — Protocol Labs

NFT.Storage は同じ流れの姉妹プロジェクトで、NFT メタデータ特化だ。トークン ID、画像、attributes JSON を IPFS に無料でアップロード。

2024 年に NFT.Storage は **NFT.Storage Classic(無料、最低限のサポート)**と **NFT.Storage v2(商用サービス)**に分岐した。無料ティアのポリシーが変わり「ただで NFT メタを永久保存」という約束に小さな亀裂が入り、一部コレクションは Arweave に移行した。

教訓:「無料の IPFS pin サービスの永続性は常に疑うべきだ」。誰かが必ずコストを払っている。

第 15 章 · Web5(TBD55、Jack Dorsey)— 停滞状態

Web5 は Jack Dorsey の Block(旧 Square)傘下の TBD(後に TBD55 と呼ばれるグループ)が 2022 年に発表したビジョンだ。スローガンは「Web2 の使い勝手 + Web3 の分散性、トークンなし」。

設計上の柱:

  • DID(Decentralized Identifier) — ユーザーが自分の ID を所有。
  • VC(Verifiable Credential) — W3C 標準。
  • DWN(Decentralized Web Node) — ユーザーデータをノードに保存。

野心は大きかったが、2024〜25 年に開発速度が大きく落ちた。2026 年時点:

  • メジャー dApp が Web5 を採用した例はほとんどない。
  • DWN 仕様は生きているが、商業的モメンタムは弱い。
  • 「トークンなしの Web3」というポジショニングは、結局 Solid、IPFS など既存の非トークン分散化の流れとの差別化に失敗した。

これは興味深いケーススタディだ — **「スローガンが強力でもビルディングモメンタムがなければ死ぬ」**の見本。

第 16 章 · 韓国 / 日本の IPFS 事例

P2P プロトコルはグローバルだが、地域事例を見るとどこで実際に使われているかが掴める。

韓国

  • NFT メタ / デジタル資産保管 — Klip、各種韓国 NFT プロジェクトが IPFS と Arweave の組み合わせを採用。
  • 公共データ・デジタルアーカイブ実験 — 一部の図書館・国立記録院がコンテンツ完全性目的の IPFS 補助利用を検討。
  • ICON / カカオ Klaytn 系 — 一部の Facebook ライブラリ作業、独自の分散ストレージソリューション実験。
  • 国内 dApp 開発者コミュニティ — Helia/Storacha ベースの NFT マーケットプレイス・バックエンド。

日本

  • Sony Music / 日本のレコード会社の NFT プロジェクト — IPFS をメタデータ保管に活用した事例多数。
  • 日本の web3 サービス / NFT マーケット — トークン取引所・NFT プラットフォームが IPFS と Arweave のデュアルホスティングを標準採用。
  • 出版・アーカイブ — 一部の漫画・文学アーカイブプロジェクトが IPFS バックアップを採用。
  • 分散 ID(DID)実験 — 日本のデジタル庁の一部 PoC。

共通点:**「NFT メタ + 永久保存」**のシナリオで IPFS と Arweave が最もよく一緒に使われる。

第 17 章 · 誰が P2P コンテンツを学ぶべきか

役割何を見るべきか
dApp / NFT 開発者IPFS(Helia)、Storacha、NFT.Storage または Arweave
分散システムエンジニアlibp2p、IPFS Kubo、Iroh の内部
モバイル / Tauri 開発者Iroh、WebRTC、WebTorrent
データアーキビストArweave、Filecoin、Banyan
学術 / 研究IPFS、Arweave、Tahoe-LAFS
検閲回避 / 人権ツールIPFS、BitTorrent v2、WebTorrent、libp2p
メディア / CDNWebTorrent、Pollen、Filecoin

「なぜ学ぶか」の 4 つの動機

  1. 永久保存 — 会社が消えても残るコンテンツ。NFT、学術、ジャーナリズム。
  2. 検閲回避 — 単一ホスト依存を断つべきシナリオ。(そして責任も分散される。)
  3. CDN コスト削減 — 大容量コンテンツを P2P に乗せれば egress コストを大きく削減できる。
  4. 研究・ハッキングの面白さ — libp2p、Iroh、Hypercore はそれ自体で良いシステム設計の教材。

「学ばなくてもよい」ケース

  • 社内向け一般 Web アプリ — そのまま S3 / Cloud Storage を使え。
  • 早い MVP 構築中 — 標準クラウドの方が遥かに速い。
  • コンプライアンスが厳しい業界 — データ位置の追跡が困難になる可能性。

**P2P は「デフォルト」ではなく「特定の問題を解くためのツール」だ。**何にでも詰め込もうとするな。

第 18 章 · 2026 年の意思決定ガイド — 5 分の決定ツリー

質問答え
とりあえず小さなファイルを IPFS に置きたいStoracha(旧 web3.storage)
NFT メタデータをホストStoracha + Arweave デュアル
本当に永久保存(数十年)Arweave
S3 をそのまま置き換えたいStorj DCS
ブラウザで直接 IPFS ノードHelia
ブラウザで Torrent / P2P 動画WebTorrent
モバイルで P2P ファイル転送Iroh
append-only 協調データHypercore / Hyperdrive
Rust バックエンドで P2PIroh / libp2p(Rust)
検閲耐性の動画プラットフォームPeerTube(ActivityPub + WebTorrent)
トークン市場の P2PPintswap

エピローグ — 生き残ったものとその理由

2014 年に IPFS が登場して以来、P2P コンテンツの世界は約 12 年のサイクルを経た。その間に生き残ったものと消えたもののパターンは明確だ。

生き残ったものの共通点:

  • 明確な単一の使命 — IPFS(アドレッシング)、Arweave(永続)、WebTorrent(ブラウザ)。
  • ライブラリ化 — フルアプリではなく他のシステムに組み込める部品。
  • 継続するメンテナ — Feross、Protocol Labs、Number 0、Holepunch など中核となる人物・チームの継続性。

消えた・停滞したものの共通点:

  • 過大な野心 — Web5、Beaker Browser。
  • 単一企業依存 — 会社が冷めれば一緒に冷める。
  • 不明確な価値 — 「それで、なぜ普通のクラウドの代わりにこれを使うのか?」に答えられない。

2026 年の正解は**「オールイン分散」ではなく「選択的 P2P 活用」**だ。NFT メタには IPFS、永久保存には Arweave、ブラウザ動画には WebTorrent、そして残りはそのまま S3 — この組み合わせが実用的だ。

参考 / References

Discuss on Twitter • View on GitHub