小型業務ツールや社内フォームを作るとき、機能そのものには注意が向きます。
問い合わせを登録する。見積情報を保存する。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つから確認します。
- 問い合わせ登録画面
- 見積・請求・案件登録画面
- CSV取り込み画面
- 添付ファイルアップロード画面
- 承認・確認・ステータス変更画面
これらは、入力項目が多く、後工程への影響が大きく、担当者確認が発生しやすい画面です。
まずは「よく聞かれるエラー」「入力し直しが多い項目」「担当者が代わりに直している項目」を3つだけ選びます。
その3つについて、原因、場所、直し方、次の操作が出ているか確認します。
小型ツール化するときに決めること
スプレッドシートやメール運用から小型Webツールへ移す場合は、エラー文言も要件に入れておくと後で困りにくくなります。
相談前に次の項目を整理しておくと、画面設計が具体化します。
- 必須にしたい項目
- 空欄でも進めたい項目
- 日付、金額、電話番号、メールなど形式をそろえたい項目
- 登録前に重複確認したい項目
- 誰でも編集できる項目と、管理者だけが変更する項目
- 保存できなかったときに下書き保存するか
- 外部サービス連携が失敗したとき、どこまで成功扱いにするか
- 利用者に見せる文言と、管理者が見るログを分けるか
機能一覧だけを決めると、正常に動いたときの画面しか見えません。
実務では、未入力、形式違い、重複、通信失敗、権限不足のような「うまくいかない時」の設計が、日々の使いやすさを左右します。
YOSHIO.devへ相談する前に整理したいこと
YOSHIO.devで小型業務ツールや業務自動化を相談する場合、最初から完璧な仕様書は不要です。
ただし、次の情報があると、エラー文言や入力画面の改善範囲を決めやすくなります。
- 使っているフォーム、スプレッドシート、既存ツールの画面
- よく起きる入力ミスや問い合わせ
- 入力内容が消える、保存できない、重複するなどの具体例
- どの項目が必須か、任意か
- 登録後に誰が確認するか
- エラー時に手動で戻せる運用があるか
- 入力内容やエラーログに個人情報が含まれるか
小型ツールは、大きな業務システムでなくても作れます。
まずは、今あるフォームのエラー文言を直す、入力内容を保持する、重複候補を出す、エラー件数を集計するなど、小さな改善から始められます。
「使える機能」だけでなく「失敗したときに迷わない画面」にしておくと、社内で使われ続けるツールになりやすくなります。
よくある質問
エラー文言はどこまで細かく書くべきですか？
原因、場所、直し方、次の操作が分かる程度まで書くのがおすすめです。長い説明を毎回出すより、項目の近くに短い文言を出し、必要なら詳細ヘルプや既存データへのリンクを用意します。
「入力内容を確認してください」だけではだめですか？
入力項目が少ない場合は伝わることもありますが、業務ツールではどの項目をどう直すか分からず、問い合わせや再入力が増えやすくなります。少なくとも問題の項目名と修正例は表示した方が安全です。
エラー時に入力内容を保存しても大丈夫ですか？
業務内容によります。下書き保存できると再入力を減らせますが、個人情報や機密情報を含む場合は保存期間、閲覧権限、削除方法を決める必要があります。改善用ログには入力内容そのものではなく、エラー分類だけを残す方法もあります。
重複チェックは必ず登録を止めるべきですか？
完全一致で明らかに同じデータなら止める方が安全です。一方で、顧客名が似ているだけ、同じ会社で別案件の可能性がある場合は、候補を見せて利用者に選ばせる方が実務に合うことがあります。
小型ツール開発の相談前に何を用意すればよいですか？
現在の入力画面、スプレッドシート、よく起きる入力ミス、困っているエラー文言、手動で直している作業を用意すると十分です。そこから、入力チェック、エラー表示、ログ、通知、権限の範囲を小さく整理できます。
コメントを残す