はじめに
Solanaで委任先のバリデータを選ぶとき、提示される年率（APR）や手数料率の低さだけでは決められません。前の記事がバリデータの役割を扱ったのに対し、この記事は「どう選ぶか」に絞ります。
表示されるAPRは、額面どおりには比べられません。含まれる収益源が違えば土台がずれますし、公称・一時点で表示されるAPRと、運用の結果として実際に得られる実現利回りは別物です。そこで見るべき基準を、報酬の分配・投票実績・運用品質の3系統に分け、最後に選定チェックリストへまとめます。
報酬の分配で見る
収益の源泉はインフレ報酬（新規発行分から受け取る基本報酬）・トランザクション手数料・MEV（取引の並び順から生じる追加収益）の3つですが、標準のプロトコルで委任者に自動配分されるのはインフレ報酬だけです。手数料はブロックを作ったバリデータに入り、そのままでは委任者へ渡りません。MEVは、Jitoの仕組みなどを通して委任者にも分配されます。
- commission（手数料率）：インフレ報酬からバリデータが取る割合。まず手数料率の分がバリデータに入り、残りがvote creditとステーク量に応じて委任者へ自動で配分されます。委任者に届く自動分配は、実質これだけです。率が低いほど取り分は増えますが、率だけで選ぶと運用品質を見落としがちです。
- base fee（基本手数料）：署名ごとに発生し、公式ドキュメントでは50%がburn（焼却）、50%がブロックを作ったバリデータです。委任者には渡りません。
- priority fee（優先手数料）：混雑時に処理を優先させる追加手数料で、現在は100%がバリデータに入ります（SIMD-0096）。標準のプロトコルには、これを委任者へ自動で分ける仕組みも設定もありません。委任者へ回すなら、バリデータ側の独自実装（自前の配布）が要ります。ブロック収益の分配を扱うSIMD-0123は2025年に承認され、Agave 4.1での実装が予定されていますが、まだ稼働していません。
- MEVチップ：Jitoの仕組みでは、tip（採用を促すチップ）からバリデータの取り分（MEV commission）とBlock Engineの利用料（Block Engine fee）を引いた残りが、tip distributionで委任者にも分配されます。ただし還元するかどうかと率は、事業者しだいです。
つまり委任者へ標準で自動配分されるのはインフレ報酬だけで、手数料やMEVは、Jitoの仕組みや事業者の独自実装を通してはじめて委任者に届きます。MEVの仕組み（bundle・Tip Distribution）はMEVの記事で扱います。
なお、MEV込みで示されるAPRは特に注意が必要です。平時は小さく市場イベントで大きく振れるため、短期のMEV実績を長期の安定収益として扱うべきではありません。
投票実績で見る
同じ源泉から誰がどれだけ受け取るかを分けるのが、投票実績です。バリデータは各ブロックに投票し、そのブロックがチェーンへ残ると、vote credit（投票が採用された実績点）を得ます。epoch（報酬計算の区切り、約2日）の終わりに、各バリデータのvote creditとステーク量をもとにインフレ報酬が配分されます。
vote creditは「稼働率」では測れません。プロセスが起動していても、投票が届かない、投票が遅れる、フォーク（チェーンの一時的な分岐）で不利な側に投票する、といった状態では落ちます。
Solanaは、Timely Vote Creditsという仕組みも導入しています。投票がどれだけ早く届いたかに応じて、得られるcreditが変わる設計です。
投票の遅れ（vote latency）が大きいほどcreditが減るため、レイテンシ（通信の遅延）や地理的配置、ネットワーク品質が報酬に直結する要素です。同じ手数料率でも、vote creditの取り方が違えば、委任者が受け取る報酬は変わります。
運用品質で見る
投票実績を支えるのが、日々の運用品質です。良い投票実績を日々の稼働で切らさないための観点を、次にまとめます。
- missed leader slot：リーダースロット（自分がブロックを生成する担当のスロット）で生成に失敗した回数。落とすと、そのスロットの手数料とMEVをまるごと逃します。
- identity account残高：投票はオンチェーンの取引で手数料がかかり、これを払うidentity accountの残高が尽きると投票が止まります。稼働していても投票できず、vote creditが積み上がらない見落としやすい要因です。
- restartの時間帯：Anza（Agaveの開発元）の運用指針では、再起動はリーダースロットを避けるよう勧められています。手順書に落とせば、担当者ごとの判断に左右されません。
- 復旧方針：障害時にlocal ledger（手元の台帳）を保てるほど、履歴とネットワーク健全性の面で有利です。復旧は、再起動→追いつき→snapshot（ある時点の状態の写し）の取得→クライアントのバージョン戻し→機材交換、と重さが段階的に上がります。
- 設置場所：速さ（vote latencyやMEV）と地理分散（災害・DDoS耐性）はトレードオフです。置いている国だけでなく、代替拠点や移設手順まで見ます。
- 監視体制：どの閾値で誰に通知し、いつ誰が対応するかまで決めているか。月次レポートやインシデント報告に要る証跡は、あとから作り直せません。
運用の指標を数字で追い、内訳をレポートで出せるバリデータほど、報酬を会計や監査の記録とも突き合わせられます。
バリデータの比較サイトの紹介
ここまでの基準を裏づけるのは、コミュニティなどが作成しているバリデータの比較サイトです。それぞれのサイトがどういった視点で指標化しており、どの要素を自身が重要視するかに留意する必要があります。
代表的なサイトを、下に並べます。数字は日々動くので、同一タイミングで確認することが望ましいでしょう。
| 比較サイト | 何が見られる・強み | 使いどころ |
|---|---|---|
| Solana Beach（solanabeach.io） | バリデータ一覧・ステーク量・手数料率に加え、スキップ率や投票の遅れ、halt line（集中しすぎを示す線） | 実績と集中度をまとめて見る |
| Rated（rated.network） | effectiveness（実際にどれだけ報酬機会を取れているか）、稼働率、報酬、MEVの流れ | 実績を数値で細かく比べる |
| Stakewiz | Wiz Score（複数の指標を1点にまとめた総合点） | 候補を手早く絞る |
| validators.app | 稼働・手数料率・スコアの一覧 | 別ソースで裏を取る |
これらは、どれもバリデータを「測る」サイトです。開いたら、手数料率やAPRの順位ではなく、実績の中身を見ます。次の点が軸です。
- 手数料率だけを見ない：率が低くても、運用品質が低ければ手取りは伸びません。
- 稼働率より、実効性（effectiveness）やvote credit（採用された投票の実績）：稼働率が高くとも、投票が遅れれば(実効性が下がれば)報酬は落ちます。
- APR順を鵜呑みにしない：表示APRは、計算対象・期間・MEVの取得状況等の直近の成績により評価が変わります。
- 集中度（ステーク量）も見る：大手に集めるほど、ネットワークの分散は弱まります。健全性を気にするなら、規模も判断材料にします。
測る以外に、「預け方」を変える選択肢もあります。1つのバリデータを選ぶ代わりに、ステークプールへ預けて多数へ分散委任してもらう形です。JPoolのようなプールは、引換トークンのJSOL（預けている間も使える）を渡します。この場合は、同じ3つの基準を、プール自体の運用に当てて見ます。
選ぶときのチェックリスト
選ぶ前に見る項目は、次のとおりです。
- 報酬の分配：手数料率と変更履歴／基本手数料・優先手数料やMEVを委任者へ回しているか（標準では回らないので、事業者の独自対応かJito経由か）とその実績／claim（受け取り）の方法と自動再委任の有無。
- 投票実績：vote credit／vote latency（投票の遅れ）／missed vote（取りこぼした投票）。
- 運用品質：missed leader slot／identity account残高と投票停止の履歴／catchup（追いつき）状況／監視・インシデント体制。
- 表示APRの読み方：公称か実現か、対象期間と計算対象は何か、内訳をレポートで示せるか。
これらを分けて見れば、APRや手数料率の一点比較から抜け出せます。ソフトウェアの違いはクライアントの記事、MEVの仕組みはMEVの記事で確認できます。