ISO 42001導入を90日で進める実務ガイド

ISO 42001導入を検討するタイ・ASEANの製造業では、「認証を取るか」より先に、どのAIを誰が何の目的で使い、どのリスクを誰が管理するかを説明できる状態が必要です。本稿では、経営、IT、品質、監査、現場が90日でAI台帳、責任分担、AI影響評価、供給者証跡を整える実務を解説します。認証を前提にせず、すでに稼働中の生成AI、外観検査、需要予測、保全AIも含めて始められる方法です。

ISO/IEC 42001とは何か：認証の前に理解したいAIMS

ISO/IEC 42001:2023は、組織がAIを責任ある形で開発、提供、利用するためのAIマネジメントシステム（AIMS）の要求事項を定めた国際規格です。対象はAI開発企業だけではありません。既製のAIサービスを購入して工場やバックオフィスで利用する企業も対象になり得ます。ISOの公式説明は、リーダーシップ、方針と目的、AIリスク管理、データガバナンスとライフサイクル、透明性、評価・監視、継続的改善を主要な要素として挙げています。

ここで重要なのは、ISO/IEC 42001が特定のAIモデルの性能基準や、単一のチェックリストではないことです。組織が自社の状況、利害関係者、AIの用途、影響の大きさに応じて管理の仕組みをつくり、運用し、見直せるようにする枠組みです。既存のISO 9001やISO/IEC 27001を運用している企業なら、方針、文書管理、内部監査、マネジメントレビュー、是正措置といった管理の考え方を接続しやすいでしょう。ただし、既存認証があるからAI固有のリスク評価を省略できるわけではありません。

ISO/IEC 42001の認証は任意です。ISO自身が企業を認証するのではなく、認証を選ぶ場合は独立した認証機関が審査します。したがって、「ISOが認証したAI」「ISO 42001が法律上必須」といった表現は避ける必要があります。経営判断としては、まず顧客要求、入札条件、グループ方針、規制対応、事業リスクを整理し、第三者認証が必要か、自己適合の確認で足りるかを決めます。

タイでは、TISIの公式情報によると、タイ国家規格 มตช. 42001-2567 が2024年7月17日に官報掲載されています。タイ拠点で運用するときは、国際規格だけでなく、現地の規格表記、顧客要求、契約、個人データ保護、安全衛生、労務など周辺要件との関係も確認します。規格を取得すれば周辺法令への適合が自動的に保証されるわけではありません。

なぜタイ・ASEAN製造業でAIマネジメントシステムが必要か

製造業のAIは、単独のITツールとして閉じません。外観検査AIの判定は出荷品質に影響し、需要予測は購買と在庫を動かし、予知保全は設備停止の判断につながります。生成AIが作った作業標準書や翻訳が現場で使われれば、安全、品質、情報管理に影響します。さらに、AIモデル、クラウド、カメラ、センサー、MES、ERP、保守ベンダーが複数社にまたがり、誰がどの判断に責任を持つのか曖昧になりがちです。

特にタイ・ASEANの多拠点企業では、次の断絶が起きやすくなります。

日本本社がAIサービスを契約し、タイ工場が利用条件を十分に把握していない
PoCでは精度を測ったが、本番後の性能劣化や異常時の停止基準が決まっていない
現場が無償の生成AIへ図面、見積、顧客情報を入力している
ベンダーがモデルを更新しても、変更内容や再評価記録が残らない
品質部門はAIの存在を知っていても、入力データや人による最終判断を監査できない
各国で言語、作業慣行、データ保護要件が異なるのに、一つの手順書だけで運用している

ISO 42001導入の価値は、これらを「AI部門だけの問題」から「会社として管理する業務」に変える点にあります。重要なのは文書の量ではなく、AIの採用、変更、監視、停止、廃止に関する意思決定が再現可能であることです。

90日のISO 42001導入ロードマップ

90日という期間は、認証取得を保証する日数ではありません。組織規模、対象範囲、既存の管理システム、AI利用数、審査機関の日程によって認証準備期間は変わります。本稿の90日は、経営が範囲を決め、監査可能な最低限の運用基盤を立ち上げるための目安です。

1〜15日目：適用範囲と経営責任を決める

