PlayerPrefsは商用ゲームでも使って大丈夫ですか？

はい、設定保存用途であれば問題ありません。音量・解像度・ON/OFF設定などの軽量データは、 PlayerPrefsが最も手軽で安定した選択肢です。ただし、セーブデータ本体や改ざん対策が必要な情報には向いていないため、用途を限定して使うのがポイントです。

Unityで設定画面（Options）を作る完全ガイド｜音量・解像度・フルスクリーン・キー設定を実装

Q: 設定変更はリアルタイム反映とApply方式、どちらが正解ですか？

設定項目によって使い分けるのが正解です。 音量 ：リアルタイム反映（Slider操作と同時） 解像度・フルスクリーン ：Apply方式 特に解像度や表示モードは、即時反映すると画面が見えなくなるリスクがあるため、 Applyボタンでまとめて反映する設計が推奨されます。

Q: PlayerPrefsは商用ゲームでも使って大丈夫ですか？

はい、 設定保存用途であれば問題ありません 。 音量・解像度・ON/OFF設定などの軽量データは、 PlayerPrefsが最も手軽で安定した選択肢です。 ただし、セーブデータ本体や改ざん対策が必要な情報には向いていないため、 用途を限定して使うのがポイントです。

Q: 新Input Systemを使っている場合も、この記事の考え方は使えますか？

使えます。むしろ ラッパー関数を用意する設計 は、新Input Systemと相性が良いです。 入力処理を直接ゲームロジックに書かず、 アクション名で問い合わせる 内部でInput SystemやKey割り当てを処理する という構成にしておくと、キーボード・ゲームパッド・将来の拡張にも対応しやすくなります。

ゲームにおける設定画面（Options）は、ただの付属機能ではありません。
音量がうるさすぎる、画面が合わない、フルスクリーンにできない──
こうした“小さな不満”が積み重なると、どんなに面白いゲームでも、プレイヤーは静かに離れていってしまいます。

特にPC向けのUnityゲームでは、解像度・フルスクリーン・音量・キー設定といった項目は、
「あって当たり前」の存在です。
逆に言えば、設定画面がしっかり作られているだけで、ゲーム全体の完成度や信頼感は一段上がります。

とはいえ、実際に作ろうとすると──
UIの用意、Screenクラスの制御、AudioMixerの設定、保存処理……
思っている以上に手間がかかるのも事実です。

そこでこの記事では、Unityで実用レベルの設定画面（Options）を実装するための考え方と手順を、
初心者の方にも分かりやすく、かつ中・上級者の方にも役立つ形でまとめました。

具体的には、次のような内容を扱います。

UXを損なわない設定画面の設計ポイント
音量・解像度・フルスクリーン・VSyncの実装方法
AudioMixerを使った本格的な音量管理
設定内容を保存・復元する仕組み
「全部自作すべきか？」という現実的な判断基準

「とりあえず動く」設定画面ではなく、
プレイヤーにとって気持ちよく使えるOptions画面を作りたい方は、ぜひ最後まで読んでみてくださいね😊

Unityで設定画面（Options）が重要な理由
1. 最低限そろえておきたい設定項目
2. UXを悪化させやすい設定画面の落とし穴
Unityで設定画面（Options）を実装する全体構成
フルスクリーンとVSyncの設定を実装する
解像度設定を実装する（左右ボタン＋Apply方式）
音量設定を実装する（シンプル版 → AudioMixer版）
設定を保存・復元する（PlayerPrefsで永続化）
キーコンフィグ（キー設定）を実装する考え方（破綻しない設計）
設定画面を全部自作する前に知っておきたい現実的な選択肢
ビルド時のデフォルト設定を見直す（Player Settings）
まとめ｜Unityの設定画面（Options）実装で押さえるべきポイント
よくある質問（FAQ）
1. 関連記事:

Unityで設定画面（Options）が重要な理由

Unityでゲームを作っていると、キャラクター操作や演出、バトルシステムなどに目が行きがちですが、
設定画面（Options）はプレイヤー体験を支える「土台」のような存在です。

特にPCゲームでは、プレイヤーごとに環境が大きく異なります。

