「decentralized storage」タグの記事が 2 件 件あります

分散型ストレージネットワークは、データをピアツーピアネットワーク全体に分散させることで、データの非永続性、検閲、および中央集権化の問題に対処することを目指しています。従来の Web コンテンツは驚くほど短命です。例えば、研究によると インターネットの 98% 以上が 20 年後にアクセス不能になる ことが示されており、回復力のある長期ストレージの必要性が浮き彫りになっています。 Arweave や Pinata（IPFS 上に構築） のようなベンダーは、 Filecoin 、 Storj 、 Sia 、 Ceramic 、および基盤となる IPFS プロトコルと並んで、永続的または分散型のストレージソリューションを提供するために登場しました。本レポートでは、これらのサービスを (1) 技術的アーキテクチャと機能、(2) 価格モデル、(3) 開発者体験、(4) ユーザーの採用、(5) エコシステムの成熟度、(6) 主要なユースケース（例：NFT メタデータのホスティング、dApp バックエンド、アーカイブデータ、コンテンツ配信）の観点から分析します。違いを説明するために、比較表と例が提供されています。すべてのソースは、公式ドキュメントまたは権威ある分析にリンクされています。

1. 技術的機能とアーキテクチャ​

Arweave: Arweave は、斬新な Blockweave データ構造に基づいた ブロックチェーンのような永続的ストレージネットワーク です。ブロックを線形にリンクする従来のブロックチェーンとは異なり、Arweave の Blockweave は各ブロックを直前のブロック および ランダムな過去のブロック にリンクさせ、ウェブのような構造を作成します。この設計（ Succinct Proof of Random Access (SPoRA) コンセンサスと組み合わせ）により、マイナーは新しいブロックをマイニングするためにランダムな古いデータを検証する必要があり、 アーカイブを可能な限り多く保存するインセンティブ が与えられます。その結果、高い冗長性が実現されています。実際、現在、 Arweave データセット全体の 約 200 のレプリカ が世界中に分散されています。 Arweave にアップロードされたデータは、この「Permaweb」の一部となり、 不変かつ永続的 になります。パフォーマンスとスケーラビリティを向上させるために、 Arweave は Bundling （多くの小さなファイルを 1 つのトランザクションにまとめる）を使用して、大量のデータスループットを処理します（例：ある Arweave バンドラーは、 1 回のトランザクションで 47 GB のデータを保存しました）。 Wildfire メカニズムは、ノードを応答性によってランク付けし、ネットワーク全体での迅速なデータ伝搬を促進します。全体として、 Arweave は 分散型ハードドライブ として機能し、将来的にストレージコストが下がり続けるという期待のもと、前払いの基金からマイナーに永続的に支払われる仕組みで、データをオンチェーンに永続的に保存します。

IPFS および Pinata: InterPlanetary File System (IPFS) は、分散型データの保存と共有のための コンテンツ指向のピアツーピアファイルシステム を提供します。 IPFS 上のデータは コンテンツハッシュ (CID) によって識別され、グローバルな分散ハッシュテーブル (DHT) を介して取得されます。設計上、 IPFS 自体は ファイル共有インフラストラクチャ であり、ノードが明示的にコンテンツをホスト（「ピン留め」）し続けない限り、データの永続性は保証されません。 Pinata のようなサービスは、 ピン留めと帯域幅 を提供することで IPFS を補完します。 Pinata は、データをピン留めして利用可能な状態に保つ IPFS ノードを運営し、迅速な取得のための CDN 統合を備えた高速 HTTP ゲートウェイ を提供します（頻繁にアクセスされるデータの「ホットストレージ」と呼ばれることもあります）。技術的には、 Pinata のアーキテクチャは、分散型 IPFS ネットワークを支える中央集権的なクラウドインフラストラクチャです。ファイルは IPFS を介して分散されますが（コンテンツ指向であり、任意の IPFS ピアから取得可能）、 Pinata は 自社サーバーにコピーを保持し、専用ゲートウェイを通じてキャッシュする ことで高い可用性を確保します。 Pinata はまた、 プライベート IPFS ネットワーク （隔離された用途向け）、 IPFS を活用した キーバリューデータストア 、およびその他の開発者ツールも提供しており、これらすべてが内部で IPFS を利用しています。要約すると、 IPFS+Pinata は、信頼性とパフォーマンスを処理するための マネージドサービスレイヤー (Pinata) を備えた 分散型ストレージプロトコル (IPFS) を提供します。

Filecoin: Filecoin は、しばしば IPFS のインセンティブレイヤー と見なされます。これは、ストレージプロバイダー（マイナー）がオープンマーケットでディスクスペースを貸し出す、 ブロックチェーン駆動の分散型ストレージネットワーク です。 Filecoin は、マイナーがクライアントデータの 一意のコピー を保存したことを確認するための斬新な 複製証明 (Proof-of-Replication, PoRep) と、データが時間の経過とともに保存され続けていることを継続的に検証するための 時空証明 (Proof-of-Spacetime, PoSt) を使用します。 ゼロ知識証明 に基づいて構築されたこれらの証明は Filecoin のブロックチェーンに記録され、合意通りにデータが保存されているという 暗号経済的な保証 を提供します。 Filecoin ネットワークは、コンテンツ指向とデータ転送のために IPFS テクノロジー上に構築されていますが、 オンチェーンで執行されるスマートコントラクト（「ストレージ取引」） を追加しています。ストレージ取引では、ユーザーは指定された期間データを保存するために、マイナーに Filecoin (FIL) で支払います。マイナーは 担保 を預け入れ、ストレージの証明に失敗した場合はスラッシュ（没収）されるため、信頼性が確保されます。 Filecoin はデータを自動的に公開するわけではありません。ユーザーは通常、コンテンツ配信のために IPFS や他の取得ネットワークと組み合わせます。 スケーラブルで柔軟 であり、大きなファイルを分割して複数のマイナーに保存したり、ノードの故障に備えて複数のプロバイダーと取引を行うことで 冗長性レベル を選択したりできます。この設計は 大量ストレージ に適しています。マイナーは大規模なデータセット向けに最適化されており、取得速度については、別途「取得マイナー」を利用したり、 IPFS キャッシュを使用したりする場合があります。本質的に、 Filecoin は分散型の Amazon S3 + Glacier のようなものです。つまり、 検証可能な耐久性 とユーザー定義の冗長性を備えたストレージマーケットプレイスです。

Storj: Storj は、コンセンサスにブロックチェーンを使用せず、代わりにノードの分散ネットワークとサテライトメタデータサービスを通じてストレージを調整する、 分散型クラウドオブジェクトストレージネットワーク です。ファイルが Storj （ Storj DCS – Decentralized Cloud Storage と呼ばれるサービス）にアップロードされると、まず クライアント側で暗号化 され、次に（デフォルトで） 80 個の断片に消失訂正コーディング (Erasure coding) されます。ファイルを再構築するには、そのサブセット（例：80 個中 29 個）のみが必要です。これらの暗号化された断片は、世界中の多様なストレージノードに分散されます（各ノードはランダムな断片のみを保持し、それ自体では有用なデータではありません）。これにより、 Storj は極めて高い耐久性（ 11×9s の耐久性 – 99.999999999% のデータ生存率を主張）と ダウンロードの並列性 を実現しています。ファイルを取得するユーザーは、数十のノードから同時に断片を取得できるため、多くの場合スループットが向上します。 Storj は 取得可能性証明 (Proof-of-retrievability) の概念を使用しています（ストレージノードは、断片をまだ保持していることを定期的に監査されます）。ネットワークはエンドツーエンド暗号化を備えた ゼロトラストモデル で動作し、復号キーを保持するファイルの所有者のみがデータを読み取ることができます。このアーキテクチャには中央のデータセンターはありません。代わりに、ノードオペレーターが提供する既存の余剰ディスク容量を活用しており、これにより 持続可能性とグローバルな分散 が向上します（ Storj は、これが CDN のようなパフォーマンスと大幅に低いカーボンフットプリントをもたらすと指摘しています）。調整（ファイルのメタデータ、支払い）は、 Storj Labs が運営する「サテライト」によって処理されます。要約すると、 Storj の技術的アプローチは、 暗号化され、シャード化され、分散されたオブジェクトストレージ であり、ブロックチェーンのコンセンサスなしで、ストレージの暗号化監査を行いながら、従来の CDN と同等以上の高い冗長性とダウンロード速度を実現します。

Sia: Sia もまた、独自のブロックチェーンと暗号通貨 (Siacoin) を利用してストレージ契約を形成する 分散型クラウドストレージプラットフォーム です。 Sia は リード・ソロモン消失訂正コーディング を使用して、ファイルを 30 個の暗号化されたシャード に分割し、ファイルを復元するためにそのうちの任意の 10 個を必要とします（組み込みの 3 倍の冗長性を提供）。これらのシャードは、ネットワーク全体の 独立したホスト に保存されます。 Sia のブロックチェーンはプルーフ・オブ・ワーク (Proof-of-Work) であり、レンターとホストの間の スマートコントラクト を執行するために使用されます。 Sia のストレージ契約では、レンターは一定期間 Siacoin をロックアップし、ホストは担保を預け入れます。ホストは、データを保存していることを示す ストレージ証明 （ Filecoin の証明と趣旨が似ている）を定期的に提出しなければならず、さもなければ担保を失います。契約終了時、ホストにはエスクローされた資金から支払われます（また、プロトコル手数料として Siafund 保有者に少額が支払われます）。このメカニズムにより、ホストがデータを確実に保存するための経済的インセンティブとペナルティが確保されます。 Sia の設計は、 プライバシー （すべてのデータはエンドツーエンドで暗号化され、ホストはユーザーのファイルを見ることができません）と 検閲耐性 （中央サーバーがない）を強調しています。 Storj と同様に、 Sia は複数のホストからファイル断片を 並列ダウンロード できるため、速度と稼働率が向上します。ただし、 Sia ではストレージを維持するために、ユーザーが定期的に契約を更新する必要があります（デフォルトの契約期間は 3 ヶ月）。つまり、ユーザーが支払い続けない限り、データは「永続的」ではありません。 Sia は以前、 Web 中心の用途向けに Skynet と呼ばれるレイヤーを導入していました。 Skynet はコンテンツ指向（「スカイリンク」経由）と Sia ホスト型コンテンツを簡単に取得するための Web ポータルを提供し、事実上 Sia ファイルの分散型 CDN として機能していました。要約すると、 Sia のアーキテクチャは、強力な冗長性とプライバシーを備えた ブロックチェーン保護型クラウドストレージ であり、分散型の方法での「ホット」データ（高速取得）に適しています。

Ceramic: Ceramic は少し異なり、バルクファイルストレージではなく、 変更可能なデータストリームのための分散型ネットワーク です。分散型の方法で保存する必要がある一方で、頻繁に更新する必要がある 動的な JSON ドキュメント、ユーザープロファイル、アイデンティティ (DID) 、ソーシャルコンテンツなど のユースケースをターゲットにしています。 Ceramic のプロトコルは、順序付けのためにブロックチェーンにアンカーされた 暗号署名付きイベント（更新） を使用します。実際には、 Ceramic 上のデータは 「ストリーム」またはスマートドキュメント として保存されます。各コンテンツは、所有者によって更新可能な（バージョンの検証可能な履歴を持つ）ストリーム内に存在します。内部的には、 Ceramic は各更新のコンテンツ保存に IPFS を使用し、すべてのノードがドキュメントの最新の状態に合意できるように イベントログ が維持されます。 コンセンサス は、基礎となるブロックチェーン（元々は Ethereum ）にストリームの更新をアンカーして、不変のタイムスタンプと順序を得ることから得られます。ネイティブトークンはありません。ノードは単に Ceramic を使用している dApp のためにデータを複製します。技術的な機能には、更新認証のための DID (分散型アイデンティティ) 統合 や、相互運用可能な形式を保証するための グローバルスキーマ （データモデル）が含まれます。 Ceramic は スケーラブル であるように設計されています（各ストリームの状態は独立して維持されるため、すべてのデータのグローバルな「台帳」が存在せず、ボトルネックを回避できます）。要約すると、 Ceramic は Web3 アプリケーション向けの 分散型データベース と 変更可能なストレージ を提供します。これはファイルストレージネットワークを補完するものであり、 構造化データとコンテンツ管理 に焦点を当てています（ Arweave 、 Filecoin 、 Storj などのネットワークが静的なファイルブロブに焦点を当てているのに対し）。

アーキテクチャの概要: 以下の表は、これらのシステムの主要な技術的側面を比較したものです。

2. 料金モデル​

分散型ストレージという同様の目標を掲げているものの、これらのサービスは異なる料金体系と経済モデルを採用しています：

