世界初のAI規格、ISO/IEC 42001 取得の裏話

関連するソリューション

業務改革

AI

プリンシパルフェロー　黒住 好忠

皆さまこんにちは。プリンシパルフェローの黒住です。

「AIガバナンス、そろそろ本気で考えないと…」。最近、そんな思いがよぎる場面が増えてきたのではないでしょうか。

AIがあらゆる業務に入り込み便利になる一方で、「どう管理すれば安全に、責任を持って使えるのか」が問われる時代になりました。世界でもAIのルール整備が進んでいますが、「では実際に、何をどうすればいいのか」を示す拠りどころが求められています。その一つが、世界で初めてのAIマネジメントシステム（AIMS）の国際規格、「ISO/IEC 42001:2023」です。

とはいえ、いざ「取得しよう」となると、参考にできる情報はまだ驚くほど少ないのが実情です。私たちも、ほとんど手探りの状態からISO42001に挑みました。今回は、その取得までの道のりを、うまくいったことも、つまずいたことも含めて、できるだけ正直に綴った「裏話」としてお届けします。

この記事で、ISO42001とはそもそも何か（全体像と骨格）、私たちが実際に体験したリアルな苦労と乗り越え方、そしてこれから取り組む方がつまずかないための実践のヒントまで、ひと通りつかめるように書きました。

なお、認証は「取れば終わり、取れば安全」というものではありません。本記事も完璧な成功談ではなく、これから挑む方の地図になることを目指しています。ぜひ一緒に見ていきましょう。

第1章　ISO42001（AIMS）とは：全体像と骨格

ISO42001とは何なのか

ISO/IEC 42001は、AIを安全かつ責任を持って扱うための仕組み（マネジメントシステム）を定めた、世界初のAIマネジメントシステム（AIMS）の国際規格です。一言で表すなら、AIを安全に回し続けるための「運用ルールの土台」です。2023年12月に発行され、業種や規模を問わず、AIを開発・提供・利用するすべての組織が対象になります。

ここでのポイントは、「特定のAI技術の良し悪し」を決める規格ではない、という点です。AIを扱う組織が、リスクを見極め、ルールを定め、運用し、改善し続ける。その「回し方」を求めるのがISO42001なのです。

なぜ今、注目されているのか

背景には、世界的なAIルール整備の流れがあります。たとえばEU AI Act（EUが定めた、世界で初めての包括的なAI規制）のような法律が動き出し、「AIを使うなら、きちんと管理・説明できる体制が要る」という認識が広がってきました。ISO42001は、こうした各国の規制やガイドラインとも足並みをそろえやすく、先回りの備えとして位置づけられます。

他のISOとの関係

すでにISO27001など他のISOを取得している組織には、ちょっとした朗報があります。ISO42001は、ISO9001やISO27001と同じ共通構造（Annex SL）を採用しているため、リスクアセスメントや内部監査、マネジメントレビューといった土台の多くを共有できます。違いは守る対象です。27001が「情報セキュリティ」なら、42001は「AI固有のリスク（公平性・透明性・説明責任など）」に踏み込む、という点が異なります。

規格の骨格：「本編」と「附属書」の関係

ISO42001は、大きく「本編」と「附属書（Annex A〜D）」に分かれます。ここの関係を押さえておかないと、以降の話が分かりにくくなりますので、まずは図で整理しましょう。

それぞれの役割を整理すると、次のようになります。

• 本編（第4〜10章）： マネジメントの仕組み、つまりPDCAそのものです。PDCAは「計画→実行→評価→改善」を繰り返す進め方のことで、組織の状況把握からリーダーシップ、計画（リスク・影響評価）、支援、運用、評価、改善へと回していく骨組みです（第1〜3章は適用範囲・引用規格・用語の定義にあたります）。
• 附属書A： 参照できる管理策のリストです。9つの管理目的のもとに計38の管理策が並びます。すべてを義務として行うのではなく、自分たちのリスクに応じて「使う・使わない」を選び、その理由をSoA（適用宣言書）に書き残します。
• 附属書B： 管理策の実装、つまり「やり方」のガイドです。Aの管理策一つひとつについて、実際にどう取り組めばよいかを補足してくれます。Aが「何をやるか」、Bが「どう進めるか」の手引き、という関係です。
• 附属書C： リスクのネタ帳です。AIで問題が起きやすい原因や、目指しやすい目的の例を集めたもので、「自分たちのリスクは何だろう」と洗い出すときのヒント集として使えます。
• 附属書D： 場面別の使い方ガイドです。医療や金融といった分野ごとの取り入れ方や、他の認証と一緒に運用するときの考え方を示してくれます。

