Claudeに下書きを読ませて論理の穴を探す：校正ではなく査読役にする頼み方

先に決めておくこと：何を渡し、何を任せないか

Claudeに渡すのは次の4点です。

• 下書き本文：全文を貼ります。
• 想定読者：誰が、何に困って、この記事を開くのか。
• 記事の主張を一文で：書き手が「この記事で言いたいこと」と考えている内容。Claudeが読み取った主張とズレていれば、それ自体が重要な指摘になります。
• 除外事項：誤字、表記ゆれ、文体の好み、書き換え案は不要と書きます。

任せないのは次の3つです。

• 事実の真偽の断定。「この数字は誤りです」と言われても、一次資料で人が確認します。
• 記事の方向の決定。
• 指摘をそのまま反映した修正。

依頼文を整える前に、公式資料が前提として挙げている点も押さえておきます。Anthropicのプロンプト設計の概説は、成功基準と、それを試す方法を先に持っておくことを前提にしています。技法として、明確さ、例、XMLによる構造化、役割付与などを紹介しています（Prompt engineering overview、Prompting best practices）。この記事の依頼文は、これらの技法を査読向けに応用したものです。「採用できる指摘が何件出たか」は運用上の目安として使えますが、公式資料が示す成功基準ではありません。

未公開原稿や社外の情報を貼るとき

Anthropicの発表では、モデル改善への利用設定はFree・Pro・Maxのアカウントに適用され、許可すると新規または再開したチャットなどの保持期間が5年、許可しない場合は30日とされています。Claude for Work（Team・Enterpriseを含む）、Government、Education、APIなどの商用規約下のサービスは対象外です（Updates to Consumer Terms and Privacy Policy）。これは2025年8月の発表に記載された条件です。適用範囲や設定は変わりうるため、利用時は自分のプランの現行の案内を確認してください。

これは「学習に使うか」の話で、秘密保持を保証するものではありません。取引先名、未発表の数値、個人情報は、貼る前に「A社」「約◯件」のような仮の表現に置き換えてください。

査読役に渡す依頼文の型

次の依頼文の 【】 を埋めて使います。XMLタグで区切っているのは、指示・背景・原稿が混ざらないようにするためです。

あなたは、記事の公開前に論理だけを点検する査読者です。
文章の校正者ではありません。

<reader>
【想定読者と、その人が記事を開く理由】
</reader>

<claim>
【この記事で言いたいことを一文で】
</claim>

<draft>
【下書き全文】
</draft>

<task>
次の2つの観点だけで指摘してください。
A. 主張と根拠の飛躍：根拠が示されていない、根拠から言える範囲を超えている、
   原因と結果が逆かもしれない、特定の条件でしか成り立たない話を一般化している。
B. 読者の疑問の抜け：想定読者がその段落を読んで次に思うはずなのに、
   本文で答えていない疑問。
</task>

<rules>
- 誤字脱字、表記ゆれ、文体、言い回しは指摘しない。
- 書き換え案や修正後の文章は書かない。
- 指摘は重要度の高い順に最大7件まで。穴が少なければ少なくてよい。
- 各指摘に次を付ける：
  ①原稿からの引用（20字程度、原稿にある文言のまま）
  ②観点（AまたはB）
  ③何が飛んでいるか（1〜2文）
  ④重要度（高：主張が崩れる／中：説得力が落ちる／低：気になる程度）
  ⑤直すために書き手が決めるべきこと（質問の形で1つ）
- 事実の真偽は断定しない。確認が必要な箇所は「要確認」と書く。
- 最後に、あなたが読み取ったこの記事の主張を一文で書く。
</rules>

この型のポイント

「最大7件」と上限を切る：上限がないと、些細な指摘まで並んで仕分けの手間が増えます。7件は目安なので、記事の長さに合わせて調整してください。

⑤を質問形式にする：「ここを直してください」ではなく「どちらを言いたいのか」と返させると、書き手が判断する形になります。

最後に主張を読み取らせる：自分が書いた <claim> と読み取られた主張が違えば、個別の指摘より先に構成を見直す合図です。

