ChatGPTで作った社内ツール、3か月後に誰が直しますか？現役SEが見た「止まる設計」7つ

動いた。

社内でも使えた。

その3か月後、誰も直せなくなった。

ChatGPTで社内ツールを作るとき、本当に怖いのは「完成しないこと」ではありません。

一度は完成したように見えることです。

画面が開く。ボタンも押せる。データも登録できる。

ここまで来ると、だいたい安心します。

はい。

私も安心したくなります。

ただ、現役SEとして業務ツールの開発や修正を続けていると、止まるツールにはかなり似た匂いがあるんですよね。

最初は速いのに、数時間動かすと画面が重くなる。

再起動したのに「処理中」のまま戻らない。

2つ目のアカウントを追加した瞬間、データが重複する。

担当者のPCでは動くのに、別の人のPCでは動かない。

見た目は別々の不具合です。

でも、根っこは同じです。

「今動くこと」だけを見て、「止まった後」を作っていません。

ココナラで販売実績234件、SEとして15年ほど業務システムを見てきましたが、修正依頼で多いのは派手な新機能ではありません。

止まった。

遅くなった。

引き継げない。

前の人に聞けない。

この4つです。

今回は、ChatGPTで作った社内ツールが3か月後に止まりやすい設計を、実際に遭遇したパターンから7つに分けます。

■ 画面だけが元気な無言ツール

最初に見るのはログです。

エラーが出たときに、どの処理で、どのデータを使い、どこまで進んだのか。

これが残っていないと、修正する側はほぼ目隠しです。

「ボタンを押したら止まりました」

利用者としては、それしか言えません。

当然です。悪くありません。

ただ、開発側にログがないと、同じ操作を何度も再現し、たまたまエラーが出る瞬間を待つことになります。

クッッッソ地味です。

でも、この地味さで調査時間が決まります。

最低限、次の情報は残したほうがいいです。

・処理の開始時刻と終了時刻

・利用者または対象アカウント

・対象データの識別情報

・成功、失敗、再実行の状態

・エラー内容

・外部サービスへ送った結果

画面に「エラーが発生しました」と出すだけでは足りません。

それは利用者向けの説明であって、修理する人向けの情報ではないからです。

■ 再起動しても終わらない処理中

長い処理を持つツールでは、「実行中」という状態をデータベースへ保存することがあります。

ここまでは普通です。

問題は、途中でアプリが落ちた場合です。

処理はもう動いていない。

でも、データベースには実行中が残っている。

画面は二重実行を防ぐため、新しい処理を開始させない。

結果、再起動してもずっと処理中です。

実際、相場取得や大量データ収集のような処理では、この状態管理が甘いと簡単に詰まります。

対策は「実行中かどうか」だけではありません。

・開始時刻

・最終更新時刻

・担当ワーカー

・処理件数

・失敗理由

・再開可能な位置

・一定時間更新がなければ異常終了とみなす条件

ここまで持たせます。

人間でも、朝から席にいない人のPCに「作業中」と貼ってあったら困りますよね。

システムでも同じです。

■ 全部を一人で抱える巨大処理

情報収集、判定、保存、通知。

これを1つの処理で順番に実行すると、最初は分かりやすいです。

ただし、情報収集が遅れたら判定も止まります。

判定先が落ちたら通知も止まります。

通知に失敗しただけなのに、最初から全部やり直します。

私は実際に、全国のデータをキーワードごとに回収する処理で、7時間近く動かしても全体が終わらないケースを見ています。

対象が少ないうちは動きます。

増えた瞬間に終わります。

はい。終わるのは処理ではなく、こちらの心です。

こういう場合は、役割を分けます。

・データを集める処理

・未処理データを判定する処理

・通知対象を送る処理

データベースやキューを間に置き、前の処理が少し遅れても、後ろが完全停止しない形にします。

ChatGPTは一気に動くコードを出すのが得意です。

運用で詰まりにくい分割は、こちらから要求しないと抜けやすい部分です。

■ 速く見せるために不安を増やす画面

性能改善でよくあるのが、「先に画面だけ出して、データを後から読み込む」方法です。

Webサービスでは普通に使われます。

ただ、業務ツールでは利用者が嫌がることがあります。

一覧の一部だけ先に出る。

あとから件数が増える。

読み込み中に操作できてしまう。

保存したのか、まだ処理中なのか分からない。

