AnyPS5のシェーダーカバレッジが100%に到達、ただしPCでのネイティブPS5ゲーム実行はなお遠い
AnyPS5のシェーダーカバレッジは、追跡対象となるGPU命令1,166件すべてで100%に到達した。これはオープンソースプロジェクトにとって重要な技術的節目だが、大きな留保もある。現在は一覧にあるすべての命令を認識できるものの、認識できることは正確な変換や安定したゲーム描画を保証するものではない。
この違いこそが、価値あるエンジニアリング上の成果と、「PlayStation 5ゲームが一般的なPCでネイティブ実行できる準備が整った」という、より劇的な主張を分ける要因だ。AnyPS5には、未完成のシェーダーセマンティクス、不完全なシステムライブラリ、同期の問題、タイトル固有の挙動といった課題が依然として残る。
このプロジェクトは、SharpEmuやKytyのような実験的エミュレーターとは異なる道筋を取る。仮想的なコンソール環境を維持するのではなく、WindowsまたはLinux向けに実行ファイルを変換し、代替のシステムライブラリを提供する方式だ。その進展は、PS5ソフトウェアを従来型のコンソールエミュレーションではなく、互換性レイヤーのワークロードに近い形で適応できるかという、より大きな考え方を試している。
AnyPS5のシェーダーカバレッジ、1,166命令を網羅
今回の節目が解消したのはAnyPS5のシェーダーデコーダーにおける空白であり、PS5実行ファイルと動作するPCゲームの間にあるすべての障害ではない。
2026年10月9日付の進捗スナップショットでは、追跡対象のGPU命令1,166件中1,166件が実装済みとされている。この一覧はAMD RDNA 1およびRDNA 2の命令セットに基づき、シェーダープログラムで用いられる複数の命令ファミリーを対象としている。
これらのファミリーには、スカラー演算、ベクトル演算、メモリアクセス、画像処理、データ共有、制御フロー命令が含まれる。これらは合わせて、PlayStation 5のグラフィックスプログラムがAMDベースのGPUを制御する際に用いる語彙の大部分を構成する。
AnyPS5は、このトラッカーにおける「実装済み」を特定の意味で定義している。シェーダーデコーダーが命令を認識できれば、その命令は対象となる。デコーダーは、機械語命令を読み取り、その処理、オペランド、エンコーディングを識別するコンポーネントだ。
認識は重要である。未知の命令があると、変換プロセスは即座に停止し得る。元のプログラムの一部が何を意味するのか判断できなければ、ツールはシェーダーを変換できない。
ただし、命令を認識することと、その挙動を再現することは異なる。後者には、そのセマンティクスをPCのグラフィックススタック上で同じ結果を生むコードへ変換する必要がある。
プロジェクトの公開ドキュメントによれば、シェーダーリコンパイラーはSPIR-Vを生成する。SPIR-Vは中間表現であり、ツールが特定ベンダーの機械語を直接の対象とせず、Vulkanを含むAPI向けにGPUプログラムを表現できるようにする。
専用の検証オプションを有効にすると、生成された出力をSPIRV-Toolsで検査できるとプロジェクトは説明している。この検証では不正なモジュールや構造上の違反を検出できる。ただし、変換されたすべての命令がPS5ゲームの期待どおりに正確な結果を返すことまでは証明しない。
この違いは、技術辞典を完全に解析することと、あらゆる文章を正しく翻訳することの違いに似ている。翻訳者はまずすべての単語を認識しなければならないが、語彙の網羅だけで文脈、タイミング、曖昧な挙動が解決するわけではない。
coverage reportでは、追跡対象のシステムライブラリ実装率も、宣言済み関数3,038件中2,575件、すなわち84.76%とされている。この数字にも留保が必要だ。
これは、プロジェクトがすでに把握し、宣言している関数を測定したものだ。より多くのゲームに必要な追加関数を開発者が発見すれば、分母は増え得る。Sonyの完全な非公開ソフトウェアインターフェースに対する固定的な割合ではない。
シェーダーの数値は、明示された範囲内ではより具体的だ。プロジェクトのRDNA追跡リストに現在含まれるすべての命令が、認識の基準に達した。これにより、未知のシェーダーを調査するコントリビューターが直面する即座の行き詰まりは減る。
同時に、今後の作業内容も変わる。開発者は不足しているデコーダーエントリーを埋める作業から、セマンティクスの検証、描画不具合の診断、出力と想定されるハードウェア動作の比較へ、徐々に移行できる。
この変化により、100%は意味のある節目となる。ただし、それが互換性についての判定を意味するわけではない。
従来型エミュレーターなしでAnyPS5が動作する仕組み
AnyPS5は、PS5が採用するx86-64とAMDグラフィックスという馴染み深い基盤により、コンソール全体をソフトウェアで再構築するよりも変換のほうが実用的になり得ると考えている。
プロジェクトのアーキテクチャーは、ハードウェア上の利点から始まる。PlayStation 5はx86-64命令セットに基づくAMDプロセッサを使用しており、この命令セットは主流のWindowsおよびLinux PCでも使われている。
旧世代のコンソールでは、デスクトップハードウェアとは大きく異なるCPUアーキテクチャーが採用されていることが多かった。そのソフトウェアを実行するには、継続的な命令変換や、馴染みのないプロセッサの詳細なシミュレーションが必要だった。
AnyPS5は別のアプローチを取る。project overviewでは、実行ファイルをLinuxおよびWindowsへ自動移植するツールとして説明されている。リリンカーが元の実行ファイルを、対象OS向けのネイティブ形式へ変換する。
リリンクは、実行ファイルの構造と依存関係を扱う。PS5プログラムは、標準的なPC環境には存在しないSony固有のモジュール、インターフェース、ロード動作を想定している。
そのためAnyPS5は、PS5のシステムPRXライブラリの代替実装を提供する。PRXライブラリは、コンソールソフトウェアが利用するOSおよびランタイム機能を公開する実行可能モジュールだ。
変換されたアプリケーションは、これらの代替実装にリンクする。理論上、ゲームは別個のエミュレーションプロセス内で実行されるのではなく、ネイティブなホストプロセスとして動作できる。
グラフィックスも並行した変換経路をたどる。シェーダーリコンパイラーはGPU命令をデコードし、WindowsとLinuxでサポートされるクロスプラットフォームのグラフィックスAPIであるVulkan向けにSPIR-Vを生成する。
このアーキテクチャーは、命令を完全に認識できることが重要な理由を説明している。未知のエンコーディングを含むシェーダーは、変換パイプラインに穴を作る。追跡リストを埋めることで、デコーダーは別種の障害に遭遇するまで、より先へ進めるようになる。
同時に、この節目が不完全なままである理由も説明している。デコーダーは命令を正しく識別できても、リコンパイラーにはその挙動をSPIR-Vへ変換する処理が未完成のまま残っている可能性がある。
生成された変換結果でさえ、微妙に誤っていることがある。浮動小数点の規則、メモリー順序、レーンマスキング、ウェーブ演算、テクスチャサンプリング、未定義のハードウェア挙動は、特定のワークロードでしか現れない不具合を生む可能性がある。
コンソールゲームはCPUコードとシェーダー以上の要素にも依存している。特定のメモリーレイアウト、同期規則、グラフィックスコマンドの挙動、オーディオサービス、ストレージインターフェース、コントローラー入力、タイミング、OS応答を想定する。
ネイティブ実行ファイルは、想定される関数が1つ欠けているだけで失敗することがある。また、既存の関数がわずかに異なる値を返す、エッジケースを誤って扱う、あるいは誤った順序で処理を完了する場合にも失敗し得る。
プロジェクトのコントリビューション規則は、この難しさを認めている。シェーダーの変更では、そのセマンティクスがAMDのドキュメント、Mesa、LLVM、ハードウェア計測、あるいは別の正確な技術ソースのどれに由来するかを示さなければならない。
contribution policyによると、レビュー担当者はシェーダーのセマンティクスをハードウェアに照らして確認する。挙動が未確定のままである場合は、エラーを発生させるか、プロジェクトの技術的負債記録に入れなければならない。
この方針は、静かな近似よりも可視化された失敗を意図的に優先するものだ。明示的なクラッシュは不足する挙動を明らかにできる。一方で、静かだが不正確なスタブは状態を破損させ、かなり後になって誤解を招く結果を生み得る。
したがってAnyPS5は、単にファイル拡張子を変更しているわけではない。変換したプログラムが別のOSで正しく動作するために必要なPS5ソフトウェア環境を、十分な範囲で再構築している。
リリンカー、代替ライブラリ、シェーダーリコンパイラーは、ひとつの連鎖を成す。個々のコンポーネントの進捗が意味を持つのは、その連鎖全体が実際のタイトルを支えられる場合に限られる。
真の争点はカバレッジと正確性の間にある
中心的な対立は、AnyPS5対Sonyでも、移植対エミュレーションでもない。プロジェクトが可視化するカバレッジ率と、はるかに厳しい挙動の正確性という基準との間にある。
進捗ダッシュボードは、複雑な作業を理解しやすい数値へ圧縮する。コントリビューターが不足領域を見つける助けとなり、観察者にも急速に進むプロジェクトを追う手段を提供する。
危険が生じるのは、内部のエンジニアリング指標が公的な互換性の主張へ変わるときだ。「GPUシェーダー命令カバレッジ100%」は「GPU完全対応」に近く聞こえるが、この2つは異なる基準を説明している。
カバレッジは、デコーダーが命令の存在を認識しているかを示す。正確性は、変換された完全なシェーダーが、関連するすべての条件下で元のものと同じように動作するかを問う。
後者の問いは複数の層で成り立つ。命令は正しい値を生成し、隣接する命令と正しく相互作用し、実行順序に関するゲーム側の前提を維持しなければならない。
さらに、シェーダーはリソースバインディング、テクスチャ、バッファー、レンダーターゲット、コマンドストリームと統合されなければならない。単独で正しい演算でも、不完全なグラフィックスパイプライン内では失敗し得る。
最後に、結果はホストGPUやドライバーをまたいでも安定していなければならない。Vulkanは共通APIを通じてプラットフォーム間の差異を減らすが、あらゆる実装上の差異を消し去るわけではない。
SPIR-Vの検証も同様に限定的な役割を持つ。バリデーターはモジュールが正式な構造規則に従うことを確認できる。しかし、そのプログラムが意図されたPS5シェーダーを表現しているかまでは判断できない。
文法的に正しい文章でも、誤った事実を述べることはある。同じように、有効なSPIR-Vモジュールも、コンパイルされ実行できても、誤った画像を生成する可能性がある。
この区別は、高度な商用ゲームでは特に重要になる。現代のタイトルは、シェーダー、エンジンシステム、ミドルウェアモジュール、非同期ワークロード、独自のレンダリング技法を大規模に組み合わせている。
命令の誤りは、ある1つのマテリアル、ライティングパス、ポストプロセス効果にしか現れない場合がある。同期の不具合は、特定のシーンで十分な処理が同時進行するまで隠れたままかもしれない。
結果は、テクスチャの欠落から、ちらつくジオメトリー、ドライバーのリセット、メモリー破損、完全なクラッシュまで幅広い。こうした結果はいずれも、デコーダーカバレッジ100%と矛盾しない。
AnyPS5の厳格なエラー方針は、診断価値を高める一方で、初期段階の互換性を実際より悪く見せる可能性がある。ドキュメントによれば、未対応または想定外の状態はランタイムエラーを発生させ、プロセスを終了する。
このアプローチは、未実装の経路が動作すると装うことを避ける。また、内部状態が破損したままゲームが継続するよりも、コントリビューターに明確な失敗地点を与える。
GPUの節目とともに報じられたシステムライブラリの84.76%という数値にも、同じ慎重さが必要だ。宣言済みの数千件の関数を実装することは大きな作業だが、数値上のカバレッジから、どの不足関数が特定のゲームを阻害するかはほとんど分からない。
目立たない関数1つが起動を妨げることもある。逆に、単純なタイトルであれば、利用可能なインターフェースの狭い部分集合しか使わず、他の箇所に広範な欠落があっても動作する可能性がある。
したがって互換性は均一には進まない。プロジェクトは高い総合割合に達しても人気ゲームで苦戦することがあり、その後、慎重に実装された1つのサービスによって目に見える進展を得ることもある。
AnyPS5のシェーダーカバレッジを正しく捉えるなら、その意味は限定的ながら重要だ。追跡対象のデコーダ命令語彙は完全になり、コントリビューターは「未知の命令」という特定の障害を気にすることなく、より深い変換やランタイム上の問題を調査できるようになった。
ただし、この指標を、あらゆる描画への対応、GPUサポートの完成、あるいはPS5カタログとの近い将来の互換性を示すものにまで拡大解釈すべきではない。
ネイティブ移植とPS5エミュレーションは異なるボトルネックに直面する
AnyPS5と従来型のPS5エミュレーターは多くの技術課題を共有しているが、そのアーキテクチャによって、問題が表面化する場所は異なる。
エミュレーターは通常、元のコンソールに似せて設計された環境をソフトウェアに提供する。エミュレーション境界の内側で、仮想化ハードウェア、システムサービス、メモリ動作、グラフィックス変換、入力を統合的に扱う。
一方のAnyPS5は、実行ファイルを変換し、ホストと互換性のある実装へ接続する。ゲストとホストがCPUアーキテクチャを共有していれば層を減らせる可能性はあるが、コンソールの動作を再現する必要がなくなるわけではない。
ネイティブ方式には、性能面で魅力的な仮説がある。元のx86-64コードを直接実行できれば、異なる命令セットを用いるコンソールに伴う重いCPU変換をホスト側で避けられる。
ただし、その利点が自動的に高性能につながるわけではない。グラフィックス変換、システムコール処理、同期、互換性修正には依然としてリソースが必要となる。正確性の確保には、速度を落とす保守的な経路が求められる場合もある。
従来型エミュレーションは、より強い分離と集中管理を提供できる可能性がある。エミュレーターは管理されたランタイム内で動作を傍受できるため、ログ取得、状態管理、プラットフォーム抽象化を簡潔にできることがある。
変換されたネイティブプロセスはホスト実行環境へ直接アクセスできる一方で、ホストOSのアプリケーションモデルと共存しなければならない。実行ファイル形式、呼び出し規約、例外処理、動的リンクの違いは、即座にエンジニアリング上の課題となる。
SharpEmuは、PS5のx86-64 CPUという利点を活かしながらエミュレーター方式を採るため、有用な比較対象となる。2026年9月、同プロジェクトの開発者は、テストした55タイトルのうち12タイトルがゲームプレイに到達し、6タイトルが毎秒60フレームで動作したと報告した。
この6タイトルのすべてが、最初から最後までテストされたわけではない。互換性に関する更新で引用されたプロジェクト情報によれば、「プレイ可能」というラベルは軽微なグラフィックスまたはオーディオの問題を含み得る。
Kytyも別のエミュレーター実装を進め、より要求の高いソフトウェアで目に見える成果を示してきた。しかし、公開デモ、フレームレートの数値、短いゲームプレイ映像だけで完全な互換性が証明されるわけではない。
これらのプロジェクトは、単一サブシステムの割合よりも、タイトル単位の証拠が重要である理由を示している。互換性リストは、実際のワークロードにおいてスタック全体がどう振る舞うかを記録する。
AnyPS5は現時点で、Dreaming Sarahを検証済みゲームとして挙げている。プロジェクトのドキュメントによると、この2DプラットフォーマーはGeForce GTX 1050 TiとIntel Core i5-7500上で安定した毎秒60フレームで動作する。
これは、そのアーキテクチャが少なくとも1本のゲームを変換、リンク、グラフィックス変換、入力、実行まで通せることを示す意味のある証拠だ。ただし、同じ経路が複雑なファーストパーティ作品へそのまま拡張できる証拠ではない。
コミュニティによる一部の実験では、Dead Cellsを含む他タイトルのネイティブ変換も報告されている。こうしたデモは動作する経路を明らかにし得るが、必要なパッチ、不足機能、再現性については、それぞれ慎重に評価する必要がある。
したがって、最も有益な比較はプロジェクト間の順位表ではない。互換性の失敗を発見し、解決する手法同士の比較である。
エミュレーターはランタイム境界を維持しながら、より広範なゲームプレイ互換性を示せる可能性がある。AnyPS5は、静的変換とネイティブなホスト実行が、互換性のあるワークロードに対してよりクリーンな長期的経路を提供するかを検証できる。
どちらの方式も、同じ厳しい基準に直面する。プレイヤーにとって重要なのは、ゲームが起動し、正しく描画され、入力を受け付け、進行状況を保存し、性能を維持し、最初から最後まで動作するかどうかだ。
アーキテクチャの呼称が、そうした結果の代わりになることはない。
100%のカバレッジでも保証されないこと
AnyPS5は測定可能な1層を完了したが、残る不確実性は、まさに実際のゲームのサポートが難しくなる部分にある。
最初の不確実性はシェーダーのセマンティクスに関するものだ。公開カバレッジはデコーダが追跡対象のすべての命令を認識することを示すが、完全なSPIR-V変換を備える命令がどれだけあるかは示していない。
また、代表的な入力に対して、PS5ハードウェアと比較された変換がどれだけあるのかも明らかにしていない。公開ドキュメントで挙動が曖昧な場合、ハードウェアテストは重要になる。
2つ目の不確実性は組み合わせにある。個々の命令は集中的なテストを通過できても、より長いシェーダーでは制御フロー、精度、メモリアクセス、サブグループ操作に関する相互作用が露わになる可能性がある。
シェーダープログラムはグラフィックスパイプラインから供給されるリソースにも依存する。画像、バッファー、サンプラー、レンダーターゲットが誤って記述されていれば、正しい演算でも補えない。
3つ目の不確実性は、追跡対象の宇宙そのものに関わる。1,166という数字はAnyPS5が維持している命令リストを表す。将来のテストで、現在のトラッカーでは捉えられていない文書化されていないバリアント、エンコーディング、挙動が判明する可能性がある。
その可能性は割合の妥当性を否定するものではない。これは、この割合がPS5 GPUのあらゆる動作に関する不変の仕様ではなく、バージョン管理されたエンジニアリング上の範囲を表すことを意味する。
システムライブラリも同様に変化する対象だ。プロジェクトは10月9日時点のスナップショットで3,038の宣言済み関数を数え、そのうち2,575を実装済みとしている。
別のゲームがこれまで未確認だったインターフェースをインポートすると、データベースにさらに多くの関数が加わる可能性がある。コードベースが改善していても、分母の増加によって表示上の割合は下がり得る。
関数数は実装の深さも隠してしまう。単純なラッパーも複雑なステートフルサービスも1行として数えられるが、その実装コストは大きく異なる。
正確なメディア再生、ネットワーク、アカウントサービス、ストレージ動作、グラフィックス送信には、永続的な状態と正確なエラー処理が求められる場合がある。これらを常に戻り値だけへ還元できるとは限らない。
4つ目の不確実性は、法的かつ実務的なアクセスに関するものだ。AnyPS5は、著作権で保護されたゲーム、ファームウェア、暗号鍵、プロプライエタリライブラリを配布しないとしている。
そのドキュメントでは、バイナリを適法に取得し、関連するライセンス条件に従う責任をユーザーに委ねている。この境界は、商用ソフトウェアを扱う保存および相互運用性プロジェクトにとって不可欠だ。
このツールはPS5ゲームの代替ストアではない。ユーザーは、テストするソフトウェアへの正当なアクセスに加え、互換ファイルを取得するために必要な技術的手順にも対応する必要がある。
5つ目の不確実性は保守にある。ゲーム、ドライバー、ホストOSは大規模なテストマトリクスを生む。あるGPUで動作する変換が、別の環境では異なる問題を露呈させる可能性がある。
AnyPS5は複数システムを対象にVulkanを使用しているが、WindowsとLinuxでは依然として実行ファイルのロード、ライブラリ、ドライバー、ファイルシステム動作、デバッグツールが異なる。
プロジェクトのリリース履歴にはすでに、シェーダー、ネットワーク、メディア再生、ライブラリ、ビルド検証、再リンクにまたがる作業が示されている。この広がりは、問題がGPUデコーディングをどれほど超えているかを物語っている。
同時に、急速なコミット活動を完成した互換性と混同すべきではない理由も示す。若いプロジェクトは急速に変化し得る一方で、実験段階にとどまり、一般的なプレイヤーには適さない場合がある。
ユーザーは、軽量なタイトルから将来の大作へと外挿することにも慎重であるべきだ。小規模な2Dゲームは、最も要求の高い描画およびシステム経路を実行せずに、アーキテクチャを検証できる。
大規模なゲームは、あらゆる弱点を増幅する。より多くのモジュール、より多くのグラフィックス機能、より大きなリソースセット、より厳しいタイミング、そして長年のコンソール最適化を通じて築かれたエンジン固有の前提を利用する。
したがって、技術的に正確な要約は、この節目の両面を保たなければならない。AnyPS5は、シェーダーデコーダーから現在追跡されている未知要素をすべて取り除いた。これは価値ある基盤作業だ。
しかし、完全なシェーダー変換、完全なGPU同等性、幅広いシステムライブラリ互換性、あるいはPS5カタログへの信頼できる対応を確立したわけではない。
AnyPS5が隔たりを縮めているかを示す3つのシグナル
次に意味のある証拠は、セマンティックテスト、再現可能なゲーム互換性、そしてより広範なワークロードに耐えるシステムライブラリの分母から得られる。
第1のシグナルは、検証済みの命令動作だ。コントリビューターには、デコードされた操作が正しいSPIR-Vへ変換され、期待されるハードウェア出力と一致することを示すテストが必要となる。
プロジェクトの貢献ルールはすでにこの方向性を示している。シェーダーの変更には、正確な技術資料または実機からの測定値を引用しなければならず、結論の出ていないケースは明示的な技術的負債として残される。
より大規模な自動化セマンティックテスト群は、100%という数値を強化するだろう。それにより、トラッカーは認識マップから、変換済み動作に関する証拠へと変わる。
最も有用な報告では、少なくともデコード済み、変換済み、ハードウェア検証済みの3状態を分けるべきだ。この内訳により、実装の深さが広がりに追いついているかを観測者が確認できる。
変換済みと検証済みの数が速やかに増加すれば、この節目は焦点を絞った正確性フェーズの始まりと見なせるだろう。認識だけが唯一完成した層にとどまるなら、見出しの背後にある隔たりは残る。
第2のシグナルは、再現可能な互換性リストだ。より多くのゲームが、ハードウェア、OS、設定、既知の不具合、テストの深さを文書化した公開ビルド上で動作する必要がある。
タイトルの起動は、メニュー到達、ゲームプレイへの移行、目標フレームレートでの動作、ゲーム完走とは明確に区別されるべきだ。これらの状態をまとめてしまえば、明らかになる以上の情報を隠すことになる。
有用なエントリーは、外部パッチや手作業の手順も示すべきだ。別のユーザーが非公開コードや文書化されていない改変なしに結果を再現できる場合、ネイティブ変換の説得力は大きく増す。
検証済みの軽量ゲーム1本から、複数の独立したタイトルへ進展すれば、アーキテクチャが一般化することを示せる。要求の高い3Dタイトルへの対応は、はるかに強力なストレステストとなる。
第3のシグナルは、発見済みシステム関数と実装済みシステム関数の関係だ。報告された84.76%は有望に見えるが、その価値は分母の安定性に依存する。
さらに多くのゲームをテストして追加関数が多数見つかれば、生の割合は下がる可能性がある。それは後退ではなく、プラットフォームに関する知識の向上を表す。
重要なのは、新たに発見された関数が正確に実装され、実際のソフトウェアの障害を取り除くかどうかだ。インターフェースマップの拡大に伴い、タイトル単位の結果も改善すべきである。
観測者は、失敗が実行のより深い段階へ移るかも注視すべきだ。ゲームが起動エラーからメニュー、ゲームプレイ、より長いセッションへと進展すれば、プレイ可能と認められる前であっても、意味のある進歩を示し得る。
AnyPS5のシェーダーカバレッジが注目に値するのは、即時の失敗につながる広範な1分類を取り除いたためだ。追跡対象のすべての命令は、未知の入力として停止することなく、デコーダーに入れるようになった。
より困難な段階は、その認識の後に始まる。開発者は、変換済みシェーダーが正しく動作し、代替ライブラリが期待されるサービスを再現し、変換済みゲームが完全なワークロード下でも安定していることを示さなければならない。
開発者、保存研究者、そして技術的な好奇心を持つプレイヤーにとって、最善の問いはもはやトラッカーが100%に到達できるかではない。それはすでに達成されている。
問題は、これら1,166件の命令のうち、隠れたパッチなしで異なるPC環境の実際のゲーム内におけるセマンティックテストを通過できるものが何％あるかだ。検証済みの互換性リストと、実機ハードウェアに基づくシェーダーテストに注目したい。これらの結果が、AnyPS5の節目がPC上でのネイティブPS5ゲームの基盤となるのか、それとも印象的なデコーダー統計にとどまるのかを左右する。
