はじめに

MaestroのOSS化は、「Maestroがコードを無料公開した」という単発ニュースとして見るより、

Cardanoのインデクサ/API層が“専用SaaS依存”から“自前運用・標準化・AI接続”へ移ってきた流れ

として見ると分かりやすい。

ここでいう OSS（Open Source Software：オープンソースソフトウェア） とは、ソースコードが公開され、一定のライセンス条件のもとで誰でも閲覧・利用・改変・再配布できるソフトウェアを指す。

結論から言えば、

以前は“ブロックチェーンを使うには専門業者のAPIを契約する”方向が強かったが、現在は“誰でも自前でインデクサを動かし、SQLやMCPで直接チェーンデータを扱う”方向へ戻ってきている。

これは単なる無料化ではなく、

Cardanoの開発基盤そのものの分散化

である。

1. そもそもなぜインデクサが必要なのか

Cardano nodeそのものが扱うのは、基本的にはブロックチェーンの生データである。

例えばアプリが、

• このaddressのUTXOは何か
• このtokenの保有者は誰か
• このDRepへの委任量はいくらか
• 過去30日のDEX取引量はいくらか
• このGovernance Actionへの投票状況はどうか

を取得したい場合、nodeの生データを直接扱うのは不便である。

そこで、

Cardano node
     ↓
  Indexer
     ↓
Database
     ↓
API
     ↓
DApp

という構造が必要になる。

Indexer（インデクサ） は、ブロックチェーンの生データを検索しやすい形へ整理・索引化するソフトウェアである。

API（Application Programming Interface） は、別のソフトウェアから機能やデータを呼び出すための接続窓口である。

DApp（Decentralized Application：分散型アプリケーション） は、ブロックチェーン上のスマートコントラクトやオンチェーンデータを利用して動くアプリである。

つまりインデクサは、

ブロックチェーンの生データを、アプリがすぐ使える検索可能なデータへ変換する層

である。

2. Cardano初期の問題は「全部自前だと重い」

以前、本格的なCardano DAppを作る場合、

cardano-node
+
cardano-db-sync
+
PostgreSQL
+
独自API

のような構成が必要になることが多かった。

PostgreSQL は代表的なオープンソースのRDBMSである。

RDBMS（Relational Database Management System：リレーショナルデータベース管理システム） は、表形式で整理したデータをSQLで検索・管理する仕組みである。

これは開発者にとってかなり重い。

Cardano Foundation側も、従来のオンチェーン分析では、

• nodeを運用する
• indexerを運用する
• databaseを維持する

必要があり、小規模チームには負担が大きかったと説明している。

そこで、

• Blockfrost
• Maestro
• Koios

などのAPI infrastructureが重要になった。

3. Maestroは「面倒を全部代わりにやる」側だった

Maestroの価値は分かりやすい。

開発者は、

DApp
 ↓
Maestro API
 ↓
Cardano

という構造で利用できる。

自分で、

node
indexer
database
maintenance

をすべて持つ必要がない。

MaestroはCardano、Bitcoin、DogecoinなどのUTXO系チェーン向けに、API、data service、indexing solutionを提供してきた。

ここでいう UTXO（Unspent Transaction Output：未使用トランザクション出力） は、BitcoinやCardanoで使われる台帳モデルで、まだ使われていない取引出力を資産状態として管理する。

Cardanoではこれを拡張した eUTXO（Extended UTXO） モデルが使われている。

Maestroのようなサービスは、

node・indexer・database運用をサービス事業者が肩代わりする

ことでDApp開発を大幅に簡単にした。

4. 便利になるほど中央集約点が生まれる

ただし、便利なAPI providerほど多くのDAppが依存する。

例えば、

DApp A ─┐
DApp B ─┼─→ Maestro
DApp C ─┤
DApp D ─┘

となる。

Blockchain自体は分散化されていても、

data access layerだけ特定企業へ集中する

可能性がある。

EthereumではInfuraやAlchemyへの依存が長年議論されてきた。

Cardanoでも、

Consensus = decentralized
Data access = centralized SaaS

という非対称が生じ得る。

SaaS（Software as a Service） は、ソフトウェアを自分で設置せず、インターネット経由のサービスとして利用する形態である。

5. API企業が悪いという話ではない

Managed APIには明確な価値がある。

Self-host（セルフホスト） とは、自分自身のサーバーやクラウド環境でソフトウェアを動かす運用形態である。

