タグ: 再入力防止

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

問い合わせを登録する。見積情報を保存する。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インポートのプレビュー・ロールバック設計
• 二重送信を防ぐ設計
• お問い合わせ