モニターの解像度やサイズが違う
フルスクリーン派・ウィンドウ派が分かれる
ヘッドホン・スピーカーなど音響環境が違う
キーボード配列や操作の好みが違う

この差を吸収する役割を担うのが、設定画面です。
設定項目が不足しているだけで、「このゲーム、ちょっと不親切だな…」と感じさせてしまうこともあります。

最低限そろえておきたい設定項目

ジャンルを問わず、多くのUnityゲームで共通して求められる設定項目は次のとおりです。

音量設定（マスター / BGM / SE）
解像度設定
フルスクリーン / ウィンドウ切り替え
VSync（垂直同期）のON / OFF
キーコンフィグ（キー設定）

これらは「こだわり要素」ではなく、
あることが前提として扱われる項目です。

特に音量と解像度は、ゲーム起動直後に触られることが多く、
ここでストレスを感じさせてしまうと、そのままプレイをやめられてしまう可能性もあります。

UXを悪化させやすい設定画面の落とし穴

設定画面を作るときに、やってしまいがちな失敗もあります。

トグルを切り替えた瞬間に解像度が変わる
フルスクリーン変更で画面が一時的に見えなくなる
設定を閉じると内容が保存されていない

特に解像度やフルスクリーン設定は、
即時反映するとプレイヤーが操作不能になるリスクがあります。

そのため、多くのゲームでは

UI上では一時的に選択状態にする
「変更を適用（Apply）」ボタンを押した時だけ反映する

という方式が採用されています。
この「ワンクッション」があるだけで、設定画面の安心感は大きく変わります。

次の章では、こうした前提を踏まえたうえで、
Unityで設定画面を実装する全体構成を整理していきます。

Unityで設定画面（Options）を実装する全体構成

ここからは、Unityで設定画面を作るときに
「どんな構成で考えると破綻しにくいか」を整理していきます。

いきなりコードを書き始めるよりも、
先に全体の役割分担を理解しておくと、後からの修正がかなり楽になります。

設定画面は「UI・処理・保存」の3つで考える

Unityの設定画面は、大きく分けると次の3要素で構成されます。

UI：Toggle / Slider / Button などの見た目と操作部分
処理：Screen・QualitySettings・AudioMixerなどへの反映
保存：PlayerPrefsなどを使った設定値の永続化

この3つをごちゃ混ぜにしないことが、設定画面を安定させる最大のポイントです。

特にありがちなのが、

UIのイベント内で直接すべての処理を書く
保存と適用のタイミングが混在する

という構成です。
最初は動いても、設定項目が増えた瞬間に管理できなくなります。

「選択中の値」と「適用中の値」を分ける

設定画面では、今UIで選ばれている値と、
実際にゲームに反映されている値を分けて考える必要があります。

例えば解像度設定の場合、

左右ボタンで解像度を切り替える（選択中）
Applyボタンを押すまで画面には反映しない（未適用）

という状態が存在します。

このとき、

選択中の値 → 変数で保持
適用時 → Screen.SetResolution を実行

という流れを意識すると、UXを壊さずに実装できます。

設定画面を開いたときの初期化が重要

設定画面を開いた瞬間に、
現在の設定とUIの表示がズレていると、それだけで不信感を与えてしまいます。

そのため、設定画面では必ず次の初期化処理を行います。

現在のフルスクリーン状態をToggleに反映
VSyncの有無をToggleに反映
現在の解像度に対応するインデックスを選択
保存済みの音量をSliderに反映

「設定を開いたら、今の状態がそのまま見える」
この当たり前を守ることが、使いやすいOptions画面につながります。

Applyボタンを中心に設計する

設定画面の処理は、
すべて「変更を適用（Apply）」ボタンを起点に考えると整理しやすくなります。

UI操作 → 一時変数を変更
Apply押下 → 画面・音量・品質設定に反映
同時にPlayerPrefsへ保存

この流れを守ることで、

誤操作による事故を防げる
設定の保存漏れが起きにくい
後から項目を追加しやすい

といったメリットがあります。

次の章では、まずフルスクリーンとVSyncを例に、
Unityでの具体的な実装方法を見ていきましょう。

