Unityのセーブ・データ保存完全ガイド｜PlayerPrefs・JSON・ScriptableObject・Easy Saveを比較

Unityでゲームを作っていると、いつか必ず必要になるのが「セーブ機能」です。

プレイヤーの進行状況を保存したり、音量設定を記録したり、ゲームを再起動しても前回の状態を引き継いだり。どんなジャンルのゲームでも、データ保存は避けて通れません。

ところが、Unityには複数の保存方法があります。

• PlayerPrefs
• JSON
• ScriptableObject
• Easy Save

調べ始めると「PlayerPrefsで十分」「JSONがおすすめ」「ScriptableObjectを使うべき」などさまざまな意見が見つかり、どれを選べばいいのか迷ってしまうことも少なくありません。

特に初めてセーブ機能を実装する場合は、今の選択が将来の作り直しにつながらないか不安になりますよね。

私もUnityを学び始めた頃は、「セーブデータなら全部PlayerPrefsでいいのでは？」と思っていました。しかし実際にゲームを作ってみると、保存するデータの種類によって向いている仕組みが大きく異なることに気づきました。

データ保存は単なる実装テクニックではなく、ゲーム全体の設計にも関わる重要な要素です。

保存方法ごとの役割を理解しておくと、後から機能追加するときもスムーズになりますし、無理のない構成で開発を進めやすくなります。

---

Unityのセーブは用途別に使い分けるのが正解

先に結論をお伝えすると、Unityのセーブ機能には「これを選べば間違いない」という万能な方法はありません。

大切なのは、何を保存したいのかを基準に選ぶことです。

例えば、音量設定を保存したい場合と、RPGのプレイヤーデータを保存したい場合では必要な仕組みが大きく異なります。

実際の開発では、複数の保存方法を組み合わせることも珍しくありません。

最初に結論｜保存方法の選び方

保存したいもの	おすすめ
音量設定・画面設定	PlayerPrefs
ゲーム進行状況	JSON
アイテムデータ・敵データ	ScriptableObject
本格的なセーブシステム	Easy Save

この表だけ見ると単純に見えますが、実際のゲームでは役割を分担させることが多いです。

例えばRPGなら、

• 音量設定 → PlayerPrefs
• プレイヤーのレベルや所持金 → JSON
• 武器やモンスターの基本データ → ScriptableObject

というように使い分けるケースがよくあります。

保存方法ごとの役割を理解しておくと、後から機能を追加するときにも構造が崩れにくくなります。

迷ったらJSONから始めるのがおすすめ

もし「結局どれを選べばいいの？」と聞かれたら、私はJSONを中心に考えることをおすすめします。

理由は、ゲームのセーブデータとして扱いやすく、PlayerPrefsより柔軟で、Easy Saveほど導入コストも高くないからです。

例えば次のようなデータはJSONと相性が良いです。

• プレイヤーレベル
• 経験値
• 所持金
• クリア済みステージ
• インベントリ情報

逆に、PlayerPrefsだけでこうしたデータを管理し始めると、キーの数が増えて管理が大変になることがあります。

また、ScriptableObjectは非常に便利な仕組みですが、本来はセーブデータではなくマスターデータ管理向けです。この点を誤解している人も多いため、後ほど詳しく解説します。

---

Unityのセーブ方法は4種類ある

Unityで使われる保存方法はたくさんありますが、個人開発や小〜中規模ゲームでよく使われるのは次の4種類です。

• PlayerPrefs
• JSON
• ScriptableObject
• Easy Save

それぞれ得意なことが異なるため、「どれが優れているか」ではなく「何を保存するか」で選ぶことが重要です。

PlayerPrefsは設定保存向け

PlayerPrefsはUnityに標準搭載されている保存機能です。

キーと値をセットで保存するシンプルな仕組みで、追加パッケージなしですぐ利用できます。

例えば次のような設定値の保存に向いています。

• 音量設定
• 画面解像度
• フルスクリーン設定
• ハイスコア
• チュートリアル表示フラグ

実装も非常に簡単です。

PlayerPrefs.SetInt("HighScore", 1000);
PlayerPrefs.Save();

