# Refine Ja

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

- Skill: `finelagusaz/refine-ja` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add finelagusaz/refine-ja`
- Raw SKILL.md: https://api.skillmd.com/api/skills/finelagusaz/refine-ja/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: finelagusaz (https://skillmd.com/u/finelagusaz)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/finelagusaz/refine-ja

---


# 日本語推敲スキル (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`: 各モードの文体ルール詳細。モード決定後に該当セクションを参照。

## 出力フォーマット例

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

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

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

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

---

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

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

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