AIUC-1認証か自社の審査か｜AIエージェントを入れる判断

「AIエージェントの製品が第三者の認証を取ったと聞いた。それなら社内の審査は省いていいのでは」「質問票を何十問も送るより、認証書を一枚もらえば足りるはずだ」——AIエージェントの導入を急ぐ事業部門と、審査を受け持つ情報システム部門の間で、いま実際に交わされている声です。前の声は期待で、後の声は手間を減らしたい本音です。けれども、認証は社内の審査の代わりにはなりません。認証が見ているのは製品の側で、自社がどのデータを渡し、誰の権限で動かすかは自社にしか決められないからです。この記事では、AIエージェントの安全性の認証「AIUC-1」を例に、認証を頼りにする、既存の報告書と自社の質問票で審査する、両方を組み合わせる、の三つを比べ、認証で省ける所と自社で見なければならない所を整理します。

「認証があれば審査は省ける」が崩れる所

AIエージェントの製品を調達するとき、情報システム部門が受け持つ審査は大きく二つに分かれます。一つは製品そのものの作りです。暗号化やアクセスの管理、攻撃への耐性、誤りの出方といった、提供元の側で決まる部分です。もう一つは自社での使い方です。どのデータを入れ、どの社内システムにつなぎ、誰の権限で動かすか。認証が答えるのは、主に前者です。

崩れる場面を具体的に考えます。同じ認証済みの製品でも、顧客の名簿を丸ごと読ませる会社と、公開済みの資料だけを読ませる会社とでは、危うさがまったく違います。社内の基幹システムに書き込む権限を渡すか、読むだけに留めるかでも違います。認証書は、この違いを知りません。

AIUC-1 の公式のよくある質問自身も、認証は「独立したリスク評価と継続的な監視の代わりにすべきではない」と書いています。さらに、認証はある時点の評価であって保証ではないこと、どんな基準もAIを使うことに伴う危険をすべて無くすことはできないことも明記しています。提供元がここまで書いている以上、買う側が認証を審査の免除証として扱う理由はありません。

とはいえ、認証に意味がないわけではありません。製品の作りを自社だけで試すのは、多くの会社にとって現実的ではないからです。問題は、認証で何が減り、何が残るかを分けずに受け取ることです。以下ではまず AIUC-1 が何を見ているかを押さえ、そのうえで三つの選び方を比べます。

AIUC-1 は、AIエージェントを第三者が試験して認証する基準

AIUC-1 は、AIエージェントのセキュリティ・安全・信頼性のための基準です。2026年10月時点の公式サイトは、エージェントにまつわる危険を広く扱い、技術的な試験に根ざした基準だと説明しています。基準と監査と保険を組み合わせる考え方を、電球などの製品の安全を試験してきた米国の認証機関になぞらえています。

既存の基準との違いについて、公式のよくある質問は次のように整理しています。SOC 2 はサイバーセキュリティの業界標準だが、AIに特化していない。ISO 42001 はAIのガバナンスの枠組みとマネジメントシステムを作ることに重心がある。これに対して AIUC-1 は、独立した評価によって安全策が実際に効くかを試すことに重心がある、というものです。

つまり、組織の仕組みを見る認証とは、見ている物が違います。AIガバナンスの組織の認証や ISO 42001 は、利用する会社も含めて「仕組みがあるか」を問います。AIUC-1 は、主にエージェントを作って提供する側が「製品が試験に耐えるか」を示すために取るものです。組織の認証の取り方は、AIガバナンスの認証を扱った別の記事に譲ります。

公式サイトは、主要なAIの枠組みとの対応表を用意しているとしています。挙がっているのは、SOC 2、ISO 42001、欧州のAI法、米国 NIST のAIリスク管理の枠組み、AIへの攻撃手法をまとめた知識体系、OWASP の上位10項目などです。すでに他の基準をもとに審査の質問票を作っている会社は、対応表で重なりを確かめられます。

作っている会社と、国内でまだ知られていない理由