そのため、多くのUnity初心者が最初に触れる保存機能になります。

ただし、PlayerPrefsは大量のデータ保存には向いていません。

例えばRPGで次のようなデータを保存しようとすると管理が複雑になります。

• プレイヤーレベル
• 所持アイテム一覧
• クエスト進行状況
• 装備情報
• マップ進行状況

保存する項目が増えるたびにキー管理が必要になり、後から見返したときに何を保存しているのか分かりにくくなることがあります。

私も以前、小規模RPGの試作でPlayerPrefsだけを使っていたことがありますが、クエストフラグが増え始めた頃から管理が急激に大変になりました。

そのため、PlayerPrefsは「設定保存専用」と考えると失敗しにくいです。

JSONはゲーム進行データ向け

JSONは複数のデータをまとめて保存できる方法です。

プレイヤー情報を1つのクラスにまとめて保存できるため、多くのゲームで採用されています。

例えば次のようなデータを一括で管理できます。

• レベル
• 経験値
• 所持金
• アイテム
• クリア済みステージ

PlayerPrefsのように個別のキーを大量管理する必要がありません。

例えば次のようなクラスを作成できます。

[Serializable]
public class SaveData
{
    public int level;
    public int gold;
    public int stage;
}

このオブジェクトをJSON文字列へ変換し、ファイルとして保存します。

ゲームの進行状況をまとめて管理したい場合は非常に相性が良い方法です。

ただしJSONはテキストファイルです。

保存されたファイルを開くことができる環境では、中身を編集できる場合があります。

そのため、ランキングや課金データなど改ざん対策が必要なケースでは追加の対策を検討することがあります。

ScriptableObjectはマスターデータ向け

ScriptableObjectは少し特殊な仕組みです。

名前だけ見ると「データを保存するための機能」に見えますが、実際にはプレイヤーのセーブデータを保存するためのものではありません。

主な用途はゲーム全体で共通利用するデータの管理です。

例えば次のようなデータと相性が良いです。

• 武器データ
• アイテムデータ
• モンスターデータ
• スキルデータ
• バランス調整用パラメータ

例えば「ポーションの回復量は50」「鉄の剣の攻撃力は10」といった情報をアセットとして管理できます。

そのため、ゲーム設計が整理しやすくなります。

一方で、プレイヤーがゲーム中に取得したアイテム数やレベルなどの変化するデータを保存する用途には通常使いません。

この点は初心者が特に誤解しやすいポイントです。

ScriptableObjectは「マスターデータ」、JSONは「プレイヤーデータ」と役割を分けて考えると理解しやすくなります。

Easy Saveは実装を楽にするアセット

Easy SaveはUnity Asset Storeで販売されている人気のセーブアセットです。

Unity標準機能だけでは手間がかかる保存処理を大幅に簡略化できます。

例えば次のようなデータも簡単に保存できます。

• Dictionary
• List
• GameObject
• Transform
• Texture

また、暗号化や圧縮機能も用意されているため、標準機能だけで構築するよりも開発工数を削減しやすいです。

特に次のようなゲームでは導入メリットが大きくなります。

• RPG
• サバイバルゲーム
• クラフトゲーム
• シミュレーションゲーム

ただし、Easy Saveを導入したからといって設計を考えなくてよいわけではありません。

何を保存するのか、どのタイミングで保存するのかは依然として開発者が決める必要があります。

「保存処理を楽にしてくれる便利な道具」と考えるとイメージしやすいでしょう。

Easy Save
✅アセットストアでチェックする

---

Unityのセーブ方法を比較するとこうなる

ここまで各保存方法の特徴を見てきましたが、実際に選ぶ場面では「結局どれが自分のゲームに合うのか」が気になるところです。

そこで、開発現場で特に重要になる比較ポイントをまとめました。

比較項目	PlayerPrefs	JSON	ScriptableObject	Easy Save
実装難易度	非常に簡単	普通	簡単	簡単
ゲーム進行保存	△	◎	×	◎
設定保存	◎	○	×	◎
マスターデータ管理	×	△	◎	△
拡張性	低い	高い	高い	高い
導入コスト	無料	無料	無料	有料

実装難易度を比較

