AIの「第三者評価」は安全証明ではない　導入前に確認する7つの質問

AIサービスについて「第三者機関が評価済み」「独立した専門家が安全性を確認」と説明されても、それだけで安全な製品だと判断することはできません。第三者評価は、特定のモデル、設定、試験条件、期間、リスクについて得られた証拠の一つです。製品全体や自社での使い方まで無条件に保証する認証とは限りません。

この記事で分かるのは、第三者評価に関する発表やレポートを導入判断へ使うための読み方です。結論を先に示すと、確認すべきなのは「誰が評価したか」だけではありません。何を安全だと主張し、どのバージョンを、どの権限で、どんな方法により調べ、何を調べなかったか、その結果を受けて何を直し、いつ再評価するかまで確認する必要があります。

なぜ今、第三者評価の読み方が重要なのか

2026年9月18日、AnthropicはAccentureとの「組み込み型評価」を発表しました。発表によると、評価者は従来の外部テストより深く企業内部へ入り、従業員に近いアクセスを使って、モデル評価、レッドチーミング、アラインメント評価、セーフガードの試験を行う構想です。一方、Anthropic自身も、組み込み型評価について、評価者が何へアクセスし、何を報告すべきかという標準や、安定した資金調達の仕組みはまだ確立していないと説明しています。また、当面の評価費用をAnthropicが負担することも開示しています。Anthropicの発表

続く9月22日には、OpenAIが第三者評価に関する原則案を公表しました。対象とする安全上の主張を先に定義すること、評価に必要なアクセスを与えること、方法と不確実性を説明すること、利益相反へ対処すること、評価者の編集上の独立性を維持することなどを挙げています。OpenAIの発表

ここで区別したいのは、両社の発表は第三者評価の重要性や今後の仕組みについて述べた一次情報ではあるものの、発表内容そのものが第三者によって検証済みという意味ではないことです。Anthropicの取り組みは開始段階であり、OpenAIの文書も評価制度に関する同社の提案です。実際の評価結果や運用実績が公表された段階で、改めて確認する必要があります。

英国AI Security Instituteも、第三者評価は特定時点の能力や脆弱性を示す「スナップショット」になり得る一方、評価科学は、安全だと断定する認証機能を担えるほど成熟していないとの見方を示しています。UK AISIの解説

したがって、企業の導入担当者が取るべき姿勢は、第三者評価を無視することでも、評価済みという表示を信頼の代用にすることでもありません。評価結果を、対象と限界が明記された一つの証拠として扱うことです。

「評価済み」「監査済み」「認証済み」は同じではない

実務では、似た表現が混在します。名称だけで判断せず、その活動で何を実施したのかを確認してください。

表現	一般に示し得る内容	それだけでは分からないこと
内部評価	開発会社自身がモデルや制御を試験した	開発チームから評価担当が独立していたか
第三者評価	開発会社以外の組織が対象を試験した	評価範囲、資金関係、結果の公開権限
レッドチーミング	攻撃者の視点から失敗や回避方法を探した	通常利用時の品質や全リスクを確認したか
監査	定めた基準、手続き、記録への適合を調べた	技術的な安全性を実機で試したか
認証	認証制度が定める要求への適合を示した	自社固有の用途で安全か、認証範囲外に何があるか
ベンチマーク	固定した課題で能力や挙動を測定した	実運用、最新バージョン、連携ツールを含む結果か

この表は用語の法的な定義を示すものではありません。制度や契約によって意味は変わります。重要なのは、ラベルを具体的な証拠へ分解することです。

例えば「独立機関によるレッドチーム評価済み」という説明を見たら、次のように読み替えます。

独立機関とはどの組織か
独立性を損なり得る支払い、出資、業務関係は開示されているか
どのモデルと製品機能を試したか
標準状態と安全機能を外した状態のどちらを試したか
Web検索、コード実行、メール送信などの連携機能を含めたか
結果の全文、要約、方法、限界のどこまで公開されているか
指摘を受けて何を変更し、変更後を再試験したか

これらが不明なら、「評価を受けたという事実」は確認できても、「自社用途に必要な安全性が確認された」とは判断できません。

第三者評価を読む7つの質問

1．何についての安全主張を評価したのか

最初に探すのは総合点ではなく、評価対象となった主張です。「安全です」では広すぎます。検証可能な形なら、例えば次のようになります。

