誰が何を変えたかを追う操作履歴。開発依頼に必要な項目

「履歴を残したい」という依頼には、操作履歴の開発要件として見積もりに必要な条件が足りません。発注前に、記録イベント、変更前後、閲覧権限、保持期間、出力、秘匿項目の六つを分けて決めます。誰が、いつ、何を変えたかを追う目的なら、変更操作と記録項目を別々の欄で指定することが重要です。

たとえば、利用者情報の更新について実行者と日時だけを残しても、「何が変わったか」は特定できません。変更前後を無条件で保存すれば、パスワードやトークンまで履歴へ入るおそれもあります。では、項目を増やせばよいのでしょうか。追跡に必要な差分を選び、残してはいけない値も同時に決める必要があります。

見積依頼では六項目を一枚の仕様票にし、納品時には各欄を受入条件として照合します。まだ残る条件は、対象業務において「何が起きたら確認が必要になるか」です。ここが決まらないまま、開発会社へ記録対象の選定まで委ねると、実装後に必要な操作が抜けていた、または不要な情報まで残ったという認識差が生まれます。

操作履歴の開発要件は六つに分ける

以下は、公式資料を根拠に株式会社adding編集部が整理した運用上の提案です。各行を独立して合意できるようにし、「操作履歴機能一式」のような一括指定を避けます。

例は網羅一覧ではありません。実際の操作名、役割名、対象項目はその業務に合わせて置き換えます。見積依頼の前にシステム要件定義で確認する項目も整理すると、操作履歴だけでなく、対象利用者や権限の前提を開発会社と共有しやすくなります。

記録イベントと記録項目を混ぜない

2026年9月21日時点で、OWASPの公式資料は、監視・警告・報告の水準と内容を要件・設計段階でリスクに応じて定め、それを基に記録対象を選ぶとしています。利用者管理、管理者操作、データのインポート・エクスポートは例示され、データ変更と設定変更も記録を検討する項目です。ただし、これは全システムに必須の網羅一覧ではありません（OWASP Foundation「Logging Cheat Sheet」）。

したがって、発注者は機能一覧を起点に、後から確認したい出来事を選びます。登録、更新、削除を一つの「編集」にまとめるか、個別のイベントにするか。成功時と失敗時のどちらを確認したいか。データ出力を画面閲覧と分けて追うか。判断は対象業務と確認目的に結び付けます。

一方、記録項目は各イベントに付随する情報です。2026年9月21日時点で、NIST SP 800-53のAU-3は、監査記録にイベントの種類、時点、場所、発生源、結果、関係する個人・主体・対象を特定できる情報を含めるよう求めています。また、追加情報は監査要件に明示的に必要なものへ限定することも検討事項としています（National Institute of Standards and Technology「SP 800-53 Revision 5.1」）。

この整理から、仕様票には「記録する操作」と「一件の履歴が持つ項目」を別欄で置きます。変更操作では、日時、実行者、対象、操作、結果に加え、追跡目的に必要な変更前後を指定します。値全体の再現が不要な業務では、変化した項目の差分に絞る選択もできます。変更前後の保存はNISTの一律指定には含まれません。「何を変えたか」を追う目的から導いた運用上の提案です。

変更前後と秘匿項目は同時に決める

変更前後を残す欄には、対象項目名と、その扱いを「記録する・マスキングする・記録しない」に分けて記入します。顧客名は記録する、連絡先は一部を隠す、認証に関わる秘密は記録しない、というように、項目単位で判断できる形にします。ここで挙げる扱いは仕様票の作り方であり、どの業務項目をどれに分類するかは発注者側の情報管理方針に従います。

2026年9月21日時点でOWASPは、アクセストークン、認証パスワード、暗号鍵などの主要な秘密や、機微な個人データなどを、通常はログへ直接記録する対象から外し、除去、マスキング、サニタイズ、ハッシュ化または暗号化の対象にするとしています（OWASP Foundation「ログから除外するデータ」）。具体的な分類は情報管理方針によって変わります。秘密情報が変更前後へ露出しないことは受入確認に含めます。