最も手軽なのはPlayerPrefsです。

数行のコードだけで保存と読み込みができるため、音量設定やハイスコア保存なら数分で実装できることもあります。

一方、JSONは保存用クラスの作成やファイル操作が必要になるため、最初は少し学習コストがあります。

ただし、一度仕組みを理解すると応用範囲が広く、ゲーム開発全体の理解も深まります。

Easy SaveはJSONよりさらに実装量を減らせる場合がありますが、有料アセットの導入判断が必要です。

拡張性を比較

長く開発を続けるなら拡張性は重要です。

例えば開発初期はレベルと所持金だけ保存していたとしても、後から次のような要素を追加したくなることがあります。

• インベントリ
• 実績システム
• クエスト進行
• 装備システム
• スキルツリー

こうした拡張を考えると、JSONやEasy Saveのほうが柔軟に対応しやすい傾向があります。

PlayerPrefsは保存項目が増えるほど管理が複雑になりやすいため、大規模化を前提とする場合は注意が必要です。

セキュリティを比較

初心者が見落としやすいのがセキュリティです。

PlayerPrefsもJSONも、基本的には改ざんが不可能な仕組みではありません。

そのため、オフラインゲームなら大きな問題にならなくても、ランキングや課金要素が関わる場合は別の対策が必要になることがあります。

Easy Saveには暗号化機能が用意されていますが、それだけで完全なチート対策になるわけではありません。

セキュリティを考える場合は、保存方法そのものだけでなく、サーバー管理や検証処理も含めて設計することが大切です。

保存できるデータ量を比較

保存データが増えるほど、構造化しやすい仕組みが有利になります。

例えばRPGのセーブデータには数十〜数百項目の情報が含まれることもあります。

そのようなケースではJSONやEasy Saveのほうが管理しやすくなります。

逆に、音量や言語設定だけを保存したい場合に複雑な仕組みを導入すると、かえって保守コストが増えてしまいます。

保存方法は「高機能なものを選ぶ」のではなく、「必要十分なものを選ぶ」という考え方が重要です。

個人開発でおすすめなのはどれ？

私なら個人開発の多くのケースで、次の構成を選びます。

• 設定保存 → PlayerPrefs
• プレイヤーデータ → JSON
• マスターデータ → ScriptableObject

この組み合わせは無料で構築でき、Unityの基本的なデータ管理も学べます。

一方で、開発期間を短縮したい場合や、複雑なセーブシステムを素早く構築したい場合はEasy Saveも有力な選択肢になります。

---

Unityのセーブ設計で初心者が選ぶべき構成

保存方法の特徴を理解すると、次に気になるのは「実際のゲーム開発ではどう組み合わせればいいのか」ではないでしょうか。

ここでは、開発規模やゲームジャンルごとにおすすめの構成を紹介します。

最初から完璧な設計を目指す必要はありません。まずは管理しやすい構成を選び、必要に応じて拡張していくほうが開発を進めやすくなります。

小規模ゲームならPlayerPrefs＋JSON

個人開発や学習用プロジェクトなら、この組み合わせが最もバランスが良いと感じています。

例えば次のような役割分担です。

• 音量設定 → PlayerPrefs
• ベストスコア → PlayerPrefs
• ステージ進行状況 → JSON
• 所持コイン → JSON

パズルゲームやカジュアルゲームなら、この構成だけで十分なケースも少なくありません。

PlayerPrefsが得意な「設定保存」と、JSONが得意な「ゲーム進行保存」を分離することで、後からコードを見返したときも理解しやすくなります。

また、JSONを使った保存処理は将来的にクラウドセーブや暗号化へ発展させやすいというメリットもあります。

RPGならScriptableObject＋JSON

RPGやシミュレーションゲームになると、保存するデータ量が一気に増えます。

そこで重要になるのが、プレイヤーデータとマスターデータを分離する考え方です。

例えば次のように役割を分けます。

• プレイヤーレベル → JSON
• 所持金 → JSON
• インベントリ → JSON
• 武器データ → ScriptableObject
• モンスターデータ → ScriptableObject
• スキルデータ → ScriptableObject

