skills/note-draft-quality/references/draft-quality-contract.md

# 原稿品質ゲート契約

## 1. 目的

この契約は、note Workspaceから記事原稿を返す直前の内部確認を定める。対象は次の二つだけである。

1. 本人固有の一次情報が記事の中心にあること。
2. 利用者の文体を保ち、読みにくさや不要な反復を整えること。

結果を利用者向けレポートへ変換することは目的ではない。通常は、確認と修正を済ませた納品原稿だけを返す。

## 2. 対象外

次はこのゲートへ入れない。

- 顧客名、料金、CTA、URL、公開予定等の運用整合。
- 公開可否、法務、校閲、承認者の代行。
- AI検索やLLM引用への適性評価。
- noteへの下書き登録、公開、予約投稿、既存記事更新。
- 外部送信、クラウド同期、scheduled task。

別工程に必要な確認を、このゲートの判定項目へ混ぜない。

## 3. 一次性の確認

### 3.1 中心材料

次のいずれかが記事の流れを作っているか確認する。

- 本人が実際に見た場面や変化。
- 本人が選んだ行動と、その時の判断。
- 本人の言葉、迷い、失敗、違和感、発見。
- 本人の仕事や生活から得た具体的な観察。

固有名詞や数字があるだけでは一次性にならない。一般論の本文へ一つだけ逸話を差し込む形も不十分である。本人材料が導入、展開、結論の判断へつながっているかを見る。

### 3.2 置換確認

主要な段落について、書き手の名前を別人へ置き換えてもそのまま成立するかを考える。大半が成立する場合は、一般論が主役になっている可能性が高い。

置換できる段落をすべて消す必要はない。読者に必要な説明は残し、依頼された改稿範囲と承認済みの構成の中で、本人の観察や判断とのつながりを確かめる。解説や調査をすべて体験談へ変えない。

### 3.3 根拠と射程

- 本人の経験を、全員に当てはまる法則へ広げない。
- 公開情報と本人の経験を同じ根拠として混ぜない。
- 推測は推測として書き、未確認事項を断定しない。
- 元材料にない経験、感情、成果、数字、発言を補わない。

不足材料を創作で埋めるくらいなら、原稿を止めて短い質問を一つ返す。

## 4. 文体の確認

文体は今回の明示指定、確認済みの`profile/style-profile.md`、以下の共通項目の順で判断する。共通項目は読みづらさを探す観点であり、特定の言葉を禁止したり、すべての文章を同じ調子へ揃えたりする規則ではない。

### 4.1 文と段落の流れ

読点や接続詞が多く、文の流れを不必要に止めていないかを見る。主語と述語が離れすぎている場合は、不要な修飾を整理するか、意味のまとまりで文を分ける。読点をただ消したり、短文と改行を増やしたりして解決しない。

接続詞が示す順序、対比、因果が実際の内容と合っているかを確認する。段落のつながりを保ち、箇条書きや見出しは手順、比較、整理など読者に役割がある時に使う。

### 4.2 説明の過不足

同じ説明の言い換え、似た例の列挙、長い前置きや締めが、理解を増やさず文章を引き延ばしていないかを見る。必要な要約、注意、意図的な反復は残す。

抽象語や比喩の指す内容が分からない時は、元材料にある対象や動作で明確にする。特定語の使用自体を問題にせず、材料にない具体例を補ったり、根拠以上に強い表現へ置き換えたりしない。

### 4.3 本人の声とリズム

語尾、否定形、比喩、記号、定型的な挨拶は、使用自体をNGにしない。同じ表現の続き方が単調さや分かりにくさにつながる時だけ見直す。語尾の種類や例の数を固定せず、本人の調子と文章の目的を優先する。

引用、名称、本人が覚えている言葉、意図的な反復は、一般的な言い方へ勝手に均さない。疑わしい事実は確認事項として扱い、本人の表現を黙って別の事実へ直さない。「人間らしさ」の演出のために誤字、乱れ、感情、体験を加えない。

### 4.4 修正の範囲

具体的な読みづらさを説明でき、意味を保って改善できる箇所を、依頼された改稿範囲で小さく直す。「誤字だけ」の依頼なら、それ以外の文体は変更しない。好みの差にとどまる場合は原文を残し、確認質問を増やさない。

修正後は前後も読み、事実、主張の強さ、本人の感情、用語の意味が変わっていないかを確かめる。承認済みの構成やトーンを大きく変える必要があれば、執筆側の確認工程へ戻す。

制作・確認の報告は通常の本文へ混ぜない。その工程自体が記事の題材なら、読者に必要な説明として残せる。

## 5. signalの扱い

`scripts/check_draft_style.py`は、決定ではなく見落とし防止のsignalをJSONで返す。対象は読点が一文に四つ以上、同じ段落で同じ語尾が三文以上、制作・確認の用語である。これらの回数は見直す箇所を拾う目安であり、文章の上限ではない。見出し、Markdownの引用ブロック、コードブロックは対象外にする。

- `pass`: 静的signalは見つからなかった。一次性や意味、流れの確認は別に必要。
- `review`: 一つ以上のsignalがある。文脈を見て修正または意図的な保持を決める。
- `error`: 入力を読めず、検査できなかった。

この検査はAIによる執筆の有無を判定しない。語の出現だけでは、不自然さも修正の必要性も決められない。文脈上必要な表現や意図した反復は残し、signalをゼロにすることを目標にしない。判断の注釈を利用者向け原稿へ足さない。

## 6. 通常出力

確認後に返すのは、依頼された完成物だけである。

- 本文の依頼: 本文だけ。
- 記事一式の依頼: 合意した順序のタイトル、本文、タグ、告知文だけ。
- 材料不足: 完成物を装わず、必要な質問を一つだけ。

品質結果、点数、signal、修正一覧、内部Skill名は付けない。明示的にレビュー説明を求められた時だけ、納品原稿と混ざらない別の応答として説明する。