確認操作も具体化します。秘匿対象の項目を更新し、履歴画面と出力結果の両方を見る。記録しない指定なら値が存在しないこと、マスキング指定なら決めた表示になることを確かめます。「画面では隠れるが、ファイルには出る」という抜けを防ぐため、出力欄と同じ条件で確認するのが要点です。

閲覧権限・保持期間・出力を別の受入条件にする

履歴の内容が正しくても、閲覧者が無制限だったり、必要な時期より前に消えたりすれば追跡に使えません。保持の終期が未定のまま残し続ける運用も、削除時期を判定できません。閲覧、保持、出力は別の挙動なので、それぞれに合否を置きます。

2026年9月21日時点でOWASPは、保存済みログを不正なアクセス・変更・削除から保護し、ログへのアクセスを記録・監視し、読取権限を制限して定期的に見直すとしています（OWASP Foundation「ログの保護」）。仕様票には、閲覧を許可する役割と許可しない役割の双方を明記します。操作履歴そのものへのアクセスをどのように記録・確認するかも、必要なら別の対象イベントとして追加します。

保持期間には、発注者が根拠を添えます。OWASPは、ログ、デバッグログ、バックアップ、複製、抽出物を必要な期間中は保持し、期間の終了後は保持を終えるとしています。法令・規制・契約上の義務が期間へ影響し得るとも説明していますが、固定の日数は示していません（OWASP Foundation「ログの廃棄」）。発注者が適用する契約や社内運用を確認し、その結果を要件にします。納品時には、実際の長期経過を待つ代わりに、削除対象、起算点、削除処理を設定とテスト条件で照合します。

出力欄では、画面検索、ファイル、外部連携を分けます。OWASPは、他システムへイベントデータやログファイルを記録・送信する場合に標準形式と安全なプロトコルを用いること、信頼できないネットワークを通じた分析・報告用の送信にも安全な転送プロトコルを用いることを挙げています。特定の出力形式は一律の必須条件として示されていません（OWASP Foundation「イベントデータの記録先と転送時の保護」）。形式名、出力できる役割、含める項目、秘匿処理、外部へ送る場合の転送条件を一組として合意します。

見積依頼・納品確認・追加範囲を同じ仕様票でつなぐ

見積依頼には、六項目の各欄について「今回含める」「含めない」「要確認」を付けます。未決定を空欄にすると、実装対象外なのか判断待ちなのか区別できません。対象イベントごとに必要な記録項目を対応させ、秘匿項目だけは横断して確認できる一覧にします。システム開発の見積もりで確認したい条件と合わせて提示すれば、機能範囲と未決事項を切り分けた相談ができます。

納品時は、仕様票をそのまま確認表にします。指定イベントを実行して履歴が生成されること、変更前後が指定どおりであること、非許可役割から閲覧・出力できないこと、秘密情報が残らないことを照合します。保持は削除対象と処理を、出力は検索条件・項目・権限・転送条件を確認します。公式資料の推奨内容と、今回の契約で実装すると決めた内容を分け、合意した欄を受入基準にします。

契約後に新しい対象画面、操作種別、比較表示、役割別制御、ファイル形式、外部連携、マスキング方式を加えるなら、まず該当欄の変更として扱います。元の仕様票との差が見えるため、当初範囲の不具合なのか追加開発なのかを判断しやすくなります。

誰が、いつ、何を変えたかを追える状態には、履歴の存在に加え、内容と扱いの条件が要ります。対象となる変更操作が選ばれ、実行者・日時・対象・結果と必要な差分を照合でき、許可された人だけが確認でき、決めた保持と出力、秘匿処理が守られている状態です。六項目を分けた仕様票なら、その状態を見積依頼の前提から納品時の合否まで一貫して示せます。

費用、期間、契約、法務・税務上の扱いは条件により異なります。記事の確認日とリンク先の一次情報を確認し、個別判断は専門家へご相談ください。

システム開発・発注ガイドへ戻る