Blog

2026.08.07

タッチパネル画面設計2026|HMI開発の見積が割れる4層

タッチパネル画面設計2026|HMI開発の見積が割れる4層

タッチパネルの画面設計を外注すると、同じ装置・同じ画面数を伝えているのに見積が大きく割れることがあります。原因は、この仕事を「画面を描く作業」だと思って発注している点にあります。実際には作画に入る前に、情報設計・アラーム設計・多言語と権限・データの出口という4つの層が決まっており、そのうちどれを自社で決めたかで費用も現場での定着も変わります。この記事では、その4層を日系製造業のタイ拠点の実務に沿って言語化します。

タッチパネルの画面設計は、絵を描く前に9割が決まっている

装置メーカーやソフトハウスに「タッチパネルの画面をお願いします」と依頼したとき、返ってくる見積の根拠を説明できる発注者は多くありません。多くの場合、画面数と単価の掛け算で概算が出てくると想定しています。ところが実際に3社に声をかけると、金額が2倍近く開くことがあります。同じ装置、同じPLC、同じ画面数を伝えているのに、です。

この差は、各社の工数単価の差ではありません。各社が「この依頼で何を決めなければならないか」をどこまで見ているかの差です。画面を描く作業そのものは、実のところ工数の大きな部分を占めません。工数を決めているのは、その画面に何を出し、何を出さないか、どのビットをアラームとして人に見せるか、誰がどの操作をできるようにするか、そして画面に映した数値をどこに残すか、という設計判断です。これらが未決のまま発注されると、開発側は「決めながら作る」ことになり、そのリスクを見積に織り込みます。逆に、これらが仕様書として渡されていれば、作画はほぼ機械的な作業になります。見積が割れているとき、高いほうの会社が不当なのではなく、未決事項を自分で引き受ける前提で積んでいるだけ、という場合が少なくありません。

この構造は、HMIの国際的な標準の考え方とも一致しています。ISAが定めるISA-101.01-2015、および技術報告書のISA-TR101.01-2022(HMI Philosophy)とISA-TR101.02-2019(Usability and Performance)は、HMIを「画面という成果物」ではなく、設計・実装・運用・継続的改善までを含むライフサイクルとして扱っています。適用範囲も連続プロセスに限られず、バッチ、ディスクリート(個別生産)のいずれにも適用されるとされています。2024年8月には、このANSI/ISA-101.01を基にした国際規格としてIEC 63303 Edition 1.0が発行されました。IEC TC65/SC65A のWG19が策定したもので、HMIの構想から廃止までの全ライフサイクル、用語とモデル、そしてHMIを維持していくための作業プロセスを定義しています。つまり国際規格の側でも、HMIは作って納めて終わるものではなく、運用しながら維持する対象として位置づけられています。

本稿で扱う4つの層を先にまとめます。以降の各章は、この表の1行ずつを掘り下げる構成です。

何を決めるのか決めそこねたときに現場で起きること
層1 情報設計平常時に何を出さないかを決める。画面の階層と遷移、常時表示する指標全データを1画面に載せ、異常が背景に埋もれる。オペレーターが画面を見なくなる
層2 アラーム設計どのビットを人に見せ、誰が何をするか。優先度と件数の上限鳴りっぱなしで誰も見なくなる。重要な1件がフラッドに紛れる
層3 多言語・権限誰がどの操作を、どの言語でするか。表示言語と操作権限の設計現地作業者が使えず、日本人駐在員が装置に張り付く
層4 データの出口HMIで見せるだけにするか、MES・IoT側へ送るか。保存期間と取り出し方画面にしか残らず、後から不良やチョコ停の原因を追えない
タッチパネル画面設計2026|HMI開発の見積が割れる4層 - figure 1

さらに、第5の軸として「内製と外注の分界点」を扱います。自社に残すべきは仕様であって作画ではない、というのが本稿の立場です。この線引きは、タイ拠点のように設計リソースが薄く、かつ装置の入れ替わりが速い環境ほど重要になります。

そもそもHMIとは|タッチパネル・SCADA・アンドンの境界を引き直す

HMI画面開発を発注するとき、最初につまずくのは用語です。社内で「タッチパネル」「HMI」「SCADA」「アンドン」が混ざったまま議論されていると、外注先に渡す仕様も混ざります。この4つは、置かれる場所と担う責任が違います。

呼び方物理的な位置主な役割見る人止まったときの影響
タッチパネル(HMI表示器)装置の操作盤、制御盤の扉その装置の運転操作、設定、状態表示、アラーム表示その装置のオペレーター、段取り担当、保全その装置が操作できなくなる。生産が止まる
SCADA・監視システム事務所、監視室のPC複数装置・複数ラインの集中監視、傾向表示、履歴生産管理、生産技術、工場長監視ができなくなるが、装置自体は動く
アンドンラインの上部、通路から見える位置現在の状態を離れた場所から一目で伝える通りかかる全員、班長、応援要員呼び出しが遅れる。停止時間が伸びる
PLC制御盤の内部実際の制御ロジック。入出力の処理直接は誰も見ない装置そのものが動かない

この区別が曖昧だと、発注仕様に典型的な歪みが出ます。よくあるのは、タッチパネルにSCADAの役割まで持たせようとするケースです。装置の操作盤に月次の生産推移グラフを載せ、他ラインの状態も表示させ、品種マスタの管理までさせる。結果として画面数が膨らみ、タッチパネルの処理能力と画面容量を圧迫し、肝心の運転操作が遅くなります。逆に、アンドンで済むはずの「今どの状態か」を、わざわざタッチパネルの前まで行かないと分からない設計にしてしまうケースもあります。

