タイで医療機器を登録・販売している日系企業にとって、「医療機器UDI対応をどこから手を付ければよいのか」は足元の実務課題になりつつあります。2026年6月20日に施行された新しい表示義務のことですが、この告示の対象は医療機器全般ではありません。リスク分類2〜4のSaMD(ソフトウェアを用いた医療機器)に限定されています。本記事では、規制の射程を正確に切り分けたうえで、対応の実体であるDI・PIの発番台帳をどう整えるか、そして架空の想定企業によるモデルケースでどれくらいの工数がかかるかを解説します。
医療機器UDI対応で何が変わったか — タイ保健省告示B.E.2568の概要
タイ保健省(Ministry of Public Health)は、リスク分類2〜4のSaMD(ソフトウェアを用いた医療機器、Software as a Medical Device)に対してUDI(Unique Device Identification、機器固有識別)の表示を求める告示を発出しました。この告示は2025年12月22日にタイの政府公報(官報)に掲載され、2026年6月20日に施行されています。
本記事で最も強調したい点を先に書きます。この告示が対象とするのは、リスク分類2〜4のSaMD(ソフトウェアを用いた医療機器)であって、医療機器全般ではありません。ハードウェアとしての物理的な医療機器そのものに対して、この告示によって新たにUDI表示が義務付けられたわけではありません。物理的な医療機器には、従来からの医療機器登録制度とラベリング規則が別途適用されており、本告示はそれとは別の枠組みとして、ソフトウェアを用いた医療機器に固有の識別の問題を扱っています。
この切り分けが重要なのは、実務上の影響範囲がまったく違うからです。「タイで医療機器にUDIが義務化された」という粗い理解のまま社内に共有してしまうと、本来は対象外である物理製品のラベル改訂プロジェクトが立ち上がってしまったり、逆に「うちはソフトウェアだけだから医療機器の規制は関係ない」と誤解してSaMDの対応が抜け落ちたりします。タイ現地法人と日本本社の間で対象範囲の認識がずれたまま時間が過ぎる、という事態は避けたいところです。
なぜ今ソフトウェアが対象になったのか
背景には、医療機器の実体がハードウェアからソフトウェアへ移りつつあるという世界的な流れがあります。血糖値や心電図の解析、画像診断の補助、投薬量の計算支援といった機能は、かつては専用機器に組み込まれていましたが、今はスマートフォンアプリやクラウドサービスとして提供されるものが増えました。そうなると、従来の「製造番号を筐体に刻印する」という識別手段が使えません。ソフトウェアには筐体がなく、しかも出荷後に何度もバージョンが変わります。
この「筐体がない、しかも中身が変わり続ける製品をどう一意に識別するか」という問題に対して、国際的にはUDIという枠組みが整備されてきました。タイの告示も、この国際的な流れに沿って、リスク分類2〜4のSaMD(ソフトウェアを用いた医療機器)の識別ルールを定めたものと位置づけられます。すでに米国・EUなど、IMDRF整合市場でUDIコードを取得・運用している企業にとっては、考え方そのものは既知のものです。
施行日と経過措置の関係を最初に整理する
告示の施行日は2026年6月20日です。ここに経過措置が組み合わさるのですが、この経過措置の適用範囲を取り違えると、対応スケジュールの前提が根本から崩れます。以下のように整理してください。
| 区分 | 適用のタイミング | 実務上の意味 |
|---|---|---|
| 既存登録のSaMD(リスク分類2〜4) | 2020年告示に準拠していたラベル・添付文書は、施行日から最長2年間(2028年6月頃まで)継続使用できる | 直ちにラベルを刷り直す必要はない。準備期間を計画的に使える |
| 新規登録のSaMD(リスク分類2〜4) | 施行日(2026年6月20日)から新要件が適用される | これから登録する製品には猶予がない。登録申請の前に対応が必要 |
| リスク分類1のSaMD | 本告示の対象外 | 本告示による新たなUDI表示義務は生じない |
| 物理的な医療機器(ハードウェア) | 本告示の対象外 | 従来の医療機器登録・ラベリング規則が別途適用される |
この表で見落とされやすいのは2行目です。既存製品に2年の猶予があることばかりが社内に伝わり、新製品の登録申請の直前になって「UDIの発番ができていない」と気づくパターンです。新規登録に猶予はありません。これから新しいSaMD(リスク分類2〜4)をタイ市場に投入する計画があるなら、対応は今すぐ着手すべき課題です。
対象となるSaMDの範囲とリスク分類
本記事の要となる章です。ここで自社製品が対象かどうかを判定できるところまで具体化します。
タイの医療機器規制では、医療機器をリスクの度合いに応じて4段階に分類しています。今回のUDI表示義務が及ぶのは、このうちリスク分類2(中等度リスク)、リスク分類3(中等度から高リスク)、リスク分類4(高リスク)に該当するSaMD(ソフトウェアを用いた医療機器)です。リスク分類1(低リスク)のSaMDは、本告示の対象外とされています。
つまり判定は2段階です。第1段階は「その製品はSaMDか」、第2段階は「そのSaMDのリスク分類は2〜4か」です。どちらかがNOであれば、本告示によるUDI表示義務は生じません。
第1段階 — その製品はSaMDか
SaMDは、ハードウェアの医療機器の一部として組み込まれているのではなく、それ自体が独立して医療目的を果たすソフトウェアを指すのが一般的な整理です。スマートフォンアプリ、PCソフトウェア、クラウド上で動作するサービスなど、提供形態は問いません。
実務では、次のような線引きの判断が難しくなります。
| 製品の形 | 一般的な考え方 | 判定で見るポイント |
|---|---|---|
| 測定機器に組み込まれた制御ソフト | 機器と一体の組込みソフトウェアとして扱われることが多い | 単体で流通・更新されるか、機器と一体でしか使えないか |
| 測定機器のデータを解析する独立アプリ | 独立して医療目的を果たすならSaMDに該当しうる | 機器がなくても医療上の判断に使えるか |
| 記録・閲覧だけを行うビューワ | 医療上の判断に関与しないなら医療機器に当たらない場合がある | 解析・提案・警告など判断への関与があるか |
| 院内の予約・会計を扱う業務システム | 医療目的の判断を行わないなら医療機器に当たらない場合が多い | 患者の診断・治療方針に影響するか |
この判定はグレーゾーンが広く、最終的には登録実務の中でタイ当局および専門家の判断を仰ぐ領域です。この表はあくまで社内で議論を始めるための目安として使ってください。
第2段階 — リスク分類の考え方
リスク分類は、そのソフトウェアが出す情報が患者にどれだけ重大な影響を与えうるかで判断されます。ごく大まかには、次のような方向感で理解しておくと社内の議論が進みます。
| リスク分類 | 大まかな性質 | 本告示のUDI表示義務 |
|---|---|---|
| リスク分類1 | 低リスク。健康管理の補助的な情報提供にとどまるもの | 対象外 |
| リスク分類2 | 中等度リスク。治療方針の判断を支援する情報を提供するもの | 対象 |
| リスク分類3 | 中等度から高リスク。重篤な状態の判断に関与するもの | 対象 |
| リスク分類4 | 高リスク。生命に直結する判断に関与するもの | 対象 |
この表の「大まかな性質」は社内で議論の当たりを付けるための目安であり、当局が定める分類の定義文そのものではありません。実際の分類は、タイの医療機器規制における定義と当局の判断に従います。
自社製品のリスク分類は、多くの場合すでにタイでの医療機器登録の過程で確定しているはずです。登録証や申請書類を確認すれば、分類は書かれています。新たに分類の判定作業を一から行う必要はなく、まずは既存の登録情報を棚卸しすることから始めてください。
対象判定の結果を一覧にしておく
複数の製品を扱っている企業ほど、この判定結果を製品ごとの一覧表にして残しておく価値が大きくなります。後述するUDI発番台帳は、この対象判定一覧を出発点として組み立てていくことになります。「対象外と判断した製品について、なぜ対象外なのか」を書き残しておくことが、数年後の当局対応や社内の引き継ぎで効いてきます。
UDIの正体 — DI(固定識別子)とPI(可変情報)、ロット・シリアル管理との共通点と違い
「UDI対応」と聞くと、多くの方がまず「ラベルにバーコードを追加する作業」を思い浮かべます。しかしこれは対応の最後の1割にすぎません。本質は、識別子を発番し、その履歴を管理する台帳を社内に持つことにあります。
UDIは国際的にDIとPIの2要素で構成される
国際的なUDIのフレームワークでは、UDIは大きく2つの要素で構成されるのが一般的な整理です。IMDRFやGS1などが提示してきた枠組みでも、この2要素の考え方が共通しています。
| 要素 | 内容 | 変わるタイミング |
|---|---|---|
| DI(Device Identifier、固定識別子) | 製品そのものを一意に指す固定のコード。製造業者と製品モデルの組み合わせを表す | 製品が同一である限り変わらない |
| PI(Production Identifier、可変情報) | ロット番号、シリアル番号、バージョン番号、製造日、有効期限など、個々の出荷単位ごとに変わる情報 | 出荷単位・リリースごとに変わる |
DIは「この製品は何か」を、PIは「そのうちのどの個体・どのバージョンか」を表します。この2つが揃って初めて、市場に出た製品を一意に特定できます。
ここで書き分けを明確にしておきます。DIとPIという分割そのものは、国際的なUDIフレームワークにおける一般的な整理であって、タイの告示がこの分割仕様を固有に定めているわけではありません。リスク分類2〜4のSaMD(ソフトウェアを用いた医療機器)についてタイの告示が定めているのは、ラベルに記載すべき項目です。具体的には、製品名と使用目的、ロット番号・バージョンまたはシリアル番号、製造日と有効期限が挙げられています。
つまり実務としては、国際的なDI/PIの枠組みで社内の識別体系を設計しつつ、リスク分類2〜4のSaMD(ソフトウェアを用いた医療機器)についてタイの告示が求めるラベル記載項目を確実に満たす、という二層の作業になります。すでに米国やEUなどでUDIコードを保有している企業であれば、この設計はすでに済んでいることになり、タイ市場での主な残作業はタイFDAのUDIデータベースへのマスターデータ提出になるとされています。
ロット管理・個体管理のノウハウがそのまま使える
ここが製造業にとっての朗報です。DIとPIという構造は、工場で長年やってきたロット管理・シリアル管理とまったく同じ構造をしています。
| 製造現場の概念 | UDIでの対応物 | 共通する管理の勘所 |
|---|---|---|
| 品番・図番 | DI(固定識別子) | 一度決めたら安易に変えない。変える基準を規程で決める |
| ロット番号 | PI(ロット・バージョン) | 発番ルールを決め、採番の重複を防ぐ台帳を持つ |
| シリアル番号 | PI(シリアル) | 個体まで追う必要があるかを費用対効果で判断する |
| 現品票・出荷ラベル | UDIラベル・添付文書 | 表示媒体と表示項目を分けて管理する |
ロット単位で追うか個体単位で追うかという判断は、製造業のトレーサビリティ設計における古典的な論点で、この経済判断については個体管理システム導入2026で詳しく整理しています。SaMDの場合、この判断は「バージョン単位で追うか、ライセンス発行単位まで追うか」という形に置き換わりますが、考え方の骨格はまったく同じです。
ソフトウェア特有の難しさは「変わり続けること」
一方で、ソフトウェアには物理製品にない難しさがあります。それは、出荷後も更新され続けるという点です。
物理的な製品なら、出荷した瞬間にその個体の仕様は確定します。しかしSaMDは、ユーザーの手元でアップデートが走り、昨日まで v2.3.1 だったものが今日は v2.4.0 になります。このとき、UDIのPI部分をどう扱うかが設計上の論点になります。
さらに厄介なのは、「どのバージョンをリリースと呼ぶか」の社内定義が曖昧な組織が多いことです。開発チームはバグ修正のたびにパッチ番号を上げますが、その一つひとつを規制上のリリースとして扱っていては台帳が回りません。規制対応としてPIを更新すべき変更と、社内的なパッチにとどまる変更の線引きを、開発部門と品質保証部門で事前に合意しておく必要があります。
医療機器UDI対応に必要な4つの実務ステップ
ここまでの整理を踏まえ、リスク分類2〜4のSaMD(ソフトウェアを用いた医療機器)を持つ企業が実際に踏むべきステップを4つに分けて示します。
ステップ1 — 対象製品の棚卸しと判定
自社がタイで登録しているすべての医療機器を一覧にし、SaMDかどうか、リスク分類は何か、既存登録か今後の新規登録か、を列にした表を作ります。この段階で、経過措置の対象になる製品と、猶予なく対応が必要な製品が分かれます。所要日数は製品数によりますが、登録情報が整理されている企業なら数日で終わります。
ステップ2 — DI/PIの発番ルールを設計し、社内規程にする
自社製品にどういう体系でDIを与えるか、PIには何を含めるかを決めます。ここで決めるべきことは、おおむね次の項目です。
- DIの形式を何に準拠させるか(GS1のGTIN形式など、国際的に通用する形式を選ぶのが実務的です)
- 製品のどの単位でDIを分けるか(製品モデル単位か、提供形態単位か)
- PIに何を含めるか(バージョン番号、リリース日、ライセンス単位のシリアルなど)
- どの程度の変更でPIを更新するか(メジャー・マイナー・パッチのどこからを規制上のリリースとするか)
- 台帳のオーナーは誰か(開発部門か品質保証部門か)
この設計を文書化して社内規程に落とすところまでがステップ2です。ここを飛ばして実装に入ると、後から「そもそもどういう基準で番号を振ったのか」を誰も説明できなくなります。
ステップ3 — 台帳とシステムを整える
設計した発番ルールに従って、実際の台帳を作ります。最初はスプレッドシートでも構いませんが、リリースのたびに更新される性質のものなので、更新の抜けが起きない仕組みにしておく必要があります。あわせて、アプリの起動画面や設定画面、添付文書にUDIを表示する機能を実装します。
この「台帳を作り、システムに乗せる」という作業の進め方は、業種を問わないトレーサビリティ構築の一般論と共通する部分が多く、4層モデルによる整理と90日ロードマップの考え方はトレーサビリティ構築の費用と進め方にまとめています。医療機器規制固有の要求は本記事で、システム構築の進め方は同記事で、と読み分けていただくのが効率的です。
なお、識別子を物理的にどう表現するかを検討する場面も出てきます。SaMDそのものは画面表示が中心ですが、パッケージ版やライセンスカードなど物理媒体を伴う提供形態では、バーコードの種類を選ぶ必要があります。QRコード・刻印・RFIDのどれを選ぶべきかという判断基準はトレーサビリティのバーコード選定2026で整理しています。
ステップ4 — UDIデータベースへのマスターデータ登録
タイFDAのUDIデータベースへ、製品のマスターデータを提出します。すでに米国・EUなどでUDIコードを保有している企業にとっては、タイ市場での主な残作業がここになるとされています。逆に、ゼロから対応する企業にとっては、ステップ2とステップ3を終えていることが提出の前提になります。
4つのステップの関係を整理すると、次のようになります。
| ステップ | 主担当 | 成果物 | 先に済ませておくべきこと |
|---|---|---|---|
| 1 対象製品の棚卸し | 薬事・品質保証 | 対象判定一覧 | 既存の登録証・申請書類の収集 |
| 2 発番ルール設計 | 品質保証と開発の合同 | 社内規程、DI/PI体系 | ステップ1 |
| 3 台帳整備とシステム改修 | 開発、情報システム | 発番台帳、UDI表示機能 | ステップ2 |
| 4 データベース登録 | 薬事 | 提出済みマスターデータ | ステップ2とステップ3 |
この順序を入れ替えることはできません。とくにステップ2を後回しにして先にシステム改修に入る進め方は、手戻りの温床になります。
モデルケースで見る対応コストと工数
ここからは、対応にどれくらいの手間がかかるのかを具体的な数字で見ていきます。以下に登場する「D社」は架空の想定企業であり、工数と費用はすべて当社による独自試算です。実在の統計や調査結果ではありません。
想定するD社の状況
D社は、タイに現地法人を持つ日系の医療機器メーカーです。血糖値管理を支援するスマートフォンアプリを開発し、タイ保健省に登録・販売しています。このアプリは医師の治療方針判断を支援する機能を持ち、ハードウェアを伴わない単体のソフトウェア医療機器、すなわちSaMDに該当します。リスク分類は2です。
D社は自社で物理的な血糖測定器も製造しており、そちらは従来からロット番号による管理を行っています。しかしアプリ側は開発チームがGitのタグでバージョンを管理しているだけで、規制対応としてのDI(固定識別子)の発番や、UDIデータベースへの登録という概念そのものが社内に存在していませんでした。
つまりD社は、物理製品のトレーサビリティのノウハウは持っているのに、それがソフトウェア側に接続されていない状態です。ハードウェアとソフトウェアの両方を扱う医療機器メーカーでは、起こりやすい構図といえます。
対応前と対応後の比較
D社がUDI発番台帳を整備した前後で、何がどう変わったかを整理します。
| 項目 | 対応前(現状) | 対応後(UDI発番台帳整備後) |
|---|---|---|
| 識別子の設計 | 開発チームのGitタグ(例 v2.3.1)のみ。規制用の固定DIなし | GS1準拠のGTIN形式でDIを1つ発番。リリースごとにPI(バージョン番号+リリース日)を追記する台帳を運用 |
| 表示箇所 | アプリ内の設定画面にバージョン番号のみ表示 | ラベル・添付文書・アプリ起動画面にUDI(DI+PI)を表示 |
| データベース登録 | 未実施 | タイFDAのUDIデータベースへマスターデータを提出済み |
| 社内の管理責任者 | 開発リーダーが兼務、規制対応としての位置づけなし | 品質保証部門がUDI発番台帳のオーナーとなり、リリースの都度更新する運用に変更 |
この比較で最も大きな変化は、実は一番下の行です。技術的な実装よりも、「誰が台帳を持つか」を決めたことのほうが、継続的な運用の成否を分けます。開発リーダーの兼務のままだと、多忙なリリース直前に台帳の更新が後回しになり、いずれ実態とずれます。
初期対応に要した工数
D社が初期対応に投じた工数の内訳は次のとおりです。いずれも独自試算です。
| 作業項目 | 工数 | 内容 |
|---|---|---|
| 発番ルール設計 | 3人日 | DI/PIの体系決定、社内規程化 |
| システム改修 | 10人日 | アプリ起動画面・添付文書へのUDI表示機能追加 |
| UDIデータベース登録作業 | 2人日 | マスターデータの整備と提出 |
| 合計 | 15人日 | — |
合計は15人日です。これを外部のシステム開発・規制コンサルティングに委託した場合、SE単価を3万〜5万THB/人日と仮定すると、費用の目安は45万THB〜75万THBという試算になります。単価の仮定を置いた独自試算であり、実際の見積もりは製品構成や委託範囲によって変動します。
この内訳で注目していただきたいのは、15人日のうち10人日、つまり3分の2がシステム改修に占められている点です。逆に言えば、規制の理解と発番ルールの設計そのものは3人日で、それほど重い作業ではありません。重いのは、決めたルールをアプリと添付文書に反映する実装のほうです。
経過措置を使うと改修コストを圧縮できる
そしてここが実務上の勘所になります。この10人日の改修は、次回の大きなバージョンアップ(メジャーリリース)のタイミングに合わせて実施すれば、そのリリースのための開発作業と一体で進められるため、追加の改修コストをほぼゼロに圧縮できるという試算が成り立ちます。圧縮できるのはこの改修部分であって、発番ルール設計の3人日とデータベース登録作業の2人日は、どのタイミングで対応しても必要な作業として残ります。
既存登録のSaMD(リスク分類2〜4)には、施行日である2026年6月20日から最長2年間、つまり2028年6月頃までの経過措置があります。この2年間のうちにメジャーリリースが1回でも計画されているなら、UDI表示機能をそのリリースのスコープに含めてしまうのが最も経済的です。
ただし、繰り返しになりますが、この経過措置が適用されるのは既存登録のSaMD(リスク分類2〜4)だけです。新規登録のSaMD(リスク分類2〜4)には施行日から新要件が即時適用されるため、この圧縮策は使えません。新製品の登録を控えているなら、その開発スケジュールの中にUDI対応を最初から組み込む必要があります。
対応の進め方を3つのパターンで比較すると、次のようになります。
| パターン | 想定される状況 | 改修コストの見通し |
|---|---|---|
| 経過措置内でメジャーリリースに合わせる | 既存登録製品で、2028年6月頃までに大型改修が計画されている | 改修10人日分の追加コストをほぼゼロに圧縮できる。設計3人日と登録2人日は残る |
| 経過措置内で単独プロジェクトとして実施する | 既存登録製品だが、大型改修の予定がない | 15人日相当、45万THB〜75万THBが目安 |
| 新規登録に合わせて即時対応する | これから登録するリスク分類2〜4のSaMD | 登録スケジュールが制約になるため、前倒しの着手が必須 |
自社がどのパターンに当たるかは、ステップ1の対象製品の棚卸しをすれば自動的に決まります。まずは棚卸しから始めてください。
タイで進める際の実務ポイント
リスク分類2〜4のSaMD(ソフトウェアを用いた医療機器)に対するUDI表示義務の中身が分かっても、タイで実際に手続きを進める段階では、日本と勝手が違う論点がいくつも出てきます。ここでは現地で押さえておきたい4点を挙げます。
ポイント1 — 経過措置の対象を取り違えない
すでに繰り返し書いてきましたが、現地でのプロジェクト管理上、最も事故が起きやすいのがここです。経過措置は既存登録のSaMD(リスク分類2〜4)に対してのみ、施行日から最長2年間です。新規登録のSaMD(リスク分類2〜4)は施行日から即時適用です。
日本本社と現地法人の間でスケジュールを共有する際は、必ず製品ごとに「既存登録か新規登録か」を明記してください。「2028年6月まで猶予がある」という一文だけが独り歩きすると、新規登録製品の対応が遅れます。
ポイント2 — 表示言語の要件を確認する
対象となるリスク分類2〜4のSaMD(ソフトウェアを用いた医療機器)の表示言語については、家庭用のものはタイ語表示、医療従事者向けのものはタイ語または英語表示が認められるとされています。
これは実装に直接影響します。同じアプリを一般消費者向けにも医療機関向けにも提供している場合、提供先によって表示言語の要件が変わりうるためです。UI設計の段階で、UDIの表示部分を含むラベル・添付文書相当の画面を多言語対応にしておくのが安全です。
なお、物理的なラベルや同梱物を伴う提供形態がある場合、表示内容の改訂が発生するたびにラベルの版管理が必要になります。ラベル発行を手作業で回している工場では、この改訂対応が慢性的な負荷になりがちです。ラベル運用そのものをシステム化して版管理を自動化する考え方はラベル発行システム2026で整理していますので、あわせてご覧ください。
ポイント3 — UDIデータベース登録の実務は流動的
対象となるリスク分類2〜4のSaMD(ソフトウェアを用いた医療機器)については、タイFDAのUDIデータベースへのマスターデータ提出が対応の最終ステップになります。ただし、タイFDAの電子申請システムがUDI関連手続きに未対応であるとの実務者コメントが業界メディアで報じられています。これは一次情報ではなく業界解説記事に基づく情報であるため、断定的には書けませんが、実務上は次のような備えをしておく価値があります。
- 提出フォーマットが確定していない前提で、マスターデータを構造化した形(製品名、DI、PI体系、使用目的、製造日など)で自社側に保持しておく
- 提出手段が電子申請に限らない可能性を織り込み、書面での提出も想定した資料を準備しておく
- 現地の薬事コンサルタントや業界団体を通じて、手続きの最新状況を定期的に確認する
要するに、「データベースに登録する」という最終工程の手順が固まるのを待ってから台帳整備を始めるのではなく、台帳を先に作っておいて、提出手順が固まったらすぐ出せる状態にしておくのが賢明です。台帳さえあれば、提出形式が変わっても対応できます。
ポイント4 — 海外でUDIを持っているかどうかで作業量が大きく変わる
リスク分類2〜4のSaMD(ソフトウェアを用いた医療機器)を扱う企業のうち、すでに米国・EU・その他IMDRF整合市場でUDIコードを保有しているところでは、タイ市場での主な残作業はタイFDAのUDIデータベースへのマスターデータ提出になるとされています。DIの体系はすでにあり、PIの運用も回っているため、タイ向けに新たな設計をする必要が薄いからです。
一方、本記事のモデルケースであるD社のように、タイと日本でしか展開しておらず、UDIという枠組み自体が社内にない企業は、台帳整備から始める必要があります。両者を分けるのは、先に挙げたステップ2の発番ルール設計とステップ3のシステム改修が丸ごと必要になるかどうかであり、工数への影響は小さくありません。
自社がどちらに当たるかを最初に確認してください。グループ会社が米国やEUで同種製品を展開している場合、そちらの発番体系を流用できる可能性があります。タイ現地法人だけで検討を始める前に、本社の薬事部門に「グローバルでUDIの発番体系があるか」を一度問い合わせる価値は十分にあります。
よくある失敗
リスク分類2〜4のSaMD(ソフトウェアを用いた医療機器)のUDI対応をタイで進める際に起きやすい、あるいは起こりうるつまずき方を整理します。
失敗1 — 「医療機器全般にUDIが義務化された」と社内に伝えてしまう
起きやすい誤解です。この告示の対象は、リスク分類2〜4のSaMD(ソフトウェアを用いた医療機器)に限定されています。リスク分類1のSaMDは対象外であり、物理的な医療機器も本告示の対象ではありません。物理製品には従来からの医療機器登録・ラベリング規則が別途適用されます。
社内共有の一文目を「SaMDのうちリスク分類2〜4が対象」と正確に書くだけで、無駄なプロジェクトの立ち上げと、必要な対応の見落としの両方を防げます。
失敗2 — ラベル作業だと思って外注に丸投げする
UDI対応をラベルデザインの改訂作業だと捉え、印刷業者やデザイン会社に依頼してしまうケースです。実体は識別子の発番と台帳の運用設計であり、印刷の話は最後の工程にすぎません。発番ルールを社外の誰かが決めることはできませんし、決めてもらっても社内で運用できません。
失敗3 — 発番台帳のオーナーを決めないまま実装だけ進める
システム改修は終わったのに、リリースのたびに台帳を更新する担当が決まっていない状態です。半年後には台帳と実際のバージョンがずれ、当局対応の場面で説明できなくなります。D社のモデルケースで品質保証部門をオーナーに変えたのは、この事態を避けるためです。
失敗4 — 開発のパッチ番号をそのままPIに流し込む
規制上のリリースと社内のパッチを区別せず、Gitのタグをそのまま台帳に流し込む設計です。台帳のレコード数が膨大になり、更新が追いつかなくなります。どの粒度の変更をPIの更新とするかを、規程で先に決めてください。
失敗5 — 経過措置の2年を「何もしなくていい2年」と読む
既存登録のSaMD(リスク分類2〜4)に最長2年の経過措置があるのは事実ですが、これは準備のための期間です。しかも、この期間内のメジャーリリースに合わせて対応すれば改修10人日分の追加コストをほぼゼロにできるという試算があるとおり、計画的に使えば経済的なメリットが得られます。何もせずに2年を過ごすと、期限直前に単独プロジェクトとして15人日相当の作業を積むことになります。
失敗6 — 新規登録製品を経過措置の対象と誤認する
失敗1と並んで影響の大きい誤認です。新規登録のSaMD(リスク分類2〜4)には施行日から新要件が適用されます。登録申請の直前にUDIが用意できておらず、申請そのものが止まる、という事態が最悪のシナリオです。
よくある質問
医療機器UDI対応はタイで販売するすべての医療機器が対象ですか
いいえ。2026年6月20日に施行された本告示の対象は、リスク分類2〜4のSaMD(ソフトウェアを用いた医療機器)に限定されています。リスク分類1のSaMDは対象外です。また、物理的な医療機器そのものは本告示の対象ではなく、従来からの医療機器登録・ラベリング規則が別途適用されます。
SaMDのUDI表示はどこに表示すればよいですか
対象となるリスク分類2〜4のSaMD(ソフトウェアを用いた医療機器)について、タイの告示ではラベルに記載すべき項目として、製品名と使用目的、ロット番号・バージョンまたはシリアル番号、製造日と有効期限が挙げられています。本記事のモデルケースであるD社(架空の想定企業)では、ラベル・添付文書に加えてアプリの起動画面にもUDI(DI+PI)を表示する構成としました。ソフトウェア製品の場合、利用者が実際に目にする画面での表示を含めて設計するのが実務的です。
医療機器のトレーサビリティとUDIはどう違いますか
トレーサビリティは、製品や部品がどこから来てどこへ行ったかを追跡できる状態を指す一般的な概念です。UDIは、その追跡を成り立たせるための「識別子の付け方の国際的な約束事」に当たります。UDIはDI(固定識別子)とPI(可変情報)の2要素で構成されるのが国際的に一般的な整理で、この構造は工場のロット管理・シリアル管理と同じ考え方です。トレーサビリティ全体の設計手順についてはトレーサビリティ構築の費用と進め方をご覧ください。
UDIデータベース登録には何が必要ですか
対象となるリスク分類2〜4のSaMD(ソフトウェアを用いた医療機器)について、タイFDAのUDIデータベースへマスターデータを提出することになります。前提として、DI/PIの発番ルールが確定し、製品ごとの識別子が台帳として整理されている必要があります。なお、タイFDAの電子申請システムがUDI関連手続きに未対応であるとの実務者コメントが業界メディアで報じられているため、提出手順の最新状況は現地の薬事専門家を通じて確認することをお勧めします。
米国やEUですでにUDIコードを持っている場合、タイでは何をすればよいですか
対象となるリスク分類2〜4のSaMD(ソフトウェアを用いた医療機器)について、すでに米国・EU・その他IMDRF整合市場でUDIコードを保有している企業にとって、タイ市場での主な残作業はタイFDAのUDIデータベースへのマスターデータ提出になるとされています。発番体系がすでにあるため、ゼロから台帳を作る企業に比べて作業量は大幅に軽くなります。まずは本社やグループ会社に既存の発番体系があるかを確認してください。
経過措置の2年間はいつまでで、どの製品に適用されますか
2020年告示に準拠していた既存登録のSaMD(リスク分類2〜4)のラベル・添付文書は、施行日である2026年6月20日から最長2年間、つまり2028年6月頃まで継続使用できるとされています。この経過措置が適用されるのは既存登録の製品のみで、新規登録のSaMD(リスク分類2〜4)には施行日から新要件が適用されます。
SaMDのラベルはタイ語で表示しなければなりませんか
対象となるリスク分類2〜4のSaMD(ソフトウェアを用いた医療機器)のうち、家庭用のものはタイ語表示、医療従事者向けのものはタイ語または英語表示が認められるとされています。同一製品を一般消費者にも医療機関にも提供している場合は、提供先によって要件が変わりうるため、多言語での表示切り替えを想定した設計にしておくのが安全です。
UDI対応にはどれくらいの工数がかかりますか
本記事の架空の想定企業D社(リスク分類2のSaMDを1製品保有)のケースでは、発番ルール設計3人日、システム改修10人日、UDIデータベース登録作業2人日の合計15人日という独自試算になりました。外部委託した場合の費用目安は、SE単価を3万〜5万THB/人日と仮定して45万THB〜75万THBです。ただし製品数や既存の管理体制によって大きく変動します。
まとめ
タイで2026年6月20日に施行された、リスク分類2〜4のSaMD(ソフトウェアを用いた医療機器)を対象とするUDI表示義務について、実務の観点から整理してきました。最後に要点を確認します。
第一に、この告示の対象はリスク分類2〜4のSaMD(ソフトウェアを用いた医療機器)に限定されています。リスク分類1のSaMDは対象外であり、物理的な医療機器そのものも本告示の対象ではなく、従来からの医療機器登録・ラベリング規則が別途適用されます。「医療機器全般にUDIが義務化された」という理解は誤りです。
第二に、対応の実体はラベルにバーコードを貼る作業ではなく、DI(固定識別子)とPI(可変情報)を発番・管理する台帳を社内に持つことです。UDIが国際的にDIとPIの2要素で構成されるという枠組みを土台に、リスク分類2〜4のSaMD(ソフトウェアを用いた医療機器)についてタイの告示が定めるラベル記載項目を満たす設計をします。
第三に、この台帳運用は製造現場のロット管理・シリアル管理と同じ構造をしています。物理製品でトレーサビリティを回してきた企業なら、そのノウハウをソフトウェアのバージョン管理に転用できます。
第四に、既存登録のSaMD(リスク分類2〜4)には施行日から最長2年間の経過措置がありますが、新規登録のSaMD(リスク分類2〜4)には施行日から新要件が適用されます。この違いを取り違えないでください。経過措置の期間内にメジャーリリースを計画しているなら、そこにUDI表示機能の実装を含めることで改修10人日分の追加コストをほぼゼロに圧縮できるという試算も成り立ちます。
まずやるべきことは1つです。タイで登録している自社製品を一覧にし、SaMDかどうか、リスク分類は何か、既存登録か新規登録かを埋めてください。それだけで、自社に猶予があるのかないのかが決まります。
自社製品が対象に当たるのかどうかの切り分けや、DI/PIの発番台帳をどう設計してどの部門が持つべきか、既存の生産管理システムやラベル発行の仕組みとどう接続するかといった論点は、製品構成や社内体制によって答えが変わります。TOMAS TECHはタイで日系製造業向けにトレーサビリティと現品管理の仕組みづくりを支援しており、規制対応をきっかけに社内の識別体系を整理し直したいというご相談にも対応しています。まだ検討を始めたばかりで要件が固まっていない段階でも構いませんので、状況の整理からご一緒したい場合はお問い合わせページからお気軽にお声がけください。
参考情報
- Tilleke & Gibbins「Thailand Introduces UDI Labeling Requirements for Software as a Medical Device」
- Mondaq「Thailand Introduces UDI Labeling Requirements For Software As A Medical Device」
- Siam Development(業界解説記事、タイFDAのUDI関連手続きに関する実務者コメント)
- Thai FDA(タイ食品医薬品局)公式サイト
- IMDRF(International Medical Device Regulators Forum)公式サイト
- GS1 Healthcare(医療分野の識別標準)
- Ratchakitcha(タイ政府公報)公式サイト
