null
執筆：imToken
客観的に言えば、過去しばらくの間、多くのユーザーがイーサリアムの直感的な感覚を得るのは、しばしばロードマップや開発者会議からではなく、具体的なオンチェーン操作のたびに感じるものだった。
例えば、ここ2年ほど皆が共感しているのは、送金時のGasが徐々に低下したことや、クロスチェーンの相互運用性の体験が改善されたことなどであり、これが示すのは、イーサリアムのスケーリングは単なる「性能競争」の問題ではないということだ——一般ユーザーにとっては、より高いTPS、大きなブロック、より複雑な基盤アーキテクチャは、実際にコストが下がり、操作がスムーズになり、安全なウォレット体験に変換されて初めて意味を持つ。
そして最近のイーサリアムの一連の新動向は、まさに、ウォレットやDApp、サードパーティリレー、ユーザー自身が担ってきた複雑性を、システム的にプロトコル層に前倒ししていこうとする試みを指している。
その中には、Vitalikが関わるKeyed Noncesや、Glamsterdamアップグレードにおいて2億Gasリミットの下限をめぐる方向性の合意、そして2026年のロードマップで継続的に強調されるネイティブアカウントの抽象化、L2間の相互運用性、L1のセキュリティ強化など、一連の伏線も含まれている。
一、Gasリミットを2億に引き上げる？
まず最もユーザーに感知されやすい点、Gasリミットについて見てみよう。
周知の通り、イーサリアムネットワークでは、各取引（送金もコントラクト操作も）には一定のGas消費が必要であり、各イーサリアムブロックのGasリミット容量は固定されている。つまり、席数には限りがある：席数が多ければ同時に運べる乗客も多くなるし、席数が少なければ、同じ時間内に運べる人数は少なくなる。席が逼迫すれば、皆が同じ座席をめぐって競争し、Gas代も高騰する。
理論的には、ブロックのGas上限を拡張すれば、イーサリアムメインネットの性能は大きく向上するはずだ。ただし、過去のイーサリアムはL2などのルートの発展背景もあり、この点については慎重だった。多くのスケーリング圧力は意図的にL2に振り分けられてきた。
イーサリアムのGasリミットの拡張曲線を振り返ると、2019年9月にGasリミットが800万から初めて1000万を突破し、それから今年までの7年間で、Gasリミットは800万から6000万にまで増加した。特に2025年に本格的な加速段階に入り、2月に3000万から3600万へ、7月に4500万へ、12月のFusakaアップグレード後に6000万へと引き上げられた。
ほとんどの拡張は2025年に集中していると言えるだろう。もちろん、我々も以前触れたが、2025年はイーサリアムの歴史において非常に重要な年だ。5月のPectraアップグレードから7か月後のFusakaアップグレードは、EF（Ethereum Foundation）が大きなリーダーシップの変動を経ても、重要なアップデートを推進できることを示し、またイーサリアムが「年2回のハードフォーク」という加速的な開発リズムに正式に入ったことを示している（詳細は「イーサリアム2026：EF最新プロトコルロードマップ解読、いよいよ『エンジニアリングアップグレード』時代へ？」を参照）。
出典：Etherscan
そして、Ethereum Foundationが5月2日に発表したSoldøgn Interop Recapによると、ノルウェーのスバールバル諸島で、Glamsterdamアップグレードに関する相互運用会議に100人以上のイーサリアムコア貢献者が参加し、主な目的はGlamsterdamのマルチクライアント実装、テスト、パラメータ調整の推進だった。会議終了時点で、開発者たちはGlamsterdam後の2億Gasリミットに関して方向性の合意を形成していた。
これは、今後の流れが順調に進めば、イーサリアムL1の実行容量は現状の約6000万Gasリミットからさらに2億規模へと引き上げられる可能性を示している。長期的に見れば、イーサリアムエコシステムのGasリミットに対する公開討議の姿勢は「かなり積極的」になっている。EIP-9698提案では、「2年ごとに10倍引き上げる」ことも提案されており、2029年にはGasリミットを36億にまで引き上げることを目指している。これは現状の50倍にあたる。
ただし、ここで強調したいのは、Gasリミットの引き上げは単にブロックを大きくすることではない。
もし単純に計算量を増やすだけなら、短期的には手数料を下げる効果も期待できるが、長期的にはノードの負担増や状態データの膨張を招き、普通のユーザーがノードを運用するのをより困難にし、結果的にイーサリアムの最も核心的な分散性を弱めることになる。
したがって、Glamsterdamの拡張戦略は、次のような複合的アプローチだ。
ePBS（enshrined Proposer-Builder Separation）により、ブロック構築と検証のプロセスをより明確にプロトコルルールに組み込み、検証者がより安全に大きなブロックを処理できるようにする。
Block-Level Access Lists（BAL）は、ブロック実行中にアクセスされるアカウントやストレージ位置を事前に記録し、並列ディスク読み取りや並列取引検証、並列状態根計算を可能にする。
EIP-8037は、状態作成に関わる操作のコストを引き上げることで、Gasリミット引き上げ後の状態の過剰な増加を抑制する。
結局のところ、イーサリアムは「より多くの取引を詰め込む」だけを目指しているのではなく、より多くの取引を詰め込む一方で、ノードの運用コストを上げすぎないように工夫している。
これが、多くのハイパフォーマンスチェーンとの根本的な違いだ。検証コストを犠牲にして表面的なスループットを追求するのではなく、普通のノードも参加でき、システム全体が検証可能な範囲内で、メインネットの耐荷重性を高めることを追求している。
二、Keyed Nonces：一つの「列」から「複数のチャネル」へ
Gasリミットの解決が「一つのブロックにどれだけ詰め込めるか」だとすれば、Keyed Noncesは、より細かく重要な別の問題に焦点を当てている。それは、「取引の並び順」だ。
周知の通り、イーサリアムにおいてnonceは、アカウントの取引の「番号付け」に相当し、これの役割は、同じ取引の重複実行を防ぎ、同一アカウントからの取引を順番通りに処理することだ。
この仕組みは、普通の送金シーンでは理解しやすい。最初の取引、次の取引、3番目の取引と順番に並べる。
しかし、問題は、アカウントの能力がより複雑になると、例えばプライバシー取引、スマートウォレット、セッションキー、一括操作、サードパーティの代行などの場合、単一の線形nonceはボトルネックになり得る。そこでEIP-8250で提案されたのが、Keyed Noncesだ。
具体的には、従来の単一のsender nonceを、(nonce_key, nonce_seq)構造に置き換える。ここで、nonce_key==0は従来のアカウントnonceに対応し、非ゼロのkeyは独立したプロトコル管理のnonceシーケンスを持つ。異なるkeyの下では、取引は互いに独立し、リプレイ防止も相互に影響しない。
これは技術的には難しいが、生活の比喩で理解すれば、従来のアカウントは銀行の一つの窓口のようなもので、すべての取引は同じ列に並ぶ必要があった。Keyed Noncesは、異なる取引を異なる窓口に振り分けるようなもので、送金、プライバシー引き出し、セッション認証、一括実行などがそれぞれの通路を持つことになる。
これは特にプライバシー関連のプロトコルにとって重要だ。なぜなら、ユーザーのオンチェーン活動を特定の公開アドレスに直接結びつけたくない場合、複数のユーザーが共有のsenderアドレスから取引を発信することがあり、その場合、単一nonceの仕組みだと、あるユーザーの取引がパッキングされた後、他のユーザーの取引が失効したりブロックされたりする可能性があるからだ。
Keyed Noncesは、各取引が自分専用のnonce域を持つことを可能にし、例えばプライバシーnullifierから派生させるなど、プロトコル層でこの並列化の衝突を減らす。
Vitalik自身は、これをより大きな視点で捉えており、EIP-8250の紹介時に明言している。Keyed Noncesは「単なるプロトコル層のプライバシー支援だけでなく、イーサリアムの新たな状態拡張戦略の第一歩になり得る——異なるユースケースに最適化されたストレージタイプを作ることで、分散性を保ちつつ、極限まで拡張性を高めることができる」と。
要するに、Gasリミットが「ブロックの大きさ」を解決するのに対し、Keyed Noncesは「状態の形状」を探るものだ——イーサリアムが将来担うのは、より多くの取引だけでなく、多種多様な取引を可能にすることだ。
三、これが普通のユーザーにどう影響するか？
イーサリアムエコシステムにとって、多くのプロトコルのアップグレードは遠い未来の話のように見えるかもしれないが、最終的にはウォレットの体験に直結する。
なぜなら、ユーザーがイーサリアムに触れる入口は、EIPやクライアント、開発者会議ではなく、ウォレット内の送金、認証、署名、クロスチェーン、DAppとのインタラクションだからだ。つまり、プロトコル層の変化は、ウォレット側でよりわかりやすく、スムーズで、安全な操作体験に翻訳されて初めて、技術的なアップグレードからユーザー体験の向上へと実現する。
例えば、すでに広く知られるアカウント抽象化は、ユーザーにとって技術的な用語を理解させるためではなく、将来的により自然にオンチェーンアカウントを使えるようにするためのものだ。近年では、バッチ取引、Gas代付、リカバリーメカニズム、異なる署名方式、セッション認証、より柔軟なセキュリティ戦略などが、徐々にウォレットの基本機能になりつつある。
同じくKeyed Noncesも、底層のアカウント並びの最適化のように見えるが、ユーザー側にとっては潜在的な影響は抽象的ではない。たとえば、多くのユーザーは、取引が遅延して未確認になったり、後続の取引が詰まったり、キャンセルや加速をしたいが、nonceやGas、置換取引の関係を理解できずに困ることがある。特に複数の操作を並行して行う場合、一つの失敗が後続の操作に影響を及ぼす。
これらの問題は、「ウォレットの使い勝手が悪い」や「チェーンが使いにくい」と見なされがちだが、実際にはイーサリアムのアカウントモデルの単一線形nonceの設計に根ざしている。Keyed Noncesの方向性は、アカウントが一つの列に沿って順番に操作を行うのではなく、シナリオに応じて複数の並列チャネルに分割できるようにすることだ。
将来的には、普通の送金やDApp認証、プライバシー取引、バッチ取引、Gas代付などの操作は、それぞれより独立した実行空間を持ち、相互のブロックや衝突を減らすことが期待できる。
これにより、スマートウォレットの設計空間はさらに広がる。
さらに重要なのは、これらの能力は従来、ウォレットやDApp、中継サービス、ユーザーが共同で複雑性を負担してきたが、今後は一部の複雑性をプロトコル層に前倒しし、より標準化された底層能力を基に、ユーザーにとってより良いインタラクションの抽象化を提供しようとしている点だ。
これが、Gasリミット、BAL、ePBS、Keyed Nonces、Frame Transactions、ネイティブアカウント抽象化、クロスL2相互運用性が、それぞれ異なる技術モジュールに見えても、実は同じ目的——「分散性と安全性を犠牲にせず、より複雑なオンチェーンシナリオを担えるようにする」——を支えている理由だ。
これらを総合して見ると、イーサリアムの最近の重点は次のように整理できる。
・Gasリミットの引き上げは、メインネットの実行容量とコスト圧力の解決策。
・BAL、ePBS、EIP-8037は、拡張中のノードの検証性と状態増加のコントロール。
・Keyed NoncesとFrame Transactionsは、アカウントモデル、プライバシー、スマートウォレットのボトルネック解消。
・ネイティブアカウント抽象化とクロスL2の相互運用性は、最終的にユーザーが実感できる体験改善へとつながる。
これもまた、イーサリアムが新たな段階に入ったことを示している。
過去数年、市場はL2のスケーリングやBlobのコスト削減、モジュール化のナラティブに注目し、ユーザーも異なるL2間で資産を移動し、より低コストなインタラクションを求めることに慣れてきた。しかし、メインネットのGasリミットが引き続き上昇し、Glamsterdamなどのアップグレードが進み、アカウント抽象化や相互運用の方案が進化する中で、イーサリアムが答えようとしているのは、「取引をより安くする」だけでなく、「全体としてのオンチェーン体験をよりシームレスにする」ことだ。
この過程で、ウォレットの重要性はさらに高まる。
なぜなら、ウォレットは単なる入口ではなく、プロトコルの能力をユーザーに理解させ、使わせるためのインターフェースだからだ。今後、より複雑な底層のアップグレードほど、より明確な署名提示や取引経路の理解、リスクの事前認識、よりスムーズなオンチェーンインタラクションへと変換されていく必要がある。
皆さんと共に歩もう。
1.68M 人気度
46.7K 人気度
937.89K 人気度
63.7K 人気度
795.35K 人気度
ガスリミットからキー付きノンスまで、イーサリアムのスケーラビリティの次の一歩をどう理解すべきか？
null
執筆：imToken
客観的に言えば、過去しばらくの間、多くのユーザーがイーサリアムの直感的な感覚を得るのは、しばしばロードマップや開発者会議からではなく、具体的なオンチェーン操作のたびに感じるものだった。
例えば、ここ2年ほど皆が共感しているのは、送金時のGasが徐々に低下したことや、クロスチェーンの相互運用性の体験が改善されたことなどであり、これが示すのは、イーサリアムのスケーリングは単なる「性能競争」の問題ではないということだ——一般ユーザーにとっては、より高いTPS、大きなブロック、より複雑な基盤アーキテクチャは、実際にコストが下がり、操作がスムーズになり、安全なウォレット体験に変換されて初めて意味を持つ。
そして最近のイーサリアムの一連の新動向は、まさに、ウォレットやDApp、サードパーティリレー、ユーザー自身が担ってきた複雑性を、システム的にプロトコル層に前倒ししていこうとする試みを指している。
その中には、Vitalikが関わるKeyed Noncesや、Glamsterdamアップグレードにおいて2億Gasリミットの下限をめぐる方向性の合意、そして2026年のロードマップで継続的に強調されるネイティブアカウントの抽象化、L2間の相互運用性、L1のセキュリティ強化など、一連の伏線も含まれている。
一、Gasリミットを2億に引き上げる？
まず最もユーザーに感知されやすい点、Gasリミットについて見てみよう。
周知の通り、イーサリアムネットワークでは、各取引（送金もコントラクト操作も）には一定のGas消費が必要であり、各イーサリアムブロックのGasリミット容量は固定されている。つまり、席数には限りがある：席数が多ければ同時に運べる乗客も多くなるし、席数が少なければ、同じ時間内に運べる人数は少なくなる。席が逼迫すれば、皆が同じ座席をめぐって競争し、Gas代も高騰する。
理論的には、ブロックのGas上限を拡張すれば、イーサリアムメインネットの性能は大きく向上するはずだ。ただし、過去のイーサリアムはL2などのルートの発展背景もあり、この点については慎重だった。多くのスケーリング圧力は意図的にL2に振り分けられてきた。
イーサリアムのGasリミットの拡張曲線を振り返ると、2019年9月にGasリミットが800万から初めて1000万を突破し、それから今年までの7年間で、Gasリミットは800万から6000万にまで増加した。特に2025年に本格的な加速段階に入り、2月に3000万から3600万へ、7月に4500万へ、12月のFusakaアップグレード後に6000万へと引き上げられた。
ほとんどの拡張は2025年に集中していると言えるだろう。もちろん、我々も以前触れたが、2025年はイーサリアムの歴史において非常に重要な年だ。5月のPectraアップグレードから7か月後のFusakaアップグレードは、EF（Ethereum Foundation）が大きなリーダーシップの変動を経ても、重要なアップデートを推進できることを示し、またイーサリアムが「年2回のハードフォーク」という加速的な開発リズムに正式に入ったことを示している（詳細は「イーサリアム2026：EF最新プロトコルロードマップ解読、いよいよ『エンジニアリングアップグレード』時代へ？」を参照）。
出典：Etherscan
そして、Ethereum Foundationが5月2日に発表したSoldøgn Interop Recapによると、ノルウェーのスバールバル諸島で、Glamsterdamアップグレードに関する相互運用会議に100人以上のイーサリアムコア貢献者が参加し、主な目的はGlamsterdamのマルチクライアント実装、テスト、パラメータ調整の推進だった。会議終了時点で、開発者たちはGlamsterdam後の2億Gasリミットに関して方向性の合意を形成していた。
これは、今後の流れが順調に進めば、イーサリアムL1の実行容量は現状の約6000万Gasリミットからさらに2億規模へと引き上げられる可能性を示している。長期的に見れば、イーサリアムエコシステムのGasリミットに対する公開討議の姿勢は「かなり積極的」になっている。EIP-9698提案では、「2年ごとに10倍引き上げる」ことも提案されており、2029年にはGasリミットを36億にまで引き上げることを目指している。これは現状の50倍にあたる。
ただし、ここで強調したいのは、Gasリミットの引き上げは単にブロックを大きくすることではない。
もし単純に計算量を増やすだけなら、短期的には手数料を下げる効果も期待できるが、長期的にはノードの負担増や状態データの膨張を招き、普通のユーザーがノードを運用するのをより困難にし、結果的にイーサリアムの最も核心的な分散性を弱めることになる。
したがって、Glamsterdamの拡張戦略は、次のような複合的アプローチだ。
ePBS（enshrined Proposer-Builder Separation）により、ブロック構築と検証のプロセスをより明確にプロトコルルールに組み込み、検証者がより安全に大きなブロックを処理できるようにする。
Block-Level Access Lists（BAL）は、ブロック実行中にアクセスされるアカウントやストレージ位置を事前に記録し、並列ディスク読み取りや並列取引検証、並列状態根計算を可能にする。
EIP-8037は、状態作成に関わる操作のコストを引き上げることで、Gasリミット引き上げ後の状態の過剰な増加を抑制する。
結局のところ、イーサリアムは「より多くの取引を詰め込む」だけを目指しているのではなく、より多くの取引を詰め込む一方で、ノードの運用コストを上げすぎないように工夫している。
これが、多くのハイパフォーマンスチェーンとの根本的な違いだ。検証コストを犠牲にして表面的なスループットを追求するのではなく、普通のノードも参加でき、システム全体が検証可能な範囲内で、メインネットの耐荷重性を高めることを追求している。
二、Keyed Nonces：一つの「列」から「複数のチャネル」へ
Gasリミットの解決が「一つのブロックにどれだけ詰め込めるか」だとすれば、Keyed Noncesは、より細かく重要な別の問題に焦点を当てている。それは、「取引の並び順」だ。
周知の通り、イーサリアムにおいてnonceは、アカウントの取引の「番号付け」に相当し、これの役割は、同じ取引の重複実行を防ぎ、同一アカウントからの取引を順番通りに処理することだ。
この仕組みは、普通の送金シーンでは理解しやすい。最初の取引、次の取引、3番目の取引と順番に並べる。
しかし、問題は、アカウントの能力がより複雑になると、例えばプライバシー取引、スマートウォレット、セッションキー、一括操作、サードパーティの代行などの場合、単一の線形nonceはボトルネックになり得る。そこでEIP-8250で提案されたのが、Keyed Noncesだ。
具体的には、従来の単一のsender nonceを、(nonce_key, nonce_seq)構造に置き換える。ここで、nonce_key==0は従来のアカウントnonceに対応し、非ゼロのkeyは独立したプロトコル管理のnonceシーケンスを持つ。異なるkeyの下では、取引は互いに独立し、リプレイ防止も相互に影響しない。
これは技術的には難しいが、生活の比喩で理解すれば、従来のアカウントは銀行の一つの窓口のようなもので、すべての取引は同じ列に並ぶ必要があった。Keyed Noncesは、異なる取引を異なる窓口に振り分けるようなもので、送金、プライバシー引き出し、セッション認証、一括実行などがそれぞれの通路を持つことになる。
これは特にプライバシー関連のプロトコルにとって重要だ。なぜなら、ユーザーのオンチェーン活動を特定の公開アドレスに直接結びつけたくない場合、複数のユーザーが共有のsenderアドレスから取引を発信することがあり、その場合、単一nonceの仕組みだと、あるユーザーの取引がパッキングされた後、他のユーザーの取引が失効したりブロックされたりする可能性があるからだ。
Keyed Noncesは、各取引が自分専用のnonce域を持つことを可能にし、例えばプライバシーnullifierから派生させるなど、プロトコル層でこの並列化の衝突を減らす。
Vitalik自身は、これをより大きな視点で捉えており、EIP-8250の紹介時に明言している。Keyed Noncesは「単なるプロトコル層のプライバシー支援だけでなく、イーサリアムの新たな状態拡張戦略の第一歩になり得る——異なるユースケースに最適化されたストレージタイプを作ることで、分散性を保ちつつ、極限まで拡張性を高めることができる」と。
要するに、Gasリミットが「ブロックの大きさ」を解決するのに対し、Keyed Noncesは「状態の形状」を探るものだ——イーサリアムが将来担うのは、より多くの取引だけでなく、多種多様な取引を可能にすることだ。
三、これが普通のユーザーにどう影響するか？
イーサリアムエコシステムにとって、多くのプロトコルのアップグレードは遠い未来の話のように見えるかもしれないが、最終的にはウォレットの体験に直結する。
なぜなら、ユーザーがイーサリアムに触れる入口は、EIPやクライアント、開発者会議ではなく、ウォレット内の送金、認証、署名、クロスチェーン、DAppとのインタラクションだからだ。つまり、プロトコル層の変化は、ウォレット側でよりわかりやすく、スムーズで、安全な操作体験に翻訳されて初めて、技術的なアップグレードからユーザー体験の向上へと実現する。
例えば、すでに広く知られるアカウント抽象化は、ユーザーにとって技術的な用語を理解させるためではなく、将来的により自然にオンチェーンアカウントを使えるようにするためのものだ。近年では、バッチ取引、Gas代付、リカバリーメカニズム、異なる署名方式、セッション認証、より柔軟なセキュリティ戦略などが、徐々にウォレットの基本機能になりつつある。
同じくKeyed Noncesも、底層のアカウント並びの最適化のように見えるが、ユーザー側にとっては潜在的な影響は抽象的ではない。たとえば、多くのユーザーは、取引が遅延して未確認になったり、後続の取引が詰まったり、キャンセルや加速をしたいが、nonceやGas、置換取引の関係を理解できずに困ることがある。特に複数の操作を並行して行う場合、一つの失敗が後続の操作に影響を及ぼす。
これらの問題は、「ウォレットの使い勝手が悪い」や「チェーンが使いにくい」と見なされがちだが、実際にはイーサリアムのアカウントモデルの単一線形nonceの設計に根ざしている。Keyed Noncesの方向性は、アカウントが一つの列に沿って順番に操作を行うのではなく、シナリオに応じて複数の並列チャネルに分割できるようにすることだ。
将来的には、普通の送金やDApp認証、プライバシー取引、バッチ取引、Gas代付などの操作は、それぞれより独立した実行空間を持ち、相互のブロックや衝突を減らすことが期待できる。
これにより、スマートウォレットの設計空間はさらに広がる。
さらに重要なのは、これらの能力は従来、ウォレットやDApp、中継サービス、ユーザーが共同で複雑性を負担してきたが、今後は一部の複雑性をプロトコル層に前倒しし、より標準化された底層能力を基に、ユーザーにとってより良いインタラクションの抽象化を提供しようとしている点だ。
これが、Gasリミット、BAL、ePBS、Keyed Nonces、Frame Transactions、ネイティブアカウント抽象化、クロスL2相互運用性が、それぞれ異なる技術モジュールに見えても、実は同じ目的——「分散性と安全性を犠牲にせず、より複雑なオンチェーンシナリオを担えるようにする」——を支えている理由だ。
これらを総合して見ると、イーサリアムの最近の重点は次のように整理できる。
・Gasリミットの引き上げは、メインネットの実行容量とコスト圧力の解決策。
・BAL、ePBS、EIP-8037は、拡張中のノードの検証性と状態増加のコントロール。
・Keyed NoncesとFrame Transactionsは、アカウントモデル、プライバシー、スマートウォレットのボトルネック解消。
・ネイティブアカウント抽象化とクロスL2の相互運用性は、最終的にユーザーが実感できる体験改善へとつながる。
これもまた、イーサリアムが新たな段階に入ったことを示している。
過去数年、市場はL2のスケーリングやBlobのコスト削減、モジュール化のナラティブに注目し、ユーザーも異なるL2間で資産を移動し、より低コストなインタラクションを求めることに慣れてきた。しかし、メインネットのGasリミットが引き続き上昇し、Glamsterdamなどのアップグレードが進み、アカウント抽象化や相互運用の方案が進化する中で、イーサリアムが答えようとしているのは、「取引をより安くする」だけでなく、「全体としてのオンチェーン体験をよりシームレスにする」ことだ。
この過程で、ウォレットの重要性はさらに高まる。
なぜなら、ウォレットは単なる入口ではなく、プロトコルの能力をユーザーに理解させ、使わせるためのインターフェースだからだ。今後、より複雑な底層のアップグレードほど、より明確な署名提示や取引経路の理解、リスクの事前認識、よりスムーズなオンチェーンインタラクションへと変換されていく必要がある。
皆さんと共に歩もう。