Python で新しい Web API を立ち上げるとき、Django（フルスタック Web フレームワーク）にするかFastAPI（非同期処理が得意な軽量 API フレームワーク）にするか、最初の設計会議で必ず議題に上がります。
この記事は、Python バックエンドを新規に立ち上げるエンジニアやテックリードに向けたものです。採用要件を決める前段階として、技術選定そのものの判断軸を整理したいという方の参考になれば幸いです。
選定を誤ると、半年後に「管理画面がないから全部自前で作っている」「非同期処理が絡むたびに動作がおかしくなる」といった後悔につながります。フレームワーク選びは採用する人材のスキルセットにも直結するため、技術的な判断軸を先に固めておく価値があります。
判断に悩む典型的な場面
よくあるのは、社内向け管理ツールやSaaSの管理画面を作る案件です。
アカウント管理、権限制御、データ一覧のCRUD（Create・Read・Update・Deleteの頭文字、基本的なデータ操作）画面が中心なら、ゼロから組むのは非効率です。
一方で、機械学習モデルの推論APIやWebhook（外部サービスからのイベント通知を受け取る仕組み）処理、モバイルアプリ向けのバックエンドのように、APIそのものが成果物になる案件もあります。この両者で最適なフレームワークは変わります。
判断軸1: 同期処理中心か非同期処理中心か
Djangoは歴史的に同期処理（1つの処理が終わるまで次を待つ方式）を前提に設計されています。Django 3.1以降はASGI（非同期サーバーゲートウェイインターフェース）に対応し、非同期ビューも書けるようになりましたが、エコシステム全体がまだ同期前提の部分を多く残しています。
FastAPIは最初からasync/await構文を前提にした非同期ファーストの設計です。高い同時接続数をさばく必要がある、外部APIへのI/O待ちが多い処理では明確に有利です。
たとえば、複数の外部決済サービスに同時に問い合わせて結果をまとめるような処理は、FastAPIの非同期処理のほうが素直に書けます。
判断軸2: 管理画面・ORMなどの「バッテリー同梱」が必要か
DjangoにはORM（オブジェクトとデータベースのレコードを対応させる仕組み）、マイグレーション機能、管理画面（Django Admin）、認証、権限モデルが標準で付属しています。
これは「バッテリー同梱（batteries included）」と呼ばれる設計思想で、Ruby on RailsやLaravelに近い考え方です。業務システムや社内ツールでは、この管理画面だけでも開発工数を大きく削減できます。
FastAPIにはこうした機能は標準で含まれていません。ORMはSQLAlchemyやSQLModelなどを別途組み合わせ、認証や管理画面も自前で設計するか、サードパーティ製ライブラリに頼ることになります。自由度は高い一方、初期の意思決定事項が増えます。
判断軸3: API仕様書の自動生成が必要か
FastAPIは型ヒント（Pythonの変数や関数の型を明示する記法）とPydantic（データ検証ライブラリ）を組み合わせることで、OpenAPI仕様書とSwagger UIを自動生成します。
フロントエンドチームやモバイルチームが別組織にいて、API仕様をドキュメントとして共有する必要がある場合、これは実務上かなり大きな差になります。
Djangoでもdjango-ninjaやdrf-spectacularのようなライブラリでOpenAPI対応は可能ですが、標準機能ではなく追加の選定・導入作業が発生します。
選択肢の比較
| 観点 | Django | FastAPI |
|---|---|---|
| 設計思想 | バッテリー同梱のフルスタック | 軽量・組み立て式のAPIフレームワーク |
| 非同期処理 | 部分対応（ASGI対応だが同期前提の資産も多い） | 非同期ファースト |
| 管理画面・ORM | 標準搭載 | 別途SQLAlchemy等を選定 |
| API仕様書生成 | 追加ライブラリが必要 | 標準で自動生成 |
| 向いている領域 | マーケットプレイス、社内ダッシュボード、課金付きSaaS | 推論API、Webhook処理、モバイルバックエンド |
ケース別の推奨
- 管理画面・会員管理・課金が絡むSaaSを最短で形にしたいなら、Djangoを選びます
- 機械学習モデルの推論エンドポイントや高並行なAPI統合を作るなら、FastAPIを選びます
- フロントエンド・モバイルチームと仕様書ベースで連携する必要が強いなら、FastAPIのOpenAPI自動生成が効いてきます
- 将来的に管理画面や複雑な権限モデルが必要になる見込みが高いなら、最初からDjangoを選んでおくほうが手戻りが少なくなります
判断に迷う場合、どちらか一方の基礎をしっかり持つエンジニアを採用する考え方もあります。SQLとデータモデリング、pytestによるAPIレベルのテスト、Docker・CI・環境設定といった基礎は両フレームワークに共通して必要なスキルです。基礎が固まっていれば、もう一方のフレームワークへの移行は数週間程度で済むとされています。
あえて見送るべき条件
Djangoを見送るべきなのは、APIがシステムの全てで、画面や管理機能をほぼ必要としない場合です。Django Adminやテンプレートエンジンといった機能が使われないまま、学習コストだけがかかります。
FastAPIを見送るべきなのは、逆に管理画面・権限モデル・会員機能など「よくあるWeb UI業務」が中心の場合です。これらをFastAPI上で自前構築すると、Djangoなら標準機能で済む部分に開発工数を割くことになります。
また、チームにPythonの非同期処理に不慣れなメンバーが多い場合もFastAPIは慎重に検討すべきです。async関数の中で同期関数を誤って呼び出すと、イベントループをブロックして性能が出ない、という典型的な不具合が起きやすいためです。
技術面接で確認すべきポイント
フレームワークを決めたら、採用候補者のスキルを見極める質問も用意しておくと判断の精度が上がります。
Django向け: 関連オブジェクトを含むリスト画面が遅い場合、どうデバッグしますか
FastAPI向け: 同期関数をasyncエンドポイントの中で実行するとどうなりますか前者はN+1問題（関連データを取得する際に不要なクエリが大量発行される問題）への理解を、後者は非同期処理の仕組みへの理解を確認する質問です。フレームワークの用語を知っているかどうかより、こうした実務的な問いへの回答のほうが実力を映し出します。
まとめ
DjangoかFastAPIかは、流行や好みではなく「何を作るか」で決まります。
- 管理画面・CRUD・課金が中心ならDjango、APIそのものが成果物ならFastAPIという軸で考えます
- 非同期処理の必要性とOpenAPI自動生成の必要性は、追加の判断軸として確認します
- SQL設計・テスト・Docker・セキュリティ基礎は、どちらを選んでも共通して必要なスキルです
- 迷った場合は、現在のプロジェクトで6ヶ月後に何が必要になっているかを先に書き出してみると選びやすくなります
まずは自分のプロジェクトの画面要件とAPI要件を棚卸しし、この記事の判断軸に当てはめてみてください。