多くの業務システムは、長いあいだユーザーにこう要求してきた。

正しく入力してください。
決められた形式で入力してください。
正式名称で入力してください。

住所は都道府県から分けて書く。
商品は正式名称かコードで入力する。
問い合わせ内容は一覧から最も近い種別を選ぶ。
少しでも形式が違えば、エラーで突き返す。

昔は、それが合理的だった。
システムが曖昧さをうまく扱えなかったからだ。

はじめに：エンジニアは、一番大事な話をしていない

生成AIの話題といえば、Claude CodeやCursorで「コードが速く書ける」という話で持ちきりだ。

それは確かに価値がある。でも、同じものを速く作れるようになった話に過ぎない。

生成AIで本当に変わるのは、これまで作れなかったものが作れるようになることだ。プロダクトをプロダクトたらしめる体験の質——そこに生成AIを組み込めるかどうかが、これからの設計者の必須要件になる。

コーディング効率化で盛り上がっている間に、その話が置き去りにされている。具体的には、システム設計の前提が変わり、UIの設計思想まで変わるという話だ。

その象徴が、冒頭の「正しく入力してください」というUIだ。

今までのシステム設計は、曖昧さを外に出す技術だった

ユーザーの入力は、たいてい曖昧だ。言葉は揺れる。情報は足りない。前提は省略される。人間なら補って理解できるが、従来のシステムはそこが苦手だった。

だから設計者は、曖昧さをできるだけ排除する方向でシステムを作ってきた。入力ルールを増やし、項目を細かく分け、プルダウンで縛り、例外は運用で吸収する。

結果として設計の実態はこうなった。

曖昧なケースはエラーにする
備考欄に逃がす
最後は人間が読む
想定外は運用で吸収する

これは怠慢ではない。そうしないと壊れるからだ。システムは気難しい。そしてその気難しさを、だいたいユーザーに負担させてきた。

曖昧さとは、何が厄介なのか

ここでいう曖昧さは、単に「文章がふわっとしている」という意味ではない。システム設計上の曖昧さには、いくつかの顔がある。

1. 表記ゆれ

株式会社ABC、（株）ABC、ABC Inc.、ｴｰﾋﾞｰｼｰ——人間には同じに見える。システムには別物に見える。

2. 内容情報の欠如

郵便番号はあるが都道府県がない。商品名はあるがコードがない。「前回と同じで」と書いてあるが何の前回かわからない。人間は文脈で埋める。システムは困る。

3. 構造情報の欠如

テキストはあるが、カテゴリやマスターIDが紐づいていない。「急ぎの件」と書かれていても、業務フロー上のどの分類コードに当たるか、どの担当者IDに割り当てるかはわからない。人間が脳内で変換していた部分が、システムには渡っていない。

4. 意図未明示

「普通の請求書で」「急ぎで」「赤いやつの小さい版」「例の件」——人間同士ならだいたい通じる。システムは「普通とは」「例とは」で固まる。

5. 正解が一意でない

これはクレームか、相談か。差し戻しか、確認依頼か。こうしたものは「一発で正解を当てる」より候補を出して確認する方が現実的だ。

6. 前提が省略されている

「田中さん経由の件」「前回と同じで」「例のあれ」——人間同士の業務連絡は前提の共有で成り立っている。その前提がシステムには渡っていない。

ここが大事だ。曖昧さの処理とは、必ずしも一発正解マシンを作ることではない。多くの場合必要なのは、曖昧なものを、後続処理しやすい形まで整えることだ。

生成AIが変えたのは、曖昧さを扱う初期コストだ

生成AIは、曖昧さを完璧に理解する魔法ではない。嘘もつくし、揺れるし、たまに妙な自信を出す。そこは油断ならない。

それでも、決定的に違うことがある。曖昧な入力をひとまず解釈し、構造に落としてみるコストが、異常に下がった。

