スマホで発注すると画面が小さい？押し間違いを減らす基準と、直す・変える判断

◆監修・編集責任者　小園 将隆　2026年10月5日

B2B EC-COLUMN

スマホで発注画面を開くと何が小さすぎるのか：操作別に見る失敗の起き方

外出先や店頭でスマホから発注画面を開くと、ボタンや数量欄が小さく、隣の品目を押したり数量を打ち間違えたりしないか不安になります。
どこを直すべきかは、品目検索・数量入力・送信前の確認・送信のどこで困っているかによって変わります。
押す部分の大きさはWCAGの24px・44px、Androidの48dpという設計上の目安と比べます。
あわせて、拡大しても画面が崩れないか、送信前に内容を確かめられるかを見ます。
端末の設定や運用で足りるのか、画面や発注手段を変えるのかは、その結果と、誤発注が起きたときの影響の大きさで決まります。

品目検索

発注の操作を一続きの作業として見ると、画面の小ささが影響する場面は四つに分けられます。
品目を探して選ぶ、数量を入れる、送る前に内容を見直す、送信する、の順です。
拡大で済むのか、確認の仕組みが必要なのかは場面によって違います。
そのため、まず自分の失敗がどの場面で起きているかを分けて考えます。

品目検索で起きやすいのは、候補一覧の行が詰まっていて、狙った品目の一つ上や下を押してしまうことです。
PC向けの画面では、規格違いや容量違いの品目が一行ずつ細かく並ぶことがあります。
たとえば同じ洗剤の業務用と小分け用が隣り合っていれば、行の高さが指先より小さいだけで、別の規格を選んだまま次へ進んでしまいます。

この失敗は、その場では気づきにくいのが厄介なところです。
品名の前半が同じだと、選んだ後の画面でも違いが目に入りにくく、商品が届いてから規格違いに気づくことになります。
品目検索での押し間違いには、ボタンの大きさだけでなく、選んだ品目を後から見分けやすい表示かどうかも関係しています。

数量入力

数量欄では、押し間違いと打ち間違いの両方が起きます。
欄そのものが小さいと、隣の品目の数量欄を開いてしまい、別の行に数字を入れることがあります。
さらに、キーボードが出ると画面の下側が隠れ、いま入力している行がどの品目なのか見えにくくなります。

打ち間違いには、「10」のつもりが「100」になる、単位がケースなのかバラなのかを取り違える、といった形があります。
単位を小さなプルダウンで選ぶ画面では、数字は正しいのに単位だけが違う注文になることもあります。
数量の誤りは金額や在庫に直接響くため、四つの場面の中でも影響が大きくなりやすいところです。

送信前の確認

確認の場面で起きるのは、押し間違いというより「見えない」という問題です。
注文内容の一覧が横に長い表のまま表示されると、品名は見えても、数量や単位の列が画面の外に隠れてしまいます。
横にスクロールしなければ確かめられません。
確認画面があっても、狭い画面ですべてを確かめにくければ、品名だけを見て送ってしまいがちです。

そもそも確認画面がなく、カートに入れた内容がそのまま送られる画面もあります。
この場合、品目検索や数量入力で起きた誤りを止める機会がありません。
確認の場面で困っているのか、確認の場面そのものがないのかによって、後の判断が変わります。

送信ボタン

送信ボタンのまわりでは、「戻る」「削除」「送信」などが近くに並んでいることが問題になります。
削除のつもりで送信を押せば、見直していない注文が出てしまいます。
送信のつもりで削除を押せば、入力をやり直すことになります。
前者は取り消せるかどうか、後者はやり直しの手間というように、困り方が違います。

四つの場面のうち、押し間違いが中心になるのは品目検索と送信ボタン、打ち間違いや見落としが中心になるのは数量入力と送信前の確認です。
前者は押す部分の大きさと間隔で判断します。
後者は、拡大したときの表示の崩れや確認の仕組みで判断することになります。

「小さすぎる」の基準：24px・44px・48dpという目安と、その適用条件

WCAG 2.2の24px（AA）と44px（AAA）

押す部分の大きさには、ウェブの使いやすさに関する国際的な指針に数値の目安があります。
W3CのWCAG 2.2（ウェブコンテンツのアクセシビリティに関する指針）は、達成基準2.5.8（レベルAA）で、指やマウスで操作する対象を24×24 CSSピクセル以上にすることを求めています¹。
より高い水準の達成基準2.5.5（レベルAAA）では、これが44×44 CSSピクセル以上になります¹。

