公開2025.09.02更新2026.11.03 ブロックチェーン

IPFSとブロックチェーンの違い｜仕組み・暗号化・問題点とCIDの記録方法【2026年11月】

Q: IPFSとFilecoinはどう違いますか？

IPFSの公式FAQ は両者を別々の補完的なプロトコルと位置づけ、「IPFS addresses and moves content, while Filecoin is an incentive layer to persist data」と説明しています。IPFSがアドレス付けと転送を担い、Filecoinは保存を続けた者に報酬を払う経済の層です。保存をお金で担保したいときに、Filecoinや有償のピン留めサービスを組み合わせます。

IPFSとブロックチェーンの違い｜仕組み・暗号化・問題点とCIDの記録方法【2026年11月】

IPFS（InterPlanetary File System）とブロックチェーンは並べて語られますが、担当する仕事は別物です。IPFSはデータそのものを預けて取り出すための分散ファイルシステム、ブロックチェーンは「誰が何をいつ記録したか」を第三者が検証できる形で残す台帳です。この記事では両者の違いを8項目で比べ、検索の多い「IPFSは暗号化されるのか」「問題点は何か」に公式ドキュメントの記述で答えます。後半では、CIDをEthereumのコントラクトに記録するコードとFoundryで測ったガス代、2026年8〜10月に起きた公開ゲートウェイと保守体制の変化を踏まえた採用判断までを扱います。

まとめ：IPFSは保管と配布、ブロックチェーンは記録の合意を担う別の技術

IPFSはデータの保管と配布、ブロックチェーンは記録の合意形成を担います。競合する技術ではなく、NFTのように実データをIPFSへ、そのCIDだけをチェーンへ置く分担が標準的な構成です。
IPFSに置いたファイルは暗号化されません。暗号化されるのは通信経路だけで、CIDを知っている相手は誰でも中身を取得できます。
IPFSは「見つかること」を保証しても「残ること」は保証しません。ピン留めやMFSによる保持の対象になっていないデータは、各ノードでガベージコレクションが実行されると削除される可能性があります。
CIDをEthereumに記録するトランザクションのガスは、32バイトのbytes32で持つと46,154、46文字の文字列で持つと92,991でした（Foundry 1.8.4で測定・基本料込み）。文字列保存は約2倍かかります。
ipfs.ioとdweb.linkは2026年9月21日にHTTPでの代理取得を終え、ブラウザ以外からの取得にはHTTP 429を返します（11月3日に確認）。Kuboを保守してきたShipyardは9月30日でIPFS関連の業務を終えました。公開ゲートウェイと特定実装に頼る構成は作り直す時期です。

IPFSとブロックチェーンの違いを8項目で比較：役割・保存先・コスト・永続性

両者は分散構成やハッシュによる検証を使いますが、データ配布と記録の合意形成という主な役割が異なります。Ethereumではフルノードごとに全取引を検証して現在の状態を持つため、ノードが増えるほど同じデータの複製が増えます。IPFSはそのデータを欲しいノードだけがブロックを持てばよく、大容量データの配布に向きます。

比較軸	IPFS	ブロックチェーン（Ethereum等）
主な役割	データの保管・配布	取引と状態変化の記録・合意
格納するもの	ファイル本体（画像・動画・JSON）	CIDなどの参照とロジック
アドレスの決まり方	中身のハッシュ（CID）	アカウント・コントラクトのアドレス
ノード間の複製	取得したノードだけ	フルノードごとに現在の状態を保持
書き込みコスト	サーバー費・ピン留め料金	ガス代（32バイトの新規保存で22,100）
改ざん検知	受け取った中身とCIDの照合	ブロックのハッシュ連鎖と合意
永続性	保証なし（ピン留め次第）	現在の状態はフルノードが保持
中身の更新	CIDが変わる（名前はIPNS・DNSLink）	トランザクションで状態を書き換え

実務での使い分けは「格納するもの」と「永続性」の2行でほぼ決まります。

保存対象の分担：IPFSの実データとチェーン上のCID