判断の原則はシンプルです。その情報を必要とする人が、どこに立っているかで置き場所を決めます。装置の前に立っている人が今この瞬間に必要とする情報はタッチパネル、離れた場所から状態を知りたい人向けはアンドン、後から傾向を見たい人向けはSCADAや上位システムです。この切り分けを最初にやっておくと、画面数は目に見えて減ります。

なお、異常が起きたときに担当者へ通知を飛ばす仕組みは、タッチパネルの画面設計とは別の領域になります。装置の前に人がいない時間帯や、夜勤で人員が薄い時間帯をどう埋めるかは、設備異常の通知システムの話題として整理しています。HMIの画面上で赤く光らせることと、担当者のスマートフォンに届けることは、設計としては別物です。両方を「アラーム対応」と一括りにすると、層2の議論が曖昧になります。

層1|情報設計:平常時に「出さないもの」を決める

何を決めるのか

層1で決めるのは、画面の構造です。具体的には、画面の階層、各画面に載せる情報、そして常時表示させる要素の3つです。

ここで最も重要な決定は、加算ではなく減算です。「何を出すか」ではなく「平常時に何を出さないか」を決めます。この発想は High Performance HMI と呼ばれる設計思想に由来し、ASM Consortium の研究を背景としてISA-101にも取り込まれています。核となる考え方が report by exception です。平常時の画面は「すべてが想定内にある」ということを最小の認知負荷で伝えるだけにとどめ、想定運転範囲から外れた瞬間に初めて、見逃せない形でそれを示す。この設計だと、オペレーターは常に画面を精読する必要がなくなり、変化があったときだけ注意を向ければよくなります。

画面の階層は、一般に4段階で組み立てられます。最上位に工場やラインの全体状態、次に装置やユニット単位の運転画面、その下に詳細な設定値やトレンド、最下位に個別機器の診断や保全用の画面を置きます。オペレーターが日常的に見るのは上から2段目までで、それ以外は必要なときにたどり着ければ十分です。この階層を先に決めておくと、「この情報はどの画面に載せるべきか」という議論が個別に発生しなくなります。

決めそこねると現場で何が起きるか

情報設計を飛ばして発注すると、ほぼ確実に「全部載せ」の画面ができます。PLCで持っているデータを片端から数値表示にして、装置の外形図の上にセンサのランプを全部並べ、余白があれば温度と圧力のトレンドを追加する。設計者としては親切のつもりですが、現場では逆の結果が出ます。

情報が均一に敷き詰められた画面では、異常が起きても異常が目立ちません。センサランプが40個並んでいる画面で1つだけ色が変わっても、人はそれを検出できません。結果としてオペレーターは画面を見なくなり、装置の異音や搬送の詰まりといった物理的な兆候だけで判断するようになります。せっかく作った画面が、実質的に無いのと同じ状態になります。

もう1つの症状は、色の使いすぎです。装置全体を鮮やかな配色で描き、稼働中は緑、待機は青、といった配色を全機器に適用すると、色が飽和して「注意を引く色」が残りません。異常時に赤を出しても、すでに画面上に赤系の装飾があれば埋もれます。High Performance HMI の設計では、平常時の画面はグレースケールに近い低彩度で構成し、彩度の高い色は逸脱の表示にだけ使います。この配色思想は見た目が地味なため、初見の役員説明では「寂しい」と言われがちですが、運用に入ると評価が逆転します。

発注時にどう書くか

情報設計を外注先に伝えるとき、画面イメージのラフを描く必要はありません。次の4項目を文章で書けば足ります。

項目書き方の例
画面階層全体監視/装置運転/詳細設定・トレンド/保全診断の4階層とする。オペレーターの通常操作は上位2階層で完結させる
常時表示要素全画面共通のヘッダに、運転モード、現在の品種、アラーム最上位1件、時刻を常時表示する
平常時に出さないもの平常時は個別センサの状態を表示しない。詳細画面に格納し、異常時のみ運転画面に昇格させる
配色方針平常時は低彩度で構成する。彩度の高い色は逸脱表示に限定する。緑の点灯を「正常」の意味で常用しない

この4行を仕様書に書いておくだけで、開発側の作画方針が固まります。逆に、この4行がないまま「見やすい画面でお願いします」と伝えると、見やすさの定義が開発者個人の感覚に委ねられます。

層2|アラーム設計:鳴り続ける画面は、無い画面と同じ

何を決めるのか

層2で決めるのは、PLCが持っている異常ビットのうち、どれを人に見せるかです。そして見せると決めたものについて、誰が何をするのかを決めます。

多くの装置では、PLC側に数百から数千の異常ビットが存在します。センサの断線、リミットスイッチの不検出、サーボのアラーム、インバータの過負荷、通信タイムアウト。これらを機械的に全部HMIのアラーム一覧に流し込むと、アラームは「情報」ではなく「ノイズ」になります。層2の設計とは、この流し込みを止めて、1件ずつ判断を通すことです。

判断の基準は1つです。そのアラームが出たときに、人が取るべき行動があるか。行動がないアラームは、アラームではありません。記録として残す価値はあっても、オペレーターの画面に割り込ませる理由はありません。「データが取れるから鳴らす」から「人が行動する必要があるから鳴らす」へ基準を変えることが、この層の中身です。

定量基準を仕様に置く

アラーム設計には、参照できる定量的な基準があります。ISA-18.2がアラームマネジメントの枠組みを定性的に示し、EEMUA 191がそれに対応する定量的な目安を示す、という関係で理解すると整理しやすくなります。代表的な数値は次のとおりです。

