> ## Documentation Index
> Fetch the complete documentation index at: https://docs.raydium.io/llms.txt
> Use this file to discover all available pages before exploring further.

# 共有インフラストラクチャ

> Raydium の全プログラムが共有するプリミティブ — オーソリティ PDA、AmmConfig アカウント、プロトコル・ファンド・クリエイター手数料分割、オブザーベーション アカウント、公開 REST API サーフェス — を一度定義し、プロダクト別の章がこれを参照できるようにしたものです。

<Info>
  **このページは AI による自動翻訳です。すべての内容は英語版を正とします。**

  [英語版を表示 →](/protocol-overview/shared-infrastructure)
</Info>

<Info>
  Raydium のプロダクト プログラムは独立したコードベースですが、共有された規約セットに対して設計されています。このページは、その規約の正式なリファレンスです。プロダクト別の章では、規約がどのようにアカウントに*実装される*かを説明します。このページでは、規約そのものを説明します。
</Info>

## ここで「共有」が意味すること

コードベース全体を通じて、3 つのレベルの共有が存在します。

* **規約の共有。** すべてのプログラムは同じ PDA 導出パターン、同じ手数料分割形状、同じオブザーベーション アカウントのアイデアを使用します。ただし、各プログラムはそれぞれ独自のプログラムで、独自のシードを使用して実装します。
* **アカウント共有。** ごく少数のアカウントは、複数のプール間で*文字通り*同じレコード（CPMM のグローバル オーソリティ PDA、AmmConfig アカウント）です。
* **オフチェーン共有。** 1 つの REST API と 1 つの TypeScript SDK がすべての 4 つのプログラムの前面に立ちます。どのプログラムを呼び出すかに関わらず、統合者は 1 つの HTTP ホストと 1 つの NPM パッケージと対話します。

以下の 5 つのプリミティブが、プログラム境界を越えるすべてのものをカバーします。

## 1. オーソリティ PDA

すべての Raydium プログラムには、そのトークン ヴォルトを所有する PDA が正確に 1 つあります。ユーザーはヴォルト オーソリティを直接保有することはありません。オーソリティ PDA は、資金を引き出すことができる唯一の署名者であり、有効なプログラム命令が署名するよう指示したときのみ署名します。

パターンはプロダクト全体で同一です。シードは異なります。

| プログラム                 | オーソリティ PDA シード                          | 注記                                           |
| --------------------- | --------------------------------------- | -------------------------------------------- |
| **AMM v4**            | `[poolId]`                              | プール単位のオーソリティ。v4 のプール単位設計と同じ形状。               |
| **CPMM**              | `[b"vault_and_lp_mint_auth_seed"]`      | **すべての CPMM プール間で共有される単一 PDA。** プール固有のシードなし。 |
| **CLMM**              | `[b"pool_vault_and_lp_mint_auth_seed"]` | すべての CLMM プール間で共有される単一 PDA。                  |
| **Farm v3 / v5 / v6** | `[farmId]`                              | ファーム単位。PDA はそのファームのステーキング + リワード ヴォルトを所有します。 |
| **LaunchLab**         | `[b"vault_auth", launchId]`             | ローンチ単位。卒業前のベース + クォート ヴォルトを所有します。            |

これにより以下のことが生じます。

* CPMM と CLMM の場合、オーソリティ PDA は**グローバル アカウント**です。そのタイプのすべてのプールはそれを使用します。CPMM に CPI している場合、プールごとではなく 1 回必要です。
* プール単位 / ファーム単位のオーソリティの場合、プール/ファーム ID から PDA を導出します。SDK は `getPoolKeys` / `getFarmKeys` でこれを行います。直接統合する場合は、`findProgramAddressSync` で導出します。
* **ヴォルト所有権は変更できません。** トークン アカウントがオーソリティ PDA を所有者として作成されると、そのプログラムによって呼び出された PDA のみが転送できます。管理者オーバーライドはありません。

プログラムごとの正確なシードと ATA レイアウトについては、[`products/cpmm/accounts`](/ja/products/cpmm/accounts)、[`products/clmm/accounts`](/ja/products/clmm/accounts)、[`products/amm-v4/accounts`](/ja/products/amm-v4/accounts)、[`products/farm-staking/accounts`](/ja/products/farm-staking/accounts)、[`products/launchlab/accounts`](/ja/products/launchlab/accounts) を参照してください。

