法人ギフトの連携鍵を切り替えても二重注文を出さない

架空の東京本社で、年度末の勤続表彰品を手配する金曜の夜です。購買の当番が一件分の発注番号を紙に控えた直後、連携ジョブの応答が切れます。画面には「失敗」。翌朝の補正担当は、支店の受取締切までにその一件を送り直すか決めなくてはなりません。

その晩は連携鍵の切替も予定されています。担当は紙の番号を台帳へ戻し、その一件を照会に回します。新しい鍵で試す注文と、先に結果を調べる注文を分けておけば、切替を進めながら同じ表彰品が二箱届くのを防げます。

---

当番が控えた発注番号から、一件の範囲を決める

当番が紙に書いた番号を照会に使えるようにするには、鍵を替える前から同じ番号で発注を記録しておく必要があります。事業者から注文番号が返るより先に、購買の承認と送信の試みを結びます。朝の補正処理が新しい鍵で起動しても、その記録を先に読めば、夜間に結果が途切れた分と初めて送る分を分けられます。

まず、何を一件として扱うかを購買と合意します。たとえば、社内の購買申請番号、承認された明細番号、納品先の社内参照番号の組を、一件のギフト手配の基準にします。同じ申請に総務宛てと営業所宛ての二明細がある場合は、別の手配です。一方、同じ明細を夜間ジョブと翌朝の補送処理が読み込んだ場合は、一件のままです。品番、数量、メッセージ、納品条件など、承認の対象が何だったかも固定します。内容を変える必要が生じたときは、購買が旧手配の状態を確認してから、修正や取消しを承認します。

ここで使う手配番号は、供給事業者が付ける注文番号とも、プログラムが通信のたびに採番する追跡番号とも別のものです。社内の手配番号は承認から納品確認まで共通です。事業者注文番号は受理を確認した後で紐付けます。通信の追跡番号は、どの送信に応答があったかを後から探すために使います。障害時に追跡番号を発行し直しても、元の手配番号との関連は保ちます。鍵の新旧は通信記録に付ける属性であり、手配番号には組み込みません。更新日の前後で同じ明細を別の注文として数えないためです。

番号の有効範囲も書き出します。例えば購買申請番号が年度ごとに振り直される会社では、法人、年度、発行元を含める必要があります。複数の営業所の発注が一つの連携に集まるなら、支店ごとの番号が衝突しないかを調べます。法人が違う場合は、供給事業者の契約アカウントも対応表に含めます。番号の重複防止と個人情報保護の両方を満たすため、氏名や住所、メールアドレスの代わりに内部の参照番号を使います。外部に渡す識別子の長さや文字種は、事業者の仕様を確認して決めます。

鍵の発行元と実際に使う処理を棚卸しする

外部事業者に注文を送る認証情報と、自社のクラウド上で保管庫にアクセスする認証情報は、発行元も失効の手続きも異なります。夜間ジョブが保管庫から外部事業者の鍵を読んでいる場合、どちらを更新するのかを作業票に明記してください。複数の認証情報を同じ時間に変更すると、注文が届かなかった理由が保管庫の読み取り失敗なのか、外部事業者による認証拒否なのかを追いにくくなります。注文受付と注文照会に別の権限がある場合は、それぞれの利用者も確認します。

棚卸しの起点には、予定表にある本番ジョブだけでなく、実行履歴と事業者側のアクセス記録も使います。夜間の定期実行、翌朝の補正処理、配送状況の取込、手動で起動する運用端末、障害復旧時だけ起動する待機系を順に調べます。環境変数を起動時だけ読むプロセスは、保管庫の参照先を変えても再起動まで旧鍵を保持することがあります。逆に、実行のたびに最新版を取得する設定だと、切替責任者の判断より先に一部の処理が新鍵を使い始めることがあります。各処理が参照する鍵の版と、いつ参照が切り替わるかを一覧にします。

AWS の IAM アクセスキー更新手順では、同サービスで新しい鍵を追加し、利用するアプリケーションを更新してから、旧鍵を無効化して動作を確かめる流れを案内しています。Secrets Manager の日本語資料も、対象がデータベースのシークレットである場合に一つの利用者を更新する方式と二つの利用者を交代させる方式を説明しています。自社の基盤側で操作順を組み立てる際の参考にできます。ギフト事業者の鍵を併用できるかは、別途その事業者の契約と仕様で確認してください。AWS IAM のアクセスキー更新手順 · AWS Secrets Manager のローテーション戦略

切替方法を選ぶ前に事業者へ確認する