フルスクリーンとVSyncの設定を実装する

まずは設定画面の中でも実装しやすく、
かつ効果が分かりやすい項目である「フルスクリーン」と「VSync」から作っていきましょう。

この2つは、Unity標準のクラスだけで制御できるため、
Options実装の入り口としてとても向いています。

使用するUnityのクラスとUIコンポーネント

今回使用する主な要素は次のとおりです。

UI Toggle：ON / OFF の切り替え
Button：変更を適用（Apply）
Screen クラス：画面表示の制御
QualitySettings クラス：品質・VSync設定

Toggleは「今どうしたいか」を表し、
実際の反映はApplyボタンで行う、という役割分担を意識します。

フルスクリーン設定の基本

フルスクリーンの切り替えは、
Screen.fullScreen を使って制御できます。

考え方はとてもシンプルで、

ToggleがON → フルスクリーンにしたい
ToggleがOFF → ウィンドウ表示にしたい

という状態を、Apply時に反映させるだけです。

起動時・表示時の初期化

設定画面を開いたときは、
現在の画面状態をそのままToggleに反映させます。

例えば、フルスクリーン用Toggle（fullscreenToggle）がある場合、

Screen.fullScreen が true → ToggleをON
false → ToggleをOFF

という関係になります。

これを忘れると、
「チェックは入っているのに画面はウィンドウ」といった違和感が生まれてしまいます。

VSync（垂直同期）の設定

VSyncは、
フレームレートとモニターの同期を制御する設定です。

Unityでは、QualitySettings.vSyncCount を使って設定します。

VSync ON → QualitySettings.vSyncCount = 1
VSync OFF → QualitySettings.vSyncCount = 0

こちらもToggleと非常に相性が良い項目です。

VSyncの初期状態をToggleに反映する

VSyncの場合は少しだけ注意が必要です。

QualitySettings.vSyncCount は数値なので、

0 → OFF
1以上 → ON

というルールでToggleに反映します。

これにより、現在の品質設定とUIの表示を正しく同期できます。

Applyボタンでまとめて反映する

フルスクリーンとVSyncは、
Applyボタンを押したタイミングでまとめて反映するのがおすすめです。

Applyボタンの処理では、

フルスクリーンToggleの状態を取得
Screen.fullScreen に反映
VSync Toggleの状態を取得
QualitySettings.vSyncCount を設定

という流れになります。

こうしておくことで、

誤操作による画面トラブルを防げる
複数設定を一度に適用できる
保存処理とまとめやすい

といったメリットがあります。

次の章では、
解像度設定を例に、もう一段階踏み込んだOptions実装を見ていきましょう。

解像度設定を実装する（左右ボタン＋Apply方式）

次は、設定画面の中でも「実装の難易度が少し上がる」
解像度（Resolution）に挑戦していきます。

解像度はプレイヤーの環境によって最適解が変わるため、
Optionsで調整できるようにしておくとUXが一気に上がります。

解像度設定で押さえるべき考え方

解像度設定は、フルスクリーンToggleと違って
「候補の中から選ぶ」タイプの設定です。

そのため、実装では次の2つを管理する必要があります。

解像度の候補リスト（例：1920×1080 / 1280×720 など）
現在選択している候補のインデックス（selectedRes）

そして重要なのが、前の章と同じく
選択した瞬間に反映しない（Apply方式）という点です。

解像度情報を管理する方法（インスペクターで編集できる形）

解像度の候補は、Unityのインスペクターで編集できるようにしておくと便利です。
そのために、幅と高さを持つシンプルなクラスを用意します。

ポイントは次の2つです。

[System.Serializable] を付ける（インスペクター表示のため）
MonoBehaviourを継承しない（ただのデータとして扱う）

こうしておけば、設定スクリプト側で

解像度配列（resolutions）をpublicで持つ
インスペクターで候補解像度を追加できる

という運用ができます。

UI：左右ボタンで解像度を切り替える

解像度のUIは、よくある形として

左ボタン（<）
解像度表示テキスト（例：1920 x 1080）
右ボタン（>）

の構成が分かりやすいです。

