なぜこう書くのか
サービスの変更案内がクレームに発展する原因の多くは、変更そのものではなく「伝える順番」にあります。冒頭に会社都合の事情を並べると、同じ内容でも単なる言い訳として読まれてしまいます。顧客向け案内プロンプトで最初に決めるべきは、文体のトーンではなく「最初の1行に何を置くか」です。
最初の段落で役割をマーケターではなくCS担当者に設定したのはそのためです。マーケターの視点では変更が「改善」として美化されがちで、顧客はそれを敏感に察知して反発を強めます。一方、CS担当者は「問い合わせが何件発生するか」を基準に文章を推敲します。
2番目の段落の文脈は、この文章がアプリ通知やメールで読まれること、そして顧客の関心は「自分への影響」にあることを伝えています。課題部分で5つの項目の順序を番号で固定したのは、この順番こそが読者の不安を解消する最短ルートだからです。影響を先に理解できれば、その後の説明は確認として読めますが、順序が逆になると同じ文章でも釈明に聞こえます。形式部分で変更前後の対比を求めているのも、文章だけで説明するより誤解を大幅に防ぎ、サポート窓口でもそのまま回答テンプレートとして活用できるためです。
制約の段落は2つの役割を持ちます。前半は表現に関するもので、陳腐な定型句を排除して誠実なトーンを維持させます。より重要なのは後半です。存在しない猶予期間や返金条件をAIが勝手に創作してしまうと、それが公式な約束事になってしまいます。利用規約改定など責任が伴う文章ほど、この制約指示が欠かせません。
用語が分からなければAha AIで: role-prompting, output-format
悪い例との比較
サービスの変更案内を書いて。配送周期が変わります。
（変更内容を貼り付け）
適用の日付や顧客が取るべきアクションが指示されていないため、モデルは「より良いサービスを提供するため」といった定型文で始まる案内文を生成してしまいます。既存顧客が自動切り替えになるのか、いつまでに変更可能なのかが曖昧なままになり、問い合わせが殺到する原因になります。また、お詫びの言葉が段落ごとに繰り返され、実際以上に深刻な問題に見えてしまうこともあります。
バリエーション
利用規約やポリシー変更を通知する場合
{{サービス名}}の規約・ポリシー変更をお客様にお知らせする案内文を作成してください。変更前の条文と変更後の条文を表形式で並べ、各行の横に「お客様への影響」を1文で記載してください。{{適用の日付}}と、同意しない場合の選択肢を本文に含め、提供された情報にない手順は勝手に作らないでください。
""" {{変更点}} """
規約変更は条文の対比が重要になるため、表形式を中心に構成しています。「影響」の列を設けることで、顧客が難解な条文をすべて読まなくても判断できるようになります。
アプリプッシュやSMSで短く送る場合
以下の変更内容をもとに、アプリプッシュ通知用のテキストを作成してください。タイトル20文字以内、本文60文字以内とし、{{適用の日付}}と{{顧客対応方法}}を必ず含めてください。トーンの異なる候補を3パターン作成し、それぞれ「どのような顧客が誤解する可能性があるか」を1行ずつ記載してください。
""" {{変更点}} """
短い通知文は省略された部分から誤解が生じやすくなります。複数案とそれぞれの懸念点をセットで出力させることで、最適な文面を選定しやすくなります。
モデル別の注意
文字数制限を正確に守れない場合があります。プッシュ通知文のように長さがシビアな用途では、「各パターンの文字数を横に記載してください」と追加で指示して確認してください。
関連プロンプト
最終更新 2026-09-02 · 誤りがありますか？ 知らせる