併用できる時間を決める前に、同じ法人アカウントで旧鍵と新鍵を同時に有効にできるか、追加発行と失効の時刻は何に記録されるか、照会だけを行える確認手段があるかを聞きます。新鍵で認証が通っても、対象の法人、配送範囲、発注権限が同じとは限りません。書き込み試験が必要なら、事業者の試験環境や、実配送と請求が発生しないことを合意した試験用の手配を用意します。本番アカウントで実際に一箱を送る場合は、宛先と費用について別に承認を取ります。

再送に関しては、同じ依頼番号を使うと一件に集約される仕様があるか、その番号の有効期間、適用されるアカウントや操作、鍵を更新しても同じ範囲で有効かを確認します。二回目の内容が異なる場合や、先の依頼が処理中の場合の応答も重要です。外部参照番号で注文を検索できる場合は、検索への反映にかかる時間と、結果がなかったときに未受理を確定できる条件まで確認します。予定の切替日までに回答が得られない項目は、再送条件として使わず、担当者の確認へ回します。AWS の冪等な応答に関する設計資料

二鍵を併用できる構成でも、二つの処理が同じ手配を担当すると事故になります。どの鍵で送るかを選ぶ前に、手配を取り出す担当を一つに定めます。少数の試行では、例えば一つの営業所の未送信分だけを対象にし、通常の処理が同じ範囲を拾わないようにします。振り分けに使うのは、手配に結びつく所属や承認済みの集合です。通信のたびに無作為に鍵を選ぶと、失敗を再現したり古い鍵の使用者を見つけたりしにくくなります。試行後は対象外の処理も含めて、鍵の版ごとの利用状況を確認します。

受理と出荷が別々に動く台帳を作る

購買側の台帳には、少なくとも手配番号、承認済み明細の版、担当アカウント、現在の状態、事業者注文番号、確認時刻を記録します。状態は、送信前、送信中、結果不明、受理確認、取消確認など、次に取る行動が分かる名前にします。配送伝票番号がまだない受理済みの注文を、未送信として扱わないようにします。反対に、配車や梱包の依頼を出せたことだけで、受取人への配達まで済んだと判断しません。購買の発注管理と配送状況には、それぞれの状態欄を設けます。

内部の重複を抑えるには、承認済みの明細と送信予定の記録を同じ取引として保存するか、定期的に差分を検出できる仕組みにします。送信担当は台帳上で手配を取得し、同じ手配番号を二つの担当が同時に取得できないようにします。担当が通信の途中で異常終了した場合は、取得期限の満了でその手配を他の担当へ戻す前に、送信に着手した可能性を確認します。期限切れの行をすべて送信前に戻すと、先に届いていた発注が再び流れます。結果不明を扱う照会担当へ引き渡す方が、境界を保ちやすくなります。

社内台帳の記録と、外部事業者による受理は、通常は別の仕組みで起きます。事業者が受け付けた直後に回線が切れると、内部の担当は受理番号を記録できません。このため内部で一件しか取得できない仕組みだけでは、外部で一件しか成立しないことまで証明できません。注文を送る直前に対象を記録しておけば、処理が止まった後も、事業者に確認する対象を絞れます。事業者の側で重複防止が保証される場合でも、期限を過ぎた補送や別アカウントへの再送は個別に判断します。

監視記録には、社内手配番号、通信の追跡番号、鍵の版を示す社内ラベル、応答の分類を残します。鍵本体、認証ヘッダー、送り先の住所やメッセージ本文は、障害通知やチームの会話に載せないようにします。内容の一致を機械で確認する場合は、承認済み明細の版を参照し、必要に応じてアクセスが制限された場所で内容の照合値を管理します。外部から届く配送や状態の通知は、契約で定めた真正性の確認を経て台帳へ反映します。同じ通知が複数回届いても、発注の再実行を起動しない構成にします。

停止と再開の手順を夜間当番に渡す

作業の開始時には、変更責任者が今回の対象法人、連携先、ジョブ、承認済み明細の締切、保留できる時間を確認します。購買が承認を続けられる場合でも、連携担当が発注を送る入口を停止できるようにしておきます。定期ジョブの起動を止めても、すでに起動した処理、時間差で登録された再送、手動ボタンなどが動くことがあります。それぞれの停止を確認し、停止時刻に実行中だった手配は別に記録します。利用者が承認結果を見られる画面には、承認済みで発注連携待ちであることを表示すると、現場での二重手配も減らせます。

予定どおり旧鍵が使える場合は、最初に読み取り専用の確認で、新鍵が期待した法人を指していることを確かめます。続いて、合意済みの試験で一件の依頼に一件の受理結果があることを調べます。正常応答を受け取った後に台帳が更新されるか、応答が欠けた場合に保留へ移るか、再開後に保留分が通常の送信対象に混ざらないかを確認します。旧鍵がまだ使えることだけを根拠に、故障時に全件を旧鍵で送り直す手順は設定しません。旧版の設定に戻す場合も、送信済みの可能性がある行は照会を続けます。

