AI監査：AIエージェント継続評価と再承認の実務

AI監査は、導入前に一度だけ行う合否判定ではありません。稼働中のAIエージェントは、モデル、システムプロンプト、接続ツール、権限、参照データ、業務手順のいずれかが変わるだけで、受入時とは異なるリスクを持ちます。必要なのは「モデル精度を定期測定する」ことではなく、どの業務シナリオを、どの構成で、誰が、どの証跡に基づいて再承認したかを追跡できる仕組みです。本稿ではタイでAIエージェントを運用・調達する企業向けに、継続評価、独立性、レッドチーミング、証跡、再承認ゲートを一つの実務フローへまとめます。

先に結論：AI監査の単位は「モデル」ではなく業務構成で固定する

AI監査の台帳にモデル名だけを書いても、実際のリスクは再現できません。同じモデルでも、閲覧だけのFAQと、発注案をERPへ登録できる購買エージェントでは影響が違います。同じツールでも、参照権限と更新権限では監査シナリオが変わります。参照データが更新されれば、検索結果、根拠、言語、例外処理も変化します。

本稿で推奨する評価単位は、次の組み合わせです。

業務シナリオ × ツール × 権限 × データ × モデル／プロンプト版

この五つを一つの「評価対象構成」として識別し、変更前後の差分を記録します。差分がなければ定期監視でよいのか、限定回帰が必要か、独立した第三者評価まで戻すべきかを、リスクに応じて決めます。評価単位を固定すると、「モデルは同じだから再試験不要」「プロンプトだけの変更だから軽微」という危険な省略を避けられます。

また、独立性は「第三者を使ったか」という0か1かの質問ではありません。日々の変更をすべて外部へ委託するのは現実的ではなく、開発者だけで重大な変更を承認するのも不十分です。開発チームの自己評価、業務・リスク部門による第二線の異議申立て、外部第三者による独立評価を、変更の影響と残余リスクに応じて組み合わせます。

なぜ受入試験に合格したAIエージェントも監査し直すのか

受入試験は必要です。しかし、それが証明するのは、特定の時点、構成、データ、テスト条件で要求を満たしたことです。稼働後も同じ状態が続くとは限りません。

たとえば、モデルの更新で指示追従やツール選択が変わる、システムプロンプトの整理で例外条件が抜ける、コネクタの更新で利用可能な操作が増える、権限ロールの変更で参照範囲が広がる、製品マスタやSOPの更新で検索根拠が変わる、といったことが起きます。個々の変更は小さく見えても、組み合わせると業務上の能力が変わります。

NIST AI RMF Coreは、AIリスク管理をライフサイクル全体で継続的に行い、AIシステムを導入前だけでなく稼働中も定期的に評価する考えを示しています。Measure 2.4は、本番環境でシステムと構成要素の機能・挙動を監視することを扱います。Playbookも、運用条件、データドリフト、モデルドリフトの変化により、指標と統制の妥当性を再評価する必要が生じると説明しています。

ここで重要なのは「決まった曜日に同じテストを回す」だけでは足りない点です。カレンダーによる定期評価と、変更・事故・異常によるイベント駆動評価を併用します。次の事象は、少なくとも変更影響分析を開始するトリガーになります。

モデル、モデル設定、推論経路、フォールバック先の変更
システムプロンプト、ガードレール、ポリシー、検索テンプレートの変更
ツール、API、MCPサーバー、コネクタ、実行環境の追加・更新・削除
ロール、スコープ、承認者、対象拠点、対象データの変更
学習データ、RAGデータ、製品マスタ、規程、SOPの更新
重大な誤答、越権、停止失敗、証跡欠落、利用者苦情、ニアミス
業務シナリオ、影響を受ける人、法域、外部委託先の変更

AIエージェント受入試験の7ゲートは公開前の判断を整理します。本稿はその後段として、合格時の基準構成を保ち、変更後に必要な部分を再試験し、再承認する運用に絞ります。

評価対象構成を台帳化する

継続評価を始める前に、監査対象を再現できる台帳が必要です。台帳の目的は資産一覧を増やすことではなく、どのテスト結果がどの本番構成に対応するかを結び付けることです。

業務シナリオ

「顧客対応」「購買」のような大分類では粗すぎます。開始条件、入力、期待する業務結果、禁止行為、例外、承認点、終了条件を記述します。たとえば「承認済み見積依頼から候補サプライヤーを抽出し、発注ドラフトまで作る。ただし送信はしない」という単位なら、成功と越権を判定できます。

