私のWeb3サイトは4年間の放置を生き延びた

Drupal CMS ラボ編集部

2026-02-23

2026-03-05

この記事は Dries Buytaert 氏の公式ブログ「dri.es」の翻訳記事です。Driesブログの記事一覧よりすべての翻訳記事をご覧いただけます。

4年間放置した私のWeb3サイトは、まだ機能しているのでしょうか？さらに、Web3がウェブサイトホスティングにもたらした進歩についての考察もお伝えします。

4年前、私はIPFSとENSを使って初めてのWeb3ウェブページを公開しました。シンプルな「Hello World」HTMLファイルをアップロードし、dries.ethをそのファイルに紐付け、そのまま放置しました。2年後に確認したところ、まだ稼働していました。

それ以来、一切手を加えていません。実験を始めてからちょうど4年目の今日、再び確認してみました。dries.eth.limoでまだ稼働中です。完全に放置したまま4年が経ちましたが、ページは問題なく読み込まれました。

2年前に確認した時点では、利用していた全サービスが稼働していました。当時は「非常に心強い」と感じましたが、その楽観的な見方は長続きしませんでした。

今日確認したところ、サービスの半数が閉鎖、アクセス制限、あるいは全く別の事業へと転換していました：

コンテンツのピン留めに利用していたプラットフォーム「Fleek」は、2026年1月31日にホスティングサービスを終了しました。AI事業へ転換しています。
「Infura」はMetaMaskに買収され、新規ユーザー向けのIPFSサービスを終了しました。
「Web3.storage」は「Storacha」へとリブランディングし、IPFSのピン留め機能を完全に廃止しました。
CloudflareはパブリックIPFSゲートウェイを終了しました。
ScalewayはIPFSピンニングサービスを停止しました。

当初利用していたサービスの中では、Pinataが依然としてIPFSに注力しています。ログインしてみると、「Hello World」HTMLファイルはまだ残っていました。また、通常のブラウザで.ethサイトにアクセスできるENSゲートウェイのeth.limoも、現在も正常に機能しています。

技術的には堅牢、しかし商業的には脆弱

IPFS上のコンテンツは、誰かがホストし続けることを選んでいる間だけ存在します。2022年当時、私のHTMLファイルはFleek・Pinata・Infura、そして友人のノードにピン留めされていました。今日では、Pinataの無料プランだけが頼りです。私のWeb3ページは、かろうじて生き残っている状態です。

これは脆弱に聞こえますし、ある意味ではその通りです。しかし、プロトコル自体は設計通りに機能しています。IPFSはコンテンツの永続性を保証しません。保証するのは、コンテンツがアドレス指定可能で検証可能であり、ピン留めしようとする意思のある誰によっても存続させられるということです。

IPFS上のコンテンツの耐久性は、それに対する人々の関心の度合いによって決まります。私の「Hello World」ページに誰も関心を持たないため、ピン留めされていません。もしこれが反体制的なジャーナリズムや検閲された言論であれば、多くの人がピン留めするでしょう。

IPFSノードを運用していて私のページを存続させたい方は、ぜひピン留めしてください：ipfs pin add bafybeibbkhmln7o4ud6an4qk6bukcpri7nhiwv6pz6ygslgtsrey2c3o3q

もちろん、追加のサービスでピン留めしたり独自のノードを運用したりすれば、自分自身でより堅牢な状態にすることもできます。しかし私はサードパーティに依存してきました。自分のノードを持たない以上、存続はピン留めサービスや他のユーザーに完全に委ねられています。

本当の問題は脆弱性ではなく、経済性です。分散型ストレージに対する需要が、健全なプロバイダー市場を支えるには単純に不足している可能性があります。企業は参入し続けますが、ビジネスモデルを見つけられず、方向転換を余儀なくされています。

従来のホスティングは安価で信頼性が高く、馴染みがあります。検閲への耐性を本当に必要としている人は限られた層であり、私を含む他の多くの人が乗り換える理由はほとんどありません。また公平を期すならば、日常的なウェブホスティングの代替を目指すことは、おそらくもともとIPFSの目標ではなかったのでしょう。

私はIPFSというプロトコルとその背景にある思想は今も大好きです。しかし、そのエコシステムは商業的に脆弱で、しかもさらに弱体化しているように感じます。

以前、ウェブコンテンツ向けRAIDという構想について書いたことがあります。単一のシステムに依存するのではなく、複数のレイヤーにまたがる冗長性を実現するのが目的です。IPFSをさらに実験的に活用し、そのレイヤーの一つとして組み込んでいきたいと考えています。

ブラウザのサポートは改善されず、むしろ悪化した

2022年当時、Braveを除く主要ブラウザはENSやIPFSをネイティブでサポートしていませんでした。BraveにはIPFSノードが組み込まれており、ipfs://やipns://アドレスを直接解決することができました。

2024年8月、Braveはこの統合機能を削除しました。利用したことのあるユーザーが0.1%未満しかおらず、サポートコストが高すぎたためです。

Chrome・Firefox・SafariはいまだにENSやIPFSをネイティブでサポートしていません。FirefoxへのIPFSサポート追加に関する課題は2017年から未解決のままで、実装の計画もありません。IPFSコミュニティはブラウザ標準化の推進を続けていますが、ネイティブプロトコルサポートの実現はまだ遠い道のりのようです。

現在、.ethサイトを訪問する最も簡単な方法は、eth.limoのようなゲートウェイ経由です。ENS名に.limoを付加すれば、どのブラウザでもアクセスできます。機能はしますが、分散型システムへの中央集権的なブリッジであり、やや皮肉な状況です。

ガス料金が99%低下

全てが悪化したわけではありません。最初の投稿で、ENSレコードの更新コストが大きな障壁だと指摘しました。IPFS上のコンテンツが変更されると、そのハッシュも変わります。dries.ethを常に最新バージョンに向け続けるには、新しいアドレスをイーサリアムに書き込む必要があり、そこにガス代がかかります。

イーサリアム上でのコンテンツ更新にかかった費用は、2022年には11.69ドル、2024年には4.08ドルでした。今日同じ作業をすると、約1セントで済みます。

現在のイーサリアム平均ガス料金は0.03〜0.05グウェイ程度ですが、私が最初に設定した当時は30〜50グウェイでした。およそ1,000分の1の安さです。

この背景には二つの要因があります。

第一に、イーサリアムは2025年にかけてブロック単位で処理できる計算量を約2倍に拡大しました。バリデーターが段階的にガスリミットを引き上げ、12月のFusakaアップグレードで正式に3,000万から6,000万へと引き上げられました。

第二に、多くのアプリケーションがレイヤー2ネットワークへと移行しました。これらは別個のブロックチェーンで、トランザクションをまとめて処理してからイーサリアムに一括清算します。メインチェーンからトラフィックが分散したことで、混雑と手数料がさらに低下しました。

ENSへの影響は劇的です。今月、ENS Labsは「Namechain」と呼ばれる計画中のレイヤー2ブロックチェーンを中止しました。イーサリアムのメインネットワークのコストが大幅に低下し、レイヤー2が不要になったためです。ENS共同創設者兼リード開発者のニック・ジョンソン氏は、現在のガス料金でENS取引の100%を補助した場合、年間約1万ドルのコストになると指摘しています。