Source / Publication

• 記事：SIPO「Yaci Store 3.0.0 ベータに SQL 分析層と MCP

サーバー」

• 公開日：2026-09-27
• 主な一次情報：Cardano Foundation、BloxBean / Yaci Store

GitHub、Yaci Store公式ドキュメント

• 検証日：2026-09-28 JST
• Cardano Epoch：658

一文要約：Yaci Store 3.0.0 betaは、CardanoのチェーンデータをAPIだけでなくSQLとMCPから扱えるようにし、「人間・dApp・AI Agentが同じオンチェーン事実へアクセスするローカルデータ基盤」へ発展しつつある。

結論

この記事のポイントは、Yaci Storeが単なる「Cardano用インデクサ」から、

Cardanoのデータを、人間・アプリ・AI Agentが共通して利用できるローカル・データ基盤

へ変わりつつあることです。

構造を単純化すると、次のようになります。

Cardano blockchain
        ↓
    Yaci Store
        ↓
 ┌──────┼──────┐
 API    SQL     MCP
 ↓       ↓       ↓
dApp   人間分析  AI Agent

3.0.0 betaで重要なのは、単にAPIの種類が増えたことではありません。

Cardanoのオンチェーン事実を、API・SQL・AIの三つの入口から利用できる方向へ設計が進んでいることが本質です。

1. そもそもYaci Storeとは何か

Cardanoノードそのものは、ブロックチェーンの正しい状態を検証することが主目的です。

しかし、DRepやアプリ開発者が知りたいのは、たとえば次のような情報です。

• 特定アドレスの取引履歴
• DRepの投票履歴
• Governance Actionの状態
• SPOの投票
• UTXO
• Native Asset
• Token metadata
• staking / rewards
• protocol parameters
• treasury関連データ

これらをノードの生データから毎回取り出すのは扱いにくいため、ブロックチェーンを検索・分析しやすい形へ変換するindexerが必要になります。

Yaci Storeは、このCardano向けインデックス基盤です。

従来のイメージは、

Cardano Node
    ↓
Yaci Store
    ↓
REST API
    ↓
Application

でした。

3.0系では、ここに分析層とAI接続層が加わってきました。

2. SQL分析層がかなり重要

今回の大きな変更の一つが、Parquet形式で保持したCardanoデータをDuckDBからSQLで問い合わせられる分析層です。

概念的には、

Cardano
   ↓
Yaci Store
   ↓
Parquet
   ↓
DuckDB
   ↓
SQL

となります。

DuckDBとは

DuckDBは、非常に大ざっぱに言えば、

分析処理に強い「SQLite的なローカルSQLエンジン」

と考えると分かりやすいです。

巨大なデータベースサーバーを別途構築しなくても、ローカルファイルに対してSQL分析を行えます。

Parquetは列指向のデータ形式なので、分析用途との相性がよく、オンチェーン履歴のような大量データを絞り込む処理に向いています。

Cardano Foundationが2026年6月に紹介したYaci Analytics Storeでは、Cardanoの全履歴をParquetとして扱い、通常のPCでも分析できる方向性が示されています。

Foundationの説明では、ブロック、トランザクション、UTXO、入力、script、datum、metadata、asset、staking、reward、protocol/economics、governanceなどを含む多数のexporterが用意されています。

Governance領域には、DRep、vote、governance proposal、committee、constitutionなども含まれます。

3. DRepにとってSQL化は非常に大きい

BWtakeのようなDRepにとって重要なのは、Yaci Storeが単なる開発者用ツールではなく、

自分でオンチェーン事実を検証するための調査基盤

になり得ることです。

たとえば、次のような調査が可能になります。

調査対象 例 --------------------- -------------------------------- DRep投票履歴 特定DRepが過去にどう投票したか Voting Power 時系列で委任量がどう変化したか Governance Action 類似提案が過去に存在したか Treasury 過去の資金引き出し履歴 SPO voting SPO側の投票状況 Protocol Parameters パラメータ変更履歴 Stake DRep/SPOのstake構造 Proposal 提案と投票結果の横断分析

これはCardanoガバナンスでは特に重要です。

Cardano憲法ではTreasury Withdrawalについて、受領者が過去24か月にTreasuryからADAを受け取ったかなど、一定の開示・検証可能性を求める基準があります。

したがって将来的には、

SELECT
    recipient,
    SUM(amount)
FROM treasury_withdrawals
WHERE date >= current_date - INTERVAL '24 months'
GROUP BY recipient;

のような考え方で、DRep自身がオンチェーン履歴を照合する環境を作れます。

つまり、

「誰かのダッシュボードを見る」から「自分でチェーンに問い合わせる」へ

移れるわけです。