Ethereumのストレージは1スロット32バイトで、値がゼロのスロットへ新しく書き込むと20,000ガス（EIP-2200のSSTORE_SET_GAS）に、EIP-2929のコールドアクセス分2,100ガスが加わります。32バイト1個で22,100ガスです。数MBの画像をそのまま載せる設計が成り立たないのは、この単価からわかります。チェーン側の手数料を構造から下げる方法はブロックチェーンのレイヤー2とは？ロールアップの仕組みと手数料の内訳・成熟度の見分け方【2026年版】で扱っていますが、それでも大容量データを載せる選択肢にはなりません。

そこで実データはIPFSへ置き、返ってきたCIDだけをコントラクトに記録します。何をチェーンに残し何を外に逃がすかという設計の考え方は、オンチェーンとは？オフチェーンとの違い、手数料と確定までの時間をノードの取得値で解説で整理しています。

永続性の非対称性：確定したブロックと、GCで消えうるIPFSのファイル

ブロックチェーンでは、コントラクトに書いた現在の値をすべてのフルノードが持ち続けます（過去の時点の値まで引くにはアーカイブノードが要ります）。IPFSでは、誰かが持ち続けない限りデータは残りません。公式ドキュメントの永続性の解説は「IPFS guarantees that any content on the network is discoverable, it doesn’t guarantee that any content is persistently available」と書いています。見つけられることと、残っていることは別です。

Kubo v0.43.1の設定リファレンスでは、ガベージコレクションの周期Datastore.GCPeriodの既定が1時間、容量の目安Datastore.StorageMaxの既定が10GBです。ただし自動のガベージコレクションはデーモンを--enable-gc付きで起動したときだけ動き、付けなければipfs repo gcを手で実行したときに回収されます。どちらでも捨てられるのはピン留めしていないブロックで、自分のノードだけがそのファイルを持っていた場合、CIDは正しいままデータだけが取得できなくなります。

IPFSとは：CIDで中身を指す分散ファイルシステムの仕組み

IPFSは、Protocol Labsが開発したピアツーピアのデータ転送プロトコルです。HTTPが「どのサーバーの、どのパスか」で場所を指すのに対し、IPFSは「このハッシュ値を持つデータ」と中身で指します。同じ内容のファイルは、同じ設定で追加する限り、誰がどこから追加しても同じCIDになります。IPFS公式ブログの2026年8月25日の告知によれば、ネットワークが処理するリクエストは1日あたり約2億5,000万件です。

CIDの構造：v0とv1の違い、QmとbafyのCIDを見分ける受け取り側の実装

CIDの公式解説とmultiformatsの仕様によると、CIDはマルチハッシュ（ハッシュ値とアルゴリズムの識別子）、マルチコーデック（データの解釈方法）、マルチベース（文字列の符号化方式）の組み合わせです。CIDv0はbase58で「Qm」から始まる46文字、CIDv1は既定でbase32を使い「bafy」などで始まります。CIDv0の中身はマルチハッシュの接頭辞2バイト（0x12＝SHA-256、0x20＝32バイト長）と32バイトのダイジェストで、この性質を後半のコードで使います。

Kubo v0.43.1でもImport.CidVersionの既定は0で、ipfs addはv0を返します。一方、KuboのREADMEの例はipfs init --profile=unixfs-v1-2025で初期化しており、この場合はv1が返ります。同じブロックを指すCIDv0とCIDv1は、CIDv1へ正規化して比較できます。ただし、追加時のraw-leavesやチャンクサイズなどが異なると、同じファイルでもブロック構造が変わるため、CIDの版をそろえるだけでは一致しません。

DHTでの発見と再広告：CIDが正しいのにデータが届かない理由と対処

CIDからデータを引くには、そのブロックを持つノードを分散ハッシュテーブル（DHT）で探します。提供側のノードは、自分が持つCIDを定期的に広告し直さなければなりません。Kubo v0.43.1のProvide.DHT.Intervalの既定は22時間で、DHT上のプロバイダレコードが48時間で失効するため、その半分弱の間隔で更新する設計です。この再広告が止まると、ノードが動いていてもDHT経由では見つからなくなります。再広告の停止は「CIDは正しいのに取得できない」原因の一つで、v0.42で加わったipfs provide onceを使えば次の周期を待たずに指定のCIDを広告できます。

