---
title: "クライアント・ダイバーシティ"
description: "イーサリアムのクライアント・ダイバーシティの重要性に関するハイレベルな説明。"
lang: ja
sidebarDepth: 2
---

[イーサリアム](/)ノードの動作は、実行しているクライアントソフトウェアによって制御されます。本番環境レベルのイーサリアムクライアントは複数存在し、それぞれ異なるチームによって異なる言語で開発および保守されています。クライアントは共通の仕様に基づいて構築されており、クライアント同士がシームレスに通信し、同じ機能を持ち、同等のユーザー体験を提供することが保証されています。しかし、現時点ではノード間でのクライアントの分布が十分に均等ではないため、このネットワーク強化の可能性を最大限に引き出すことができていません。理想的には、ユーザーがさまざまなクライアントにほぼ均等に分散し、ネットワークに可能な限り最大のクライアント・ダイバーシティをもたらすことです。

## 前提知識 {#prerequisites}

ノードとクライアントについてまだ理解していない場合は、[ノードとクライアント](/developers/docs/nodes-and-clients/)を確認してください。[実行レイヤー](/glossary/#execution-layer)と[コンセンサス・レイヤー](/glossary/#consensus-layer)については、用語集で定義されています。

## なぜ複数のクライアントが存在するのか？ {#why-multiple-clients}

独立して開発および保守される複数のクライアントが存在するのは、クライアント・ダイバーシティによってネットワークが攻撃やバグに対してより強靭になるためです。複数のクライアントが存在することは、イーサリアム独自の強みです。他のブロックチェーンは、単一のクライアントの無謬性に依存しています。しかし、単に複数のクライアントが利用可能であるだけでは不十分であり、それらがコミュニティに採用され、アクティブなノード全体がそれらの間で比較的均等に分散されている必要があります。

## クライアント・ダイバーシティはなぜ重要なのか？ {#client-diversity-importance}

独立して開発および保守される多くのクライアントを持つことは、分散型ネットワークの健全性にとって不可欠です。その理由を探ってみましょう。

### バグ {#bugs}

個々のクライアントのバグは、それがイーサリアムノードの少数派である場合、ネットワークに対するリスクは小さくなります。多くのクライアント間でノードがほぼ均等に分散していれば、ほとんどのクライアントが共通の問題に苦しむ可能性は低くなり、結果としてネットワークはより堅牢になります。

### 攻撃に対する耐性 {#resilience}

クライアント・ダイバーシティは、攻撃に対する耐性も提供します。例えば、[特定のクライアントを騙して](https://twitter.com/vdWijden/status/1437712249926393858)チェーンの特定のブランチに誘導する攻撃は、他のクライアントが同じように悪用される可能性が低く、正規のチェーンが破損しないため、成功する可能性は低いです。クライアント・ダイバーシティが低いと、支配的なクライアントへのハッキングに関連するリスクが高まります。クライアント・ダイバーシティは、ネットワークに対する悪意のある攻撃に対する重要な防御策であることがすでに証明されています。例えば、2016年のシャンハイでのサービス拒否攻撃は、攻撃者が支配的なクライアント（ゲス）を騙して、ブロックごとに数万回の遅いディスクI/O操作を実行させることができたために可能になりました。脆弱性を共有しない代替クライアントもオンラインであったため、イーサリアムは攻撃に耐え、ゲスの脆弱性が修正される間も稼働し続けることができました。

### プルーフ・オブ・ステークのファイナリティ {#finality}

イーサリアムノードの33%以上を占めるコンセンサス・クライアントにバグがあると、コンセンサス・レイヤーのファイナリティが妨げられる可能性があります。これは、ユーザーがトランザクションが後で元に戻されたり変更されたりしないと信頼できなくなることを意味します。これは、イーサリアム上に構築された多くのアプリ、特に分散型金融 (DeFi) にとって非常に問題となります。

<Emoji text="🚨" className="me-4" /> さらに悪いことに、3分の2の多数派を占めるクライアントに致命的なバグがあると、チェーンが<a href="https://www.symphonious.net/2021/09/23/what-happens-if-beacon-chain-consensus-fails/" target="_blank">誤って分岐してファイナリティに達する</a>可能性があり、多数のバリデータが無効なチェーンで立ち往生することになります。正しいチェーンに再参加したい場合、これらのバリデータはスラッシングに直面するか、遅くて費用のかかる自発的な引き出しと再有効化を行う必要があります。スラッシングの規模は、責任のあるノードの数に比例し、3分の2の多数派が最大（32 ETH）でスラッシングされます。

これらは起こりそうにないシナリオですが、イーサリアムのエコシステムは、アクティブなノード間でクライアントの分布を均等にすることで、そのリスクを軽減できます。理想的には、どのコンセンサス・クライアントも全ノードの33%のシェアに達しないことです。

### 責任の共有 {#responsibility}

多数派のクライアントを持つことには、人的コストも伴います。小規模な開発チームに過度の負担と責任を負わせることになります。クライアント・ダイバーシティが低いほど、多数派のクライアントを保守する開発者の責任の負担は大きくなります。この責任を複数のチームに分散させることは、イーサリアムのノードのネットワークと人々のネットワークの両方の健全性にとって良いことです。

## 現在のクライアント・ダイバーシティ {#current-client-diversity}

### 実行クライアント {#execution-clients-breakdown}

<PieChart
data={[
{ name: "Geth", value: 41 },
{ name: "Nethermind", value: 38 },
{ name: "Besu", value: 16 },
{ name: "Erigon", value: 3 },
{ name: "Reth", value: 2 }
]}
/>

### コンセンサス・クライアント {#consensus-clients-breakdown}

<PieChart
data={[
{ name: "Lighthouse", value: 42.71 },
{ name: "Prysm", value: 30.91},
{ name: "Teku", value: 13.86},
{ name: "Nimbus", value: 8.74},
{ name: "Lodestar", value: 2.67 },
{ name: "Grandine", value: 1.04 },
{ name: "Other", value: 0.07 }
]}
/>

この図は古い可能性があります。最新情報については、[ethernodes.org](https://ethernodes.org)および[clientdiversity.org](https://clientdiversity.org)にアクセスしてください。

上記の2つの円グラフは、実行レイヤーとコンセンサス・レイヤーの現在のクライアント・ダイバーシティのスナップショットを示しています（2025年10月執筆時点）。クライアント・ダイバーシティは長年にわたって改善されており、実行レイヤーでは[ゲス](https://geth.ethereum.org/)による支配が減少し、[ネザーマインド](https://www.nethermind.io/nethermind-client)が僅差で2位、[ベス](https://besu.hyperledger.org/)が3位、[エリゴン](https://github.com/ledgerwatch/erigon)が4位となり、他のクライアントはネットワークの3%未満を占めています。コンセンサス・レイヤーで最も一般的に使用されているクライアントである[ライトハウス](https://lighthouse.sigmaprime.io/)は、2番目に使用されているクライアントと非常に近い割合です。[プリズム](https://prysmaticlabs.com/#projects)と[テク](https://consensys.net/knowledge-base/ethereum-2/teku/)はそれぞれ約31%と約14%を占めており、他のクライアントはほとんど使用されていません。

実行レイヤーのデータは、2025年10月26日に[supermajority.info](https://supermajority.info/)から取得されました。コンセンサス・クライアントのデータは、[Michael Sproul](https://github.com/sigp/blockprint)から取得されました。コンセンサス・レイヤーのクライアントは、それらを識別するために使用できる明確な痕跡を常に持っているわけではないため、コンセンサス・クライアントのデータを取得するのはより困難です。データは、一部の少数派クライアントを混同することがある分類アルゴリズムを使用して生成されました（詳細については[こちら](https://twitter.com/sproulM_/status/1440512518242197516)を参照してください）。上の図では、これらの曖昧な分類は「いずれか」のラベル（例：ニンバス/テク）で扱われています。それにもかかわらず、ネットワークの大部分がプリズムを実行していることは明らかです。スナップショットに過ぎませんが、図の値は現在のクライアント・ダイバーシティの状態の全体像をよく表しています。

コンセンサス・レイヤーの最新のクライアント・ダイバーシティデータは、現在[clientdiversity.org](https://clientdiversity.org/)で入手できます。

## 実行レイヤー {#execution-layer}

これまで、クライアント・ダイバーシティに関する議論は主にコンセンサス・レイヤーに焦点が当てられてきました。しかし、実行クライアントの[ゲス](https://geth.ethereum.org)は現在、全ノードの約85%を占めています。この割合は、コンセンサス・クライアントの場合と同じ理由で問題があります。例えば、トランザクションの処理や実行ペイロードの構築に影響を与えるゲスのバグは、コンセンサス・クライアントが問題のある、またはバグのあるトランザクションをファイナライズすることにつながる可能性があります。したがって、実行クライアントがより均等に分散され、理想的にはどのクライアントもネットワークの33%以上を占めない方が、イーサリアムはより健全になります。

## 少数派クライアントを使用する {#use-minority-client}

クライアント・ダイバーシティに対処するには、個々のユーザーが少数派クライアントを選択するだけでなく、バリデータプールや主要な分散型アプリケーション (dapp)、取引所などの機関もクライアントを切り替える必要があります。しかし、すべてのユーザーは、現在の不均衡を是正し、利用可能なすべてのイーサリアムソフトウェアの使用を標準化するために、それぞれの役割を果たすことができます。マージ後、すべてのノードオペレーターは実行クライアントとコンセンサス・クライアントを実行する必要があります。以下で提案されているクライアントの組み合わせを選択することで、クライアント・ダイバーシティの向上に役立ちます。

### 実行クライアント {#execution-clients}

- [ベス](https://www.hyperledger.org/use/besu)
- [ネザーマインド](https://downloads.nethermind.io/)
- [エリゴン](https://github.com/ledgerwatch/erigon)
- [ゴー・イーサリアム](https://geth.ethereum.org/)
- [レス](https://reth.rs/)

### コンセンサス・クライアント {#consensus-clients}

- [ニンバス](https://nimbus.team/)
- [ライトハウス](https://github.com/sigp/lighthouse)
- [テク](https://consensys.io/teku)
- [ロードスター](https://github.com/ChainSafe/lodestar)
- [プリズム](https://prysm.offchainlabs.com/docs/)
- [Grandine](https://docs.grandine.io/)

技術的なユーザーは、少数派クライアント向けのチュートリアルやドキュメントをさらに作成し、ノードを運用している仲間に支配的なクライアントからの移行を促すことで、このプロセスを加速させることができます。少数派のコンセンサス・クライアントへの切り替えに関するガイドは、[clientdiversity.org](https://clientdiversity.org/)で入手できます。

## クライアント・ダイバーシティのダッシュボード {#client-diversity-dashboards}

いくつかのダッシュボードでは、実行レイヤーとコンセンサス・レイヤーのリアルタイムのクライアント・ダイバーシティ統計が提供されています。

**コンセンサス・レイヤー:**

- [Rated.network](https://www.rated.network/)
- [clientdiversity.org](https://clientdiversity.org/)

**実行レイヤー:**

- [supermajority.info](https://supermajority.info//)
- [Ethernodes](https://ethernodes.org/)

## 参考文献 {#further-reading}

- [イーサリアムのコンセンサス・レイヤーにおけるクライアント・ダイバーシティ](https://mirror.xyz/jmcook.eth/S7ONEka_0RgtKTZ3-dakPmAHQNPvuj15nh0YGKPFriA)
- [イーサリアムのマージ：多数派クライアントの実行は自己責任で！](https://dankradfeist.de/ethereum/2022/03/24/run-the-majority-client-at-your-own-peril.html) – _Dankrad Fiest、2022年3月24日_
- [クライアント・ダイバーシティの重要性](https://our.status.im/the-importance-of-client-diversity/)
- [イーサリアムノードサービスのリスト](https://ethereumnodes.com/)
- [クライアント・ダイバーシティ問題の「5つのなぜ」](https://notes.ethereum.org/@afhGjrKfTKmksTOtqhB9RQ/BJGj7uh08)
- [イーサリアムのダイバーシティとその解決方法 (ユーチューブ)](https://www.youtube.com/watch?v=1hZgCaiqwfU)
- [clientdiversity.org](https://clientdiversity.org/)

## 関連トピック {#related-topics}

- [イーサリアムノードの実行](/run-a-node/)
- [ノードとクライアント](/developers/docs/nodes-and-clients/)
