入力値チェック（使用性/usability）

　• 人が入力する
　• ファイルから読み込む
　• 他システムや機器から受信する
　• etc.…

ソフトウェア…その中のプログラムに渡されるデータには色々あるのでしょうが、どんなデータ、どんな目的であっても、プログラムの中に入ってくるもの（＝インプット）であれば、それは必ずチェックしなければなりません。

なぜなら、プログラム言語には必ず目的に沿った「データ属性」と言うものが存在しているからです。属性には「型」「サイズ」「上限値／下限値」「様式」「重複可不可」「未入力可不可」等、色々なものがあります。

仮に規格等が統一されていて、絶対に「誤った値が入ってこない」とわかっていたとしても、当該プログラムの外から受け渡されるデータであればチェックは必要です。

自分たちで作ったプログラムの中での値の受け渡しについてはテスト工程で散々確認しているため、基本的に問題は残っていないかもしれませんが、プログラム外の場合は、「そういうルールだから」と言うだけの口約束でしかなく、いつ誤った形で送られてくるか不明です。

たとえば、インターフェースが画面であり、利用者が画面入力をするとします。プログラム（ビジネスロジック）に対して渡す値（入力する値）は必ず、完璧なものであると言う保証はどこにあるのでしょう。老若男女すべての利用者が、入力を誤らず、完璧なデータを入力できるでしょうか。

仮に、今現在だけを切り取ってみれば、各社間、各利用者間で完璧な意識合わせができていて信頼・信用しあうことも可能かもしれませんが、５年、10年と使い続けるシステムにおいて、

　この先もずっと同じ利用者だけで連携しているか？
　連携するシステムが追加されることはないのか？
　仕様が追加や変更されることはないのか？
　その時、同じように信頼や信用ができるのか？

と言うと、所詮未来のことなので答えは「その時になってみないとわからない」わけです。そういった先を見据えて、誤ったデータ等が混入されていても、その中で動くべきプログラムが異常とならないように、水際で止めようとする仕組みが入力値チェックになります。

正確には、入力妥当性検証と言います。
エンジニアにとっては、わかりやすく「バリデーション (validation)」と言った方が良いかも知れません。

ご存知のように、プログラム内でのデータの受け渡しはすべて"変数"に代入されることになります。変数には原則として『型』があり、その型で指定された形式以外の値を無理やり代入しようとすると、値そのものが変化するか、あるいはシステムエラーとなって停止してしまいます。

※ただし、variant型(任意の種類のデータを格納できる特別なデータ型)は何でもアリ過ぎて無秩序になるためこの話の中では除く。int型と言われたら、整数値でなければなりません(小数値を代入しても、丸められてしまいます)。float型と言われたら、小数値でなければなりません(整数値を代入しても、少数化されてしまいます)。String型と言われたら、文字または文字列でなければなりません(数字ももちろん文字ですが、値ではなく文字なので計算はできません)。

画面から利用者の手を介して値を入力する場合、当然ながら、入力項目１つ１つには『意味』が定義されています。

　項目名："社員番号"

と言われれば、「社員番号」を入力することが目的となっていますし、管理するための項目でなければならないはずです。そこに誤って"氏名"を入力されても困るのです。

たとえば、Webシステムのログインにおいて、"社員番号"を"ＩＤ"として入力する画面があったとしましょう。

みなさんならば、この"社員番号"欄にたいして、具体的にどのような入力値チェックをすべきだと思いますか。あるいは一切のチェックが必要ないと思いますか？

※「ADやLDAP、OneLoginなど、シングルサインオンサービス使えば不要じゃん」とか、そう言うのはちょっと置いておいてください。ここでは、入力値チェックの重要性について説明していますので。

シンプルに"作り"のことだけ考えるなら、

　「データベースへ問い合わせて、存在しなければエラー」

と言うチェックだけで十分じゃないか？と言う意見も出てくることでしょう。観点が"作り"だけであれば、実のところそれだけで十分かもしれません。

　・入力必須チェック
　・文字/数字チェック
　・全角/半角チェック
　・桁チェック

等、色々ありますが、そういうチェックをあらかじめしておかなくても、
ＤＢに問い合わせて存在しない社員番号であれば、ＮＧと返すだけでも十分です（nullも同様）。

しかし、それでは利用者にとって「何が悪かったのか？」が不明で、どこをどう改善してよいかわからないため、不親切とみられる可能性があります。

こう言う観点を"ユーザビリティ(usability：使いやすさ、使い勝手)"と言います。

年齢層や、システムに対する理解度など、利用者の予備知識の有無を考慮に入れ、「入力操作のどこに問題があったのか？」を特定する目的で、細やかなチェックを必要とする場合もあります。

これはただ"作る"だけの効率性重視な観点だけではなかなか生まれない発想で、"利用時"・"利用者"・"利用目的"の観点を持たなければなりません。

また、"システム特性"などに精通していれば、さらに

　・禁則文字（ルール外入力値）

に対するチェックも視野に入ることでしょう。たとえば、Webシステムの場合、"<"や">"などが混入していると、後で画面表示の際にHTMLタグが崩れてしまって、画面表示がおかしくなってしまうケースがあります。"*"や"?"はワイルドカードとして認識されてしまうかもしれませんし、"\"を混入させると、エスケープシーケンスとして認識してしまうかもしれません。

SQLインジェクション攻撃への対策｜脆弱性を悪用する仕組みと具体例

ほかにも、SQL操作などでは、"SQLインジェクション"に代表されるように、不正操作を可能とする文字列を組むことだってできてしまいます。プログラムの予約語や構文編成などは、必ず注意して設計およびテストすべき観点だったりします。

こう言った課題に対し、「社員番号を入力しろって言っているのに、他の文字を入力するやつが悪い」と、人依存な考え方しかできないようでは、エンジニアとして三流です。エンジニアであれば、プロでもアマでも、大前提として知っているはずです。

　コンピュータは与えられた命令しか実行できない

そういうものです。「人」と言う、限りなくアナログでアバウトな存在に依存して、プログラムに起きうる危険性が予測できないアルゴリズムしか作れないようでは、社会インフラに根ざしたシステムを構築することは難しいでしょう。

一般に「入力値チェック」は、コアなサービスやビジネスロジックと言う位置づけになく、プレゼンテーション層におけるただのサポート機能のように見られることが多くあります。しかし、ただの入力値チェックでさえも、軽視していると利用者に愛想をつかされてしまうほど、痛い目に遭うこともあるのです。