問い合わせ返信テンプレを、自己流から卒業する

発送遅延_修正版_最新（2）.docx

このファイル名を自分でつけた記憶はない。気づいたら、そうなっていた。同じフォルダに、同じ接頭辞のファイルがあと5本ある。

問い合わせ返信テンプレは「1つの完成形」で持つと、状況が増えるたびに破綻する。骨格（型）と状況別の言い回し（差分）を分けて管理し、差分の量産だけをAIに任せると崩れない。金額・規約・返品可否といった事実は、人が確定した文言をAIに渡す。

• テンプレは「型＋差分」で分離管理する。1本の完成形として持つと、状況が増えるたびに複製が増えて破綻する
• AIが向くのは差分（状況別の言い回し・トーン調整）の量産であって、事実をゼロから作らせる用途ではない
• 金額・返品条件・規約などの事実は、人が確定した文言をAIに渡す。AIの役目は整形と量産に限定する

なぜ「テンプレの使い回し」は状況が増えるほど破綻するのか

問い合わせ返信のテンプレが崩れていく過程には、だいたい同じ順序がある。最初は3〜4本で足りている。「発送遅延」「返品・交換」「欠品」「在庫の入荷時期」あたりだ。ところが運用して半年もすると、フォルダの中はこうなっている。

• 発送遅延.docx
• 発送遅延_セール時.docx
• 発送遅延_メーカー取り寄せ.docx
• 発送遅延_沖縄離島.docx
• 発送遅延_修正版_最新.docx
• 発送遅延_修正版_最新（2）.docx

ファイル名の末尾で世代管理が始まった時点で、そのテンプレ群はもう管理されていない。どれが最新かを毎回目で判断しているからだ。繁忙期になれば、その目視判断が最初に飛ぶ。

ここで起きているのは「テンプレが足りない」問題ではない。完成形を丸ごと複製して増やしているという構造の問題である。発送遅延の返信文には、状況が変わっても動かない部分がある。お詫びの一文、注文番号の提示、現在の状況説明、次のアクションと期日、こちらの連絡先。動くのは「なぜ遅れたか」と「いつ出荷できるか」の2箇所だけだ。それなのに、動かない部分まで含めて丸ごとコピーするから、お詫びの言い回しを1回直したいだけで6ファイルを開く羽目になる。差分がN個あればテンプレはN本に増え、共通部分の修正コストもN倍になる。これが破綻の正体だ。

保管場所と送信チャネルが分断している

もう一つの破綻要因は、テンプレの置き場と実際に送る画面が別々にあることだ。多くの現場では、返信は楽天RMSの「R-Messe（アールメッセ）」、Amazonセラーセントラルの購入者からのメッセージ、Shopify Inbox、自社フォームからのメール転送と、窓口が3つも4つもある。しかしテンプレ本体は個人PCのフォルダか、共有ドライブか、Slackのピン留めにある。つまり選ぶ場所と送る場所がつながっていない。だから運用は必ず「別ウィンドウで開く→コピー→貼り付け→可変情報を手打ち」になる。

手打ちが入る以上、事故は確率の問題になる。前の顧客の注文番号が残ったまま送信される、金額だけ差し替えて発送予定日が前のまま残る、返品送料の負担者が旧ルールのままになっている。どれも「気をつける」で防げたことがない類のミスだ。お買い物マラソンやスーパーSALEの直後、問い合わせが平時の数倍に膨らんでいる日ほど起きる。

チャネルごとにトーンが揃わない

同じ「発送遅延」でも、モールのメッセージ機能と自社サイトのメールでは文面が別々に育っていることが多い。片方だけを直したまま、もう片方が3年前の文面で止まっている。レビューや評価で温度差が可視化されるのはたいていこの状態のときだ。「サイトでは丁寧なのに、モールでは事務的」という印象は、こういう分断から生まれる。

