街づくり12日目・第二章｜KOGAMAI Payを安全に試す
2026年8月26日、街づくり12日目・第二章。
KOGAMAI Payは、見た目だけの銀行アプリではありません。円残高、明細、口座の切替、個人間送金を、同じ台帳とserver authorityから読める入口です。便利さを増やすほど、二重送信や途中失敗を「たまたま起きない」に任せない設計が必要になります。
画面より先に台帳を守る
clientやPhoneは、送金の成功や残高を自分で決めません。serverが認証済みのactor、送金先、金額、intentの状態を検証し、同じ要求が届いても一つの結果へ収束させます。二重送信、timeout、再接続は正常系とは別の必須testです。
P2P送金を試すswitchも、請求、燃料、素材、craft、医療などの別domainをまとめて有効にしません。小さな機能だけを開き、関係のないmutationが増えていないことを先に確かめます。
DB変更の前に戻れることを証明する
金融migrationの前には、live DBを変更しないsnapshotを作り、read-backしたdumpをnetworklessな一時MariaDBへisolated restoreします。source DBの前後digestが一致し、一時targetがcleanupされたときだけ次のgateへ進めます。
migrationはappend-onlyとし、既存行や既存migrationの置換を許しません。snapshotがあるだけでは十分ではなく、復元できること、対象releaseとledger markerが一致することまでを証拠にします。
未決定は使えない状態にする
claim、債務回収、providerごとの料金など、仕様が確定していない部分は推測で有効にしません。readinessが欠けるときはfail closedにし、UIも「成功したように見える」表示を避けます。
現在のKOGAMAI PayはDEVで段階的に確かめる実験です。code、contract、failure-first testを揃えることと、実際のDEVで残高や送金を確認することは別の証拠です。productionへの昇格は、この技術記事やcode mergeだけでは行いません。