左右ボタンが押されたら、selectedRes を増減し、
そのたびに表示テキストを更新します。

インデックスの範囲チェックが重要

ここでミスりやすいのが、インデックスの範囲外アクセスです。

左に行きすぎて -1 になる
右に行きすぎて配列の長さを超える

そのため、左右ボタンでは必ず

0未満にならない
resolutions.Length – 1 を超えない

という制限を入れておきます。
この1行があるだけで、解像度周りのエラーが激減します。

起動時（または設定画面を開いたとき）の初期化

設定画面を開いた瞬間に、
現在の解像度がUIに反映されている状態にしたいですよね。

そこで、起動時や表示時に

resolutions配列をループ
Screen.width / Screen.height と一致する要素を探す
一致したインデックスを selectedRes に入れる
表示テキストを更新する

という初期化を行います。

もし一致する候補が見つからない場合は、
「一番近い解像度」や「デフォルト候補」に寄せる、という設計にしておくと安心です。

Applyで解像度を反映する（Screen.SetResolution）

選択した解像度を反映するときは、
Screen.SetResolution(width, height, isFullscreen) を使います。

ここで大事なのが、第3引数の isFullscreen です。

解像度を変えるタイミングで、フルスクリーン状態も一緒に指定できるので、
Apply時には

選択中の解像度（selectedRes）から width / height を取得
fullscreenToggle.isOn を第3引数に渡す

という形にしておくと整合性が取れます。

ここまでで、画面設定の中心である

フルスクリーン
VSync
解像度

が「Apply方式」で実装できる形になります。

次は、プレイヤーが最も触ることが多い音量設定です。
まずは簡単な方法から入り、AudioMixerを使った本格管理まで一気に解説していきます。

音量設定を実装する（シンプル版 → AudioMixer版）

設定画面で一番触られやすいのが、実は音量です。
ゲーム起動直後に「うるっ…！」となった瞬間、プレイヤーは反射的に音量を探します😇

ここでサクッと調整できるだけで、体験の快適さがかなり変わります。

方法1：とにかく簡単に作る（AudioListener.volume）

まず、ゲーム全体のマスターボリュームだけ調整できればOK、という場合は
AudioListener.volume を使うのが最短です。

実装イメージは次のとおりです。

UIにSlider（0〜1）を用意
Sliderの値を AudioListener.volume に代入
値を PlayerPrefs に保存して次回起動時に復元

「まずは動く設定画面が欲しい！」という段階なら、この方式でも十分役に立ちます。

保存・復元のポイント（PlayerPrefs）

音量は、設定画面を閉じたら元に戻ってしまうとガッカリされがちです。
なので、少なくとも

Apply時（またはスライダー変更時）に保存
起動時（または設定画面を開いた時）に復元してSliderに反映

の流れは用意しておくのがおすすめです。

方法2：BGM/SEを分けて管理する（AudioMixer）

次に、本格的にやるならAudioMixerです。
BGMとSEを分けて音量調整できるようにしたい場合、ほぼ必須になります。

AudioMixer方式のメリットは大きく、

BGM/SE/環境音などを別々に調整できる
音の演出（フィルター、ダッキングなど）も組み込みやすい
後から項目を増やしても破綻しにくい

という「設定画面の拡張性」が手に入ります。

AudioMixer実装のざっくり手順

AudioMixerを使った音量設定は、流れをつかめば怖くありません。
手順はだいたい次の順番です。

プロジェクトでAudio Mixerアセットを作成
Masterの下に BGM / SE などのグループを作る
各AudioSourceのOutputを対応するグループに設定
BGM/SEグループのVolumeをExpose Parameterする
スクリプトから AudioMixer.SetFloat() で音量を反映

ここまでできれば、設定画面からBGMとSEを別々に操作できます。

スライダー値（0〜1）をdBに変換する理由

AudioMixerのVolumeは、基本的にdB（デシベル）で制御します。
理由はシンプルで、人の耳は音の変化を線形ではなく対数的に感じるからです。

そのため、スライダーの値（0〜1）をdBに変換するのが一般的です。

変換例：20 * Mathf.Log10(value)
無音側は -80dB 付近まで落とす（実質ミュート）