例えば「鉄の剣」の攻撃力を変更したい場合、ScriptableObjectのデータを編集するだけで済みます。

もし全てをJSONで管理していると、ゲームバランス調整のたびに大量のデータを修正することになりかねません。

RPG開発では、プレイヤーが変化させる情報と、開発者が管理する情報を分けることで保守性が大きく向上します。

Unityゲーム プログラミング・バイブル 2nd Generation
✅ Amazonでチェックする｜✅ 楽天でチェックする

商用開発ならEasy Saveも有力候補

商用タイトルや中規模以上のゲームでは、開発効率も重要な判断材料になります。

例えば次のようなケースです。

• セーブ対象が非常に多い
• 開発スケジュールが厳しい
• 複数人で開発している
• 実装工数を減らしたい

このような場合、Easy Saveを導入することで保存処理の実装時間を短縮できる可能性があります。

特にインベントリや建築データなど複雑なデータ構造を扱うゲームでは、標準機能だけで実装するより効率的な場合もあります。

ただし、有料アセットだから必ず優れているというわけではありません。

小規模ゲームならJSONで十分なことも多いため、「工数削減によるメリットが購入コストを上回るか」という視点で判断すると選びやすくなります。

---

ScriptableObjectをセーブデータに使うのは危険？

Unity初心者が特につまずきやすいのが、ScriptableObjectとセーブデータの関係です。

実際、ネット上でも「ScriptableObjectでデータを保存できた」という情報を見かけることがあります。

しかし、その挙動を正しく理解しないまま使うと、ビルド後に思わぬトラブルにつながることがあります。

なぜ保存されたように見えるのか

Unityエディタ上でScriptableObjectの値を変更すると、その変更内容が残っているように見えることがあります。

例えば、ScriptableObjectに所持金を保存してPlayモード中に数値を変更すると、ゲーム内で正常に反映されます。

そのため、

• レベルを保存できた
• 所持金を保存できた
• セーブ機能として使えそう

と感じることがあります。

しかしこれは「ScriptableObjectがセーブデータとして優秀」という話ではありません。

Unityエディタ特有の挙動やテスト環境の影響で、保存できているように見えているケースもあるため注意が必要です。

ビルド後に起きる問題

実際にゲームをビルドすると、ScriptableObjectは通常アセットデータとして扱われます。

例えば次のような使い方をすると問題が発生しやすくなります。

• プレイヤーレベルを保存する
• 経験値を保存する
• 所持アイテム数を保存する
• クエスト進行を保存する

これらは本来プレイヤーごとに変化するデータです。

ところがScriptableObjectはゲームの設計データとして扱うことを前提に作られているため、一般的なセーブシステムとは役割が異なります。

その結果、アプリを再起動したら値が戻る、期待通りに保存されないといった問題につながることがあります。

「エディタでは動いたのに製品版では動かない」という典型的な落とし穴のひとつです。

正しい使い方はマスターデータ管理

ScriptableObjectが最も力を発揮するのは、ゲーム全体で共有するデータ管理です。

例えば次のような用途です。

• 武器データ
• アイテムデータ
• 敵ステータス
• スキル設定
• ゲームバランス用パラメータ

例えば「鉄の剣」の攻撃力を10から12へ変更したい場合、ScriptableObjectのアセットを編集するだけで済みます。

コードを書き換える必要がなく、デザイナーやプランナーも調整しやすくなります。

このような用途こそ、ScriptableObjectの本来の強みです。

セーブデータとは役割を分ける

ゲーム開発では、次のように考えると整理しやすくなります。

種類	保存するもの	おすすめ
マスターデータ	武器・敵・スキル情報	ScriptableObject
プレイヤーデータ	レベル・所持金・進行状況	JSONやEasy Save

私もRPGやシミュレーションゲームを設計するときは、この分離を最優先で考えます。

マスターデータとセーブデータを混在させると、後から機能追加するときに管理が複雑になりやすいからです。

---

Unityのセーブでよくある失敗例

セーブ機能は一度動けば完成に見えますが、実際には後から問題が発生しやすい部分でもあります。

特に開発初期の判断が、その後の保守性や拡張性に大きく影響します。

ここでは、多くの開発者が一度は経験する失敗例を紹介します。

