業務システムの動作が遅い｜改善を頼む前に記録することと、調査・改修の分け方

業務システムが遅くなったとき、原因が分からないうちは作り直しを決めずに「どの画面が、どの条件で、何秒かかるか」を記録してください。そのうえで、まず原因を調べる作業（調査）を頼み、直す作業（改修）は調査結果を見てから頼むのが、費用を無駄にしにくい進め方です。この記事は、数年使ってきた自社の業務システムで一覧表示・検索・集計・帳票出力が遅くなり、締め日に業務が止まって困っている業務部門長・情シス担当の方に向けたものです。

遅さの原因は、端末・ネットワーク、画面の作り、プログラムの処理、データベース（以下DB）、サーバー構成の5か所に分かれます。直し方も、直すときに止める時間も、場所ごとに違います。この記事では、依頼前の記録の取り方、架空データで測った「索引で直る遅さ・直らない遅さ」の例、調査だけ頼むか改修までまとめて頼むかの分かれ目、改善目標と受入方法の書き方を順に説明します。費用の目安として、当社（AI革命）の既存システムの改修は100万円〜（税別）です。

この進め方が合う場合・合わない場合

この記事の進め方（記録 → 調査 → 改修）が合うのは、次のようなシステムです。

• 自社向けに作った業務システム（開発会社に作ってもらったもの、社内で作ったもの）で、ソースコードやDBに手を入れられる見込みがある
• 特定の画面や締め日の処理など、遅い場所がある程度しぼれている
• 機能そのものには大きな不満がなく、「遅さが直れば当面は使い続けたい」と考えている

一方、次の場合はこの記事の進め方より先に別の手を打つのが近道です。

依頼前に記録すること：遅さの記録シート

「全体的に遅い」「締め日になると重い」という伝え方では、調査する側はどこから見ればよいか決められません。調査にかかる時間が延びて、その分が費用に跳ね返ります。依頼の前に、次の項目を遅い操作ごとに1行ずつ記録してください。

記入例は次のとおりです（説明用の架空の例です）。

秒数はストップウォッチで測れば十分です。締め日と平常日の両方を測っておくと、「件数が原因か、同時利用が原因か」の見当がつきやすくなります。

記録の整理や依頼文の下書きは、ChatGPTやClaudeなどの生成AIでも進められます。ただし、本番の画面の写しに顧客名や金額が写っている場合や、ログイン情報が含まれる場合は、AIに貼り付ける前に伏せてください。

遅さの原因は5か所に分かれ、直し方と止める時間が違う

出典: PostgreSQL 公式

同じ「遅い」でも、原因の場所によって直し方も、直す作業の影響範囲も違います。

このうちDBの「索引」は、本の巻末索引のように、全件を順に読まずに目的の行を探すための仕組みです。PostgreSQLの公式ドキュメントでも、索引は検索を速くする一方、データを更新するたびに索引も更新されるため書き込みに負担がかかること、大きな表に索引を作ると時間がかかり、通常はその間の書き込みが止まることが説明されています（PostgreSQL 18 ドキュメント「インデックスの紹介」、2026-10-13確認）。

原因を調べるための設定にも注意が要ります。MySQLで遅い問い合わせを記録する機能（スロークエリログ）は、初期設定では無効で、記録の基準も初期値は10秒です（MySQL 8.4 リファレンス、2026-10-13確認）。PostgreSQLで問い合わせごとの実行時間を集計する拡張機能（pg_stat_statements）は、有効にするのにサーバーの再起動が必要です（PostgreSQL 18 ドキュメント、2026-10-13確認）。そのため、調査を始める段階でも、締め日を避けた作業時間帯を決めておく必要があります。

架空データ10万件・100万件で測った：索引で直る遅さ、直らない遅さ

「データが増えたから遅くなった。索引を足せば直る」とは限りません。これを確かめるため、架空の受注データで一覧画面の処理時間を測りました。

検証の条件（2026-10-13実施）

• データ：乱数で作った架空の受注10万件・100万件と取引先2,000社。実案件・実顧客のデータではない
• 環境：SQLite 3.53.4（ファイル形式のDB）、Python 3.14.8、手元のPC1台（macOS 13）
• 測り方：各条件を7回実行した中央値
• 索引あり：「状態＋受注日」と「取引先＋受注日」の2本
• 含まないもの：本番で使われるDB製品（PostgreSQL・MySQL・SQL Serverなど）、サーバーとアプリの間の通信、画面の表示、複数人の同時利用

結果（中央値。単位はミリ秒＝1000分の1秒。架空データでの合成例）

この構成に限って、次のことが読み取れます。

