필사 모드: 分散・P2P コンテンツプロトコル 2026 — IPFS Helia / libp2p / BitTorrent v2 / WebTorrent / Hyperdrive / Iroh / Filecoin / Arweave / Storacha 徹底ガイド
日本語プロローグ — 「分散」という言葉は隠しすぎる
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 の例:
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 ノードを簡略化した形:
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 ブラウザ例:
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 の例:
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 を狙う。まだメインストリーム到達前。
一行要約マトリクス
| ソリューション | 一行 |
| --- | --- |
| Filecoin | IPFS とペアになったストレージマーケットブロックチェーン |
| Banyan | Filecoin 上のユーザーフレンドリーなクラウド UX |
| Storj | S3 互換の分散ストレージ |
| Arweave | 「永久保存」が核となる blockweave |
| Sia | 古参の P2P ストレージ、ホスト・レンター契約 |
| Akord | Arweave 上の 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 |
| メディア / CDN | WebTorrent、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 バックエンドで P2P | Iroh / libp2p(Rust) |
| 検閲耐性の動画プラットフォーム | PeerTube(ActivityPub + WebTorrent) |
| トークン市場の P2P | Pintswap |
エピローグ — 生き残ったものとその理由
2014 年に IPFS が登場して以来、P2P コンテンツの世界は約 12 年のサイクルを経た。その間に生き残ったものと消えたもののパターンは明確だ。
**生き残ったものの共通点:**
- **明確な単一の使命** — IPFS(アドレッシング)、Arweave(永続)、WebTorrent(ブラウザ)。
- **ライブラリ化** — フルアプリではなく他のシステムに組み込める部品。
- **継続するメンテナ** — Feross、Protocol Labs、Number 0、Holepunch など中核となる人物・チームの継続性。
**消えた・停滞したものの共通点:**
- **過大な野心** — Web5、Beaker Browser。
- **単一企業依存** — 会社が冷めれば一緒に冷める。
- **不明確な価値** — 「それで、なぜ普通のクラウドの代わりにこれを使うのか?」に答えられない。
2026 年の正解は**「オールイン分散」ではなく「選択的 P2P 活用」**だ。NFT メタには IPFS、永久保存には Arweave、ブラウザ動画には WebTorrent、そして残りはそのまま S3 — この組み合わせが実用的だ。
参考 / References
- IPFS — https://ipfs.tech/
- IPFS Docs — https://docs.ipfs.tech/
- Helia — https://helia.io/
- Helia GitHub — https://github.com/ipfs/helia
- Boxo (Go IPFS modular library) — https://github.com/ipfs/boxo
- Kubo (Go IPFS implementation) — https://github.com/ipfs/kubo
- libp2p — https://libp2p.io/
- libp2p Specs — https://github.com/libp2p/specs
- BitTorrent v2 spec (BEP 52) — https://www.bittorrent.org/beps/bep_0052.html
- BitTorrent v1 spec (BEP 3) — https://www.bittorrent.org/beps/bep_0003.html
- WebTorrent — https://webtorrent.io/
- WebTorrent GitHub — https://github.com/webtorrent/webtorrent
- Hypercore — https://hypercore-protocol.org/
- Hypercore GitHub — https://github.com/holepunchto/hypercore
- Holepunch (Pear runtime) — https://holepunch.to/
- Beaker Browser (sunset announcement) — https://beakerbrowser.com/
- Dat Project — https://dat-ecosystem.org/
- Iroh (Number 0) — https://iroh.computer/
- Iroh GitHub — https://github.com/n0-computer/iroh
- Filecoin — https://filecoin.io/
- Filecoin FVM — https://fvm.filecoin.io/
- Banyan Storage — https://banyan.computer/
- Storj DCS — https://www.storj.io/
- Arweave — https://www.arweave.org/
- Sia — https://sia.tech/
- Akord — https://akord.com/
- Pintswap — https://pintswap.com/
- Storacha (web3.storage rebrand) — https://storacha.network/
- web3.storage docs — https://web3.storage/docs/
- NFT.Storage — https://nft.storage/
- Web5 / TBD — https://developer.tbd.website/
- ActivityPub spec — https://www.w3.org/TR/activitypub/
- WebRTC — https://webrtc.org/
- Tahoe-LAFS — https://www.tahoe-lafs.org/
- PeerTube — https://joinpeertube.org/
- IPLD — https://ipld.io/
- Multiformats — https://multiformats.io/
- UCAN — https://ucan.xyz/
현재 단락 (1/347)
2026 年に「分散コンテンツ」と言うと、人によって思い浮かべるものが全く違う。ある人は IPFS の CID(Content ID)を、別の人は Torrent の magnet リンクを、また別の...