## 2. 管理アカウント設定アカウント

CPMM と CLMM は、**`AmmConfig`** と呼ばれる設定アカウント パターンを共有します。これは、小さなグローバル アカウントで、`u16` でインデックス付けされ、手数料率とそれがある全体*手数料ティア*に適用される管理先を保持します。プールは作成時に設定にバインドし、再バインドされません。

```rust theme={null}
// CPMM AmmConfig（省略形 — CLMM バージョンは構造的に似ています）
pub struct AmmConfig {
    pub bump: u8,
    pub disable_create_pool: bool,        // このティアでの新規プール作成をゲート
    pub index: u16,                       // ティア インデックス
    pub trade_fee_rate: u64,              // トレードの手数料に行く部分
    pub protocol_fee_rate: u64,           // トレード手数料のプロトコルへの部分
    pub fund_fee_rate: u64,               // トレード手数料のファンドへの部分
    pub create_pool_fee: u64,             // 1 回限りのプール作成手数料
    pub protocol_owner: Pubkey,           // CollectProtocolFee の署名者
    pub fund_owner: Pubkey,               // CollectFundFee の署名者
    pub padding: [u64; 16],
}
```

**ルール：**

* **手数料ティアはグローバルです。** プールが「これは 0.25% プールです」と言う場合、作成時に `trade_fee_rate` が 0.25% だった AmmConfig にバインドしていることを意味します。プール単位のレート オーバーライドはありません。
* **設定は変更できますが、プールは従いません。** 設定オーソリティが AmmConfig を編集すると、その設定にバインドされたすべての既存プールは新しいレートを即座に取得します。これはバグではなく機能です。プロトコル レベルの経済的な変更がプール単位のマイグレーションなしに伝播する方法です。
* **`disable_create_pool` は非推奨レバーです。** 手数料ティアが日没すると、プロトコル マルチシグはこのフラグを設定します — 既存プールは動作し続けますが、新しいプールはティアを選択できません。
* **`protocol_owner` / `fund_owner`** は手数料徴収呼び出しの*署名者*です。それらをマルチシグに設定することが、手数料引き出しをゲートしています。それらは手数料自体の宛先アドレスではなく、それは同じアカウント上の `protocol_fee_destination` / `fund_fee_destination` です。

AMM v4 には `AmmConfig` がありません。その手数料パラメータはプール単位で、作成時にハードコードされています。Farm と LaunchLab はそれぞれのチャプターでカバーされている独自の同等物（`FarmConfig`、`LaunchConfig`）を持っています。

誰が何を変更できるかの完全な表は [`security/admin-and-multisig`](/ja/security/admin-and-multisig) にあります。現在のユーザー向け手数料分割は [`ray/protocol-fees`](/ja/ray/protocol-fees) にあります。

## 3. プロトコル・ファンド・クリエイター手数料分割

すべての CPMM と CLMM スワップ手数料は、出ていく際に最大 4 つの宛先に分割されます。

```
                         total swap fee
                              │
              ┌───────────────┼───────────────┬──────────────┐
              ▼               ▼               ▼              ▼
        LP pool side     Protocol         Fund         Creator
        (raises k)       treasury         multisig     (LaunchLab pools)
```

機械的には：

1. **トレード手数料はプールに蓄積します。** 手数料はスワップの入力側から削除され、*手数料後*の金額が定積乗法に見えます。これが「LP が手数料を獲得する」という意味です。`k` が上昇し、暗黙の LP トークンの価値ごともそうです。
2. **プロトコル/ファンド/クリエイター部分がその LP 側の蓄積からプール単位のカウンター アカウントに控除されます。** それらはプール状態（`protocol_fees_token{0,1}`、`fund_fees_token{0,1}` など）に保持されます。誰かが `CollectProtocolFee` / `CollectFundFee` / `CollectCreatorFee` を呼び出すまで。それらはその時までプールのヴォルトを離れません。スワップの観点から見ると、それらはまだ「プール内」です。
3. **徴収はそれらを移動します。** 実行する署名者（AmmConfig 上の `protocol_owner` / `fund_owner` キー、または LaunchLab プール向けのローンチ クリエイター）は徴収命令を呼び出し、プログラムはプール ヴォルトから宛先 ATA に転送します。

