Unity新Input Systemでキーコンフィグ実装！実行時リバインド＆保存まで完全手順

はじめに

ゲームを遊んでいて、「このキー配置、ちょっと押しにくいな……」と感じたことはありませんか？ 実はこの操作割り当てを自由に変更できるかどうかは、遊びやすさだけでなく、 プレイヤーの満足度やアクセシビリティにも大きく関わる、とても大事なポイントなんです。

Unityでは昔から入力処理を扱えましたが、近年主流になってきた新しい Input Systemでは、 ゲーム内で実行時にキー割り当てを変更する、いわゆる キーコンフィグ（ランタイムリバインディング）を 公式にサポートする仕組みが用意されています。

ただし……正直に言うと、
「ドキュメントを読んだけど、どう組み合わせればいいのか分からない」
「RebindActionUI を触ってみたけど、仕組みが理解できずに止まった」
そんな経験をした人も多いはずです。

この記事では、Unityの新しい Input System を使って、ゲーム内でキーコンフィグを実装する方法を、 実装の全体像 → UI構築 → リバインディング処理 → 保存・リセットまで、 ひとつずつ丁寧に解説していきます。

「とりあえず動く」だけでなく、
・入力の重複をどう防ぐか
・Composite（WASDなど）をどう扱うか
・メモリリークを起こさない実装とは何か
こういった実務でハマりやすいポイントもしっかりカバーします。

Input Systemを使い始めたばかりの方はもちろん、
すでに導入していて「キーコンフィグだけ後回しにしていた」という方にも、 きっと役立つ内容になっています 😊

それでは次の章から、まずはUnityでキーコンフィグを実装するための選択肢を整理していきましょう。

1. Unityにおけるキーコンフィグ実装の選択肢

Unityでキーコンフィグ（操作割り当て変更）を実装しようとしたとき、 大きく分けて2つの選択肢があります。

• 新しい Input System を使って 自前で実装する
• キーコンフィグ対応の 専用アセットを導入する

どちらが正解、というわけではなく、
「プロジェクト規模」「対応したいデバイス」「開発にかけられる時間」によって ベストな選択は変わってきます。

1-1. Input Systemで自前実装する場合

新しい Input System には、 PerformInteractiveRebinding() を使った 実行時リバインディング機能が用意されています。

この方法のメリットは、
・Unity標準機能だけで完結する
・UIや挙動を自由にカスタマイズできる
・PlayerPrefs や JSON を使って柔軟に保存できる
など、自由度の高さにあります。

その一方で、 UI構築・Action Mapの切り替え・保存処理・例外対応まで すべて自分で面倒を見る必要があります。 特に Composite Bindings や入力重複チェックは、後から効いてくるポイントです。

1-2. アセットを使うという選択肢

「そこまで細かく作り込む余裕がない」
「キーボード・ゲームパッド・複数デバイスを最初から安定して対応したい」
そんな場合は、実績のある入力管理アセットを使うのも現実的な選択です。

代表的なのが Rewired です。 多くの商用タイトルでも使われており、 キーコンフィグや複数入力デバイスの管理をかなり楽にしてくれます。

自前実装に比べると学習コストは下がりますが、 「Input System の仕組みを理解したい」「細かい挙動まで制御したい」 という人には、ややブラックボックスに感じるかもしれません。

どちらを選ぶにしても大切なのは、
自分のプロジェクトにとって何が必要かを最初に整理することです。

本記事では、まず Input System を使った標準的な実装方法 を中心に解説し、 その上で「アセットを使うとどう楽になるのか」が分かる構成にしています。

次の章では、実際に実装する前に押さえておきたい キーコンフィグ処理の全体像を整理していきましょう。

2. 新しい Input System でキーコンフィグを実装する全体像

ここからは、新しい Input System を使って キーコンフィグ（操作割り当て変更）を実装する流れを、 まずは大きな視点で整理していきます。

