LASSIC Media らしくメディア

監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）

開発会社から届いた不具合の報告に、見慣れない英数字の羅列が貼られている。「スタックトレースを確認したところ」と説明されても、それが何を示す情報なのか分からない——。システムの発注担当者やプロジェクトマネージャーの現場では、こうした場面が起こりがちです。スタックトレースとは、プログラムがエラーで止まったとき、どの処理からどの処理を呼び出してエラーに至ったかを、順に書き出した記録です。

読み方を知っておくと、エラーの重さや対応の緊急度を自分たちでも判断しやすくなり、開発会社への依頼も具体的になります。ただし万能ではなく、スタックトレースだけで原因を断定できるとは限りません。本記事では、発注担当者やプロジェクトマネージャーに向けて、スタックトレースに書かれている情報、読み方の基本、調査と運用での使い方、そして開発を委託するときに確認したい点を整理します。

スタックトレースとは

PythonやJavaScriptなどの言語では、例外（プログラムの実行中に起きた想定外の事態）が発生し、途中で対処されないままプログラムが止まると、エラーメッセージとあわせてスタックトレースが出力されます。

Webアプリケーションでも考え方は変わりません。サーバー側の処理で例外が起きたときは、利用者の画面には汎用的なエラー表示だけを返し、サーバー側のログにスタックトレースを記録する運用が広く採られています。ブラウザ側で動くJavaScriptの処理でも、同じように例外が起きてスタックトレースが記録されます。

「スタック」という呼び名は、処理を呼び出すたびに情報を積み上げ、処理から戻るたびに取り出すというデータの持ち方に由来します。エラーメッセージ1行だけでは、どの機能のどの処理がきっかけだったのかをつかめません。呼び出しの経路が段ごとに記録されている点が、原因を絞り込むうえで役に立ちます。

書かれている3つの情報

スタックトレースの中身は、大きく3つの情報から成ります。この構成は、Java・PHP・Rubyなど、ほかの主要な言語でも共通しています。1つ目は、発生したエラーの種類とメッセージです。例外のクラス名（エラーの分類名）と、原因を短く示した文言が並びます。2つ目は呼び出し履歴で、どの関数（処理のまとまり）から、どの関数を呼び出したかが順に並びます。履歴の1段ぶんはフレームと呼ばれます。3つ目はファイル名と行番号で、どのソースコードの何行目で処理が呼ばれていたかを示し、直す箇所を絞り込む手がかりになります。

このうち見落とされがちなのが、1つ目のエラーの種類です。「入力値の形式が想定と違う」という種類の例外と、「外部のサーバーへ接続できない」という種類の例外とでは、疑うべき原因も、確認を頼む担当者も変わります。呼び出し履歴を読む前に、まず種類とメッセージを確かめる習慣をつけておくとよいでしょう。

具体的な例で見てみます。注文画面の処理（関数A）が在庫を確認する処理（関数B）を呼び出し、在庫の確認の中でデータベースへ問い合わせる処理（関数C）を呼び出したとします。関数Cで想定外のデータ形式に当たって例外が起きると、スタックトレースには関数C・関数B・関数Aの3段の呼び出しが、それぞれのファイル名と行番号つきで記録されます。Pythonで書いた場合の出力は、次のようになります。

最終行の「ValueError: unexpected data format」がエラーの種類とメッセージで、その上に並ぶ3つの「File」の行が呼び出し履歴です。この3段を追えば、どの画面のどの操作から問題が始まったのかを、コードを1行ずつ読まずにつかめます。

言語ごとの並び順の違い

スタックトレースを読む向きは、言語やツールによって異なります。Pythonのトレースバックは「most recent call last」、つまり最新の呼び出しを末尾に置く並びで、末尾の行が例外の発生元です。^*2 先の例では、末尾に近い「db.py」の行が発生元で、いちばん上の「order.py」が最初の入り口に当たります。JavaScriptのError.stack（エラーの記録を取り出す仕組み）は反対に、最新の呼び出しを先頭に置き、最初に呼ばれた処理を末尾に置く順に並びます。^*1

図は、JavaScriptのように最新の呼び出しを先頭に置く並びの例です。この違いを知らずに読むと、発生元を取り違えかねません。開発を委託している会社に、使っている言語やツールがどちらの並び順なのかを一度確かめておくと、報告を受けたときに読み違えずに済みます。

読み方の基本

実際にスタックトレースを読むときは、まずこのシステムのために書かれたコードのファイル名を探します。フレームワークやライブラリ（共通の処理をまとめた部品）の内部の行が並んでいても、直すべき箇所は、実務上、このシステムのために書かれたコードの中にあることがほとんどです。部品の内部の行はいったん読み飛ばし、そのコードの行に行き着くまで履歴をたどります。

原因の手がかりは、例外の発生元の行にあります。前の節で見た並び順に従って発生元の行を見ると、原因の見当が付けやすくなります。統合開発環境やエラー監視ツールには、トレースのファイル名や行番号をクリックすると該当するソースコードへ移動できる機能を備えたものもあり、調査の初動を早められます。表に、読み取れる情報と調査での使い道をまとめました。

調査と運用での使い方

スタックトレースは、本番環境（利用者が実際に使っているシステム）で起きたエラーを再現し、原因を特定する手がかりになります。発生箇所と呼び出しの経路が分かれば、どの操作の組み合わせで問題が起きたのかを推測しやすくなります。本番環境の調査では、おおむね次の流れでスタックトレースを使います。