指標目安意味
定常時のアラーム発生率1オペレーターあたり10分に1件未満(1日あたり約150件が目安)これを超えると、オペレーターは1件ずつ対応する時間を確保できない
異常時ピークの発生率10分に10件未満トラブル発生直後でも、この範囲に収まるよう設計する
アラームフラッドの定義10分間に10件超(ISA-18.2)フラッド状態では、重要な1件を識別することが実質的に不可能になる
常時発報(standing alarm)1オペレーターあたり10件未満出っぱなしのアラームが多いと、一覧が常に赤く、新規発生が埋もれる
優先度の配分高5%/中15%/低80%高優先度が多すぎると優先度の意味が消える
チャタリングアラーム排除する短時間にオン・オフを繰り返すアラーム。一覧を占有し、他を押し流す

出典は exida のアラームマネジメント標準の整理、および Emerson の「Alarm Management by the Numbers」です。これらの数値は連続プロセス産業を主な想定として作られたものですが、ディスクリート生産の装置HMIでも「オペレーターが処理できる件数には上限がある」という前提は変わりません。数値をそのまま契約仕様にするかどうかは装置の性格によりますが、少なくとも設計時の目標値として置いておくと、アラーム定義の議論が感覚論から抜け出します。

決めそこねると現場で何が起きるか

アラーム設計を飛ばした装置では、一定のパターンで現象が進行します。

最初に起きるのは、立ち上げ直後のフラッドです。調整中の装置は各所で閾値に触れるため、アラーム一覧が埋まります。この時点で現場は「立ち上げ中だから仕方ない」と判断し、一覧を見ずに解除ボタンを押す運用が始まります。次に起きるのは、この運用の固定化です。量産に入ってもアラームは減らず、押して消す動作が習慣になります。そして最後に、本当に対処が必要なアラームが出たときにも同じ動作が実行されます。これがアラーム疲れ(alarm fatigue)です。

タイ拠点では、この進行がもう一段速くなることがあります。アラームメッセージが日本語や英語のままだと、現地作業者はそもそも内容を読めません。読めないものを判断することはできないので、最初から「押して消す」以外の選択肢がありません。層2の失敗が層3の未整備と重なると、アラーム機能は装置の立ち上げ直後から死んでいることになります。

装置が止まっているわけではないのに生産数が伸びない、というチョコ停の分析をしようとしたときにも、この失敗が効いてきます。アラーム履歴が「押して消した記録」の羅列になっていると、停止要因の分類ができません。チョコ停対策とOEEの考え方で扱っている停止要因の分解は、アラームが1件ずつ意味を持って定義されていることを前提にしています。

発注時にどう書くか:合理化の7項目

アラーム合理化(rationalization)は、アラーム候補を1件ずつ棚卸しして文書化する作業です。1件につき、次の7項目を埋めます。

項目内容記入例のイメージ
タグ名PLC側のデバイスやタグの識別子装置内で一意になる命名規則を先に決めておく
説明何が起きたのかを、行動する人の言葉で書く「M120 ON」ではなく「投入コンベア 材料詰まり」
原因想定される発生原因ワークの傾き、センサ汚れ、前工程の供給過多
結果放置した場合に何が起きるか後工程が空転する。3分でライン全体が停止する
オペレーターの取るべき行動誰が、何を、どの順序でするか作業者が扉を開けて詰まりを除去し、リセットを押す
優先度高・中・低のいずれか上記の配分(5%/15%/80%)に照らして決める
確認要否確認操作を必須にするか、自動復帰でよいか復帰後も履歴に残すか、確認なしで消えてよいか

この7項目を埋める作業は、外注先だけではできません。原因と結果と行動を書けるのは、その装置を運転する側だからです。逆に言えば、この表を発注側が作って渡せば、開発側の作業はそれを画面とロジックに落とすだけになり、見積の不確実性が大きく下がります。アラーム定義数が見積の主要ドライバーであることは後述しますが、その定義を誰が作るかで金額の性格が変わります。

現実には、全ビットについてこの7項目を埋めるのは負荷が大きすぎます。実務的な進め方は、まず全ビットを「人に見せる/記録だけ残す/HMIには出さない」の3つに仕分け、「人に見せる」に分類したものだけ7項目を書くことです。この仕分けだけでも、アラーム一覧に流れ込む件数は大きく減ります。

タッチパネル画面設計2026|HMI開発の見積が割れる4層 - figure 2

層3|多言語と操作権限:本社の画面がタイ拠点で効かなくなる場所

何を決めるのか

層3で決めるのは、誰がどの操作を、どの言語で行うかです。多言語対応と権限設計は別の話に見えますが、実務上は同じ層で扱ったほうが破綻しません。理由は単純で、両方とも「その画面の前に立つのが誰か」という同じ問いから答えが出るためです。

日本の本社で設計された装置をタイ拠点に持ち込むとき、画面は多くの場合そのまま来ます。日本語のまま来ることもあれば、英語表記が追加されていることもあります。ここで暗黙に置かれている前提は、「装置の操作は日本語か英語が読める人が行う」というものです。この前提が成立している拠点は、実際にはほとんどありません。

決めそこねると現場で何が起きるか

前提が崩れたときの症状は、日本人駐在員の張り付きという形で現れます。品種切替のたびに、設定値の入力のたびに、アラーム発生のたびに、駐在員か日本語の読める現地スタッフが呼ばれます。呼ばれる側の工数は装置台数に比例して増え、他の業務を圧迫します。そして、その人が休暇や帰任でいなくなった瞬間に、その装置は誰も設定を変えられない装置になります。

