IPFS Shipyardが2026年9月30日に活動終了へ ― KuboもHeliaもメンテナー不在に、分散ウェブは誰が支えるのか

2026年9月30日、IPFSの主要実装を2年以上にわたって保守してきたエンジニアリング集団「IPFS Shipyard（Interplanetary Shipyard）」が、すべてのIPFS業務を停止します。

このニュースはHacker Newsで271ポイントを記録し、Web3・分散ストレージ界隈に大きな衝撃を与えました。Kubo、Helia、Boxo、Rainbow……分散ウェブを支えてきた主要ツール群が、一夜にして専任メンテナー不在になる可能性があるのです。

そして今回の件が突きつける本質的な問いは、技術的な問題にとどまりません。「分散型」を標榜するプロトコルが、資金面では長年にわたり一社に依存し続けていた——この矛盾を、私たちはどう受け止めるべきでしょうか。

この記事では次の3点を解説します。

①何が起きたのか（Shipyard終了の経緯と背景）
②何に影響するのか（プロジェクト・インフラへの具体的な影響）
③開発者が今すべきこと（実践的な移行チェックリスト）

【結論先出し】IPFS Shipyard終了で何が変わるのか

3行でわかる要点

Protocol Labsが資金更新を拒否 → Shipyardは2026年9月30日にIPFS業務を終了
Kubo・Helia・Boxo・Rainbowなど主要実装が専任メンテナー不在に
ipfs.io・dweb.linkなどの無料公開ゲートウェイも停止予定

「IPFSは終わるのか？」への回答

結論から言えば、IPFSというプロトコル仕様そのものは消えません。ホワイトペーパーも、CID（Content Identifier）の仕様も、誰かが「廃止」を宣言できる類のものではないからです。

消えるのは「専任で保守する人と、その活動を支える資金」です。この区別は非常に重要です。プロトコルが存在し続けても、バグが修正されず、セキュリティパッチが当たらず、新しいOSやランタイムに対応されなければ、実用的には「終わった」も同然になりえます。

そもそもIPFS Shipyardとは何だったのか

元Protocol Labs職員が2024年に設立した独立エンジニアリング集団

IPFS Shipyard（正式名称：Interplanetary Shipyard）は、2024年に元Protocol Labs職員たちが設立した独立エンジニアリング組織です。設立の経緯はProtocol Labsの組織再編にあり、IPFSコアの実装・保守を引き継ぐ形で分離独立しました。

組織としては独立していましたが、資金調達の実態はProtocol Labsへの依存がほぼ全面的でした。この「独立した組織」と「資金的な独立」が別物であるという点が、今回の問題の核心です。

Protocol LabsとShipyardの資金関係

Protocol LabsはIPFS・Filecoinなどの分散ウェブ技術を開発・推進する企業です。2021年のIPO（Filecoin）以降、暗号資産市場の変動とともに投資戦略を大きく変化させてきました。

Shipyardはこのような背景の中で設立され、Protocol Labsからの資金提供によってKuboやHeliaの保守を担ってきました。しかし今回、Protocol Labsが資金契約の更新を行わないと決定したことで、Shipyardはビジネスの継続が不可能になったと判断し、IPFSに関するすべての業務を終了することを発表しました。

前提知識：IPFSと分散ウェブの基本

IPFSは「InterPlanetary File System」の略で、ファイルをその**内容のハッシュ値（CID）**で指定する「コンテンツアドレッシング」方式のP2Pファイルシステムです。

通常のHTTPが「このサーバーのこのURLにあるファイル」という「場所ベース」の指定をするのに対し、IPFSでは「このハッシュ値を持つコンテンツ」という指定をします。これにより、サーバーがダウンしても別のノードから同じファイルを取得できる、改ざん検知が容易になるなどのメリットがあります。NFTのメタデータ保存先や、検閲耐性を求めるウェブサイトなどで広く採用されてきました。

影響を受ける主要プロジェクト一覧

Kubo ― 最も広く使われるGo実装

KuboはGoで実装されたIPFSノードのデファクトスタンダードです。IPFSを「動かす」ためのメインの実装として、世界中のサーバーやゲートウェイで利用されており、影響範囲は最大級です。Kuboのメンテナーが不在になるということは、IPFSエコシステム全体のインフラの土台が揺らぐことを意味します。

Helia ― JavaScript実装とブラウザ側の未来

HeliaはJavaScriptで実装されたIPFSライブラリで、ブラウザ上やNode.js環境での動作を主眼に設計されています。Webアプリからネイティブにコンテンツアドレッシングを扱うための中核的な存在であり、@helia/verified-fetchはShipyard自身が今後の推奨移行経路として位置づけていた重要なAPIです。

