2026年10月8日に、NIST AI RMF CoreとNIST AI 600-1を再読しました。導入前に目的、利用者、入力の許可、品質の測り方、担当者、停止・回復条件を具体化し、モデルのベンチマークや短時間の試行を業務成果と同一視しません。リスク管理は一度の承認ではなく、測定・監視・対応を繰り返す運用です。
「まずAIを入れよう」と始めると、何が改善したかを後から説明しにくくなります。導入する前に、減らしたい作業、守る品質、使えるデータ、確認する人、続ける条件を決めると、小さな試行から判断できます。
この記事は、AI導入を検討する担当者と経営者に向けた判断手順です。特定のFirst byte案件の失敗率や効果を報告するものではありません。以下の業務例と数値は、手順を理解するための架空例です。例は生成AIによる下書き利用を中心に扱います。
30秒で要点
- AIを使わない改善案も含め、同じ仕事・品質・期間で比べます。
- 生成時間だけでなく、確認、修正、例外対応を含む総時間を測ります。
- 本番に広げる前に、担当者、使用できる情報、停止と回復の条件を決めます。
最初に決める5つのこと
図はこの記事の整理案です。NISTのAIリスク管理フレームワークは、GOVERN・MAP・MEASURE・MANAGEを状況に応じて組み合わせる枠組みで、図の順番や5項目を公式の合格条件として定めているわけではありません。
表が収まらない場合は、横にスクロールできます
| 見落としやすい点 | 導入前に決めること | 試行で残す根拠 |
|---|---|---|
| 過度な期待 | 対象業務、必要品質、AI以外の比較案 | 従来方法と試行方法の結果 |
| 利用者不在 | 実際の利用者、確認者、例外の戻し先 | 使いにくかった場面と追加作業 |
| データの問題 | 使用許可、出典、鮮度、適用範囲 | 入力資料の版と未確認事項 |
| 測定の不足 | 総工数、重大な誤り、費用の測り方 | 同条件の測定記録 |
| 改善の不足 | 再確認のきっかけ、判断者、停止手順 | 継続・縮小・停止の理由 |
表の項目を埋めても失敗を防ぎ切れるわけではありません。目的は、試行の結果から次の判断へ進めるようにすることです。
1. 期待を「対象業務と必要品質」に変える
「問い合わせを自動化する」だけでは、定型質問への下書きと、契約条件を判断して顧客へ送る仕事が混ざります。まず対象を分け、AIが担当する範囲と人が判断する範囲を決めます。
たとえば架空の問い合わせ業務なら、公開済みの製品説明から回答案を作る試行と、個別契約の例外を判断する業務を分けます。後者の担当と承認が決まらない段階では、回答案を自動送信しません。
表が収まらない場合は、横にスクロールできます
| あいまいな目標 | 試行できる問いへの置き換え |
|---|---|
| なるべく自動化したい | どの種類の問い合わせを、どの資料に基づいて下書きするか |
| 速くしたい | 同じ品質で、確認・修正を含む総時間は減るか |
| 正確なAIがほしい | 対象の条件や出典に合わない回答を、どの段階で止められるか |
| AIを使えばよい | 定型文、検索改善、手順の整理では解決できないか |
「70%を自動化」「50%の時間削減」といった数値を、根拠のない共通目標にしません。自社の対象業務を測った結果から、必要な品質と両立する目標を置きます。
生成AIには文章や案を作る用途があります。一方で、もっともらしい誤情報や架空の出典を出すこともあります。「創造的な思考ができない」と一括りにするより、何を生成させ、何を根拠と照合するかを具体化した方が、導入範囲を判断できます。
2. 実際の利用者と確認者に試してもらう
デモが便利でも、日々の仕事で使えるとは限りません。担当者が資料を整える時間、出力を直す時間、承認を待つ時間が増える場合もあります。
早い段階で、対象業務を普段担当している人に、通常の入力と難しい入力を使ってもらいます。開発担当だけが使えるプロンプトや、特別に整えた資料だけで評価しないようにします。
表が収まらない場合は、横にスクロールできます
| 試す場面 | 確認すること |
|---|---|
| よくある依頼 | 必要な資料にたどり着き、担当者が確認できるか |
| 資料に答えがない依頼 | 推測で埋めず、未確認と担当への戻し先を示せるか |
| 条件が複数ある依頼 | 対象、例外、適用日を取り違えないか |
| 忙しい時間帯 | 確認者が不在でも、承認を飛ばして外へ出ないか |
| 入力を間違えた場合 | 取り消し、修正、再確認へ戻れるか |
気に入ったかどうかに加え、どの場面で何の追加作業が生じたかを記録します。使われない理由が入力の負担なら、モデルを変える前に、資料の配置や業務手順を直す判断もできます。
3. データの品質と使用条件を分けて確認する
整理されたデータでも、その業務に使ってよいとは限りません。内容の正しさと、利用する許可や条件を別々に確認します。
表が収まらない場合は、横にスクロールできます
| 観点 | 確認例 |
|---|---|
| 使用条件 | 入力できる情報か、契約や社内規則、個人情報の扱いを確認したか |
| 出典 | 正式な資料と担当が分かるか |
| 鮮度 | 適用日、版、変更箇所を識別できるか |
| 適用範囲 | 別製品、別契約、別地域の条件が混ざっていないか |
| 欠けと矛盾 | 必要な情報がないとき、どこへ戻すか |
| 偏りと不足 | 対象の期間、利用者、問い合わせの種類を、資料や評価例が十分に含むか |
資料の欠損や異常な値を直す前に、誤記なのか、残すべき実際の例外なのかを確認します。項目名や単位の統一、重複の整理などの前処理を行う場合も、元資料と変更理由をたどれるようにします。特定の利用者や簡単な問い合わせだけで評価すると、対象業務での使いにくさを見落とすことがあります。
古い料金表と新しい料金表が両方見つかったとき、AIに都合のよい方を選ばせません。適用条件を確認する担当へ戻します。「資料を大量に入れた」ことと、「今回の回答を裏付ける資料がある」ことは別です。
顧客情報や従業員情報を使う場合は、その情報を入力する必要性、利用目的、サービスの取扱条件などを確認します。本記事の判断表だけで、個別のデータ利用に必要な法的・契約上の確認を終えたとは扱えません。
4. 生成時間から「仕事を終える総時間」へ測り方を変える
AIが文章をすぐ作っても、事実確認や修正に時間がかかれば、仕事全体では速くならないことがあります。従来方法とAIを使う方法を、同じ業務範囲、品質条件、測定期間で比べます。
次は、同じ100件を同じ完了条件で処理する架空例です。従来方法は、難しい20件の対応も含め、1件12分で完了したと仮定します。AI側の通常の確認時間と、20件に発生する追加の例外対応時間は重複しません。この表は処理工数の例で、導入前の資料整備、教育、初期設定の工数と費用は別途比較します。
表が収まらない場合は、横にスクロールできます
| 工程 | 従来方法 | AIを使う試行 |
|---|---|---|
| 作成 | 100件 × 12分 = 1,200分 | 100件 × 3分 = 300分 |
| 通常の確認・修正 | 上の12分に含む | 100件 × 4分 = 400分 |
| 追加の例外対応 | 上の12分に含む | 20件 × 5分 = 100分 |
| 合計 | 1,200分 | 800分 |
| 差 | — | 400分減、従来の約33.3% |
AIの生成だけを見れば300分ですが、比較に使うのは確認と例外対応を含む800分です。約33.3%はこの仮定で計算した値で、実測結果や導入効果の保証ではありません。
作成と通常の確認・修正を合わせて1件11分かかる条件なら、100件 × 11分 + 100分 = 1,200分で、時間削減は0です。この11分は作成3分も含む合計です。どの工程を含む数字かを揃えないと、判断が変わります。
品質も別の欄で測ります。必要な条件の取り違えや、誤った外部送信など、業務にとって重大な問題を平均時間の改善で相殺しません。
表が収まらない場合は、横にスクロールできます
| 測るもの | 注意点 |
|---|---|
| 総時間 | 作成、確認、修正、例外対応、必要な準備を重複なく含める |
| 品質 | 重大な誤りと軽い修正を分け、確認条件を先に決める |
| 利用状況 | 使わなかった件数と理由も残す |
| 費用 | 利用料金、運用、追加の確認にかかる費用を確認する |
| 結果の範囲 | 対象、件数、期間、入力条件を記録する |
少数の都合のよい例だけで、他の部署や全業務への効果を推定しません。結果のばらつきや評価者の違いも確認します。時間が減った場合でも、固定給が変わらないなら、そのまま現金支出が減ったことにはなりません。金額の比較はAI導入の投資対効果で別に整理します。
5. 続ける条件と、止めて戻る条件を決める
試行で良い結果が出ても、資料やモデル、利用者、業務が変われば同じ結果とは限りません。何が変わったら再確認するかを、運用に組み込みます。
表が収まらない場合は、横にスクロールできます
| 変化・観測 | 次の判断 |
|---|---|
| 対象業務と資料の条件が同じで、必要品質と総工数を満たす | 決めた範囲で継続する |
| 一部の入力だけで修正や例外対応が多い | 対象を縮小し、原因を直して再確認する |
| 重大な条件の取り違え、許可外の入力・送信がある | 該当機能を止め、影響確認と回復へ戻す |
| 正式な資料やサービス仕様が変わる | 変更範囲を確認し、評価用の事例も更新する |
| 確認者が不在、または担当が曖昧になる | 承認を飛ばさず、担当と運用を決め直す |
「止める人」と「止めた後に影響を確認する人」を決めます。ツールの機能を止めること、外部に出た内容を回収・訂正すること、業務を元の方法へ戻すことは、それぞれ別の対応が必要です。
日本のAI事業者ガイドライン1.2も、関係者の役割、説明、記録、利用時の判断を扱っています。この記事の表は、それらを業務の試行に落とし込むための例であり、表を使えばガイドラインへの適合や事故ゼロが保証されるという意味ではありません。
最初の試行メモを作る
まず1つの業務に絞り、次の欄を関係者で埋めます。根拠がない欄には「未確認」と書き、担当と確認方法を決めます。
表が収まらない場合は、横にスクロールできます
| 欄 | 記入すること |
|---|---|
| 対象 | どの業務の、どの部分を試すか |
| 比較 | 従来方法と、AIを使わない改善案は何か |
| 入力と出力 | 使える資料、扱わない情報、外へ出す前の確認は何か |
| 評価 | 必要品質、総時間、費用、例外対応をどう測るか |
| 判断 | 誰が継続・縮小・停止を決め、停止後にどう戻すか |
責任の割り振りと記録の内容は、生成AI導入の責任分界・運用ルール・監査ログで具体化できます。評価用の資料と出力の照合は、AI生成文章の品質管理も参照してください。
参考資料
- NIST AI RMFのCore：GOVERN・MAP・MEASURE・MANAGEの役割と、利用状況に応じたリスク管理の枠組み。
- NIST AI 600-1：生成AIのconfabulationと、評価・監視・事案対応に関する検討事項。
- 総務省・経済産業省「AI事業者ガイドライン1.2」：2026年3月31日版。透明性、アカウンタビリティ、AI利用者の役割を扱う。