IPFSとブロックチェーンの違い｜役割分担・暗号化・CID連携

IPFS（InterPlanetary File System）とブロックチェーンは並べて語られることが多い一方、担当する仕事はまったく別です。IPFSは「データそのものを預けて取り出す」ための分散ファイルシステム、ブロックチェーンは「誰が何をいつ記録したか」を第三者が検証できる形で残す台帳です。この記事では両者の違いを役割・保存先・コスト・永続性の4点で整理し、よく検索される「暗号化されるのか」「問題点は何か」に公式ドキュメントの記述で答えたうえで、CIDをスマートコントラクトに記録する実装までを扱います。

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

• IPFSはデータの保管と配布、ブロックチェーンは記録の合意形成を担います。競合技術ではなく、NFTのように役割を分けて併用するのが標準的な構成です。
• IPFSに置いたファイルは暗号化されません。公式ドキュメントが明記するとおり暗号化されるのは通信経路だけで、CIDを知っている相手は誰でも中身を取得できます。
• IPFSは「見つかること」は保証しますが「残ること」は保証しません。ピン留めを止めたノードのデータはガベージコレクションで消えます。
• Ethereumに32バイトのCIDダイジェストを書き込むコストは初回で約22,100ガス。46文字のCIDv0を文字列のまま保存すると3スロット必要になり、概算で3倍前後に膨らみます。

以下では、この4点をそれぞれ根拠と手順まで掘り下げます。

IPFSとブロックチェーンの違い：役割・保存先・コスト

両者は「分散」という言葉を共有しているだけで、設計目標が異なります。ブロックチェーンは全ノードが同じ台帳を持つことで改ざん検知を成立させるため、データを複製するほど全体コストが上がる構造です。一方のIPFSは、必要なノードだけがブロックを持てばよく、大容量データの配布に向いています。主要な軸を並べると次のとおりです。

この表の「格納するもの」の行が、実務での使い分けをほぼ決めます。

保存するものの分担：実データはIPFS、チェーンには参照のみ

Ethereumのストレージは1スロット32バイトで、ゼロ値のスロットへ新規に書き込むと20,000ガス（EIP-2200のSSTORE_SET_GAS）に、EIP-2929で導入されたコールドアクセス分2,100ガスが加算されます。合計22,100ガスが32バイト1個の値段です。数MBの画像をそのまま載せる発想が成立しないことは、この単価から明らかでしょう。チェーン側のコストを構造から下げるアプローチはブロックチェーンのスケーリングソリューションとは何か？スケーラビリティ問題を解決するための必要性と種類で扱っていますが、それでも大容量データをオンチェーンに置く選択にはなりません。

そこで実データはIPFSへ置き、返ってきたCIDだけをコントラクトに記録します。CIDv0はQmで始まる46文字のbase58文字列ですが、その実体はマルチハッシュ接頭辞2バイト（0x12＝SHA-256、0x20＝32バイト長）＋32バイトのダイジェストです。接頭辞は固定のため、ダイジェスト32バイトだけをbytes32で保存すれば1スロットに収まります。文字列型のまま保存した場合は長さスロット＋データ2スロットで計3スロットとなり、概算で6万ガス台に増加。この差は、発行数の多いNFTでは無視できない額になります。

永続性の非対称性：確定したブロックと、いつ消えるか分からないファイル

ブロックチェーンに記録された値は、ネットワークが動いている限り消えません。IPFSはそうではありません。公式ドキュメントは「IPFS guarantees that any content on the network is discoverable, it doesn’t guarantee that any content is persistently available」と明記しています。見つけられることと、残っていることは別だという設計思想です。

Kuboの既定設定では、ガベージコレクションの周期Datastore.GCPeriodが1時間、保存容量の上限Datastore.StorageMaxが10GBです。上限に達したノードは、ピン留めしていないブロックから順に捨てます。自分のノードだけがそのファイルを持っていた場合、CIDは有効なままデータだけが取得不能になります。

使い分けの判断基準：片方だけで足りる場面の切り分け

併用が前提のように語られますが、実際には片方で十分な案件のほうが多いと考えています。判断は次の順で行うと迷いません。

まず「第三者に検証させる必要があるか」を問います。社内の関係者しか見ない証跡なら、S3にファイルを置いてハッシュ値をRDBに記録するだけで改ざん検知は成立し、ブロックチェーンは不要です。台帳とRDBの構造的な違いはブロックチェーンと従来のデータベースの違い｜分散台帳とRDBを構造・改ざん耐性・性能で比較で整理しています。

