大阪の運用担当、真紀は、取引先向けキャンペーンの案内を出す朝にチャネルシークレットの再発行を任された。配信担当は予定どおり進めたいが、真紀は先に発送処理を保留する。新しい設定で届いたリクエストを検証できることと、既に承認した一件が二件の注文にならないことを確認するまで、受信の成功を発送許可として扱わないためだ。
この手順の目的は、認証設定を切り替えても、元の承認判断を維持することにある。LINEのイベント、社内のギフト承認、外部への手配指示は別の記録だ。再送を受け取ること自体は異常ではない。一方、署名を確認できなかった本文を、担当者が見覚えのある内容という理由だけで再処理に流すことはできない。
再発行前に、無効になる設定と止める処理を決める
LINEの署名検証に関する公式説明では、新しいチャネルシークレットを発行すると従来のものは無効になる。旧設定と新設定を都合よく併用できると想定しない。まず影響するチャネル、受信エンドポイント、実行環境と設定の参照先を特定する。似た名前の検証用チャネルで試しただけでは、本番の設定が正しい証拠にならない。
再発行の権限を持つ担当者と、アプリケーションに設定を反映する担当者が異なる場合は、作業の順序を明示する。実際の秘密値は組織の承認済み保管先で扱い、変更票には機密を含まないバージョン識別子を残す。秘密値が見える画面の画像を、関係者全員が読める議事録に貼り付ける必要はない。
真紀は受信経路と発送経路を分けて考える。安全に検証し永続化できる受信まで止める必要があるか、発送ワーカーだけを保留できるかは、実装と障害範囲によって異なる。保留はデータの削除ではない。どの状態を保存し、誰が再開を決めるかを先に決めないと、復旧時に全件を新規扱いする事故につながる。
漏えいの懸念がある再発行なら、通常の保守とは別に、社内のインシデント対応者が隔離と影響調査を判断する。予定された案内の時刻が、疑わしい秘密値を信頼し続ける理由にはならない。定期作業でも緊急作業でも、最終的に現在有効な設定での検証と、既存の承認記録との突合が必要だ。
原文の検証と、業務上の許可を分ける
受信した本文と署名ヘッダーを変更せず、イベントを業務処理する前に検証する。JSONを読み直して整形した文字列は、見た目が同じでも元のリクエストと同じとは限らない。ミドルウェアが本文を書き換えるなら、その経路を修正する。検証に失敗するからといって検証機能を外すと、変更作業の目的そのものが失われる。
社内では、受信試行、検証済みイベント、承認、手配指示、外部結果を別々に管理すると整理しやすい。受信試行は到着の事実、検証済みイベントは信頼できる発生元、承認は誰に何の目的でいくらまで渡せるかを表す。手配指示はその許可を一度だけ実行するための社内記録であり、外部結果は実際に注文が成立したかを表す。
LINEの受信と再送の公式説明にある webhookEventId は、同一イベントの重複検出に使える。ただし、イベントの識別子は社内の贈答方針ではない。同じ受取人に別の機会で贈ることはあり得るし、異なる二つのイベントが一つの承認機会に対応することもある。両方を扱える業務側のキーが必要になる。
承認キーの範囲は、組織、企画、受取人の安定した社内参照、対象期間などから、実際の制度に合わせて定める。表示名だけで一意にしたり、一度贈った人には永久に贈れなくしたりしない。例外の補送にも根拠となる別の許可が必要だ。キーの設計は、費用と対象者を決める企画責任者が確認する。
| 記録 | 確認すること | 残す証拠 |
|---|---|---|
| 受信試行 | 現在の設定で検証できたか | 到着時刻、設定版、検証結果 |
| 検証済みイベント | 同じ発生元を既に受理したか | 元のイベント参照と状態 |
| ギフト承認 | この機会は今も許可されているか | 承認キー、方針版、判断 |
| 手配指示 | 同じ許可で既に手配を始めたか | 一意の指示と外部参照 |
検証に成功しても、予算や受取人の確認が済んでいなければ業務保留になる。逆に、担当者が受取人を知っていても、未検証のイベントが信頼できるものに変わるわけではない。問い合わせ画面でもこの違いを示しておくと、受信障害と承認待ちを混同せず、適切な担当者に引き継げる。
判断例一：大阪の切り替え試験では、何を数えるか
真紀の試験では、五十二回のHTTP受信を用意したとする。四十回は異なるイベントの有効な初回送信、七回はその一部の有効な重複送信、五回は意図的に誤った署名を付けた試行だ。四十件の検証済みイベントのうち、三十一件には現在有効な承認があり、九件は企画担当の確認待ちとする。いずれも試験の前提であり、企業の実績値ではない。
受信段階で期待するのは、四十件の異なる検証済みイベントと、七回の重複受信の証拠である。五回の検証失敗は信頼済みの処理対象に入れない。安全上必要な診断を制限付きで残すことはあっても、失敗した本文をそのまま再送用の業務キューに移してはいけない。それでは署名検証を迂回する別の入口になってしまう。
業務段階では三十一件の一意な手配指示と、九件の承認待ちを期待する。四十七回の有効な受信が四十七件の注文になるわけではない。重複を除く数と、業務判断で保留した数を分けて示す。担当者が見る集計にも、それぞれの単位を表示し、「処理済み」という一つの列に押し込めない。
実際の再発行に備える試験では、発送を保留していること、既に検証済みの記録が保存されていることを確認してから、授権された手順で設定を変更する。新しい有効な設定を使った受信が通ることと、誤った署名が依然として拒否されることを両方見る。旧設定が無効になった後で、古い試験データを通すために信頼を戻さない。
次に、既に受理したイベントについて、正規の検証経路を通る再送を試す。同じイベント参照から既存の承認と手配指示に戻り、新しい指示を追加しないことが合格条件だ。保存済みの信頼できるイベントを社内で再評価する操作と、未検証の本文を入力し直す操作は区別する。後者を前者と同じ権限で扱ってはいけない。
外部結果も確かめる。三十一件の指示のうち三十件で注文の成立を確認でき、一件は通信のタイムアウトで結果が不明だったとする。この段階は三十件完了と一件不明であり、三十二件目を作る根拠はない。元の指示に付いた外部参照を使い、実際のシステムで成立の有無を照合する。
既に成立した注文が見つかれば、その結果を元の指示に結び付ける。未成立が確認でき、実際の契約で再試行できる場合は、同じ指示の管理下で行う。判断できなければその一件を保留する。外部の冪等性や照会機能を確認していないのに、同じ内容を送れば必ず安全だとは約束しない。
判断例二：福岡の二つのイベントを、一つの承認に戻す
福岡の企画担当が、同じ参加者から二つの有効な操作イベントを受け取ったとする。イベント識別子は異なるが、どちらも同じ企画、同じ受取人、同じ承認機会を指す。イベント単位の重複排除はそれぞれを一度受理するので、ここだけでは二重手配を防げない。業務承認のキーで同じ指示に戻す必要がある。
二つのワーカーがほぼ同時に「まだ指示がない」と読んだ場合を試す。確認してから別々に追加するだけでは、両方が空の状態を見てしまうことがある。実際のデータベースの制約や取引処理などを使い、一つの承認キーに対する有効な指示を原子的に確定させる。どの仕組みを使ったかも試験記録に残す。
この前提での合格は、二つの検証済みイベント、一つの承認、一つの指示、一つの確認済み外部結果である。後から来たワーカーは既存の指示を参照し、完了または保留の状態を返す。重複追加をデータベースが拒否しても、画面が一律に「失敗、もう一度実行」と表示すれば、人が別の注文を作る恐れがある。利用者に示す状態まで確認する。
比較用に、同じ受取人が別企画の正式な承認を持つ試験も行う。その制度で認められた別の機会なら、二件目の指示が正しい場合もある。重複を防ぐ試験と、正当な別件を誤って止めない試験は対になる。氏名やメールアドレスだけを共通キーにすると、この境界が曖昧になる。
さらに、後から届いたイベントの処理時点で承認が取り消されていた場合を試す。発生元が正しいことは、取り消し済みの支出を復活させる理由にならない。現在の権威ある承認状態を読み、既存の中止や確認の手順に従う。既に発送した品を、受信記録の状態変更だけで取り消したことにもしない。
承認と履行の基本的な分離は、隣接する更新イベントから企業ギフトを判断する運用記事でも扱っている。こちらの試験は、その業務方針を再発行の前後で守れるかを確認するものだ。別サービスのイベント例を参考にしても、受信と署名の仕様は実際のLINEチャネルに合わせる。
再送は、欠落を自動的に埋める保証ではない
再送の利用状態は実際のチャネルで確認する。公式説明では初期状態で無効であり、利用には設定が必要だ。また、再送の回数や間隔は公開されず、確実な再送も保証されない。固定の時間だけ待って「もう全件そろった」と判断したり、後で必ず戻るから受理記録を不要としたりしない。
受信の順序が発生順と異なる可能性にも備える。時刻は前後関係を調べる手がかりだが、それだけで発送許可を確定しない。古いイベントを受け取った時点で承認が変わっていることもある。元のイベントの意味と、現在の業務状態を分けて確認する。複数の更新を単純な到着順で上書きする設計は、切り替え時に特に確認したい。
送信元の応答トークンと社内の手配指示も同一視しない。メッセージへの応答と、ギフトの注文成立は別の操作である。画面に案内を返せたことを、配送が完了した証拠にしない。通知文には、受付、審査中、手配済みなど、実際に確認できた状態を対応させる。相手に再操作を勧める前に、既存の承認と指示を検索できるようにする。
障害で記録が足りない場合は、企画の承認対象と、受理済みイベントと、手配指示の差分を照合する。差分があることと、特定のイベントが本当に送られたことは別の事実だ。確認できない部分は不明として担当者を割り当て、見かけの件数を合わせるために架空のイベントを作らない。必要な追加承認があるなら、その経路で記録する。
障害を再実行ボタン一つに集約しない
署名エラーなら、チャネル、環境、設定版、本文を変更した処理の有無を順に調べる。複数の実行個体のうち一台だけ古い参照先を使っている可能性もある。一台の成功だけで全体を再開せず、実際にトラフィックを受ける範囲の設定を確認する。検証を一時停止する修正は、問題を解消するのではなく見えなくする。
永続化の前にデータベースが停止したなら、受理済みとは扱えない。実際の受信契約と試験済みのエラー応答に従う。既に検証済みの記録を保存し、承認の評価だけが未完了なら、その状態から続ける。どちらの場合も記録を消して全件を送り直す方式では、外部結果が残っている指示まで二重実行される恐れがある。
外部への依頼後に応答が失われた場合は、元の指示参照、送信時刻、外部の照会に必要な情報と不確実性を保存する。秘密値や不要な個人情報をログに追加する必要はない。元の注文を調べるための情報を残し、別の表から新しい指示を組み立てない。調査の責任者と、再試行できる証拠を明示する。
アプリケーションを旧版に戻す場合も、旧シークレットが復活するわけではない。戻した版が新しい有効設定を扱えないなら、影響範囲の発送は保留を続ける。修正版か検証済みの構成が準備できるまで、復旧と記録しない。設定変更の巻き戻しと、事業上の処理状態の巻き戻しを一つの操作にまとめないことが重要だ。
引き継ぎ担当が、同じ判断を再現できるか
真紀は、自分が口頭で説明しなくても別の担当者が対応できるかを確認する。変更票には、現在の有効な設定参照、受理済みの記録、保留した承認、不明な外部結果、次の許可された操作を記す。資料が多いだけでは十分ではない。各記録から同じ承認キーと同じ指示にたどれることが、引き継ぎの実用性を決める。
一つ目の引き継ぎ試験は、実在しそうな受取人の情報を持つ未検証の本文だ。担当者は業務処理に入れず、制限された調査として扱う。二つ目は、検証は成功したが承認が未完了のイベントだ。これは技術障害として再送を要求せず、企画担当の判断を待つ。三つ目は外部結果不明の指示で、既存の注文を先に照合する。
この三つは、利用者にはどれも「まだ届かない」と見えるかもしれない。窓口には異なる案内が必要だ。秘密値や内部検証の詳細を伝える必要はないが、単にもう一度押すよう勧めると事態を複雑にする。元の受付参照で状況を調べ、どの担当者が何を確認しているかを説明できる形にする。
状態名は組織に合うものを選んでよい。ただし、未検証から承認済みへ直接移れないこと、結果不明から新規指示へ自動的に移れないことを明確にする。例外には理由と権限を記録し、元の失敗を上書きして見えなくしない。問い合わせ担当の閲覧権限と、設定変更や支出承認の権限も分けて確認する。
証拠の表で、再開の条件を揃える
| 確認項目 | 大阪の試験で期待する結果 | 未達の場合 |
|---|---|---|
| 新設定の検証 | 有効な試験が通り、保存される | 受信経路を修復する |
| 不正な署名 | 五回とも信頼済み処理に入らない | 影響範囲の発送を止める |
| 重複した送信 | 七回で指示が増えない | 二層の識別を調べる |
| 承認の維持 | 三十一件許可、九件確認待ち | 元の方針と照合する |
| 外部結果の不明 | 三十件確定、一件を保留 | 元の外部依頼を調べる |
| 同時処理 | 一つの承認に一つの指示 | 原子的な制御を修正する |
合計の意味も添える。五十二回は受信試行で、四十七回は有効な試行、四十件は異なるイベント、三十一件は承認済みの指示である。これらを足して成果件数にはできない。一件不明を解消したときも、元の指示に結果を付けるのであり、新たな指示数を増やすわけではない。
実装者以外の確認者が、実際の版と試験結果を確認する。正常系だけでなく、誤った署名、同時処理、別企画の正当な承認、取消済みの承認、外部のタイムアウトを含める。期待値を書いた表だけでは実行証拠にならない。観測した結果と、その結果を説明できる参照先を残す。
保存する証拠は必要な範囲に絞る。通常の報告は不透明な識別子と結果で足りる場合が多い。調査で原文を保管するなら、既存のアクセス制御と保存期限を適用し、住所や連絡先を広い共有先へ複製しない。秘密値の実物を見せずに検証結果を確認できることも、運用設計の一部だ。
補送と再評価を、元のイベントから切り離さず管理する
品物が実際に破損し、企画責任者が補送を認めた場合を考える。これは元のイベントを再送するだけで成立する新しい権利ではない。元の指示、確認した事故、追加の承認を関連付け、どの範囲で再手配を許したかを残す。重複防止を理由に正当な救済を拒まないためにも、通常の再試行と追加承認の違いを明確にする。
社内の再評価ツールには、既に検証済みのイベントと対象の承認を選ばせる。任意の本文を貼るだけで信頼済みイベントを作る入口にはしない。操作した人、理由、評価する方針版を記録し、通常の処理と同じ一意性の制約を適用する。障害を直した後の再評価でも、既に手配済みなら元の指示へ戻ることが合格条件となる。
試験では権限のない担当者による操作も確認する。閲覧できることと再評価を許されることは別だ。権限のない操作は処理を変えず、必要な監査記録だけを残す。許可された担当者が同じイベントを再評価しても、既存の承認と指示の関係が維持される。こうした管理は社内実装の責任であり、署名検証のライブラリに備わる業務機能とは説明しない。
時刻も具体的に残す。再発行を行った時刻、アプリケーションへ反映した時刻、新しい設定で初めて検証できた時刻、発送を再開した時刻は一致しない場合がある。日付だけでは、どの設定で受理したかを説明できない。時差やサーバー間の時計のずれを確認し、曖昧な前後関係から信頼性を推測しない。
最後に、復旧の結果を差分として保存する。本文を変更していた処理を修正したなら、修正版、現在有効な試験の結果、依然として拒否される不正な試験を記録する。元の未検証データを成功に書き換えるのではなく、何が直り、どの信頼済み記録から続行したかを示す。次の担当者は、その証拠を基に同じ手順を再現できる。
再開後も、一件の不明を完了に変えない
再開する担当者は、設定の有効性、承認件数、既存の手配指示を突合し、影響のないものから社内方針に従って進める。保留は明確な理由と責任者を持つ一件として残す。別の試験が成功したからといって、その一件まで自動的に再試行可能にしない。新しい差分が出たら、対象の指示と版を特定して調査する。
監視も分ける。署名検証の失敗、受理の保存失敗、承認待ちの増加、外部結果不明の滞留では、対応する人も違う。「Webhook失敗」という一つの通知だけでは、夜間の担当者が原因を推測することになる。通知から必要な記録にたどれるようにし、観察期間は実際の再送仕様と企画の運用時間に合わせる。
再開を決める責任者と、不在時の代理者も変更票で明示する。引き継ぎの会話だけで権限が移ったと推測せず、既存の承認手順に沿って担当を確かめる。未解決の一件は、次に確認できる条件と連絡先を添えて残す。
真紀の最初の判断は、新しい有効設定を証明し、既存の承認を守った上で案内を再開することで完結する。時刻どおり送るだけでは合格ではない。二つの受信が一つの承認に戻り、結果不明の外部依頼が勝手に増殖しないことまで確認して、変更を閉じる。
承認された企画を、Giftpackとの具体的な相談につなげる
社内の判断と手配指示が整理できたら、対象者、国、予算、時期、品目の制約と確認責任者をまとめる。Giftpackの企業ギフトに関する案内では、企画に必要な情報や選択肢、人による確認について説明している。実際の調達、生産、在庫、配送条件は案件ごとに確かめる必要がある。
共有するのは、秘密値を含まない、承認済みで追跡できる要件でよい。未確認のLINE連携や自動承認機能があると想定せず、実際に利用する手配方法を合意する。真紀が守った一つの承認を、適切なギフト体験へ引き継ぐ。そのために、認証、業務判断、外部結果を最後まで分けて残す。