Webシステムを設計していると、
「この処理は非同期にした方がよいのか」
「普通にAPIの処理が終わるまで待てばよいのか」
と迷うことがあります。
結論からいうと、非同期処理は主に、
- 処理完了まで時間がかかる
- ユーザーが完了を待つ必要がない
- 大量データを処理する
- 外部サービスの応答に時間がかかる
- 一時的な失敗を再実行したい
といった処理で有効です。
具体的には、
- メール送信
- PDF・帳票生成
- 大量CSV出力
- ファイル変換
- 画像処理
- 外部API連携
- AIによる文章生成・解析
- 大量データの集計
- 通知配信
などが代表的な使いどころです。
一方、すべての処理を非同期にすればよいわけではありません。
非同期処理を導入すると、
- 処理状況の管理
- エラー処理
- 再実行
- 重複実行対策
- キュー管理
- ユーザーへの結果通知
など、新しい設計が必要になります。
そのため重要なのは、
「非同期処理を実装できるか」
ではなく、
「この処理を非同期にすることで、システム全体が本当に使いやすくなるか」
を判断することです。
この記事では、非同期処理の使いどころを、実際の業務システムを想定しながら具体的に解説します。
非同期処理とは
非同期処理とは、ある処理の完了を待たずに次の処理へ進める仕組みです。
例えば、ユーザーが管理画面から1万件のデータをCSV出力するとします。
同期処理の場合は、
CSV出力ボタンを押す
↓
サーバーで1万件を取得
↓
CSVを生成
↓
処理完了までユーザーが待つ
↓
ダウンロード
という流れになります。
処理に30秒かかるなら、ユーザーは30秒待たなければなりません。
非同期処理では、
CSV出力ボタンを押す
↓
「CSV作成を受け付けました」
↓
ユーザーは別の作業へ戻る
↓
バックグラウンドでCSV生成
↓
完了通知
↓
ダウンロード
という流れにできます。
時間のかかる処理をユーザー操作から切り離せることが、非同期処理の大きな特徴です。
同期処理と非同期処理の違い
違いを簡単に整理すると次のようになります。
| 項目 | 同期処理 | 非同期処理 |
|---|---|---|
| 処理完了 | その場で待つ | 後から完了 |
| 実装 | 比較的シンプル | 複雑になりやすい |
| エラー表示 | その場で表示しやすい | 別途管理が必要 |
| 長時間処理 | 不向き | 向いている |
| 大量処理 | 負荷に注意 | 分散しやすい |
| 再実行 | 個別実装 | キューなどで管理しやすい |
| ユーザー体験 | 短時間処理なら良好 | 長時間処理で有効 |
どちらが優れているというものではありません。
処理内容によって使い分けます。
非同期処理を使うべき5つの判断基準
「非同期にするべきか分からない」という場合は、次の5点を確認すると判断しやすくなります。
- 処理時間が長いか
- ユーザーが結果をその場で必要としているか
- 大量データを処理するか
- 外部サービスに依存しているか
- 失敗時に再実行したいか
順番に見ていきます。
1．処理時間が長いなら非同期処理を検討する
最も分かりやすい判断基準が処理時間です。
例えば、
顧客情報を1件登録
↓
0.2秒
程度なら、同期処理で問題ないでしょう。
一方、
1万件のデータを集計
↓
30秒
PDFを100ファイル生成
↓
2分
動画変換
↓
5分
といった処理を、ユーザーが画面上で待ち続ける設計は使いにくくなります。
またWebサーバーやロードバランサーなどにはタイムアウト設定があることもあり、処理が長すぎると途中で接続が切れる可能性もあります。
長時間処理は、Webリクエストから切り離してバックグラウンドで実行することを検討します。
2．その場で結果が必要かを確認する
処理時間だけでなく、
「結果をすぐ返す必要があるか」
も重要です。
例えばログイン処理では、
ログインボタン
↓
本人確認
↓
成功・失敗
↓
画面表示
という結果をその場で返さなければなりません。
これを、
「ログイン処理を受け付けました。後で確認してください」
としても使い物になりません。
一方、メール送信なら、
会員登録
↓
登録完了
↓
メール送信
という処理があります。
ユーザーにとって重要なのは、まず会員登録が正常に完了したことです。
メール送信そのものが数秒後でも問題ないのであれば、
会員登録
↓
完了
↓
メール送信をキューへ登録
↓
画面へ成功レスポンス
↓
バックグラウンドでメール送信
と分けることができます。
3．大量データを扱う場合は非同期処理と相性がよい
大量データ処理も非同期処理の代表的な使いどころです。
例えば、
- 10万件のCSV取込
- 1万件の帳票出力
- 顧客全員へのメール送信
- 大量画像の変換
- 売上データの再集計
などです。
これらをWebリクエスト内ですべて処理すると、リクエストが長時間占有されます。
非同期処理なら、
処理依頼
↓
ジョブ登録
↓
1000件ずつ処理
↓
進捗更新
↓
完了
といった構成にできます。
4．外部APIを使う処理では非同期化を検討する
外部APIは、自社システムだけでは処理時間を完全に制御できません。
例えば、
自社システム
↓
AI API
↓
回答待ち
という処理では、AI側の応答に数秒から数十秒かかることがあります。
さらに、
- API障害
- レート制限
- ネットワークエラー
- タイムアウト
などが発生する可能性もあります。
そのため、ユーザーがその場で回答を必要としない処理であれば、非同期化を検討できます。
例えば、
契約書100件をAIで分類
↓
処理を受け付ける
↓
バックグラウンドで順次AI解析
↓
完了後に結果一覧を表示
という構成です。
5．再実行したい処理は非同期化と相性がよい
外部サービスでは一時的なエラーが起こることがあります。
例えば、
メール送信
↓
メールサービスが一時的に応答しない
というケースです。
同期処理だけで実装すると、その場でエラーを返して終了することになります。
ジョブキューを利用すれば、
メール送信
↓
失敗
↓
1分後に再実行
↓
失敗
↓
5分後に再実行
のようなリトライ処理を実装しやすくなります。
業務システムにおける非同期処理の具体的な使いどころ
ここからは、実際の業務システムで非同期処理が使われる場面を見ていきます。
1．メール送信
メール送信は、非同期処理と相性がよい代表例です。
例えば問い合わせフォームなら、
問い合わせ登録
↓
データベース保存
↓
受付完了
↓
メール送信
という処理があります。
メールサービスの応答を待ってから画面を返す必要がないのであれば、
問い合わせ登録
↓
メール送信ジョブ作成
↓
画面へ成功レスポンス
↓
バックグラウンドでメール送信
とできます。
これにより、外部メールサービスが多少遅くても、問い合わせ登録画面のレスポンスへの影響を減らせます。
2．PDF・帳票生成
請求書、見積書、契約書などのPDF生成も非同期処理の候補です。
1ファイルだけなら同期処理でも問題ない場合があります。
しかし、
請求書500件を一括出力
となると話が変わります。
例えば、
一括出力ボタン
↓
帳票生成ジョブ
↓
500件のPDF生成
↓
ZIP圧縮
↓
完了通知
↓
ダウンロード
という構成にできます。
大量帳票を扱う業務システムでは有効です。
3．大量CSV出力
数十件・数百件のCSVなら、その場で生成できることもあります。
一方、
数十万件の取引履歴
などをCSV出力すると、データベース取得やファイル生成に時間がかかります。
その場合、
CSV作成依頼
↓
バックグラウンド処理
↓
ファイルストレージへ保存
↓
完了通知
↓
一定期間だけダウンロード可能
という設計が考えられます。
4．CSVインポート
CSV取込も大量データでは非同期化しやすい処理です。
例えば顧客1万件を登録するとします。
ファイルアップロード
↓
処理受付
↓
バックグラウンドで検証
↓
登録
↓
結果作成
とします。
結果画面では、
処理件数：10,000件
成功：9,950件
エラー：50件
のように表示できます。
エラー行だけCSVで出力できるようにすると、利用者が修正しやすくなります。
5．画像・動画処理
例えば商品管理システムで画像をアップロードした後、
- リサイズ
- サムネイル生成
- 圧縮
- AI画像解析
などを行う場合があります。
画像アップロード
↓
保存完了
↓
バックグラウンド処理
↓
サムネイル生成
という構成にすれば、利用者を長く待たせる必要がありません。
動画変換など処理時間が長いものでは、さらに非同期処理が重要になります。
6．AIを使った処理
生成AIやAI解析も、非同期処理と相性のよい分野です。
例えば、
- 議事録要約
- 書類分類
- OCR後のデータ整理
- 顧客問い合わせ分類
- 商品説明生成
- 大量文書のEmbedding作成
などです。
例えば1,000件の問い合わせをAIで分類する場合、
ボタン
↓
1,000回APIを順番に呼び出す
↓
終了まで画面で待つ
という設計は現実的ではありません。
代わりに、
AI分類開始
↓
ジョブ作成
↓
バックグラウンド処理
↓
進捗表示
↓
完了通知
という構成にできます。
7．外部システムへのデータ連携
業務システムでは、
受注
↓
会計システムへ連携
顧客登録
↓
CRMへ連携
商品更新
↓
ECへ連携
などの処理があります。
外部システムが一時停止していた場合でも、社内システム側の業務まで止める必要がないケースがあります。
例えば、
受注登録
↓
自社DBへ保存
↓
連携ジョブ作成
↓
受注登録は完了
↓
会計システムへ非同期連携
という構成です。
外部APIが失敗した場合は後から再実行します。
8．通知処理
大量通知も非同期処理に向いています。
例えば、
イベント参加者5,000人へ通知
を一つのWebリクエストで処理する必要はありません。
ジョブとして登録し、一定件数ずつ送信します。
これにより、外部サービスのレート制限にも対応しやすくなります。
9．集計・ダッシュボード更新
大量データからKPIを計算するダッシュボードでは、毎回画面表示時にすべて計算すると遅くなる場合があります。
例えば夜間に、
前日のデータ
↓
集計処理
↓
集計テーブルへ保存
としておけば、ダッシュボード表示時は集計済みデータを取得するだけで済みます。
これも広い意味ではバックグラウンド処理の活用例です。
非同期処理にしない方がよい処理
非同期処理にはメリットがありますが、何でも非同期にする必要はありません。
ログイン
ログイン結果はその場で必要です。
基本的には同期処理が適しています。
1件の登録・更新
例えば顧客名を変更するとき、
保存
↓
「変更処理を受け付けました」
↓
後から更新
としてしまうと、利用者は本当に更新されたか分かりにくくなります。
短時間で完了する一般的なCRUD処理は同期処理の方が分かりやすいことが多いでしょう。
在庫確保など即時確定が必要な処理
例えば、
在庫1個
↓
ユーザーAが注文
↓
ユーザーBも注文
という競合が起こる処理では、在庫確保の結果を正確に判断する必要があります。
「あとで処理します」とするだけでは、二重販売につながる可能性があります。
このような処理ではトランザクションや排他制御など、データ整合性を優先した設計が必要です。
決済結果が必要な処理
注文確定時に、
「決済に成功したか」
が必要なのであれば、重要部分は同期処理として確認する必要があります。
ただし、
決済成功
↓
領収書メール送信
↓
ポイント付与通知
など、その後の処理は非同期化できる場合があります。
「同期か非同期か」ではなく処理を分割して考える
実務では、処理全体を同期か非同期のどちらか一方にする必要はありません。
例えば会員登録なら、
同期処理
- 入力値検証
- ユーザー登録
- 重複チェック
- 登録結果返却
非同期処理
- ウェルカムメール
- CRM連携
- 分析サービス連携
というように分けられます。
例えば受注処理なら、
同期
受注データ保存
非同期
- メール通知
- PDF生成
- CRM連携
- 会計システム連携
という設計も可能です。
「ユーザーへ結果を返すために本当に必要な処理はどこまでか」
を考えることがポイントです。
非同期処理ではジョブキューを利用する
業務システムで非同期処理を実装するときによく使われるのがジョブキューです。
基本的な構成は、
Webアプリ
↓
ジョブをキューへ登録
↓
ワーカー
↓
処理実行
↓
完了
です。
Webアプリは重い処理を直接実行せず、
「この仕事を後で実行してください」
という情報だけをキューへ登録します。
ワーカーと呼ばれる処理担当が、キューから順番にジョブを取得して実行します。
非同期処理ではステータス管理が重要
非同期処理では、ユーザーへすぐ結果を返せないため、
「現在どの状態なのか」
を管理する必要があります。
例えばCSV出力なら、
- WAITING：待機中
- PROCESSING：処理中
- COMPLETED：完了
- FAILED：失敗
などです。
画面上では、
CSV作成中…
↓
完了
↓
ダウンロード
という状態を表示できます。
進捗率を表示するかどうかも検討する
長時間処理では、
「処理中」
だけでは利用者が不安になることがあります。
例えば1万件のデータ処理なら、
2,500 / 10,000件
25％完了
のように進捗を表示する方法があります。
ただし、正確な進捗率を計算すること自体が難しい処理もあります。
その場合は無理にパーセンテージを出さず、
- 待機中
- 処理中
- 完了
だけでも十分な場合があります。
非同期処理では失敗する前提で設計する
同期処理ではエラーをそのまま画面へ返せます。
一方、非同期処理ではユーザーがすでに別画面へ移動している可能性があります。
そのため、
処理失敗
↓
ステータスをFAILED
↓
エラー内容を記録
↓
必要なら再実行
↓
利用者・管理者へ通知
という設計が必要です。
リトライできる処理とできない処理を分ける
非同期処理では、自動再実行が便利です。
しかし、すべての処理を単純に再実行できるわけではありません。
例えばメール送信で、
1回目
↓
メールは送れた
↓
成功レスポンスを受け取る前に通信切断
↓
失敗判定
↓
再実行
とすると、同じメールが2通送信される可能性があります。
そのため、
「同じ処理を複数回実行しても問題ないか」
を考える必要があります。
この性質を「冪等性（べきとうせい）」と呼びます。
非同期処理では冪等性が重要
例えば注文番号12345の請求書を生成する処理なら、
job_id
order_id
status
などを管理して、
「すでに処理済みならもう一度実行しない」
という設計ができます。
外部APIへデータ登録する場合も、
同じデータを2回送信
↓
二重登録
にならないよう注意が必要です。
非同期処理とバッチ処理の違い
非同期処理と一緒に出てくる言葉がバッチ処理です。
非同期処理は、
「処理完了を待たずに別の処理へ進む」
という実行方法です。
一方、バッチ処理は、
「複数の処理やデータをまとめて実行する」
という考え方です。
例えば、
毎日午前2時
↓
前日の売上を集計
はバッチ処理です。
ユーザーが、
CSV出力ボタン
↓
バックグラウンドでCSV生成
するのは非同期処理です。
両方を組み合わせる場合もあります。
非同期処理を使うデメリット
非同期処理は便利ですが、同期処理より設計が複雑になります。
システム構成が増える
例えば、
- キュー
- ワーカー
- ジョブ管理
- 監視
などが必要になる場合があります。
単純なWebアプリなら、
Web
↓
DB
だけだった構成が、
Web
↓
Queue
↓
Worker
↓
DB
になることがあります。
エラー原因を追いにくくなる
HTTPリクエストと実際の処理が分離されるため、
「ユーザーが操作した時点」
と、
「エラーが起きた時点」
が異なります。
そのため、
- ジョブID
- ユーザーID
- 実行日時
- エラー内容
などをログへ残して追跡できるようにすることが重要です。
運用監視が必要になる
ワーカーが停止していると、
ジョブ登録
↓
キューに溜まる
↓
いつまでも処理されない
という状態になります。
そのため、
- キュー滞留数
- エラー数
- 処理時間
- ワーカー稼働状況
などを確認できるようにする必要があります。
非同期処理を採用する判断フロー
迷った場合は、次のように判断すると整理しやすくなります。
処理は数秒以内で終わるか？
YES
↓
同期処理を基本に検討
NO
↓
次へ
ユーザーは結果をその場で必要としているか？
YES
↓
処理高速化を優先して検討
NO
↓
非同期処理を検討
大量データ・外部API処理か？
YES
↓
非同期処理との相性がよい
一時的な失敗を再実行したいか？
YES
↓
ジョブキューを検討
という流れです。
【コピペ用】非同期処理の設計チェックリスト
システム開発で非同期処理を検討するときは、次の項目を整理してみてください。
処理内容
- 対象処理：
- 1回の処理時間：
- 最大処理時間：
- 処理件数：
- 外部API利用有無：
ユーザー要件
- 結果をその場で必要とする：
- 後から完了でも問題ない：
- 完了通知が必要：
- 進捗表示が必要：
ジョブ管理
- 待機中：
- 処理中：
- 完了：
- 失敗：
- キャンセル：
エラー
- 自動リトライ：
- 最大リトライ回数：
- 管理者通知：
- ユーザー通知：
- 手動再実行：
重複実行
- 同じジョブを複数回実行して問題ないか：
- 二重登録防止：
- 二重メール防止：
- 処理済み判定：
運用
- キュー監視：
- エラーログ：
- 処理時間監視：
- ジョブ履歴：
- 異常時の対応方法：
非同期処理でよくある失敗
何でも非同期にする
短時間で終わる単純な登録処理まで非同期にすると、利用者にとって結果が分かりにくくなります。
必要な処理だけに利用します。
処理状況が分からない
ボタンを押した後、
「受付しました」
だけで終わり、完了したのか分からないシステムがあります。
ジョブ履歴や通知などを検討します。
失敗したジョブが放置される
非同期処理では、失敗してもユーザーが気付かない可能性があります。
FAILED状態、通知、監視などを設計します。
無限にリトライする
外部APIが恒久的に失敗しているのに再実行を続けると、キューや外部APIへ負荷をかけます。
リトライ回数や間隔を決めます。
二重処理が発生する
リトライによって、
- メールが2通届く
- 注文が2件登録される
- 請求が重複する
といった問題が発生することがあります。
冪等性を意識した設計が重要です。
キューが詰まったときの運用を決めていない
通常は1分で終わるジョブでも、急に1万件登録されれば処理待ちが発生します。
ピーク時の件数も考慮します。
非同期処理に関するよくある質問
非同期処理は何秒以上なら使うべきですか？
一律の秒数で決めるものではありません。
処理時間だけでなく、ユーザーが結果をその場で必要としているか、タイムアウトの可能性、大量処理かどうかなどを含めて判断します。
数十秒以上かかる処理では、特に非同期化を検討する価値があります。
メール送信は非同期にした方がよいですか？
ユーザーがメール送信結果をその場で待つ必要がなければ、非同期処理と相性がよい処理です。
メールサービスの一時的な障害に対してリトライしやすくなるメリットもあります。
PDF出力は非同期処理にするべきですか？
1枚だけを短時間で生成できるなら同期処理でも問題ない場合があります。
数百枚の帳票を一括生成するなど、処理時間が長くなる場合は非同期処理を検討するとよいでしょう。
AI APIは非同期にした方がよいですか？
用途によります。
チャットのようにユーザーが回答をその場で待っているなら、同期的に結果を返す必要があります。
一方、大量文書の分類・要約・Embedding生成などは非同期処理に向いています。
バッチ処理と非同期処理は同じですか？
同じではありません。
バッチ処理は複数データや処理をまとめて実行する考え方で、非同期処理は処理完了を待たずに次へ進む実行方法です。
バッチをバックグラウンドで非同期実行することもあります。
非同期処理には必ずメッセージキューが必要ですか？
必ずではありません。
システム規模や技術構成によっては、クラウドサービスのバックグラウンドジョブやタスク実行機能などを利用する方法もあります。
ただし、再実行、負荷分散、ジョブ状態管理などが必要になると、キューを利用するメリットが大きくなります。
非同期処理はユーザー体験だけでなく障害分離にも役立つ
非同期処理のメリットは、
「画面を速くすること」
だけではありません。
例えば、
注文登録
↓
メールAPI障害
↓
注文自体も失敗
という構成では、メールサービスの障害によって自社の主要業務まで止まってしまいます。
一方、
注文登録
↓
DB保存
↓
注文完了
↓
メールは非同期処理
とすれば、メール送信に問題があっても注文自体は継続できます。
このように外部サービスや補助処理を分離することで、システム全体の障害影響範囲を小さくできる場合があります。
hiro-dev-labでは非同期処理を含む業務システム設計から相談できます
非同期処理は、単純にバックグラウンドでプログラムを動かせば終わりではありません。
例えば大量帳票出力なら、
帳票作成依頼
↓
ジョブ登録
↓
処理中
↓
PDF生成
↓
ファイル保存
↓
完了通知
↓
ダウンロード
まで含めて設計する必要があります。
さらに、
- 途中で失敗したらどうするか
- 再実行できるか
- 二重生成をどう防ぐか
- 処理中にユーザーがもう一度ボタンを押したらどうするか
- 大量ジョブが発生したらどうするか
まで考えることが重要です。
hiro-dev-labでは、
- 業務ヒアリング
- 要求整理
- 要件定義
- Webシステム設計
- API設計
- 非同期処理設計
- バッチ処理設計
- 外部API連携
- AI API連携
- 帳票・CSV処理
- 業務自動化
- Webシステム開発
などから相談できます。
「帳票出力に時間がかかって画面が固まる」
「大量CSVを扱いたい」
「外部APIの障害でシステム全体が止まる」
「AI処理を業務システムへ組み込みたい」
という場合は、処理全体を非同期にするのではなく、どの部分をWebリクエストから切り離すべきか整理することが重要です。
まとめ
非同期処理の主な使いどころは、
- メール送信
- 大量CSV入出力
- PDF・帳票生成
- 画像・動画処理
- AI処理
- 外部API連携
- 大量通知
- 大規模集計
などです。
判断するときは、
- 処理時間が長いか
- ユーザーがその場で結果を必要とするか
- 大量データを扱うか
- 外部サービスに依存するか
- 再実行したい処理か
を確認します。
一方、
- ログイン
- 通常のデータ登録
- 即時確定が必要な処理
などでは同期処理の方が適していることがあります。
重要なのは、同期処理と非同期処理のどちらか一方に統一することではありません。
例えば、
受注登録
↓
同期処理
メール送信
↓
非同期処理
帳票生成
↓
非同期処理
会計システム連携
↓
非同期処理
というように、業務上必要な部分だけを分離することができます。
非同期処理は、処理速度を改善するだけでなく、外部サービスの障害を分離し、大量処理を安定して実行するための重要な設計手段です。
ただし、導入するとジョブ状態、再実行、冪等性、監視などの設計も必要になります。
「時間がかかるから非同期にする」だけではなく、ユーザー体験とシステム運用の両方を見ながら使いどころを判断することが重要です。