1. エラー監視ツールの通知やログから、スタックトレースを含む記録を確認する
2. 呼び出し履歴をたどり、発生元に近い自社コードの行を特定する
3. 発生時の入力値や操作手順を、ログや利用者からの報告とあわせて推測する
4. テスト用の環境で同じ条件を再現し、修正内容を確かめる

近年は、Sentryなどのエラー監視ツール（発生した例外を集めて通知や一覧表示をするサービス）で、スタックトレースを自動で集める運用も広がっています。発生箇所やエラーの種類が同じものを1つのグループにまとめる機能を備えたツールが一般的です。件数を数えて頻発する不具合を見つけやすくなり、同じ原因のエラーが何度も通知されることも抑えられます。

JavaScriptのconsole.trace()のように、任意の時点で呼び出し履歴を出力できる機能もあります。^*4 疑わしい処理の前後で呼び出し履歴をログに残しておけば、後から原因を調べやすくなります。集めたスタックトレースは溜めたままにせず、発生頻度が高いまま残っているエラーや、同じ箇所で繰り返し起きているエラーがないかを定期的に見返すと、先に直すべき箇所が分かります。

つまずきやすい点

一つ目は、非同期処理（複数の処理を並行して進める書き方）です。非同期処理を多く使う画面では、処理を頼んだ側の行がスタックトレースに残らないことがあります。その場合は、ログで処理を頼んだ側を探します。また、例外が別の例外を引き起こす場合は、最初の例外と後から起きた例外の両方がトレースに含まれることがあり、どちらが引き金なのかを見分ける必要があります。

二つ目は、記録の量です。すべての警告にまでスタックトレースを付けると記録が膨らみ、肝心のエラーが埋もれてしまいます。記録する重大度（エラー・警告・情報など）ごとに、スタックトレースを残すかどうかを決めておくと、後から見返す量を絞り込めます。

三つ目は、機密情報です。スタックトレースには、関数に渡された引数（処理に渡されたデータ）の値まで含まれる場合があり、^*1 個人情報や認証情報が意図せず記録されるおそれがあります。外部の監視ツールへログを送る構成では、送る前に機密情報を取り除く処理（マスキング）を挟んでおくと、社外のサービスに内部情報がそのまま渡ることを防げます。どの項目を取り除くかは、扱うデータに応じて開発の初期に決めておきます。

開発を委託するときに確認しておきたい点

スタックトレースの扱いは、発注時の打ち合わせで話題になりにくいテーマです。それでも、稼働後の障害対応の速さや、外部への情報流出のリスクに関わります。システムを開発会社に発注する段階で確かめておきたい点は、次の3つです。

1つ目は、エラーが起きたときにスタックトレースを記録し、通知する仕組みがあるかどうかです。ログに残すだけの設計と、監視ツールで通知まで行う設計とでは、障害に気づくまでの早さが違います。「エラーが起きたことを、誰がどの手段で最初に知るのか」を具体的に確かめておくとよいでしょう。監視ツールを導入済みでも、通知先が特定の担当者1人になっていないか、担当者が不在のときに気づける体制かどうかを確認しておきます。

2つ目は、利用者向けの画面に内部情報を出していないかです。エラー画面にスタックトレースをそのまま表示すると、内部のファイルパスやコードの構成が外部から見え、攻撃の手がかりを与えかねません。レビューの場で実際にエラーを起こした画面を見せてもらい、テスト用の環境では詳しい情報を表示し、本番環境では汎用的なメッセージに切り替える設定になっているかを確かめます。

3つ目は、保守運用の契約での取り決めです。障害が起きたときの連絡の流れや対応時間の目安とあわせて、スタックトレースをどこまで記録し、どこまで発注元と共有するかを契約の段階で文書にしておくと、実際に障害が起きたときに動きやすくなります。

まとめ：スタックトレースで確かめておきたい3つの点

スタックトレースを読み、原因の調査に役立てるうえで、確かめておきたい点は3つに整理できます。第一に、エラーの種類とメッセージ、呼び出し履歴、ファイル名と行番号の3つの情報を分けて読み、言語ごとの並び順を確かめること。第二に、システムのために書かれたコードの行を探し、例外の発生元の行から原因の見当を付けること。第三に、記録と通知の仕組み、利用者の画面に内部情報を出さない設定、トレースの共有の取り決めを、発注の段階で確かめることです。この3点を踏まえておけば、「報告にトレースが貼られていたのに、何が起きたのかを社内に説明できなかった」という事態を避けやすくなります。エラーを調べる体制づくりに迷いがあれば、外部の手を借りるのも一つの選択肢です。

よくある質問

出典

1. *1　参考：MDN Web Docs「Error: stack property」（https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Error/stack）。出典：MDN Web Docs「Error: stack property」。stackプロパティの並び順（最新の呼び出しから元のグローバルスコープの呼び出しまで）と、呼び出された関数・順序・行とファイル・引数が含まれることを参照（2026年9月確認）
2. *2　参考：Python公式ドキュメント「8. Errors and Exceptions」（https://docs.python.org/3/tutorial/errors.html）。出典：Python公式ドキュメント「8. Errors and Exceptions」。トレースバック（Traceback (most recent call last)）の表示例を参照（2026年9月確認）
3. *3　参考：Python公式ドキュメント「traceback — Print or retrieve a stack traceback」（https://docs.python.org/3/library/traceback.html）。出典：Python公式ドキュメント「traceback」モジュール。スタックトレースの取り出しと表示を参照（2026年9月確認）
4. *4　参考：MDN Web Docs「console: trace() static method」（https://developer.mozilla.org/en-US/docs/Web/API/console/trace）。出典：MDN Web Docs「console: trace() static method」。任意の時点でスタックトレースを出力する機能を参照（2026年9月確認）

Tweet