はじめに
「キー入力が反応しない」「ボタンを押しても何も起きない」
Unityを触っていると、一度はこの状態にハマります。
しかもやっかいなのが、
原因が1つじゃないことなんですよね。
- 設定ミスなのか
- コードの問題なのか
- Input Systemの仕様なのか
これが分からないと、延々と調べ続けることになります。
私も最初の頃は、
「昨日まで動いてたのに、なんで…?」って何時間も悩んだことがあります🙂
ただ実は、入力トラブルはある程度パターンが決まっています。
・よくある原因はほぼ固定
・チェックする順番も決まっている
つまり、正しい順番で確認すれば短時間で解決できるんです。
このあと、
- 最優先で確認すべきポイント
- 原因ごとの具体的な直し方
- 自分で原因を特定する判断基準
この3つを順番に整理していきます。
「とりあえず動かしたい」だけじゃなく、
次から自力で直せる状態まで持っていきましょう✨
結論:まず最初に確認すべき5つのポイント
原因を探す前に、まずここを確認してください。
この5つでほとんどの入力トラブルは解決できます。
- Active Input Handling が正しいか(旧Input / 新Inputの不一致)
- Input Systemの場合、ActionをEnableしているか
- Control Schemeが使用デバイスと一致しているか
- EventSystem(UI入力)が正しく設定されているか
- Input Debuggerで入力が検知されているか
ここで大事なのは、闇雲に直そうとしないことです。
まずは「どこまで正常か」を確認すると、一気に原因が絞れます。
入力が来ているかで切り分ける
Unityには「Input Debugger」という便利な機能があります。
これを使うと、キー入力がUnityに届いているかを確認できます。
- 入力が検知される → コードや設定の問題
- 入力が検知されない → デバイスやUnity設定の問題
この切り分けだけで、調査時間がかなり短縮できます。
よくある詰まりポイントの優先順位
実務的な体感だと、原因の多い順はこんな感じです。
- Input SystemのEnable忘れ
- Active Input Handlingの設定ミス
- Control Schemeの不一致
- EventSystemの設定ミス
- 環境・エディタの問題
特に最初の2つは本当によくあります。
「コードは合ってるのに動かない…」というときは、まずここを疑ってください。

このあと、原因ごとに「なぜ起きるのか」「どう直すのか」を具体的に見ていきます。
よくある原因7選
Input設定の競合
キーを押してもまったく反応しない場合、まず疑うべきなのがこれです。
Unityには「旧Input Manager」と「新Input System」があり、
この設定がズレていると入力は一切届きません。
たとえばこんなケースです。
- 新Input Systemを有効にしているのに
Input.GetKeyを使っている - 逆に旧Input前提のコードなのにInput Systemが有効になっている
この状態だと、コードが正しくても動きません。
解決方法はこちらです。
- メニューから「Edit」をクリック
- 「Project Settings」を開く
- 「Player」を選択
- 「Active Input Handling」を確認
設定は以下のどれかにします。
- Input Manager(旧のみ)
- Input System Package(新のみ)
- Both(両方)
初心者のうちは、どちらかに統一するのがおすすめです。
「Both」にすると一見便利ですが、
どっちの入力が使われているか分かりにくくなります。
注意点
- 設定変更後はUnityの再起動が必要です
- 再起動しないと変更が反映されません
再発防止のコツ
- プロジェクト開始時に入力方式を決める
- チーム開発なら必ず共有する

