【Unity】ドアギミックの作り方完全ガイド｜自動ドア・鍵・パスワード認証まで解説

脱出ゲームやホラーゲームを作っていると、「ドアギミックってどう作ればいいんだろう？」と悩む場面、かなり多いですよね。

実際、ドアはただ開くだけではなく、

• 近づくと自動で開く
• 鍵を持っている時だけ開く
• パスワード入力でロック解除する

など、ゲームの進行や演出に深く関わることが多いです。

ただ、Unity初心者の頃はここでつまずきやすいんです。

• ドアが変な方向に回転する
• Triggerが反応しない
• UI入力と連携できない
• 動いたけど、あとから拡張できなくなる

……このあたり、私もかなりハマりました（笑）。

特に脱出ゲーム系は、「とりあえず開けばOK」では終わらず、あとから鍵・イベント・セーブデータと連動したくなることが多いんですよね。

だからこそ、最初の構造づくりがかなり大事です。

今回は、Unityでよく使われるドアギミックを、段階的に整理しながら作っていきます。

• 自動ドア
• 鍵付きドア
• パスワード認証ドア

この3つを中心に、Collider・Trigger・UI・状態管理まで含めて、実践で困りやすいポイントも一緒に整理していきます。

---

Unityのドアギミックは「親オブジェクト回転」が基本

Unityでドアを作る時、最初に覚えておきたいのが「ドア本体ではなく、親オブジェクトを回転させる」という考え方です。

ここを理解しておくと、自動ドア・鍵付きドア・パスワードドアなど、ほぼすべてのドアギミックへ応用できるようになります。

なぜDoor本体ではなく親を回転させるのか

初心者の頃によくあるのが、「DoorオブジェクトをそのままRotateする」という作り方です。

ただ、この方法だとかなり高確率でこうなります。

• ドアが中央から回転する
• 扉ではなく“回転板”みたいになる
• 蝶番（ちょうつがい）の動きにならない

これは、Cubeや3DモデルのPivot（回転基準点）が中央にあることが多いためです。

そこで使うのが「親オブジェクト」です。

たとえば、以下のような構造にします。

DoorManage
└ Door

この状態で、親の「DoorManage」を回転させると、子のDoorが一緒に動きます。

そして、DoorManageの位置を“ドアの端”に置けば、自然な開閉になるわけです。

実際、脱出ゲームやホラーゲームでも、この構造はかなりよく使われています。

DoorManage構造の作り方

まずはシンプルなCubeで試すのがおすすめです。

Hierarchyで以下を作成します。

1. Planeを作成
2. Cubeを作成して「Door」に変更
3. Empty Objectを作成して「DoorManage」に変更

次に、DoorをDoorManageの子にします。

DoorManage
└ Door

そのあと、DoorManageをドアの左端や右端へ移動します。

たとえば、CubeのScaleがX=2なら、X方向へ1くらいズラすと自然になりやすいです。

この状態でDoorManageを回転すると、「蝶番で開くドアっぽい動き」になります。

逆に、この構造を作らないまま進めると、あとで鍵システムやアニメーションを追加した時に修正が大きくなりがちです。

初心者がハマる回転軸ズレの原因

ここで注意したいのが、「Positionを(1,0,0)にすれば絶対OK」というわけではないことです。

これはCubeならうまくいきやすいのですが、3Dモデルを使う場合は事情が変わります。

なぜなら、モデルごとにPivot位置が違うからです。

特にアセットストア製モデルでは、

• 中央Pivot
• 左端Pivot
• 床基準Pivot

などバラバラなことがあります。

そのため、実践では以下を確認するクセを付けるとかなり楽になります。

• Pivot / Center の切り替え
• Local / Global の切り替え
• Sceneビューで回転軸位置を見る

私も最初の頃、「なんでドアが空中でプロペラみたいに回るの…？」となりました（笑）。

でも、原因のほとんどはPivotか親子構造です。

ここを理解すると、ドア以外にも、

• 引き出し
• レバー
• エレベーター
• 回転ギミック

などにも応用できるようになります。

---

Unity自動ドアの作り方｜Triggerで開閉する方法

ドアギミックの中でも、最初に作るなら「Trigger型の自動ドア」がかなりおすすめです。

理由はシンプルで、

• 構造が分かりやすい
• Colliderの理解が深まる
• 鍵システムへ発展しやすい

からです。

特に脱出ゲームでは、「プレイヤーが特定範囲へ入ったらイベント発生」という構造をよく使うので、ここでTriggerに慣れておくと後がかなりラクになります。