Boxo / Rainbow ― モジュール群と高性能ゲートウェイ

BoxoはKuboを構成するGoモジュール群です。IPFS関連ツールを自作・カスタマイズするエンジニアが依存しているライブラリで、これもメンテナンスが止まります。Rainbowは高性能なセルフホスト型IPFSゲートウェイ実装で、自社でIPFSゲートウェイを運用したい企業が採用してきたソフトウェアです。

IPFS Desktop / Companion ― エンドユーザー向けクライアント

IPFS DesktopはGUIでIPFSノードを操作できるデスクトップアプリ、IPFS Companionはブラウザ拡張機能です。これらは一般ユーザーがIPFSに触れる最初の入口であり、これらが更新停止になることはエコシステムへの新規参入者の減少を意味します。

プロジェクト別・影響度と代替策マトリクス

プロジェクト	役割	影響度	当面の対応
Kubo	Go実装ノード	高	セルフホスト継続／コミュニティfork監視
Helia	JS実装	高	`@helia/verified-fetch`へ移行
Boxo	Goモジュール群	中	バージョン固定して様子見
Rainbow	高性能ゲートウェイ	中	セルフホストで継続運用可能
Desktop/Companion	エンドユーザークライアント	中	更新停止前提で運用

公開インフラの停止 ― スポンサードゲートウェイの終焉

停止対象となるエンドポイント

Shipyardが管理・運用してきた公開インフラのうち、停止対象として挙げられているのは以下です。

ipfs.io — IPFSの「公式顔」とも言えるゲートウェイ
dweb.link — 広く使われてきたパブリックゲートウェイ
delegated-ipfs.dev — ルーティング委譲サービス
ブートストラップノード — P2Pネットワークへの参加に必要なエントリーポイント

これらの今後の扱いはProtocol Labsが決定するとされていますが、現時点では具体的な方針は示されていません。

なぜ「無料ゲートウェイ」が重要だったのか

IPFSはP2Pプロトコルですが、通常のWebブラウザはIPFSネイティブにコンテンツを取得できません。そのため、HTTP経由でIPFSのコンテンツを提供する「ゲートウェイ」が事実上の入口として機能してきました。

https://ipfs.io/ipfs/Qm... というURLを見たことがある方も多いでしょう。これがHTTP-to-IPFSゲートウェイの典型例です。これが廃止されると、NFTのメタデータURL、分散型サイトのリンク、あらゆる「ipfs.ioを前提にしたコンテンツ」がアクセス不能になるリスクがあります。

逆説的ですが、「分散型」IPFSのコンテンツへのアクセスが、実際には少数の中央集権的なゲートウェイに依存していたという構造的な問題も、今回の件で可視化されました。

ブラウザユーザーは `inbrowser.link` へリダイレクトされる

Shipyardの発表によれば、既存のゲートウェイURLへのアクセスはinbrowser.linkへリダイレクトされる見込みです。inbrowser.linkはサービスワーカーを用いたブラウザ内蔵型ゲートウェイで、実際のコンテンツ取得がクライアントサイドで行われます。既存のHTTP前提のリンクが多数存在する中でのリダイレクト対応は、UX上の摩擦を生む可能性があります。

既存アプリの「壊れ方」を予測する

最も深刻なリスクは、ハードコードされたipfs.ioやdweb.linkのURLを持つコンテンツです。特にNFTのメタデータJSONに記録されたゲートウェイURLは、ブロックチェーン上に刻まれているため書き換えが困難です。自社のサービスやコードベースにipfs.ioなどのURLが直書きされていないか、今すぐ確認することを強く推奨します。

Protocol Labsの立場 ― 「軽量な監視体制」への移行

Molly Mackinlay氏の表明内容

Protocol LabsのIPFS技術リードであるMolly Mackinlay氏は、今後のIPFSガバナンスについて「IPFS Foundationを通じた個別メンテナーへの助成金モデルへの移行」を表明しています。この体制を氏は"lighter-weight stewardship"（軽量な監視体制）と表現しています。

専任チームによる集中的な保守から、コミュニティ主導の分散した保守体制へ——言葉の上では理念的ですが、問題は「誰が、いつから、どのコンポーネントを担当するか」が現時点で具体的に決まっていないことです。

懸念点：後継メンテナーが未定という空白

IPFS Forumsでは「9月30日以降、Kuboのバグ修正は誰がやるのか」「セキュリティ脆弱性が発見されたときの対応フローは？」といった実務者の不安が多数投稿されています。助成金モデルの構築には時間がかかります。移行期の空白をどう埋めるか、現在のところ明確な答えは出ていません。

「助成金モデル」は機能するのか

