リリース後にシステムが止まる会社の共通点
リリースはゴールではなく、運用のスタートである。
この記事の結論
- リリース後に止まる会社の共通点は、監視・ログ・問い合わせ導線・保守担当者・例外処理 の 5 領域の設計不足です。
- 「動いている」と「運用されている」は別物。動いていても、通知が誰にも届かない、原因が追えない、改修できない 状態は止まる前兆。
- リリース日に最低限揃えるべき運用設計があります: Sentry 通知・外部 API 失敗検知・バッチ失敗・問い合わせ窓口・Runbook。
- 運用設計は 発注前から決めておく ことが安全です。「リリース後に決める」では遅すぎます。
- 月の保守予算は 開発予算の 15〜25% を目安に確保するのが現実的です。
「システムをリリースしたんですが、運用で困っていて……」
リリース後 1〜3 ヶ月のタイミングで、min's に届く相談の典型パターンです。「障害が起きても原因が分からない」「顧客から問い合わせが来ても答えられない」「軽微改修ができる人がいない」。
これらは、リリース後の運用設計が、開発時に組み込まれていなかった ことが原因です。「動くシステム」を作ることと、「運用されるシステム」にすることは、別の設計です。
この記事では、リリース後に止まる会社の共通点と、運用に強い設計の最小セットを整理します。
共通点 1: 監視がない
リリースして 1 週間、エラーログが Sentry にも Slack にも流れていない。気づくのは顧客からの「動きません」という連絡。
起きること
- 障害発生から検知まで数時間〜数日のタイムラグ
- 顧客に指摘されるまで気づけない
- 影響範囲が広がってから対応開始
最低限の対策
- Sentry / Datadog / Bugsnag などのエラー監視
- エラー発生時に開発者・運用担当者の Slack に通知
- 主要 API の応答時間とエラー率を監視
- 24h 稼働サービスなら、夜間障害の通知設計
OpenAI のワークスペースエージェントの設計でも、監視と統制 が運用の前提に組み込まれています (Introducing workspace agents in ChatGPT / OpenAI)。AI でない普通のシステムでも、監視は同じく前提です。
共通点 2: ログが追えない
障害が起きたが、何が原因か追えない。バックアップから戻すしかない状態。
起きること
- 「現象を見て勘で直す」状態が固定化
- 同じ障害が何度も再発
- 顧客からの「データが消えました」の問い合わせに答えられない
最低限の対策
- アプリケーションログを集約 (CloudWatch, Datadog, Better Stack)
- 重要操作の監査ログを別テーブルに保存
- 外部 API への送信・受信ログ
- バッチ実行履歴と結果
- ログ保存期間と削除ポリシーの定義
「ログがある」だけでなく、「いつでも検索できる」「30 日分は遡れる」 状態にすることが重要です。
共通点 3: 問い合わせ導線がない
顧客が困っても、どこに連絡したらいいか分からない。SNS で愚痴を投稿される、別の経路 (本社代表電話) に来る。
起きること
- サービス上での問い合わせ受付がない
- 営業時間外の対応経路がない
- 問い合わせの種類別の振り分けがない
- 担当者が不在時のエスカレーションフローがない
最低限の対策
- サービス内に「お問い合わせ」リンクを必ず置く
- LINE / Intercom / Help Scout / メールのいずれかで受付経路を用意
- 問い合わせ受信時に Slack に通知
- 営業時間外の自動応答 (「翌営業日に回答します」)
- 緊急時の連絡経路 (BtoB なら担当営業の電話)
共通点 4: 保守担当者が決まっていない
リリースで開発会社の関与が終わり、内製チームもいない。軽微な改修ができない状態。
起きること
- 文言修正、新規ユーザー追加すら依頼できない
- 開発会社に毎回見積もりを取らないと動けない
- 緊急時に対応できる人がいない
- 内製チームへの引き継ぎが進まない
最低限の対策
- リリース前に 保守体制を契約で決める (月額固定、時間単価、スポット)
- 月の保守時間の目安 (例: 月 30 時間)
- 緊急時の対応経路 (営業時間外、深夜)
- ドキュメントの引き継ぎ (Runbook、運用マニュアル)
- 内製化計画 (将来的に内製したい場合)
OpenAI が AWS との提携で強調しているのも、エンタープライズで AI を運用するには 既存のセキュリティ・コンプライアンス・ガバナンス・調達 のワークフローに乗ることが鍵だ、というポイントです (OpenAI frontier models and Codex on AWS / OpenAI)。AI でないシステムでも、運用組織との整合が運用の前提です。
共通点 5: 例外処理が設計されていない
ハッピーパスは動くが、例外で止まる。顧客の特殊対応はシステム外で処理されている。
起きること
- 標準フローから外れた処理が手作業
- Excel と LINE と紙で処理する例外が増える
- システムと現実の業務がズレていく
- 担当者の頭の中にしか情報がない
最低限の対策
- 設計時に「いま、システム外でやっている例外」を吐き出すヒアリングを実施
- 自由記述メモ機能 (どんな業務でも残せる)
- 例外承認フロー (上長承認で逸脱を記録)
- 特殊対応の履歴を残せる仕組み
ここまでで「自社のシステムも当てはまるかも」と感じたら、運用改善の診断から相談するのが現実的です。
運用に耐える設計のチェックリスト
リリース前 / リリース後すぐにチェックする項目です。
| 項目 | 確認すること |
|---|---|
| エラー監視 | Sentry 等で本番エラーが Slack に届くか |
| アプリログ | 30 日分が検索可能な状態で保存されるか |
| 監査ログ | 金銭・個人情報・契約変更が履歴に残るか |
| 外部 API 監視 | 失敗時に通知が来るか |
| バッチ監視 | 失敗時に通知が来るか |
| 問い合わせ窓口 | サービス内に明示されているか |
| エスカレーション | 担当者不在時の経路 |
| 保守体制 | 月額契約 or 内製 or 両方 |
| Runbook | 障害時の対応手順 |
| 例外フロー | 自由記述・例外承認・特殊対応 |
8 個以上欠けている場合、リリース 1〜3 ヶ月以内に大きな問題が起きる可能性が高いです。
保守費用の目安
「月いくら確保すべきか」の目安:
| 規模 | 月の保守費用 |
|---|---|
| 小規模 SaaS (利用者 100 人以下) | 月 10〜30 万円 |
| 中規模 SaaS (利用者 1,000 人) | 月 30〜80 万円 |
| 大規模 SaaS / 業務システム | 月 80〜200 万円 |
開発予算の 15〜25% が月の保守予算の目安です。詳しくは 業務システムの保守費用はなぜ発生するのか で展開しています。
運用設計はいつ決めるか
「リリース後に運用設計を決める」は、ほぼ確実に失敗します。発注前 から、以下を決めておきます。
- リリース後の不具合の窓口は誰か
- 営業時間外の障害対応はどうするか
- 軽微改修の対応経路と料金
- ドキュメント (Runbook、運用マニュアル) の引き渡し範囲
- 内製化計画の有無
詳しくは AI 時代の開発外注ガイド で発注前 7 項目の中の「運用責任」として整理しています。
min's の運用改善支援
min's では、既にリリース済みのシステムの運用改善を以下の形で支援しています。
Phase 1: 診断 (1〜2 週間)
- 既存システムの監視・ログ・保守体制の評価
- 改善優先順位の整理
- 運用 Runbook の整備状況確認
- 費用 50〜100 万円
Phase 2: 改善 (2〜4 週間)
- 監視・通知の整備 (Sentry / Datadog)
- ログ集約とダッシュボード
- 問い合わせ導線の設計
- Runbook 作成
- 費用 100〜300 万円
Phase 3: 継続並走 (月単位)
- 月次の運用レビュー
- 軽微改修
- 障害対応のスポット支援
- 費用 月 30〜100 万円
システムの運用改善を相談したい方へ
min's では、リリース済みシステムの運用改善診断、監視・通知の整備、保守体制の設計、改善並走を支援しています。
以下のような状態であれば、ご相談ください。
-
リリース後、障害が頻発している
-
顧客からの問い合わせに対応できない
-
開発会社と連絡が取りにくくなった
-
軽微改修ができる人がいない
-
内製化したいが移行できない
次に読む記事
参考
- Introducing workspace agents in ChatGPT / OpenAI — 監視と統制を組み込んだエージェント運用
- OpenAI frontier models and Codex on AWS / OpenAI — エンタープライズ運用におけるガバナンス・調達フロー