基準を作っているのは、米国サンフランシスコの AIUC です。社名は、人工知能の引受会社を意味する英語の頭文字です。公式トップは、自社を最先端AIの基準と保険の会社と紹介し、シリーズAで5,500万ドルを調達したと掲げています（日付の記載はありません）。基準は、数百人規模のセキュリティとリスクの責任者や、最先端のAIを作る会社とともに作ったとしています。人数は公式の各ページで250人超・300人超と表記が分かれています。

取得した会社として、公式トップは、KPMG の米国法人が四大監査法人で初めて自社の業務基盤で認証を取ったこと、Cursor のエージェントが12のリスク区分で数千の技術的な試験に通ったことを掲げています。業務自動化の UiPath は、2026年3月9日の公式発表で、文書の読み取り、エージェント、アシスタントの3製品で取得したと発表しました。2,000を超えるリスクの場面で試験を受け、監査は米国のセキュリティ監査会社シェルマンが行ったとしています。

国内でまだ知られていない理由は、確かめた範囲で三つあります。一つ目は、基準と認証の情報が英語でしか出ていないことです。日本語で読めるのは、取得した製品の提供元が出した日本語の発表くらいです。二つ目は、認定監査人として名前が挙がっているのがシェルマンやコールファイアといった米国の監査会社であることです。国内の監査法人や認証機関が監査人になれるかは、公式の資料では確かめられませんでした。

三つ目は、取得している製品の多くが米国の会社のものであることです。国内の会社がこの認証を目にするのは、米国のAIエージェント製品を調達するとき、提供元の営業資料や信頼性の説明のページの中で、という形が中心になるはずです。つまり当面、国内の読者にとって AIUC-1 は「取る」ものではなく「受け取って読む」ものです。本稿もこの立場で書きます。

6つの領域と、四半期ごとの改定

2026年10月時点の基準は、6つの領域に分かれています。A はデータとプライバシーで、データの利用方針、知的財産、個人情報、顧客をまたいだ露出、秘密情報の漏れを扱います。B はセキュリティで、攻撃を想定した試験、入力の絞り込み、アクセスの管理などです。C は安全で、リスクの分類、展開前と第三者による試験、有害な出力や範囲外の出力を扱います。

残りの三つは、D の信頼性（ハルシネーションの防止と試験、危ない道具の呼び出しの制限）、E の説明責任（失敗時の計画、責任者、委託先の審査、記録、透明性、品質の管理）、F の社会（AIを使ったサイバー攻撃や重大な悪用の防止）です。買う側の審査で特に効くのは、B の攻撃への耐性と D の道具の呼び出しの制限で、ここは自社で試すのが難しい部分です。

基準は四半期ごとに改定されます。公式サイトに並ぶ2026年の改定は、1月15日に証跡の要件の詳細化、4月15日に MCP のセキュリティとエージェントの権限と第三者のリスク、7月14日にコーディングエージェント向けの版と技術監査人の指針、10月15日に公開されたモデルを使う場合の統制と第三者による試験の強化です。

改定が速いのは利点でもあり、読む側の注意点でもあります。AIへの攻撃の手口やエージェントの使われ方は数か月で変わるので、年に1回しか変わらない基準では追いつきません。一方で、認証を取った時点の版と最新の版の間には差が生まれます。この差の扱いは、あとの「版と範囲を突き合わせる」の節で詳しく見ます。

認証までの4段と、買う側の手に入るもの

公式サイトによれば、認証は4つの段で進みます。1段目は範囲決めで、対象のエージェント、使われ方、統制の領域を決めます。48時間で差分の評価から始め、組織はこの時点で基準の版を1年間固定します。2段目は評価で、AIUC が脱獄、悪意ある指示の紛れ込み、データの漏えい、ハルシネーション、危ない道具の呼び出しといった現実的な場面を試します。攻撃を想定した試験は、一般に1,000〜5,000の場面に及ぶとしています。

3段目は、認定を受けた第三者の監査人による監査です。6つの領域にわたって、方針、運用、技術の統制を確かめます。4段目で監査報告書と認証書が出され、認証は1年間有効です。公式のよくある質問は、多くの組織が5〜10週間で終えること、有効を保つには少なくとも3か月ごとの評価が要ることを書いています。公式の認証書を出せるのは AIUC だけです。

