LASSIC Media らしくメディア
外部エンジニアのメモリリーク調査、性能改善に向けて渡す記録
監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）
この記事の結論
- メモリリーク調査を頼む前に、メモリの使用量の推移、GCログ、再現条件、直前の変更を社内でそろえておきます。
- ヒープダンプは取得の負荷が大きく、業務のデータも含むので、取る時間帯と持ち出しの可否を先に決めます。
- 定期的な再起動は当面の対処にとどめ、残り続けるオブジェクトの特定と修正を性能改善の本筋に置きます。
※ 本記事は2026年9月時点の公式情報（省庁・公的機関、および製品やサービスを提供する事業者が公開している資料）に基づきます。
本番のサーバーが、再起動してから数日たつと重くなる。メモリを増やしても、しばらくすると同じことが起きる——。長く動き続ける業務システムでは、こうした性能劣化が起こりがちです。メモリリークとは、使い終わったはずのメモリが解放されず、使用量が時間とともに増え続ける状態を指します。
原因を突き止めるメモリリーク調査は、診断の道具に慣れた外部エンジニアに頼むと進めやすくなります。ただし万能ではなく、調査の材料になる記録を社内でどれだけ渡せるかで、進み方が大きく変わります。本記事では、開発の現場を回すマネージャーに向けて、メモリリークの見分け方、社内で用意する記録、ヒープダンプの扱い、調査の進め方、そして外部に頼むときに確認したい点を整理します。
目次
メモリリーク調査とは
メモリが足りなくなったからといって、すぐにメモリリークだとは限りません。Oracle の Java のトラブルシューティング・ガイドは、「Java heap space」という詳細メッセージの付いたエラーについて、必ずしもメモリリークを意味しないと書いています。指定したヒープ（プログラムが使うメモリ領域）の大きさが、アプリケーションに対して足りないだけという設定の問題もありうるためです。*1
そこで調査の最初の仕事は、「領域が小さすぎる」のか「使い終わった物が残り続けている」のかを分けることになります。同じガイドは、ガベージコレクション（使われなくなったメモリを自動で回収する仕組み）を一通り終えた直後のヒープの使用量を見るよう勧めています。処理の量が落ち着いた状態で、この値が時間とともに増えていくなら、メモリリークの強い兆候だとしています。*1 回収の直後でも減らない分が、残り続けている物の量というわけです。
性能との関係も押さえておきます。ガイドは、ゆっくり進むメモリリークの典型的な症状として、長く動かすうちに回収が頻繁になり、アプリケーションが遅くなることを挙げています。*1 画面の応答が日を追って遅くなるシステムの性能改善は、SQLやサーバーの増強より先に、メモリリーク調査から始めたほうがよい場合があるのです。回収の仕組みそのものは「ガベージコレクションの仕組みとメモリ管理の注意点」で扱っています。
Java以外でも考え方は同じです。Node.js の公式ガイドは、疑わしい機能を使う前後でヒープの状態を2回記録し、その差を比べる方法を紹介しています。差の大部分が漏れている物になる、という説明です。*2 言語が変わっても、時間を置いた比較で増え方を見るという点は変わりません。
なぜ社内の記録が要るのか
Oracle のガイドは、ソースコードの中のメモリリークを診断するのは難しく、アプリケーションについての詳しい知識が要り、作業は繰り返しが多く長くなりがちだと書いています。*1 外部エンジニアは診断の道具には詳しくても、そのシステムがどの機能でどんなデータを持ち続けているかまでは知りません。その差を埋めるのが、社内にしかない本番の記録と、アプリケーションを知る社内の担当者です。
記録が残っているかどうかは、システムを作ったときの取り決めで決まります。IPAの「非機能要求グレード」は、監視で集める情報の段階を、死活監視、エラー監視、トレース情報を含むエラー監視、リソース監視、パフォーマンス監視の順に分けています。このうちリソース監視は、ログや別途集める情報をもとに、CPUやメモリ、ディスク、ネットワーク帯域の使用状況を判断する監視です。*3 死活監視しか決めていなかったシステムでは、メモリの推移がそもそも残っていないことがあります。
ゆっくり進むメモリリークは、見つけにくいものです。数日から数週間かけて増えていく場合、症状が出た時点の記録だけでは増え始めた時期が分かりません。調査を頼む前に、自社のシステムがどの段階の監視をしていて、どのくらいの期間の記録が残っているかを確かめておきます。
社内で用意しておく記録
外部エンジニアに渡す記録は、次の6つにまとめておくと話が早く進みます。すべてがそろっていなくても調査は始められますが、欠けている物を先に伝えておくと、何から集めるかの相談ができます。
| 記録 | 中身の例 |
|---|---|
| 再現条件 | 起動からの経過時間、処理した件数、重くなる機能や画面、夜間の一括処理との重なり |
| メモリの推移 | プロセスが使うメモリの量と、回収の直後のヒープの使用量。症状が出るまでの期間の分 |
| GCログ | ガベージコレクションが動いた時刻、回収の前後の使用量、止まった時間 |
| エラーの記録 | メモリ不足のエラーの全文と詳細メッセージ、発生した時刻 |
| 構成と設定 | 言語と実行環境の版、ヒープの上限などの起動時の設定、主なライブラリの版 |
| 変更の履歴 | 症状が出る前後のリリース、設定変更、利用者数や取り込むデータ量の変化 |
GCログは、GCログを見れば漏れているかどうかが分かる、というものではありません。Oracle のガイドには、ヒープを48MBに設定した例で、全体の回収を行っても使用量が45MBから少しも減らなかったログが載っています。ガイドはこの結果について、ヒープがアプリケーションの必要量より小さいか、メモリリークのどちらかだとしています。*1 1回分のログでは両者を分けられず、日をまたいだ推移と合わせて初めて判断できるわけです。
記録どうしの時刻をそろえておくことも欠かせません。非機能要求グレードは、機器の時刻を同期させると複数のサーバーが出すログの順序が保証され、障害調査の手間を下げられる可能性があるとしています。*3 アプリケーションのサーバーとデータベースのサーバーで時計がずれていると、メモリが増えた時刻と重い処理が走った時刻を並べられません。
今後に備えるなら、日ごろの運用で測る項目にメモリも入れておきます。デジタル庁の標準ガイドライン解説書（DS-110）は、運用計画書に、データ量、重要な処理の応答時間や処理件数、CPUの利用率を定点観測として測るよう定義する、と書いています。*4 ここにメモリの使用量を並べておけば、次に同じ症状が出たときに、増え始めた日までさかのぼれます。
ヒープダンプの扱い
ヒープダンプとは、ある時点のヒープの中身を丸ごとファイルに書き出したものです。Oracle のガイドは、ヒープダンプをメモリリークの調査でいちばん重要なデータと位置づけ、専用のコマンドや、メモリ不足のエラーが起きたときに自動で書き出す起動時の設定で取れると説明しています。*1
ただ、本番で取るには負荷の見積もりが要ります。Node.js の公式ガイドは、記録を作っている間はメインスレッドの他の処理がすべて止まり、ヒープの中身によっては1分を超えることもあると注意しています。記録はメモリの中で組み立てられるため、ヒープの大きさが倍になってメモリを使い切り、アプリケーションが落ちるおそれもあります。そのうえで、本番で取るなら、落ちても利用者に影響しないプロセスから取るよう求めています。*2
このため、取る前に社内で決めておくことがあります。どのサーバーを振り分けの対象から外して取るか、利用の少ない時間帯はいつか、コマンドを誰が実行するか、誰が承認するか、書き出すファイルの置き場所に十分な空きがあるか、といった点です。外部エンジニアにはこれらを伝えたうえで、取り方の手順を書いてもらうと、当日の作業で迷いません。
もう一つ大事なのが中身の扱いです。ヒープダンプには、その時点でアプリケーションがメモリに持っていたデータがそのまま入ります。顧客の氏名や取引の内容、画面の入力値が含まれることもあるため、本番のファイルを社外へ持ち出してよいか、社内の端末で解析してもらうかを先に決めておきます。個人データを扱う作業を外部に任せるときの確認は「業務委託エンジニアに個人データを任せる前の確認」でまとめています。
Javaの動作記録を取る仕組み（Java Flight Recorder）のファイルには、機密にあたる中身を取り除いたり、ファイルを小さくしたりする専用のコマンドが用意されています。*5 ヒープダンプより扱いやすい記録で足りるかどうかも、外部エンジニアに相談できる点です。
調査の進め方
メモリリーク調査は、おおむね次の順に進みます。
- 領域の大きさの設定が、アプリケーションの必要量に足りているかを確かめる
- 回収の直後の使用量の推移で、残り続けている物があるかを確かめる
- 時間を置いた2回の記録を比べ、増えている物と、それを持ち続けている箇所を特定する
- 原因の箇所を直し、同じ条件で動かして使用量が増えなくなったことを確かめる
3つ目の手順で使う動作記録の仕組みについて、Oracle のガイドは負荷が1%未満と非常に小さく、本番で常に動かしておける設計だと説明しています。*1 記録の中の、残り続けているオブジェクトの見本を並べると、記録された時点のヒープ使用量が増えていく様子が見えます。
ガイドの例では、この値が63.9MBから121.7MBまで増えていき、それがメモリリークの兆候だと説明しています。*1 あわせて、起動のときに作られた物や、記録を取る直前に作られた物は、ふつうはメモリリークではないとも書いています。 増えている物を見つけても、作られた時刻を見ずに犯人と決めないよう、報告では根拠も示してもらいます。
原因を直すまでの間は、定期的な再起動でしのぐ現場も多いでしょう。経済産業省の「非機能要求記述ガイド」は、予防措置の手段の例として、メモリリークを防ぐためにサーバーやプロセスを定期的に再起動することを挙げています。*6 一方で同じガイドは、この手段を時間効率性を良くする手段ではないと位置づけています。 再起動は当面の対処として日程を決め、原因の特定と修正を性能改善の本筋として別に進めます。
外部に頼むときに確認しておきたい点
一つ目は、本番での操作の範囲です。記録を取るコマンドを外部エンジニア自身が本番で実行するのか、社内の担当者が手順書どおりに実行してファイルを渡すのかを決めます。後者なら、外部エンジニアに本番の権限を渡さずに済みます。
二つ目は、区切りの置き方です。調査は繰り返しが多く長くなりがちなので、最初から原因の特定までを一括で頼むより、「推移を見て漏れの有無を判断するところまで」を一区切りにすると、途中で方針を見直せます。報告書に書いてもらう項目や作業時間の上限の決め方は「外部エンジニアに不具合の原因調査を頼む手順」で扱っています。
三つ目は、社内の窓口です。どの機能がどんなデータを持ち続けるのかを答えられるアプリケーションの担当者を、調査の間だけでも決めておきます。外部エンジニアの問いにすぐ答えられるかどうかで、同じ調査でもかかる日数が変わります。
まとめ：メモリリーク調査で確かめておきたい3つの点
外部エンジニアにメモリリーク調査を頼むうえで、確かめておきたい点は3つに整理できます。第一に、回収の直後の使用量の推移、GCログ、再現条件、直前の変更を社内でそろえ、欠けている記録を先に伝えること。第二に、ヒープダンプを取るサーバーと時間帯、実行する人、中身を社外へ持ち出してよいかを事前に決めること。第三に、定期的な再起動は当面の対処にとどめ、原因の特定と修正を性能改善の本筋として区切りを置いて進めることです。この3点を踏まえておけば、「調査を頼んだのに、記録が無くて何週間も待つだけになった」という事態を避けやすくなります。記録のそろえ方や頼む範囲に迷いがあれば、外部の手を借りるのも一つの選択肢です。
よくある質問
メモリリーク調査には、どのくらいの期間がかかりますか
一律には決まりません。漏れる速さによって、症状がもう一度出るまで待つ必要があるためです。数日かけて増える場合は、推移を見るだけでも数日かかります。最初の区切りを「漏れの有無の判断」に置き、そこで次の期間を決めると見通しを立てやすくなります。
JavaやNode.js以外の言語でも、同じ準備でよいですか
基本の準備は同じです。時間を置いてメモリの状態を比べ、増えている物を探すという考え方は変わりません。記録を取る道具やコマンドは言語ごとに違うので、使っている版の公式ドキュメントを外部エンジニアと一緒に確認しておくと確実です。
本番のヒープダンプを社外へ持ち出せないときは、どうすればよいですか
社内の端末や環境の上で、外部エンジニアに解析してもらう方法があります。本番と同じ手順で試験用の環境に負荷をかけ、試験用のデータで症状を再現できれば、その環境のダンプを渡すこともできます。どちらにするかは、調査を頼む前に決めておきます。
再起動の間隔は、どう決めればよいですか
メモリの推移から、上限に届くまでの日数を見て、それより短い間隔にするのが基本です。ただし、リリースで漏れる速さが変わると、その間隔では足りなくなることがあります。再起動を続ける間も推移を見続け、原因の修正の予定とあわせて管理します。
メモリリーク調査を頼める人を探したいとき
「Javaの業務システムで、再起動から数日たつと重くなる」のように、症状と使っている技術が分かっていれば、そのままご相談いただけます。記録のそろえ方を決めきれていない段階でも構いません。
Remoguとリラシクなら、リモートワークで働く社員の候補者も、業務委託で開発に加わる専門人材も探せます。
Remoguは、リモート前提で全国から即戦力のITプロ人材を調達するサービスです。リラシクは、扱う求人がすべてリモートワークのITエンジニア専門転職エージェントです。どちらもLASSICが運営しています。
出典
- *1 参考：Oracle「Java Platform, Standard Edition Troubleshooting Guide」（Release 21）3 Troubleshoot Memory Leaks（https://docs.oracle.com/en/java/javase/21/troubleshoot/troubleshooting-memory-leaks.html）。出典：Oracle「Java Platform, Standard Edition Troubleshooting Guide」Release 21 の第3章。Detail Message: Java heap space、Detecting a Memory Leak（ライブセットの監視、ゆっくり進むリークの症状、GCログの例）、Diagnosing Java Memory Leaks（診断の難しさ、Heap Dumps、The jfr tool の負荷と Old Object Sample の例）を参照（2026年9月確認）
- *2 参考：Node.js「Using Heap Snapshot」（https://nodejs.org/en/learn/diagnostics/memory/using-heap-snapshot）。出典：Node.js 公式サイト Learn の Diagnostics / Memory「Using Heap Snapshot」。Warning（メインスレッドの停止、1分を超える場合、ヒープの大きさが倍になるおそれ、本番で取る場合の注意）と How to find a memory leak with Heap Snapshots を参照（2026年9月確認）
- *3 参考：IPA「非機能要求グレード2018」（https://www.ipa.go.jp/archive/digital/iot-en-ci/jyouryuu/hikinou/ent03-b.html）。出典：独立行政法人情報処理推進機構（IPA）「非機能要求グレード2018」本体一括ダウンロード（ZIP）に収録の「04_項目一覧」。C.1.3.1 監視情報のレベルと説明、C.1.4.1 時刻同期設定の範囲の運用コストへの影響を参照（2026年9月確認）
- *4 参考：デジタル庁「デジタル・ガバメント推進標準ガイドライン解説書」（DS-110）（https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/e2a06143-ed29-4f1d-9c31-0f06fca67afc/50952dae/20260715_resources_standard_guidelines_guideline_03.pdf）。出典：デジタル庁「デジタル・ガバメント推進標準ガイドライン解説書」。第3編第9章1. の表9-3 運用計画書の記載内容「ア 作業概要」（データの収集として定点観測で測定する項目）を参照（2026年9月確認）
- *5 参考：Oracle「The jfr Command」（JDK 21）（https://docs.oracle.com/en/java/javase/21/docs/specs/man/jfr.html）。出典：Oracle「Java Development Kit Version 21 Tool Specifications」の jfr コマンド。jfr scrub subcommand の説明を参照（2026年9月確認）
- *6 参考：経済産業省「非機能要求記述ガイド」（2008年7月）（https://www.ipa.go.jp/archive/digital/iot-en-ci/jyouryuu/hikinou/ps6vr700000077he-att/000004469.pdf）。出典：経済産業省 ソフトウェア開発力強化推進タスクフォース 要求工学・設計開発技術研究部会 非機能要求とアーキテクチャWG「非機能要求記述ガイド」（2008年7月、IPAのアーカイブに掲載）。(8) 予防措置の効率性の説明と、実現手段の例の表（サービスからの除去）を参照（2026年9月確認）