先に全体像を掴んでおくことで、
「なぜこの処理が必要なのか？」
「このタイミングで UI を切り替えている理由は？」
といった疑問が、あとでスッと理解しやすくなります。

キーコンフィグ処理の基本フロー

Input System におけるランタイムリバインディングは、 次のような流れで実装されるのが基本です。

1. リバインド対象の InputAction を一時的に無効化する
2. PerformInteractiveRebinding() を開始し、 ユーザーの入力を待つ
3. 入力が確定、またはキャンセルされたら処理を終了する
4. RebindingOperation.Dispose() を呼び出し、 メモリを解放する
5. InputAction を再度有効化する
6. 変更されたバインディングを保存する

一見するとシンプルですが、
Action Map の切り替えや UI の表示制御を適切に行わないと、 意図しない入力が入ったり、操作不能になることがあります。

なぜ Action Map の切り替えが重要なのか

キーコンフィグ中にプレイヤーの操作が有効なままだと、 「キーを押した瞬間にキャラクターが動く」 といった問題が起こりがちです。

そのため多くの実装では、 PlayerInput.SwitchCurrentActionMap() を使って 一時的に入力が定義されていない Action Mapや Menu 用の Action Mapに切り替えます。

こうしておくことで、 リバインド中の入力だけを安全に受け取れる状態を作れます。

RebindingOperation のライフサイクル

PerformInteractiveRebinding() は、 RebindingOperation というオブジェクトを返します。

このオブジェクトはアンマネージドリソースを使っているため、 完了時やキャンセル時に 必ず Dispose() を呼び出す必要があります。

ここを忘れると、見えないところでメモリが解放されず、 後から原因不明の不具合につながることもあります。 地味ですが、とても大切なポイントです。

次の章では、実装に入る前の準備として、 Input Action Asset と PlayerInput の設定を 具体的に見ていきましょう。

3. 事前準備：Input Action Asset と PlayerInput の設定

ここからは、キーコンフィグを実装する前に必ず行っておきたい Input System 側の準備について解説します。

この段階を雑に済ませてしまうと、
「リバインドはできたのに入力が反応しない」
「Action Map を切り替えたら戻らなくなった」
といったトラブルに繋がりやすいので、ひとつずつ確認していきましょう。

3-1. Input System パッケージの導入

まずは Unity に Input System パッケージを導入します。 Package Manager を開き、一覧から Input System をインストールしてください。

インストール後、Input System を有効化するかどうか聞かれた場合は、 Yes を選択して再起動します。

また、UI からの入力を正しく扱うために、 シーン上の EventSystem には Input System UI Input Module が設定されていることを確認してください。

3-2. Input Action Asset の作成と設定

次に、操作の定義をまとめる Input Action Asset を作成します。

プロジェクトウィンドウを右クリックして 「Create」→「Input Actions」を選び、 新しい Input Action Asset を作成します。

作成した Asset を開き、以下のように構成していきます。

• Action Map：Gameplay / Menu など役割ごとに分ける
• InputAction：Move / Jump / Attack などの操作単位
• Binding：Keyboard や Gamepad の入力割り当て

キーコンフィグを前提にする場合、 最初から複数デバイス（Keyboard / Gamepad）を想定して Binding を作っておくと、 後の実装がかなり楽になります。

3-3. PlayerInput コンポーネントの設定

プレイヤーオブジェクトに PlayerInput コンポーネントを追加します。

PlayerInput には、先ほど作成した Input Action Asset を割り当ててください。

ここで重要なのが、 Action Map を切り替えられる構成になっているかです。

キーコンフィグ中は Gameplay の操作を止め、 終了後に元に戻す必要があるため、 Action Map は「ひとつだけ」ではなく、 役割ごとに分けて設計しておくのがおすすめです。

準備が整ったら、次は リバインディング用の UI 構築に進みます。 画面構成とスクリプトの役割を整理しながら作っていきましょう。

4. リバインディングUIの構築とスクリプトの準備

