Communityライティング&編集github.com

プレーンなレジスター変換

AI の作文調の文体を削除し、文書の種類に合った自然でプロフェッショナルな文体に書き換えます。社外向けの文書(覚書、仕様書、提案書、報告書など)の最終調整に最適です。

プレーンなレジスター変換 とは?

このスキルは、ChatGPT や Claude などの AI アシスタントが生成した文章に特有の「 AI 臭さ」を取り除き、文書本来の形式にふさわしい「プレーンなレジスター(文体)」に書き換えるためのものです。具体的には、強調のための副詞(「本当に」「実際に」)、評価的な形容詞(「鋭い」「正直な」)、比喩表現(「重荷」「静かな部分」)、対比構文(「~ではなく、~だ」)など、AI が多用しがちなパターンを削除します。また、読者を誘導する表現や自己主張の強い言葉、ワークスペースに由来する内部的な参照も除去します。このスキルは、特に社外向け文書、監督官庁やクライアントへの提出物、法的文書など、形式が重視される場面で役立ちます。変更対象は文体のみで、事実内容や構成、引用、数値は保持されます。最終的には、読み手が自然に受け取れる平易かつ正確な文体を実現します。

対応✓Claude Code~Codex CLI~Cursor
npx skills add https://github.com/josie2479-maker/claude-skills/tree/HEAD/skills/plain-register-pass

Installed? Explore more ライティング&編集 skills: steipete/notion, langchain-ai/langchain, bytedance/podcast-generation · View all 6 →

お気に入りのAIに質問する

このエージェントスキルを事前に読み込んだ状態で新しいチャットを開きます。

ドキュメント

プレーンなレジスター変換 は何をしますか?

ライセンス: CC BY 4.0 で公開 — 自由に使用、改変、共有できます(クレジット表示必須)。

文書を、その文書タイプが本来持つレジスター(文体)に書き換えます。内容、構造、結論はそのままに、散文のみを変更します。

このスキルが解決する問題:AI が生成したドラフトは、エッセイのような強調表現にあふれています。そのジャンルに詳しい読者はすぐにそれとわかります。そして、送信する側は毎回手作業でそれを取り除かねばなりません。AI の文体を除去してからでないと送信できないドラフトは、完成していないのです。

1. 最初にターゲットとするレジスターを特定する

質問するか、文書から推測します。誰がこれを受け取り、どのような種類の文書か? 調達文書、法的覚書、臨床プロトコル、役員会アップデートでは、それぞれに固有の文体があります。その文体で書きなさい。汎用的な「プロフェッショナル」な文体ではありません。

ほとんどのビジネス文書や政府文書におけるデフォルトの目標:平坦で、断定的で、意図的に退屈な文体。主張、根拠、結果。 ポイントは1回述べ、より強く言い換えてはいけません。より短く、より味気ない言葉を選びましょう。

機能テスト:もしある一文をステータスミーティングで声に出して読んだら変に聞こえるなら、書き直すこと。

読者固有の「これが AI らしい」リストを確認する。 受信者が何を AI らしいと感じるかを言っている場合(例えば、レビュアーが「最初の文に推奨事項を入れろ」とか「表を減らせ」と言った場合)、そのリストは以下の一般リストよりも優先されます。プロジェクトフォルダ(README、トラッカー、ノートファイル)を確認してから開始してください。ユーザーがその読者から新たな反応を報告した場合は、リストに追加します。

フィクションや創作文章:平坦化パスを実行しない。 「意図的に退屈」は物語にとっては間違った目標です。セクション2と2aの「AI らしさ」リストのみを AI の癖を見つけるために使用し、その作品自体の文体ルール(ストーリーバイブルやスタイルノート)をターゲットレジスターとして維持します。文体ルールがまだない場合は、最初にユーザーと一緒に書き留めてください。

2. 削除するもの

強調としての強意語 — 「本当に」「実際に」「正直に」「単純に」「真の問題は」「要点は」

説明として紛れ込んだ評価形容詞 — 「鋭い」「不愉快な」「正直な」「残酷な」「清潔な」「エレガントな」「赤裸々な」「率直な」「印象的な」。もし形容詞が事実の性質ではなく、書き手の意見であるなら、削除する。