さらに、担当者が退職・異動すると、テンプレの所在自体が引き継がれずに作り直しになりやすい。テンプレは業務ナレッジのはずなのに、ファイルの置き場が個人に紐づいているせいで属人化する。これは文章力の問題でも、真面目さの問題でもない。設計がない状態で運用年数だけが積み上がった結果である。だから対処も「もっと丁寧に管理する」ではなく、持ち方そのものを変えるところから入る。

AIに任せていい範囲、任せてはいけない範囲

「ChatGPTに返信文を作って、と入れれば終わり」という話をときどき見かけるが、その入れ方をすると必ず同じところで事故る。生成AIは、指示に足りない情報があっても文章としては完成させてしまうからだ。返品の可否、返送料の負担者、返金までの日数、キャンセル可能な期限——このあたりは、渡していなければAIが「それらしい一般解」で埋める。しかも文章としては自然なので、読んでも違和感がない。ここが一番危ない。

線引きはシンプルに考えていい。事実か、表現かである。事実は人が確定してAIに渡す。AIがやるのは、渡された事実を状況に合わせて言い回しに落とすところだけだ。

種類	具体例	担当
金額・数量	返金額、返送料の負担者、手数料、代替品の差額	人が確定して渡す
規約・条件	返品可能期間、開封後の可否、初期不良の扱い、キャンセル期限	人が確定して渡す
日付・期日	出荷予定日、入荷予定、返金処理の着金目安	人が確定して渡す
在庫・物流の状態	在庫引当の可否、出荷指示済みか、伝票番号が発行済みか	人が確定して渡す
謝罪・共感の言い回し	お詫びの強弱、書き出し、締めの一文	AIで量産・調整
構成・順序	お詫び→事実確認→代替案の並べ替え	AIで下書き、人が採否
チャネル別の言い換え	モールのメッセージ用／自社メール用のトーン差	AIで量産
読みやすさの調整	1文が長い、二重敬語、専門用語の言い換え	AIで調整

この表の上半分に共通するのは、間違えたときに謝って済まないという点だ。返品期限を1日長く書いてしまえば、その顧客に対してはその条件で応じることになる。返金額を多く書けば粗利がそのまま削れる。これらはCSの範囲を超えて、経理と在庫にまで波及する。逆に下半分は、間違えても読み直せば気づくし、直せば済む。この「取り返しがつくか」の差でAIに渡す範囲を決めると、判断がぶれない。

プレースホルダで渡す、という形にする

実務的な落とし込み方はひとつだけだ。事実の入る場所を{注文番号}{出荷予定日}{返送料の負担者}のようなプレースホルダにして、AIには「この記号は絶対に書き換えず、そのまま残すこと」と指示する。AIに具体的な日付や金額を一切書かせない。そうすると、生成された文面にプレースホルダが残っているかどうかを見るだけで、AIが勝手に事実を作っていないかを目視で判定できる。チェックが「読んで違和感を探す」から「記号が残っているかを見る」に変わるのが大きい。前者は疲れていると素通りするが、後者は疲れていてもできる。

法令が絡む文言は、テンプレ側で確定させておく

返品・交換まわりの文言は、社内の運用ルールというより表示のルールに近い。通信販売では返品の可否・期間・条件・送料の負担について、広告や購入手続きの最終確認画面での表示が問題になる領域であり、「都度ご相談ください」のような曖昧な書き方は避けたほうがよい、という整理がされている。ここは記事の一般論で判断せず、自社の特定商取引法に基づく表記と最終確認画面の実際の文言を突き合わせて、テンプレ側に固定文として持たせるのが安全だ。テンプレの文言とサイト表示がずれていること自体がトラブルの火種になる。判断に迷う場合は、消費者庁の通信販売に関する解説や社内の法務・顧問に確認する工程を、テンプレ更新のフローに入れておく。

また、モール側にも返信に関する運用ルールがある。たとえば購入者メッセージへの応答時間の目安や、自動返信を有効な応答と見なすかどうかの扱いは、モールやツールによって考え方が異なる。仕様は変わりうるので、セラーセントラルのヘルプやRMSの管理画面で、自社アカウントに表示されている条件を必ず一次確認してからテンプレの運用ルールに落とすこと。「速く返す」ためにAIの生成文をそのまま送る運用にすると、この種の条件に抵触する余地が出てくる。

