前回の続き——構成の内側で、処理をどう動かすか
前回のN-07では、アプリ全体を1つにまとめるモノリスと、機能ごとに分けるマイクロサービスの選択を学びました。今回は、その構成の内側で、個々の処理をどう動かすかの判断です。同期と非同期という言葉は、F-04で仕組みを、K-09では重い処理を切り離す道具として学びました。この講義はそれを設計の判断軸へと昇華させ、実装をAIに頼む前に人間が決めておく基準にします。
このスライドのポイント
- N-07: アプリ全体を1つにまとめるモノリスか、機能ごとに分けるマイクロサービスかの構成選択を学んだ
- 今回: その内側で、個々の処理を同期で動かすか非同期で動かすかの判断
- 同期・非同期はF-04で仕組み、K-09で重い処理を切り離す道具として既習
- この講義の役割: それを「実装前に人間が決める設計の判断軸」へ昇華させる
判断基準は、たった1問
同期処理と非同期処理の違いは、F-04で仕組みとして、K-09では重い処理を切り離す道具として学びました。設計の場面で使う判断基準は、実はたった1問です。「利用者は、この処理の結果を見てからでないと次へ進めないか」。答えがYesなら同期にします。利用者を待たせて結果を返す方式で、ただし待ち時間は数秒までが目安です。答えがNoなら非同期にします。受付だけをすぐ返し、実際の処理は裏側で進め、進捗はH-07で学んだ状態表示で見せます。
このスライドのポイント
- 同期・非同期の違い: F-04で仕組みとして、K-09で重い処理を切り離す道具として既習
- 設計で使う判断基準はただ1問:「利用者は、この処理の結果を見てからでないと次へ進めないか」
- Yes → 同期（待たせて結果を返す。ただし待ち時間は数秒まで）
- No → 非同期（受付だけすぐ返し、処理は裏側=K-09で進める。進捗はH-07の状態表示で見せる）
なぜ必要か——判断を両極端に振らせないため
この1問を持たないと、判断が両極端に振れます。片方は、何でも同期にしてしまう失敗です。重い処理を利用者に待たせ続け、K-09で見たタイムアウトの事故を招きます。もう片方は、何でも非同期にする失敗です。保存できたかどうか分からないまま画面が次へ進み、利用者を不安にさせます。これはH-08で学んだ、操作の結果を必ず伝えるという原則に反します。基準が1つあるだけで、この両極端を避けられます。
このスライドのポイント
- この1問を持たないと、判断が両極端に振れる
- 何でも同期にする失敗: 重い処理を待たせ続け、K-09で見たタイムアウトの事故を招く
- 何でも非同期にする失敗: 保存できたか分からないまま画面が進み、利用者を不安にさせる（H-08違反）
- 基準が1つあるだけで、両極端を避けられる
構造——1本の判断フロー
判断は1本のフローで表せます。出発点は「この処理の結果は、次の操作にすぐ必要か」です。必要ならば同期の枝へ進みます。ただし最悪でも3秒を超えるなら、設計そのものを見直す合図です。必要でなければ非同期の枝へ進みます。この枝では3つをセットで設計します。受付をすぐ返す応答、処理中を示す進捗表示、終わったことを知らせる完了通知です。フロー図にすると、迷ったときに立ち返れる1枚の判断地図になります。
このスライドのポイント
- 出発点:「この処理の結果は、次の操作にすぐ必要か」
- 必要 → 同期の枝。ただし最悪で3秒を超えるなら設計を見直す合図
- 必要でない → 非同期の枝。3つをセットで設計する
経費精算アプリでの仕分け
経費精算アプリで仕分けてみます。申請の保存は同期です。保存できたと確認できてから次の画面へ進みたいからです。一方、領収書を100枚まとめて読み取るOCR処理は非同期にします。これはK-09で切り離した重い処理そのものです。月次レポートの生成も非同期にし、完了したら通知で知らせます。H-08の原則どおり、裏で進む処理ほど「終わりました」の一言を欠かさないことが、安心して使えるアプリの分かれ目になります。
このスライドのポイント
- 申請の保存 = 同期（保存できたと確認してから次の画面へ進みたい）
- 領収書100枚のOCR読み取り = 非同期（K-09で切り離した重い処理そのもの）
- 月次レポートの生成 = 非同期＋完了通知（H-08）
- 裏で進む処理ほど「終わりました」の一言を欠かさないことが、安心して使えるアプリの分かれ目
技術サンプル——処理の仕分け表
スライドの表は、経費精算アプリの処理を先ほどの1問で仕分けたものです。読み方のポイントは2つあります。1つ目は、判断の列がすべて同じ問い、結果を見てから次へ進むか、で埋まっている点です。処理ごとに別の理由を持ち出さず、1つの基準で通します。2つ目は、非同期にした行には必ず進捗と完了の見せ方が添えられている点です。裏で動かすなら、その見せ方までが設計の一部になります。
混同しやすい——技術の非同期 と 設計の非同期
混同しやすいのは、技術としての非同期と、設計としての非同期です。技術としての非同期は、F-04で学んだコードの書き方で、処理を待たずに次へ進める仕組みそのものです。これはほぼすべてのアプリの内部で使われています。一方、設計としての非同期は、利用者を待たせない構造をあえて選ぶという判断の結果です。前者は道具、後者は判断です。この講義で仕分けているのは後者であって、コードの書き方の話ではありません。
バイブコーディングでの確認点
AIに実装を頼むときの確認点です。処理ごとに、これは最悪で何秒かかりますか、を必ず聞いてください。答えが3秒を超える同期処理があれば、非同期にできないかを検討させます。この確認は、M-06で決めた非機能要件の応答時間の数値と突き合わせると効きます。AIへの質問例です。このアプリの処理一覧を同期と非同期で仕分けし、非同期にしたものについては進捗と完了の見せ方も提案してください。
このスライドのポイント
- 処理ごとに「これは最悪で何秒かかりますか」をAIに必ず聞く
- 3秒を超える同期処理があれば、非同期にできないか検討させる
- M-06で決めた非機能要件の応答時間の数値と突き合わせると効く
- AIへの質問例:「このアプリの処理一覧を同期/非同期で仕分けし、非同期にしたものについては進捗と完了の見せ方も提案してください」
一問一答とまとめ
一問一答です。同期か非同期かを分ける、たった1つの問いは何でしょうか。（間）答えは、利用者は、この処理の結果を見てからでないと次へ進めないか、です。Yesなら同期、Noなら非同期です。30秒まとめです。仕組みはF-04とK-09で学びました。設計では1問で仕分け、非同期には進捗と完了の見せ方を必ず添える。これを持ち帰ってください。次回のN-09は、可用性・拡張性・保守性を正式に定義します。関連資料は「通知・リマインド設計30」と「n8n自動化レシピ50」です。
このスライドのポイント
- 一問一答:「同期/非同期を分ける1問は？」→ 利用者は結果を見てからでないと次へ進めないか
- 30秒まとめ: 仕組みはF-04・K-09、設計では1問で仕分け、非同期には進捗と完了の見せ方を必ず添える
- 次回: N-09 可用性・拡張性・保守性の正式定義へ
- 関連資料:「通知・リマインド設計30」「n8n自動化レシピ50」