• Arweave の料金設定： Arweave は、データを「永久に」保存するために、AR トークンによる一度限りの前払いを必要とします。ユーザーは少なくとも 200 年分のストレージ料金を支払い、プロトコルはその手数料の約 86% を基金（Endowment Fund）に積み立てます。基金の蓄積（利息および AR の価値上昇による）は、ハードウェアコストが時間の経過とともに低下する（歴史的に年間約 30% 低下）という仮定の下、ストレージマイナーに対して無期限に報酬を支払うように設計されています。実務的には、価格は AR の市場価格によって変動しますが、2023 年時点では 1 TB あたり約 3,500 ドルの一時払いでした（注：これは永久ストレージを購入するものであり、従来のクラウドのような継続的なコストではありません）。Arweave のモデルは負担を前倒しにします。ユーザーは最初に多く支払いますが、その後は一切支払いません。これは大量のデータにとっては高額になる可能性がありますが、将来的にプロバイダーを信頼することなく永続性を保証します。
• Pinata (IPFS) の料金設定： Pinata は、Web2 SaaS で一般的なサブスクリプションモデル（法定通貨による価格設定）を採用しています。無料プラン（最大 1 GB のストレージ、10 GB/月の帯域幅、500 ファイル）と有料プランを提供しています。人気の 「Pinata Picnic」プランは月額 20 ドルで、1 TB のピン留め済みストレージと 500 GB の帯域幅が含まれており、超過料金はストレージ 1 GB あたり約 0.07 ドル、帯域幅 1 GB あたり 0.10 ドルです。上位の 「Fiesta」プランは月額 100 ドルで、ストレージ 5 TB、帯域幅 2.5 TB まで拡張され、超過料金もさらに安くなります。すべての有料プランには、カスタムゲートウェイ、API リクエスト制限の引き上げ、追加料金によるコラボレーション機能（マルチユーザーワークスペース）などの機能が含まれています。また、カスタム価格のエンタープライズプランもあります。したがって、Pinata のコストはクラウドストレージプロバイダーと同様に予測可能な月額料金であり、トークンベースではありません。IPFS を使い慣れた料金体系（ストレージ + 帯域幅、ゲートウェイでの無料 CDN キャッシング付き）に抽象化しています。
• Filecoin の料金設定： Filecoin はオープンマーケットとして運営されているため、価格はストレージマイナーの需要と供給によって決定され、通常はネイティブの FIL トークンで表記されます。実際には、供給が豊富であるため、Filecoin のストレージは非常に安価になっています。2023 年半ば時点で、Filecoin へのデータ保存コストは 1 TB あたり年間 2.33 ドル程度であり、中央集権的な代替手段（AWS S3 は頻繁にアクセスされるストレージで約 250 ドル/TB/年）や、他の分散型オプションと比較しても大幅に安価です。ただし、このレートは固定されていません。クライアントが入札（Bid）を行い、マイナーが売り手価格（Ask）を提示します。市場価格は変動する可能性があります。また、Filecoin のストレージ契約には特定の期間（例：1 年）があります。期間を超えてデータを保持したい場合は、更新（再支払い）するか、最初から長期契約を結ぶ必要があります。また、有用な公開データを保存する「検証済み」クライアントにボーナスを与え、より低い実効コストでマイナーを引きつけるインセンティブプログラムである Filecoin Plus (FIL+) という概念もあります。ストレージ料金に加えて、リクエストごとの取得（Retrieval）に対して少額の FIL を支払う場合がありますが、取得市場はまだ発展途上です（現在は多くが IPFS 経由の無料取得に依存しています）。重要な点として、Filecoin のトークノミクス（ブロック報酬）はマイナーを強力に補助しています。FIL でのブロック報酬が、ユーザーが支払う手数料を補填しています。つまり、現在の低価格は一部、インフレ的な報酬によるものです。時間が経ちブロック報酬が減少するにつれて、ストレージ料金は上昇方向に調整される可能性があります。要約すると、Filecoin の価格設定は動的かつトークンベースであり、一般的にバイトあたりのコストは非常に低いですが、ユーザーは更新の管理と FIL 通貨のリスクに対処する必要があります。
• Storj の料金設定： Storj は従来の通貨基準で価格設定されています（ただし、支払いは法定通貨または STORJ トークンで行うことができます）。従量課金制のクラウド料金モデルに従っており、現在は ストレージ 1 TB あたり月額 4.00 ドル、送信データ転送量（Egress）1 TB あたり 7.00 ドルです。詳細には、保存データ 1 GB あたり月額 0.004 ドル、ダウンロード 1 GB あたり 0.007 ドルとなります。また、メタデータのオーバーヘッドを考慮して、保存されるオブジェクト（セグメント）ごとにごくわずかな料金（1 セグメントあたり月額約 0.0000088 ドル）が発生しますが、これは数百万もの非常に小さなファイルを保存する場合にのみ問題となります。特筆すべきは、受信（アップロード）が無料であること、そしてベンダーロックインを避けるために、移行を決定した場合には送信手数料を免除するポリシーが Storj にはあることです。Storj の価格設定は透明で固定されており（入札市場なし）、従来のクラウドを大幅に下回ります（リージョン間のレプリケーションや大規模なデータセンターのオーバーヘッドが不要なため、AWS と比較して 約 80% の節約になると宣伝されています）。エンドユーザーは、希望しなければトークンを扱う必要はありません。利用料金を米ドルで支払うだけです。その後、Storj Labs がノードオペレーターに STORJ トークンで報酬を支払います（トークン供給量は固定されており、オペレーターが価格変動リスクを負います）。このモデルにより、Storj は内部で分散型支払いのためにトークンを活用しつつ、価格設定において開発者フレンドリーとなっています。
• Sia の料金設定： Sia のストレージマーケットもアルゴリズムに基づいたトークン建てであり、Siacoin (SC) を使用します。Filecoin と同様に、借り手（Renter）とホストはネットワークの市場を通じて価格に合意します。歴史的に Sia は極めて低いコストで知られてきました。初期の頃、Sia はストレージを 1 TB あたり月額約 2 ドルと宣伝していましたが、実際の価格はホストの提示内容に依存します。2020 年のある Reddit コミュニティの計算では、冗長性のオーバーヘッドを除いた借り手の実質コストは月額約 1 〜 3 ドル/TB でした（冗長性を考慮すると、3 倍の冗長性で月額 7 ドル/TB など、実効コストは数倍高くなる可能性がありますが、それでも非常に安価です）。2024 年第 3 四半期時点で、需要の増加と SC トークンの変動により、Sia のストレージ価格は前四半期比で約 22% 上昇しましたが、依然として中央集権的なクラウド価格をはるかに下回っています。Sia の借り手は、帯域幅（アップロード/ダウンロード）と担保（Collateral）のためにもいくらかの SC を割り当てる必要があります。ホストは低価格を提示して競い合い（契約を獲得して SC を稼ぎたいため）、借り手はその競争から利益を得るという経済構造になっています。しかし、Sia を使用するには Siacoin を入れたウォレットを操作し、契約の設定を行う必要があるため、Storj や Pinata ほどコスト計算がユーザーフレンドリーではありません。簡単に言えば、Sia のコストはトークン市場主導であり、1 TB あたりの単価は非常に低いですが、ユーザーは契約を延長するために（SC で）継続的に支払う必要があります。永久保存のための前払い一括料金はありません。暗号資産形式の従量課金制です。多くのユーザーは取引所で SC を入手し、あらかじめ決められたレートで数ヶ月分のストレージ契約をロックインします。
• Ceramic の料金設定： Ceramic はプロトコルレベルでの使用料を課していません。Ethereum ブロックチェーン上で更新をアンカリング（固定）するためのわずかなガス代以外に、ストリームの作成や更新のためのネイティブトークンや手数料はありません（これは通常 Ceramic のインフラによって処理され、バッチ処理されるため更新あたりのコストは無視できるほどです）。Ceramic ノードの運用はオープンな活動であり、誰でもデータをインデックス化して提供するためにノードを実行できます。3Box Labs（Ceramic の背後にあるチーム）は開発者向けのホスト型サービス（Ceramic Cloud）を提供しており、利便性のためにエンタープライズ料金を導入する可能性がありますが、ネットワーク自体はノード運用の労力を除けば無料で使用できます。したがって、Ceramic の「価格」は主に、開発者がノードを自前でホストする場合に発生する運用コスト、またはサードパーティのノードを使用する場合の信頼コストとなります。本質的に、Ceramic のモデルは分散型データベースやブロックチェーンの RPC サービスに近く、収益化（もしあれば）はデータのマイクロペイメントではなく、付加価値サービスを通じて行われます。これにより、開発者はトークンを必要とせずに動的なデータストレージを試すことができますが、長期的なノードのサポートを確保する必要があることも意味します（利他的なノードや助成金ベースのノードがストレージを提供しているため）。

料金サマリー： 以下の表は、料金と支払いモデルをまとめたものです。

3. 開発者体験 (Developer Experience)​

普及に向けた重要な要素は、API、SDK、ドキュメント、ツールを通じて、開発者がこれらのストレージソリューションをいかに簡単に統合できるかという点です。

• Arweave の開発者体験: Arweave は arweave.net/graphql で GraphQL API エンドポイント を提供しており、パーマウェブのトランザクションやデータをクエリできます。開発者はタグやウォレットアドレスなどを使用して、保存されたコンテンツを検索することが可能です。ブラウザおよび Node.js 用の Arweave.js のような公式 SDK が用意されており、ファイルのアップロードやネットワークへのトランザクション投稿を簡素化します。例えば、開発者は Arweave SDK を使用して、わずか数行のコードでファイルをバンドルしてアップロードできます。各アップロードがオンチェーンのトランザクションとなるため、歴史的に大規模なアップロードの UX は困難でしたが、 Bundlr (Bundlr Network) の導入によりスループットが大幅に向上しました。Bundlr (現在は Arweave スケーリングのために 「Iris」 へリブランディング) は、本質的にはバンドリングノードのネットワークであり、開発者が一度の支払いで多くのファイルをオフチェーンでアップロードし、それらを定期的にまとめて Arweave にコミットできるようにします。これにより、dApp (特に NFT プラットフォーム) は、メインチェーンに負荷をかけることなく 数千のファイルを迅速にアップロード しながら、最終的な永続性を得ることができます。Arweave のツールエコシステムには、 Arweave Deploy CLI や、Arweave 上でファイル管理を行うためのユーザーフレンドリーなアプリ ArDrive も含まれています。 Permaweb (パーマウェブ) の概念は Web アプリのホスティングにも及び、開発者は Ardor や Web3 バンドラーなどのツールを介して HTML/JS を Arweave にデプロイし、永続的な URL で利用できるようにできます。Arweave のドキュメントは広範で、アップロードの価格設定方法 (計算機も存在します)、データの取得方法 (ゲートウェイ経由または軽量ノードの実行)、およびコミュニティ作成の 「クックブック」 などを網羅しています。学習曲線の一つは、トランザクション署名のための ウォレットキー の取り扱いです。Arweave は開発者が管理する RSA ベースのキーを使用します (Web ウォレットやクラウドキー管理ソリューションも存在します)。全体として、 信頼性の高い SDK、シンプルな REST 風インターフェース (GraphQL)、およびコミュニティツール により、Arweave が成熟するにつれて開発者体験は向上しています。注目すべき点として、ユーザーは AR で支払う必要があるため、開発者は暗号資産の支払いフローを統合する必要があります。一部の開発者は、ユーザーのために事前支払いをしたり、クレジットカードを受け付けて AR に変換するサードパーティサービスを利用したりすることで、この問題を解決しています。
• Pinata の開発者体験 (IPFS): Pinata は開発者を念頭に置いて構築されています。そのスローガンは 「数分で IPFS ファイルのアップロードと取得を追加」 であり、 シンプルな REST API と堅牢な JavaScript SDK を提供しています。例えば、Node.js を使用する場合、開発者は npm install @pinata/sdk を実行し、 pinata.pinFileToIPFS(file) や新しい pinata.upload メソッドを使用して Pinata のサービス経由で IPFS にファイルを保存できます。SDK は認証 (Pinata は API キーまたは JWT を使用) を処理し、IPFS ノードの実行を抽象化します。Pinata のドキュメントは明確で、ファイルのアップロード、CID によるピン留め (コンテンツがすでに IPFS 上にある場合)、ピンの管理 (ピン留め解除、ステータスなど) の例が記載されています。また、 コンテンツゲートウェイ もサポートしています。開発者はカスタムサブドメイン (例: myapp.mypinata.cloud) を使用して HTTP 経由でコンテンツを配信でき、 CDN や画像最適化 機能も組み込まれています。これにより、開発者は IPFS に保存された画像を、Cloudinary や Imgix を使用する場合とほぼ同じように扱うことができます (Pinata の画像最適化機能は、URL パラメータを介して即座にサイズ変更や切り抜きが可能です)。Pinata は最近、 「Pinata KV」 (JSON やメタデータ用のキーバリューストレージ、ファイルストレージと併用すると便利) や アクセス制御 (コンテンツを公開または制限付きに設定) などの機能を導入しました。これらの上位レベルの機能により、完全なアプリケーションの構築が容易になります。さらに、Pinata は IPFS とのインターフェースに過ぎないため、開発者は 移行の柔軟性 を維持できます。IPFS は相互運用可能であるため、Pinata 経由でピン留めされた CID をいつでも取得して、他の場所 (または独自のノード) でピン留めすることができます。Pinata のサポート (ガイド、コミュニティ) は高く評価されており、Protocol Labs と提携して NFT.Storage からの移行などのイニシアチブにも取り組んでいます。暗号資産に一切触れたくない人にとって、Pinata は理想的です。ブロックチェーンを統合する必要はなく、シンプルな API 呼び出しとクレジットカードだけで済みます。その反面、Pinata の可用性とサービス品質に依存するため、 統合自体の分散性は低くなります (ただし、コンテンツは依然としてハッシュアドレス指定され、IPFS 上で複製可能です)。要約すると、Pinata は 優れた DX (開発者体験) を提供します。セットアップが簡単で、包括的なドキュメント、SDK、および IPFS の複雑さを抽象化する機能 (ゲートウェイ、CDN、分析) が備わっています。
• Filecoin の開発者体験: Filecoin を直接使用するのは複雑な場合があります。伝統的には Filecoin ノード (Lotus など) を実行し、セクター、ディール、マイナーなどの概念を扱う必要がありました。しかし、エコシステム内では、これを簡素化するために多くの 開発者向けサービスやライブラリ が作成されています。特に、Protocol Labs による web3.storage や NFT.storage を使用すると、開発者は FIL トークンやディールの仕組みを扱うことなく、Filecoin のバックアップ付きで IPFS にデータを保存できます。これらのサービスは (Pinata に類似した) シンプルな API を提供します。例えば、NFT プロジェクトは NFT.storage の API を呼び出して画像とメタデータをアップロードでき、NFT.storage はそれを IPFS でピン留めした上で、複数のマイナーと Filecoin ディールを締結して長期保存します。これらはすべて無料 (PL による助成) で提供されており、NFT 分野での開発者の採用において画期的なものとなりました。それ以外にも、 Estuary 、 Powergate (Textile 製)、 Glacier など、Filecoin ストレージへの開発者フレンドリーなゲートウェイを提供するツールがあります。また、2023 年にローンチされた Filecoin Virtual Machine (FVM) を中心としたエコシステムも成長しており、Filecoin 上でスマートコントラクトを実行できるようになりました。開発者は Filecoin ブロックチェーン上で動作するプログラムを作成できるようになり、 データ中心の dApp (自動更新ストレージディールや、取得のインセンティブ化など) の可能性が広がっています。基本的な保存と取得に関しては、ほとんどの開発者が上位の IPFS レイヤーを使用するか (Filecoin を 「コールドストレージ」 バックアップとして扱う)、ホストされたソリューションを使用します。Filecoin はオープンなネットワークであるため、多くの サードパーティサービス が存在します。例えば、 Lighthouse.storage は、Filecoin 上に構築された 「一度の支払いで永久に保存」 できるサービスを提供しています (前払いの手数料を徴収し、Arweave に似た基金の概念を使用していますが、Filecoin ディールを通じて実装されています)。より詳細な制御を求める開発者のために、Filecoin のドキュメントにはネットワークと対話するためのライブラリ (Go、JavaScript など) が提供されており、 Slate (ユーザー向けストレージアプリ構築用) や Space (Fleek の Filecoin + IPFS ユーザーストレージ SDK) などのフレームワークも存在します。Pinata や Storj よりも学習曲線は高く、特に低レイヤーを扱う場合は、開発者はコンテンツアドレッシング (CID)、ディールのライフサイクルを理解し、高速な取得のために IPFS ノードを実行する必要があるかもしれません。 IPFS のドキュメント では、IPFS と Filecoin は補完的であると強調されています。実際、Filecoin を使用する開発者は、アプリ内での実際のデータアクセスのために、ほぼ常に IPFS と組み合わせて使用します。そのため、実質的に Filecoin の開発者体験は、永続性のための追加ステップを伴う IPFS の開発者体験となることが多いです。エコシステムは巨大で、2022 年時点で 330 以上のプロジェクトが Filecoin/IPFS 上に構築 されており、NFT、Web3 ゲーミング、メタバースストレージ、ビデオなど多岐にわたります。これは、コミュニティの事例やサポートが豊富であることを意味します。要約すると、 Filecoin の DX はターンキー型 (NFT.storage) から高度にカスタマイズ可能なもの (Lotus や FVM) まで多岐にわたります 。強力ですが複雑になる可能性もありますが、無料の IPFS + Filecoin ストレージサービスの利用により、多くの一般的なユースケースでの採用が容易になっています。
• Storj の開発者体験: Storj DCS は、 従来のオブジェクトストレージのドロップイン置換 として位置付けられています。 S3 互換 API を提供しているため、開発者はエンドポイントを Storj のゲートウェイに向けるだけで、使い慣れた AWS S3 SDK やツール (boto3 など) を使用できます。これにより、S3 で動作する事実上すべてのソフトウェア (バックアップツール、ファイルブラウザなど) が最小限の設定変更で Storj と連携できるため、導入の障壁が大幅に低くなります。Storj 独自のインターフェースを好む開発者向けには、ライブラリ (Go、Node、Python など) と uplink と呼ばれる CLI が提供されています。storj.io および storj.dev のドキュメントは徹底しており、一般的なタスク (アップロード、ダウンロード、共有、アクセス権限の設定) のサンプルコードが含まれています。ユニークな機能の一つは、Storj の アクセスグラントトークン (access grant tokens) です。これは暗号化キーと権限をカプセル化するセキュリティメカニズムであり、クライアント側の信頼を可能にします。開発者は、ルートキーを公開することなく、アプリに埋め込むための限定的な権限トークン (特定のバケットへの読み取り専用アクセスなど) を作成できます。これは、共有可能なリンクやネットワークへのクライアント側からの直接アップロードを作成するのに開発者にとって便利です。Storj の ダッシュボード は使用状況の監視に役立ち、 サポートリソース (コミュニティフォーラム、Slack/Discord) は開発者とノードオペレーターの両方で活発です。サードパーティサービスとの統合ガイドも存在します。例えば、 FileZilla (FTP クライアント) は Storj を統合しており、ユーザーは通常のサーバーと同じようにファイルを Storj にドラッグアンドドロップできます。人気のコマンドライン同期ツールである Rclone も標準で Storj をサポートしており、開発者は Storj をデータパイプラインに簡単に組み込むことができます。Storj は暗号化を自動的に処理するため、開発者が自身で実装する必要はありません。ただし、これはキーを紛失した場合に Storj がデータを復元できないことを意味します (ゼロトラストセキュリティのためのトレードオフです)。パフォーマンス面では、小さなファイルを大量にアップロードする場合、セグメント手数料や消失訂正符号 (erasure coding) によりオーバーヘッドが発生することに気づくかもしれません。そのため、小さなファイルをまとめるか、マルチパートアップロード (クラウドストレージを使用する場合と同様) を使用するのがベストプラティスです。クラウドストレージの概念に慣れている人にとって 学習曲線は非常に緩やか であり、多くの開発者がそうです。Storj は意図的に AWS の開発者体験 (SDK、ドキュメント) を可能な限り模倣しつつ、分散型のバックエンドを提供しています。本質的に、 Storj は暗号化と分散化の利点を備えた、馴染みのある DX (S3 API、十分に文書化された SDK) を提供します 。これにより、分散型ストレージオプションの中で最もスムーズなオンボーディング体験の一つとなっています。
• Sia の開発者体験: 歴史的に、Sia はマシン上で Sia クライアント (デーモン) を実行する必要があり、それがアップロードとダウンロードのためのローカル API を公開していました。これは管理可能ではありましたが、クラウド API ほど便利ではなく、開発者はスタック内に Sia ノードを組み込む必要がありました。Sia チームとコミュニティは使いやすさの向上に取り組んできました。例えば、 Sia-UI は手動でファイルをアップロードするためのデスクトップアプリであり、ローカルノードと対話するための sia.js のようなライブラリも存在します。しかし、より大きな DX の向上は、2020 年に導入された Skynet によってもたらされました。Skynet により、開発者はノードを実行することなく パブリック Web ポータル (siasky.net、skyportal.xyz など) を使用してデータをアップロードできるようになりました。これらのポータルが Sia とのやり取りを処理し、 Skylink (コンテンツハッシュ/ID) を返します。これを使用して、任意のポータルからファイルを取得できます。これにより、Sia ストレージの使用は HTTP API を使用するのと同じくらい簡単になりました。Skynet ポータルにファイルを curl してリンクを取得するだけです。さらに、Skynet は (Arweave のパーマウェブと同様に) Web アプリのホスティングを可能にしました。開発者は SkyID (分散型アイデンティティ)、SkyFeed (ソーシャルフィード)、さらにはアプリマーケットプレイス全体などの dApp を Skynet 上に構築しました。開発者の観点からは、Skynet の導入により Siacoin、コントラクト、またはノードの実行について心配する必要がなくなり 、コミュニティが運営するポータル (無料のものも商用もあり) に重労働を任せることができました。これを Web アプリに統合するための SDK (SkyNet JS など) もありました。しかし、課題として、Skynet の主要な支援者であった Skynet Labs が資金不足により 2022 年に閉鎖されました。コミュニティと Sia Foundation はその概念を存続させるために取り組んでいます (ポータルコードのオープンソース化など)。2025 年現在、Sia の開発者体験は二極化しています。最大限の分散化を求めるなら、Sia ノードを実行し、SC (Siacoin) とコントラクトを扱います。これは強力ですが、比較的低レイヤーです。使いやすさを求めるなら、 Filebase のようなゲートウェイサービス や Skynet ポータル (利用可能な場合) を使用してそれを抽象化します。例えば、 Filebase は S3 互換 API を提供するサービスですが、実際にはデータを Sia (および現在は他のネットワーク) に保存します。そのため、開発者は Storj や AWS を使うように Filebase を使用でき、その裏側で Sia のメカニズムが処理されます。ドキュメントに関しては、Sia はドキュメントを改善し、活発なコミュニティチャンネルを持っています。また、開発者がネットワークの状態を把握できるように、 ホストランキング (HostScore) やネットワーク統計 (SiaStats/SiaGraph) も提供しています。Sia におけるもう一つの新しい取り組みは S5 プロジェクトです。これは Sia ストレージを IPFS のようなコンテンツアドレッシング方式 (S3 との互換性も維持) で提示することを目指しており、開発者の対話を合理化するための継続的な努力を示しています。全体として、Sia の DX はブロックチェーンと通貨を扱う必要があるため、歴史的に他のものより遅れていましたが、Skynet やサードパーティの統合により容易になりました。 プライバシーと制御を重視する開発者は、多少の努力で Sia を使用でき、他の開発者は Sia の上に構築されたサービスを利用してスムーズな体験を得ることができます。
• Ceramic の開発者体験: Ceramic は、特にソーシャル機能、アイデンティティ、または動的なコンテンツを構築する Web3 dApp 開発者をターゲットにしています。開発者は、 Ceramic ノードを実行するか、ホストされたノード (3Box Labs やコミュニティプロバイダーが提供) を使用して Ceramic と対話します。重要な概念は、Ceramic のセマンティックデータレイヤーである 「ComposeDB」 です。開発者はアプリケーションのデータの データモデル (スキーマ) を定義し (例: 名前やアバターを持つプロファイルモデル)、 GraphQL クエリ を使用してそのデータを Ceramic から保存・取得できます。本質的に、Ceramic はグローバルで分散型のデータベースを使用しているような感覚です。Ceramic チームはアプリケーションの立ち上げを支援する CLI と SDK を提供しています。例えば、データモデルを管理するための glaze/JS や、ユーザーが自身の暗号資産ウォレット/DID で認証してデータを制御するためのアイデンティティ SDK である self.id などがあります。比較的新しいプロジェクトであるため、ツールはまだ進化の途上ですが、しっかりとしたドキュメントがあり、(ソーシャルネットワーク、ブログプラットフォーム、認証情報ストレージなどの) サンプルアプリも増えています。Ceramic DX の重要な部分は DID (分散型 ID) の統合です。データのすべての更新は DID によって署名されます。これには、3Box Labs がストリーム全体でユーザーのアイデンティティデータを管理するために構築した IDX (Identity Index) がよく使用されます。開発者にとって、これは did-js のようなライブラリを組み込んで (通常は Ceramic の did:3 メソッドを使用して DID を提供する Ethereum ウォレットを介して) ユーザーを認証することを意味します。認証されると、そのユーザーのデータを Ceramic ストリームで通常のデータベースのように読み書きできます。ここでの学習曲線は、分散型アイデンティティと、テーブルではなくストリームという概念を理解することです。しかし、Web 開発に慣れている人なら、ComposeDB の GraphQL による抽象化は非常に自然に感じられるでしょう。例えば、ブログアプリのすべての投稿を Ceramic に照会する場合、Ceramic ノードが関連するストリームを確認して解決する GraphQL クエリを使用できます。 Ceramic のドキュメント では 「仕組み」 が解説されており、Ceramic は 大きなファイル用ではない ことが強調されています。むしろ、大きなメディアについては IPFS や Arweave への参照を保存し、メタデータ、インデックス、およびユーザー生成コンテンツに Ceramic を使用します。実際には、dApp はユーザープロファイルやコメントなどのために Ceramic を使用し (これによりプラットフォーム間で更新や共有が可能になります)、画像やビデオのような大きなファイルには Filecoin/IPFS を使用します。Ceramic 周辺の コミュニティ は活発で、ハッカソンや助成金制度もあり、 Orbis (Ceramic 上に構築された分散型 Twitter 風プロトコル) のようなツールはソーシャル機能のためのより高度な SDK を提供しています。要約すると、Ceramic は ハイレベルな Web3 ネイティブの DX を提供します。開発者は DID、モデル、GraphQL を扱いますが、これは低レイヤーのストレージ管理とは大きく異なり、分散型の Firebase や MongoDB 上で構築する感覚に近いです。変更可能で相互運用可能なデータを必要とするユースケースにとって、開発者体験は最先端 (多少の不安定さはあるかもしれませんが) であり、それ以外のケースでは不必要な複雑さになる可能性があります。