テンプレの型と差分をAIに渡せるようになっても、「どこまで任せていいか」の線引き自体は人の判断が残る。そしてこの判断力は、テンプレ整備に限らずEC実務全体でこれから問われることになる。→EC実務者はAI時代に何を学べばいいのか

型（骨格）と差分（状況別の言い回し）を分けて設計する

ここからが本題になる。テンプレを「1本の完成された文章」として持つのをやめて、骨格と差分の2階建てにする。既存のテンプレを整理し直す場合も、テンプレ資産がゼロの状態から作る場合も、始まりは同じこの型でよい。

骨格は6ブロックで足りる

問い合わせ返信は、内容が何であれ、構造としてはほぼ同じ順序を踏む。骨格を先に固定しておけば、状況ごとに考えるのは中身だけになる。

1. 宛名・書き出し：注文への感謝と、問い合わせを受け取った事実の確認
2. 状況の要約：こちらが何をどう理解したかの言い直し（＝認識合わせ）
3. お詫び／共感：非がある場合とない場合で強度を変える。ここが差分の主戦場になる
4. 事実の提示：注文番号、現在のステータス、日付、金額。プレースホルダで持つ部分
5. 次のアクションと期日：誰が、いつまでに、何をするか。「確認します」で終わらせない
6. 締め・連絡先：追加の問い合わせ先と受付時間

この6つのうち、1・2・6は状況が変わってもほとんど動かない。3と5が状況で変わり、4は毎回中身が入れ替わる。つまり本当に状況別に用意すべきなのは3と5だけだ。ここに気づくと、テンプレの本数は一気に減る。「発送遅延_沖縄離島」を丸ごと1本持つ必要はなく、必要なのは「離島宛の場合の追加日数の伝え方」という差分1つである。

差分は2つの軸で持つ

差分には性質の違う2種類がある。混ぜると管理できなくなるので、最初から分けておく。

軸	何が変わるか	例
状況軸	書く内容そのもの	発送遅延／返品・交換／欠品・キャンセル／初期不良／サイズ違い／到着後の破損
チャネル軸	長さ・敬語の濃さ・改行の作法	RMSのR-Messe（アールメッセ）／セラーセントラルの購入者メッセージ／Shopify Inbox／自社フォーム返信メール

状況軸が6個、チャネル軸が4個あるとき、完成形で持とうとすると24本になる。だから破綻する。骨格1本＋状況差分6個＋チャネル差分4個＝11パーツで持てば、組み合わせで24通りが出る。管理する対象を掛け算から足し算に落とすのが、この設計の目的だ。

置き場はスプレッドシート1枚でいい

ここでいきなり専用ツールを導入する必要はない。Googleスプレッドシートを1枚作り、1行＝1差分で持つのが最も壊れにくい。列は次の程度で足りる。

• 差分ID（例：S-01_発送遅延_在庫確保済み）
• 軸（状況／チャネル）
• 使う場面の条件（1文で。「出荷指示は出ているが伝票番号が未発行」など）
• 本文（プレースホルダ入り）
• 必要な事実（{出荷予定日}{注文番号}など、この差分を使うときに埋める項目の一覧）
• 最終更新日／更新者
• 法務確認の要否（返品条件・返送料に触れる差分はここにフラグを立てる）

「必要な事実」の列があると、送信前チェックがそのままチェックリストになる。埋めるべき項目が3つあるなら、送信前に3つのプレースホルダが消えているかを見ればいい。ファイル名で世代管理していたときと違い、最新かどうかは最終更新日の列を見れば分かる。共有ドライブ上にあるので、担当者が変わっても所在ごと引き継がれる。

ゼロから作る場合の始め方

