「その人だけエラーが出る」という問い合わせを受けて、自分の画面では正常に動いている表示を見ながら、手がかりを探している保守運用の担当者
障害対応・運用監視約14分

特定のユーザーだけエラーになる｜全体か個別かを切り分ける手順

「○○さんだけ、登録ボタンを押すとエラーになるそうです」

そう連絡をもらって自分の画面で試すと、何事もなく動く。テスト用のアカウントでも動く。もう一度その人の名前を聞き直して、同じ操作をなぞってみても、やっぱり動く。

こういう問い合わせは、障害としては小さく見えるのに、時間だけがどんどん溶けていきます。しかも「自分の手元では再現しない」と伝えると、相手には「信じてもらえていない」と受け取られかねない。技術の問題と、気持ちの問題が同時に来る、なかなかしんどい場面です。

これは、あなたの調べ方が甘いからではありません。個別事象は「原因を探す」より先に「範囲を確かめる」順番でないと、そもそも手がかりが集まらない——ただそれだけの話です。この記事では、その順番を一緒に整理していきます。

結論：やることは3つです。①「本当にその人だけか」を先に確かめる（全体障害の入口かもしれません）、②その人と、動いている人との「違い」を5つの層に分けて並べる（権限・データ・端末・回線・時間）、③自分の手元で再現しようとせず、相手の環境からしか取れない情報を先にもらう（正確な時刻・操作・画面）。原因の当てずっぽうは、この3つが終わってからで間に合います。

なお、環境やシステム構成によって見る場所は変わります。ここで挙げるのは「順番の型」です。自分の現場のログの置き場所に置き換えながら読んでみてください。

なぜ「その人だけ」は調べにくいのか

腕の問題ではなく、構造的に難しい要素がそろっています。

だからこそ、最初の一手は原因究明ではありません。範囲の確定です。ここを飛ばすと、たまたま最初に思いついた仮説を延々と追いかけることになります。

ステップ1：本当に「その人だけ」かを確かめる

不具合の範囲を「全体」「一部」「ひとり」の3つに分けて確かめる考え方を示した図
まず範囲を確かめる。同じ症状の人が何人いるかで、次に見る場所が変わる

「その人だけ」というのは、たいてい報告が1件しか来ていないという意味です。実際にその人だけとは限りません。まずここを確かめます。

確かめ方は、難しいことをしなくて大丈夫です。

  1. エラーログを、その時間帯だけ見る。同じエラーが他のユーザーでも出ていないかを数えます。
  2. 報告者の近くの人に1人だけ聞いてもらう。「同じ操作をして同じことが起きるか、隣の方に試していただけますか」と依頼すれば、数分で範囲が分かります。
  3. 問い合わせ履歴を検索する。同じ症状が過去に別の人から来ていないか。問い合わせ対応を「調査ログ」として資産にする方法で記録が残っていれば、ここが一番速い場所になります。

ログで同じエラーの発生件数と、出ているユーザーの広がりを見るなら、こんな形で足ります（パスやログ形式は自分の環境に合わせてください）。

# 当該時間帯のエラーを抜き出して、件数を数える
grep "2026-08-16 14:" /var/log/app/error.log | grep -c "登録処理"

# 同じエラーが出ているユーザーIDを一覧にして、何人いるかを見る
grep "2026-08-16 14:" /var/log/app/error.log \
  | grep -o 'user_id=[0-9]*' \
  | sort | uniq -c | sort -rn | head

ここで「実は5人出ていた」と分かることは、決して珍しくありません。1人からの報告は、氷山の見えている部分かもしれないという前提で見ておくと、後の判断が変わります。

ステップ2：時刻と操作を特定して、ログをその人に絞る

範囲が「ひとり」だと確定したら、次はログの中からその人を見つけます。ここで必要なのは、推測ではなく相手からの3点セットです。

この3つがそろうと、ログの絞り込みは一気に楽になります。逆にここが曖昧なままだと、何万行を眺めても手がかりは出てきません。