ざっくり言えば、本編で「AIをどう管理するか」の仕組みを作り、附属書Aから「具体的に何をやるか」をリスクに応じて選ぶ。これがISO42001の基本構造なのです。

ここでは要求事項を一つずつ解説することはしませんが、まずは「本編＝PDCAの仕組み」「附属書＝リスクに応じて選ぶ管理策」という全体像をつかめれば十分です。この地図を持っておくと、次章からの「取得のリアル談」がぐっと読みやすくなるはずです。

第2章　なぜ取ろうと思ったのか：きっかけと動機

正直にお話しすると、最初から壮大な計画があったわけではありません。きっかけは「AIをこれだけ使う時代に、自分たちはちゃんと管理できているか」という、素朴な問題意識でした。

動機は大きく2つです。1つは社内の体制づくりで、AI活用が広がるほど、ルールと責任の所在を整えたいという思い。もう1つは対外的な信頼で、「きちんとやっています」を、第三者の認証という形で示したいという思いです。

数ある選択肢の中でISO42001を選んだ理由は、次の4つでした。

• 国際標準であること： 世界のどこでも通用する物差しになります。
• 世界初のAIMS規格という知名度： 「AIを管理する規格」として話が通じやすい点です。
• 先行者としての価値： まだ取得例が少ないうちに動くことに意味があると考えました。
• 取得そのものが社内の規律づくりになること： 認証はあくまで手段であり、体制を整えるきっかけになる、という見立てです。

構想を始めたのは、「AIガバナンス」という言葉が、まだ今ほど一般的ではなかった頃でした。

第3章　取得までの道のり：プロセスの全体像

ISO42001は、一部署だけで取れるものではありませんでした。ISOの知見、AIの実務、社内標準づくり。複数の部門が手を組む必要があります。私たちの場合は、推進委員会や定例会議を回しながら、部門をまたいで進めていきました。

取得までは、最短でも1年から1年半ほど。流れはこのような形です。

1. 現状把握・ギャップ分析： 今ある仕組みと規格要求の差を洗い出します。
2. 文書・規程の整備： ポリシーや手順、台帳などを形にしていきます。
3. 運用実績づくり： 決めたことを実際に回し、記録を残します。
4. 審査（Stage1→Stage2）： 第三者の認証機関による審査は2段階です。Stage1で文書や準備状況を確認し、Stage2で実際の運用がきちんと機能しているかを見ます。

このうち意外と時間がかかるのが、3の「運用実績づくり」です。仕組みを作っても、回した証拠が一定期間ないと審査に進めません。「文書を作れば終わり」ではない、というのが最初の実感でした。

第4章　一番大変だったこと：つまずきの記録

ここからが、今回一番お伝えしたかったところです。きれいに整理された成功の手順ではなく、実際に私たちが頭を抱えた場面を、できるだけそのまま書きます。これから取り組む方が、同じ壁の前で「あ、これ記事で読んだやつだ」と思い出せるように……という願いを込めて。

つまずき①　そもそも規格が何を言っているのか分からない

正直に告白すると、着手した当初、私自身はISOにあまり詳しくありませんでした。規格書を開いても、全体がどういう構成で、何を求めていて、何から手をつければいいのか、まったく見当がつかない。最初のうちは「読んでいるのに頭に入ってこない」という状態が続きました。

規格特有の言い回しにも苦戦しました。「〜しなければならない」「〜することが望ましい」という独特の表現で要求がびっしり書かれていて、その一つひとつを「結局、自分たちは何をすればいいのか」に翻訳できるようになるまで、相当な時間がかかったのです。あとから思えば、すでに他のISOを知っている方なら、もっと早く飲み込めたはずです。AIMSは「他のISOと共通する土台」の上に「AIならではの要求」が乗っているイメージなのですが、私はその土台ごと初めてだったので、余計に時間がかかりました。

つまずき②　英語と、海外の認証機関という壁

これは、取得を始めた時期ならではの苦労でした。当時は国内にAIMSを扱える認証機関がまだなく、海外の認証機関とやりとりするしかなかったのです。つまり、提出する成果物も、審査でのコミュニケーションも英語。通常のISO取得と比べて、ここのハードルは明らかに高いものでした。