買う側から見て大事なのは、手に入るものが二つあることです。一つは「認証を取った」という事実と認証書、もう一つは監査報告書です。審査の材料になるのは後者で、どの製品のどの使われ方が範囲に入り、どの版で、どの統制がどう確かめられたかが書かれているはずです。ただし、買う側が監査報告書をどう受け取れるかは、公式のよくある質問では確かめられませんでした。

したがって最初に、提供元に秘密保持の契約のもとで監査報告書を見せてもらえるかを聞きます。認証書の一枚だけで判断すると、範囲も版も分かりません。SOC 2 で報告書の中身を読むのと同じく、AIUC-1 も報告書を読んで初めて審査の材料になります。

3つの選び方を、見ている範囲で比べる

ここからが本題です。AIエージェントの製品を審査するやり方は、大きく三つに分けられます。AIUC-1 の認証を頼りにする、SOC 2 などの既存の報告書と自社の質問票で審査する、両方を組み合わせる、です。見ている範囲・更新の速さ・自社が決める所・費用の増え方の四つの観点で比べます。

観点	認証を頼りにする	既存の報告書と自社の質問票	両方を組み合わせる
見ている範囲	エージェントに固有の攻撃・誤動作への耐性を、試験で確かめた結果	提供元の組織のセキュリティの統制と、自社が聞きたいことへの自己申告	製品の試験の結果と、自社の使い方に固有の問い
更新の速さ	基準は四半期ごとに改定され、認証も四半期ごとに再試験	報告書は年1回が多い。質問票は自社が改訂するまで同じ	認証で速さを補い、質問票は自社の変化に合わせる
自社が決める所	範囲と版が自社の使い方に合うかの判断が抜けやすい	問いの設計と回答の真偽の見極めを全部自社で持つ	渡すデータ・権限・接続・止め方・受け入れの可否
費用の増え方	買う側の手間は小さいが、認証のない製品には使えない	製品の数と問いの数に比例して増える	最初に質問票を作り直す手間が要り、その後は製品ごとに軽くなる

表の中で一番大きいのは、見ている範囲の違いです。SOC 2 は提供元の組織の統制を見る報告書で、生成AIに固有の試験の欄を持ちません。逆に AIUC-1 は製品の試験には強いものの、自社の使い方のことは何も知りません。どちらか片方だけでは、どこかに空白が残ります。

費用の増え方も見ておきます。質問票だけの審査は、製品が一つ増えるたびに同じ量の読み込みが要ります。組み合わせにすると、最初の作り直しに手間がかかる代わりに、認証のある製品ほど1件あたりの審査が軽くなります。以下では、三つの選び方を一つずつ見ていきます。

選び方1：認証を頼りにする。省けるのは「製品の作り」の試験

認証を頼りにするやり方で省けるのは、製品の作りが攻撃や誤動作にどこまで耐えるかを自社で試す作業です。悪意ある指示の紛れ込みへの耐性、ほかの顧客のデータが混ざらないか、指示されていない道具の呼び出しを止めるか、といった点は、買う側が独自に試すには技術も時間も足りません。認証の評価が1,000を超える場面を試していることは、自社で数回試すよりずっと厚い材料です。

質問票のうち、製品の作りに関する問いは、認証の監査報告書で置き換えられる可能性があります。たとえば「入力に紛れ込んだ悪意ある指示をどう検出しているか」「道具の呼び出しにどんな制限があるか」「事故のときの対応の計画はあるか」といった問いです。提供元が自己申告で答えるより、第三者が確かめた結果のほうが信頼できます。

ただし、このやり方だけで決めると三つの穴が残ります。一つ目は、認証のない製品が来たときに審査の物差しが無くなることです。二つ目は、範囲に入っていない機能や製品を、認証済みの印象のまま受け入れてしまうことです。三つ目は、自社の使い方の危うさを誰も見ないことです。選び方1は単独ではなく、組み合わせの一部として使うのが現実的です。

頼りにするなら、少なくとも監査報告書を受け取り、範囲と版と例外の欄を読むことを条件にします。認証書の写しだけで受け入れを決める運用は、審査の手順書で明示的に禁じておきます。

