英語の問い合わせを受け取ったとき、最初から英語で回答を考える必要はありません。内容を日本語で正確に整理し、伝えることを決めてから英語へ変換したほうが、確認する箇所を減らせます。
返信で優先するのは、英語らしい表現よりも、相手が次に何をすればよいか誤解なく分かることです。
日本語で判断してから英語にする
返信は次の順番で作ります。
- 問い合わせを日本語に訳して、質問と事実を分ける
- 日本語で回答または確認事項を書く
- 短い英語へ変換する
- 製品名、バージョン、日付、URL、否定表現を原文と照合する
翻訳結果を無条件で送るのではなく、固有名詞と「できる・できない」の向きだけは必ず見直してください。返金、個人情報の削除、重大な障害など、判断を伴う内容は定型文だけで確定させないほうが安全です。
返信を3ブロックに分ける
毎回ゼロから文章を組み立てず、次の三つに分けます。
- 受領：連絡へのお礼と、必要なら困らせたことへの短い謝意
- 回答または確認：解決手順、現在の状況、追加で必要な情報
- 次の一手：試した結果や不足情報を返信してもらう案内
この順番なら、長い挨拶に埋もれず、ユーザーが必要とする行動を中央に置けます。
調整して使えるフレーズ
受け取ったことを伝える
Thank you for reaching out. I’m sorry you’re having trouble with
アプリ名.
追加情報をお願いする
To investigate this, could you tell me your device model, OS version, and app version?
手順を試してもらう
Could you try
手順and let me know what happens?
確認中であることを伝える
I’m looking into this issue. I’ll update you when I have more information.
解決したか確認する
Please let me know if the issue continues after trying these steps.
「次の更新で必ず直ります」「返金できます」のような確約は、実際に決定している場合だけ書きます。未確認なら、確認中であることと次に連絡する条件を伝えます。
短く単純な英文にする
英語が母語ではないユーザーもいます。長い敬語表現や比喩より、主語と動詞が分かる短い文が向いています。
Microsoftのグローバル向けライティング指針も、短く単純な文を使い、複雑な段落をリストへ分けることを勧めています。
- 一文に依頼を二つ以上詰め込まない
- 手順が三つ以上なら番号付きリストにする
itやthisが何を指すか曖昧なら製品名や機能名を再度書く- 日付は月名を使うなど、読み違えにくい形式にする
丁寧さは文章を長くすることではありません。相手の状況を認識し、必要な情報と次の行動を明確にするほうが、サポート返信として役立ちます。
送信前に確認する
- 問い合わせの質問へ答えている
- 未確認の原因や修正時期を断定していない
- アプリ名、OS、バージョン、URLが正しい
- 相手に求める次の行動が一つに絞られている
- 原文と翻訳後の返信を見比べた
問い合わせを受け取った時点で原文と日本語訳を並べられると、読む段階で止まりにくくなります。返信案も原文の言語に合わせて用意できれば、日本語で内容を確認してから送信できます。
IndieFormなら返信案がユーザーの言語で先に用意されている
IndieFormは、登録したFAQやアプリ仕様を根拠に、問い合わせを送ったユーザーの言語で返信案を作成します。この記事で説明した「日本語で判断してから英語にする」という手順を、返信案の下書きとして先に済ませておく形です。根拠が足りない場合は機能や保証を推測せず、確認が必要な返信案に留めます。返金、法務、個人情報削除、重大障害などは高リスクとして扱われます。
問い合わせの原文も保持されるため、問い合わせ詳細では原文と翻訳を切り替えて、固有名詞や否定表現を原文へ戻って確認できます。
返信案は自動送信されません。日本語で内容を確認し、必要なら編集してからメールへ渡せるので、下書きを無条件に送る流れにはなりません。英語を読む、回答を考える、英文化する作業をまとめて省ける点がIndieFormの強みです。
関連する窓口の準備は、App StoreのサポートURLに必要なものでも確認できます。