Input Action Asset と PlayerInput の準備ができたら、 次はいよいよ キーコンフィグ用の UI を作っていきます。

ここでは見た目を作るだけでなく、
「どのアクションを、どのバインディングとしてリバインドするのか」
を正しく管理できる構成にすることが大切です。

4-1. UIの基本構成

まずは、最低限必要になる UI 要素を整理しておきましょう。

• 操作名を表示するテキスト（例：Jump / Attack）
• 現在の割り当てキーを表示するテキスト
• リバインド開始用のボタン
• 入力待ち状態を示すオーバーレイ（「キーを押してください」など）
• 割り当てを初期状態に戻すリセットボタン

これらを1セットとして並べておくと、 プレイヤーにとっても分かりやすいキーコンフィグ画面になります。

4-2. スクリプトの作成

次に、キーコンフィグ処理をまとめるスクリプトを作成します。

プロジェクトウィンドウを右クリックして 「Create」→「C# Script」を選び、 例えば RebindActionUI という名前でスクリプトを作成します。

このスクリプトでは、主に次の情報を参照します。

• InputActionReference：リバインド対象のアクション
• TMP_Text：操作名・割り当て表示用
• GameObject：入力待ちオーバーレイの表示制御
• RebindingOperation： 実行中のリバインド処理を保持する変数

公式サンプルの RebindActionUI を参考にすると、 「何をどこで管理すればいいか」が一気に見えてきます。

4-3. ターゲットバインディングの指定

ひとつの InputAction に対して、 複数の Binding が設定されているケースは珍しくありません。

例えば、
・Keyboard 用のキー
・Gamepad 用のボタン
が同じアクションに割り当てられている場合です。

このとき、どの Binding をリバインドするのかを明確にするために、 WithTargetBinding() を使って バインディングのインデックスを指定します。

インデックス管理が曖昧だと、 「キーボードを変更したつもりがゲームパッドが変わった」 という事故が起こりやすくなります。

UI 側で「キーボード用」「ゲームパッド用」を分けて表示する設計にしておくと、 この問題はかなり防ぎやすくなります。

次の章では、いよいよ リバインディング処理そのものを実装していきます。 ボタンを押した瞬間から、入力を待ち、確定・キャンセルする流れを見ていきましょう。

5. リバインディング処理の開始（StartRebinding）

UI の準備ができたら、次は 「リバインド開始ボタンを押したら入力待ち状態に入る」部分を実装していきます。

ここはキーコンフィグ機能の心臓部です。
変なタイミングでアクションが発火したり、入力が二重に取られたりしないように、 手順通りに組み立てていきましょう。

5-1. StartRebindingでやること（流れ）

リバインド開始時に必要な処理は、ざっくり次の通りです。

1. （必要なら）Action Map を切り替えて、通常操作を止める
2. リバインド対象の InputAction を Disable() する
3. 入力待ち UI（オーバーレイ）を表示する
4. PerformInteractiveRebinding() を開始して入力を待つ
5. 完了/キャンセル時の処理を登録し、.Start() で開始する

5-2. 実装例（基本形）

まずは全体像を掴むために、基本形のコード例を載せます。
細かい調整はこのあと順番に解説しますね。

using UnityEngine;
using TMPro;
using UnityEngine.InputSystem;

public class SimpleRebindUI : MonoBehaviour
{
    [Header("Rebind Target")]
    [SerializeField] private InputActionReference actionReference;
    [SerializeField] private int targetBindingIndex = 0;

    [Header("UI")]
    [SerializeField] private TMP_Text bindingText;
    [SerializeField] private GameObject waitingOverlay;

    private InputActionRebindingExtensions.RebindingOperation _rebindOp;

