Flask Blueprint 入門：使い方を徹底解説

By /

Flask Blueprint 入門：使い方を徹底解説

はじめに：なぜBlueprintが必要なのか？

FlaskはPythonで書かれたマイクロフレームワークであり、そのシンプルさと柔軟性から人気があります。小規模なWebアプリケーションやAPIを迅速に開発する際には、一つのファイルにすべてのコードを記述しても問題ありません。しかし、アプリケーションが成長し、機能が増えていくにつれて、コードは肥大化し、管理が困難になります。

例えば、ユーザー認証機能、ブログ機能、管理機能など、複数の異なる機能を一つのファイルに詰め込んだ場合を想像してみてください。

  • コードの可読性の低下: ファイルが長くなり、何がどこにあるのか探しにくくなります。
  • 保守性の悪化: ある機能を修正する際に、他の機能に予期せぬ影響を与えてしまうリスクが高まります。
  • 再利用性の低さ: 作成した認証機能やブログ機能を別のアプリケーションで使いたいと思っても、他の機能と密結合しているため、簡単に切り出すことができません。
  • 開発効率の低下: 複数人で開発を行う場合、同じファイルを編集することによるコンフリクトが発生しやすくなります。

これらの課題を解決するために、FlaskにはBlueprintという機能が用意されています。Blueprintは、アプリケーションを再利用可能なコンポーネントに分割するためのメカニズムを提供します。これにより、大規模なアプリケーション開発をより効率的かつ効果的に行うことができるようになります。

この記事では、Blueprintの基本的な使い方から、詳細な設定、応用例、そして実践的なディレクトリ構成や注意点まで、Flask Blueprintを徹底的に解説します。

第1章：Blueprintとは？目的とメリット

1.1 Blueprintの定義

Flaskドキュメントによれば、Blueprintは「アプリケーションの構造化を支援する方法」です。Blueprintは、ルート、ビュー関数、テンプレートフォルダ、静的ファイルフォルダなどをまとめて定義することができます。しかし、Blueprintそのものは完全なアプリケーションではありません。Blueprintは、Flaskアプリケーションインスタンスに登録されることで初めて機能します。

例えるなら、Blueprintはアプリケーションという大きな建物を建てるための、設計図やプレハブ工場の部品のようなものです。部品単体では機能しませんが、建築現場（Flaskアプリケーション）に持ち込んで組み立てることで、建物の一部として機能します。

1.2 Blueprintを使う目的

主な目的は、前述した大規模アプリケーション開発における課題を解決し、以下のメリットを享受することです。

  • モジュラリティ（モジュール性）の向上: アプリケーションの機能を論理的に分割し、それぞれを独立したモジュールとして扱うことができます。例えば、auth（認証）、blog（ブログ）、admin（管理）などのBlueprintを作成し、それぞれの機能に関連するコードをそこに集約できます。
  • コードの整理と管理の容易さ: 各Blueprintが特定の機能に特化するため、コードが整理され、どこに何があるのかが分かりやすくなります。これにより、メンテナンスやデバッグが容易になります。
  • 再利用性の向上: Blueprintはアプリケーションインスタンスから独立しているため、一度作成したBlueprint（例: 認証Blueprint）を、異なるFlaskアプリケーションで再利用することができます。
  • 開発効率の向上: 複数人で開発を行う際に、各開発者が異なるBlueprintを担当することで、コンフリクトを減らし、並行開発を効率的に進めることができます。
  • URLの名前空間管理: BlueprintにURLプレフィックスを設定することで、そのBlueprint内の全てのルートに対して共通のプレフィックスを適用できます。これにより、URLの衝突を防ぎ、構造を明確にできます（例: /auth/login, /auth/register）。

第2章：Blueprintの基本的な使い方

Blueprintを使うための基本的なステップは以下の通りです。

  1. Blueprintオブジェクトを作成する。
  2. 作成したBlueprintオブジェクトを使ってルートやビュー関数を定義する。
  3. テンプレートや静的ファイルをBlueprintに関連付ける（必要に応じて）。
  4. メインのFlaskアプリケーションインスタンスにBlueprintを登録する。

これらのステップを順を追って見ていきましょう。

2.1 Blueprintオブジェクトの作成

まず、Blueprintオブジェクトを作成します。これはflask.Blueprintクラスをインスタンス化することで行います。

Blueprintクラスのコンストラクタは、最低限以下の2つの引数を取ります。

  • name: Blueprintの名前。アプリケーション全体で一意である必要があります。主に、このBlueprint内のエンドポイント名を生成する際のプレフィックスとして使用されます（例: auth.login, blog.index）。通常は、Blueprintを定義するPythonモジュールの名前（__name__）を使用するのが慣習です。
  • import_name: Blueprintが定義されているモジュールの名前。Flaskがテンプレートや静的ファイルなどのリソースを探す際に使用します。これも通常は__name__を使用します。

例：

“`python

project_root/app/auth/auth.py

from flask import Blueprint

‘auth’ という名前のBlueprintを作成

import_name として name を指定

bp = Blueprint(‘auth’, name)

後ほど、この bp オブジェクトを使ってルートを定義します

“`

2.2 ルートとビュー関数の定義

Blueprintオブジェクトを作成したら、それを使ってルートを定義します。使い方はFlaskアプリケーションインスタンスの時とほぼ同じです。@bp.route()デコレーターを使用します。

“`python

project_root/app/auth/auth.py

from flask import Blueprint, render_template

bp = Blueprint(‘auth’, name, url_prefix=’/auth’) # url_prefixを追加

@bp.route(‘/login’)
def login():
# ログインページのビュー関数
return ‘Login Page’

@bp.route(‘/register’)
def register():
# 登録ページのビュー関数
return ‘Register Page’

project_root/app/blog/blog.py

from flask import Blueprint, render_template

bp = Blueprint(‘blog’, name, url_prefix=’/blog’) # url_prefixを追加

@bp.route(‘/’)
def index():
# ブログ記事一覧ページのビュー関数
return ‘Blog Index Page’

@bp.route(‘/‘)
def post_detail(post_id):
# 特定のブログ記事ページのビュー関数
return f’Post {post_id}’
“`

上記の例では、auth Blueprintには/loginと/registerというルートが、blog Blueprintには/（/blog/に対応）と/<int:post_id>（/blog/1, /blog/2などに対応）というルートが定義されています。url_prefix='/auth'とurl_prefix='/blog'を指定しているため、それぞれのBlueprint内のルートは指定されたプレフィックス以下にマウントされます。

