PythonのFastAPI vs TypeScriptのHono:2026年のモダンAPI開発で選ぶなら

FastAPIとHonoの比較概要 プログラミング

1. はじめに

現代のバックエンド開発において、「型安全」「高速な実行速度」は欠かせない要素になっています。その中で今、圧倒的な支持を集めている2つのフレームワークがあります。

  • FastAPI: Pythonの型ヒントを駆使し、データ分析やAI連携に強いバックエンドの標準。
  • Hono: Web標準(Fetch API)に準拠し、エッジ/サーバーレス環境で圧倒的な軽さを誇るTypeScriptの新星。

言語の違いもあり簡単には比較できず、自分もどちらを使うか考えることが多くなりました。

本記事では、Pythonに親しんできた筆者の実体験をもとに、2つの設計思想の違い、実用的なCRUDコード比較、デプロイコスト、そして最終的に筆者がHono(Cloudflare Workers)を選んだ決定的な理由まで徹底解説します。

2. 概要比較:基本スペックの決定的な違い

まずは両者の立ち位置を整理します。これらは単なる言語の違いだけでなく、「実行環境(ランタイム)」の思想が根本的に異なります。

項目FastAPI (Python)Hono (TypeScript)
主な言語Python (3.8+)TypeScript / JavaScript
型システムの核Python Type Hints + PydanticTypeScript Native + Zod等
ドキュメントOpenAPI (Swagger UI) が標準で自動生成hono/zod-openapi 等の追加設定が必要
得意な領域AI・機械学習連携、データ処理、重厚なビジネスロジックエッジコンピューティング、超軽量マイクロサービス、フロントエンドとの型共有(RPC)
主な実行環境UvicornなどのASGIサーバー(伝統的なVPS/コンテナ)Cloudflare Workers、Bun、Deno、AWS Lambda、Node.js(マルチランタイム)

3. 具体的なコード比較(CRUDの基本例)

「パスパラメータの取得」と「リクエストボディのバリデーション(型チェック)」を行うシンプルなエンドポイントで比較します。

FastAPIのコード例

FastAPIは Pydantic を使ってリクエストのバリデーションを行います。

from fastapi import FastAPI, HTTPException, status
from pydantic import BaseModel
from typing import Dict

app = FastAPI()

# 擬似データベース(メモリ上の辞書)
# 構造: { user_id: {"name": str, "age": int} }
user_db: Dict[int, dict] = {}

# --- Pydanticモデル(バリデーション用) ---

# 作成・更新時のリクエストボディ用
class UserItem(BaseModel):
    name: str
    age: int

# レスポンス用(必要に応じてメッセージなどを追加できる型)
class UserResponse(BaseModel):
    user_id: int
    name: str
    age: int


# --- CRUD操作のエンドポイント ---

# 1. CREATE (作成): ユーザーの新規登録
@app.post(
    "/users/{user_id}", 
    response_model=UserResponse, 
    status_code=status.HTTP_201_CREATED
)
async def create_user(user_id: int, item: UserItem):
    if user_id in user_db:
        raise HTTPException(
            status_code=status.HTTP_400_BAD_REQUEST, 
            detail=f"User with ID {user_id} already exists."
        )
    
    # データを保存
    user_db[user_id] = item.model_dump() # Pydantic v2の書き方 (v1の場合は .dict())
    
    return {
        "user_id": user_id,
        **user_db[user_id]
    }


# 2. READ (読み取り): ユーザー情報の取得
@app.get("/users/{user_id}", response_model=UserResponse)
async def read_user(user_id: int):
    if user_id not in user_db:
        raise HTTPException(
            status_code=status.HTTP_404_NOT_FOUND, 
            detail="User not found"
        )
    
    return {
        "user_id": user_id,
        **user_db[user_id]
    }


# 3. UPDATE (更新): ユーザー情報の全更新
@app.put("/users/{user_id}", response_model=UserResponse)
async def update_user(user_id: int, item: UserItem):
    if user_id not in user_db:
        raise HTTPException(
            status_code=status.HTTP_404_NOT_FOUND, 
            detail="User not found"
        )
    
    # 既存のデータを上書き
    user_db[user_id] = item.model_dump()
    
    return {
        "user_id": user_id,
        **user_db[user_id]
    }


