タグ: 運用設計

小型業務ツールを複数人で使い始めると、こんな確認が増えることがあります。

「顧客の電話番号が変わっている」

「この見積金額は誰が直した？」

「案件のステータスが完了になったのはいつ？」

「削除したデータを戻したいが、何が消えたのか分からない」

変更した本人が覚えていれば解決できます。しかし、担当者が休み、共有アカウントを使い、数日前の操作を確認したい場面では、記憶やチャットの履歴だけでは追えません。

そこで役立つのが、操作履歴と変更履歴です。

ただし、何でも記録すればよいわけではありません。履歴が多すぎると必要な変更を探せず、個人情報やAPIキーまで残すと別の管理リスクが生まれます。

この記事では、小規模事業者や少人数チーム向けに、小型業務ツールへ履歴機能を付けるときの残す項目、画面の見せ方、共有アカウント、保存期間、機密情報の扱いを整理します。

結論：重要な変更だけを「いつ・誰が・何を・どう変えた」で残す

最初からすべてのクリックを記録する必要はありません。

まずは、あとから確認できないと業務に困る操作を選びます。

• 顧客名、住所、連絡先の変更
• 見積金額、請求金額、数量の変更
• 担当者、期限、ステータスの変更
• 承認、差し戻し、完了の操作
• データの削除、アーカイブ、復元
• 権限の追加・変更・削除
• CSVの一括取り込み・一括出力
• 外部サービスへの送信・再送

そのうえで、最低限次の項目を残します。

項目	例	確認できること
日時	2026-09-20 10:42	いつ起きたか
操作者	利用者ID 023 / 山田	誰の操作か
対象	顧客 C-1042	どのデータか
操作	連絡先を更新	何をしたか
変更内容	電話番号の末尾を 1200 から 1280 へ変更	どう変わったか
結果	成功 / 失敗	操作が完了したか
理由・メモ	顧客から訂正依頼	なぜ変えたか

OWASPのLogging Cheat Sheetでも、ログの基本要素として、いつ、どこで、誰が、何をしたかを識別できる情報が挙げられています。ただし、実際に必要な項目はツールの目的と扱うデータに合わせて絞る必要があります。

操作履歴・変更履歴・エラーログは役割が違う

「ログ」という言葉で全部をまとめると、必要な画面や閲覧権限が曖昧になります。

小型業務ツールでは、少なくとも次の3つを分けて考えると整理しやすくなります。

種類	主な目的	例	主な閲覧者
操作履歴	誰が何をしたか確認する	承認した、CSVを出力した、削除した	利用者、管理者
変更履歴	データがどう変わったか確認する	金額が5万円から6万円になった	利用者、管理者
エラーログ	失敗原因を調べる	メールAPIがタイムアウトした	管理者、開発者

利用者が知りたいのは「担当者が9月20日に金額を変更した」という業務上の事実です。

一方、開発者が知りたいのは「保存処理の途中で外部APIがタイムアウトした」という技術的な情報です。

この2つを同じ画面に出すと、利用者には難しく、開発者には情報が足りない画面になりがちです。

日常業務で見る履歴と、障害調査で見るログは、保存場所や表示方法、閲覧できる人を分ける方が扱いやすくなります。

先に「履歴を何に使うか」を決める

履歴機能を作る前に、目的を一文で決めます。

たとえば次のような目的です。

• 顧客から問い合わせがあったときに変更経緯を説明する
• 誤操作が起きたときに変更前の内容を確認する
• 承認や差し戻しの流れを追えるようにする
• 担当者の引き継ぎ時に過去の判断を確認する
• 権限変更やデータ出力の不審な操作を確認する

目的が「誤操作の確認」なら、変更前と変更後が重要です。

目的が「承認の確認」なら、承認者、日時、対象、コメントが重要です。

目的が「データ出力の管理」なら、出力者、件数、検索条件、出力結果が重要です。