2.3 アプリケーションへの登録

Blueprintを定義しただけでは、まだWebサーバーからアクセスできません。メインのFlaskアプリケーションインスタンスにBlueprintを登録する必要があります。これにはapp.register_blueprint()メソッドを使用します。

通常、アプリケーションのファクトリ関数やアプリケーションインスタンスを生成する部分で、定義したBlueprintをインポートし、登録します。

“`python

project_root/app/init.py

from flask import Flask

各Blueprintをインポート

from .auth import bp as auth_bp # auth.pyからbpオブジェクトをauth_bpという名前でインポート
from .blog import bp as blog_bp # blog.pyからbpオブジェクトをblog_bpという名前でインポート

def create_app():
app = Flask(name)
# アプリケーションの設定などをここで行う（例: app.config.from_object(‘config.Config’))

# Blueprintをアプリケーションに登録
app.register_blueprint(auth_bp)
app.register_blueprint(blog_bp)

# 必要に応じて、メインのルートを定義することも可能
@app.route('/')
def index():
    return 'Welcome to My App!'

return app

アプリケーションを実行するためのファイル (e.g., run.py)

project_root/run.py

from app import create_app

app = create_app()

if name == ‘main‘:
app.run(debug=True)
“`

この例では、create_appというアプリケーションファクトリ関数内でFlaskインスタンスを作成し、その後register_blueprint()メソッドを使ってauth_bpとblog_bpを登録しています。auth Blueprintは/auth以下に、blog Blueprintは/blog以下にそれぞれマウントされます。

アプリケーションを起動し、以下のURLにアクセスしてみましょう。

  • http://127.0.0.1:5000/ -> Welcome to My App!
  • http://127.0.0.1:5000/auth/login -> Login Page
  • http://127.0.0.1:5000/auth/register -> Register Page
  • http://127.0.0.1:5000/blog/ -> Blog Index Page
  • http://127.0.0.1:5000/blog/123 -> Post 123

このように、Blueprintを使用することで、アプリケーションの異なる機能を分離し、整理されたコード構造を実現できます。

第3章：Blueprintでのテンプレートと静的ファイルの利用

Webアプリケーションでは、HTMLテンプレートを表示したり、CSSやJavaScriptなどの静的ファイルを提供したりすることが不可欠です。Blueprintでは、これらのリソースもそれぞれのBlueprintに関連付けて管理することができます。

3.1 テンプレートファイルの利用

デフォルトでは、Flaskアプリケーションはアプリケーションルートディレクトリ直下のtemplatesフォルダとその中のサブフォルダからテンプレートファイルを探します。Blueprintを使用する場合、Blueprintごとに独自のテンプレートフォルダを持つことができ、Flaskはそれを優先的に探します。

Blueprintに関連付けられたテンプレートフォルダは、Blueprintのtemplate_folderオプションで指定します。通常はBlueprintのPythonファイルと同じディレクトリにあるtemplatesサブフォルダを指定します。

例：

“`python

project_root/app/auth/auth.py

from flask import Blueprint, render_template

template_folder=’templates’ を指定

bp = Blueprint(‘auth’, name, url_prefix=’/auth’, template_folder=’templates’)

@bp.route(‘/login’)
def login():
# auth Blueprint の templates フォルダ内の login.html を探す
return render_template(‘login.html’)

@bp.route(‘/register’)
def register():
# auth Blueprint の templates フォルダ内の register.html を探す
return render_template(‘register.html’)

project_root/app/blog/blog.py

from flask import Blueprint, render_template

template_folder=’templates’ を指定

bp = Blueprint(‘blog’, name, url_prefix=’/blog’, template_folder=’templates’)

@bp.route(‘/’)
def index():
# blog Blueprint の templates フォルダ内の index.html を探す
return render_template(‘index.html’)

project_root/app/blog/templates/index.html (例)




Blog Index

Blog Posts

This is the blog index page from the blog Blueprint.


project_root/app/auth/templates/login.html (例)




Login

Login Page

This is the login page from the auth Blueprint.


“`

テンプレートファイルの探索順序:

render_template()関数がテンプレートファイルを探索する際、Flaskは以下の順序でディレクトリを探します。

  1. リクエストを処理しているBlueprintにtemplate_folderが指定されている場合、そのフォルダ。
  2. メインのFlaskアプリケーションインスタンスにtemplate_folderが指定されている場合（Blueprintとは異なる設定が可能）、そのフォルダ。
  3. アプリケーションルートディレクトリ直下のtemplatesフォルダ。

これにより、Blueprint内でrender_template('index.html')と記述した場合、そのBlueprintに属するtemplatesフォルダ内のindex.htmlが優先的に使用されます。もし見つからなければ、アプリケーション全体のtemplatesフォルダを探します。これにより、Blueprintごとにテンプレートを独立して管理したり、共通のテンプレートをアプリケーション全体のtemplatesフォルダに置いたりすることが可能になります。

サブディレクトリを使ってテンプレートを整理することも一般的です。例えば、auth Blueprintのテンプレートをapp/auth/templates/auth/に置く場合、render_template('auth/login.html')のようにパスを指定します。Blueprintのtemplate_folderをtemplatesとした場合、Flaskはapp/auth/templates/auth/login.htmlを探します。

3.2 静的ファイルの利用

CSS、JavaScript、画像などの静的ファイルも、Blueprintごとに管理できます。Blueprintに関連付ける静的ファイルフォルダは、Blueprintのstatic_folderオプションで指定します。通常はBlueprintのPythonファイルと同じディレクトリにあるstaticサブフォルダを指定します。

また、これらの静的ファイルにアクセスするためのURLパスは、static_url_pathオプションで指定できます。指定しない場合、デフォルトではstaticというパスになりますが、Blueprintの名前をプレフィックスとして付けるのが一般的です。

例：

“`python

project_root/app/blog/blog.py

from flask import Blueprint, render_template

static_folder=’static’ と static_url_path を指定

bp = Blueprint(‘blog’, name,
url_prefix=’/blog’,
template_folder=’templates’,
static_folder=’static’,
static_url_path=’/static/blog’) # このBlueprintの静的ファイルは /static/blog/ 以下になる

@bp.route(‘/’)
def index():
return render_template(‘index.html’)

project_root/app/blog/templates/index.html (例)




Blog Index
{# Blueprintの静的ファイルを参照する #}

Blog Posts

This is the blog index page from the blog Blueprint.


project_root/app/blog/static/style.css (例)

body {
background-color: lightblue;
}
“`

