Express

この用語をシェア

概要

Express（Express.js）は、Node.js環境で動作する最も歴史が長く利用実績の多いWebアプリケーションフレームワークです。2010年にTJ Holowaychukによって公開され、RubyのWebフレームワークSinatraの「薄いルーティング層」という設計思想を強く受け継いでいます。現在はOpenJS Foundation配下のプロジェクトとして運営され、npmのexpressパッケージとして配布されています。

公式が掲げる「Fast, unopinionated, minimalist web framework（高速・非オピニオン型・最小限）」というキャッチコピーどおり、Expressのコア自体はルーティングとミドルウェア実行の仕組みしか持ちません。認証、DB接続、入力値検証、ロギングといった機能はすべてサードパーティ製のミドルウェアやライブラリを組み合わせて実現します。この「フレームワークが開発者の設計判断に介入しない」割り切りが、Ruby on RailsやDjangoのようにディレクトリ構成や設計方針まで規定する「フルスタック型」フレームワークとの決定的な違いであり、Node.js上でAPIサーバーやSPAのバックエンドを構築する際の事実上の標準（デファクトスタンダード）としての地位を長年にわたり保っている理由でもあります。

特徴

• ミニマル設計：必要最小限の機能でシンプルかつ高速
• ミドルウェアアーキテクチャ：機能をモジュラー化した柔軟な構成
• 豊富なルーティング：HTTPメソッド、URLパラメータ、パスパターンに対応
• テンプレートエンジンサポート：EJS、Pug、Handlebars等と連携
• 静的ファイル配信：CSS、JavaScript、画像の簡単な配信
• 大規模エコシステム：豊富なサードパーティライブラリ
• 開発効率：シンプルなAPIで素早いプロトタイピング

アーキテクチャ（仕組み）

Expressは以下のシンプルで柔軟なアーキテクチャを採用しています。

• ミドルウェアスタック：リクエスト処理を連鎖的に実行
• ルーターシステム：URLパスとHTTPメソッドのマッピング
• Request/Responseオブジェクト：Node.jsのコア機能を拡張した便利なAPI
• アプリケーションインスタンス：一つのExpressアプリで全てを管理
• エラーハンドリング：中央集権的なエラー処理機構

Expressの処理の中心にあるのは「ミドルウェア関数」という単純な概念です。ミドルウェアは (req, res, next) という3つの引数（エラー処理用は先頭に err が加わり4引数）を取る通常の関数にすぎず、app.use() や app.get() などで登録した順にスタックへ積まれ、リクエストが来るたびに先頭から順に実行されます。ミドルウェア内で next() を呼べば処理は次のミドルウェアへ渡り、next(err) を呼べば通常の処理チェーンを飛び越えて4引数のエラーハンドリング用ミドルウェアへジャンプします。この「関数を鎖のようにつなぐだけ」の仕組みが、認証チェック・ロギング・レスポンス圧縮・エラー処理といった横断的関心事を疎結合に組み合わせられる柔軟性の源泉になっています。

app.use(express.json());
app.use(requestLogger);
app.get('/users/:id', authenticate, async (req, res, next) => {
  try {
    const user = await User.findById(req.params.id);
    res.json(user);
  } catch (err) { next(err); }
});
// 4引数シグネチャはエラーハンドラとして扱われる
app.use((err, req, res, next) => {
  res.status(500).json({ error: err.message });
});

なお、Express 5系ではこのエラーハンドリングの仕組みが強化され、ルートハンドラがreturnするPromiseがreject（例外throwを含む）した場合、上記のような明示的なtry/catchとnext(err)の呼び出しがなくても自動的にエラーハンドリング用ミドルウェアへ委譲されるようになりました。Express 4系までは非同期関数内で例外を投げてもExpressが検知できず、プロセスがクラッシュしたりリクエストが応答なしのまま固まったりする事故が起きやすい典型的な落とし穴でした。

具体例・ユースケース

Expressが実際の開発現場でどのように使われているか、具体的な場面で見てみます。

