pypi 0.141.1

fastapi のOSSカルテ

最終確認 2026年9月15日 02:13

6 観測できた項目

0 確認すべき点

1 データが取得できない項目

fastapi は 2026年9月15日時点で公開されている OSS です。当サイトで確認した範囲では、採用前に確かめておきたい点は見つかりませんでした。採用の可否は、使う版の既知の脆弱性・ライセンス・必要な機能を合わせてご判断ください。

リポジトリとの紐付け

リポジトリ紐付け: 検証済み

パッケージ名とリポジトリ名が一致していることを確認しました。来歴情報ほど強い裏付けではありませんが、名前を似せた別のパッケージが本物のリポジトリを指す場合は、この条件を満たしません。

deps.dev の relatedProjects: UNVERIFIED_METADATA
パッケージ名とリポジトリ名が一致します（fastapi ↔ fastapi/fastapi）

github.com/fastapi/fastapi

確認すべき点（0件）

当サイトで確認できた範囲では、確かめておきたい点は見つかりませんでした。 これは「問題が無い」という保証ではありません。 観測できなかった項目が 1 件あります。

観測した項目

確認できたライセンス MIT として公開されています。実際の利用条件は、リポジトリ内の LICENSE 原文をご確認ください。当サイトは法的な判断をしません。読み方

確認できた既知の脆弱性版 0.141.1 に影響する未修正の Advisory は見つかりませんでした。これは「脆弱性が無い」という意味ではありません。まだ公開されていないものは、ここには出てきません。読み方

確認できたリポジトリとの紐付け github.com/fastapi/fastapi と結び付いています。パッケージ名とリポジトリ名が一致していることを確認しました。来歴情報ほど強い裏付けではありませんが、名前を似せた別のパッケージが本物のリポジトリを指す場合は、この条件を満たしません。

確認できた直近の更新最後の push は 2026年9月1日です。読み方

確認できたリリース直近のリリースは 2026年7月29日です。読み方

データが取得できない OpenSSF Scorecard このリポジトリは OpenSSF の週次スキャンの対象外のため、スコアがありません。スキャンの対象は重要度の高いリポジトリに限られています。対象外であることは、問題があることを意味しません。

確認できた貢献者 30名の貢献が記録されています。読み方

当サイトの観測

直近のリリースからの経過	46 日
リリース間隔の中央値	0 日（直近30件から算出）
記録されている貢献者	30 名（上位30名まで）
最多貢献者の割合	55.9 %

⭐ Stars	102,333

採用前に確認すること

☐ ライセンスを確認した
☐ 使うバージョンの脆弱性を確認した
☐ パッケージとリポジトリの紐付けを確認した
☐ 保守の状態を確認した
☐ 脆弱性の報告先を確認した
☐ 代替手段を確認した
☐ 更新が止まったときの対応を決めた

詳しくは採用前の7項目チェックリストをご覧ください。

出典

ソース	状態
OSV.dev	取得しました
GitHub	取得済み（保存していた内容）
Open Source Insights (deps.dev)	取得しました
OpenSSF Scorecard	データがありません
Open Source Insights — 版の詳細	取得しました
GitHub — リリース	取得済み（保存していた内容）
GitHub — 貢献者	取得済み（保存していた内容）

Open Source Insights (deps.dev) が生成したデータは CC-BY 4.0 のもとで利用しています。 OpenSSF Scorecard のスコアは OpenSSF が算出したものです。詳しくはデータの出典をご覧ください。

OSSカルテの見方

Python の Web API フレームワークです。型ヒントから入力の検証と OpenAPI ドキュメントを自動生成するのが特徴で、 async def による非同期処理を前提に設計されています。ルーティングは Starlette、検証は Pydantic の上に構築されています。

採用を検討するときに迷う点

検討するときに実際に迷うのは、同期のコードを混ぜたときの挙動です。

FastAPI は async def と def の両方を受け付けますが、扱いが違います。

async def … イベントループ上でそのまま実行される
def … スレッドプールへ逃がされる

問題になるのは async def の中で同期のブロッキング処理を呼んだときです。 requests での通信、同期の DB ドライバ、重い CPU 処理などをそのまま書くと、 イベントループ全体が止まり、他のリクエストも待たされます。 エラーにならず「なぜか遅い」という形で出るため、原因を追いにくい種類の問題です。

対策は、非同期対応のライブラリを使う（httpx、asyncpg、SQLAlchemy の async）か、 def で定義してスレッドプールに任せるかのどちらかです。

その他、採用時に確認しておきたい点。

Pydantic のメジャーバージョン。 v1 と v2 で書き方が変わります。既存のコードや他のライブラリが v1 前提だと衝突します
本番の動かし方。 開発サーバーではなく、 Uvicorn（+ プロセス管理）や Gunicorn の worker として動かします
エコシステムの広さ。 管理画面や認証などは Django のように標準では付いてきません。自分で選んで組む前提になります

型ヒントを書く文化が定着していないコードベースに後から入れると、利点の大半（自動検証・自動ドキュメント）が得られない点も見ておくとよいでしょう。

同じ目的のOSSとの関係

Django は管理画面・ORM・認証・マイグレーションまで揃っており、 Web アプリ全体を作る場合に選択肢になります。API だけなら Django REST framework を併用します。

Flask は小さく始めたい場合の選択肢です。非同期は限定的で、入力検証やドキュメント生成は自分で組む形になります。

Litestar は FastAPI に近い設計で、より新しいフレームワークです。

「API だけを非同期で作る」なら FastAPI、「アプリ全体を作る」なら Django、という分かれ方が実務では多いようです。

ここは当サイトによる説明です。上の観測結果とは分けて表示しています。

リリースと活動の履歴

GitHub が公開している記録から遡ったものです。 当サイトの計測開始より前も含みます。

記録のある最初のリリース: 2018年12月15日; 遡れた 300 件のうち最も古いもの

93 直近12か月のリリース

3日リリース間隔の中央値

プレリリースは数えていません。平均ではなく中央値を出しています（1度だけ間が空いた年があると平均は歪むため）。

年ごとのリリース本数

2 18 65 19 31 20 14 21 25 22 32 23 25 24 51 25 52 26

最も多い年で 65 本。 本数の多さは、そのまま良し悪しを表しません。 細かく出す方針のプロジェクトと、まとめて出す方針のプロジェクトがあります。

週ごとのコミット数（直近52週）

合計 1,709 コミット / 最も多い週で 131 コミット。 GitHub の集計によるもので、マージコミットの扱いなど数え方は GitHub に従います。

当サイトでの観測の記録

当サイトでの計測開始: 2026年8月22日; 24日ぶん / 23回の観測

計測を始めてから、確認すべき点に関わる変化は観測していません。

記録が短いため、推移のグラフは表示していません。

OpenSSF Scorecard のスコアと脆弱性情報の状態は、 当サイトの計測開始より前には遡れません。 公開元が過去の値を残していないためです。リリース日や最終コミット日など、上の観測結果に出ている日付は GitHub などの記録によるもので、計測開始より前のものも含みます。

同じ目的のOSS

flask 小さく始める。同期が中心 django 管理画面や ORM まで揃う