ツール

ツール名だけでなく、版、提供元、許可された操作、入力スキーマ、出力スキーマ、実行先、資格情報の種類、タイムアウト、リトライ、フォールバックを記録します。ツールの内部実装が変わらなくても、エージェントに公開する関数や説明文が変われば、選択挙動が変わるため監査対象です。

権限

人のロール名をコピーするだけでは不十分です。読取・作成・更新・送信・承認の操作、対象テナント、拠点、顧客、金額や状態の範囲、時間帯、有効期限、代理実行、承認者を明示します。許可された成功ケースと、許可されない操作を拒否するケースを対にして評価します。

データ

データセットや検索インデックスの識別子、スナップショット、抽出時刻、言語、適用範囲、更新責任者、品質検査結果を残します。本番データ全体を監査用に複製できない場合でも、テスト入力のハッシュ、取得条件、根拠文書ID、マスキング規則を残し、再現可能性を確保します。

モデル／プロンプト版

モデル名、提供形態、設定、システムプロンプト、ツール説明、ルーティング、メモリ方針、出力検証、ポリシー版を一つの構成マニフェストへまとめます。「最新モデル」のような可変名ではなく、テスト時と本番時を照合できる識別子を使います。

変更差分から再評価範囲を決める

すべての変更で全テストをやり直すと運用が止まり、何もやり直さないとリスクを見逃します。そこで変更を入力にして、影響経路をたどります。

変更された構成要素を特定する。
その要素を使う業務シナリオ、ツール、権限、データを逆引きする。
影響する失敗モードと既存統制を特定する。
必要な回帰テスト、レッドチーム、業務確認、証跡確認を選ぶ。
リスクに応じて評価者の線と再承認者を割り当てる。
本番反映前後の監視条件とロールバック条件を設定する。

変更の大きさはファイル差分の行数で決めません。たった一つの権限追加で送信が可能になれば、業務能力は大きく変わります。一方、表示文言の修正で実行経路や判断根拠が変わらない場合は、限定された確認で十分かもしれません。変更の技術量ではなく、禁止境界、影響範囲、検出可能性、回復可能性への差分で判断します。

変更クラスを決めるときの質問

新しい種類の行動を実行できるようになるか
読めるデータ、書ける対象、承認を通過できる条件が広がるか
誤りが人、顧客、財務、品質、設備、法令遵守へ与える影響が変わるか
既存の拒否テスト、停止手順、ロールバックがそのまま機能するか
以前のテストデータと指標が新しい利用状況を代表しているか
事故が起きたとき、入力からツール結果まで再構成できるか

答えが不明なら「軽微」とは分類しません。不明点を解消する評価を先に設計します。

AI第三者評価を3線で設計する

NIST AI RMFのMeasure 1.3は、最前線の開発者ではない内部専門家や独立評価者を定期評価へ関与させる考えを示します。NIST Dioptraの設計原則は、開発中の1st party、調達・評価ラボの2nd party、監査・コンプライアンスの3rd partyというテスト用途を挙げ、再現可能性と追跡性も重視しています。本稿ではこれを企業運用へ落とし、次の3線として整理します。これはTOMAS TECHの実務的な整理であり、NISTが特定の組織図を要求しているという意味ではありません。

第1線：開発・運用チームの自己評価

変更内容を最も理解しているチームが、単体テスト、シナリオ回帰、ツール境界、ログ生成、既知不具合を確認します。高速に回せることが強みです。一方、自分たちの仮定や実装上の抜けを見落としやすく、納期や稼働率の圧力も受けます。第1線の合格だけで高影響変更を本番承認しない仕組みが必要です。

第1線が提出すべきものは、成功率のグラフだけではありません。変更差分、影響分析、テストケースと入力、期待結果、実結果、失敗ログ、除外項目、既知制限、残余リスク、ロールバック手順を一つの評価パッケージにします。

第2線：業務・リスク・品質部門の異議申立て

第2線はコードを再実装するのではなく、「業務上の成功を正しく定義したか」「禁止行為を十分に試したか」「閾値が都合よく変更されていないか」「ログで本番挙動を追えるか」を問い直します。業務責任者、情報セキュリティ、品質、法務、コンプライアンス、内部統制などから、シナリオの影響に合う担当を選びます。