次に「そのデータを世界に公開してよいか」を問います。IPFSに追加したデータは公開が前提です。個人情報や契約書のように削除請求に応じる義務があるデータ、非公開にすべきデータをIPFSへ置く構成は採用すべきではありません。一度取得されたブロックは相手のノードに残るため、削除要求に技術的に応えられないからです。この2つを通過して初めて、IPFS＋チェーンの併用が妥当になります。

IPFSの仕組み：コンテンツ指向アドレスとDHTによる探索

IPFSが「分散ファイルシステム」と呼ばれるのは、ファイルの置き場所ではなく中身でアドレスが決まるためです。HTTPが「どのサーバーの、どのパスか」を指定するのに対し、IPFSは「このハッシュ値を持つデータ」を指定します。同じ内容のファイルは、誰がどこから追加しても同じCIDになります。プロトコルはProtocol Labsが開発し、現在はそこから独立したエンジニア集団Interplanetary Shipyardが中核の実装を維持しています。

CIDの構造：v0とv1の違いと使い分け

CIDはマルチハッシュ（ハッシュ値とアルゴリズム識別子）、マルチコーデック（データの解釈方法）、マルチベース（文字列表現の符号化方式）から構成されます。CIDv0はbase58でQmから始まる46文字に固定され、CIDv1は既定でbase32が使われbafyで始まります。公式ドキュメントは既存ツールの多くがv0を生成すると述べており、受け取り側は両方を扱える実装にしておくのが安全です。v1で追加したい場合はipfs add --cid-version=1を指定します。

DHTでの発見と再広告：CIDを持っていても届かない理由

CIDからデータを引くには、そのブロックを持つノードを分散ハッシュテーブル（DHT）で探します。提供側のノードは自分が持つCIDを定期的に広告し直す必要があり、KuboのProvide.DHT.Intervalは既定22時間です（12時間はv0.18以前の旧既定で、プロバイダレコードの有効期限48時間に合わせて変更されました）。この再広告が止まると、ノードは生きていてもDHT経由では発見されなくなります。「CIDは正しいのに取得できない」障害の多くはここが原因です。2026年8月時点の最新安定版であるKubo v0.42.0（2026年6月8日公開）ではipfs provide onceが追加され、次の広告サイクルを待たずに指定CIDを即時アナウンスできるようになりました。

IPFSは暗号化されますか：通信は暗号化、中身は公開

検索需要の大きい問いなので、結論から書きます。IPFSはファイルの中身を暗号化しません。公式ドキュメントの記述は「IPFS uses transport-encryption but not content encryption」で、暗号化されるのはノード間の通信経路だけです。さらに「All traffic on IPFS is public, including the contents of files themselves, unless they’re encrypted」と続きます。CIDを知っている相手は、誰でもその中身を取得できます。

加えて、DHTにはノードの識別子（PeerID）と提供中のCIDが広告されます。「誰がどのデータを持っているか」はネットワークから観測できる情報です。機密データを扱うなら、IPFSへ追加する前にクライアント側で暗号化し、復号鍵は当然ながらチェーンにもIPFSにも載せない構成にします。プライベートネットワーク機能で参加ノードを限定する方法もありますが、鍵を共有した全ノードが中身を読める点は変わりません。

IPFSの問題点：可用性・ゲートウェイ依存・削除できない前提

「ipfs 問題点」で調べる読者が直面するのは、思想上の欠陥ではなく運用上の3つの落とし穴です。

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

ピン留め（ipfs pin add）は、そのノードでガベージコレクションの対象から外す指定です。ネットワーク全体への保存命令ではありません。自社ノード1台だけがピン留めしている状態は、可用性としてはサーバー1台構成と変わらず、分散の恩恵を受けていません。冗長化するにはPinataなどのピン留めサービスを併用するか、複数拠点に自前ノードを立てて同じCIDをピン留めします。永続性そのものを経済的に担保する層としては、別プロトコルのFilecoinが用意されています。

パブリックゲートウェイ依存：cloudflare-ipfs.comの停止が示したリスク

ブラウザからIPFSのデータを見せる際、多くの実装がhttps://ipfs.io/ipfs/<CID>のようなHTTPゲートウェイのURLを埋め込みます。ここが単一障害点になります。

実例として、Cloudflareは2024年5月14日から自社の公開IPFSゲートウェイのトラフィックをIPFS Foundation側へ移行し、cloudflare-ipfs.comおよびcf-ipfs.comは2024年8月14日に接続を終了しました。現在の公開ゲートウェイは、IPFS Foundationに代わってInterplanetary Shipyardが運用するipfs.ioとdweb.linkが中心です。特定ゲートウェイのURLをデータベースやコントラクトに焼き込んでいた実装は、この時点で参照切れを起こしました。永続的に残す値はipfs://<CID>形式にとどめ、ゲートウェイのホスト名はアプリ側の設定値として差し替え可能にしておくべきです。