4. ユーザーの採用と利用指標​

分散型ストレージの採用状況を評価するには多角的な視点が必要です。具体的には、 保存されたデータ量、ユーザー / 開発者数、注目すべきユースケースやパートナー、そして市場シェア を考慮します。以下に、各プロジェクトの主要な採用指標と事例をまとめました。

• Arweave の採用: 2018 年に立ち上げられた Arweave のネットワークは、 Filecoin と比較すると総データ保存量は少ない ものの、 永久保存（permanent storage） という重要なニッチを確立しています。2023 年初期時点で、約 140 TB のデータ が Arweave のパーマウェブ（permaweb）に保存されていました。これは Filecoin よりも数桁少ない量ですが、Arweave はこのデータが完全に支払済みであり、永久に保存されることを強調しています。成長率は安定しており、開発者やアーカイブプロジェクトは、ウェブページ（例：分散型ウェイバックマシンのような「archivist」コミュニティ経由のウェブページ保存）から ブロックチェーンの履歴 （例えば Solana ブロックチェーンは履歴データのオフロードに Arweave を使用）まで、さまざまなデータを提供しています。採用における大きな節目として、 Meta (Facebook) が 2022 年に Instagram の NFT デジタルコレクティブルメディア を永久保存するために Arweave を統合したことが挙げられます。これは、Web2 の巨人が Arweave の永続性を信頼したことを示しています（後に Meta は NFT イニシアチブを停止しましたが、不変のストレージとして Arweave を選択した事実は変わりません）。ブロックチェーンの世界では、 Solana の NFT プラットフォーム Metaplex が NFT のメタデータとアセットの保存に Arweave を使用しており、Solana で人気の Candy Machine 標準はメディアを自動的に Arweave にアップロードして永続性を確保します。その結果、 数百万の NFT が（多くの場合 arweave.net を介して）Arweave の URI を参照しています。別の例として、Web3 アーカイブプロジェクトである KYVE は、Arweave 上でメインネットを立ち上げ、2023 年後半までに 2,000 TB (2 PB) 以上のデータ を Arweave にアップロードしました。これは非常に大規模であり、他のブロックチェーンのスナップショットやデータセットが含まれています。Arweave のエコシステムには 数百人の開発者 が存在します。公式サイト Ar.io によると、2023 年 1 月までにストレージを維持するための基金として 44,000 AR 以上が蓄積されています。ソーシャル指標では、Arweave のコミュニティは NFT クリエイターやアーカイブ愛好家の間で強力です。「パーマウェブ」という言葉は、NFT アートワーク、ウェブコンテンツ（例：mirror.xyz は分散型ブログ投稿を永久に保存するために Arweave を使用）、さらにはパーマウェブベースのアプリケーション（メール、フォーラム）の保存と同義になっています。Arweave は主要な暗号資産 VC からの支援を受けており、創設者の Sam Williams はデータの永続性を提唱する著名な人物です。生のバイト数では最大ではありませんが、Arweave の採用は 影響力が高い のが特徴です。保証された永続性が必要なあらゆる場所で使用されています。また、多くの Web3 スタック に間接的に統合されています（例えば、 Ledger のハードウェアウォレット は一部の NFT プロバンスデータの保存に Arweave を使用しており、 The Graph インデックスプロトコルはサブグラフデータの保存に Arweave を使用できます）。要約すると、Arweave の採用は NFT およびブロックチェーンメタデータの分野 、永久ウェブアーカイブで強力であり、長期記録に対する企業の関心も高まっています。現在のネットワーク利用量（140 TB 以上）は小さく見えるかもしれませんが、各バイトは永遠に残ることを意図しており、利用は加速しています。
• Pinata と IPFS の採用: IPFS は、誰でも無料でオープンに使用できるため、純粋な数値で見ればおそらく最も広く採用されている分散型ストレージ技術です。誰でもノードを実行してコンテンツを追加できるため、IPFS の「ストレージ量」を測定するのは困難ですが、Web3 の世界では至る所に普及しています。 Pinata は、主要な IPFS ピニングサービスの一つとして、開発者による IPFS の利用状況を垣間見せてくれます。Pinata のウェブサイトでは「 600,000 人以上の開発者に信頼されている 」と謳われており、これはその人気を反映した巨大な数字です。2021 年の NFT ブーム時に多くのプロジェクトが NFT アセットのホストに Pinata を使用したことで、この数字はさらに押し上げられたと考えられます。Pinata の無料プランを使用する個人アーティストから、コンテンツ配信のために Pinata を統合する大手 NFT マーケットプレイスまで、このサービスは業界標準となっています。NFT.Storage チームは 2023 年に、「 Pinata は 2018 年以来、IPFS コミュニティで信頼される名前であり、多くのトッププロジェクトやマーケットプレイスを支えてきた 」と述べています。これには、有名な NFT プラットフォーム、ゲーム開発者、さらには IPFS 経由でフロントエンドアセットを提供する必要があった一部の DeFi プロジェクトも含まれます。例えば、 OpenSea（最大手の NFT マーケットプレイス） は、保存されている多くのアセットに IPFS を使用しており、コンテンツの可用性を確保するために NFT クリエイターに Pinata などのピニングサービスを推奨することもありました。多くのプロフィール写真（PFP）NFT コレクション（CryptoPunks の派生作品から Ethereum 上の無数のジェネレーティブアートセットまで）は、画像に IPFS の CID を使用しており、トークンのメタデータに Pinata のゲートウェイ URL が含まれていることは一般的です。Pinata はピニングされたデータの総統計を公開していませんが、逸話的には 数ペタバイトの NFT データ のピニングを担当しているとされています。別の側面として、IPFS は ウェブブラウザ （Brave、Opera）に統合されており、グローバルなピアネットワークを持っています。その中での Pinata の役割は、コンテンツホスティングのための信頼できるバックボーンとしてのものです。IPFS はセルフホストで無料で使用できるため、Pinata の膨大なユーザー数は、多くの開発者がその利便性とパフォーマンスを好んでいることを示しています。Pinata はメディアやエンターテインメント業界にも企業ユーザーを抱えています（例えば、一部の音楽 NFT プラットフォームは音声コンテンツの管理に Pinata を使用していました）。IPFS の採用は Pinata に留まらず、 Infura の IPFS サービス 、 Cloudflare の IPFS ゲートウェイ 、その他（Temporal、Crust など）の競合他社も貢献していますが、Pinata はその中でも最も著名な存在の一つです。要約すると、 IPFS は Web3 において遍在的 であり、Pinata の採用はその遍在性を反映しています。これは NFT や dApp コンテンツのバックボーンであり、数十万人のユーザーを抱え、世界中のプロダクションアプリに統合されています。
• Filecoin の採用: Filecoin は、 生のストレージ容量という点で最大の普及 を見せています。ネットワーク内には 22 エクサバイト（22,000,000 TB 以上）の利用可能なストレージ があると報告されており、そのうち約 3%（660 PB 以上）が 2023 年半ばまでに利用 されていました（比較として、この利用済みストレージ量は Arweave の 3 桁以上上回っており、Filecoin がビッグデータに焦点を当てていることを示しています）。この容量の多くは大規模なマイナーによるものですが、Filecoin Plus などのプログラムにより、 有用な 保存データも大幅に増加しました。2022 年初頭までに 45 PiB （約 45,000 TB）の実データが保存され、大規模なアーカイブがデータを取り込むにつれて、それ以降さらに成長していると考えられます。ユーザーの面では、Filecoin の採用は エコシステムプロジェクト によって支えられています。例えば、NFT.storage（内部で Filecoin を使用）には、2023 年時点で 1 億 5,000 万以上の NFT アセット がアップロードされています。多くの NFT マーケットプレイスが NFT.storage や同様のサービスに依存しており、間接的に Filecoin をそれらの NFT のバックエンドにしています。 Web3.storage （アプリ向けの一般的な IPFS / Filecoin ストレージ）は数万人のユーザーを抱え、Web3 ゲームやメタバースコンテンツなどのアプリケーションのデータを保存しています。特に、Filecoin は 企業や機関とのパートナーシップ を獲得しています。 カリフォルニア大学バークレー校 と提携して研究データを保存し、 ニューヨーク市政府 と提携してオープンデータセットを保存し、 Seagate （企業向けバックアップソリューションとして Filecoin を検討しているハードドライブメーカー）や Ernst & Young (EY) と提携してビジネスユースケースでの分散型ストレージを推進しています。 OpenSea も Filecoin のクライアントになり、NFT データのバックアップに使用しています。これらの著名なクライアントは、Filecoin のモデルに対する信頼を示しています。さらに、プロジェクト数で見ると、2022 年後半までにビデオプラットフォーム（例：VideoCoin、Huddle01）から DeFi オラクルデータのアーカイブ、科学データリポジトリ（Starling プロジェクト経由のショア財団のホロコーストアーカイブ）まで、 600 以上のプロジェクトや dApp が Filecoin / IPFS 上に構築 されました。Filecoin のブロックチェーンは、世界中に 3,900 以上のストレージプロバイダー の幅広いコミュニティを持っており、地理的に最も分散化されたインフラの一つとなっています。しかし、Filecoin のユーザー採用は、その複雑さによって時に和らげられることがあります。多くのユーザーは、より簡単な IPFS レイヤーを介してやり取りします。それでも、FVM（Filecoin Virtual Machine）の登場と、 完全なクラウドプラットフォーム（ストレージ + コンピューティング）としての Filecoin への推進により、開発者や企業の関心は加速しています。要約すると、 Filecoin は容量と企業への関与においてリード しています。規模の面では 随一の 分散型ストレージネットワークであり、その容量の多くはまだ未利用ですが、価値のあるコンテンツ（オープンサイエンスデータ、Web2 アーカイブ、Web3 アプリデータ）で埋めるための取り組みが進んでいます。エクサバイト規模を処理できる証明された能力は、需要が追いつけば、伝統的なクラウドストレージを破壊する強力な候補となります。
• Storj の採用: Storj は、 Web2 と Web3 のハイブリッドなユースケース（特にメディア分野） をターゲットにすることで着実に成長してきました。ネットワークは 100 か国以上 に広がる約 13,000 以上のストレージノード （自宅やデータセンターで Storj ソフトウェアを実行する個別のオペレーター）で構成されており、強力な分散化を実現しています。顧客側では、Storj はメディアや IT 分野で エンタープライズパートナーシップ を獲得しています。例えば、 Videon の LivePeer （ビデオストリーミング）は Storj を使用してライブビデオのチャンクを世界中に配信しており、 Fastly の Compute@Edge はアセット保存のために Storj と提携しました。また、ウェブサイトにあるように、Storj は Cloudwave 、 Caltech（カリフォルニア工科大学） 、 TrueNAS 、 Vivint 、および複数のメディア制作会社などの組織から 信頼されています 。 Caltech （主要な研究大学）の存在は科学データストレージでの利用を示唆し、 Vivint （スマートホーム企業）は IoT やカメラ映像のストレージを示唆しており、多様な現実世界のアプリケーションが存在します。Storj は、メディアワークフローにおけるソリューションとして、 NAB（全米放送事業者協会）の Product of the Year 2025 を受賞するなど、業界で高く評価されています。彼らはケーススタディを強調しています。例えば、 Inovo は Storj を使用して数百万人のユーザーにコスト効率よくビデオを配信しており、 Treatment Studios はグローバルなビデオコラボレーションに Storj を使用し、 Ammo Content は Storj のネットワークを介して 3,000 万時間以上 のコンテンツをストリーミングしました。これらの例は、Storj が 高帯域幅かつ大容量のコンテンツ配信 を処理できることを示しており、重要な証明となっています。開発者の採用も顕著で、2022 年までに 20,000 人以上の開発者 が Storj DCS のアカウントを持っていました（Storj の統計レポートより）。オープンソースコミュニティは、統合において Storj を受け入れています（前述のように、FileZilla、ownCloud、Zenko など）。Storj はトークンで報酬を支払うため、ノードオペレーターの関心は高く、需要のためにノードになるための待機リストができることもあります。保存データ量に関しては、Storj は最近の総ペタバイト数を公表していませんが、数ペタバイトに達しており、特に最近の Web3 空間への進出により急速に成長していることが知られています。Filecoin の生の数字には及ばないかもしれませんが（Storj は容量だけでなく アクティブな データに焦点を当てているため）、データ数で見れば最大規模の 暗号化された クラウドストレージネットワークである可能性があります。Storj のマルチリージョンで CDN のようなパフォーマンスは、純粋にコストパフォーマンスのメリットから Web2 ユーザーを惹きつけています（分散型であることを気にせず、単に 80% のコスト削減を享受しているユーザーもいます）。伝統的な業界へのこの「トロイの木馬」的なアプローチは、典型的な暗号資産の枠を超えて採用が広がる可能性があることを意味します。全体として、 Storj の採用はメディアストリーミング、バックアップ、開発者ツールにおいて強力 です。分散型サービスが企業の SLA を満たせることを証明しています（これは 11 9s の耐久性や、バックアップソリューションのための Evergreen のような企業との提携に反映されています）。分散型 クラウド GPU の提供への転換により、Storj はより広範な分散型クラウドプロバイダーとしての地位を確立しようとしており、これがさらなる採用を促進する可能性があります。
• Sia の採用: Sia は 2015 年に開始された最も古いプロジェクトの一つですが、その採用の軌跡は比較的緩やかです。2024 年第 3 四半期時点で、Sia のネットワークには 2,310 TB (2.31 PB) のデータ が保存されており、これは四半期で約 17% の増加であり、小規模ながらも利用が着実に成長していることを示しています。容量に対する利用率も向上しており、より多くのホストがビジネスを得ていることを示唆しています。Sia ネットワークは歴史的に、その低コストさから個人のバックアップ目的で使用する個人ユーザーが多く存在していました。技術に精通したユーザーが写真コレクションを保存したり、安価な「Backblaze の代替品」として Sia を運用したりする様子を想像してください。企業側では、Sia は Filecoin や Storj ほどパブリックなパートナーシップは見られません。これには、初期段階の UX や、Sia の親会社である Nebulous が（Web3 dApp やコンテンツホスティングをターゲットとした）Skynet にピボットしたことが一部影響しています。 Skynet の採用 は 2020 年から 2021 年にかけて有望であり、Web3 ソーシャルメディアエコシステム（例： SkyFeed は数千人のユーザーを抱えていた）を支え、一部の NFT プロジェクトもアートワークのホスティングに Skynet を使用していました（IPFS の代替として NFT メタデータに Skylink が表示されることがあります）。分散型音楽プラットフォームである Audius も、一部のコンテンツ配信で Skynet を試行しました。しかし、Skynet のメインポータルの閉鎖により、その勢いの一部はコミュニティの手に委ねられることになりました。現在は Sia Foundation （2021 年設立）が開発を主導しており、パフォーマンスや経済性の向上を図った Sia v2（2025 年のハードフォーク）を導入しました。これにより将来の採用が促進される可能性があります。エコシステムは比較的小規模です。Sia の統計によると、 Sia 上に構築されたプロジェクトは 32 件 （ユーザー向けアプリを除く）であり、成長を促進するために 2025 年までに 合計 320 万ドルの助成金 が割り当てられています。これには、 Filebase （バックエンドの一つとして Sia を使用）、 SiaStream （Sia 上のメディアストリーミングストレージ用）、および HostScore や SiaFS などのコミュニティツールが含まれます。Sia のコミュニティは小規模ながらも情熱的です。例えば、議会図書館の公開データを Sia に保存する注目すべきユーザー主導の活動がありました。Sia の ホスト数 は数百（Storj のような数千ではない）であり、その多くは企業レベルのセットアップ（データセンターノード）を提供しています。なぜなら、非常に安価なストレージを提供できない限り、ホストとしての収益性は低いためです。要約すると、 Sia の採用はニッチですが安定しています 。低コストのクラウドストレージとしてコアコミュニティに使用され、分散型ウェブコンテンツをホストするために一部の Web3 プロジェクトに使用されています。その利用量（2 PB 以上保存）は無視できないものですが、Filecoin には大きく遅れをとっています。しかし、Sia は 非営利かつコミュニティ主導 であるという点で差別化されており、分散化の理念を優先する人々に共鳴しています。進行中の改善（Sia v2）と「世界で最も安全なクラウド」であることへの焦点は、自己主権型データを重視するユーザーをさらに惹きつける可能性があります。
• Ceramic の採用: Ceramic はデータやコンポーザブル（構成可能）なコンテンツに特化したネットワークであり、その採用は生のストレージ容量ではなく、開発者やアプリケーションによって測定されます。Ceramic のウェブサイト（2025 年）によると、 400 以上のアプリやサービス が Ceramic 上に構築されており、約 1,000 万のコンテンツストリーム を管理しています。これは、Web3 アプリ開発者の間で分散型データへの関心が高まっていることを示しています。Ceramic を使用している注目すべきプロジェクトには、 Orbis （Ceramic 上の Twitter のような分散型ソーシャルネットワーキングプロトコル）、 CyberConnect （当初 Ceramic の DID 上に構築されたソーシャルグラフプロトコル）、 Gitcoin （分散型ユーザープロフィールのために Ceramic を検討）、 Self.ID （ユーザーが dApp 間でプロフィールを管理するための ID ハブ）などがあります。さらに、Ceramic の 3ID を介した DID（分散型 ID）の採用 は顕著です。例えば、多くの Ethereum ベースのアプリケーションがユーザープロフィールの保存に Ceramic を活用していました（これにより、ユーザーのプロフィールを Uniswap、Boardroom、DAO 向けの Snapshot などの間で持ち運ぶことができました）。 NEAR Protocol がクロスチェーン ID のために Ceramic を統合 するなどの提携もあり、レイヤー 1 ブロックチェーンが Ceramic をオフチェーンユーザーデータのソリューションとして見ていることを示しています。別の分野は DeSci（分散型科学） です。研究メタデータや実験ノートなど、データの共有や検証が必要だが不変である必要はない（更新が必要な）データの保存にプロジェクトが Ceramic を使用しています。3Box Labs（Ceramic の創設チーム）が最近 Textile （IPFS / Filecoin ツールで知られるチーム）と合流したことも注目に値します。これは力を合わせる努力を示唆しており、データインフラ分野における Ceramic のリーチを広げる可能性があります。 アクティブな Ceramic ノード数 は公開されていませんが、多くのアプリが独自のノードを運営するか、コミュニティノードを使用しています。全体像として、Ceramic は比較的新しく、「データバース（dataverse）」という概念はまだ浸透の途上にあります。まだ誰もが知るような企業ユーザーはいませんが、既存のストレージネットワークでは十分に提供できない領域（ソーシャルメディアコンテンツやアプリ間のデータ相互運用性など）で 草の根的な Web3 の採用 が進んでいます。ベンチマークとして、各ストリームをデータの一部と見なすと、1,000 万ストリームは相当な量ですが、多くのストリームは（ユーザーのプロフィール文書や単一の投稿のように）非常に小さいものです。注目すべき指標は、これら 400 のアプリがどれだけの最終ユーザーをもたらすかであり、分散型ソーシャルネットワークのようなアプリがスケールすれば、潜在的には数十万人に達する可能性があります。要約すると、 Ceramic の採用は Web3 開発コミュニティにおいて有望 （数百のアプリ、さまざまな Web3 エコシステムへの統合）ですが、本質的に特定のユースケースに限定されており、ストレージサイズやスループットの面で Filecoin や Arweave と競合するものではありません。