テンプレを1本も持っていない場合、いきなり全パターンを作ろうとすると必ず途中で止まる。順序としては、直近1〜2か月の問い合わせを実際に開いて、内容を上の状況軸に振り分けるところから始めるといい。RMSのR-Messe（アールメッセ）でもセラーセントラルでも、受信履歴は残っている。件数の多い順に3つだけ作れば、たいていの現場では問い合わせの大半をカバーできる。残りは発生したときに1行足す。最初から網羅しようとしないことが、この設計を続けられるかどうかの分かれ目になる。

AIでテンプレを作り直す手順とプロンプト例

設計が決まったら、あとは差分を埋める作業になる。ここがAIの出番だ。使うのはChatGPTでもClaudeでもGeminiでも構わない。テンプレの下書きを作るだけなら、この段階で有料プランや専用ツールを検討する必要はない。重要なのはツールの選定ではなく、渡す材料と指示の順序である。

手順0：AIに貼ってはいけないものを先に外す

最初にやるのはこれだ。過去の返信文をそのままAIに貼ると、顧客の氏名・住所・電話番号・注文番号が一緒に流れる。テンプレ化の材料として必要なのは文章の構造であって、個人情報ではない。貼る前に、氏名は{お客様氏名}、注文番号は{注文番号}へ置き換える。ここは面倒でも手でやる。会社として生成AIの利用ルールがある場合は、外部サービスへ業務データを入力してよいかの範囲を先に確認しておく。

手順1：ゼロから作らせず、自社の文章から骨格を抽出させる

いきなり「返信テンプレを作って」と頼むと、どこかで見たような一般的なCSメールが返ってくる。自社の言葉遣いとは合わないので、結局書き直しになる。既存の返信が3通でもあるなら、それを渡して構造だけ取り出させるほうが早い。

以下は当社のカスタマーサポートが実際に送った返信文です（個人情報はプレースホルダに置換済み）。
これらに共通する構成を、ブロック単位で分解してください。

条件：
- 各ブロックに「役割」と「状況が変わっても動かないか／動くか」を付けてください
- 当社特有の言い回し（頻出する語尾・定型句）があれば抜き出してください
- 新しい文章は書かないでください。分解だけしてください

【返信文1】…
【返信文2】…
【返信文3】…

「新しい文章は書かないでください」の一行が効く。これがないと、AIは頼んでいない改善提案版を勝手に作って返してくる。ここで欲しいのは自社の型であって、AIの考える理想形ではない。

手順2：骨格を固定し、状況差分だけを量産させる

骨格が固まったら、状況ごとの差分を作らせる。ポイントは、骨格を先に提示して「この構造は変えるな」と明示することと、事実をプレースホルダのまま残させることだ。

あなたは日本のEC事業者のカスタマーサポート担当です。
以下の骨格は確定済みです。ブロックの順序と役割は変更しないでください。

【骨格】
1 書き出し／2 状況の要約／3 お詫び・共感／4 事実の提示／5 次のアクションと期日／6 締め・連絡先

次の状況について、ブロック3（お詫び・共感）とブロック5（次のアクションと期日）の文面だけを作成してください。

【状況】メーカー欠品により、注文済み商品の出荷が予定より遅れる。代替品はなく、
キャンセルも受け付ける。当社に非がある（在庫データの更新遅れ）。

【厳守事項】
- 日付・金額・日数・返品条件は書かないこと。必ず {出荷予定日} {注文番号} {返金額} の形式のまま残すこと
- 事実が不足していて書けない箇所は、創作せず「要確認：〇〇」と明記すること
- 敬語は二重敬語を避け、1文は60字以内
- 3パターン作成し、それぞれお詫びの強度を「弱・中・強」で変えること

最後の「3パターン／強度を変える」がこの使い方の肝になる。人間が3種類のお詫び文を書き分けるのは地味に消耗するが、AIは苦にしない。選ぶ側に回れるのが差分量産をAIに渡す最大の利点だ。そして「不足しているなら創作せず要確認と書け」と指示しておけば、AIが埋めてしまった箇所が目印付きで返ってくる。

