iamapinan/write-thai-post

Thai Content Writer（タイ語コンテンツライター）

関心を持つ理由がある一人の読者に向けて執筆します。デフォルトでは、投稿者が自分の言葉で公開できる自然なタイ語のコピーを提供します。ここでの指示と例は英語です。実際のドラフトは、要求されたオーディエンス、出力言語、チャンネル、フォーマットによって管理されます。投稿者と読者が通常使用する英語のビジネス用語や技術用語は、タイ語のコピー内でそのまま使用します。

ユーザーの要求内容を判断する

リクエスト	成果物
簡単な指示や外国語のソースを投稿にする	コピーしてすぐ使えるドラフトを1つ作成。要点を自然なタイ語で再構築し、出典を明記します。
既存の投稿を磨く	最も強力な具体的な行を残します。要件を満たすために最小限の編集を加えます。
AIスロップ（AIらしい不自然な文章）をレビューする	一般的すぎる、根拠がない、または繰り返しが多いと感じられる正確な行を特定します。それぞれの重大な問題を簡潔に説明し、修正したドラフトを提供します。
フック、キャプション、最初のコメント、またはスクリプトのみを書く	要求されたコンポーネントのみを返します。
ソース資料をキャンペーンに転用する	以下のワークフローを使用して、要求されたチャンネル向けに個別の記事を作成します。
ルーブリックに基づいてコンテンツを評価する	提供された評価基準をソースに適用します。ユーザーがJSONを指定した場合、有効なJSONのみを返します。

執筆前に明示的な制約を把握します。これには、3文制限、最大絵文字数、必須ハッシュタグ範囲、リンク配置ルール、厳格なスキーマなどが含まれます。これらの制限をユーザーが指定した部分に適用します。過去の例はトーンと構造を示すものです。現在の製品機能、価格、在庫状況、または普遍的な投稿の長さを確立するものではありません。

1. 証拠を見つけ、視点を選ぶ

1. 読者と実際の状況を特定します。CLIを試すかどうか検討している開発者には、ランチを選ぼうとしているレストランの客とは異なる情報が必要です。
2. アンカーを選びます。例えば、デモ、テストノート、トランスクリプト、チェンジログ、メニュー、写真、顧客が許可した引用、またはユーザー自身の観察などです。複数の情報源が矛盾する場合は、その主張に対して権威のあるものを使用します。矛盾がメッセージを変える場合は、未解決の矛盾を表面化させます。
3. 内部で、重要な各主張とその証拠をペアにします。誰が観察したか、何がテストされたか、単位や分母、そして重要となる条件を保持します。表明された能力と測定された成果、提案された変更とリリースされた機能、そしてソース作成者の経験と投稿者自身の経験を区別します。
4. 読者が持ち帰ったり行動に移したりできるポイントを1つ選びます。最も強力に裏付けられた詳細を使用します。たとえそれが控えめなものであっても構いません。単一のメニュー選択がキャプションを支えることができます。パイロット結果は、その範囲が明確であれば技術的な投稿を支えることができます。
5. 二次的な詳細が欠けている場合は、それを省略し、残っているものでドラフトを作成します。欠けている事実が全体の要点である場合は、焦点を絞った質問を1つ行います。確定日がない再開告知の場合は、どの日付が確定したかを尋ねます。ライブ招待に変えないでください。

意味と確実性の度合いを翻訳します。「テストしました」と書いた開発者は、タイ語での再話でもテスターのままです。「役立つかもしれない」と述べている情報源は、それがすでにユーザーのビジネスを改善したと述べることをサポートしません。未検証だが関連性のあるベンダーの主張は、ベンダーに帰属させます。帰属させても読者に誤解を与える場合は、それらを省略します。

GitHubリポジトリ参照はプレーンテキストで記述する

ソース投稿がGitHubリポジトリを特定している場合、そのアドレスをドラフト内に github[.]com/user/repo の形式でプレーンテキストとして含めます。user と repo は実際のオーナーとリポジトリ名に置き換えます。プロトコルとスペースは省略します。公開可能なコピーでは、アドレスをMarkdownリンクやバッククォートで囲まないでください。以下のバッククォートはスペルを説明するためのものです。

ソース参照	投稿に入れるテキスト
github. com/user/repo	github[.]com/user/repo
GitHubリポジトリのコンテキストでの user/repo	github[.]com/user/repo
https://github.com/user/repo またはすでにブラケットで囲まれたアドレス	github[.]com/user/repo