この例では、blog Blueprintの静的ファイルはapp/blog/static/フォルダに配置し、URL上では/static/blog/以下でアクセスできるように設定しています。

テンプレート内での静的ファイル参照 (url_for):

テンプレート内でBlueprintに属する静的ファイルを参照するには、url_for()関数を使用します。第一引数にはBlueprint名.staticという形式でエンドポイント名を指定し、第二引数にfilenameとして静的ファイルのパスを指定します。

例: {{ url_for('blog.static', filename='style.css') }}

これは、blog Blueprintの静的ファイルエンドポイントに対して、style.cssというファイル名を渡しています。Blueprintのstatic_url_path設定に基づき、Flaskは適切なURL（この場合は/static/blog/style.css）を生成します。

もしstatic_url_pathを指定しない場合、デフォルトは/staticとなりますが、複数のBlueprintがそれぞれstaticフォルダを持つと衝突する可能性があります。static_url_pathを使ってBlueprintごとに固有のパス（例: /static/auth, /static/blog）を設定するか、staticフォルダのサブディレクトリ名で区別する（例: app/static/auth/style.css, app/static/blog/style.cssとして、url_for('static', filename='auth/style.css')のように参照する）などの方法で衝突を避ける必要があります。Blueprintにstatic_url_pathを指定する方法が最も明確で推奨されます。

静的ファイルの探索順序:

url_for(blueprint_name.static, filename='...')を使って静的ファイルを参照した場合、Flaskは以下の順序でディレクトリを探します。

  1. 指定されたblueprint_nameを持つBlueprintにstatic_folderが指定されている場合、そのフォルダ。
  2. メインのFlaskアプリケーションインスタンスにstatic_folderが指定されている場合（Blueprintとは異なる設定が可能）、そのフォルダ（通常はアプリケーションルート直下のstaticフォルダ）。

Blueprintごとに静的ファイルを管理することで、各機能に必要なリソースをまとめて配置でき、コードがより整理されます。

第4章：Blueprintの詳細設定と応用

Blueprintは、ルート、テンプレート、静的ファイルだけでなく、より詳細な設定や様々な機能を持つことができます。

4.1 URLプレフィックス (url_prefix)

第2章でも少し触れましたが、Blueprintを登録する際にurl_prefix引数を指定すると、そのBlueprint内の全てのルートに対して指定した文字列がURLのプレフィックスとして追加されます。

“`python

project_root/app/auth/auth.py

bp = Blueprint(‘auth’, name, url_prefix=’/auth’)

@bp.route(‘/login’) # -> /auth/login
def login():
pass

project_root/app/blog/blog.py

bp = Blueprint(‘blog’, name, url_prefix=’/blog’)

@bp.route(‘/’) # -> /blog/
def index():
pass

@bp.route(‘/‘) # -> /blog/
def post_detail(post_id):
pass
“`

url_prefixを使うことで、各BlueprintのURL空間を明確に分離できます。これは、異なるBlueprintで同じパス（例: /や/listなど）を使いたい場合に特に便利です。

app.register_blueprint()メソッドにurl_prefixを指定することも可能ですが、通常はBlueprintを作成する際に指定する方が、Blueprint単体を見たときにどのURL空間に属するのかが分かりやすいため推奨されます。

4.2 サブドメイン (subdomain)

高度な使い方として、Blueprintを特定のサブドメインにマウントすることも可能です。これは、app.register_blueprint()メソッドにsubdomain引数を指定することで行います。

“`python

project_root/app/init.py

from flask import Flask
from .admin import bp as admin_bp

def create_app():
app = Flask(name)
app.config[‘SERVER_NAME’] = ‘myapp.com’ # SERVER_NAMEを設定する必要がある

# admin Blueprintを admin.myapp.com にマウント
app.register_blueprint(admin_bp, subdomain='admin')

return app

project_root/app/admin/admin.py

from flask import Blueprint

bp = Blueprint(‘admin’, name) # url_prefixは不要 (サブドメインで分離されるため)

@bp.route(‘/’)
def index():
return ‘Admin Dashboard’

@bp.route(‘/users’)
def users():
return ‘Admin Users List’

この例では、admin.myapp.com/ にアクセスすると Admin Dashboard が、

admin.myapp.com/users にアクセスすると Admin Users List が表示されます。

ただし、ローカル開発環境でサブドメインをテストするには、hostsファイルを編集するなどの設定が必要です。

“`

subdomainを使用する場合、アプリケーションのSERVER_NAME設定が必要になります。

4.3 エラーハンドリング (@bp.errorhandler)

アプリケーション全体のエラーハンドリングと同様に、Blueprint内でも特定のエラーハンドラーを定義できます。Blueprintで定義されたエラーハンドラーは、そのBlueprint内のビュー関数で発生したエラーに対してのみ適用されます。

“`python

project_root/app/blog/blog.py

from flask import Blueprint, render_template, abort

bp = Blueprint(‘blog’, name, url_prefix=’/blog’, template_folder=’templates’)

@bp.route(‘/‘)
def post_detail(post_id):
if post_id != 1: # 例として、IDが1以外の投稿は存在しないとする
abort(404) # 404エラーを発生させる
return f’Post {post_id}’

blog Blueprint 内で発生した 404 エラーを処理するハンドラー

@bp.errorhandler(404)
def page_not_found(error):
return render_template(‘404_blog.html’), 404

project_root/app/blog/templates/404_blog.html (例)




Blog Post Not Found

Blog Post Not Found (Blueprint Handler)

The blog post you are looking for does not exist.


“`

Blueprintのエラーハンドラーは、アプリケーション全体のエラーハンドラーよりも優先されます。つまり、blog Blueprint内のルートで404エラーが発生した場合、まず@bp.errorhandler(404)が試行され、それがなければアプリケーション全体の@app.errorhandler(404)が使用されます。

4.4 リクエスト処理前後の処理 (Request Hooks)

