開発方針を相談する

AI で作った業務システムが、リリース後に破綻する 5 パターン

リリースまでは速かったのに、運用に入った瞬間に止まる。現場で詰まる構造を 5 つに分解します。

この記事の結論

「リリースまでは順調だった。でも、運用に入ったら誰も触らなくなった」

AI で作った業務システムについて、min's に多く持ち込まれる相談がこれです。Cursor や Claude Code で数週間で立ち上がり、デモは通った。発注側も「思ったより安く速く出来た」と感じている。それなのに、半年後にはスプレッドシートに戻っている。

業務システムには、EC サイトや SaaS プロダクトとは違う「破綻の構造」があります。顧客が増えて壊れるのではなく、社内の使い手が増えて壊れる。例外パターンが現実の業務から差し込まれて壊れる。リリース時点では発覚しない問題が、運用 30 日目に表面化する。

この記事では、実際の業務 SaaS 支援の現場で見えてきた、AI で作った業務システムが運用で詰まる 5 つの典型パターンを取り上げます。すでに動いているシステムをお持ちの方は、自社の状態と照らし合わせるチェックリストとしても使えるはずです。

なぜ「AI で作ったから」ではないのか

最初に整理しておくと、業務システムが運用で壊れるのは「AI が書いたから」が原因ではありません。業務運用の前提が決まる前に、実装が走った ことが原因です。

AI で作ろうが、ベテランエンジニアが作ろうが、業務知識が不足したまま着手した業務システムは同じように壊れます。違いは、AI で作ると 「動くもの」までが速いので、壊れる前に運用に入ってしまう こと。

ここから紹介する 5 パターンは、Vibe Coding 案件・社内 DX 案件・SaaS 開発案件、すべてに共通して見られるものです。

パターン 1: ステータスを増やし続けて、誰も全体を把握できなくなる

業務システムを作り始めたとき、最初は 未着手 / 対応中 / 完了 の 3 ステータスで十分です。半年運用すると、次のような追加が入ってきます。

気づくと 12 個のステータスがあり、それぞれに「次に取れる遷移」のルールが付随しています。AI に「このステータスのときはこう動かして」と頼んで実装が進むので、状態は増えやすい。一方で 「全体としてどう動くのか」を一望できる人が、社内にいなくなる。

修正のたびに別のステータス遷移が壊れ、テストも書きにくく、最終的に「触らない」が結論になります。

事業上の被害: キャンセル済みなのに請求される、完了済みなのにステータスが残る、といった現場の混乱と、月次集計のズレが同時に起きます。

手当て: 台帳 + 状態派生に切り替える

「現在のステータス」を 1 つのフィールドで持つのをやめます。代わりに 発生したイベントを append-only で記録し、現在の状態はそこから計算する 設計に切り替えます。

この設計だと、ステータスが増えても 既存のイベントは変更されない ので、過去の集計や履歴が壊れにくくなります。請求や予約のように「お金や約束」が動く業務では、最初からこのモデルにしておいた方が、長期的には楽です。

パターン 2: 集計・締め・請求のロジックが画面ごとに散らばる

業務システムを使い始めると、必ず「集計」が出てきます。

それぞれの画面で、それぞれのエンジニアが、それぞれの集計ロジックを書く、というのが破綻の典型パターンです。値引き、税の丸め、為替の扱い、返金の扱い、解約のタイミング、無料期間の数え方が、画面ごとに微妙にズレている。発覚するのは、たいてい月初の経理締めです。「請求書の合計と、ダッシュボードの売上が、合わない」。

AI を使うと、この種の集計ロジックが 特に増えやすい 傾向があります。画面ごとに必要な集計をプロンプトで指示するので、独立に書かれてしまう。

事業上の被害: 請求書、管理画面、CSV で数字が合わず、月次締めが止まります。経理から問い合わせが続き、運用工数が膨らみます。

手当て: ドメイン層に「数字の責任」を集約する

数字を扱うロジックは、画面側ではなく、ドメイン層 (services / domain / use-cases) に 1 箇所 にまとめます。画面からは「結果」だけを受け取る設計に変える。

これは AI に頼む前に 人間が「数字の単一の真実」を、どこに置くかを決める 仕事です。決まっていれば、AI に書かせても破綻しません。