「全部動かない」系のトラブルは、かなりの確率でここが原因です。
まず最初にチェックしておくと、無駄な遠回りを防げます🙂
Input SystemでEnable()を忘れている
新Input Systemを使っているのに反応しない場合、かなり高い確率でこれです。
見た目は正しく設定されていても、
Actionを有効化していないと入力は一切届きません。
旧Inputでは意識しなくてよかった部分なので、ここでつまずく人はとても多いです。
よくある症状
- キーを押しても何も起きない
- エラーは出ていない
- 設定も正しそうに見える
この場合、「Enableしていない」可能性が高いです。
原因
- Input Actionは初期状態では無効
- 明示的に
Enable()を呼ぶ必要がある
解決方法
private void OnEnable()
{
inputAction.Enable();
}
private void OnDisable()
{
inputAction.Disable();
}
このように、OnEnable / OnDisableで管理するのが基本パターンです。
なぜこの書き方がいいのか?
- オブジェクトの有効状態と同期できる
- 不要な入力を防げる
- バグの原因になりにくい
逆に、StartやAwakeでEnableしてしまうと、
オブジェクトの状態とズレてしまうことがあります。
注意点
- 複数のActionを使う場合、それぞれEnableが必要
- Action Map単位でEnableする方法もある
再発防止のコツ
- Input処理のテンプレを作っておく
- 「動かない=まずEnableを疑う」と習慣化する
体感ですが、
「Input Systemが動かない問題の半分くらいはこれ」です。

設定やコードを疑う前に、一度ここをチェックしてみてください。
Control Schemeの設定ミス
「キーを押しているのに反応しない」場合、設定は合っているのに動かない…という状況になります。
このときよくあるのがControl Schemeの不一致です。
Input Systemでは、どのデバイスからの入力を受け取るかを「Control Scheme」で制御しています。
よくある症状
- キーボードは押しているのに反応しない
- ゲームパッドでは動くのにキーボードは動かない(または逆)
- 特定のキーだけ反応しない
原因
- Control Schemeに対象デバイスが含まれていない
- Bindingが違うデバイスに割り当てられている
つまり、
入力は届いているけど「無視されている」状態です。
解決方法
- Input Action Assetを開く
- 「Control Schemes」タブを確認
- Keyboard / Mouse / Gamepad が正しく設定されているかチェック
- 各ActionのBindingも確認する
特にBindingの設定は見落としやすいです。
- KeyboardなのにGamepadのBindingしかない
- キーが別の入力(例:ArrowキーではなくWASD)になっている
こういった状態だと、当然ですが入力は反応しません。
判断基準
- Input Debuggerで入力が検知される → ほぼControl SchemeかBindingの問題
注意点
- Control Schemeは複数作れるが、優先順位に注意
- PlayerInputを使う場合はAuto-Switch設定も影響する
再発防止のコツ
- 最初はシンプルに1つのControl Schemeだけにする
- デバイスごとに明確に分ける
「入力しているのに動かない」タイプのトラブルは、
かなりの確率でここに原因があります。

コードを疑う前に、まず設定をしっかり見直してみてください🙂
Input Action Assetの重複
入力が「効いたり効かなかったりする」場合は、このパターンを疑ってみてください。
Input Systemでは、同じInput Action Assetを複数のオブジェクトで使うと、
別ユーザーとして認識されて入力が分散することがあります。
よくある症状
- 同じキーなのに反応する時としない時がある
- 特定のオブジェクトだけ入力を受け取る
- シーンによって挙動が変わる
原因
- 同じInput Action Assetが複数のGameObjectにアタッチされている
- PlayerInputコンポーネントが複数存在している
この状態になると、Unity内部で「複数ユーザー」として扱われ、
入力がどこに届くか分散してしまいます。
解決方法
- シーン内のPlayerInputコンポーネントを確認する
- 同じInput Action Assetを使っているオブジェクトが複数ないかチェック
- 不要なものを削除するか、役割を分ける
確認方法(おすすめ)
- Window → Analysis → Input Debugger を開く
- 「Users」タブでユーザー数を確認する
意図しないユーザーが増えている場合、この問題の可能性が高いです。
注意点
- Prefabを複製したときに発生しやすい
- UI用とプレイヤー用で分けると安全
再発防止のコツ
- Inputの管理を1箇所に集約する
- PlayerInputの役割を明確にする
少し分かりづらいですが、
「入力が不安定」なときはかなり有力な原因です。