実際の改善相談でも、「途中まで表示されるより、全部読めてから見せてほしい」という要望はあります。

技術的に速いことと、利用者が速いと感じることは別です。

業務ツールでは、待ち時間が少し長くても、

・処理中であることが分かる

・何を待っているか分かる

・完了するまで誤操作できない

・表示後は内容が変わらない

このほうが安心されます。

数字だけ追って画面表示を0.5秒縮めても、利用者が毎回「これ全部？」と確認していたら負けです。

■ 2人目で壊れる一意キー

1つのアカウントで試している間は正常。

2つ目のアカウントを追加したら、登録済み扱いになる。

これも実際に起きやすいです。

たとえば、日付だけをデータの識別子にしていた場合です。

1つ目のアカウントで7月21日のデータを登録する。

2つ目のアカウントでも7月21日のデータを登録する。

システムから見ると、同じ日付です。

重複エラーになります。

本来は、アカウントと日付の組み合わせで識別すべきでした。

開発初期は1人、1店舗、1現場で試すことが多いです。

だから気づきません。

利用者が増える前に、次の条件を考えます。

・複数アカウント

・複数拠点

・同じ名前の現場

・同じ日に複数回登録

・過去データの再取込

・削除後の再登録

「今のサンプルで重複しない」は、重複対策ではありません。

■ 日本で使うのに日本時間ではない時計

サーバーはUTC、利用者は日本時間。

この違いも地味に刺さります。

画面上では7月21日なのに、保存データは7月20日。

深夜に登録したものだけ前日扱い。

通知時刻が9時間ずれる。

テストを昼間にしていると、なかなか気づきません。

さらに厄介なのは、一部だけ日本時間へ変換されている状態です。

画面は日本時間。

ログはUTC。

検索条件は日本時間。

データベースは時刻情報なし。

こうなると、調査する人の頭が先に落ちます。

時刻は最初に決めます。

・保存時刻の基準

・画面表示の基準

・日付検索の境界

・定期実行のタイムゾーン

・ログへ出すタイムゾーン

「日本で使うから日本時間だろう」は、システムには通じません。

■ 作った本人しか知らない完成条件

最後が一番大きいです。

ChatGPTとの会話には、要望や修正経緯が残っています。

ただし、その会話を見ないと分からない設計は、引き継げません。

どのExcelが最新版か。

どの計算式を正とするのか。

どのボタンは未実装なのか。

エラー時に再実行してよいのか。

外部サービスが止まった場合はどうするのか。

この情報がコードの外にないと、次の担当者は推測で直します。

推測で直したシステムは、だいたい別の場所が壊れます。

モグラたたき開発の開幕です。

最低限、次の4つは残してください。

・現在の機能一覧

・未対応事項

・設定方法と実行方法

・正常と判断するテスト手順

立派な設計書でなくても構いません。

README、Excel、テキストでもいいです。

大事なのは、作った本人がいなくても「何が正しいか」を判断できることです。

■ ChatGPT製だから止まるわけではありません

ここまで読むと、「やっぱりChatGPTで作るのは危ない」と感じるかもしれません。

違います。

ChatGPT、Claude Code、Cursorを使っても、運用を考えて作れば使えます。

私自身、開発や調査、コードレビューで日常的に使っています。

問題は、コードを出したところをゴールにすることです。

社内ツールの完成は、ボタンが動いた日ではありません。

止まったときに原因が分かる。

データが増えても処理できる。

再起動後に戻れる。

別の人が修正できる。

利用者が迷わない。

ここまで来て、やっと業務で使える状態です。

あなたは今ここまで読んでますよね？

頭の中に、少し気になるツールが1つくらい浮かんでいると思います。

そのツール、今すぐ作り直す必要はありません。

まずはログ、状態管理、バックアップ、テスト手順の4つだけ確認してください。

すでに途中まで作ったツールでも、現在のソース、画面、エラー内容、元になったExcelがあれば、修正範囲を整理できます。

新規開発より、止まらない形への修正のほうが効果が大きいこともあります。

「動いてはいるけど、このまま業務で使っていいか不安」

「ChatGPTで作ったが、エラーの直し方が分からない」

「前の担当者から引き継げていない」

この段階でも大丈夫です。

今の状態から、直す順番を一緒に整理します。

ご相談はこちら

https://coconala.com/users/5379632