一般利用者が特定の危険手順を引き出そうとしても、定義した成功率以下に抑えられる
外部文書に埋め込まれた命令を受けても、承認なしに送信や削除を行わない
指定した属性間で審査結果の差が許容範囲を超えない
障害時には操作を停止し、人間へ引き継げる

安全主張には、対象リスク、条件、合格基準、前提、限界が必要です。OpenAIの原則案も、評価開始前に対象とする主張を定め、何が範囲内・範囲外だったかを結論で明確にする考え方を示しています。

評価レポートに具体的な主張がなければ、広報文の「安全性を確認」という表現を、導入承認の根拠にしない方が安全です。

2．実際に使うモデル、製品、設定を評価したのか

同じ名称のAIでも、結果を左右する要素は多数あります。

モデルのバージョンや更新日
システム指示と安全フィルター
温度、推論時間、トークンや操作回数の上限
Web、社内検索、コード実行などのツール
ユーザーへ与えた権限
管理者設定、地域、契約プラン
単発の質問か、長い会話や自律実行か

能力を測るため安全制御を外したモデルと、利用者に提供される製品では挙動が異なります。反対に、モデル単体のテストが良好でも、ファイル、ブラウザ、社内システムを接続した製品全体では新しいリスクが生じます。

評価対象の識別子が導入候補と一致しない場合は、「参考資料」として扱い、自社環境で追加試験を行います。モデルが継続更新されるサービスでは、レポートの日付だけでなく、評価後に何が変更されたかも確認します。

3．評価者は何から独立しているのか

第三者であることと、完全に利害関係がないことは同義ではありません。委託元から報酬を受けても、有用な第三者評価は可能です。問題は、関係が隠されていることや、否定的な結果を公表できないことです。

最低限、次を確認します。

誰が評価費用、計算資源、モデル利用料を負担したか
評価者が対象企業へコンサルティング、販売、開発支援も提供しているか
結果に応じて報酬が変わる契約になっていないか
評価者や責任者を誰が選定したか
対象企業が結論や表現を拒否できるか
利益相反の申告、担当者の除外、一定期間の兼務制限があるか

Anthropicは、Accentureとの取り組みについて、評価費用を直接負担する予定であること、非独占の関係であること、異なる資金形態の評価者とも連携する意向を開示しています。これは独立性が証明されたという意味ではありませんが、導入担当者が関係性を検討するための重要な情報です。

判断は「有償だから失格」「有名組織だから合格」という二択にしません。資金関係を開示し、評価方法、結論、公開の独立性を守る仕組みがあるかを見ます。

4．評価に必要なアクセスが与えられたか

外から製品画面を数回試すだけでは、内部の監視、制御、学習過程、事故記録まで評価できません。一方、企業秘密や危険な能力への無制限アクセスにも、情報漏えいのリスクがあります。そのためアクセスは、評価したい主張に比例させる必要があります。

確認項目は次の通りです。

公開版だけか、リリース前のモデルも試したか
安全制御のオン・オフを比較できたか
内部評価、既知の事故、監視ログへアクセスできたか
評価者自身が試験を実行したか、企業担当者へ操作を依頼したか
アクセスできなかった資料や機能は何か
企業管理端末や施設内での閲覧など、アクセス制約が結論へ影響したか

深いアクセスは評価の質を高め得ますが、「社内に入った」という事実だけでは独立性を保証しません。反対に、機密保持のため詳細を公開できない場合もあります。アクセスの深さと、結論を自分で決められる権限を別々に確認することが重要です。

5．試験方法と不確実性を追跡できるか

評価結果には、再現に必要な条件と、結果がどの程度ぶれるかの説明が必要です。単一のプロンプトで一度成功した、あるいは失敗しなかっただけでは十分ではありません。

次を確認してください。

テストケースの選び方と件数
通常例、境界例、攻撃例の構成
同じ条件での反復回数
合否基準と採点者
AIによる自動採点を人間の専門家で検証したか
成功率だけでなく、ばらつきや信頼区間を示したか
比較対象としたモデルや従来手段
実利用に近い複数ターンや長時間実行を含めたか
実行時間、費用、トークン、操作回数などの予算