選び方2：既存の報告書と自社の質問票で審査する

これまで多くの会社が取ってきたのが、SOC 2 などの第三者の報告書と、自社で作った質問票を組み合わせるやり方です。報告書の欄の読み方は別の記事で扱っているので、ここでは要点だけにします。報告書は提供元の組織の統制が一定の期間動いていたかを示すもので、生成AIを載せたサービスに固有の欄はありません。

このやり方の強みは、どんな製品にも同じ物差しを当てられることです。認証の有無に関係なく、自社が気にする点を全部聞けます。弱みは、エージェントに固有の問いに対する回答が自己申告になることです。「悪意ある指示への対策をしていますか」と聞けば、ほとんどの提供元は「している」と答えます。その対策が実際に効くかは、回答からは分かりません。

もう一つの弱みは、質問票が古くなりやすいことです。AIエージェントは、つなぐ道具を増やしたり、外のAIから呼べる口を開いたりと、数か月単位で形を変えます。年に1回しか見直さない質問票では、MCP でつながる先や、エージェントが自分で動ける範囲といった問いが抜け落ちます。AIUC-1 が2026年4月の改定で MCP とエージェントの権限を足したのは、基準の側でも同じ変化を追いかけている例です。

認証を取った製品がまだ少ない今は、このやり方を土台に残すことになります。ただ、土台のままでは、エージェント製品の数が増えるほど担当者の手が足りなくなります。そこで三つ目の選び方が出てきます。

選び方3：組み合わせる。認証で埋まる問いを質問票から外す

組み合わせるやり方では、質問票を「製品の作り」の問いと「自社の使い方」の問いに分け直します。製品の作りの問いは、AIUC-1 の監査報告書や SOC 2 の報告書で埋まる場合は回答を求めず、報告書の該当箇所を示してもらうだけにします。自社の使い方の問いは、認証の有無に関係なく必ず聞きます。

分け直しの目安を挙げます。製品の作りの問いは、攻撃への耐性、データの分離、記録の取り方、事故の計画、委託先の審査など、6つの領域に対応するものです。自社の使い方の問いは、自社のどのデータが入るか、どの社内システムにつなぐか、エージェントにどの操作を許すか、誰が承認するか、どう止めるかです。

組み合わせの利点は、審査の時間を、自社にしか判断できない問いに集中できることです。認証のある製品は1件あたりの審査が軽くなり、認証のない製品には従来どおりの質問票を当てます。物差しは一つのまま、手間だけが製品によって変わる形になります。

注意したいのは、外した問いを「確かめなくてよい問い」にしないことです。外したのは回答を求める作業であって、報告書の該当箇所を読む作業は残ります。誰がその箇所を読み、何を確かめたかを、審査の記録に残します。

認証が見ていない所：自社が渡すデータと動かす権限

組み合わせにしても、自社で必ず見なければならない所があります。一つ目は渡すデータです。同じ製品でも、どの社内文書、どの顧客の情報を読ませるかは自社が決めます。個人情報を含むなら、委託や国外への移転の扱いを含めて、自社の決まりに照らして判断します。

二つ目は権限です。エージェントに読むだけを許すのか、社内システムへの書き込みや社外への送信まで許すのか。誰の資格で動かすのか。共有のアカウントで動かすと、誰が何をさせたかが追えなくなります。三つ目は接続です。MCP などで社外の道具につなぐ場合、その先の道具は認証の範囲の外にあるかもしれません。認証を受け取る側で起きやすい失敗を挙げます。

• 認証書の写しを受け取っただけで受け入れを決め、対象の製品と範囲を誰も読んでいなかった
• 認証の範囲は特定の製品だけだったのに、同じ提供元の別の機能まで認証済みとして扱った
• エージェントに顧客名簿への書き込み権限まで渡したが、権限を決めた記録が残っていなかった
• 共有のアカウントで動かしたため、エージェントの操作を誰が指示したのか追えなかった
• 四半期の再試験の結果を確かめず、有効が切れた認証を1年後も有効だと思い込んでいた