返ってきた指摘を仕分ける

指摘は、次の表の条件で採用・保留・却下に分けます。判断の基準は編集上の提案で、公式の仕様ではありません。

• 採用、条件：引用が原稿に実在する。読者がそこでつまずくと自分でも思う。直す方向を決められる、次にやること：修正する。直したら印をつける
• 保留、条件：もっともらしいが、確認に資料やデータが要る。または自分の意図がまだ決まっていない、次にやること：確認事項に書き出し、期限と確認先を決める
• 却下、条件：引用が原稿にない。想定読者に不要。本文ですでに答えている。好みの問題、次にやること：理由を一行だけ残す

仕分けの順番は次のとおりです。

1. まず引用を原稿で検索し、実在するか確かめます。ない指摘は、中身を読む前に却下です。
2. 次に、指摘された段落を想定読者の立場で読み直します。
3. それでも判断できないものは、無理に決めず保留にします。

却下の理由を残すのは、同じ指摘が次の原稿で出たときに迷わないためです。「3回続けて同じ却下理由が出る」なら、依頼文の <reader> や <rules> が足りていない可能性があります。依頼文を直す手がかりになります。

運用例（説明用の例）

以下は、型の使い方を示すために私が作った架空のやり取りです。Claudeで実際に実行した結果ではありません。実際の返答は文言も件数も変わります。

想定読者：個人ブログを運営していて、タイトルの付け方を見直したい人

主張：検索からの流入を増やすには、タイトルに数字を入れるとよい

下書きの一部

検索流入を増やしたいなら、タイトルに数字を入れましょう。数字入りのタイトルはクリックされやすいからです。実際、私のブログでも効果がありました。

査読役の指摘（想定される形の例）

• 1、引用：「クリックされやすいからです」、観点：A、指摘：根拠が示されていない。主張は「流入が増える」だが、根拠はクリック率の話で、順位や表示回数とは別の指標、重要度：高
• 2、引用：「効果がありました」、観点：A、指摘：何をどれだけ比べたのかがなく、他のブログに当てはまるか判断できない、重要度：高
• 3、引用：「数字を入れましょう」、観点：B、指摘：読者は「どんな数字を、どこに入れるか」「入れてはいけない場合はあるか」を知りたいはずだが、答えがない、重要度：中
• 4、引用：「タイトルに」、観点：B、指摘：「自分のジャンルでも同じか」という疑問に答えていない、重要度：中

書き手の仕分け（例）

• #1は採用：主張を「クリックされやすくなる」に絞り、流入との関係は別の段落で扱うことにします。
• #2は保留：自分のサーチコンソールのデータに期間と比較対象があるか確認します。なければ「効果があった」の一文を削ります。確認は本人が行い、Claudeに数値を言わせません。
• #3は採用：数字の入れ方の例を追加します。
• #4は却下：この記事は個人ブログ向けと冒頭で限定しており、ジャンル別の検証は別記事で扱う予定のため、理由を一行残します。

#4は「読者の疑問」としては妥当な指摘でも、記事の範囲外なら却下できます。査読役の指摘が正しいことと、今回の記事で対応すべきことは別です。

仕上げに：2回目の読ませ方と、使い続けるための記録

修正したら、同じ依頼文で新しい会話に貼り直します。前の会話を引き継ぐと、直した箇所を前提にした甘い読みになりやすいので、別の会話で読ませるのが無難です（これも提案で、効果を測ったわけではありません）。

記録は、仕分け表に3列で十分です。

• 指摘の要約
• 判定（採用・保留・却下）
• 理由

数本分たまったら、採用の多かった観点と、却下が続く観点を見比べます。却下が多い観点は <rules> から外すか、読者像の説明を足します。採用が多い観点は、公開前のチェック項目として固定できます。

Claudeの指摘は、あくまで候補です。引用の誤り、読者像のズレ、原稿の範囲を超えた要求は起こりえます。そのため、仕分けの最初の1手は必ず引用の実在確認、事実関係は一次資料での確認、というように人が確かめる手順を外さずに使ってください。