Filebaseの代替：S3不要のシンプルなIPFSピニング

Filebase と IPFS Ninja を比較する：主な違い#

結論：すでにAWS SDKクライアントを組み込んでいるなら、Filebaseは自然にはまります。curlコマンド一発でIPFSにファイルを送りたいなら、シンプルさでIPFS Ninjaの勝ちです。

30秒でIPFSにファイルをアップロード#

これがIPFS Ninjaのアップロードフローです。SDK不要、XML不要、バケット作成ステップも不要：

curl -X POST https://api.ipfs.ninja/upload/new \
  -H "X-Api-Key: bws_a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4" \
  -H "Content-Type: application/json" \
  -d '{
    "content": "Hello from IPFS Ninja!",
    "description": "My first file"
  }'

レスポンス：

{
  "cid": "bafkreib4mrow...",
  "sizeMB": 0.00002,
  "uris": {
    "ipfs": "ipfs://bafkreib4mrow...",
    "url": "https://ipfs.ninja/ipfs/bafkreib4mrow..."
  }
}

以上です。このCIDはピニングされ、IPFS上でアクセス可能になり、パブリックゲートウェイ経由でも即座に到達できます。

一方、Filebaseの同等のフローはこうなります：

1. アカウントを作成し、Filebaseコンソールでバケットを作成する。
2. アクセスキーとシークレットキーのペアを生成する。
3. エンドポイントhttps://s3.filebase.com、リージョンus-east-1、クレデンシャルでS3クライアントを設定する。
4. ファイル本体を指定してputObjectを呼び出す。
5. オブジェクトのメタデータをポーリングしてIPFS CIDを取得する（FilebaseがピニングするとX-Amz-Meta-Cidヘッダーとして現れる）。

間違ったやり方ではありません――ただ、ほとんどのREST指向プロジェクトが必要とするよりも動くパーツが多いのです。

開発者がFilebaseのS3摩擦に当たる理由#

FilebaseのS3互換性が本当に役立つのは次のケースです：

• LambdaファンクションやTerraformモジュール、バックアップエージェントなど、既存インフラがS3と通信している。
• 大きなblobを保存していて、すでに知っているマルチパートアップロードのセマンティクスが欲しい。
• チームがAWSに精通していてS3 SDKがすでに依存関係に入っている。

しかし、IPFSをWebアプリ、dApp、CIパイプラインに組み込む多くの開発者はその世界から来ていません。彼らが直面するのは：

XMLエラーレスポンス。 S3はXMLを返します。JavaScriptのfetchコールが<?xml version="1.0" ...><Error><Code>InvalidAccessKeyId</Code>を受け取ると、デバッグのためにXMLパーサーを追加しなければなりません。

クレデンシャル管理。 S3スタイルの認証（アクセスキー＋シークレット＋HMAC-SHA256リクエスト署名）は、ブラウザやエッジ関数でゼロから実装するのは簡単ではありません。事前署名URLは助けになりますが、サーバーサイドで生成するとラウンドトリップが増えます。

CID取得が後付け。 CIDはS3オブジェクトのメタデータであり、プライマリレスポンスではありません。レスポンスヘッダーをパースするか、別のメタデータエンドポイントを呼び出す必要があります。

ネイティブな署名アップロードトークンがない。 サーバークレデンシャルを露出せずにユーザーがブラウザから直接アップロードできるようにするには、Filebaseでは事前署名URL生成エンドポイントを自分で構築する必要があります。

IPFS Ninjaの署名アップロードトークンはこのパターンをネイティブに処理します：サーバーサイドで一度期限付きトークンを生成し、フロントエンドに埋め込めば、トークンが期限切れになるか失効させるまでユーザーはapi.ipfs.ninjaに直接POSTできます。

ブラウザからS3署名を生成する手順#

Filebaseへブラウザから直接アップロードするには、AWS Signature Version 4形式でリクエストに署名する必要があります。典型的な手順は次のとおりです：

1. サーバーサイドでシークレットキーを使い、日付・リージョン・サービス名から派生鍵をHMAC-SHA256で計算する。
2. リクエストのメソッド、URI、クエリ文字列、ヘッダー、ペイロードハッシュから「正規リクエスト」を組み立てる。
3. 正規リクエストのSHA256ハッシュを使って署名文字列を作成し、派生鍵で署名する。
4. 署名をAuthorizationヘッダーまたはクエリパラメータに付与し、有効期限（通常最大7日）を設定する。
5. 署名済みURLをブラウザに渡し、直接PUTさせる。

シークレットキーをブラウザに渡すことはできないため、この処理は必ずサーバー側で行う必要があり、アップロードのたびにサーバーとの往復や署名ロジックの保守コストが発生します。

IPFS Ninjaの署名付きアップロードトークンによる代替#

IPFS Ninjaはこの複雑さを丸ごと置き換えます。サーバーサイドでトークンを一度生成するだけで済みます：

curl -X POST https://api.ipfs.ninja/token/upload/new \
  -H "X-Api-Key: bws_a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4" \
  -H "Content-Type: application/json" \
  -d '{ "expiresInMinutes": 60 }'

レスポンスにはブラウザへそのまま渡せる署名付きトークンが含まれます。HMAC計算も正規リクエストの組み立ても、日付やリージョンの管理も不要です。ブラウザはAuthorization: Signed {token}ヘッダーを付けてapi.ipfs.ninjaへ直接POSTするだけで、CIDを含むレスポンスを受け取れます。トークンはダッシュボードからいつでも即座に失効させられるため、漏洩時の対応もシンプルです。

料金の並列比較#