採用状況を可視化するために、以下の表にいくつかの指標と注目すべき採用者をまとめました。

5. エコシステムの成熟度とアクティビティ​

単なる利用状況を超えて、サードパーティツール、統合、資金調達、コミュニティ活動を含む各エコシステムの成熟度は、長期的な生存可能性を評価する上で極めて重要です。

• Arweave エコシステム: Arweave のエコシステムは、その規模の割に非常に強固です。インフラ面では、多くのプロジェクトが Arweave の機能を強化しています。前述の Bundlr (Iris) は、バンドリングノードのネットワークを運営し、独自の資金調達を行って Arweave のスループットを拡大しました（2023 年後半までに 10 億件以上のバンドルされたトランザクション を処理）。ArDrive は、Arweave 上で Dropbox のような体験を提供する人気のユーザー向けアプリです。2023 年に完全に分散化され、大容量ファイルのサポートなどの機能を備えた 2.0 をリリースしました。EverPay と Warp は、Permaweb（パーマウェブ）をベースレイヤーとして使用することで、レイヤー 2 スタイルの即時決済やスマートコントラクトのような機能を Arweave 上で実現しています（Arweave 自体は従来のスマートコントラクトをサポートしていませんが、これらのプロジェクトは契約状態を保存し、相互作用を可能にします）。2024 年、Arweave は 「Atomic Oasis (AO) Compute」 を導入しました。これは Arweave 上に構築された compute-over-data（データ上の計算） ネットワークであり、データ可用性に Arweave を使用しながら、並列オンチェーン計算を可能にします。これにより、本質的に Arweave は（Filecoin が FVM で計算機能を追加しているのと同様に）クラウドコンピューティングの領域に進出しており、将来を見据えたロードマップを示しています。資金面では、Arweave は強力な支援を受けています。a16z や Union Square Ventures などから 3,730 万ドル を調達し、継続的な開発のための資金を確保しています。コミュニティは、利益共有トークン (PST) システムを通じて活発に関与しています。開発者は Permaweb アプリ用に PST を作成でき、保有者は手数料の分配を受ける権利を得るため、アプリ開発のインセンティブとなっています。Decent.land（Arweave 上の分散型ソーシャルプロファイル）から CommunityXYZ（Arweave PST 用の DAO プラットフォーム）まで、多数の Permaweb アプリ が稼働しています。Arweave は基金のための DAO 型ガバナンス も備えており、意思決定にコミュニティが関与しています。ネットワークは主要なアップグレード（2022 年の SPoRA コンセンサスアップグレードなど）をスムーズに完了しています。統合に関しては、Arweave は他のチェーンとも統合されています。Ethereum、Polkadot、Avalanche のスマートコントラクト は、大規模なデータやメタデータの保存に Arweave を使用しています（多くの場合、Arweave ↔ Ethereum ブリッジ や The Graph のインデックス作成を介しています）。Lens Protocol（Polygon 上の Web3 ソーシャル）は、永続的な投稿保存のオプションとして Arweave を提供しています。Arweave と Solana の提携は深く、本質的に Solana のアーカイブレイヤーとして機能しています。また、Solana の新しいスマートフォン (Saga) では、モバイル dApp のコンテンツを永続的に保存するために Arweave が使用されることが言及されました。全体として、Arweave のエコシステムは、専用のストレージアプリ、クロスチェーン統合、さらには計算のような新しい垂直分野の探索により、活発に成長 しています。コミュニティ文化は「Permaweb」の使命を中心に据えており、それは価値のあるデータセットのストレージコストを補助する Arweave Boost や、文化的データを保存するパートナーシップ（活動家によって保存されたウクライナ戦争の文書アーカイブなど）などの取り組みに表れています。これらすべての兆候は、Filecoin よりも規模は小さいものの、成熟したミッション主導型のエコシステム であることを示しています。
• Pinata / IPFS エコシステム: Pinata 自体は一企業のサービスですが、非常に広範な IPFS エコシステム の中に位置しています。Pinata のエコシステム活動には、パートナーシップ（NFT.storage との提携など）やクリエイタープラットフォームでの統合（一部の NFT ミンティングプラットフォームでは、ユーザーの利便性のために Pinata へのアップロード機能が組み込まれています）が含まれます。Pinata は自社製品の機能（KV ストレージ、プライベート IPFS、ゲートウェイプラグインなど）を拡張しており、基本的なピンニング以上の機能を提供する意欲を示しています。一方、IPFS 全体 には巨大なオープンソースコミュニティが存在します。独自のピンニングネットワークを構築するための IPFS-Cluster、IPFS 上に ThreadsDB などのツールを構築した Textile、Web アプリの IPFS ホスティングを提供する Fleek など、多くのプロジェクトが繁栄しています。IPFS が属する Protocol Labs のエコシステムには、libp2p（ネットワーク層）や Filecoin も含まれており、そこでの開発はしばしば IPFS に利益をもたらします（例：Filecoin Saturn による IPFS リトリーバルキャッシュ は新しい取り組みです）。成熟度の面では、IPFS はバージョン 0.15 以上に達しており、十分に実戦でテストされています。暗号資産以外の企業による IPFS の利用 も始まっています。例えば、NFL（アメリカンフットボールリーグ）は、帯域幅コストを削減するために IPFS を使用してビデオハイライトをファンに配信しました。Cloudflare の IPFS ゲートウェイは、Web2 企業が IPFS への橋渡しに関心を持っていることを示しています。定期的に発行される IPFS の RFC や学術研究 も、それが確立されたプロトコルであることを証明しています。サポートに関しては、無数のライブラリ（Go、JS、Python、Rust の IPFS 実装）が存在します。IPFS は現在、コンテンツアドレッシングの事実上の標準となっています。Pinata は、使いやすいレイヤーを提供することで、この成熟したエコシステムの恩恵を受けています。歴史的な課題の一つは IPFS 上の発見可能性（コンテンツアドレッシングは検索機能を提供しない）でしたが、IPFS 検索エンジン やピンニングサービスインデックス などのエコシステムツールが作成されており、Pinata もそれらのネットワークに参加している可能性があります。Pinata が NFT に特化したサポート（NFT 開発者向けの専用ガイドやケーススタディなど）へ移行したことは、ユーザーのニーズへの適応を示しています。また、コミュニティイベント（ハッカソンのスポンサーなど）にも積極的に参加しています。総括すると、IPFS のエコシステムは非常に成熟しており（8 年以上の歴史、広範な採用）、Pinata はその分野における主要な商業プレーヤー として、他と良好に統合されています。Pinata 自身のエコシステムは、サードパーティの開発者が Pinata 上に構築するというよりも、大規模で成長を続ける顧客ベース（開発者やクリエイター） によって構成されています。しかし、IPFS のオープン性を考えればスイッチングコストは低く、Pinata は信頼性と使いやすさを提供することで競争力を維持しています。この競争環境には Infura や web3.storage などが含まれており、継続的な改善を促しています。要約すると、IPFS は分散型ストレージとして最高レベルの成熟度 に達しており、Pinata はその上で開発者の UX に焦点を当て、繁栄する相互運用可能なエコシステムにおいて頼りになるサービスであり続けるための機能を追加しています。
• Filecoin エコシステム: Filecoin のエコシステムは、分散型ストレージの中で最も活発で、潤沢な資金を持つと言えます。ローンチ以来、Protocol Labs と Filecoin Foundation は、スタートアップを育成するために多数のハッカソン（HackFS、Space Race など）やアクセラレータープログラム（Tachyon との Filecoin Launchpad など）を開催してきました。2022 年までに、330 以上のプロジェクト が Filecoin 上で構築されており、2025 年までには FVM により DeFi や新しいプリミティブが実現し、その数はさらに増加しています。重要な進展は、2023 年の Filecoin Virtual Machine (FVM) のローンチであり、これにより Filecoin に一般的なプログラム可能性（スマートコントラクト）がもたらされました。これにより、Filecoin DeFi（ストレージ取引のマーケットプレイス、トークン化されたストレージなど）、データ DAO（価値のあるデータを保存するために資金を出し合う分散型組織）、Ethereum dApp で Filecoin ストレージを使用するためのクロスチェーンブリッジなどのプロジェクトが誕生しました。さらに、リトリーバルマーケット（Lighthouse など）が構築されており、Filecoin に保存されたコンテンツをインセンティブ化されたノードが効率的に配信できるようになっています（IPFS を補完）。企業側では、前述のように Filecoin と主要企業（Seagate など）とのパートナーシップにより、エンタープライズツール のエコシステムが発展していることが示唆されています。例えば、IBM クラウドや他のストレージベンダーとのハイブリッドソリューションのための Filecoin 統合 などの話があります。Filecoin のガバナンスとコミュニティも注目に値します。Filecoin DAO（ガバナンス提案） が存在し、Filecoin Plus は、実際のデータを検証するコミュニティ選出の公証人（Notary）によって管理されています。これはこの分野独自の社会的信頼システムであり、成熟したガバナンスプロセスを示しています。ネットワークのトークノミクスは複雑ですが、数千のマイナーが参加して維持されており、健全な供給側を示しています。別のエコシステム構成要素として、Filecoin 上の L2 があります。Polybase や Tableland（分散型データベース）などのプロジェクトがデータ可用性のために Filecoin の使用を検討しており、Estuary は Filecoin 上でより簡単なストレージのための API を提供しています。Filecoin サイドチェーン（コンテンツ配信に焦点を当て、支払いに Filecoin を使用する Filecoin Saturn など）さえ存在します。Protocol Labs の研究チームは、技術の向上（プルーフパフォーマンスの改善、耐久性のための新しいコーディングスキームの探索など）に積極的に取り組んでいます。Filecoin Orbit ミートアップや年次の Sustainable Blockchain Summit（オープンデータとサステナビリティにおける Filecoin の役割を強調することが多い）などのコミュニティイベントは、エコシステムの活気をさらに強固なものにしています。資金面では、ICO に加えて、2022 年に Filecoin 上で構築されるプロジェクトに投資するための巨大な Filecoin エコシステムファンド（1 億ドル以上）が設立されました。ChainSafe（Filecoin ツール構築）、Open Forest Protocol（気候データの保存に Filecoin を使用）などの企業に注目すべき投資が行われました。まとめると、Filecoin のエコシステムは巨大で、資本力があり、急速に進化しています。単なるストレージを超え、本格的な分散型クラウド（ストレージ、リトリーバル、計算、さらにはデータベース）を目指しています。この広がりは成熟の証ですが、同時に複数のフロントで競争している（各ドメインの専門ネットワークと競合している）ことも意味します。しかし、IPFS とのシナジーや Protocol Labs の支援が強力な推進力となっています。
• Storj エコシステム: Storj のエコシステムは、Filecoin ほど「Web3 のトレンド」ではないかもしれませんが、統合と企業の即戦力という点では非常に成熟しています。供給面では、一貫したトークン支払いのおかげで、Storj は安定したノードオペレーターの基盤を持っています。ノードソフトウェア（現在は第 3 の主要バージョン）は文書化が充実しており、オペレーターはノードを監視するためのコミュニティツール（Grafana ダッシュボードなど）を持っています。Storj Labs は採用を促進するために、オープンソースプロジェクト向けの無料ストレージ を提供し、リリースバイナリやデータセットのホスティングに Storj を試すようコミュニティに促しました。需要面では、Storj がメディアおよびビッグデータのワークフロー に焦点を当てたことで、統合が進みました。例えば、Iconik（メディアアセット管理ソフトウェア）はバックエンドとして Storj をサポートし、Gsuite の代替となる Skiff Mail/Drive は暗号化されたメールの添付ファイルやファイルの保存に Storj を使用しています。また、ownCloud とのパートナーシップにより、企業はワークフローを変更することなく Storj を導入できます。オープンソースライブラリのエコシステム も成長しており、例えば Fastly の Terrarium プロジェクトはエッジキャッシュに Storj を使用しています。Storj はコミュニティ開発者 も重視しており、サードパーティの開発者がプロジェクト（Storj にメディアをオフロードする WordPress プラグイン、Veeam バックアップ統合など）を共有する活発なフォーラムがあります。成熟の兆候の一つは、Storj 上のサードパーティサービス です。例えば、Filebase は Sia を使用するだけでなく、2021 年にバックエンドとして Storj を追加しました。これにより、Filebase のユーザーは同じ S3 インターフェースを介して Storj を選択できるようになりました。これは、Storj がマルチバックエンド・ストレージサービスに含まれるほど安定しており、魅力的であることを示しています。Storj のトークンは支払いに使用されますが、顧客からは大幅に抽象化されており、これが DeFi 的なコンポーザビリティを制限する一方で、伝統的な採用を増やしています。2022 年から 2023 年にかけて、Storj は単なるストレージではなく、分散型クラウドプラットフォーム の一部として再配置し、計算とデータベースの計画を含む Storj Next を発表しました。実際、彼らの クラウド GPU 製品（2025 年時点でベータ版）は、分散型プロバイダーから GPU をレンタルすることで、エコシステムをエッジコンピューティングに拡張しています。これが成功すれば、Storj の傘下に GPU プロバイダーとユーザーのミニエコシステムが構築され、プラットフォームはさらに定着するでしょう。Storj Labs 自体がネットワークの主要な管理人であり続けていますが（別の財団を持つ Filecoin や Sia に比べると、やや中央集権的なガバナンス）、コードをオープンソース化し、コミュニティの貢献を歓迎しています。また、企業からの信頼に不可欠なサードパーティによる監査（セキュリティ、SOC2 などのコンプライアンス）も受けています。要約すると、Storj のエコシステムは統合とエンタープライズ機能において成熟しています が、純粋な Web3 開発者コミュニティの存在感は比較的小規模です。イデオロギーよりも メリット（コスト、セキュリティ） に基づいて分散型技術を販売するというニッチを築いており、これは持続可能なアプローチとなる可能性があります。
• Sia エコシステム: Sia のエコシステムには紆余曲折がありました。Skynet Labs の閉鎖後、Sia Foundation が引き継ぎ、それ以来 Sia v2（ハードフォークのコードネームはしばしば 「Nebulous」）のロードマップを実行しています。一部の要素をリブランディングしており（Skynet ポータルのコードは、パフォーマンスを向上させ、ポータル機能を統合した renter-host プロトコルを統一する Sia v2 に作り直されています）、現在のエコシステムには Sia-UI やホストソフトウェアなどの Sia central アプリのほか、HostScore（ホストのベンチマーク）や SiaStats / SiaGraph（ネットワーク統計サイト）などのコミュニティプロジェクトが含まれます。Sia Foundation が立ち上げた 助成金プログラム（2025 年までに 320 万ドルを配分）は、新しいツールを生み出しています。例えば、SiaFS（Sia 用の FUSE ファイルシステム）、Décentral（Sia 上の分散型 Web フロントエンド）、S5（IPFS 機能を模倣した Sia 上のコンテンツアドレッシング層）などです。これらは、Sia が追いつく必要があった点（コンテンツの参照や共有の簡素化など）を認識していることを示しています。コミュニティは小規模ながら献身的であり、r/siacoin サブレディットは活発で、多くの長期ユーザーがイデオロギー的な理由（真の分散化、VC の強い影響がないことなど）で Sia を支持し続けています。Sia のトークノミクス（Siafunds を含む）は安定しており、Siafunds はコントラクトからの「配当を得る」トークンの一種として取引されるという、Sia のエコシステム独自の金融モデルとなっています。エコシステム内の競争: Skynet のスピンオフのように、Sia 上に構築されたいくつかの企業は生き残りませんでしたが、それによりエコシステムの成長は一時鈍化しました。しかし、新しい企業も登場しています。例えば、Cloudless は使いやすい Sia ストレージアプリを構築している最近のスタートアップであり、PixelSlime は NFT ゲームアセットの保存に Sia を使用しています。Filebase の統合（マルチネットワーク）は、Sia が間接的に広範なエコシステムの一部であることを意味します。Sia Foundation は、透明性を高め、開発の進捗に対する信頼を育むために、毎月 「State of Sia」 アップデートを発行しており、これはコミュニティエンゲージメントの健全な兆候です。一つの課題は、Sia が Web3 において IPFS や Filecoin ほどのマインドシェアを獲得していないことです。分散型ストレージを求める開発者の中には、話題性が低いために Sia を検討しない人もいます。しかし、実際に使用している人々は、その信頼性と低コストを称賛することが多く、DX（開発者体験）のハードルが下がれば口コミで成長する可能性を秘めています。総括すると、Sia のエコシステムは財団の下で再構築と成長の段階にあります。他と比較して小規模で草の根的ですが、長い歴史と独自の機能（他のプロトコルへの非依存、利他的な精神など）を持っています。今後 1 〜 2 年（Sia v2 のローンチを含む）は、成長が加速するかどうかの重要な局面となるでしょう。
• Ceramic エコシステム: Ceramic は比較的新しい（2021 年頃ローンチ）にもかかわらず、分散型アプリ開発者の間で良好なエコシステムの牽引力を見せています。3Box Labs は、Ceramic とそのツールの開発のために、Coinbase Ventures や Multicoin などの企業から多額の資金を確保しました。エコシステムには Ceramic Network 自体に加え、開発者向けのフラッグシップ製品として ComposeDB が含まれます。彼らは Discord や定期的な開発者会議を通じてコミュニティを育成してきました。興味深い側面の一つは、データのコンポーザビリティ基準: Ceramic には「データモデルマーケットプレイス」があり、開発者は互いのスキーマ（プロフィールモデル、ブログ投稿モデルなど）を公開して再利用でき、相互運用可能なデータのエコシステムを育んでいます。これは非常にユニークなアプローチです。多くの dApp が ERC-20 トークン規格を共有しているのと同様に、Ceramic アプリは「SocialPost」モデルや「Profile」モデルを共有でき、共通のデータ構造上での構築を促します。これは、より多くのアプリがこれらを採用するにつれて、ユーザーのプロフィールやコンテンツを多くのサービス間で移植できるようになる（真の Web3 ネットワーク効果）ことを意味します。エコシステムは 他のネットワーク とも相互作用しています。例えば、Ceramic はデフォルトでアンカリングに Ethereum を使用しているため、Ethereum L1 または L2 の改善（安価なアンカーのためにスケーリングソリューションを使用する計画があります）は Ceramic に直接利益をもたらします。また、Chainlink（複数のチェーンでのタイムスタンプ用）や、Ceramic のアイデンティティをブロックチェーンアドレスにリンクできる IDX も統合されています。もう一つのシナジーは ウォレット との連携です。Ceramic のユーザー認証は暗号資産ウォレット経由で行われることが多いため、ウォレットプロバイダーはある意味でパートナーです。例えば、MetaMask の Snaps には最終的にユーザーデータを管理するための Ceramic 統合が含まれる可能性があり、Spruce や IDen3 などのアイデンティティウォレットが Ceramic のアイデンティティにブリッジするかもしれません。Textile の合併（「Textile ファミリー」への加入）は、他のデータ / ストレージプロジェクトとの連携を示唆しています（Textile は元々 IPFS / Filecoin 上に構築されており、彼らの Threads DB のコンセプトは Ceramic のストリームを補完します）。これにより、コンテンツに IPFS を、メタデータに Ceramic をシームレスに使用するような新しいハイブリッドソリューションが生まれる可能性があります。コミュニティプロジェクトに関しては、NFT チケット発行（Ceramic 上で更新されるチケットメタデータの保存）や DAO メンバープロフィールなどに Ceramic を使用する ハッカソン勝者 が見られます。Ceramic のメインネットはまだ若いですが、複数の ゲートウェイプロバイダー（Ethereum における Infura のように、利用可能なホストされた Ceramic ノード）が存在します。これには 3Box によるもののほか、コミュニティによるものも含まれており、アクセスにおける分散化が進んでいることを示しています。ロードマップには、「複数チェーンでの Ceramic アンカリング」 や、参加を容易にするための**「ライトノード」** などの機能が含まれており、これらは技術の成熟の兆候です。まとめると、Ceramic のエコシステムはダイナミックで開発者中心 であり、相互運用性と広範な Web3 スタックとの統合を重視しています。これは汎用的なストレージエコシステムではなく、コンポーザブルなデータエコシステム であり、何百人もの開発者とコラボレーションの精神（データモデルマーケットプレイス）によってそれを実現しつつあるようです。その成功は、これら 400 のアプリが大規模なユーザーベースを取り込めるかどうかにかかっていますが、インフラとコミュニティの土台は積極的に築かれています。

