本文へ移動

生成AIを使った顧客納品の確認|担当者が残す根拠と承認記録

生成AIを使った顧客納品の確認方法を、顧客固有条件・数字・権利・修正経緯の判断表で整理。担当者が残す根拠と承認記録、差戻し条件を具体化し、納品可否を印象で決めない実務手順を示します。

執筆
cotomu AI顧問 編集部

監修
岩崎 裕馬

編集方針

生成AIを使った顧客納品の確認は、顧客固有条件、数字・出典、第三者の権利、修正経緯の四区分で行います。各区分を「承認」「条件付き承認」「差戻し」で判定し、何を見て、何が見つかり、誰が承認したかを成果物にひも付けて残します。四区分の停止条件がすべて解消し、最終承認まで追える状態が納品可です。

四つの区分では、見る根拠も判断を引き上げる相手も異なります。契約や依頼内容との一致は依頼書や合意記録、数字は元資料、素材は利用条件、修正経緯は版ごとの差分が主な確認先です。不明点の照会先も、顧客窓口、数字の管理部門、法務などに分かれます。確認項目を増やすより先に、区分ごとの通過条件と停止条件をどう定めればよいでしょうか。

生成AIによる顧客納品の確認を四つに分ける

以下の判断表は、NISTの一般原則を個別成果物へ応用した実務上の提案です。NIST所定の分類や義務ではないため、自社の契約、規程、承認権限に合わせて調整します。

表: 確認区分、確認対象、承認、条件付き承認
確認区分確認対象承認条件付き承認差戻し
顧客固有条件依頼目的、納品形式、対象読者、禁止事項、顧客指定の表現・資料指定条件との一致を根拠とともに確認できる未反映事項があるが、納品前に誰が何を直すか確定している目的や必須条件との不一致が残る、または判断に必要な条件が不明
数字・出典元資料の該当箇所、対象期間、単位、定義、対象範囲各数字を元資料までたどり、文中の意味と一致すると確認できる表記修正など残作業と再確認者が確定している元資料へ到達できない、または期間・単位・定義・範囲のいずれかを確認できない
第三者の権利文章、画像、図表、データの出所と利用条件出所と利用条件を確認し、社内手続上の確認が完了している未解消事項を法務などへ回し、納品を止める範囲が明確出所不明、利用条件不明、または権利上の懸念が未解消
修正経緯発見事項、修正内容、再確認結果、担当者、承認者差戻しから最終版までの変更と承認を追える記録の追記責任者と完了条件が確定している何を直したか、誰が再確認したか、最終判断が追えない

「条件付き承認」は、残作業、担当者、再確認の要否、納品を止める条件が明らかな状態に限ります。この判定は工程内の進行を認めるもので、顧客への納品許可とは分けて扱います。納品時点で停止条件が残っていれば差戻しです。

この判断表を使う前に、対象成果物の版を固定します。ファイル名に加え、更新日時や社内の版番号など、確認対象を一意に識別できる情報を記録します。表の各行には、少なくとも「確認対象」「参照した根拠」「発見事項」「修正内容」「確認担当者」「承認者」「最終判断」をひも付けます。この記録項目も、履歴、監督、go/no-go判断の文書化というNISTの一般原則を個別納品へ応用した提案です。

顧客固有条件は依頼文の転記で終わらせない

最初の区分では、顧客の依頼を成果物の確認可能な条件へ置き換えます。「分かりやすく」「自社らしく」といった表現だけでは、担当者と承認者が同じ判断を再現できません。参照する依頼書、合意した対象読者、必須要素、避ける表現、納品形式を確認欄へ分けます。

2026年9月21日時点で、NIST AI RMF CoreのMAP 1.1は、意図した目的、文脈固有の法令・規範・期待、利用者とその期待、用途の前提・制約を理解し文書化することを示しています。MAP 1.6は、関係するAIアクターからシステム要求を引き出して理解することを示しています。

この原則を納品確認へ当てはめると、判定軸は「顧客と合意した条件に合うか」です。プロンプトへの一致は制作途中の確認にとどまり、納品条件への適合を示す根拠にはなりません。依頼条件そのものが曖昧なら、生成し直す前に顧客窓口または社内責任者へ確認します。出力の修正で埋められない不明点は、制作担当者の推測で確定させず、依頼条件へ戻して解消します。

社内で生成AIを使う前段の入力範囲、承認ツール、相談先が未整理なら、生成AIの社内ルール・利用ガイドラインの作り方【テンプレート付き】もあわせて確認してください。利用ルールは全社共通の使用条件を、個別成果物の判断表は案件ごとの納品可否を担います。

数字は元資料まで戻って確認する