目的を決めずに記録項目を増やすと、履歴はあるのに必要な答えが出ない状態になります。

最初に残したい7種類の操作

小型ツールで優先しやすいのは、業務への影響が大きい操作です。

1. 登録と更新

新しいデータを作った人と、重要項目を更新した人を残します。

すべての項目を保存する必要はなく、顧客名、金額、期限、担当者、ステータスなど、後工程に影響する項目から始めます。

2. 削除・アーカイブ・復元

データを見えなくした操作は、対象、操作者、日時、理由を残します。

完全削除する場合も、削除した事実まで同時に消える設計では、あとから経緯を確認できません。通常画面の削除操作と、管理上の履歴削除は分けて考えます。

3. ステータス変更

受付中、対応中、確認待ち、完了、取消など、業務の進行を変える操作を残します。

特に、完了や取消へ進めた操作は、誰が判断したか分かると問い合わせ対応がしやすくなります。

4. 承認・差し戻し

承認者、承認日時、差し戻し理由を残します。

コメントを必須にするかは業務によります。すべての承認で長文を求めると負担になるため、高額案件や例外時だけ理由を必須にする方法もあります。

5. 権限変更

管理者の追加、閲覧範囲の変更、退職者アカウントの停止などを残します。

権限変更は、変更した本人だけが履歴を削除できる状態にしない方が安全です。

6. CSVの取り込み・出力

取り込みでは、ファイル名だけでなく、対象件数、成功件数、失敗件数、実行者を残します。

出力では、誰が何件を出力したか、どの条件で絞ったかを残すと、個人情報や顧客情報の持ち出し確認にも使えます。ただし、出力内容そのものを履歴へ丸ごと複製すると、管理対象が増える点に注意が必要です。

7. 外部連携と再実行

メール、チャット通知、会計サービス、外部APIへの送信結果を残します。

登録は成功したが通知だけ失敗した場合は、「全体が失敗」とまとめず、どこまで成功したかを分けて残します。

変更前と変更後は「差分」で見せる

変更履歴で大切なのは、履歴の件数より、違いが分かることです。

たとえば顧客データ全体を毎回表示すると、どこが変わったのか探す必要があります。

次のように、変わった項目だけを見せる方が実務向きです。

日時	操作者	項目	変更前	変更後
9/20 10:42	山田	担当者	佐藤	鈴木
9/20 10:43	山田	納期	9/25	9/27
9/20 10:44	山田	ステータス	対応中	確認待ち

長い備考欄では、全文を横に並べるより、変更部分を強調表示する、履歴を開いたときだけ全文を見せるなどの方法があります。

金額や個人情報は、閲覧権限によって伏せ字にすることも検討します。

共有アカウントでは「誰が」が分からない

操作履歴を入れても、全員が同じIDでログインしていれば、履歴には同じ操作者しか残りません。

これでは「共有アカウントが変更した」ことは分かっても、実際の担当者は分かりません。

誰が変更したかを確認したいなら、基本は利用者ごとのアカウントに分けます。

どうしても共有端末や簡易運用が必要な場合は、操作前に担当者を選ぶ、個人コードを入れるなどの方法もあります。ただし、代理入力ができるため、本人確認の強さは個別ログインより下がります。

ツールの手軽さと履歴の信頼性はトレードオフです。重要な金額、権限、顧客情報を扱うほど、個別アカウントと適切な権限管理が必要になります。

ログに残してはいけない情報を決める

履歴は確認に役立つ一方で、機密情報の複製場所にもなります。

次の情報は、原則としてそのまま記録しない設計を検討します。

• パスワード
• APIキー、アクセストークン
• セッションID
• データベース接続情報
• クレジットカード情報、口座情報
• 本文全体を残す必要がない個人情報
• 問い合わせ本文や社内メモに含まれる機密情報

たとえばメールアドレスを変更した事実は必要でも、履歴一覧では ya***@example.com のように一部を伏せられる場合があります。

