「過去の見積書を参考に、AIに新しい見積書の下書きとメール文を作ってもらった。読んだ限りは問題ない。このまま送ってよいのだろうか」。AIを仕事で使い始めた経営者や、総務と営業を兼ねている担当者の方へ。

結論は三つです。「作る」と「送る」を別の仕事に分ける。AIには下書きまでを任せ、送るボタンは人が押します。送る前に見るのは四つ。宛先、金額、添付、そして誰がどの版を確認したか。これを短い確認票に残します。確認したあとに書き換えたら、前の確認は使いません。書き換えた版をもう一度見てから送ります。

この記事で使うHaruIroAIの記録は、自社ブログの公開で決めている承認の決まりと、説明用に作った小さなプログラムの結果です。見積メールを実際に送る実験をしたわけでも、お客様のもとで起きた事故の話でもありません。誤送信が何件起きるか、といった数字も書きません。

「作る」と「送る」は、別の仕事

AIが作るのは「下書き」です。下書きとは、まだ誰にも届いていない、直せる状態の文書のこと。気に入らなければ何度でも作り直せます。いっぽう「送信」は、相手に届いて、取り消せなくなる操作です。取り返しがつくかどうかで分けると、下書きはやり直せる仕事、送信は一度きりの仕事になります。

見積書とメール文をAIに作らせるときの役割分担を3つの箱で示した図。左はAIが下書きを作る箱で、過去の見積書を参考に見積書の案とメール文を作る、まだ誰にも届いていない直せる状態、やり直せる仕事と書く。中央は人が送る前に4つを見る箱で、宛先は依頼をくれた相手のアドレスと会社名か、金額は品目・数量・単価・合計・税を根拠と照らす、添付はファイルを開いてこの見積書か、誰がどの版を確認したかは名前・日時・版の目印を票に残す、と並べ、確認票に残すと添える。右は人が送る箱で、確認票に書いた版と同じものを送る、届いたあとは取り消せない、一度きりと書く。下の帯に、書き換えたら真ん中の確かめるへ戻る、確認はその版にだけ有効、と添える。
役割分担はHaruIroAIが勧める進め方で、架空の場面です。出典の公式ヘルプは、Microsoft サポート「Outlook で Copilot を使用してメール メッセージを下書きする」と Gmail ヘルプ「Gemini in Gmail でメールの下書きを作成する」。いずれも2026年9月15日に開いて転記しました。特定の製品の設定や、安全を保証する図ではありません。

市販のAIの説明書も、この分け方で書かれています。Microsoft の公式ヘルプは、Outlook で Copilot に下書きを作らせたあとの手順を「メッセージを確認します」「必要に応じて下書きを編集し、準備ができたら [送信] を選択します」と書いています。送る操作は、人が選ぶ手順として書かれているということです。Google の Gmail のヘルプは、Gemini の下書き機能に「Gemini 機能によって、不正確または不適切な情報が提案される場合があります」という注意を添えています。作った文をそのまま信じないでほしい、という前提が公式の注意書きにあります。

ただし、これは説明書に書かれた手順であって、「どの製品でも必ず人が送る」という保証ではありません。使っているAIや契約によって、送信まで自動でできる設定もあり得ます。いまの設定がどうなっているかは、あとの節で確かめ方を書きます。

「送信・公開・削除のように取り返しのつかない操作の直前に、人の確認を1か所だけ置く」という考え方は、AIに任せる範囲と人が確認する範囲の線引きで書きました。今回はその1か所で、何を見るかを具体的にします。

確認先:Microsoft サポート「Outlook で Copilot を使用してメール メッセージを下書きする」/Gmail ヘルプ「Gemini in Gmail でメールの下書きを作成する」。いずれも2026年9月15日に開いて転記

送る前に見るのは、四つだけ

見るものは四つに絞ります。項目を増やすほど確認が丁寧になるわけではなく、多すぎると流し読みになって「見たつもり」で通してしまうからです。これはHaruIroAIが承認の仕組みを作るときの考え方で、7月20日の記事でも同じことを書きました。

送る前に見る四つAIが作った見積書とメール文を、人が送る直前に見る項目。HaruIroAIが勧める最小の型

