スキルアップ

Djangoのviews.pyでリクエストとレスポンスの制御

はじめに

DjangoでWebアプリ開発を始めるとき、
バックエンド側の根幹を担うのが views.py です。

しかし、はじめて触れてみると、

  • このファイルに何を書けばいいのか
  • テンプレートとの違いがよく分からない

と戸惑ってしまうことも少なくありません。

views.pyは、ユーザーからのリクエストを受け取り、
適切なレスポンスを返す司令塔 のような役割を持ちます。

テンプレートとしてのHTMLを表示させるのも、
フォームから送られたデータを処理するのも、
最終的にはこのViewの中で決定されます。

この記事では、views.pyの基本的な役割や、
私が学習する中でつまずいたポイント、
実際の具体的な書き方などをまとめて紹介していきます。

この記事はこんな方におすすめです！

  • DjangoのViewが何をしているのかまだ曖昧な方
  • HTML（Template）は作れるけど、
    処理の流れが理解できていない方
  • 実際のWebアプリを動かすために、
    views.pyの基礎を固めたい方

第1章：views.pyの役割

まず、DjangoはMTVモデルと呼ばれる仕組みで動いています。

  • Model：
    データベースとのやり取りを担当
  • Template：
    ユーザーに見せる画面（HTML）を担当
  • View：
    処理の流れをコントロールする司令塔

この中で views.py が担うのは、
ユーザーのリクエストを受け、適切な処理を行い、
その結果をレスポンスとして返す部分です。

1. リクエストとレスポンスの橋渡し

Webアプリの基本的な流れはシンプルです。

  • ユーザーがURLにアクセスする
    （リクエストを送る）
  • Djangoがurls.pyを見て
    「どのViewを呼ぶか」を決定
  • Viewが必要な処理を行う
    （データ取得や計算など）
  • 処理結果をHTMLやJSONなどの
    レスポンスに変換して返す

このWebアプリの処理一連の流れの中で、
③と④を担うのがviews.pyです。

例えば「Hello Django!」と表示するだけのページを作る場合、
views.pyには次のように書きます。

from django.http import HttpResponse

def hello_view(request):
    return HttpResponse("Hello Django!")
  • ユーザーが /hello/ にアクセスすると、
    hello_view が呼び出されるように
    urls.pyに定義しておく
  • ここで文字列を直接レスポンスとして返すと、
    ブラウザにそのまま表示

とてもシンプルですが、これがViewの基本形です。

2. Templateとの関係

Webアプリとして作成する場合、
「Hello World!」のような文字列を直接返すのではなく、
テンプレート（HTMLファイル）を組み合わせて
画面を表示することがほとんどです。

そのため、Viewでは対象のテンプレートに
必要なデータをセットで受け渡す役割を担います。

from django.shortcuts import render

def signup_view(request):
    return render(request, 'signup.html')

この場合、Viewは
「signup.htmlというテンプレートを探して返す」
という役割を果たします。

テンプレートについては、
こちらで私の学習をもとに別記事にしていますので
参考にしてみてください。

DjangoのテンプレートでデータをHTMLに埋め込む

2025/9/12  

スキルアップ

3. 関数ベースビュー（FBV）とクラスベースビュー（CBV）

DjangoのViewには大きく2種類あります。

  • 関数ベースビュー（FBV）
    • 上の例のように
      Pythonの関数として書く形式
    • シンプルで理解しやすい
  • クラスベースビュー（CBV）
    • Djangoが用意したクラスを
      継承して作る形式
    • 例えば ListView や DetailView を
      使うと、記事一覧や記事詳細を
      少ないコードで実現できる

私は、まずポートフォリオの作成では
FBVでViewを作成しています。

私と同じようにPythonやIT自体未経験の場合、
FBVでまずは基本の流れを押さえて、
慣れてきたらCBVを学ぶと理解がスムーズになると思います。

第2章：つまずいたポイント

views.pyはDjangoアプリの中心的な存在です。

しかし、学習を始めたての頃は、
何を書けばよいかで迷いやすいです。
ここでは、私がつまずいたポイントを整理します。

1. ViewとTemplateの違いがあいまい

Viewという名前から画面表示（ビュー）だと思っていたため、
HTMLの画面表示に関わるものを、
views.pyとtemplatesのどちらに書けばいいのかが
最初はあいまいで、疑問も多い状態でした。

それぞれの役割として、

  • View：
    処理の流れを制御する場所
    （データを集めてテンプレートに渡す）
  • Template：
    見た目を担当する場所
    （データを画面に表示する）

例えば、ユーザー一覧を表示するときの処理の切り分けは、

  • Viewで「データベースからユーザーを取得」
  • Templateで「取得したユーザー名をリスト表示」

このように、処理と見た目を混ぜないことが
それぞれの役割を曖昧にせず、
つまずかないためのポイントです。

2. POSTデータが取得できない

画面からの操作でフォームを送信したとき、
バックエンド側でデータ操作をしたいのに、
そのデータがviews.pyで受け取れないという点もつまずきました。

典型的な誤りとして、

def signup_view(request):
    username = request.POST['username']  # KeyErrorが出る

この場合、フォームが送信されていない状態でも
request.POST['username'] を実行しており、
エラーが発生しています。

解決策としては、まず リクエストの種類を判定することです。

def signup_view(request):
    if request.method == "POST":
        username = request.POST.get('username')
        # データを使った処理
    return render(request, 'signup.html')

また、request.POST.get() を使うと、
キーが存在しない場合もエラーを出さずに
None を返すので安全です。

3. TemplateDoesNotExistエラー

ポートフォリオ作成のために、よく遭遇したのが
TemplateDoesNotExist というエラーです。

