DynamoDBを追加せず、CRMの項目だけで結果確認のPollerを回しました。受付後の進行情報をAWS側の別ストアに増やさず、履歴レコード上のJSONに載せます。確認用Lambdaに公開HTTPは付けません。

シリーズ「Zoho WidgetとLambdaの連携」の第5回です。シリーズの締めです。

この記事の内容

構成要素

ポーリングは、完了通知を待つ代わりに、クライアントまたはジョブ側から繰り返し状態照会する方式です。利用者のブラウザタブが閉じても、バックエンドの定期ジョブは継続します。

起動は公開HTTPSではなく、EventBridge SchedulerからIAMでInvokeします。間隔はおおよそ2分です。重要なのは秒数より、公開HTTPではなくScheduler起動という境界です。間隔とバッチサイズは、外部APIのレート制限を超過しない前提で環境ごとに決めます。

運用は履歴を見る前提です。送信ボタン成功は受付成功であり、最終結果ではありません。

照会の終端は、最終成功、最終失敗、または期限切れ等による人手確認です。これが確認用Lambdaの役割です。状態遷移の詳細は第4回です。

入口や副作用の公開HTTPに同居させると、定期ジョブまで公開攻撃面になります。同期の画面操作と非同期の継続処理も混ざります。そのため別Lambdaとし、Function URLは持たせず、SchedulerからのIAM Invokeのみにしました。

DynamoDBはAWSのマネージドNoSQLです。キーアクセス向けの別テーブルとして進行管理を置く設計もあります。

本稿の構成ではCRM側を選びました。進行用の正本を増やさないためです。

確認用Lambda自体はほぼstatelessです。起動のたびにCRMを参照し、対象を取得し、外部を照会し、履歴を更新します。進行情報は履歴レコード上のJSONフィールドに載せます（実フィールド名は記載しません）。

JSONで見る主な項目は、次回照会時刻、試行回数、期限、最後のエラーです。無期限照会を避け、打ち切り後は人手確認へ遷移するためです。

自動確認の対象は、自動照会が必要な状態のみです。最終成功・失敗・人手確認は主対象から外し、自動では再進捗しません。競合（HTTP 412）では上書きせずskipします。

一覧は状態で絞ってバッチ取得します。未到期行が枠を占有すると取りこぼしがありえます。厳密なキューではありません。取りこぼしは、次回起動や期限打ち切りで運用から見える前提で回します。

シリーズ全体で意図的に受容している点、または運用依存の制限です。防衛方針はURL秘匿ではなく、検証できない要求を通さないことです。

制限	扱い
Function URLが `NONE` で公開HTTPになる	URL秘匿を防衛に数えない。HMAC／token／IAMで実効認可
HMACの300秒以内replay台帳なし	受容。更新系はidempotency・競合・状態ガード
プレビュー短命URLの漏洩	有効期限内のPDF読取リスク。業務POSTは閉じる
直送tokenの横断one-time不完全	warmコンテナ上のbest-effort。期限切れは再発行
画面改ざん＋hash一致	確認bytes＝保存bytesまで。画面自体の改ざんは別レイヤ
Poller一覧のバッチ取りこぼし	厳密なキューではない前提で運用
鍵ローテーション手順	運用依存。片方遅れで全HMACが失敗する