数字の欄では、元資料の該当箇所、対象期間、単位、定義、対象範囲を確認できたものだけを承認候補にします。生成AIの回答は、元資料に到達するまで根拠として扱いません。文章として自然でも、どの期間の何を表す数字か確認できなければ差戻しです。

2026年9月21日時点で、NISTのGenerative AI ProfileにあるMS-2.5-003は、導入前のリスク測定と継続的モニタリングにおいて、生成AI出力の情報源と引用をレビューし検証することを提案しています。この考え方に沿い、確認記録には数字、元資料名と該当箇所、文中での使い方を一組で残します。

たとえば、元資料は確認できても対象期間が成果物の記述と異なる場合、出典URLの存在だけでは承認条件を満たしません。定義が一致しない場合も同じです。表記の統一だけが残り、修正担当者と再確認者が決まっている場合は条件付き承認にできます。判定を分けるのは、成果物の主張と根拠の対応関係です。

権利確認は納品前スクリーニングとして扱う

第三者素材の欄では、文章、画像、図表、データごとに出所と利用条件を確認します。確認できない素材があれば差し替えるか、未解消事項として法務など適切な担当へ引き上げます。この欄は納品前のスクリーニングであり、個別成果物の法的適法性を保証するものではありません。

2026年9月21日時点で、NISTのGenerative AI ProfileにあるMAP 4.1は、第三者の知的財産その他の権利を侵害するリスクを含む、技術・法的リスクの把握と文書化を扱っています。同資料のMP-4.1-002は潜在的な知的財産権侵害の申立てなどに対応するプロセスを、MP-4.1-006は第三者の知的財産と学習データの利用・保存・保護を定める方針と実務を提案しています。

したがって、「AIで生成したから権利確認済み」という判定は置きません。使用した第三者素材・データを特定できない、利用条件を確認できない、判断権限が担当者にない、のいずれかなら承認者へ回さず、差替えまたは専門担当への確認を先に行います。法務確認が必要な範囲は、顧客との契約や自社規程に沿って別途定めます。

修正経緯と承認記録を一つの流れにする

差戻しが起きたら、旧版の判定を残したうえで、発見事項、修正内容、再確認結果をつなげます。承認者は最終版と変更の履歴を照合し、未解消だった点と、解消を判断した根拠を確認します。

2026年9月21日時点で、NIST AI RMF PlaybookのMEASURE 2.8は、履歴や監査ログを保持してエラーなどの原因をレビューできるようにすること、人による監督の程度、利用者による上書き、報告された誤りや苦情と対応を記録すること、責任者によるgo/no-go判断を文書化することを提案しています。またGenerative AI ProfileのGV-1.5-003は、生成AIに関する試験・評価・妥当性確認・検証と、デジタルコンテンツ透明性手法の履歴を保持する文書保存方針を提案しています。

実務記録は、次の順に読めれば十分です。

  • 確認対象:どの成果物のどの版を見たか
  • 参照した根拠:依頼書、元資料、利用条件など何を見たか
  • 発見事項:どの条件と合わなかったか、何が不明だったか
  • 修正内容:どこをどう変更したか
  • 再確認:誰がどの根拠で解消を確認したか
  • 最終判断:誰が承認、条件付き承認、差戻しを決めたか

完成条件は、後から「なぜ納品可としたか」を成果物と根拠までたどって説明できる状態です。空欄を埋めるだけで終えず、記録の保存場所、閲覧権限、保存期間も自社の既存規程と顧客との合意に合わせて決めます。

自社で運用を始めるための条件

運用開始前に、四つの区分それぞれについて確認担当者、承認者、差戻し条件、専門担当へ引き上げる条件を決めます。一人が制作と確認を兼ねる場合も、最終判断者と根拠の置き場所は明示します。まず対象業務を限定し、実際に出た差戻し理由を確認項目へ反映してから適用範囲を広げます。対象業務の決め方から整理する場合は、AI導入は何から始めるべきか|中小企業の最初の90日が参考になります。

納品可否は、四つの区分のうち最も弱い判定に合わせます。顧客固有条件と修正経緯が承認でも、数字の元資料を確認できなければ差戻しです。権利上の未解消事項があり、専門担当の判断を要するなら納品を止めます。これにより、全体の印象が個別の停止条件を覆うことを避けられます。

生成AIを使った顧客納品の確認では、生成AIらしさの有無より、顧客固有条件との一致、数字を支える元資料、第三者素材の出所と利用条件、差戻しから承認までの経緯を判定します。通過条件は、四区分の根拠がそろい、停止条件が解消し、承認者の最終判断まで追えることです。いずれかが差戻しなら全体も差戻しとします。この基準を自社の「納品可」の定義にしてください。