Blueprintでも、アプリケーションインスタンスと同様に、リクエスト処理の様々な段階で実行される関数を登録できます。これは、@bp.before_request, @bp.before_app_request, @bp.after_request, @bp.after_app_request, @bp.teardown_request, @bp.teardown_app_request, @bp.context_processor, @bp.app_context_processorなどのデコレーターを使用します。

  • @bp.before_request: このBlueprintに属するリクエストが処理される直前に実行されます。
  • @bp.before_app_request: どのBlueprintに属するかに関わらず、アプリケーション全体のリクエストが処理される直前に実行されます。これはBlueprint内で定義されますが、アプリケーション全体に適用されます。
  • @bp.after_request: このBlueprintに属するリクエストが処理された直後に実行されます。ビュー関数の戻り値（レスポンスオブジェクト）を受け取り、修正して返すことができます。
  • @bp.after_app_request: どのBlueprintに属するかに関わらず、アプリケーション全体のリクエストが処理された直後に実行されます。Blueprint内で定義されますが、アプリケーション全体に適用されます。
  • @bp.teardown_request: このBlueprintに属するかどうかに関わらず、リクエストが完了し、レスポンスがクライアントに送信された後に必ず実行されます。エラーが発生した場合でも実行されます。
  • @bp.teardown_app_request: アプリケーションコンテキストがティアダウンされる際に実行されます。

最もよく使われるのは@bp.before_requestと@bp.before_app_requestです。@bp.before_requestは特定の機能（Blueprint）に閉じた処理（例: 認証Blueprintでのログインチェック）に使い、@bp.before_app_requestはアプリケーション全体に渡る処理（例: データベースセッションの開始）に使います。

例：

“`python

project_root/app/auth/auth.py

from flask import Blueprint, request, redirect, url_for, session

bp = Blueprint(‘auth’, name, url_prefix=’/auth’)

このBlueprint内のリクエストの前に実行される

@bp.before_request
def check_authentication():
if request.endpoint and ‘auth’ not in request.endpoint and ‘user_id’ not in session:
# auth Blueprint 以外のエンドポイントで、かつログインしていない場合
return redirect(url_for(‘auth.login’)) # auth Blueprint の login エンドポイントにリダイレクト

@bp.route(‘/login’)
def login():
# ログイン処理
return ‘Login Page’

@bp.route(‘/logout’)
def logout():
# ログアウト処理
return ‘Logout Page’

project_root/app/blog/blog.py

from flask import Blueprint, render_template

bp = Blueprint(‘blog’, name, url_prefix=’/blog’)

@bp.route(‘/’)
def index():
# ログインしていない場合は check_authentication でリダイレクトされる
return ‘Blog Index Page (Authenticated)’

“`

この例では、auth Blueprintの@bp.before_requestフックは、auth Blueprint内のエンドポイントではないリクエストに対して、ユーザーがログインしているか（セッションにuser_idがあるか）をチェックし、ログインしていなければauth.loginにリダイレクトしています。これにより、blog Blueprintのページなどにアクセスする際に、自動的に認証チェックが行われます。

4.5 コンテキストプロセッサ (@bp.context_processor)

Blueprint内でテンプレートコンテキストプロセッサを定義することもできます。ここで定義された関数は、そのBlueprintのテンプレートをレンダリングする際に自動的に呼び出され、戻り値（辞書）がテンプレートコンテキストに追加されます。

“`python

project_root/app/blog/blog.py

from flask import Blueprint, render_template

bp = Blueprint(‘blog’, name, url_prefix=’/blog’, template_folder=’templates’)

@bp.route(‘/’)
def index():
return render_template(‘index.html’)

blog Blueprint のテンプレートで利用できる変数を追加

@bp.context_processor
def inject_blog_title():
return {‘blog_title’: ‘My Awesome Blog’}

project_root/app/blog/templates/index.html (例)




{{ blog_title }} {# context processor から渡された変数を利用 #}

{{ blog_title }}

Welcome to my blog!


“`

@bp.context_processorで定義された関数は、Blueprint内のテンプレートレンダリング時のみ有効です。アプリケーション全体で共通のコンテキストプロセッサが必要な場合は、@app.context_processorを使用します。

4.6 CLIコマンド (@bp.cli.command)

Flask CLI (flask run, flask shellなど) のカスタムコマンドをBlueprintに追加することもできます。これは、Blueprintに関連する管理タスクなどをコマンドラインから実行したい場合に便利です。

“`python

project_root/app/blog/blog.py

import click
from flask import Blueprint

from your_app.models import Post # 例としてモデルをインポート

bp = Blueprint(‘blog’, name, url_prefix=’/blog’)

blog Blueprint に CLI コマンドを追加

@bp.cli.command(‘create-posts’)
@click.argument(‘count’)
def create_posts_command(count):
“””指定された数のダミーブログ投稿を作成します。”””
count = int(count)
# ダミー投稿を作成するロジック（例: データベースに書き込む）
# for i in range(count):
# post = Post(title=f’Dummy Post {i+1}’, body=’…’)
# db.session.add(post)
# db.session.commit()
click.echo(f'{count} dummy posts created.’)

アプリケーションの init.py で blog_bp を登録している場合、

flask create-posts 10 のようにコマンドを実行できるようになります。

“`

@bp.cli.command()デコレーターを使用し、関数名がCLIコマンド名になります（デコレーターに引数を指定すれば、別のコマンド名にすることも可能）。これにより、Blueprintに関連するデータベースの初期化、データの移行、特定のリソースの生成などのタスクを、各Blueprint内で定義し、Flask CLIから実行できるようになります。

第5章：Blueprint間の連携

Blueprintは独立したコンポーネントとして設計されますが、実際には異なるBlueprint間で連携する必要が多くあります。最も一般的な連携方法は、あるBlueprint内のビュー関数から別のBlueprint内のビュー関数へのリダイレクトや、テンプレート内での別のBlueprintのルートへのリンク生成です。これにはurl_for()関数を使用します。

5.1 url_for()でのBlueprintのエンドポイント参照

url_for()関数は、与えられたエンドポイント名からURLを生成します。Blueprintのエンドポイントを参照する場合、エンドポイント名はBlueprint名.ビュー関数名の形式になります。

例：

