新しいAPIに替えた瞬間、古い画面は動く？更新途中の互換性を考える

Appli Parkのデプロイ手順を読むと、バックエンドを先に更新し、安定したことを待ってからフロントエンドを更新していました。完成した新旧二つの画面だけを考えていると、途中の「古い画面＋新しいAPI」を見落としそうです。更新を通せるかは、この途中の組み合わせにも左右されます。

画面とAPIは、一斉には切り替わらない

確認したワークフローは、まずバックエンドのイメージだけを替えたタスク定義を作り、サービスが安定するまで待ちます。その後、フロントエンドのイメージも替えた定義で再び更新します。 ここでいう安定待ちは、APIの全項目が古い画面と互換かを自動判定するものではありません。動かす構成が安定していることと、画面が応答を正しく読めることは分けて確認します。

項目名を変えるだけでも、古い画面は困る

ここからは架空のAPIです。旧画面は応答のtitleを表示し、新画面はdisplayNameを表示するとします。新APIでtitleを削除してdisplayNameだけを返すと、新画面は読めても旧画面は読めません。 一方、移行期間中は両方の項目を返せば、旧画面も新画面もそれぞれの項目を読めます。これはAppli Parkの記事APIを実際に変更した例ではなく、組み合わせの問題を小さくした検証用の作例です。

検証では二つの読み取り関数へ同じダミー文字列を渡し、対象項目が文字列なら表示、なければ「必要な文字列なし」としました。HTTP通信や本番の画面は動かしていません。この表だけでも、同じ機能を実装できたことと、新旧を混ぜても動くことの違いが見えます。

足してから移す。消すのは利用がなくなってから

この作例なら、まず新APIへdisplayNameを追加してtitleを残します。次に画面を新しい項目へ移し、古い項目を読む利用がなくなったことを確かめてから削除を検討します。 同名の項目が残っていても、値の型や意味、必須条件を変えれば互換性を失うことがあります。項目数だけでは判断せず、旧画面が何を期待しているかを見ます。DBの変更でも、旧アプリが動く期間に必要な列を急に消さない、という考え方につながります。

開いたままの画面も、旧版の利用者になり得る

サーバーの更新が完了しても、利用者が開いたタブには古い画面のコードが残る場合があります。キャッシュやクライアントの更新方法もあるため、「新しいサーバーが動いた時刻」と「古いAPIの利用がなくなる時刻」は同じとは限りません。 今回の順序では、旧画面が旧APIと新APIの双方で動くかが、特に確認したい組み合わせです。新画面を先に出す構成なら、必要な確認も変わります。自分の更新順序を図にして、その途中をテスト対象へ入れるところから始められます。

参照：Appli Parkのdeploy-production.ymlとローリング更新の運用記録。表は本記事用の架空のAPIによる関数実行結果です。

確認日：2026年9月22日。画面・実装・検証結果は確認時点のものです。