この変換を入れると、「音量が自然に変わる」感覚になります。

サウンドダッキング（Ducking）もAudioMixerでできる

ちょっと上級編ですが、AudioMixerではダッキングも設定できます。
例えば

SEが鳴った瞬間だけBGMを少し下げる

といった演出が可能です。
地味ですが、これがあるとゲームの“プロっぽさ”が上がります。

音管理をもっと楽にしたい人向け（1回だけ紹介）

AudioMixer方式は強力ですが、運用が増えるほど管理も大変になります。
「音の管理をまとめてラクにしたい」「スクリプト増やしたくない…」という場合は、専用アセットを使うのも手です。

Audio Manager Pro
✅ Asset Storeでチェックする

次の章では、ここまで作った設定を保存・復元（PlayerPrefs）して、
「起動したら前回の設定が反映されている」状態まで仕上げていきます。

設定を保存・復元する（PlayerPrefsで永続化）

ここまでで、音量・解像度・フルスクリーン・VSyncといった設定項目は実装できました。
でも、もしゲームを再起動したら設定が初期化されてしまったら……ちょっと悲しいですよね🥲

そこで次は、設定内容を保存して、次回起動時に復元する仕組みを作ります。
小〜中規模のゲームなら、まずは PlayerPrefs で十分実用になります。

PlayerPrefsでできること（できないこと）

PlayerPrefsは、Unityに標準で用意されている「簡易セーブ領域」です。
数値や文字列をキー（名前）で保存でき、Windows/MacなどのPCでも問題なく動きます。

保存できる：int / float / string
向いている：音量、解像度インデックス、ON/OFF設定など
向いていない：大量データ、暗号化が必要なデータ、複雑な構造

今回のOptions用途は、まさにPlayerPrefsの得意分野です。

保存の基本方針：Apply時にまとめて保存する

おすすめは、「変更を適用（Apply）」ボタンを押したタイミングで
反映と保存をセットで行う設計です。

こうしておくと、

UIで選んだだけの「未適用」状態を誤って保存しない
保存漏れが起きにくい
処理の流れが読みやすい

というメリットがあります。

保存するキー設計（例）

PlayerPrefsは「キー名」が命なので、
最初にルールを決めておくと後から混乱しません。

例として、こんなキー設計が使いやすいです。

音量（マスター）：opt_volume_master
BGM音量：opt_volume_bgm
SE音量：opt_volume_se
フルスクリーン：opt_fullscreen（0/1）
VSync：opt_vsync（0/1）
解像度：opt_resolution_index（候補配列のindex）

「opt_」のように接頭辞を付けると、他の保存データと衝突しにくくなります。

復元の基本方針：起動時（または設定画面表示時）にUIへ反映

保存ができたら、次は復元です。
復元で大事なのは、値を読み込むだけで終わらせないこと。

プレイヤーが設定画面を開いたときに、

Toggleが現在の設定を正しく表示している
Sliderが保存した音量になっている
解像度表示が前回の選択に一致している

という状態にして、初めて「設定が生きてる」感が出ます。

GetXXXのデフォルト値を必ず用意する

初回起動では、PlayerPrefsに値が入っていません。
そのため、GetInt や GetFloat にはデフォルト値を入れます。

音量：1.0（最大）
フルスクリーン：端末や方針に合わせて 0 or 1
VSync：パフォーマンス方針に合わせて
解像度：0（候補配列の先頭）など

これを決めておくと、初期状態の挙動が安定します。

「リセット（初期化）」ボタンを用意すると親切

設定画面には、できれば初期化（Reset）も付けておくと安心です。

音量が変になった
解像度をミスって見づらくなった
いろいろ触って戻したい

こういうときに、ワンボタンで戻せるとUXが上がります。

実装としては、

UIをデフォルト値に戻す
Applyを呼ぶ（反映）
PlayerPrefsもデフォルトで上書き保存

までセットにすると、ズレが起きにくいです。

これで、Options画面は「変更できる」だけでなく、
次回起動でも維持される実用レベルになります。