主な原因として、

  • テンプレートファイルの場所が間違っている
  • settings.pyの TEMPLATES['DIRS'] に
    パスを追加していない
  • アプリの templates/ フォルダ構成
    が正しくない

解消するために、意識したいポイントとして

  • app_name/templates/app_name/template.html のように
    アプリごとにtemplatesを作る
    （ベストプラクティス）
  • render関数の第2引数には、
    フォルダ構成に合わせた正しいパスを書く

4. HttpResponseとrenderの使い分け

Webアプリのレスポンスの返却方法として、
単純に文字列を返す HttpResponse と、
テンプレートを使う render の違いで混乱しがちでした。

  • HttpResponse：
    とてもシンプル、学習やテストに便利
  • render：
    テンプレートにデータを渡すときに使う、
    実際のアプリ開発ではほとんどこちら

学習初期やサンプルコードではまず
HttpResponse("Hello Django!") が多いですが、
ポートフォリオなど、実際のWebアプリを作る場合、
render() を最初から使うようにすると
スムーズに理解できます。

5. URLとViewの紐づけミス

単純ミスではありますが、
urls.pyで指定したView関数名と、
views.pyの関数定が一致しておらず
エラーの原因が迷宮入りしかけることもありました。

# urls.py
path('signup/', views.sign_up, name='signup')  

# views.py
def signup_view(request):  # 名前が一致していない
    ...

この場合、Djangoはurls.pyの定義をもとに、
views.pyの「sign_up」という関数を探します。
しかし、存在しないためエラーになります。

関数名のミスやスペル間違いは、
気を付けたいあるあるの落とし穴です。

第3章：実際のViews.pyの定義

views.pyの役割や注意点を理解したところで、
実際の定義のためのコードで振り返ってみます。

DjangoにおけるViewの基本から、
フォーム処理やクラスベースビュー（CBV）の使い方までを
段階的にまとめていきます。

1. テンプレートを使った画面表示

Webアプリのほとんどでは、
画面表示にHTMLテンプレートを使って画面を表示します。

from django.shortcuts import render

def index_view(request):
    return render(request, 'index.html')

この場合、Djangoは templates/index.html
を探して返します。

ただテンプレートを表示さえるだけではなく、
データをテンプレートに渡して、
そのデータで動的に画面の値を変えたい場合、
render関数の第三引数に受け渡したいデータを渡します。

def greet_view(request):
    context = {"name": "太郎"}
    return render(request, 'greet.html', context)

テンプレート側では、受け渡されたデータのキー名で
アクセスすることで値を利用可能です。

<p>こんにちは、{{ name }}さん！</p>

Viewがデータを集めてテンプレートに渡す
という役割を果たしていることがここでわかります。

3. GETとPOSTの処理

フォームからデータを送る場合、
リクエストの種類を判定する必要があります。

def signup_view(request):
    if request.method == "POST":
        username = request.POST.get("username")
        password = request.POST.get("password")
        # ユーザー登録処理をここで書く
        return HttpResponse(f"{username} さんを登録しました！")
    else:
        return render(request, 'signup.html')
  • GET：フォームを表示する
  • POST：送信されたデータを処理する

このように、リクエストの種類の条件分岐で
処理を切り替えるのがViewの典型的なパターンです。

4. 複数の処理を分けて管理

処理が増えると、1つのViewに全部書くのは非効率です。

  • 「入力フォームの表示」と「送信後の処理」を
    別のView関数に分ける
  • 「一覧表示」「詳細表示」「新規作成」など、
    役割ごとに関数を作る

例として、ブログアプリの一部を抜粋すると

def post_list(request):
    posts = Post.objects.all()
    return render(request, 'post_list.html', {"posts": posts})

def post_detail(request, post_id):
    post = Post.objects.get(id=post_id)
    return render(request, 'post_detail.html', {"post": post})

Viewを小さく分けると、可読性と保守性が向上します。

5. クラスベースビュー（CBV）の導入

Djangoには、よく使う処理を効率化するために
クラスベースビュー（CBV） が用意されています。

記事一覧を表示するためのListViewを参考にすると、

from django.views.generic import ListView
from .models import Post

class PostListView(ListView):
    model = Post
    template_name = 'post_list.html'
    context_object_name = 'posts'

urls.py側では、

from django.urls import path
from .views import PostListView

urlpatterns = [
    path('posts/', PostListView.as_view(), name='post_list'),
]
  • ListView を継承することで、
    Post.objects.all() の処理を自動で行う
  • DetailView, CreateView, UpdateView
    などもあり、同じように使える

まず関数ベースビュー（FBV）で
基礎を理解することが大事ですが、
実装の効率を上げていくために、
CBVを段階的に取り入れるのはありです。

第4章：まとめ

今回は、Djangoの views.py について基本を
私が学習した内容をもとに記事をまとめていきました。

views.pyは、バックエンド側の
アプリ全体の動きを決める役割です。

DjangoでWebアプリを作成する際に、
フロントエンドの画面側だけでなく、
バックエンドでのデータ操作も重要です。

そのためには、このviews.pyを押さえることが大切です。

ポートフォリオとしては、まずは簡単なViewからはじめ
次にフォーム入力を受け取って処理するViewを実装してみると、
Djangoらしい流れが理解できると思います。

Viewを理解すれば、
Djangoでできることの幅が一気に広がります。
実際に動かしながら学ぶことが、理解の近道です。

私もポートフォリオ用のWebアプリができたら
また記事にしていこうと思います。

  • この記事を書いた人

ニコ

元美容師、未経験からIT業界へ転職。
現在はIT企業でWEBシステム、
汎用業務システムのSEとして在籍！
趣味の筋トレ、スキルアップや副業など
社会人の総合量を磨く情報を発信。
170cm / 65kg / ライフタイムナチュラル

-スキルアップ