IPNSとDNSLink：中身を更新しても同じ名前で指す方法

CIDは中身から決まるので、ファイルを1文字直すと別のCIDになります。更新し続けるものを固定のアドレスで指すのが、IPNSとDNSLinkです。IPNSの公式解説によると、IPNS名は公開鍵から作るCIDで、レコードには指し先のパスと秘密鍵による署名が入ります。秘密鍵の持ち主だけが指し先を差し替えられ、受け取った側は署名で正当性を確かめられます。

# 鍵を作り、その鍵のIPNS名でCIDを公開する
ipfs key gen site-key
ipfs name publish --key=site-key /ipfs/<CID>
# IPNS名から現在のCIDを引く
ipfs name resolve <IPNS名>

DHT上のレコードは最後の公開から48時間で失効するため、KuboはIpns.RepublishPeriod（既定4時間）ごとに公開し直します。ノードを止めて再公開が途切れると、48時間後にはDHTから引けなくなります。ただし、有効なキャッシュや別の配信経路があれば解決できる場合があります。DNSLinkは、DNSの_dnslinkサブドメインのTXTレコードにdnslink=/ipfs/<CID>を書く方式です。2026年11月3日にdig +short TXT _dnslink.docs.ipfs.techを実行すると、公式ドキュメント自身がdnslink=/ipfs/bafybeier6ud42ptljtfaxrdlknktw54b7ohfpg5h33mosxpxjndxs7xzvmを返しました。

ブロックチェーンとの関係で押さえたいのは、IPNS名やDNSLinkは「書き換えられる参照」だという点です。NFTのメタデータのように改ざんされないことに価値があるデータは、チェーンにCIDそのものを書きます。IPNS名を書くと、鍵の持ち主が後から中身を差し替えられ、チェーンに記録する意味が薄れます。

IPFSは暗号化されるのか：通信経路だけが暗号化され中身は公開される仕様

結論から書くと、IPFSはファイルの中身を暗号化しません。公式ドキュメントのプライバシーと暗号化の解説は、暗号化をtransport-encryption（通信経路）とcontent-encryption（中身）に分け、IPFSが標準で行うのは前者だけだと説明しています。続く文は「All traffic on IPFS is public, including the contents of files themselves, unless they’re encrypted」です。CIDを知っている相手は誰でも中身を取得できます。

DHTにはノードの識別子（PeerID）と提供中のCIDも広告されるので、「誰がどのデータを持っているか」はネットワークから観測できます。プライベートネットワーク機能で参加ノードを限ることはできますが、鍵を共有した全ノードが中身を読める点は同じです。CIDはハッシュ値であって暗号文ではありません。この区別はハッシュ化とは？暗号化との違いとパスワード保管・改ざん検知の仕組みを解説で扱った性質そのもので、ハッシュは中身の同一性を確かめる道具であり、隠す道具ではありません。

公開前にクライアント側で暗号化する手順と、復号鍵をどこにも載せない設計

機密データを扱うなら、IPFSへ追加する前に手元で暗号化し、暗号文だけを追加します。復号鍵はチェーンにもIPFSにも載せません。GnuPGのマニュアルにある共通鍵暗号を使うと、最小の手順は次のとおりです。

# 手元で共通鍵暗号化（パスフレーズはIPFSにもチェーンにも載せない）
gpg --symmetric --cipher-algo AES256 contract.pdf
# 生成された contract.pdf.gpg だけをIPFSへ追加する
ipfs add contract.pdf.gpg
# 取得側は同じパスフレーズで復号する
ipfs cat <CID> > contract.pdf.gpg
gpg --output contract.pdf --decrypt contract.pdf.gpg

この構成でも暗号文は公開され続けます。将来の鍵の漏えいや暗号の危殆化には備えられないため、長く保存する個人情報や契約書は、そもそもIPFSに置かない判断のほうが安全です。

IPFSの問題点：ピン留め運用・公開ゲートウェイ・保守体制・悪用・削除不能

IPFSの採用時には、データ保持、取得経路、保守の責任分担と、公開後の削除を保証できない制約を確認します。2026年は、これに公開ゲートウェイの縮小と保守体制の変化が加わりました。

