AIの出力は誰が承認するか|用途別に確認の深さを決める
AI出力の承認は、内部メモ・顧客説明・実行指示を分け、用途ごとに最終責任者と確認資料を定めます。転用時の再承認条件まで判断表で整理し、迷わず運用できる状態を具体化します。
AI出力の承認は、用途ごとに最終判断者を分けます。内部メモは業務担当者、顧客説明は説明内容を所管する業務責任者、実行指示は対象業務の実行権限を持つ責任者が担います。出力が使われる場面に承認責任を結び付けるのが基本です。
確認資料の深さも用途に応じて変えます。内部メモなら目的・参照元・前提と限界、顧客説明なら主張ごとの根拠と確認記録、実行指示なら対象・範囲・権限・実行前条件まで必要です。内部メモを経営判断や社外説明へ転用する時点では、用途に合う再承認へ切り替えます。その開始条件まで決めて、初めて運用できます。
AI出力の承認は「誰が作ったか」より「何に使うか」で分ける
AIが文章を生成したという理由だけで、確認の深さは決まりません。同じ要約文でも、担当者が論点を拾うために読む場合と、顧客へ回答する場合では、誤りが及ぶ相手も、その後に起きる行為も異なります。さらに、設備変更や発注などの実行につながる指示では、文章の正しさに加えて、実行する権限と条件の確認が要ります。
2026年9月21日時点で確認したNISTのAI RMF Playbook: Governは、組織のリスク許容度に基づいて必要なリスク管理活動の水準を決め、潜在的な影響と発生可能性を理解・測定する仕組みや、共通のリスク尺度を方針化することを提案しています。また、AIリスクの把握・測定・管理に関する役割、責任、連絡経路を組織全体で明確に文書化するよう示しています。
したがって、承認フローは「誰に届き、何の判断または行為を生むか」から組み立てます。作成者、根拠確認者、専門確認者、最終承認者を分け、誰へ連絡するか、どこまで委任できるかも記録します。NISTは個別企業に所定の承認手順を課していません。ここで採用するのは、その一般原則を自社運用へ置き換える考え方です。
用途別の承認責任と確認資料を決める判断表
次の判断表は、NISTの一般原則を基にした実務上の提案であり、原典所定の分類や義務ではありません。会社の業種、契約、既存の職務権限、扱う情報に合わせて役職名と条件を置き換えてください。
| 用途 | 主な状態 | 根拠確認 | 必要に応じる専門確認 | 最終承認 | 承認時に残す資料 | 上位区分へ切り替える条件 |
|---|---|---|---|---|---|---|
| 内部メモ | 担当者の検討材料で、社外送付や実行の根拠にしない | 作成した業務担当者 | 内容を判断できない領域の担当者 | 業務担当者。意思決定へ転用する場合は責任者 | 目的、参照元、前提と限界 | 経営・業務判断の根拠にする、社外へ示す、実行を指示する |
| 顧客説明 | 顧客へ事実、方針、提案などを伝える | 作成者とは別に、主張と参照元を照合できる担当者 | 契約、法令、専門領域に触れる場合の法務・コンプライアンス・専門担当 | 説明内容を所管する業務責任者 | 目的、参照元、前提と限界、主張ごとの根拠、ファクトチェック記録、想定影響 | 説明が契約変更や業務実行の指示を伴う |
| 実行指示 | 人やシステムが出力を受け、業務上の行為へ移す | 運用担当者が対象と条件を照合 | 対象業務に必要な専門担当 | 対象業務の実行権限を持つ責任者 | 顧客説明の項目に加え、対象、範囲、実行権限、実行前条件、監視条件、変更条件 | 権限外、条件不足、対象や影響範囲が不明なら実行を止めて差し戻す |
この表では、文章に「低・中・高」と抽象的な評価を付ける方法から一歩進め、用途ごとに責任者と証拠を対応させています。AI推進担当者が担うのは、区分、記録欄、差し戻し条件の整備です。各部門の責任者は、自分がもともと持つ説明責任や実行権限の範囲で最終判断します。
内部メモは「転用しない」条件まで書く
内部メモでは、業務担当者が目的に照らして参照元を確かめ、前提と限界を併記します。たとえば、資料の論点整理に使うメモなら、参照した資料と、確認できていない箇所が分かる状態にします。この段階では、担当者自身の検討材料に限定することが承認条件です。
迷いやすいのは、読みやすく整ったメモを、そのまま会議の結論や顧客向け資料へ移す場面です。見た目が完成していても用途は変わっています。意思決定の根拠にするなら業務責任者へ、社外へ示すなら顧客説明の承認へ、実行を促すなら実行指示の承認へ切り替えます。「内部利用」という当初のラベルより、実際の使われ方を優先して再判定します。
区分や相談先を社内ルールへ落とす際は、生成AIの社内ルール・利用ガイドラインの作り方【テンプレート付き】も参考になります。入力時のルールとは別に、出力後の転用条件と連絡先を追記すると、承認表と利用ルールを接続できます。
顧客説明は主張単位で根拠を確認する
顧客説明の承認では、文章全体の自然さに加えて、どの主張がどの参照元に基づくかを対応させ、確認した記録を残します。2024年7月26日公表、2026年9月21日時点で確認したNISTの生成AIプロファイルは、生成AI出力の正確性・品質・信頼性・真正性について、既知の正解データとの比較、人による監督、入力内容の確認などで評価することを提案しています。情報源が複数または不明な場合には、正確性と真実性を検証するファクトチェック手法の導入・文書化も挙げています。
そこで承認資料には、目的、参照元、前提と限界に加え、主張ごとの根拠、誰が何を照合したか、顧客への想定影響を含めます。契約、法令、業界固有の専門判断に触れる場合は、該当する専門担当、法務、コンプライアンスへ確認を回します。追加確認の要否は、その案件が触れている論点で決めます。法務などの個別判断は、該当する専門家へ委ねる必要があります。
最終承認は、説明内容を所管する業務責任者が担います。AI推進担当者が文章生成の運用に詳しくても、顧客へ何を約束できるかを決める職務権限まで自動的に得るわけではないからです。既存の業務上の承認責任へ、AI出力の根拠確認記録を渡す形にします。
実行指示は文章確認と実行権限を分ける
実行指示では、出力内容がもっともらしいことと、その行為を実施してよいことを分けます。運用担当者は対象、範囲、実行前条件を照合し、対象業務の実行権限を持つ責任者が最終承認します。専門的な成立条件がある場合は、その領域の担当者による確認も加えます。
残す資料は、目的、参照元、前提と限界、主張ごとの根拠に加え、次の項目です。
- 対象と範囲:何に対する指示で、何を対象外とするか
- 実行権限:誰の権限で実行し、誰が最終判断したか
- 実行前条件:開始前に満たすべき確認事項は何か
- 監視条件:実行後に何を見て継続可否を判断するか
- 変更条件:前提が変わったとき、誰へ戻して再承認するか
一つでも不明なら、差し戻しが必要です。対象や範囲を作成者の推測で補うと、責任の所在が曖昧になるためです。初期導入の対象業務と責任者を決める進め方は、AI導入は何から始めるべきか|中小企業の最初の90日と合わせて整理できます。
承認台帳に判断の証跡を残す
2026年9月21日時点のAI RMF Playbook: Governは、文書化方針の対象例として、担当者の連絡先、業務上の理由、範囲と用途、想定されるリスクと影響、前提と限界、出力データの説明、テスト・検証結果、依存関係、導入・監視・変更管理の計画などを挙げています。また、同日時点のAI RMF Playbook: Mapは、意図した目的、利用者、導入環境、運用要件、期待、潜在的影響、前提と限界の理解と文書化を示しています。
この一般原則を基に、台帳には少なくとも「用途区分」「作成者」「根拠確認者」「専門確認者」「最終承認者」「参照元」「前提と限界」「転用先」「差し戻し理由」を置く方法が考えられます。原典には所定の様式や義務はありません。ここで挙げた項目は、記事が提案する実務上の方法です。台帳に判断の経路を残せば、誰が何を根拠に承認したか、用途変更時にどこへ戻すかを追跡できます。
生成AIについては、機会・リスク・長期的性能が十分に理解されていないことや、人の受け止め方・行動が多様であることから、NISTの生成AIプロファイルは、異なる水準の監督や追加の人手レビュー、追跡、文書化、経営上の監督が妥当な場合があるとしています。用途、影響、前提が変わった案件を見つけるたびに、必要な確認者と資料を見直す根拠になります。
自社で決めるべき条件
役職名の一覧を作るより先に、内部メモ、顧客説明、実行指示について、それぞれ「誰が最終判断できるか」「何を見れば判断できるか」「どの変化で上位区分へ移すか」を一組で定めます。
内部メモは担当者の検討内にとどまる限り担当者が確認し、意思決定へ使う時点で責任者へ上げる。顧客説明は主張単位の根拠を揃え、説明内容の所管責任者が承認する。実行指示は対象、範囲、権限、実行前条件まで確認し、実行権限者が承認する。この境界により、承認責任を用途ごとに分担しながら、必要な確認の深さを保てます。
まず実際の出力を三用途へ仮置きし、判断表で担当者と資料が空欄になる箇所を探してください。その空欄こそ、会社として責任と運用条件を決める場所です。