Python | Web フレームワーク：FastAPI 基本

Python
スポンサーリンク

概要（FastAPI は「型付きの超書きやすい Web API フレームワーク」）

FastAPI は、
「Python で Web API を作るためのフレームワーク」です。

特徴を一言でまとめると、

型ヒントをちゃんと書くと、
入力チェック、ドキュメント、自動補完まで“いい感じ”に揃えてくれる
すごく書きやすい Web フレームワーク

というイメージです。

すでに「自動化スクリプト」を書いているあなたなら、
それを「外から HTTP で呼べるサービス」に変えるのに、FastAPI はかなり相性がいいです。

FastAPI が何をしてくれるのかイメージする

Flask との違いから入るイメージ

Python の Web フレームワークとしては、Flask がよく話題に出ます。

Flask は「軽量で自由度が高い」代わりに、
リクエストの型チェック、レスポンスのスキーマ、API ドキュメントなどは、自分で頑張る必要があります。

FastAPI は最初からこう決めています。

Python の型ヒントをちゃんと書いてくれたら、
リクエストのバリデーション（型チェック）
レスポンスの構造
API ドキュメント（Swagger UI）
を自動で用意します

つまり、「型ヒントを書くだけで、いろいろおまけが付いてくる」フレームワークです。

典型的な用途

FastAPI でよくやることは、例えば次のようなものです。

データ分析や自動化スクリプトを、HTTP 経由で呼べるようにする
スクレイピングやバッチ処理の結果を、API として提供する
社内用のツール（ちょっとしたダッシュボードや BOT の裏側）を作る

あなたがすでに作っている「関数ベースの自動化処理」を、
「リクエストを受け取って結果を返すエンドポイント」に載せ替える、という使い方がとても自然です。

最小サンプルで「動く感覚」をつかむ

とにかく 1 つ動かしてみる

まずは、最小の FastAPI アプリを書いてみます。

main.py:

from fastapi import FastAPI

app = FastAPI()

@app.get("/")
def read_root():
    return {"message": "Hello FastAPI"}
Python

この状態で、開発用サーバーを起動します。

uvicorn main:app --reload

main:app は「main.py の中の app という変数」を指しています。
--reload は、コードを変えたら自動で再起動してくれる開発用のオプションです。

ブラウザで http://127.0.0.1:8000/ にアクセスすると、
{"message": "Hello FastAPI"}
という JSON が返ってきます。

これが FastAPI の「最初の一歩」です。

自動ドキュメントを見てみる（超重要）

FastAPI のすごく大事な機能が「自動ドキュメント」です。

サーバーを起動した状態で、
http://127.0.0.1:8000/docs
にアクセスしてみてください。

Swagger UI という画面が開いて、
さっき作った GET / のエンドポイントが一覧表示されます。

さらに、ボタン一つで「試しに実行」もできます。

これからエンドポイントを増やすたびに、ここに自動でドキュメントが増えていきます。
「型ヒントにちゃんと意味を書いておくと、ドキュメントも勝手にリッチになっていく」のが FastAPI の気持ちよさです。

パスパラメータとクエリパラメータ（URL から値を受け取る）

パスパラメータ（/items/123 の 123 の部分）

ID やユーザー名などを URL の一部として渡したい場合、パスパラメータを使います。

from fastapi import FastAPI

app = FastAPI()

@app.get("/items/{item_id}")
def read_item(item_id: int):
    return {"item_id": item_id}
Python

ここで大事なポイントが 2 つあります。

ひとつ目は、/items/{item_id} という書き方です。
URL の {item_id} の部分が、そのまま引数 item_id に入ってきます。

ふたつ目は、引数に item_id: int と型ヒントを書いていることです。
FastAPI はここを見て、「このパラメータは整数でなければいけない」と自動判断します。
もし /items/abc のように文字列を入れると、400 番エラー（Bad Request）を返してくれます。

つまり、「関数の引数に型を書くだけで、入力チェックまでやってくれる」のが重要です。

クエリパラメータ（/search?keyword=…&limit=… の部分）

検索条件やオプションを、?key=value の形で渡すのがクエリパラメータです。

from fastapi import FastAPI

app = FastAPI()

@app.get("/search")
def search_items(keyword: str, limit: int = 10):
    return {
        "keyword": keyword,
        "limit": limit,
        "results": []
    }
Python

このエンドポイントは、
/search?keyword=apple&limit=5 のように呼ばれます。

ここでも型ヒントとデフォルト値が効いています。

keyword: str は必須（指定がないとエラー）
limit: int = 10 は省略可（指定がなければ 10）

FastAPI は、クエリパラメータを関数の引数に自動マッピングしてくれるので、
「リクエストから値を取り出すためのゴチャゴチャしたコード」がほぼ不要になります。

リクエストボディと Pydantic モデル（ここが FastAPI の肝）

JSON を受け取るときは「モデル」を定義する

POST で JSON を受け取りたいとき、
FastAPI では Pydantic というライブラリのモデルを使います。

まず、モデルを定義します。

from fastapi import FastAPI
from pydantic import BaseModel

app = FastAPI()

class Item(BaseModel):
    name: str
    price: float
    in_stock: bool = True
Python

この Item は、「こういう形のデータを期待しています」という宣言です。

次に、このモデルを引数として受け取るエンドポイントを書きます。

@app.post("/items")
def create_item(item: Item):
    return {
        "message": "created",
        "item": item
    }
Python

ここでのキモを深掘りします。