PlayerPrefsに全部保存してしまう

最もよくある失敗がこれです。

PlayerPrefsは非常に手軽なので、最初は次のようなデータも保存したくなります。

• レベル
• 経験値
• 所持金
• 装備情報
• クエスト進行状況

しかし開発が進むにつれて、保存するキーが大量に増えていきます。

例えば、

PlayerLevel
PlayerGold
Quest01
Quest02
Quest03
Weapon01
Weapon02

といったキーが増え始めると、どのデータを保存しているのか把握しにくくなります。

結果として、デバッグや機能追加のたびに管理コストが増えてしまいます。

PlayerPrefsは設定保存、ゲーム進行はJSONやEasy Saveという役割分担を意識すると管理しやすくなります。

ScriptableObjectだけで完結させようとする

ScriptableObjectを使い始めると、「データを保存できるならセーブ機能も作れるのでは？」と考えることがあります。

しかし、前のセクションで説明したように、ScriptableObjectは主にマスターデータ管理向けです。

例えば、

• 武器の攻撃力
• 敵のHP
• アイテム説明文

を管理するのは得意ですが、

• 現在レベル
• 所持金
• ゲーム進行状況

を保存する用途には通常向いていません。

役割を混同すると、後からデータ管理が複雑になる原因になります。

セーブデータ改ざんを考慮していない

開発初期は見落としがちですが、セーブデータはユーザーから見える場所に保存されることがあります。

そのため、保存方法によっては編集ツールで内容を書き換えられる場合があります。

例えばオフラインゲームなら大きな問題にならないこともありますが、次のようなケースでは注意が必要です。

• ランキング機能
• オンライン対戦
• 課金要素
• 共有データ

こうした機能を実装する予定があるなら、保存方式だけでなくサーバー側での検証も視野に入れる必要があります。

なお、暗号化は改ざん対策の一部ではありますが、万能ではありません。

将来の機能追加を考えていない

ゲーム開発では、途中で仕様変更が発生することがよくあります。

例えば最初はレベルと所持金だけだったとしても、後から次のような要素を追加したくなるかもしれません。

• 実績システム
• スキルツリー
• ペット育成
• 装備強化
• クラフト要素

保存方法を選ぶ際は、「今必要なもの」だけでなく「半年後に追加されそうな機能」も少しだけ意識しておくと、後から大規模な作り直しを避けやすくなります。

結局どう選べばいい？

• 音量や設定 → PlayerPrefs
• プレイヤーの進行状況 → JSON
• 武器や敵の定義データ → ScriptableObject
• 工数を減らしたい → Easy Save

---

まとめ

Unityには複数の保存方法がありますが、重要なのは「どれが最強か」を探すことではありません。

保存したいデータの種類に合わせて、適切な仕組みを選ぶことが大切です。

今回紹介した内容を整理すると、次のようになります。

• PlayerPrefs → 音量や設定の保存
• JSON → プレイヤーの進行状況の保存
• ScriptableObject → マスターデータ管理
• Easy Save → 保存処理の効率化

特に初心者の方は、ScriptableObjectとセーブデータを混同しやすいため注意が必要です。

ScriptableObjectは非常に便利な機能ですが、本来は武器やアイテム、敵ステータスなどの共有データを管理するための仕組みです。

プレイヤーのレベルや所持金など、ゲームプレイによって変化する情報はJSONやEasy Saveなど別の保存方法で管理するほうが整理しやすくなります。

私自身も小規模なゲームを作る場合は、まず「PlayerPrefs＋JSON」の構成から考えることが多いです。

無料で構築できるうえに、セーブシステムの仕組みそのものを理解しやすいからです。

そして、開発規模が大きくなったり、保存対象が増えて実装コストが気になったりしたタイミングでEasy Saveの導入を検討します。

セーブ機能はゲーム完成後に追加するより、早い段階で方針を決めておくほうが後々の作業が楽になります。

これからセーブ機能を実装するなら、まずは「何を保存したいのか」を紙に書き出してみてください。

その一覧ができれば、どの保存方法を選ぶべきか自然と見えてくるはずです。

---

よくある質問（FAQ）