# ユーザーIDが分かるなら、まずそれで絞る
grep "user_id=1234" /var/log/app/app.log | grep "2026-08-16 14:"

# アクセスログを、相手のIPアドレスと時間帯で絞る
grep "203.0.113.10" /var/log/nginx/access.log | grep "16/Aug/2026:14:"

# 見つけた1行の前後を、流れごと見る（-B 前 / -A 後の行数）
grep -n -B 20 -A 20 "処理対象のリクエストID" /var/log/app/app.log

エラーの1行だけを見ても、たいてい原因は分かりません。その前後を「流れ」として読むのがコツです。絞り込みのやり方は大量ログからエラーを絞り込む｜grep・tailの実務術にまとめてあります。アプリのスタックトレースが取れているなら、スタックトレースの読み方と合わせて読むと、どの層で落ちているかまで見えてきます。

なお、相手からスクリーンショットや操作ログをもらうときは、個人情報や取引先の情報が写り込むことがあります。調査に必要な範囲だけ受け取り、調査が終わったら保管ルールに沿って扱う——このひと手間を先に決めておくと、後から困りません（個人データの取り扱いについては個人情報保護委員会の情報が参考になります）。

ステップ3：「違い」を5つの層に分けて並べる

ここからが本番です。動いている人と、動かない人。その2人の違いを、思いつく順ではなく層ごとに並べます。順番に見ていけるようになるだけで、迷子になりません。

  1. 権限・アカウント：ロール、所属、有効期限、初回ログインかどうか、パスワード有効期限切れ。「管理者だけ通る」「一般ユーザーだと落ちる」は定番です（退職者アカウントの棚卸しと権限の最小化で権限の整理をしていれば、ここは早く見つかります）。
  2. データ：その人が扱っているデータそのもの。件数が極端に多い、名前に特殊な文字（旧字体・環境依存文字・絵文字）が入っている、必須のはずの項目が空、日付が未来や過去に飛んでいる。「その人のデータだけが特殊」というのは、かなりよくある原因です。文字が絡む症状なら文字化けの切り分けも合わせて見てください。
  3. 端末・ブラウザ：OSやブラウザのバージョン、拡張機能、画面サイズ、社内標準ではない端末、スマホからのアクセス。古いブラウザだけで特定の機能が動かない、というのは今も普通に起きます。
  4. 回線・経路：社内プロキシ経由か自宅からか、VPN、社内からのIP制限、通信の遅い回線。管理画面にアクセス制限をかけている場合はここが直撃します（管理画面のアクセス制限）。
  5. 時間・状態：いつも同じ時刻に起きるのか、初回だけか、ログインしっぱなしのセッションが古いのか、ブラウザに残ったキャッシュか。「一度ログアウトすると直る」なら、この層が濃厚です（キャッシュが原因の「直したのに直らない」）。

書き出すときは、表の形にしてしまうのが早いです。

層動く人動かない人差はあるか
権限・アカウント一般ユーザー一般ユーザーなし
データ取引先3件取引先1,200件あり
端末・ブラウザChrome最新Chrome最新なし
回線・経路社内社内なし
時間・状態随時随時なし

差が1つに絞れたら、そこが調査の入口です。差が複数出ても構いません。安く試せるものから順に消していくのが次のステップです。

ステップ4：安く試せるところから消していく

原因の可能性を、いきなり深いところから掘らないでください。手間がかからず、相手に負担をかけない確認から先に済ませます。

  1. 別のブラウザ、またはプライベートウィンドウで試してもらう（キャッシュ・セッション・拡張機能を一度に切り分けられます。数十秒で終わります）
  2. 別の端末・別の回線から試してもらう（スマホのテザリングなど。端末と経路がまとめて外れます）
  3. 同じ権限のテスト用アカウントで、自分が試す（権限の層を確かめる）
  4. 相手のデータに近い状態を、検証環境で作って試す（件数を増やす、同じ特殊文字を入れる。本番データはそのまま持ち出さず、検証用に加工した形で試すのが安全です）
  5. 相手の操作を、画面共有で一緒になぞる（ここまでで分からなければ、これが一番速い。5分の同席が、2時間の調査を省くことがあります）

