メインコンテンツへ移動
Hone Research に戻る

Honeがパフォーマンス調整を評価する方法

あらゆる調整がすべてのPCを改善するとは決めつけず、Honeが最適化を調査、テスト、承認する方法を説明します。

  • パフォーマンスベンチマーク
  • フレームペーシングと遅延
  • PC システム最適化
Honeメソッド「機能するものだけ」を、パフォーマンスゲージと採用・不採用の最適化チェックで表現した画像
目次
  1. 要点
  2. 1. 問題から始める
  3. 2. 調整によって何が変わるかを理解する
  4. 3. リスクを見つける
  5. 4. 成功の意味を定義する
  6. 5. 条件をそろえてテストする
  7. 6. 結果とリスクを比較する
  8. 7. 効果がある条件とない条件を定義する
  9. 8. 採用、変更、または不採用にする
  10. 採用
  11. 変更
  12. 不採用
  13. 例:デバイスアフィニティ
  14. Honeが主張しないこと

PC向けの調整には、もっともらしく聞こえることを重視したものが少なくありません。レジストリキーを変更し、Windowsの機能を無効にし、設定を変えれば、すぐに「FPSが上がる」とうたえます。

Honeでは、それだけでは不十分です。

最適化を追加する前に、何が変わるのか、なぜ効果が見込めるのか、どのようにテストできるのかを理解する必要があります。これらの問いに答えられないものは公開しません。

要点

Honeのすべての最適化には、次の条件が必要です。

  • 解決すべき実在の問題
  • 何を変更するかについての明確な説明
  • 測定可能な目標
  • 既知のリスク
  • 安全に元へ戻す方法
  • 変更を正当化できる十分な証拠
  • 効果が見込まれるシステムの明確な定義

調整がすべてのPCに効果をもたらす必要はありません。ただし、筋が通っており、解決する問題より大きな問題を生まないことが必要です。

小さい画面では図にフォーカスし、矢印キーまたはスワイプで横方向に移動できます。

Honeの最適化が公開前に満たすべき7つの条件を示す評価表。
調整は実在の問題を解決し、7つの条件をすべて満たして初めてテストの対象になります。

1. 問題から始める

まず、プレイヤーが気づく可能性のある一般的な問題から始めます。たとえば次のようなものです。

  • バックグラウンド処理によるカクつき
  • 不安定なフレームタイム
  • 高い入力遅延
  • 一時停止を引き起こすディスク処理
  • 回線負荷が高いときのネットワーク遅延
  • CPUやメモリをゲームと奪い合うアプリ

問題を説明できなければ、その調整は自動的に不採用となります。

「この設定が存在する」ことは、変更する理由にはなりません。「この設定が、ゲーム中の遅延を引き起こしている可能性のある動作を制御している」のであれば、調査する価値があります。

2. 調整によって何が変わるかを理解する

すべての最適化には、直接的な説明が必要です。

次の問いに答えられなければなりません。

  • Windowsのどの部分に影響するか?
  • 適用後にどの動作が変わるか?
  • その変化がゲームに影響し得るのはなぜか?
  • どのようなシステムで効果が見込まれるか?

デバイスアフィニティの調整を例に挙げます。これは、一部のハードウェア処理をCPUコアに割り当てる方法を変更するものです。システムによっては、処理を移すことでリソース競合と遅延を減らせます。

これは、調整が必ず効果をもたらすことの証明ではありません。ただし、テストできる仕組みは明らかになります。

仕組みを説明できない調整は、推測として扱います。

3. リスクを見つける

パフォーマンスの向上を探す前に、問題が起こり得る箇所を探します。

変更内容によっては、最適化が次の要素に影響する可能性があります。

  • 安定性
  • フレームの均一性
  • 入力遅延
  • ドライバーと接続デバイス
  • ゲームの起動
  • アンチチートとの互換性
  • 消費電力と温度
  • Windows Update

変更には、制御しやすいものとそうでないものがあります。ゲーム中のバックグラウンド処理を減らす方が、デバイスの低レベルな動作を変更するより簡単に元へ戻せます。

