AIチャットボットの回答を公開前に誰が見るか — 小さな会社の“承認メモ”

「FAQを直しました。もう公開して大丈夫ですよね」。小さな会社では、この一言で更新が外に出ます。

直した本人は正しいつもりです。それでも、旧料金が残った1行や、言い切りすぎた納期の説明が、そのままお客様の画面に出ます。

直した回答を外に出す前に、誰が、どこを見て、OKを出すのでしょうか。

直した人が、そのままOKを出していないか

改善依頼を受け、直す先を決め、資料を更新する。ここまでは回せる会社が増えました。抜けやすいのは、「これを出していいか」を決める工程です。

直した人は、直した箇所を中心に読みます。自分の変更は正しい前提で見るので、隣の行に残った古い金額に気づきにくくなります。能力ではなく、視点の話です。

NIST AI Risk Management Frameworkは、AIのリスクを一度で終わらせず、継続的に見て、測り、管理する考え方を示しています。承認は、その「見る」を公開の直前に1回だけ置く作業です。

改善依頼をどう受けるかは改善受付メモで扱いました。この記事は、その修正を外に出す直前の話です。

公開前のテストと承認は、別の作業です

Microsoftの公式ドキュメントでも、エージェントをテストする手順と、公開してチャネルへ展開する手順は別々に案内されています。

テストは「動くか」を見る作業です。承認は「出していいか」を決める作業です。会社の名前でこの文章を出すのか、という判断が入ります。

小さな会社なら、テスト5問、承認1人で始められます。公開前のテスト質問表を作ってあるなら、その5問を通したあとに、承認の1手だけ足す形になります。

承認メモは6項目でいい

承認と聞くと、申請書と押印を思い浮かべるかもしれません。小さな会社では、1件につき1行、6項目で足ります。

日付、変更した回答、確認者、見た項目、判定、再テスト日。この6つです。列を増やすほど、誰も書かなくなります。

たとえば、こう書きます。「9/1／『土曜も当日予約できますか』の回答／店長／事実・範囲／OK／9/8に再テスト」。これで、来月「なぜこの回答なのか」と聞かれても答えられます。

4項目めは、確認の手抜きを責めるためではありません。事実だけ見て言い方を見ていない日が続いたら、そこが弱点だと分かる材料です。

「保留」と「戻す」の条件を先に決めておく

判定はOKと保留の2択にします。差し戻し、要修正、条件付き承認と増やすと、判定そのもので迷う時間が生まれます。

保留にしたら、理由を1行だけ書きます。「料金の根拠になるPDFが去年の版だった」「納期を言い切っている」。この程度で十分です。書いた本人が直すとは限らないので、次の人が読める言葉にします。

合わせて、出したあとに戻す条件も決めます。変更履歴メモの「戻す条件」列と同じ考え方を、公開の手前に持ってくるだけです。

小さな会社では、確認者が外出していて夕方まで連絡がつかない日が普通にあります。だからこそ「確認者が捕まらない日は公開しない」まで先に決めておくと、当日に判断を迫られません。

もうひとつ、承認の場で1回だけ聞くことがあります。「この回答文は、どこから来たか」です。OWASPのGen AI Security Projectが整理しているリスクには、外部からの入力が意図しない挙動につながるPrompt Injectionが含まれます。お客様の会話ログから拾った文を、確認せずにそのまま登録しない。承認の1手が、その歯止めになります。

誰を確認者にするか — 最初は1人でいい

確認者は役職で決めなくて構いません。基準は、料金と契約条件をお客様に説明できる人かどうかです。

最初から2人体制にすると、たいてい止まります。「もう1人が見ているはず」と思うからです。1人を決めて、その人が不在のときの代理を1人だけ書いておく。この形が、いちばん続きます。

確認が要る範囲もはっきりさせます。外部に出る回答、料金、契約条件、納期、個別判断。この5つは人が見ます。社内向けの言い換えや、営業時間の表記ゆれの修正まで承認にかけると、回らなくなります。

PromnyAIなら、どこを見て承認するのか

PromnyAIでは、自社情報をAI学習データに登録します。カテゴリはサービス、ブログ、コンセプト、メンバー、その他の5つで、登録後は一覧が「学習中」から「学習完了」に変わります。承認メモの「変更した回答」欄には、このカテゴリ名か、元になったPDF・ページ名を書きます。

チームで使う場合の考え方は、マニュアルハブをチームで使うに書いています。管理者・更新担当・確認担当という役割の分け方と、外部に出す前の確認フローが4ステップで載っています。参照資料が最新か。数字や日付を原本と照合したか。お客様に送る文面を担当者か管理者が読み直したか。修正文を学習データへ戻したか。承認メモは、この4ステップを1行に写したものです。

生成履歴には、作成日時、コンテンツ種別、テーマ、本文が残ります。「その文章はいつの情報で作ったか」を確かめる材料になります。

承認の判定を自動で出す話ではありません。OKを出すのは人です。まずは今週直した1件について、6項目を埋め、確認者の名前を書きます。1件書ければ、2件目からは1分で終わります。

まとめ：公開の直前に、確認の1手を置く

• check_circle直した人が、そのままOKを出す形をやめます。
• check_circleテストは「動くか」、承認は「出していいか」。別の作業として分けます。
• check_circle承認メモは、日付・変更した回答・確認者・見た項目・判定・再テスト日の6項目にします。
• check_circle判定はOKか保留の2択。戻す条件は、出す前に書いておきます。
• check_circle確認者は1人と代理1人。料金・契約条件・納期・個別判断を範囲にします。

承認メモを置いても、事故がゼロになるわけではありません。それでも「誰が、何を見て、出すと決めたか」を説明できるかどうかの差は、あとから効きます。1行のメモは、その差の入口です。