カスタムプログラムからの CPI

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

sdk-api/rust-cpi では、各 Raydium プログラムを呼び出すための低レベルの仕組みについて説明しています。このページはその上位レベルの補足です。Raydium をカスタムプログラムに組み込む理由、ユースケースに適した パターン、そして端から端までの完全な実装方法について説明します。

CPI が適切なツールである場合

カスタムプログラムは、トレードがあなたのプログラムのみが実行できる他のオンチェーン状態変更と原子的に発生する必要がある場合に有効です。一般的なケースは以下の通りです。

エスクロー・リミットオーダープログラム — ユーザーがミントをエスクロー内に預け、プログラムが価格条件を監視し、トリガーされたときにプログラムが原子的に Raydium を通じてスワップし、ユーザーのアカウントにクレジットします。
アグリゲータープロキシ — Raydium と 1 つ以上の他の DEX を通じてスワップをルーティングする単一の命令で、すべてのホップがプログラムが所有する単一のスリッページチェック下にあります。
自動複利運用ヴォルト — LP またはファームステークをヴォルトに預け、ヴォルトがスケジュールに従ってリワードを収穫し、流動性を再供給し、シェアトークンを発行します。
ストラテジーヴォルト — CLMM を通じてスワップして再バランスするレバレッジ LP ポジション、ポジションをクローズして 1 つのトランザクションで担保をスワップするリクイデーター。
カスタムベスティング付きトークン起動プラットフォーム — プログラムがベスティングトークンを保有し、スケジュールに従って Raydium プールにリリースします。

オフチェーンコードからスワップを送信したいだけの場合、CPI は過剰です — SDK を使用してください。CPI が複雑さに見合う価値があるのは、独自の状態との原子性が要件である場合のみです。

構成パターン

パターン 1: シンプロキシ

プログラムは単一の命令を公開し、いくつかのポリシー（例：ホワイトリストに登録されたミントペア、検証済みユーザーの手数料割引）を検証してから Raydium に転送します。

┌──────────────┐   user tx    ┌────────────────┐  CPI  ┌──────────┐
│ user         │─────────────▶│ your program   │──────▶│ Raydium  │
└──────────────┘              │  (validate)    │       │  (CPMM)  │
                              └────────────────┘       └──────────┘

状態はユーザーの ATA に存在します。プログラムはトークンを所有しません。最小限の信頼フットプリント。

パターン 2: エスクロー

プログラムはユーザーの入力ミントを保有する PDA を所有しています。トリガー時に、PDA は Raydium へのスワップの CPI に署名します。

           deposit                   trigger
   user ───────────▶  PDA vault  ───────────────▶  Raydium swap
                     (your prog)                    (signed by PDA)
                                                            │
                                                            ▼
                                                    PDA vault (output mint)
                                                            │
                                                     withdraw ▼
                                                         user

重要な詳細：PDA は CpiContext::new_with_signer を通じて署名します。PDA 署名者シードを参照してください。

パターン 3: 構成マルチホップ

プログラムは 1 つの命令で複数の CPI を発行し、すべてのホップ全体で単一のスリッページ境界を強制します。Raydium スワップ命令はそれぞれ独自の minimum_amount_out を持ちますが、それらを 0（または非常に緩い下限）に設定し、最後のホップの後に厳密な最終最小値を自分で強制します。

instruction:
  CPI swap: tokenA → tokenB   (raydium, loose min)
  CPI swap: tokenB → tokenC   (raydium / third-party, loose min)
  CPI swap: tokenC → tokenD   (raydium, loose min)
  require(user.tokenD_ata.amount - pre_balance >= user_min_out)

これにより、ルート全体に対して単一のリバートゲートが得られます。すべてのホップがスリッページセーフであると信頼する場合にのみこのパターンを使用してください。そうでない場合は、各ホップに独自の最小値を強制させてください。

パターン 4: ヴォルト・ストラテジー

プログラムは PDA に LP トークンまたはファームステークを保有しています。キーパー（またはユーザー）が compound() を呼び出すと、以下が実行されます。