手順3：チャネル差分は言い換えとして作る

状況差分ができたら、チャネルごとの言い換えを別プロンプトで作る。ここで内容を変えさせないことが重要になる。

以下の文面の内容・事実・プレースホルダを一切変えずに、表現だけ調整してください。

- 版A：モールのメッセージ画面用。装飾なし、全体を400字以内、改行は少なめ
- 版B：自社サイトからの返信メール用。件名案も付ける。署名の直前まで

変えてよいのは語順・敬語の濃さ・一文の長さのみです。
事実や条件を追加・削除した場合は、その箇所を明示してください。

手順4：作った文面をAIに検品させる

最後に、生成物を別のセッションで点検させる。書いたAIと点検するAIを分けると、自分の生成物を擁護しにくくなる。「この文面を読んで、書かれていない前提を推測して補った箇所を列挙してください」「顧客がこの返信を読んで生じうる誤解を3つ挙げてください」の2つが実用的だ。特に後者は、社内では自明でも顧客には伝わらない書き方（「確認が取れ次第」が誰の確認なのか不明、など）を拾ってくれる。

ただし、検品もあくまで下読みである。最終確認は人がやる。とくにプレースホルダが残っているか、要確認の印が消えていないかは、AIの報告ではなく自分の目で見る。

クレーム・低評価など、トーンが難しい返信の扱い方

ここまでの話には例外がある。テンプレの機械的な適用がかえって逆効果になる領域だ。強い言葉で届いたクレーム、レビューや出品者評価に書かれた低評価、SNSに投稿された不満。この種の返信をテンプレの貼り付けで処理すると、相手には一発で伝わる。「定型文が返ってきた」という事実そのものが二次クレームの火種になる。

テンプレ化してよいのは初動だけ

とはいえ、何も持たずに毎回ゼロから書くのも危険だ。動揺した状態で書いた文章は、たいてい言い訳が長い。現実的な線引きはこうなる。

工程	テンプレ化	理由
受け止め（届いた事実の確認と一次のお詫び）	してよい	速さが最優先。内容は状況に依存しない
事実確認（何が起きたかの特定）	質問項目のみテンプレ化	聞くべき項目は決まっている。文面は都度
代替案・解決の提示	しない	金額・在庫・過去経緯に依存する。個別判断
再発防止の説明	しない	使い回すと必ず同じ文面が別の顧客に届く

実務でよく言われる順序は「お詫び→事実確認→代替案」であり、この順を飛ばして最初から値引きや返金の提示に入ると、かえってこじれやすい。相手が求めているのが金銭的な補償とは限らないからだ。何が起きたのかを把握してもらえていない、という不満のほうが多い。順序を守ること自体が、テンプレに込めるべき最大の資産になる。

AIは「書く」ではなく「冷ます」ために使う

クレーム返信でのAIの使いどころは、文面の生成ではない。自分が書いた下書きを客観視する工程にある。実務で効くのは次の3つの聞き方だ。

• 「この文面を、怒っている顧客の立場で読んだとき、言い訳に聞こえる箇所を挙げてください」
• 「責任の所在を曖昧にしている表現を指摘してください」（「〜となっております」「〜という状況でございます」の多用は、たいていここで引っかかる）
• 「この返信で、こちらが何をいつまでにやるのかが読み取れますか。読み取れないなら、どこが不足していますか」

3つ目が特に効く。クレーム返信が炎上するときの共通点は、謝罪の言葉が足りないことより、次に何が起きるのかが書かれていないことだ。「確認のうえご連絡いたします」だけで終わっている返信は、相手からすると何も決まっていないのと同じである。誰が、いつまでに、何を返すのかを1文で書く。テンプレのブロック5を用意しておくのは、動揺しているときにこの一文を落とさないための保険でもある。

レビュー返信は、書いた相手だけが読者ではない

