AIエージェントのPoCを終えて本番業務へ移すかを判断するとき、精度を評価したという報告だけでは足りません。対象業務、利用範囲、テストで確かめたこと、残る不確実性、運用中の対応を、誰がどの根拠で判断するかまでつなげて記録する必要があります。

本稿では、評価項目を導入判断へつなぐための1枚の意思決定シートを示します。これはAISIおよびNISTの公開資料を踏まえた編集上の実務提案です。両者が定める必須様式や、すべてのAIシステムに共通する合格基準ではありません。

このシートで決めること

シートの目的は、AIエージェントを一律に承認または停止することではありません。対象業務と利用範囲を明らかにしたうえで、次のいずれにするかを判断可能にすることです。

  • Go：定めた利用範囲で運用を始める
  • 条件付きGo：人の確認や利用範囲の制限を条件に始める
  • No-Go：追加評価または設計変更をしてから再判断する

重要なのは、評価結果だけで結論を出さないことです。判断の対象範囲、観測方法、停止できる人と条件を同じ記録に置くことで、後から前提を確認できます。

判断の土台になる公開資料

AISIは、AIエージェントに観測と制御の観点を加えています。

AIセーフティ・インスティテュートは2026年7月7日、AIエージェントシステムの自律的な挙動と外部環境との相互作用に関する評価項目として、観測と制御を追加した評価観点ガイド第1.20版を公表しました。

NIST AI RMF 1.0は、導入判断を一度きりの判定にしない考え方を示しています。

NIST AI RMF 1.0は任意のフレームワークです。Govern、Map、Measure、Manageの4機能を固定順のチェックリストではなく、反復して使うものとして示しています。MapはAIを使う文脈や利用範囲を整理し、導入の初期Go/No-Go判断に必要な情報を与えます。Measureは導入前と運用中の評価、評価条件と結果の記録を扱い、その結果がManageでの対応判断を支えます。

本稿の提案は、これらをそのまま転記することではありません。評価表と承認メモを分けず、対象範囲、評価根拠、運用中に見る信号、停止条件、判断者を一つの記録にまとめるための実務上の整理です。

評価したのに判断できない状態を避ける

精度や操作画面の所感だけでは、本番移行の判断に必要な情報が残りません。本稿の判断シートでは、少なくとも次の5点を具体化します。

  1. 何の業務で、誰が、どこまで使うのか
  2. どの前提・限界・未解決事項を受け入れるのか
  3. どのテスト結果を根拠にするのか
  4. 運用中に何を観測し、誰が対応するのか
  5. どの条件なら停止またはエスカレーションするのか

どれかが欠けると、PoCで動いたという事実から、本番に進めるという結論へ飛躍しやすくなります。一方で、すべてを過度に作り込む必要はありません。対象業務のリスクと影響に応じて、判断に必要な項目を具体化してください。

Go/No-Go判断シートのテンプレート

以下は、AISIとNISTの公開資料を基にした編集上のテンプレートです。組織の規程、対象業務、リスク許容度に合わせて修正してください。

記入欄 判断に必要な記録 確認する問い
利用範囲 対象業務、利用者、入力・出力、外部環境との接点 AIエージェントは何をし、何をしないか。利用範囲は明確か。
意思決定者 本番可否の判断者、業務責任者、運用責任者 判断と運用の責任は誰にあるか。
前提・限界 想定条件、既知の制約、未解決事項 どの前提が崩れると利用を続けられないか。
評価設計 テストケース、評価指標、根拠となる結果、実施日・版・記録先、合格または保留の判断方法 何を試し、どの結果を根拠として残すか。
観測と対応 運用中の観測信号、確認頻度、対応者 想定外の挙動や外部環境との相互作用をどう把握するか。
停止・エスカレーション 停止条件、連絡先、実行権限、復旧前の確認 誰が、どの条件で、止めるまたは上位へ判断を上げるか。
結論と次回確認 Go、条件付きGo、No-Go、未解決事項、次回見直し日 今回の結論は何か。結論を見直す契機は何か。

記入例：問い合わせの振り分け案を作るAIエージェント

ここでは、社内に届く問い合わせを要約し、担当チームへの振り分け候補を作るAIエージェントを例にします。実在の導入事例ではありません。

  • 利用範囲：問い合わせ本文を要約し、振り分け候補を提示する。顧客への送信や基幹システムへの確定登録は行わない。
  • 評価設計：分類対象が曖昧な問い合わせ、複数部署にまたがる問い合わせ、必要情報が不足する問い合わせをテストケースに含める。要約内容と振り分け候補を担当者が確認し、誤りの内容、テスト時のプロンプトと対象版を記録する。
  • 観測と対応：担当者が毎営業日、確認結果、保留件数、誤分類の内容を記録する。同じ種類の誤分類が続く場合は、運用責任者へ共有する。
  • 停止・エスカレーション：人による確認を省く運用が発生した場合、または緊急性の高い問い合わせを誤った担当へ振り分けるおそれが判明した場合は、運用責任者が候補提示を停止する。業務責任者が、追加評価の対象と再開条件を決める。
  • 結論：担当者確認を前提に、限定した利用範囲での条件付きGoとする。評価対象外だった入力パターンを追加し、次回の見直し日を決める。

このように書くと、評価結果だけでなく、その結果がどの利用範囲に対するものか、運用開始後に誰が何を確認するかまで追えます。

Go、条件付きGo、No-Goをどう分けるか

以下の3区分も、外部資料が定める統一基準ではなく、判断を曖昧にしないための編集上の整理です。

結論 判断の置き方 記録すべきこと
Go 限定した対象範囲について、事前に定めた評価条件の判定が完了し、重大な未解決事項がなく、責任者、観測、停止経路が記録されている 残る不確実性、運用開始日、次回見直し日
条件付きGo 人の確認、権限、利用範囲などを制限すれば開始できるが、解除前に扱う未解決事項が残る 適用条件、解除条件、追加評価、判断者
No-Go 意図した利用範囲を支える評価根拠、または運用上の対応経路が不足している 停止理由、追加で必要な検証、再判断の条件

条件付きGoを、とりあえず進めるという意味にしないことが重要です。条件、責任者、再判断の時点を書かなければ、条件付きという言葉だけが残ります。

判断会議で確認する5つの質問

判断シートを埋めたら、会議では次の順に確認します。

  1. この判断は、どの利用範囲にだけ有効なのか。
  2. 評価結果は、想定した利用条件と例外ケースのどこまでをカバーしているか。
  3. 運用中に想定外の挙動や外部環境との相互作用をどう観測するか。
  4. 停止またはエスカレーションが必要になったとき、誰が実行できるか。
  5. 未解決の不確実性を、誰がいつ再評価するか。

回答が曖昧な項目があっても、直ちに導入を否定するとは限りません。ただし、条件付きGoにするのか、追加評価を行うのか、利用範囲を縮小するのかは、判断記録に明記します。

フレームワークを合格証にしない

このテンプレートを埋めたこと自体は、本番導入の根拠になりません。未解決の前提や限界を表面化させ、判断者が利用範囲と責任を確認するために使います。

AIエージェントの導入判断では、何を評価したかと同じくらい、その評価を誰がどう判断し、運用中にどう見続けるかが重要です。まずは対象業務を一つに絞り、1枚のシートに記録してみてください。

参考資料

注記：NIST AI RMF 1.0は改訂作業中であることが公式Coreページに示されています。運用規程に参照する場合は、対象とする版と確認日を記録してください。