    public void StartRebinding()
    {
        var action = actionReference.action;
        if (action == null) return;

        // 1) リバインド中に通常入力が暴れないように、まず止める
        action.Disable();

        // 2) 入力待ちUI
        if (waitingOverlay != null) waitingOverlay.SetActive(true);

        // 3) 既に走っていたら念のため破棄
        _rebindOp?.Dispose();
        _rebindOp = null;

        // 4) インタラクティブリバインド開始
        _rebindOp = action.PerformInteractiveRebinding(targetBindingIndex)
            .WithControlsExcluding("<Mouse>")
            .WithCancelingThrough("<Keyboard>/escape")
            .OnComplete(op => OnRebindComplete(action))
            .OnCancel(op => OnRebindCancel(action));

        _rebindOp.Start();
    }

    private void OnRebindComplete(InputAction action)
    {
        _rebindOp?.Dispose();
        _rebindOp = null;

        if (waitingOverlay != null) waitingOverlay.SetActive(false);

        action.Enable();
        UpdateBindingDisplay();
        // TODO: 保存処理（後の章で実装）
    }

    private void OnRebindCancel(InputAction action)
    {
        _rebindOp?.Dispose();
        _rebindOp = null;

        if (waitingOverlay != null) waitingOverlay.SetActive(false);

        action.Enable();
        UpdateBindingDisplay();
    }

    private void UpdateBindingDisplay()
    {
        if (bindingText == null || actionReference?.action == null) return;
        bindingText.text = actionReference.action.GetBindingDisplayString(targetBindingIndex);
    }
}

5-3. 重要ポイント：除外・キャンセルの設定

WithControlsExcluding("<Mouse>") は、 リバインド中に「マウス移動」や「クリック」が勝手に拾われないための保険です。

また WithCancelingThrough("<Keyboard>/escape") を入れておくと、 ユーザーが「やっぱやめたい！」となったときに、 ESCで安全に抜けられるようになります。

5-4. PlayerInputのAction Map切り替えはどこでやる？

今回のコード例ではシンプルにするために省略しましたが、 実際のゲームではリバインド中にキャラが動いたり攻撃したりすると困ることが多いです。

そのため、プロジェクトによっては StartRebindingの最初に Action Map を Menu/Blank に切り替える実装が有効です。 この章の後半（完了/キャンセル処理）とセットで入れると事故が減ります。

次の章では、完了・キャンセル時にやるべきことを整理しつつ、 UI更新と保存処理の土台を作っていきます。

6. リバインディング処理の完了・キャンセル（RebindComplete / RebindCancel）

リバインド処理は「入力を待つ」だけでは終わりません。
入力が確定したとき（完了）と、途中でやめたとき（キャンセル）で、 必ず後片付けをしてあげる必要があります。

ここを丁寧に作っておくと、
「リバインド後に操作が効かない」
「入力待ちUIが消えない」
「いつの間にかメモリが増えていく」
みたいな、地味にしんどい事故をかなり防げます。

6-1. 完了/キャンセル時に必ずやること

完了でもキャンセルでも、基本的にやることは同じです。

1. RebindingOperation を Dispose() して破棄する
2. 入力待ちUI（オーバーレイ）を非表示にする
3. 無効化していた InputAction を Enable() する
4. （必要なら）Action Map を元に戻す
5. 表示テキストを更新する
6. （完了時のみ）保存処理を行う

特に大事なのが Dispose() です。
RebindingOperation はアンマネージドリソースを使うため、 完了・キャンセルに関係なく 必ず破棄します。

6-2. 実装例：共通の後片付け関数を作る

完了/キャンセルで同じ処理が多いので、 “後片付け”を共通関数にまとめておくとミスが減ります。

using UnityEngine;
using UnityEngine.InputSystem;

public partial class SimpleRebindUI : MonoBehaviour
{
    [Header("Optional")]
    [SerializeField] private PlayerInput playerInput;
    [SerializeField] private string gameplayMapName = "Gameplay";
    [SerializeField] private string rebindMapName = "Menu"; // または Blank