ピン留めの運用：誰が保持し続けるのかを決めていない構成の可用性

ピン留め（ipfs pin add）は、そのノードでガベージコレクションの対象から外す指定であり、ネットワーク全体への保存命令ではありません。自社ノード1台だけがピン留めしている状態は、可用性ではサーバー1台の構成と変わりません。冗長化するには、ピン留めサービスを併用するか、複数の拠点に自前のノードを立てて同じCIDをピン留めします。2026年11月3日時点の無料枠は、Pinataが保存1GB・帯域10GB、Filebaseが保存5GB・ピン留め500ファイル・IPFSの転送10GBです。ピン留めサービス自体が終わることもあり、web3.storageの後継のStorachaは2026年4月15日にアップロードを止め、5月31日にw3s.linkでの配信を終えると告知しました。1社だけに預けず、手元にも同じデータを残しておきます。保存を経済的に担保する層としては、別プロトコルのFilecoinがあります。

公開ゲートウェイの縮小：cloudflare-ipfs.com停止と2026年のipfs.io転送変更

多くの実装はhttps://ipfs.io/ipfs/<CID>のようなHTTPゲートウェイのURLを埋め込んできましたが、この依存が単一障害点になります。Cloudflareの告知どおり、cloudflare-ipfs.comとcf-ipfs.comは2024年8月14日に接続を終え、このURLを焼き込んでいた実装は参照切れを起こしました。

残ったipfs.ioとdweb.linkも、2026年に役割が変わりました。8月25日の告知で直リンクとバックエンドからの取得にレート制限が入り、移行案内のページによれば、9月1日から1時間ごとに少しずつ止める時間を延ばし、9月21日（UTC）にHTTPでの代理取得を終えました。10月14日の発表では、ブラウザからのゲートウェイ利用はすべてService Worker方式のinbrowser.linkへ転送され、取得と検証が利用者のブラウザ内で行われています。

11月3日にcurl -sS -i https://ipfs.io/ipfs/<CID>/を実行すると、HTTP 429とretry-after: 900、2026年9月21日を示すsunsetヘッダーが返り、本文は「This IPFS gateway is switching to a service worker gateway only.」でした。<img src>やサーバーからこのURLを引いている実装は、もう中身を受け取れません。移行先は、アプリなら@helia/verified-fetch、バックエンドならRainbowやKuboで立てる自前のゲートウェイです。永続的に残す値はipfs://<CID>形式にとどめ、ゲートウェイのホスト名はアプリの設定値として差し替えられるようにしておきます。

保守体制の変化：Shipyardが2026年9月末でKuboと公開基盤から撤退

Shipyardの告知（2026年8月24日）によると、Protocol Labsが資金提供を更新しなかったため、ShipyardはIPFS関連の開発・保守・インフラ運用を2026年9月30日で終えました。運用をやめる対象にはipfs.io、dweb.link、IPFSのブートストラップノードなどが含まれ、今後はドメインを持つProtocol Labsが決めるとされました。IPFSプロジェクトは10月14日に、ブートストラップとService Worker Gatewayの基盤をIPNI／Compassのチームが、ネットワークの計測をProbeLabが、後述のBadBitsをSkapaが引き継ぐと発表しました。実装とライブラリの扱いは今後の発表に回されています。

2026年11月3日時点で、Kuboの最新リリースはv0.43.1（9月15日公開）で、GitHubのmasterブランチへの最後のコミットは9月27日です。プロトコルやCIDの仕様が使えなくなるわけではありませんが、Kuboを本番で動かすなら、次のセキュリティ修正を誰が出すのかを継続して確認する必要があります。新しく設計するなら、CIDだけを正本として持ち、取得経路は差し替えられる形にしておくのが無難です。

フィッシングへの悪用：攻撃事例とゲートウェイのdenylist対策

「消せない」性質は、攻撃者にとっても都合がよいものです。Cisco Talos（2022年11月9日）は、IPFSがフィッシングキットやマルウェアの配布に使われている複数の攻撃を報告しました。トレンドマイクロの分析では、同社が検出したIPFS上の脅威の90%以上がフィッシングで、2022年10月にはIPFSでホストされた固有のフィッシングページが23,000を超えていました。あるゲートウェイで削除されても、別のゲートウェイのURLから同じページに届く点が通常のWebサイトと違います。