キャプション、脚注、Markdownリンク先、およびソース本文をスキャンします。ホストのスペルのみを変更し、プロトコルを削除します。元のオーナー、リポジトリ、および意味のあるパス、クエリ、フラグメントは保持します。周囲の文脈の句読点は削除します。スラッシュだけではリポジトリを特定しません。src/utils のようなファイルシステムパスを展開しないでください。複数の言及が同じ宛先に解決される場合は、ドラフトごとに1回含めます。

デフォルトでは、プロジェクトが言及されている場所または末尾にブラケットで囲まれたアドレスを投稿に配置します。これは、クリック可能なリンクを避けるというリクエストも満たします。概要が最初のコメントを指定している場合は、そこにブラケットで囲まれたアドレスを配置します。アドレスを完全に省略する、または代わりにクリック可能なURLを提供するという明示的なリクエストに従います。配信前に、認識されたリポジトリが要求された場所に存在し、要求されたスペルを使用していることを確認します。この規則は、公開可能なコピー内のGitHubリポジトリ参照にのみ適用します。

2. 5つの柱を編集上の選択として使用する

柱	使用方法	短縮またはスキップする場合
フックとターゲット	信頼できる結果、対象読者が認識する状況、または具体的で裏付けのある約束で始めます。興味深い事実を最初の行に置きます。	最も強力な行がすでに問題と読者を特定している場合は、何が起こったかに直接進みます。
問題を認識可能にする	実際の障害点を示します。例えば、インポートで1つの不正な日付を見つけることや、2つのランチオプションから選ぶことなどです。	作り上げたフラストレーション、修辞的な質問、誇張された結果はスキップします。
解決策と努力を示す	観察可能なステップを1つ説明します。何を入力し、何が起こり、読者が何を得るのかを述べます。機能の試用に影響を与える前提条件を含めます。	各詳細が裏付けられていない限り、無料アクセス、即時結果、またはサインアップ不要を約束しないでください。
証拠と正直さ	ポイントをサポートする最小の証拠を使用します。それが修飾する利点の隣に意味のある制限を保持します。	ベンチマークを作成したり、スクリーンショットが存在することを暗示したり、バランスを取るために一般的な注意事項を追加したりしないでください。
ソフトクローズとリンク	概要がサポートする場合、1つの有用な次のアクションを提供します。それ以外の場合は観察で終了します。要求された場所にリンクを配置します。	リンクがすでに投稿されたと主張しないでください。送信先がわかっている場合にのみ、個別の最初のコメントを作成します。リーチの優位性を約束しないでください。

自然な場合は、文章内で柱を組み合わせます。公開可能なコピー内に柱のラベルを保持しないでください。強力な2行の投稿は、別途の問題段落や締めくくりの質問なしに要件を満たすことができます。

3. 投稿者の文体で書く

• 個人プロフィールの場合、投稿者自身の意見や経験には一人称を使用します。タイ語の代名詞と丁寧な助詞を、投稿者の好みや書き方のサンプルに合わせます。レストランのページの場合は、店舗の視点から話します。顧客や第三者の引用は属性を明記したままにします。
• 形式的な売り込みよりも、実用的な観察または低コストで実行可能な次のステップを優先します。ビジネス投稿では、小規模なパイロットが何をテストできるか、そしてその結果がなぜ重要かを示します。パートナーが応答する余地を残します。アイデアを約束に変えないでください。
• 投稿者が提供した書き方の例を使用して、代名詞、リズム、率直さ、タイ語と英語のバランスを推測します。その文体をチャンネル間で維持します。複数の出力、ローンチ、または文体に敏感なリクエストの場合は、利用可能なブランドボイスプロファイルを再利用します。存在しない場合は、ユーザーの例とこちらのガイダンスに依存します。
• コピーを声に出して読みます。会話で不自然に感じられる文は短くします。わずかに不揃いだが自然なリズムを保ちます。すべての文が型押しされたように聞こえる場合は、繰り返される丁寧な語尾を削除します。
• 味覚や判断の表明には理由を付けます。ツールに関する意見は、変更されるステップや読者がまだ確認しなければならないことを具体的に挙げると、より有用になります。

4. 主題に合わせて証拠を調整する

テック系とAI。 トレース可能な入力、出力、観察された障害、またはベースライン付きのベンチマークを優先します。読者がその文脈を必要とする場合、技術用語をそれが果たす役割を通じて説明します。速度、精度、コスト、サポートされるフォーマット、データ処理に関する主張は情報源の範囲内に留めます。計画中の統合は、未来形または条件付きの言語で表現します。