4. MCPサーバーが加わる意味

今回もっとも未来的なのがMCPです。

MCPはModel Context Protocolで、AIモデルやAIツールが外部データ・ツールへ標準化された形で接続するための仕組みです。

Yaci StoreにMCPサーバーが入ると、概念的には次の構造になります。

CGTA / AI Agent
      ↓
     MCP
      ↓
  Yaci Store
      ↓
   DuckDB
      ↓
   Parquet
      ↓
Cardano blockchain data

これまでは人間がSQLを書いていました。

SELECT *
FROM governance_votes
WHERE drep_id = '...';

MCPを介すると、将来的には人間が、

このDRepの過去1年間の投票履歴を調べて。
Treasury Withdrawalだけ抽出して。

と指示し、

自然言語
   ↓
AI
   ↓
SQL生成
   ↓
Yaci Store
   ↓
結果
   ↓
AIが整理

という流れが可能になります。

SIPO記事が紹介したMCP実装では、AI側からtable/schemaを確認し、SQLを実行する仕組みが示され、専用のbalanceやtop addresses系の機能も説明されています。

記事では、返却行数やquery timeoutにも制限が設けられ、MCP自体はデフォルト無効とされています。

このあたりは、AIに無制限なデータベース操作権を与えないための基本的な安全設計として重要です。

5. Blockfrost互換APIの意味

3.0.0 betaではBlockfrost互換APIも拡張されています。

BlockfrostはCardanoアプリがチェーンデータを取得する代表的なAPI基盤の一つです。

従来、

dApp
 ↓
Blockfrost
 ↓
Cardano

だったアプリが、互換性が十分に確保されれば、

dApp
 ↓
Yaci Store
 ↓
Cardano

というself-hosted構成を選びやすくなります。

これはBlockfrostを不要にするという話ではありません。

重要なのは、

ホステッドAPIと自己運用インデクサの選択肢が増える

ことです。

Cardanoの分散化を考える場合、チェーンそのものが分散していても、多くのアプリが少数のデータAPIへ依存すれば、観測層に集中点ができます。

Yaci Storeのようなself-host可能なindexerは、この依存を減らす選択肢になります。

6. Yaci Storeは「AIの目」になり得る

BWtakeが最近追っているCardanoのAI関連技術を並べると、かなり面白い構造が見えてきます。

Cardano
 ├─ settlement
 ├─ eUTXO
 ├─ governance
 └─ native assets

Yaci Store
 ├─ chain indexing
 ├─ API
 ├─ SQL
 └─ MCP

Masumi
 ├─ AI Agent identity / registry
 ├─ payment
 ├─ escrow
 ├─ refund
 └─ action log

x402
 └─ machine-to-machine payment

Midnight
 ├─ privacy
 └─ selective disclosure

ここでYaci Storeの役割は、

AI AgentがCardanoを観測するための「目」

に近いものになります。

AI Agentの基本サイクルを単純化すると、

Observe
   ↓
Reason
   ↓
Decide
   ↓
Act
   ↓
Observe

です。

これまでCardanoのAI Agent構想では、Masumiやx402などAct側が注目されがちでした。

しかし、自律Agentにはその前段として、

現在のチェーン状態を正確に読む能力

が必要です。

Yaci Store + SQL + MCPは、まさにObserve側を強化します。

7. x402 × Masumi × Yaci Store

三つを並べると役割分担が明確になります。

技術 主な役割 ------------ ------------------------------------------- Yaci Store オンチェーン情報を読む MCP AIとYaciを接続する Masumi Agentの登録・支払い・escrow・行動記録など x402 Web/API利用時のmachine payment Cardano 決済・資産・ガバナンスの基盤 Midnight privacy / selective disclosure

たとえば将来、AI Agentがサービスを購入する場合、

AI Agent
   ↓
Yaci MCP
   ↓
残高・価格・履歴確認
   ↓
Reasoning
   ↓
x402
   ↓
API料金支払い
   ↓
Masumi
   ↓
Agent payment / action record
   ↓
Cardano settlement

のような構成が考えられます。

ただし、これは現時点ですべてが一体化して完成しているという意味ではありません。

現在は、それぞれの部品が個別に整備され始め、相互接続可能な形が見え始めた段階です。

8. Midnightまで入れるとさらに意味が変わる

AI Agentがオンチェーン情報を読むだけなら、公開チェーンだけでも可能です。

しかし現実の経済活動では、

• 個人情報
• 契約条件
• 医療情報
• 企業秘密
• 取引相手
• API credential
• 内部評価
• 非公開のAgent context

など、公開できない情報があります。

そこでMidnightのprivacy / selective disclosureが加わると、

Public facts
     ↓