ファームからリワードを収穫します。
リワードをプールトークンにスワップします（CPMM または CLMM への CPI）。
収益を LP に戻します（別の CPI）。
新しい LP をステークします（別の CPI）。

すべて 1 つのトランザクションで実行されるため、ヴォルトの NAV は原子的に移動します。コンピュート予算は通常 600k～1M CU です。アドレスルックアップテーブルは必須です。

アカウントリスト構築

呼び出し元プログラムの Accounts 構造体は Raydium プログラムのアカウント順序を反映しますが、ほとんどの Raydium 側のアカウントは UncheckedAccount です。Raydium がそれ自体で検証するためです。あなたが所有するアカウントにのみ制約を追加します。

use anchor_lang::prelude::*;
use anchor_spl::token::{Token, TokenAccount};

#[derive(Accounts)]
pub struct EscrowSwap<'info> {
    /// The escrow PDA; holds input mint and signs the CPI.
    #[account(
        mut,
        seeds = [b"escrow", user.key().as_ref()],
        bump = escrow.bump,
    )]
    pub escrow: Account<'info, Escrow>,

    #[account(mut)]
    pub user: Signer<'info>,

    // ----- Raydium-side accounts, mostly unchecked -----

    /// CHECK: validated by CPMM
    #[account(mut)] pub pool_state: UncheckedAccount<'info>,
    /// CHECK: validated by CPMM
    pub amm_config: UncheckedAccount<'info>,
    /// CHECK: validated by CPMM
    pub pool_authority: UncheckedAccount<'info>,
    #[account(mut)] pub input_vault:  Account<'info, TokenAccount>,
    #[account(mut)] pub output_vault: Account<'info, TokenAccount>,
    /// CHECK: validated by CPMM
    #[account(mut)] pub observation_state: UncheckedAccount<'info>,

    /// Escrow's input ATA — owned by the escrow PDA.
    #[account(
        mut,
        associated_token::mint = input_mint,
        associated_token::authority = escrow,
    )]
    pub escrow_input_ata: Account<'info, TokenAccount>,

    /// Escrow's output ATA.
    #[account(
        mut,
        associated_token::mint = output_mint,
        associated_token::authority = escrow,
    )]
    pub escrow_output_ata: Account<'info, TokenAccount>,

    pub input_mint:  Account<'info, anchor_spl::token::Mint>,
    pub output_mint: Account<'info, anchor_spl::token::Mint>,

    pub cpmm_program:       Program<'info, raydium_cp_swap::program::RaydiumCpSwap>,
    pub token_program:      Program<'info, Token>,
    pub token_program_2022: Program<'info, anchor_spl::token_2022::Token2022>,
}

非対称性 — あなたのアカウントに対する厳密な検証、Raydium のアカウントに対する UncheckedAccount — は怠惰ではありません。受信者は独自に検証します。呼び出し元で二重検証するだけで CU が消費され、Raydium が新しい構造体レイアウトフィールドを出荷するときに同期がずれるリスクがあります。

CPI 呼び出し自体

use raydium_cp_swap::cpi::{self, accounts::Swap as CpmmSwap};