最初に「全社AI」を対象にすると、議論が広がりすぎて進まないことがあります。まずは、タイの一工場における品質検査AI、またはタイ法人が業務利用する生成AIサービスなど、事業上説明できる境界を設定します。対象組織、拠点、業務、AIシステム、データ、外部サービス、除外範囲を一枚にまとめます。除外する場合は、なぜ影響がないと判断したかを記録します。

次に、経営責任者、AIMS責任者、システムオーナー、業務オーナー、データオーナー、リスク評価者、内部監査者を定めます。兼務は可能でも、自己承認ばかりになる設計は避けます。例えば、外観検査AIの業務オーナーが生産技術部門であれば、出荷判定の受容基準は品質部門が確認し、セキュリティと個人データはそれぞれの専門部門が評価する形が考えられます。

経営が承認すべき最低限の項目は、AIMSの目的、対象範囲、リスク受容の考え方、重大事象の報告経路、必要な人員と予算です。「AIを積極活用する」という抽象方針だけでは、現場が許容される行動を判断できません。人の安全に関わる自動判断は必ず人が確認する、顧客秘密を公開型AIへ入力しない、重大変更は再評価する、といった実務上の原則を明記します。

16〜30日目：AI台帳を作り、未申請AIを見つける

AI台帳はISO 42001導入の中核です。台帳は単なる製品リストではなく、責任、データ、目的、影響、供給者、変更履歴、監視を結ぶ索引として設計します。最低限、次の項目を持たせます。

項目	記録内容の例
AI ID／名称	工場・用途・連番で一意に識別
目的と業務工程	外観欠陥候補の検出、保全優先順位の提案など
利用形態	自社開発、組込み製品、SaaS、汎用生成AI
オーナー	業務、システム、データ、承認者
対象者・影響	作業員、顧客、サプライヤー、製品品質、安全
入出力データ	画像、設備信号、個人情報、図面、プロンプト、ログ
人の関与	推奨のみ、二重確認、自動実行、停止権限
供給者	契約先、再委託、モデル提供者、保管地域
リスク区分	影響度、発生可能性、検出可能性、残留リスク
監視指標	誤検出、見逃し、ドリフト、例外、苦情、停止回数
状態	検討、PoC、本番、停止、廃止

台帳作成はIT資産台帳だけから始めない方がよいでしょう。購買のSaaS契約、経費精算、ブラウザ拡張、工場PC、保全部門のエッジ端末、品質部門のカメラ、個人が作ったマクロや生成AIアカウントも照合します。アンケートでは「AIを使っていますか」ではなく、「自動で分類・予測・文章生成・画像判定・推奨をするツールはあるか」と具体的に聞くと漏れを減らせます。

未申請のAIが見つかったとき、直ちに全面禁止すると地下利用を招く場合があります。入力禁止情報、暫定承認者、利用期限、ログ保存、代替手段を定めた暫定管理に置き、リスクの高いものから正式評価します。安全、雇用、顧客権利、機密、出荷品質へ重大な影響を持つ用途は優先して停止または制限を判断します。

31〜45日目：AI影響評価とAIリスク管理を実施する

AIリスク管理では、一般的な情報セキュリティだけでなく、誤った出力、偏り、説明可能性、人の過信、目的外利用、性能劣化、データ品質、供給者変更、停止不能などを扱います。リスク評価表は点数を付けること自体が目的ではありません。どの被害が誰に起き得るか、既存管理で十分か、誰が残留リスクを受容するかを明らかにします。

ISO/IEC 42005:2025は、AIシステムの影響評価に関するガイダンスを提供します。影響評価では、組織の損失だけでなく、個人、集団、社会への結果も検討します。例えば、作業員の映像を用いた行動分析なら、生産性だけでなく、監視の妥当性、説明、アクセス権、誤判定による不利益、保存期間も検討対象です。外観検査なら、見逃しによる顧客影響、過検出による廃棄、照明や材料変更による性能差、人がAIを無条件に信頼するリスクを評価します。

実務では、次の順序で一つのAIにつき60〜90分のワークショップを行うと進めやすくなります。