ゲートウェイを運用する側は、Kuboのコンテンツブロック機能を使います。$IPFS_PATH/denylists/に*.denyファイルを配置してからデーモンを起動すると、IPIP-383形式のdenylistが適用されます。稼働中に新しいファイルを追加した場合は再起動が必要で、公式ビルドには既定で有効なdenylistは含まれていません。公開ゲートウェイ向けに通報済みのCIDを共有するBadBitsは、2026年10月31日更新の版で536,754件のハッシュ化された項目を持ち、10月以降はSkapaが運営を引き継いでいます。自社のコンテンツだけを配るゲートウェイなら、同ドキュメントが勧めるとおりGateway.NoFetch=trueで自分がホストするデータ以外を返さない設定のほうが確実です。

削除できない前提での設計：個人情報を誤って追加したときの不可逆性

自ノードのピン留めを外してガベージコレクションを走らせても、すでに他のノードが取得したブロックには手が届きません。誤って個人情報を含むファイルを追加し、CIDを公表していた場合、回収はできないと考えるべきです。追加前の内容チェックをレビュー工程に組み込み、公開してよいデータだけを扱う予防のほうに手間をかけます。

IPFSとEthereumの連携実装：KuboでのCID取得とコントラクトへの記録

ここまでの分担を最小のコードに落とします。流れは「IPFSへ追加してCIDを得る」「CIDをコントラクトに記録する」「取得時にCIDで照合する」の3段です。

Kuboの導入とファイル追加：CID取得からpin、provide onceまでの手順

Kuboを公式のインストール手順で入れ、ノードを初期化してファイルを追加します。ipfs addの出力がCIDです。

# ノードの初期化とデーモン起動（自動GCを使う場合は --enable-gc を付ける）
ipfs init
ipfs daemon --enable-gc &
# ファイルを追加してCIDを取得（値は内容ごとに変わる）
ipfs add sample.json
# added <CID> sample.json
# v1形式で追加する場合
ipfs add --cid-version=1 sample.json
# 取得とピン留めの明示（ipfs add は既定で追加したデータをピン留めする）
ipfs cat <CID>
ipfs pin add <CID>
# 次の再広告周期を待たずにDHTへ広告する（v0.42以降）
ipfs provide once <CID>

取得できるかを確かめるときは、自ノードのキャッシュに残っているだけの状態と区別するため、別のネットワークにあるIPFSノードから引きます。ipfs.ioとdweb.linkは確認先に使えないので、ブラウザで見るならinbrowser.linkを使います。

CIDv0とbytes32の相互変換：Pythonで接頭辞0x1220を外して戻す処理

コントラクトへ渡す前に、CIDv0からダイジェスト32バイトを取り出します。外部ライブラリを使わずに書くと次のとおりで、Python 3.9.6で実行し、戻した値が元のCIDと一致すること、先頭に1文字足した47文字の入力や31・33バイトのダイジェストを例外で弾くことを確かめました。

ALPHABET = '123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz'

def b58decode(s):
    n = 0
    for ch in s:
        n = n * 58 + ALPHABET.index(ch)
    return n.to_bytes(34, 'big')

def b58encode(b):
    n = int.from_bytes(b, 'big')
    out = ''
    while n:
        n, r = divmod(n, 58)
        out = ALPHABET[r] + out
    return out

def cidv0_to_bytes32(cid):
    if len(cid) != 46 or not cid.startswith('Qm'):
        raise ValueError('CIDv0は「Qm」で始まる46文字')
    raw = b58decode(cid)
    if raw[:2] != b'\x12\x20':
        raise ValueError('sha2-256のCIDv0ではない')
    return '0x' + raw[2:].hex()

def bytes32_to_cidv0(hex32):
    digest = bytes.fromhex(hex32.removeprefix('0x'))
    if len(digest) != 32:
        raise ValueError('ダイジェストは32バイト')
    return b58encode(b'\x12\x20' + digest)

