LASSIC Media らしくメディア
非同期とは？結果を待たずに次へ進む処理と同期との違い
監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）
この記事の結論
- 同期処理は結果が返るまで待つ方式、非同期処理は待たずに次へ進み、後から結果を受け取る方式です。
- 非同期処理は応答性や処理量を高めやすい反面、整合性の確認やエラー処理が複雑になり、常に速くなるとは限りません。
- 決済の確定のようにその場の確認が要る処理は同期、通知やメール送信は非同期と、処理の性質で使い分けます。
※ 本記事は2026年9月時点の公式情報（省庁・公的機関、および製品やサービスを提供する事業者が公開している資料）に基づきます。
ボタンを押すたびに画面が止まり、応答が返るまで待たされる。処理を非同期に切り替えたら、今度は処理が失敗しても誰も気づかない——。システムの処理方式を決める場面では、こうした悩みが出てきがちです。同期処理とは、頼んだ処理の結果が返るまで待ってから次へ進む方式で、非同期処理とは、結果を待たずに次へ進み、後から結果を受け取る方式です。
どちらも処理の進め方を決める設計上の選択肢で、処理の性質に合わせて選べば、利用者を待たせる時間を減らしたり、処理の成否をその場で確かめたりできます。ただし万能な方式はなく、非同期にすれば速くなるというものでもありません。本記事では、システム開発の発注担当者・PM（プロジェクトの責任者）・設計者に向けて、二つの方式の仕組みと違い、長所と短所、使い分けの判断軸、そして開発を委託するときに確認したい点を整理します。
目次
同期処理とは
同期処理では、処理を頼む側（呼び出し元）と引き受ける側（呼び出し先）の処理が、一つの流れとして順番に実行されます。プログラムの中で関数やAPI（他のプログラムを呼び出す仕組み）を呼び出す場面を思い浮かべると分かりやすいでしょう。呼び出し元は、呼び出し先の処理が終わるまでその場で待ち、ほかの処理を並行して進めることはありません。結果を受け取ってはじめて、次の処理へ進みます。
この「待つ」という前提があるため、処理の順序や結果の受け渡しを単純に管理でき、プログラムの流れを追いやすいのが特徴です。利用者がボタンを押してから応答が返るまで画面が先へ進まない処理や、データベースに問い合わせて、結果が返るまで次の画面を表示しない処理は、同期処理の典型例です。結果がすぐに必要で、その結果を確かめてから次に進む場面で多く使われています。
非同期処理とは
非同期処理では、呼び出し元は処理を依頼したら、完了を待たずに次の処理へ進みます。呼び出された処理は裏側（バックグラウンド）で進み、終わった時点で呼び出し先から呼び出し元へ結果が通知されるか、呼び出し元が後から結果を取りに行きます。呼び出し元の処理が止まらない点が、同期処理との大きな違いです。
呼び出し元と呼び出し先が並行して進むため、呼び出し元は待たずに次の作業へ進めます。その代わり、結果をいつ、どのように受け取るかを前もって設計しておく必要があります。通知の仕組みやエラーが起きたときの扱いを決めておかないと、処理が終わったのかどうかを把握しにくくなります。会員登録の後に送る確認メール、大きなファイルのアップロード完了の通知、まとめて実行する集計処理などが、非同期処理がよく使われる例です。利用者やシステムが結果をその場で必要としない処理と相性がよい方式です。
同期処理と非同期処理の違い
どちらも処理を実行する点は同じですが、結果を待つかどうかで、処理の流れや成否の確かめ方、デバッグ（不具合の原因を探して直す作業）のしやすさに違いが出ます。主な観点を次の表にまとめました。
| 観点 | 同期処理 | 非同期処理 |
|---|---|---|
| 処理の流れ | 結果が返るまで呼び出し元が待つ | 結果を待たず次の処理へ進む |
| 応答の速さ | 利用者は結果が出るまで待たされる | 待たされる感覚を減らしやすい |
| 処理できる件数（スループット） | 処理中はほかの要求を受け付けにくい | 多くの要求を並行して受け付けやすい |
| 整合性の確認 | その場で成否を確かめやすい | 結果が後から届くため、成否を確かめる仕組みが別に要る |
| エラー処理 | 呼び出し元にその場で返しやすい | 通知や再試行の仕組みを別に用意する |
| 実装・デバッグ | 流れが順番どおりで追いやすい | 完了の順番が前後し、追跡が難しくなりやすい |
| よく使われる用途 | 決済の確定、在庫の引き当て（注文分の在庫の確保）など | 通知・メール送信、集計・バッチ処理など |
表のとおり、どちらかが優れているというものではなく、結果を待つか待たないかという、設計の選び方の違いです。次の図で、それぞれの処理の流れを確認しておきましょう。
メリットとデメリット
方式を選ぶときは、応答の速さ、処理できる件数、整合性、実装とデバッグの手間という4つの観点で比べると判断しやすくなります。
応答の速さ
非同期処理では呼び出し元が結果を待たずに次へ進むため、利用者から見た応答は速く感じられやすくなります。ただし、非同期にしても処理そのものの実行時間が短くなるわけではありません。主な効果は、待たされていると感じる時間を減らせることです。
処理できる件数
非同期処理は、一つの処理が終わるのを待たずに次々と要求を受け付けられるため、単位時間あたりに処理できる件数を高めやすい方式です。同期処理では、呼び出し元が1件の処理を終えるまで次の要求を受け付けにくく、同時に多くの要求をさばく場面では、全体の処理を遅らせる原因になりやすくなります。
整合性
同期処理では、呼び出し元が結果を確かめてから次へ進むので、処理の成否をその場で把握でき、整合性（データに食い違いがない状態）を保ちやすくなります。非同期処理では結果が返る時点が呼び出し元の処理とずれるため、途中の状態でデータの食い違いが生じないよう、整合性を保つための設計が別に必要です。決済や在庫の確定のように、結果を確かめてから次の手続きへ進みたい場面では、同期処理が向いています。
実装とデバッグの手間
同期処理は処理が順番に流れるので追いやすく、動作確認やデバッグの負担は比較的軽く済みます。非同期処理は、処理が終わるタイミングが呼び出し元の処理の進み方と連動しないため、いつ、どの順番で結果が返るかを意識した設計が要ります。障害が起きたときに、どの処理でエラーが出たのかを突き止めるのも難しくなりがちです。非同期処理を採り入れるときは、完了状況やエラーを誰がどう確かめるかといった運用の体制も、あわせて決めておきます。
非同期処理を実現する仕組み
非同期処理を実現する仕組みはいくつかあり、扱う処理の性質によって向き不向きがあります。ここでは代表的な3つを紹介します。
コールバック
コールバックは、処理が終わったときに、あらかじめ指定しておいた別の処理（コールバック関数）を呼び出す仕組みです。比較的簡単に非同期処理を組み込めます。一方で、コールバック関数の中でさらに別のコールバック関数を指定する形が重なると、処理の流れを読み解きにくくなることがあります。複雑な非同期処理を多く扱うシステムでは、読みやすさに気を配る必要があります。
メッセージキュー
メッセージキューは、処理の依頼内容を「メッセージ」としてキュー（待ち行列）に登録し、別の処理（ワーカー）がキューから順に取り出して処理する仕組みです。依頼が処理より速く届いてもキューにためておけるので、依頼が一時的に集中しても取りこぼしを抑えやすいのが特徴です。その反面、処理の実行順序を保証するか、失敗したときにどう再試行するかなど、設計で決めることも多くなります。
ジョブ・バッチ処理
ジョブ・バッチ処理は、依頼を1件ずつその都度処理するのではなく、一定量たまった処理や、決まった時刻の処理をまとめて実行する仕組みです。夜間バッチのように、すぐに結果が要らず、まとめて処理したほうが効率のよい業務と相性がよい方法です。処理件数が多くても、実行する時間帯をずらしてシステム全体の負荷を分散できます。
どう使い分けるのか
同期処理と非同期処理のどちらが合うかは、次の5つの点を確かめると整理しやすくなります。
- 結果の即時性：処理の結果をその場で確かめ、次の判断に使う必要があるか
- 処理の重さと時間：処理に時間がかかり、呼び出し元を待たせたくないか
- 整合性の要件：処理の成否をその場で保証する必要がある業務か
- 失敗したときの扱い：すぐに利用者へ伝える必要があるか、後から再試行できればよいか
- 運用の体制：非同期処理の完了状況やエラーを監視し、追跡できる体制があるか
これらを踏まえると、処理の性質ごとに、おおよその傾向が見えてきます。
- 決済の確定：結果を確かめてから次の手続きに進むため、同期処理が向く場面が多い
- 在庫の引き当てなど整合性が重要な処理：その場の確認が要るなら同期処理が合いやすい
- 会員登録後の確認メールや通知の送信：利用者が結果をその場で必要としないため、非同期処理が向く
- 大量データの集計やレポートの作成：処理に時間がかかるため、非同期処理やバッチ処理が扱いやすい
- 画像・動画のアップロード後の変換：受付は同期で行い、変換そのものは非同期で進める構成が一般的
ここに挙げたのは一般的な傾向です。実際の判断は、業務の要件や利用者の使い勝手、既存システムの構成を踏まえて、処理ごとに検討します。
開発を委託するときに確認しておきたい点
非同期処理を含むシステムの設計や開発を委託するときは、次の点を前もって確かめておくと、後になってからのやり直しを減らせます。
- どの処理を同期・非同期のどちらで作るかが、業務の要件に沿って整理されているか
- 非同期処理が失敗したときの再試行と通知の仕組みが、設計に含まれているか
- 処理の完了状況を、利用者や運用担当者が確かめる手段が用意されているか
- 非同期処理の遅れや、処理待ちの依頼がたまっていないかを監視する仕組みが、運用設計に含まれているか
- 非同期にすることで増える実装とテストの工数が、見積もりに反映されているか
非同期処理は、採り入れれば使い勝手が良くなるとは限らず、設計と運用の両方で検討が要る仕組みです。こうした確認点を発注の段階で開発会社と共有しておくと、期待していた動きとのずれを防ぎやすくなります。
まとめ：同期と非同期で確かめておきたい3つの点
同期処理と非同期処理を使い分けるうえで、確かめておきたい点は3つに整理できます。第一に、処理の結果をその場で確かめて次の判断に使う必要があるかどうかを見ること。第二に、非同期にする処理について、失敗したときの再試行と通知、完了状況の確認と監視の仕組みを設計に含めること。第三に、非同期にすることで増える実装とテストの工数を、見積もりと運用の体制に反映させることです。この3点を踏まえておけば、「非同期にしたのに速くならず、失敗にも気づけなかった」という事態を避けやすくなります。処理方式の整理に迷いがあれば、外部の手を借りるのも一つの選択肢です。
よくある質問
非同期にすれば、処理は速くなりますか
処理そのものの実行時間が短くなるとは限りません。非同期処理で減らせるのは、呼び出し元が結果を待つ時間です。結果を待たずに次へ進めるので応答が速く感じられることはありますが、常に速くなるとは言い切れません。
非同期処理のデバッグは難しいのですか
難しくなりやすいのは事実です。処理が終わるタイミングが呼び出し元の処理の進み方と連動しないため、どの処理でエラーが起きたのかを追いにくくなります。ログを整えることや、処理の状況を追跡する仕組みを前もって設計に組み込んでおくことで、この負担はある程度軽くできます。
同期処理と非同期処理は、一つのシステムで併用できますか
併用できます。実務では、受付は同期で行ってその場で確認し、時間のかかる部分だけを非同期で進める組み合わせがよく見られます。システム全体をどちらか一方にそろえるのではなく、工程ごとに合う方式を選ぶのが現実的です。
非同期処理に使う製品や実装方法は、どう選べばよいですか
コールバック、メッセージキュー、ジョブ・バッチ処理のどれを使うかは、処理の即時性、再試行が要るかどうか、処理量をもとに考えます。特定の製品や実装方法は、扱うシステムの要件に沿って個別に検討します。
システム開発・設計のご相談はLASSICへ
元請（プライムベンダー）として、処理方式の整理から、基盤の構築を含むシステム開発までご提案します。
Remoguとリラシクなら、非同期処理の設計や運用に加わる開発エンジニアを、業務委託でも社員の採用でも探せます。
Remoguは、リモート前提で全国から即戦力のITプロ人材を調達するサービスです。リラシクは、扱う求人がすべてリモートワークのITエンジニア専門転職エージェントです。どちらもLASSICが運営しています。
出典
- *1 参考：IPA（独立行政法人情報処理推進機構）「情報処理技術者試験」（https://www.ipa.go.jp/shiken/）。出典：IPA（独立行政法人情報処理推進機構）「情報処理技術者試験」シラバスにおける同期・非同期処理関連の情報（2026年9月確認）
