Pythonの学習が進んでくると、作ったものを他のプログラムから呼べるようにしたくなる瞬間があります。スマホアプリの裏側や、AIサービスの窓口として使われているのが、いわゆるWeb APIです。
そのAPIをPythonで作るときに、いま最もよく名前が挙がるのがFastAPIです。求人票やチュートリアルで見かけて、気になっていた方も多いのではないでしょうか。
ただ、名前だけ聞くとFlaskとどう違うのか分かりにくいですよね。速いらしい、型を書くらしい、そのあたりで止まってしまいがちです。
この記事では、FastAPIが何をしてくれる道具なのかを、実際のコードと一緒に順番にほどいていきます。
FastAPIは、型ヒントを土台にしたAPIの道具¶
まずは立ち位置をはっきりさせておきましょう。FastAPIは公式に、Pythonの標準的な型ヒントをもとにAPIを構築するための、モダンで高速なWebフレームワークと説明されています。
ここで大事なのは、型ヒントという言葉です。これは変数や引数に、どんな種類の値が入るのかを書き添えておく記法のことを指します。
FastAPIの面白いところは、その型ヒントを飾りで終わらせない点にあります。書いた型が、そのまま入力チェックとドキュメントの材料になるのです。
型ヒント自体にまだ馴染みがない方は、先にこちらで基礎を押さえておくと、この記事がぐっと読みやすくなります。【関連記事】Pythonの型ヒントとは？型ヒントの基礎を解説
中身は、大きく2つのライブラリの上に乗っています。エラーメッセージに知らない名前が出てきたときのために、役割を知っておくと安心です。
| 部品 | 役割 |
|---|---|
| Starlette | 通信やルーティングを担当するWebの土台 |
| Pydantic | 型ヒントをもとにデータを検証して変換する担当 |
| FastAPI本体 | 2つをまとめて、APIとして書きやすい形にする窓口 |
つまりFastAPIは、ゼロから全部を作った巨大な道具ではありません。実績のある2つの部品を、うまく組み合わせた接着剤のような存在です。
最小のアプリを動かすまで¶
説明を読むより、動かしたほうが早いはずです。ここから手順を追っていきます。
インストールとPythonのバージョン¶
FastAPIは標準ライブラリではないので、pipで入れるところから始めます。角かっこ付きで指定すると、開発に必要なものがまとめて入ります。
pip install "fastapi[standard]"
この standard を付けておくと、あとで使う起動コマンドとサーバーが一緒に入ってきます。初めて触るときは、迷わず付けておいて構いません。
執筆時点の最新版は0.141.1で、2026年7月29日に公開されています。動かすにはPython 3.10以降が必要で、3.14まで対応が明示されています。
古いPythonを使っている場合は、ここで引っかかります。入らないときはまずPythonのバージョンを疑う、これだけ覚えておけば時間を無駄にしません。
fastapi dev で立ち上げる¶
入ったら、公式ドキュメントに載っている最小の例を書いてみます。main.py という名前で保存してください。
from fastapi import FastAPI
app = FastAPI()
@app.get("/")
def read_root():
return {"Hello": "World"}
@app.get("/items/{item_id}")
def read_item(item_id: int, q: str | None = None):
return {"item_id": item_id, "q": q}
保存したら、ターミナルで次のコマンドを打ちます。ファイル名を渡さなくても、FastAPIが main.py を見つけてくれます。
fastapi dev
このコマンドはファイルの中のアプリを検出し、Uvicornというサーバーを立ち上げます。開発中はコードを保存するたびに自動で再読み込みされるので、いちいち止めなくて大丈夫です。
ブラウザで http://127.0.0.1:8000 を開くと、辞書がそのままJSONとして返ってきます。PythonのdictをreturnするだけでJSONになる、この気軽さがFastAPIの入口です。
返ってきたデータをPython側で受け取る方法が気になったら、こちらもあわせてどうぞ。【関連記事】PythonでJSONデータの扱いをマスター！API連携に必須のjsonモジュールの使い方
型ヒントが、そのまま入力チェックになる¶
先ほどのコードで、さらっと書いた item_id: int に注目してください。これがFastAPIの心臓部です。
http://127.0.0.1:8000/items/5 を開くと、item_id は文字列の5ではなく整数の5として渡ってきます。URLから来る値はもともと文字列なので、FastAPIが型ヒントを見て変換してくれているわけです。
では http://127.0.0.1:8000/items/abc を開いたらどうなるでしょうか。整数にできないので、エラーの内容を説明したJSONが返ります。
ここが地味に効きます。関数の中で数値かどうかを確かめる処理を、自分で書かずに済むからです。
もう少し複雑なデータを受け取るときは、Pydanticのモデルを使います。クラスとして形を宣言しておけば、受け取ったJSONがその形に合っているかを自動で確認してくれます。
from fastapi import FastAPI
from pydantic import BaseModel
app = FastAPI()
class Item(BaseModel):
name: str
price: float
in_stock: bool = True
@app.post("/items/")
def create_item(item: Item):
return {"name": item.name, "tax_included": item.price * 1.1}
price に文字列が届けば、その時点で弾かれます。関数の中に入ってくる時点で、データはすでに信用できる状態になっているのです。
このモデルの書き方をもっと知りたい方は、Pydanticそのものを扱った記事も用意しています。【関連記事】Pydantic v2で堅牢なデータバリデーションをやってみよう！
自動で作られるドキュメントが効いてくる¶
FastAPIには、書いた覚えのない画面がついてきます。サーバーを立ち上げたまま http://127.0.0.1:8000/docs を開いてみてください。
APIの一覧が並んだ画面が出て、その場でボタンから実行できるようになっています。これはSwagger UIと呼ばれるもので、/redoc を開けば別の見た目のドキュメントも出ます。
なぜこんなことができるのかというと、FastAPIがOpenAPIという標準仕様に沿って、APIの説明書を自動で組み立てているからです。材料になっているのは、あなたが書いた型ヒントとPydanticのモデルです。
私は10年ほどエンジニアとして開発に関わってきましたが、APIの仕様書とコードがずれていく問題には何度も泣かされてきました。仕様書は書いた瞬間から古くなるのに、直す人がいないからです。
コードが仕様書を兼ねるというのは、その悩みへの現実的な答えのひとつです。チームで開発するときほど、この恩恵は大きくなります。
Flaskとの違いは、どこにあるのか¶
さて、気になるのはFlaskとの比較でしょう。どちらもPythonのWebフレームワークで、どちらも小さく始められます。
大づかみに言えば、Flaskは画面を持つWebアプリ全般、FastAPIはデータをやりとりするAPIが得意です。もちろん逆もできますが、標準で用意されているものが違います。
主な違いを表にまとめます。どちらが優れているという話ではなく、向きの違いだと思ってください。
| 観点 | Flask | FastAPI |
|---|---|---|
| 土台の規格 | WSGI | ASGI |
| 得意なもの | HTMLを返すWebアプリ | JSONを返すAPI |
| 入力チェック | 自分で書くか拡張を足す | 型ヒントから自動で行う |
| APIドキュメント | 標準では付かない | /docs に自動生成される |
| 非同期処理 | 限定的な対応 | 標準で async def を使える |
| 必要なPython | 3.9以降（3.1.3の場合） | 3.10以降（0.141.1の場合） |
Flask側の作法をまだ知らない方は、先にこちらを読むと違いが立体的に見えてきます。【関連記事】PythonのFlaskとは？WebアプリをPythonで動かす仕組みを初心者向けに解説
ASGIとWSGIという土台の違い¶
表に出てきたWSGIとASGIは、PythonのWebアプリとサーバーが会話するための決まりごとです。仲介役の共通ルール、と考えると分かりやすいでしょう。
WSGIは1つのリクエストを最後まで処理してから、次に移る前提で作られています。素直な仕組みですが、外部への通信待ちが多いと手が空いたまま待つ時間が生まれます。
ASGIはその後に登場した規格で、待っている間に別のリクエストを進められるように設計されています。FastAPIが速いと言われる理由のひとつが、ここにあります。
async def と def、どちらで書くか¶
FastAPIを触り始めた人が最初に迷うのが、この使い分けです。ネット上のサンプルには両方が出てくるので、混乱しても無理はありません。
判断の軸はひとつだけです。呼び出す相手が await に対応しているかどうか、それだけを見ます。
非同期対応のデータベースライブラリなどを使うなら async def で書きます。そうでない普通の関数を呼ぶだけなら def のままで構いません。
def で書いた関数は、FastAPIが別のスレッドに逃がして実行してくれます。だから全体の処理を止めてしまう心配はありません。
いちばん危ないのは、async def の中で await の付かない重い処理を呼ぶことです。待っている間に他のリクエストが進めなくなり、かえって遅くなります。
async や await の考え方があやふやなときは、こちらで基礎から確認できます。【関連記事】Pythonのasyncioとは？async/awaitで待ち時間を減らす仕組みを初心者向けに解説
つまずきやすいところと、私の失敗¶
最後に、実際に手を動かすと出会いやすい点をまとめておきます。どれも知っていれば数秒で解決するものばかりです。
まず、自分のファイルに fastapi.py と名前を付けないでください。本物のライブラリではなく自分のファイルが読み込まれ、原因の分かりにくいエラーになります。
次に、fastapi dev はあくまで開発用です。名前のとおり開発中に手元で試すためのもので、公開する本番ではUvicornを本番向けの設定で動かすのが基本になります。
私自身の失敗も書いておきます。以前、/docs の画面を社内向けだからと軽く考えて、外から見える環境に置いたまま数日放置してしまったことがあります。
APIの入口が全部並んだ画面は、攻撃する側にとっても親切な地図です。公開環境では自動ドキュメントの扱いを必ず決める、これは設計の段階で話し合っておくべきことでした。
サーバーや公開まわりの言葉が曖昧なままだと、この判断はできません。土台を固めておくと、事故の芽に気づけるようになります。
まとめ¶
FastAPIは、型ヒントを書くだけで入力チェックとドキュメントがついてくるフレームワークです。APIを作る手数が、はっきり減ります。
覚えることは多くありません。デコレータでURLと関数を結び、引数に型を書き、複雑なデータはPydanticのモデルにする。この3つで、ひととおり形になります。
Flaskと迷ったら、返したいものがHTMLかJSONかで選んでみてください。画面を作りたいならFlask、他のプログラムに使ってもらうならFastAPIが素直です。
まずは fastapi dev を一度打って、/docs の画面が出るところまで試してみましょう。あの画面を見た瞬間に、このフレームワークが人気な理由が腑に落ちるはずです。
ここまでお読みいただきありがとうございました。