リスクの高い調整を自動的に不採用にするわけではありません。ただし、より強い証拠、狭い適用範囲、確実な復元方法が必要です。

変更を安全に元へ戻せない場合、軽い判断では扱いません。

4. 成功の意味を定義する

すべての最適化が平均FPSの向上を目的としているわけではありません。

カクつきの軽減、フレーム表示の均一化、入力遅延の低下、バックグラウンド処理の削減、ネットワーク性能の安定化を目的とする調整もあります。

主張する効果に合わせてテストを選びます。

  • FPSと滑らかさ: 平均FPS、1% low、0.1% low、フレームタイム、カクつき
  • 遅延: 測定したPC遅延、ドライバーのタイミング、割り込み動作、CPUスケジューリング
  • ストレージ: 読み書きの遅延、応答時間、アセット読み込み時の一時停止
  • ネットワーク: Ping、ジッター、パケットの挙動、バッファブロート

測定方法を誤ると、弱い結果が成功したように見えるため、この選択は重要です。

ネットワークの変更をFPSで判断すべきではありません。平均FPSが変わらなかったという理由で、遅延の改善を否定すべきでもありません。カクつきが悪化したなら、平均FPSの上昇も成功とはいえません。

小さい画面では図にフォーカスし、矢印キーまたはスワイプで横方向に移動できます。

FPSと滑らかさ、遅延、ストレージ、ネットワークの最適化に用いる4つの測定グループ。
測定項目は主張する効果に合わせる必要があります。平均FPSだけですべての最適化を検証することはできません。

5. 条件をそろえてテストする

PCのパフォーマンスにはばらつきがあります。

シェーダーのコンパイル、Windowsのタスク、温度、バックグラウンドアプリ、異なるマップ、サーバーの状態、さらにはテスト中にプレイヤーが見ている方向によっても結果は変わります。

そこで、できる限り多くの条件をそろえます。

  • 同じPCとハードウェア
  • 同じゲーム、マップ、場面、経路、またはリプレイ
  • 同じグラフィック設定
  • 同じバージョンのWindowsとドライバー
  • 同じ電源プラン
  • 同じバックグラウンドアプリ
  • 同じ測定方法とテスト時間
  • 同じFPS上限と同期設定
  • 同じ再起動条件

また、一度にテストする変更は1つだけです。5つの調整を同時に有効にすると、どれが効果をもたらしたのか、どれが問題を引き起こしたのかを判断できません。

1回だけ良い結果が出ても不十分です。

各PCで、調整の適用前に基準テストを3~5回実行します。その後、調整を1回だけ適用し、必要なら再起動して、同じテストを適用後に3~5回実行します。

つまり、各PCでの前後比較には合計6~10回の測定が含まれます。テストを繰り返すことで、通常のばらつきを把握し、シェーダーのコンパイル、キャッシュ、その他の一時的な条件に影響された結果を見分けやすくなります。

結果を比較する前に、基準テスト同士がどの程度ばらついているかを確認します。適用後の結果が通常の基準変動を上回り、その変化が複数回のテストで一貫して現れた場合にのみ、改善と判断します。

適用前後の結果がほぼ同じなら、結論は「測定可能な差はない」となります。

結論を出す前に、すべての調整を同じ手順で検証します。繰り返しテストに耐えない結果を改善とは呼びません。ここが、Honeと多くの最適化ツールとの違いです。

小さい画面では図にフォーカスし、矢印キーまたはスワイプで横方向に移動できます。

3~5回の基準テスト、1回の調整適用、必要に応じた再起動、3~5回の比較テストで構成される管理された前後比較手法。
各PCで合計6~10回を測定し、条件をそろえた基準テストと適用後テストの間では1つの項目だけを変更します。

6. 結果とリスクを比較する

測定可能な改善が、必ずしも公開する価値のあるものとは限りません。

低リスクな変更による小さくても再現可能な向上は役に立つ場合があります。同じ向上でも、クラッシュ、カクつき、デバイスの問題を引き起こし得る変更を正当化できるとは限りません。