削除できない前提での設計：チェーン以外にも及ぶ不可逆性

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

IPFSとEthereumの連携実装：CIDのスマートコントラクトへの記録

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

Kuboでのファイル追加とCID取得

Kuboを導入し、ローカルノードを初期化してファイルを追加します。ipfs addの戻り値がCIDです。CIDはファイルの中身から決まるため、同じコマンドでも内容が違えば別の値になります。

# ノードの初期化とデーモン起動
ipfs init
ipfs daemon &

# ファイルを追加してCIDを取得（表示される値は内容ごとに変わる）
ipfs add sample.json
# added <CID> sample.json

# 取得と、ガベージコレクションからの保護
ipfs cat <CID>
ipfs pin add <CID>

取得できるか確認する際は、自ノードのキャッシュに残っているだけの状態と区別するため、別ネットワークの端末かパブリックゲートウェイからも引いてみます。

Solidityでの記録：bytes32とstringのコスト差

CIDv0のダイジェスト32バイトをbytes32で受け取る実装です。接頭辞の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 バイトのみ保存する。
    // CIDv1 や sha2-256 以外を扱う場合はコーデック情報も併せて保存が必要。
    function register(uint256 id, bytes32 digest) external {
        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];
    }
}

このregisterのストレージ書き込みが、前述の約22,100ガスにあたります。これは書き込み分だけの数値で、トランザクション全体では21,000ガスの基本料とイベントログ分が上乗せされる点に注意してください。CIDをstringで持つ実装に書き換えると1件あたり3スロットを消費するため、発行件数が増えるほど差が開きます。開発環境の準備からテストネットへのデプロイまでの手順はSolidity入門｜開発環境の選び方・基本構文・Sepoliaデプロイまで【2026年版】にまとめています。オンチェーンに何を残しオフチェーンに何を逃がすかという設計論はオンチェーンとは？オフチェーンとの違い・仕組み・使い分けをわかりやすく解説が参考になります。

NFTのtokenURIがipfs://を指す理由

ERC-721のtokenURIがIPFSのURIを返す構成は、ここまでの分担をそのまま製品化したものです。チェーン上にはトークンIDとメタデータのCIDだけを置き、メタデータJSON（名前・説明・画像のCID）はIPFSに、画像本体はさらに別のCIDとしてIPFSに置きます。画像を差し替えればCIDが変わるため、チェーン上のCIDと一致しなくなり、改ざんが検知できるという仕組みです。逆に言えば、メタデータをHTTPのURLで指しているNFTは、そのサーバーの管理者が中身を差し替えられます。作品性が価格に直結する用途でIPFSが選ばれるのは、この差によるものです。

よくある質問

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

使えます。IPFSは単独の分散ファイルシステムとして動作し、ブロックチェーンを必要としません。逆にブロックチェーン側も、数十バイト程度のデータならIPFSなしで完結します。併用が必要になるのは、大きなファイルを扱いつつ、その内容の同一性を第三者に検証させたい場合です。

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

公式FAQは両者を別個の補完的なプロトコルと位置づけ、「IPFS addresses and moves content, while Filecoin is an incentive layer to persist data」と説明しています。IPFSがアドレス付けと転送を担い、Filecoinは保存を続けた者に報酬を与える経済層を担います。片方だけでも利用可能です。

IPFSに追加したファイルは削除できますか？

自分のノードからはピン留めを解除してガベージコレクションを実行すれば削除できます。ただし他のノードが取得済みのコピーには影響しません。公開したCIDのデータを完全に消すことはできない前提で運用してください。

IPFSの利用は無料ですか？

ソフトウェア自体はオープンソースで無料です。費用が発生するのは可用性を確保する部分で、自前ノードならサーバー費用、Pinataなどのピン留めサービスなら保存容量に応じた料金がかかります。「無料で永久に保存される仕組み」ではありません。

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

置き換えを目指す文脈で語られることはありますが、現状の使われ方は補完です。ブラウザの多くはIPFSを直接扱えず、HTTPゲートウェイ経由で表示しています。実務では、変更されては困るデータの参照先をIPFSに置き、配信経路はHTTPを使う組み合わせが現実的です。

関連記事

• オンチェーンとは？オフチェーンとの違い・仕組み・使い分けをわかりやすく解説
• Solidity入門｜開発環境の選び方・基本構文・Sepoliaデプロイまで【2026年版】
• ブロックチェーンと従来のデータベースの違い｜分散台帳とRDBを構造・改ざん耐性・性能で比較
• ブロックチェーンのスケーリングソリューションとは何か？スケーラビリティ問題を解決するための必要性と種類