mcpField
W
work-humanizer

work-humanizer

github.com/phurynマーケティング・グロース11959 回インストール3 週間前に更新
リポジトリ

work-humanizer について

work-humanizerは、文章の編集や執筆者へのインタビューに基づく作成を支援するスキルです。事実を保ち、執筆者自身の表現や論理を活用し、検出回避は保証しません。

主な機能

  1. 01書き換えとインタビューモード
  2. 02事実と確実性の維持
  3. 03執筆者のメモに基づく構成
  4. 04文体とリズムの確認

活用シーン

  1. 01事実を加えず業務連絡を編集
  2. 02インタビューから個人的な文章を作成
  3. 03論旨を保ちながらメモを編集

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/phuryn/work-humanizer --skill work-humanizer

インストール後、Claude Code で/work-humanizerを入力して読み込まれたか確認します。

同梱ファイルcheck.pytells.md

詳細

work-humanizer

特定の読者に向けて、特定の人が書いたような文章にします。事実はすべて残します。何も創作しません。

以下のすべては、私たちが測定した3つのことを踏まえています。

  1. 読者は文章の手触りに気づきます。 情報を伴わない強調、均一なリズム、ありきたりな主張、読者の代わりに考えるような文。こうした点は編集で改善できます。
  2. 検出器が読み取るのは言葉ではなく構成です。 人間が書いた記事は、AI による書式調整、AI によるコピー編集、AI による全文の一文ずつの言い換えを経た後も、商用の検出器で人間らしさが99〜100%のままでした。同じ記事を AI がアウトラインから構成した場合は、人間らしさが68%と判定され、その AI 版を文体に合わせて書き直しても、スコアは1ポイントしか上がりませんでした。2026年10月のテストでは、このスキル、blader/humanizer、または単純なプロンプトで AI の下書きを書き直したものは、いずれもその検出器で AI と判定されました。一方、書き手自身の文をもとに作成した文章は、元の文がどれだけ残っているかにおおむね比例して、人間が書いたと判定されました。アシスタントモデルが下書きを言い換えても、誰が文章を構成したかは変わりません。検出器対策として訓練された言い換えモデルはスコアを変えましたが、同じテストで意味と品質を損ないました。「検出されない」と決して約束しないでください。書き手が本当に自分の文章を必要としているなら、インタビューモードを使ってください。
  3. 具体的な情報が人間らしさを伝えます。 私たちが調査したクリエイターの間で、読者の反応と一貫して関連していた唯一の指標は、数字、名前、日付の密度でした。使ってよい具体的な情報は、ソースにあるものか、書き手から提供されたものに限られます。

モードを選ぶ

書き直しモード(デフォルト)。ユーザーから文章を受け取り、編集します。

インタビューモード。 ユーザーが希望した場合、または書き手が質問に答えられ、文章が次のテストに当てはまらない場合に使います。同じ一行の依頼を受けた人なら、誰でもこれを書けただろうか? もしそうなら、書き手にしかわからないこと(実際の例、「大幅に」の裏にある数字、何がうまくいかなかったか、実際にどう考えているか)が欠けており、編集では補えません。投稿、ニュースレター、エッセイ、略歴、講演概要、提案メール、ランディングページ、求人情報、ローンチ記事では、たいていこれに当てはまります。Slack の更新、サポートへの回答、リリースノート、ポリシー、ドキュメントのように、業務上の文章で事実がすべて揃っている場合は、質問せずに書き直してください。

インタビューモード

質問は1回に最大5つまでにしてから、文章を書きます。

  • 各質問で、読者が気づく欠落を埋めます。 実例、数字、名前、起きたこと、書き手が実際にどう考えているか、友人に何と伝えるかを尋ねます。回答で置き換える行を引用してください。
  • 書式ではなく、語るように答えてもらいます。 「お客さんが初めて使ったときのことを、声に出して話すときのように、2〜3文で教えてください」は、「顧客の事例を提示してください」よりも適切です。
  • 回答の負担を軽くします。 各質問には1分以内で答えられるようにします。どの質問もスキップできると伝えてください。
  • 本当に推測できない場合を除き、文体、読者層、形式については尋ねないでください。

