Chapter 2で作ったWebシステムが自分のパソコンで動いたら、次はいよいよ公開です。しかし、公開は開発のゴールではありません。お店にたとえると、開店してお客様を迎え始める日です。
公開後は、利用者の入力を受け取り、個人情報を扱い、外部サービスと通信します。止まったときの連絡や復旧も必要です。そこで大切になるのが、戻せる・気づける・直せるという三つの準備です。
公開前に「元へ戻せる状態」を作る
Webシステムの更新では、正しいと思った変更が別の機能へ影響することがあります。公開前に、何を変更したか、どの状態を公開したか、問題が出たらどこへ戻すかを決めておきます。
GitとGitHubは変更の履歴書
Gitは、ファイルの変更履歴を残す仕組みです。GitHubなどの保管場所と組み合わせると、いつ、何を、なぜ変えたかをチームで確認しやすくなります。
公開する状態には番号や名前を付けます。たとえば「2026年8月版」「v1.2」のように記録しておけば、問題が発生したときに、直前の安定した状態を探せます。
ただし、Gitが保存するのは主にプログラムや設定の履歴です。予約情報、問い合わせ内容、アップロードされた画像など、運用中に増えるデータのバックアップとは別物です。
バックアップは「戻せるか」まで試す
バックアップを作っただけでは安心できません。必要なときに読み出せなければ役に立たないからです。
- 何を保存するか
- どのくらいの間隔で保存するか
- 何世代残すか
- 誰が復元するか
- 復元に何分・何時間かかるか
- 復元後に何を確認するか
この六つを決め、架空データを使って一度は復元を試します。
開発用と公開用を分ける
公開前の試運転場所と、お客様が使う本番環境は分けます。飲食店でいえば、調理練習をする厨房と、お客様へ料理を出す営業中の厨房を混ぜない考え方です。
公開先となるホスティング、ドメイン、通信を暗号化するHTTPSを準備します。さらに、テスト用と本番用でデータベースや外部サービスの接続先を分けると、試験操作が本物のデータへ影響する事故を減らせます。
公開作業は、思いつきでファイルを置き換えるのではなく、次の順番を固定します。
- 変更内容を確定する
- 自動テストと人の確認を行う
- バックアップと戻し先を確認する
- 公開を実行する
- 主要な操作をもう一度試す
- エラーと利用状況を確認する
APIキーやパスワードをコードへ書かない
APIキー、データベースのパスワード、外部サービスの認証情報は、家や金庫の鍵にあたります。プログラム本体、GitHubへ保存するファイル、AIへの指示、画面画像、ログへ直接書かないようにします。
ホスティングサービスの秘密情報設定や、Google CloudのSecret Managerのような専用の保管機能を使い、必要なシステムだけが読み取れるようにします。開発用と本番用の値を分け、権限は必要最小限にします。
環境変数へ入れれば必ず安全、というわけでもありません。誤ったデバッグ設定やログ出力によって表示される可能性があるため、重要度に合わせて専用の秘密管理機能を選びます。
もし秘密情報が漏れた疑いがある場合は、表示を消すだけでは不十分です。古い鍵を無効にして新しく発行し、利用履歴を確認します。
利用者の入力と権限を二重に確認する
公開された入力欄には、空欄、長すぎる文章、想定外の形式、不正な命令など、さまざまな値が届きます。ブラウザの表示だけでなく、サーバー側でも形式、長さ、範囲、業務上の条件を確認します。
また、「ログインできること」と「その情報を見たり変更したりできること」は別です。社員としてログインできても、全顧客の情報や管理設定まで見られる必要はありません。
- 初期状態では許可しない
- 操作ごとに権限を確認する
- 管理者を必要以上に増やさない
- 退職や担当変更時に権限を外す
- 権限のない操作が本当に止まるか試す
個人情報は、集める項目、利用目的、保存期間、閲覧できる人、削除方法まで決めます。「将来使うかもしれない」という理由だけで集めすぎないことも大切です。
公開前チェックは正常時だけで終わらせない
公開前には、うまく動く場合だけでなく、失敗する場合も確認します。
| 確認する場面 | 主なチェック |
|---|---|
| 通常利用 | 表示、入力、保存、検索、通知が正しく動く |
| 誤入力 | 保存を止め、直し方を分かりやすく伝える |
| 権限外 | 他人の情報や管理機能を見たり変更したりできない |
| 外部サービス停止 | 画面全体が固まらず、再試行や連絡方法を示す |
| 更新失敗 | 安定版へ戻し、データの整合性を確認できる |
| スマートフォン | 文字、ボタン、入力欄が操作しやすい |
AIエージェントは、変更箇所の整理、テスト項目の作成、決められたテストの実行、結果の要約を支援できます。ただし、本番へ公開してよいか、利用者や事業への影響を許容できるかは、人が確認して決めます。
公開後は「気づける仕組み」を用意する
システムが止まっていても、誰も気づかなければ復旧を始められません。ログ、監視、通知を用意します。
ログは仕事の足あと
ログには、いつ、どの機能で、何が起き、成功したか失敗したかを記録します。入力エラー、ログイン失敗、権限外の操作、外部サービスとの通信失敗、システムエラーなどが調査の手掛かりになります。
一方で、パスワード、APIキー、決済情報、不要な個人情報を記録してはいけません。ログそのものにも閲覧権限と保存期間が必要です。
監視は「重要な仕事が完了するか」を見る
トップページが表示されるだけでは、予約や問い合わせが完了できるとは限りません。次のような事業上重要な状態を見ます。
- Webシステムが応答しているか
- エラーが急に増えていないか
- 表示が極端に遅くなっていないか
- 予約や問い合わせの完了件数が急にゼロになっていないか
- データベースや外部APIへ接続できているか
異常時の通知先を決め、夜間や休日にどこまで対応するかも現実的に決めます。すべての小さな変化を通知すると重要な警告が埋もれるため、事業への影響が大きいものから始めます。
障害時は順番を決めて動く
問題が起きてから対応方法を考えると、焦って被害を広げることがあります。最低限、次の順番を文書にします。
- 止める：危険な機能や新しい公開を一時停止する
- 知らせる：担当者と責任者へ連絡する
- 残す：時刻、症状、変更内容、ログを保存する
- 範囲を調べる：利用者、データ、機能への影響を確認する
- 安全な状態へ戻す：直前の安定版やバックアップから復旧する
- 鍵を交換する：漏えいの疑いがある秘密情報を無効化・再発行する
- 確認して再開する：主要機能と安全性を人が確認する
- 再発を防ぐ：原因、対応、改善項目を記録する
個人情報の漏えい、決済、契約、健康・採用など影響の大きい情報が関係する場合は、自社だけで判断せず、契約先や法務・セキュリティの専門家へ早めに相談します。
費用と保守を毎月の仕事にする
Webシステムには、サーバー、データベース、保存容量、メール、API、監視などの費用がかかります。利用量に応じて増えるサービスでは、予算と通知を設定し、急な増加を確認できるようにします。
保守では、次の項目を定期的に確認します。
- 利用者と管理者の権限
- APIキーなど秘密情報の更新
- 使用している部品やライブラリの更新
- ドメイン、証明書、外部サービスの契約期限
- バックアップの成功と復元テスト
- エラー、速度、費用の変化
- 利用されていない機能やデータの整理
- 問い合わせや現場の声を基にした改善
更新は一度に大きく行わず、小さく変更し、テストし、公開し、監視する流れを繰り返します。
YMWorksがWebシステムの運用まで考える理由
Webシステムは、画面を作って公開すれば終わる商品ではありません。誰が管理し、問題をどう見つけ、どの状態へ戻し、毎月何を確認するかまで含めて、事業で使える仕組みになります。
YMWorksでは、業務と要件の整理、AIを活用した試作・実装だけでなく、公開前チェック、権限や秘密情報の整理、監視、更新手順までを一つの流れとして考えます。
高度なセキュリティ監査や法的判断が必要な場合は専門家と連携しながら、事業規模と扱う情報に合った現実的な運用を整えることが重要です。
まとめ
Webシステムの公開で大切なのは、問題を一度も起こさないと約束することではありません。問題が起きる可能性を減らし、早く気づき、安全に戻し、同じ問題を繰り返さない仕組みを持つことです。
- 変更履歴と戻す状態を決める
- コードと運用データを分けてバックアップする
- 開発用と本番用を分ける
- 秘密情報をコード、AIの指示、ログへ書かない
- 入力と権限をサーバー側でも確認する
- 公開前に失敗する場面まで試す
- ログ、監視、通知で異常へ気づく
- 障害時の連絡・停止・復旧手順を決める
- 費用と保守を定期業務にする
AIは確認や改善を速くする力になります。しかし、公開の判断、権限、個人情報、事故対応の責任までAIへ預けることはできません。人が目的と基準を決め、AIを作業者として使うことが、安全な運用につながります。