“`python

project_root/app/auth/auth.py

from flask import Blueprint, render_template, redirect, url_for

bp = Blueprint(‘auth’, name, url_prefix=’/auth’, template_folder=’templates’)

@bp.route(‘/login’)
def login():
# ログイン処理後にブログ記事一覧ページにリダイレクト
# ブログBlueprint (bp名: ‘blog’) の index ビュー関数へのURLを生成
return redirect(url_for(‘blog.index’))

project_root/app/blog/blog.py

from flask import Blueprint, render_template

bp = Blueprint(‘blog’, name, url_prefix=’/blog’, template_folder=’templates’)

@bp.route(‘/’)
def index():
return render_template(‘index.html’)

@bp.route(‘/‘)
def post_detail(post_id):
return render_template(‘post_detail.html’, post_id=post_id)

project_root/app/blog/templates/post_detail.html




Post {{ post_id }}

Post {{ post_id }}

{# 認証Blueprint (bp名: ‘auth’) の login ビュー関数へのリンクを生成 #}

Login

{# 同じBlueprint内の index ビュー関数へのリンクを生成 (blog.index) #}

Back to Blog List


“`

この例では：

  • auth Blueprintのloginビュー関数内で、url_for('blog.index')を使ってblog Blueprintのindexビュー関数に対応するURL（/blog/）を生成し、そこにリダイレクトしています。
  • blog Blueprintのテンプレートpost_detail.html内で、url_for('auth.login')を使ってauth Blueprintのloginビュー関数に対応するURL（/auth/login）へのリンクを生成しています。
  • 同じくblog Blueprint内のindexビュー関数へのリンクは、url_for('blog.index')で生成しています。同じBlueprint内のエンドポイントを参照する場合でも、明示的にBlueprint名を付けるのが一般的ですが、現在のリクエストが属するBlueprint内のエンドポイントであれば、Blueprint名を省略してurl_for('.index')のように記述することも可能です（ただし、明示的に書く方が分かりやすい場合が多いです）。

url_for()は、Blueprintのurl_prefixやアプリケーション全体のルーティング設定を考慮して正しいURLを生成してくれるため、ハードコーディングされたURLを使用するよりも推奨されます。

5.2 リダイレクト (redirect)

前述の例のように、redirect()関数とurl_for()を組み合わせて使用することで、あるBlueprintから別のBlueprintへのリダイレクトを簡単に行えます。

“`python

認証が成功したら、ブログのトップページにリダイレクト

return redirect(url_for(‘blog.index’))

ユーザーがログアウトしたら、ホーム(‘/’)またはログインページにリダイレクト

アプリケーション全体のルートへの参照 (Blueprint名なし)

return redirect(url_for(‘index’)) # アプリケーションの init.py で定義した @app.route(‘/’) の index 関数

または特定のBlueprintのログインページへ

return redirect(url_for(‘auth.login’))

“`

第6章：Blueprintを用いたディレクトリ構成

Blueprintを効果的に活用するためには、適切なディレクトリ構成が重要です。プロジェクトの規模や複雑さによって様々な構成が考えられますが、ここでは一般的な例をいくつか紹介します。

6.1 シンプルな構成

小〜中規模のアプリケーションであれば、アプリケーションのルートディレクトリ直下にBlueprintごとのディレクトリを作成し、その中にBlueprintのPythonファイル、テンプレート、静的ファイルを配置するシンプルな構成が考えられます。

myproject/
├── venv/ # 仮想環境
├── app/ # アプリケーション本体
│ ├── __init__.py # アプリケーションファクトリ、Blueprint登録など
│ ├── auth/ # 認証機能 Blueprint
│ │ ├── __init__.py # auth Blueprint 定義 (auth.py の代わり)
│ │ ├── routes.py # ビュー関数定義 (@bp.route)
│ │ ├── templates/
│ │ │ └── auth/
│ │ │ ├── login.html
│ │ │ └── register.html
│ │ └── static/
│ │ └── auth/
│ │ └── style.css
│ ├── blog/ # ブログ機能 Blueprint
│ │ ├── __init__.py # blog Blueprint 定義
│ │ ├── routes.py # ビュー関数定義
│ │ ├── models.py # モデル定義 (データベース関連)
│ │ ├── forms.py # フォーム定義
│ │ ├── templates/
│ │ │ └── blog/
│ │ │ ├── index.html
│ │ │ └── post_detail.html
│ │ └── static/
│ │ └── blog/
│ │ └── style.css
│ └── models.py # アプリケーション全体で共通のモデルなど
├── config.py # 設定ファイル
├── run.py # アプリケーション実行用スクリプト
└── requirements.txt # 依存パッケージ

この構成のポイント：

  • app/ディレクトリがアプリケーション本体を格納するPythonパッケージとなっています。
  • app/__init__.pyでアプリケーションファクトリ（create_app関数）を定義し、各Blueprintをインポートして登録します。
  • 各Blueprintは独自のディレクトリを持ち、その中に__init__.pyまたはroutes.pyでBlueprintオブジェクトを定義し、関連するコードを配置します。
  • テンプレートや静的ファイルは、Blueprintディレクトリ内のtemplatesやstaticサブディレクトリに配置し、さらにサブディレクトリ（例: auth/, blog/）を使って整理します。これにより、Blueprintのtemplate_folder='templates'、static_folder='static'設定で適切にファイルを探索できるようになります。
  • static_url_pathには、Blueprintごとに/static/authや/static/blogのように固有のパスを指定するのが推奨されます。

6.2 アプリケーションファクトリパターンの採用

前述の例でも採用していますが、create_app()のようなアプリケーションファクトリ関数を使用することは、Blueprintと組み合わせて使う場合のベストプラクティスです。

  • テストのしやすさ: アプリケーションインスタンスをファクトリ関数で生成することで、テストごとに新しいインスタンスを作成しやすくなります。
  • 設定の切り替え: 環境変数などに応じて異なる設定（開発用、テスト用、本番用）をロードできます。
  • 拡張機能の登録: SQLAlchemy, Flask-LoginなどのFlask拡張機能を、ファクトリ関数内で初期化し、アプリケーションインスタンスにバインドできます。これにより、Blueprintが直接アプリケーションインスタンスや拡張機能のグローバルなインスタンスに依存するのを避けることができます。
  • 循環参照の回避: 後述する循環参照の問題を回避するのに役立ちます。

app/__init__.pyの例：

