AIエージェント導入前チェックリストで見るAISI第1.20版の観測と制御

AIエージェントの導入前には、「良い回答が出るか」だけでなく、何を見られ、どこで止められるかを決めておく必要があります。AISIが2026年7月7日に公表した「AIセーフティに関する評価観点ガイド(第1.20版)」は、その確認を「観測と制御」という言葉で整理しました。

ここでは公式ガイドの内容を、導入判定表にそのまま転記できる7項目に再編します。設定表を眺めて終わらせず、誤指示や外部ツールの誤用が起きたときに、実際に介入・停止できるかまで試すのが要点です。

AISI第1.20版が変えた安全評価の視点

AISIは、AIエージェントシステムの普及を踏まえて第1.20版へ改訂し、既存の10評価観点を見直した上で、特有の評価観点として「自律的な挙動」と「外部環境との相互作用」を追加しました。読み取り専用のチャットAIと違い、ファイル更新やメール送信、外部サービス操作まで行うAIでは、回答文の品質だけを見ても安全性を判断できません。

出典: AISI「AIセーフティに関する評価観点ガイド(第1.20版)の公開」

改訂内容の全体像が必要な場合は、先にAISI第1.20版で追加された3つのリスクを把握すると、本チェックリストの意図をつかみやすくなります。本記事ではその先へ進み、誰が、何を、どの証跡で合格とするかを実務に落とします。

「観測と制御」は何を見るか

観測は、AIが何を読み、どのツールを呼び出し、どんな結果を返したかを追える状態です。一方の制御は、目標から外れたり異常な操作を始めたりしたときに、権限を制限し、承認を要求し、処理を止める状態を指します。

AIエージェント導入前チェックリスト7項目

以下の7項目は、AISIが示した評価項目例を、AI利用企業が導入判定に使える形へ再編したものです。法令チェック表や安全認証ではないため、自社の業務、データ、接続先、影響範囲に合わせて合格条件を追記してください。

1. 対象業務と達成目標を1つに絞る
   「バックオフィスを自動化」では広すぎます。例えば「公開済み資料だけを読み、会議用の要点を提案する」のように、対象と終了条件を限定します。
2. 読み取り・作成・送信・削除・権限変更を分ける
   操作ごとに許可範囲を分け、初期値は読み取りから始めます。AIエージェントの権限を業務別に分ける考え方も、この列の設計に使えます。
3. 接続するファイル、データベース、SaaS、ツールを一覧化する
   「必要なデータだけ」で済ませず、接続名、対象フォルダ、操作範囲、管理者を記録します。
4. 入出力、ツール呼び出し、実行者、日時、結果を記録する
   回答文だけではなく、どの外部ツールを使い、対象がどう変わったかを追える状態にします。利用ログを月次で見る安全指標と組み合わせると、導入後の点検につなげられます。
5. 高リスク操作の承認点と停止条件を決める
   外部送信、削除、権限変更、高負荷処理など、失敗したときに戻しにくい操作を別表にします。承認者が不在の場合は、自動継続ではなく中断を初期値にします。
6. テスト環境で誤指示、目標逸脱、ツール誤用、記憶汚染を試す
   正常系の成功確認だけでなく、禁止した操作を依頼したり、データを取得できない状態を作ったりして、安全側に止まるかを確かめます。
7. 本番開始後の再評価日、責任者、連絡経路を決める
   モデル更新、接続先追加、権限変更、インシデントの発生を再評価の起点にします。

判定表に残す列

列	記入内容	合格の目安
確認項目	権限、ログ、停止など	対象が明確
対象業務・接続先	どの業務とデータか	名称と範囲が特定済み
担当者	設定、試験、最終判定	役割が分離済み
証跡	設定画面、ログ、試験結果	後から再現可能
最終確認・次回日	実施日と再評価予定	期限とトリガーが明確

AIエージェントの自律的な挙動をどう観測するか

AIエージェントは、目標に向けて外部情報や記憶を参照し、手順と行動を選びます。そのため、最終結果が合っているかだけでなく、目標から外れていないか、許可していない情報やツールに触れていないかを実行中に見られるようにします。

出典: AISI「AIセーフティに関する評価観点ガイド」

ここで残すべきなのは、運用者が後から判断できる証跡です。「成功」「失敗」だけでなく、使った接続先、状態変更の前後、承認者、停止理由を並べると、原因の切り分けと再発防止がしやすくなります。

AIエージェントの外部環境との相互作用をどう制御するか

外部環境には、ファイル、データベース、メール、SaaS、他のAIエージェント、物理装置が含まれます。AISIは、利用目的に不要な情報へのアクセスを防ぐこと、必要なツールだけに権限を与えること、外部コンポーネントの実行履歴を記録すること、異常時に人が介入・停止できることを評価項目例として示しています。

承認の重さは失敗時の戻しにくさで変わり、要約案の作成なら後から直せます。一方、顧客への送信、本番データの削除、アカウント権限の変更は影響が残るため、実行直前に人の承認を置き、不在時は止める運用を基本とし、入力・外部公開・自動実行の3分類も判定表のたたき台に使えます。

AIエージェント導入前にVerificationとValidationを分ける

AISIは技術的評価を、設計・仕様が要件を満たすかを見るVerification(検証)と、実環境で意図した通りに動くかを見るValidation(妥当性確認)の2つに整理しています。言い換えると、前者は「設計図の確認」、後者は「本番に近いリハーサル」です。

Verificationでは、アーキテクチャ設計書、権限設定、ログ仕様、承認フローを見ます。一方、Validationではテストデータの投入、プロンプトインジェクションを想定した試験、高リスク操作時の介入・停止試験を行い、両方の証跡がそろった状態を導入判定の材料とします。

AIエージェント導入後も繰り返し評価する

AIエージェントのリスクは、本番開始時の設定だけで固定されません。モデル更新、プロンプト変更、接続先追加、権限の拡大、組織変更によって、同じ名称のシステムでも実際の挙動と影響範囲は変わります。

再評価は「毎月第1営業日」のような定期日に加え、権限変更、新規連携、モデル更新、インシデント発生をトリガーにします。生成AIリスクを月次で経営会議へ上げる方法と合わせれば、導入判定表を運用後の台帳として継続利用できます。

導入判定表を経営会議で使う

経営会議では、「AIを使うか、使わないか」の二択にしません。対象業務、操作権限、承認点、停止試験、残るリスクを並べ、読み取りは合格、外部送信は保留のように、権限別に結論を出します。

導入判定表を残す目的は、承認者を増やすことではなく、判定材料をそろえることです。技術担当者は設定と試験結果を、業務責任者は許容できる影響範囲を、経営層は残余リスクと再評価条件を判断すると、責任の所在が曖昧になりにくくなります。

出典: 総務省・経済産業省「AI事業者ガイドライン(第1.2版)」

AIエージェント導入前チェックリストFAQ

AIエージェント導入前チェックリストの中心は、細かい規程を増やすことではなく、見えること、止められること、変更後にもう一度試すことです。1業務の読み取りから始め、設定と動作の両方を証跡で確かめてから、承認付きの書き込みへ進めてください。