1. 10万件では、索引がなくても1回10ミリ秒前後で、人が待つ長さではありませんでした。 100万件では索引なしが約0.1秒に伸び、索引ありはほとんど変わりません。件数が増えるほど、索引の有無の差が開きます
2. 全件をプログラムに読み込んでから絞り込む作りは、索引があってもなくても同じ時間がかかりました。 10万件で約0.2秒、100万件で約2秒です。この作りの遅さは、DBに索引を足しても直らず、プログラムの書き換えが必要です
3. 索引を付けると、データの投入に時間がかかるようになりました。 100万件では索引なしの1.8秒が、索引2本ありでは15.8秒になりました。夜間の一括取込などがある場合、索引の追加で取込が遅くならないかも確かめる必要があります
4. 記入例のような「数十秒」の遅さは、この検証の範囲では再現していません。 DB単体・1人での処理は、最も遅い条件でも約2秒でした。数十秒かかる場合は、画面の表示、サーバーとの通信、同時利用、帳票の作成など、DB以外の要因も合わせて測る必要があります

取引先名を1件ずつ取る作り（計51回の問い合わせ）は、同じPCの中で完結するこの検証では差が小さく出ました。実際のシステムでは、問い合わせのたびにアプリのサーバーとDBのサーバーの間で往復が発生します。仮に1往復5ミリ秒かかるとすると、51回で約0.26秒が上乗せされる計算です（仮定に基づく試算で、往復時間は測っていません）。同じ仮定で、1画面の問い合わせが500回なら往復だけで約2.5秒です。

この検証は「索引が効く遅さと効かない遅さがある」「どこで時間を使っているかを測るのが先」を示すためのものです。本番環境で何倍速くなるかを示すものではありません。データの偏り、DB製品、サーバー構成、同時利用で結果は変わります。

調査だけ頼むか、改修まで頼むか、作り直すか

記録がそろったら、依頼の形を決めます。分かれ目は「原因の場所が分かっているか」「直す範囲がしぼれるか」「ソースコードを触れるか」の3点です。

調査のみを頼んだ場合、報告として少なくとも次のものを受け取ると、その後の改修を同じ会社に頼む場合にも、別の会社に頼む場合にも使えます。

• 遅い操作ごとの、時間の内訳（画面の表示・プログラム・DB・通信のどこで何秒か）
• 原因の場所と、その根拠（遅い問い合わせの記録、実行計画、サーバーの負荷の記録など）
• 直し方の候補ごとの、影響範囲・止める時間・副作用（索引による取込の遅れなど）
• 直し方ごとの改修の見積の前提
• 調べられなかったことと、その理由

元の開発会社とは別の会社に調査を頼む場合は、最初にソースコード・設計書・サーバー情報があるか、それを第三者に見せて手を入れてよい権利（利用権）が契約上あるかを確認してください。確認の仕方は開発会社の変更・引継ぎにまとめています。調査と改修を分けて契約する考え方は段階的な発注も参考になります。

改善目標と受入方法の書き方

出典: Nielsen Norman Group 公式

「速くしてほしい」だけでは、改修が終わったかどうかを判断できません。改善目標は「画面×条件×秒数×測り方」で書きます。

何秒を目標にするかは、業務での待ち方で決めます。参考として、利用者の感じ方について「0.1秒なら即座、1秒なら思考が途切れない、10秒が注意を保てる限界」という目安があります（Nielsen Norman Group「Response Times: The 3 Important Limits」、1993年の知見、2026-10-13確認）。これは業務システムの合格基準ではないため、窓口で顧客を待たせる画面と、締め日にまとめて出す帳票とでは別の目標にしてかまいません。帳票のように画面で待つ必要がない処理は、「出力の予約を受け付け、できたら通知する」形に変える（バッチ化）のも選択肢です。

改修を本番に反映する前には、元に戻す手順、作業前のバックアップ、作業する時間帯（締め日を避ける）も決めておきます。

費用の目安と、AI革命に頼める範囲

当社の公開価格は次のとおりです（すべて税別。2026-10-13時点の受託開発のページの記載）。

初回相談、相談後の相談メモ、資料を受け取った後の提案・見積は無料です。有償になる作業は、着手前に範囲と金額を示して合意を取ります。

先に書いたとおり、原因が索引1本の追加だと分かっていて、保守契約の範囲内や社内で直せる場合は、当社の改修（100万円〜）は割高になることがあります。その場合はそちらで直すことをおすすめします。

他社の公開価格の例も挙げておきます（各社の情報は確認日時点の公式ページの記載です。最新は各社にご確認ください）。

DB製品の診断、原因が分かった問い合わせ単位の改善、画面・プログラム・DB・サーバーをまとめて見る調査では、頼める範囲が違います。価格を比べるときは、自社の遅さがどの段階にあるかとあわせて見てください。