“`python

project_root/app/init.py

import os
from flask import Flask

def create_app(test_config=None):
# Flask アプリケーションインスタンスを作成
app = Flask(name, instance_relative_config=True)

# デフォルト設定
app.config.from_mapping(
    SECRET_KEY='dev', # 開発用のデフォルト値、本番では上書き必須
    # DATABASE='/path/to/database.sqlite', # DB設定例
)

if test_config is None:
    # test_config が指定されていない場合、config.py から設定をロード
    # production 環境ではインスタンスフォルダから production.py をロードするなど
    app.config.from_pyfile('config.py', silent=True)
else:
    # test_config が指定されている場合、それを使って設定を上書き
    app.config.from_mapping(test_config)

# インスタンスフォルダが存在することを確認
try:
    os.makedirs(app.instance_path)
except OSError:
    pass

# 必要に応じて、アプリケーション全体のルートやエラーハンドラを定義
@app.route('/hello')
def hello():
    return 'Hello, World!'

# ======= Blueprint の登録 =======

# 認証 Blueprint をインポートして登録
from .auth import auth_bp # auth.__init__.py で bp = Blueprint('auth', __name__, ...) と定義されているとする
app.register_blueprint(auth_bp)

# ブログ Blueprint をインポートして登録
from .blog import blog_bp # blog.__init__.py で bp = Blueprint('blog', __name__, ...) と定義されているとする
app.register_blueprint(blog_bp)

# 他の Blueprint も同様に登録...

# ======= Flask 拡張機能の初期化 =======
# 例: データベース初期化、ログインマネージャー初期化など
# from .models import db # SQLAlchemy の場合
# db.init_app(app)

# from .auth import login_manager # Flask-Login の場合
# login_manager.init_app(app)


return app

“`

この構成では、各Blueprintディレクトリ内に__init__.pyを作成し、その中でBlueprintオブジェクトを定義し、routes.pyやmodels.pyなどのモジュールをインポートするのが一般的なスタイルです。

“`python

project_root/app/auth/init.py

from flask import Blueprint

auth Blueprint オブジェクトを作成

auth_bp = Blueprint(‘auth’, name,
url_prefix=’/auth’,
template_folder=’templates’,
static_folder=’static’,
static_url_path=’/static/auth’)

ルート定義を含むモジュールをインポート (循環参照を避けるため、Blueprintオブジェクト作成後にインポート)

from . import routes

他のモジュールも同様にインポート

from . import models

from . import forms

“`

“`python

project_root/app/auth/routes.py

from flask import render_template, redirect, url_for, request, session
from . import auth_bp # auth Blueprint オブジェクトをインポート

@auth_bp.route(‘/login’, methods=[‘GET’, ‘POST’])
def login():
# ログイン処理
pass

@auth_bp.route(‘/register’, methods=[‘GET’, ‘POST’])
def register():
# 登録処理
pass
“`

このスタイルにより、Blueprintオブジェクトの定義と、そのBlueprint内のルートやモデルなどのコードを明確に分離できます。また、後述する循環参照の問題を回避するのにも役立ちます。

第7章：実践的なサンプルアプリケーション

Blueprintを使った簡単なアプリケーション例として、ユーザー認証機能とブログ機能を持つアプリケーションを考えてみます。

プロジェクト構造:

myproject/
├── venv/
├── app/
│ ├── __init__.py # アプリケーションファクトリ、Blueprint登録
│ ├── auth/ # 認証 Blueprint
│ │ ├── __init__.py
│ │ ├── routes.py
│ │ ├── templates/auth/
│ │ │ ├── login.html
│ │ │ └── register.html
│ │ └── static/auth/
│ │ └── style.css
│ ├── blog/ # ブログ Blueprint
│ │ ├── __init__.py
│ │ ├── routes.py
│ │ ├── templates/blog/
│ │ │ ├── index.html
│ │ │ └── post_detail.html
│ │ └── static/blog/
│ │ └── style.css
│ ├── templates/ # アプリケーション共通テンプレート
│ │ └── base.html
│ └── static/ # アプリケーション共通静的ファイル
│ └── style.css
├── config.py
├── run.py
└── requirements.txt

requirements.txt:

Flask

config.py:

“`python
import os

class Config:
SECRET_KEY = os.environ.get(‘SECRET_KEY’) or ‘you-will-never-guess’
# 他の設定…
“`

run.py:

“`python
from app import create_app

app = create_app()

if name == ‘main‘:
app.run(debug=True)
“`

app/__init__.py:

“`python
import os
from flask import Flask, render_template

def create_app(test_config=None):
app = Flask(name, instance_relative_config=True)

app.config.from_mapping(
    SECRET_KEY='dev',
)

if test_config is None:
    app.config.from_pyfile('config.py', silent=True)
else:
    app.config.from_mapping(test_config)

try:
    os.makedirs(app.instance_path)
except OSError:
    pass

# Blueprint の登録
from .auth import auth_bp
app.register_blueprint(auth_bp)

from .blog import blog_bp
app.register_blueprint(blog_bp)

# アプリケーション全体のルート
@app.route('/')
def index():
    # 共通の base.html を継承したテンプレートを使用
    return render_template('index.html')

return app

“`

app/auth/__init__.py:

“`python
from flask import Blueprint

auth_bp = Blueprint(‘auth’, name,
url_prefix=’/auth’,
template_folder=’templates’,
static_folder=’static’,
static_url_path=’/static/auth’)

from . import routes # routes.py をインポート
“`

app/auth/routes.py:

“`python
from flask import render_template, redirect, url_for, request, session
from . import auth_bp # auth Blueprint オブジェクトをインポート

ダミーのユーザーデータ (実際はデータベースを使用)

users = {
‘testuser’: ‘password123’
}

@auth_bp.before_app_request
def load_logged_in_user():
“””すべてのリクエストの前に、ログインしているユーザーをセッションからロードする。”””
user_id = session.get(‘user_id’) # セッションからユーザーIDを取得

if user_id is None:
    # ログインしていない場合は None
    # g.user = None
    pass # 簡単化のためユーザーオブジェクトはロードしない

# 実際には、user_id を使ってデータベースからユーザーオブジェクトをロードし g.user に格納します。
# from flask import g
# g.user = User.query.get(user_id) if user_id else None

@auth_bp.route(‘/login’, methods=[‘GET’, ‘POST’])
def login():
if request.method == ‘POST’:
username = request.form[‘username’]
password = request.form[‘password’]

    # ダミー認証
    if username in users and users[username] == password:
        session['user_id'] = username # 簡単化のためユーザー名をIDとしてセッションに格納
        return redirect(url_for('blog.index')) # ログイン成功後、ブログ一覧へリダイレクト
    else:
        error = 'Invalid username or password'
        return render_template('auth/login.html', error=error)

return render_template('auth/login.html')

@auth_bp.route(‘/logout’)
def logout():
session.pop(‘user_id’, None) # セッションからユーザーIDを削除
return redirect(url_for(‘index’)) # ログアウト後、トップページへリダイレクト
“`