重要なのは署名集めではなく、独立した反証です。開発側が想定した正常経路とは別に、曖昧な依頼、競合する指示、古いデータ、権限の境界、承認取消、ツール障害、長時間処理、言語切替などを試します。指摘への対応を追跡し、未解決事項をゲート判断に残します。

第3線：外部第三者による独立評価

重大な対外影響、高い自律性、規制対象、経営上重要な判断、過去の重大事故、内部で評価能力が不足する領域では、外部第三者を組み込みます。第三者を使うだけで独立性が保証されるわけではありません。委託者、報酬、アクセス範囲、報告先、結果公開、利益相反、是正確認の条件をRFPで定めます。

Anthropicは2026年9月18日、Accentureとの組込み型評価の協業を発表し、モデル評価、レッドチーミング、アラインメント評価、セーフガード検証を挙げました。両社はこの分野の能力構築に今後5年間でそれぞれ少なくとも10億米ドルを投資する見込みとしています。一方、Anthropic自身が、組込み型評価は新しく、評価者がアクセスすべき情報や報告方法の標準、独立評価の資金モデルはまだ確立していないと説明しています。これは独立評価への投資が拡大している時宜的な例ですが、完成済みの一般標準ではありません。また外部評価者が入っても、開発・提供者の説明責任は残ります。

独立性を変更リスクへ割り当てる

すべての変更に同じ線を要求する必要はありません。ただし割当ルールは変更申請の前に決め、案件ごとに都合よく下げないことが重要です。

変更・状況	第1線	第2線	第3線の検討
表示のみ、能力・根拠・ログに影響なし	必須	抽出確認	通常は不要
プロンプト、検索、モデル設定の変更	必須	シナリオと指標を再確認	高影響用途なら実施
新ツール、新しい書込、新しいデータ範囲	必須	権限・業務・証跡を独立確認	重大影響なら実施
承認回避、越権、重大誤答、停止失敗	原因分析と修正確認	必須	原則として必要性を正式判断
規制・契約上、独立保証が必要	必須	必須	要求範囲に従い実施

表は例示の判断枠であり、法的助言や万能な分類ではありません。業種、法域、影響、既存統制に合わせて定義します。第三者評価が不要と判断した場合も、その理由と承認者を残します。

「精度1個」をやめ、6面で評価する

生成AIやAIエージェントを一つの正答率で表すと、業務上重要な失敗が平均に埋もれます。正しい答えを出しても、権限外のツールを呼べば合格ではありません。安全に停止できても、証跡が欠ければ監査や事故調査ができません。本稿では最低限、次の六つを別々に評価します。

1. 業務成功率

業務シナリオの終了条件を満たした割合です。文章の類似度ではなく、必要な入力を確認し、正しい根拠を使い、必要な承認を受け、期待する業務状態へ到達したかで判定します。部分成功、手作業への引継ぎ、タイムアウト、重複実行を区別します。

分母となるシナリオ集合を版管理し、通常ケースだけでなく、例外、複数言語、欠損、競合指示、長時間処理も含めます。用途ごとに重要度が違うため、全シナリオの単純平均だけで判断しません。

2. 越権率

許可されないツール、操作、対象、データ、時間、承認経路を試みた割合です。実際に実行された越権だけでなく、ポリシー層で拒否された試行も観測します。拒否が多い場合は統制が機能している可能性と、プロンプトや業務設計が不適切な可能性の両方があります。

テストでは明示的な攻撃だけでなく、曖昧な自然言語、過去の会話、検索文書内の指示、権限変更直後、期限切れ承認、別拠点・別顧客のIDを含めます。越権率の閾値は影響に応じて決め、重大な禁止操作は平均値に埋めません。

3. 重大誤答率

すべての誤答ではなく、顧客、財務、品質、安全、法令、個人情報、契約に重大な影響を与え得る誤答を分離します。重大度分類、判定者、根拠、異議申立て手順を先に定義します。単なる表現差や軽微な省略と、虚偽の承認、誤った送信先、重要条件の欠落を同列に扱いません。

重大誤答が少数でも、検出できず、そのまま実行され、回復が難しい場合はHOLDまたはSTOPの理由になります。逆に、誤答が発生しても決定論的な検証や人の承認で確実に止まり、影響が限定されるなら、その統制証拠も評価します。

4. 停止・復旧