cid = 'QmYwAPJzv5CZsnA625s3Xf2nemtYgPpHdWEz79ojWnPbdG'
digest = cidv0_to_bytes32(cid)
print(digest)
# 0x9d6c2be50f706953479ab9df2ce3edca90b68053c00b3004b7f0accbe1e8eedf
print(bytes32_to_cidv0(digest) == cid)
# True

Base58は先頭の「1」をゼロのバイトとして扱うため、長さを確かめないと不正な文字列が同じダイジェストに化けます。CIDv1やSHA-256以外のハッシュが来たときも、この関数は例外で止まります。誤った値を黙って書き込むより、登録前に止まるほうが後始末は楽です。

Solidityでの記録：bytes32とstringでガス使用量が約2倍異なる測定結果

CIDv0のダイジェスト32バイトをbytes32で受け取る比較用の実装です。登録権限の制御はなく、誰でも未登録のIDを先に登録できるため、本番では登録者の認証と権限制御が必要です。接頭辞0x1220は固定なので、表示するときに付け直せば元のCIDに戻せます。

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;

contract ContentRegistry {
    mapping(uint256 => bytes32) private digests;
    event Registered(uint256 indexed id, bytes32 digest);

    // CIDv0(sha2-256)前提。先頭2バイト(0x1220)を除いた32バイトだけを保存する
    function register(uint256 id, bytes32 digest) external {
        require(digest != bytes32(0), "empty digest");
        require(digests[id] == bytes32(0), "already registered");
        digests[id] = digest;
        emit Registered(id, digest);
    }

    function digestOf(uint256 id) external view returns (bytes32) {
        return digests[id];
    }
}

未登録の判定にゼロを使うので、ゼロのダイジェストは最初のrequireで拒否します。同じ処理をCID文字列（mapping(uint256 => string)、イベントの引数もstring）で持つ版と並べ、Foundry 1.8.4（solc 0.8.24、EVMはCancun、最適化なし）のforge test --gas-reportでregisterを1回ずつ呼んで測りました。

保存方式	使うスロット	registerのガス
bytes32（ダイジェストのみ）	1	46,154
string（46文字のCIDv0）	3（長さ1＋本体2）	92,991

比較に使ったのは上のContentRegistryと、mappingとイベントの型だけをstringに替えた版で、どちらもID=1と前節の例のCIDを渡しています。gas-reportは呼び出しを1件のトランザクションとして隔離して測るため、この値には基本料21,000ガスとcalldataの料金が含まれます。新規に書き込むスロットは3対1ですが、両方に同じ基本料が乗るので全体の比は約2倍になり、string版はイベントに載せるデータも長い分だけ高くなります。発行件数の多いNFTほど差が積み上がるので、CIDv0しか扱わないならbytes32を選びます。開発環境の準備からテストネットへのデプロイはSolidity入門｜開発環境の作り方・基本構文・Sepoliaデプロイ手順【2026年10月】、テストとガス計測の道具立てはHardhatとは？Hardhat 3の使い方：導入・テスト・デプロイとFoundryとの違い【2026年10月】にまとめています。

NFTのtokenURIがipfs://を指す理由と、HTTPのURLで指した場合の弱点

ERC-721のtokenURIがIPFSのURIを返す構成は、ここまでの分担をそのまま製品にしたものです。チェーン上にはトークンIDとメタデータのCIDだけを置き、メタデータのJSON（名前・説明・画像のCID）と画像本体はそれぞれ別のCIDでIPFSに置きます。取得側がメタデータと画像をそれぞれのCIDで検証すれば、同じCIDに対する内容の差し替えを検知できます。ただし、ERC-721はtokenURIの変更を許容するため、参照先を固定するにはコントラクト側でもURIの更新を制限する必要があります。メタデータをHTTPのURLで指しているNFTは、そのサーバーの管理者が中身を差し替えられます。発行から出品までの手順はNFTアートの作り方｜OpenSeaでの出品手順と手数料・税金、市場の現状【2026年版】で扱っています。

IPFSとブロックチェーンを併用するか、片方で済ませるかを決める判断手順

併用が前提のように語られますが、IPFSとチェーンのそれぞれが本当に要るかは別々に決めます。確かめる基準は次の3つです。