次の章では、設定画面の中でも一番沼りやすいキーコンフィグ（キー設定）について、
破綻しにくい設計方針から整理していきます。

キーコンフィグ（キー設定）を実装する考え方（破綻しない設計）

設定画面の中でも、いちばん「作る前は簡単そうに見えて、作り始めると沼」なのが
キーコンフィグ（キー設定）です。

音量や解像度は「値を変えるだけ」ですが、キー設定は

入力の競合（同じキーが2つに割り当たる）
待機状態（次に押したキーを割り当てたい）
保存と復元
入力方式の差（旧Input / 新Input System / ゲームパッド）

など、扱う要素が一気に増えます。
なので、ここは「方針（設計）→ 実装」の順で考えるのがおすすめです。

Input.GetKeyの直書きは後で詰む

例えば、移動を

Input.GetKey(KeyCode.W)
Input.GetKey(KeyCode.A)

のようにゲーム全体へ直書きしてしまうと、
キー設定を変更した瞬間に書き換え箇所が爆発します。

なので、キーコンフィグをやるなら大前提として

「ゲーム側はKeyCodeを直接参照しない」

というルールを作るのが安全です。

ラッパー関数（入力の窓口）を作る

おすすめは、入力判定をまとめる「窓口」を用意する方法です。
例えば考え方としては、

ゲーム側：MoveForwardが押されてる？ を聞く
入力側：MoveForwardに割り当てられたキーのどれかが押されたか判定する

という役割分担です。

具体的には、

「アクション名」→「割り当てキー（KeyCode）」を管理する
ゲーム側は GetKey("MoveForward") のように問い合わせる

という設計にすると、キー変更の影響範囲を最小化できます。

「List<KeyCode>」で複数割り当てを許可すると強い

キー設定は、ひとつの操作に対して

キーボードの複数キー
ゲームパッドのボタン

など、複数割り当てしたくなるケースがよくあります。

そこで、1操作につき1キーではなく、
1操作につき複数キー（リスト）を持つ設計にしておくと拡張が楽です。

そしてラッパー関数側で

リスト内のKeyCodeを順番にチェック
どれかが押されていればtrue

という形にします。

この設計にすると、将来的に

キーボード＋ゲームパッド併用
左右利きに合わせたプリセット

などにも対応しやすくなります。

キー割り当てUIの基本（待機 → 取得 → 反映）

キーコンフィグUIは、基本的に次の状態遷移になります。

変更ボタンを押す（例：「ジャンプ」横の「変更」）
待機状態に入る（「キーを押してください…」表示）
次に押されたキーを取得
割り当てを更新（競合チェックもここで）
表示を更新（ボタン横に新しいキー名を出す）

つまり、キー設定は「入力を読む場所」が通常プレイ時と少し違います。
この待機状態をどう管理するかが、実装の肝になります。

競合（同じキーが他に使われている）をどう扱う？

実用面で必ず出るのが、キーの競合です。
例えば「ジャンプ」をSpaceに変えようとしたら、すでに「決定」がSpaceだった、みたいな状況ですね。

対応方法は主に3つあります。

上書き：既存の割り当てを外して新しい操作へ付け替える
拒否：競合しているので変更できません、と表示して戻す
確認：上書きしますか？とダイアログを出す

UX的には、確認ダイアログ方式が一番親切です。
ただし、実装が面倒なら「拒否」でも最低限成立します。

保存・復元は「KeyCodeをintで保存」するのが手堅い

PlayerPrefsで保存する場合、KeyCodeは列挙型なので
intに変換して保存するのが扱いやすいです。

保存：KeyCode → int → PlayerPrefs
復元：int → KeyCode に戻して割り当て

複数割り当て（List）をする場合は、JSON化するか、キー名を分割して保存するなど工夫が必要になります。
（ここは記事後半で、実装の選択肢として整理すると読者に親切です）

キーコンフィグは、いきなり完璧を目指すと大変なので、
まずは「入力の窓口（ラッパー）」を作ることから始めるのが一番おすすめです。

設定画面を全部自作する前に知っておきたい現実的な選択肢

ここまで読んで、「なるほど、仕組みは分かったけど……」と感じた方も多いと思います。
そう、設定画面（Options）は地味に工数が重いんですよね。

