「AIを適切に扱っています」を、どうやって外に示すか。自分で点検して自分で言うのか、第三者に確かめてもらうのか。この差は大きなものです。ISO/IEC 42001:2023は、後者を可能にした最初の国際規格になります。AIのマネジメントシステムを対象にした、認証を受けられる規格です。
何を認証するのか
まず誤解しやすい点から。この規格が認証するのは、AIそのものではありません。 モデルの精度でも、出力の安全性でもありません。
認証の対象は、組織がAIを扱う仕組みのほうです。方針を決めているか。リスクを洗い出しているか。責任者は誰か。問題が起きたときに見直す手順はあるか。それが実際に回っているかどうかを見ます。
そのため、認証を取った組織のAIが安全だ、とは言えません。言えるのは、安全に扱うための体制が第三者の目で確認された、までになります。この区別を曖昧にすると、認証の意味を取り違えます。
ISO 27001と同じ骨格
構造に見覚えがある方は多いはずです。ISOのマネジメントシステム規格は共通の骨格を持っていて、42001もその形に従っています。
- 文脈の理解：組織を取り巻く状況と、利害関係者の要求
- リーダーシップ：経営が方針を示し、責任を割り当てる
- 計画：リスクと機会を特定し、目標を置く
- 支援：資源、力量、認識、文書
- 運用：決めたことを実行する
- 評価：監視、内部監査、マネジメントレビュー
- 改善：不適合への対処と、継続的な改善
計画して、実行して、確かめて、直す。この循環そのものを審査します。
骨格が共通なので、既にISO 27001を運用している組織なら文書体系も監査の枠組みもそのまま流用でき、ゼロから作る場合とは必要な労力がかなり違ってきます。
附属書の管理策
本体が「仕組みを回せ」だとすると、具体的に何を置くかは附属書にまとまっています。ISO 27001の附属書Aと同じ位置づけです。
AI固有の論点が並びます。AIシステムの目的の明確化、データの管理、利用者への情報提供、そしてAIライフサイクル全体を通した責任の所在まで、扱う範囲は開発から運用の終わりまで届きます。
すべてを適用する必要はありません。自組織に該当しないものは、理由を書いて除外します。ここもISO 27001と同じ運用になります。除外の理由を書けることが、実質的な検討の証拠になります。
三つの物差しを並べる
ここまで扱ってきた文書と並べると、位置がはっきりします。
| 対象 | 誰が確かめるか | |
|---|---|---|
| OWASP ASVS | アプリケーションの技術要件 | 自分、または依頼した診断会社 |
| AI事業者ガイドライン | 事業者としての態勢（国内） | 自分 |
| ISO/IEC 42001 | AIのマネジメントシステム | 認定を受けた第三者機関 |
軸は「誰が確かめるか」です。技術の細部はASVSが降りていきますが、認証はありません。AI事業者ガイドラインは国内の共通言語ですが、自己宣言です。42001は細部には降りない代わりに、外部の審査が付きます。
どれが優れているという話ではありません。 求められているものが違います。取引先が認証を要求してくるなら42001が要りますし、技術の検証を求められているならASVS、国内の稟議ならガイドラインが通りやすくなります。
人間による監督が、規格に入っています
附属書のなかで、AIらしい項目を一つ挙げるなら人間による監督になります。
自動で判断する仕組みを置いたとき、人がどこで介在するかを決めておきます。すべてを自動にするのか、一定の条件で人の承認を挟むのか、事後に確認するだけなのか。決めたうえで、それが実際に運用されているかを見ます。
ここが形式的になりやすいところです。「人が最終確認します」と書いてあるのに、現場では画面の承認ボタンを押すだけになっている、という状態はよくあります。
規格が求めているのは、確認できる状態で人が介在していることです。何を見て承認したのかが残らなければ、監督があったとは言いにくくなります。判断の材料が人に届いているかまで含めて設計する必要があります。
認証の仕組み
認証を出すのは、認定を受けた審査機関です。組織が自分で名乗るものではありません。
流れは他のISO規格と同じです。仕組みを作って運用し、内部監査を回し、審査機関の審査を受けます。合格すれば認証が出て、その後も定期的な審査で維持します。
一度取れば終わりではありません。 維持審査があり、数年ごとに更新審査があります。運用が止まれば認証も維持できません。
取得済みの組織を確かめたいときは、審査機関や認定機関の公開情報を見ます。相手が「認証を持っている」と言ったとき、範囲と有効期限まで確かめておくと後で食い違いません。
関連する規格
42001は単独ではなく、いくつかの規格と組みで使われます。
ISO/IEC 22989はAIの用語を定めています。議論の前提を揃えるための土台です。
ISO/IEC 23894はAIのリスクマネジメントの指針です。42001が「リスクを扱え」と要求する部分の、具体的な進め方が書いてあります。
認証の対象になるのは42001だけで、他は指針として参照する形になります。
この構成は覚えておくと役に立ちます。用語を揃える規格、リスクの進め方を示す指針、そして仕組みを認証する規格。 三つが別々に用意されているのは、それぞれ使う場面が違うからです。用語で揉めているときに認証規格を開いても、答えは出てきません。
誰が取りにいくのか
向いている組織と、そうでない組織があります。
AIを組み込んだサービスを企業向けに売っているなら、要求される可能性が高くなります。相手の調達部門が第三者の確認を求めてくる場面が増えています。持っていれば、そこで止まりません。
規制の厳しい業種を顧客に持つ場合も同じです。金融や医療の相手は、自社の説明責任のために取引先の認証を確かめます。
一方、社内利用だけで完結しているなら、急がなくてよいことが多くなります。外に示す必要がないものに、審査の費用と工数をかける理由は薄いためです。AI事業者ガイドラインの自己点検で足りる場面のほうが多くなります。
判断の軸は「誰に示すか」です。 示す相手がいないなら、まだ早い段階かもしれません。
取りにいく前に考えること
認証は目的ではありません。 取ること自体が目的化すると、審査を通るための文書づくりになります。運用が伴わなければ、次の更新審査で綻びが出ます。
適用範囲を先に決めてください。 組織全体か、特定のサービスか。範囲を広く取ると準備が重くなり、狭く取ると証明できる範囲も狭くなります。何のために取るのかから逆算します。
費用と期間が要ります。 文書の整備、内部監査、審査。ISO 27001の経験がある組織でも、数か月単位の話になります。取引先の要求に間に合うかは、早めに見積もったほうが安全です。
EU AI Actの代わりにはなりません。 認証を持っていても、規制の適用対象なら義務は別に発生します。整合を取りやすくなる面はありますが、置き換わりはしません。
技術の検証を代替しません。 42001が見るのは仕組みであって、実装ではありません。認証を持つ組織のアプリケーションに脆弱性がないとは言えないので、ASVSのような技術の目録は別に要ります。ここを混ぜると、確かめたつもりの範囲を取り違えます。
まとめ
42001が持ち込んだのは、AIの扱い方を外から確かめられる形にしたことです。
これまで「うちはちゃんとやっています」としか言えなかった領域に、第三者が確認したという層が一枚入りました。中身の議論が変わったわけではなく、誰が保証するかが変わりました。この一枚があると、相手は中身を全部追わなくても話を先へ進められます。
AIを組み込んだサービスを企業間で売り買いする場面が増えるほど、自己申告では足りない場面が出てきます。そのときに差し出せるものがあるかどうかで、話の進み方が変わります。検討するなら、直近で認証を求められた取引があったかどうかを先に確かめてください。要求が来ていないうちは、AI事業者ガイドラインの自己点検を整えておくほうが、費用に対して得られるものが大きくなります。