• SPA/モバイルアプリ向けのBFF（Backend for Frontend）：ReactやVueで作ったフロントエンドから呼び出されるJSON REST APIサーバー。認証はJWTやセッションCookie、DB接続はPrisma・Mongoose・Sequelizeなどと組み合わせるのが典型的な構成です。
• Webhook受信サーバー：Stripeの決済通知、GitHub Actionsのイベント通知、Slackのoutgoing webhookなど外部SaaSからのコールバックを受けるエンドポイント。Stripeのように署名検証のため生のリクエストボディが必要なケースでは、通常使うexpress.json()ではなくexpress.raw({ type: 'application/json' })をそのルートだけ個別に適用する、という実務でよくある工夫が必要になります。
• 社内管理画面・ダッシュボード：EJSやPugといったテンプレートエンジンでサーバーサイドレンダリングし、フロントエンドのビルド環境を持たずに素早く画面を用意したい社内ツールとの相性がよい用途です。
• マイクロサービスの1コンポーネント：Docker/Kubernetes環境で、ヘルスチェック用エンドポイントと少数のAPIだけを持つ軽量なサービスとして起動時間の短さを活かす使い方。
• リアルタイム通信の土台：Socket.ioは内部でHTTPサーバーを必要とするため、既存のExpressアプリのHTTPサーバーインスタンスにSocket.ioをアタッチしてチャットや通知機能を追加するパターンが定番です。

メリット・デメリット（注意点）

Expressを採用する前に把握しておきたい長所と短所を整理します。

メリット	デメリット・注意点
学習コストが低く、公式ドキュメント・書籍・Q&Aサイトの情報量が圧倒的に多い	非オピニオン型ゆえにディレクトリ構成やレイヤー分けをチームで自前設計する必要があり、大規模開発では設計統一のコストがかかる
Passport・Multer・express-sessionなど10年以上蓄積されたミドルウェア資産をそのまま利用できる	標準では入力値バリデーションの型安全性がなく、TypeScript併用でもreq.bodyは基本的にany扱いになりがちで、zodやexpress-validator等の別導入が事実上必須
特定のディレクトリ構成やDIコンテナを強制しないため、既存システムへの組み込みや小規模な追加開発が容易	Fastifyと比較するとルーティング解決やJSONシリアライズのオーバーヘッドが大きく、高スループットがシビアに求められる場面では見劣りする
Node.jsの非同期I/Oを活かし、単一プロセスでも多数の同時接続をさばける	Express 4系は長期間メジャーアップデートが止まっていた経緯があり、周辺ミドルウェアの中にはメンテナンスが停滞しているものも混在する

混同されやすい用語・類似技術との違い

Node.jsのサーバーフレームワークはExpress以外にも多数あり、名前や役割が近いため混同されやすいものを整理します。

技術	Expressとの違い
Koa	Expressの開発者であるTJ Holowaychuk自身が手がけた後継的フレームワーク。async/awaitをネイティブ前提にしたミドルウェア設計でコールバック地獄を回避しますが、ルーターすら標準搭載せず別途プラグインが必要なほどコアがさらに薄く、Expressほどの普及は見せていません。
Fastify	JSON Schemaによるバリデーションとレスポンスのシリアライズをコアに組み込み、高いスループットを謳うフレームワーク。プラグインシステムやOpenAPIとの親和性が高く、パフォーマンスと型安全性を重視する新規プロジェクトの有力な選択肢です。
NestJS	内部的にExpress（またはFastify）をHTTPアダプタとして利用しつつ、Angular風のDIコンテナ・デコレータ・モジュールシステムを提供するフルスタックフレームワーク。「素のルーティング」しか提供しないExpressに対し、NestJSは大規模開発向けの規約とアーキテクチャそのものを強制する対極的な思想です。
Hono	Cloudflare Workers・Deno・Bunなどのエッジ／マルチランタイム環境向けに設計された超軽量フレームワーク。Web標準のRequest/Responseに準拠しており、Node.js専用のExpressに比べて動作環境を選ばない点が最大の違いです。
Next.js API Routes / Route Handlers	フロントエンドフレームワークNext.jsに内蔵されたサーバー機能。単体のバックエンドフレームワークであるExpressとは異なり、ページと同じプロジェクト内にAPIエンドポイントを同居させる形態で、フルスタックReactアプリでバックエンドを別立てしたくない場合の代替手段になります。