その後、本人の言葉をもとに文章を作成します。

  • 本人の文を素材にします。 言い回し、順序、独特な語句を保ちます。明瞭さ、文法、長さの調整に限って編集します。言い換えなら書き手の特徴が残りますが、再構成するとあなたの特徴に置き換わります。
  • AI の下書きは要点のチェックリストとして使い、骨組みにはしません。 下書きの文の骨組みには、AI の特徴が残ります。書き手の意見と下書きが食い違う場合は、書き手を優先します。
  • 質問がスキップされた場合は、平易な文にするか削除します。 詳細を作り上げてはいけません。
書き手からメモやボイスメモを受け取った場合

メモ、ボイスメモの文字起こし、または書き手自身が書いた下書きは、AI による下書きの背景資料ではなく、主な素材です。そこには書き手の考え方がすでに表れており、読者も検出ツールも、書き手の考え方、つまり主張、それを述べる順序、「なぜなら」や「だから」のつながり、例によって書き手を見分けます。

  • 書き手の構成を骨組みにします。 主張の順序、「なぜなら」や「だから」のつながり、例を置く位置を守ります。A だから B、したがって C と論じているなら、文章も A、B、C の順にします。AI の下書きの順序にはしません。
  • 可能な限り、書き手の文をそのまま保ちます。 明確さ、文法、長さのためにだけ編集し、独特な言葉選びは残します。
  • AI の下書きがある場合は、チェックリストとして使います。 書き手のメモで裏づけられる点だけを追加し、論旨に合う位置に置いて構いません。骨組み、つなぎ方、枠組みを借りてはいけません。
  • 事実確認の根拠はメモです。 書き手のメモにある事実、約束、留保はすべて残します。AI の下書きにだけある事実は任意です。書き手の論旨を支えるなら残し、そうでなければ削除します。いずれの場合も正確でなければならず、どちらにもない内容を追加してはいけません。
  • メモで明らかになっていないことだけを尋ねます。 すでに要点、例、読者が取るべき行動が示されているなら、尋ねずに書きます。

書き直しモード

  1. 文章の目的を読み取ります。 ジャンル、読者、読者が読後に知るべきことや行うべきことを確認します。要点をどこに置くか決めて、その方針を貫きます。返信、メール、Slack、告知では結論を先に、説明や論証では根拠を先にします。1 行目で要点を述べ、最後に同じ要点へ戻る文章は、どちらも果たしています。片方を削ります。
  2. 確度も含めて事実を列挙します。 数字、名前、日付、主張、約束、留保、リンク、行動喚起と、それぞれに付く限定表現(「可能性がある」「通常は」「約」「役に立った」「残りの部分」など)をすべて書き出します。このリストの内容はそのまま残さなければなりません。
  3. 新たに書きます。 下書きはいったん脇に置きます。手順 2 のリストをもとに、この書き手ならこの読者にどう書くかを考え(「人間らしい文章にする」を参照)、書き手の語り口や文体に合わせて、平易で自然な語順の文を書きます。AI の文をそのまま編集してはいけません。手直しした AI の下書きにも、AI らしさは残ります。下書きの言葉をそのまま使ってよいのは、名前、読者自身が使う言葉、約束や条件の表現だけです。言い回しは新しくしても主張は変えず、下書きにある主張はすべて、同じ強さで、強めたり弱めたりせずに残します。
  4. 主張は残し、決まり文句は変えます。 ありきたりな道徳訓、価値のアピール、感謝の定型句、漠然としたメリットにも、書き手が伝えようとしたことは含まれています。その内容を、書き手の声で簡潔に一度だけ述べます。「皆さんの訪問があったからこそ、ここまで来られました」は、「皆さんが通ってくださらなかったら、10 年続けることはできなかったでしょう」と言い換えます。すでに述べたことを繰り返す場合に限り、決まり文句を削ります。
  5. 削って整えます。 次に、自分の文章から冗長な部分、言い直し、大げさな表現を削り、以下のサインを優先度の高いものからすべて修正します(コロンで種明かしをする表現、三つ並べる表現、ありがちな結び、ありきたりなまとめの一文)。削ることでぶっきらぼうにならないようにします。下書きに水増しがなければ、書き直し後の長さも下書きとほぼ同じにします。書き手の声、具体的な描写、つなぎの言葉、ジャンルに必要な温かみは、水増しではありません。文には余裕を持たせます。会話で使うような短い言葉(「だから」「そして」「でも」「ただ」「それから」など)を使い、二つの考えを一つの切り詰めた節に押し込めないようにします。
  6. リズムと流れを整えます(セクション E)。
  7. 元の下書きと照らし合わせて事実を確認するなど、最終チェックを行います。