英国AISIは、評価結果を現実の危害へ結び付けるには、具体的な危害経路と能力を対応させるリスクモデルが必要だと説明しています。また、十分なアクセスと試験時間の確保も課題に挙げています。簡単な課題で低い成績だったから高度な悪用もできない、という推論は成り立ちません。試験していない経路については未確認と扱います。

6．何を評価できず、何が非公開になったか

良いレポートほど、限界が明記されています。確認したいのは次の情報です。

対象外にしたリスク、言語、地域、利用者
時間や費用のため実施しなかった試験
アクセス制限で確認できなかった証拠
危険性や機密性を理由に非公開とした方法
対象企業の依頼で削除・修正した箇所
評価者と企業の見解が一致しなかった点
結果を一般化できない条件

すべてを公開できないこと自体は、直ちに問題とはいえません。攻撃手順、個人情報、企業秘密を公開すれば別のリスクが生じるからです。ただし、非公開部分があること、非公開の理由、結論への影響を説明できなければ、読み手は証拠の強さを判断できません。

「問題は見つからなかった」という表現は、問題が存在しないという意味ではなく、実施した範囲では発見されなかったという意味です。評価範囲が狭いほど、この違いは大きくなります。

7．指摘後の是正、再試験、継続監視があるか

評価はレポート公開で終わりではありません。指摘が製品や運用の変更につながり、その変更後も安全主張が成り立つかを確かめる必要があります。

重大度と対応期限を誰が決めたか
修正、制限、監視強化、提供延期など何を行ったか
同じ評価者または別の評価者が再試験したか
未解決の残余リスクを誰が承認したか
モデルやツールの更新時に再評価する条件があるか
運用中の事故、苦情、回避手法を取り込む仕組みがあるか

NISTのAI RMF Coreは、AIを導入前だけでなく運用中も評価し、評価方法や結果を文書化すること、独立した評価者や領域専門家を関与させること、第三者AIのリスクを継続的に監視することを扱っています。第三者レポートは、導入時に一度保管して終わる証明書ではなく、変更管理や定期レビューへ接続する資料として使うべきです。

導入担当者が実務で試せる確認手順

手順1：自社の利用場面と失敗時の影響を決める

まず製品一般の安全性ではなく、自社の用途を定義します。文章の言い換えだけを行うAIと、顧客データを検索してメールを送るAIでは、必要な証拠が異なります。

用途、扱う情報、接続先、実行可能な操作、利用者、失敗時の影響を書き出します。影響が大きいほど、第三者評価の全文、個別試験、契約上の通知、停止手段まで要求します。

手順2：評価資料を三つに分けて集める

資料は次の三層に分けます。

発表資料：評価を実施したという企業の説明
評価資料：評価者が作成した方法、結果、限界を含む報告
運用資料：修正内容、現在の設定、監視、事故対応、再評価計画

発表資料しかない段階では、「評価結果を確認済み」と記録してはいけません。「評価の実施または計画を企業が発表」と記録します。

手順3：安全主張と証拠の対応表を作る

次のような短い表で十分です。

自社が必要とする主張	提示された証拠	対象一致	未確認点	判断
承認なしに外部送信しない	エージェント評価の要約	モデルは一致、メール連携は対象外	製品統合後の挙動	条件付き
顧客情報を学習へ使わない	契約条項とデータ説明	契約プラン一致	下請け処理	追加質問
危険な依頼を拒否する	第三者レッドチーム報告	言語が英語のみ	日本語での性能	自社試験

証拠がない欄を空欄のまま承認しないことがポイントです。未確認点を、追加資料、自社試験、機能制限、残余リスクの受容のいずれで扱うか決めます。

手順4：自社環境で小規模な受け入れ試験を行う

第三者評価が優れていても、自社のデータ、言語、権限構成を完全には再現できません。実データを使う前に、架空データと隔離環境で次を確認します。

許可した情報だけを参照するか
権限の異なる利用者間で情報が混ざらないか
外部文書の命令を操作指示として実行しないか
送信、変更、削除の前に承認を要求するか
エラーや曖昧な入力で安全側に停止するか
操作履歴から原因を追跡できるか
管理者が短時間で停止、権限剥奪、復旧できるか

これは第三者評価の再実施ではなく、外部の証拠を自社の利用条件へ接続する受け入れ確認です。

手順5：条件付き承認と再評価条件を記録する

