refine-ja

name	refine-ja
description	日本語文章の推敲・リライト支援スキル。文章の「質」を向上させるために、 表現のブラッシュアップ、構成改善、言い換えを提案する。 小説・ブログ・技術文書・ビジネス・標準の5モードに対応。 トリガー:「推敲して」「リライトして」「もっと良くして」「文章を磨いて」 「小説っぽく」「ブログ風に」「技術文書として」「ビジネスメールで」 「描写を豊かに」「読みやすく」「丁寧に」「自然に直して」「表現を良くして」。 校正（誤字脱字・文法チェック）ではなく文章の表現力・構成を改善したい場合に使用する。

日本語推敲スキル (Refine JA)

文章の「誤り」ではなく「質」を向上させるためのスキル。 文脈、ターゲット読者、目的に応じて、より適切な表現や構成を提案する。

誤字脱字・文法の「校正」は proofread-ja スキルが担当する。本スキルは文章の表現力・構成の「推敲」に特化する。

推敲の原則（全モード共通）

1. 意味を変えない: 原文の主張・事実関係・ニュアンスを保持する。
2. 情報を創作しない: 原文にない数値・固有名詞・事実を補わない。具体化が望ましい箇所は「（具体的な数値を明記）」のようにプレースホルダーで提案する。
3. 固有名詞・引用は原文のまま: 人名、製品名、引用文は変更しない。
4. 書き換えは必要な範囲だけ: 原文の声（作者らしさ）を尊重し、目的に照らして必要な箇所だけ手を入れる。

モード定義

ユーザーの指示や文書の内容からモードを推定する。明示されていない場合は「標準（Standard）」とする。

モード	ターゲット・特徴	重視するポイント	トリガー例
小説	読者を楽しませる物語、エッセイ	情景描写、五感への訴求、リズム、単調な語尾の回避、比喩表現	「小説っぽく」「描写を豊かに」「情緒的に」
ブログ	Web記事、note、SNS	親しみやすさ、共感、リズム、目を引く見出し、結論ファースト	「ブログ風に」「読みやすく」「親しみやすく」
技術文書	マニュアル、仕様書、技術記事	正確さ、簡潔さ、曖昧さの排除、論理的な構造、用語の統一	「技術文書として」「わかりやすく」「厳密に」
ビジネス	メール、報告書、提案書	礼儀正しさ、簡潔さ、クッション言葉、定型表現、結論ファースト	「ビジネスメールで」「丁寧に」「報告書として」
標準	一般的な文章	自然な日本語、冗長表現の削減、わかりやすさ	「推敲して」「もっと良くして」「自然に直して」

ワークフロー

0. 入力の受け取り

入力形式	対応
テキスト直貼り	そのまま推敲対象とする
ファイルパス指定	ファイルを読み込んで推敲対象とする
IDE選択範囲	選択されたテキストを推敲対象とする
入力なし	「推敲するテキストを貼り付けるか、ファイルパスを指定してください」と案内

1. 入力分析

文字数、文書タイプ、ユーザーの要望（「もっと感動的に」「短くして」など）を確認し、 文字数に応じて処理方針を決める。

文字数	処理方針
〜3,000字	全文を対象に推敲
3,000〜10,000字	セクション単位で順次推敲。リライト型の場合はセクションごとに提示
10,000字〜	全体の改善方針 + 代表箇所の Before/After を提示し、続きは分割を提案

2. モード決定

指定があればそれに従う。なければ文体から推定し、出力の冒頭で「◯◯モードで推敲します」と宣言して進める。 確認の質問で作業を止めない（モードが違っていればユーザーが指定し直せる）。

3. 推敲提案

以下の観点でテキストを分析し、改善案を作成する。

• 全体構成: 段落の長さ、見出しの適切さ、論理構成。
• 文レベル: 一文の長さ、ねじれ文、受動態/能動態の使い分け。
• 表現レベル: 強い動詞への言い換え、同じ単語の繰り返しの回避、オノマトペの使用（小説など）。

4. 出力

依頼の言葉遣いに応じて出力形式を切り替える。

依頼の例	出力形式
「推敲して」「もっと良くして」「磨いて」	提案型: 箇所ごとの Before/After と理由を提示
「リライトして」「書き直して」「〜風にして」	リライト型: 修正後の全文 + 主要な変更点と理由のサマリ
どちらとも取れない場合	提案型をデフォルトとし、末尾に「全文リライトも可能」と添える

チェックポイント（モード別）

小説 (Novel)

• 「〜した。〜した。」のような単調な語尾の連続はないか？
• 抽象的な表現（「悲しかった」）を具体的な描写（「胸が締め付けられるようだった」）にできないか？
• 五感（視覚、聴覚、嗅覚、触覚、味覚）に訴える表現はあるか？
• 意味のない重複（「頭痛が痛い」的なものだけでなく、近い位置での単語重複）はないか？

ブログ (Blog)

• 「！」や「？」を使って読者に語りかけているか？（適度な距離感）
• 一文が長すぎないか？（60文字以内推奨）
• 漢字の含有率は適切か？（開きすぎず閉じすぎず、30-40%目安）
• 専門用語を平易な言葉に言い換えられないか？

技術文書 (Technical)

• 主語と述語は明確に対応しているか？
• 「〜と思われる」「〜の可能性がある」などの曖昧な表現を避け、事実を断定しているか（必要な場合を除く）？
• 指示代名詞（これ、それ）が何を指すか明確か？
• 箇条書きを活用して構造化できているか？

ビジネス (Business)

• 結論が最初に来ているか（結論ファースト）？
• 二重否定（「〜しなくはない」）のような回りくどい表現はないか？
• クッション言葉（「恐れ入りますが」）は適切に使われているか？
• 敬語は正しく、かつ過剰ではないか（二重敬語の回避）？

標準 (Standard)

• 冗長な表現（「〜することができる」→「〜できる」）はないか？
• 一文が長すぎないか？（80文字以内推奨）
• 同じ語尾（「〜です。〜です。」）が連続していないか？
• 不要な修飾語や副詞を削って簡潔にできないか？

参照ファイル

• references/refinement-patterns.md: モード別の具体的な言い換えパターン集。推敲提案時に参照。
• references/style-guidelines.md: 各モードの文体ルール詳細。モード決定後に該当セクションを参照。

出力フォーマット例

## 推敲提案（モード：小説）

### 表現の強化
原文：
> 彼は悲しそうな顔をした。雨が降っていた。

修正案：
> 彼は眉を寄せ、沈痛な面持ちで俯いた。窓の外では、冷たい雨が降り続いていた。

理由：
「悲しそう」という直接的な形容詞を使わず、表情と情景（雨）で感情を表現することで、読者の想像力を掻き立てます。

---

### リズムの調整
原文：
> ドアを開けた。部屋に入った。電気がついていなかった。誰もいなかった。

修正案：
> ドアを開けて部屋に足を踏み入れると、そこは闇に包まれていた。人の気配はまったくない。

理由：
短文の連続による単調さを解消し、文をつなげることでスムーズな流れを作りました。