安定しない挙動が出たら、一度ここを疑ってみてください。
UIが反応しない
「ゲームのキー入力は動くのに、ボタンだけ押せない」
この場合はスクリプトではなく、EventSystemの設定を疑います。
特に新Input Systemを使っていると、ここでつまずくケースが多いです。
よくある症状
- ボタンをクリックしても反応しない
- ホバーや選択状態が変わらない
- UI操作だけ効かない
原因
- EventSystemが旧Input用のままになっている
- Input System用のUI Moduleが設定されていない
UnityのUIは、
専用の入力モジュールを通して操作される仕組みになっています。
そのため、新Input Systemを使っている場合は、
対応したモジュールに切り替える必要があります。
解決方法
- Hierarchyで「EventSystem」を選択
- Inspectorを確認
- 「Standalone Input Module」が付いていたら削除
- 「Input System UI Input Module」を追加
これでUIも新Input Systemに対応します。
判断基準
- キー入力は動くのにUIだけ動かない → ほぼこれが原因
注意点
- EventSystemはシーンに1つだけ必要
- 複数あると正常に動かないことがある
再発防止のコツ
- 新Input Systemを使うならUIも必ずセットで確認する
- テンプレートシーンを作っておくと安心

UIだけ動かない場合は、コードではなく設定を見るのが近道です。
ここをチェックするだけで一気に解決することも多いですよ🙂
Enter Play Mode設定の影響
「さっきまで動いていたのに、急に入力が効かなくなった」
こういう場合は、Unityのエディタ設定が原因のことがあります。
特に関係しているのが「Enter Play Mode Options」です。
よくある症状
- 再生するたびに挙動が変わる
- 入力が効いたり効かなかったりする
- スクリプトの状態がリセットされていない感じがする
原因
- Reload Domainが無効になっている
この設定をオフにすると再生が高速になりますが、
前回の状態がそのまま残るという特徴があります。
その結果、Inputの状態も正しく初期化されず、
予期しない挙動になることがあります。
解決方法
- メニューから「Edit」をクリック
- 「Project Settings」を開く
- 「Editor」を選択
- 「Enter Play Mode Options」を確認
- 「Reload Domain」をONにする
設定を戻したあと、再度再生して確認してください。
判断基準
- 再生するたびに挙動が変わる → この設定の可能性が高い
注意点
- Reload DomainをONにすると再生は少し遅くなる
- ただし安定性は大きく上がる
再発防止のコツ
- 原因が分からないときは一度ONに戻す
- 高速化設定は挙動を理解してから使う

便利な機能ですが、仕組みを知らないとハマりやすいポイントです。
「原因不明」のときほど、この設定を一度確認してみてください。
エディタや環境の問題
ここまで確認しても原因が分からない場合、
Unity本体やPC環境が影響している可能性もあります。
頻度はそこまで高くありませんが、
「最後のチェックポイント」として覚えておくと安心です。
よくある症状
- 原因が特定できない
- さっきまで動いていたのに突然動かなくなった
- プロジェクトを開き直すと直ることがある
考えられる原因
- Unityエディタの一時的な不具合
- キャッシュや内部状態の不整合
- 入力デバイスの認識トラブル
Unityはエディタ上で多くの状態を保持しているため、
長時間の作業や設定変更の積み重ねで挙動が不安定になることがあります。
解決方法
- Unityエディタを再起動する
- それでもダメならPCを再起動する
- USB機器(キーボード・ゲームパッド)を再接続する
シンプルですが、意外とこれで直ることがあります。
判断基準
- 原因が全く特定できない → 一度リセットしてみる
注意点
- 根本原因の解決にはならないこともある
- 頻発する場合は設定やコードを見直す必要がある
再発防止のコツ
- 長時間作業する場合は定期的に再起動する
- Unityのバージョンを安定版に保つ