判断基準1：第三者検証の必要性と社内証跡の要件

社内の関係者しか見ない証跡なら、オブジェクトストレージにファイルを置き、照合元のハッシュ値を独立した権限で保護してRDBに記録すれば、ファイルの改ざんを検知できます。この信頼モデルで要件を満たすなら、ブロックチェーンは不要です。台帳とRDBの構造の違いはブロックチェーンとデータベースの違い｜RDB・台帳DBとの比較と選び方【2026年】、ある時刻にその文書が存在したことを第三者に示す方法はタイムスタンプとは？仕組み・電子署名との違いと電子帳簿保存法での要否を解説【2026年時点】で整理しています。契約書や証憑のハッシュ記録・版管理・閲覧権限を業務システムとして一体で組むなら、文書管理システム開発の範囲になります。

判断基準2：データの公開範囲と削除対応の要件

IPFSに追加したデータは公開が前提です。法令の要件に該当して消去等への対応が必要になる保有個人データや、非公開にすべきデータを公開IPFSへ置く構成は採用すべきではありません。一度取得されたブロックは相手のノードに残り、削除の求めに技術的に応えられないからです。暗号化して置いても、暗号文が残り続ける点は変わりません。

判断基準3：ノードとゲートウェイの運用責任者・期間

最後に、保持と配信の責任者を決めます。ピン留めは自前のノードか有償のピン留めサービスか、配信は自前のゲートウェイか@helia/verified-fetchによるクライアント側の取得か。2026年9月末のShipyard撤退で、公開基盤や特定実装の保守を前提にした設計は成り立ちにくくなりました。ここに答えが出ない案件は、IPFSを見送り、署名付きURLのオブジェクトストレージとハッシュ記録で組むほうが運用の見通しが立ちます。これらの条件を満たしたうえで、複数の提供元からの配布が必要か、署名やタイムスタンプでは足りずチェーン上の合意が必要かを比較して、併用を判断します。

よくある質問

IPFSとブロックチェーンは、どちらか一方だけでも使えますか？

使えます。IPFSは単独の分散ファイルシステムとして動き、ブロックチェーンを必要としません。ブロックチェーンも、数十バイト程度のデータならIPFSなしで完結します。併用を検討するのは、IPFSによるファイル配布に加え、所有権や登録履歴についてチェーン上の合意が必要な場合です。中身とCIDの一致を第三者が検証するだけなら、IPFS単独でもできます。

IPFSとFilecoinはどう違いますか？

IPFSの公式FAQは両者を別々の補完的なプロトコルと位置づけ、「IPFS addresses and moves content, while Filecoin is an incentive layer to persist data」と説明しています。IPFSがアドレス付けと転送を担い、Filecoinは保存を続けた者に報酬を払う経済の層です。保存をお金で担保したいときに、Filecoinや有償のピン留めサービスを組み合わせます。

ipfs.ioのURLはこれからも使えますか？

ブラウザで開く用途なら、inbrowser.linkへ転送されて表示されます。アプリの直リンクやサーバーからの取得はHTTP 429で断られるため、保存する値はipfs://<CID>にし、取得は自前のノードか@helia/verified-fetchで行ってください。

IPFSの利用は無料ですか？

ソフトウェアはオープンソースで無料です。費用が出るのは可用性を確保する部分で、自前のノードならサーバー費用、ピン留めサービスなら無料枠（数GB）を超えた保存容量と転送量に料金がかかります。ipfs.ioとdweb.linkがHTTPでの代理取得をやめたため、サーバーから利用する場合は自前のゲートウェイや有償の取得サービスの費用も見込みます。「無料で永久に保存される仕組み」ではありません。

IPFSはHTTPを置き換える技術ですか？

置き換えを目指す文脈で語られることはありますが、実際の使われ方は補完です。主要なブラウザはIPFSを直接扱えず、ネイティブ対応していたBraveも2024年8月22日のv1.69.153で対応をやめました（利用者は0.1%未満だったと説明しています）。変更されては困るデータの参照先をCIDで固定し、配信にはHTTPを使う組み合わせが現実的で、取得した中身をCIDで検証する@helia/verified-fetchを使えば配信元を信頼せずに済みます。