なぜAnchor ― ボイラープレートを消す

導入

第4〜6章で書いたネイティブプログラムを思い出してください。命令の種類を自分で判定し、アカウントの数と順序を自分でチェックし、署名者かどうか・所有者が正しいプログラムかを毎回 if 文で確認する――これらはどの命令でもほぼ同じパターンの繰り返しでした。Anchor は、この「毎回同じ」部分をマクロと制約に置き換え、開発者が「このプログラム固有のロジック」だけに集中できるようにするフレームワークです。

説明

Anchorは Rust の**手続きマクロ（procedural macro）**を活用して、次のような定型作業を自動生成します。

• 命令データのシリアライズ/デシリアライズ（Borsh形式への変換）
• アカウントの署名者チェック・所有者チェック・PDA検証
• エラー型の定義とエラーコードの返却
• クライアント向けのインターフェース定義（IDL、レッスン28で扱います）

graph TB
    subgraph native["ネイティブ開発（第4〜6章）"]
        N1[命令データを自分でparse] --> N2[アカウント数・順序を確認]
        N2 --> N3[署名者かself.checkで確認]
        N3 --> N4[所有者プログラムをif文で確認]
        N4 --> N5[ようやく本題のロジック]
    end
    subgraph anchor["Anchorを使う開発（第7章〜）"]
        A1["#[derive(Accounts)]<br/>で制約を宣言"] --> A2[Anchorが自動で検証]
        A2 --> A3[本題のロジックだけ書く]
    end

Anchorのプロジェクトは anchor init で作られ、次のような構成になります。

my-project/
├── Anchor.toml        # クラスタ設定（localnet/devnet等）・プログラムID
├── programs/
│   └── my-project/
│       └── src/
│           └── lib.rs # プログラム本体（この章のコード）
└── tests/
    └── my-project.ts  # TypeScriptのテスト（第9章）

開発の基本コマンドは3つだけです。

「ネイティブで仕組みを理解してからAnchorで楽をする」――このコースがあえて素のプログラムから始めた理由がここにあります。制約が何を検証しているか知っているからこそ、Anchorのマクロがブラックボックスに見えません。

演習

もし #[derive(Accounts)] のような仕組みがなかったら、第4〜6章で書いた「署名者チェック」「所有者チェック」「PDA検証」を、あなたが今書いているプログラムの命令が増えるたびに何回書き直すことになるか考えてみましょう。