分析を代行する比喩 — 「重荷」「静かな部分」「静かな部分を声に出して言う」「Xの服を着ている」「変装している」「爆発範囲」「特徴」「剥がれた」「結合」「指し示す」。文字通りの関係に置き換える:「決定する」「制限する」「参照する」「示す」。

対比の対句 — 「Xではなく、Yだ」「それはXではない。それはYだ」「Aかどうかではなく、Bかどうか」「Xだけでなく、Yも」「XでもYでもなく、Zだ」、逆の形「YではなくX」「Yの代わりにX」。単一の肯定的な主張にまとめる。

診断名詞 — 「罠は」「失敗モードは」「特徴は」「ここでの主なリスクは」「注目すべき点は」。これから述べようとしていることを事前に告知するのではなく、直接ポイントを述べる。

読者へのナッジ — 「注目に値する」「目を通す価値がある」「ここがポイントだ」「特に」「決定的に」「重要なことに」「覚えておく/考慮することが重要だ」「そしてそのときに限り」「儀式なしに」「それが発見であれば」。ことさらに強調せずに、そのまま述べる。

自己保証の厳密さ — 書き手が注意深く作業したことを読者に保証する言葉:「正直に」「意図的に」「記憶からではなく」「黙って省略するのではなく」「落とすのではなく運ぶ」。事実だけを述べる。方法ノートは手順を保持する(「各引用は [日付] 時点の最新規制と照合した」)が、美徳を示す言葉は削除する。また、読者ではなく将来の起草者への指示(「再導出しない」「推定で埋めない」)も削除する。

強調を運ぶダッシュの挿入句。 節、別の文に変換するか、削除する。挿入情報としてのダッシュは問題ないが、一拍置くために使われるものは削除する。

修辞的な形 — 3拍子のリスト、エスカレートする繰り返し、効果のための1行段落、そして前の文をより強く見せるためだけに存在する文。その文を削除する。

装飾 — 絵文字の旗、矢印、太字の感嘆符。旗は残し、装飾は削る:⚠️ を単純な太字ラベル 注意事項 または 前提条件 に置き換える。