いくつかの負荷を担う観察：

* **分割パーセンテージはトレード手数料の端数であって、トレードではありません。** 0.25% のトレード手数料と 12% のプロトコル シェアは、プロトコルがトレードの `0.25% × 12% = 0.03%` を取得することを意味します。トレードの 12% ではなく。
* **クリエイター手数料は LaunchLab 卒業プールにのみ存在します。** 標準 CPMM/CLMM プールには 3 方向分割（LP / プロトコル / ファンド）があります。LaunchLab は、誰がトークンをローンチしたかにルーティングされた 4 番目のスロットを追加します。これは `Initialize` で設定され、不変です。
* **AMM v4 は 2 方向のみ分割**し、プール単位でハードコードされます。ファンド スロットなし、クリエイター スロットなし。
* **ファンド対プロトコル** — 両者ともプロトコル財務宛先ですが、異なる署名者と異なる意図される用途があります。`protocol` は歴史的に操作に資金を提供します。`fund` はより長期的な財務です。2 つの間の分割それ自体が調整可能です。

特定のレートは [`reference/fee-comparison`](/ja/reference/fee-comparison) と [`ray/protocol-fees`](/ja/ray/protocol-fees) にあります。

## 4. オブザーベーション アカウント（TWAP リング バッファ）

CPMM と CLMM は両方とも、プール単位で**オブザーベーション アカウント**を維持します。これは、他のコントラクトが操作耐性のある TWAP を導出するために使用できる固定サイズの `(timestamp, cumulative_price)` サンプルのリング バッファです。

```rust theme={null}
// CPMM ObservationState（省略形）
pub struct ObservationState {
    pub initialized: bool,
    pub observation_index: u16,            // 次に上書きするスロット
    pub pool_id: Pubkey,
    pub observations: [Observation; OBSERVATION_NUM],
    pub padding: [u64; 4],
}

pub struct Observation {
    pub block_timestamp: u64,
    pub cumulative_token_0_price_x32: u128,  // 初期化以降の (price × dt) の合計
    pub cumulative_token_1_price_x32: u128,
}
```

仕組みは次のとおりです。

* **すべてのスワップが `update_observation` を呼び出します。** プログラムは現在の価格を読み、前のオブザーベーションからの経過秒数を乗算し、累積カウンターに追加します。新しいエントリは最も古いスロット（リング バッファ スタイル）を上書きします。
* **ウィンドウ上の TWAP** = `(cumul[end] − cumul[start]) / (timestamp[end] − timestamp[start])`。消費者は目的のウィンドウをブラケットする 2 つのオブザーベーションを選んで除算します。
* **Raydium 自体は TWAP を価格付けに使用しません。** AMM 数学は、スポット準備金を直接読みます。オブザーベーション外部性です。Raydium は、他のコントラクトが読めるようにそれらを書く費用を支払います。
* **AMM v4 はオブザーベーション アカウントを持ちません。** これは ObservationState デザインより古い。v4 TWAP を望む統合者は、ログ履歴からオフチェーンで計算する必要があります。

レイアウトの詳細とインデックス数学は [`products/cpmm/accounts`](/ja/products/cpmm/accounts) と [`products/clmm/accounts`](/ja/products/clmm/accounts) にあります。

## 5. REST API + SDK + IDL

オフチェーン サーフェスは、すべてのプロダクトで使用される単一のトリオです。