APIキーの更新では、キー本体ではなく「連携用APIキーを更新した」という操作だけを残します。

OWASPも、アクセストークン、パスワード、暗号鍵、機微な個人情報などをログへ直接残さず、削除、マスキング、ハッシュ化、暗号化などを検討するよう案内しています。

履歴を見る画面も設計する

記録だけしても、必要なときに探せなければ使えません。

小型ツールでは、次の2か所があると確認しやすくなります。

各データの履歴タブ

顧客、案件、見積などの詳細画面に「履歴」タブを付けます。

そのデータだけの作成、更新、承認、削除、復元を時系列で表示します。

問い合わせ対応や引き継ぎでは、この画面が主に使われます。

管理者向けの履歴一覧

管理者は、期間、操作者、操作種類、対象、成功・失敗で絞り込めるようにします。

一括出力、権限変更、大量削除、連続した失敗などを確認したい場合に使います。

ただし、履歴を誰でもCSV出力できるようにすると、新しい持ち出し経路になります。履歴の閲覧権限と出力権限は分けて考えます。

履歴そのものを勝手に変えられないようにする

通常の利用者が履歴を編集・削除できると、確認材料としての価値が下がります。

少なくとも次の点を決めます。

• 通常利用者は履歴を閲覧できるが編集できない
• 管理者でも日常画面から履歴を直接書き換えない
• 履歴の削除は保存期間に基づく処理に限定する
• 履歴の閲覧や出力も必要に応じて記録する
• アプリのデータと履歴のバックアップ範囲を決める
• サーバーや端末の時刻とタイムゾーンをそろえる

重要度が高い場合は、追記型で保存する、別の保存先へコピーする、改変を検知する仕組みを入れるなど、履歴を守る設計も検討します。

保存期間は「とりあえず無期限」にしない

履歴を長く残すほど過去を確認しやすくなりますが、保管量と情報管理の負担も増えます。

保存期間は、次の条件から決めます。

• 問い合わせや修正が発生する期間
• 契約、請求、承認の確認に必要な期間
• 社内規程や顧客との取り決め
• 個人情報や機密情報を含むか
• バックアップにも同じ履歴が残るか
• 期限後に自動削除、集計化、匿名化するか

法令や契約で必要な期間は業種や情報によって異なります。該当する場合は、社内の担当者や専門家に確認してください。

小さく始めるなら3画面だけ選ぶ

すべての機能へ一度に履歴を付けると、開発範囲も確認項目も増えます。

まずは次の手順で始めます。

1. 問い合わせが多い画面を1つ選ぶ
2. 金額や顧客情報など影響の大きい画面を1つ選ぶ
3. 削除、権限、CSV出力など管理操作の画面を1つ選ぶ
4. 各画面で「あとから知りたいこと」を3つ書く
5. 必要な履歴項目だけ実装する
6. 1か月使い、探せなかった情報と不要だった情報を見直す

たとえば、顧客詳細、見積、管理者設定の3画面から始めます。

顧客詳細では連絡先と担当者、見積では金額と承認、管理者設定では権限変更を残します。

この範囲なら、「何でも記録する大きな監査システム」にせず、日常業務で本当に見る履歴から作れます。

YOSHIO.devへ相談する前に整理したいこと

YOSHIO.devへ小型業務ツールや業務自動化を相談する場合、完成した仕様書は不要です。

次の情報があると、履歴機能の範囲を決めやすくなります。

• 誰が使うツールか
• 個別アカウントか共有アカウントか
• あとから確認したい操作は何か
• 変更前と変更後の両方が必要な項目は何か
• 履歴を見られる人は誰か
• 個人情報、金額、APIキーなどを扱うか
• 何か月・何年の履歴が必要か
• 誤操作時にデータを戻したいか、確認だけできればよいか
• 現在はチャット、メール、スプレッドシートのどこで経緯を確認しているか

最初は「顧客情報の変更」「見積金額の変更」「削除・復元」のように、困っている3種類だけでも構いません。