変更してはいけないこと
  • 確実性。 言葉そのものではなく、確実性の度合いを保ってください。「減らすのに役立つ可能性がある」は「減らす」ではなく、「通常は」は「常に」ではなく、「残っている部分」は「唯一の大きな部分」ではありません。ただし、限定表現は一つあれば十分です。「目立った症状が現れる前に変化を見つけるのに役立つ可能性がある」は、「症状に気づく前に変化を見つけられる可能性があります」とできます。
  • 理由と条件。 書き手が述べていない説明、原因、適用条件、メリットを、たとえ明らかに思えても付け加えないでください。
  • 曖昧な表現をさらに曖昧にしない。 主張が曖昧で、具体的な情報がない場合は、書き手の言葉をそのまま使うか、文全体を削除してください。「Premium はアプリにさらに多くの機能を追加します」のような、より曖昧な表現に置き換えてはいけません。
  • 誰が何をするか。 行為者を保ってください(「こちらからメールをお送りします」は、書き手が明らかに一個人でない限り、「こちら」を主語にしたままにします)。

注意すべき表現。上から順に重要度が高いもの

A. 情報を加えない強調表現
  • 誰もしていない主張との対比。 「X ではなく Y です」「X だけでなく Y も」「これは X の話ではありません。Y の話です。」や、言い切りの「X も Y もありません」という締めくくりなどです。Y だけを述べてください。読者が実際に X を信じている場合に限り、対比を残してください。
  • 間を置いて要点を示す表現。 「ここがポイントです:」「重要なのはここです:」「はっきり言います:」「詳しく見ていきましょう。」や、一行でコロンの後に種明かしをする表現(「一番の魅力は、学習することです。」)、リストの前に項目数を予告する表現(「これは四つの点で問題になります:」「三つのことが変わりました:」)などです。要点は、そのまま次の文にしてください。
  • 言い換えで締めくくる表現。 「結論は?」「重要なポイント:」「これこそが本当の成果です。」「だからこそ、X が未来なのです。」「どう思いますか?」「ご意見は?」などです。最後の具体的な内容、または書き手の結論を一行で述べたところで終えてください。
  • 格言や、同じ型を重ねた表現。 「クリックを減らす。構築を増やす。」「自動化は実行する。エージェンシーは決断する。」などです。文章一つにつき、引用したくなるような工夫された一文は多くても一つにしてください。ゼロでも問題ありません。経験豊富な書き手でも、長い記事でさえ平均してゼロから一つです。事実を保ったまま、残りは平易な文にしてください。
  • 文章中の断片的な表現の連続。 「セットアップ不要。設定不要。結果だけ。」などです。主語と動詞のある一文にまとめてください。リストは対象外です。
  • 独自に作った比喩的なラベル。 読者が役立てられる具体的な意味を持たない、気の利いたイメージ表現(「安心の毛布」「チームのオペレーティングシステム」など)です。平易な言葉で述べてください。
B. 読者に代わって考える表現

六つのパターンがあります。各文を削除しても読者が意味を理解できるか確認してください。理解できるなら、削除したままにしてください。

  1. 読者が知っている言葉を定義する(「トークンを失効させます。これによりセッションが無効になります。」)。
  2. 含意を言葉にする(「つまり……」「言い換えると……」など)。後に続く現在分詞の補足も含みます(「……チームの取り組みを示しています」「……を強調しています」「……より大きな変化を反映しています」など)。
  3. 事実からすでにわかる結論を述べる(「つまり、教訓は……です」など)。
  4. 読者に注目を促す(「ここに注目してください……」「ご覧のとおり……」「ここからわかることは……」など)。
  5. 読者の感じ方を指示する(「これはわくわくします」「これは心配すべきです」など)。
  6. 話題の移行を実況する(「次に見ていきましょう……」「続いて……」など)。長く、複数のセクションに分かれた文書では、大きなセクションごとに案内表現を一つ使う程度なら問題ありません。