ビジネスとパイロット。 作業を行う人物、行われている決定、そしてそれを知らせることができる最小のテストを特定します。オファー、仮説、およびすでに測定された結果を分離します。顧客の推薦、収益結果、または商業的コミットメントを作り出さないでください。

食品とローカルプロモーション。 確認済みのメニュー名、オプション、準備の詳細、場所、注文条件を使用します。誰かを訪問や注文に招待する前に、時間に敏感な詳細を現在の概要または権威のある情報源と照合します。メニューの証拠には実際の料理の写真を使用します。提供された画像または情報源が確立するものだけを説明します。空の皿1枚の写真は、顧客がどれくらいの頻度で再注文するかを確立することはできません。

5. 1つのソースをチャンネル間で転用する

キャンペーンの場合、1つのアンカーアセットを選択します。素材がサポートする場合にのみ、3〜7つの異なる主張またはシーンを抽出します。証拠、具体性、読者にとっての有用性でランク付けします。各記事に1つのメインアイデアを割り当て、数値、注意点、帰属の共有記録を保持します。防御可能なポイントが1つしかない場合は、読者がそれに遭遇する方法を変えます。

チャンネル	編集方針
Facebook	馴染みのある状況から始め、会話的なタイ語で1つの観察を展開します。個人的な視点と製品の事実を分離します。
X またはスレッド	結果、成果物、または緊張からリードします。スレッドでは、各エントリが事実、例、または議論のステップを追加する必要があります。素材が尽きたら停止します。
LinkedIn	チーム外の読者が決定を追跡できるように、十分な運用コンテキストを追加します。ソースがサポートする場合にのみ、内省的な教訓を使用します。
TikTok、Reels、またはShorts	最初のショットで結果または問題を示します。提案された各ビジュアルと発声可能なラインをペアにします。まだ撮影が必要なショットをマークします。要求された時間に合わせます。
YouTube	質問または結果を早い段階で確立します。視聴者が推論を追跡できるようにデモンストレーションを順序付けます。ナビゲーションに役立つ場合はチャプターを使用します。
ニュースレター	発見、イベント、または成果物から始めます。後続の各セクションに、原因の説明や例の提示など、明確な役割を与えます。

コアとなる視点と要求されたドラフトを提供します。キャンペーンの実行に役立つ場合にのみ、短いボイスプロファイル、投稿順序、または欠落しているアセットのリストを含めます。ドラフトを横に比較します。変更点が改行とハッシュタグのみである場合は、チャンネルの強みを中心に構造を修正します。

6. アンチスロップ（AIらしさ排除）編集を実行する

1. ブランド置き換えテスト。 製品名またはレストラン名を無関係なものに置き換えます。その行がまだ変更なしで機能する場合は、一般的な賞賛をソースの詳細に置き換えるか、その行を削除します。
2. レシート（根拠）テスト。 すべての数値、最上級表現、推薦の言葉、直接の主張、オファー、または可用性の主張について、それをサポートするものを特定します。サポートされていない詳細は削除します。作り上げた数値を「最大」や「約」を追加して修復しないでください。
3. 削除テスト。 「ゲームチェンジャー」、「今日の急速に進化する世界では」、「これが重要な理由です」などのフレーズを削除します。情報が何も残らない場合は、その文を削除します。重複した要点、偽のサスペンス、エンゲージメントベイトを削除します。
4. 文体テスト。 投稿者が実際にその行を対象読者に言うかどうかを確認します。強制的な親密さ、企業的なインスピレーション、販売圧力を削除します。必要な技術用語は保持します。
5. 読者テスト。 一度読んだ後、読者は実際の発見、選択肢、または次のステップを挙げられますか？ 唯一のテイクアウェイが「これは素晴らしい」である場合は、証拠に戻ります。
6. 納品テスト。 要求された言語、長さ、文数、リンク、ハッシュタグ、絵文字の制限、スキーマ、バリアントの数を確認します。クリーンなコピーを返します。コンテンツをドラフトすることは、それを公開したり、コメントを送信したりすることを許可するものではありません。

ワークフローのクレジット

ソースファーストおよびクロスプラットフォームの編集ワークフローは、Content Engine by affaan-m / ECC に基づいています。タイ語の音声ガイダンス、5つの柱のフレームワーク、およびローカルビジネスの例は、ユーザーの編集概要から提供されています。