記録する項目、見せる画面、閲覧権限、保存期間を一緒に決めることで、開発範囲を小さくしながら「誰が変えたか分からない」状態を減らせます。

よくある質問

関連リンク

• 小型業務ツールのログイン・権限設計
• 削除・アーカイブ・復元のルール
• 一覧画面の検索・絞り込み設計
• 小型業務ツールの要件整理
• 業務自動化
• お問い合わせ

小型業務ツールや社内フォームを作るとき、機能そのものには注意が向きます。

問い合わせを登録する。見積情報を保存する。CSVを取り込む。担当者へ通知する。

しかし実務で意外と詰まりやすいのが、入力エラーが出た後の画面です。

「エラーが発生しました」

「入力内容を確認してください」

このような表示だけでは、利用者はどこを直せばよいか分かりません。入力済みの内容が消えたり、画面上部に戻されたり、同じデータをもう一度入れ直す必要があると、ツールへの不信感も増えます。

この記事では、小規模事業者や少人数チーム向けに、小型業務ツールで決めておきたいエラー文言、表示位置、再入力防止、エラーログの設計を整理します。

結論：エラー文言は「原因・場所・直し方・次の操作」まで書く

入力エラーで必要なのは、赤文字を出すことではありません。

利用者が迷わず直せる情報を出すことです。

最低限、次の4つを入れます。

入れること	例	目的
原因	メールアドレスの形式が正しくありません	なぜ止まったか分かる
場所	連絡先メール	どの項目を見るか分かる
直し方	name@example.com の形式で入力してください	何に変えればよいか分かる
次の操作	修正後に「保存」を押してください	どこから再開するか分かる

反対に、次のような文言だけでは不十分です。

• エラーが発生しました
• 入力内容を確認してください
• 保存できませんでした
• 不正な値です
• もう一度お試しください

システム側から見ると正しい表現でも、利用者から見ると「何をすればよいか分からない」状態です。

「入力ミス」と「処理失敗」を分ける

エラーを全部同じ表示にすると、利用者も担当者も原因を切り分けられません。

まずは、次のように分類します。

エラーの種類	例	画面で伝えること
入力不足	必須項目が空欄	どの項目が必要か
形式違い	メール、電話番号、日付、金額	正しい形式の例
範囲外	期限が過去、数量が0、金額が上限超え	入力できる範囲
重複	同じ受付ID、同じ顧客と日付	既存データの確認方法
権限不足	編集権限がない、承認者ではない	誰に依頼するか
通信・外部連携	メール送信失敗、API接続失敗	入力内容は残っているか
システム障害	予期しない保存失敗	問い合わせ時に伝える番号

たとえば「保存できませんでした」だけでは、利用者の入力が悪いのか、権限がないのか、外部サービスが止まっているのか分かりません。

「連絡先メールの形式が正しくないため保存できません」と「メール送信サービスへ接続できないため、登録は保存しましたが通知は未送信です」では、次に取る行動がまったく違います。

エラー文言は、技術的な例外名ではなく、業務上の次の行動に合わせて分けます。

エラー箇所は画面の上だけでなく項目の近くに出す

画面上部に赤いメッセージを1つだけ出すと、どの項目に問題があるか探す必要があります。

入力項目が少ないフォームならまだ対応できますが、見積、顧客登録、問い合わせ受付、CSV取り込み画面では負担が大きくなります。

おすすめは、全体メッセージと項目ごとのメッセージを分けることです。

表示位置	役割	文言例
画面上部	何件エラーがあるか伝える	3か所を修正すると保存できます
項目の下	その項目の直し方を伝える	郵便番号は7桁の数字で入力してください
ボタン付近	次の操作を伝える	修正後にもう一度「保存」を押してください
一覧行	どの行が止まったか伝える	12行目: 顧客名が空欄です

スマホ画面では、エラー箇所まで自動でスクロールする、エラー項目にフォーカスを移す、エラー数を上部に表示するなどの配慮も必要です。