pub fn escrow_swap(
    ctx: Context<EscrowSwap>,
    amount_in: u64,
    minimum_amount_out: u64,
) -> Result<()> {
    let user_key = ctx.accounts.user.key();
    let bump     = ctx.accounts.escrow.bump;
    let seeds: &[&[u8]] = &[b"escrow", user_key.as_ref(), &[bump]];
    let signer: &[&[&[u8]]] = &[seeds];

    let cpi_accounts = CpmmSwap {
        // `payer` is the account whose signature must cover the input ATA. That ATA is
        // owned by the escrow PDA, so the escrow — signing via new_with_signer below —
        // goes here, NOT `user`.
        payer:                ctx.accounts.escrow.to_account_info(),
        // `authority` is CPMM's own vault PDA at [b"vault_and_lp_mint_auth_seed"];
        // CPMM signs the vault leg with it itself. Passing your escrow here fails the
        // seeds constraint before any transfer runs.
        authority:            ctx.accounts.pool_authority.to_account_info(),
        amm_config:           ctx.accounts.amm_config.to_account_info(),
        pool_state:           ctx.accounts.pool_state.to_account_info(),
        input_token_account:  ctx.accounts.escrow_input_ata.to_account_info(),
        output_token_account: ctx.accounts.escrow_output_ata.to_account_info(),
        input_vault:          ctx.accounts.input_vault.to_account_info(),
        output_vault:         ctx.accounts.output_vault.to_account_info(),
        input_token_program:  ctx.accounts.token_program.to_account_info(),
        output_token_program: ctx.accounts.token_program.to_account_info(),
        input_token_mint:     ctx.accounts.input_mint.to_account_info(),
        output_token_mint:    ctx.accounts.output_mint.to_account_info(),
        observation_state:    ctx.accounts.observation_state.to_account_info(),
    };

    // Anchor 1.0 takes the program's Pubkey here, not its AccountInfo.
    let cpi_ctx = CpiContext::new_with_signer(
        *ctx.accounts.cpmm_program.key,
        cpi_accounts,
        signer,
    );

    cpi::swap_base_input(cpi_ctx, amount_in, minimum_amount_out)?;
    Ok(())
}

PDA 署名者シード

CPI は、authority として渡された PDA が呼び出し元が主張する導出と一致する場合にのみ成功します。2 つは以下に同意する必要があります。

シードバイトシーケンス（ここでは [b"escrow", user.key().as_ref()]）。
バンプ。
呼び出し元プログラム ID（Raydium ではなく、あなたのプログラム）。

PDA が何と一致しなければならないかに注意してください。CPMM の authority スロットは CPMM 自身の ボルト PDA です — プログラム全体で固定されたアカウントで、CPMM がそれを導出し自ら署名します。あなたのプログラムはこれを制御も差し替えもできません。あなたの PDA シードが一致しなければならないアカウントは payer です：チェックは CPMM 自身の transfer_from_user_to_pool_vault ヘルパー内で行われ、payer として渡されたアカウントが input_token_account の所有者であることを要求します。一般的なバグ：escrow_input_ata がエスクロー PDA によって所有されているのに、user を payer として渡すことです。SPL Token プログラムは owner mismatch で拒否します。常に payer を ATA の所有者にしてください — そしてその所有者が PDA の場合は new_with_signer で署名してください。

残りのアカウント

いくつかの Raydium 命令は、固定されたアカウントの後に追加された可変長のアカウントリストを取ります — 残りのアカウント。

CLMM SwapV2: スワップが走査する可能性のあるティック配列の 1～8 個の TickArrayState アカウント（スワップ方向）。
Farm v6 Deposit / Harvest / Withdraw: (reward_vault, user_reward_ata) ペア、ライブリワードスロットごとに 1 ペア。
Token-2022 転送フックミント: 転送フックプログラムと、フックが必要とするアカウント。

Anchor CPI ヘルパーは残りのアカウントを型チェックしません。それらを通す：

let cpi_ctx = CpiContext::new_with_signer(program_id, accounts, signer)
    .with_remaining_accounts(ctx.remaining_accounts.to_vec());

順序が重要です。 CLMM の場合：

remaining = [
    tick_array_in_direction_0,    // first one crossed
    tick_array_in_direction_1,
    ...,
]

Farm v6 ハーベストの場合：

remaining = [
    reward_vault_0, user_reward_ata_0,
    reward_vault_1, user_reward_ata_1,
    // omit any slot whose reward_state is Uninitialized
]

呼び出し元プログラムは、クライアントから受け取った残りのアカウントを変更されずに通す必要があります。フィルタリングまたは並べ替えを試みないでください。

構成呼び出しのコンピュート予算

CPI は呼び出しフレーム自体に約 1,500 CU のコストがかかります。被呼び出し側の独自の CU 使用量がその上に積み重なります。以下の被呼び出し側の数値は、2026-09-09 に高ボリュームのプールで実行されたライブのメインネットトランザクションから、Raydium プログラム自身の呼び出しに対する Program <id> consumed N of M compute units ログ行を読み取って測定したものです（したがって内部のトークンプログラム CPI も含まれます）：