* **REST API** — `https://api-v3.raydium.io`。すべてのオンチェーン状態のほぼ読み取り専用のインデックス付きビューと引用エンジン。1 つのホスト、1 つのスキーマ。
* **TypeScript SDK** — NPM の `@raydium-io/raydium-sdk-v2`。すべてのプログラムのトランザクションを構築して署名します。見積もり/メタデータ用に API と通信し、署名前の状態更新用に Solana RPC と通信します。
* **IDL レジストリ** — 公開されたすべてのプログラムの Anchor IDL は [`raydium-idl`](https://github.com/raydium-io/raydium-idl) リポジトリに存在します（プログラムごとに 1 つの JSON：CPMM、CLMM、LaunchLab）。TypeScript SDK はこれらの IDL を内部的に消費します。ダウンストリーム Rust / Python クライアントは同じファイルから再生成します。

それぞれの間の境界は明確です。

| 部分       | 読み込み元              | 書き込み先                   | 古さの許容範囲                 |
| -------- | ------------------ | ----------------------- | ----------------------- |
| REST API | インデクサー（チェーン ログを解析） | — （統合者向けの読み取り専用）        | 数秒                      |
| SDK      | API + RPC          | トランザクションを構築。ブロードキャストしない | なし — 署名前に状態を再取得する必要がある  |
| IDL      | プログラム ソース          | —                       | プログラム アップグレードごとにバージョン管理 |

よくある間違いは、REST API 出力をトランザクションに直接与えることです。しないでください。署名しているスロットで Solana RPC から関連するプール/ポジション状態を再取得してください。SDK はファースト パーティのフローに対してこれを自動的に行います。SDK をバイパスする場合は、自分で行う必要があります。

完全なリファレンスは [`sdk-api/`](/ja/sdk-api) にあり、IDL サーフェスは特に [`sdk-api/anchor-idl`](/ja/sdk-api/anchor-idl) にあります。

## 6. インデクサーと価格フィード

REST API は Raydium 独自のインデクサーによって給されます。インデクサーは Solana RPC の fleet からプログラム ログにサブスクライブし、非正規化されたレコードを SQL ストアに書き込みます。統合者に対する 2 つの結果：

* **インデクサーは「クロスプログラム状態を知っている」唯一のもの。** CPMM プールを CLMM の対応にマッピングすること、プログラム バージョン全体で 24 時間ボリューム番号を計算すること、LP ミントに関連付けられたファームを取得することなど、それはすべてインデクサー作業です。プログラム自体はそれを行いません。
* **インデクサーのダウンタイムは API のダウンタイム。** API がスタイルまたは空のデータを返す場合、インデクサーが容疑者です。オンチェーン状態は影響を受けません。独自の RPC と SDK を持つ統合者は、トランザクションを続行できます。

価格フィードは別の懸念事項です。API はほとんどのプール応答で `priceUsd` フィールドを公開します。これはインデクサーのプール準備金の見方のスナップショットと引用リファレンス価格（共通の基軸として USDC プール）からオフチェーンで計算されます。UI には十分です。オンチェーン オラクルとして使用するのは安全ではありません。そのためにオブザーベーション TWAP を使用してください。

## 共有されていないこと

新しい読者は多くの場合、存在するより多くの共有を仮定するため、明示的にリストアップする価値があります。

* **プログラムは相互に呼び出しません。** CPMM スワップは決して CLMM または AMM v4 に CPI しません。複数の AMM を構成する唯一のプログラムは、AMM ルーティング プログラムです。それ自体も細いもので、単に各 AMM に順番に CPI を発行します。
* **プログラム間での共有アップグレード オーソリティなし。** オンチェーン プログラムごとに、独自のプログラム アップグレード キー（3/4 マルチシグと 24 時間タイムロック）があります。それらはリンクされていません。
* **ファームと AMM 間での共有状態なし。** ファームは、それがステークするどの LP が CPMM プール、CLMM ポジション NFT ミント、または無関係の SPL トークンのどれであるかを知りません。ファーム プログラムはステーキング ミントを不透明として扱います。
* **オラクル依存なし。** 価格はオンチェーン準備金。Pyth/Switchboard フォールバックはありません。AMM はクリアする前にオラクルをチェックしません。

## ポインタ

* [`protocol-overview/architecture`](/ja/protocol-overview/architecture) — これらのピースがどのように構成されるかを示す正式なダイアグラム。
* [`protocol-overview/versions-and-migration`](/ja/protocol-overview/versions-and-migration) — 規約がプログラム バージョン全体でどのように進化したか。
* [`security/admin-and-multisig`](/ja/security/admin-and-multisig) — AmmConfigs の背後にあるキーを制御する人。
* [`reference/fee-comparison`](/ja/reference/fee-comparison) — プロダクトごとの手数料レート マトリックス。
* [`reference/program-addresses`](/ja/reference/program-addresses) — 正式なプログラム ID。

ソース：

* [Raydium SDK v2](https://github.com/raydium-io/raydium-sdk-V2) — PDA シード、アカウント レイアウト、IDL 定義の情報源。
* [Raydium IDL レジストリ](https://github.com/raydium-io/raydium-idl) — Anchor IDL。
* 上記でインラインで引用されたプロダクト単位のアカウント ページ。