速い判断は現場、集計はクラウドへ

画像を全部クラウドへ送れば、現場の機器を軽くできるのでしょうか。回線の速さや判定までの期限によっては、送る前に現場で処理した方がよい場合があります。まず、何が制約になるかを数字で確かめます。

事例：12台のカメラで、30ms以内に判定したい

工場のカメラは12台。1台が4MBの画像を毎秒2枚出力します。工場からクラウドへの回線は100Mbpsで、装置を止める判定は撮影後30ms以内に必要です。ここではMBを10⁶B、1Bを8bitとして計算します。

現場のエッジ機器なら判定に8ms。クラウドは通信の往復に60ms、計算に5msかかるとします。画像そのものを送る時間や待ち時間は、この通信時間に追加でかかる可能性があります。

速い判断は現場、集計はクラウドへ

1. 画像を渡す
2. 判定結果
3. 結果を非同期送信

判定結果の転送と長期集計を、装置の停止判断から切り離します。

まず、回線に入り切る？

画像の発生量は12×4×2=96MB/s。bitへ直すと96×8=768Mbpsです。100Mbpsの回線では送信が追い付かず、未送信の画像がたまります。CPUを速くしても、回線の不足は解消しません。

現場で判定し、画像1枚につき20KBの結果だけ送るなら、12×0.02×2=0.48MB/s、つまり3.84Mbpsになります。画像を後から調査に使う必要があるなら、別途保管・間引き・転送の方法を決めます。

送るもの	毎秒の発生量	100Mbps回線での判断
全画像	96MB/s = 768Mbps	帯域が足りない
判定結果	0.48MB/s = 3.84Mbps	計算上は収まる

この比較にはヘッダ、暗号化、再送、他の通信の負荷を含めていません。回線の公称値を常に使い切れるとも限らないため、実測値と余裕を確認します。平均だけでなく、同時送信の山も対象にします。

クラウドの計算が速くても、期限を守れないのはなぜ？

クラウド側の下限は60+5=65msです。計算が5msでも、30msの期限を超えます。現場の8msには余裕がありますが、撮影・待ち・制御出力を足した全体の時間が30ms以内かを確認します。

エッジ
機器の近くで処理します。転送量や通信遅延を減らせますが、現場の資源、故障時の動作、更新手順が必要です。
クラウド
遠隔の計算資源を使います。複数拠点の集計や長期保存をまとめやすい一方、回線への依存を考慮します。
分担
期限の厳しい判定と、時間に余裕のある分析を分けます。どちらか一方ですべてを処理する必要はありません。

回線断でも安全側に停止するのか、直近の設定で続けるのかを業務の条件から決めます。「エッジなら常に安全」ではなく、監視、更新、現場機器の冗長化まで設計に含めます。

SPAなら、業務の判断もブラウザへ任せてよい？

注文画面をSPAにすると、読み込んだページの一部を更新しながら操作できます。画面表示はブラウザ、業務データの取得・更新はAPIという分担を考えます。SPAだけで通信断への対応まで備わるわけではありません。

価格、在庫、操作権限の最終確認はサーバ側で行います。ブラウザの値は利用者が変更でき、表示後に在庫も変わります。入力の案内を画面で行っても、API側の検証を省けません。

表示と注文の確定を分ける

キャッシュされた表示は案内に使い、確定時には更新対象の状態を確認します。

在庫の確認と引当の間に別の注文が入るなら、トランザクションや条件付き更新などで競合を扱います。APIを呼ぶ回数だけでなく、データの更新境界と整合性を考えることが必要です。

キャッシュで速くすると、どのくらい古くなる？

公開の商品説明を120秒保存するなら、更新直後から最大120秒程度、古い説明が使われる条件を考えます。実際の古さは作成時刻、保存階層、再検証や更新方法にも依存します。注文確定の在庫を同じ条件で扱うのは危険です。

HTTPでは、保存してよいかと、そのまま再利用してよいかは別の判断です。認証済みの個人情報を、多数の利用者が共有するキャッシュへ混ぜないことも確認します。

指定	基本的な意味	取り違えやすい点
no-cache	再利用前に元のサーバへ再検証する	保存禁止という意味ではない
no-store	その応答などを保存しない	既に保存した過去の応答の削除ではない
private	共有キャッシュでの保存を禁止する	ブラウザ内の保存禁止とは異なる

TTLだけに頼らず、更新時の無効化、版を含むURL、条件付きリクエストを用途に合わせて使います。短くし過ぎると取得回数が増えるため、許容する古さと元のサーバの負荷を合わせて判断します。

演習1：画像をそのまま送る

条件：12台、4MB/枚、毎秒2枚、回線100Mbpsです。

問い：必要帯域と送信の可否を答えてください。

解答例：768Mbpsが必要で、その回線では追い付きません。

根拠：12×4×2×8=768Mbpsです。

誤答の理由：96という値をMbpsとして使うと、Byteからbitへの変換を落としています。

演習2：判定結果だけ送る

条件：画像ごとに20KBの結果を送り、台数と枚数は同じです。

問い：結果の必要帯域を計算してください。

解答例：3.84Mbpsです。

根拠：12×0.02×2×8=3.84Mbps。ヘッダなどは別途加えます。

誤答の理由：削減後も4MBで計算すると、送る対象を取り違えています。

演習3：期限と計算時間

条件：期限30ms、クラウド通信往復60ms、計算5msです。

問い：クラウドで期限を守れますか。

解答例：通信と計算だけで65msとなり、守れません。

根拠：応答時間には通信も含まれます。追加の待ちがあればさらに遅くなります。

誤答の理由：計算5msだけを比べると、利用者が待つ全体の時間を見落とします。

演習4：表示と確定

条件：商品一覧を120秒キャッシュします。注文時の在庫は変動します。

問い：注文APIで必要な確認は何ですか。

解答例：操作権限と最新の価格・在庫を確認し、競合を扱って確定します。

根拠：表示後の変更とブラウザの改変を前提にします。

誤答の理由：画面に表示された在庫をそのまま確定値にすると、過剰な引当が起こり得ます。

演習5：保存と再利用

条件：応答にCache-Control: no-cacheを指定します。

問い：キャッシュへの保存は禁止ですか。

解答例：保存は禁止されず、再利用前の再検証が必要です。

根拠：no-cacheとno-storeは役割が異なります。

誤答の理由：名称のcacheだけから保存禁止と判断すると、仕様を取り違えます。

演習6：回線断に備える

条件：停止判定は30ms以内、クラウドへの回線断が起こり得ます。

問い：処理配置と障害時の条件を説明してください。

解答例：即時判定を現場に置き、回線断でも安全な制御方針で動かします。集計は再送などを別に設計します。

根拠：期限と外部通信への依存を切り分けます。

誤答の理由：クラウドを高性能化するだけでは、回線断で結果を受け取れない問題は解消しません。

出典と仕様を確認する

IPA：APシラバス Ver.7.2

MDN：SPA

MDN：HTTPキャッシュ

処理はどこで動かす？｜エッジ・クラウド・SPA・キャッシュ