当社は、他社が作ったシステムも含め、言語やフレームワークを問わず既存システムの調査・改修に対応できます。「調査のみ」「調査＋改修」のどちらでも受けられます。最初にソースコード・設計書・サーバー情報の有無と利用権を確認します。なお、性能改善として公開できる当社の事例はまだありません。この記事の記録シート・目標の例は説明用の構成例です。締め日の集計に関わる開発としては、通信事業の数万件の請求情報の取込・集計・確認画面の開発実績があります（性能改善の事例ではありません）。

社内でChatGPTやClaudeなどを使い、遅い問い合わせの読み解きや修正案づくりを進めることもできます。その場合も、本番への反映前に、書き込みへの影響、元に戻す手順、受入の測定を確認してください。当社にはこの確認の部分だけを頼み、社内で進める部分は残す、という分け方も相談できます。

遅くなった画面の調査から相談する

相談の前に揃えておくと話が早いもの

初回相談は無料・30分・オンライン（Google Meet）です。要件が決まっていなくても大丈夫です。次のものがあれば、30分で話せる範囲が広がります。

• 遅さの記録シート（上の項目のうち分かるものだけでよい）
• システムの名前と、誰が作ったか（開発会社・社内・パッケージ製品）
• ソースコード・設計書・サーバー情報があるか、元の開発会社との契約がどうなっているか
• 止められない業務の時間帯（締め日、月初など）
• 目標にしたい画面と秒数の希望

本番のログイン情報、パスワード、実際の顧客データは送らないでください。 調査で本番に入る必要がある場合は、契約後に範囲を決めて権限を受け取ります。

相談では、何を解決したいか、自社でAIを使って進められる部分と任せた方がよい部分の切り分け、依頼の形の候補（調査のみ／調査＋改修／作り直しの検討）を一緒に整理します。相談後に、依頼範囲の候補・進め方・費用の目安をまとめた相談メモをメールでお送りします。30分の相談の場で見積を確定したり、直せるかどうかを断定したりはしません。

よくある質問

Q1. サーバーを増強すれば速くなりますか？

サーバーのCPUやメモリが足りないことが原因なら効きます。ただ、上の検証のように全件をプログラムに読み込む作りの場合、データが増えれば処理時間もそのまま延びます。増強しても、データの増加に追いつかなくなるおそれがあります。時間帯別の利用者数とサーバーの負荷を並べて、増強で直る遅さかを先に確かめてください。クラウドへの移行と合わせて考える場合は業務システムのクラウド移行も参考になります。

Q2. 元の開発会社と連絡が取れません。別の会社でも調査できますか？

ソースコードと、それを第三者に見せて改修してよい権利があれば、別の会社でも調査できます。ソースコードが手元に無い場合は、まず元の開発会社か契約書でソースコードの所在と権利を確かめるところから始めます。当社も他社が作ったシステムの調査・改修に対応できます。

Q3. 調査の間、システムを止める必要がありますか？

記録を読み取るだけの調査なら、止めずに進められることもあります。ただし、PostgreSQLの集計用の拡張機能のように、有効にするのにサーバーの再起動が要る道具もあります。調査を始める前に、止めてよい時間帯と、本番に触ってよい範囲を決めておいてください。

Q4. 何年も使っているシステムで、古いデータを消せば速くなりますか？

古いデータを別の場所に移すと速くなる場合はあります。ただし、過去の取引を参照する画面や、法令上の保存義務があるデータもあるため、消す前に「誰がいつ過去分を見るか」を確かめる必要があります。消すのではなく、日常の画面から外して別の場所で見られるようにする方法もあります。

Q5. 締め日の帳票出力だけが遅い場合、どう頼めばよいですか？

帳票は画面の前で待たなくてよい場合があるため、「速くする」以外に「出力の予約を受け付け、できたら通知する」形に変える選択肢があります。依頼時には、帳票を何時までに誰が使うのかを伝えてください。目標が「表示まで何秒」から「何時までに出力済み」に変わることがあります。

Q6. 改修後にまた遅くなることはありますか？

データの量や利用者は増え続けるため、ありえます。改修の受入時に測った条件と秒数を残しておき、締め日など決まったタイミングで同じ手順で測り直すと、遅くなり始めたことに早く気づけます。改修後の保守の頼み方はシステムの保守運用費にまとめています。

業務システムの遅さは、記録があれば原因の場所を早くしぼれます。遅い画面と記録を伺い、調査のみで始めるか改修まで含めるかの候補と費用の目安を、相談メモでお返しします。

遅くなった画面の調査から相談する