音量、解像度、フルスクリーン、VSync、キー設定、保存処理、UI更新……
一つひとつは難しくなくても、積み上げるとかなりの作業量になります。

設定画面は「完成して当たり前」な機能

設定画面は、プレイヤーからすると

あって当たり前
ちゃんと動いて当たり前
不具合があると一気に評価が下がる

という、わりとシビアな機能です。

しかも、ここに時間をかけても
ゲームの見た目や面白さが直接伸びるわけではありません。

だからこそ、個人開発や小規模チームでは

「自作にこだわらない」
「完成形を使って時間を別に回す」

という判断が、結果的にクオリティを上げることも多いです。

Options画面を一気に完成させたい人向けの選択肢

ここまで解説してきた内容を、
最初から一通りそろった形で使えるアセットも存在します。

UI・処理・保存がセットになっているため、
「設定画面だけで数日溶ける…」という状況を避けたい場合には、かなり有効です。

Settings & Options Menu Creator – Complete Bundle
✅ Asset Storeでチェックする

この手のアセットは、

音量（AudioMixer対応）
解像度・フルスクリーン・VSync
キー設定
設定の保存・復元

といった「まさに今まで解説してきた要素」が、
すでに動く形で用意されているのが強みです。

自作とアセット、どちらを選ぶべき？

迷ったら、次の基準で考えると判断しやすくなります。

学習目的 → 自作（仕組みを理解できる）
個人開発・短期開発 → アセット（完成度と速度を優先）
将来の拡張や独自仕様 → 自作ベース＋部分的にアセット

どちらが正解というより、
「今のプロジェクトで何を優先するか」が大切です。

次の章では、設定画面を作るときに見落としがちな
ビルド時のデフォルト設定（Player Settings）について整理していきます。

ビルド時のデフォルト設定を見直す（Player Settings）

設定画面（Options）をしっかり作っていても、
ビルド時の初期設定がズレていると、プレイヤーに違和感を与えてしまいます。

そこでこの章では、Unityエディター側で設定しておくべき
Player Settings（ビルド時のデフォルト挙動）を整理しておきましょう。

Player Settingsは「初回起動時の体験」を決める

Player Settingsは、ゲームを初めて起動した瞬間の状態を決める場所です。

まだPlayerPrefsに保存データが存在しない状態では、

どの解像度で起動するか
フルスクリーンかウィンドウか
ウィンドウサイズを変更できるか

といった挙動は、すべてここでの設定が基準になります。

設定場所：Resolution and Presentation

Player Settingsは、次の場所から開けます。

Edit → Project Settings
Player → Resolution and Presentation

PC（Windows / macOS）向けゲームでは、
この項目がOptions画面の挙動と特に密接に関係します。

Fullscreen Modeの選び方

Fullscreen Modeには、いくつか種類があります。

Exclusive Fullscreen
Fullscreen Window（ボーダーレス）
Maximized Window
Windowed

それぞれ特徴がありますが、
現在の主流は「Fullscreen Window」です。

理由はシンプルで、

Alt+Tab の切り替えが速い
画面が暗転しにくい
トラブルが少ない

というメリットがあるからです。

Exclusive Fullscreenはパフォーマンス面では有利ですが、
切り替え時の挙動が重く、Windows限定という点には注意が必要です。

Default Screen Width / Height

Windowedモードで起動した場合の、
初期ウィンドウサイズを指定する項目です。

ここは

1280 × 720
1600 × 900
1920 × 1080

など、ゲームのターゲットに合わせて決めておくと安心です。

フルスクリーン前提のゲームでも、
一瞬ウィンドウ表示になるケースがあるため、
極端に小さい値は避けたほうが無難です。

Resizable Window と Allow Fullscreen Switch

この2つは、Options画面との相性がとても重要です。

Resizable Window → ユーザーがウィンドウサイズを変更できるか
Allow Fullscreen Switch → OS標準の全画面切り替え（例：F11）を許可するか

Options画面で

解像度変更
フルスクリーン切り替え

を実装している場合は、
この2つを有効にしておくのが基本です。