6. 価格比較​

7. ユースケースとアプリケーション​

分散型ストレージネットワークは、永続性、可変性、速度などの要件が異なるさまざまなユースケースに対応できます。以下では、代表的なユースケースと、前述の各ベンダーがどのようにそれらに適合するかを探ります。

a. NFT メタデータとメディアホスティング: 2021 年における分散型ストレージの「キラーアプリ」は NFT でした。Ethereum や Solana などのチェーン上の NFT は、通常、トークン ID のみをオンチェーンに保存し、属性・名前・説明を含む「メタデータ JSON」や「メディアファイル」（画像、動画、音声）はオフチェーンに保存されます。NFT がリンク切れで消滅するのを防ぐために、分散型ストレージは不可欠です。

• IPFS + Pinata は、多くの Ethereum NFT の標準となりました。作成者はメディアを IPFS にアップロードし、トークンの URI にハッシュ（CID）を使用します。Pinata は、コンテンツが永続的にピン留めされ、IPFS ゲートウェイ経由で迅速にアクセスできるようにするために頻繁に利用されます。これにより、作成者がいなくなっても、CID を知っている人なら誰でも NFT コンテンツを取得できます。例えば、Bored Ape Yacht Club のような著名なコレクションは、画像に IPFS を使用しました。Pinata の役割は、作成者が独自の IPFS インフラを運用することなく、数万の画像が確実かつ継続的に利用可能にすることでした。OpenSea などのマーケットプレイスは、これらの IPFS リンクからメタデータを取得して NFT を表示します。利点: コンテンツアドレッシングにより信頼性が高まり（購入者はアセットのハッシュが販売中のものと一致することを確認できる）、検閲耐性が得られます（特定のサーバーが画像をホストしているわけではない）。課題: 誰もデータをピン留めしなければデータが消える可能性があるため、Pinata や NFT.storage のようなサービスが可用性を維持するために介入しています。
• Arweave は、NFT ストレージの「永久保存」ソリューションとして台頭しました。より高いコストを払ってでも、NFT アセットを「永遠に」存続させたいプロジェクトは Arweave を選びます。Solana の NFT エコシステムはその典型例です。Solana の Candy Machine（ミント用プログラム）は Arweave と直接統合されており、メディアとメタデータをアップロードして、NFT のトークン URI 用に Arweave TXID URL（多くの場合 arweave.net を介したプロキシ）を返します。これは、一度ミントされると、NFT の JSON と画像が Arweave のパーマウェブ（Permaweb）に永久に保存される（ミント者が費用を支払う）ことを意味します。Solana の MetaPlex は、この設計によってコレクターに対し、NFT アートが消えたり変更されたりしないことを保証できると主張しています。Ethereum 上でも、一部のプロジェクトは高額なアートやジェネレーティブ作品に Arweave を使用しています（例：Async Art はプログラム可能なアートのコンポーネントを Arweave に保存しました）。さらに、Arweave のバンドルアップロード機能により、NFT ドロップ用の数千の画像を効率的に一括保存することが可能です。
• Filecoin （NFT.storage 経由）も、特に 2021 年半ばに NFT.storage が無料ストレージを開始して以降、NFT のバックエンドとして普及しました。NFT.storage はハイブリッド方式を採用しており、迅速な取得のためにデータを IPFS にピン留めし、同時に長期的な耐久性のために複数の Filecoin マイナーとそのデータを保存します。Ethereum、Polygon、Flow などの多くの NFT プロジェクトが NFT.storage を利用しており、Protocol Labs がコンテンツを維持してくれることを信頼しています（これは Filecoin のディールによって促進されます）。ここでの メリット は、Filecoin のトークンエコノミクスによる補助のおかげで、プロジェクトが費用を支払うことなく分散型の冗長性を得られることです。また、暗号学的証明を備えたブロックチェーンベースのネットワーク（Filecoin）上にデータがあるという概念を好むプロジェクトもあります。さらに、保存状況を確認するための「NFT チェッカー」の開発も進んでいます。
• Storj と Sia は NFT での利用はあまり一般的ではありませんが、NFT メディアをホストする能力は十分に備えています。普及していないのは、統合ツールの有無の問題です。Sia の Skynet にはいくつかの NFT 統合（Skylink をトークン URI として Sia ホストの NFT をミントできる SkyNFT など）がありました。Storj はエンタープライズに焦点を当てていたため、直接 NFT をターゲットにはしませんでしたが、マーケットプレイスがコンテンツのホスティングに Storj を使用し、CDN パフォーマンスの恩恵を受けることは十分に考えられます。IPFS/Arweave が NFT ストレージを支配した主な理由は、ネットワーク効果とツールにあります。IPFS は NFT ミントライブラリで広くサポートされており、Arweave はコレクターに響く「永遠のストレージ」という明確な価値提案を持っていました。対照的に、Storj を使用するにはカスタム統合が必要になります（技術的には Storj リンクをトークン URI として使用可能ですが、一般的ではありません）。Sia の利点はコストです。予算を重視する NFT プロジェクトは、Filebase などを通じて Sia を利用し、低コストでアセットを保存する可能性があります。
• Ceramic は、NFT の文脈では「動的または進化する NFT」として登場します。NFT のメタデータを更新する必要がある場合（レベルアップするゲームアイテムなど）、Ceramic は可変ストリームを許可するため、それらの進化するプロパティを保存できます。また、Ceramic はオフチェーンでの NFT 所有権の追跡や、NFT とユーザープロフィールのリンクにも使用できます。ただし、実際のメディアファイルについては、Ceramic は大きなバイナリデータの処理を目的としていないため、通常は参照（CID や Arweave リンクなど）を保存するにとどまります。