異常検知から新規処理停止、進行中作業の扱い、資格情報の無効化、キュー隔離、手動運転、状態整合、再開承認までを試します。単にプロセスを終了できるかではありません。長時間動くエージェントでは、途中成果、外部ツールの副作用、再試行、重複実行も確認します。

OpenAIが2026年9月10日にパブリックベータとして発表したAgents APIは、長時間動くエージェントの文脈、ツール、サブエージェント、永続実行を管理する実行基盤の例です。パブリックベータ段階の製品発表であり、同ページの顧客事例もマーケティング上の個別例であって、成熟した監査標準や一般的な性能保証ではありません。ただし、エージェントがモデル呼出し一回ではなく、環境とツールを伴って長く動くなら、評価対象もモデル単体で終わらないことを示す材料になります。実行基盤の設計についてはAgents API運用ガイドを参照してください。

5. 証跡完全性

各テストと本番事象について、依頼、入力、参照根拠、構成版、ポリシー判定、ツール呼出し、承認、結果、例外、停止・復旧を相関できるかを確認します。秘密情報や個人情報を無制限に保存することではありません。必要最小限の証跡、マスキング、アクセス制御、保持、時刻同期、改ざん検知、エクスポートを設計します。

NIST Dioptraは、リソースのスナップショットによる再現可能性と、実験・入力履歴による追跡性を重要な性質として挙げています。特定ツールを採用するかにかかわらず、「同じ構成を再現し、誰が何を試したかを追える」ことをRFP要件へ変換できます。

6. 変更後回帰

新しい版で新機能が成功するだけでなく、以前に合格した重要シナリオ、拒否、停止、ログが壊れていないかを評価します。変更要素から依存シナリオを逆引きし、必要な回帰集合を自動または半自動で選びます。過去事故やニアミスは恒久的な回帰ケースへ追加します。

回帰結果には「前版との差」を残します。総合点が同じでも、重大シナリオが改善し、別の重大シナリオが悪化しているかもしれません。平均だけでなく、失敗の移動、分散、特定条件への集中を確認します。

AIレッドチーミングを継続評価へ組み込む

AIレッドチーミングは公開前の一大イベントではなく、脅威、能力、接続先が変わるたびに仮説を更新する活動です。通常回帰が「既知の要求を満たすか」を確かめるのに対し、レッドチームは「想定外の経路で境界を越えられないか」を探します。

対象には、間接プロンプトインジェクション、ツール説明の曖昧さ、権限混同、メモリ汚染、データ出所の偽装、承認疲れ、長時間処理中の状態変化、ツール応答の改ざん、エラー時のフォールバック、複数エージェント間の責任移動などを含めます。攻撃成功の有無だけでなく、検出、遮断、通知、証跡、復旧まで評価します。

タイではETDAが2026年6月9日のAI 2026方針で、AI Governance Testingとタイ初のRed Teaming Challengeを掲げました。ETDAはAIガバナンスのガイドライン／ツールキット12組が利用可能で、AI Ethical Impact Assessment PlaybookとAI Value Creationの2組を2026年中に追加開発中と説明しています。これはタイのエコシステムが評価実務へ進む方向を示しますが、すべてのタイ企業へ一律の法的義務を課す発表ではありません。また同発表のChallengeは実利用前の弱点発見を強調しており、本稿の継続評価はそれを稼働後へ延長する企業運用上の提案です。

証跡パッケージを「監査時に集める」から「実行時に作る」へ

監査直前にスクリーンショットを集めても、変更履歴と本番構成は再現できません。評価を実行するたびに、機械可読なマニフェストと人が読める判断記録を一緒に生成します。

構成マニフェスト

業務シナリオIDと版
モデル、設定、プロンプト、ポリシーの識別子
ツール、API、コネクタ、実行環境の版
権限、資格情報スコープ、承認経路
データスナップショット、取得条件、適用範囲
テストハーネス、評価ロジック、判定規則の版

実行証跡

テストケースID、入力、期待結果、実結果
参照根拠とツール呼出しの連鎖
ポリシー判定、承認、拒否、例外
タイムスタンプ、相関ID、評価環境
評価者、レビュー者、実行者の分離
失敗、再試験、是正、未解決事項

判断記録

適用した閾値と、その承認日・承認者
6面評価の結果と重要な差分
既知制限、残余リスク、補完統制
GO／CONDITIONAL GO／HOLD／STOPの理由
本番監視、期限、次回評価、ロールバック条件