ワークスペースのアーティファクト — ドラフト作成環境内でのみ意味を持つ参照:

  • 設定ファイルや設定ファイル名(CLAUDE.mdなど)
  • AI やアシスタントのロールラベル(「アシスタント(プロジェクトリーダー)」「AI」)
  • 内部チケットやトラッカータグ(TASK#N形式、意思決定ログID D7、O12など)
  • ローカルファイルパス
  • 「[名前]より」「[名前] [日付]」などの出典メモ
  • チャットボットの残骸:「これがお役に立てば幸いです」「もちろんです!」「もちろん!」「よろしければ…」「お知らせください」「こちらが…です」

削除するか、読者向けの同等の表現(承認役割、決定ログ参照、文書タイトル)に置き換えます。これらは表、フッター、コメント、ソースセルに隠れているため、Office ファイルを含むファイル全体を検索します。タグが事実の出典を記録する唯一の場所である場合は、事実を保持し、不足している出典をフラグで示します(タグを黙って削除しない)。

2a. 既知の AI の兆候(外部チェックリスト)

主な出典:Wikipedia「AI 執筆の兆候」(WikiProject AI クリーンアップアドバイスページ)。ページの日付付きコピー(PDFなど)をプロジェクトノートと一緒に保存し、リストをその時点の内容と照らし合わせられるようにしてください。以下の (W) の項目はここから来ています。マークのない項目は、過度に使用されるチャットボットの単語に関する一般的な報道からのものであり、出典の確かさは劣ります。

出典から、すべてのパスに適用される2つの注意事項:

  • 1回か2回のヒットは何も証明しない。 これらの単語やパターンは共起します。クラスターが信号です。「重要な」「さらに」のような普通の単語を機械的にすべて削除してはいけません。
  • 兆候はより深い問題を指し示す。 誇張された重要性、曖昧な帰属、付随的な分析は、通常、根拠のない主張を示します。主張を修正しなさい(根拠を追加する、範囲を狭める、または削除する)。文言だけではありません。

誇張された重要性 (W) — 「~として機能する」「~の証である」「重要な/極めて重要な/不可欠な/重要な/キーとなる役割や瞬間」「その重要性を強調する/際立たせる」「より広範な~を反映する」「継続的な/永続的な/長く続く~を象徴する」「~に貢献する」「~の舞台を整える」「~を形作る/目印となる」「~の変化を表す/示す」。また、「重要な役割を果たす」「豊かな歴史」「永続的な遺産」「~への道を開く」。何が誰に起こったかを述べなさい。

末尾の「~しながら」分析 (W) — 事実文の末尾に現在分詞句が付くもの:「, ~を強調/強調/強調し…」「, ~を確実にし…」「, ~を反映/象徴し…」「, ~に貢献し…」「, ~を育成/促進し…」「, ~を含み…」「, ~を強化し…」。また「貴重な洞察」「~と一致/共鳴する」。末尾を削除するか、根拠を持った独立した文にする。

宣伝的な言葉 (W) — 「誇る」「活気のある」「豊かな」「深遠な」「強化する」「披露する」「例示する」「~へのコミットメント」「画期的な」「有名な」「特徴とする」「多様な品揃え」「居心地よく位置する」「中心部で」。また「シームレスな」「最先端の」「革新的な」「ダイナミックな」「変革をもたらす」「ゲームチェンジャー」「最新式の」「効率化する」「エンパワーする」。測定可能な特性に置き換えるか削除する。

AI 語彙 (W) — 「さらに(特に文頭)」「~と一致する」「強化する」「重要な」「深く掘り下げる」「探究する」「強調する」「永続的な」「高める」「育成する」「獲得する」「強調する(動詞)」「相互作用」「複雑な/複雑さ」「重要な(形容詞)」「風景(抽象名詞)」「細心の」「極めて重要な」「堅牢な」「披露する」「タペストリー(抽象名詞)」「証明する」「強調する(動詞)」「貴重な」「活気のある」。また「領域」「ナビゲートする(比喩)」「活用する」「全体的な」「多面的な」「微妙な」「着手する」「高める」「活用する」「解き放つ」。

単純な「である」「持つ」を避ける (W) — 「~として機能する」「~として立つ」「~として機能する」「~として動作する」「~を示す」「~を表す」「誇る/特徴とする/提供する/維持する」を、単純な「である」「持つ」で代用できる場合。また「~としてキャリアを始めた」のような elaborate なバージョンは「~だった」で。単純な動詞を使う。

曖昧な接続 (W) — 「~と接続している」「~に関連して」「~と関連して」「~に関連する」を、実際の関係(「~の CEO だった」「~で教鞭をとった」)の代わりに使用。関係を明示する。

曖昧な帰属 (W) — 「業界レポート」「オブザーバーは引用した」「専門家は主張する」「一部の批評家は主張する」「複数の情報源(1つだけ引用されている場合)」、また「研究によると」「多くの人が信じている」。情報源を明示するか、主張を削除する。

決まりきった書き出しと締め (W、一部) — 「~にもかかわらず、いくつかの課題に直面している…」「これらの課題にもかかわらず…」「将来の見通し」で終わる、「要約すると」「結論として」「全体的に」、構成を繰り返す最終段落。また「今日の~では」「~に関しては」「最終的に」「X から Y までの範囲(包括的に使う)」「反射的な While X, Y の書き出し」「ペアになった課題と機会」。

情報源に関するヘッジ (W) — 「具体的な詳細は限られているが…」「広く文書化/利用可能ではない」「入手可能な情報に基づく」「提供された情報源において」。事実を見つけるか、ギャップをギャップとしてマークする。

書式の習慣 (W、一部) — キーフレーズの各インスタンスを太字にする;インラインヘッダーリスト(箇条書き、太字ラベル、コロン、テキスト);タイトルケースの見出し;書式としての絵文字;散文で十分な表;パンチラインのためのスペース入りダッシュ;コロンヘッダー;2段落ごとの見出し;均一な文の長さ。ジャンルに合わせる:手紙は段落を取得;プロジェクト提案は見出しといくつかのラベルを保持してもよい。

AI 検出サイトを使用しない(GPTZero、Pangram など)。Wikipedia のページはそれらに依存しないよう警告しており、誤検出を生成し、ドラフトを公開ツールに貼り付けると、ユーザーの職場やクライアントの機密保持または AI 使用ポリシーに違反する可能性があります。パターンレビューと音読テストがチェック方法です。

3. 変更しないもの

  • 実質的な主張、数値、引用、法令または規制の参照、日付、名前。
  • 文書構造、セクションの順序、見出し。
  • プレースホルダー、[CONFIRM] マーカー、ギャップリスト、前提条件フラグ、推測または構築とラベル付けされたものすべて。これらは、より 臨床的に しなさい。見えにくくしないこと。
  • 所有権および著作者性の枠組み(意図的に空白のフィールドを含む)。

重要なガードレール:結論を和らげずに文体を取り除く。 厳しく述べられた好ましくない発見は、平易に述べられた同じ発見になる。- 楽観的な発見にはならない。「ほとんどのユーザーにとって、アップグレードは以前より悪くない」は「ほとんどのユーザーにとって、期待される結果は変化なし」となり、「ユーザーは恩恵を受ける」にはならない。散文の目標は平凡さであり、内容の目標ではありません。もし書き換えによって文書が送りやすくなった場合は、結論が移動していないか確認してください。

4. 標準用語は比喩ではない

一部のドメイン用語は比喩的に見えますが、受け入れられた専門用語です。「クリティカルパス」「カーブアウト」「ランウェイ」「単一連絡窓口」。それらを保持し、その判断をメモします。専門用語を説明に書き換えると、その分野に不慣れであると読まれます。

5. 方法

  1. 編集前にファイルをバックアップする(コピー、またはファイルがリポジトリにある場合はバージョン管理)。
  2. 書き換える。全文書き換えが適切です。散文の表面全体が対象だからです。ただし、定型ルールで部分的な編集が必要な場合は、これが望まれていることを確認する。
  3. 機械的なスイープを実行する:結果をセクション2と2aの単語とパターン(「~ではなく」「~の代わりに」「~として機能する」「ダッシュ」「、~しながらで終わる文」を含む)で検索し、各ヒットを修正するか、そのまま残す理由をメモする。
  4. 名前が付けられた読者が読むように読む。会議で変に聞こえる行、または読者固有の「AI らしさ」リストに一致する行は、書き直す。
  5. 結果を、書いた経路とは別の経路で読み返して確認する。セクション構造、すべての引用、すべてのプレースホルダーが残っていることを確認する。
  6. 削除した特定のフレーズ、元の表現 → 置き換え後を報告する。 これはパスの最も有用な出力です。読者がルールが適切なものを捕捉しているかどうかを判断できるようにし、パターンを書き換えられた文書よりも速く教えます。
  7. 合理的に別の判断が下せる可能性のある裁量判断をフラグ付けし、文書全体を再読せずに元に戻せるようにする。

Individual skills in this repo

This repo contains 3 individual skills — each has its own dedicated page.

josie2479-maker/claude-skills

Test a ready-made list of deliverables, documents or artifacts before anyone commits to tracking it. Use when someone is handed a list from a template, vendor, consultant, PMO framework or AI (\"standard project documents\", \"required artifacts\", \"deliverables checklist\") and asks whether to adopt it, what is really required, what to drop, or what is missing. Tags each item by who requires it (funder, law or regulation with citation, a named person, or standard practice that nobody requires), reads the funder's or agency's own template section by section to find required items the list leaves out, and returns a table plus a drop / keep / add list. Not for building a list from scratch with no list in hand, and not for checking whether finished documents are good.

josie2479-maker/claude-skills

Verify factual claims before delivering them. Use before any answer or deliverable the user will act on, forward, or share with others — rules, policy, legal, financial, date, or product facts — and whenever they say 'is that right', 'double-check that', 'verify this', 'fact-check', 'are you sure', or 'source?'. Exception: vetting a claim someone else handed the user is critical-thinking-walkthrough; fetching page text is reliable-fetch (this skill calls it).

josie2479-maker/claude-skills

Interview the user about something they are ABOUT TO BUILD, before any of it is built — a feature, a system, an automation, a workflow, a document structure. Use when a plan exists only in their head or as a rough idea and the design decisions are still open: \"grill me\", \"interview me about this\", \"help me think this through before I build it\", \"what am I not deciding\", \"ask me what you need to know\". Works the design as a dependency tree, asking one answerable question per round (the one that unblocks the most decisions first) with a recommended answer attached, and never asking anything it could look up itself. BOUNDARY — this is front-loaded, for decisions not yet made. Reviewing a plan that already exists and stress-testing it for holes is the plc skill. Interrogating information someone else handed you is critical-thinking-walkthrough. If the thing is already written down and the question is \"is this any good\", it is not this skill.

関連スキル