CSSピクセルは、画面の物理的な点の数ではなく、ウェブページの設計で使う長さの単位です。
WCAGの適合レベルはA・AA・AAAの三段階で、AAAがもっとも高い水準です。
WCAGは法律上の義務ではなく指針なので、使っている発注システムが準拠しているかどうかは、画面ごとに確かめる必要があります。

発注のように押し間違いが損失につながる操作では、24を下回っていないかを最低限の線とし、44に近いほど押し間違いの余地が小さい、と読むことができます。
品目の行や送信ボタンのように、毎回押す部分ほど、この差が積み重なります。

Androidの48dpと間隔8dp

Android端末については、Googleのアクセシビリティのヘルプが、タッチする対象を48×48dp以上にし、対象どうしの間隔を8dp以上空けることを検討するよう勧めています²。
これは設計上の推奨で、必須の要件ではありません。

注意したいのは、CSSピクセルとdpが別の単位だという点です。
「48は44より大きいから、Androidの方が厳しい」といった単純な比べ方はできません。
二つの目安から言えるのは、別々の機関がいずれも、指で押す対象には一定以上の大きさと、隣との間隔が必要だと考えている、ということです。

間隔の目安が示されていることは、発注画面を見るときにも役立ちます。
一つひとつのボタンにそれなりの大きさがあっても、品目の行や「送信」「削除」がすき間なく並んでいれば、指先が境目にかかったときにどちらが反応するか分かりません。
品目検索の一覧や送信ボタンのまわりでは、大きさより間隔が原因で押し間違いが起きていることもあります。

基準が使えない例外

24 CSSピクセルの基準は、画面上の押せる部分すべてに当てはまるわけではありません。
WCAGは、文中に埋め込まれたリンクのような要素や、ブラウザが標準で表示する部品を作り手が手を加えずに使っている場合などに、例外を設けています¹。
例外の細かな条件は原典で定められていて、ここで挙げたものがすべてではありません。

発注画面に当てはめると、注意書きの文中にある「詳しくはこちら」のようなリンクが小さくても、それだけで基準を満たしていないとは言えません。
一方で、品目の選択、数量欄、送信ボタンのように発注の操作そのものに使う部品は、例外に頼らずに大きさを確保するのが妥当です。

利用者が画面を定規で測るのは現実的ではありません。
これらの基準は設計する側のための数値で、利用者が自分で判定するための物差しではないからです。
利用者の側でできるのは、指の腹で押したときに隣の行やボタンにかかりそうか、押したつもりの部品と違うものが反応することがあるか、といった症状を記録しておくことです。
そのうえで画面を提供している側に、達成基準2.5.8の大きさを満たしているかを問い合わせると、話が具体的になります。

大きさが基準に届いていない場合、利用者の側では部品の大きさそのものを変えられません。
手元でできるのは、表示を拡大して押しやすくすることと、押し間違いが起きても送信前に止める工夫の二つです。

今の画面のまま、拡大表示や横向きでどこまで直るか

200%拡大で崩れないか

端末やブラウザで表示を拡大すれば、ボタンも文字も大きくなり、押し間違いが減りそうに思えます。
ただし、効果があるかどうかは画面の作り次第です。
拡大するとボタンどうしが重なったり、数量欄が画面の外にはみ出したりする画面では、かえって操作しにくくなります。

WCAG 2.2の達成基準1.4.4（レベルAA）は、支援技術を使わなくても、文字を200%まで拡大して内容や機能が失われないことを求めています¹。
発注画面でいえば、文字を2倍にしても品名が切れず、数量欄に入力でき、送信ボタンを押せる状態が保たれているか、ということです。
これは拡大しても使える画面の条件を示したもので、自社の発注画面が満たしているという保証ではありません。

試すときは、ふだん発注している品目を一つカートに入れ、送信の手前まで進めるのが分かりやすい方法です。
拡大した状態で、品名・数量・単位が読めるか、確認画面の金額や数量が欠けずに見えるか、送信ボタンまでたどり着けるかを見ます。
テストの注文を実際に送ってしまわないよう、送信の直前で止めます。

320px幅で横スクロールが出ないか

もう一つの目安が、達成基準1.4.10（レベルAA）です。
幅320 CSSピクセル相当の表示で、縦のスクロールだけで読めて、縦と横の両方向にスクロールしなくても使えることを求めています¹。
狭い画面でも、横に動かさずに使えるかどうかの目安です。