成果物の多くは工数の都合もあり、「日本語で作ったものを機械翻訳する」かたちで挑みました。大半はそれで通用したのですが、ときどき妙な訳が紛れ込みます。

つまずき③　従来の開発のやり方だけでは、まったく足りない

私たちはもともと、システム開発の中でリスク管理や要件定義、設計、デプロイ、データの取り扱いといった工程は、きちんとやってきた自負がありました。だから当初は「これまでの延長でいけるだろう」と思っていた部分もあります。

しかし、それだけでは規格の要求に届きませんでした。AIならではの管理策や「責任あるAIの利用」という観点で、これまで意識してこなかった要素を、新たに盛り込む必要があったのです。中でも頭を悩ませたのが、附属書A・Bの管理策でした。どれを採用し、どれを採用しないのかを「なんとなく」ではなく、しっかりした理由をつけて選び、採用したものは運用するプロセスまで整える。これがSoA（適用宣言書）づくりです。しかも、つまずき①のとおり、最初は本編と附属書の関係そのものが分かっておらず、「この管理策は本編のどの要求とつながっているのか」を一つずつ紐解く作業から始めることになりました。

つまずき④　要求を「漏れなく」証跡に落とす難しさ

そして、これが一番大変だった部分です。

規格の要求は、「〜しなければならない」「〜することが望ましい」といった本当に短い言葉で、文章のあちこちに散らばっています。日本語にして十数文字、ほんの数語のこともめずらしくありません。それを「だいたい、こういう管理が要るんだろうな」と雰囲気で捉えたまま進めると、審査で痛い目を見ます。

実際、初回の審査では「〜のプロセスが定義されていません」「〜の証跡がありません」という指摘をいくつか受け、「えっ、そんなこと、どこに書いてありました！？」と規格書を慌てて読み返す場面が何度かありました。私たちは初回審査で軽微な不適合（規格要求からの軽微なズレで、是正すれば取得の妨げにはなりにくいもの）をいくつか指摘された立場ですので、これは身をもって言えます。やっかいなのは、「〜しなければならない」とは書いてあっても、「では、どんな台帳で、どんなプロセスで管理するのか」までは規格に一切書かれていないことでした。要求を、具体的な運用のかたちに翻訳する作業そのものが、ひたすら大変でした。

影響評価とリスクアセスメントも、骨が折れました。ここで戸惑いやすいのが、「影響評価」と「リスクアセスメント」は別物だという点です。ざっくり言えば、影響評価（インパクトアセスメント）でライフサイクルの中のインパクトを洗い出し、それらに対してリスクアセスメントでリスクの評価を行っていきます。ところが私たちは影響評価とリスクアセスメントを同じようなものと誤解していた部分があり、結果としてリスクアセスメントが影響評価をサマリーしたような曖昧な成果物になっていて、審査で指摘を受けました。

実際の作業としては、AIシステムのライフサイクルごとの影響評価を行い、それを受けてリスクアセスメントを、「影響とリスクを紐づける」かたちで進めます。とにかく地道で、作業量も多い。私たちの実感では、審査でも特にこの「影響評価・リスクアセスメント」「データ管理」のあたりが厳しく見られる印象でした（認証機関や審査員によって多少の差はあると思います）。

第5章　どう乗り越えたか：効いたこと

第4章で「大変だった」と書いたからには、「では、どう切り抜けたのか」も正直に書きます。特別な裏技はありませんでした。効いたのは、人の力と、地道な工夫です。

効いたこと①　伴走してくれる存在がいた

これは断言できます。社内にISO取得支援を専門とする部門があり、そのサポートを受けられたことが、何より大きかった。正直に言えば、この伴走がなければ、私たちのAIMS取得はまず無理だったでしょう。

ただ、「支援部門に任せておけば安心」という単純な話でもありませんでした。AIMSは2023年に登場したばかりで、品質や情報セキュリティのISOのように、長年のノウハウが積み上がっているわけではありません。支援部門にとっても手探りの部分は多く、「これはどう解釈すべきか」を一緒に何度も議論しながら進めました。結果として、世の中にまだ少ないAIMS取得のノウハウを、支援部門も含めて自分たちの中に蓄えられたことは、苦労の副産物として大きな財産になりました。

効いたこと②　審査員との対話で、理解が一気に進んだ

