【Django】Djangoでよく出るエラーと解決法まとめ

Django
2025.07.16

こんにちは、かつコーチです。

Djangoを学び始めると、赤い画面いっぱいに英語のエラーメッセージが表示されて、何をどう直せばいいのか分からなくなることがよくあります。
筆者自身、最初の1ヶ月は「エラー画面が出るたびにコピペで検索する」を繰り返していました。

この記事では、Django学習の序盤でとくに遭遇しやすいエラーを取り上げ、原因と対処法をセットでまとめます。
エラーメッセージを読む力がつくと、検索に頼らず自力で解決できる場面が一気に増えます。

エラーメッセージの読み方の基本

Djangoのエラー画面（デバッグページ）の見方

DEBUG=Trueの状態でエラーが起きると、Djangoはトレースバック（エラーが発生するまでの処理の流れ）を表示してくれます。
一番下に書かれている行が、実際にエラーを引き起こした核心部分であることが多いです。

慣れないうちは画面全体を読もうとして混乱しがちですが、まずは以下の2点だけ確認する癖をつけましょう。

  • 画面上部のエラーの種類と一言メッセージ（例：OperationalErrorなど）
  • 一番下のファイル名と行番号（自分のコードのどこで起きたか）

エラーの種類を大きく3つに分類する

Djangoのエラーは、ざっくり次の3つに分類できます。

分類特徴例
構文・記述ミスPythonの文法エラーSyntaxError、IndentationError
設定・環境系アプリ起動時の設定不備ImproperlyConfigured
データベース系モデルとDBの不整合OperationalError、DoesNotExist

よくあるつまずきポイント・エラー対処

TemplateDoesNotExist

❌Before

TemplateDoesNotExist at /
blog/index.html

テンプレートファイルの場所が正しく設定されていない、または実際にファイルが存在しない場合に出ます。
筆者は最初、templatesフォルダの中にさらにアプリ名のフォルダを作るというルールを知らず、直接HTMLファイルを置いてしまい、このエラーにハマりました。

✅After

myapp/
  templates/
    myapp/          ← アプリ名のフォルダを挟む
      index.html

settings.pyのAPP_DIRSがTrueになっていれば、この構成で自動的に見つけてもらえます。

TEMPLATES = [
    {
        "BACKEND": "django.template.backends.django.DjangoTemplates",
        "APP_DIRS": True,  # ここがTrueになっているか確認
        ...
    },
]

NoReverseMatch

❌Before

NoReverseMatch at /blog/
Reverse for 'detail' not found. 'detail' is not a valid view function or pattern name.

{% url 'detail' %}のようにテンプレートやビューでURL名を指定したものの、urls.pyのnameと一致していない場合に発生します。

✅After

# urls.py
urlpatterns = [
    path("post/<int:pk>/", views.post_detail, name="post_detail"),  # nameを明示する
]

<!-- テンプレート側もnameと完全一致させる -->
<a href="{% url 'post_detail' pk=post.pk %}">詳細へ</a>

引数（pkなど）の数が合っていないケースでも同じエラーが出るので、urls.py側の<int:pk>とテンプレート側の引数の数を必ず見比べましょう。

CSRF verification failed

❌Before

Forbidden (403)
CSRF verification failed. Request aborted.

フォームを送信したときに出る代表的なエラーです。
<form>タグの中に{% csrf_token %}を書き忘れていることがほとんどです。

✅After

<form method="post">
    {% csrf_token %}
    <!-- 入力フィールド -->
    <button type="submit">送信</button>
</form>

OperationalError: no such table

❌Before

django.db.utils.OperationalError: no such table: blog_post

モデルは定義したものの、マイグレーションを実行していない場合に出ます。
筆者もモデルを追加した直後にこのエラーを見て、「モデルを書いただけではDBに反映されない」ことを実感しました。

✅After

python manage.py makemigrations
python manage.py migrate

モデルを変更するたびに、この2つのコマンドをセットで実行する習慣をつけましょう。

応用・一歩先の使い方

エラーメッセージを検索するときのコツ

エラーメッセージをそのまま検索するときは、自分の変数名やファイル固有の部分を除いて検索するのがコツです。
例えばblog_postのような自分がつけたテーブル名は消して、OperationalError: no such tableの部分だけで検索すると、より的確な情報にたどり着けます。

DEBUG=Falseにしたときのエラー画面にも慣れておく

本番環境（DEBUG=False）では、詳細なエラー画面の代わりに簡素な500エラーページが表示されます。
開発中に見ていた親切なエラー画面がなくなるため、ログ出力の設定をあらかじめ整えておくことが重要です。

まとめ

この記事のポイント

  • エラー画面は上部の「種類」と下部の「発生行」をまず確認する
  • TemplateDoesNotExistはテンプレートのフォルダ構成ミスが多い
  • NoReverseMatchはURL名や引数の不一致が原因
  • CSRF verification failedは{% csrf_token %}の書き忘れ
  • OperationalErrorはマイグレーションのし忘れが典型パターン

次に読むべき記事

より踏み込んだトラブルとして、複数人開発で起きやすい「makemigrationsが競合して困った話と対処法」もあわせてチェックしてみてください。

タグ: Django, 初心者向け, エラー解決

タイトルとURLをコピーしました