12. インターネットに公開する | ミニバンクの作り方

手元で動くアプリを公開するときに、構成と秘密情報をどう扱うかを見ます。

このページでわかること

v1の設計では、Next.jsの画面とAPIをVercel、認証とPostgreSQLをSupabaseに置きます。利用者のブラウザは公開された画面へアクセスし、APIが必要な処理をサーバー側で行います。

マイグレーションの適用、動作確認、監査、エラーの調査が必要です。公開環境でデータを直接直すのではなく、履歴が残る手順で変更します。v1は学習用のため、実際の銀行サービスとして運用する前提ではありません。

新しい機能が新しい表や関数を使うなら、コードを公開する前にデータベース側を準備します。ただし古いコードがしばらく動いても問題ない形にしておくことが大切です。列を追加して切り替え、利用がなくなった後に古い列を削除するように段階を分けます。

「ローカルでは動いた」は、公開環境の設定、既存データ、権限、実行順序まで確認したことにはなりません。

開発用、検証用、公開用で接続先と秘密を分けます。公開用のサービスロールキーを開発端末へむやみに置かず、ブラウザへ渡るコードに混ぜません。デモ用OTP表示のような学習向け設定も、公開時には明示的に確認します。

設定が足りないときに、危険な既定値で動き続けるより、起動や操作を止めて原因を示す方が安全な場合があります。

画面だけを以前の版へ戻せても、データベースの変更は簡単に巻き戻せないことがあります。公開前に変更の影響を確認し、バックアップ、復旧方法、互換性のある旧版を準備します。

特に帳簿のデータは「直前の状態に戻す」だけでは、公開後に成立した取引を消しかねません。コードの戻し方と、取引データの扱いを別々に考えます。

健康確認のAPIが応答しても、送金や帳簿が正しいとは限りません。エラー率、処理時間、監査記録、照合結果を合わせて見ます。問い合わせで「送金が完了したか不明」と言われたら、リクエストIDや取引履歴から調べられることが必要です。

v1は学習用の公開構成を示します。実サービスに必要な当番体制、障害連絡、復旧訓練は別に設計する領域です。

必要な環境変数が欠けているときは、動くふりをして重要操作の途中で失敗するより、早く設定不足を検知した方が安全です。接続先、公開してよいキー、サーバーだけが読むキーを一覧にし、検証環境と公開環境で値を取り違えないようにします。

デモ用設定を公開環境へ持ち込まないことも確認項目です。

秘密のキーは「公開しない」で終わりません。誤って共有された場合に交換できるか、どこで使われているか追えるか、交換中にアプリがどう動くかを考えます。強い権限のキーほど利用範囲を絞り、ブラウザのコードやログへ出さないようにします。

学習用v1の構成を公開運用へ進めるなら、鍵の更新手順を具体化する必要があります。

障害時にコードを前の版へ戻しても、その間に成立した送金は消せません。バックアップから戻す場合も、どの時点の取引まで反映され、戻した後の取引をどう扱うかを決める必要があります。

帳簿の整合性を確かめる手順と、利用者へ状況を伝える手順まで含めて、復旧の計画になります。