商品レビューや出品者評価への返信は、個別メッセージとは性質が違う。文面が公開され、これから買う人が読む。だからここでの目的は、書いた本人を説得することよりも、第三者が読んだときに誠実に見えるかに寄る。AIに下読みさせるなら「この返信を、購入を検討している別の閲覧者が読んだ場合の印象を書いてください」という聞き方が合う。

なお、レビューや評価に関する対応には各モール・各プラットフォームのポリシーがある。削除依頼が可能な条件、返信で書いてよい内容、レビュー投稿と引き換えに特典を提供する行為の可否などは、規約側の話であり、しかも改定される。テンプレ化の前に、RMSやセラーセントラルのヘルプで現行のポリシーを確認しておくこと。特に「見返りを示してレビューの取り下げを促す」ような文面は、プラットフォームの規約面でも表示上の観点でもリスクが高いため、テンプレに組み込まない。

作ったテンプレの運用：誰が更新し、いつ見直すか

テンプレ整備の作業は、作り終えた時点が最高到達点で、そこから劣化が始まる。送料が変わる、返品ポリシーが変わる、モールの画面仕様が変わる、扱う商材が変わる。放置されたテンプレは、ある日「今は使っていない条件」を顧客に案内する装置になる。だから作った直後に、更新の手順まで決めておく。

「四半期ごとに見直す」は続かない

カレンダーに入れた定期見直しは、繁忙期と重なった瞬間に飛ぶ。飛んだあとは誰も再設定しない。続くのは、日付ではなく出来事をトリガーにした見直しのほうだ。

トリガー	見直す対象
送料・返送料の改定	返品・交換、破損、サイズ違いの差分すべて
返品ポリシー／特商法に基づく表記の変更	法務確認フラグの立っている差分すべて
取扱商材・仕入先の追加	欠品・入荷時期・リードタイムに触れる差分
モール側の仕様変更（メッセージ画面・評価まわり）	チャネル差分と、送信前チェックの手順
大型セール（お買い物マラソン、スーパーSALE等）の前	発送遅延・在庫の差分。想定される問い合わせの前倒し
クレームや誤送信が起きた直後	該当する差分と、そのとき欠けていた確認項目
担当者の交代・増員	全体。引き継ぎのタイミングが唯一の棚卸し機会になる

特に効くのは最後から2番目だ。事故が起きた直後は、何が足りなかったかが全員に見えている。そのタイミングでスプレッドシートに1行足すか、既存の差分の「必要な事実」列に項目を1つ増やす。事故を差分に変換するこの習慣があるかどうかで、1年後のテンプレの精度が変わる。

更新権限は分けておく

運用ルールは2つだけでいい。差分の追加提案は誰でもできる。ただし公開（＝正式運用への昇格）は1人が承認する。 全員が自由に本文を書き換えられる状態にすると、誰がいつ何を変えたか分からなくなり、結局ファイル名で世代管理していた頃に戻る。逆に承認者を通さないと1行も足せない運用にすると、現場は自分のメモ帳に「自分用テンプレ」を作り始める。これも属人化の再生産だ。

スプレッドシートで運用しているなら、提案用の列を1つ足すだけで足りる。承認前の差分は下書き状態として置き、承認された時点で本文列に反映して最終更新日を入れる。ここに更新履歴が残るので、担当が交代しても「なぜこの文言なのか」を辿れる。

送信前チェックは3項目に絞る

チェックリストは長いほど守られない。実務で回るのは、この3つに絞った形だ。

1. { } のプレースホルダが1つも残っていないか（残っていれば差し替え漏れ）
2. 「要確認」の文字列が残っていないか（AIが埋められなかった箇所）
3. 注文番号と顧客名が、いま返信している相手のものか（前の顧客の情報が残る事故の防止）

この3つは、いずれも読解を必要としない。文面の良し悪しを判断する項目を入れないのがコツで、良し悪しの判断は疲れているときに必ず甘くなる。文字列の有無だけなら、繁忙期の深夜でも同じ精度で確認できる。メール送信画面での検索機能（Ctrl＋F）で足りる。

使われていない差分は削る

