Claudeで査読コメントへの回答書を下書きする — 原稿と照らして修正済みの誤記を防ぐ

査読コメントへの回答書(response to reviewers)で一番まずいのは、「ご指摘のとおり修正しました」と書いたのに、原稿のその箇所が直っていないことです。改訂の最終盤には、修正案、新旧の原稿、査読コメントが別々のファイルに散らばります。書いた本人の記憶だけでは、どこまで直したかを追いきれません。

ClaudeのProjectsに原稿と査読コメントを置くと、コメントごとに「該当箇所」「修正案」「反論の根拠」を並べた下書きを作れます。この記事では、その作り方と、修正済みと書いた主張を改訂原稿と突き合わせる二段目の確認を順に示します。

回答書の下書きでClaudeに任せる範囲

Claudeに任せるのは、コメントと原稿の対応づけ、回答文の叩き台、修正案の選択肢の列挙までです。反論してよいか、どの程度直すか、新しい解析を追加するかは著者が決めます。ここをClaudeに委ねると、原稿に無い解析を「実施した」と書く文面が混ざりかねません。

Projectsは、チャット履歴とナレッジベース(知識ベース)を持つ独立した作業場です。プロジェクトには文書、文章、コードなどのファイルを置け、Claudeはそれを個々のチャットの文脈として使います。プロジェクトごとに指示(project instructions)も設定できます。回答書のように同じ原稿を何度も参照する作業に合います。

原稿と査読コメントをProjectsに置く

ファイルの用意

置くものは次の4種類です。ファイル名は中身が分かる名前にしておきます。ファイル名で指定して聞けるため、検索の手がかりにもなります。

• 投稿時の原稿(例: manuscript_v1_submitted.pdf)
• 改訂中の原稿(例: manuscript_v2_revised.docx)
• 査読コメント全文(例: reviewer_comments.txt。レビュアーごとに分けず1ファイルでもよい)
• 編集者からの決定通知(例: editor_letter.txt)

投稿時の版と改訂中の版を別ファイルで置くのは、後半の照合で「何が変わったか」を見るためです。変更履歴付きのWordが、修正前後のどちらをどう読まれるかは、Projectsの公式ヘルプに記載がありません。変更を反映したクリーン版と、投稿時の版を別ファイルにしておくのが無難です。

ファイル形式と上限

プロジェクトに置くファイルの上限は1ファイル30MBです。ファイル数に上限はなく、全体の中身がClaudeのコンテキストウィンドウに収まることが条件になります。内容は原則としてテキストが抽出されます。PDFだけは例外で、100ページ以下ならグラフや図などの視覚要素も解析されます。101〜1000ページのPDFはテキストのみで、1000ページを超えるものはアップロードできません。

Wordなど非PDFの文書は、テキストだけが抽出され、埋め込まれた画像は読み取られません。図の説明を求める査読コメントがある場合、図を含む原稿はPDFで置くほうが確実です。「図3の軸ラベルが小さい」のような指摘は、画像を読み取れない形式では原稿側の確認ができません。

ページを指して聞くときは、原稿に印字されたページ番号ではなく、PDFビューアーで表示されるPDF上のページ番号を使うよう公式ヘルプが案内しています。回答書に載せるページ番号とは別物になるので、ここで混同しないよう、下書きの段階で「PDF上のページ」と明記してもらいます。

有料プランのRAGモードに注意する

有料プラン(Pro / Max / Team / Enterprise)では、知識ベースがコンテキストウィンドウの上限に近づくとRAGモードに自動で切り替わり、容量が最大10倍まで広がります。RAGモードでは、全文を読み込まず、プロジェクト知識検索ツールで関連箇所を探して答えます。切り替えの有無は画面の表示で分かります。

査読対応のプロジェクトでは、補足資料や参考文献のPDFを足していくとRAGに入りやすくなります。RAGに入ると、原稿の該当節が検索で拾われず、見落とされる可能性があります。コメント照合では、次の2つを徹底します。

• 聞くときに文書名と節を指定する(「manuscript_v2_revised.docx のMethods 2.3」)
• 該当箇所は、原稿の文言をそのまま引用させる

引用させておけば、Claudeが見つけた箇所が本当に原稿にあるかを、著者が検索で一度に確かめられます。

プロジェクト指示に入れる規約

回答書の作業では、プロジェクトの指示に次のような規約を置くと、毎回の聞き方が短くなります。下は例示で、そのまま使う文面ではありません。

あなたは論文の改訂作業を手伝います。
- 原稿の記述は、必ずファイル名・節番号・原文の引用で示す
- 原稿に該当する記述が見つからないときは「見つかりません」と答える
- 実施していない解析や実験を、実施済みとして書かない
- 修正案は「案」と明記し、採否は著者が決める
- 査読者の指摘に同意できない点は、反論の根拠を原稿の記述から示す

「見つからないときは見つからないと答える」を入れておくと、存在しない記述を作って埋める失敗を減らせます。ただし、これで確実に防げるわけではありません。次の二段目の照合で別に確かめます。

コメントごとに「該当箇所・修正案・反論の根拠」を並べる

論点に分解して対応表を作る

査読コメントは、1つの文章に複数の論点を含むことがよくあります。「サンプルサイズが小さく、統計手法の記述も不足している」という1文は、サンプルサイズと統計手法の2論点です。回答書で片方だけに答えて見落とすのは典型的な失敗なので、先に論点へ分解します。

聞き方の例を示します。

reviewer_comments.txt の Reviewer 2 の全コメントを、
1論点1行に分解して表にしてください。
列は「コメント番号 / 論点 / 要求の種類(追加解析・記述の追加・
文言修正・反論可) / manuscript_v2_revised.docx の該当節と原文引用」です。
該当箇所が原稿に無いものは「該当なし」と書いてください。