AIが支援または自動化する意思決定を一文で定義する
影響を受ける人、製品、工程、権利、契約を列挙する
正常時、誤作動時、悪用時、停止時のシナリオを考える
データ、モデル、UI、人、設備、供給者の原因を分ける
予防、検知、対応、復旧の管理策を対応付ける
残留リスク、承認者、期限、監視指標を記録する

点数方式を使う場合も、数字だけで承認を自動化しません。例えば「影響度×発生可能性」のマトリクスは優先順位づけに使えますが、低頻度でも人命や重大な法的影響を伴うリスクは個別に経営へ上げます。各言語の現場で説明できる短いシナリオを残す方が、複雑なスコアより運用に役立ちます。

46〜60日目：供給者証跡とデータガバナンスを整える

AIサービスを外部から購入しても、利用組織の説明責任が消えるわけではありません。供給者から入手すべき証跡を、契約前、導入時、変更時、障害時に分けて管理します。最低限、サービス仕様、利用目的の制限、データの利用・保持・削除、保存場所、アクセス管理、下請け、モデル変更通知、性能情報、障害通知、ログ取得、解約時のデータ処理を確認します。

供給者が「AI倫理に配慮」と説明しても、それだけでは管理証跡になりません。自社の利用シナリオに対し、どの入力を許可し、誰が出力を確認し、どのログを取れるかを契約と運用の両方で確かめます。ブラックボックスのSaaSで内部構造を得られない場合でも、受入試験、出力制限、人による確認、定期評価、代替手段、停止条件でリスクを下げられます。資料が得られない事実自体を供給者リスクとして記録します。

データについては、学習用、評価用、本番入力、生成出力、監視ログを分けます。出所、権利、品質、代表性、変更、保持、削除、アクセス権を記録し、目的外利用を防ぎます。タイ語、英語、日本語、ベトナム語が混在する工場では、一言語だけで評価したモデルを全拠点へ展開すると性能差が生じる可能性があります。言語別、工場別、製品別、設備条件別の評価結果を残すことが重要です。

生成AIの運用環境を整える具体策は、生成AIを安全に使う社内環境の設計も参考になります。AIエージェントに業務を実行させる場合は、AIエージェントの業務フローとガバナンスのように、権限、承認、ログ、例外処理を業務フローの中で設計します。

61〜75日目：運用手順、監視、インシデント対応を動かす

文書を完成させるだけではAIMSは機能しません。AIの申請、リスク評価、承認、リリース、変更、監視、インシデント、停止、廃止までを一つのライフサイクルとして運用します。PoCから本番へ移る条件と、本番から停止へ戻す条件を明確にします。

監視指標は、AIの技術性能だけでなく、業務結果と管理の有効性を含めます。外観検査なら、精度という一語ではなく、欠陥種別ごとの見逃し率、過検出率、手動差戻し、照明条件、材料ロット、モデル版を関連付けます。生成AIなら、禁止情報入力、出力の修正率、根拠確認の実施率、誤情報報告、権限外実行、利用者教育の完了率などを検討できます。

インシデント手順では、誰がAIを停止できるか、停止後に何へ切り替えるか、どのログを保全するか、誰に報告するか、供給者へ何を確認するかを決めます。現場が停止を恐れて異常を隠さないよう、暫定的な手作業への切替手順と生産計画への影響も経営が承認しておきます。

変更管理では、モデル更新だけを対象にしません。プロンプト、しきい値、カメラ、照明、材料、UI、対象者、利用目的、データ接続、供給者の利用規約が変われば、再評価が必要か判断します。変更の重大度に応じて、文書確認のみ、小規模な再試験、全面的な影響評価の三段階に分けると運用しやすくなります。

76〜90日目：内部監査とマネジメントレビューで閉じる

最後の15日では、台帳に登録した代表的なAIをサンプルに、記録と実態が一致するかを内部監査します。申請書があるかだけでなく、現場が承認条件を理解しているか、ログが実際に取れているか、供給者変更が反映されたか、期限超過の是正がないかを確認します。監査者は自分が設計・運用した活動だけを監査しないよう独立性を考慮します。