どれも、認証そのものの欠陥ではなく、受け取る側の使い方の失敗です。認証は製品の作りを確かめる材料で、自社の使い方の決定を肩代わりしない、という線を審査の手順書の冒頭に書いておきます。

版と範囲を突き合わせる：どの版で、どの製品が対象か

監査報告書を受け取ったら、最初に見るのは版と範囲です。公式サイトによれば、組織は範囲決めの段で基準の版を1年間固定します。たとえば2026年1月の版で認証を取った製品は、4月の改定で足された MCP のセキュリティやエージェントの権限の要件を満たしているとは限りません。

範囲も同じです。UiPath の発表では、範囲は文書の読み取り、エージェント、アシスタントの3製品と明記されていました。KPMG の取得も、特定の業務基盤についてのものです。提供元が認証を取ったと書いていても、自社が買う製品や機能が範囲に入っているかは別に確かめます。

突き合わせの作業は、AIに下読みさせると速くなります。監査報告書と自社が使う予定の機能の一覧を並べ、範囲に入っていない機能、固定された版より後に足された要件、例外として書かれた統制を拾い出させます。拾い出した結果には、報告書のどの箇所が根拠かを必ず書かせ、人が原文と照らして確かめます。AIに範囲の解釈を決めさせないことが条件です。

版の差が見つかった場合は、提供元に最新の版の要件への対応を聞きます。差のある要件が自社の使い方に関係するなら、その問いだけを質問票に戻します。関係しないなら、差があることを記録に残して先へ進みます。

四半期の再試験と、製品が変わったとき

公式サイトは、認証を受けたシステムに四半期ごとの再試験があり、有効を保つには少なくとも3か月ごとの評価が要るとしています。UiPath の発表も、四半期ごとの継続的な評価を含むと書いています。買う側にとって、これは年1回の報告書より新しい材料が手に入る可能性を意味します。

一方で、再試験の結果を買う側がどう受け取れるかは、公式の資料では確かめられませんでした。受け入れの条件として、再試験の結果か、認証が有効なままであることの確認を、四半期ごとか契約の更新のたびに受け取れるかを、契約の前に聞いておきます。

もう一つの論点は、製品が変わったときです。AIエージェントは、使うモデルを差し替えたり、新しい道具をつないだりします。公式のよくある質問は、認証はある時点の評価だと明記しています。大きな変更があったときに、提供元が買う側に知らせる約束があるかを契約で確かめ、知らせを受けたら自社の審査のどこを見直すかを決めておきます。

自社の側の変化も同じです。最初は読むだけで入れたエージェントに、あとから書き込みの権限を足すなら、それは新しい審査の対象です。認証が続いているかと、自社の使い方が変わっていないかを、同じ周期で確かめます。

費用の増え方：審査の手間はどこで減り、どこで残るか

費用は、認証の取得費用ではなく、買う側の審査の手間で考えます。認証の取得にかかる費用は提供元が負うもので、料金は公式サイトに書かれていません。買う側の手間は、製品の数、問いの数、見直しの周期の三つで増えます。

組み合わせにすると、最初に質問票を作り直す手間が一度かかります。そのあとは、認証のある製品では製品の作りの問いを読む作業が報告書の確認に置き換わり、1件あたりの手間が減ります。認証のない製品は、これまでと同じ手間がかかります。

減らないのは、自社の使い方の問いです。データ、権限、接続、止め方、受け入れの判断は、製品が増えるほど比例して増えます。ここを減らす近道は、製品ごとに決めるのではなく、データの区分と権限の型を先に社内で決めておくことです。型が決まっていれば、審査は型への当てはめで済みます。

なお、AIの事故に備える保険も AIUC が扱う領域の一つですが、保険で何が補償されるかは別の記事で扱っています。本稿では、保険を審査の代わりにしない、の一点だけを付け加えます。

AIに任せてよい下読みと、人が決める受け入れ

審査の作業のうち、AIに任せられるのは下読みです。届いた質問票の回答や監査報告書を読み込ませ、自社の問いに答えていない箇所、範囲の外の機能、版の差、例外の記述を拾い出させます。英語の報告書を日本語で要約させるのも、この段の仕事です。