# 4. DELETE (削除): ユーザーの削除
@app.delete("/users/{user_id}", status_code=status.HTTP_204_NO_CONTENT)
async def delete_user(user_id: int):
    if user_id not in user_db:
        raise HTTPException(
            status_code=status.HTTP_404_NOT_FOUND, 
            detail="User not found"
        )
    
    # データを削除
    del user_db[user_id]
    
    # 204 No Content を返すため、値は return せず終了します
    return

Honoのコード例

Honoは Zod などのバリデータと組み合わせることで、TypeScriptの強力な型安全性を活かせます。

import { Hono } from 'hono'
import { HTTPException } from 'hono/http-exception'
import { zValidator } from '@hono/zod-validator'
import { z } from 'zod'

const app = new Hono()

// 擬似データベース(メモリ上のマップ)
// 構造: Map<number, { name: string; age: number }>
const userDb = new Map<number, { name: string; age: number }>()

// --- Zodスキーマ(バリデーション用) ---

// パスパラメータのバリデーション用(文字列として入ってくるIDを数値に変換)
const paramSchema = z.object({
  user_id: z.string().transform((val) => {
    const parsed = parseInt(val, 10)
    if (isNaN(parsed)) {
      throw new HTTPException(400, { message: 'Invalid user_id format' })
    }
    return parsed
  })
})

// リクエストボディ用
const userItemSchema = z.object({
  name: z.string().min(1, 'Name is required'),
  age: z.number().int().positive()
})


// --- CRUD操作のエンドポイント ---

// 1. CREATE (作成): ユーザーの新規登録
app.post(
  '/users/:user_id',
  zValidator('param', paramSchema),
  zValidator('json', userItemSchema),
  (c) => {
    const { user_id } = c.req.valid('param')
    const { name, age } = c.req.valid('json')

    if (userDb.has(user_id)) {
      throw new HTTPException(400, { message: `User with ID ${user_id} already exists.` })
    }

    // データを保存
    const newUser = { name, age }
    userDb.set(user_id, newUser)

    // 201 Created で返却
    return c.json({ user_id, ...newUser }, 201)
  }
)


// 2. READ (読み取り): ユーザー情報の取得
app.get(
  '/users/:user_id',
  zValidator('param', paramSchema),
  (c) => {
    const { user_id } = c.req.valid('param')
    const user = userDb.get(user_id)

    if (!user) {
      throw new HTTPException(404, { message: 'User not found' })
    }

    return c.json({ user_id, ...user })
  }
)


// 3. UPDATE (更新): ユーザー情報の全更新
app.put(
  '/users/:user_id',
  zValidator('param', paramSchema),
  zValidator('json', userItemSchema),
  (c) => {
    const { user_id } = c.req.valid('param')
    const { name, age } = c.req.valid('json')

    if (!userDb.has(user_id)) {
      throw new HTTPException(404, { message: 'User not found' })
    }

    // 既存のデータを上書き
    const updatedUser = { name, age }
    userDb.set(user_id, updatedUser)

    return c.json({ user_id, ...updatedUser })
  }
)


// 4. DELETE (削除): ユーザーの削除
app.delete(
  '/users/:user_id',
  zValidator('param', paramSchema),
  (c) => {
    const { user_id } = c.req.valid('param')

    if (!userDb.has(user_id)) {
      throw new HTTPException(404, { message: 'User not found' })
    }

    // データを削除
    userDb.delete(user_id)

    // 204 No Content を返却 (ボディは空)
    return c.body(null, 204)
  }
)

export default app

ここがポイント!

FastAPIは関数に型ヒントを書くだけで、自動的にバリデーションとSwagger UIドキュメントが生成される手軽さがあります。一方、HonoはWeb標準(Request/Response)に近いクリーンなコードになり、フロントエンド(Next.jsなど)とAPIの型を共通化(RPCモード)できる独自の強みを持っています。

開発体験(DX)の比較:自動ドキュメント vs 型共有(RPC)

両者の大きな差別化ポイントは「周辺開発エコシステムとの連携」にあります。

FastAPIとHonoの開発方法の比較

FastAPI:Swagger UIによるドキュメント自動生成

FastAPI最大の強みは、コードを書くだけで /docs にInteractiveなSwagger UIが自動生成される点です。 フロントエンドエンジニアやクライアントへの仕様共有、Postman等を使わない手軽なAPIテストにおいて圧倒的な利便性を誇ります。

