学会の論文誌の事務局が、届いた査読報告を Claude で指摘ごとに分け、著者への通知文の下書きと査読者どうしの判定の食い違いを担当編集委員に示す

処理の起点を決める

論文の査読報告がすべてそろったことを起点にします。 投稿審査システムの状態（「査読完了」「判定待ち」など）を、Python から1時間ごとに確かめ、新しくその状態になった論文だけを処理します。システムに状態の変化を外へ知らせる仕組みがあれば、それを使います。

1名分の報告が届くたびには動かしません。 食い違いは全員分がそろって初めて分かり、途中で送り状を作ると、残りの報告が届いた後に作り直しになります。ただし、締切を2週間過ぎても1名の報告が届かない論文は、届いている分だけで送り状を作り、「1名未着」と明記して編集委員に判断を仰ぎます。

判定の後の通知文は、担当編集委員が判定と所見を投稿審査システムに入れたことを起点に作ります。メールで返ってくる運用なら、事務局の職員が判定を入れた時点を起点にします。

入力データを集める

投稿論文の本文は入力に入れません。 指摘の切り分けと食い違いの整理は、報告だけで足ります。本文を渡さないことで、外部のサービスに出す資料を最小にします。

再査読では、前回の指摘の一覧を一緒に渡します。 査読者が「前回の指摘3は解消された」と書いていれば、どの指摘のことかを前回の一覧で引けます。前回の一覧が無いと、解消された指摘と新しい指摘の区別がつきません。

データの取得方法を決める

1. 報告の取り出し … 投稿審査システムから、論文ごとに査読報告を書き出します。欄ごとに分かれた形（CSV・JSONなど）で取れるならそれを使い、PDFでしか出せないなら PDF のまま扱います
2. 欄の分離 … 著者あての欄、編集委員あての欄、推奨判定を別の項目として持ちます。編集委員あての欄は、この段階でAIに渡す入力から外します
3. 前回の一覧の取得 … 再査読なら、前回の処理で保存した指摘の一覧（番号付き）を引きます
4. 査読者の情報の取得 … 氏名・所属・研究室名を、照合のための一覧にします

2番目は、プログラムで項目として分けます。 AIに「編集委員あての部分は無視して」と指示するのではなく、そもそも渡しません。 渡したうえで使わないように頼む設計は、いつか通知文に紛れます。

AIへ渡す前に整形する

1. 形式の確認 … 文字のデータか PDF かを確かめます。PDF はパスワードの有無を確かめ、かかっていれば事務局に回します
2. 査読者の匿名性の確認 … 著者あての欄から、査読者の氏名・所属・研究室名と、「私の論文」「私たちのグループ」など自分の研究を名乗る表現を探し、見つかった箇所に印を付けます
3. 編集委員あての表現の検出 … 著者あての欄に「編集委員へ」「Editor」「not for the authors」などの語があれば印を付けます
4. 長さの確認 … 報告が極端に短いもの（数行）や、推奨判定が空のものに印を付けます
5. 個人情報の確認 … 査読者が著者の個人的な事情に触れていれば印を付けます
6. 報告の番号付け … 査読者を「査読者A・B・C」と置き換えます。AIに渡すのは置き換えた後の記号だけです

2番目と3番目は、AIより先にプログラムで行います。 決まった語の照合は機械のほうが確実で、見つかった箇所はAIの結果にかかわらず送り状の冒頭に出します。 AIにも同じ観点で確かめさせますが、それは取りこぼしを拾うための二重の網です。

AIに処理させる

いちばん効くのは、表の6行目の「中身が正反対のもの」です。 判定の割れは推奨判定の欄を見れば機械でも分かりますが、中身の食い違いは文を読まないと分かりません。 事務局が見落としやすく、著者からの照会の元になっているのはこの型です。

指示内容を固定する

あなたは学会の論文誌の編集事務局で、査読報告を取りまとめる補助をします。
渡すのは、1本の投稿論文に対する複数の査読者の「著者へのコメント」だけです。
論文の本文は渡していません。論文の中身の良し悪しを判断しないでください。

【させること】
1. 各査読者のコメントを、1つの要求または1つの問題点の単位に分けてください。
2. 各指摘に category と severity を付けてください（値は下の一覧から）。
3. 各指摘の根拠にした原文を quote に一字一句そのまま写してください。
   要約・言い換え・語順の変更・誤字の修正をしないでください。
4. 別の査読者が同じ論点を指摘していれば、同じ issue_group を付けてください。
5. 査読者どうしで推奨判定が異なるもの、指摘の中身が反対のもの
   （一方が追加を求め、他方が不要と書いている等）を conflicts に挙げてください。
6. 著者あてのコメントの中に、査読者自身を特定できる記述
   （氏名・所属・自分の論文や研究室への言及）や、編集委員に向けた記述があれば
   leak_flags に挙げてください。

【category】novelty / method / interpretation / statistics /
            literature / presentation / ethics_data
【severity】major（修正しないと採録できないと読める）/
            minor（修正が望ましい）/ question（質問・確認）
  原文から読み取れないときは unclear にしてください。

【厳守事項】
- 採否を推奨したり、判定を予想したりしないでください。
- 指摘が正しいか、もっともかを評価しないでください。
- どちらの査読者に従うべきかを書かないでください。
- 原文に無い指摘を補わないでください。
- 査読者が誰かを推測しないでください。
- 前回の指摘の一覧が渡されたときは、査読者が解消・未解消と明記している
  ものだけを対応づけてください。明記がなければ not_mentioned にしてください。