Cardano / Yaci

Private facts
     ↓
Midnight

        ↓
     AI Agent
        ↓
必要な情報だけ利用・証明

という設計が可能になります。

したがって、長期的には、

Cardano = 公開された経済状態

>

Midnight = 非公開・選択開示される状態

>

Yaci = 公開オンチェーン状態の観測

>

MCP = AIとの接続

という分業が成立する可能性があります。

9. これはCardanoの分散化にも関係する

Cardanoの分散化というと、通常は、

• SPO
• DRep
• Constitutional Committee
• node
• stake distribution

が議論されます。

しかしAI時代には、もう一つ重要な層があります。

それが、

data access layer

です。

もしAI AgentがCardanoを利用するとき、

AI
 ↓
中央API
 ↓
Cardano

しか選択肢がなければ、チェーンが分散していても、AIの観測経路は集中します。

一方、

AI
 ↓
MCP
 ↓
自分のYaci Store
 ↓
Cardano

が可能なら、観測層もself-hostできます。

これはCardanoの「検証可能性」と非常に相性がよい方向です。

10. ただしAIがSQLを使えること自体は正しさを保証しない

ここは重要です。

AIがYaci Storeへ直接アクセスできても、

AIの回答が自動的に正しくなるわけではありません。

たとえば、

質問
 ↓
AI
 ↓
間違ったSQL
 ↓
正しいチェーンデータ
 ↓
間違った集計
 ↓
間違った結論

は普通に起こり得ます。

したがって必要なのは、

Chain data
   ↓
SQL
   ↓
Result
   ↓
AI interpretation
   ↓
Human verification

です。

特にDRepの投票判断では、

• SQL
• query条件
• 集計期間
• stake snapshot
• deregistration
• stale vote
• proposal state
• constitutional interpretation

などを分離して検証する必要があります。

Yaci Store 3.0の価値は「AIが正しくなる」ことではなく、

AIの回答をオンチェーン事実へ接地しやすくする

ことにあります。

11. Governance集計修正も地味だが重要

SIPO記事では3.0.0-beta4について、Governance/DRep APIだけでなく、governance aggregationに関する修正も紹介されています。

例として、

• deregistered SPOのdefault vote
• proposal depositをSPO stake計算へ反映
• deregistered DRepの古いvoteを無視する処理

などです。

Governanceデータは単純な「voteの一覧」ではありません。

Cardanoでは登録状態、stake、snapshot、default vote、proposal状態などが最終集計へ影響します。

したがってindexer側の集計ロジックが不正確なら、

チェーン自体は正しいのに、ダッシュボードやAIが見ている数字が違う

ということが起こり得ます。

DRepとしては、こうした修正はUI改善より重要な場合があります。

12. 3.0.0 betaと2.0.3 stableを分けて考える

今回の記事では、3.0.0 betaだけでなく、同時期にstable 2.0.3も公開されたとされています。

概念的には、

系列 位置付け ------------ -------------------- 2.0.3 安定運用側 3.0.0 beta 次世代機能の検証側

と見るのがよいでしょう。

3.0系で注目されるのは、

• 新しいBlockfrost-compatible API
• analytics layer
• MCP
• Java plugin

などです。

一方、productionで利用する場合には、betaであることを軽視すべきではありません。

記事では3.0 betaについて、既存DBのin-place upgradeよりもgenesisからのresyncが推奨される旨も紹介されています。

これはまだデータ構造やmigration前提が固まり切っていないことを示す重要な注意点です。

13. BWtake向けに最も面白い用途：DRep専用オンチェーン調査AI

BWtakeの用途に置き換えると、かなり具体的です。

BWtake
   ↓
CGTA
   ↓
MCP
   ↓
BWtake Yaci Store
   ↓
Cardano

たとえばGovernance Actionが提出されたとします。

BWtakeが、

この提案者または受領主体は過去にTreasury資金を受け取っているか。\ 類似提案はあるか。\ 過去の投票結果はどうだったか。\ 現在のDRep/SPO投票構造はどうなっているか。

と質問します。

CGTA側がYaci MCPを通じて、

proposal
 ↓
past treasury funding
 ↓
related proposals
 ↓
DRep votes
 ↓
SPO votes
 ↓
stake structure
 ↓
protocol parameters

を取得し、その上で憲法・提案文・予算文書と照合する。

これは単なる「AI検索」ではありません。

オンチェーン一次データを根拠にしたDRep意思決定支援

になります。

BWtakeのFBLやDRep活動とはかなり相性がよい構成です。

14. 「AI Agent Cardano Stack」として見る

今回のYaci Storeを単独ニュースとして見るより、最近のCardano周辺の動きを一つのstackとして見る方が本質を捉えやすいと思います。

