IPFSパフォーマンス：ファイル取得とゲートウェイ応答時間の高速化

「IPFSは遅い」というのは開発者からの最もよくある不満の一つですが、同時に最も解決しやすい問題でもあります。原因はほぼ常にプロトコルではなく、アクセス方法にあります。このガイドでは、本番環境でIPFSのレイテンシを解消する4つの手法を解説します。

速度別IPFSアクセス方法を選択する#

本番環境でパブリックゲートウェイを使用しているなら、専用ゲートウェイに移行するだけでレイテンシのほとんどが即座に解消されます。

パブリックゲートウェイが遅い理由#

パブリックゲートウェイは、最近参照していないCIDに対して毎回DHT（Distributed Hash Table）ルックアップを実行します。DHT ルックアップとは、コンテンツを保持しているノードを特定するためにネットワーク全体の数十のピアに問い合わせることを意味します。このラウンドトリップはコールドリクエストで2〜15秒かかります。

キャッシュヒット時でも、パブリックゲートウェイは数百万人のユーザーにサービスを提供しています。最近ピン留めしたファイルはキャッシュの優先度が低く、リクエストの間にエビクトされる可能性があります。

解決策1：専用ゲートウェイ#

専用ゲートウェイはあなたのアカウント専用のプライベートゲートウェイです。ピン留めしたファイルはそのゲートウェイに即座にキャッシュされ、コールドかウォームかを問わずどのリクエストでもDHTルックアップは発生しません。

# 変更前：パブリックゲートウェイ、低速で不安定
curl https://ipfs.io/ipfs/bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi

# 変更後：専用ゲートウェイ、高速で安定
curl https://my-app.gw.ipfs.ninja/ipfs/bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi

IPFS.NINJAダッシュボードでゲートウェイを作成し、プロジェクトに合わせてスラッグを設定してください。ゲートウェイスラッグは制限アクセスモード（トークン必須）またはパブリック静的アセット向けのオープンモードに対応しています。

解決策2：読み込み時ではなく書き込み時にピン留めする#

ファイルを作成した瞬間にピン留めして、ユーザーがリクエストする前にゲートウェイにファイルを持たせましょう。最速のリクエストは、キャッシュミスを起こさないリクエストです。

# 1ステップでアップロードとピン留めを実行
curl -X POST https://api.ipfs.ninja/upload/new \
  -H "X-Api-Key: bws_a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4" \
  -H "Content-Type: application/json" \
  -d '{
    "content": {
      "data": "BASE64_ENCODED_CONTENT",
      "type": "image/png"
    },
    "description": "Product hero image v2"
  }'

# レスポンス — CIDを保存し、urlを即座に配信
# {
#   "cid": "bafy...",
#   "sizeMB": 0.24,
#   "uris": {
#     "ipfs": "ipfs://bafy...",
#     "url": "https://ipfs.ninja/ipfs/bafy..."
#   }
# }

既存CIDの再ピン方法#

別のノードやピニングサービスから既存のCIDがある場合は、再アップロードせずに再ピン留めできます。CIDさえ分かっていれば、ファイル本体を再送信する必要はありません — /pinエンドポイントにCIDを渡すだけで、IPFS.NINJAのゲートウェイがコンテンツを取得してピン留めします：

curl -X POST https://api.ipfs.ninja/pin \
  -H "X-Api-Key: bws_a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4" \
  -H "Content-Type: application/json" \
  -d '{"cid": "bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi"}'

# レスポンス
# {
#   "cid": "bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi",
#   "status": "pinned",
#   "pinnedAt": "2026-07-02T10:15:00Z"
# }

これは、他のピニングサービスからIPFS.NINJAに移行する場合や、複数のノード間でコンテンツを冗長化したい場合に特に便利です。再ピン留めリクエストは通常数秒で完了しますが、コンテンツのサイズによって多少変動します。

ピン状態の確認方法#

コンテンツが実際にピン留めされ、いつでも配信可能な状態かを確認するには、ピンステータスエンドポイントにCIDを指定してGETリクエストを送ります：