C. 誇張と一般論
  • 具体的な裏付けのない形容詞(「重要な」「シームレスな」「強力な」「堅牢な」「画期的な」など)。原文にある数値、名前、仕組みを添えるか、その形容詞を削ってください。原文にない数値を補ってはいけません。
  • 重要性の誇張。「重要な節目」「~の証し」「状況を一変させる」「未来は明るい」など。事実は残し、重要性の主張は削ってください。
  • マーケティング以外でのマーケティング調の表現や、AI でよく使われる決まり文句。リストは tells.md にあります。一つだけでは判断材料になりませんが、いくつも重なるとそれが表れます。
  • 口に出して誰も言わないような言い回し。「推奨される方法は X です」は「X をしてください」に。「~として機能する」は「~です」に。「評価の実施」のような名詞表現は動詞に。情報源について論説調の動詞(「論じる」「主張する」「断言する」)は「述べる」や「書く」にしてください。判断の目安は、頭の切れる友人とコーヒーを飲みながらこの文を口にするかどうかです。もっと平易な言い方をするなら、そう書いてください。
  • 曖昧な権威付け。「専門家の間では意見が一致している」「調査によると」「多くの企業」など。原文に誰のことか書かれているなら、その名前を挙げてください。そうでなければ削るか、「社内テストでは」のように範囲を限定してください。
D. 適切でない箇所に置かれた留保表現

人は事実を断定し、意見には留保を付けます。AI の文章はその逆になったり、あらゆることに留保を付けたりします。

  • 事実はそのまま述べてください。事実に留保を付け加えてはいけません。書き手が選んだ限定表現(「通常は」「およそ」「~する可能性がある」など)は事実の一部なので残し、その周りに重ねた表現は削ってください。
  • 意見には留保表現を一つだけ使ってください(「私はそう思います」「おそらく」「私の経験では」など)。一文に二つ使ってはいけません。
  • あらゆる箇所から、不要な留保表現を削ってください。「そう言えるかもしれませんが」「注目すべきなのは」「重要なのは」「潜在的に~する可能性がある」などです。
  • 主張に限定が必要な場合は、曖昧に和らげるのではなく、当てはまらないケースを示してください。「規制対象のチームでは、手動レビューのほうが適しています。」
  • 原文で裏付けられない絶対表現(「全員」「常に」「誰もいない」「最初の」など)を加えてはいけません。
E. ルールに基づく文章のリズム
  • 文の長さ。 AI の文章は、通常は10~20語程度の同じ長さに偏ります。文の約70%以上が中央値から5語以内に収まる場合は、適切な方向に長さを変えてください。長文ばかりなら、一、二文を分け、事実を端的に伝える短い文を加えます。短くぶつ切りの文ばかりなら(ダッシュや断片的な文を削った結果にありがちです)、息の長い文(25~40語)にまとめてください。測定対象となった人間の書き手では、その範囲に入る文の割合は12%から66%まで幅がありました。短い文には意味を持たせてください。「動きます。」だけでは何も伝わりません。
  • 文頭のパターン。 AI は文頭に「~は」「それは」「これは」「あなたは」を使いすぎます。変化をつけてください。
  • 反射的に三つ並べること。 三つ並べるのは、実際に項目が三つある場合だけにしてください。
  • 並べ替えテスト。 意味を損なわずに文の順番を変えられるなら、それは論旨ではなく、事実の羅列です。前の文を受けて次の文が展開するよう、文章の軸を組み立て直してください。因果、対比、例、結果などでつなげます。つなぎ言葉を散りばめてごまかしてはいけません。
  • 文頭の不要なつなぎ言葉。 「さらに」「そのうえ」「しかしながら」「重要なのは」「最終的に」「結論として」「とはいえ」などは削るか、文の構成を変えてください。必要な場合は、「しかし」「そのため」「そして」をそのまま使ってかまいません。
  • 類義語を次々に使うこと。 同じものを指す語(ツール、レポート、機能など)が二つあるなら、毎回同じ語を使ってください。「プラットフォーム」と「ソリューション」が別物なのかと読者を迷わせてはいけません。
F. 句読点と書式
  • ダッシュと、前後にスペースを入れたエンダッシュ: 書き手自身の文章で使われている場合を除き、削除します。文脈に応じて置き換えます。ラベルに続けて説明する場合はコロン、独立した内容が二つある場合はピリオド、本当に補足を入れる場合は括弧、軽く間を置く場合はコンマを使います。セミコロンは使いません。 AI による編集ではダッシュがセミコロンに置き換えられます(AI が編集した投稿では、同じ書き手自身の文章の 1,000 語あたり 0.3〜0.4 個に対し、2.9 個でした)。また、コロンで種明かしをする形も避けます(セクション A)。
  • 太字のラベルで始まる段落(「速度。 新しいエンジンは……」)、語句に散りばめた太字、絵文字の箇条書き、タイトルケースの見出しは削除します。
  • 内容のないラベル。 すべての項目に同じラベル(「軽減策:」「利点:」「影響:」など)が付いている場合や、ラベルが文の内容を繰り返しているだけの場合は、ラベルを削除し、文として書きます。読者が流し読みしたり、後で見返したりする箇所では、リストや見出しを残します。リリースノート、仕様、手順、比較する選択肢、参照ページなどが該当します。
  • 感嘆符: 最大 1 つまでとし、本当に感嘆する場面だけで使います。熱意を装うためには使いません。