人が決めるのは、受け入れるかどうか、どのデータと権限を渡すか、例外を認めるかです。AIの要約には根拠になった報告書の箇所を必ず書かせ、人が原文で確かめます。AIに「この製品は安全か」を判断させないことを、審査の手順書に書きます。受け入れの前に確かめる項目は次のとおりです。

• 監査報告書を受け取り、対象の製品・機能・使われ方の範囲を読んだか
• 固定された基準の版と、最新の版の差を確かめたか
• 自社が使う機能が範囲に入っているか、入っていない機能を書き出したか
• 四半期の再試験の結果か、認証が有効なことの確認を受け取る約束があるか
• 渡すデータの区分、エージェントの権限、接続先を自社で決めて記録したか
• 受け入れの可否と例外を、責任者の名前で承認したか

この確認の役割は、部署ごとに分けておきます。報告書の範囲と版は情報システム部門、データと権限の使い方の決定はAI導入の担当と利用部門、契約の約束は法務、というのが一つの分け方です。一人の担当者が全部を抱える形にしないことが、審査を形だけにしないための条件です。

受け入れを決める手順

組み合わせのやり方を社内の手順に落とすと、次の5つの段になります。最初の段だけは手間がかかりますが、二つ目以降は製品ごとに繰り返す作業です。

一度作れば、認証のある製品が増えるほど審査は軽くなります。質問票の分け方そのものも、基準の改定に合わせて年に1〜2回見直します。取引先の審査全体をAIに任せる仕組みや、自社が認証を取る準備は、それぞれ別の論点なので本稿では扱いません。

よくある質問

AIUC-1 の認証がある製品なら、質問票は送らなくてよいですか

いいえ。製品の作りに関する問いは監査報告書で置き換えられる可能性がありますが、自社が渡すデータ、エージェントの権限、接続先、止め方の問いは残ります。公式のよくある質問も、認証は独立したリスク評価と継続的な監視の代わりにすべきでないと書いています。

SOC 2 の報告書と AIUC-1 の認証は、どちらを優先しますか

優先ではなく、見ている物が違うと考えます。SOC 2 は提供元の組織の統制を、AIUC-1 はエージェントの攻撃や誤動作への耐性を見ています。公式サイトは両方を同時に取る道も案内しています。両方あれば、それぞれで埋まる問いを質問票から外せます。

国内の会社が自社で AIUC-1 を取る意味はありますか

対象は主に、AIエージェントを作って提供する会社です。国内でエージェント製品を提供し、米国の会社に売る計画があるなら検討の余地はありますが、国内の監査人で監査を受けられるかは公式の資料では確かめられませんでした。利用するだけの会社は、受け取って読む側に徹するのが現実的です。

基準の中身は誰でも読めますか

公式サイトでは、6つの領域の概要と四半期ごとの改定の内容が公開されており、統制の一覧へのつながりも用意されています。ただし、個々の製品の監査報告書は公開されていないため、審査に使うには提供元から受け取る必要があります。

まとめ

AIUC-1 は、AIエージェントの攻撃や誤動作への耐性を第三者が試験して認証する基準で、四半期ごとに改定され、認証も四半期ごとに再試験されます。製品の作りを自社だけで試すのが難しい会社にとって、厚い材料になるのは確かです。ただし、認証が見ているのは製品の側で、自社が渡すデータ、エージェントの権限、接続先、止め方は認証の外に残ります。選ぶなら、認証を頼りにするか質問票かの二択ではなく、監査報告書で版と範囲を確かめたうえで、認証で埋まる問いを質問票から外す組み合わせです。AIには下読みと差分の拾い出しを任せ、受け入れの可否と例外は責任者の名前で人が決めます。

• AIUC と AIUC-1 の内容は、AIUC の公式トップ、基準の公式サイト（トップ・よくある質問）を2026年10月27日に確かめた範囲に基づきます。UiPath の取得は、同社の2026年3月9日の公式発表によります
• 買う側が監査報告書や再試験の結果を受け取る方法、料金、国内の監査人については、公式の資料で確かめられなかったため、提供元に確かめる項目として扱っています

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。