「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を組み込んだサービスを企業間で売り買いする場面が増えるほど、自己申告では足りない場面が出てくる。そのときに差し出せるものがあるかどうかで、話の進み方が変わる。