以前なら、自由記述から意図を分類する、表記ゆれを吸収する、不完全な情報から候補を出す——こうしたことは個別にルールを書くか、辞書を作るか、分類器を育てるか、人間に回すしかなかった。

今は違う。まずは生成AIで、曖昧な入力を受け止めてみることができる。何を言いたいのか、何が足りないのか、どの候補が近いのか——こうしたものを、少ない初期実装で試せる。

つまり生成AIは、曖昧さを消す技術というより、曖昧さをいったん受け止め、扱える形に変換する技術として強い。

AIは「答える」より「整える」で効く

生成AIの話をすると、つい「賢い答えを返すもの」として見がちだ。RAGやチャットボットの話に寄りがちなのも、そのせいだと思う。

もちろんそれも大事だ。でも、業務システムで地味に効くのは、もっと手前にある。

雑な入力を受け止めて、下流システムが扱える状態まで整えること。

ユーザーや現場の人は、いつもきれいに入力してくれるわけではない。むしろ大半は雑だ——いや、雑というより自然だ。人間はそういうものだ。問題は、その自然さを、今までシステム側が受け止められなかったことにある。

例1：備考欄を「読めるデータ」に変える

多くの業務システムには備考欄がある。そして多くの現場では、その備考欄に業務の本体が沈んでいる。

「午前中だと助かる」「不在が多いので携帯に」「前回と同じ感じで」「領収書は別で」

従来のシステムでは、これはただの文字列だった。人間が読むしかない。

生成AIを使えば、この曖昧な備考から時間指定の意図、連絡先の扱い変更、請求処理の分岐、過去注文参照の必要性を抽出して構造化できる。重要なのは「文章を読める」ことではない。曖昧な備考を、後工程が使えるデータに変えることだ。

例2：雑な依頼文を、入力フォームの下書きに変える

「前の見積りベースで保守だけ抜いた版ほしい」「田中さん経由の件、急ぎで再提出」——人間ならだいたい通じる。従来のシステムは、こういう曖昧な依頼が苦手だった。

だからこれまでは、案件IDを入力させ、商品コードを指定させ、修正内容を項目ごとに記載させていた。つまり、システムが必要な構造を、最初からユーザーに作らせていた。

生成AIを挟むと、この雑な依頼文から対象案件候補、参照すべき過去見積り、不足情報、確認が必要な論点を整理できる。ここでの価値は、AIが全部やることではない。曖昧な依頼を、確認可能な入力データへ変えることだ。

例3：入力チェックを「拒否」から「補助」に変える

従来のバリデーションは、基本的に門番だった。「住所形式が不正です」「商品コードが不正です」——システムとしては正しい。でもユーザーからすると、かなり不親切だ。

生成AIを入れると、「この住所はたぶんこの構造です」「商品コードは不明ですが候補はこれです」「足りない情報はこの1点です」といった返しができる。

つまり入力チェックが、違うから弾く仕組みから、曖昧さを解いて前に進める仕組みに変わる。

そしてここに、見落とされがちな業務的価値がある。曖昧なテキストをマスターIDやカテゴリコードに変換できるということだ。「株式会社ABC」「（株）ABC」「ABC inc.」という揺れた表記を受け取って、社内マスターの vendor_id: 00123 に名寄せして通す。これまで人手でやっていた正規化・名寄せ・マスタ突合という泥臭い作業が、設計に組み込める。既存の業務システムとの接続コストが劇的に下がる、ということでもある。

ここで本題になる。UIも昔の前提で作る必要があるのか

ここまでの話を突き詰めると、見直すべきなのはバックエンドだけではない。UIそのものだ。

従来のUIは、曖昧さを嫌うシステムのために作られていた。だから、項目を細かく分け、必須入力を増やし、プルダウンで縛り、フォーマット違反をエラーにする設計が合理的だった。

要するに、UIの役割はユーザーを矯正して、システムが扱える形にしてもらうことだった。