    // リバインド開始時に呼ぶ例
    private void SwitchToRebindMapIfNeeded()
    {
        if (playerInput == null) return;
        if (!string.IsNullOrEmpty(rebindMapName))
            playerInput.SwitchCurrentActionMap(rebindMapName);
    }

    // 完了/キャンセル後に呼ぶ例
    private void SwitchBackToGameplayMapIfNeeded()
    {
        if (playerInput == null) return;
        if (!string.IsNullOrEmpty(gameplayMapName))
            playerInput.SwitchCurrentActionMap(gameplayMapName);
    }

    private void CleanupAfterRebind(InputAction action, bool save)
    {
        // 1) 必ず破棄
        _rebindOp?.Dispose();
        _rebindOp = null;

        // 2) UIを戻す
        if (waitingOverlay != null) waitingOverlay.SetActive(false);

        // 3) アクションを戻す
        if (action != null) action.Enable();

        // 4) Action Map を元に戻す（必要なら）
        SwitchBackToGameplayMapIfNeeded();

        // 5) 表示更新
        UpdateBindingDisplay();

        // 6) 保存（完了時のみ）
        if (save)
        {
            SaveBindingOverrides();
        }
    }

    private void OnRebindComplete(InputAction action)
    {
        CleanupAfterRebind(action, save: true);
    }

    private void OnRebindCancel(InputAction action)
    {
        CleanupAfterRebind(action, save: false);
    }
}

ポイントは CleanupAfterRebind() に 「完了でもキャンセルでも必ずやること」を集約しているところです。 「Dispose忘れ」みたいな致命傷が出にくくなります。

6-3. Action Map切り替えを入れる場合の注意

Action Map を切り替える構成にする場合は、
開始時に切り替え → 完了/キャンセルで必ず戻す
ここをセット運用にしてください。

片方だけ入れると「二度とGameplayに戻れない」みたいな悲劇が起こります…（わりとあるあるです）

次の章では、プレイヤーに見せるためにとても重要な バインディング表示の更新（見やすく表示する方法）を解説します。 キーボードだけでなく、ゲームパッドの表示にも繋がるところです。

7. バインディング表示の更新（見やすく・分かりやすく）

キーコンフィグ画面って、実は「リバインド処理」よりも 表示が分かりやすいかどうかの方が体験に直結します。

たとえば、リバインド自体は成功しているのに
「今どのキーなの？」が分からないと、プレイヤーは不安になりますよね。 なのでここはしっかり作り込みましょう。

7-1. まずは GetBindingDisplayString() を使う

Input System には、バインディングを人間に読みやすい形で表示するための 便利メソッドが用意されています。

基本はこの一行でOKです。

bindingText.text = action.GetBindingDisplayString(bindingIndex);

これだけで、たとえば <Keyboard>/space のような内部パスが 「Space」みたいに読みやすい表示になります。

7-2. 表示オプションで「見た目」を整える

もう少し見た目にこだわるなら、表示オプションも使えます。

bindingText.text = action.GetBindingDisplayString(
    bindingIndex,
    out var deviceLayoutName,
    out var controlPath
);

deviceLayoutName と controlPath を受け取れるので、ここが地味に便利です。

• deviceLayoutName：Keyboard / Gamepad など、デバイス種別のヒント
• controlPath：ボタン種別（southButton など）を判定する材料

この情報を使うと、 「テキスト表示」だけでなく「アイコン表示」もできるようになります。

7-3. キーボードとゲームパッドで表示を分ける考え方

キーコンフィグでハマりがちなのが、
「キーボードで変更したのに、ゲームパッド側の表示が更新されない」
逆に「ゲームパッドを変えたらキーボード表示が変わった」
みたいな混乱です。

これを防ぐには、UI設計段階で “どのデバイスのどのBindingを編集しているか” をはっきり分けておくのがコツです。

• キーボード用のリバインド行（bindingIndexはKeyboard側を指す）
• ゲームパッド用のリバインド行（bindingIndexはGamepad側を指す）

