試行期間が終わり、部門長を集めたデモは好評だった。それでも「では来月から本番の業務に載せるのか」という問いになると、会議が止まることがあります。動いている画面は見たが、何が満たされれば移してよいのかを、試行を始める前に誰も文章にしていなかったためです。この記事では、生成AIの試行を、本番移行の可否を判断する材料を作る工程として設計し直し、受入条件・証拠・判定・運用準備を一枚の記録につなげる手順を整理します。
対象は、生成AIの試行をこれから設計する方、または試行を終えて社内の判断をまとめる立場の方です。特定製品の優劣、合格ラインとなる数値、法令への適合可否の断定は扱いません。そもそもAIを業務補助として使うかどうかの位置づけは業種横断・AI業務補助の経営判断軸、サービスそのものの選定は生成AIサービス選定の実務チェックリスト、導入後の成果測定は生成AI導入の効果測定で扱っています。本稿はその間にある、試験の設計と移行判断を扱います。
- 1 対象業務：どの業務のどの工程を対象とし、誰が使い、誰が移行の可否を判定し、何を対象から外すかを、試験を始める前に確定させる
- 2 試験条件：日常的に扱う代表的な入力、体裁が崩れた資料や判断が割れる例外、試験では入力しないと決めたデータ、実運用に近い権限・版・負荷の条件を定める
- 3 証拠：試験に用いた入力の集合、測る項目とその式、人が確認した範囲と確認者、使用した製品と版、実施日を記録する
- 4 判定：試験の前に書いた受入条件と照らし、満たされた項目、満たされなかった項目、確かめていない項目を分けて示し、緩和していないリスクを併記する
- 5 運用準備：担当者、権限、ログ、代替手段、事故時の対応、移行後の監視を決める
矢印は工程の順序を表します。図に合格点や試験件数の数値は入れていません。参照した資料にそれらの指定がないためです。この5段階の並びは本記事の編集上の整理であり、公的機関が定めた手順ではありません。以降の各節が、この5段階に対応します。
1. PoCは何を決めるための試験か
試行が「動くかどうか」を見る場になっていると、終わったときに残るのは印象です。印象は共有できますが、移行の可否を決める根拠には使いにくい。試行を本番へ移してよいかを判断する材料を作る工程として設計すると、手元へ残るものが変わります。
米国国立標準技術研究所（NIST）が公表した『Artificial Intelligence Risk Management Framework (AI RMF 1.0)』（NIST AI 100-1、2023年1月26日）の MANAGE 1.1 は、次のように記しています。
「A determination is made as to whether the AI system achieves its intended purposes and stated objectives and whether its development or deployment should proceed.」（当該AIシステムが意図された目的および明示された目標を達成しているか、その開発または配備を進めるべきかについて、判断が行われる）
注意したいのは文の形です。この一文は受動態で書かれており、判断を下す主体が明示されていません。「NISTが判定者を定めている」とは読めません。誰が判断するのかは、各組織が決める空白として残されています。節2で判定者を先に決めるのは、この空白を自社側で埋めるためです。
「go/no-go」という語をどこまで借りるか
NIST が AI RMF の効果（Framework Effectiveness）について説明しているページは、「Framework users are expected to benefit from:」（枠組みの利用者は次の事柄から便益を得ることが期待される）という書き出しに続けて便益を列挙します。その一つが 「explicit processes for making go/no-go system commissioning and deployment decisions」（システムの運用開始および配備に関する go/no-go の判断を行うための、明示的な手続き）です。
位置づけを取り違えないようにします。主語は Framework users であり、NIST が go/no-go の手続きを要求しているわけではありません。列挙されているのは、枠組みを用いた結果として期待される便益です。対象も system commissioning and deployment、すなわちシステムの運用開始と配備であって、試行そのものの合否ではありません。なお go/no-go は AI RMF 内の2箇所に異なる文脈で現れますが、いずれも主語は Framework users です。
参照する資料の性格と、本稿での「PoC」
AI RMF は自身について、自主的であり、権利を保全し、特定分野に限定されず、ユースケースに依存しないことを intended to be（そうであることを意図している）という形で述べています。また Core の冒頭には 「Actions do not constitute a checklist, nor are they necessarily an ordered set of steps.」（各アクションはチェックリストを構成するものではなく、順序づけられた手順の集合であるとも限らない）とあります。本稿では「NIST 準拠」といった表現は用いません。
あわせて、本稿が引用した NIST の資料に PoC（概念実証）の定義は見当たりません。本稿は「本番移行の可否を判断する材料を作る試験」という意味で用います。
2. 対象業務、利用者、判定者、除外条件
受入条件は、いきなりは書けません。何の業務で、誰が使い、誰が判定するのかが決まっていなければ、「満たされた」と告げる相手が定まらないからです。設計は対象の確定から始まります。
AI RMF の MAP 機能には、この作業に対応する項目が並びます。MAP 1.3 は 「The organization’s mission and relevant goals for AI technology are understood and documented.」（AI技術に関する組織のミッションと関連する目標が理解され、文書化される）、MAP 1.4 は 「The business value or context of business use has been clearly defined or – in the case of assessing existing AI systems – re-evaluated.」（事業上の価値または事業利用の文脈が明確に定義される。既存システムの評価では再評価される）と記しています。
用途の粒度については MAP 2.1 が、AIシステムが支援する具体的なタスクと実装に用いる手法（分類器、生成モデル、推薦システム等）を定義することを outcome としています。「議事録作成に使う」では粗く、どの工程のどの作業を補助するのかまで降ろすことになります。
| 項目 | 書き出す内容 | 決めずに進むと |
|---|---|---|
| 対象業務 | どの業務のどの工程か。前後の受け渡し | 受入条件の分母が定まらない |
| 利用者 | 誰が使うか。部署、習熟度、社外を含むか | 特定の人の技量に依存する |
| 判定者 | 移行の可否を判断する人と、決裁の場 | 結果が出てから判断者を探す |
| 除外条件 | 対象から外す案件と、その理由 | 都合の悪い事例が事後に外れる |
判定者の欄について、MANAGE 1.1 の文に判断主体は書かれていません（節1）。NIST AI 600-1 の MS-2.3-003 は、配備前の試験結果を関連する生成AIの関与者と共有することを挙げ、その例として 「such as those with system release approval authority」（システムのリリース承認権限を持つ者など）を示しています。原文は such as、すなわち例示であり、承認権限者を置くことを要件化した文でも、時期を定めた文でもありません。ただし、その権限を誰が持つのかが決まっていなければ結果の渡し先が定まらない——これは本記事の整理です。
除外条件を試験の前に書くのも同じ理由です。結果を見てから外す事例を選べる状態では、判定は動きます。
3. 現行業務のbaselineと期待する変化
「速くなった」「楽になった」は、比較の相手があって成り立ちます。相手は、AIを使う前の同じ業務の状態＝baseline です。試行が始まってから測ろうとすると、すでに現場の手順が動いており、比較の相手が失われます。
baseline に何を並べ、どう測るかは生成AI導入の効果測定で扱っています。本稿がここで足すのは二点だけです。ひとつは、MAP 1.4 が事業上の価値または事業利用の文脈を明確に定義するとしている以上、何がどうなれば価値があると言えるのかを試験の前に書いておくこと。もうひとつは、期待する変化と並べて変えてはならない条件を書くことです。速さと引き換えに落ちうるもの——確認工程、記録の粒度、社外へ出る文面の点検——を挙げておくと、試験の後に「速くはなったが」の議論を根拠づけられます。
測り方の定義を残す欄も要ります。着手から完了までに待ち時間を含めるかどうかで、同じ業務の数字は変わるためです。試行後に同じ定義で測り直せなければ、比較は成立しません。
4. 代表入力、例外、禁止データ、実運用に近い条件
試験の入力が、担当者の手元にあった読みやすい資料へ偏ると、結果は良く出ます。本番の入力はそこまで整っていません。
AI RMF の MEASURE 2.3 は 「AI system performance or assurance criteria are measured qualitatively or quantitatively and demonstrated for conditions similar to deployment setting(s). Measures are documented.」（性能または保証の基準が定性的もしくは定量的に測定され、配備環境に類似した条件で実証される。測定内容は文書化される）と記しています。本番と同一の環境を無条件に求める文ではなく、どの条件で測ったのかを残すと読むのが実務的です。
範囲の外側についても項目があります。MEASURE 2.5 は 「The AI system to be deployed is demonstrated to be valid and reliable. Limitations of the generalizability beyond the conditions under which the technology was developed are documented.」（配備されるAIシステムが妥当かつ信頼できることが実証される。技術が開発された条件を超えた一般化可能性の限界が文書化される）としています。確かめた範囲の外は、確かめていないと書くことになります。
生成AIについては、NIST AI 600-1 がより直接的です。MS-2.5-001 は 「Avoid extrapolating GAI system performance or capabilities from narrow, nonsystematic, and anecdotal assessments.」（狭く、体系的でなく、逸話的な評価から、生成AIシステムの性能や能力を外挿することを避ける）、MS-2.3-002 は 「Evaluate claims of model capabilities using empirically validated methods.」（モデルの能力に関する主張を、経験的に妥当性が確認された方法で評価する）と記しています。
ここで気をつけたいのは、例が少ないことだけを理由に「狭く、体系的でなく、逸話的」と分類はできない点です。少数の事例でも、対象範囲・選定方法・試験条件・評価手順が定めてあれば体系的な評価になりえます。逆に言えば、会議で示された数例について、その四つが記録されていない場合は、そこから本番の性能を外挿できません。非体系的な評価になるおそれがある、という判断はこの条件のうえで成り立ちます。
| 入力の区分 | 何を入れるか | 見るところ |
|---|---|---|
| 代表入力 | 対象業務で日常的に扱う体裁と分量の資料 | 手直しの量と、直した箇所の傾向 |
| 例外・境界 | 体裁が崩れた資料、情報が欠けた資料、判断が割れる事例 | 誤りの出方。使う人が誤りに気づけるか |
| 入力しないデータ | 試験では入れないと決めたもの（区分と理由を書く） | 実際に混ざっていないか |
| 負荷の条件 | 同時に使う人数、締切のある時間帯 | 応答の遅れと、遅れたときの手順 |
入力しないデータを先に決めるのは、試験の途中で本番のデータが混ざる事態を避けるためです。MAP 1.6 はシステム要件が関連する関与者から引き出され理解されることを扱い、要件文の例として 「the system shall respect the privacy of its users」（当該システムは利用者のプライバシーを尊重するものとする）を挙げています。要件は文にしておくと、試験条件へ落とせます。情報の区分と権限はAIに渡す情報の管理と権限設計で扱っています。
あわせて、使用した製品と版、設定、実行した権限、実施日を条件として控えます。これらは節6の記録項目へ引き継ぎます。
5. 品質・時間/費用・安全・プライバシー/セキュリティ・運用負荷の受入条件
受入条件とは、「これが満たされていれば本番へ移してよい」と試験の前に合意した文です。試験の後に書くと、出た結果に合う条件が選ばれます。
土台になるのは、許容できるリスクの範囲です。MAP 1.5 は 「Organizational risk tolerances are determined and documented.」（組織のリスク許容度が決定され、文書化される）と記しています。許容度が文書になっていないと、受入条件の水準は担当者の感覚の上に置かれます。
残っているリスクとの関係を述べているのが MEASURE 2.6 です。同項目は、AIシステムを安全上のリスクについて定期的に評価するとしたうえで、「its residual negative risk does not exceed the risk tolerance, and it can fail safely」（残存する負のリスクがリスク許容度を超えないこと、そして安全に失敗しうること）を挙げています。残っているリスクの絶対量ではなく、許容度との関係で見る構図です。外したときに業務側で気づいて止められる形かどうかも、受入条件に入ります。
| 面 | 受入条件として書くこと | 空欄（自社で決める） |
|---|---|---|
| 品質 | 何をもって使える出力とするか。誰がどの基準で判定するか | 許容する誤りの種類と水準 |
| 時間・費用 | 1件あたりの所要時間、確認工数、利用料。baselineとの比較の式 | 移行に見合うと判断する水準 |
| 安全 | 誤った出力が業務へ流れたとき、どこで止まるか | 止まらない経路を残してよいか |
| プライバシー・セキュリティ | 入力の区分、保存先、権限、記録の範囲 | 交渉の余地を置かない条件 |
| 運用負荷 | 使う人の手順、教育、問い合わせ、例外処理の担当 | 現場が負える範囲 |
この五面の分け方と、空欄の扱い
受入条件を五つの面へ分けたのは本記事の整理であり、引用した NIST の資料が定めた分類ではありません。分ける目的は、品質以外の面を落とさないことにあります。また試験件数、期間、正答率、誤りの許容件数、費用の上限といった数値は、本稿が引用した資料にありません。自社のリスクとユースケースで決める欄として、空欄のまま示します。
受入条件を書こうとすると、書けないことが分かる場合があります。「品質はどうなれば十分か」に答えられない業務は、AIを載せる前の段階で、判定基準が言語化されていない業務です。これは試行の失敗ではなく、試行が返した情報です。
6. test set、metric、human review、versionの記録
試験の後に問われるのは「何をどう試したのか」です。残っていなければ、結果の読み直しも次回との比較もできません。
MEASURE 2.1 は 「Test sets, metrics, and details about the tools used during TEVV are documented.」（TEVV——試験・評価・検証・妥当性確認——において用いられたテストセット、指標、ツールの詳細が文書化される）と記しています。並んでいるのは、入力の集合、測る項目、使った道具の三つです。
| 記録項目 | 何を書くか | 対応 |
|---|---|---|
| test set | 代表入力と例外の内訳、作り方、実データを含むか | MEASURE 2.1 |
| metric | 何を、どの式で測るか。baselineと同じ定義か | MEASURE 2.1 |
| tools | 製品名、設定、実行環境 | MEASURE 2.1 |
| human review | 誰が、どの範囲を、どの基準で見たか。判断が割れた事例 | 本稿の具体化 |
| version | モデルや製品の版、確認日 | 本稿の具体化 |
| 条件 | 権限、時期、負荷、除外した事例（節4） | MEASURE 2.3 / 2.5 |
下の二行について、人の確認と版の記録は、引用した項目が名指ししているものではなく、本稿による具体化です。ただし MEASURE 2.5 が一般化可能性の限界を文書化するとしている以上、どの条件で測ったのかは書き残す対象に入ります。生成AIの製品は、利用者側が何もしなくても版が変わりえます。版を書いていない結果は、後から同じ条件で読み直せません。
自動で採点する場合、採点する側の設定と版も変数です。検索と生成を分けて測る例はRAGの品質評価で扱っています。記録の宛先も決めます。MS-2.3-003 は配備前の試験結果の共有を挙げています。要約の段階で不利な結果が落ちれば、判定は別の情報の上で行われます。渡す記録から不利な結果と未確認の項目を落とさない——これは本記事の整理です。
7. go／conditional go／hold／stopと未解決事項
合否の二択にすると、材料が足りていない試行まで不合格へ寄せられます。逆に、条件付きで進める判断が合格へ丸められると、残った条件を誰も追いません。四区分を提案します。
この四区分と、次節の判定記録は本記事の編集上の整理です
go／conditional go／hold／stop という分類は、引用した NIST の資料が定めたものではありません。MANAGE 1.1 が示すのは、意図した目的を達成しているか、開発または配備を進めるべきかについて判断が行われる、という記述までです。四区分は、その判断を社内で扱いやすくするための整理です。
| 判定 | 状態 | 次の行動 |
|---|---|---|
| go | 受入条件が満たされ、残余リスクが許容度の内側にあると判定者が確認した | 移行の時期と、節8の運用準備を確定させる |
| conditional go | 受入条件は満たすが、未確認または未設定の項目が残る | 解除条件を文にする。誰が、何を、いつまでに、何をもって解除するか |
| hold | 判定に足る証拠が揃っていない | 不足している証拠と再開の契機を記録し、試験の設計へ戻る |
| stop | 受入条件を満たさない、または許容度を超える残余リスクが残る | 理由を記録する。対象業務を変える案と、AIを使わない案を含めて検討する |
運用が難しいのは conditional go です。解除条件が文になっていないと、実質的に go として動き始めます。
そして、どの判定であっても残っているリスクを書きます。MANAGE 1.4 は、負の残余リスク——緩和されていないリスクの合計と定義される——を、下流の取得者と end users の双方について文書化するとしています。対象は緩和したリスクではなく、緩和していないリスクです。end users が明記されている点も読みどころで、使う人の側に残る負担や誤りの影響が記録の対象に入ります。
本稿の四区分は、試行への評点ではなく、移行をどう扱うかの選択肢として置いています（節1）。
8. owner、権限、ログ、fallback、インシデント、監視
go と判定しても、移行後に誰が何を見るのかが決まっていなければ、判定材料はまだ揃っていません。ここは判定の前に決める欄です。
MEASURE 2.4 は 「The functionality and behavior of the AI system and its components – as identified in the MAP function – are monitored when in production.」（MAP機能で特定されたAIシステムとその構成要素の機能および挙動が、本番運用中に監視される）と記しています。監視の対象が MAP 機能で特定したものと結びついている点が要点です。節2で対象を細かく確定させておくと、監視する項目もそこから決まります。
止める手立てについては MANAGE 2.4 が 「Mechanisms are in place and applied, and responsibilities are assigned and understood, to supersede, disengage, or deactivate AI systems that demonstrate performance or outcomes inconsistent with intended use.」（意図された用途と整合しない性能や結果を示すAIシステムを、置き換え、切り離し、または停止するための仕組みが整備され適用され、責任が割り当てられ理解されている）と記しています。仕組みと、責任の割り当てと、その理解が並んでいます。停止する手段があることと、誰が使ってよいと分かっていることは別です。
移行後の計画については MANAGE 4.1 が広い範囲を挙げています。「Post-deployment AI system monitoring plans are implemented, including mechanisms for capturing and evaluating input from users and other relevant AI actors, appeal and override, decommissioning, incident response, recovery, and change management.」（配備後のAIシステム監視計画が実施される。利用者その他の関連する関与者からの入力を収集し評価する仕組み、異議申立てと上書き、廃止、インシデント対応、復旧、変更管理を含む）
| 欄 | 判定の前に決めること |
|---|---|
| owner（担当） | 出力の品質と事故の一次窓口。交代時の引き継ぎ |
| 権限 | 誰がどの範囲で使えるか。人の確認を経ずに社外へ出る経路があるか |
| ログ | 何が記録され、誰が取り出せるか。保存期間 |
| fallback（代替手段） | 停止中に業務を回す手順と担当。手作業を含めて成立するか |
| インシデント | 気づいた人の初動、連絡先、記録の残し方 |
| 監視 | 測り続ける項目と頻度、異議申立てと上書きの経路 |
欄の並べ方は本記事の整理ですが、異議申立てと上書き、廃止、インシデント対応、復旧、変更管理は MANAGE 4.1 が名指しした要素です。初動の手順は生成AIインシデントの初動対応、権限の絞り方はAIエージェントの権限設計で扱っています。
9. 一枚で残すPoC判定記録
ここまでの欄を一枚へ落とすと、そのまま判定の記録になります。この様式は本記事の編集上の整理であり、公的機関が定めた様式ではありません。数値の欄は、自社のリスクとユースケースに応じて埋める空欄として置いています。
| 欄 | 対応する節 |
|---|---|
| 対象業務・工程／利用者／判定者／除外条件 | 節2 |
| baseline／期待する変化／変えてはならない条件 | 節3 |
| 試験条件（代表入力・例外・入力しないデータ・権限・版・実施日） | 節4 |
| 受入条件（五面） | 節5 |
| 証拠（test set・metric・tools・human review・version） | 節6 |
| 判定／解除条件／残余リスク／未解決事項 | 節7 |
| 運用準備（owner・権限・ログ・fallback・インシデント・監視） | 節8 |
| 共有先と、渡した日 | 節6 |
この様式で効くのは、未解決事項の欄が空欄のまま目に見える点です。埋まらない欄があること自体は問題ではありません。埋まっていないと分かったうえで判断するのか、気づかずに判断するのかが違います。
まとめ
試行を「動くかどうかを見る場」から「本番移行の可否を判断する材料を作る工程」へ置き直すと、必要なものは三つに絞られます。試験の前に書いた受入条件、どの条件で何を測ったかの記録、そして判定と一緒に残す残余リスクと未解決事項です。節9の様式は、この三つを一枚に落とすためのものです。
この手順を踏んでも、そのAIシステムが安全である、法令に適合している、事故が起きない、といったことは言えません。分かるのは「どの条件で何を確かめ、何を確かめていないか」だけです。それでも、この一枚があれば社内の議論は「デモの印象」から「未確認の欄」へ移ります。移った先の議論は、次に何をすればよいかを示します。
これから試行を計画するなら、まず節5の受入条件の表を一つ埋めてみてください。空欄のまま残る面が、試験の前に社内で決める事項です。すでに試行を終えているなら、節9の様式へ結果を移してみてください。埋められない欄が、判定の前に取り戻す証拠です。
引用元・参考文献
公的機関・一次情報
- NIST『Artificial Intelligence Risk Management Framework (AI RMF 1.0)』（NIST AI 100-1、2023年1月26日公表。MAP 1.3〜1.6／2.1、MEASURE 2.1／2.3／2.4／2.5／2.6、MANAGE 1.1／1.4／2.4／4.1 の各 outcome、および「intended to be voluntary, rights-preserving, non-sector-specific, and use-case agnostic」「Actions do not constitute a checklist, nor are they necessarily an ordered set of steps.」／確認日：2026年8月25日）：https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf
- NIST『Effectiveness of the AI RMF』（「Framework users are expected to benefit from:」に続く便益の列挙のうち「explicit processes for making go/no-go system commissioning and deployment decisions」／確認日：2026年8月25日）：https://airc.nist.gov/airmf-resources/airmf/4-effectiveness/
- NIST『AI RMF Core』（AI RMF 1.0 の抜粋。確認日：2026年8月25日）：https://airc.nist.gov/airmf-resources/airmf/5-sec-core/
- NIST『Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile』（NIST AI 600-1、2024年7月26日。MS-2.5-001、MS-2.3-002、MS-2.3-003／確認日：2026年8月25日）：https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf
※ go／conditional go／hold／stop の四区分、受入条件を五面へ分けた整理、節9の判定記録の様式は、本記事による編集上の整理です。NIST がこれらの分類・様式を規定しているものではありません。NIST が go/no-go に触れている箇所は、枠組みの利用者が得ると期待される便益の列挙であり、対象はシステムの運用開始と配備の判断です。MANAGE 1.1 は受動態で書かれており、判断の主体は明示されていません。NIST AI 600-1 の各項目は "Suggested Action"（推奨される行動）であり、義務ではありません。AI RMF 1.0 は改訂作業中であることが公式ページに告知されています（"The AI RMF 1.0 is being updated. A revised version is in progress."／2026年8月25日確認）。本稿に試験件数、期間、正答率、費用上限の数値を置いていないのは、参照した資料にそれらの指定がないためです。