自分で読むぶんには問題なくても、他人に渡した瞬間に性質が変わる。
送る前に見ておくべき点を整理します。
責任が移る
いちばん大きい変化がこれです。
自分で見ているうちは、間違いがあっても自分で気づける。転送すると、受け取った側はそれを情報として扱います。誰が書いたかにかかわらず、送った人の発言になる。
「AIが言っていた」は、実務では言い訳にならない。出典を確かめずに転送した責任は残ります。
文脈が抜ける
回答は、そこまでの会話を前提にしています。
何を聞いたか。どんな資料を渡したか。どんな条件を伝えたか。それらを知らない人が読むと、一般論として受け取られます。
「この条件下ではこうなる」という答えが、無条件の結論として伝わることがある。転送するなら、前提も一緒に書き添えたい。
一行で足ります。「A社の条件で、9月時点の資料をもとに聞いた結果」と書いておけば、読む側は範囲を誤りません。
送る前に見る4点
| 見るもの | なぜ |
|---|---|
| 数字と日付 | 桁のずれや年度の違いは読んで気づけない |
| 出典 | 存在しない資料が挙がっていることがある |
| 固有名詞 | 社名や人名の表記が変わっていることがある |
| 断定の強さ | 推測が事実として書かれていないか |
4番目が見落とされやすい。確信がないときに黙るより推測したほうが有利になる構造があるので、断定の形で書かれていても根拠があるとは限らないからです。
「〜とされています」「〜が一般的です」という言い方には特に注意したい。誰がそうしているのか、どこにそう書いてあるのか。それが言えないなら、その一文は削るか、確かめてから送る。
自分の言葉に直す
そのまま貼るより、要点を自分で書き直すほうが安全です。
書き直す過程で、理解していない部分に気づく。自分の言葉にできない箇所は、実は分かっていない箇所だからです。
全部を書き直す必要はありません。結論と、その根拠だけでも自分の文にしておけば、質問されたときに答えられる。
逆にいえば、質問されて答えられない文は、まだ送る段階にない。この基準はかなり使えます。
開示すべきか
AIを使ったことを伝えるべきか、という問いがあります。
検索大手が公開しているガイダンスでは、「これはどう作られたのか」と読み手が思いそうな場合に開示するのが有益だとされています。全部に定型文を入れる話ではないようです。
実務的には、作り方より「どこまで自分が確かめたか」を書くほうが役に立つ。数値の出どころ、確認した日付、参照した資料。これが書いてあれば、受け取る側も扱い方を判断できます。
社外に出すとき
取引先や顧客に渡すものは、扱いを一段厳しくします。
提案書に書いた内容は、後から契約の解釈に影響することがある。約束していない条件が紛れていないか、必ず確かめたい。
生成した画像や文章を納品物に含めるなら、使ったサービスの規約も確認が要ります。権利の帰属や商用利用の条件は、サービスによって違うからです。
見積もりの数字を含む文書なら、なおさら。桁がひとつ違うだけで、後から取り消せない話になる。
社内で共有する場合
うまくいった回答を共有するのは、社内の学習になります。
そのとき、回答だけでなく指示も一緒に渡すと再現できる。「この文をコピーして、資料を貼るだけ」という形にすると、相手も試しやすい。
ただし指示文に社内の事情や取引先の名前が入っていないか、貼る前に読み返してください。共有した瞬間に、そこに書いたものまで一緒に渡ることになる。
グループチャットは特に注意
個人あてに送るのと、複数人が見る場に貼るのとでは、影響の範囲が違います。
グループに貼られた文は、その場の共通認識になりやすい。誰も出典を確かめないまま、次の会議の資料に引用されることがあります。一度そうなると、どこから来た数字なのか追えなくなる。
対処は単純です。貼るときに「未確認」と一言添える。確かめたなら、確かめた範囲を書く。それだけで、受け取る側の扱いが変わります。
相手が社外の人を含むチャットなら、社内向けの表現が混ざっていないかも見ておきたい。内輪の言い回しは、外から見ると別の意味に読めることがある。
まとめ
転送は、送信ボタンを押す作業に見えて、実際には責任を引き受ける作業です。
数字、出典、固有名詞、断定の強さ。この4点を見るだけなら1分もかかりません。1分で防げる事故は、防いでおいたほうがいい。
出典
推測が起きやすい理由と、開示についての指針は、下記に基づきます。