クライアントは、次のような JSON を POST します。

{
  "name": "Apple",
  "price": 1.5,
  "in_stock": false
}

FastAPI は、この JSON を自動的に Item モデルに変換し、
型チェック（バリデーション）まで済ませてから関数に渡します。

もし price に文字列 "abc" を渡したら、
Pydantic が「float じゃない」と判断して 422（Unprocessable Entity）のエラーを返します。

つまり、

リクエストの「型」と「必須項目」「デフォルト値」を Pydantic モデルとして書く
→ FastAPI が「入力チェック＋パース」を全部やってくれる
→ 関数の中では「すでに正しい形のデータ」として安心して扱える

この流れです。

レスポンスの型もモデルで表現できる

レスポンスに対しても「この形の JSON を返します」と宣言できます。

from typing import List
from fastapi import FastAPI
from pydantic import BaseModel

app = FastAPI()

class Item(BaseModel):
    id: int
    name: str

fake_db = [
    Item(id=1, name="Apple"),
    Item(id=2, name="Banana"),
]

@app.get("/items", response_model=List[Item])
def list_items():
    return fake_db
Python

ポイントは、response_model=List[Item] です。

FastAPI は、戻り値をこのモデルで「整形」して返します。
余計なフィールドが含まれていたら落としてくれるし、
docs 画面で「こういう JSON が返るよ」というスキーマも表示してくれます。

リクエストとレスポンスの両方に「型」を導入することで、

コード補完が効きやすい
入力・出力の仕様が分かりやすい
後から見る人にも優しい

という状態を作れます。

実用に近い構造にする（ファイル分割とルーター）

1ファイルから「ルーター」へ

FastAPI も、規模が大きくなると 1 ファイルではきつくなります。
そこで、「ルーター」を使ってエンドポイントごとに分割します。

構成例:

app/
  main.py
  api/
    __init__.py
    items.py

items.py:

from fastapi import APIRouter
from pydantic import BaseModel
from typing import List

router = APIRouter(prefix="/items", tags=["items"])

class Item(BaseModel):
    id: int
    name: str

fake_db = [
    Item(id=1, name="Apple"),
    Item(id=2, name="Banana"),
]

@router.get("/", response_model=List[Item])
def list_items():
    return fake_db

@router.get("/{item_id}", response_model=Item)
def get_item(item_id: int):
    for item in fake_db:
        if item.id == item_id:
            return item
    raise RuntimeError("not found")
Python

main.py:

from fastapi import FastAPI
from api.items import router as items_router

app = FastAPI()

app.include_router(items_router)
Python

これで、/items と /items/{item_id} のエンドポイントが items.py にまとまります。

重要なのは、

APIRouter で「このファイルは items 関連の API をまとめたもの」と宣言する
main.py は「アプリを作って、ルーターを登録するだけ」にする

という構造です。

自動化×FastAPI の世界でも、
処理ごとにルーターを分けておくと、後から機能を追加するのが楽になります。

自動化と FastAPI をどうつなぐか（イメージづくり）

既存のバッチ・スクリプトを「裏側の関数」にしてラップする

あなたがすでに持っている自動化処理
（CSV 処理、API 集計、スクレイピング、レポート生成など）を
FastAPI と組み合わせるときの基本パターンはシンプルです。

もともとのバッチ処理を「引数を受け取って結果を返す関数」に整理する。
FastAPI のエンドポイントから、その関数を呼ぶ。
引数の型・レスポンスの型を Pydantic モデルで表現する。

具体的に書くと、例えばこんな感じになります。

既存の処理:

# report_service.py
from datetime import date

def generate_sales_report(target_date: date) -> dict:
    # ここで売上集計して、結果を dict で返す想定
    return {"date": target_date.isoformat(), "total": 12345}
Python

FastAPI 側:

# main.py
from fastapi import FastAPI
from pydantic import BaseModel
from datetime import date
from report_service import generate_sales_report

app = FastAPI()

class ReportRequest(BaseModel):
    date: date

class ReportResponse(BaseModel):
    date: date
    total: int

@app.post("/sales-report", response_model=ReportResponse)
def sales_report(body: ReportRequest):
    result = generate_sales_report(body.date)
    return result
Python

こうしておくと、
「もともとスクリプトとして使っていた集計処理」を、
そのまま Web API として公開できます。

このスタイルに慣れると、

「まずはスクリプトとして動かす → よさそうなら FastAPI に乗せて他から呼べるようにする」

という成長パターンが自然に取れるようになります。

まとめ（FastAPI は「型を味方にした、書きやすい Web の入口」）

FastAPI の基本を、自動化・初心者視点で整理すると、こうなります。

FastAPI は Python の型ヒントと Pydantic モデルを使って、「リクエスト／レスポンスの型チェック」と「ドキュメント自動生成」をしてくれる Web フレームワーク。
@app.get や @app.post でエンドポイントを定義し、関数の引数に型を書くことで、パスパラメータ・クエリパラメータを自然に受け取れる。
Pydantic のモデル（BaseModel）を使うことで、JSON の入力チェックとスキーマ定義を一度に行い、docs 画面にもそのまま反映される。
既存の自動化関数を「引数→結果を返す」形に整理しておけば、それを FastAPI のエンドポイントから呼び出すだけで Web API 化できる。
規模が大きくなったら APIRouter でルーター分割し、main.py は「アプリ生成＋ルーター登録」に専念させると構造がきれいになる。

スポンサーリンク
タイトルとURLをコピーしました