そして更新も「その行のbindingIndexだけ更新する」ようにすると、 UIがスッキリして事故が減ります。

7-4. 実機確認はゲームパッドがあると一気に楽

ここまでの実装は、エディタ上のキーボードだけでも進められますが、
ゲームパッドの表示やリバインド挙動は 実機で触った方が圧倒的に早く気づけます。

もし検証用に1つ持っておくなら、 PCでもそのまま使える有線タイプが手軽でおすすめです。

PowerA 有線コントローラー Xbox Series X|S Xbox One PC
✅ Amazonでチェックする ｜ ✅ 楽天でチェックする

次の章では、WASDのような Composite Bindings（複合バインディング）を リバインドするときの特殊な扱い方を解説します。 ここ、最初に知っておくとだいぶ時短になります…！

8. Composite Bindings（WASDなど）をリバインドする方法

キーコンフィグ実装で、多くの人が一度は詰まるのが Composite Bindingsの扱いです。

代表例が、移動操作でよく使われる
WASD を 2DVector としてまとめた入力ですね。 見た目は1つの操作なのに、内部的には少し特殊な構造になっています。

8-1. Composite Binding の構造を知る

Composite Binding は、 「親」と「子」のバインディングで構成されています。

• 親：2DVector（まとめ役、入力は持たない）
• 子：Up / Down / Left / Right（実際のキー割り当て）

Input Action Asset 上では、
親の Composite の直後に、子バインディングが 連続したインデックスで並んでいます。

つまり「移動」を1つリバインドしたいつもりでも、 実際には 4つのバインディングを順番に変更する必要がある、 というわけです。

8-2. なぜ普通のリバインドでは上手くいかないのか

Composite の親バインディングは、 入力を直接受け取らないため、 PerformInteractiveRebinding() を そのまま呼んでも意味がありません。

その結果、
「最初のキーだけ変わる」
「どこを押しても反応しない」
といった混乱が起こります。

8-3. 子バインディングを順番にリバインドする考え方

Composite のリバインドでは、 Up → Down → Left → Right のように、 子バインディングをひとつずつ処理していくのが基本です。

実装イメージとしては、 「今どの子をリバインドしているか」を覚えながら、 PerformInteractiveRebinding() を 繰り返し呼び出します。

8-4. インデックス取得の考え方

Composite の子バインディングは、 インデックスがズレやすいポイントでもあります。

そのため、固定の数値を直接書くよりも、 バインディング名を使って取得する方が安全です。

int index = action.GetBindingIndex("Up");

また、Input System には ChangeCompositeBinding() という拡張も用意されており、 NextPartBinding() を使うことで 次にリバインドすべき子バインディングを 順番に取得できます。

この仕組みを使うと、 「次は Down キーを押してください」 といった案内を UI に出すこともできるので、 プレイヤーにとっても親切です。

8-5. UIでの見せ方の工夫

Composite をまとめて1行で表示すると、 何が起きているのか分かりにくくなりがちです。

個人的には、
・移動（Up / Down / Left / Right）をそれぞれ表示する
・または「移動キーをまとめて変更」ボタンを用意する
といった形が分かりやすいかな、と思っています。

次の章では、ここまで変更してきたキー割り当てを どうやって保存し、次回起動時に復元するかを解説します。 ここを押さえれば、キーコンフィグはほぼ完成です ✨

9. キーコンフィグ設定の保存・ロード・リセット

ここまでで、キーの割り当てを変更する仕組みはほぼ完成しました。
ただし、保存されなければ意味がありませんよね。

この章では、Input System の Binding Overrides を JSON として保存・復元する方法と、 すべてを初期状態に戻すリセット処理を解説します。

9-1. バインディングを JSON として保存する

Input Action Asset は、 現在のバインディング変更内容を SaveBindingOverridesAsJson() で まとめて取得できます。

これを PlayerPrefs に保存しておけば、 次回起動時にも同じ設定を使えます。