app/blog/__init__.py:

“`python
from flask import Blueprint

blog_bp = Blueprint(‘blog’, name,
url_prefix=’/blog’,
template_folder=’templates’,
static_folder=’static’,
static_url_path=’/static/blog’)

from . import routes # routes.py をインポート
“`

app/blog/routes.py:

“`python
from flask import render_template
from . import blog_bp

ダミーのブログ記事データ (実際はデータベースを使用)

posts = {
1: {‘title’: ‘First Post’, ‘body’: ‘This is the first post.’},
2: {‘title’: ‘Second Post’, ‘body’: ‘This is the second post.’},
}

@blog_bp.route(‘/’)
def index():
# 実際にはデータベースから記事一覧を取得
return render_template(‘blog/index.html’, posts=posts.items())

@blog_bp.route(‘/‘)
def post_detail(post_id):
post = posts.get(post_id)
if post is None:
# 記事が見つからない場合は404エラーを発生させる (Blueprintのエラーハンドラが処理)
from flask import abort
abort(404)
return render_template(‘blog/post_detail.html’, post=post)

blog Blueprint 内の 404 エラーハンドラ

@blog_bp.errorhandler(404)
def blog_not_found(error):
return render_template(‘blog/404_blog.html’), 404
“`

テンプレートファイル:

app/templates/base.html:

“`html




{% block title %}{% endblock %} – My App {# アプリケーション共通の静的ファイル #}
{% block head_css %}{% endblock %} {# Blueprint 固有の CSS をここに含める #}


{% block content %}{% endblock %}

© 2023 My App


“`

app/templates/index.html:

“`html
{% extends ‘base.html’ %}

{% block title %}Home{% endblock %}

{% block content %}

Welcome!

This is the main page of the application.

{% endblock %}
“`

app/auth/templates/auth/login.html:

“`html
{% extends ‘base.html’ %}

{% block title %}Login{% endblock %}

{% block head_css %} {# auth Blueprint 固有の静的ファイル #}
{% endblock %}

{% block content %}

Login

{% if error %}

{{ error }}

{% endif %}





{% endblock %}
“`

app/blog/templates/blog/index.html:

“`html
{% extends ‘base.html’ %}

{% block title %}Blog{% endblock %}

{% block head_css %} {# blog Blueprint 固有の静的ファイル #}
{% endblock %}

{% block content %}

Blog Posts

    {% for post_id, post in posts %}
    {# 同じ Blueprint 内の post_detail ルートへのリンク #}

  • {{ post.title }}

    • {% endfor %}

{% endblock %}
“`

app/blog/templates/blog/post_detail.html:

“`html
{% extends ‘base.html’ %}

{% block title %}{{ post.title }}{% endblock %}

{% block head_css %} {# blog Blueprint 固有の静的ファイル #}
{% endblock %}

{% block content %}

{{ post.title }}

{{ post.body }}

{# 同じ Blueprint 内の index ルートへのリンク #}

Back to Blog List

{% endblock %}
“`

app/blog/templates/blog/404_blog.html:

“`html
{% extends ‘base.html’ %}

{% block title %}Post Not Found{% endblock %}

{% block content %}

Blog Post Not Found

Sorry, the blog post you were looking for could not be found.

{% endblock %}
“`

静的ファイル:

app/static/style.css (アプリケーション共通):

css
body {
font-family: sans-serif;
margin: 0;
padding: 0;
}
header {
background-color: #f0f0f0;
padding: 10px;
}
nav ul {
list-style: none;
padding: 0;
margin: 0;
display: flex;
gap: 15px;
}
main {
padding: 20px;
}

app/auth/static/auth/style.css (認証 Blueprint 固有):

css
/* auth Blueprint specific styles */
form {
border: 1px solid #ccc;
padding: 20px;
max-width: 300px;
}

app/blog/static/blog/style.css (ブログ Blueprint 固有):

css
/* blog Blueprint specific styles */
ul {
list-style: disc;
margin-left: 20px;
}

実行:

仮想環境をアクティベートし、pip install -r requirements.txtで依存関係をインストールした後、flask run（またはpython run.py）を実行すると、開発サーバーが起動し、Blueprintで分割されたアプリケーションが動作します。

この例は非常にシンプルですが、Blueprintがどのように異なる機能を分離し、それぞれ独自のルート、テンプレート、静的ファイルを管理し、url_forを使って連携するかを示しています。認証機能とブログ機能はそれぞれ独立したディレクトリに配置され、app/__init__.pyで組み合わされています。

第8章：Blueprint利用上の注意点とベストプラクティス

Blueprintは強力な機能ですが、正しく使わないと問題が発生することもあります。ここでは、利用上の注意点とベストプラクティスをいくつか紹介します。

8.1 エンドポイント名の名前空間管理

前述のように、Blueprint内のエンドポイント名はblueprint_name.view_function_nameの形式になります。これにより、異なるBlueprintで同じビュー関数名（例: index, detail）を使っても衝突しません。

しかし、Blueprintの名前そのものはアプリケーション全体で一意である必要があります。Blueprint('auth', __name__, ...)のように名前を付ける際に、他のBlueprintやアプリケーション自身と重複しないように注意してください。

静的ファイルのURLパスも同様です。static_url_pathを指定しない場合、デフォルトは/staticになりますが、複数のBlueprintがこの設定を使うと、静的ファイルの名前が衝突した場合に問題が発生する可能性があります。static_url_pathにBlueprintの名前を含める（例: /static/auth, /static/blog）などの方法で、名前空間を分離することが推奨されます。

8.2 循環参照 (Circular Imports) の回避

Blueprintを使ったモジュール分割を行う際、循環参照（あるモジュールが別のモジュールをインポートし、その別のモジュールが元のモジュールをインポートしている状態）が発生しやすい場合があります。例えば、Blueprintのビュー関数内でアプリケーションインスタンスや他のBlueprintのオブジェクトにアクセスする必要がある場合などです。

例：

“`python

app/auth/routes.py

from . import auth_bp
from app import db # アプリケーション全体の db オブジェクトをインポートしたい

…

app/init.py

from flask import Flask
from .auth import auth_bp

from flask_sqlalchemy import SQLAlchemy

db = SQLAlchemy() # ここで db オブジェクトを初期化

def create_app():
app = Flask(name)
# db.init_app(app) # db を app にバインド
app.register_blueprint(auth_bp)
return app
“`