Hono:RPC機能によるフロントエンドとのエンドツーエンド型安全

Honoは Next.js や React などのフロントエンド開発者にとって革命的な RPC(Remote Procedure Call)モード を備えています。

// フロントエンド側のコード例
import { hc } from 'hono/client'
import type { AppType } from './api' // Hono側の型定義のみインポート

const client = hc<AppType>('
https://api.example.com/
(https://api.example.com/)') // エディタ補完が効き、レスポンスの型も自動的に推論される! const res = await client.users[':user_id'].$get({ param: { user_id: '123' } })

OpenAPIの定義ファイルや型生成ツールを挟むことなく、APIの戻り値やリクエスト型がフロントエンド側で自動補完されるため、開発スピードが格段に上がります。

4. デプロイ・コスト・運用保守のリアルな比較

個人開発や小規模プロダクトにおいて、「どこにどうデプロイして、いくらかかるか」は極めて重要です。

VPSのDockerとCloudflareWorkersのデプロイ比較

FastAPIのデプロイ先

FastAPIはバックグラウンドでプロセスが常駐する「伝統的なサーバー環境」や「コンテナ」が一般的です。

  • Docker + VPS(エックスサーバーVPS、Ubuntuなど) / クラウド(AWS EC2など)
    • Dockerfile を作成し、UvicornなどのASGIサーバーを動かす構成。インフラを自由に制御したい場合に最適です。
  • Render / Railway
    • PaaS環境。GitHub連携だけで簡単にPythonアプリをWebサービスとして公開できます。
    • 一定のメモリ消費とコールドスタートが発生。

Honoのデプロイ先

Honoの最大の強みは、「どこでも動く(Multi-runtime)」点です。特にサーバーレス/エッジ環境との相性が抜群です。

  • Cloudflare Workers
    • Hono開発者がもっとも推奨する環境の一つ。世界中のエッジサーバーでミリ秒以下で起動(コールドスタートなし)。
    • コスト: 1日10万リクエストまで完全無料。個人開発レベルならほぼ無償で運用可能。
  • Vercel Edge Functions / AWS Lambda
    • ベンダーロックインなしで他環境への移行もコード変更なしで容易。
    • Next.jsなどのフロントエンドと一元管理したい場合に最適です。
  • AWS Lambda / Bun / Deno Deploy
    • 環境に依存しないため、インフラの移行がコード変更なしで行えます。

5. まとめ:どちらを選ぶべきか?

最終的な選定基準をまとめます。

  • FastAPIを選ぶべきケース
    1. プロジェクトで Pythonの豊富なエコシステム(機械学習、データ解析、スクレイピング) を利用したい。
    2. コードを書くだけで自動生成される Swagger UI(APIドキュメント) が欲しい。
    3. すでにDockerやVPSなどの固定サーバー環境が手元にある。
  • Honoを選ぶべきケース
    1. TypeScript一本でフルスタックに開発したい(フロントエンドとAPIの型を同期させたい)。
    2. Cloudflare Workers などのエッジサーバーを活用し、グローバルに超低遅延で、格安(または無料)のインフラ運用をしたい。
    3. コールドスタート(サーバーレス特有の起動遅延)に悩まされたくない。

7. 筆者のリアルな結論

筆者自身、元々は書き慣れている Python と FastAPI の組み合わせに慣れていましたし、好んで使っていました。

しかし、フロントエンドで Next.js を本格的に採用し始めてから状況が変わりました。 「TypeScriptで言語を統一し、Hono RPCで型を共有する開発体験の快適さ」を知ってしまうと、APIドキュメントの手動整合や型定義の重複管理に戻れなくなったのです。

さらに、Cloudflare Workers を使うことで、面倒なDockerコンテナの管理やVPSの月額コストから解放され、完全無料で超高速なサーバーレス環境が手に入る 点が決定打となりました。

AI・データ処理がメインのプロジェクトなら今でも FastAPI を選びますが、WebアプリやAPIサーバーをサクッと構築・運用するなら、今の時代の最適解は Hono だと感じています。

ぜひご自身のプロジェクトの性質に合わせて、最適なフレームワークを選んでみてください!

コメント