OSSの資金調達モデルには、助成金・財団型・企業コンソーシアム型・デュアルライセンス型など様々なアプローチがあります。Rustの場合はMozilla財団から始まり現在はRust Foundationが担い、Linuxカーネルは大手企業が費用を出し合うLinux Foundationモデルで成功しています。これらと比較したとき、「後継メンテナーが未定のまま助成金モデルに移行する」という現状には、相応のリスクがあると言わざるを得ません。

開発者が今すぐ取るべき移行策【実践編】

ケース1｜ブラウザ／フロントエンドから利用している場合

JavaScriptやTypeScriptでIPFSコンテンツにアクセスしているWebアプリ開発者には、@helia/verified-fetchへの移行が推奨されています。

npm install @helia/verified-fetch

@helia/verified-fetchはブラウザネイティブのFetch APIに近いインターフェースでIPFSコンテンツを取得でき、かつ**コンテンツのCIDによる検証（verified fetch）**を行うため、改ざんされたコンテンツを掴まされるリスクが低減されます。Shipyardが管理するゲートウェイへの依存をなくしつつ、セキュリティモデルを向上させられる点で、最も積極的な移行先です。

ケース2｜サーバーサイドで運用している場合

バックエンドやインフラ側でIPFSを利用している場合は、Rainbow または Kubo によるセルフホスト型ゲートウェイの構築が選択肢です。

パブリックゲートウェイへの依存をなくし、自社インフラで制御できる点は大きなメリットですが、運用コスト・監視体制・セキュリティパッチ適用の責任が自社に移ることを忘れてはいけません。「メンテナー不在のソフトウェアを自社でセルフホストする」という判断には、それ相応の覚悟が必要です。

ケース3｜運用負荷を避けたい場合

インフラ管理の工数を割けない場合、Pinata・Filebaseなどの有料ピンニングサービスの利用が現実的な選択肢です。重要なのは、これらのサービスはShipyardに依存しておらず、2026年9月30日以降も継続する点です。コスト面での検討は必要ですが、安定性の観点では最も確実な選択肢と言えます。

移行チェックリスト（コピペ可）

- [ ] ハードコードされたゲートウェイURL（ipfs.io、dweb.link等）の洗い出し
- [ ] 依存ライブラリのバージョン固定（9/30以降に意図しない更新が入らないよう）
- [ ] ブートストラップノード設定の見直し
- [ ] ピンニング先の冗長化（単一ゲートウェイへの依存排除）
- [ ] NFTメタデータ等に含まれる旧ゲートウェイURLの棚卸し
- [ ] 監視・アラートの追加（ゲートウェイ死活監視）
- [ ] @helia/verified-fetch または セルフホスト移行の技術評価

コミュニティの動き ― 空白を埋めるのは誰か

atprotoコミュニティ発の小規模実装が台頭

Blueskyが採用する分散SNSプロトコル「atproto」コミュニティから生まれたatcuteやlibipldといった小規模実装が、Shipyard空白後の代替として注目を集めています。これらはKuboのような大規模な実装ではなく、特定のユースケースに特化した軽量ライブラリですが、「大きな単一実装よりも、小さく分散した複数の実装群」という方向性を示しています。

「小さく分散した実装」への揺り戻し

皮肉なことに、「分散型」を設計思想とするIPFSエコシステムが、大規模な単一実装（Kubo）と単一スポンサー（Protocol Labs）に依存していたことが今回の件で露呈しました。今後、軽量な複数実装が競い合う形への揺り戻しが起きるとすれば、それはIPFSにとって長期的に健全な方向性かもしれません。ただし、その移行期には相応の混乱が伴うことも覚悟が必要です。

フォークとコミュニティ主導保守の現実的なハードル

「KuboをコミュニティでForkして維持しよう」という声は自然に出てきます。しかし、Kuboのようなコードベースを継続的に保守するには、相当数のフルタイムエンジニアが必要です。ボランティアベースのコントリビューションでは、セキュリティパッチの迅速な適用やバグ修正が難しい場面が出てきます。「Forkは簡単、維持は難しい」という現実を直視する必要があります。

本質的な論点 ― オープンソース持続性と「単一スポンサー依存」

分散型を標榜しながら、資金は中央集権的だった矛盾

今回の件が技術者に突きつけた最大の教訓は、「プロトコルの分散性と、その実装・インフラを維持するための資金の集中は、まったく別の問題である」ということです。

IPFSのP2Pアーキテクチャ上、どのノードも特権を持ちません。しかし現実には、そのノードを実装するソフトウェアの開発・保守費用は、10年以上にわたって実質的にProtocol Labsという一社に依存してきました。技術的な分散と、経済的な分散は、意識的に設計しなければ同時には実現しないのです。