自動ドアはOnTriggerEnterがおすすめな理由

Unityには、衝突判定として主に2種類あります。

判定	特徴
OnCollisionEnter	物理的にぶつかる
OnTriggerEnter	範囲へ入ったことを検知

自動ドアの場合は、「触れた瞬間」よりも「近づいたら開く」のほうが自然なことが多いです。

そのため、基本は OnTriggerEnter を使うのがおすすめです。

Triggerを使う場合は、ドア側Colliderの「Is Trigger」にチェックを入れます。

また、Trigger判定では少なくとも片方にRigidbodyが必要です。

ここを忘れると、「コードは合ってるのに反応しない…」になりやすいです。

TriggerとCollisionの違いを整理したい場合は、こちらもかなり参考になります。

プレイヤーとドアのCollider設定

今回は、以下の構成で作ると分かりやすいです。

• Player
  • Collider
  • Rigidbody
• DoorTrigger
  • Collider（Is Trigger ON）

ここで初心者がよくやるミスが、「Door本体にTriggerを付ける」ことです。

もちろんそれでも動く場合はあります。

ただ、実践では「判定用オブジェクト」を分けたほうが管理しやすいです。

たとえばこんな感じですね。

DoorManage
├ Door
└ DoorTrigger

こうしておくと、

• 判定範囲だけ大きくする
• 見た目と判定を分離する
• あとで鍵判定を追加する

などがやりやすくなります。

特にホラーゲームだと、「少し離れた場所で勝手に開く演出」を作ることも多いので、Trigger範囲を独立できる構造はかなり便利です。

Coroutineでドアを開閉する流れ

ドア開閉はCoroutineで作るとシンプルです。

流れとしては、

1. ドアを回転して開く
2. 一定時間待機
3. 閉じる

という構造になります。

たとえば、こんなイメージです。

IEnumerator OpenDoor()
{
    // 開く

    yield return new WaitForSeconds(1f);

    // 閉じる
}

WaitForSeconds は「停止時間」を作るためのものです。

ここで誤解しやすいのですが、ドアの“回転速度”そのものを決めているわけではありません。

回転速度は、

• Rotate量
• Time.deltaTime
• 補間処理

などで変わります。

なので、「ドアが速すぎる！」となったら、待機時間だけでなく、回転処理側も確認してみてください。

ドアが動かない時のチェックポイント

もしドアが動かない場合は、まず以下を確認してみてください。

• Rigidbodyがあるか
• Is TriggerがONか
• スクリプトのアタッチ先がDoorManageか
• Colliderサイズが小さすぎないか
• Playerタグや名前判定が一致しているか

特に多いのが、「Door本体にスクリプトを付けてしまう」ケースです。

これをやると、中央回転になったり、想定外の軸で回ったりします。

また、CharacterControllerを使っている場合は、通常のRigidbody挙動と少し違うので、Trigger判定側の構成も確認してみてください。

---

Unity鍵システムの作り方｜ドアとアイテムを連動する

自動ドアが作れるようになると、次にやりたくなるのが「鍵付きドア」ですよね。

脱出ゲームではかなり定番のギミックですが、初心者の頃はここで設計が急に難しく感じやすいです。

というのも、単純なドア開閉だけではなく、

• アイテム取得
• 状態保存
• ドア側の判定

など、“複数の情報を連携する必要”が出てくるからです。

ただ、最初から難しく考えすぎなくて大丈夫です。

まずは「鍵を持っているかどうか」をboolで管理するところから始めると、かなり理解しやすくなります。

鍵システムはbool管理から始めればOK

初心者向けなら、最初はこんな感じで十分です。

public bool hasKey;

鍵を取得した時に、

hasKey = true;

へ変更します。

そして、ドア側でこう判定します。

if(hasKey)
{
    // ドアを開く
}

かなりシンプルですが、実は脱出ゲームの基礎構造はほぼこれです。

最初からInventoryシステムを完璧に作ろうとすると、

• Dictionary
• ID管理
• ScriptableObject
• セーブ連携

など、一気に難易度が上がります。

なので、まずは「フラグ管理」に慣れるのがおすすめです。

鍵を取得してドアを開ける流れ

基本の流れはかなりシンプルです。

1. プレイヤーが鍵を取得
2. hasKey を true にする
3. ドア接触時に判定
4. trueなら開く

たとえば、鍵オブジェクト側ではこんな感じになります。

private void OnTriggerEnter(Collider other)
{
    if(other.CompareTag("Player"))
    {
        player.hasKey = true;

        Destroy(gameObject);
    }
}