この例では、auth/routes.pyがappパッケージ（app/__init__.py）をインポートし、app/__init__.pyがauthパッケージ（auth/__init__.py、そこからauth/routes.pyがインポートされる）をインポートしているため、循環参照が発生する可能性があります。

この問題を回避するための主な方法：

  1. アプリケーションファクトリパターンの使用: アプリケーションインスタンスや拡張機能（dbなど）をファクトリ関数内で作成し、Blueprintのインポートと登録はその後に遅延させます。Blueprint内では、直接アプリケーションインスタンスや拡張機能のグローバルオブジェクトを参照するのではなく、リクエストコンテキストからcurrent_appやgオブジェクト経由でアクセスします。
  2. Blueprintオブジェクトを先に定義し、ルート定義のインポートを遅延させる: 各Blueprintの__init__.pyでBlueprintオブジェクトを作成し、その後にルート定義などが含まれるモジュール（例: routes.py）をインポートします（第6章の例を参照）。
  3. 必要なものだけをインポート: 本当に必要なものだけをインポートし、モジュール間の依存関係を最小限に抑えます。

アプリケーションファクトリパターンと「Blueprintオブジェクト作成後のルート定義モジュールのインポート」の組み合わせが、Blueprintを用いた大規模アプリケーション開発における循環参照回避の最も一般的なプラクティスです。

Blueprintのビュー関数内でアプリケーションインスタンスの設定などにアクセスしたい場合は、from flask import current_appを使います。current_appは、リクエストコンテキストまたはアプリケーションコンテキストがアクティブなときに、現在処理中のアプリケーションインスタンスを指します。

8.3 設定情報の共有方法

アプリケーション全体の設定情報（データベースURI、シークレットキーなど）は、通常app.configに格納されます。Blueprint内のコードからこれらの設定情報にアクセスするには、from flask import current_appを使って現在のアプリケーションインスタンスを取得し、current_app.config['SETTING_NAME']のようにアクセスします。

例：

“`python

project_root/app/blog/routes.py

from flask import render_template, current_app
from . import blog_bp

@blog_bp.route(‘/’)
def index():
# アプリケーション設定にアクセス
db_uri = current_app.config[‘DATABASE_URI’]
print(f”Using database: {db_uri}”) # デバッグ用

# 記事を取得するロジック (db_uri を使うなど)
posts = {} # ダミーデータ

return render_template('blog/index.html', posts=posts.items())

“`

これにより、Blueprintはアプリケーション全体の設定に依存できますが、その設定がどこからロードされたか（config.pyからか、インスタンスフォルダからかなど）をBlueprint自身が知る必要はありません。これは、設定管理を一元化し、Blueprintの再利用性を高める上で重要です。

8.4 Blueprintのテスト

Blueprintで分割されたアプリケーションは、単一ファイル構成よりもテストが容易になります。各Blueprintをある程度独立したコンポーネントとして捉え、ユニットテストを書くことができます。

統合テストを行う際には、アプリケーションファクトリ関数を使ってテスト用のアプリケーションインスタンスを生成し、Flaskのテストクライアントを使用します。

“`python

project_root/tests/test_auth.py

import pytest
from app import create_app

@pytest.fixture
def app():
# テスト用の設定でアプリケーションファクトリを呼び出し
app = create_app({
‘TESTING’: True, # テストモードを有効化
‘SECRET_KEY’: ‘testing’, # テスト用のキー
# その他のテスト固有の設定…
})
yield app # テスト関数に app インスタンスを渡す

@pytest.fixture
def client(app):
# テストクライアントを作成
return app.test_client()

def test_login_page(client):
# auth Blueprint のログインページにアクセス
response = client.get(‘/auth/login’)
assert response.status_code == 200
assert b’Login Page’ in response.data # レスポンスボディに ‘Login Page’ が含まれているか

def test_login_with_valid_credentials(client):
# auth Blueprint のログインページに POST リクエストを送信
response = client.post(‘/auth/login’, data={‘username’: ‘testuser’, ‘password’: ‘password123’})
# ログイン成功後、ブログ一覧ページ (/blog/) にリダイレクトされることを確認
assert response.status_code == 302
assert ‘/blog/’ in response.headers[‘Location’] # リダイレクト先の Location ヘッダーを確認
“`

Blueprintは、コードの構造化、再利用性、開発効率向上に大きく貢献します。これらの注意点やベストプラクティスを理解し、適切に適用することで、Blueprintのメリットを最大限に引き出し、より堅牢で保守しやすいFlaskアプリケーションを開発できます。

第9章：まとめ

この記事では、FlaskのBlueprint機能について、その目的から基本的な使い方、詳細な設定、Blueprint間の連携、実践的なディレクトリ構成、そして利用上の注意点とベストプラクティスまで、幅広く解説しました。

Flask Blueprintは、アプリケーションを論理的かつ再利用可能なコンポーネントに分割するための強力なツールです。Blueprintを使用することで、以下のメリットが得られます。

  • モジュラリティの向上: 機能を独立した単位で開発・管理できる。
  • コードの整理と管理の容易さ: 各Blueprintが特定の機能に特化し、コードベースが分かりやすくなる。
  • 再利用性の向上: 作成したBlueprintを他のプロジェクトで簡単に利用できる。
  • 開発効率の向上: 複数人での並行開発が容易になる。
  • URLの名前空間管理: URLの衝突を防ぎ、アプリケーション構造を明確にする。

小規模なアプリケーションではBlueprintの必要性を感じないかもしれませんが、アプリケーションが成長するにつれて、その価値は明白になります。将来的な拡張やメンテナンスを考慮するならば、プロジェクトの初期段階からBlueprintを使ってコードを構造化しておくことを強く推奨します。

Blueprint、アプリケーションファクトリパターン、適切なディレクトリ構成、そして循環参照などの一般的な問題への対処法を理解することで、より大規模で複雑なWebアプリケーションをFlaskで効果的に開発できるようになります。

この記事で紹介した内容が、あなたのFlask開発におけるBlueprintの理解と活用の一助となれば幸いです。Blueprintを使いこなし、モジュラーで効率的なFlaskアプリケーション開発を進めましょう。

コメントする

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

上部へスクロール