この症状は、タイの労務環境の変化とともに深刻さを増します。JETROの調査によれば、在タイ日系企業の賃金上昇率は2023年が3.8%、2024年が4.58%、2025年見込みが4.64%と、年々上昇幅が広がっています。同じ調査で、製造業ワーカーの人材不足感は42.3%とされています。人材の確保が難しくなるほど、既存の作業者が担える範囲を広げる必要が出てきます。にもかかわらず装置の画面が読めないままだと、作業者は「運転はできるが段取りはできない」状態に固定され、拠点全体の柔軟性が下がります。

作業者の入れ替わりが一定の頻度で起きる前提に立つと、もう1つの論点が出てきます。教育コストです。画面が現地語で書かれていれば、新しい作業者への引き継ぎは画面を見せながら説明できます。読めない言語の画面では、「この位置のこのボタン」という位置の暗記になり、画面レイアウトが少しでも変わると再教育が必要になります。

多言語対応の実務:切替の方式と文字の実務

多言語対応と一口に言っても、実装方式には幅があります。

方式内容向いている場面注意点
単一言語固定現地語のみで作る操作者が単一の言語層に限られる日本人の立ち会い時や本社からの遠隔支援で読めない
画面上での言語切替切替ボタンで表示言語を変える複数の言語層が同じ装置を使う全テキストを言語ごとに保持する必要がある。文字数が最も多い言語で枠を設計する
併記1つのラベルに2言語を並べるラベル数が少ない簡易な装置画面が窮屈になる。アラームメッセージには向かない
ログイン連動ログインしたユーザーの設定言語で表示する権限設計と一体で運用する権限設計が前提。層3の他の要素とセットで決める必要がある

方式を決めたら、文字そのものの実務が待っています。ここは日本語だけを扱ってきた設計者が最も見落とす部分です。

第一に、文字幅です。日本語で「非常停止」と4文字で収まる語が、英語では EMERGENCY STOP、タイ語やベトナム語ではさらに別の長さになります。ボタンやラベルの枠を日本語の文字数で設計すると、切り替えた瞬間に文字がはみ出すか、極端に小さいフォントに落ちます。枠は最も長くなる言語を基準に設計します。

第二に、タイ語の行の高さです。タイ文字は基線の上下に声調記号と母音記号が付くため、同じフォントサイズでも縦方向に必要な領域が広くなります。日本語基準で行間を詰めた設計だと、上下の記号が切れます。記号が欠けると別の語になるため、これは体裁の問題ではなく意味の問題です。

第三に、ベトナム語のダイアクリティカルマークです。声調記号が落ちると語義が変わります。フォントによっては記号の一部が正しく表示されない場合があるため、実機のタッチパネルで実際に表示させて確認する工程を、検収項目に入れておく必要があります。開発時のPC画面では正しく見えても、パネル実機のフォントで崩れることがあります。

第四に、アラームメッセージの文体です。翻訳を外注すると、原文の日本語をそのまま逐語訳したメッセージが返ってきます。層2で決めた「オペレーターの取るべき行動」が原文に書かれていなければ、翻訳しても行動は分かりません。多言語化は翻訳作業ではなく、行動を伝える文の再設計だと捉えておくと、出来上がりが変わります。

操作権限の設計

権限は、役割の数だけ細かく分ければよいというものではありません。細かすぎると運用されなくなり、全員が管理者アカウントを共用する状態に戻ります。実務的には3〜4段階が扱いやすい範囲です。

権限レベル想定する人できることできないこと
運転ライン作業者起動・停止、品種の選択、アラーム確認、通常のリセット設定値の変更、インターロックの無効化
段取り班長、段取り担当品種条件の呼び出しと微調整、治具交換時の原点合わせ品種マスタの新規作成、安全関連の設定
保全保全担当、生産技術手動運転、I/Oモニタ、パラメータの変更ユーザー管理、監査ログの削除
管理生産技術責任者、装置管理者ユーザー登録、品種マスタの作成、上位系との接続設定監査ログの削除(全レベルで削除不可に設定する)

権限設計をするなら、あわせて操作ログの方針も決めておきます。誰がいつ何を変更したかが残っていないと、条件が変わって不良が出たときに、変更の履歴からたどることができません。ログを取るかどうかは見積に影響する項目でもあるため、要否を仕様段階で明示します。

発注時にどう書くか

層3の仕様は、次の形で渡します。第一に、対応言語とその優先順位(既定言語をどれにするか)。第二に、切替方式(ボタン切替か、ログイン連動か)。第三に、権限レベルの定義と、各レベルが操作できる画面・項目の一覧。第四に、操作ログの要否と保存期間。第五に、実機での表示確認を検収項目に含めること。この5点があれば、開発側は多言語と権限にかかる工数を確定できます。

層4|データの出口:HMIに残すのか、MES・IoT側へ送るのか

何を決めるのか

層4で決めるのは、画面に表示した数値をどこに残すか、そして誰がどうやって取り出すかです。

タッチパネル自体にも、データを蓄積する機能はあります。ロギング機能で数値の推移を保存し、アラーム履歴を保持し、SDカードやUSBメモリにCSVで書き出せます。この機能があるために、「HMIで記録できるからそれで足りる」という判断が下されがちです。しかし、この判断には見落としがあります。

第一に、容量と保存期間です。HMI内部の記憶領域は限られており、古いデータから順に上書きされます。半年前の同じ品種の運転条件を確認したい、という要求には応えられません。第二に、取り出しの手間です。データを見るには、その装置の前まで行って媒体を挿す必要があります。10台の装置から月次でデータを集める運用は、実際には続きません。第三に、装置をまたいだ突き合わせができないことです。工程Aの温度と工程Bの不良率を並べて見る、という分析は、データが各装置の中に閉じている限り不可能です。

決めそこねると現場で何が起きるか

