はじめに
Spring Boot の Web アプリや API を作っていると、
Filter と Interceptor という 2 つの仕組みを目にします。
- どっちを使えばいいの？
- 役割の違いは？
- 実務ではどう使い分けるの？
こういった疑問はとても多いです。
この記事では、Filter と Interceptor の違いを
やさしく・実務寄り で整理していきます。
まずは全体像から見ていきましょう。
Filter / Interceptor の違いを一言でいうと…
Filter → Servlet レベルの前処理・後処理
Interceptor → Spring MVC レベルの前処理・後処理
です。
- Filter はもっと“下の層”
- Interceptor は Spring MVC に近い“上の層”
というイメージを持つと理解しやすいです。
リクエストの流れを図で理解する
┌──────────────┐
│ Filter（Servlet） │ ← 一番外側
└───────────┬────┘
│
┌───────────▼──────────┐
│ Interceptor（Spring MVC） │ ← Controller の手前
└───────────┬──────────┘
│
┌───────────▼──────────┐
│ Controller │
└────────────────────────┘
Filter → Interceptor → Controller
の順に処理されます。
Filter の役割
一言でいうと
「アプリ全体のリクエストを横断的に処理する仕組み」
特徴
- Servlet レベルで動く
- Spring に依存しない
- すべてのリクエストが対象
- 認証・ログ・CORS などに向いている
コード例
@Component
public class LoggingFilter implements Filter {
@Override
public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)
throws IOException, ServletException {
System.out.println("Filter: before");
chain.doFilter(request, response);
System.out.println("Filter: after");
}
}向いている用途
- リクエスト全体のログ
- CORS
- 認証（トークンの検証など）
- 文字コード設定
Interceptor の役割
一言でいうと
「Controller の前後で処理を挟む仕組み」
特徴
- Spring MVC に依存
- Handler（Controller）単位で動く
- HandlerMethod の情報が取れる
- 認可・業務的な前処理に向いている
コード例
@Component
public class AuthInterceptor implements HandlerInterceptor {
@Override
public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) {
System.out.println("Interceptor: before");
return true;
}
@Override
public void postHandle(HttpServletRequest request, HttpServletResponse response,
Object handler, ModelAndView modelAndView) {
System.out.println("Interceptor: after");
}
}向いている用途
- 認可（権限チェック）
- Controller の前処理
- Controller の後処理
- HandlerMethod の情報を使う処理
Filter と Interceptor の違いを表で整理
| 項目 | Filter | Interceptor |
|---|---|---|
| 層 | Servlet | Spring MVC |
| 適用範囲 | 全リクエスト | Controller 単位 |
| 取得できる情報 | リクエスト全体 | HandlerMethod（Controller の情報） |
| 主な用途 | 認証・ログ・CORS | 認可・業務的前処理 |
| 実行タイミング | 一番外側 | Controller の前後 |
| Spring 依存 | なし | あり |
この表だけで、実務の 8 割は理解できます。
実務での使い分け
認証（トークン検証） → Filter
リクエスト全体に対して行う処理。
認可（権限チェック） → Interceptor
Controller の情報（メソッド名・アノテーション）を使いたい。
ログ → Filter
全リクエストを対象にしたい。
業務的な前処理 → Interceptor
Controller の前で処理したい。
CORS → Filter
Servlet レベルで処理するのが基本。
実務でよくあるアンチパターン
Interceptor で認証を行う
→ 全リクエストに適用したい場合は Filter の方が適切。
Filter で Controller の情報を使おうとする
→ Filter では HandlerMethod が取れません。
Controller に前処理を書いてしまう
→ Interceptor に移すとコードがきれいになります。
Filter / Interceptor をもっと活かすポイント
HandlerMethod を使うと柔軟な認可ができる
Interceptor なら
- メソッド名
- アノテーション
- クラス名
が取得できます。
Filter は Spring に依存しない
Servlet の知識があれば理解しやすい。
Interceptor は Spring MVC の流れを理解するのに最適
Controller の前後で処理を挟めます。
まとめ
Filter / Interceptor の違いは、
- Filter → Servlet レベル（全体の前処理）
- Interceptor → Spring MVC レベル（Controller の前後処理）
です。
- 認証 → Filter
- 認可 → Interceptor
- ログ → Filter
- 業務的な前処理 → Interceptor
難しく聞こえますが、
「Filter は外側、Interceptor は Controller の近く」
と理解できれば十分です。
Filter と Interceptor の違いを理解すると、
リクエスト処理の流れが一気にクリアになります。
前処理・後処理をどこに書くべきか迷わなくなるだけで、
設計も保守もぐっと楽になります。
あなたの開発が、今日より少しだけ楽になりますように。
外側で見守る Filter さんと、近くで支える Interceptor さん…
役割分担ってすてきだね。
コメント