呼び出される命令	測定 CU	サンプル
CPMM `swap_base_input`	~23,000	22,721–23,052 (n=8)
AMM v4 swap	~26,000	25,215–26,002
CLMM `swap`（V1）	~41,000	37,148–44,721
CLMM `swap_v2`	~48,000	43,838–52,887 (n=6)
CLMM `increase_liquidity_v2`	~36,000	36,058

各 CPI フレームにつき約 1,500 と、あなた自身のプログラムのオーバーヘッドをその上に追加してください。CLMM のスワップコストはティック交差の回数に応じて増えるため、その数値は下限として扱ってください。Token-2022 ミントは転送自体の拡張機能処理コストを追加します。一律の乗数を当てるのではなく、自分のミントで測定してください。

このページの以前の版には 5～7 倍高い見積もり（CPMM スワップ約 150,000 CU、CLMM 約 180,000）が記載されていました。それらは一度も測定されたものではありません。ドキュメント化された数値ではなく、自分自身の computeUnitsConsumed の読み取り値から予算を組んでください — また、ATA 作成、wSOL のラッピング、compute-budget 命令を数えると、トランザクション全体は Raydium 命令単体よりも高くつくことに注意してください。

常に明示的な ComputeBudgetProgram::set_compute_unit_limit を設定してください。

import { ComputeBudgetProgram } from "@solana/web3.js";

const tx = new Transaction().add(
  ComputeBudgetProgram.setComputeUnitLimit({ units: 900_000 }),
  ComputeBudgetProgram.setComputeUnitPrice({ microLamports: priorityFeeMicroLamports }),
  yourInstruction,
);

デフォルトの 200k CU 上限は、構成呼び出しが完了する前に静かに枯渇します。

エラー伝播

Raydium のプログラムは安定したエラーコードを持つ Anchor エラーを返します。呼び出し元プログラムはそれらを Err(ProgramError::Custom(code)) として見ます。デフォルトでバブルアップします。

cpi::swap_base_input(cpi_ctx, amount_in, minimum_amount_out)?;

または特定のコードをインターセプトします。

use anchor_lang::error::{Error, ERROR_CODE_OFFSET};
use raydium_cp_swap::error::ErrorCode as CpmmErr;

match cpi::swap_base_input(cpi_ctx, amount_in, minimum_amount_out) {
    Ok(_) => {}
    Err(Error::ProgramError(pe))
        if pe.program_error
            == ProgramError::Custom(CpmmErr::ExceededSlippage as u32 + ERROR_CODE_OFFSET) =>
    {
        // Your program might want to retry at a larger slippage, or unwind state.
        return err!(YourErr::PoolTooVolatile);
    }
    Err(err) => return Err(err),
}

ERROR_CODE_OFFSET という項に注意してください：#[error_code] のバリアントは 6000 から始まる番号で発行されるため、素の enum 判別子と比較しても一致することはありません。（anchor-lang にも raydium_cp_swap にも is_err ヘルパーは存在しません — このページの以前のリビジョンでは、存在しないヘルパーを使用していました。）エラーコードから意味へのマッピングは IDL ポリシーごとに安定しています（sdk-api/anchor-idlを参照）。新しいコードは最後に追加され、既存のコードの意味は変わりません。

完全な実装例：リミットオーダーエスクロー

フロー：

open_order — ユーザーが input_mint の amount_in をエスクロー PDA に預け、ターゲット min_amount_out と有効期限を記録します。
execute_order — 誰でも（キーパー）現在のプールアカウントで呼び出すことができます。プログラムは現在の見積もりが min_amount_out 以上であることを確認してから、Raydium スワップに CPI し、出力をエスクロー内に保持します。
claim — ユーザーはエスクロー内から出力ミントを引き出します。

#[account]
pub struct LimitOrder {
    pub user:          Pubkey,
    pub input_mint:    Pubkey,
    pub output_mint:   Pubkey,
    pub amount_in:     u64,
    pub min_out:       u64,
    pub expiry_unix:   i64,
    pub state:         u8,    // 0 open, 1 filled, 2 cancelled, 3 expired
    pub bump:          u8,
}

