公開は、コードを置く前から始まる
接続先、移行順序、観測、戻し方を一緒に考え、安全な公開計画を読む。
本文の説明・図・掲載コードだけで読み進められます。出典リンクは、権限のある人向け（非公開GitHub）です。GitHubで閲覧権限がある方だけ開けます。
この記事でわかること
- アプリと DB の版・接続先を一組で確認する
- 開発完了と本番公開の判断は別に行う
- 差戻し・復元・前方修正を状況で選ぶ
この記事の目次
動いた環境と、公開する環境を分ける
架空の開発担当が「Preview で画面が開くから、そのまま公開しよう」と考えたとします。しかし、画面が参照している DB が違えば、同じビルドでも結果は変わります。新しい関数がない DB へ新しい API を出せば、画面は存在しても操作は失敗します。公開はファイルの配布だけでなく、接続先とデータの準備を合わせる作業です。
MiniBank には Preview が指定された本番 DB を向く構成を拒否するガードがあります。それでも、すべての誤設定が自動で消えるわけではありません。どのアプリ、どの DB、どの認証設定、どの migration 履歴を組み合わせるかを、公開計画で明示します。本章はその考え方を説明し、設定変更や配信の操作は実行しません。
開発の区切りを、公開の許可にしない
Development Gate は、決めた開発範囲の受け入れ条件です。統合前には別の変更との衝突や migration 順序を確認し、Preview では実認証や実際の接続を含めた挙動を確かめ、本番ではバックアップ、停止時間、利用者への影響を判断します。一段の成功が、次の段の承認まで含むわけではありません。
固定ソースにある十月三日の修復 RC 記録でも、隔離環境の検証結果と、本番への正式適用・公開が未実施であることを分けています。以前の文書にあるローカルの合格数や、過去の Preview の通過記録は、それぞれの時点の証拠です。現在公開されている版や現在の本番状態は、この教材からは断定しません。
移行の順番は、過去の件数を暗記する問題ではありません。最初の v20 文書にある構成の後にも、停止境界、digest、追加修復の変更が続いています。十月三日の記録では、既存の migration を書き換えずに修復を追加し、古い基準から修復を経て新しい機能へ進む順序を隔離環境で確認しています。公開計画では、その記録の出発点と、これから変更する DB の出発点が同じかを確かめる必要があります。空の DB へ一括適用できたことだけでは、既存データを持つ DB を途中から更新しても安全だとは分かりません。対象の版が違えば再確認が必要です。変更後も金融データを保つことと、新しい機能が動くことを、二つの受け入れ条件として持つと移行の目的が明確になります。
設定は名前より、失敗したときの意味を読む
公開 URL と公開可能なキーは、利用者として接続する入口を決めます。強い管理用の秘密や振込認証を仲介するサーバー専用の秘密は、同じ扱いではありません。秘密が不足した場合に認証を省略して動かすのではなく、処理を止める設計を読むことが大切です。設定値は教材の画面やログへ貼り付けません。
復旧後の書込世代も設定の一つです。DB が古い世代のアプリを拒否する機能は、世代の強制を有効にした場合に働きます。変数が存在するだけで常に守られている、と説明すると過大になります。古いアプリへ戻す場合にも、DB に残る停止ゲートや認証契約との互換性を確認する必要があります。
出した後は、成功画面の外側を見る
公開直後の観測は、ページが二百番台の応答を返すかだけでは足りません。依頼から金融処理、仕訳、残高、監査までがつながり、照合が一致すること、失敗時に余分な記帳がないことを確認する計画が必要です。追跡用の ID を残せば、利用者の「結果が分からない」を、個別の処理へ結び付けられます。
運用センターの黄信号も、緑色に変えること自体を目的にしません。最終修復記録では、元帳検査や日次締めの鮮度に関する AMBER を、公開直前の新しい確認に残しています。古い検査の成功と、いまの状態の正常は違います。通知や自動監視の範囲を超えて、人が何を見るかまで決める必要があります。
「前に戻す」は、一つの操作ではない
新しい画面だけに不具合があり DB が無事なら、アプリを前のビルドへ戻す選択があります。DB の追加機能は残るため、その旧アプリが現在の認証や停止条件と共存できるかを確認します。特に古いデモ認証へ戻せると考えてはいけません。データを古くしない差戻しと、DB 全体の復元は別物です。
DB をバックアップから復元すると、その後に確定した書込みを失います。すでに新しい取引が動いた後は、新しい修正を追加する前方修正や、理由を残す訂正仕訳が向く場合があります。元帳を消して過去を合わせる方法ではありません。戻しやすさは便利ですが、戻したために別の利用者の正しい取引を失う危険も見積もります。
計画を読む：三つの戻し方
判断のための擬似コードです。コマンドや自動実行手順ではありません。
画面だけの問題 → DB を保ってアプリの互換性を確認
新しい書込みの前の重大不整合 → 停止し復元の影響を判断
新しい取引が確定済み → 前方修正・専用訂正を検討
どの場合も → 照合・権限・利用者の流れを再確認復旧に必要なものは、壊れる前に外へ残す
復元後の DB だけを見て「正しい状態です」と判断すると、古いバックアップも自分自身とは一致します。そこで v17 以降は、障害前に控えた manifest の digest、版、最大の書込世代を外部記録から照合します。運用者の権限は別の外部一覧が必要です。migration 後は古い記録が合わなくなる場合があり、バックアップと同じスキーマの記録を組にします。
manifestは、復旧時に比べる状態の要約をまとめた記録です。digestは、その対象データから計算した内容照合用の値です。対象範囲や計算方法が変われば値の意味も変わるため、方式の版と組にして比べます。書込世代は、復旧をまたいで新旧の書き手を区別する番号です。これらを障害前にDBの外へ控え、復元したDBの状態と照合します。
復旧は検証、提出、別の責任者による再開へ進みますが、外部一覧が古ければ検知できない権限の巻戻りが残ります。人が記録を保ち、二人で手順を通せるかも技術の外の重要な条件です。ローカル演習の復旧時間を、本番の保証値にはできません。「公開できるか」はコードだけでなく、その条件を実際に守れるかを含めた判断です。
出典と、確認できた範囲
以下のリンクは非公開GitHubへの出典で、閲覧権限が必要です。本文はリンク先を開かなくても読める構成です。固定コード・設計資料を参照していますが、今回、この読み物のために銀行の取引やDB操作、本番試験は実行していません。実装や資料にある検査と、こちらで実施した検証を混同しないようにしています。
- Preview の接続先ガード ↗（非公開GitHub・要権限）
Preview が指定の本番 DB に接続しない防御 - 環境と設定 ↗（非公開GitHub・要権限）
接続先・書込世代・運用前提 - 統合候補の条件 ↗（非公開GitHub・要権限）
開発・統合・公開判断を区別する - 2026年10月3日の修復 RC 記録 ↗（非公開GitHub・要権限）
追加修復と最新記録時点の検証・未実施の範囲 - 現行の振込認証 API ↗（非公開GitHub・要権限）
検証済み利用者と秘密を使う限定的な認証仲介 - v17 復旧契約 ↗（非公開GitHub・要権限）
状態遷移・外部証跡・再開と書込世代の限界 - 現行の対応手順 ↗（非公開GitHub・要権限）
結果不明や照合差異ごとの案内と遷移先 - ロールバックと復旧 ↗（非公開GitHub・要権限）
アプリ差戻し・復元・前方修正の使い分け - TOTP と振込意図の設計 ↗（非公開GitHub・要権限）
新しい認証を金額・宛先・セッションへ結び付ける契約
MiniBankは学習・検証用の銀行アプリです。架空の金額や人物は、仕組みを説明するための例です。
つながる読み物
ここまで読んだ記録を、ひとつ。
自分のペースで。あとから取り消すこともできます。