半年に一度でいいので、一度も使われていない差分を確認する。使われていない理由はたいてい2つで、そもそもその状況が発生していないか、あるいは存在を知られていないかだ。後者なら差分IDの命名が実態と合っていない。使う場面の条件を書いた列を読み直して、探すときの言葉に寄せて名前を付け替える。テンプレは書く道具である前に、探す道具である。

この設計の限界：コピペは消えないし、毎回AIを通すわけでもない

ここまでの内容には、正直に書いておくべき限界が3つある。実際にこの形で運用しようとすると必ずぶつかるので、先に潰しておく。

限界1：パーツのままでは、現場の手間はむしろ増える

スプレッドシートに骨格と差分を並べただけでは、返信のたびに「該当パーツを探して組み立てる」という作業が発生する。問い合わせが1日30件ある日に、毎回パーツを組み立てるのは現実的ではない。完成形をコピペしていた頃より遅くなることさえある。

だから、スプレッドシートは原本であって、運用の窓口ではないと割り切る。組み合わせが確定した時点で、よく使う数パターンは全文に展開して、実際に送る画面側のテンプレート機能に登録しておく。RMSのR-Messe（アールメッセ）にも、セラーセントラルの購入者メッセージにも、Shopify Inboxにも、定型文を保存する機能はある。現場が触るのは登録済みの全文で、スプレッドシートを開くのは差分を直すときだけになる。

この形にすると、スプレッドシート側の1回の修正が、展開先の複数テンプレへ反映すべき対象として特定できる。「お詫びの一文を直したら、どのテンプレを更新すべきか」が分かる状態になるのが、パーツ化の実利だ。コピペ作業がなくなるわけではない。なくなるのは、直すたびに全ファイルを開いて回る作業のほうである。 展開先が増えるほどこの差は開く。

限界2：チェック3項目は「事故の検出」であって「品質の担保」ではない

プレースホルダの残存や注文番号の取り違えは、機械的に見つけられる。しかし、その文面のトーンが今回の相手に合っているかどうかは、読まないと分からない。3項目チェックはこの読解を代替しない。

ではなぜ絞るのかというと、読解の必要な確認と、必要でない確認を混ぜると、混ぜた瞬間に両方の精度が落ちるからだ。文面を読んで温度感を判断する作業は集中を要する。そこに「記号が残っていないか」という単純作業を混ぜると、読むほうに意識が寄って記号を見落とす。だから機械的な3項目は送信ボタンの直前に独立して置き、トーンの確認はその前の工程として分けておく。件数が多い日に守れるのはこの順序だけだ。逆に言えば、初めて使う差分や、相手が明らかに怒っている案件では、3項目チェックの前に人が全文を読む工程を省いてはいけない。

限界3：AIを通すのは作成時であって、返信のたびではない

誤解されやすいので明示しておくと、前述のプロンプト手順はテンプレを作る／直すときの作業である。問い合わせ1件ごとに個人情報を外してAIに投げて言い換えさせる、という運用ではない。それをやったら1件あたりの所要時間は確実に増えるし、繁忙期には最初に捨てられる工程になる。

実際の頻度でいえば、この作業が発生するのは差分を新設するときと、限界1で挙げた出来事トリガーが引かれたときだけだ。日常の返信では、登録済みのテンプレを呼び出して事実を埋め、3項目を見て送る。AIは日々のフローの中ではなく、フローの手前にある準備工程に置く。この位置関係を間違えると、「AIを使うと遅くなる」という体感になって定着しない。

そのうえで、日常フローにAIを入れる余地が全くないわけではない。強いクレームが来た日に自分の下書きを冷ます用途は、件数が少ないので所要時間の問題になりにくい。件数が多く速さが要る場面ではAIを外し、件数が少なく判断が重い場面でだけAIを挟む。この振り分けが、実務で続く形に近い。

よくある質問

ヘルプデスクツールや自動応答（チャットボット）と、何が違うのか