「全部確認したのに分からない…」というときは、
一度環境をリセットしてみるのも現実的な選択です。
3分でできる診断チェックリスト
原因を1つずつ探すのが面倒なときは、上から順にチェックしていくのが一番早いです。
実際の開発でも、この順番で確認するだけでかなりの確率で原因が見つかります。
- □ Input Debuggerでキー入力が検知されているか
- □ Active Input Handlingの設定は正しいか
- □ Input SystemならActionをEnableしているか
- □ Control SchemeとBindingは合っているか
- □ EventSystemの設定は正しいか
- □ Unityを再起動したか
ポイントは、上から順にチェックすることです。
たとえば、入力自体が届いていないのにコードを直そうとしても意味がありません。
順番を間違えると、無駄に時間を使ってしまいます。
チェックのコツ
- 1つずつ確認して「OK / NG」を切り分ける
- 怪しいところは変更してすぐ再生して確認する
- 複数同時に変更しない(原因が分からなくなる)
デバッグを効率化したい場合は、コンソールや状態確認がしやすいツールを使うのもおすすめです。
SRDebugger – Console & Tools On-Device
✅アセットストアでチェックする

ログ確認や状態の可視化がしやすくなるので、
原因特定のスピードがかなり変わります。
入力の仕組み
原因を根本から理解したい場合は、入力の流れを知っておくとかなり楽になります。
Unityの入力は、次の順番で処理されています。
- デバイス(キーボード・ゲームパッド)
- Unityが入力を受け取る
- Input System(または旧Input)で処理
- Action(入力の定義)に変換
- スクリプトで使用
つまり、どこか1つでも詰まると、最終的に「入力が効かない」状態になります。
イメージするとこんな感じです
キーボード → Unity → Input System → Action → スクリプト
この流れを意識すると、原因の切り分けがとても簡単になります。
旧Inputと新Inputの違い
まず大きな違いは「入力の取り方」です。
| 項目 | 旧Input | 新Input System |
|---|---|---|
| 取得方法 | GetKeyなどで毎フレーム取得 | イベントで受け取る |
| 難易度 | シンプル | やや複雑 |
| 拡張性 | 低い | 高い(複数デバイス対応) |
旧Inputはシンプルで分かりやすいですが、
複数デバイス対応などは苦手です。
一方で新Input Systemは柔軟ですが、
設定が増える分、ミスも増えやすいという特徴があります。
初心者が混同しやすいポイント
入力トラブルでよくある勘違いを整理しておきます。
- Input Systemは設定すれば自動で動く → 実際はEnableが必要
- UIとゲーム入力は同じ仕組み → 実は別(EventSystemが必要)
- 一度動いたから設定は正しい → 状態が残っているだけの可能性あり
このあたりを理解しておくと、
「なんで動かないのか?」がかなり見えやすくなります。

少し抽象的に見えるかもしれませんが、
ここを理解するとトラブル対応のスピードが一気に上がりますよ🙂
どこが悪いか一瞬で判断する方法
入力トラブルは「全部を疑う」と時間がかかります。
実務では、最初に切り分けをして原因の範囲を一気に絞ります。
ポイントは「どこまで正常か」を見ることです。
Input Debuggerで切り分ける
まずはInput Debuggerを開いて、入力が届いているか確認します。
- Window → Analysis → Input Debugger
ここでキー入力が表示されるかを見てください。
- 入力が表示される → Unityまでは正常
- 入力が表示されない → デバイス or 設定の問題
この1ステップだけで、調査範囲が大きく変わります。
症状別の判断パターン
よくあるパターンを整理するとこんな感じです。
| 症状 | 原因の可能性 |
|---|---|
| 全く入力が効かない | Input設定・デバイス |
| UIだけ効かない | EventSystem |
| 特定のキーだけ効かない | Binding / Control Scheme |
| 効いたり効かなかったりする | Input Actionの重複 |
この表を頭に入れておくだけで、かなり早く原因にたどり着けます。
現場でよくある原因の割合
体感ベースですが、原因の多い順はこんな感じです。
- Enable忘れ
- Input設定の不一致
- Control Schemeのミス
- UI設定
- その他(環境など)
特に最初の2つは頻出です。
「コードが間違っているはず」と思い込むとハマりやすいので、
まず設定から疑うのがコツです。