層4を決めずに装置を導入した拠点では、「データは取れているはずなのに、聞かれたときに出せない」という状態が定着します。品質問題が発生し、日本の本社から「その日のその号機の運転条件を出してほしい」と依頼されたとき、装置の前まで行って媒体を挿し、CSVを開き、該当時刻を探す作業が発生します。装置台数と品種数が増えるほど、この作業は非現実的になります。

もう1つの症状は、紙への逆流です。HMIから取り出しにくいために、結局は作業者が画面の数値を紙の帳票に転記する運用が残ります。転記した紙は月末にファイルに綴じられ、分析に使われることはありません。電子帳票システムによる紙の置き換えを検討する場面の相当数は、この「HMIにデータがあるのに紙に書いている」という状態から始まります。層4を装置の設計段階で決めておけば、そもそも転記が発生しません。

発注時にどう書くか:置き場所の判断表

データの種類ごとに、置き場所を決めます。すべてを上位へ送る必要はありません。

データの種類HMI内で完結させてよいか上位へ送る価値判断の目安
現在値(温度、圧力、位置)完結してよい傾向分析をするなら送る異常の予兆を見たいなら周期を決めて送る。全点を高頻度で送る必要はない
アラーム履歴完結させない高い。停止要因の分析に直結する発生時刻・復帰時刻・タグ・優先度をセットで送る
稼働・停止の状態完結させない高い。OEEの算出に必要状態の変化点だけを送れば足りる場合が多い
生産数・不良数完結させない高い。生産管理側の実績と突き合わせる品種とロットの識別子を必ず付ける
運転条件・レシピ場合による品質問題の追跡に使うなら送る変更が発生したタイミングで送る
保全用の詳細診断完結してよい低い。必要時に現地で見れば足りる送るとデータ量が跳ねる割に使われない

この表で「送る」と決めた項目については、送り先と経路も仕様に書きます。上位への接続方式(OPC UA、MQTT、データベースへの直接書き込み、ゲートウェイ経由など)は、HMIの機種と上位側の受け口の両方に依存します。装置メーカーに任せきりにすると、装置ごとに方式がばらつき、後から集約するときに変換の手間が増えます。拠点として1つの方式に寄せる方針を、装置発注のたびに繰り返し伝えておく価値があります。

なお、装置から上位へデータを送るということは、制御系のネットワークが情報系と接点を持つということです。この接点をどう設計するかは、工場のOTセキュリティの領域になります。層4を決めるときは、同時にネットワークの分離方針も決めておかないと、後から「セキュリティ上の理由で接続できない」と差し戻されます。

タッチパネル画面設計2026|HMI開発の見積が割れる4層 - figure 3

HMI画面開発の外注見積が割れる6つの内訳

見積は多くの場合、一式の金額として提示されます。内訳を出してもらうと、何を比較しているのかがはっきりします。本稿では具体的な金額は示しません。画面数、装置の性格、上位連携の有無で費用が大きく変わり、根拠のある単価を一律に置けないためです。代わりに、金額を動かす要素で考えます。

内訳何が金額を動かすか発注前に打てる手
画面数と画面種別単純な表示画面と、条件入力を伴う設定画面、トレンド画面では工数が数倍違う。画面数だけの提示は比較の役に立たない画面を「表示のみ」「操作あり」「設定・マスタ」「トレンド・履歴」に分類して数を示す
タグ点数とPLC側インターフェースHMIとPLCの間でやり取りするデバイス点数、およびアドレスの割付が整理されているかどうか。命名規則がないと解読工数が乗るデバイスコメント付きのアドレス一覧を先に渡す。命名規則を発注側で決めておく
アラーム定義数層2で述べた7項目を誰が作るか。開発側が原因と行動まで考える前提だと、確認と手戻りの工数が積まれる合理化済みのアラーム一覧を発注側が作って渡す。少なくとも仕分けだけは済ませる
対応言語数言語数そのものより、翻訳の供給元と検収方法が効く。開発側に翻訳まで委ねると品質確認の往復が発生する翻訳は発注側で用意し、用語集を添える。実機表示の確認手順を決めておく
権限・監査ログユーザー管理機能、権限別の画面制御、操作ログの保存と取り出し。層3の仕様が未定だと後から仕様変更になる権限レベルの数と、レベルごとの操作可否表を渡す。ログの要否と保存期間を明示する
上位系連携接続方式、送信項目、送信周期、通信断時の扱い。相手方システムの仕様確認の工数が読みにくい送信項目一覧と接続方式を指定する。相手側の仕様書を同時に渡す

この6項目に共通するのは、いずれも発注側にしか決められない情報だという点です。開発側が独自に決められるのは作画の細部だけで、それ以外はすべて発注側の意思決定を待っています。見積が割れるとき、高い会社は「待ちの時間」と「決まらないリスク」を織り込んでいます。

もし絶対額の目安が必要な場面では、必ず前提を明示した試算という形にしてください。たとえば「表示のみの画面が10面、操作画面が5面、設定画面が3面、アラーム定義が80件、言語が3、上位連携なし」という前提を置いたときの工数はいくらか、という聞き方をします。前提のない金額は比較にも予算化にも使えません。前提を置いて出してもらった金額であれば、前提のどれを削ると金額がどう動くかという議論ができます。

内製と外注の分界点|自社に残すべきは仕様であって作画ではない

「HMIの画面は自社で作れるようになったほうがいいのではないか」という議論は、多くの拠点で一度は出ます。作画ソフト自体は入手でき、操作を覚えれば画面は描けるためです。

結論から言えば、自社に残すべきは仕様であって作画ではありません。理由は3つあります。

第一に、作画は習熟による生産性の差が大きい領域です。年に数回しか触らない担当者と、日常的に触っている開発者では、同じ画面を作るのにかかる時間が大きく違います。年に数台の装置しか導入しない拠点で作画スキルを維持するのは、費用対効果が合いません。