【論文の情報】{paper_meta}
【前回の指摘の一覧】{previous_issues}
【査読報告（査読者A・B・C）】{reports}

「誤字の修正をしないでください」まで書くのは、AIが善意で直すからです。 査読者の誤字を直した quote は、プログラムでの照合に通らず、すべて人の確認に回ってしまいます。原文と一字も違わないことが、照合の前提です。

「明記がなければ not_mentioned」も同じ理由で入れます。 何も言わないと、査読者が触れていない前回の指摘まで「解消」と推し量って埋めます。触れていないという事実が、編集委員には大事な情報です。

出力形式を固定する

{
  "paper_id": "",
  "round": "initial | revision",
  "recommendations": [
    { "reviewer": "A", "recommendation": "accept | minor | major | reject | none" }
  ],
  "issues": [
    { "id": "A-01", "reviewer": "A", "issue_group": "G1",
      "category": "method", "severity": "major | minor | question | unclear",
      "summary": "", "quote": "" }
  ],
  "conflicts": [
    { "type": "recommendation | content", "issue_groups": ["G3"],
      "reviewers": ["A", "C"], "description": "" }
  ],
  "previous_issue_status": [
    { "previous_id": "", "reviewer": "", "status": "resolved | unresolved | not_mentioned", "quote": "" }
  ],
  "leak_flags": [
    { "reviewer": "", "kind": "identity | editor_only | personal", "quote": "" }
  ]
}

1つ目の理由は、quote をプログラムで照合できることです。 受け取った後、各 quote が元の報告にそのまま含まれているかを文字列で確かめます。含まれていない指摘は、AIが言い換えたか作ったものなので、送り状で「原文と一致せず」と表示します。

2つ目は、送り状を毎回同じ形にできることです。 issue_group ごとに指摘を並べ、「G1：統計の扱い（A・B・C が指摘、うち2名が major）」のように出します。職員によって送り状の書き方が変わることがなくなります。

3つ目は、leak_flags を前処理の結果と合わせて出せることです。 プログラムで見つけたものとAIが見つけたものを1つの表にし、どちらか一方でも挙げた箇所は、職員が必ず目で見ます。

送り状は次の形で担当編集委員に送ります。

【論文番号】J-2026-0412（再査読）
【推奨判定】A：minor ／ B：major ／ C：minor
【食い違い】G3（追加実験）：A は不要、B は必須と記載
【主な論点】G1 統計の扱い（A・B・C）／G3 追加実験（A・B）…
【前回の指摘】解消 5 ／ 未解消 2 ／ 言及なし 1
【確認が要る箇所】査読者B の著者あての欄に所属への言及（事務局で削除の要否を確認中）

システムへ連携する

投稿審査システムには書き込みません。 判定の入力も、著者への送付も、これまでどおり人が行います。この構成が作るのは下書きまでで、送信のボタンは職員が押します。

通知文の組み立ては、AIではなくプログラムで行います。 判定に応じた定型文を選び、編集委員の所見（職員と編集委員が確かめたもの）と、査読者の著者あての欄の原文をそのまま差し込みます。AIの出力の summary は送り状にだけ使い、著者には送りません。

人が確認する

1. 送り状を送る前（事務局） … leak_flags と、quote が原文と一致しなかった指摘を先に見ます。そのうえで conflicts が報告の原文と合っているかを確かめます
2. 判定（担当編集委員） … 送り状と、必要なら報告の原文を読んで判定と所見を決めます。AIの整理は材料で、判定は編集委員が報告の原文に基づいて行います
3. 通知文を送る前（事務局） … 差し込まれた査読コメントが著者あての欄だけであること、leak_flags の箇所の扱いが決まっていることを確かめます
4. 送る前の了承（担当編集委員） … 所見の下書きを直したものを、編集委員が了承します

1番目で leak_flags の箇所を事務局が勝手に消さないでください。 査読者のコメントを削るかどうかは、担当編集委員か査読者本人に確かめて決めます。消すのも、査読者の言葉を変えることだからです。

目標は、1件15分です。 送り状の確認に5分、編集委員とのやり取りの取りまとめと通知文の確認に10分を見込みます。食い違いのある論文は15分を超え、判定が一致していて指摘の少ない論文は数分で終わります。

例外に対処する

4行目の「報告が短い」をAIに補わせないことが大事です。 短い報告からAIが指摘をふくらませると、査読者が書いていない要求が著者に届きます。短いことは、そのまま編集委員への情報にします。

記録を残す

• 取り出した査読報告（欄ごと）と、AIに渡した入力の全文
• AIの出力のJSONと、quote の照合結果
• 前処理で見つけた leak_flags と、その扱い（削除・そのまま・査読者に確認）と決めた人
• 担当編集委員に送った送り状と、返ってきた判定・所見
• 著者に送った通知文の版と送付日時
• 再査読のための指摘の一覧（論文番号と回の番号付き）

最後の行が、次の再査読の入力になります。 前回の指摘の一覧が残っていないと、再査読で「解消されたか」を対応づけられません。論文番号と回の番号で引けるように保存します。

leak_flags の扱いの記録は、査読の運用を見直す材料になります。 同じ査読者が毎回著者あての欄に所属を書いているなら、査読依頼の案内を直すほうが早いです。

保存先は、投稿審査システムと同じ権限で守られた場所にします。 送り状とAIの出力には、査読者の記号と推奨判定が並んでいます。記号と査読者の対応表は別の場所に分けて持ち、両方を見られる人を事務局の担当者と編集委員長に限ります。 保存の期間は、論文誌が査読の記録を残す期間に合わせ、それを過ぎたものは入力の全文から先に消します。