再開できる件数は、滞留している数だけでは決められません。委託先が同時に受け付けられる量、配送の締切、照会担当が扱える未確定件数を合わせて判断します。例えば、最初の五件がすべて受理済みで、発注と台帳の対応が取れたことを確認してから次のグループへ進みます。応答が遅いときは、送信数を増やす前に事業者と状況を共有します。一時的な通信エラーに備えた再試行にも、重複防止の条件、待機時間、回数の上限が必要です。AWS のバックオフによる再試行パターン

受理の確認に事業者の営業担当しか対応できない場合は、夜間当番の作業を「新鍵での接続確認と新規分の限定処理」までに区切ることもできます。結果不明の手配が数件残っていても、翌朝に確認する担当と期限が決まっていれば、その範囲を保留にしたまま別の未送信分を扱えます。保留の基準が決まっていない状態で夜間に再開すると、担当者が配送の都合を優先して手作業で補送しやすくなります。配達日が近い明細は、どの時点で社内依頼元へ遅延を案内するかも作業票に記載します。

---

年度末の三十件から、応答のない一件を切り離す

冒頭の東京本社では、年度末の勤続表彰品に三十明細の承認がありました。支店へまとめて送る分と、在宅勤務者の指定先へ送る分があり、受取の締切が異なります。事業者は同じ契約アカウントで二つの鍵を短時間併用でき、社内の手配番号で照会できると回答しています。購買は、夜間の定期ジョブと朝の補正処理が同じ発注台帳を参照することを確認します。

切替開始時には、十二件に事業者注文番号があり、十七件は送信前でした。残りの一件が、夜の担当者が番号を控えた行です。その一件は定期ジョブと補正処理の両方から外し、購買の照会一覧へ置きます。試行は、十七件の未送信分から購買が選んだ少数に限ります。支店への一括と個別の納品を試し、それぞれ一回の発注に事業者注文番号が一つ付くことを確かめてから対象を増やします。十七件と一件をまとめて「残り十八件」と書かず、朝の引継ぎにも別の状態で載せます。

事業者からは、応答の途切れた一件も旧鍵で受理されていたと回答が来ます。購買は紙に控えた番号の台帳行に既存の注文番号を記録し、支店へ配送確認を引き継ぎます。再送は行いません。朝の補正処理で新しい版が使われたことを確かめ、旧鍵を読む処理が残っていないことを確認してから旧鍵を無効にします。その後は、事業者と合意した安全な照会で旧鍵が拒否され、新鍵で同じ契約アカウントの照会ができることをそれぞれ試します。元の三十明細が、十二件の既知の受理、一件の照会結果、十七件の新規受理に対応するところまで照合します。

販促の鍵が漏れた場合は、併用せずに受付を止める

大阪の事業部が代理店向けの新製品説明会を終え、アンケートの回答者へお礼を手配する想定です。イベント翌朝、連携処理のログを共有した際に認証情報が出力されていたと判明しました。購買は四十件を承認し、十件には事業者注文番号があります。九件は送信中だった可能性があり、残る二十一件はまだ取り出されていません。この場合、旧鍵を残したまま段階的に移すと、不正利用の可能性がある時間が長くなります。対象の発注を止め、情報セキュリティ責任者と事業者の窓口で失効と証跡の保全を進めます。IPA の中小企業向けサイバーリスク事例集

先に十件の注文を事業者側で確認し、予定していた宛先や明細との不一致がないかを調べます。次に九件を手配番号で一件ずつ照会します。照会で五件の受理を確認でき、四件は初回検索に出ないとします。検索への反映が遅れる仕様なら、この四件は保留のままです。同じ法人の注文履歴に、社内の承認と対応しない注文があれば、正規の再送候補に含めず、事業者に出荷停止が可能かを確認します。すでに発送されていた場合は、倉庫の記録と配送会社の受付を確かめ、取消しや回収の可否を購買が判断します。

新鍵を安全に設定できた後、証跡が揃った未送信の二十一件だけを再開します。未確定の四件は、事業者から処理待ちも受理も存在しないことを確認できた段階で、元の明細と承認の有効性を検証してから送信します。旧鍵を無効化した後に業務用の連携が停止しても、旧鍵を再び有効にする判断は取りません。連携処理を止めた状態で、事業者の管理画面や合意した窓口を通じて、照会と出荷状況の確認を続けます。発注手段を切り替える場合も、同じ手配台帳で担当と状態を更新します。