そしてドア側で、

if(player.hasKey)
{
    OpenDoor();
}

と判定します。

この構造を理解すると、

• 赤い鍵
• 青い鍵
• 特定イベント後だけ開くドア
• ボス撃破後に解放

などにも応用しやすくなります。

鍵アイテムの取得周りをもっと詳しく整理したい場合は、こちらの記事もかなり相性が良いです。

初心者がやりがちな危険設計

ここでありがちなのが、「全部Doorスクリプトに書く」設計です。

たとえば、

• 鍵取得
• UI表示
• SE再生
• アニメーション
• フラグ管理

を全部1つのスクリプトへ詰め込んでしまうケースですね。

これ、最初は動くんです。

でも、ドアが3個、10個、20個…と増えた瞬間にかなり苦しくなります。

特に脱出ゲームはギミック数が増えやすいので、「責務分離」を少し意識しておくと後で助かります。

また、Find() を大量に使うのも注意です。

最初は便利ですが、

• 名前変更で壊れる
• 参照ミスしやすい
• パフォーマンス低下

などの原因になりやすいです。

基本はInspector参照のほうが安定します。

中級者向け｜拡張しやすい管理方法

ドアギミックが増えてくると、boolだけでは管理しづらくなる場合があります。

そんな時によく使われるのが、

• GameManager
• InventoryManager
• ScriptableObject
• 鍵ID管理

です。

たとえば、

RedKey
BlueKey
BossKey

のようにIDで判定すると、複数ドア管理がかなりラクになります。

ただ、ここは最初から無理に導入しなくても大丈夫です。

まずは「ドアと状態フラグを連携できる」ことがかなり重要です。

実際、私も最初の脱出ゲームではboolだらけでした（笑）。

---

Unityパスワード認証ドアの作り方｜UI入力を連携する

脱出ゲームっぽさが一気に増すのが、「パスワード認証ドア」です。

ただ、このギミックは今までのドアと違って、

• UI
• 文字列判定
• 入力管理

が入ってくるため、急に難しく感じやすいポイントでもあります。

でも、仕組み自体はそこまで複雑ではありません。

基本は、

1. プレイヤーがドアへ接近
2. 入力UIを表示
3. 正解ならドアを開く

という流れです。

ここを順番に整理していきましょう。

InputFieldよりTMP_InputField推奨な理由

昔のUnity記事では、InputField がよく使われていました。

ただ、現在はTextMeshProベースの TMP_InputField を使うケースがかなり増えています。

理由はシンプルで、

• 文字表示がきれい
• 日本語対応しやすい
• Unity標準UIとして扱われやすい

からです。

特に脱出ゲームでは、数字入力やメモ表示など、UIを使う場面がかなり多いです。

なので、早めにTextMeshProへ慣れておくと後でラクになります。

もしTMP_InputFieldを触るのが初めてなら、こちらの記事もかなり参考になります。

パスワード入力UIの基本構造

まずはHierarchyで以下を作成します。

Canvas
└ PasswordPanel
    └ TMP_InputField

ここで重要なのは、「最初は非表示にしておく」ことです。

たとえば、ドアへ近づいた時だけ表示する形ですね。

そうすると、脱出ゲームっぽい自然な流れになります。

また、UIを使う時は EventSystem が必要です。

通常はCanvas作成時に自動生成されますが、削除してしまっていると入力が反応しません。

「入力欄をクリックできない…」という時は、かなり高確率でここです。

さらに、パスワード入力中はプレイヤー移動を止めることも多いです。

これをやらないと、

• 入力中にプレイヤーが動く
• ホラーゲームで壁へ埋まる
• カメラ操作が暴れる

などが起きやすくなります。

正しいパスワードだけドアを開ける方法

パスワード判定は、まずは文字列比較で十分です。

たとえば、

if(inputText == "1234")
{
    OpenDoor();
}

という形ですね。

ここで初心者が混乱しやすいのが、「数字なのにstringなの？」という部分です。

でも、InputFieldから取得する値は基本的に文字列です。

そのため、最初はstring比較で考えたほうが分かりやすいです。

また、成功時と失敗時でUI挙動を変えると、かなりゲームっぽくなります。

たとえば、

• 正解 → ドア開放＋UI閉じる
• 不正解 → エラー表示
• 数秒後に再入力可能

などですね。

この「フィードバック」があるだけで、プレイヤー体験がかなり変わります。

UIが表示されない時の原因

パスワードギミックで多いトラブルが、「UIが出ない」です。