G. チャットの名残

「いい質問ですね!」「もちろんです!」「お役に立てば幸いです」「ご希望であればお知らせください……」「修正版はこちらです:」「前回の更新時点では」など。前置きは削除し、内容は残します。

不自然な演出ではなく、人らしい文章にする

癖を取り除くのは作業の半分です。平易な文章は、無味乾燥な文章ではありません。このジャンルの読者に向けて、その役割にふさわしい文章を、対面で話すように書きます。

  • 短縮形を基本にする(it's、we're、you'll、don't、that's)。ポリシー、契約書、正式な PRD など、フォーマルな文書では短縮形を避けます。
  • 書き手は自分の立場から話します。 原稿の話し手を保ちます(「we」は「we」のまま、「I」は「I」のまま)。ただし、外部から自分たちを描写するのではなく、一人称で話します(チームが書いているなら「チームが確認します」ではなく「私たちが確認します」とします)。
  • 読者に呼びかけるジャンルでは、「あなた」に話しかけます。
  • 日常的な動詞を使います。 use、help、start、need、fix、send を使い、utilize、leverage、facilitate、ensure、enable は避けます。
  • 誰が対応するかを明確にします。 「追跡番号をお送りします」と書き、「追跡情報が提供されます」とは書きません。
  • 個人的な内容では温かさを込めます。 お礼、謝罪、招待、お祝い、お客様へのメッセージでは、温かい言葉を率直に一度だけ伝えます(「お付き合いいただき、ありがとうございます。」)。本当に感嘆する場面なら、感嘆符を 1 つ使ってもかまいません。
  • 場に合わせます。 Slack、コミュニティ向けニュースレター、ショップの SNS 投稿などではくだけた調子にし、PRD、メモ、ポリシーなどでは平明でプロフェッショナルな調子にします。フォーマルな文章でも、平易な動詞と自然な完全文を使います。
  • 会話調にし、くだけすぎないようにします。 平易で自然な英語を使います。各段落で慣用句や俗っぽい表現は最大 1 つまでにします。「pointy end up」「a natter」「the hard bit」のような表現が重なると、人間味を加えようとした印象になります。

わざと個性を加えないでください。「正直なところ」「ちょっとしたお知らせです」「悪くないですね」「もっと嬉しい話として」などの言葉や、会話らしく見せるための修辞疑問、書き手がしていない冗談を加えると、読者には不自然なくだけた表現だとすぐに見抜かれます。AI らしい磨き込みも同様です。

すでに人間らしい部分は残す

  • 具体的な詳細、独特な言い回し、意見、余談、ユーモア、迷い、複雑な感情。残すべきものはこうした要素です。
  • 読者が普段使う語彙。入力したり検索したりする製品名や専門用語は残します。専門性を誇示するだけの専門用語は削り、読者が行動に移すための用語は残します。
  • ジャンルの慣例。リリースノートはリスト形式でもかまいません。PRD には見出しがあってもよく、サポートへの返信は温かい調子にでき、手紙には結びの言葉を添えられます。
  • ユーザーが文章サンプルを提示した場合は、文の長さ、句読点、書き出し、文体を合わせます。サンプルは上記のルールより優先されます。
  • わざとらしい雑音は加えません。 誤字を仕込んだり、無理に俗語を使ったり、わざと小文字にしたり、「lol」と書いたり、架空の「昔こんなことがあった」という話を作ったりしません。人間らしさは、具体性と判断から生まれるものであり、間違いの模倣から生まれるものではありません。

ジャンル別の注意点

  • **Slack、DM、スレッドへの返信:**回答または依頼を先に書きます。読み手がすでに知っている背景は省きます。多くの場合、1〜4文で十分です。
  • **コールドメール:**この相手に連絡する具体的な理由を、元の情報から1つ示し、依頼を1つします。「お元気でお過ごしのことと思います」は使いません。
  • **ソーシャルメディアの投稿:**1行目に、投稿内で最も具体的な内容を書きます。反応を煽る締めくくりや、ハッシュタグの羅列は避けます。
  • **リリースノートまたは製品アップデート:**何が変わったか、誰に向けたものか、何をすべきかを、数値も含めて伝えます。「発表できることを大変うれしく思います」は使いません。
  • **ランディングページ:**具体的な成果と、その実現方法を伝えます。「力を与える」「可能性を引き出す」「シームレスな」「高める」は省きます。
  • **ドキュメント、PRD、ポリシー:**平易かつ正確に書き、構成を保ちます。確かな不確実性がある場合に限り、断定を避けます。

最終チェック(毎回)

  1. **事実の確認。**事実が抜け落ちるのは文章を組み直すときです。そのため、文ごとに元の原稿と照らし合わせます(書き手のメモをもとに書いた場合は、そのメモと照らし合わせます。該当するセクションを参照してください)。すべての数値、名前、日付、価格、引用、条件、約束、利点、留保が、同じ値と確かさで含まれており、発言者も変わっていないことを確認します。強さを表す語に注意してください。「役立つことがある」を「役立つでしょう」に、「かもしれない」を「だろう」に、「少し」を「まったくない」に変えてはいけません。提案を約束に変えてはいけません。「唯一」「すべて」「常に」「保証される」を新たに加えてはいけません。原稿で暗示されているだけのことを明示してはいけません。逆方向も確認します。書き換えによって、書き手が示していない事実、例、逸話、理由、利点、意見、詳細を加えてはいけません。温かみや語り口は加えてもかまいませんが、新しい内容は加えません。
  2. **機械的な確認。**最終テキストで、em dash(U+2014)、en dash(U+2013)、セミコロン、および tells.md にある語句を検索します。目視では見落とすことがあります。コードを実行できる場合は、python check.py <file> を実行します。
  3. **練り上げた一文:**1つまで。
  4. **リズム:**文章の調子と書き出しを確認します。
  5. **書き手になったつもりで声に出して読む。**本人が言わないような表現は、もっと平易にします。
  6. **長さ。**冗長な入力より短くし、冗長でない入力とは同程度の長さにします。そのために、事実や語り口、ジャンルに必要な温かみを削ってはいけません。
  7. **短い案(毎回作成し、採用するかは書き手が決めます)。**最終テキストはそのままにします。次に、段落を1つずつ隠して残りを読みます。読者は事実、約束、決定事項、書き手の主張を見落とすでしょうか。見落とすものがなければ、その段落は削除候補です。削除候補になりやすいものを多い順に挙げます。本文で具体例やエピソードを示す前に要点を一般論で述べる書き出し(練り上げた一文だからといって書き出しを残す必要はありません。下の例やエピソードのほうが要点をうまく伝えているなら、削除候補です)。似た文章ならどれにも入るような一文(一般論、締めくくりの「まだやることがある」や「一息つくのも大切」、2度目のお礼など)。別の箇所とほぼ同じことを述べている部分(より強いほうを残します)。単独で成り立つ2つ目の論拠や調査結果(返信、続報、別の文章に移せます)。根拠や重要性を示すもの、つまり例、数値、約束、または読者の信頼につながる開示事項は、削除案にしてはいけません。候補ごとにおおよその語数を記し、合計します。推測せず、実際に数えます。候補の合計が文章全体の約4分の1以上なら、短い案を提示します。削除候補が内容に見合わないなら、3分の1でも半分でも大胆に削ります。それ以外の場合は「なし。すでに簡潔です」とします。約100語未満の文章では、この確認を省きます。

返す内容

書き換えモード:最終テキストです。ユーザーがメモを求めている場合は、変更点を最大5つ箇条書きで追加し、実際の具体的な情報があると効果が高まる箇所(「実際の顧客数があると、この一文がより伝わります」など)も示してください。インタビューモード:まず番号付きの質問を提示し、回答を受け取ってから最終テキストを作成します。

その後、約100語を超える文章については、「Shorter option:」で始まる1行を末尾に追加してください(最終確認7)。短縮案は、提案するだけで適用せず、削る内容、おおよそどれだけ短くなるか、削ると失われる事実とその移動先を示すか、「なし。すでに簡潔です。」としてください。執筆者から求められた場合は、短縮版を全文で作成してください。

コメント