はじめに
PythonでWeb APIを作る際に使われる組み合わせで、FastAPI・Pydantic・SQLAlchemy・Alembicがあります。それぞれ役割が異なるライブラリですが、初めて触れると「どこからどこまでがどのライブラリの仕事なのか」が分かりにくく感じます。
本記事では、この4つの役割分担を整理します。
全体像
Web APIがリクエストを受け取ってからレスポンスを返すまでの流れの中で、各ライブラリは次のような役割を担います。
クライアントからのリクエスト
↓
【FastAPI】 ルーティング(どのURL・メソッドで受けるか)を管理
↓
【Pydantic】 リクエストの中身を検証・型変換(バリデーション)
↓
（ビジネスロジック）
↓
【SQLAlchemy】 Pythonのオブジェクトとして、DBの読み書きを行う(ORM)
↓
【Alembic】 SQLAlchemyのモデル定義とDBの実際のテーブル構造を同期させる(マイグレーション)
FastAPI：Web APIフレームワーク
FastAPIは、Pythonの型ヒント(Type Hints)を活用してWeb APIを構築するためのフレームワークです。関数の引数に型を明記するだけで、リクエストパラメータの受け取り・検証・APIドキュメントの自動生成までを行ってくれる点が特徴です。
from fastapi import FastAPI
app = FastAPI()
@app.get("/recipes/{recipe_id}")
def get_recipe(recipe_id: int):
return {"id": recipe_id}
上記のようにrecipe_id: intと型を書くだけで、FastAPIは自動的に「このパラメータは整数でなければならない」というバリデーションを行い、さらにSwagger UIによる対話的なAPIドキュメントも自動生成します。
FastAPIを実際に動かすには、uvicornのようなASGI(Asynchronous Server Gateway Interface)サーバーが必要です。FastAPI自体はアプリケーションの定義を担い、uvicornがHTTPリクエストを実際に受け付けてFastAPIアプリケーションに渡す役割を担います。
Pydantic：データのバリデーション
Pydanticは、Pythonの型ヒントを使ってデータの検証・構造化を行うライブラリで、FastAPIは内部的にこのPydanticを使ってリクエスト/レスポンスのデータを扱っています。
from pydantic import BaseModel
class RecipeCreate(BaseModel):
title: str
servings: int
このように「入力として期待する形」をクラスとして定義しておくと、FastAPIはリクエストボディをこの形式に自動変換・検証してくれます。型に合わないデータが送られてきた場合は、FastAPIが自動的に422 Unprocessable Entityエラーを返してくれるため、バリデーション処理を自前で書く必要がありません。
多くのプロジェクトでは、「作成用」「更新用」「レスポンス用」のように用途ごとに複数のPydanticモデル(例：RecipeCreate・RecipeUpdate・RecipeOut)を使い分け、入出力のデータ形状を明確に分離します。
SQLAlchemy：ORM(オブジェクト関係マッピング)
SQLAlchemyは、PythonのORM(Object-Relational Mapper)ライブラリです。ORMとは、リレーショナルデータベースのテーブルを、Pythonのクラス・オブジェクトとして扱えるようにする技術です。
from sqlalchemy import Column, Integer, String
from sqlalchemy.orm import declarative_base
Base = declarative_base()
class Recipe(Base):
__tablename__ = "recipes"
id = Column(Integer, primary_key=True)
title = Column(String)
ORMを使うことで、生のSQL文を書かなくても、Pythonのオブジェクト操作としてDBの読み書きができるようになります(例：session.add(recipe)、session.query(Recipe).filter(...))。SQLAlchemyは接続管理を行うEngineと、実際のデータ操作の単位となるSessionという2つの中心的な概念を持っています。
SQLAlchemyが提供するのはあくまで「Pythonのモデル定義とDB操作の橋渡し」であり、実際のDBのテーブル構造をどう作成・変更するかは担当していません。この役割を担うのが次のAlembicです。
Alembic：マイグレーション管理
Alembicは、SQLAlchemyのためのマイグレーションツールです。マイグレーションとは、アプリケーションの開発が進んでデータモデルが変わるたびに、実際のDBのテーブル構造(スキーマ)をその変更に追従させる作業のことです。
開発が進むにつれて「カラムを追加したい」「テーブルを新設したい」といった変更が発生しますが、本番DBに対して手作業でSQLを実行して構造を変更するのはミスが起きやすく、変更履歴も残りません。Alembicは、この変更を「マイグレーションスクリプト」というPythonファイルの形で管理し、バージョン管理された形でDBのスキーマを段階的に適用・巻き戻しできるようにします。
# モデルの変更内容から、マイグレーションスクリプトを自動生成
alembic revision --autogenerate -m "add servings column to recipes"
# 生成されたマイグレーションをDBに適用
alembic upgrade head
生成されたマイグレーションスクリプトには、「アップグレード時(スキーマを新しくする時)に何をするか」と「ダウングレード時(元に戻す時)に何をするか」の両方が定義されており、必要に応じてDBの状態を前のバージョンに戻すことも可能です。
まとめ
| ライブラリ | 役割 |
|---|---|
| FastAPI | HTTPリクエストのルーティング・APIドキュメントの自動生成を担うWebフレームワーク |
| Pydantic | 型ヒントを使ったリクエスト/レスポンスデータのバリデーション・変換 |
| SQLAlchemy | Pythonのオブジェクトとしてデータベースを操作するORM |
| Alembic | SQLAlchemyのモデル変更に合わせて、実際のDBスキーマを段階的に更新するマイグレーションツール |
この4つは「Web APIのフレームワーク」「データの検証」「データベース操作」「データベース構造の変更管理」という、それぞれ独立した関心事を担当しており、組み合わせることでPythonでのWeb API開発の定番構成の1つになっています。