まずは以下を確認してみてください。

• Canvasが有効か
• Panelが非表示のままになっていないか
• EventSystemが存在するか
• Inspector参照が切れていないか
• TMP_InputFieldを正しく参照しているか

特に多いのが、「SerializeFieldへオブジェクトを入れ忘れる」ケースです。

コード自体は合っていても、Inspector参照が空だと動きません。

また、TextMeshProを初めて導入した時は、TMP Essential Resourcesのインポートを求められる場合があります。

これをスキップすると、文字が表示されないこともあります。

UI周りは最初かなり混乱しやすいですが、逆にここを理解すると、

• 会話システム
• メモ入力
• 暗証番号
• 名前入力

など、一気に作れるものが増えていきます。

---

Unityドアギミックを自然に見せる調整方法

ドアギミックは、「動けば完成」というわけではありません。

実際は、開く速度や演出次第で、ゲームの空気感がかなり変わります。

特にホラーゲームや脱出ゲームでは、“ただのドア”なのに印象へ直結することも多いんですよね。

ここでは、ゲームっぽく見せるための調整ポイントを整理していきます。

開閉速度はどう決めるべき？

ドア速度は、ゲームジャンルによってかなり変わります。

ジャンル	おすすめ傾向
ホラー	ゆっくり重め
FPS	高速でテンポ重視
脱出ゲーム	中間くらい

たとえばホラーゲームでは、ドアが「ギィ…」とゆっくり開くだけでかなり雰囲気が出ます。

逆にFPSで毎回ゆっくり開くと、プレイヤーがストレスを感じやすいです。

なので、「リアルさ」だけでなく、“プレイテンポ”もかなり重要になります。

私も最初はリアル重視で遅くしていたんですが、テストプレイすると「遅すぎてイライラする」が意外と多かったです（笑）。

実際に触って調整するのがかなり大事ですね。

90度回転だけが正解ではない

初心者の頃は、「ドア＝90度回転」と考えやすいです。

もちろん基本としては正しいです。

ただ、ゲームによっては別の開き方のほうが自然なこともあります。

• 病院 → スライドドア
• 研究所 → 自動横開き
• 和風屋敷 → 引き戸
• 壊れたドア → 半開き

特にホラーゲームは、「完全に開かないドア」がかなり演出として強いです。

少しだけ開いて暗闇が見えるだけで、プレイヤーの緊張感が変わります。

また、回転角度を45度くらいに抑えるだけでも、“リアルな重さ”が出ることがあります。

なので、「90度固定」で考えすぎないのもポイントです。

SE・ライト・演出を追加すると没入感が変わる

ドア演出は、音を入れるだけでかなり印象が変わります。

たとえば、

• 金属ドア音
• 電子ロック解除音
• 警告ランプ点滅
• 開閉時の機械音

などですね。

特にパスワード認証ドアは、「正解音」があるだけでかなり気持ち良くなります。

逆に、無音だと「本当に反応した？」となりやすいです。

また、ライト演出もかなり相性が良いです。

• 赤 → ロック中
• 青 → 解放
• 点滅 → 異常状態

など、視覚的な情報を追加すると、プレイヤーが状況を理解しやすくなります。

Animatorを使うべきケース

ここまでは、主に Transform.Rotate ベースで説明してきました。

ただ、演出を強化したい場合はAnimatorもかなり便利です。

特に以下のケースでは相性が良いです。

• 複雑なモーション
• 複数パーツ連動
• 自動ドアの横スライド
• ロック解除アニメ
• カットシーン演出

逆に、単純な開閉だけなら、スクリプト回転のほうが軽くて管理しやすい場合もあります。

なので、

• 小規模脱出ゲーム → スクリプト回転
• 演出重視ホラー → Animator
• 商用レベル → 状況次第で使い分け

くらいで考えると分かりやすいです。

もし「もっと本格的なドア演出をラクに作りたい」という場合は、専用アセットを使う方法もかなり便利です。

Door System
✅アセットストアでチェックする

---

Unityドアギミックでよくある誤解と注意点

ドアギミックは、見た目以上に「Unityの基礎」がかなり詰まっています。

そのぶん、初心者の頃は同じ場所でつまずきやすいです。

ここでは、実際によくある誤解や、「最初に知っておくとラクになるポイント」を整理しておきます。

OnCollisionEnterが反応しない理由

かなり多いのが、「コードは合ってるのに反応しない」というケースです。

この原因で特に多いのが、

• Rigidbody不足
• Is Trigger設定ミス
• CollisionとTriggerの混同

です。