マネジメントレビューでは、AI台帳件数、高リスク用途、重大事象、監視結果、苦情、供給者問題、是正措置、資源不足、法規・顧客要求の変化を経営に提示します。経営は、継続、制限、追加投資、停止、対象範囲拡大、第三者認証準備のいずれを進めるか決定します。議事録には決定、責任者、期限を残します。

90日目の成果は「認証準備完了」という宣言ではなく、少なくとも一回、計画、実行、評価、改善が回った証拠です。第三者認証を目指す場合は、選定した認証機関に審査範囲、必要な運用期間、審査日程、力量を直接確認します。ISO/IEC 42006:2025はAIMSの監査・認証を行う機関への要求事項を定めた規格であり、認証機関選定時の確認材料になります。なお、ISOの現行カタログでISO/IEC 42003に関連する導入ガイダンスは開発中のため、発行済みの実装ガイドとして扱いません。

部門別の責任分担：RACIを「責任の押し付け」にしない

AIガバナンスでは、IT部門だけを責任者にすると、業務影響の判断が抜けます。一方、現場部門だけに任せると、データ、セキュリティ、供給者管理が不十分になります。役割は次のように分け、AIごとに名前を入れます。

経営責任者：方針、対象範囲、リスク受容、資源、重大事象を決定
AIMS責任者：管理システム全体、台帳、会議、監査、改善を統括
業務オーナー：利用目的、業務手順、人の判断、成果指標に責任
システムオーナー：構成、権限、ログ、変更、停止・復旧を管理
データオーナー：データ利用の正当性、品質、保持、アクセスを管理
品質・安全部門：製品、人、設備への影響と受容基準を確認
法務・コンプライアンス：契約、個人情報、労務、表示、規制を確認
購買：供給者評価、契約証跡、変更通知、再委託先を管理
利用者：承認条件に従い、異常と誤出力を報告
内部監査：仕組みと実態の適合性・有効性を独立して確認

RACI表の「Accountable」を一人に決めても、その人が全作業を行うわけではありません。重要なのは、出荷停止、AI停止、例外承認、残留リスク受容といった重要決定の最終責任者が曖昧にならないことです。タイ法人と日本本社で責任が分かれる場合は、現地で即時判断できる権限と、本社へエスカレーションする条件を明記します。

AIガバナンス文書を増やしすぎない方法

ISO 42001導入でよくある失敗は、規程のひな形を大量に作り、実際の業務と接続しないことです。最初は次の「最小文書セット」を既存管理システムへ組み込みます。

AIMSの対象範囲、方針、目的
AI台帳とAIシステムカード
AI影響評価・リスク評価記録
AI申請、承認、変更、停止、廃止の手順
データと供給者の確認記録
監視・インシデント・苦情の記録
教育・力量の記録
内部監査、是正措置、マネジメントレビューの記録

既存のISO 9001、ISO/IEC 27001、プライバシー、製品安全、購買の手順が使える場合は重複文書を作りません。例えば、供給者評価票へAI固有項目を追加し、変更管理票へモデル・データ・プロンプトの変更を追加します。文書番号を増やすより、現場が一つの申請から必要な審査へ進めるワークフローを作る方が効果的です。

NIST AI RMF、ISO/IEC 42005、EU AI Actとの関係

NIST AI RMF 1.0との併用

NIST AI Risk Management Framework 1.0は、AIリスクをGovern、Map、Measure、Manageの機能で扱う任意の枠組みです。NISTは現在AI RMF 1.0の改訂を進めており、2026年4月7日には重要インフラ向けプロファイルのconcept noteも公表しています。したがって、NISTの資料を社内手順へ固定的に転記するのではなく、改訂状況を確認しながら、リスクシナリオの洗い出しや測定方法の補助として使うのが現実的です。

ISO/IEC 42001とNIST AI RMFは同一ではありません。前者はマネジメントシステムの要求事項、後者はリスク管理のための枠組みです。AIMSの運用骨格にISO/IEC 42001を用い、リスクの特定・測定を深めるためNISTの資源を参照する、という併用ができます。

ISO/IEC 42005のAI影響評価