なお「Express」と「Express.js」は同一のものを指す表記ゆれで、npmパッケージ名はexpressです。またJavaのSpring、PythonのFlask/Django等と役割の対応関係で語られることが多いですが、それぞれ言語・実行環境が異なるため機能や設計思想を一対一で比較できない点にも注意が必要です。

主な用途

• REST API開発：JSON APIサーバーの構築
• SPAバックエンド：React、Vue.js、AngularアプリのAPIサーバー
• マイクロサービス：小さな独立したサービスコンポーネント
• プロトタイプ開発：素早いMVP作成と検証
• 企業Webアプリ：管理システム、ダッシュボード
• IoTバックエンド：デバイスデータ収集・API
• チャットアプリ：Socket.ioと組み合わせたリアルタイム通信

パフォーマンス

Expressのパフォーマンス特性：

• 高速起動：ミニマルなコアで素早いサーバー起動
• 低オーバーヘッド：必要最小限のメモリ使用量
• 高スループット：Node.jsのイベントループを活用した高速処理
• 同時接続：非同期 I/O で多数の同時リクエスト処理
• スケーラビリティ：クラスタリング、ロードバランシングで水平スケール

ただし注意したいのは、Expressのミドルウェアチェーンは登録した順に必ず全件を通過する仕組みであるため、ミドルウェアの数が増えるほどリクエストごとのオーバーヘッドが積み重なる点です。特にボディパーサーやロギング、CORSチェックなど汎用ミドルウェアをapp.use()で無条件に全ルートへ適用していると、静的ファイル配信のような軽い処理にも不要なコストがかかりがちです。実務では、認証やバリデーションのように特定のルートにしか要らないミドルウェアはapp.use()ではなく該当ルートの引数として個別に渡し、常時実行するミドルウェアを最小限に絞り込むのが定石です。また、Fastifyが謳う数倍規模のスループット差は主にJSONのシリアライズ処理とルーティングのマッチング方式の違いによるもので、DBアクセスやI/O待ちがボトルネックになる典型的なWebアプリケーションでは、フレームワーク自体の処理速度差が体感できるほど問題になるケースは限定的です。

エコシステム

Expressを中心とした豪華なライブラリ群：

• Passport.js：包括的な認証ライブラリ（OAuth、JWT等）
• Mongoose：MongoDBオブジェクトモデリングライブラリ
• Socket.io：リアルタイム双方向通信ライブラリ
• Helmet：HTTPセキュリティヘッダー設定
• Morgan：HTTPリクエストロガーミドルウェア
• CORS：クロスオリジンリソースシェアリング設定
• Express Validator：リクエストデータ検証
• Compression：HTTPレスポンス圧縮
• Multer：multipart/form-data形式のファイルアップロード処理
• express-rate-limit：IPアドレス単位のリクエスト回数制限
• express-session / connect-redis：セッション管理とRedisなどのストア連携
• Prisma / Sequelize / TypeORM：SQLデータベース向けのORM。ExpressのルートハンドラからそのままCRUD処理を呼び出す構成が一般的

これらはExpressが公式に提供しているものではなく、あくまで独立したnpmパッケージ群です。Expressのコアが機能を持たない分だけ、プロジェクトの要件に応じて必要なライブラリだけを選んで組み合わせられる点が、Djangoのように認証やORMが最初から同梱されているフレームワークとの大きな違いです。裏を返せば、どのライブラリを選定し、どうバージョンを維持するかという判断・保守コストをすべてプロジェクト側が負う設計だとも言えます。

よくある質問（FAQ）