したがって、

MaestroがAPI事業を不要にした

という理解は正しくない。

重要なのは、

Managed serviceしか選択肢がない状態から、self-hostという逃げ道もある状態へ変化すること

である。

6. Cardano ecosystem全体で「portable / open / self-hostable」へ

Cardano ecosystemでは、

データアクセス自体を、よりportable、open、self-hostableにする

流れが強まっている。

Portable は、特定providerに強く依存せず、別環境へ移しやすいことを意味する。

Self-hostable は、自分で運用できる設計であることを意味する。

その代表がYaci Storeである。

7. Yaci Storeの登場

Yaci StoreはBloxBeanが開発するJavaベースのCardano indexerである。

概念的には、

Cardano node
      ↓
   Yaci Store
      ↓
structured data

となる。

従来のcardano-db-syncより、

• 組み込みやすい
• 開発環境を作りやすい
• モジュール化しやすい

方向に設計されている。

そしてYaci Store 3.0で性格が大きく変わってきた。

8. Yaci Store 3.0でIndexerからData Platformへ

2026年のYaci Store 3.0系ではAnalytics Storeが重要な追加要素になった。

従来、

Blockchain
 ↓
Indexer
 ↓
Database
 ↓
SQL

だったものが、

Blockchain
 ↓
Yaci Store
 ↓
Parquet files
 ↓
Laptop / SQL / Analytics

でも扱えるようになる。

SQL（Structured Query Language） は、リレーショナルデータベースや分析データに対して検索・集計・更新を行うための標準的な問い合わせ言語である。

Apache Parquet は、大量データ分析向けの列指向ファイル形式で、圧縮効率と検索効率が高い。

つまり、Cardano全履歴をParquetへ落とせれば、

node・indexer・live databaseを常時動かさなくても、ノートPC上で分析できる

方向へ進む。

これは大きな転換である。

9. Cardano blockchain自体を巨大な分析データベースとして扱える

Analytics Storeでは、

• blocks
• transactions
• UTXOs
• assets
• scripts
• metadata
• staking
• rewards
• treasury
• protocol parameters
• DReps
• governance votes
• proposals
• constitution

などをtable化できる。

つまり、

Cardano blockchainそのものを巨大なanalytics databaseとして扱う

ことが可能になる。

DRep活動の分析にも相性が良い。

10. Blockfrost互換APIの意味

Yaci Store 3.0ではBlockfrost-compatible APIも重要である。

これは、

Application
     ↓
Blockfrost API

向けに作られたアプリを、

Application
     ↓
Self-hosted Yaci

へ移しやすくする。

つまり、

API portability

が生まれる。

API portabilityが高まると、

• provider lock-inを弱める
• 障害時に代替しやすい
• コスト比較しやすい
• self-hostへ移行しやすい

という効果がある。

Vendor lock-in / Provider lock-in は、特定ベンダーや特定APIへの依存が強くなり、別サービスへ移行しにくくなる状態を指す。

11. MCPが入った意味

ここで2026年らしい変化が出てくる。

Yaci DevKitではMCP対応が進んでいる。

MCP（Model Context Protocol） は、AIモデルやAI Agentが外部ツール、データベース、API、ファイルなどへ標準的な方法で接続するためのプロトコルである。

つまり、

Human
 ↓
AI Agent
 ↓ MCP
Yaci
 ↓
Cardano data

という構造が作れる。

AIは単に文章を生成するだけでなく、

Cardanoのオンチェーンデータを直接読みに行く

ことが可能になる。

12. 以前と何が違うのか

以前は、

Developer
   ↓
API specificationを読む
   ↓
コードを書く
   ↓
Maestro / Blockfrost
   ↓
Cardano

という流れだった。

これからは、

Human / AI Agent
       ↓
      MCP
       ↓
 Yaci / data layer
       ↓
   Cardano

という構造になり得る。

つまりdata infrastructureが、

開発者向けAPI

から、

AIも直接扱えるmachine-readable infrastructure

へ変わっていく。

13. そこでMaestroのOSS化が意味を持つ

Maestro自身も、

managed serviceだけ

ではなく、

open-source tools + managed services

を組み合わせる方向へ進んでいる。

ここでいう Managed Service は、利用者自身ではなくサービス事業者がソフトウェアの運用・監視・更新・可用性確保まで担当する形態を指す。

つまり、

software = open
operation = paid

という構造へ寄っていく。