資金が止まれば専任チームが消える構造の危うさ

オープンソースソフトウェアは「無料で使える」というイメージがありますが、その維持には多大な労力と資金が必要です。「使われているOSS」と「支えられているOSS」の間には大きなギャップがあります。IPFSは世界中で使われていましたが、その開発コストを負担していたのは一社だけでした。

他のOSSプロジェクトへの教訓

今回のIPFS/Shipyard問題は、OSSに依存するすべての開発者・企業への警告です。自社が本番環境で依存しているOSSについて、「資金の出どころはどこか」「単一スポンサーへの依存度は高くないか」「スポンサーが撤退した場合にコミュニティは自立できるか」を確認することは、技術的なリスク管理の一部として認識すべきです。

利用企業側の責任 ― タダ乗りをやめるという選択

OSSの持続性を担保するためには、利用者側の積極的な関与が不可欠です。具体的にはスポンサーシップ（OpenCollective等を通じた資金提供）、コントリビュート（コードレビュー、バグ修正、ドキュメント整備）、雇用（OSSメンテナーを社員として雇い、OSS活動を業務として認める）といった方法があります。「使うだけで、支えない」という姿勢がエコシステムを脆弱にするという認識が、業界全体で広まることが求められています。

よくある質問（FAQ）

Q. IPFSはなくなるのですか？

A. なくなりません。IPFSというプロトコル仕様は誰かが廃止できるものではなく、残り続けます。停止するのは主要実装（Kubo、Heliaなど）の専任メンテナーによる保守と、公開インフラ（ipfs.io等）の運用です。

Q. IPFSに保存した自分のデータは消えますか？

A. PinataやFilebaseなどのピンニングサービスに固定されているデータは、それらのサービスがShipyard依存ではないため継続して保存されます。ただし、自前のノードだけにピンしているデータや、ipfs.ioのような公開ゲートウェイ経由でのみアクセスしていたデータについては、アクセス経路の見直しが必要です。

Q. Filecoinは影響を受けますか？

A. FilecoinはIPFSとは独立したプロジェクトですが、同じProtocol Labsエコシステムに属しており、関連性は高いです。現時点ではFilecoinへの直接的な影響は発表されていませんが、Protocol Labsの戦略変更という文脈で動向を注視することをお勧めします。

Q. 2026年10月1日に突然すべてが止まるのですか？

A. 9月30日が「業務終了日」ですが、物理的なサービス停止は段階的に進むと見られます。ゲートウェイのリダイレクト設定、リポジトリのアーカイブ化、ドメインの管理移管など、技術的な切り替えには時間がかかります。ただし、セキュリティパッチや新機能の開発という意味での「メンテナンス」は10月以降実質的に止まると考えて行動することが賢明です。

Q. 今からIPFSを新規採用するのは危険ですか？

A. ユースケースによります。実験・学習目的であれば引き続き有意義です。本番環境での長期運用を前提とする場合は、代替手段（有料ピンニングサービスとの組み合わせ、セルフホスト前提の設計）を事前に検討することを強く推奨します。データの長期保存を目的とする場合は、Filecoin等の経済的インセンティブを持つストレージプロトコルとの組み合わせを検討してください。

まとめ ― 分散ウェブは「誰かが金を払う」上に成り立っていた

この記事の要点を振り返ります。

Shipyard終了はIPFSの死ではない — プロトコル仕様は残る。消えるのは専任メンテナーと公開インフラ
影響範囲は広い — Kubo、Helia、Boxo、Rainbow、ipfs.io、dweb.linkなど主要ツール・インフラのすべてが対象
開発者は今すぐ動く必要がある — ゲートウェイURLのハードコード洗い出し、ピンニング先の確認、@helia/verified-fetchへの移行検討
後継メンテナーは未定 — IPFS Foundationを通じた助成金モデルへの移行が表明されたが、10月以降の具体的な体制は不透明
「分散型」の矛盾が露呈した — 技術的分散と経済的分散は別問題であり、意識的に両立を設計しなければならない

Shipyard終了は「IPFSの死」ではありません。しかし、「IPFSエコシステムが単一スポンサーに依存していたという構造的な脆弱性の露呈」であることは間違いありません。

今あなたのコードベースにipfs.ioのURLは何件ありますか？依存しているIPFSライブラリのメンテナンス状況を最後に確認したのはいつですか？この記事をきっかけに、自社のIPFS依存箇所の棚卸しと、移行計画の着手を始めることを強くお勧めします。

2026年9月30日以降の動向は、IPFS Forums および blog.ipfs.tech で継続的に情報が更新される予定です。ブックマークしておくことをお勧めします。