証跡には機密情報が含まれ得ます。第三者へ渡す場合は、閲覧場所、マスキング、持出し、保持、削除、再委託をRFPと契約で定めます。独立性のために無制限アクセスを与えるのではなく、必要な検証ができるアクセスと、データ保護を両立させます。

GO / CONDITIONAL GO / HOLD / STOPへ結び付ける

評価はレポート提出で終わらせず、変更のリリース権限へ接続します。四つの判断は次のように定義できます。

GO

対象構成が承認済み閾値を満たし、重大な未解決事項がなく、証跡が完全で、監視と復旧が準備できています。GOは無期限許可ではありません。対象版、対象シナリオ、対象権限、期限を限定します。

CONDITIONAL GO

残余リスクが明示され、期限付きの補完統制、利用範囲縮小、追加監視、手動承認などによって許容できる場合です。条件、所有者、期限、解除判定を記録します。条件が満たされないまま自動的に恒久GOへ移行してはいけません。

HOLD

証拠不足、再現不能、未解決の重要欠陥、閾値未達、独立レビュー未完了などにより判断できない、または是正後の再試験が必要な状態です。本番反映を止め、何を直し、どのテストを再実行すれば判断できるかを示します。

STOP

重大な禁止境界の突破、受容できない残余リスク、停止・復旧不能、証跡の信頼性喪失などにより、対象構成の利用を停止する判断です。既存本番への影響を評価し、安全な縮退、資格情報失効、手作業への切替、事故対応を実行します。

閾値はこの記事が一律に決めるものではありません。業務シナリオの影響、リスク許容度、契約、規制、既存統制に基づき、テスト前に承認します。結果を見てから合格線を動かす場合は、例外として理由と再承認を残します。

AI監査RFPに含める要求

AI監査を外部へ依頼する場合、提案会社の知名度だけで選ぶと、範囲や証跡が合いません。RFPでは次を明確にします。

目的と評価単位

対象がモデル評価なのか、業務シナリオとツールを含むシステム評価なのかを明記します。本稿の目的なら、業務シナリオ×ツール×権限×データ×モデル／プロンプト版を対象単位にし、変更後の回帰と再承認まで含めます。

独立性と利益相反

評価会社が開発、販売、導入、運用にも関与しているか、どのチームを分離するか、誰が報告書を受け取るか、否定的結果を修正できる権限が誰にあるかを尋ねます。第三者という名称より、意思決定と報告の構造を確認します。

アクセスとデータ保護

モデル、プロンプト、ツール、ログ、テスト環境、本番観測への必要アクセスを定義します。機密情報、個人情報、越境移転、再委託、保存場所、削除、事故通知、成果物の所有権も定めます。

方法と再現性

テストケースの作成法、通常回帰とレッドチームの区別、サンプリング、重大度分類、再試験、評価者間の不一致、使用ツール、版管理を求めます。ブラックボックス評価だけの場合は、何が検証できずに残るかを示してもらいます。

6面評価とゲート

業務成功、越権、重大誤答、停止・復旧、証跡完全性、変更後回帰を別々に報告し、総合点で相殺しないことを要求します。GO／CONDITIONAL GO／HOLD／STOPの判断権限、例外、エスカレーションも決めます。

成果物と是正確認

経営向け要約だけでなく、構成マニフェスト、ケース一覧、実行ログ、失敗証拠、再現手順、指摘、重大度、是正案、再試験結果を納品物にします。監査後の質問、修正検証、証拠保管、次回変更への回帰ケース移管も契約します。

標準・法令の扱い

ISO/IEC 42001、NIST AI RMF、適用法令との対応表を求める場合、評価会社が確認した本文と適用範囲を明示させます。公開概要だけで規格条項への適合を断定しないようにします。ISOの公式概要はISO/IEC 42001をPlan-Do-Check-Actによる継続改善の管理システムとして説明し、トレーサビリティ、透明性、信頼性、リスク評価、監査スキームに触れています。本稿は規格本文を購入・確認していないため、条項番号を示しません。AIMS全体の導入についてはISO 42001導入ガイドを参照してください。

EU AI Actとタイ企業の読み分け

EU AI Actの2026年7月27日付統合英語版Article 72は、適用対象となる高リスクAIシステムの提供者に対し、技術とリスクに比例した市販後監視システムを確立・文書化し、ライフタイムを通じて性能データを能動的・体系的に収集、記録、分析して継続的適合を評価することを定めています。市販後監視計画は技術文書の一部になります。