項目何と照らすか見るときの問い
宛先見積の依頼をくれた相手のメールアドレスと会社名参考にした過去の見積書の宛名や、別のお客様の名前が、下書きに残っていないか。宛先が複数なら、全員に見せてよい内容か
金額品目・数量・単価・合計・税の扱いを、根拠にした資料参考にした過去の見積書の金額が、そのまま使われていないか。合計は自分で計算し直したか。税込か税抜かが本文と見積書で揃っているか
添付添付するファイルを開いて、中身本文が正しくても、添付が古い版や別のお客様の資料になっていないか。ファイル名だけで判断せず、開いて1ページ目を見たか
誰が、どの版を確認したか確認した人の名前、日時、確認した版の目印(ファイル名の日付と版番号など)「見た」という記憶ではなく、「この版を見た」と分かる目印を残したか。確認した版の記録も忘れずに残したか

四つ目が見慣れないかもしれません。宛先・金額・添付は「中身」の確認で、四つ目は「確認そのもの」の記録です。なぜ必要かを、次の節で説明します。

書き換えたら、前の確認では足りない

確認は「その版」に対して行うものです。版とは、文書のある時点の状態のこと。金額を直した、添付を差し替えた、宛先を一人足した。どれも「書き換え」で、確認した版とは別の版になります。人の記憶では「さっき確認した」となりますが、確認したのは前の版です。書き換えた版は、まだ誰も見ていません。

確認したあとに数量を直したという架空の例を、左右2つの文書で比べた図。左は確認した版v1で、宛先はA社ご担当者、金額は合計120,000円税込、添付は見積_0916_v1.pdf、確認済みの印に担当者・9月16日10時05分・v1を見たと書く。中央に、数量を1つ直した、見積書を作り直しメール本文の合計も変えた、と矢印で示す。右は送ろうとしている版v2で、宛先は同じ、金額は合計132,000円税込に変わり、添付は見積_0916_v2.pdfに変わり、確認なし、さっき見たのはv1でv2は誰も見ていない、と書く。下の帯に、v2をもう一度見て確認票を書き直してから送る、HaruIroAI自身のブログ公開でも確認した版が変われば承認は失効する決まり、と添える。
架空の例です。宛先・金額・ファイル名・時刻は説明のために置いたもので、実在の取引や事故ではありません。「確認した版が変われば承認は失効する」はHaruIroAIの社内ルール(2026年8月14日更新の編集標準)の転記で、法令や製品の仕様ではありません。

HaruIroAIは、自社の公開でこの決まりを使っている

HaruIroAIは、自社ブログを公開するときにこの決まりを使っています。社内の編集標準(2026年7月16日発効、8月14日更新)には、本文と見た目を人に示して公開の直前に明示の承認を得ること、そして確認した版が変われば承認は失効することが書いてあります。承認は「この記事を公開してよい」ではなく、「この版を公開してよい」なのです。承認のあとに一行でも直したら、直した版を見せ直して、承認を取り直します。見積もりでも同じで、確認票に「どの版か」を残すのはこのためです。

この決まりは、AIの下書きをそのまま出さないためでもあります。AIが書いた記事を別のAIに検品させた記録に書いたとおり、2026年9月4日から10日に公開した7本は、初回の検品で7本とも止まりました。読んだ限りは問題なさそうな下書きでも、確かめると直す箇所が出る。それが自社の実数です。

決まりを作ったあとに、抜け道も見つけた

決まりを作れば済む話でもありませんでした。2026年7月22日の記事に書いたとおり、自社の承認の仕組みが、文面がまったく同じ依頼を「前回と同じ依頼」とみなして、前回の判断をそのまま返す場合があると分かりました。依頼した側は「今回も確認してもらえた」つもりでも、実際には一度目の判断が使い回されているだけ、ということが起こり得た。見つけた時点では直せておらず、その記事にもそう書いています。確認の仕組みは、作ったあとに「本当に毎回見ているか」を試す必要がある、という記録です。

受注の例でも、変更は人へ戻す

「変更」を別扱いにする考え方は、受注の例でも同じにしています。2026年9月13日、HaruIroAIが説明用に作った架空の注文6件を小さなプログラムで分けたところ、商品と単位が登録どおりの2件は転記候補になり、「既存注文を2ケースへ変更」を含む4件は確認待ちになりました。変更は新しい注文としては扱わず、「元の注文と変更内容を確認」する仕事として人に戻しています。これは決めたルールどおりに動いたことの確認で、AIの読み取り精度や本番の実績ではありません。分け方の全体はAIで自動化できる仕事・人が判断する仕事に書きました。

送る前の確認票(コピーして使う)