パターン 3: 権限・テナント分離があとから雑にかかる

「最初は自社内だけで使う」と決めて、認証・権限を簡略化して作ったシステムは、3 ヶ月後に「他の会社にも使ってもらいたい」「複数拠点で運用したい」という要望が出てくることが多くあります。

このタイミングで権限を後付けすると、既存の画面ロジックに if 文が増殖していきます。「店舗担当には XX を見せない」「経理は金額だけ見える」「親会社は全拠点を集計できる」。半年後には、誰が何を見られるかが、コードを全部読まないと分からなくなります。

最も避けたいのは、SELECT * FROM 注文 WHERE 店舗 ID = ? をうっかり書き忘れた画面が 1 枚あって、他社のデータが見えてしまう ケース。テストでは気づきません。本番のお客さんが気づきます。

事業上の被害: 最悪の場合、他社データの閲覧や情報漏えいにつながり、SLA・契約違反の損害賠償リスクが発生します。

手当て: データアクセス層で強制的に絞る

権限の境界は、画面で出し分けるのではなく、データを取得する瞬間に強制される仕組み に組み込みます。

OpenAI のワークスペースエージェントは、「組織が定めた権限の範囲内でのみ動作する」設計が前提とされています (Introducing workspace agents in ChatGPT / OpenAI)。AI で動く社内業務システムを作るときも、同じ原則は人間用の業務システムにも当てはまる と考えた方が、長期的には安全です。

権限を「あとからかける」コストは、初期から組み込むより大きくなる、というのが現場の感覚です。新規実装ではなく、既存実装全体の再点検に近い作業として扱います。

パターン 4: ログ・履歴がなく、不具合のたびに勘で直すしかない

「いつ、誰が、何を、どの値からどの値に変えたか」が残っていない業務システムは、不具合対応で詰まりやすくなります。

特に、金が動く・個人情報が動く・契約状態が変わる イベントについて、履歴がないと再発防止のしようがありません。「またこの種の問い合わせが来ても、原因は特定できない」が固定化します。

AI で作ったコードベースは、この種の運用観点が落ちていることが多くあります。プロンプトで「監査ログも残して」と頼まない限り、出てきません。

事業上の被害: 顧客から問い合わせが来ても、原因を説明できません。問い合わせ対応の品質が落ち、信頼を失います。

手当て: 監査ログとイベント履歴を最初から積む

最低限、以下のイベントは、別テーブルに append-only で記録する設計にします。

実装としては、ドメインイベントを発火する仕組み (Domain Event / Outbox パターン) を 1 つ入れて、すべての状態変更をそこに通すのが現実的です。Firestore なら最新の状態とイベントログを別コレクションで持つ、SQL なら trigger または application-level の Outbox。

「監視」と「障害対応」を AI で支援する場合も、監査ログがあること が前提になります。Claude の Managed Agents では、エージェントの session を後から振り返って改善する仕組みが紹介されていますが (New in Claude Managed Agents / Anthropic)、これは振り返れる材料 (ログ・履歴) があって初めて成立します。人間の運用も同じです。

パターン 5: 手作業と例外処理が、システムの外側で増え続ける

業務システムをリリースして 1 ヶ月後、ユーザーに「使い心地はどうですか」と聞くと、こんな答えが返ってきます。

これが恐ろしいのは、「動いている」と「機能している」が、まったく違うものになっている ことです。システムに入っているデータは現実の業務の 70% にすぎず、残り 30% は Excel と LINE と担当者の頭の中で動いている。

最終的に「システムにデータを入れる」のと「Excel で処理する」のが、二重作業になり、現場のモチベーションが下がります。

事業上の被害: 二重作業で工数が増え、データの正確性が落ち、現場が「Excel に戻ろう」と判断します。投資した開発費が業務効率改善につながりません。

手当て: 例外処理を最初から「システム内」で扱える設計にする

業務システムを設計するときに、最も時間をかけるべきなのは、「例外をどう扱うか」 です。

ハッピーパスだけで設計されたシステムは、例外で破綻します。AI で実装すると、ハッピーパスを書くのが特に速いので、例外フローの検討が後回しになりがち です。