発注画面では、品目の一覧や確認画面の表が画面の幅に合わせて折り返されるのか、横にはみ出すのかの違いになります。
横にはみ出す表では、指で画面を左右に動かしているあいだに、意図せず行を押してしまうことがあります。
最初に見た「数量の列だけが画面の外に隠れる」確認画面も、この基準を手掛かりに見直すことができます。

画面を横向きにすると幅が広がり、横スクロールが減る画面もあります。
その代わり、縦に見える範囲が狭くなり、キーボードを出したときに入力中の行や送信ボタンが見えにくくなることがあります。
横向きで操作しやすくなるかどうかは、拡大と同じように、自社の画面で一度試して確かめるものです。

端末側で直らない場合の見分け方

拡大や横向きで押し間違いが減るのは、画面が表示の大きさに合わせて並び直る作りになっている場合です。
並び直らない画面では、拡大すると表示は大きくなりますが、一度に見える範囲が狭くなり、横スクロールが増えます。
押す部分は大きくなっても、いまどの品目の行を操作しているのかを見失いやすくなり、別の種類の誤りが増えます。

拡大して試したときの手掛かりを並べると、次のようになります。

<ul><li>品目の一覧が画面の幅に合わせて折り返される：端末側の対処で改善が見込める</li><li>横スクロールが増え、数量や単位の列が隠れる：端末側の対処には限界がある</li><li>ボタンが重なる、送信ボタンまでたどり着けない：端末側では直らない</li></ul>

後の二つに当てはまる場合は、利用者が設定を工夫しても解決は難しく、画面の側の問題として扱うことになります。
一方、拡大で十分に押しやすくなるなら、まずはその設定で運用し、それでも残る誤りを送信前の確認で止める、という組み合わせが現実的です。

送信前に誤発注を止める：確認・訂正・チェックの考え方

確認画面

押す部分を大きくしても、数量の打ち間違いや規格の取り違えはなくなりません。
入力ミスそのものは、スマホに限らず手入力について回る課題です。
中小企業庁のミラサポplusは、電話やFAXによる受発注では経理システムへの手入力が必要になり、ミスや書類紛失のリスクがあると説明しています³。
これは電話・FAXの受発注についての説明で、スマホでの入力ミスの起きやすさを示すものではありません。
それでも、人が数字を打ち込む以上は誤りを後から止める仕組みが必要だという点は共通しています。

送信前に誤りを止める仕組みについては、WCAG 2.2の達成基準3.3.4（レベルAA）が手掛かりになります。
法的な取引や金銭的な取引の送信について、次のいずれかを満たすことを求めるものです¹。

<ul><li>取り消し可能：送信を取り消せる</li><li>チェック済み：入力された内容が点検される</li><li>確認済み：送信前に内容を見直し、確かめられる</li></ul>

発注は代金の支払いにつながるため、この基準を発注画面に当てはめて考えることができます。
三つの要件を発注の仕組みに置き換えると、次のように整理できます。
どの仕組みがどれだけ誤発注を減らすかは、画面と運用によって変わります。

「確認済み」に当たるのが、送信前の確認画面です。
スマホで役に立つ確認画面は、ただあるだけでなく、狭い幅でも品名・規格・数量・単位・金額が一度に見えるものです。
数量の列が画面の外に隠れていれば、確認の場面があっても確かめられないことは、横スクロールの目安で見たとおりです。

確認画面のない画面で利用者にできるのは、送信の前に自分で確認の場面を作ることです。
たとえば、カートの内容を画面ごと保存して見直す、数量の多い品目と単位だけは読み上げてから送る、といった方法があります。
どちらも手間は増えますが、見る場所を決めておくことで、品名だけを見て送ってしまう見落としを減らすねらいがあります。

数量の上限チェック

「チェック済み」に当たるのが、入力された値を画面の側で点検する仕組みです。
発注でいえば、品目ごとにふだんの発注量から大きく外れた数量が入ったときに注意を出す、上限を超えた数量では先へ進めない、といった形が考えられます。
「10」のつもりの「100」は本人が見直しても見落としやすい誤りなので、人の目とは別の点検があると止まりやすくなります。

ただし、上限の値をどう決めるかは、発注の実態によります。
繁忙期だけ数量が増える品目に低い上限を設けると、正しい注文まで止まってしまい、注意表示を読み飛ばす習慣がつきかねません。
上限は品目ごとの発注の幅を見て決めるもので、一律の数字で済むものではありません。

取消猶予