b. 分散型アプリケーション (dApp) バックエンド: 多くの dApp は、ブロックチェーンに保存するには大きすぎる、あるいは不適切なデータ（コストの問題や、ユーザー生成コンテンツなど）を保存する必要があります。分散型ストレージネットワークは、dApp の「バックエンド」またはデータベースとしてこのギャップを埋めます。

• Web3 フロントエンドホスティング: 一般的なパターンは、分散型アプリのフロントエンドコード（HTML/JS/CSS）を分散型ストレージネットワークでホストし、アプリが分散的な方法で（多くの場合 IPFS ゲートウェイや Arweave URL を介して）アクセスできるようにすることです。IPFS （Fleek や Pinata などのサービス経由）は、DeFi アプリや NFT マーケットプレイスなどの静的サイトのホスティングに広く使用されており、メインのウェブサイトがダウンしても、ユーザーは IPFS 経由で UI を取得できます。Arweave も、検閲耐性が必要なフロントエンドのホスティングに使用されます。例えば、多くの Ethereum DeFi プロジェクトの UI が Arweave にアップロードされ、ENS リンクでピン留めされています。トルコが特定の暗号資産サイトを禁止した際、ユーザーが Uniswap のインターフェースの Arweave リンクを共有してアクセスを継続できたのは有名な話です。Storj もウェブアセットを提供できますが、リンクの容易さやコンテンツアドレッシングの面から、フロントエンドには IPFS/Arweave が選ばれるのが一般的です。フロントエンドに分散型ストレージを使用することで、中央集権的なサーバーへの依存を減らせます。完全に実現されれば、ユーザーは IPFS/Arweave から UI を読み込み、そこからオンチェーンのスマートコントラクトに接続するという、完全な分散型スタックと対話できるようになります。
• ユーザーデータとソーシャルアプリケーション: 分散型ソーシャルメディアやコラボレーションアプリは、投稿、メッセージ、プロフィール情報を保存する必要があります。ここで Ceramic が威力を発揮します。Ceramic は一般的なソーシャルデータ型のスキーマを提供し、更新を可能にします。例えば、Lens Protocol （Polygon 上の分散型ソーシャル）は投稿内容の保存に IPFS を使用していますが、ユーザープロフィールや投稿のインデックスには Ceramic を使用でき、プラットフォームをまたいだソーシャルアイデンティティを実現できます。Orbis は Ceramic を使用してツイートやコメントを保存し、複数のフロントエンドが同じコンテンツを表示できるようにしています。Arweave は、永続させたいソーシャルコンテンツ（「不変のツイート」のようなもの）に使用されることがありますが、通常、ソーシャルには可変性（編集/削除）が必要であり、Arweave はそれを許可しません。Storj は、安全なユーザーファイルストレージを必要とするアプリのバックエンドとして役立ちます（例えば、分散型 Dropbox のようなアプリが Storj を使用して、クライアントサイド暗号化でユーザーファイルを保存し、ネットワークの弾力性の恩恵を受けることができます）。
• 分散型アイデンティティ (DID) と認証情報: これは Ceramic と IPFS が重要な役割を果たすユースケースです。DID ドキュメント（ユーザーの公開鍵などを記述した小さな JSON ドキュメント）は IPFS に保存できます。Ceramic の DID メソッド (did:3) は、実際には DID ドキュメントのイベントを Ceramic ストリームに保存します。また、検証可能な認証情報 (Verifiable Credentials) （暗号署名された主張、通常数 KB 程度）も、ブロックチェーンではなく IPFS や Ceramic 経由で保存・配布し、アイデンティティプロトコルから参照することができます。Arweave は、公的な認証情報や証明を後世のためにアーカイブするために使用されるかもしれません。
• DeFi および DAO 用のバックエンドデータ: 多くの DeFi プロトコルは、チェーン上に置くには高価すぎる大量のデータ（取引記録、分析データ）を生成します。一部のプロジェクトは、取引履歴やステートのバックアップを保存するために Filecoin/IPFS を使用しています。The Graph （ブロックチェーンデータをインデックス化するプロトコル）は最近、クエリ可能なデータのストレージとして Arweave のサポート を導入しました。Graph Node はサブグラフデータを Arweave に永続化し、その永続性を活用できます。DAO は、提案、憲章、投票データのスナップショットを保存する必要があることが多く、Snapshot のようなサービスは提案の JSON 保存に IPFS を使用し、IPFS リンクがガバナンス投票のオンチェーンに埋め込まれます。

c. アーカイブデータの保存: 分散型ストレージの核心的な約束は、歴史的記録、オープンデータ、科学的知識、文化的遺産などの情報を、冗長性を保ちながら無期限に保存することです。

• Arweave は、明確にアーカイブ市場をターゲットにしています。「パーマウェブ」という用語は、人類の知識の永久的なアーカイブを作成することを意味します。Arweave は、ウェブサイトのアーカイブに使用されてきました（例：インターネットアーカイブ (Internet Archive) は Arweave と協力してデータを保存しており、ウェブページを Arweave にアーカイブするブラウザ拡張機能「ArweaveSave」も存在します）。Arweave の利益共有コミュニティは、ニュース記事を不変の形でアーカイブする ArweaveNews のようなプロジェクトにも資金を提供しました。データが一度 Arweave に乗れば事実上検閲不可能で永久的であるため、重要な文書（ジャーナリストが紛争地帯や抗議活動の文書を消去されないように保存するなど）の保存に理想的です。Arweave は「燃えないアレクサンドリア図書館」とも称されています。
• Filecoin もアーカイブのユースケースをターゲットにしています。Filecoin Discover プログラムを通じて、オープンアクセスの科学データセットや政府のオープンデータを保存するために使用されたのは有名です。USC ショア財団とスタンフォード大学のパートナーシップである Starling Lab は、ホロコースト生存者の証言などの機密性の高い歴史的メディアを、信頼性の証明とともにアーカイブするために Filecoin を使用しています。Filecoin Archives イニシアチブでは、コミュニティグループがパンデミックデータや大規模な文学コーパスなどの重要な公共データを選択してアップロードしています。Filecoin ストレージは安価であるため、公共データセットのリポジトリ全体のようなマルチテラバイトのアーカイブを保存するのに実用的です。
• Storj は、高い耐久性と自動的な地理的分散により、アーカイブのニーズに応えることができます。例えば、医療アーカイブやメディアアーカイブを Storj に保存することで、消失のリスクを軽減し、異なる地域で複数のコピーを維持する手間を省くことができます（Storj が自動的に行います）。また、現在高額なクラウド費用を支払っているアーカイブにとっても、Storj は安価であるため財務的に魅力的です。Storj がアピールしているニッチな分野の一つが バックアップストレージ です。企業は Storj をバックアップ先として使用でき、一般的なバックアップソフトウェアとの統合も進んでいます。
• Sia は、低コストと冗長性により、本質的にアーカイブに適しています。個人が文書や写真の個人アーカイブを数十年にわたって保持したい場合、契約を更新し続ける限り、最小限の費用で Sia を利用できます。実際に、Wikipedia 全体を Sia にアーカイブし、その手頃な価格を活用した例もあります。Sia の完全にプライベートな性質（デフォルトで暗号化）は、プライバシーに関わるアーカイブ（個人の健康記録など）にとって魅力的です。

d. コンテンツ配信とストリーミング: 分散型ストレージは、エンドユーザーへのコンテンツ配信、さらにはライブやオンデマンドのストリーミングとしても機能します。

• Storj はこのユースケースを強調してきました。そのアーキテクチャにより、コンテンツは事実上分散型 CDN 上に配置されます。世界中のノードが、最も近い / 最速のノードからビデオセグメントをユーザーに提供できるため、低遅延が実現します。Storj とビデオストリーミングプラットフォームとの提携（3,000 万時間のストリーミング実績など）は、高いスループットを処理できることを示しています。ビデオオンデマンドに適しており（ビデオファイルを保存し、ユーザーが再生すると、プレーヤーが並列でピースを取得する）、Cloudflare Stream との比較デモでも競争力のあるパフォーマンスを示しました。ソフトウェア配信（大きなバイナリやゲームファイルをユーザーに迅速に配信し、分散型 Akamai のように機能する）にも適しています。
• IPFS は、コンテンツが多くのノードによってシードされるほど人気があれば、コンテンツ配信に使用できます。ライブストリーミングにおける IPFS の実験も行われてきました（例：Livepeer は初期バージョンで、放送者から視聴者へビデオセグメントを配信するために IPFS を使用していました）。IPFS の課題は可用性の確保です。人気のあるコンテンツであれば複数のピアが保持している可能性がありますが、あまり人気のないコンテンツの場合は、ピン留めされているゲートウェイ（Pinata など）へのフォールバックが必要になります。
• Filecoin は現在、ライブ配信よりもストレージとしての側面が強いですが、「CDN としての Filecoin」という概念も浮上しています。データが迅速に必要とされる場合、Filecoin のデータはより高速なネットワーク（IPFS や専門の取得プロバイダーなど）にキャッシュされるというシナリオが有力です。また、人気のデータセットを常にオンラインに保ち、ユーザーの近くに配置する Beta Storage Providers に関する取り組みも進んでいます。
• Arweave は、高速なコンテンツ配信を目的として設計されたわけではありません。Arweave から大きなファイルを取得するにはネットワークにクエリを投げる必要があり、専用 CDN よりも遅くなる可能性があります。しかし、Arweave の Wildfire プロトコルは、マイナー間でデータを迅速に共有するようにインセンティブを与えており、これにより取得時間が改善されます。それほど人気のないコンテンツ（数人が取得する画像など）の場合、ゲートウェイがキャッシュすることがよくあります。