役割が違う。この記事で扱ったのは「人が送る返信の中身をどう持つか」という設計の話で、ヘルプデスクツールやチャットボットは「誰がどの窓口で受けて、どう振り分けるか」という配送の話にあたる。順序としては中身が先だ。テンプレが型と差分に整理されていない状態でツールを入れても、登録されるのは整理されていない完成形テンプレのままで、ツールの中に同じ混乱が引っ越すだけになる。逆に、テンプレが整理されていれば、後からツールを入れたときの移行がそのまま登録作業で済む。

テンプレを整備すると、問い合わせ件数は減るのか

返信の書き方を整えるだけで件数が減るとは考えないほうがいい。件数に効くのは商品ページやサンクスメール、配送状況の通知など、問い合わせが発生する前の情報提供のほうだ。ただし、テンプレ整備には副産物がある。差分を作る過程で「どの状況の問い合わせが多いか」が数えられる状態になるので、上位3つの状況を商品ページやFAQページ側に書き足す判断材料になる。件数を減らす施策は、そこから始まる。

無料のAIで足りるのか。専用ツールを買うべきか

テンプレの下書きを作る用途なら、まずは手元で使えるものから始めて構わない。この工程は月に何度も発生するものではないので、頻度から考えても最初から契約を増やす必要は薄い。判断が必要になるのは、業務データを外部サービスに入力してよいかという社内ルールの部分で、これはツールの性能とは別の論点だ。料金体系や学習利用の扱い、法人向けプランの条件は各サービスで異なり改定もあるため、導入前に自社の情報管理ルールと突き合わせて確認する。

AIが下書きしたことを、顧客に伝える必要はあるのか

人が内容を確認して送っている返信について、AIで下書きした旨の開示を一律に求める国内の法的義務は、現時点で確認できない。ただし論点はある。「すべて有人で対応しています」といった表示を掲げている場合に、実態が自動応答で完結しているなら、表示と実態の乖離が問題になりうる。また、AIの利用に関する国内のガイドラインでは透明性の確保が論点として挙げられている。仕様も運用も変わりうる領域なので、自社サイトの表示内容と実際の運用が一致しているかを定期的に点検する観点として持っておくのがよい。

テンプレを作る時間が取れない。どこから手を付けるべきか

直近1か月で最も多かった状況を1つ選び、その骨格6ブロックだけを作る。所要はおそらく1時間かからない。全体設計を先に完成させようとすると、たいてい着手の前に力尽きる。1本目が動いてから2本目を作る順序でよく、むしろ1本目を運用してみないと、自社にとっての差分の切り方は決まらない。

まず1本だけ、骨格を書き出すところから

返信テンプレの整備は、文章がうまい人の仕事に見えて、実際は設計の仕事だ。うまい文章を1本書ける能力より、状況が20個に増えても壊れない持ち方を決める能力のほうが効く。そして後者は、一度決めてしまえばあとは差分を足すだけの作業になる。

今日やることを1つに絞るなら、直近で一番多かった問い合わせを1件開いて、自分が実際に返した文章を6ブロックに切り分けてみることだ。どこが毎回同じで、どこが状況で変わるのかが見えれば、その時点で型と差分の分離は半分終わっている。AIに渡すのはその後でいい。渡す先が整理されていない状態でAIを使うから、出てくるものが使えないのであって、順序を逆にするだけで結果は変わる。

問い合わせ対応のどこまでをAIに任せ、どこから人が持つのかという線引き全体については、こちらで整理している。→ECの問い合わせ対応にAIを入れる：どこまで任せて、どこから人か

型と差分の分離、AIへの任せ方——ここまでの整理は、あくまで作業の効率化の話だった。次に問われるのは、その作業を担ってきた自分のスキルをどう持つかという話になる。テンプレの差分を量産する部分がAIに移るなら、残るのは「どこまで任せてよいかを決める判断」と「事実を確定させる責任」のほうだ。この2つは職種名では説明できず、実務の経験でしか積み上がらない。→EC実務者はAI時代に何を学べばいいのか