これは継続監視の具体的な法的例ですが、タイ企業一般やすべてのAIエージェントへArticle 72が直接適用されるという意味ではありません。EU市場、提供者・導入者の役割、高リスク分類、製品・サービスの流れを確認し、必要に応じて法律専門家へ相談します。適用外でも、ライフタイム監視、文書化、変更後の適合確認という考えを、自社統制へ参考として取り入れることはできます。

運用手順：変更申請から再承認まで

1. 変更を登録する

変更者は技術説明だけでなく、対象シナリオ、能力、データ、権限、利用者、法域への影響を申告します。緊急変更でも事後記録を省略せず、暫定期限と縮退条件を付けます。

2. 基準構成との差分を生成する

承認済みマニフェストと候補版を比較し、モデル、プロンプト、ツール、権限、データ、評価ロジックの差分を出します。自動比較できない業務手順や契約変更は人が追記します。

3. 影響と評価線を割り当てる

影響経路、重大度、検出、回復、既存統制を確認し、第1線だけでよいか、第2線が必要か、第三者評価を求めるかを決めます。割当結果と理由を記録します。

4. テストパッケージを凍結する

ケース、入力、期待結果、閾値、重大度、環境を承認してから実行します。結果を見た後にケースを除外する場合は、その理由を監査証跡へ残します。

5. 回帰とレッドチームを実行する

変更に直結するテスト、重要な恒久回帰、過去事故ケース、予期しない経路を探す攻撃的評価を分けて実施します。失敗を隠さず、再現可能な最小ケースへ落とします。

6. 6面で集計し、例外を分離する

平均スコアだけを出さず、禁止境界、重大誤答、停止失敗、ログ欠落を個別に示します。数値化できない所見も、根拠、影響、所有者、期限を持つ課題として残します。

7. ゲート判断と本番条件を承認する

承認者は評価を実行した本人と分離し、GO、CONDITIONAL GO、HOLD、STOPを決めます。承認対象の構成識別子、期限、監視、ロールバック条件を記録します。

8. 本番を観測し、次の評価へ戻す

本番の失敗、越権試行、手動介入、停止、証跡欠落、利用者フィードバックを収集し、テストセットとリスク台帳へ戻します。評価は直線ではなく循環です。

よくある失敗

モデル名だけで監査範囲を決める： ツール、権限、データ、プロンプトの変更を見逃します。
成功率で越権を相殺する： 多数の正常ケースが一件の重大境界突破を隠します。
第三者へ丸投げする： 業務の成功条件と禁止事項を社内が定義しなければ、有効な評価になりません。
監査時にログを集める： 本番時の構成、入力、判断、ツール結果を再現できません。
レッドチームを年次イベントにする： 新しいツールや権限で生じた攻撃面を次回まで放置します。
条件付き承認を恒久化する： 期限、責任者、解除条件がないまま例外が通常運用になります。
評価者のアクセスを曖昧にする： 見られない情報が結果へ与える制約も、過剰アクセスによるデータリスクも管理できません。
結果を見て閾値を変える： 比較可能性と判断の信頼を失います。

実務チェックリスト

監査プログラム設計

[ ] 評価単位を業務シナリオ×ツール×権限×データ×モデル／プロンプト版で定義した
[ ] 定期トリガーと変更・事故トリガーを定義した
[ ] 3線の割当ルールと利益相反管理を決めた
[ ] 6面の定義、分母、重大度、閾値をテスト前に承認した
[ ] GO／CONDITIONAL GO／HOLD／STOPの権限と例外を決めた

変更ごとの評価

[ ] 基準構成との差分と影響シナリオを特定した
[ ] 成功ケースと拒否ケースを対で用意した
[ ] 過去事故、ニアミス、利用者苦情を回帰へ追加した
[ ] レッドチームの仮説を変更内容に合わせて更新した
[ ] 停止、復旧、ロールバック、再実行の副作用を試した
[ ] 入力から結果までの証跡を再構成できた

再承認

[ ] 評価者と承認者の役割を分離した
[ ] 未解決事項、残余リスク、補完統制を明示した
[ ] 承認対象の版、範囲、期限を記録した
[ ] 条件付き承認の所有者と解除期限を設定した
[ ] 本番監視と次回評価のトリガーを登録した

FAQ：AI監査とAIエージェント継続評価

