2026年10月8日に、NISTの現行AI RMFページを再読しました。AI RMFは任意利用の枠組みで、設計・開発・利用・評価へ信頼性の観点を組み込むことを目的としています。ページはAI RMF 1.0が改訂中であること、2026年4月7日に重要インフラ向けAI RMFプロファイルのコンセプトノートが公開されたことも案内しています。この記事の三条件、Lv0〜3、役割表はこの考え方を業務へ翻訳した編集案で、NISTの権限レベルや認証ではありません。
AIに資料の要約を頼んだのに、同じ接続先で資料を変更したり、顧客へ送信したりできる。こうした状態では、「下書きだけ」の依頼と、実際に与えた権限が一致していません。
任せ方は、仕事の種類と操作の許可を分けて決めます。この記事は、文章作成や情報整理を中心にした運用例です。四段階やチェック表を採用するだけで、誤りや事故がなくなるという説明ではありません。
30秒で要点
- 誤りの影響、戻せる範囲、根拠を点検し、入力と操作の許可を別に確認します。
- アイデア・下書き・推奨・確定の四段階は、仕事を整理する案です。権限の自動許可には使いません。
- 読む、変更する、削除する、送る権限を分け、実行するシステムでも制限します。
- タグは照合の補助です。担当、承認範囲、停止と回復の条件を残します。
三つの条件から始め、許可を別に確認する
最初に見るのは、次の三条件です。全部そろえば無条件に任せてよい、という判定表ではありません。
表が収まらない場合は、横にスクロールできます
| 条件 | 確認すること | 見落としやすい点 |
|---|---|---|
| 誤りの影響が小さい | 誰に、どの程度の損失や誤解が生じるか | 社内の案でも機密入力や外部接続は別 |
| 戻せる範囲が明確 | 元の状態、回復方法、残る影響 | 送信・開示の影響は完全に取り消せるとは限らない |
| 根拠が明確 | 正式な参照先、対象、確認日、例外 | 古い資料や条件違いを最新の事実として使わない |
仕事の四段階と、実行権限を混同しない
表が収まらない場合は、横にスクロールできます
| 段階 | 任せる仕事の例 | 追加で決めること |
|---|---|---|
| Lv0：アイデア・発散 | 切り口、見出し、比較観点の候補 | 渡せる情報、対象、避ける内容 |
| Lv1：下書き・整形 | 要約、文章案、表現の統一 | 根拠の照合、編集、公開前の確認 |
| Lv2：判断・推奨 | 選択肢の比較、優先順位の案 | 前提、不確実性、判断者、必要な専門確認 |
| Lv3：確定・約束 | 価格・条件の確定、契約、公開や送信 | 権限を持つ担当の判断、必要な承認と実行条件 |
これはFirst byteの編集上の分類です。Lv0やLv1でも、資料の公開可否や入力先の利用条件、ツールの権限を確認します。「文章の整形だから低リスク」と決め付けません。
価格・契約・法務・医療・金融、成果保証、数値、固有事例の公開などは、誤りの影響と必要な専門確認を考えます。AIに案を作らせることと、正式な判断や説明を確定させることは別です。人が承認したという記録だけで、その内容の正しさまで保証されるわけでもありません。
例：料金案内の要約を任せるなら
架空の社内作業として、公開済みの料金案内から説明文を作る場合を考えます。価格改定や顧客への連絡まで任せた例ではありません。
表が収まらない場合は、横にスクロールできます
| 境界 | 許可する範囲の例 | その依頼に含めない操作 |
|---|---|---|
| 入力・参照 | 指定した公開ページと確認日の資料 | 顧客情報や無関係の社内文書の取得 |
| 下書き | 条件を残した要約と要確認箇所の提示 | 正式な価格や例外条件の新規決定 |
| 更新・削除 | 許可された作業用原稿への保存 | 公式料金表の上書き、資料の削除 |
| 送信・公開 | 今回は実行させず、担当へ原稿を渡す | 顧客へのメール送信、公式ページの公開 |
資料を読む権限から、変更・削除の権限を推定しません。OWASPのExcessive Agencyも、機能・権限・自律性の過剰付与を分け、要約用途に変更や削除の権限を与える例、メールを読む用途に送信機能を付ける例を挙げています。
この図と表は実装の仕様ではありません。実際の接続先で、許可された資料だけを読み、許可された操作だけを実行できるかは別に確認します。禁止プロンプトやタグは、認可の代わりになりません。実行側で対象と操作を制限し、必要な人の承認を通します。
毎回の確認と、事前承認の範囲を設計する
作業によっては、対象・操作・期間・宛先・件数や金額の上限を明示した事前承認を使えます。その範囲をAI自身が拡張してよいことにはしません。権限外の依頼や不明な条件は停止し、担当へ戻します。
OWASPは影響の大きい操作で人の承認を求め、利用者の権限と下流システムの認可も扱います。すべての操作で同じ承認手順を使う、という一律の規則ではありません。組織の方針と影響に応じ、誰がどの操作を許可したかを具体化します。
要確認タグは、根拠の照合を助ける印
AIには、不明点を推測で埋めず、確認が必要な箇所を示すよう指示できます。タグを付け忘れる可能性もあるため、重要な主張はタグの有無にかかわらず確認します。
表が収まらない場合は、横にスクロールできます
| 印の例 | 確認して残すもの |
|---|---|
| 【要確認：価格／条件】 | 正式な条件、対象、参照日 |
| 【要確認：規約／専門判断】 | 該当文書と必要な専門確認 |
| 【要確認：数値／出典】 | 一次資料、分母・単位・期間、計算 |
| 【要確認：固有名詞／公開可否】 | 公開権限と含められる情報 |
| 【要確認：最新性】 | 公開・更新日と適用される版 |
作成・照合・編集・確定の役割を決める
表が収まらない場合は、横にスクロールできます
| 役割 | 担当すること |
|---|---|
| Owner | 任せる範囲と必要な確認を決め、確定や公開の判断を担う |
| Fact-check | 価格・条件・数値・出典を正式な情報と照合する |
| Editor | 読者に必要な説明、構造、表現と図の整合を確認する |
| AI | 許可された範囲で候補や下書きを作り、不明点を示す |
これは小さな役割分担表で、完全なRACI表ではありません。一人で兼ねる場合も工程と記録を分けられますが、自己確認を独立レビューとは呼びません。確認できない重要事項は、必要な専門家や別担当へ回します。
二段階生成の前に、短い依頼書を作る
文章業務なら、設計を先に確認し、その条件で下書きを作る方法があります。次の表は料金案内の架空例です。
表が収まらない場合は、横にスクロールできます
| 依頼書の項目 | 記入例 |
|---|---|
| 目的・読者 | 初めて利用する人向けに、料金の適用条件を説明する |
| 参照先 | 指定した公開料金案内、確認日、例外の該当箇所 |
| 許可する作業 | 見出し案、要約、作業用原稿への保存 |
| 含めない操作 | 料金の決定、公式資料の更新、送信・公開 |
| 不明点 | 【要確認】を残し、重要な条件を補って断定しない |
| 担当・停止 | Ownerと照合担当を指定し、資料の矛盾や範囲外依頼なら止める |
第一段階は、前提・見出し・必要な情報・質問を作ります。第二段階は、確認した設計に沿う下書きです。その後に根拠の照合、編集、確定と公開の判断が残ります。二段階に分けただけで、誤りがなくなるわけではありません。
止め方と、戻せない影響を残す
範囲外の操作、重要な資料の矛盾、必要な承認の不足を検知したら、誰へ戻すかを決めます。ログや監視は原因を調べる材料であり、権限の制限そのものではありません。
復元できるファイルと、送信・開示・公開によって残る影響を区別します。停止、回復、関係者への対応を設計し、「元に戻せるから許可してよい」と短絡しません。
一つの仕事から依頼書と権限表を作り、資料と指示の設計、AIレビューの設計、文章品質管理、例外集の作り方につなげて、任せる条件を見直してください。