こんにちは。バナナデスクです。
AIにメールを書いてもらい、文章はきれいに整った。でも、そのまま送ってよいかとなると手が止まる。確認する時間が長ければ、どこまで任せる意味があるのかも気になります。
ここで見るのは、文章の出来だけではありません。宛先は合っているか、料金は現在のものか、予約が確定していないのに「承りました」と書いていないか。下書きと実行では、確認する対象が増えます。
今回は、個人事業のブログ・メール・顧客対応で、AIへ任せる範囲と人が確認する場所を決める方法を整理します。特定ツールの自動化設定ではなく、仕事を分けるための設計例です。自動送信や自動公開を実施した検証結果ではありません。
作業を「材料・下書き・判断・実行」に分ける
「記事作成を任せる」と一括りにすると、資料集めから公開までが混ざります。私はまず、AIに触らせる具体物を書き出すことを勧めます。公開済み資料の要点を並べることと、本番サイトの記事を変更することは、同じ作業ではありません。
| 段階 | 扱うもの | 決めること |
|---|---|---|
| 材料 | 資料、問い合わせ、商品情報 | 何を渡してよいか。どの版を使うか |
| 下書き | 構成、返信案、比較案 | どこまで作り、何を不明として残すか |
| 判断 | 根拠、適用条件、送る相手 | 採用する人、確認する項目 |
| 実行 | 公開、送信、予約、更新 | 対象・内容・日時と、実行結果を確認する方法 |
下書きまでなら元に戻して作り直せる仕事でも、顧客への送信後は相手が読める状態になります。任せる範囲は、AIができる機能の数ではなく、間違ったときの影響、見つけやすさ、戻しやすさに合わせて決めます。
NISTのAI Risk Management Frameworkは、AIの設計・利用・評価へ信頼性を組み込み、組織の目的や優先事項に合うリスク管理を考えるための任意の枠組みです。以下の表は、そのように用途ごとに確認を考えるための本稿独自の運用例です。NISTが個人事業へこの手順を義務づけているという意味ではありません。
記事・メール・顧客対応で、確認箇所を変える
| 仕事 | AIへ任せる例 | 実行前に人が見るもの | 止める条件 |
|---|---|---|---|
| ブログ記事 | 確認済み資料から構成と本文案を作る | 主要な主張の根拠、具体例、公開先、予約日時、画像 | 体験の創作、根拠未確認の数値、資料を読めない |
| メール | 承認済み商品情報から案を作る | 宛先・配信対象、件名、料金、リンク、送信日時 | 存在しない期限、古い料金、対象者が未確定 |
| 顧客対応 | 質問を分け、確認済み部分だけ返信案を作る | 相手、質問の取りこぼし、契約範囲、予約・返金等の約束 | 未確認の割引・納期・対応可否を求められる |
この表を全部の文章に同じ重さで当てはめる必要はありません。誤字の修正と、サービス価格の変更では、見るべき人や根拠が違います。小さな修正は変更箇所を確かめ、約束が変わる修正は関連する条件まで読み直す、という差をつけます。
反対に、過去に似た文章を送ったことがあるからといって、新しい相手にも同じ条件が当てはまるとは限りません。実行対象の違いは毎回確認します。
ブログでは「正しい下書き」と「正しい公開」を別々に見る
次は架空の編集作業です。「無料相談の所要時間を30分から45分へ変更する記事」を作るとします。AIには新しい案内を渡したつもりでも、記事末尾だけ旧案内の30分が残ることがあります。本文中の時間を揃えるだけでなく、リンク先の案内と矛盾していないかも確認対象です。
記事の承認を「原稿第2版、無料相談45分、対象は初回利用者、公開先は対象記事、予約は指定日時」と記録すれば、何を確認したのかが残ります。別の記事へ貼り付けた、旧版を公開した、時刻の設定が違った、といった操作の問題も切り分けられます。
公開前に最新の原稿を取り直すことも大切です。自分が下書きを作っている間に別の人が訂正していたら、古い原稿の上書きでその訂正が消えます。差分がある場合は、どちらを残すか判断してから公開します。
原稿の直し方そのものは、AI記事がありきたりになるときの素材整理と編集例で説明しています。ここでは、その原稿がどの状態になったら公開へ進めるかを決めます。
メールでは、本文と配信対象を一組にする
説明用に、架空の講座の開催案内を考えます。申込済みの人には参加方法を送り、未申込の人には概要を送る運用です。本文が丁寧でも、参加URLを未申込の人へ送れば意図した配信になりません。
確認する欄を「本文」だけにせず、次のような実行票にします。値はすべて架空です。
| 項目 | 確認内容 |
|---|---|
| 目的 | 申込済みの参加者へ開催案内を送る |
| 配信対象 | 対象講座の受付が確定した人。取消済みを除く |
| 対象件数 | 抽出後に実件数を記録。予想で埋めない |
| 本文 | 確認した版を指定。日時・参加方法・問い合わせ先を照合 |
| リンク | 公開範囲と、受信者が開けるページかを確認 |
| 送信時刻 | 日付・時刻・タイムゾーンを確認 |
| 確認後の変更 | 対象または本文が変わったら、影響する欄を再確認 |
ここでAIへ「対象者を適当に絞って」と頼むことは避けます。受付状態を判断する正しい記録が必要です。実行票の記入を手伝わせる場合も、AIが見られないデータの件数や状態を推測させません。
送信ボタンを押した後も、受付された処理、失敗、実際の送信記録を区別します。処理を開始したことだけで全員へ届いたとは扱わず、利用する配信サービスの結果を確認してください。
顧客対応は「答えられる所」と「確認待ち」を分ける
「料金はいくらですか。明日対応できますか」という質問なら、公開料金は答えられても、明日の空きは確認が必要かもしれません。全体を保留にするか、すべて了承するかの二択にせず、分けて下書きします。
お問い合わせありがとうございます。料金は公開中の案内では33,000円（税込）です。明日の対応可否は日程の確認が必要なため、確認後にご案内します。現時点ではご予約は確定していません。
これは架空の料金を使った例文です。実際には最新の料金・対象サービス・返信予定を確認して置き換えます。「確認後に案内する」と書くなら、その確認を誰が行うかまで仕事として残してください。文章だけ丁寧にしても、確認が放置されれば対応は終わりません。
また、氏名を消せば必ず入力してよいわけではありません。契約、利用目的、入力する情報、AIサービス側の取扱いを確認します。個人情報保護委員会も生成AIサービスへ個人情報を入力する際の注意を示しています。参照：生成AIサービスの利用に関する注意喚起。
止める条件と、再開に必要な材料を書く
「問題があれば止める」では、何が問題か人によって違います。「料金資料が二つあり金額が違う」「送信対象の除外条件が不明」「予約表にアクセスできない」のように、観察できる状態で書きます。
| 止まった仕事 | 理由 | 再開に必要なこと |
|---|---|---|
| 料金案内の返信 | 公開ページと社内資料の金額が違う | 現在適用する料金を担当者が確認し、根拠の版を指定 |
| 開催案内の配信 | 取消済みを除いた対象一覧が未確定 | 対象一覧と件数を確認し、配信票へ記録 |
| 記事の予約公開 | 承認後に本文へ別の変更が入った | 最新版の差分を確認し、公開する版を確定 |
一人で運営していても、この記録は役立ちます。翌日に作業を再開するとき、どこまで確認したかを思い出す時間を減らせるからです。確認済みという印だけでなく、対象の版と日付を残します。
任せる範囲は、一度決めて終わりではありません。よく失敗する箇所は工程を分け、十分に確認しやすい箇所は手順を簡単にする。ただし、数回うまくいっただけで、異なる顧客や条件へ同じ範囲を広げないようにします。
まずは普段の仕事を一つ選び、「AIが完成させるもの」「自分が確かめるもの」「実行する対象」の3行を書いてみてください。確認が多すぎるなら、確認を省く前に、任せる仕事を小さく切る方が進めやすくなります。