┌───────────────────────────┐
│ AI Agent / CGTA           │
├───────────────────────────┤
│ MCP                       │
├───────────────────────────┤
│ Yaci Store / SQL / API    │
├───────────────────────────┤
│ Masumi / x402             │
├───────────────────────────┤
│ Cardano                   │
├───────────────────────────┤
│ Midnight                  │
└───────────────────────────┘

役割を言葉にすると、

層 機能 -------------- --------------------------------- AI Agent 判断 MCP 接続 Yaci 観測 SQL / DuckDB 分析 Masumi Agent経済・支払い・記録 x402 machine payment Cardano settlement / asset / governance Midnight privacy

となります。

15. 今回のニュースを一言で表現すると

CGTAは今回のYaci Store 3.0を、

Cardanoに「AIが読めるオンチェーン観測層」を作り始めた動き

と捉えます。

以前整理した流れと接続すると、

x402
= AIの「支払い口」

Masumi
= AI Agentの「経済活動・identity・action」

Yaci + SQL + MCP
= AIの「目・データ分析器」

Midnight
= AIが扱う「秘密・privacy」

となります。

まだ各部品が完全統合されたわけではありません。

しかし、

AIがCardanoを読む → 判断する → 支払う → 行動する → 結果を再び読む

という循環を作るための部品は、以前より明確になってきました。

16. シナリオ分析

以下はCGTAによる将来シナリオ推定であり、一次情報ではありません。確率は技術成熟度、導入コスト、Cardano開発者による採用、MCPの普及、Masumi/x402等との接続可能性を踏まえた主観的推定です。

Scenario 内容 推定確率 --------------------- ---------------------------------------------------------------------------------------------------------- ---------------------------- S5 Yaci + MCPがCardano AI 15% Agentの標準的データ層の一つとなり、Masumi・x402等と組み合わされ、自律Agentの観測→判断→決済ループが実用化

S4 Cardano開発者・DRep・分析者のAIオンチェーン分析でYaci MCPが広く利用される 35%

S3 SQL/Parquet分析層は定着するが、MCP利用は一部の開発者・分析者にとどまる 35%

S2 主にBlockfrost互換APIや従来型indexerとして利用され、AI/MCPは限定的 12%

S1 運用負荷、resync、データ量、AI接続の安全性・複雑性などが障壁となり、3.0系新機能の普及が進まない 3%

中心シナリオはS3〜S4です。

SQL/Parquetによるローカル分析は用途が明確であり、比較的定着しやすい一方、MCPがCardano開発・DRep分析の標準経路になるかは、今後のstable化、tooling、権限管理、AI側のMCP採用状況に左右されます。

17. 今後見るべきポイント

今後は次の点を追う価値があります。

1. 3.0.0 stableの公開時期
2. genesis resync要件がstableでも残るか
3. MCPがデフォルト無効のままか
4. MCPの権限・read-only設計がどう整理されるか
5. SQL schemaがどの程度安定するか
6. Blockfrost互換範囲がどこまで拡大するか
7. DRep/Governance向けqueryの標準化
8. Masumiや他のAI Agent frameworkとの実接続
9. x402系machine paymentとの接続
10. Cardano + Midnightをまたぐpublic/private data accessの実装

特にBWtakeのDRep活動という観点では、

Governance Actionを入力すると、オンチェーン履歴・stake・過去のTreasury支出・類似提案・投票履歴を自動調査するDRep専用Agent

が現実的な次の実験候補です。

Sources

今回の記事

• SIPO, 「Yaci Store 3.0.0 ベータに SQL 分析層と MCP サーバー」,

2026-09-27

一次・高信頼情報

• Cardano Foundation, "How to Get Cardano Data Without

Infrastructure", 2026-06-22\ https://cardanofoundation.org/blog/how-to-get-cardano-data-without-infrastructure

• Cardano Foundation, June 2026 development update / Yaci Analytics

Store coverage\ https://cardanofoundation.org/

• Yaci Store official site\

https://store.yaci.xyz/

• BloxBean / Yaci Store GitHub\

https://github.com/bloxbean/yaci-store

注記

• 3.0.0-beta4の個別変更点、MCPのdefault row limit・timeout・default

disabled等は、今回提示されたSIPO記事の記述を基礎として整理した。

• Cardano Foundationが2026年6月に公開したYaci Analytics

StoreのParquet/DuckDB分析方針と、governanceを含むデータexporterの存在は一次情報で確認できる。

• 将来のMasumi・x402・Midnightとの統合図は、現在完成済みの単一製品を示すものではなく、各技術の役割から構成したアーキテクチャ上の分析である。

作成日時：2026-09-28 22:47:11 JST