設計時に、現場のヒアリングで「いま、システム外で処理している例外」をすべて吐き出してもらう時間を取るのが、現実的な手当てです。最低限、「自由記述メモ」と「例外承認フロー (上長承認で逸脱を記録する)」の 2 つだけは、最初から入れておくことをお勧めします。

ここまで読んで、自社のシステムが複数のパターンに当てはまる場合は、運用に入ったあとで「直しながら使う」のは時間と工数が両方かかります。運用に入る前に、または運用 30 日目までに、コードと業務フローを一度、外部の目で見直すのが安全 です。

既存システムの運用改善診断を相談する →

5 つに共通する原因

5 パターンに共通するのは、「動かす」コードと「続けるための情報」を、最初から分けて設計していない ことです。

業務システムは、リリースされた瞬間から、

という変化に晒され続けます。「動くもの」を作るだけだと、これらの変化のどれか 1 つで止まります。

Anthropic がセキュリティの観点で書いている解説でも、AI でコードを扱うときのボトルネックは「発見」ではなく「検証・トリアージ・修正」に移っているとされています (Using LLMs to Secure Source Code / Anthropic)。これは業務システムの運用にもそのまま当てはまる構造で、システムが動いた後の「判断」と「修正」に、人間の時間が必要 になります。設計時に、その判断と修正をやりやすい形にしておく、というのが「続けるための情報」の意味です。

運用に耐える設計のチェックリスト

未然に防ぐためのチェックリストを、設計レビュー時に使えるよう整理します。

項目確認すること見落としたときに起きること
状態モデルステータスは増えても壊れない設計か (台帳 + 派生)キャンセル・返金・再開で履歴がズレる
集計責任数字を扱うロジックが 1 箇所にまとまっているか請求書と管理画面で数字が合わない
権限境界データアクセス層で強制される設計になっているか他社・他部門のデータが見える
監査ログ金・個人情報・契約状態の変更が履歴に残るか問い合わせ・監査に対応できない
例外フロー自由記述・例外承認・特殊対応がシステム内で扱えるか現場が Excel に戻る
外部依存連携先 SaaS が変わったとき、業務が止まらないかAPI 変更で業務が停止する
運用 Runbook障害時に誰が、何を見て、どう直すかが文書化されているか担当者不在時に復旧できない
改修フロー軽微な改修 (文言、項目追加) を、誰がどう入れるか軽微な改修が放置される

8 項目すべて揃っている必要はありません。事業フェーズに応じて、どこから揃えるかを判断します。社内 PoC なら状態モデル・権限境界・例外フローが最低ライン。複数社で本格運用するなら、すべて揃える前提で設計します。

立て直すか、作り直すかの判断は、コードを見ないと出せない

「いまの業務システム、運用で詰まっているのですが、立て直せますか」

min's へのご相談で最も多い質問です。答えは、コードと運用フローを見ないと、判断できません。一般論で言えば、

立て直しの典型的な進め方は次のとおりです。

  1. 診断 (1〜2 週間): コードベースを読み、運用フローをヒアリングし、上記 8 項目の充足度を可視化する
  2. 優先順位整理: 直さないと止まる部分、直すと運用が楽になる部分、放置していい部分を仕分け
  3. 重要部分の作り直し: 認証・権限・データモデルだけ作り直す、または集計責任を集約するなど
  4. 運用設計: 監視・通知・障害対応の経路を入れて、最低限の保守ができる状態にする
  5. 継続並走: 月単位で改善を積み上げ、現場の感覚で「使われ続ける」状態を保つ

GitHub または Vercel のアクセスを共有いただければ、診断は遠隔で進められます。動いている画面と業務フローのヒアリングは、現地で 1〜2 日いただけると精度が上がります。

既存システムの運用改善に不安がある方へ

min's では、AI で作った業務システム・社内 DX システムの運用改善、立て直し、保守設計を支援しています。

以下のような状態であれば、ご相談ください。

まずは診断 (1〜2 週間) で、改修すべき範囲と優先順位を整理します。

次に読む記事

参考

動くデモで終わらせず
本番まで持っていく開発を

AI で作りかけたもの、止まりかけている開発、新しいプロダクトの構想。 まずは現状を整理するところから、ご相談ください。

開発方針を相談する概算見積もりを依頼する