【2026年最新】記録に何を残すか|設計の7原則と障害時に役立つ書き方

【2026年最新】記録に何を残すか|設計の7原則と障害時に役立つ書き方

障害が起きたとき、記録に必要な情報が残っていなければ原因を追えません。逆に、すべてを記録すれば量が膨大になり、肝心の情報が埋もれます。この記事では、何を残し、何を残さないかの判断基準を整理します。

【結論先出し】判断の材料になるものだけを残します。
①いつ ②誰が ③何をして ④どうなったか
この4つが揃っていれば、大半の調査は進みます。
秘密情報は絶対に残さないでください。記録は複製され、長期間保管されます。
目次

設計の7原則

【結論】後から検索できる形にしてください。

1. 構造化する

自由な文章ではなく、項目ごとに分けた形式で出力します。機械で検索や集計ができるようになり、調査の速度が変わります。

2. 一意の識別子を付ける

1つの処理の流れに固有の番号を振り、関連する記録すべてに含めます。これがあると、複数の場所に散った記録を1本の線につなげられます。

3. 時刻を統一する

環境ごとに時刻の基準が違うと、順序が分からなくなります。世界標準時で記録し、表示のときに変換するのが確実です。

4. 段階を分ける

情報、警告、エラーといった段階を設けます。通常時は重要なものだけを出し、調査時に詳細を出す切り替えができるようにしてください。

5. 文脈を含める

「処理に失敗しました」だけでは追えません。何の処理で、どの対象に対して、どういう条件で失敗したのかを含めてください。

6. 秘密情報を除外する

パスワード、認証情報、個人情報は記録しないでください。記録は複製され、長期間保管されます。

7. 量を制御する

すべてを記録すると保管費用が増え、必要な情報が埋もれます。頻度の高い処理では、間引く仕組みも検討してください。

段階 出す内容 通常時の扱い
詳細 変数の中身、分岐の経過 出さない
情報 処理の開始と完了 出す
警告 想定外だが継続可能 出す
エラー 処理が失敗した 出す・通知する

残すべき情報

【結論】再現に必要なものです。

いつ

ミリ秒まで含めた時刻です。秒単位では、同時に発生した処理の順序が分かりません。

どこで

どのサーバー、どの処理、どの行で発生したかです。複数台で動いている場合、これがないと絞り込めません。

誰が

利用者を識別する情報です。ただし個人を直接特定できる情報ではなく、内部の識別番号を使ってください。

何をして

実行された操作の内容です。受け取った値も含めると調査しやすくなりますが、秘密情報は除外します。

どうなったか

成功か失敗か、失敗ならその理由です。エラーの内容だけでなく、そこに至る経過も残っていると原因が絞れます。

残してはいけない情報

【結論】漏れたら取り返せないものです。

認証に関わるもの

パスワード、鍵、認証用の文字列。これらが記録に残ると、記録を見られる全員が権限を持つのと同じになります。

個人を特定する情報

氏名、住所、電話番号、生年月日。調査に必要なら内部の識別番号を使い、必要なときだけ照合してください。

決済に関わるもの

カード番号、口座情報。これらは記録に残すこと自体が規約違反となる場合があります。

受け取った内容の全体

外部から受け取った内容をそのまま記録すると、上記が含まれることがあります。必要な項目だけを選んで出力してください。

保管期間を決める

【結論】用途によって必要な期間が違います。

短期の調査用

障害対応に使う詳細な記録は、数日から数週間で足ります。量が多いため、長期保管には向きません。

中期の分析用

利用状況の分析には数か月分が必要です。集計した形にすれば、量を抑えられます。

長期の監査用

誰がいつ何をしたかの記録は、要件によって年単位の保管が求められることがあります。

削除の仕組み

期間を過ぎたものを自動で削除する設定を入れてください。手作業では必ず溜まります。

調査で使うときの工夫

【結論】検索できる形にしておくことが前提です。

識別子で追う

1つの処理に振った番号で検索すれば、関連する記録がすべて出てきます。この設計があるかどうかで、調査の時間が大きく変わります。

時刻で絞る

障害が起きた時刻の前後を確認します。ここで時刻の基準が揃っていないと、突き合わせができません。

集計する

エラーの発生件数を時系列で見ると、いつから増えたかが分かります。原因となった変更の時刻と照合できます。

正常時と比べる

失敗した記録だけを見ても、何が異常か分からないことがあります。成功したときの記録と並べてください。

よくある失敗

【結論】書く量の判断を誤ると、どちらにも振れます。

少なすぎる

「エラーが発生しました」とだけ出力していると、何も分かりません。せめて処理の名前と対象は含めてください。

多すぎる

すべての処理で詳細を出すと、量が膨大になります。保管費用も増え、検索も遅くなります。

形式がばらばら

担当者ごとに書き方が違うと、機械的な処理ができません。形式を決めて共有してください。

本番で詳細を出したまま

調査のために詳細を出す設定にしたまま戻し忘れると、量が急増します。設定の見直しを習慣にしてください。

よくある質問(FAQ)

Q1. どの段階まで通常時に出すべきですか

情報以上が一般的です。詳細は調査時のみ有効にしてください。

Q2. 個人情報を残さないと調査できません

内部の識別番号を使い、必要なときだけ照合してください。記録そのものに含める必要はありません。

Q3. 保管期間はどう決めますか

用途で分けてください。詳細は短期、監査用は長期です。

Q4. 構造化とは具体的に何ですか

項目名と値の組み合わせで出力する形式です。機械が解析できる形になります。

Q5. 個人開発でもここまで必要ですか

最低限、時刻と処理の名前、エラーの内容があれば足ります。規模に応じて増やしてください。

Q6. 誤って秘密情報を記録してしまいました

該当の記録を削除し、その情報を無効化してください。削除より無効化が優先です。

まとめ

記録に残すべきは、いつ、どこで、誰が、何をして、どうなったかの5点です。これが揃っていれば、大半の調査は進みます。

1つの処理の流れに固有の番号を振り、関連する記録すべてに含めてください。この設計があると、複数の場所に散った記録を1本の線につなげられます。

パスワード、認証情報、個人情報、決済情報は残さないでください。記録は複製され、長期間保管されます。漏れたときに取り返しがつきません。

段階を分けて、通常時は重要なものだけを出す設定にしてください。すべてを詳細に記録すると、保管費用が増えるうえ、肝心の情報が埋もれて見つからなくなります。

この記事を書いた人

まじこ(マルヒデ代表)

中卒・うつ病から生成AIを独学し事業を立ち上げた実践者。Kindle著者。プロフィール詳細 →

𝕏 @ore_chusotsu

📱 運営の裏側・最新情報はXで発信中 → @ore_chusotsu

目次