「赤くなっているところを探してください」ではなく、「ここをこう直してください」と示す方が、問い合わせや操作説明を減らせます。

入力済みの内容を消さない

エラーが出たあとに入力内容が消えると、利用者は一気に離れます。

業務ツールでは、長い備考、顧客情報、見積明細、相談内容、添付ファイル情報を入れることがあります。これが消えると、再入力だけでなく、内容の抜け漏れも起きます。

エラー画面で守りたいことは次の通りです。

• 入力済みの文字を残す
• 選択済みの項目を残す
• 添付ファイルの状態を分かるようにする
• エラーのない項目まで入力し直させない
• 戻るボタンで内容が消えない
• 通信失敗でも下書き保存できる場合は保存する
• 二重送信を防ぐため、処理中の表示を出す

特に、問い合わせフォームや見積作成画面では「保存できなかった」だけでなく、「入力内容は保持されています」「下書きとして保存しました」「通知だけ失敗しました」のように、どこまで成功したかを分けて伝えることが重要です。

文言は責める言い方にしない

エラー文言は、利用者のミスを責める言い方にしない方がよいです。

たとえば、次のような表現は避けます。

• 入力が間違っています
• 正しく入力してください
• 不正な操作です
• 無効なデータです

業務では、利用者が悪いとは限りません。選択肢が足りない、説明が分かりにくい、古いデータが残っている、権限ルールが変わったなど、ツール側の設計が原因のこともあります。

文言は、責任の所在よりも直し方を優先します。

避けたい文言	改善例
入力が間違っています	電話番号は数字のみで入力してください
不正な日付です	納期は今日以降の日付を選択してください
保存できません	同じ受付IDがあるため保存できません。既存データを確認してください
権限がありません	この項目は管理者だけが変更できます。変更が必要な場合は管理者へ依頼してください
エラーが発生しました	登録は保存しましたが、通知メールの送信に失敗しました。担当者へ手動で共有してください

小さな違いですが、利用者の行動は大きく変わります。

重複エラーは「止める」だけでなく確認先を出す

小型ツールで多いのが、重複登録です。

同じ問い合わせを2回送る。同じ顧客を別名で登録する。同じCSVをもう一度取り込む。同じ見積番号を使ってしまう。

重複チェックを入れること自体は大切ですが、「重複しています」だけでは不十分です。

利用者が知りたいのは、どのデータと重複しているのか、登録をやめるべきなのか、既存データを更新すべきなのかです。

状況	文言例	次の導線
同じ受付IDがある	受付ID A-1042 は登録済みです	既存受付を開く
顧客名とメールが近い	似た顧客が2件あります	候補を確認する
同じCSVを再取り込み	同じファイル名と件数の取り込み履歴があります	履歴を見る
同じ見積を複製	同じ顧客・金額・日付の見積があります	複製として保存するか選ぶ

重複の可能性が高いなら止める。似ているだけなら候補を見せる。業務上あり得る重複なら理由を書いて進める。

この違いを決めておくと、強すぎるエラーで業務を止めることも、弱すぎる警告で重複を増やすことも避けやすくなります。

エラーをログに残すと改善しやすい

エラー文言は、画面だけの問題ではありません。

どのエラーが何回起きているかを残すと、画面改善や業務ルールの見直しに使えます。

最初は、次のような項目で十分です。

ログ項目	例	見るポイント
発生日時	2026-09-06 10:20	特定時間に集中していないか
画面名	見積登録	どの画面が詰まりやすいか
エラー分類	入力不足、形式違い、重複、通信失敗	改善先を分ける
項目名	連絡先メール、納期、受付ID	分かりにくい項目を探す
表示文言	納期は今日以降の日付を選択してください	文言が機能しているか
次の結果	修正後に保存、離脱、担当者対応	自力で解決できたか

ただし、入力内容そのものをすべてログに残す必要はありません。