実務上、ソリューションはレイヤー化されることがあります。例えば、コンテンツを Arweave や Filecoin に永久保存しつつ、IPFS や Storj を使ってエンドユーザーへ迅速に配信するといった具合です。あるいは、インデックスと参照に Ceramic を、バックアップに Arweave を、ホットアクセスに IPFS を使用することもあります。

ユースケース別適合性の概要:

• Arweave: 「永久ウェブ」コンテンツ、永遠に持続すべき NFT メディア、改ざん防止アーカイブに最適。NFT メタデータ、ブロックチェーン履歴のアーカイブ、ウェブページやブログ記事の保存、検閲耐性のあるサイトホスティングによく使われます。頻繁に変更されるデータや高帯域幅のストリーミングには不向きです。
• Pinata/IPFS: コンテンツアドレッシングと配信に理想的。NFT（広く普及）、dApp 用のウェブアセットホスティング、Web3 アプリでの一般的なファイル共有、迅速な分散型 CDN が必要なシナリオで使用されます。適切なピン留めにより準永続的なストレージとして機能しますが、誰かがピン留めし続けない限り永久性は保証されません（そのため Filecoin と併用されることが多い）。
• Filecoin: 大規模な長期ストレージに最適。特に取得のために IPFS と組み合わせた場合に威力を発揮します。大規模なデータセットのアーカイブ、NFT アセットのバックアップ（フロントエンドが IPFS URI を使用していても、背後で Filecoin が支えているケースが多い）、エンタープライズ向けのコールドストレージに使用されます。取引のオーバーヘッドがあるため、リアルタイムデータには不向きですが、新しいツールにより進化しています。
• Storj: 安全でパフォーマンスの高いクラウドストレージに優れており、S3 API 互換の分散型ソリューションを求める開発者や企業をターゲットにしています。メディアストリーミング、S3 API を必要とするアプリバックエンド、世界中からアクセス可能なコラボレーションファイル（スピードとコストの利点から Dropbox の代わりに使用）に適しています。
• Sia: 予算重視の分散型ストレージや、プライバシーを最優先するユーザーに適しています。個人のバックアップや、ビジネス用の冗長バックアップ、Filebase のような使いやすいサービスの背後にあるレイヤーとして選ばれます。Skynet によりウェブホスティングやアプリデータへ拡張されました。
• Ceramic: dApp データとアイデンティティに特化。Web3 のユーザープロフィール、ソーシャルコンテンツ（投稿、コメント）、DAO の提案と議論（ブロックチェーンを肥大化させずに編集可能にする）、ゲームの状態データ、メタデータレジストリに使用されます。分散型の文脈で「データベース」が必要な場合に適しています。

結論として、分散型ストレージベンダーの展望は、それぞれの強みを補完し合う関係にあります。複雑な dApp は、これらを複数組み合わせて使用することがあります。例えば、NFT マーケットプレイスは、アセットの迅速な提供に IPFS+Pinata を使い、アセットの長期バックアップに Filecoin を使い、ユーザープロフィールとコメントに Ceramic を使い、ウェブサイトと全メタデータの永久記録に Arweave を使うといった構成が考えられます。

出典:

• Reflexivity Research (2024) – Arweave Overview
• Gate.io Research (2023) – Arweave: Pay Once, Store Forever
• FiveT Investment (2023) – Decentralized Storage: Filecoin vs Arweave
• Pinata Cloud – 公式サイトおよび価格
• NFT.storage Blog (2023) – Partnerships with Pinata and Lighthouse
• Storj Docs – 価格とアーキテクチャ; ownCloud – Storj 統合
• Messari (2024) – State of Sia Q3 2024
• Ceramic Network – 公式サイト (2025); LogRocket – Managing data with Ceramic
• IPFS Docs – 比較
• The Block (2022) – Meta が Instagram NFT に Arweave を採用

プライバシーは公共インフラになりつつあります。2025年、開発者にはデータ保存と同じくらい簡単に暗号化を行うツールが必要です。Mysten LabsのSealは、まさにそれを提供します—オンチェーンアクセス制御を備えた分散シークレット管理。このチュートリアルでは、アイデンティティベース暗号化、閾値セキュリティ、プログラマブルアクセスポリシーを使用して安全なWeb3アプリケーションを構築する方法を教えます。

導入：なぜSealがWeb3にとって重要なのか​

従来のクラウドアプリケーションは、単一のプロバイダーが暗号化データへのアクセスを制御する集中型キー管理システムに依存しています。便利ですが、これは危険な単一障害点を作り出します。プロバイダーが侵害されたり、オフラインになったり、アクセスを制限することを決定した場合、あなたのデータはアクセス不可能または脆弱になります。

Sealは、このパラダイムを完全に変えます。Mysten LabsがSuiブロックチェーン向けに構築したSealは、分散シークレット管理（DSM）サービスで、以下を可能にします：

• アイデンティティベース暗号化：コンテンツが環境を離れる前に保護される
• 閾値暗号化：複数の独立したノード間でキーアクセスを分散
• オンチェーンアクセス制御：タイムロック、トークンゲーティング、カスタム認証ロジック
• ストレージ非依存設計：Walrus、IPFS、または任意のストレージソリューションと連携

安全なメッセージングアプリ、ゲート付きコンテンツプラットフォーム、タイムロック資産転送を構築する場合、Sealは必要な暗号プリミティブとアクセス制御インフラストラクチャを提供します。

はじめに​

前提条件​

開始する前に、以下があることを確認してください：

• Node.js 18+がインストールされていること
• TypeScript/JavaScriptの基本的な知識
• テスト用のSuiウォレット（Sui Walletなど）
• ブロックチェーンの概念の理解

インストール​

npm経由でSeal SDKをインストールします：

npm install @mysten/seal

ブロックチェーンインタラクション用にSui SDKも必要です：

npm install @mysten/sui

プロジェクトセットアップ​

新しいプロジェクトを作成し、初期化します：

mkdir seal-tutorial
cd seal-tutorial
npm init -y
npm install @mysten/seal @mysten/sui typescript @types/node

シンプルなTypeScript設定を作成します：

// tsconfig.json
{
  "compilerOptions": {
    "target": "ES2020",
    "module": "commonjs",
    "strict": true,
    "esModuleInterop": true,
    "skipLibCheck": true,
    "forceConsistentCasingInFileNames": true
  }
}

コアコンセプト：Sealの仕組み​

コードを書く前に、Sealのアーキテクチャを理解しましょう：

1. アイデンティティベース暗号化（IBE）​

公開キーに暗号化する従来の暗号化とは異なり、IBEではアイデンティティ（メールアドレスやSuiアドレスなど）に暗号化できます。受信者は、そのアイデンティティを制御していることを証明できる場合にのみ復号化できます。

2. 閾値暗号化​

単一のキーサーバーを信頼する代わりに、Sealはt-of-n閾値スキームを使用します。3-of-5キーサーバーを設定することで、任意の3つのサーバーが協力して復号化キーを提供できますが、2つ以下では不可能です。

3. オンチェーンアクセス制御​

アクセスポリシーはSuiスマートコントラクトによって強制されます。キーサーバーが復号化キーを提供する前に、要求者がオンチェーンポリシー要件（トークン所有権、時間制約など）を満たしていることを確認します。

4. キーサーバーネットワーク​

分散キーサーバーはアクセスポリシーを検証し、復号化キーを生成します。これらのサーバーは、単一の制御点を確保しないよう、異なる当事者によって運営されます。

基本実装：最初のSealアプリケーション​

Suiブロックチェーンポリシーを通じてアクセスを制御し、機密データを暗号化するシンプルなアプリケーションを構築しましょう。

ステップ1：Sealクライアントの初期化​

// src/seal-client.ts
import { SealClient } from '@mysten/seal';
import { SuiClient } from '@mysten/sui/client';

export async function createSealClient() {
  // テストネット用のSuiクライアントを初期化
  const suiClient = new SuiClient({
    url: 'https://fullnode.testnet.sui.io'
  });

  // テストネットキーサーバーでSealクライアントを設定
  const sealClient = new SealClient({
    suiClient,
    keyServers: [
      'https://keyserver1.seal-testnet.com',
      'https://keyserver2.seal-testnet.com',
      'https://keyserver3.seal-testnet.com'
    ],
    threshold: 2, // 2-of-3閾値
    network: 'testnet'
  });

  return { sealClient, suiClient };
}

ステップ2：シンプルな暗号化/復号化​

// src/basic-encryption.ts
import { createSealClient } from './seal-client';

async function basicExample() {
  const { sealClient } = await createSealClient();

  // 暗号化するデータ
  const sensitiveData = "これは私の秘密メッセージです！";
  const recipientAddress = "0x742d35cc6d4c0c08c0f9bf3c9b2b6c64b3b4f5c6d7e8f9a0b1c2d3e4f5a6b7c8";

  try {
    // 特定のSuiアドレス用にデータを暗号化
    const encryptedData = await sealClient.encrypt({
      data: Buffer.from(sensitiveData, 'utf-8'),
      recipientId: recipientAddress,
      // オプション：メタデータを追加
      metadata: {
        contentType: 'text/plain',
        timestamp: Date.now()
      }
    });

    console.log('暗号化されたデータ:', {
      ciphertext: encryptedData.ciphertext.toString('base64'),
      encryptionId: encryptedData.encryptionId
    });

    // 後でデータを復号化（適切な認証が必要）
    const decryptedData = await sealClient.decrypt({
      ciphertext: encryptedData.ciphertext,
      encryptionId: encryptedData.encryptionId,
      recipientId: recipientAddress
    });

    console.log('復号化されたデータ:', decryptedData.toString('utf-8'));

  } catch (error) {
    console.error('暗号化/復号化に失敗しました:', error);
  }
}

basicExample();

Suiスマートコントラクトによるアクセス制御​

Sealの真の力は、プログラマブルアクセス制御にあります。特定の時間後にのみデータを復号化できるタイムロック暗号化の例を作成しましょう。

ステップ1：アクセス制御コントラクトのデプロイ​

まず、アクセスポリシーを定義するMoveスマートコントラクトが必要です：

// contracts/time_lock.move
module time_lock::policy {
    use sui::clock::{Self, Clock};
    use sui::object::{Self, UID};
    use sui::tx_context::{Self, TxContext};

    public struct TimeLockPolicy has key, store {
        id: UID,
        unlock_time: u64,
        authorized_user: address,
    }

    public fun create_time_lock(
        unlock_time: u64,
        authorized_user: address,
        ctx: &mut TxContext
    ): TimeLockPolicy {
        TimeLockPolicy {
            id: object::new(ctx),
            unlock_time,
            authorized_user,
        }
    }

    public fun can_decrypt(
        policy: &TimeLockPolicy,
        user: address,
        clock: &Clock
    ): bool {
        let current_time = clock::timestamp_ms(clock);
        policy.authorized_user == user && current_time >= policy.unlock_time
    }
}

ステップ2：Sealとの統合​

// src/time-locked-encryption.ts
import { createSealClient } from './seal-client';
import { TransactionBlock } from '@mysten/sui/transactions';

async function createTimeLocked() {
  const { sealClient, suiClient } = await createSealClient();

  // Sui上でアクセスポリシーを作成
  const txb = new TransactionBlock();

  const unlockTime = Date.now() + 60000; // 1分後にアンロック
  const authorizedUser = "0x742d35cc6d4c0c08c0f9bf3c9b2b6c64b3b4f5c6d7e8f9a0b1c2d3e4f5a6b7c8";

  txb.moveCall({
    target: 'time_lock::policy::create_time_lock',
    arguments: [
      txb.pure(unlockTime),
      txb.pure(authorizedUser)
    ]
  });

  // ポリシーを作成するトランザクションを実行
  const result = await suiClient.signAndExecuteTransactionBlock({
    transactionBlock: txb,
    signer: yourKeypair, // あなたのSuiキーペア
  });

  const policyId = result.objectChanges?.find(
    change => change.type === 'created'
  )?.objectId;

  // このポリシーで暗号化
  const sensitiveData = "これは1分後にアンロックされます！";

  const encryptedData = await sealClient.encrypt({
    data: Buffer.from(sensitiveData, 'utf-8'),
    recipientId: authorizedUser,
    accessPolicy: {
      policyId,
      policyType: 'time_lock'
    }
  });

  console.log('タイムロックされたデータが作成されました。1分後に復号化を試してください。');

  return {
    encryptedData,
    policyId,
    unlockTime
  };
}

実用的な例​

例1：安全なメッセージングアプリケーション​

// src/secure-messaging.ts
import { createSealClient } from './seal-client';

class SecureMessenger {
  private sealClient: any;

  constructor(sealClient: any) {
    this.sealClient = sealClient;
  }

  async sendMessage(
    message: string,
    recipientAddress: string,
    senderKeypair: any
  ) {
    const messageData = {
      content: message,
      timestamp: Date.now(),
      sender: senderKeypair.toSuiAddress(),
      messageId: crypto.randomUUID()
    };

    const encryptedMessage = await this.sealClient.encrypt({
      data: Buffer.from(JSON.stringify(messageData), 'utf-8'),
      recipientId: recipientAddress,
      metadata: {
        type: 'secure_message',
        sender: senderKeypair.toSuiAddress()
      }
    });

    // 暗号化されたメッセージを分散ストレージ（Walrus）に保存
    return this.storeOnWalrus(encryptedMessage);
  }

  async readMessage(encryptionId: string, recipientKeypair: any) {
    // ストレージから取得
    const encryptedData = await this.retrieveFromWalrus(encryptionId);

    // Sealで復号化
    const decryptedData = await this.sealClient.decrypt({
      ciphertext: encryptedData.ciphertext,
      encryptionId: encryptedData.encryptionId,
      recipientId: recipientKeypair.toSuiAddress()
    });

    return JSON.parse(decryptedData.toString('utf-8'));
  }

  private async storeOnWalrus(data: any) {
    // Walrusストレージとの統合
    // 暗号化されたデータをWalrusにアップロードし
    // 取得用のblob IDを返します
  }

  private async retrieveFromWalrus(blobId: string) {
    // blob IDを使用してWalrusから暗号化されたデータを取得
  }
}

例2：トークンゲート付きコンテンツプラットフォーム​

// src/gated-content.ts
import { createSealClient } from './seal-client';

class ContentGating {
  private sealClient: any;
  private suiClient: any;

  constructor(sealClient: any, suiClient: any) {
    this.sealClient = sealClient;
    this.suiClient = suiClient;
  }

  async createGatedContent(
    content: string,
    requiredNftCollection: string,
    creatorKeypair: any
  ) {
    // NFT所有権ポリシーを作成
    const accessPolicy = await this.createNftPolicy(
      requiredNftCollection,
      creatorKeypair
    );

    // NFTアクセス要件でコンテンツを暗号化
    const encryptedContent = await this.sealClient.encrypt({
      data: Buffer.from(content, 'utf-8'),
      recipientId: 'nft_holders', // NFTホルダー用の特別な受信者
      accessPolicy: {
        policyId: accessPolicy.policyId,
        policyType: 'nft_ownership'
      }
    });

    return {
      contentId: encryptedContent.encryptionId,
      accessPolicy: accessPolicy.policyId
    };
  }

