ポーリング（Polling）（ポーリング）

制御システムやプログラムが、対象の機器・サーバー・処理に対して一定間隔で繰り返し問い合わせ、その状態やデータを確認する処理手法。相手からの通知を待つのではなく、こちら側から能動的に「まだか」「どうなっているか」を聞きにいく点が特徴。

実装上は、問い合わせ間隔（インターバル）、リトライ回数、タイムアウト、打ち切り条件を設計要素として決める必要がある。間隔が短すぎれば相手システムへの負荷とAPI利用枠の消費が増え、長すぎれば状態変化の検知が遅れる。

代表的な用途は次の二つ。

• 死活監視・ヘルスチェック: 監視側が対象サーバーやエンドポイントへ定期的にリクエストを送り、応答の有無や内容で正常／異常を判定する。
• 非同期処理の完了待ち: 相手システムに処理を依頼し、その完了を待ってから次の工程へ進む必要がある場合に、状態を問い合わせ続けて完了を検知する。

対になる考え方がイベント駆動（Webhookやプッシュ通知）で、状態が変わった側から通知を送る。通知を受け取る仕組みが用意されていない、通知の取りこぼしを補完したい、確実に完了を確認してから次に進みたい——こうした場面ではポーリングが依然として現実的な選択肢になる。

外部システム連携やバッチ処理の設計では、Webhookなどのイベント駆動が使える箇所はそれを優先し、ポーリングは「完了を確実に確認してから次工程へ進む」ための手段と「通知の取りこぼしを補う」保険として組み合わせる。実装時は問い合わせ間隔・最大リトライ・タイムアウトを明示し、Shopify APIの利用枠（レートリミット）を圧迫しない設計にする。

実例として、Plus加盟店の案件で3Dセキュアとギフトカードの分割決済時に refunds/create のWebhookが届かない事象を経験した。Shopify Developer Support との調査の結果、Webhookのリトライに頼らず返金情報を定期的に問い合わせて照合するリコンサイルジョブを実装する運用知見を得ている。Bulk Operations のような非同期処理の完了待ちも、状態を問い合わせて検知する典型的なポーリングの場面である。自社コーポレートサイトの運用でも、記事公開の検知をWebhookではなく毎時のフィード巡回で行い、取りこぼしても復旧が容易な方式を選んでいる。