UE5 の旧入力から Enhanced Input へ移行する手順

途中まで作ったプロジェクトや、古い解説を見ながら組んだ入力処理を Unreal Engine 5 (UE5) の Enhanced Input へ移す作業には、機械的に置き換えられる部分と、考え方から見直す必要がある部分が混在しています。この記事では、旧 Input Mappings が Enhanced Input のどこに対応するのかを整理したうえで、実際の手順と起きやすいトラブルの原因を扱います。

1なぜ移行するのか

旧来の入力システムは、Project Settings の Input カテゴリにある Action Mappings と Axis Mappings で設定するものでした。UE5 では Enhanced Input が標準となり、旧 Bindings のセクションには非推奨である旨の表示が出ます。当面は動作しますが、公式ドキュメントもテンプレートも新しい情報はすべて Enhanced Input 前提で書かれるため、旧方式のままでは参照できる資料が急速に減っていきます。

機能面の差も小さくありません。旧方式では自作コードが必要だった「長押し判定」「入力体系の切り替え」「入力値の加工」が、設定だけで実現できます。移行の手間はかかりますが、その後の追加実装は明確に軽くなります。

2対応関係を先に押さえる

移行作業のほとんどは、旧設定の各項目をどこに書き換えるかという単純作業です。まず対応表を頭に入れておくと迷わず進められます。

3移行の手順

いきなり全部を書き換えるのではなく、機能のまとまりごとに置き換えて都度動作確認するのが結果的に早道です。

1. 現状の棚卸しをします。Project Settings の Input を開き、Action Mappings と Axis Mappings の一覧を書き出します。名前・キー・Scale をメモしておけば、そのまま移行後のチェックリストになります。
2. Enhanced Input が使える状態か確認します。プラグインが有効か、既定クラス（Player Input Class / Input Component Class）が Enhanced Input 用かを確認します。古いプロジェクトでは旧クラスのままのことがあります。
3. Input Action を作ります。棚卸しした一覧をもとに、対応表に従って Value Type を決めます。前後と左右の Axis Mapping は、この段階で1つの Axis2D にまとめる判断をします。
4. Input Mapping Context を作ります。まずは IMC_Default のような1つのコンテキストに、旧設定と同じキー割り当てをすべて入れます。分割は後からでもできます。
5. Modifier と Trigger を設定します。Scale の負値を Negate に、倍率を Scalar に置き換えます。Axis2D にまとめたキーには Swizzle Input Axis Values を追加します。
6. Mapping Context を適用する処理を追加します。ブループリント (Blueprint) なら BeginPlay で Enhanced Input Local Player Subsystem を取得し、Add Mapping Context を呼びます。旧方式にはなかった工程で、忘れると全部が無反応になります。
7. イベントノードを1つずつ差し替えます。旧 InputAction / InputAxis ノードから伸びている処理を、新しいイベントノードにつなぎ替えます。1機能ずつ動作確認し、済んだら旧ノードを削除します。
8. 旧設定を削除します。すべての差し替えが終わったら、Project Settings の Action Mappings / Axis Mappings を空にします。

4Axis Mapping の統合が最大の作り替えポイント

単純な置き換えでは済まないのがここです。旧方式では MoveForward と MoveRight という2つの Axis Mapping を作り、それぞれ独立した float として受け取っていました。そのまま Axis1D の Input Action を2つ作っても動きますが、Enhanced Input の利点をほとんど捨てることになります。

Axis2D 1つに統合すると、キーボードとゲームパッドのスティックを同じ Input Action に同居させられます。スティックは元から2軸の値を出すため、Modifier なしで割り当てるだけです。受け取り側は Vector2D を1回受け取るだけになり、2つに分かれていた処理を1か所にまとめられます。

統合時のキーごとの Modifier は次のとおりです。キーが生む値は既定で X 成分に入るため、前後方向は Swizzle Input Axis Values で Y 成分へ移す必要があります。

Modifier は並べた順に上から適用されます。S のように2つ付ける場合は、順序が違うと結果が変わります。「効いているはずなのに方向がおかしい」ときは、まず並び順を疑ってください。

5Pressed / Released の置き換え

旧 InputAction イベントノードには Pressed と Released の2つの実行ピンがありました。Enhanced Input のイベントノードにはこの名前のピンはなく、代わりに Started / Ongoing / Triggered / Completed / Canceled が並びます。対応のさせ方は2通りあり、どちらでも動きます。

どちらでもかまいませんが、プロジェクト内で方針を統一しておくと後から読みやすくなります。複数人で作業する場合、同じ意味の実装が2種類混在すると混乱のもとです。

6つまずきやすい点

最後の項目は移行作業と無関係に見えて、実際には移行のタイミングで表面化することがあります。ウィジェット (Widget) の表示前後で挙動が変わるなら、「Set Input Mode」の種類と使い方 と SetInputMode_UIOnlyを取り消す方法 を確認してください。メニューを閉じるキーが効かない場合は Blueprintで「Esc」キーを使ってイベントを発生させる方法 も参考になります。

7移行を機に設計を見直す

せっかく手を入れるので、旧設定をそのまま写すだけで終わらせず、Enhanced Input ならではの構成に整えておくと後が楽です。とくに効果が大きいのが Input Mapping Context の分割です。

Input Action の命名も見直しどきです。旧方式では MoveForward のようにキーの向きに近い名前を付けがちでしたが、IA_Move のようにゲーム内の意味で名付けたほうが、キー割り当てを変えたときのずれが起きません。あわせて Input フォルダにアセットをまとめるなど、置き場所のルールも決めておくとよいでしょう。

移行そのものは地味ですが、一度終えれば以後の入力まわりの追加実装は明らかに短く済みます。アニメーション関連の新しい仕組みを試すときにも足回りが整っている必要があるので、Motion Matchingの導入と必要なプラグイン のような機能に進む前に片付けておくことをおすすめします。