四つの項目と、版の目印を一枚にしました。紙でも、チャットの1行でも構いません。大事なのは、「確認した版」と「送る版」が同じだと分かる目印を残すことです。

確認票を開く(コピー可)
【AIが作った見積もり・送る前の確認票】

送る相手(会社名):
件名:

1. 宛先
   □ 依頼をくれた相手のアドレスと会社名と一致
   □ 参考にした過去の見積書の宛名・別のお客様の名前が残っていない
   □ 宛先が複数なら、全員に見せてよい内容
2. 金額
   □ 品目・数量・単価を、根拠の資料と照らした
   □ 合計を自分で計算し直した
   □ 税込/税抜が、本文と見積書で揃っている
3. 添付
   □ ファイルを開いて、1ページ目を見た
   □ 古い版・別のお客様の資料ではない
4. 誰が、どの版を確認したか
   確認した人:
   確認した日時:
   確認した版の目印(ファイル名の日付と版番号など):

送る版の目印:            ← 4 と同じであることを確かめてから送る
送る人・送った日時:

決めごと
・確認したあとに一文字でも書き換えたら、この票を書き直す(前の票は使わない)
・「送る版の目印」が 4 と違うなら、送らない

版の目印の付け方は、単純なもので足ります。見積書のファイル名に日付と版番号を入れる(例:見積_2026-09-16_v2.pdf)。書き換えたら番号を上げ、上げた番号の版をもう一度見る。メール本文には版番号を付けにくいので、確認したあとは本文を触らない、触ったらもう一度見る、と決めます。

この票は社内用です。お客様に見せる必要も、当社へ送る必要もありません。お客様の名前や金額を、確認のために別のAIやチャットへ貼り付けないようにしてください。

使っているAIに、送る力があるかを確かめる

ここまでの確認票は、「送るボタンは人が押す」ことが前提です。その前提が本当に成り立っているかは、製品と契約で違います。「送らないでと頼んであるだけ」なのか、「設定でも送信できないようにしてある」のかを、設定した担当者に聞いてください。聞き方は、会社の資料、AIにどこまで見せていい?の確認メモに、読む・書き換える・送るの三つの許可として置きました。

送信まで自動でできる仕組みを使う場合は、この記事の確認票を「送信の直前に、人が埋めないと送れない」形で仕組みに組み込みます。自動で送ったあとに票を埋めるのでは、止める仕組みになりません。これはHaruIroAIの考え方で、どの製品でそれができるかは、製品ごとに確かめる必要があります。

この記事で書いていないこと

  • 特定の製品で、送信を止める設定の手順。製品と契約で異なるため、設定した担当者と公式の説明で確かめてください。
  • 誤送信が何件起きるか、原因の何割が宛先の間違いか。自社に記録が無く、検索で見えた数字は製品を売る会社の記事だったので使っていません。
  • 間違って送ったあとの法律上の手続き。今回は一次資料に当たっていません。
  • 7月22日に見つけた承認の使い回しが、その後どう直ったか。この記事では確認していません。

HaruIroAIはこう考える

下書きは任せ、送るのは人。確認は、送信の直前の1か所に絞ります。あちこちに確認を置くと、一つひとつが雑になるからです。

確認は「この版」に付ける。書き換えたら前の確認は捨てて、書き換えた版を見ます。自社のブログ公開でも、版が変われば承認は失効する決まりにしています。

仕組みは、作ったあとに試す。「毎回見ている」つもりの仕組みが、前回の判断を使い回していたことが、自社にもありました。同じ依頼を時間を空けて2回出し、2回とも新しく確認が来るかを確かめます。

「うちの見積もりの流れなら、どこで人が確認するか」。受注から送信までの流れを書き出し、人が確認する場面と、AIや自動処理に任せる場面を分けるところから必要なら、はるいろAI活用支援で一緒に決めます。初回30分の無料相談で、今の流れと次に確かめることを整理できます。

公式情報の確認日:2026年9月16日。製品の名称や手順は変更されることがあります。

この記事の作り方

Microsoft サポートと Gmail ヘルプの公式ページを2026年9月15日に開いて転記し、「」内は逐語で引用しました。HaruIroAIの記録は、社内の編集標準(2026年8月14日更新)、2026年7月22日と9月11日の公開記事、2026年9月13日に実行した説明用プログラムの結果からの転記です。見積メールを実際に送る実験は行っておらず、お客様の事故や実データも使っていません。図の宛先・金額・ファイル名は架空です。