この記事の対象読者
- 問い合わせ対応と開発調査をつなぐ人
- 画面エラーとログを結びつけたい人
- requestIdや問い合わせコードの出し方に迷っている人
本題に入る前に
問い合わせでよく困るのが、「どの操作で起きたエラーなのか分からない」ことです。
ユーザーは「保存できません」と教えてくれます。でも調査する側は、時刻、ユーザー、操作、ログのどれかにたどり着かないと原因を追えません。
もちろん、ユーザーに細かい技術情報を聞くのは大変です。スクショをお願いして、時刻を聞いて、操作手順を聞いて、それでもログが見つからない。こういうこと、ありますよね。地味に時間が溶けます。
そこで役に立つのが、画面に表示する調査用IDです。
この記事では、エラー表示に requestId や supportCode を含め、ログ調査につなげる考え方を紹介します。
画面表示とログをつなぐ
APIのリクエストごとに requestId を持たせると、画面のエラーとサーバーログを結びつけやすくなります。
APIレスポンスにIDを含める
エラー時のレスポンスに、問い合わせで使えるIDを入れます。
{
"errorCode": "RESERVATION_SAVE_FAILED",
"message": "予約を保存できませんでした。",
"requestId": "req_20260701_abc123"
}
画面では、技術的な詳細ではなく、問い合わせ時に伝えられる形で表示します。
type ApiError = {
errorCode: string;
message: string;
requestId?: string;
};
function ErrorMessage({ error }: { error: ApiError }) {
return (
<div role="alert">
<p>{error.message}</p>
{error.requestId && (
<p>お問い合わせコード: {error.requestId}</p>
)}
</div>
);
}
見せる情報と見せない情報を分ける
画面に出すのは、ユーザーやCSが伝えられる情報だけにします。
| 出してよいもの | 出しすぎに注意するもの |
|---|---|
| 問い合わせコード | スタックトレース |
| 発生時刻 | 内部APIのURL |
| 操作名の一般的な表現 | DB名、テーブル名 |
エラーの中身を全部出せば調査しやすくなる、というわけではありません。見せる情報は少なく、ログには十分に残す。ここを分けるのが大事です。
フロント側で生成する場合
API側で生成するのが自然なことが多いですが、フロント側で操作IDを作って送ることもあります。
function createRequestId() {
return crypto.randomUUID();
}
async function saveReservation() {
const requestId = createRequestId();
await fetch("/api/reservations", {
method: "POST",
headers: {
"Content-Type": "application/json",
"X-Request-Id": requestId,
},
body: JSON.stringify({ title: "サンプル予約" }),
});
}
この場合も、サーバー側で受け取ったIDをログに出す必要があります。
まとめ
問い合わせ対応では、画面とログをつなぐ手がかりがあるだけで調査がかなり楽になります。
エラー画面に問い合わせコードを出し、ログには同じIDを残す。ユーザーに内部情報を見せすぎず、調査に必要な道しるべを用意する。小さい工夫ですが、運用ではかなり助かります。