製造業で「点検未実施アラート管理システムを導入したい」と考えるとき、電子点検表を作るだけでは目的を達成できません。点検予定が発生したのに、期限までに誰も実施せず、その事実を責任者が翌日まで知らないことが問題だからです。必要なのは、設備・点検項目・実施予定回を識別し、期限を判定し、未実施を担当者に届け、確認と是正を記録する仕組みです。本稿では、日次・シフト・暦日の期限計算、休止や代行の例外、段階的エスカレーション、追完と未実施の区別、証跡、RFPとFAT/SATを一つの運用として設計します。
点検表の入力項目や紙から電子への移行は別のテーマです。本稿は予定された点検が欠落した瞬間からの対応に絞ります。校正管理や法定点検の資格判断も対象外です。文中の時刻、件数、期限、工数はすべて仕組みを説明するための仮定例であり、実測値やTOMAS TECHの導入効果ではありません。
紙の項目を電子フォームに移す基礎は点検表の電子化ガイドを、既存の紙記録を読み取って保全データとつなぐ論点は設備点検表とAI-OCRの導入ガイドを参照してください。本稿では、フォームや文字認識の有無にかかわらず、予定回と責任者が定義されていることを前提にします。
点検予定と点検結果を別の記録として管理する
点検結果のデータベースに今日の入力が無いことだけでは、未実施とは断定できません。休日で予定が無かったかもしれず、設備が停止中かもしれず、夜勤の期限が翌朝までかもしれません。最初に必要なのは、設備ごとに「この回の点検を、いつ、どの条件で、誰が行う予定だったか」という予定インスタンスです。点検マスターは周期を定義し、予定インスタンスは特定の実施義務を表し、点検結果は実際の観察を表します。三つを分けると、結果がない理由を説明できます。
予定インスタンスには、予定ID、設備ID、点検項目版、適用ライン、予定開始・期限、タイムゾーン、シフト、一次担当、代理担当、リスク区分、生成根拠のマスター版を持たせます。結果には、予定IDへの参照、実施者、実施時刻、登録時刻、観察値、判定、端末、添付、訂正履歴を持たせます。「設備Aの日常点検」という名称だけで照合すると、昨日の遅い入力が今日の予定を誤って満たす恐れがあります。予定ID単位の一対一または承認された複数結果という関係を明示します。
電子点検表は結果の入力体験を改善しますが、未実施アラートは予定と結果の照合から生まれます。Microsoftの公式資料には、保全計画から保全作業指示を作る手順、担当者に割り当てられた作業と点検チェックリストをモバイルで扱う機能、作業指示内の点検フォームが記載されています。ただし、これらの説明だけで本稿の未実施判定、代理担当への通知、追完区分が全環境で標準装備されるとは言えません。導入候補の設定と追加開発範囲を確認してください。
期限はシフト・稼働日・暦日で計算を分ける
「毎日点検」は一つの期限式ではありません。毎日08:00まで、始業前、各シフト開始後30分以内、稼働した日だけ、毎暦日など、現場ごとに意味が違います。予定生成規則には、対象日・シフト、開始条件、締切、猶予、休日カレンダー、設備の稼働状態、改訂版を入れます。工場はAsia/Bangkok、サーバーはUTCでも、保存時刻はタイムゾーン付きの絶対時刻として扱い、画面では現地時刻とシフト名を表示します。日跨ぎの夜勤を単純に0時で区切ると、前夜の点検が翌日の未実施と混同されます。
仮定例として、夜勤が20:00開始、翌08:00終了し、点検期限を開始後30分とします。この回の期限は20:30であり、翌00:00ではありません。20:31に結果が無ければ未実施候補ですが、端末がオフラインで20:25の実施記録を21:00に送信した場合、発生時刻とサーバー受信時刻を区別して判定を訂正する必要があります。オフライン入力を無条件に信じるのではなく、端末時刻のずれと後入力の権限を管理します。この数字は設計説明用で、現場の許容時間を示すものではありません。
日曜は操業しないラインでは予定を作らない一方、停止中でも安全確認が必要な設備では予定を維持します。設備停止、計画休止、改造、外部業者への引渡しなどの例外を一律の「スキップ」にしないでください。予定を発生させない条件、発生した予定を延期する条件、責任者が承認して免除する条件を分け、理由と期間を保存します。点検の実施義務そのものが残るのかを安全・品質担当と合意することが先です。
予定生成を毎日夜間バッチで行う場合は、バッチ失敗で「予定が存在しないから未実施も見えない」状態を防ぎます。翌日の予定件数、生成失敗件数、設備マスターとの照合差を監視し、生成処理の失敗を別の運用警報にします。予定を長期間先まで作る方式なら、マスター改訂時に将来分をどう更新するかを決めます。過去分の予定を無言で上書きしないように版を残します。
周期が変わる設備をどう扱うか
点検には、毎シフト・毎日・毎週のような時間周期と、稼働時間や生産回数に応じるカウンター周期があります。カウンター周期では計画値に到達した時刻が予定の発生条件になりますが、カウンター信号の欠損やリセットがあれば、予定自体が生成されない恐れがあります。信号の最終受信時刻、カウンターの単調増加、交換時の初期値、手動補正を監視し、入力が古い間は「期限内」と表示せず「判定不能」と区別します。時間周期とカウンター周期を併用する設備では、先に到達した条件で一回だけ予定を作るのか、二つの予定を別々に管理するのかを決めます。
臨時稼働、休日出勤、製品切替も周期に影響します。普段は休業の土曜に設備を動かすなら、始業前点検を臨時に発生させる場合があります。逆に操業予定だった日に設備を動かさなかった場合、予定が残るか免除となるかは点検目的によります。例外の判断者を明確にし、あとから操業実績に合わせて無断で予定を消さないことが重要です。点検予定と生産予定の同期が遅れる場合は、一時的に「要確認」の事案を作り、人が判断できるようにします。
点検期限超過アラートの状態を細かく決める
少なくとも「予定」「実施済み」「期限超過」「通知済み」「確認済み」「対応中」「追完済み」「未実施で確定」「免除承認済み」を区別します。通知済みはメッセージが送られた状態、確認済みは責任者が受け取った状態、実施済みは有効な点検結果がある状態です。通知を開いたことを点検完了と扱ってはいけません。同様に、期限後に追完した点検を「期限内実施」に書き換えず、期限超過の事実と実際の実施時刻を両方残します。
追完とは、期限後に点検を実施し、必要な観察値と実施者を記録した状態です。未実施で確定とは、その予定回の点検が行われなかったことを責任者が確認し、理由と影響評価を残した状態です。両者は改善の意味が違います。翌日にまとめて「実施済み」と入力すると、点検の空白時間が消え、異常発見の遅れを評価できません。後入力が必要な場合は、実施時刻と登録時刻、申告者、承認者を別々に記録します。
未実施の回を翌回の結果で埋めてよいかも項目ごとに決めます。油量など、その時点の観察を後で再現できない項目は、翌日の測定値で昨日の実施を証明できません。追完可能な確認作業でも「期限内に安全が保証されていた」とは言えません。結果画面に「いつ実施したか」「予定から何分遅れたか」「空白期間の運転をどう評価したか」を並べます。
担当者の確認と段階的エスカレーションを設計する
一次担当はシフトに実際にいる人または職務ロールで割り当てます。休暇・応援・交替時の代理担当を持たせ、通知先が空になる予定を生成時に検出します。アラートには設備、点検項目、予定回、期限、超過時間、リスク、今できる行動を示します。単に「点検未実施」と送るだけでは、担当者がどの端末と設備へ向かうべきか判断できません。通知先をアプリ、現場端末、メール等から選ぶ場合は、作業環境で実際に届く経路を試します。
仮定例の三段階では、期限直後に担当者へ通知し、確認期限を過ぎたら班長、なお未解決なら設備保全または品質の責任者へ上げます。10分、30分、60分といった間隔は例示であり、点検ごとのリスクと対応可能時間から決めるべきです。同一予定IDの通知を何通も別件として作らず、一つの事案に履歴を積みます。次シフトへ変わる前に未確認の事案を引き継ぎ、旧担当だけに残さない設計が必要です。
担当者の「確認」は、見たことと次の行動を記録する操作です。実施できない理由があれば、設備停止、部品不足、アクセス不可、作業者不在などを選び、誰がいつまでに何をするかを残します。確認後に放置されないよう、解決期限を別に監視します。エスカレーションは単純な通知回数ではなく、リスク、経過時間、未確認、異常兆候、設備の運転状態で決めます。緊急度の高い設備では、責任者への電話や現場停止判断の経路を別途定めることもあります。
アラートを無条件に設備停止へ直結させる設計は避けます。停止・ロックアウトが必要かは、設備の危険、法規、品質影響、既存の安全手順を踏まえてサイトの責任者が判断します。必要な場合は、承認されたリスク区分に対してのみ、制御システムとの連携と復帰条件を別の安全設計として検証します。単なる入力漏れで生産設備を突然停止させると、別のリスクや現場の迂回行動を生みます。逆に重大な点検の欠落をメールだけで済ませても不十分です。
通知疲れを避けるための設計
同じ設備に十項目の点検があり、全項目が同時刻に期限を迎える場合、十通の通知を十人へ配る方式は確認作業を増やします。担当が同じなら一つの一覧にまとめ、項目ごとのリスクと期限を残す方法があります。ただし一括確認を一括実施と誤解させてはいけません。通知のまとめ方と結果の照合単位は別です。高リスク項目は一覧に埋もれないよう、個別の強い通知や班長への直接通知を維持します。
「既読」が増えても現場が動かなければ効果はありません。週次のレビューでは、通知件数、到達率、確認時間、追完時間、同じ設備の再発、代理者への移管数を組み合わせます。設備が停止していたために通知が不要だったのか、停止情報の連携が遅れたのかも分けます。通知のしきい値を調整するときは、画面上の件数だけでなく、未実施の空白期間とリスクが実際に縮んだかを確かめます。
証跡には「やった記録」と「見逃さなかった記録」が要る
点検実施の証跡は、予定ID、設備ID、項目版、実施者、実施時刻、測定値、判定、必要な写真・署名、端末情報で構成します。未実施対応の証跡は、期限時刻、判定時刻、通知経路と送達結果、確認者と時刻、理由、暫定処置、追完または未実施確定、承認者で構成します。異常値が出た場合は、単に点検実施済みとして終わらせず、修理依頼や品質処置の事案IDへつなぎます。点検未実施と点検結果NGは別の例外です。
二重送信は予定IDと結果IDで冪等化します。結果を訂正する場合は元の値を消さず、訂正前後、理由、操作者、承認者を残します。端末がオフラインの場合、端末での実施時刻とサーバー登録時刻を保存し、時計のずれを検知します。共有端末の共通アカウントでは誰が点検したかを証明できないため、個人または承認された代理入力の仕組みが必要です。証跡の保存期間とアクセス権は顧客要求、契約、社内方針に従って定めます。
写真だけで点検実施を証明する設計にも注意が必要です。写真は設備と時刻の文脈が欠けたり、過去写真を再利用できたりします。設備タグの読み取り、予定IDへの紐付け、実測値、本人確認を組み合わせ、現場負担に見合う証明水準を決めます。すべての点検で重い証明を要求すると、作業時間が延びて形式的入力が増えます。高リスク項目へ重点を置く設計が実務的です。
監査用の集計では、実施率だけを示さず、期限内実施率、追完率、未実施確定件数、免除件数、通知から確認までの時間、理由別内訳を出します。分母は発生した予定回であり、停止中として予定を生成しなかった回をどう表示するかも説明します。マスターの変更で分母が減ったのに実施率だけ改善したように見せないことが重要です。
保全システム・MES・ERPの境界を分ける
設備台帳、保全計画、点検周期、作業指示は保全システムやEAM/CMMSが正本になることが多く、ラインの運転状態や作業者・シフトはMESが持つことがあります。ERPは設備投資、購買、予算、製造指図などと連携します。ただし製品名だけで責任範囲を決めず、現行データの正本と更新権限を表にしてください。点検予定の生成元、実施結果の保存先、未実施事案の管理先を明確にしないと、同じ予定が二つ作られ、片方だけ未実施になることがあります。
例えばMESから設備停止を受けて保全システムの予定を免除するなら、停止の開始・終了、対象設備、理由、承認者、遅延時の扱いをインターフェース仕様にします。設備再稼働時には、保留した点検を再開するのか、新たな再稼働前点検を起こすのかを定義します。ERPの生産計画変更で点検の期限を動かす場合も、現場に既に通知された旧期限の履歴を消さないでください。
インターフェースのAPI名だけでは不足です。予定ID、設備ID、時刻とタイムゾーン、イベント順序、再送、二重受信、エラーキュー、照合頻度、権限、マスター版、システム停止時の代替手順まで書きます。日次で予定回と結果回、未解決事案を突き合わせれば、連携障害による見かけの未実施と実際の未実施を分けられます。ISO 55001:2024は資産マネジメントシステムの要求事項を示しますが、特定のリマインダー時刻や通知方法を定めるものとして引用してはいけません。
基準値を測ってからしきい値と投資効果を決める
まず一つのラインで、点検予定回数、期限内実施、追完、未実施、免除、結果の後入力、確認に要した時間を測ります。紙運用で時刻が残らないなら、導入前に短期間の観察を行います。アラート導入直後は、以前見えなかった未実施が顕在化して件数が増える可能性があります。件数増だけで悪化とせず、データ捕捉率も併せて見ます。
仮定例として、週に予定が200回、期限内が184回、期限後追完が10回、未実施が6回だったとします。期限内実施率は184÷200で92%です。この200・184・10・6・92%は架空の計算例であり、業界平均ではありません。導入目標は「未実施をゼロ」に飛びつく前に、高リスク点検の未実施を翌シフトまで放置しない、通知到達を記録できる、例外理由を特定できるなど、運用で制御できる指標を含めます。
投資効果を見積もる際は、点検漏れの検出時間短縮、監督者の追跡工数削減、記録検索時間短縮、停止や品質逸脱を早期に避けられた事案を分けます。重大事故の削減率を根拠なく仮定して金額化しないでください。システムが直接変えるのは情報の到達と対応の速度です。点検自体の品質は教育、適切な測定器、現場の時間確保にも左右されます。
点検の優先順位は予定数の多さではなく、未実施時の影響から決めます。高リスク設備の点検を先行させる場合でも、現場で点検を実施できる人、必要な工具、設備に安全にアクセスできる時間があるかを確認します。予定をシステムへ登録するだけで、その時間が確保されるわけではありません。夜勤の人員が少なく、点検と段取りが重なるなら、期限を守れる工程計画に変える必要があります。
また、システムが示す「未実施」の一部は入力漏れです。入力漏れを減らすために予定画面と設備タグを改善し、同時に実施を後から装う操作を防ぐ必要があります。実施時刻と登録時刻を分けること、後入力に理由を求めること、期限後の結果を自動で期限内に戻さないことは、その両方を支えます。データ品質の課題と実際の点検漏れを別々に改善すると、現場がアラートを信頼しやすくなります。
現場で起こる三つの誤判定を先に潰す
第一は「予定が作られないため未実施がゼロに見える」誤判定です。新しい設備を台帳へ登録したが点検計画へ関連付けられていない、またはカレンダーが古い場合に起こります。対象設備数と予定数の照合を独立した管理画面で行い、点検義務のある設備に次回予定が無いときはマスター不備として担当者へ割り当てます。予定が無いことを安全の証拠にしません。
第二は「現場では実施したのに未実施と通知される」誤判定です。オフライン端末、バーコードの読み間違い、結果の承認待ち、別システムへの先行入力が原因になりえます。発生時刻、受信時刻、予定ID、設備IDを照合し、事案を訂正した理由も残します。同じ誤判定が繰り返されるなら、しきい値を緩める前に入力導線や連携品質を直すべきです。
第三は「実施していないのに完了に見える」誤判定です。過去写真の再利用、共通アカウント、前日の結果の流用、項目の一括完了などが原因です。高リスク項目では本人確認、設備タグ、実測値の整合を求め、監督者が抜き取りで確認します。ただしすべての点検で同じ強い認証を要求すると作業が形骸化します。項目リスクに応じて証拠水準を段階化し、点検者がなぜ記録するか理解できるよう教育します。
現場の判断を止めない障害時運用
ネットワーク停止時に通知システムが使えなくても、点検を止めるとは限りません。紙の代替様式、掲示場所、記入時刻、責任者への口頭連絡、復旧後の転記担当をあらかじめ決めます。点検が品質や安全に直結する場合は、システム障害中の設備運転可否を現場の承認済み手順で判断します。復旧後は代替記録を元の予定IDへ紐付け、紙に書いた時刻と転記時刻を分けます。データが戻った後に事案が大量発生しても、実施済みか未実施かを一括で決めつけず、証跡に基づき一件ずつ閉じます。
端末とネットワークの復旧だけで運用復旧は完了しません。未送信結果の再送、二重登録の除去、期限超過事案の再計算、通知先の確認、未解決件数の照合まで必要です。これらを誰がいつ実施し、どの差異を班長へ報告するかを手順書へ記します。現場には「障害中でも有効な点検記録を残せる」という信頼が必要で、管理者には「障害の間に何が見えなくなったか」を説明できる記録が必要です。
RFPには判定できる要求と責任境界を書く
RFPの要求表には、対象設備と点検、予定生成、期限計算、休日・シフト、停止例外、担当・代理、通知、確認、追完、未実施確定、異常値の処置、証跡、権限、連携、障害時運用を並べます。「未実施を自動通知」とだけ書くと、いつ未実施と判定するか、誰に届けば成功か、夜勤の期限をどう扱うかが見積から抜けます。「予定IDごとの期限後、許容時間内に結果がなければ事案を一件生成し、担当者への送達結果を記録する」のように書き、許容時間は現場で決めます。
ベンダーには、①予定の再生成で過去記録を保てるか、②夜勤と休日を正しく扱えるか、③設備停止中の免除に承認を付けられるか、④オフライン結果の遅延到着で誤警報をどう訂正するか、⑤代理担当と班長への段階的通知を設定できるか、⑥追完と未実施確定を別集計できるか、⑦点検NGを修理依頼へ結べるか、⑧監査ログを出力できるかを尋ねます。デモでは画面の色より、架空の予定と結果を入れて答えを出してもらいます。
見積比較には、端末、ネットワーク、設備台帳と点検マスターの整備、既存システム連携、通知経路、データ移行、権限設定、受入試験、教育、保守を含めます。最安のフォーム作成費だけを比較すると、予定生成や通知の費用が後から現れます。一方、すべてを初期から全設備へ展開する必要もありません。高リスク設備群で一巡させ、予定と証跡の品質を確認してから広げる方が、ルールの誤りを小さく直せます。
権限変更とマスター改訂を運用試験に含める
点検者、代理者、班長、保全責任者、システム管理者ができる操作を分けます。点検者が自分の未実施を免除できると、警報は形だけになります。小規模拠点で兼務が避けられない場合も、理由と承認履歴を残します。人事異動やシフト変更で通知先が空にならないよう、毎日予定生成時に担当割当を検査します。退職者のアカウントで結果が入力されないことも確認します。
点検項目が改訂された場合、どの予定回から新版を適用するかを決めます。既に完了した回の設問や基準値を新しいものへ書き換えると、当時何を点検したかを再現できません。過去の結果は旧版と結び、将来予定だけ新版へ移すか、承認された移行規則を適用します。設備の名称変更、ライン移設、分割、廃止も、未解決の事案を失わずに引き継げるか試験します。
FAT/SATは正常系だけでなく未実施の境界を試す
FATでは、予定生成→期限内実施→結果照合の正常系に続き、期限超過→通知→確認→追完または未実施確定を試します。夜勤の日跨ぎ、休日、設備停止、臨時稼働、期限直前の通信断、二重送信、端末時計のずれ、代理担当への移管、点検NG、マスター改訂、通知不達を含めます。各ケースの期待結果に、予定ID、期限、事案発生時刻、送達先、確認時刻、結果区分、監査履歴を記入します。「赤くなった」だけでは合格にしません。
SATでは実設備タグ、実端末、実ネットワーク、実シフトを使います。点検者が予定を見つけられるか、点検しなかった回が適切な時刻に見つかるか、代理担当へ届くか、追完を期限内実施と誤表示しないかを現場で確かめます。回線断の間は紙に記録し、復旧後に誰がいつ転記するかも試します。安全上の停止・ロックアウトを導入する場合は、システム受入だけでなく、現場の安全責任者による別の承認と復帰試験を設けます。
初期導入は、例えば同一ラインの数台と同じ点検周期に限定します。仮定の数台という範囲は目安ではなく、設備のリスクと運用担当の能力に合わせて決めます。運用後は週次で期限超過、追完、未実施確定、免除、通知不達、未確認、理由未確定を見直します。過剰な通知で無視が増えていれば、リスク区分や期限を見直します。ただし通知数を減らすためだけに重要点検の予定を削除しないでください。
小規模導入から横展開する判断条件
最初の対象では、予定の生成漏れ、結果の突合失敗、通知不達、担当者未設定を別々に数えます。一定期間、未解決の高リスク事案が放置されず、点検者が現場の手順を使えることを確認してから次の設備群へ進みます。期間や許容件数は設備リスクを踏まえた社内の受入基準で定めます。担当者が画面を開いているだけで、紙の点検表が別に残り続けるなら二重運用の負担も測る必要があります。
横展開前には、対象設備の台帳整備率、点検項目の版、シフトと休日カレンダー、代理担当、端末接続、教育日を一覧で確認します。設備ごとに同じルールをコピーしても、実際の始業時刻や危険度が違えば誤警報になります。既存の紙記録をすべて過去の予定回に変換する必要はありません。移行時点以前の履歴は「参考資料」、移行後の予定は「システムで判定する記録」と境界を明示し、初日から過去の欠落警報が大量発生しないようにします。
導入の責任者は、現場、保全、品質、ITのどこが何を承認するかを決めておきます。点検項目の妥当性は設備を知る部門、通知ルートは現場管理者、データの連携と権限はIT、運用停止時の可否は安全・品質責任者が関与するのが自然です。名称だけの承認欄ではなく、変更要求から設定、試験、現場周知までの流れを一本にすると、横展開後も点検ルールを保守できます。
よくある質問
設備点検の未実施通知と点検表電子化は何が違いますか？
点検表電子化は観察結果を入力・保存する仕組みです。未実施通知は、発生した予定回と有効な結果を照合し、期限超過を担当へ届け、対応を閉じる仕組みです。点検表だけでは、誰も開かなかった予定を検知できません。
点検期限を過ぎたらすぐアラートを出すべきですか？
設備・点検項目のリスク、シフト、通信遅延、実際の対応可能時間で決めます。期限と猶予を別項目にし、どちらも版管理します。この記事の時間例はすべて仮定です。高リスク点検では長い猶予を機械的に適用しないでください。
日常点検を翌日に追完すれば未実施は消えますか？
消しません。結果は追完として保存できますが、元の期限に間に合わなかった事実と空白期間は履歴に残します。後から観察できない項目は未実施で確定する可能性があり、品質・安全責任者が扱いを決めます。
点検未実施で設備を自動停止すべきですか？
一律には決められません。設備リスク、法規、既存安全手順を評価し、サイトの責任者が必要と判断した範囲だけ、制御連携と復帰条件を別途設計・試験します。通常の通知システム導入と安全機能の設計を混同しないことが重要です。
点検実施の証跡は写真だけで足りますか？
写真だけでは設備、予定回、実施者、時刻、実測値を十分に証明できないことがあります。予定IDと設備タグ、本人、記録時刻、測定値、必要な添付と訂正履歴を、点検リスクに応じて組み合わせます。
まとめ
点検未実施アラートを使える仕組みにするには、点検表の画面より先に、予定回を作り、シフトと暦日をまたぐ期限を確定し、結果が無いときの担当・確認・追完・未実施確定を決めます。証跡には「点検した記録」と「漏れに気づき処置した記録」の両方が必要です。保全システム、MES、ERPの正本を整理し、RFPとFAT/SATで夜勤、通信断、マスター変更まで試せば、点検漏れを現場の行動へ変えられます。
タイ工場で設備の日常点検が紙や複数システムに分かれ、期限超過時に誰へどう知らせるかを検討中なら、対象設備や現行点検表が整理途中でもTOMAS TECHへご相談ください。最初の設備群で、予定、通知、証跡、受入条件を一緒に具体化できます。
参照した一次資料
- Microsoft Learn, Creating work orders — 保全計画と保全作業指示の生成。
- Microsoft Learn, Manage work orders using the Asset Management mobile app — 担当者の作業指示・点検チェックリスト・予定時刻。
- Microsoft Learn, Use inspections in work orders — 作業指示内の点検フォーム。
- Microsoft Learn, Maintenance plans — 時間・カウンターに基づく保全計画の設定。
- ISO, ISO 55001:2024 Asset management — Asset management system — Requirements — 資産マネジメントシステムの要求事項。
*一次資料は標準と各製品の説明に限って使用しました。本稿の期限式、通知間隔、追完区分、RFPおよび試験ケースは実務設計案であり、特定製品の標準機能またはISOの個別通知要件を示すものではありません。*
