前回との接続とこの講義の役割
前回のJ-04では、メソッドとパスの組み合わせで処理を振り分けるルートと、その処理本体であるハンドラーを見ました。ただし、多くのルートには共通してやりたい仕事があります。たとえば、誰からのリクエストかを記録するログや、送られてきた本文を読める形に直す解析です。この講義では、そうした共通の仕事を、ハンドラーの手前や応答の直前にまとめて挟む仕組みを扱います。
このスライドのポイント
- 前回J-04: メソッド×パスで処理を振り分けるルートと、処理本体であるハンドラー
- ただし多くのルートには共通してやりたい仕事がある（ログ、本文の解析など）
- この講義: その共通の仕事を、ハンドラーの手前や応答の直前にまとめて挟む仕組み
ミドルウェアの定義
ミドルウェアとは、リクエストがハンドラーへ届く前、または応答が返る前に、共通で通る処理の層のことです。代表的な例は四つあります。一つ目はログの記録、二つ目はD-03で見た本文のJSONを読める形に直す解析、三つ目は認証の確認、四つ目はD-10で学んだCORSヘッダーの付与です。認証の詳しい仕組みはカテゴリQで扱いますので、ここでは共通処理の一つとして押さえてください。ミドルウェアは一つだけとは限らず、複数が直列に並んで順に通ります。
このスライドのポイント
- ミドルウェア＝リクエストがハンドラーへ届く前、または応答が返る前に、共通で通る処理の層
- 代表例4つ: ①ログの記録 ②本文の解析（D-03のJSONを読める形に）③認証の確認（詳細はカテゴリQ）④CORSヘッダーの付与（D-10）
- 1つとは限らず、複数が直列に並んで順に通る
なぜ必要か
もしミドルウェアという発想がないと、同じ認証チェックのコードを、すべてのハンドラーに書き写すことになります。これはE-07で学んだ関数化や、H-10で学んだ共通化と同じ原理を、サーバーの共通処理に当てはめる場面です。コピーが増えるほど、直すときに一部を修正し忘れる危険が高まります。さらに、D-10で見たCORSの許可ヘッダーが、いったいコードのどこで付いているのかも分からなくなります。
このスライドのポイント
- ミドルウェアがないと、同じ認証チェックを全ハンドラーに書き写すことになる
- E-07の関数化・H-10の共通化と同じ原理を、サーバーの共通処理へ適用する場面
- コピーが増えるほど、直すときに一部を修正し忘れる危険が高まる
- D-10のCORS許可ヘッダーが「どこで付くのか」も分からなくなる
構造——通過順に意味がある
構造をトンネルに例えて見てみます。リクエストは、まずログの層を通り、次に本文の解析、続いて認証の確認という順にトンネルを進み、ハンドラーへ到達します。ハンドラーが処理を終えると、応答は共通ヘッダーを付ける層を通って返っていきます。ここで大切なのは、通る順番に意味があることです。たとえば本文を解析する前の層では、まだ中身を読むことはできません。順番を間違えると、必要なデータがまだ用意されていない、という不具合が起きます。
このスライドのポイント
- トンネルに例える: リクエストが層を順に通ってハンドラーへ到達し、応答が層を通って返る
- 通過順: リクエスト→[ログ]→[解析]→[認証]→ハンドラー→[共通ヘッダー付与]→応答
- 順番に意味がある（解析前の層では、まだ本文の中身は読めない）
処理の流れ——CORS許可はミドルウェアで付ける
具体例として、D-10で学んだCORSの許可を思い出してください。どのブラウザからのアクセスを認めるかを示すヘッダーは、ルートごとに書くのではなく、ミドルウェアで全ての応答にまとめて付けるのが定石です。こうすれば、一箇所の設定が全てのルートに効きます。新しいルートを追加しても、CORSの設定を書き忘れて特定の画面だけ通信が弾かれる、といった事故を防げます。共通の仕事を一箇所に集めることが、抜けをなくす近道になります。
このスライドのポイント
- D-10のCORS許可ヘッダーは、ルートごとではなくミドルウェアで全応答にまとめて付けるのが定石
- 一箇所の設定が全ルートに効く
- 新ルートを追加してもCORS設定の書き忘れを防げる（特定の画面だけ通信が弾かれる事故の予防）
技術サンプルカード（diagram）
サンプルは図解です。目的は、ある共通処理をどの層に置くべきかを判断できるようになることです。トンネル図で通過順を確かめたうえで、判定の三つの問いを使います。全てのルートで必要ならミドルウェアへ、特定のルートだけで必要ならそのハンドラーの中へ、画面上の見た目の親切ならフロントエンドへ置きます。読み方の要点は、置き場所は通過順と適用範囲で決まることです。AIには「ミドルウェアを通過順に列挙し、役割を説明してください」と聞くとよいでしょう。
混同しやすい概念
混同しやすいのが、ミドルウェアとハンドラーの違いです。ミドルウェアは全てのルートに共通で、通過する順番が意味を持ちます。一方ハンドラーは、J-04で見たとおり、特定のルートだけに固有の処理です。もしAIが作ったコードで、同じ認証チェックがハンドラーごとにコピーされていたら、それはミドルウェアへ一元化すべきサインです。共通化を指示しましょう。
バイブコーディングでの確認点
バイブコーディングでの確認点です。AIが生成したサーバーコードには「認証の確認はミドルウェアで一元化されていますか。抜けているルートはありませんか」と聞いてください。認証チェックが一本でも抜けていると、そのルートだけ無防備になり、事故につながります。一元化されていれば、抜けを探す手間も、直すときの修正箇所も一つで済みます。
このスライドのポイント
- AIのサーバーコードには「認証の確認はミドルウェアで一元化されていますか。抜けているルートはありませんか」と確認
- 認証チェックが一本でも抜けると、そのルートだけ無防備になり事故につながる
- 一元化されていれば、抜けを探す手間も修正箇所も一つで済む
一問一答とまとめ
最後に一問一答です。全てのルートに共通する処理を置く場所はどこでしょうか。……答えはミドルウェアです。三十秒でまとめます。ミドルウェアは、リクエストがハンドラーへ届く前や応答が返る前に共通で通る処理の層で、ログ、本文の解析、認証、CORSヘッダーの付与などをまとめて担い、複数が順に直列で通ります。次回のJ-06では、共通処理の中でも最重要のサーバー側入力検証へ進みます。関連資料は「AIアプリのセキュリティ超入門」「API連携 超入門」です。
このスライドのポイント
- 一問一答: 全ルート共通の処理を置く場所は？ → ミドルウェア
- 30秒まとめ: ミドルウェアはリクエストがハンドラーへ届く前・応答が返る前に共通で通る層。ログ・解析・認証・CORSヘッダー付与を担い、複数が直列で通る
- 次回J-06: 共通処理の中でも最重要の、サーバー側入力検証へ
- 関連資料: AIアプリのセキュリティ超入門／API連携 超入門