1と2だけで切り分けがついてしまう案件は、思っているより多いものです。まずここから声をかけてみてください。

具体例：よくある3つのパターン

どのパターンにも共通するのは、原因は「その人」ではなく、たいていシステム側の前提の外にあるということです。ここを見誤ると、無意識に相手を責める説明になってしまいます。

影響：この順番を持っていると、何が変わるか

調査が長引きそうなときは、途中で相談していい合図でもあります。ひとりで抱え込む必要はありません。

そのまま使える：相手に送る確認テンプレート

最初の返信で、これを送っておくと調査が一気に進みます。責めないトーンのまま、必要な情報が集まる形にしてあります。

お世話になっております。ご連絡ありがとうございます。
状況を正確につかみたいので、いくつか教えていただけますでしょうか。

■ 起きたこと
　1. 発生した日時（できるだけ細かく：例 8/16 14時05分ごろ）
　2. どの画面で、どの操作をされたか
　3. 画面に表示された文言（お手数ですが画面の写真でも助かります）
　4. 直前に何か操作されていましたか（保存・検索・添付など）

■ 切り分けのお願い（どちらも1分ほどで終わります）
　5. 別のブラウザ、またはプライベートウィンドウで同じ操作をすると
　　 どうなりますか
　6. お近くの方が同じ操作をされた場合、同じことが起きますか

■ 環境について
　7. 社内のパソコンからでしょうか、社外（自宅・外出先）からでしょうか
　8. お使いのブラウザ（Chrome / Edge / Safari など）

こちらでも同時に調査を進めております。
お手数をおかけしますが、よろしくお願いいたします。

「再現しませんでした」だけを返すのは避けたいところです。再現しないという事実も、こちらの調査結果のひとつとして、「私の環境と◯◯さんの環境で違うところを探しています」と伝えると、相手も一緒に探す側に回ってくれます。

明日やること

いま抱えている「その人だけ」の案件があれば、この順でどうぞ。

  1. 範囲を確かめる。同じ症状の人がほかにいないか、ログか問い合わせ履歴で数える。
  2. 3点セットをもらう。正確な時刻・操作・画面の文言。上のテンプレートをそのまま使って構いません。
  3. ログをその人に絞る。ユーザーIDかIPアドレスと、時間帯で絞り込む。前後20行を流れで読む。
  4. 違いを5層で書き出す。権限・データ・端末・回線・時間。表にして、差のある行に印をつける。
  5. 安いものから試す。別ブラウザ、別回線、テストアカウント。ここまでで多くは形が見えます。
  6. 分かったことを1行残す。原因と決め手を書いておけば、次の1件が早くなります。

全部を今日やる必要はありません。1の「範囲を確かめる」だけでも、調査の景色はずいぶん変わります。

「その人だけ」切り分けチェックリスト

全部そろわなくても大丈夫です。上から3つできていれば、調査はもう前に進んでいます。

よければ、こちらも

特定のユーザーだけに起きていた不具合の原因が分かり、調査の記録をまとめながら安心している保守運用の担当者

「その人だけ」の不具合は、直っても誰にも気づかれない仕事です。全体障害のように騒がれることもなく、静かに報告が閉じるだけ。それでも、その1人は毎日その画面で仕事をしていて、あなたが動いたおかげで明日から普通に使えるようになります。

再現しないのは、あなたの見落としではありません。まだ違いが見つかっていないだけです。順番に並べていけば、たいていどこかに差が出てきます。明日は、範囲を数えるところからで十分です。

ほかの実務ヒントは記事一覧からどうぞ。保守運用の小さな備えを、メールでも少しずつお届けしています。

関連用語