curl https://api.ipfs.ninja/pin/bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi \
  -H "X-Api-Key: bws_a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4"

# レスポンス — CIDがピン留めされ、配信可能であることを示す
# {
#   "cid": "bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi",
#   "status": "pinned",
#   "sizeMB": 0.24,
#   "gatewayUrl": "https://my-app.gw.ipfs.ninja/ipfs/bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi"
# }

statusフィールドがpinned以外（例えばpinningやfailed）の場合は、アップロードやピン留めがまだ完了していないか、エラーが発生している可能性があります。本番環境のアップロードパイプラインでは、公開前にこのエンドポイントをポーリングしてpinnedステータスを確認することを推奨します。

完全なアップロードAPIリファレンスはIPFSへのファイルアップロード方法をご覧ください。

解決策3：ゲートウェイの前にCDNを配置する#

専用ゲートウェイは固定リージョンからサービスを提供します。ユーザーが複数の大陸にまたがる場合は、最寄りのポイント・オブ・プレゼンスから配信するためにCDNエッジレイヤーを追加してください。

IPFSはコンテンツアドレッシングを採用しているため — 特定のCIDは常に同一のバイト列に解決されます — 永続的にキャッシュできます：

Cache-Control: public, max-age=31536000, immutable

Cloudflareの例（無料プランでほとんどの静的アセットのワークロードに対応）：

1. ゲートウェイのサブドメイン（my-app.gw.ipfs.ninja）をCloudflareプロキシ経由のCNAMEとして追加する。
2. Page Ruleを作成する：my-app.gw.ipfs.ninja/ipfs/* → Cache Everything、Edge Cache TTL: 1ヶ月。
3. 最初のリクエストがゲートウェイに到達し、最寄りのエッジPoPにキャッシュされる。以降のリクエストはすべてCloudflareから配信される。

結果：グローバルTTFBが50〜200 msから10〜50 msに短縮されます。

解決策4：画像最適化API#

フル解像度で配信されるIPFS画像はページを重くし、Core Web Vitalsに悪影響を与えます。エッジでリサイズし、モダンなフォーマットで配信するために画像最適化エンドポイントを使用してください：

# オリジナル（ゲートウェイ経由のフル解像度）
https://my-app.gw.ipfs.ninja/ipfs/bafy...

# 幅800pxにリサイズ、WebPに変換
https://api.ipfs.ninja/image/bafy...?w=800&format=webp

# 正方形サムネイル
https://api.ipfs.ninja/image/bafy...?w=200&h=200&fit=cover

Reactでの使用例：

function IPFSImage({ cid, width }) {
  return (
    <img
      src={`https://api.ipfs.ninja/image/${cid}?w=${width}&format=webp`}
      width={width}
      loading="lazy"
      decoding="async"
    />
  );
}

最適化エンドポイントは各(cid, width, format)の組み合わせをキャッシュします — 同じパラメータによる以降のリクエストはオリジンへのアクセスをすべてスキップします。

チェックリスト#

• パブリックゲートウェイから専用ゲートウェイに切り替える
• 読み込み時ではなく書き込み時（アップロード時）にコンテンツをピン留めする
• ゲートウェイのレスポンスにCache-Control: immutableを設定する
• グローバルトラフィック向けにゲートウェイの前にCDNを追加する
• 生のゲートウェイURLの代わりに最適化エンドポイント経由で画像を配信する

速度だけでなく可用性のためにピン留めが重要な理由については、IPFSピン留めとはをご覧ください。

ピン留めを始める準備はできましたか？ 無料アカウントを作成する — ファイル50件、ストレージ1 GB、帯域幅2 GB/月。クレジットカード不要。

この記事について：この記事はIPFS.NINJAのコンテンツ生成ワークフローを使用してAIアシスタントによって下書きされ、Nacho Collによってレビューおよび承認されました。すべてのコード例はライブIPFS.NINJA APIに対して検証されています。不正確な点を見つけた場合は、https://github.com/ipfs-ninja/feedback にIssueを開いてください。コンテンツへのAI活用方法とIPFS.NINJAを支える人々についてもご覧ください。