ISO/IEC 42005:2025は、AIシステムの影響評価を行うためのガイダンスです。AI導入前の一回だけでなく、用途、対象者、データ、環境、供給者が変わったときに影響評価を見直す設計にします。評価の出力を台帳、リスク対応計画、受入試験、利用者への説明、監視指標へ接続すると、評価が書類で終わりません。

EU AI Act Article 17との違い

EU AI ActのArticle 17は、高リスクAIシステムの提供者に品質管理システムを求め、規制適合、設計、開発、試験、データ管理、記録、責任、監視、是正などを文書化することを要求しています。ただし、ISO/IEC 42001認証を取得すればEU AI Actへ自動的に適合する、という関係ではありません。自社が提供者、導入者、輸入者、流通業者などどの立場に該当し得るか、対象AIが高リスクに分類されるか、EU市場との接点があるかを個別に法務確認します。

タイの製造拠点で使うAIでも、EU向け製品、EU所在者へのサービス、グループ会社へのAI提供などに関係する場合は検討対象になり得ますが、域外適用を一般化して断定してはいけません。契約と実際の提供関係を基に専門家へ確認します。

ISO 42001認証機関・コンサルティング会社の選び方

認証を目指す場合、ISOと認証機関を混同しないことが出発点です。認証機関には、AIMS審査の力量、対象産業・地域の経験、言語対応、審査範囲、日程、認定の状況を確認します。コンサルティング会社を利用する場合、審査の合格保証ではなく、自社のAI利用を理解し、既存管理システムに実装できるかを見ます。

確認質問の例は次の通りです。

タイの製造現場と多言語運用をどのように調査するか
自社開発AIと外部SaaSをどう区別して台帳化するか
AI影響評価を品質、安全、情報セキュリティへどう接続するか
既存のISO 9001／ISO/IEC 27001文書をどこまで再利用するか
供給者から十分なモデル情報を得られない場合にどう対応するか
内部監査員の力量と独立性をどう確保するか
認証を見送る場合でも残る成果物は何か

支援会社の比較については、タイでAIコンサルティング会社を選ぶポイントも参照してください。秘密保持、データ持出し、再委託、生成AIの利用条件を契約前に確認することが重要です。

費用と工数を見積もる考え方

導入費用は、組織の規模より「対象範囲にあるAIの数と多様性」「既存管理の成熟度」「供給者証跡の入手性」「拠点と言語」「認証の有無」に左右されます。本稿では相場を断定しません。見積を比較するときは、次の作業単位で分けます。

現状調査と適用範囲設定
AI台帳の初期棚卸し
影響評価・リスク評価ワークショップ
方針、手順、様式、ワークフローの整備
技術的管理策やログ基盤の実装
教育、模擬運用、内部監査
認証機関による審査費用と是正対応
翻訳、出張、複数拠点展開、年次運用

仮定試算をする場合は、前提を明示します。例えば、対象AIが12件で、1件あたりの台帳確認と影響評価に平均6人時、共通手順・教育・内部監査に160人時かかると仮定すれば、初期内部工数は 12件×6人時＋160人時＝232人時 です。これは市場価格や標準工数ではなく、体制計画のための仮定です。実際には高リスクAIの検証、データ整理、技術改修、翻訳、認証審査の工数を別途見込みます。同じ前提を各拠点で使い、差分理由を説明できるようにすると予算承認が進みやすくなります。

よくある失敗と是正策

認証日から逆算し、AI台帳を後回しにする

文書ひな形を先に埋めても、実際のAIが把握できなければリスク、責任、監視を設計できません。最初の30日で台帳を作り、対象AIの代表サンプルを選びます。

すべてのAIを同じ厳しさで管理する

会議要約と出荷判定では影響が異なります。影響度、利用者、データ、実行権限に応じて審査、承認、監視頻度を変えます。ただし、低リスク分類の根拠も台帳に残します。

ベンダーの説明を自社評価の代わりにする

第三者資料は有用ですが、自社のデータ、工程、人の関与を反映しません。受入試験と運用条件は利用組織が定義します。

精度だけで安全性と品質を説明する

平均精度が高くても、重大欠陥の見逃しや特定条件での性能低下が隠れることがあります。用途別の誤りコスト、条件別指標、手動確認、停止条件を組み合わせます。

研修を一度実施して完了とする