14. ビジネスモデルの変化

以前のinfrastructure businessは、

Indexer code
      ↓
非公開
      ↓
Hosted API
      ↓
subscription

という形になりやすかった。

Subscription は、月額・年額などの継続課金モデルである。

現在は、

Open-source indexer
       ↓
誰でもself-host
       ↓
必要ならManaged Serviceを購入

というモデルが強くなっている。

これはLinux、PostgreSQL、Kubernetesなどに近い。

Kubernetes（K8s） は、コンテナ化されたアプリケーションを複数サーバーで自動配置・運用するためのオープンソース基盤である。

15. OSS化してもMaestroは不要にならない

OSSがあっても、企業や大規模DAppは、

• 24/7 monitoring
• backup
• scaling
• high availability
• security
• support

を自分でやりたくない場合が多い。

そこで、

software = free/open
operation = paid

という市場が成立する。

ここでいう SLA（Service Level Agreement） は、サービス提供者が可用性や応答時間などについて契約上保証する品質水準である。

High Availability（HA：高可用性） は、一部の機器やサービスに障害があっても全体を止めにくくする設計である。

つまりOSS化は、

Maestroの商売を消すのではなく、価値の中心を「コード保有」から「運用品質」へ移す

可能性がある。

16. YaciとMaestroは競合だけではない

一見、

Yaci
vs
Maestro

に見える。

しかし実際には役割が違う。

CF（Cardano Foundation） は、Cardanoの普及、標準化、インフラ支援などを担うスイス拠点の非営利組織である。

つまり、

Yaciは基盤ソフトウェア寄り、Maestroはサービス運用寄り

と見ると整理しやすい。

17. 両者ともMCPへ向かう

MaestroにもMCP Serverが登場している。

MCP Server は、AI Agentが特定サービスやデータへアクセスできるよう、MCP形式で機能を公開するサーバーである。

これにより、

• Blockchain Indexer
• Mempool
• Market Price
• Wallet
• Node RPC

などをAIから扱う方向が開く。

RPC（Remote Procedure Call） は、別のコンピューターやプロセス上の機能を、あたかもローカル関数のように呼び出す仕組みである。

Mempool は、まだブロックに取り込まれていない未確定トランザクションを一時的に保持する領域である。

18. 競争軸が変わった

昔の競争軸は、

誰がAPI endpointを持っているか

だった。

これからは、

誰が最も良いdata layerを提供できるか
+
誰がAI Agentから最も使いやすいか
+
誰が最も信頼できるmanaged operationを提供できるか

へ変わる。

つまり、

APIそのものがcommodity化する

方向である。

Commodity化 とは、機能差が小さくなり、単なる提供有無より価格・運用・付加価値で差別化する状態を指す。

19. Dune参入も同じ流れ

Cardano dataがDuneへ統合されたことも、同じ流れである。

Dune は、ブロックチェーンデータをSQLで分析し、ダッシュボードや可視化を作成できるオンチェーン分析プラットフォームである。

ここでも、

• transactions
• tokens
• stake pools
• governance proposals
• votes
• DRep distributions

などをSQLで扱える。

Dune MCPも加わることで、

Human
 ↓
AI
 ↓
Dune MCP
 ↓
SQL / Dashboard

という形になる。

20. CardanoのData Layerは多極化しつつある

現在の流れを整理すると、

                Cardano
                   |
        +----------+-----------+
        |          |           |
      Yaci       Dune       Maestro
        |          |           |
     SQL/MCP     MCP/API     API/MCP
        \          |          /
         \         |         /
            AI / Developer

となる。

ここでいう Developer は開発者、AI Agent は目標に応じてツールやAPIを自律的に使うAIソフトウェアを指す。

21. Cardanoにとって健全な理由

Cardanoが分散型ネットワークであるなら、data accessも、

1 provider

に依存するより、

Yaci
Maestro
Blockfrost
Koios
Dune
独自indexer

が共存する方が健全である。

特定providerに障害や料金変更があっても、

DApp全体が止まりにくくなる。

22. Cardanoの「第二の分散化」

Cardanoでdecentralizationというと通常はSPOが注目される。

SPO（Stake Pool Operator） は、Cardanoでブロック生成ノードを運用し、ネットワークのコンセンサスと安全性を支える主体である。

しかし実際には、分散化には複数層がある。

DRep（Delegated Representative） は、ADA保有者からガバナンス投票権を委任され、オンチェーン・ガバナンスで投票する代表者である。