意外に聞こえるかもしれませんが、審査そのものが大きな学びの場になりました。審査は一発合格ではなく、不適合の指摘もありました。けれども、その指摘について審査員と本気で議論し、是正を進めていく過程で、「規格が本当は何を求めているのか」が、ようやく腑に落ちていったのです。

効いたこと③　逃げずに、原文を読み込む

身も蓋もないのですが、規格書を一字一句きちんと読む。結局、これが一番効きました。第4章のとおり、要求は短い言葉で散らばっています。雰囲気で読み飛ばさず、「ここで求められているのは具体的に何か」を一つずつ拾っていく。ISO42001は細かい部分を他のISO規格に委ねている箇所もあって、「いったい、ISOをいくつ読めばいいんだ」とぼやきたくなることもありました。それでも、要求を正確に読み解いたことは、振り返ってみて間違いなく重要でした。

効いたこと④　「様子見」だった現場を、どう巻き込んだか

体制づくりも、一筋縄ではいきませんでした。取得を決めたあと、まず経営層の承認を取り、トップダウンで動き出しました。ただ、実際に手を動かす適用部署、とりわけ開発のエンジニアからは、「新しいプロセスに沿うのは、正直、面倒だ」という本音も出てきました。ここも、隠さずに書いておきます。

それでも前に進められたのは、「自分たちはAIサービスをお客さまに提供する立場であり、国際標準に沿ってきちんと管理できていることには大きな意味がある」という意義を、繰り返し共有したからだと思います。号令をかけるだけでなく、なぜやるのかを腹落ちさせる。地味ですが、ここを飛ばすと現場は動いてくれません。

効いたこと⑤　要求を「仕組み」に落とし込む

最後は、決めたことを運用として回せるかたちにする作業です。支援部門のメンバーと一緒に、社内規程やプロセス文書を整備し、それと並行して記録用の台帳テンプレートもそろえていきました。具体的には、AI台帳・データ台帳・リスク台帳といった管理台帳の整備、影響評価やリスクアセスメントの様式・テンプレートの作成、そして社内規程・プロセス文書としての明文化です。

このとき、役割分担も工夫しました。本編の要求は、他のISOとも共有する「組織全体」に関わる内容が多いので、支援部門（コンサル側）のウェイトを高めに。一方で、リスクに応じて採否を決める附属書A・B関連は、実際にAI開発を担う適用部署の関与が欠かせないので、現場メンバーのウェイトを高めに。この按配が、運用への落とし込みをずいぶん楽にしてくれました。

第6章　取得を通じて見えた、AIガバナンスという考え方

ここ数年で、お客さまからの相談の重心が変わってきました。「どう活用するか」から「どう安全に管理するか」へ。AIガバナンスは、もはや一部の先進企業だけの話ではありません。

そのうえで、私たちが大事にしている考え方を3つ整理しておきます。

• プロセスと証跡をベースに、継続的に改善すること： AIMSの要求は、まさにこれです。
• 認証はゴールではなくスタートであること： 取って終わりではなく、運用し続けて初めて意味があります。
• 認証は万能ではないこと： 「取れば安全」ではなく、社内の統制と対外的な信頼を同時に育てるための土台だと考えています。

第7章　これから取り組む方へ：実体験からのアドバイス

最後に、これからISO42001に挑もうとしている方へ、私たちが「先に知っておきたかった」と痛感したことを、そのままお伝えします。

①　まずは、全体像から入る

遠回りに見えて、これが一番の近道でした。いきなり個々の要求事項に飛び込むのではなく、本編（PDCAの仕組み）と附属書A・Bの関係という地図を、最初に頭へ入れる。それだけで、あとから出てくる一つひとつの要求が「ああ、あの地図のここの話か」とつながって見えてきます。第1章で図解にこだわったのも、まさにここでつまずいてほしくなかったからです。

②　支援者を、できるだけ早く巻き込む

ISOの知見がある方や、支援部門・コンサルの力は、初期から借りることをおすすめします。私たちの実感では、行き詰まってから呼ぶより、最初から一緒に走ってもらうほうが、結果的にずっと効率的でした。ISO42001の取得ノウハウは、まだ世の中に多く出回っていません。だからこそ、伴走してくれる存在がいるかどうかが効いてきます。

③　原文を読む。そして「証跡に何を書くか」まで確認する