結果全体を確認します。

  • 改善の幅はどれほどだったか?
  • 結果は再現したか?
  • フレームタイムの安定性は向上したか?
  • 遅延は改善したか?
  • 別の指標は悪化していないか?
  • システムは安定していたか?
  • 変更を元に戻せるか?
  • 特定のハードウェアやゲームにしか効果がないか?

単に数値が上がったかどうかだけが問題なのではありません。得られる効果が変更に伴う負担を正当化できる必要があります。

7. 効果がある条件とない条件を定義する

多くの最適化には条件があります。

たとえば、次の状況では調整が役立つ可能性があります。

  • ゲームがCPUによって制限されている
  • バックグラウンドアプリがゲームとリソースを奪い合っている
  • システムでドライバー遅延の急増が発生している
  • ストレージ処理が一時停止を引き起こしている
  • CPUが古い、または利用できるリソースが少ない
  • 回線の使用中にネットワーク遅延が増えている

条件があるからといって、その調整が弱いわけではありません。

全員にFPS向上を約束するより、証拠で裏付けられる具体的な主張を選びます。

8. 採用、変更、または不採用にする

すべての最適化は、3つの判断のいずれかに至ります。

採用

次の条件を満たす場合に採用します。

  • 仕組みが明確である
  • 目的の指標が改善する
  • 結果が再現する
  • リスクが正当化される
  • 変更を元に戻せる
  • 使うべき条件がわかっている

「許容できるリスク」は、リスクがないという意味ではありません。起こり得る不利益が限定され、理解され、復旧できるという意味です。

変更

アイデアは妥当でも、実装の準備ができていない場合があります。

1つの指標を改善する一方で、別の指標を悪化させることがあります。特定のハードウェアやゲームだけを対象にする必要があるかもしれません。設定の改善や、より安全な復元方法が必要な場合もあります。

ベンチマークで良い結果が出ても、自動的に公開するわけではありません。

不採用

次の場合は調整を不採用にします。

  • 何を変更するのか説明できない
  • 結果が再現しない
  • 効果が小さすぎて意味がない
  • 不安定化やカクつきを引き起こす
  • 互換性のリスクが高すぎる
  • 安全に元へ戻せない
  • 証拠が主張を裏付けていない

調整を不採用にすることは、常に手順の一部です。証明されていない調整を公開することこそ失敗です。

例:デバイスアフィニティ

この最適化は、この記事で説明した方法と同じ手順でテストしました。同じ構成、シナリオ、設定を使い、調整の適用前に5回、適用後に5回測定しました。結果は、平均パフォーマンスが約177 FPSから182 FPSへ小幅に上昇したことを示しました。平均フレームタイムと測定したPC遅延もわずかに改善しました。

「この調整でFPSが上がる」と早まって主張するのではなく、次のように結論づけました。

このシステムでは、調整によって平均FPSと測定したPC遅延が改善しました。より広い範囲に当てはまると判断するには、さらにテストが必要です。

小さい画面では図にフォーカスし、矢印キーまたはスワイプで横方向に移動できます。

平均FPS、1% low、0.1% low、PC遅延と、肯定的ではあるものの指標によって異なる結論を示すデバイスアフィニティの結果。
この1台のシステムでは、平均FPSと測定したPC遅延が改善し、1% lowはほぼ横ばい、0.1% lowはわずかに低下しました。

Honeが主張しないこと

Honeは、すべての最適化があらゆるPCを改善するとは主張しません。

1つのベンチマークだけでは、異なるゲーム、ハードウェア、ドライバー、Windowsのバージョンで調整が有効だと証明できません。また、性能を上げるためにゲームのメモリ、アンチチートのファイル、その他の機密性の高いゲームファイルを変更することもありません。パフォーマンスは、技術的に聞こえるだけの幅広い主張に頼るべきではありません。

目標は、最も長い調整一覧を作ることではありません。説明でき、テストでき、適切な対象に適用でき、元へ戻せる変更を選びます。

すべてのHone最適化に求める基準はこれです。

引用

Hone Research (2026). Honeがパフォーマンス調整を評価する方法. Hone Research. https://hone.gg/ja/kenkyu/hone-performance-chosei-no-hyoka