CC（Constitutional Committee：憲法委員会） は、Governance ActionがCardano憲法に整合するかを判断するガバナンス機関である。

今回の流れは、

Data Layerの分散化

である。

Amaruがnode implementation diversityなら、

Yaci / Maestro OSS化は、

indexer diversity

と見ることができる。

23. AI Agent時代では重要度が上がる

これまでは人間のdeveloperがAPIを呼んでいた。

今後は、

AI Agent
 ↓
MCP
 ↓
Indexer
 ↓
Blockchain

となる。

例えば、

「過去20 epochで投票率が低下したDRepを抽出」

とAIへ依頼すると、

MCP
↓
Yaci Analytics
↓
governance tables
↓
SQL

のように処理できる可能性がある。

Epoch は、Cardanoで時間を区切る単位で、現在は1 Epoch = 5日である。

24. Yaci + MCPならDRep業務も変わる

将来的には、

「今回のTreasury Proposalについて
上位100 DRepの投票を分析して」

とAIに依頼し、

AI
↓
Yaci MCP
↓
on-chain votes
↓
analysis

と処理できる。

あるいは、

「自分へのdelegationが
過去10 epochでどう変化したか」

という分析も自然言語で可能になる。

Treasury は、Cardano ecosystemの開発・運営などに使われるオンチェーン国庫である。

Yaci 3.0は単なるindexer upgradeではなく、

Cardano chain dataをAI-readableにする基盤

として重要である。

25. YaciとMaestro OSS化が合流する流れ

全体を時系列的に整理すると、

Phase 1
Nodeしかない
↓
自前indexingが必要

Phase 2
Managed API登場
↓
Blockfrost / Maestro

Phase 3
Open indexer成熟
↓
Yaci / Koios等

Phase 4
Open analytics
↓
Parquet / SQL / Dune

Phase 5
AI interface
↓
MCP

Phase 6
Agentic blockchain
↓
AIが直接chain dataを解析・取引

今は、

Phase 4 → Phase 5

へ移行している段階と見ると分かりやすい。

Agentic Blockchain は、AI Agentが人間の逐次操作なしにブロックチェーンデータを参照し、判断し、必要な操作を実行する構造を指す概念である。

26. 5段階シナリオ分析

以下は推測である。

中心シナリオは S4 と考える。

理由は、企業やDAppが完全self-hostへ移るとは考えにくい一方、

「いつでもself-hostへ逃げられる」

こと自体がprovider lock-inを弱めるからである。

27. まとめ

Maestro OSS化とYaci Store 3.0を一緒に見る意味はここにある。

昔は、

Cardano
 ↓
専門provider
 ↓
API
 ↓
Developer

だった。

現在は、

             Cardano
                ↓
     Open indexing layer
      /       |       \
   Yaci    Maestro    Dune
      \       |       /
        SQL / API / MCP
              ↓
       Developer / AI

へ変わりつつある。

したがって今回の本質は、

Maestroがコードを無料公開したことではなく、Cardanoのデータアクセス層そのものがオープン化・標準化され、AIから直接利用可能な公共インフラへ近づいていること

である。

Yaci Store 3.0の、

• Parquet
• SQL
• Blockfrost互換API
• MCP

という組み合わせは、その流れを明確に示している。

BWtakeのDRep視点では、

Governance dataをAIが直接読み、DRep投票、委任変化、Treasury履歴、Protocol Parameterを横断分析できる基盤ができ始めた

ことが特に重要である。

略語・専門語一覧

出典・情報源

• Cardano Foundation: Yaci Store / Cardano Data Analytics関連公開情報
• Cardano Foundation: 2026年6月活動報告
• Cardano Foundation: Dune統合関連公開情報
• Maestro公式GitHub
• Maestro API Specifications
• Maestro MCP Server
• BloxBean / Yaci Store関連公開情報

ファクトチェック上の注意

• MaestroのOSS化は「Maestroの全サービスが無料化・終了した」という意味ではない。
• Managed APIとOSS self-hostは今後も併存する可能性が高い。
• Yaci Store 3.0の価値はIndexer単体ではなく、Analytics、API互換、MCP連携を含むData Platform化にある。
• AI Agentによる自動分析・自動取引の大規模普及については将来予測であり、現時点で全面的に実現しているわけではない。
• 5段階シナリオの確率はCGTAによる推測である。

作成日時：2026-10-02 JST