メールアドレス、電話番号、顧客名、相談内容、金額などをそのまま残すと、別の管理リスクが生まれます。改善目的なら、分類、項目名、件数、結果だけで足りることも多いです。

エラー文言を直したあと、同じエラーで問い合わせが減ったか、修正後に保存まで進めているかを見ると、改善効果を確認できます。

まず見直す5つの画面

すべての画面を一度に直す必要はありません。

小規模に始めるなら、次の5つから確認します。

1. 問い合わせ登録画面
2. 見積・請求・案件登録画面
3. CSV取り込み画面
4. 添付ファイルアップロード画面
5. 承認・確認・ステータス変更画面

これらは、入力項目が多く、後工程への影響が大きく、担当者確認が発生しやすい画面です。

まずは「よく聞かれるエラー」「入力し直しが多い項目」「担当者が代わりに直している項目」を3つだけ選びます。

その3つについて、原因、場所、直し方、次の操作が出ているか確認します。

小型ツール化するときに決めること

スプレッドシートやメール運用から小型Webツールへ移す場合は、エラー文言も要件に入れておくと後で困りにくくなります。

相談前に次の項目を整理しておくと、画面設計が具体化します。

• 必須にしたい項目
• 空欄でも進めたい項目
• 日付、金額、電話番号、メールなど形式をそろえたい項目
• 登録前に重複確認したい項目
• 誰でも編集できる項目と、管理者だけが変更する項目
• 保存できなかったときに下書き保存するか
• 外部サービス連携が失敗したとき、どこまで成功扱いにするか
• 利用者に見せる文言と、管理者が見るログを分けるか

機能一覧だけを決めると、正常に動いたときの画面しか見えません。

実務では、未入力、形式違い、重複、通信失敗、権限不足のような「うまくいかない時」の設計が、日々の使いやすさを左右します。

YOSHIO.devへ相談する前に整理したいこと

YOSHIO.devで小型業務ツールや業務自動化を相談する場合、最初から完璧な仕様書は不要です。

ただし、次の情報があると、エラー文言や入力画面の改善範囲を決めやすくなります。

• 使っているフォーム、スプレッドシート、既存ツールの画面
• よく起きる入力ミスや問い合わせ
• 入力内容が消える、保存できない、重複するなどの具体例
• どの項目が必須か、任意か
• 登録後に誰が確認するか
• エラー時に手動で戻せる運用があるか
• 入力内容やエラーログに個人情報が含まれるか

小型ツールは、大きな業務システムでなくても作れます。

まずは、今あるフォームのエラー文言を直す、入力内容を保持する、重複候補を出す、エラー件数を集計するなど、小さな改善から始められます。

「使える機能」だけでなく「失敗したときに迷わない画面」にしておくと、社内で使われ続けるツールになりやすくなります。

よくある質問

関連リンク

• 業務自動化
• スプレッドシート管理の限界サイン
• 小型業務ツールの要件整理
• CSVインポートのプレビュー・ロールバック設計
• 二重送信を防ぐ設計
• お問い合わせ

問い合わせ、案件、見積、顧客、制作物、タスクを管理する小型業務ツールを作ると、「不要なデータを消したい」という要望が出ます。

しかし、削除ボタンを付けるだけでは危険です。担当者が間違えて案件を消す。顧客を消したら見積や対応履歴まで見えなくなる。必要なデータだと分かっても戻せない。誰がいつ消したか分からない。

小型ツールは少人数で使うことが多く、専任の管理者がいない場合もあります。だからこそ、完全削除より先に、アーカイブ、削除予約、復元、権限を決める必要があります。

結論：通常操作では完全削除させず、まずアーカイブする

操作	状態	向いている場面
非表示	一覧に出さないが、すぐ戻せる	完了済みを普段の画面から外す
アーカイブ	通常一覧から外し、検索・復元できる	古い案件、終了した顧客、過去の制作物
完全削除	保存データを消し、原則戻せない	保存義務がなく、削除が確定したデータ