この切り分けを覚えておくだけで、
入力トラブルの対応スピードはかなり変わります。
よくある誤解・注意点
入力トラブルは、思い込みが原因で解決が遅れることも多いです。
ここでは、特にハマりやすい誤解を整理しておきます。
一度動いたから設定は正しい
これはかなり危険な思い込みです。
Unityでは、前回の状態が残って動いているだけというケースがあります。
特にEnter Play Modeの設定やキャッシュの影響で、
本来は間違っているのに動いてしまうことがあります。
「昨日動いてたのに今日は動かない」は、むしろ自然な現象です。
とりあえずBothにしておけば安心
Active Input Handlingを「Both」にすると一見便利ですが、
入力経路が増えるため、原因の特定が難しくなります。
- どの入力が使われているのか分かりにくい
- 挙動が不安定になることがある
慣れないうちは、どちらか1つに統一するほうが安全です。
Input Systemは難しいからバグが多い
実際には、バグというより設定ミスが原因のことがほとんどです。
新Input Systemは柔軟な分、
- Enableが必要
- Control Schemeがある
- UIは別設定
といった要素が増えています。
つまり、「やることが増えた=ミスしやすい」というだけです。
コードを直せば解決すると思っている
入力トラブルの多くはコードではなく、設定が原因です。
特に初心者のうちは、
- コードを何度も書き直す
- でも原因は設定だった
というケースがよくあります。
まずは「設定 → 入力検知 → コード」の順で確認するのが近道です。
Unityのバグだと思い込む
もちろん可能性はゼロではありませんが、
実際にはかなり低いです。
ほとんどの場合は、
- 設定ミス
- Enable忘れ
- Control Schemeの不一致
といった基本的な原因に行き着きます。

最後まで原因が分からないときだけ、
環境やバージョンの問題を疑うようにすると効率的です。
まとめ
入力が効かないときは、原因を1つずつ潰していくよりも、
優先順位を決めて確認することが大切です。
まずはこの3つをチェックしてください。
- Input設定(Active Input Handling)は正しいか
- Input SystemならEnableしているか
- Control SchemeとBindingは一致しているか
この3つで、かなりの割合の問題は解決します。
そして次に重要なのが、
「どこまで正常か」を切り分けることです。
- Input Debuggerで入力が来ているか
- UIだけ動かないのか
- 特定のキーだけなのか
この判断ができるようになると、
原因特定のスピードが一気に上がります。
入力トラブルは一見複雑に見えますが、
実際はパターンが決まっています。
仕組みを理解しておけば、
次に同じ問題が起きても迷わず対処できるようになります。
少しずつで大丈夫なので、
「なぜそうなるのか」を意識しながら触っていくと、理解が深まりますよ🙂
よくある質問(FAQ)
- QInput Systemと旧Inputはどっちを使うべき?
- A
用途によって選び方が変わります。
- シンプルな操作だけ → 旧Inputの方が簡単
- キーボード・ゲームパッド・複数入力対応 → Input Systemがおすすめ
今後の拡張性を考えるなら、Input Systemを選ぶケースが増えています。
- QInput Debuggerで反応しているのに動かないのはなぜ?
- A
この場合は「入力は届いているけど使われていない」状態です。
- ActionがEnableされていない
- Control SchemeやBindingが間違っている
- スクリプト側で受け取れていない
まずはEnableとBindingを優先的に確認してください。
- Q急に入力が効かなくなった場合はどうする?
- A
次の順番で確認すると効率的です。
- 設定(Input HandlingやControl Scheme)
- Enable状態
- Unityの再起動
特に再起動で直る場合は、エディタの状態が影響している可能性があります。







※当サイトはアフィリエイト広告を利用しています。リンクを経由して商品を購入された場合、当サイトに報酬が発生することがあります。
※本記事に記載しているAmazon商品情報(価格、在庫状況、割引、配送条件など)は、執筆時点のAmazon.co.jp上の情報に基づいています。
最新の価格・在庫・配送条件などの詳細は、Amazonの商品ページをご確認ください。