役割ごとに必要な力量は異なります。一般利用者、業務オーナー、開発者、購買、監査者に分け、理解確認、演習、再教育を記録します。

FAQ：ISO 42001導入でよくある質問

ISO/IEC 42001とは何ですか？

組織がAIを責任ある形で開発、提供、利用するためのAIマネジメントシステムの要求事項を定めた国際規格です。AI固有のリスクと機会を、方針、役割、運用、評価、改善の仕組みで管理します。

ISO 42001認証はタイ企業に必須ですか？

ISO/IEC 42001の認証は任意です。ただし、顧客契約、入札、グループ方針などで求められる可能性はあります。タイでは มตช. 42001-2567 が国家規格として官報掲載されていますが、個別の法令・契約要求は別に確認してください。

ISOは企業を認証しますか？

いいえ。ISOは国際規格を開発する組織であり、企業の認証は行いません。第三者認証を選ぶ場合は、独立した認証機関が審査します。

AI影響評価とAIリスク評価は何が違いますか？

影響評価はAIが個人、集団、組織、社会へもたらし得る結果を広く捉えます。リスク評価は、不確実性や被害シナリオ、発生可能性、管理策、残留リスクを扱います。実務では両者を接続し、影響をリスク対応と監視へ落とし込みます。

既存のISO 9001やISO/IEC 27001を流用できますか？

方針管理、文書管理、供給者管理、内部監査、是正措置などは統合できます。ただし、AI台帳、AI影響評価、人の監督、モデル・データの変化などAI固有の論点は追加が必要です。

生成AIだけを対象にできますか？

初期範囲として生成AIを選ぶことは可能です。ただし、外観検査、予測、最適化など他のAIが事業へ重大な影響を持つ場合、除外理由と今後の拡張計画を説明できるようにします。

90日で認証を取得できますか？

本稿の90日は運用基盤を立ち上げる目安であり、認証取得を保証しません。組織の準備状況、対象範囲、是正事項、認証機関の日程で変わります。認証日程は候補機関へ直接確認してください。

EU AI Actへの適合にも使えますか？

AIMSの記録や品質管理は対応の土台になり得ますが、ISO/IEC 42001認証とEU AI Act適合は同一ではありません。対象AI、事業者の役割、EU市場との関係を個別に評価する必要があります。

まとめ：90日後に残すべきもの

ISO 42001導入の最初の90日で目指すのは、証明書ではなく、経営が把握できるAI台帳、名前の入った責任分担、用途ごとのAI影響評価、供給者証跡、変更・監視・停止の記録です。小さな適用範囲から一度運用を回し、内部監査とマネジメントレビューで改善点を決めれば、認証を選ぶ場合にも、選ばない場合にも、AIガバナンスの実効性が残ります。

TOMAS TECHでは、タイの製造現場、既存の品質・情報セキュリティ管理、AI／MES／IoTの実装状況を踏まえ、適用範囲の整理からAI台帳、影響評価、供給者確認、運用ワークフローまで支援できます。認証の要否を決める前の現状診断や、一つの工場・一つのAIからの試行段階でも、お問い合わせください。

参考文献・一次情報

ISO, “ISO 42001 explained: What it is and why it matters”: https://www.iso.org/home/insights-news/resources/iso-42001-explained-what-it-is.html
ISO, “ISO/IEC 42001:2023 Information technology — Artificial intelligence — Management system”: https://www.iso.org/standard/42001
Thai Industrial Standards Institute, มตช. 42001-2567（官報掲載日 2024-07-17）: https://service.tisi.go.th/license/web/index.php?ifdr=159&r=site/viewnac
ISO, “ISO/IEC 42005:2025 Artificial intelligence — AI system impact assessment”: https://www.iso.org/standard/42005
NIST, “AI Risk Management Framework”: https://www.nist.gov/itl/ai-risk-management-framework
EUR-Lex, Regulation (EU) 2024/1689, Article 17: https://eur-lex.europa.eu/eli/reg/2024/1689/2026-07-27/eng
ISO/IEC JTC 1/SC 42 catalogue（ISO/IEC 42006:2025等）: https://www.iso.org/committee/6794475/x/catalogue/