Flaskはなぜ今も死なないのか

🧭 はじめに（What / Why）

このページでは Flaskが「古い・軽量・時代遅れ」と言われながら、なぜ今も現役で使われ続けているのか を整理する。

• Flaskは何を目的として生まれたフレームワークか
• FastAPIやDjangoが普及した現在でも選ばれる理由は何か
• 「Flaskを選ぶ判断」が成立する境界はどこか

到達点はシンプルで、 「Flaskは“何でもできる”道具ではなく、“責任範囲が明確な道具”だと理解できること」。

---

🧱 立ち位置の整理（Before / After）

Before：Python Webフレームワークの状況

• 標準ライブラリにはWebフレームワークは存在しない

• WSGIはあるが、アプリケーション構造は各自で設計する必要があった

• Djangoは存在していたが、

  • ORM
  • 認証
  • 管理画面
  • 設定規約 が一体化しすぎていると感じる層も多かった

After：Flaskの立ち位置

Flaskは 「Webアプリの最小骨格」 を提供するために登場した。

• ルーティング
• リクエスト / レスポンス
• テンプレート連携（Jinja2）
• WSGIとの自然な接続

それ以上は 意図的に提供しない。

Flaskは「Djangoの軽量版」ではない。責務を限定した設計という別解である。

---

🧠 設計思想の核（最重要）

Flaskが優先したもの

• 明示性
• 最小主義
• フレームワークが主張しすぎないこと

Flaskは「こう書け」とは言わない。 代わりに「ここまで用意するから、あとは自分で決めろ」と言う。

app = Flask(__name__)

@app.route("/")
def hello():
    return "Hello"

この簡潔さは偶然ではない。

Flaskが捨てたもの

• デフォルトORM
• デフォルト認証
• 設定ファイル規約
• プロジェクト構成テンプレートの強制

Flaskは「フレームワークの意思」より「利用者の意思」を優先する。

---

🎯 できること / できないこと

得意なこと

• 小〜中規模Webサービス
• 内部向けAPI
• プロトタイプ
• 既存システムへの組み込み
• WebというI/O層だけを担当する構成

向いていないこと

• 大規模チームでの暗黙知に依存しない開発
• 初学者大量投入プロジェクト
• 「何も考えずに正解に辿り着きたい」ケース

Flaskは設計をサボると一気に破綻する。 「自由」はそのまま「責任」になる。

---

🧩 典型的な利用パターン（最小）

Flaskは 「Webの入口」だけを担当させる のが典型。

[Client]
   ↓
[Flask]
   ↓
[Application / Domain Logic]
   ↓
[DB / External API]

• FlaskはI/O変換のみ
• ビジネスロジックは外に出す
• dataclass / pydantic / service層と自然に分離可能

Flaskは「薄く使う」ほど強い。

---

🚨 よくある誤解・アンチパターン

❌ Flask = 何でも自由に書いてよい

• 単一ファイル巨大化
• グローバル状態氾濫
• 暗黙依存だらけ

→ 設計責任を放棄した結果。

❌ FastAPIがあるからFlaskは不要

• FastAPIは型駆動・API志向
• Flaskは構造を押し付けない

思想が違う。

「FastAPIの下位互換としてFlaskを見る」のは完全な誤認。

---

🔗 他ライブラリとの関係

• FastAPI → 型・OpenAPI・自動生成重視
• Django → 一貫した規約と統合体験
• Flask → Web層の最小責務

Flaskは 他OSSと組み合わせる前提 で成立している。

---

🧾 まとめ（1文で言うと）

Flaskは「Webフレームワーク」ではなく、「WebというI/Oを引き受ける最小の器」である。