前回の続き——引き金から「処理の重さ」へ
前回のK-08では、時刻を引き金にする定期実行を扱いました。今回は引き金ではなく、処理そのものの重さに注目します。ここまでの多くの処理は、リクエストを受けたその場で実行し、終わってから応答を返していました。しかし処理が重くなると、この「その場で全部やる」やり方が壊れます。この講義は、重い処理を安全に扱うための、分離の発想を身につける回です。
このスライドのポイント
- K-08では、時刻を引き金にする定期実行を扱った
- 今回は引き金ではなく、処理そのものの「重さ」に注目する
- これまでの多くの処理は「受けたその場で全部やって、終わってから返す」形だった
ジョブキューとワーカーの定義
ジョブキューとは、時間のかかる処理、つまりジョブを受け付けた順に並べておく待ち行列です。そして、その行列から順に取り出して実行する係をワーカーと呼びます。ワーカーはリクエストとは別のプロセス、B-02で見た独立した処理の流れとして動きます。構図はこうです。リクエストは「受け付けました」という応答、D-06の202が典型ですが、これを即座に返し、実際の処理は裏で進みます。F-04で学んだ非同期の考え方を、一つのアプリ全体へ広げた形だと捉えてください。
このスライドのポイント
- ジョブキュー = 時間のかかる処理（ジョブ）を、受け付けた順に並べておく待ち行列
- ワーカー = 行列から順に取り出して実行する係。リクエストとは別プロセス（B-02）で動く
- 構図: リクエストは「受け付けました」を即返し（D-06の202が典型）、実処理は裏で進む
- F-04で学んだ非同期の考え方を、アプリ全体へ広げた形
なぜ必要か——分離を知らないと重い機能が壊れる
この分離を知らないと、たとえばAIが「PDFを100枚まとめて処理する」機能を、リクエストの中で全部実行する設計として出してきたとき、その危うさに気づけません。処理が長引けばタイムアウトし、100枚すべての処理が失敗します。受付と完了は別のもの、という発想がないと、重い機能はことごとく壊れてしまいます。だからこそ、重い処理では最初から受付と実行を分けて設計する必要があるのです。
このスライドのポイント
- 「PDF100枚を一括処理」をリクエストの中で全部実行する設計をAIが出しがち
- 処理が長引けばタイムアウトし、100枚すべての処理が失敗する
- 「受付」と「完了」は別、という発想がないと、重い機能がことごとく壊れる
構造——受付・行列・実行・確認の4役割
全体像を見ます。まず受付側は、依頼を受け取ったら即座に202を返します。依頼は待ち行列であるキューに積まれ、ワーカーが順番に取り出して実行します。実行が終わると結果が記録され、画面は後からその結果を確認します。この「後から結果を取りに行く」動きは、I-10で見た再検証と同じ考え方です。受付・行列・実行・確認という四つの役割が、それぞれ独立して並んでいる点が要点です。
このスライドのポイント
- 受付: 依頼を受け取ったら即座に202を返す
- 行列（キュー）: 依頼を積んでおく待ち行列
- 実行（ワーカー）: 順番に取り出して処理し、結果を記録
- 確認: 画面は後から結果を取りに行く（I-10で見た再検証と同じ考え方）
処理の流れ——領収書100枚のOCR一括処理
具体例として、領収書を100枚まとめて文字起こしする処理を考えます。これをリクエストの中で同期的に実行すると、2分近く待たされたうえに、タイムアウトで失敗しかねません。キューに分離すれば、依頼は即座に受け付けられ、利用者にはH-07で学んだローディング表示の発展形として、進捗を見せられます。そして処理が終わったら、一覧画面へ結果を反映します。待たせずに、しかし確実に、処理を進められるのです。
このスライドのポイント
- 同期でやると: 2分近く待たされ、タイムアウトで失敗しかねない
- キューに分離すると: 依頼は即座に受け付け、進捗を見せられる（H-07のローディング表示の発展形）
- 処理が終わったら、一覧画面へ結果を反映する
技術サンプルカード——同期失敗 vs キュー分離
サンプルは、同期処理で失敗する流れと、キューで分離して成功する流れを並べた対比図です。読み方の要点は二つあります。一つ目は、処理にかかる想定時間が数秒を超えるなら、分離を検討するという線引きです。二つ目は、利用者には受付が済んだことと進捗を必ず見せるという点です。AIへの質問例はこうです。「この処理の想定時間は何秒ですか。リクエスト内で処理せず、キューに分離すべきではありませんか」。
このスライドのポイント
- 種別: diagram
- 目的: 同期処理で失敗する流れと、キューで分離して成功する流れを対比して確かめる
- サンプル本体:
混同しやすい概念——「失敗」と「まだ並んでいる」
混同しやすいのは、「処理が失敗した」状態と、「まだ行列に並んでいる」状態です。F-05で学んだ「まだ終わっていないだけ」という発想が、ここで再び効いてきます。キューを導入すると、処理の状態は増えます。待機中・実行中・成功・失敗の四つです。この区別を持たないと、まだ並んでいるだけのジョブを失敗と誤認してしまい、要らない作り直しを招きます。状態を4つに分けて扱うことが、混乱を防ぐ鍵です。
このスライドのポイント
- 「処理が失敗した」と「まだ行列に並んでいる」は別の状態
- F-05の「まだ終わっていないだけ」という発想が、ここで再び効く
- キュー導入後は状態が増える: 待機中・実行中・成功・失敗の4つ
バイブコーディングでの確認点
バイブコーディングでの確認点です。重い処理をAIに作らせたら、二つを必ず確認してください。一つは「タイムアウトまでに終わる保証はありますか」。もう一つは「失敗したジョブはどうなりますか」です。後者は、次回K-10で学ぶ再試行につながる重要な問いです。動くように見えても、重い処理が裏で静かに失敗している設計は珍しくありません。受付が返ってきたことと、処理が完了したことは別だと意識して確認しましょう。
このスライドのポイント
- 重い処理をAIに作らせたら、2つを必ず確認する
- (1)「タイムアウトまでに終わる保証はありますか」
- (2)「失敗したジョブはどうなりますか」（次回K-10の再試行につながる）
- 動くように見えても、重い処理が裏で静かに失敗している設計は珍しくない
まとめ——受付と実行を分ける
一問一答です。重い処理の受付で即座に返す応答は、何を意味するでしょうか。少し考えてみてください。答えは、「受け付けた」という意味です。実行はこれからで、HTTPでは202が典型でした。30秒まとめです。ジョブキューは受付と実行を分離し、重い処理で応答を待たせない仕組みでした。ワーカーが行列から順に処理し、状態は待機中から成功・失敗まで枝分かれします。次回はカテゴリK最終回、失敗に強い連携の三点セットを学びます。関連資料は「n8n自動化レシピ50」と「業務アプリDB設計パターン50」です。
このスライドのポイント
- 一問一答: 重い処理の受付で即座に返す応答は、何を意味するか
- 30秒まとめ: ジョブキューは受付と実行を分離し、重い処理で応答を待たせない仕組み
- 次回: カテゴリK最終回、失敗に強い連携の三点セット（K-10）
- 関連資料: 「n8n自動化レシピ50」「業務アプリDB設計パターン50」
