「Account Updater（国際カードブランドのカード自動更新サービス）を入れているから、カード期限切れによる解約は基本的に大丈夫」 — 決済まわりの設計を相談すると、ここ数年で頻繁に出てくる言葉です。
結論から書くと、これは 半分は正しく、半分は誤解 です。Account Updater（以下 AU）は確かに、加盟店側で何もしなくてもカード有効期限を裏側で書き換えてくれる強力な仕組みです。ただし、AU で自動的に書き換わるカードの割合は事業者・カード種別・発行銀行ごとに大きく振れ、業界の参考値では カバー率は概ね 60〜80%（参考値） 程度と言われます。残り 20〜40% は構造的に AU の対象外となり、加盟店側で「カード更新案内」を送らないと、そのまま受動的チャーン（Involuntary Churn）に流れ込みます。
本記事では、AU が担う範囲・担えない範囲の境界線、近年のフィッシング啓発がカード更新案内のクリック率と更新率に与えている影響、そして AU を否定せず、AU が拾いきれない後段を埋めるための運用整理を扱います。背景となるカード期限切れそのものの構造はカード期限切れと「気づかれない解約」を、案内タイミング設計はカード更新案内メールの「タイミング設計」をあわせて確認してください。
「Account Updater 入れてるから大丈夫」という誤解
SaaS や D2C のサブスクリプション事業者様にカード期限切れ対応の話を持ち込むと、次のような反応をいただくことがあります。
- 「Stripe（または PAY.JP・KOMOJU・GMO-PG）を使っているから、カード情報は自動で更新されているはず」
- 「Account Updater が動いているから、カード更新案内メールはそもそも不要なのでは」
- 「以前カード期限切れの案内を送っていたが、AU 導入後に止めた」
これらは、AU が動いているケースについては事実です。実際、AU でカード番号・有効期限が裏側で書き換わった顧客に対して、加盟店から「カード情報を更新してください」というメールを送るのは、むしろ顧客体験を悪化させます（顧客側からすれば「更新した覚えがないのに更新を求められている」状態になるためです）。
ただし、ここで見落とされやすいのが 「AU でカバーされていない 20〜40% の顧客には、依然として加盟店側からの案内が必要」 という事実です。AU を入れたから「すべての顧客に対して案内が不要になった」のではなく、「AU でカバーされた顧客には案内が不要になった」だけです。AU 後に残る顧客に対する運用設計が止まると、その分の受動的チャーンは静かに積み上がっていきます。
Account Updater とは何か
Account Updater は、国際カードブランドが提供する、加盟店登録カード情報の自動更新サービスです。代表的なものは以下です。
- Visa Account Updater（VAU）: Visa が提供する自動更新サービス。加盟店が登録している Visa カードの有効期限・カード番号変更を、発行銀行のデータと照合して自動更新します。
- Mastercard Automatic Billing Updater（ABU）: Mastercard が提供する同種のサービス。仕組みは VAU と類似で、加盟店登録カードを発行銀行データと照合して自動更新します。
- American Express Cardrefresher: Amex が提供する自動更新。対応地域・対応加盟店が限定されます。
- JCB / Diners / Discover の対応: 各ブランドで AU 相当のサービスが用意されているケースがあります。国内発行カードについては、ブランドごと・発行銀行ごとに参加状況が異なります。
国内主要決済代行会社の対応状況は、概ね以下です（2026 年時点・参考値）。
- Stripe: Card Account Updater（VAU/ABU 連携）が標準的に提供されており、自動更新がデフォルトで動作するケースが多い。
- PAY.JP: 一部カードについて Account Updater 相当の自動更新に対応。
- KOMOJU: ブランド・発行会社単位で対応状況が異なる。
- GMO-PG / SBPS: マーチャント契約・加盟店プラン単位で AU 連携の可否が変わるケースがある。
つまり「決済代行会社を使っていれば自動的に全カードが更新される」のではなく、決済代行会社 × カードブランド × 発行銀行 × 契約プランの組み合わせで、AU が動くかどうかが決まります。詳細は契約中の決済代行会社の AU 対応資料を確認するのが正確です。
なぜカバー率に上限があるのか — AU が拾えない 5 つのケース
AU は強力ですが、構造的に拾えないケースが存在します。代表的なものは以下です。
1. 発行銀行が AU プログラムに参加していない
AU は、加盟店側だけでなく、カード発行銀行側も AU プログラムに参加していて初めて成立します。発行銀行が AU に参加していない場合、その銀行が発行したカードについては、有効期限が更新されても加盟店側に反映されません。
国内発行カードについては、大手銀行・信販系の参加率は比較的高い一方、地方銀行・流通系カード・一部のクレジットカードについては参加状況が個別に異なります。海外発行カードについても国・発行銀行単位で参加率が変わります。
2. カード再発行（紛失・盗難）は対象外
AU は「同じカード番号・有効期限が更新される」または「リプレース後の新しいカード番号が反映される」シナリオを想定した仕組みです。一方、紛失・盗難によるカード再発行は、不正利用対策の観点から AU の対象外として扱われるケースが多くあります。
この場合、顧客は新しいカードを手元で受け取りますが、加盟店側の登録カードは旧カードのままです。次回課金のタイミングで決済エラーになり、加盟店側からの案内が必要になります。
3. 国際カードブランドが変わる発行替えは対象外
顧客が VISA カードから JCB カードへ、または別ブランドへ切り替えた場合、AU はブランドをまたいで情報を引き継ぐことはできません。AU は同一ブランド内での更新を担当する仕組みであり、ブランド変更時は事実上「別のカード」として扱われます。
このケースでは、加盟店側で旧カードがエラーになって初めて気づくか、顧客自身に新しいカード情報を登録してもらう必要があります。
4. デビット・プリペイドは多くで対象外
AU はクレジットカードを主たる対象としており、デビットカード・プリペイドカードについては対応が限定的です。発行銀行・ブランド・地域によっては対応するケースもありますが、サブスクリプション事業者様の登録カードにデビット・プリペイドが含まれる場合、AU カバー率は構造的に下がります。
特に、近年は若年層を中心にデビット・プリペイドの利用比率が増えており、業種によっては AU が十分機能しない母集団を抱えるケースがあります。
5. 顧客都合の解約・締切後の更新は AU 範囲外
顧客がカードを能動的に解約した場合、または有効期限切れ後しばらく経ってからカードを再発行した場合、AU が更新情報を取得するタイミングを過ぎていることがあります。AU は発行銀行とのデータ同期サイクルで動いており、リアルタイム同期ではありません。
この場合、加盟店側に届く情報は「決済エラー」のみで、顧客に直接案内する以外の経路がありません。
AU 後に残るカード更新案内対象のレンジ参考値
これらを総合すると、Account Updater を入れていても、月次でカード期限切れ系の決済エラーが一定数残る、という構造になります。海外の参考値ベースでは概ね次のレンジです（参考値・事業者の業種・顧客属性で大きく振れます）。
- AU カバー率: 概ね 60〜80%（参考値）。決済代行会社・カードブランド構成・顧客属性で変動。
- AU 後に残る期限切れ系決済エラー: 全期限切れ顧客のうち 20〜40%（参考値）。
- うち加盟店側からの案内で更新が成立する割合: 10〜30%（参考値）。
つまり、AU を入れていても、月次で発生する期限切れ顧客のうち約 2〜4 割は加盟店側の案内に依存し、そのうち実際に更新まで至るのは更にその 1〜3 割、というのが現実的なレンジです。「AU を入れたから期限切れ案内は不要」という前提でこの母集団を放置すると、構造的に受動的チャーンが積み上がります。
フィッシング啓発でクリック率が下がっている
もう一つ、近年のカード更新案内運用で見落とせない変化が、フィッシング啓発の浸透によるクリック率の低下 です。
クレジットカード会社・金融庁・消費者庁は、フィッシング詐欺対策として「カード会社からのメールに記載された URL は安易にクリックしないでください」「カード情報の更新を求めるメールは公式アプリ・公式サイトから直接アクセスして確認してください」と継続的に啓発しています。これは消費者保護の観点では正しい啓発ですが、加盟店からの正規のカード更新案内メールにとっては、構造的にクリック率を下げる要因になります。
業界の参考値レベルでは、ここ数年で次のような変化が観察されると言われます（参考値）。
- カード更新案内メールのクリック率: 従来 15〜25%（参考値） 程度だったものが、近年は 3〜8%（参考値） に低下しているケースが見られる。
- 最終的なカード更新成立率: 従来 10〜15%（参考値） 程度だったものが、近年は 1〜3%（参考値） に低下しているケースが見られる。
これは加盟店側のメール文面の問題というより、「カード情報の更新を求めるメールのリンクをクリックすべきでない」というメッセージが社会全体に浸透した結果として、正規の案内であっても顧客側で警戒される、という構造的な変化です。件名・本文の改善や A/B テストである程度の改善は見込めますが、従来水準への完全な回復は難しい、というのが現場感覚に近いと思われます。
結果として、AU でカバーされず・加盟店側の案内メールでもリーチしきれない顧客が、月次で一定数残ります。この層に対しては、メール一斉送信ではなく、CS（カスタマーサポート）側で個別に案内する 運用が必要になります。
整った状態 — AU 後に残ったカード更新候補を 5 分類で抽出する
ここまでの整理を踏まえると、カード期限切れ対応が整っている状態は次のような形になります。
- AU でカバーされた顧客には案内を送らない: 決済代行会社の Webhook・更新イベントを参照し、AU で有効期限が書き換わった顧客は案内対象から外す。
- AU 後に残った顧客を抽出する: 60〜90 日以内に期限切れ予定 / 期限切れ後の決済エラー発生済み / リトライ後も復旧していない、といった条件で「加盟店側の案内が必要な顧客」をリスト化する。
- 5 分類でアクション粒度を分ける: 期限 60 日前の事前案内対象 / 期限 30 日前の本通知対象 / 期限直前 1 週間のリマインド対象 / 期限切れ後のエラー発生対象 / メール反応なしの CS 個別案内対象、の 5 段階に分けて、それぞれに合った文面・チャネルを設計する。
- 顧客連絡文面は AI 下書きで負荷を下げる: 5 分類それぞれに対応した文面ドラフトを AI が下書き生成し、{お客様名}・{カード末尾 4 桁}・{次回課金日} 等のプレースホルダのまま提示する。最終的な送信判断は CS が行う（シナリオ別の文面例は決済エラー後の顧客連絡テンプレ集を参照）。
- 結果を月次で振り返る: AU で更新された件数 / 案内メールで更新された件数 / CS 個別案内で更新された件数 / 最終的に止まった件数を分けて KPI 化する。
この設計の出発点は 「AU でどこまでカバーできており、AU 後に何件残るか」を月次で把握できている状態 です。AU を否定するのではなく、AU が拾いきれない後段を埋める、という発想でフローを組むのが現実的です。
Recovery Monitor の役割 — AU の補完ポジション
Recovery Monitor は、AI Orchestra の Payment Intelligence 領域における入口商品で、決済エラー管理（Payment Error Management）のレイヤーを担います。Account Updater との関係で整理すると、以下のポジションです。
Recovery Monitor が "行う" こと
- AU 後に残る決済エラーの分類: 決済代行会社のリトライ・AU 自動更新を経た後に残った決済エラーを、5 つの対応カテゴリ（再試行候補・カード更新候補・顧客対応候補・認証確認候補・リトライ非推奨）に分類して提示。
- カード更新候補の細分化: 期限 60 日前・30 日前・直前 1 週間・期限切れ後・メール反応なしの段階に分けて、CS が個別案内すべき対象を抽出。
- 顧客連絡文面のドラフト生成: AU 後に残った顧客向けの文面を AI 補助で下書き。プレースホルダのまま提示し、送信判断は事業者様。
- 月次レポート: AU でカバーされた件数 / AU 後に残った件数 / 案内メールで戻せた件数 / 最終的に止まった件数を、月次で整理。
Recovery Monitor が "行わない" こと
- 新規の課金実行・再課金は 行いません（決済代行会社の領域）。
- Account Updater との競合・代替は 意図しません（AU は決済代行会社経由で引き続き利用していただく前提）。
- 顧客への案内メールの自動送信・自動リトライは 行いません。AI は分類とドラフト生成の補助のみを担当し、最終的な送信判断は事業者様側に残します（Rule-first, AI-assisted）。
- カード番号・有効期限の取得・推定は 行いません。読み取り専用（Read-only）で決済データを受け取り、分類結果と文面ドラフトのみを出力します。
「AU は入れている。それでも月次で発生する期限切れ系のエラーをどう減らすか」 — Recovery Monitor が想定している立ち位置は、まさにこの後段です。AU を否定するのではなく、AU が構造的に拾えない母集団に対する加盟店側の運用を、月次フローに組み込みやすい形で支援します。
まず自社の数字を試算する
本記事のレンジ値はあくまで業界参考値です。自社の AU カバー率・AU 後に残る件数・案内メール後の更新成立率は、過去 3〜6 ヶ月の決済データから推定するのが最短です。
提案は 2 つです。
第一に、自社の月次決済エラーのうち、期限切れ系がどれくらいか・AU 後に残っているのがどの規模か を試算してください。推定損失額の試算ページ に月間決済件数・エラー率・平均単価・LTV を入力すれば、年率の受動的チャーン金額の概算が出ます。
第二に、概算を見たうえで「実データで AU 後の残りを分類する価値がある」と判断された場合は、30 日間無料トライアル で Recovery Monitor の分類結果を実データで確認してください。Stripe Checkout 経由でカード登録のうえお試しいただけます（30 日間は無料・期間中の解約で課金は発生せず、31 日目から Starter ¥19,800/月が自動課金）。トライアル中は上位プラン相当の機能（経営向け月次 AI レポート・運用改善提案など）を解放するため、AU カバー率の現実と AU 後の残り規模を、自社データで確認できます。
「Account Updater 入れているから大丈夫」 — この前提を一度疑い、AU でカバーされた件数と、AU 後に残っている件数を分けて把握するところから、カード期限切れ対応の運用設計を組み直すきっかけにしていただければ幸いです。