たとえば、OnTriggerEnter を使っているのに、Collider側の「Is Trigger」がOFFだと反応しません。

逆に、OnCollisionEnter を使っているのにTrigger化している場合も動きません。

また、Trigger系では少なくとも片方へRigidbodyが必要です。

ここを忘れると、かなりハマりやすいです。

特にCharacterControllerを使っている場合は、通常の物理挙動と少し違うため、Collider構成も確認してみてください。

Find頼りの設計は後で壊れやすい

初心者の頃は、

GameObject.Find("Door")

をかなり使いたくなります。

もちろん、最初の学習では便利です。

ただ、実践では注意も必要です。

なぜなら、

• 名前変更で壊れる
• 同名オブジェクトで誤取得する
• 大量使用で重くなる

などの問題が起きやすいからです。

特に脱出ゲームはオブジェクト数が増えやすいので、「なんで別のドアが開いたの！？」みたいな事故も起きやすいです（笑）。

基本はInspectorから参照するほうが安定します。

たとえば、

[SerializeField]
private DoorController door;

のような形ですね。

この方法なら、Scene上で直接対象を設定できます。

UpdateでRotateし続ける危険性

ドアを開閉する時、初心者の頃はこう書きがちです。

void Update()
{
    transform.Rotate(0, 1, 0);
}

これ、動きはします。

ただ、止める処理を書かないと、ドアが永遠に回転し続けます。

さらに、フレーム依存の問題も起きやすいです。

PC性能によって速度差が出たり、ガタついたりすることもあります。

そのため、実践では、

• Coroutine
• Quaternion.Lerp
• Animator

などを使うケースがかなり多いです。

特に「90度だけ回転したい」という場合は、現在角度を管理する考え方がかなり重要になります。

UIとゲーム操作が競合する問題

パスワード入力ドアで起きやすいのが、「UI入力中にプレイヤーも動いてしまう」問題です。

たとえば、

• Wキー入力で前進してしまう
• カメラが回転する
• FPS視点が暴れる

などですね。

特にFPSやホラーゲームでは、かなり違和感が出やすいです。

そのため、UI表示中は、

• プレイヤー操作停止
• Cursor表示
• Cursor.lockState変更

などを切り替えることが多いです。

逆に、ここを分離できるようになると、

• 会話システム
• インベントリ
• メニュー画面
• 設定画面

などもかなり作りやすくなります。

---

Unityドアギミックは「拡張しやすい設計」が重要

ドアギミックは、最初はシンプルでも大丈夫です。

むしろ、最初から全部入りを目指しすぎると、かなり高確率で混乱します。

おすすめは、段階的に作ることです。

1. 自動ドア
2. 鍵付きドア
3. パスワード認証ドア

この順番で進めると、Unityで重要な、

• Trigger判定
• 状態管理
• UI連携
• Coroutine
• オブジェクト参照

などを自然に理解しやすくなります。

特に脱出ゲーム制作では、「あとからギミック追加」がかなり多いです。

だからこそ、

• 親オブジェクトで回転管理する
• 判定用Triggerを分離する
• boolで状態管理を始める
• UIを独立させる

といった“拡張しやすい構造”を最初から意識しておくと、あとでかなり助かります。

逆に、最初に全部1つのスクリプトへ詰め込むと、ドアが増えた瞬間に管理が大変になりやすいです。

私も最初の頃は、DoorController.csが1000行近くなって、「どこで開いてるのか分からない…」状態になったことがあります（笑）。

でも、Trigger・UI・状態管理を少しずつ分離できるようになると、ゲーム制作がかなり楽しくなっていきます。

ドアギミックは一見地味ですが、実はUnityゲーム開発の基礎がかなり詰まった題材です。

ここを理解できると、

• レバーギミック
• 会話イベント
• エレベーター
• 監視カメラ
• スイッチ連動

などにも一気に応用しやすくなります。

まずは「ちゃんと開くドア」を1つ作るところから始めてみてください。

そこから少しずつ、ゲームらしい仕掛けが増えていく感覚は、かなり楽しいですよ 🙂

---

Unity学習を体系的に進めたい場合は、基礎から3Dゲーム制作を学べる入門書もかなり役立ちます。

楽しく学ぶUnity「3Dゲーム」作りのきほん
✅ Amazonでチェックする｜✅ 楽天でチェックする

---

参考文献・参考情報

• Unity公式ドキュメント（Collider / Trigger / Coroutine / UI）
• Unity Learn
• TextMeshPro公式ドキュメント

よくある質問（FAQ）