生成AIを使って、曖昧な入力を後段で解釈・構造化できるなら、この前提は崩れる。

UIの役割は、最初から正しく入力させることではなく、自然に渡された情報から、必要な構造へ育てることに変わっていく。

ユーザーは「入力する人」から「確認する人」になる

従来のUIでは、ユーザーは「何をどの形式で入れるべきか考え、正しく入力する人」だった。

生成AI前提のUIでは、ユーザーはむしろ「システムが解釈した内容が合っているか確認する人」に近づく。

人は一般に、ゼロから正しく埋めるより、出てきた案を見て直す方が楽だ。だからUIも、空欄を埋めさせる・コードを覚えさせる・どの分類か考えさせるより、推定結果を見せる・候補を並べる・足りない点だけ聞く、という方向に寄っていく。

最初は大きなテキスト欄だけでもよいかもしれない。「やりたいことをそのまま書いてください」——そこからシステム側が構造を抽出して確認UIを返す。フォームは、最初から完成している必要はない。あとから立ち上がってくるものに変わる。

入力は、テキストですらないかもしれない

曖昧さを扱えるようになると、入力形式そのものも見直せる。

たとえば現場確認や保守対応では、どこが壊れているか・型番は何かを文章で書かせるより、写真を1枚上げてもらった方が早いことがある。画像から製品候補・破損箇所・確認が必要な論点を推定し、必要な質問だけ返せる。従来は写真は補足資料だった。これからは一次入力そのものになりうる。

UI/UXの問いも、「どう正しく入力させるか」から「どう自然に渡してもらい、最後に必要な形へ整えるか」に変わる。

ただし、AIに確定権を渡す話ではない

曖昧さを扱えるからといって、AIにそのまま最終判断まで任せていいわけではない。強い設計は、役割分担がはっきりしている。

AIに任せると強いもの：曖昧な入力の解釈、自由記述の構造化、表記ゆれの正規化、候補抽出、不足情報の洗い出し

決定論で守るべきもの：認証・認可、課金、在庫反映、契約確定、金額計算、監査ログ、外部システムへの確定連携

AIは、確定する層ではなく、**曖昧さをほどいて整える層に置くと強い。**ここを混ぜると事故る。ここを分けるとかなり使える。

設計者が変えるべき問い

従来はこう考えていた。「システムで安定して扱えるものは何か」——だから要件は、その枠の中で削られていった。

これからは、先にこう考えた方がいい。

「人間が曖昧さをなんとなく読んで補っている場所はどこか。それをシステム側で受け止められないか」

この問いに変わると、見えるものが変わる。

本当の課題は検索精度ではなく、検索前の言い方が曖昧すぎることかもしれない。本当の課題は入力ミスではなく、人間には同じに見える揺れをシステムが別物扱いしていることかもしれない。本当の課題はワークフロー不足ではなく、ワークフローに入る前の曖昧な理解を、人間だけが背負っていることかもしれない。

結論："正しく入力してください"を疑え

生成AIが変えたのは、開発速度だけではない。もっと大きいのは、これまでユーザーに我慢させていた曖昧さ、現場が脳内補完していた曖昧さ、備考欄やメール本文に沈んでいた曖昧さ——こうしたものを、設計対象に戻せるようになったことだ。

従来の設計者は、曖昧さを排除してシステムを成立させてきた。これからの設計者は、曖昧さをどこまで受け止め、どこから先を厳密系に渡すかを設計することになる。

そしてその変化は、バックエンドだけでは終わらない。入力フォームも、確認画面も、依頼フローも、検索UIも、見直しの対象になる。

だから今、「正しく入力してください」というUIを見たら、一度立ち止まった方がいい。

それは本当に必要な制約なのか。それとも、曖昧さを扱えなかった時代の名残なのか。

この問いを持てるかどうかで、これからのシステム設計とUI/UXの差は、かなり開くと思う。