第二に、属人化のリスクが高い領域です。作画は個人の作業として完結してしまうため、担当者が異動や退職でいなくなると、そのプロジェクトファイルを誰も触れなくなります。装置は動き続けるので、問題は数年後に顕在化します。

第三に、これが最も重要ですが、仕様を決める能力は外注では代替できないためです。層1から層4まで見てきたとおり、決定の材料はすべて現場側にあります。誰が装置の前に立つのか、どのアラームにどう対応するのか、どのデータを後から使うのか。これらは外部の開発者には分かりません。

一方で、自社に残す価値がある作業もあります。既存画面の軽微な修正(ラベルの文言変更、閾値の数値変更)、追加品種のデータ登録、画面のバックアップと復元。これらは頻度が高く、外注に出すと待ち時間のほうが大きくなります。装置導入時に、この範囲の作業ができるようにプロジェクトファイルと手順書を受け取り、担当者を2名以上決めておくことをお勧めします。

作業自社に残す外注する理由
4層の仕様決定決定の材料が現場にしかない
アラーム合理化の7項目原因・結果・行動を書けるのは運転する側
翻訳と用語集現地作業者が実際に使う語彙を持っているのは拠点側
画面の新規作成習熟による生産性差が大きい
PLCとの連携ロジックPLC側の設計と一体。分割すると責任範囲が曖昧になる
軽微な文言・数値の修正頻度が高く、待ち時間のほうが損失になる
プロジェクトファイルの管理装置の寿命より外注先との関係のほうが短いことがある

分割発注の可否についても触れておきます。PLCのプログラムとHMIの画面は、別の会社に発注することが技術的には可能です。ただし、分けるなら両者の境界を仕様として固定する必要があります。具体的には、共有するデバイスアドレスの一覧、各ビットとワードの意味、書き込み側と読み出し側の責任分担です。この境界仕様がないまま分割すると、不具合が出たときに双方が相手側の問題だと主張し、切り分けに時間がかかります。PLCプログラム開発を外注するときの考え方で整理している仕様の渡し方は、HMIを分離発注する場合にもそのまま当てはまります。

さらに、装置を新規に立ち上げるのではなく既設装置にHMIを追加する場合は、制御盤側の改造が伴います。パネルの取り付け開口、電源の確保、盤内のスペース、配線の引き回し。これらは画面設計とは別の工事であり、別の見積になります。制御盤の設計・製作の観点から、盤の改造範囲を先に確定させておくと、HMI側の発注と工程を合わせられます。

タイ拠点で発注するときの勘所

現地製作と立ち上げ支援

タイでHMI画面開発を発注する場合、現地のシステムインテグレータに出すか、日本の装置メーカーに含めてもらうかという選択が生じます。この判断は単価では決まりません。

日本の装置メーカーに含めてもらう場合、装置の制御と一体で設計されるため整合性は高くなります。一方で、立ち上げ後の修正が発生するたびに、日本からの出張か、リモート対応の調整が必要になります。品種追加のたびに数週間待つ運用になっている拠点は珍しくありません。

現地のインテグレータに出す場合、修正の往復が速く、立ち上げ時に現場に張り付いてもらえます。一方で、装置メーカーの制御仕様を読み解く工数が発生し、PLC側との責任分界が曖昧になりやすくなります。

現実的な解は、新規装置は装置メーカーに含めて発注し、立ち上げ後の改造・多言語化・上位連携の追加は現地側に持たせる、という分担です。ただしこの分担が成立するには、装置導入時にプロジェクトファイルと設計資料を受け取る契約になっている必要があります。ソースを受け取れない契約になっていると、後から誰も手を入れられません。この一点だけは、装置の発注仕様書に必ず入れてください。

立ち上げ支援の範囲を先に決める

設備の立ち上げ支援を依頼するとき、範囲の定義が曖昧なまま進むと追加費用の議論になります。少なくとも次の項目は、発注段階で明示しておきます。立ち会いの日数と時間帯、量産開始後の同行の有無、現地作業者への操作教育の実施とその言語、不具合対応の応答時間、保証期間とその起算点。特に教育については、誰が誰に何語で行うかを決めておかないと、日本語での説明を現地スタッフが通訳する形になり、内容が薄まります。

BOIと投資判断

タイでの自動化投資には、BOI(タイ投資委員会)の投資奨励制度があります。BOIは自動化機械設備・ロボット産業に対する奨励制度を設けており、対象となる事業内容や条件が公開されています。HMI画面開発そのものが単独で対象になるとは限りませんが、自動化設備の導入や既存設備の高度化の一部として位置づけられる場合には、検討の余地があります。適用可否は事業内容と申請時点の制度に依存するため、投資計画の初期段階で確認しておくと、設備仕様の組み立て方が変わることがあります。

背景として、タイの製造業には高度化への構造的な要請があります。JETROは貿易投資構造の変化を踏まえ、タイ製造業の高度化の必要性を指摘しています。装置の操作を現地作業者が担える状態にすることは、この高度化の実装のひとつです。層3で扱った多言語と権限の設計は、労務対策であると同時に、拠点の技術水準を引き上げる作業でもあります。

ネットワークとセキュリティ

層4で上位連携を選択した場合、装置と上位システムをつなぐ経路が必要になります。工場内で装置の設置位置が変わる可能性がある場合や、有線の敷設が難しい区画がある場合には、無線を検討することになります。ただし工場内の無線は、事務所の無線とは設計の前提が違います。金属什器による反射、フォークリフトなどの移動体による遮蔽、既存機器との干渉。工場の無線LAN構築で扱っている設計上の注意点は、装置からのデータ送信を無線に載せる場合にそのまま該当します。