要求の種類を列に入れるのは、あとの手順を分けるためです。「文言修正」は短時間で終わり、「追加解析」は著者が実施しなければ回答書に書けません。「反論可」は、根拠を原稿から示せるかが問われます。

修正案と反論の根拠を並べる

対応表の各行に、修正案と反論の根拠を足します。ここで大事なのは、案に「状態」の列を付けることです。

回答文を書かせる前に、状態を著者が埋めます。Claudeに「状態を判断して」と任せると、原稿に反映されていないのに反映済みと書く原因になるためです。状態の列は著者が埋め、Claudeにはその状態に合う文面を書かせます。

添付の対応表のうち、状態が「原稿に反映済み」の行について、
Reviewer への回答文の叩き台を書いてください。
回答文には、改訂原稿の節番号とページ(PDF上のページ)を含めてください。
状態が「反論のみ」の行は、反論の根拠として使える原稿の記述を
引用で示してください。「要追加作業」の行は文面を書かず、
何が必要かだけ列挙してください。

こう分けると、「要追加作業」の行に、実施していない作業を「実施した」と書く余地がなくなります。

「修正済み」と書いた箇所を改訂原稿と照合する

別チャットで、回答文と改訂原稿だけを突き合わせる

回答書の叩き台ができたら、ここからが本題です。下書きを作ったチャットとは別のチャットを新しく開き、改訂原稿と回答文だけで照合します。同じチャットで続けると、直前の会話に引きずられて「直っているはず」という前提で答えがちです。

プロジェクト内のチャットは、知識ベースに置いたファイルを共有します。一方、別のチャットでの会話は引き継がれません。そこを逆手に取る使い方です。照合用のチャットには、回答文のテキストを貼り付けます。

次の回答文には「修正した」「追記した」という記述があります。
それぞれについて、manuscript_v2_revised.docx に実際にその修正が
あるかを確認してください。
- 修正が確認できる行: 節番号と原稿の該当文を引用で示す
- 確認できない行: 「確認できない」と書き、理由を一言
- 回答文の言う内容と原稿の文言が食い違う行: 両方を並べて示す
引用できない行を「ある」と判断しないでください。

結果の読み方

出力は、3種類に分けて読みます。

「確認できる」の判定でも、引用の実在確認は省けません。引用が原稿の文言と1語違うだけで、別の版の記述を引いている場合があるためです。投稿時の版と改訂中の版の両方がプロジェクトにあるなら、「改訂版の記述だけを引用すること。投稿時の版の文は引用しないこと」と条件に書いておきます。

数値と図表番号は別枠で見る

回答文に書く数値(サンプルサイズ、p値、効果量)と図表番号は、書き間違いが起きやすい箇所です。次の観点は、Claudeの照合とは別に、著者が表を見て確認します。

• 回答文の数値が、改訂原稿の本文と表で一致しているか
• 改訂で図表を追加・削除したときに、番号がずれていないか
• 「Table 2に追加した」と書いた表が、改訂原稿にその位置と内容で存在するか

統計値の照合そのものは、生データを使う別の手順になります。手順はClaudeで論文の統計値を生データと照合して検証するにあります。

回答書をまとめる前の最終点検

下書きがそろったら、提出前に次の順で見ます。

最後の「版を揃える」は、改訂が複数回あると崩れやすいところです。改訂のたびに原稿を差し替えるときは、古い版をプロジェクトから外すか、ファイル名で最新版が一目で分かるようにします。

先行研究の引用を足す場合

査読で「この研究を引用すべき」と指摘されることがあります。その文献をプロジェクトに追加して要点を読ませる場合は、論文PDFの読み方に関する英語論文PDFをClaudeで読む方法が参考になります。文献を足したあとは、本文の引用と参考文献リストの突き合わせも要ります。点検の手順はClaudeで卒論の参考文献と本文引用を点検する手順にまとめています。文献探しの段階から整理したいときは、Claudeで文献レビューの計画を立てるが入り口になります。

共有範囲と未公開原稿の扱い

投稿中の原稿と査読コメントは、まだ公開されていない資料です。Team / Enterpriseプランでは、プロジェクトを組織のメンバーと共有できます。共有の権限は「閲覧のみ」と「編集可」の2段階で、プロジェクトの作成者が個別の共有か組織全体への公開かを選びます。共著者と同じ組織なら、共有で原稿の確認を分担できますが、組織の管理者が共有を止めている場合は使えません。

プロジェクトの作成時は、可視性の設定を確認します。投稿先の投稿規程や所属機関のAI利用方針が、未公開原稿や査読コメントを生成AIに入力することを制限している場合があります。入力の可否は投稿先と所属機関の規程で決まるので、プロジェクトに置く前に確認します。

よくある質問

回答書の英文そのものをClaudeに書かせてよいか

文面の叩き台としては使えます。ただし、事実の記述(何を修正したか)は、前章の照合を通してから採用します。投稿先がAI利用の開示を求める場合は、その規程に従います。

査読コメントが長く、レビュアーが3人いる場合はどう置くか

1ファイルにまとめても、レビュアーごとに分けても構いません。分ける場合はファイル名に reviewer1 のように番号を入れ、対応表の「コメント番号」列に R1-3 のような形式で書くと、回答書の見出しと対応づけやすくなります。

再投稿のたびにプロジェクトを作り直すべきか

同じ論文の再改訂なら、同じプロジェクトにファイルを追加できます。古い版は外すか、ファイル名に版を入れて区別します。別の論文は、別のプロジェクトに分けます。プロジェクトは作業場ごとにチャット履歴とナレッジベースを持つためです。