導入判断は「安全／危険」の二択にせず、条件を付けられます。例えば、読み取り専用で開始する、外部送信を無効にする、対象部門を限定する、人間承認を必須にする、といった方法です。

同時に、再評価のきっかけを定めます。

基盤モデルや安全フィルターが変わった
新しい外部ツールを接続した
権限や対象データを拡大した
重大事故や新しい回避手法が報告された
評価レポートの対象期間を超えた
自社の許容水準を超える失敗が発生した

失敗しやすい判断

有名な評価者だから結果も正しいと考える

組織の知名度は、個別評価の範囲や方法を保証しません。担当チームの専門性、テスト方法、利益相反、公開権限を案件ごとに確認します。

「第三者」という一語だけで独立性を判断する

企業外の組織でも、発注者、資金、データ、公開許可に強く依存する場合があります。依存関係を開示し、結論へ影響させない統制があるかを見る必要があります。

モデル単体の結果を製品全体へ当てはめる

検索、メモリ、プラグイン、社内データ、実行権限が加われば、リスクは変化します。評価対象が基盤モデルだけなら、製品統合部分を別に確認します。

一度の合格を更新後も使い続ける

クラウド型AIは、名称が同じでも内部モデルや制御が更新されることがあります。変更通知と再評価条件がなければ、過去の証拠がいつまで有効か判断できません。

評価レポートを自社の責任移転に使う

第三者評価は、導入企業が用途、権限、データ、監督を設計する責任を引き受けてくれるものではありません。Anthropicも発表の中で、組み込み型評価者の存在によってモデル提供者自身の責任が減るわけではないと説明しています。同様に、利用企業も自社の運用責任を評価者へ移すことはできません。

この手順だけでは足りない場合

医療、雇用、与信、保険、教育評価、重要インフラ、公共サービスなど、人の権利、安全、生活へ大きく影響する用途では、この記事のチェックだけで導入判断を完結させないでください。適用法令、業界規則、契約、影響評価、専門家による検証が別途必要です。

また、評価結果の詳細が国家安全保障、脆弱性、個人情報などの理由で非公開となる場合、公開資料だけで十分な保証を得られないことがあります。その場合は、守秘義務下での説明、監督機関への報告、契約上の保証、機能制限など、別の統制を組み合わせます。それでも重大な未確認リスクが残るなら、導入延期や非AI手段の採用も選択肢です。

導入前チェックリスト

評価対象となった安全主張を一文で説明できる
対象モデル、バージョン、製品機能、設定が分かる
評価対象外のリスクと利用条件が明記されている
評価者の選定方法、報酬、その他の取引関係が開示されている
評価者がどの資料、モデル、ログへアクセスしたか分かる
テスト件数、反復、採点、合格基準、不確実性を確認できる
公開前の確認、修正、削除に関する権限が説明されている
指摘事項、是正内容、未解決の残余リスクが分かる
修正後の再試験または継続監視が計画されている
自社の言語、データ、権限、連携先で受け入れ試験を行った
モデル更新や事故発生時の再評価条件を決めた
停止、権限剥奪、復旧、人間への引き継ぎ手順がある

一つでも不明だから直ちに不採用、というチェックリストではありません。不明点の重要度を、用途と失敗時の影響に照らして判断するためのものです。ただし、重大な操作を任せる製品で、対象範囲、方法、限界、是正の四つが確認できない場合は、少なくとも権限を制限した試行段階に留めるのが妥当です。

まとめ

第三者評価の価値は、「第三者」という肩書ではなく、明確な安全主張、対象に合ったアクセス、追跡できる方法、利益相反への対処、限界の開示、是正と再評価によって決まります。

2026年9月のOpenAIとAnthropicの発表は、AI企業が評価者を開発・運用の深い部分へ関与させようとしていることを示しています。同時に、組み込み型評価のアクセス、報告、資金、共通標準は発展途上です。今後、具体的な評価報告、指摘事項、是正結果がどこまで公開されるかを見る必要があります。

確認日は2026年9月23日です。主要な一次情報として、OpenAIの第三者評価原則、Anthropicの組み込み型評価に関する発表、NIST AI RMF Core、英国AI Security Instituteの第三者評価に関する実務的な解説を確認しました。新しい評価結果や制度が公表された場合は、対象範囲、独立性、方法、限界、是正という同じ軸で再確認してください。

PRIMARY SOURCES