using UnityEngine;
using UnityEngine.InputSystem;

public class InputSaveManager : MonoBehaviour
{
    [SerializeField] private InputActionAsset actions;
    private const string SaveKey = "input_rebinds";

    public void Save()
    {
        string json = actions.SaveBindingOverridesAsJson();
        PlayerPrefs.SetString(SaveKey, json);
        PlayerPrefs.Save();
    }
}

保存単位は InputActionAsset 全体なので、 複数の Action Map やアクションがあっても まとめて管理できます。

9-2. 起動時に設定をロードする

保存しただけでは反映されません。 ゲーム起動時に ロード処理を入れましょう。

public void Load()
{
    if (!PlayerPrefs.HasKey(SaveKey)) return;

    string json = PlayerPrefs.GetString(SaveKey);
    actions.LoadBindingOverridesFromJson(json);
}

この処理は、
・ゲーム起動時
・Input Action Asset を使い始める直前
に呼び出すのが安全です。

9-3. すべて初期状態に戻す（リセット）

「全部元に戻したい」というニーズも、かなり多いです。

Input System では、 RemoveAllBindingOverrides() を呼び出すだけで、 すべての変更をリセットできます。

public void ResetToDefault()
{
    actions.RemoveAllBindingOverrides();
    PlayerPrefs.DeleteKey(SaveKey);
}

リセット後は、
・表示テキストの更新
・Action Map の再有効化
を忘れずに行いましょう。

9-4. PlayerPrefs以外の保存方法は？

小〜中規模のゲームであれば、 PlayerPrefs + JSON で十分実用的です。

ただし、
・クラウドセーブと連携したい
・ユーザーごとに複数スロットを持ちたい
といった場合は、 JSON をファイルとして保存する設計も検討するとよいでしょう。

次の章では、実装の仕上げとして、 キーコンフィグでハマりやすい注意点をまとめます。 ここを知っているかどうかで、完成度がかなり変わります。

10. 実装でハマりやすいポイントと対策

キーコンフィグは「動いたら終わり」ではなく、
実際に触られたときに破綻しないかがとても重要です。

この章では、Input System を使ったキーコンフィグ実装で よくある落とし穴と、その対策をまとめておきます。 事前に知っておくだけで、かなり安心感が違いますよ。

10-1. 同じキーを複数のアクションに割り当ててしまう

Input System では、同じキーが複数のアクションに割り当てられていても、 基本的にはエラーになりません。

その結果、
「攻撃とジャンプが同時に発動する」
といった事故が起こることがあります。

対策としては、リバインド完了時に すべてのアクションの effectivePath をチェックし、 重複があれば警告を出す、または上書き禁止にする方法が一般的です。

10-2. RebindingOperation を Dispose し忘れる

何度も触れてきましたが、これは本当に多いミスです。

RebindingOperation はアンマネージドリソースを使うため、 Dispose を呼ばないとメモリリークにつながります。

完了・キャンセルの両方で 共通の後片付け処理を用意しておくことで、 ほぼ確実に防げます。

10-3. Binding Index がズレる問題

Binding のインデックスは、 デバイスの接続状況や構成変更で 予想外にズレることがあります。

特に、
・未接続の Gamepad 用 Binding
・Composite Binding の子要素
は影響を受けやすいポイントです。

可能であれば、 固定の数値ではなく Binding 名やグループ名から取得する実装にしておくと、 事故が起きにくくなります。

10-4. リバインド中に意図しない入力が入る

マウス移動やスティックの微妙な入力で、 勝手にリバインドされてしまうこともあります。

これは、 WithControlsExcluding() を使って あらかじめ除外しておくことで防げます。

また、入力待ち中は Action Map を切り替えて ゲームプレイ側の入力を完全に止めるのも有効です。

10-5. UIと実装がズレてくる

実装が進むにつれて、 「UIではキーボード用なのに、中身はパッドをいじっていた」 みたいなズレが起こりがちです。

