The Graphとは、ブロックチェーン上の膨大なデータを整理・検索可能にする、分散型のインデクシングプロトコルです。
この記事では、全7回にわたるThe Graph解説シリーズの第4回として、Web3のエコシステムを支える「目に見えない主役」であるThe Graphが、具体的にどのようなdApp（分散型アプリケーション）で、いかなる課題を解決しているのかを紐解きます。UniswapやAaveといったDeFiの巨人たちが、なぜThe Graphなしでは成立しないのか、その理由も併せて解説します。
当ブログでは、The Graphについて詳細を知りたい方に向けて、以下の合計7記事にわたって解説します。ぜひとも第一回の記事から順番にご覧下さい。
Contents
第一回～第三回の振り返り
これまで、The Graphの全体像と歴史（第一回）、The Graphを動かす人の役割（第二回）、The Graphの進化の軌跡（第三回）をご紹介してきました。
すなわち、これまでは「The Graphというインフラの仕組み」という土台の話をしてきましたが、今回の記事では、The Graphという土台を、どのようなサービスが、どのように使用しているかという点に焦点を当てていきましょう。
dApp(分散型アプリケーション)とは?
The Graphを利用している組織や開発者について語る前に、まずはその舞台となるdApp（Decentralized Applications / 分散型アプリケーション）について整理しておきましょう。
私たちが普段スマートフォンで使っているアプリ（Web2アプリ）と、dAppの決定的な違いは、その心臓部がどこにあるかです。
中央集権的なサーバーからの脱却
InstagramやYouTubeのような従来のアプリは、MetaやGoogleのような特定企業が管理するサーバー上で動いています。この状態を、当該企業の独占的な管理下にあるという意味で、中央集権的と呼ばれます。この状況下では、その企業が「サービスを止める」と言えば、ユーザーにはどうすることもできません。
これに対し、dAppは特定の企業ではなく、EthereumやArbitrumといったブロックチェーンの上で動くアプリケーションを指します。
dAppには、従来のアプリにはない決定的な3つのメリットがあります。
- 「検閲耐性」特定の管理者が存在しません。世界中に分散したコンピューター群がネットワークを支えているため、誰にも止めることができず、24時間365日稼働し続けます。
- 「改竄耐性」アプリケーションの動作ルールは「スマートコントラクト」としてプログラム化されています。一度ブロックチェーンに書き込まれたルールは、開発者であっても勝手に書き換えることはできません。
- 「透明性」すべての取引履歴やコードは公開されており、誰でも検証可能です。特定の企業を「信じる」必要はなく、公開された「コード」そのものが信頼の根拠となります。
dAppを語るうえで最も革新的な仕組みこそがスマートコントラクトです。 これは、ブロックチェーン上で「もしAという条件が満たされたら、Bを実行する」という契約を自動で実行する仕組みです。
例えば、DeFi（分散型金融）のdAppであれば、「担保を預けたら、対価としてトークンを貸し出す」という動作を、銀行員の手を介さずプログラムが自動で行います。このプログラムの内容はブロックチェーン上に公開されているため、誰であっても内容を監査することができます。
このような構造的な違いこそが、特定の管理者を信頼する必要のない新しいサービスの形としてdAppが注目されている理由です。
ところが、第一回でブロックチェーンの構造上の課題として述べた通り、「データの書き込みやスポット的な表示に強い一方で、条件付き検索に弱い」という点が、dAppsを実用化するうえでの課題となっていました。
ブロックチェーンの「データの壁」
ブロックチェーンは、例えるなら「通し番号しか振られていない巨大な日記帳」です。
あなたがその日記の中から、「山田さんとショッピングに行った日はいつだったか？」という特定の出来事を探そうとする場合、時期にある程度の当たりがない限り、目次も索引もない日記帳からその日を特定するには、1ページ目から順番に指でページをめくって、一日ずつ内容を確認していくしか方法がないことでしょう。
それと同様の事態が、ブロックチェーンで発生していたのです。なお悪いことに、現実のブロックチェーンには１日に何百万もの新しい情報が書き込まれていくため、どれほど処理能力に優れたコンピューターであっても、そのすべての履歴をスキャンするには多大な時間を要しました。
一方で、dAppはウェブ上でユーザーからのリクエストに応じて、瞬時にブロックチェーンから情報を探し当てなければなりません。現代のウェブサービスにおいて、そのレスポンスは長くとも数秒以内に収める必要があります。ページを開くたびに計算が終わるまで何時間も待ってくれるようなユーザーは、一人も存在しないからです。
この「データの壁」という絶望的な状況を打破し、dAppに快適な操作性をもたらす救世主こそがThe Graphでした。先の例でいえば、The Graphは、日記帳をあらかじめすべて読み込み、何がどこに書いてあるかを整理して、誰でも即座に検索できる目次を作成しておく図書館の検索システムの役割を果たしたのです。
では、具体的にどのようなサービスがThe Graphを使っているのでしょうか？今回は、特に著名なサービスである「Uniswap」「Aave」「ENS」の3つを見てみましょう。
Case1: Uniswap 世界最大の分散型取引所
dAppにおけるThe Graphの活用事例を語る上で、Uniswapを避けて通ることはできません。
Uniswapは、証券会社のような仲介者を一切介さず、ユーザー同士が直接トークンを交換できるDEX（分散型取引所）のパイオニアです。自動マーケットメーカーという仕組みを先駆的に導入したことでも知られています。
DeFiLlamaによれば、分散型取引所の分野においてUniswapはTVL(Total value locked; 預かり総資産)で総額33億ドル（2026年2月1日時点）、すなわち5000億円以上の資産がプールされている、世界一位の巨大取引所でもあります1。
ここで注目すべきは、UniswapがTVL世界1位の座を競っていること以上に、「世界で最もデータを消費しているdApp」であるという点です。
ユーザーがUniswapの画面を開いたときに見る以下の情報は、すべてThe Graphから提供されています。
- 取引ボリューム: 過去24時間でどれだけの交換が行われたか。
- 価格チャート: 通貨ペア画面で生成されるローソク足。
- 流動性プール: どの通貨ペアにどれだけの残高があるか。
もしThe Graphが止まればUniswapの画面からはあらゆる数字が消え、利用者は「どのペアをいくらで交換できるのか」すら分からない暗闇の中で取引を強いられることになります。
The Graphにおける圧倒的な需要
UniswapがThe Graphに投げるリクエストの量は圧倒的です。
Graph Explorerのサブグラフ一覧ページでUniswap関連のサブグラフを検索してみましょう。2026年2月1日時点において、Uniswapに関連するサブグラフは月間で数億件のクエリを処理しています。
これは、個人のユーザーだけでなく、世界中の取引ボットや分析ツール、他のdAppまでもが「Uniswapにおける今の正確な状態」を知るために、The GraphのAPIを叩き続けているからです。
v1からv4へ：進化と共に歩んだ歴史
Uniswapは2018年に誕生したv1から2025年1月にローンチしたv4に至るまで、劇的な進化を遂げてきました。
システムの構造がどれほど高度になっても、Uniswapチームは一貫してデータのインデクシングにThe Graphを採用し続けてきました。業界のリーダーが「データの整理は自前でやるより、The Graphに任せるのが最も効率的で信頼できる」という答えを、8年以上にわたって出し続けているのです。
業界標準となった「DEX × The Graph」
Uniswapの成功を受けて、その公開されているスマートコントラクトを元にして作られた、いわゆる「フォーク版」の取引所が次々と誕生しました。その代表格が、BNBスマートチェーンを中心に成長したPancakeswapや、ヴァンパイア攻撃によってUniswapからの顧客奪取を目論んだSushiswapです。Pancakeswapは現在の預かり資産22億ドル(3400億円)で業界二位、Sushiswapも預かり資産6800万ドルで一定の規模を誇る巨大取引所です。
これらのプロジェクトは、単に取引の仕組みをコピーしただけではありませんでした。彼らがUniswapから学んだ最も重要なことの一つは、ユーザーに「今、何が起きているか」を正しく伝えるためのデータの視覚化でした。そのための手軽かつ堅牢な解決策が、やはりThe Graphを利用することだったのです。
現在では、新しい分散型取引所が立ち上がる際、スマートコントラクトを公開するのとほぼ同時にThe Graphでサブグラフを公開することが、Web3業界における「作法」となっています。もし新しい取引所がThe Graphを利用せず、自前でデータを集計しようとすれば、それだけで開発スピードは数ヶ月遅れ、競合に対して不便な仕組みをユーザーに強要し、その結果として業界で地位を確立することが困難となるからです。
このように、The GraphはUniswapという世界最大の成功者を支えるだけでなく、PancakeswapやSushiswap、そしてその後に続く数多の取引所に対して、最も有力な業界標準の一つとなっています。
Case2: Aave 世界最大の暗号通貨レンディングプラットフォーム
次にご紹介するAaveは、Web3の世界における「銀行」の役割を担う巨大なプロトコルです。
2017年にスタニ・クレチョフ氏によって設立されたこのプロジェクトは、当初はETHLendという名称で始まり、その後Aaveへとリブランディングされました。Aaveでは、従来の銀行で行われる「資産を預けて利息を得る」「資産を担保にお金を借りる」という行為が、スマートコントラクトによって完全自動で実行されます。
特筆すべきはその圧倒的な規模です。2026年2月1日時点のデータによれば、AaveのTVL（預かり総資産）は約290億ドル、日本円にして約4.4兆円を超えており、DeFi市場において圧倒的一位のプロトコルとして君臨しています2。
この巨大な銀行においても、The Graphは安全装置としての極めて重要な役割を果たしています。Aaveで資産を借りる際、最も重要な指標となるのが「ヘルスファクター」と呼ばれる数値です。これは、預けている担保の価値に対して、借りている金額がどれほど安全な水準にあるかを示す健康診断のようなもので、従来型金融における与信審査に相当します。もし担保価格が下落して数値が一定ラインを割り込めば、借り手の資産は即座に清算されることになります。
利用者が自分のダッシュボードを開いたとき、自分の現在のヘルスファクターがいくらで、清算まであとどれくらいの猶予があるのかをリアルタイムで確認できるのは、The Graphが裏側で常に各ユーザーの借入状況を監視し、整理されたデータとしてアプリに提供し続けているからです。また、過去から現在に至るまでの貸付金利や借入金利の推移グラフも、The Graphのサブグラフが膨大な履歴データを瞬時に集計することで実現されています。
もしThe Graphが存在しなければ、利用者は自分の資産が今どのようなリスクにさらされているのかを直感的に把握することが困難になります。それは、自分の資産がいつ没収（清算）されてもおかしくない危機的な状況にあることに自分で気づけないということを意味します。当然、そのような情報の非対称性が存在する中で、Aaveを利用する人は多くないでしょう。
世界最大の預かり資産を誇るAaveにとって、The Graphは単なるデータの取得先を超えて、システムの健全性とユーザーからの信頼を守るための重要な基盤となっています。
ネットワーク間の壁を取り払ったThe Graph
再びGraph Explorerのサブグラフ一覧ページに戻り、次はAave関連のサブグラフを検索してみましょう。
先ほどのUniswapとは対照的な光景が広がっていることに気づくはずです。
Uniswapのサブグラフは一つあたりのクエリ数が圧倒的であるのに対し、Aaveに関連するサブグラフは、驚くほど膨大な種類が並んでいます。これは、AaveがEthereumだけでなく、Polygon、Avalanche、Arbitrum、Optimism、BaseやScrollといった、あらゆる主要なネットワークへ展開していることの現れです。
このように、複数のネットワークを統合して一つのアプリケーションとして機能させることは、Layer 1、Layer 2のいずれにおいても苛烈な競争が繰り広げられている昨今においては、ユーザービリティの観点から現代のdApp開発で避けては通れない道となっています。これをThe Graphなしで、自前のサーバーで実現しようとすると、そこには多大な苦難が待ち受けています。
まず直面するのは、物理的なインフラコストの壁です。それぞれのブロックチェーンからデータを読み取るためには、各ネットワークごとに「フルノード」と呼ばれる専用のサーバーを稼働させ続けなければなりません。イーサリアム一つをとってもテラバイト級のストレージと高度な処理能力が必要ですが、それが複数のネットワークに増えれば、サーバーの維持費やエンジニアの人件費の数は、それに比例して増加していくことになります。
The Graphは、このよう複雑な作業を抽象化し、APIだけを提供します。そこにはサーバー費用や人件費も存在せず、ただクエリ数に応じた手数料を払う必要があるのみです。
開発者は背後にある無数のサーバー群やネットワークごとの細かな仕様の違いを一切気にすることなく、ただ「全てのチェーンを統合した、最高のユーザー体験」を作ることに専念できるのです。Aaveという世界最大の暗号通貨レンディングサービスがこれほどまでに多角的な展開をスピーディーに実現できた裏には、こうした過酷なインフラ管理をThe Graphという分散型のネットワークへアウトソーシングできたという、戦略的な合理性が隠されています。
Case3: ENS Web3のアイデンティティプロバイダ
最後に、Web3における身分証明として不可欠な役割を果たしているENS(Ethereum Name Service)について触れておきましょう。
Web3の世界に足を踏み入れた人が最初に直面する壁は、「1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa」のように無意味な英数字のウォレットアドレスです。暗号通貨によっては更に長い桁数が用いられていることもありますし、そのうち1文字でも間違えればそのお金はウォレットの持ち主でない限り決して動かせないため、これを友人同士で教え合ったり、請求書に書いたりするのはリスクの塊でしかありません。
この課題を解決するために2017年に誕生したのがENS（Ethereum Name Service）です。ENSは、複雑なアドレスを「yamada.eth」のような人間が読める名前に変換する、いわば「Web3版の電話帳」（あるいはDNS）です。
2026年現在、登録ドメイン数は168万を超え、Web3における最も標準的なアイデンティティ・インフラとしての地位を確立しています。
車輪の再発明に対する終局的な解決
このようなENSの仕組みは一見するとシンプルなものに思えるかもしれませんが、この「誰がどの名前を持っているか」という情報をアプリケーションに表示させる際、中央集権的なデータベースの考え方では非常に大きな非効率が生じることになります。
もしThe Graphが存在せず、それぞれのアプリケーションが独自に名前解決用のデータベースを構築・維持しなければならないとしたら、それぞれの開発者は新しいアプリを作るたびに、ENSの膨大な履歴をブロックチェーンからスキャンして整理し直すという、全く同じ作業をゼロから繰り返さなければなりません。これは、Web3の世界に数千のアプリがあれば、数千回も同じ「車輪の再発明」が行われることを意味します。それぞれの開発者が同じデータを管理するためのサーバー代を払い、同じエンジニアのリソースを割くことは、エコシステム全体にとって多大な損失です。
The Graphのサブグラフは、この無駄を劇的に解消しました。ENSによって作成された「ENSサブグラフ」は、誰に対しても開かれた公共財のようなAPIとして提供されています。新しいSNSを作る開発者も、NFTマーケットプレイスを作る開発者も、自分たちで名前解決用のデータベースを自作する必要は一切ありません。すでに作成され、世界中のインデクサーによって常に最新状態に保たれている既存のサブグラフを「再利用」するだけで、わずか数行のコードで正確な名前データを自分のアプリに組み込むことができるのです。
このように、一度作られた「情報の整理術」を全員で共有し、誰でもプラグインのように接続できる仕組みこそが、Web3の開発スピードを加速させる真の原動力となっています。The Graphは、個別のアプリの裏方である以上に、Web3という巨大なエコシステム全体で共通して使える「開かれた電話帳」として、無意味な重複作業をこの世界から決定的に排除したのです。
第四回のまとめ
Uniswapの価格チャート、Aaveの安全スコア、そしてENSのプロフィール表示といったdAppにおけるクリティカルな機能、それらに裏打ちされるユーザーの利便性は、ブロックチェーンという巨大な日記帳をThe Graphという索引システムで読み解くことで初めて成立しています。
もしThe Graphのような検索システムが存在しなかったら、Web3の世界は不透明で遅く、使いにくい不毛な地のままだったかもしれません。The Graphは、バラバラに散らばったデータの断片を、私たちが理解できる「意味のある情報」へと変換し、何百、何千というdAppから構成される巨大市場を影から支えているのです。
次回予告
第4回では、現在のWeb3を支える「実需」としてのThe Graphを見てきました。
しかし、Web3はまだまだ発展途上の世界であり、馴染み深く感じられなかった方もいるかもしれません。
次回の第5回では、The Graphの将来性を決定づけるかもしれない、より広大な市場への挑戦に迫ります。
GoogleやCoinbaseと連携したx402決済プロトコルへの挑戦、そして米国DTCCという世界の金融の核となる機関がいかにしてThe Graphの技術を評価し活用しようとしているのか。The Graphの止まらない挑戦についてご紹介していきます
当ブログでは、The Graphについて詳細を知りたい方に向けて、以下の合計7記事にわたって解説します。ぜひとも第一回の記事から順番にご覧下さい。