第5章とも重なりますが、要約や解説だけで分かった気にならず、原文（ISO/IEC 42001:2023）にあたることを強くおすすめします。理由は単純で、要求の細かなニュアンスは、かみ砕いた解説の段階でこぼれ落ちてしまうことが多いからです。

そのうえで、原文を読むときに意識していただきたい「もう一歩進んだ注意点」を、私たちの失敗をふまえてお伝えします。ISO42001は、いくつかの事項について「文章や記録として残しておくこと」を求めます。ここで陥りやすいのが、「うちは普段の開発でもドキュメントを作っているのだから、その要求も自然に満たせているはずだ」という思い込みです。私たちも、まさにそう考えていました。たとえば要件定義のフェーズでは、当然のように要件定義書を作ります。だから「成果物はもう作っている、つまり要求事項はクリアできている」と早合点してしまいがちなのです。

ところが、本当に問われるのはそこではありませんでした。「成果物を作っているかどうか」ではなく、「AIMSが書いておくべきだとしている中身が、その成果物の中に実際に書かれているかどうか」です。同じ要件定義書でも、AIMSが求める観点（たとえばAIに関するリスクや影響の検討など）が一行も触れられていなければ、証跡としては不十分とみなされてしまいます。だからこそ、プロセスを整えただけで満足せず、「証跡として残す文書に、要求された中身まできちんと書き込まれているか」を、もう一段深く確認しておく。これを最初から意識しておくだけで、審査での指摘や手戻りは、目に見えて減るはずです。

④　運用実績の期間を、甘く見ない

見落としがちなポイントです。ISO42001は、仕組みを整えて終わりではありません。整えたプロセスを実際に「運用した実績」が、一定期間求められます。文書を作り終えてから審査までに思った以上の時間が必要になりますので、スケジュールには余裕を持たせていただければと思います。

⑤　動くなら、早いほうがいい

AIガバナンスはあちこちで語られ始め、ISO42001への注目度は、今後ますます高まっていくはずです。AIサービスを提供する側はもちろん、AIを「使う」側の企業にとっても、これは決して他人事ではありません。取得に向けた一連の取り組みを走り抜けた今、ISO42001は取っておいて損のないものだと、はっきり感じています。迷っているなら、動き出すのは早いほうがいい。これが、一足先に同じ道を歩いた私たちからの、一番率直なアドバイスです。

まとめ

ISO/IEC 42001の取得に向けた道のりは、決して平坦ではありませんでした。でも、その過程で得たものは、認証という紙以上に、「AIをどう管理するか」という考え方そのものでした。

お伝えしたかったポイントを、簡潔に整理します。

• 規格の骨格： 本編はPDCAの仕組み、附属書はリスクに応じて選ぶ管理策。まずこの全体像を地図として持っておくと安心です。
• つまずきの正体： 規格理解、英語と海外認証機関、AI特化の要求とSoA、そして要求を漏れなく証跡に落とす難しさ。ここに苦労が集中します。
• 乗り越えるコツ： 支援者を早く巻き込み、原文を読み込み、審査員との対話を学びに変え、要求を仕組みに落とし込む。
• 大前提： 認証はゴールではなくスタートであり、万能でもありません。運用し続けて初めて意味を持ちます。

認証はゴールではなく、スタートです。この記事が、これからISO42001やAIガバナンスに挑む方の地図になれば幸いです。

AIガバナンスでお困りごとがあれば

ISO42001の取得やAIガバナンスの進め方について、「何から手をつければいいのか分からない」「全体像はつかめたが、自社で進めきれるか不安だ」と感じている方もいらっしゃるのではないでしょうか。実は、今回私たちがISO42001に取り組むにあたって伴走してくれたのが、ISO取得を専門に支援する部署のメンバーでした。下記でご紹介するのは、まさにその部署が提供しているサービスです。自分たち自身の取得を内側から支えてくれた知見とノウハウをそのまま活かし、同じ道を歩もうとする皆さまのお手伝いができるかもしれません。

• AIガバナンス導入（ISO42001対応） | インフォメーション・ディベロプメント

ご興味がありましたら、ぜひお気軽にご相談ください。

それではまた、次回のコラムでお会いしましょう。

当サイトの内容、テキスト、画像等の転載・転記・使用する場合は問い合わせよりご連絡下さい。

エンジニアによるコラムやIDグループからのお知らせなどを
メルマガでお届けしています。