---

受入試験で「送信成功」の外側を確かめる

受入試験では、通常の成功だけでなく、同じ明細が二つの入口から来た場合、事業者が受理した後に応答だけが失われた場合、旧鍵の無効化後に待機系が起動した場合を含めます。模擬の受理結果を使える環境では、応答を受け取らないまま通信を終了させ、その行が結果不明へ移って照会まで再送されないことを確かめます。同じ手配番号に別の内容を混ぜた場合は、自動処理が先へ進まず、購買へ差し戻されることを確認します。受理結果を照会で補完した後に、遅れて元の応答や同じ通知が届いても、一つの注文番号に収まるかを見ます。

切替の途中で新鍵が想定外のアカウントを指したり、必要な権限が足りなかったりした場合は、対象の発注を停止します。原因確認では、発注と照会のどちらが拒否されたか、事業者による拒否か自社の保管庫での読み取り失敗か、未確定行が増えていないかを確認します。エラー表示が消えたことだけで停止を解除せず、正しいアカウントで読み取り確認をやり直し、試行した明細と実際の注文を照合します。事業者注文番号が社内の明細と一致しなければ、別法人のデータが混じっていないかも調査対象です。

切替責任者の完了承認には、承認済み手配の総数と内訳、受理確認済みの一覧、保留理由と担当、旧鍵の失効確認、新鍵で必要な操作ができた証跡を添えます。購買は請求の重複や配送の重複を翌営業日にも確認します。受理と配送の反映に時間差があるため、同じ時間帯に取得した画面同士で突き合わせ、差がある場合は取得時刻を記録します。未確定の手配は完了した件数に含めず、いつまでに誰が決めるかを記録します。翌朝に見た人が、対象の一件を迷わず調べられれば、夜間に作成した作業票が実際に役立ちます。

朝の当番が保留の理由と期限を読めるようにする

朝に届く表には、夜に応答を受け取れなかった一件が再び並ぶことがあります。保留の印だけでは、当番は受取期限を理由に手で送り直すかもしれません。元の番号、事業者への照会時刻、次に回答を待つ先、再送の可否を台帳に残します。照会を待っていることを知った支店も、受取人に確定していない予定を案内せずに済みます。

連休前の切替では、変更作業が終わる時刻と、倉庫の出荷締切を別に確認します。例えば金曜日の夜に新鍵での接続を確認できても、事業者の照会窓口が月曜日まで開かなければ、金曜日に送った結果不明分を確定できないことがあります。保留のまま配達予定日を迎える明細は、購買から社内依頼元へ連絡し、納品日を変更するか、先に発送済みの品だけを案内するかを決めます。依頼元が別の調達先に同じ品を注文する可能性があるなら、その操作も手配台帳に入れます。注文ルートを変えた時点で、元の事業者への依頼を放置してよいとは限らないからです。

保留が長引いた場合に備え、事業者との取引記録の取得方法も決めます。翌営業日に担当者が注文一覧を出力する運用なら、法人と対象期間を指定し、照会に使った手配番号と照合します。金額と日付だけが一致する行は候補にとどめ、明細や承認された配送条件が合うまで受理確定にしません。購買の月次締めが先に来る場合は、未確定分を承認済みの予定額として区別し、事業者の請求が届いてから計上済みの注文と突き合わせます。現場の締切が異なっても、手配番号を揃えると同じ一件を調べられます。

---

紙に控えた一件を、朝の台帳で閉じる

補正を受け持つ担当者は、金曜の紙にあった番号を引くと、旧鍵で成立した注文と現在の配送状況を確認できます。支店で受け取るのは、購買が承認した一件に対応する一箱です。朝までに回答が得られなければ、その番号と次に照会する時刻を引き継ぎ、発注は保留のままにします。新鍵でほかの明細を処理できることと、応答のなかった一件をもう一度出せるかどうかは、同じ判定にしません。

---

Giftpack を検討するときに購買が渡す情報

複数の拠点や受取人に法人ギフトを届ける計画では、配送先の範囲、承認方法、受取人による選択の有無、問い合わせ窓口を整理してから、提供サービスを比較します。Giftpack のヘルプでは、目的、対象、予算、国、希望する品目、承認や社内規定といった情報をもとにキャンペーンを組み立てる流れを紹介しています。連携を前提に見積もる場合は、発注、照会、取消しをどの方法で行えるか、鍵を更新する際にどこまで試験できるかを契約前に確認してください。社内で一件を追える手配番号、結果が不明な場合の保留先、事業者との連絡経路を最初の打ち合わせで共有すると、実際の運用に合わせて選べます。Giftpack の法人ギフトとパーソナライズに関するヘルプ