「取り消し可能」に当たるのが、送信後しばらくは注文を取り消せる仕組みです。
送信ボタンを押し間違えたときに、特に役立ちます。
確認画面や数量のチェックが送信前に誤りを止めるのに対し、取消猶予は送った後に気づいた誤りを戻すもので、守る場面が違います。

取り消せる時間や条件は、発注システムや取引先の受け付け方によって変わります。
取引先がすでに出荷の準備に入っていれば、画面上では取り消せても、実際の手配は止まらないこともあります。
取り消しに頼るなら、いつまで取り消せるのか、取り消した後に取引先へ連絡が必要なのかを、事前に把握しておく必要があります。

定型発注・お気に入りの運用

毎回同じ品目を発注しているなら、品目を探す操作そのものを減らす方法もあります。
よく使う品目をお気に入りに登録する、決まった組み合わせを定型の発注として保存しておく、といった方法です。
小さな一覧から品目を探す回数が減れば、品目検索で押し間違える場面そのものが少なくなります。

一方で、定型発注は数量の誤りを止める仕組みではありません。
前回と同じ数量がそのまま入る場合、今回は少なくてよいのに前回の数量で送ってしまう、という別の誤りも起こりえます。
お気に入りや定型発注は品目の選び間違いを減らす手段で、数量の確認は別に残る、と分けて考えるのが安全です。

こうした運用の工夫が効いているかどうかは、誤発注の件数を記録すると見えてきます。
どの品目で、品目・数量・単位・送信のどこで誤りが起きたかを残しておけば、運用を変える前と後で比べられます。
この記録は、画面の変更を相談するときの材料にもなります。

画面改修・アプリ化・別の発注手段に変えるのは、どんな状況か

変更を考える3つの条件

ここまでの確かめ方で、画面の側に原因があるかどうかは、かなりの程度分かります。
変更を考える条件として挙げられるのは、次の三つです。

<ul><li>品目の行や送信ボタンが24 CSSピクセルの目安に届いていない、または隣との間隔がなく、押し間違いが続く</li><li>拡大すると表示が崩れ、横スクロールが増えて数量や単位が隠れる</li><li>送信前の確認、数量のチェック、送信後の取消のいずれもない</li></ul>

一つ目と二つ目は利用者の工夫では直りません。
三つ目は運用で補えますが、その手間がずっと残ります。
三つすべてに当てはまる画面を運用だけで支え続けると、担当者が毎回注意を払い続けることに頼る形になります。

誤発注の影響と発注頻度

条件に当てはまっても、すぐに画面を変えるべきとは限りません。
判断を分けるのは、誤発注が起きたときの影響の大きさと、スマホで発注する頻度です。

たとえば、月に数回、少額の備品を発注するだけなら、拡大表示と自分での見直しで運用し、誤りが出たら取消や返品で対応する、という選び方もあります。
反対に、毎日のように食材や資材を発注していて、数量の誤りが廃棄や欠品に直結するなら、確認やチェックの仕組みがない画面で運用を続ける負担は大きくなります。
どこで線を引くかは、各社の取引の実態によって変わります。

発注そのものをスマホ以外へ移す方法もあります。
現場では品目と数量だけをメモし、発注は事務所のPCでまとめて行う、といった分け方です。
この場合、メモから発注画面へ書き写す手入力が一回増えるため、書き写しの誤りを確かめる場面が新たに必要になります。
電話やFAXの受発注でも手入力のミスが課題として挙げられているとおり、手段を変えれば入力の誤りがなくなるわけではありません。

自社で変更できるか確認する質問

画面を変えられるかどうかは、立場によって違います。
自社で発注システムを選んだり改修したりできる立場なら、提供元に直接相談できます。
取引先が用意した発注画面を使っている場合、変更を決めるのは取引先やその提供元で、こちらにできるのは要望を伝えることです。

どちらの場合も、伝える内容を具体的にすると話が進みやすくなります。
費用や期間は提供元や改修の範囲によって変わるため、まずは次のような点を確かめるところから始めます。

<ul><li>スマホの画面幅に合わせた表示、または別のスマホ向け画面やアプリが用意されているか</li><li>品目の選択や送信ボタンが、WCAG 2.2の達成基準2.5.8の大きさを満たしているか</li><li>文字を200%に拡大しても、品名・数量・送信ボタンが使えるか</li><li>送信前の確認画面、数量のチェック、送信後の取消のうちどれがあり、取消はいつまでできるか</li><li>画面を変える場合、取引先側の受け付け方や手順に影響があるか</li></ul>