そして繰り返しになりますが、制御系と情報系が接続されるということは、攻撃面が増えるということです。装置のHMIがUSBポートを持ち、そこから保守員がプログラムを更新する運用は、多くの工場で現に行われています。層4の設計をするときは、接続の方向(装置から上位への一方向か、双方向か)、認証の方式、USBポートの物理的な扱いを、あわせて決めておきます。

発注前チェックリスト

ここまでの内容を、発注前に埋めるべき項目としてまとめます。この表を埋めた状態で相談すれば、見積の精度と比較可能性が大きく変わります。

確認項目埋めるべき内容未定のまま発注した場合のリスク
共通装置の役割この画面は装置操作か、監視か、掲示か。SCADAやアンドンとの分担役割が混ざり、画面数が膨らむ
共通画面の分類と数表示のみ/操作あり/設定・マスタ/トレンドの各画面数画面数だけの提示になり、各社の見積が比較できない
層1画面階層何階層にするか。日常操作は何階層目までで完結させるか画面遷移が場当たりになり、操作者が迷う
層1常時表示要素全画面共通のヘッダに何を出すか現在の運転状態が画面ごとに分からなくなる
層1平常時に出さないもの詳細画面に格納する情報の範囲全部載せの画面になり、異常が埋もれる
層1配色方針平常時の彩度、逸脱表示に使う色の限定色が飽和し、異常表示が目立たなくなる
層2アラーム候補の仕分け全ビットを「人に見せる/記録のみ/出さない」に分類全ビットが一覧に流れ込み、フラッドが常態化する
層2合理化の7項目タグ名・説明・原因・結果・行動・優先度・確認要否「M120 ON」のようなメッセージになり、行動につながらない
層2件数の目標値定常時と異常時ピークの目標発生率、優先度の配分目標がなく、削減の議論が感覚論になる
層3対応言語と既定言語何語に対応し、起動時は何語で表示するか現地作業者が読めず、駐在員が張り付く
層3切替方式ボタン切替か、ログイン連動か、併記か実装後に方式変更となり、全画面の作り直しになる
層3翻訳の供給元と用語集誰が訳すか。装置固有の用語をどう統一するか逐語訳になり、行動が伝わらない
層3権限レベルと操作可否表何段階にするか。各レベルの操作範囲全員が管理者権限を共用する状態に戻る
層3操作ログ取得の要否、保存期間、取り出し方法条件変更の履歴が追えず、品質問題の原因究明が止まる
層4上位へ送る項目データ種別ごとの送信要否画面にしか残らず、後から分析できない
層4接続方式と周期OPC UA/MQTT/DB書き込み等の指定、送信周期装置ごとに方式がばらつき、後から集約できない
層4通信断時の扱い上位が停止したときにHMI側でどう振る舞うか通信断で装置が止まる、またはデータが欠損する
層4ネットワーク分離制御系と情報系の境界、USBポートの扱いセキュリティ要件で後から接続を差し戻される
契約成果物の受領範囲プロジェクトファイル、設計資料、翻訳ファイルの受領後から誰も手を入れられない装置になる
契約立ち上げ支援の範囲立ち会い日数、教育の実施と言語、応答時間、保証期間追加費用の議論になり、立ち上げが遅れる
契約検収項目実機での多言語表示確認、アラーム動作確認の方法実機で文字が崩れたまま納品される

このチェックリストのうち、外注先が代わりに決められる項目は1つもありません。すべて発注側の意思決定です。逆に言えば、この表を埋める作業こそが「タッチパネルの画面設計」の実体であり、作画はその後に来る実装作業です。

よくある質問(FAQ)

タッチパネルの画面設計とは何を決める作業ですか?

画面のレイアウトを描く作業ではなく、4つの層を決める作業です。層1の情報設計では、画面の階層と、平常時に何を出さないかを決めます。層2のアラーム設計では、PLCが持つ異常ビットのうちどれを人に見せ、それぞれについて誰が何をするのかを決めます。層3の多言語と権限では、誰がどの操作をどの言語で行うかを決めます。層4のデータの出口では、画面に表示した数値をHMI内に留めるか、MESやIoT基盤へ送るかを決めます。この4つはすべて発注側にしか決められない情報で、外注先が代わりに決めることはできません。作画は、この4層が決まった後に来る実装作業です。見積が割れているとき、その多くは4層のどこかが未定のまま渡されており、開発側がその不確実性を金額に織り込んでいます。

HMI画面開発の費用はどこで決まりますか?

主に6つの内訳で決まります。画面数と画面種別(表示のみか、操作を伴うか、設定やマスタを扱うか、トレンドを描くか)、PLCとやり取りするタグ点数とアドレス割付の整理状況、アラーム定義の件数と定義を誰が作るか、対応言語数と翻訳の供給元、権限レベルと監査ログの要否、そして上位システムとの連携の有無と方式です。このうち発注側が事前に決めておくだけで金額が動くのは、アラーム定義と翻訳です。この2つを開発側に委ねると、確認と手戻りの往復が工数として積まれます。金額の目安を聞く場合は、必ず前提(画面種別ごとの数、アラーム定義数、言語数、上位連携の有無)を明示したうえで試算してもらってください。前提のない一式金額は、比較にも予算化にも使えません。

PLCプログラム開発とHMI画面開発は分けて発注できますか?