AI監査はどの頻度で行うべきですか？

一律の頻度だけでは決められません。定期評価に加え、モデル、プロンプト、ツール、権限、データ、業務、法域の変更、事故や異常をトリガーにします。高影響で変更が多いシナリオほど、監視と再評価を密にします。頻度と範囲はリスク許容度、契約、規制、変更速度に基づき文書化してください。

AIエージェント継続評価は受入試験と何が違いますか？

受入試験は公開前の特定構成を承認する活動です。継続評価は、その合格構成を基準に、本番観測と変更差分から必要な回帰、レッドチーム、証跡確認を選び、再承認します。両者は代替ではなく連続した統制です。

AI第三者評価は必ず必要ですか？

すべての変更で必須とは限りません。影響、自律性、規制・契約、事故歴、社内能力、利益相反に応じて判断します。ただし第三者を使わない場合も、第2線の独立した反証と、その判断理由を残します。第三者を使う場合は、名称ではなくアクセス、報告先、利益相反、是正確認を設計します。

AIレッドチーミングだけでAI監査は完了しますか？

完了しません。レッドチームは未知の攻撃経路や境界突破を探すのに有効ですが、業務成功、重大誤答、停止・復旧、証跡完全性、回帰、承認をすべて代替しません。通常評価と組み合わせ、発見を恒久回帰へ移します。

精度が改善したら再承認できますか？

精度だけでは判断できません。越権、重大誤答、停止・復旧、証跡、回帰を別に確認します。精度が上がっても、新しいツールを誤って呼ぶ、拒否境界が弱まる、ログが欠けるならHOLDやSTOPになり得ます。

AI監査RFPで最初に確認すべきことは何ですか？

評価単位と独立性です。モデル単体か業務システム全体か、どの構成・データ・権限を対象にするか、評価会社が開発や販売にも関与するかを明確にします。その上で方法、証跡、データ保護、6面評価、ゲート、是正確認を要求します。

ISO/IEC 42001認証があれば個別の継続評価は不要ですか？

不要にはなりません。管理システムは継続改善の枠組みを与えますが、個別の業務シナリオ、構成、変更に対するテストと証拠は別途必要です。認証範囲と実際のAIシステム範囲も照合してください。

まとめ：AI監査を変更管理とリリース権限へ接続する

AIエージェントは、受入試験に一度合格しても、モデル、プロンプト、ツール、権限、データの更新で監査対象が変わります。評価単位を「業務シナリオ×ツール×権限×データ×モデル／プロンプト版」に固定し、変更差分から回帰範囲を選んでください。開発、業務・リスク、外部第三者の3線を影響に応じて割り当て、業務成功、越権、重大誤答、停止・復旧、証跡完全性、変更後回帰の6面を別々に評価します。結果をGO／CONDITIONAL GO／HOLD／STOPへ結び付け、対象版、期限、監視、ロールバック条件を記録して初めて、監査が運用統制になります。

AI監査RFP、継続評価の台帳、変更トリガー、評価ケース、証跡パッケージを検討する段階でも、TOMAS TECHへお問い合わせいただけます。既存の受入試験やISO 42001の枠組みを活かし、稼働後の再承認へつなぐ範囲から整理できます。

参考情報

Anthropic, “Partnering with Accenture on embedded evaluation” (2026-09-18): https://www.anthropic.com/news/accenture-embedded-evaluation
NIST, AI Risk Management Framework Core — Measure: https://airc.nist.gov/airmf-resources/airmf/5-sec-core/
NIST, AI RMF Playbook — Measure: https://airc.nist.gov/airmf-resources/playbook/measure/
NIST, Dioptra Design Principles: https://pages.nist.gov/dioptra/explanation/dioptra-motivation/design-principles.html
ISO, AI management systems: What businesses need to know: https://www.iso.org/artificial-intelligence/ai-management-systems
European Union, AI Act consolidated text, Article 72 (2026-07-27): https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX%3A02024R1689-20260727
ETDA, AI 2026 — Driving Trust AI Governance (2026-06-09): https://www.etda.or.th/th/pr-news/aigc_Driving-Trust_AI_Governance.aspx
OpenAI, “Introducing the Agents API” (2026-09-10): https://openai.com/index/introducing-the-agents-api/

本記事は2026年9月19日時点で確認した公開情報に基づく一般的な実務解説です。個別の法的助言、認証、保証を提供するものではありません。