UI の各行が どの InputAction / どの Binding を触っているのか を、スクリプト上でも明示しておくと、 後から修正しやすくなります。

次はいよいよ最後です。
記事全体を振り返りつつ、 実務目線でのまとめをしていきましょう。

まとめ

この記事では、Unity の 新しい Input System を使って、 ゲーム内でキーコンフィグ（操作割り当て変更）を実装する方法を、 基本から実践レベルまで一通り解説してきました。

キーコンフィグは後回しにされがちな機能ですが、
実際にはプレイヤー体験やアクセシビリティに直結する、 とても重要な要素です。

この記事のポイントおさらい

• Input System では PerformInteractiveRebinding() で実行時リバインドができる
• Action Map の切り替えで、リバインド中の誤操作を防げる
• RebindingOperation は必ず Dispose() する
• Composite Bindings（WASDなど）は子バインディングを順番に扱う
• 設定は JSON として保存・ロードでき、リセットも簡単

実装を一通り経験すると分かりますが、
Input System のキーコンフィグは 「仕組みさえ理解できれば、あとは組み立て」 というタイプの機能です。

もし、
「自前実装が大変そう」
「デバイス対応をもっと楽にしたい」
という場合は、 専用アセットを使うのも立派な判断だと思います。

Rewired はその代表例で、 キーコンフィグや複数デバイス管理を かなりシンプルにしてくれます。

Rewired
✅ Unity Asset Storeでチェックする

ぜひ今回の内容をベースに、 自分のゲームに合ったキーコンフィグを作ってみてください。 触り心地が変わるだけで、ゲームの完成度が一段上がりますよ 😊

あわせて読みたい

キーコンフィグの実装とあわせて理解しておくと、 入力まわりや UI の設計がぐっと楽になる記事をまとめました。 必要なところから読んでみてください。

• Unity 2023でInput Systemが動かない時の対処法【旧Inputとの互換性も解説】
• Unityの使い方⑪ UI（ユーザーインターフェース）を作ってみよう
• Unityの使い方⑫ TextMeshProで日本語を表示できるようにしよう
• 【実践】UnityでJSONデータ管理！セーブ＆ロードを最適化する方法
• Unityのデータ管理を最適化！SerializableとScriptableObjectの違いと活用法

入力・UI・データ保存はそれぞれ独立したテーマですが、 組み合わさることで初めて「使いやすい設定画面」になります。 気になるところから少しずつ理解を深めてみてくださいね。

参考文献

• Unity公式マニュアル： Input System における Action と Binding の基本構造
• 技術ブログ： Unity Input Systemでキーコンフィグ（リバインディング）を実装する方法
• note： Unity Input SystemのRebinding実装メモ
• 個人ブログ： Unity 新Input Systemの基本と実践
• YouTube（Unity公式）： Introduction to the New Input System
• YouTube： Runtime Key Rebinding with Unity Input System
• YouTube： Unity Input System Rebinding Tutorial
• YouTube： Building a Keybinding Menu in Unity
• Qiita： Unity Input Systemでキー割り当てを変更する方法
• 技術ブログ： Unity Input SystemのRebinding実装時の注意点
• Unity公式マニュアル（旧Input）： 従来の Input Manager（旧Input System）について

本記事は、上記の公式ドキュメントや技術記事を参考にしつつ、 実務での実装経験を踏まえて内容を整理しています。 Input System の仕様は更新されることもあるため、 気になる点は公式マニュアルもあわせて確認してみてください。

よくある質問（FAQ）

関連記事:

Hearts of Iron風ゲームを作るなら！おすすめのUnityアセット Unityでメモリリークを防ぐ！C#のDisposeパターンとイベント管理の極意 Unityの使い方㉑新Input Systemの使い方完全ガイド｜キーボード・ゲームパッド・スマホ対応！ 【Unity】初心者向け2Dアクションゲームを作ろう②｜プレイヤーのアクション