#[program]
pub mod limit_orders {
    use super::*;

    pub fn execute_order(
        ctx: Context<ExecuteOrder>,
    ) -> Result<()> {
        let order = &ctx.accounts.order;
        require!(order.state == 0, OrderErr::NotOpen);
        require!(Clock::get()?.unix_timestamp < order.expiry_unix, OrderErr::Expired);

        let user_key = order.user;
        let seeds: &[&[u8]] = &[b"order", user_key.as_ref(), &[order.bump]];
        let signer: &[&[&[u8]]] = &[seeds];

        let pre_out_balance = ctx.accounts.escrow_output_ata.amount;

        let cpi_accounts = CpmmSwap {
            // The escrow's input ATA is owned by the `order` PDA, so `order` must be
            // `payer` — it signs via new_with_signer below. The keeper only pays the
            // transaction fee; it is not the ATA owner.
            payer:                ctx.accounts.order.to_account_info(),
            // CPMM's own vault PDA at [b"vault_and_lp_mint_auth_seed"].
            authority:            ctx.accounts.pool_authority.to_account_info(),
            amm_config:           ctx.accounts.amm_config.to_account_info(),
            pool_state:           ctx.accounts.pool_state.to_account_info(),
            input_token_account:  ctx.accounts.escrow_input_ata.to_account_info(),
            output_token_account: ctx.accounts.escrow_output_ata.to_account_info(),
            input_vault:          ctx.accounts.input_vault.to_account_info(),
            output_vault:         ctx.accounts.output_vault.to_account_info(),
            input_token_program:  ctx.accounts.token_program.to_account_info(),
            output_token_program: ctx.accounts.token_program.to_account_info(),
            input_token_mint:     ctx.accounts.input_mint.to_account_info(),
            output_token_mint:    ctx.accounts.output_mint.to_account_info(),
            observation_state:    ctx.accounts.observation_state.to_account_info(),
        };

        let cpi_ctx = CpiContext::new_with_signer(
            *ctx.accounts.cpmm_program.key,
            cpi_accounts,
            signer,
        );

        // Let the escrow enforce the minimum — we trust Raydium's slippage, but we
        // also re-check our own post-swap delta in case a future change ever relaxes it.
        cpi::swap_base_input(cpi_ctx, order.amount_in, order.min_out)?;

        ctx.accounts.escrow_output_ata.reload()?;
        let delta = ctx.accounts.escrow_output_ata.amount
            .checked_sub(pre_out_balance)
            .ok_or(error!(OrderErr::AccountingError))?;
        require!(delta >= order.min_out, OrderErr::InsufficientOutput);

        let order = &mut ctx.accounts.order;
        order.state = 1;
        Ok(())
    }
}

キーパーはトランザクション手数料を支払います（他の場所でキーパー手数料を取得します — 表示されていません）。order PDA はエスクローの入力 ATA を所有しているため、payer として CPI に署名します。したがって ExecuteOrder には、CPMM 自身のボルト PDA 用に pool_authority: UncheckedAccount<'info> フィールドも必要です。Raydium 側のスリッページチェックとエスクロー独自のデルタチェックの両方が下限を強制します — 二重チェック。

テスト

Raydium プログラムをローカルバリデーターにプルして統合テストを実行します（Anchor.toml から）。

[test.validator]
clone = [
  { address = "CPMMoo8L3F4NbTegBCKVNunggL7H1ZpdTHKxQB5qKP1C" }, # CPMM
  { address = "CAMMCzo5YL8w4VFF8KVHrK22GGUsp5VTaW7grrKgrWqK" }, # CLMM
  { address = "675kPX9MHTjS2zt1qfr1NYHuzeLXfQM9H24wFSUt1Mp8" }, # AMM v4
  { address = "FarmqiPv5eAj3j1GMdMCMUGXqPUvmquZtMy86QH6rzhG" }, # Farm v6
]

プール状態アカウントもクローンして、テストが実際にスワップを実行できるようにします。anchor test はスタートアップ時にメインネットからそれらをフェッチします。sdk-api/rust-cpi を参照してください。

構成に固有の落とし穴

