「WASDで動かしたいだけなのに、なぜ設定するファイルが3つもあるのか」。UE5で入力を触りはじめた人が最初に感じる戸惑いは、だいたいこれです。UE4の頃はProject Settingsに1箇所書けば済んだのに、いまはInput ActionとInput Mapping Contextを作り、さらにBlueprintで登録する必要があります。
面倒に見えるこの分離は、後から効いてくる仕組みです。この記事では、Enhanced Inputの3つの部品を「やりたいこと」と「どのキーか」の分離として整理し、WASD移動とジャンプの組み方を解説します。最後の実践では、 車に乗り込んだ瞬間に操作系が丸ごと入れ替わる 仕組みを2ノードで作ります。
この記事でわかること
- Enhanced Inputの本質は 「やりたいこと（IA）」と「キー割り当て（IMC）」の分離
- IMCを有効にする窓口は Enhanced Input Local Player Subsystem
- WASD移動でつまずく原因No.1—— Swizzle Input Axis Values の役割
- Triggers（長押し・タップ）と Modifiers（反転・デッドゾーン）はアセット 側で設定できる
- 実践：車に乗った瞬間に 操作系を丸ごと差し替える
3つの部品と、その関係
Enhanced Inputを難しく感じる原因は、部品の数ではなく どれが何の担当か が最初は見えないことです。まず役割分担から整理します。
| 部品 | 担当 | ひとことで言うと |
|---|---|---|
| Input Action（IA） | 「ジャンプしたい」「移動したい」と いう やりたいこと の定義。キーの情報は持たない | やりたいことの名札 |
| Input Mapping Context（IMC） | 「ジャンプ＝Spaceキー」「移動＝WASD」という 割り当て表 | 操作表1枚 |
| Triggers / Modifiers | 「長押しで発動」「値を反転」など、 発動条件と値の加工 | 操作表に添える注釈 |
そしてもう1つ、Blueprintから触るものがあります。 Enhanced Input Local Player Subsystem は、「いま、どの操作表を使うか」を管理している窓口です。IMCを作っただけでは何も起きず、この窓口に Add Mapping Context で渡してはじめて有効になります。
なぜわざわざ分けるのか。答えは 操作表を1枚まるごと差し替えられるから です。徒歩用の操作表と運転用の操作表を用意しておけば、車に乗るときは表を取り替えるだけ。「Wキーの処理を運転モードかどうかで分岐させる」といったコードは一切要りません。
UE4の入力システムとの違い: UE4ではProject Settingsに全入力を書き、Blueprint側で
InputAction Jumpのようなイベントを直接受けていました。設定が1箇所にまとまるのは楽ですが、 状況に応じて操作を切り替える となると、コード側で細かく分岐するしかありませんでした。UE5では表そのものを差し替えます。
WASD移動とジャンプを組む
サードパーソンテンプレートを新規作成すると、これらは最初から組まれています。ですが 自 分で一度ゼロから作ると、どこで詰まるかが分かる ので、ここでは手で作ります。
ステップ1: Input Actionを2つ作る
コンテンツブラウザで右クリック → Input → Input Action を選び、2つ作ります。
| 名前 | Value Type | 理由 |
|---|---|---|
IA_Move | Axis2D (Vector2) | 前後と左右の2方向をまとめて受け取るため |
IA_Jump | Digital (Bool) | 押した／押していないの2択で足りるため |
Value Typeは後から変えると接続が外れるので、 最初に決めておく のがコツです。
ステップ2: Input Mapping Contextでキーを割り当てる
右クリック → Input → Input Mapping Context で IMC_PlayerControls を作り、開いて + でマッピングを追加します。
| Input Action | キー | Modifiers |
|---|---|---|
IA_Move | W | Swizzle Input Axis Values (YXZ) |
IA_Move | S | Swizzle Input Axis Values (YXZ) ＋ Negate |
IA_Move | A | Negate |
IA_Move | D | （なし） |
IA_Jump | Space Bar | （なし） |
ここが 最初の関門 です。なぜWとSにだけ変な設定が要るのか。理由はシンプルで、 キーボードのキーは押すと常にX軸に1.0を出す からです。
IA_Move はVector2（X＝左右、Y＝前後）を期待しています。ところがWキーを押しても、届くのは (1.0, 0.0) ——つまり「右へ1.0」です。これでは前に進みません。そこで Swizzle Input Axis Values（YXZ） で軸を入れ替え、(0.0, 1.0) ＝「前へ1.0」に直します。SキーはそこからさらにNegateで符号を反転させて「後ろへ1.0」に。AキーはX軸のままでよいので、Negateで反転するだけです。
つまずいたときの合言葉: 「WASDで動かない」の原因は、9割がこのModifier設定か、次のステップの
Add Mapping Context忘れです。
ステップ3: 操作表を有効にする
キャラクターBlueprint（BP_ThirdPersonCharacter など）の Event BeginPlay で、作った操作表をSubsystemに渡します。
Event BeginPlay
→ Get Player Controller
→ Get Enhanced Input Local Player Subsystem ← Player Controllerを繋ぐ
→ Add Mapping Context（Mapping Context: IMC_PlayerControls, Priority: 0）
ノードが見つからないとき: 「Cast to Enhanced Input Player Controller」というノードは 存在しません 。Player Controllerから伸ばして
Get Enhanced Input Local Player Subsystemを探してください（Get SubsystemからクラスにEnhancedInputLocalPlayerSubsystemを指定する形でも同じです）。
ステップ4: イベントを受けて動かす
イベントグラフで右クリックし、IA_Move と検索すると Enhanced Input Action IA_Move が出てきます。これがキー入力の受け口です。
Enhanced Input Action IA_Move
Triggered
→ Break Vector 2D（Action Value）
→ Add Movement Input（World Direction: Get Actor Forward Vector, Scale Value: Y）
→ Add Movement Input（World Direction: Get Actor Right Vector, Scale Value: X）
Enhanced Input Action IA_Jump
Started → Jump
Completed → Stop Jumping
Playすると、WASDで移動し、Spaceで跳べます。ここで イベントの出力ピンが4つある こと に気づいたはずです。よく使うのは次の3つです。
| ピン | いつ出るか | 使いどころ |
|---|---|---|
| Started | 押された瞬間に1回 | ジャンプ、単発の攻撃 |
| Triggered | 条件を満たしている間、毎フレーム | 移動、視点操作 |
| Completed | 入力が終わったとき | ジャンプを止める、チャージを解放する |
移動を Started に繋ぐと一瞬しか動かず、ジャンプを Triggered に繋ぐと押している間ずっと跳ぼうとします。 継続する動きはTriggered、単発はStarted と覚えてください。
TriggersとModifiers：ノードを増やさずに挙動を変える
Enhanced Inputで一番おいしいのがここです。「長押しで発動」「スティックの遊びを無視」といった調整を、 Blueprintに1ノードも足さずに IMC側の設定で済ませられます。
Triggers（いつ発動するか）
| Trigger | 動き | 使いどころ |
|---|---|---|
| Pressed | 押した瞬間 | 通常の攻撃、ジャンプ |
| Hold | 一定時間押し続けたとき | チャージ攻撃、長押しでメニュー |
| Tap | 素早く押して離したとき | ステップ回避、素早い切り替え |
| Chord Action | 別のIAと同時に押されているとき | L1+R1のコマンド |
Modifiers（値をどう加工するか）
| Modifier | 動き | 使いどころ |
|---|---|---|
| Dead Zone | 小さすぎる入力を切り捨てる | ゲームパッドのスティック |
| Negate | 符号を反転する | 後退、視点のY軸反転 |
| Swizzle Input Axis Values | 軸を入れ替える | キーボードのWASD |
| Scalar | 値を定数倍する | 視点感度の調整 |
スティックの遊び（Dead Zone）やトリガーの踏み込み量など、ゲームパッド特有の調整は ゲームパッド対応 にまとめています。
たとえば「Eキー長押しで扉を開ける」を作るとき、旧システムなら押した時刻を記録して毎フレーム経過時間を測る必要がありました。Enhanced Inputなら IA_Interact のマッピングに Hold Triggerを足し、Durationを1.0秒にするだけ。Blueprint側は Triggered を受けるだけで済みます。
実践：車に乗った瞬間に操作を丸ごと切り替える
Enhanced Inputの真価が出るのは、 操作系が複数あるゲーム です。オープンワールドの徒歩と運転、シューティングの通常時とスナイパースコープ、ホラーゲームの探索と一人称カメラ操作——どれも「同じキーに別の意味を持たせたい」場面です。
ここでは車の乗り降りを組みます。 Fキーで乗り込み、乗っている間はWASDが車の運転になり、Fキーで降りると徒歩に戻る 。これを分岐なしで実現します。
再現用の準備: 徒歩用に加えて、運転用のアセットを用意します。
| 種類 | 名前 | 設定 |
|---|---|---|
| Input Mapping Context | IMC_Driving | 運転用の操作表 |
| Input Action | IA_Accelerate | Axis1D (Float)。W＝そのまま、S＝Negate |
| Input Action | IA_Steer | Axis1D (Float)。D＝そのまま、A＝Negate |
| Input Action | IA_ToggleVehicle | Digital (Bool)。F キー。 両方のIMCに登録する |
| 変数（キャラクター） | bIsDriving（Boolean） | 初期値 false。状態の記録用 |
肝は IA_ToggleVehicle だけを両方の操作表に載せる ことです。乗っていても降りていても、Fキーは常に効いてほしいからです。
グラフはこうなります。
Enhanced Input Action IA_ToggleVehicle
Started
→ Get Player Controller → Get Enhanced Input Local Player Subsystem
→ Branch（Condition: bIsDriving）
False（＝いまは徒歩。乗り込む）
→ Remove Mapping Context（IMC_PlayerControls）
→ Add Mapping Context（IMC_Driving, Priority: 0）
→ Set bIsDriving（true）
True（ ＝いまは運転中。降りる）
→ Remove Mapping Context（IMC_Driving）
→ Add Mapping Context（IMC_PlayerControls, Priority: 0）
→ Set bIsDriving（false）
差し替えが効いたかどうかは、そのままでは目に見えません。運転用のアクションが入力を受け取れているかを確かめるために、IA_Accelerate に確認用のログを1つ挿しておきます。
Enhanced Input Action IA_Accelerate
Triggered
→ Print String（In String: Append("Accel: ", Action Value)）
これで、運転モードに入った後にWを押すと、画面に Accel: と数値が流れます。徒歩モードのときはこのアクションにキーが割り当たっていないので、Wを押しても数値は出ません。
Playしてキーを試してみてください。 Fを押す前はWASDで歩き、押した後はキャラクターが止まって（＝ IA_Move が呼ばれなくなり）、代わりにWで Accel: の数値が流れ、もう一度Fを押すとまた歩けるようになれば成功です 。
- Fを押しても何も変わらない →
IA_ToggleVehicleが片方のIMCにしか登録されていません - Fを押した後、Wで
Accel:が出ない →IMC_DrivingにIA_Accelerateを登録し忘れているか、Add Mapping Contextが実行されていません - 徒歩と運転が同時に効く →
Remove Mapping Contextが抜けています
ポイントは2つです。
- キャラクター側に「運転中か」の分岐が要らない: IMCが外れた瞬間に
IA_Moveのイベントは呼ばれなくなります。移動処理は一切いじりませ ん - 同じ仕組みがキーコンフィグになる: プレイヤーにキー配置を変えさせたいときも、書き換えるのはIMCの中身だけ。Blueprintのロジックは無傷です（→ キーコンフィグ（リバインド）を作る）
運転中もメニューを開きたい、のように 複数の操作表を同時に有効にしたい ときは Priority を使います。数字が大きいIMCが優先され、同じキーが競合したときに勝ちます。
おまけ：先に知っておくと良いこと
Enhanced Inputプラグインは既定で有効ですが、念のため確認を。 Edit → Plugins で "Enhanced Input" を検索し、チェックが入っているか見ておくと、「ノードが出てこない」で悩む時間を節約できます。
入力が来ているか自信がないときは、まずログを1つ。 IA_Move の Triggered に Print String を挿し、Action Value を繋いでみてください。数字が流れていればIMCの適用は成功していて、問題は移動処理側。何も出なければ Add Mapping Context かModifierの側です（→ Print Stringで値を確認する）。
IAの名前は「動詞」で付けると迷いません。 IA_Jump IA_Interact IA_Reload のように、 やりたいこと で名付けます。IA_SpaceKey のようにキー名を入れてしまうと、後でキー配置を変えたときに名前が嘘になります。分離の意味がなくなるので気をつけてください。
C++で書くとどうなるか。 個人開発では基本Blueprintで足りますが、既存のC++プロジェクトに組み込むこともあります。その場合は SetupPlayerInputComponent の中で UEnhancedInputComponent にキャストし、BindAction(MoveAction, ETriggerEvent::Triggered, this, &AMyCharacter::Move) のように IAと関数を結びつけます 。考え方はBlueprintとまったく同じで、「イベントの出力ピンを繋ぐ」代わりに「関数を登録する」だけの違いです。
まとめ
Enhanced Inputは、部品が増えた代わりに 操作系を「表」として扱えるようになった システムです。
| やりたいこと | 触る場所 |
|---|---|
| キー配置を変える | IMC（Blueprintは無変更） |
| 長押し・タップにする | IMCのTrigger（Blueprintは無変更） |
| 反転・デッドゾーン | IMCのModifier（Blueprintは無変更） |
| 操作系を丸ごと切り替える | Remove / Add Mapping Context の2ノード |
| 押したときの処理を変える | Blueprintのイベント |
表を見て分かるとおり、 入力まわりの変更のほとんどはBlueprintを触らずに済みます 。最初の設定こそ手数が多いものの、その後の変更はずっと軽くなります。
あなたのゲームには、いくつの「操作表」が必要でしょうか？