問い合わせには、記録しておいた誤りの場面を添えると、どの画面のどの部品を直せばよいかが伝わります。
「スマホだと使いにくい」という感想より、「確認画面で数量の列が横に隠れ、数量違いの注文が続いた」という具体的な症状の方が、改修か、設定の変更か、運用かの切り分けがしやすくなります。

自社の発注画面が目安に届いていないのか、運用で補える範囲なのかは、実際の画面と発注の流れを並べて見ないと切り分けにくいためです。

相談では、品目検索から送信までのどの場面に手を入れるべきかと、提供元へ伝える症状の整理を一緒に確かめられます。無料相談で要件を整理する

要点の整理

軸	基準
押す部分の大きさ	WCAG 2.2の2.5.8は24×24 CSSピクセル以上（AA）、2.5.5は44×44（AAA）
Androidの目安	48×48dp以上・間隔8dp以上（推奨）。CSSピクセルとは単位が違う
拡大したときの使いやすさ	文字200%で内容・機能が失われない（1.4.4）、320 CSSピクセル幅で横スクロール不要（1.4.10）
送信前後の止め方	取り消し可能・チェック済み・確認済みのいずれか（3.3.4）
変更を考える条件	基準未達・拡大で崩れる・止め方がない、に影響の大きさ・頻度・変更できる立場を重ねる

画面の見直し、運用での確認、発注手段の変更のどれを選ぶかは、誤発注の影響や取引先との手順も絡むため、担当者一人では決めにくいためです。 相談では、いまの発注の流れに残る確認の手間と、変更を検討するときに提供元へ確かめる点を整理できます。

よくある質問

発注画面のボタンが基準より小さいと分かったとき、利用者側でできることは何ですか。

ボタンの大きさそのものは、利用者の側では変えられません。
できるのは、表示を拡大して崩れずに押しやすくなるかを試すこと、押し間違いが起きた場面を記録すること、送信前に自分で内容を見直す手順を作ることです。
あわせて画面の提供元に、WCAG 2.2の達成基準2.5.8の大きさを満たしているかを、記録した症状を添えて問い合わせると話が具体的になります。

横向きにすると押し間違いは減りますか。減らない画面はどんな画面ですか。

画面の作りによります。
横向きで幅が広がり、横スクロールが減って操作しやすくなる画面もあります。
その一方で、縦に見える範囲が狭くなり、キーボードを出すと入力中の行や送信ボタンが見えにくくなることもあります。
表示の大きさに合わせて並び直らない画面では、向きを変えても押し間違いは減りにくいので、送信の直前まで進めて一度試すのが確実です。

送信前の確認画面がない発注システムで、運用でできる確認方法は何ですか。

送信の前に、自分で確認の場面を作る方法があります。
カートの内容を画面ごと保存して見直す、数量の多い品目と単位だけは読み上げてから送る、など見る場所を決めておくと、品名だけを見て送ってしまう見落としを減らすねらいになります。
送信後にいつまで取り消せるか、取り消した後に取引先への連絡が必要かも、あらかじめ把握しておくと安心です。

定型発注やお気に入り登録は、スマホ発注のミスを減らす手段になりますか。

小さな一覧から品目を探す回数が減るため、品目の選び間違いが起きる場面を減らす手段になります。
ただし、数量の誤りを止める仕組みではなく、前回の数量がそのまま入って送ってしまう誤りも起こりえます。
数量の確認は別に残し、誤発注の件数を場面ごとに記録して、運用を変える前と後で比べると効果を確かめられます。

自社で発注システムを変更できない場合、誰に何を相談すればよいですか。

取引先が用意した発注画面なら取引先の窓口に、自社で契約しているシステムなら提供元に相談します。
伝える内容は、スマホ向けの表示やアプリがあるか、ボタンの大きさや拡大への対応、確認画面・数量チェック・取消の有無、変更による取引先側への影響です。
「確認画面で数量の列が隠れる」のように、誤りが起きた場面を具体的に添えると、改修・設定変更・運用のどれで対応するかを決めやすくなります。

1. 1　出典：W3C「Web Content Accessibility Guidelines (WCAG) 2.2」（2023年）
2. 2　出典：Google「Androidアクセシビリティ ヘルプ：タッチ対象のサイズ」
3. 3　出典：中小企業庁（ミラサポplus）「企業間のデータ連携で、受発注の業務コストを削減する！」（2020年）