逆に、UIが崩れるのを避けたい場合などは、
あえてResizable WindowをOFFにする、という判断もあります。

Supported Aspect Ratios（アスペクト比）

起動時に表示される解像度候補を、
特定のアスペクト比に制限することもできます。

例えば、

16:9のみ対応
16:10や21:9を許可

といった方針がある場合は、
ここでチェックを整理しておくと事故が減ります。

Options画面とPlayer Settingsは、
どちらか一方だけ正しくてもダメで、必ずセットで考える必要があります。

まとめ｜Unityの設定画面（Options）実装で押さえるべきポイント

この記事では、Unityで実用レベルの設定画面（Options）を実装するために、
設計の考え方から具体的な実装方針までを順番に整理してきました。

最後に、特に重要なポイントを振り返っておきましょう。

設定画面は「UXを支える基盤機能」

設定画面は、ゲームの面白さを直接押し上げる機能ではありません。
しかし、不便だと確実に評価を下げる、とても影響力の大きい要素です。

音量がすぐ調整できる
解像度や表示モードを自由に変えられる
設定が次回起動でもきちんと反映される

これだけで、ゲーム全体の「丁寧さ」が伝わります。

Apply方式と「選択中 / 適用中」の分離が安定のカギ

解像度やフルスクリーン設定では、
変更した瞬間に反映しない設計がとても重要でした。

UI操作 → 一時的に値を保持
Applyボタン → まとめて反映＆保存

この流れを守ることで、

画面が見えなくなる事故を防げる
保存漏れが起きにくい
設定項目を後から追加しやすい

といったメリットが得られます。

音量・入力・保存は「最初に設計」しておく

音量設定やキーコンフィグは、後から追加しようとすると一気に複雑になります。

音量は AudioMixer を前提に考えるか
入力はラッパー関数経由にするか
保存キーの命名ルールをどうするか

こうした点を最初に軽くでも決めておくだけで、実装の負担はかなり減ります。

自作かアセットかは「目的」で決めていい

設定画面は、自作して学ぶ価値も高いですが、
すべてのプロジェクトで自作が正解とは限りません。

仕組みを理解したい → 自作
短期間で完成させたい → アセット活用
独自仕様が多い → 自作＋部分的にアセット

今のプロジェクトで何を優先したいかを基準に選ぶのが、一番後悔が少ないです。

Player SettingsとOptionsは必ずセットで考える

Unityエディター側のPlayer Settingsは、
初回起動時の体験を大きく左右します。

Options画面を作ったら、

Fullscreen Mode
初期解像度
ウィンドウの挙動

が噛み合っているか、必ず確認しておきましょう。

設定画面は地味ですが、
「ちゃんと作ってあるゲーム」は、それだけで信頼されます。

この記事が、UnityでOptions画面を実装するときの
迷いや手戻りを減らす手助けになればうれしいです。

あとは実際に手を動かしながら、
自分のゲームに合った形へ少しずつ調整していきましょう 😊

あわせて読みたい

設定画面（Options）を実装するうえで、
一緒に読んでおくと理解が深まる関連記事をまとめました。

参考文献・参考リンク

よくある質問（FAQ）

Q 設定変更はリアルタイム反映とApply方式、どちらが正解ですか？

設定項目によって使い分けるのが正解です。

音量：リアルタイム反映（Slider操作と同時）
解像度・フルスクリーン：Apply方式

特に解像度や表示モードは、即時反映すると画面が見えなくなるリスクがあるため、
Applyボタンでまとめて反映する設計が推奨されます。

Q PlayerPrefsは商用ゲームでも使って大丈夫ですか？: A

はい、設定保存用途であれば問題ありません。

音量・解像度・ON/OFF設定などの軽量データは、
PlayerPrefsが最も手軽で安定した選択肢です。

ただし、セーブデータ本体や改ざん対策が必要な情報には向いていないため、
用途を限定して使うのがポイントです。

Q 新Input Systemを使っている場合も、この記事の考え方は使えますか？

使えます。むしろラッパー関数を用意する設計は、新Input Systemと相性が良いです。

入力処理を直接ゲームロジックに書かず、