小〜中規模プロジェクトでは、無料から最初の有料ティアへのジャンプはIPFS Ninjaで$5/mo、Filebaseでは約$20/moです。サイドプロジェクトやスタートアップMVPを構築しているなら、この差は重要です。

ゲートウェイ機能の比較#

両サービスとも専用IPFSゲートウェイ（ピニングされたコンテンツをHTTPS経由で配信するサブドメイン）を提供しています。違いは：

Filebaseは有料プランで専用ゲートウェイを提供します。バケットのコンテンツを配信し、S3ネームスペースと統合されています。

IPFS Ninjaのゲートウェイ（https://{slug}.gw.ipfs.ninja）は以下をサポートします：

• アクセスモード：制限付き（トークン必須）、オープン（パブリック）、フォルダー（ディレクトリリスト表示）。
• IPホワイトリスト：既知のサーバーIPにゲートウェイをロック。
• オリジン制限：特定のHTTPオリジンに制限。ブラウザ専用CORSシナリオに便利。
• 画像最適化：/image/{cid}エンドポイントでリサイズ、クロップ、フォーマット変換をオンザフライで実行――別途画像CDNは不要。

Webフロントエンドにアセットを配信するユースケースなら、CORSオリジン制限と組み込みの画像最適化エンドポイントにより、別サービスの統合が不要になります。

既存CIDのピニング#

別のノードやサービスからCIDをすでに持っていますか？両プラットフォームとも再アップロードなしでピニングできます。IPFS Ninjaの場合：

curl -X POST https://api.ipfs.ninja/pin \
  -H "X-Api-Key: bws_a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4" \
  -H "Content-Type: application/json" \
  -d '{
    "cid": "bafkreib4mrow...",
    "description": "Pinned from external source"
  }'

Filebaseの場合、CIDをカスタムメタデータヘッダーとしてバケットへPUTでピニングし、FilebaseがフェッチしてピニングするするS3経由の方法です。IPFS Ninjaのフローは、S3ネイティブではなくIPFSネイティブな視点から来ているなら、よりダイレクトです。

ピニングが重要な理由とコンテンツがピニングされていない場合に何が起こるかについての詳しい説明は、IPFSピニングとはを参照してください。

クレデンシャルを漏らさないクライアントサイドアップロード#

よくあるアーキテクチャ上の質問です：APIキーをクライアントに送らずにブラウザからIPFSにアップロードさせるにはどうすればよいか？

Filebaseのアプローチ：サーバーで事前署名S3 PUT URLを生成し、クライアントに返し、クライアントが直接PUTする。標準のS3事前署名パターンで問題なく動きますが、サーバーサイドの署名エンドポイントを実装する必要があります。

IPFS Ninjaのアプローチ：/token/upload/newを呼び出す（またはダッシュボードで生成する）して署名アップロードトークンを作成します。そのトークンをフロントエンドに埋め込みます。クライアントはAuthorization: Signed {token}を使ってapi.ipfs.ninjaにPOSTします。トークンは設定した時間後に期限切れになるよう設定でき、ダッシュボードから即座に失効させることもできます。

// フロントエンドコード — トークンはサーバーから取得済み
const token = 'your-signed-upload-token';

const response = await fetch('https://api.ipfs.ninja/upload/new', {
  method: 'POST',
  headers: {
    'Authorization': `Signed ${token}`,
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    content: btoa(fileContentAsArrayBuffer), // バイナリはbase64で
    description: 'User uploaded file',
  }),
});

const { cid, uris } = await response.json();
console.log('Pinned at:', uris.url);

アップロードパターンの詳細なウォークスルーは、IPFSへのファイルアップロード方法を参照してください。

それでもFilebaseを選ぶべきとき#

この記事は一方的な売り込みではなく、正直であることを目指しています。

Filebaseを選ぶべきケース：

• コードベースがすでにAWS SDK v3またはBoto3を使用していて、追加の依存関係をゼロにしたい。
• S3からIPFSへ移行していて、アップロードロジックを書き直すのではなくエンドポイントを差し替えたい。
• 非常に大きなファイルを保存していて、S3セマンティクスによる信頼性の高いマルチパートアップロードが必要（ただしIPFS Ninjaにも大容量アップロードAPIがあります）。
• チームがAWSの深い知識を持っていて、S3認証の方がRESTヘッダーより馴染みがある。

IPFS Ninjaを選ぶべきケース：

• POST /upload/new一発でCIDを受け取りたい、中間ステップなし。
• フロントエンドファーストのアプリを構築していて、事前署名インフラを構築せずにクライアントセーフなアップロードトークンが必要。
• 別サービスを追加することなく画像最適化とアクセス制御付きゲートウェイが欲しい。
• 価格を重視していて、$5/moのエントリーポイントがプロジェクトのステージにとって重要。

まとめ#

FilebaseはAWSエコシステムにどっぷり浸かっているチームにとって堅実なプロダクトです。S3互換性はそのコンテキストでは本物のアドバンテージです。しかし、クリーンなREST API経由でIPFSにファイルをピニングして――CIDをすぐに受け取りたい開発者にとっては、S3レイヤーはメリットなく手間を増やすだけです。

IPFS NinjaはAPI表面を最小限に保ちます：アップロード、ピニング、フェッチ。ゲートウェイ、画像最適化、アップロードトークン機能は必要なときに使えますが、最初から必須ではありません。

IPFS Ninjaが他サービスとどう比較されるかの広い視点は、最良のIPFSピニングサービスを参照してください。

ピニングを始める準備はできましたか？ 無料アカウントを作成 ― 500ファイル、1 GBストレージ、クレジットカード不要。

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