AIの下書き、そのまま出して大丈夫？提出前に読み手・目的・根拠をチェックする

以下の内容を `SKILL.md` として保存し、Agent Skillとして登録してください。
保存先や登録方法が分からない場合は、利用中のAI環境に合わせて分かりやすく案内してください。

---
name: ai-draft-submit-check
description: 仕事で誰かに見せるAI下書きを、読み手・目的・根拠・リスク観点で提出前レビューするスキル。メール、記事、提案文、SNS告知、商品説明、調査まとめなどを公開・送信・提出する前に使う。
---

# AI下書き提出前チェック

## このスキルの目的

AIが作った「それっぽい下書き」を、仕事で誰かに見せてもよい状態か確認する。

単なる誤字脱字チェックではなく、以下を見る。

- 読み手に合っているか
- 読んだ人にしてほしい行動につながっているか
- 根拠が必要な主張に、資料・URL・データ・実体験などの裏づけがあるか
- 曖昧、言いすぎ、誤解されそうな表現がないか
- 最初に直すべき箇所はどこか

## 対象

仕事で誰かに見せる文章を対象にする。

例:
- メール
- 記事
- SNS告知
- 提案文
- 商品説明
- お知らせ文
- 企画メモ
- 調査まとめ

創作、日記、雑談、個人的な相談文は対象外ではないが、必要なら「仕事で誰に見せる前提か」を確認してからレビューする。

## レビュー前に必ず確認すること

レビューを始める前に、次の4点がそろっているか確認する。

1. チェック対象の下書き
2. 読み手
   - 例: 上司、取引先、既存顧客、初めて読む人、SNSフォロワー、社内メンバー
3. 読んだ人にしてほしいこと
   - 例: 返信してほしい、購入してほしい、理解してほしい、安心してほしい、承認してほしい
4. 文章の種類
   - 例: メール、記事、SNS投稿、提案文、お知らせ、商品説明、調査まとめ

この4点のどれかが不足している場合は、レビューを始めずに質問する。

ただし、ユーザーが「仮で見て」「前提はそちらで置いて」などと言った場合だけ、仮定を明記してレビューする。

## 任意で確認すること

根拠チェックの精度を上げるため、必要に応じて次を聞く。

- 参照してよい資料、URL、メモ、過去実績、データ
- 避けたい表現やトーン
- 文字数や媒体の制約
- すでに決まっている事実や数字

資料やURLがない場合、AIは根拠を作らない。
根拠が必要そうな箇所は「要確認」として出す。

## チェック観点

### 1. 前提との一致

- 読み手に合っているか
- 目的に合っているか
- 文章の種類に合っているか
- 期待する行動が読み手に伝わるか

### 2. 伝わりやすさ

- 最初に何の話かわかるか
- 重要な情報が埋もれていないか
- 順番が自然か
- 専門用語や内輪語が多すぎないか

### 3. 根拠・エビデンス

- 数字、比較、効果、実績、断定表現に根拠があるか
- 本文中に資料、URL、データ、実体験、出典が示されているか
- 根拠がないまま「業界初」「必ず」「大幅に改善」などと言っていないか
- 外部確認が必要な主張は何か

### 4. リスク表現

- 誇大表現
- 誤解されそうな表現
- 責任を負いすぎる表現
- 相手に失礼な表現
- 個人情報や機密情報の混入
- 法務、医療、金融、税務など専門判断が必要そうな断定

### 5. 修正優先度

- 最初に直すべき3点
- 後回しでよい軽微な点
- そのままでよい点

## デフォルト出力形式

ユーザーが形式を指定しない場合は、Markdownで次の形にする。

```md
## 前提
- 読み手:
- 読んだ人にしてほしいこと:
- 文章の種類:

## 総合判定
判定: そのまま出せる / 少し直せば出せる / まだ出さない方がいい
理由:

## 気になる点
| 優先度 | 該当箇所 | 気になる理由 | 修正方針 |
|---|---|---|---|

## 根拠チェック
| 主張・表現 | 根拠の有無 | 確認したい資料・URL・データ |
|---|---|---|

## 最初に直す3つ
1.
2.
3.

## 修正版の方向性

## 修正版
必要な場合のみ、全文または該当部分だけ出す。
```

## 出力形式の変更

ユーザーが希望する場合は、次の形式に切り替える。

- さっと見たい: 短い箇条書き
- しっかり確認したい: Markdown表つき
- そのまま直したい: 修正版つき

指定がなければ「しっかり確認したい: Markdown表つき」を使う。

## 修正版を出す前の照合

修正版を出す場合は、先に「根拠チェック」の各行と修正版を照合する。

「根拠なし」「提示なし」「要確認」とした主張は、修正版で次のいずれかに変える。

- 主張自体を削除する
- 「仮説」「可能性」「確認が必要」など、未確認であることが明確な表現にする
- 資料確認後に判断する条件付きの文にする

元の下書きにあったという理由だけで、未確認の主張を事実表現のまま修正版へ残さない。
別の言い回しへ変えただけで、同じ未確認主張を維持していないかも確認する。

修正版を確定する前に、次を点検する。

1. 根拠チェックで「根拠なし」「提示なし」「要確認」とした主張を抜き出す。
2. 修正版内で同じ主張や言い換えを探す。
3. 事実表現のまま残っていたら、削除・仮説化・条件付き表現へ直す。
4. 新しい数字、実績、対象読者、既存状況などを根拠なく追加していないことを確認する。

## 注意

- 根拠を捏造しない。
- 資料やURLが提示されていないのに「確認済み」と言わない。
- 外部情報が必要な場合は「要確認」として出す。
- 根拠なし・要確認と判定した主張を、修正版で事実表現のまま残さない。
- 法律、医療、金融、税務などの専門判断は断定しない。
- ユーザーが求めていない限り、本文を勝手に大きく書き換えすぎない。
- レビューは厳しめでよいが、相手を責める言い方にしない。

## 最初の応答

このスキルが呼ばれたら、まず次のように返す。

「AI下書き提出前チェックをします。下書きとあわせて、次の3つを教えてください。
1. 誰に見せる文章ですか？
2. 読んだ人にどう動いてほしいですか？
3. 文章の種類は何ですか？」