通常の担当者はアーカイブまで、完全削除は管理者だけにする方法が安全です。さらに7日や30日の削除予約期間を置けば、誤操作に気付く時間を作れます。

削除ボタンだけを付けると起きる事故

• 一覧で隣の行を誤って削除する
• スマホで誤タップする
• 完了と削除を同じ意味で使う
• 顧客を削除して見積や対応履歴まで消える
• 古いデータだと思ったら請求や問い合わせ対応に必要だった
• 退職者や担当変更後も削除権限が残る
• バックアップはあるが1件だけ戻せない
• 誰がいつ削除したか確認できない

「本当に削除しますか？」という確認だけでは十分ではありません。毎日見る確認画面は反射的に押されます。削除後の状態、戻し方、権限まで含めて設計する必要があります。

まず「消したい理由」を分ける

消したい理由	適した対応
一覧が見づらい	完了済みを非表示またはアーカイブ
検索結果に古い情報が出る	状態や有効期限で除外
入力を間違えた	訂正履歴を残して修正
重複登録した	正しいデータへ統合し、重複側をアーカイブ
個人情報を消す必要がある	対象項目と関連データを確認して削除
テストデータが混ざった	テストフラグで分離して一括削除

「画面から見えなくしたい」と「保存データを消したい」は別です。この違いを確認するだけで、完全削除が必要な場面を減らせます。

削除前に決める6項目

1. 誰が削除できるか

閲覧、編集、アーカイブ、復元、完全削除を同じ権限にしない方が安全です。担当者はアーカイブ、管理者は復元と完全削除というように分けます。

2. 何が一緒に消えるか

顧客には案件、見積、請求、対応履歴、添付ファイルが紐づくことがあります。親データを削除した時に関連データまで消えるのか、残るのか、別の顧客へ移せるのかを決めます。削除画面には「関連する見積3件、添付5件があります」のように影響範囲を表示します。

3. いつまで復元できるか

アーカイブは無期限、削除予約は30日、完全削除後は復元不可など、状態を分けます。期限がある場合は、完全削除予定日を表示し、管理者へ事前通知する方法もあります。

4. 何を履歴に残すか

最低限、対象データ、実行者、日時、操作、理由、復元日時を残します。操作履歴を誰が見られるか、何年間残すかも決めます。

5. バックアップから1件戻せるか

バックアップがあっても、システム全体しか戻せない場合があります。1件を戻すために全体を昨日の状態へ巻き戻すと、今日入力した情報が失われます。日常の誤削除は、アーカイブや削除予約の段階で個別に戻せるようにします。

6. 保存期間はあるか

見積、請求、契約、顧客情報には、業務上または法令上の保存が必要な場合があります。反対に、不要になった個人情報を保持し続けることも避ける必要があります。データ種類ごとに確認し、必要なら専門家へ相談します。

安全な削除画面の作り方

• 通常一覧では「アーカイブ」を主操作にする
• 完全削除は詳細画面のメニュー内に置く
• 削除対象の名前やIDを確認画面に出す
• 関連データの件数を表示する
• 復元期限または復元不可を明記する
• 削除理由を選択または短く入力させる
• 削除直後に「元に戻す」を出す
• 複数件削除は管理者だけにする

赤いボタンにするだけでは不十分です。押す前に影響が分かり、押した後に戻せる時間を作ることが重要です。

小さく始める状態設計

状態	通常一覧	検索	復元
使用中	表示	対象	不要
完了	条件により表示	対象	使用中へ戻せる
アーカイブ	非表示	専用検索で対象	可能
削除予約	非表示	管理者のみ	期限内は可能

完全削除は管理者が削除予約一覧から実行します。この形なら、日常の整理と本当の削除を分けられます。

関連リンク

• 小型ツールのログイン・権限設計
• 小型ツールの一覧画面設計
• 業務自動化で二重送信を防ぐ設計
• 業務自動化

よくある質問