  async accessGatedContent(
    contentId: string,
    userAddress: string,
    userKeypair: any
  ) {
    // まずNFT所有権を確認
    const hasAccess = await this.verifyNftOwnership(
      userAddress,
      contentId
    );

    if (!hasAccess) {
      throw new Error('アクセスが拒否されました：必要なNFTが見つかりません');
    }

    // コンテンツを復号化
    const decryptedContent = await this.sealClient.decrypt({
      encryptionId: contentId,
      recipientId: userAddress
    });

    return decryptedContent.toString('utf-8');
  }

  private async createNftPolicy(collection: string, creator: any) {
    // NFT所有権をチェックするMoveコントラクトを作成
    // ポリシーオブジェクトIDを返す
  }

  private async verifyNftOwnership(user: string, contentId: string) {
    // ユーザーが必要なNFTを所有しているかチェック
    // NFT所有権についてSuiにクエリ
  }
}

例3：タイムロック資産転送​

// src/time-locked-transfer.ts
import { createSealClient } from './seal-client';

async function createTimeLockTransfer(
  assetData: any,
  recipientAddress: string,
  unlockTimestamp: number,
  senderKeypair: any
) {
  const { sealClient, suiClient } = await createSealClient();

  // Sui上でタイムロックポリシーを作成
  const timeLockPolicy = await createTimeLockPolicy(
    unlockTimestamp,
    recipientAddress,
    senderKeypair,
    suiClient
  );

  // 資産転送データを暗号化
  const transferData = {
    asset: assetData,
    recipient: recipientAddress,
    unlockTime: unlockTimestamp,
    transferId: crypto.randomUUID()
  };

  const encryptedTransfer = await sealClient.encrypt({
    data: Buffer.from(JSON.stringify(transferData), 'utf-8'),
    recipientId: recipientAddress,
    accessPolicy: {
      policyId: timeLockPolicy.policyId,
      policyType: 'time_lock'
    }
  });

  console.log(`資産は${new Date(unlockTimestamp)}までロックされています`);

  return {
    transferId: encryptedTransfer.encryptionId,
    unlockTime: unlockTimestamp,
    policyId: timeLockPolicy.policyId
  };
}

async function claimTimeLockTransfer(
  transferId: string,
  recipientKeypair: any
) {
  const { sealClient } = await createSealClient();

  try {
    const decryptedData = await sealClient.decrypt({
      encryptionId: transferId,
      recipientId: recipientKeypair.toSuiAddress()
    });

    const transferData = JSON.parse(decryptedData.toString('utf-8'));

    // 資産転送を処理
    console.log('資産転送のロックが解除されました:', transferData);

    return transferData;
  } catch (error) {
    console.error('転送がまだアンロックされていないか、アクセスが拒否されました:', error);
    throw error;
  }
}

Walrus分散ストレージとの統合​

SealはSuiの分散ストレージソリューションであるWalrusとシームレスに連携します。両方を統合する方法は以下の通りです：

// src/walrus-integration.ts
import { createSealClient } from './seal-client';

class SealWalrusIntegration {
  private sealClient: any;
  private walrusClient: any;

  constructor(sealClient: any, walrusClient: any) {
    this.sealClient = sealClient;
    this.walrusClient = walrusClient;
  }

  async storeEncryptedData(
    data: Buffer,
    recipientAddress: string,
    accessPolicy?: any
  ) {
    // Sealで暗号化
    const encryptedData = await this.sealClient.encrypt({
      data,
      recipientId: recipientAddress,
      accessPolicy
    });

    // 暗号化されたデータをWalrusに保存
    const blobId = await this.walrusClient.store(
      encryptedData.ciphertext
    );

    // SealとWalrusの両方の情報を含む参照を返す
    return {
      blobId,
      encryptionId: encryptedData.encryptionId,
      accessPolicy: encryptedData.accessPolicy
    };
  }

  async retrieveAndDecrypt(
    blobId: string,
    encryptionId: string,
    userKeypair: any
  ) {
    // Walrusから取得
    const encryptedData = await this.walrusClient.retrieve(blobId);

    // Sealで復号化
    const decryptedData = await this.sealClient.decrypt({
      ciphertext: encryptedData,
      encryptionId,
      recipientId: userKeypair.toSuiAddress()
    });

    return decryptedData;
  }
}

// 使用例
async function walrusExample() {
  const { sealClient } = await createSealClient();
  const walrusClient = new WalrusClient('https://walrus-testnet.sui.io');

  const integration = new SealWalrusIntegration(sealClient, walrusClient);

  const fileData = Buffer.from('重要なドキュメントの内容');
  const recipientAddress = '0x...';

  // 暗号化して保存
  const result = await integration.storeEncryptedData(
    fileData,
    recipientAddress
  );

  console.log('Blob IDで保存されました:', result.blobId);

  // 後で取得して復号化
  const decrypted = await integration.retrieveAndDecrypt(
    result.blobId,
    result.encryptionId,
    recipientKeypair
  );

  console.log('取得されたデータ:', decrypted.toString());
}

閾値暗号化の高度な設定​

本番アプリケーションでは、複数のキーサーバーでカスタム閾値暗号化を設定したいでしょう：

// src/advanced-threshold.ts
import { SealClient } from '@mysten/seal';

async function setupProductionSeal() {
  // 複数の独立したキーサーバーで設定
  const keyServers = [
    'https://keyserver-1.your-org.com',
    'https://keyserver-2.partner-org.com',
    'https://keyserver-3.third-party.com',
    'https://keyserver-4.backup-provider.com',
    'https://keyserver-5.fallback.com'
  ];

  const sealClient = new SealClient({
    keyServers,
    threshold: 3, // 3-of-5閾値
    network: 'mainnet',
    // 高度なオプション
    retryAttempts: 3,
    timeoutMs: 10000,
    backupKeyServers: [
      'https://backup-1.emergency.com',
      'https://backup-2.emergency.com'
    ]
  });

  return sealClient;
}

async function robustEncryption() {
  const sealClient = await setupProductionSeal();

  const criticalData = "ミッションクリティカルな暗号化データ";

  // 高いセキュリティ保証で暗号化
  const encrypted = await sealClient.encrypt({
    data: Buffer.from(criticalData, 'utf-8'),
    recipientId: '0x...',
    // 最大セキュリティのため全5サーバーを要求
    customThreshold: 5,
    // 冗長性を追加
    redundancy: 2,
    accessPolicy: {
      // 多要素要件
      requirements: ['nft_ownership', 'time_lock', 'multisig_approval']
    }
  });

  return encrypted;
}

セキュリティベストプラクティス​

1. キー管理​

// src/security-practices.ts

// 良い例：安全なキー導出を使用
import { generateKeypair } from '@mysten/sui/cryptography/ed25519';

const keypair = generateKeypair();

// 良い例：キーを安全に保存（環境変数の例）
const keypair = Ed25519Keypair.fromSecretKey(
  process.env.PRIVATE_KEY
);

// 悪い例：キーをハードコードしない
const badKeypair = Ed25519Keypair.fromSecretKey(
  "hardcoded-secret-key-12345" // これはしないでください！
);

2. アクセスポリシーの検証​

// 暗号化前に必ずアクセスポリシーを検証
async function secureEncrypt(data: Buffer, recipient: string) {
  const { sealClient } = await createSealClient();

  // 受信者アドレスを検証
  if (!isValidSuiAddress(recipient)) {
    throw new Error('無効な受信者アドレスです');
  }

  // ポリシーが存在し有効であることをチェック
  const policy = await validateAccessPolicy(policyId);
  if (!policy.isValid) {
    throw new Error('無効なアクセスポリシーです');
  }

  return sealClient.encrypt({
    data,
    recipientId: recipient,
    accessPolicy: policy
  });
}

3. エラーハンドリングとフォールバック​

// 堅牢なエラーハンドリング
async function resilientDecrypt(encryptionId: string, userKeypair: any) {
  const { sealClient } = await createSealClient();

  try {
    return await sealClient.decrypt({
      encryptionId,
      recipientId: userKeypair.toSuiAddress()
    });
  } catch (error) {
    if (error.code === 'ACCESS_DENIED') {
      throw new Error('アクセスが拒否されました：権限を確認してください');
    } else if (error.code === 'KEY_SERVER_UNAVAILABLE') {
      // バックアップ設定で再試行
      return await retryWithBackupServers(encryptionId, userKeypair);
    } else if (error.code === 'THRESHOLD_NOT_MET') {
      throw new Error('利用可能なキーサーバーが不十分です');
    } else {
      throw new Error(`復号化に失敗しました: ${error.message}`);
    }
  }
}

4. データ検証​

// 暗号化前にデータを検証
function validateDataForEncryption(data: Buffer): boolean {
  // サイズ制限をチェック
  if (data.length > 1024 * 1024) { // 1MB制限
    throw new Error('暗号化するにはデータが大きすぎます');
  }

  // 機密パターンをチェック（オプション）
  const dataStr = data.toString();
  if (containsSensitivePatterns(dataStr)) {
    console.warn('警告：データに潜在的に機密のパターンが含まれています');
  }

  return true;
}

パフォーマンス最適化​

1. バッチ操作​

// 効率性のため複数の暗号化をバッチ処理
async function batchEncrypt(dataItems: Buffer[], recipients: string[]) {
  const { sealClient } = await createSealClient();

  const promises = dataItems.map((data, index) =>
    sealClient.encrypt({
      data,
      recipientId: recipients[index]
    })
  );

  return Promise.all(promises);
}

2. キーサーバーレスポンスのキャッシュ​

// レイテンシを減らすためキーサーバーセッションをキャッシュ
class OptimizedSealClient {
  private sessionCache = new Map();

  async encryptWithCaching(data: Buffer, recipient: string) {
    let session = this.sessionCache.get(recipient);

    if (!session || this.isSessionExpired(session)) {
      session = await this.createNewSession(recipient);
      this.sessionCache.set(recipient, session);
    }

    return this.encryptWithSession(data, session);
  }
}

Seal統合のテスト​

ユニットテスト​

// tests/seal-integration.test.ts
import { describe, it, expect } from 'jest';
import { createSealClient } from '../src/seal-client';

describe('Seal統合', () => {
  it('データを正常に暗号化および復号化する必要があります', async () => {
    const { sealClient } = await createSealClient();
    const testData = Buffer.from('テストメッセージ');
    const recipient = '0x742d35cc6d4c0c08c0f9bf3c9b2b6c64b3b4f5c6d7e8f9a0b1c2d3e4f5a6b7c8';

    const encrypted = await sealClient.encrypt({
      data: testData,
      recipientId: recipient
    });

    expect(encrypted.encryptionId).toBeDefined();
    expect(encrypted.ciphertext).toBeDefined();

    const decrypted = await sealClient.decrypt({
      ciphertext: encrypted.ciphertext,
      encryptionId: encrypted.encryptionId,
      recipientId: recipient
    });

    expect(decrypted.toString()).toBe('テストメッセージ');
  });

  it('アクセス制御ポリシーを強制する必要があります', async () => {
    // 権限のないユーザーが復号化できないことをテスト
    const { sealClient } = await createSealClient();

    const encrypted = await sealClient.encrypt({
      data: Buffer.from('秘密'),
      recipientId: 'authorized-user'
    });

    await expect(
      sealClient.decrypt({
        ciphertext: encrypted.ciphertext,
        encryptionId: encrypted.encryptionId,
        recipientId: 'unauthorized-user'
      })
    ).rejects.toThrow('アクセスが拒否されました');
  });
});

本番環境へのデプロイ​

環境設定​

// config/production.ts
export const productionConfig = {
  keyServers: [
    process.env.KEY_SERVER_1,
    process.env.KEY_SERVER_2,
    process.env.KEY_SERVER_3,
    process.env.KEY_SERVER_4,
    process.env.KEY_SERVER_5
  ],
  threshold: 3,
  network: 'mainnet',
  suiRpc: process.env.SUI_RPC_URL,
  walrusGateway: process.env.WALRUS_GATEWAY,
  // セキュリティ設定
  maxDataSize: 1024 * 1024, // 1MB
  sessionTimeout: 3600000, // 1時間
  retryAttempts: 3
};

モニタリングとログ​

// utils/monitoring.ts
export class SealMonitoring {
  static logEncryption(encryptionId: string, recipient: string) {
    console.log(`[SEAL] ${recipient}用にデータ${encryptionId}を暗号化しました`);
    // モニタリングサービスに送信
  }

  static logDecryption(encryptionId: string, success: boolean) {
    console.log(`[SEAL] 復号化 ${encryptionId}: ${success ? '成功' : '失敗'}`);
  }

  static logKeyServerHealth(serverUrl: string, status: string) {
    console.log(`[SEAL] キーサーバー ${serverUrl}: ${status}`);
  }
}

リソースと次のステップ​

公式ドキュメント​

• Sealドキュメント: https://seal-docs.wal.app/
• GitHubリポジトリ: https://github.com/MystenLabs/seal
• Suiドキュメント: https://docs.sui.io/
• Walrusドキュメント: https://docs.wal.app/

コミュニティとサポート​

• Sui Discord: コミュニティサポートのため#sealチャンネルに参加
• GitHub Issues: バグ報告と機能リクエスト
• 開発者フォーラム: ディスカッション用Suiコミュニティフォーラム

探索すべき高度なトピック​

1. カスタムアクセスポリシー: Moveコントラクトで複雑な認証ロジックを構築
2. クロスチェーン統合: 他のブロックチェーンネットワークでSealを使用
3. エンタープライズキー管理: 独自のキーサーバーインフラストラクチャを設定
4. 監査とコンプライアンス: 規制環境向けのログとモニタリングを実装

サンプルアプリケーション​

• 安全なチャットアプリ: Sealによるエンドツーエンド暗号化メッセージング
• ドキュメント管理: アクセス制御付きエンタープライズドキュメント共有
• デジタル権利管理: 使用ポリシー付きコンテンツ配信
• プライバシー保護分析: 暗号化データ処理ワークフロー

結論​

Sealは、Web3におけるプライバシーと暗号化をインフラストラクチャレベルの関心事にする根本的な変化を表しています。アイデンティティベース暗号化、閾値セキュリティ、プログラマブルアクセス制御を組み合わせることで、開発者に真に安全で分散化されたアプリケーションを構築するための強力なツールを提供します。

Sealで構築することの主な利点には以下があります：

• 単一障害点の排除: 分散キーサーバーが中央権威を排除
• プログラマブルセキュリティ: スマートコントラクトベースのアクセスポリシーが柔軟な認証を提供
• 開発者フレンドリー: TypeScript SDKが既存のWeb3ツールとシームレスに統合
• ストレージ非依存: Walrus、IPFS、または任意のストレージソリューションと連携
• 本番環境対応: エンタープライズセキュリティ標準でMysten Labsが構築

ユーザーデータの保護、サブスクリプションモデルの実装、複雑なマルチパーティアプリケーションの構築のいずれであっても、Sealは自信を持って構築するために必要な暗号プリミティブとアクセス制御インフラストラクチャを提供します。

今日から構築を始めて、プライバシーを公共インフラストラクチャの基本的な部分にする開発者の成長するエコシステムに参加しましょう。

構築を始める準備はできましたか？ @mysten/sealをインストールして、このチュートリアルの例を試してみてください。分散ウェブは、プライバシーとセキュリティを第一に考えるアプリケーションを待っています。