技術的には可能です。ただし、分けるなら両者の境界を仕様として固定する必要があります。具体的には、共有するデバイスアドレスの一覧、各ビットとワードが何を意味するか、どちら側が書き込みどちら側が読み出すかという責任分担です。この境界仕様がないまま分割すると、不具合が発生したときに双方が相手側の問題だと主張し、切り分けだけで時間を消費します。装置の新規立ち上げでは一体発注のほうが整合性を保ちやすく、既設装置へのHMI追加や画面の刷新では分離発注が現実的になります。分離する場合は、境界仕様を発注側が文書として作り、両社に同じものを渡してください。加えて、既設装置へのHMI追加では制御盤側の改造が伴うため、盤の開口・電源・盤内スペースの確認を先に済ませておく必要があります。

ISA-101やIEC 63303への準拠は必須ですか?

装置単体の納入において、これらへの準拠が法的に義務づけられているわけではありません。ただし、参照する価値は十分にあります。ISA-101.01-2015と技術報告書のISA-TR101.01-2022、ISA-TR101.02-2019は、HMIを画面という成果物ではなく設計・実装・運用・継続的改善のライフサイクルとして扱い、連続・バッチ・ディスクリートのいずれにも適用されるとしています。2024年8月に発行されたIEC 63303 Edition 1.0は、このANSI/ISA-101.01を基に国際規格化されたもので、IEC TC65/SC65AのWG19が策定し、HMIの構想から廃止までの全ライフサイクル、用語とモデル、維持のための作業プロセスを定義しています。実務的には、これらの標準が示す考え方、すなわち平常時に何を出さないかを決めること、アラームを人の行動に紐づけること、そして納入後も維持し続ける前提を置くことを、社内の設計指針として取り込むだけでも効果があります。全条項への準拠を求めるより、この3点を発注仕様に反映するほうが現実的です。

タイ拠点で多言語のHMI画面を作るときの注意点は?

5点あります。第一に、枠は最も長くなる言語を基準に設計することです。日本語の文字数でボタンやラベルの枠を決めると、他言語に切り替えた瞬間に文字がはみ出します。第二に、タイ語の行の高さです。タイ文字は基線の上下に声調記号と母音記号が付くため縦方向に広い領域を必要とし、日本語基準で行間を詰めると記号が切れます。記号が欠けると語の意味が変わるため、体裁ではなく意味の問題です。第三に、ベトナム語のダイアクリティカルマークで、フォントによっては正しく表示されない場合があるため、実機のタッチパネルでの表示確認を検収項目に入れてください。第四に、翻訳を逐語訳で済ませないことです。アラームメッセージは「オペレーターの取るべき行動」が伝わる文に再設計する必要があります。第五に、翻訳と用語集は発注側で用意することです。装置の操作を実際に行う現地作業者が使う語彙は、拠点側にしかありません。これらの背景として、在タイ日系企業の賃金上昇率は2023年3.8%、2024年4.58%、2025年見込み4.64%と上昇幅が広がり、製造業ワーカーの人材不足感は42.3%とされています(JETRO)。現地作業者が自力で操作できる画面にすることは、体裁の問題ではなく拠点の運営能力の問題です。

まとめ

タッチパネルの画面設計を外注するという行為は、作画を外に出すことではなく、どの決定を自社に残し、どの決定を相手に渡すかを決めることです。費用と現場での定着を大きく動かしているのは、平常時に何を出さないかという情報設計、どのビットを人に見せ誰が何をするかというアラーム設計、誰がどの操作をどの言語で行うかという多言語と権限、そして画面に映した数値をどこに残すかというデータの出口、この4つの層です。ISA-101.01およびそれを基に2024年8月に国際規格化されたIEC 63303が示しているのも、HMIは画面という成果物ではなく、構想から廃止までのライフサイクルだという捉え方です。

アラーム設計については、参照できる定量的な目安があります。定常時は1オペレーターあたり10分に1件未満(1日あたり約150件が目安)、異常時ピークでも10分に10件未満、10分間に10件を超えるとアラームフラッド、常時発報は10件未満、優先度は高5%・中15%・低80%という配分です。これらを設計時の目標値として置くだけで、アラーム定義の議論が感覚論から抜け出します。そして合理化の7項目、すなわちタグ名・説明・原因・結果・オペレーターの行動・優先度・確認要否を1件ずつ書けるのは、その装置を運転する側だけです。

タイ拠点では、層3の重みが日本国内より大きくなります。在タイ日系企業の賃金上昇率は2023年3.8%、2024年4.58%、2025年見込み4.64%と上昇幅が広がり、製造業ワーカーの人材不足感は42.3%とされています(JETRO)。現地作業者が画面を読めない状態は、駐在員の張り付きという形で恒常的な工数として跳ね返り、その人がいなくなった瞬間に装置が誰にも設定できなくなります。多言語化と権限設計は、装置の使いやすさの話ではなく、拠点が装置を自力で運用できるかどうかの話です。JETROが指摘するタイ製造業の高度化への要請も、自動化設備の導入と同時に、それを現地で運用できる体制の整備を含んでいます。自動化機械設備・ロボット産業に対するBOIの投資奨励制度と合わせて、装置仕様を組み立てる初期段階で確認しておく価値があります。

最後に、契約面で1点だけ落とせない項目があります。プロジェクトファイルと設計資料、翻訳ファイルを受領する取り決めです。装置は10年以上動きますが、外注先との関係がその間ずっと続くとは限りません。ソースを受け取れない契約で導入した装置は、数年後に誰も手を入れられない装置になります。

タッチパネルの画面をこれから作る段階でも、すでに動いている装置の画面が現場で使われていないという段階でも、ご相談を承っています。既存の画面のスクリーンショットとPLCのデバイス一覧を見せていただければ、4層のどこが未整備で、どこから手をつけると効くのかについては当たりをお伝えできます。上位システムとの連携まで進めるかどうかを決めていない段階でも構いません。お問い合わせからお気軽にご連絡ください。

参考情報