リエントランシー

Solana には真のリエントランシーはありません — CPI は同じ呼び出しで元のプログラムに呼び戻すことはできません。しかし、論理的なリエントランシーに自分自身を構築することはできます。CPI があなたの状態を読み、その後あなたのコードが CPI がそれを変更しなかったと仮定して再度読みます。Raydium の場合、CPI はあなたの状態に触れないため、これはフラッシュローンコンテキストなどほど懸念事項ではありません。しかし、Raydium をレンディングプロトコルと構成する場合は注意してください。

アカウント可変性ドリフト

プログラムがアカウントを mut として渡すが、Raydium がそれを読み取り専用として期待する場合（またはその逆）、ランタイムは InvalidAccountData で呼び出しを拒否します。常に IDL で Raydium の命令の予期される可変性を確認してください。raydium_cp_swap::cpi::accounts::Swap は、CPMM 自身の Swap 構造体に付いた #[account(mut)] マーカーから、各アカウントの可変性を代わりに設定します — 生成されるフィールドはすべて素の AccountInfo<'info> なので、フラグを運ぶのはフィールド型ではなく、導出された ToAccountMetas の実装です。

Token-2022 プログラムフィールド

入力ミントと出力ミントは異なるトークンプログラムの下にある可能性があります — 1 つは SPL Token、1 つは Token-2022。CPI にはこの理由のために個別の input_token_program と output_token_program フィールドがあります。常に各ミントの owner フィールドを確認し、正しいプログラムを各スロットにルーティングしてください。

バージョン管理されたトランザクション

2 つ以上の Raydium CPI と ATA 作成を実行する構成トランザクションは、レガシー（LUT なしの v0）トランザクションに収まることはめったにありません。V0 とアドレスルックアップテーブルを使用してください。raydium.getRaydiumLutAddresses() を通じて Raydium のパブリック LUT をプルしてください。

ポインター

sdk-api/rust-cpi — 低レベルの CPI 仕組み。
integration-guides/priority-fee-tuning — コンピュート予算のサイジング。
products/cpmm/code-demos、products/clmm/code-demos、products/farm-staking/code-demos — 製品ごとの CPI スニペット。

ソース：

Solana の基礎

クイックスタート

SDK と API

統合ガイド

カスタムプログラムからの CPI

CPI が適切なツールである場合

構成パターン

パターン 1: シンプロキシ

パターン 2: エスクロー

パターン 3: 構成マルチホップ

パターン 4: ヴォルト・ストラテジー

アカウントリスト構築

CPI 呼び出し自体

PDA 署名者シード

残りのアカウント

構成呼び出しのコンピュート予算

エラー伝播

完全な実装例：リミットオーダーエスクロー

テスト

構成に固有の落とし穴

リエントランシー

アカウント可変性ドリフト

Token-2022 プログラムフィールド

バージョン管理されたトランザクション

ポインター

​CPI が適切なツールである場合

​構成パターン

​パターン 1: シン プロキシ

​パターン 2: エスクロー

​パターン 3: 構成マルチホップ

​パターン 4: ヴォルト・ストラテジー

​アカウント リスト構築

​CPI 呼び出し自体

​PDA 署名者シード

​残りのアカウント

​構成呼び出しのコンピュート予算

​エラー伝播

​完全な実装例：リミットオーダー エスクロー

​テスト

​構成に固有の落とし穴

​リエントランシー

​アカウント可変性ドリフト

​Token-2022 プログラム フィールド

​バージョン管理されたトランザクション

​ポインター

CPI が適切なツールである場合

構成パターン

パターン 1: シンプロキシ

パターン 2: エスクロー

パターン 3: 構成マルチホップ

パターン 4: ヴォルト・ストラテジー

アカウントリスト構築

CPI 呼び出し自体

PDA 署名者シード

残りのアカウント

構成呼び出しのコンピュート予算

エラー伝播

完全な実装例：リミットオーダーエスクロー

テスト

構成に固有の落とし穴

リエントランシー

アカウント可変性ドリフト

Token-2022 プログラムフィールド

バージョン管理されたトランザクション

ポインター