Paper Review

論文査読スキル（Claude 用）

音声言語情報処理系の国際会議論文・ジャーナル論文（Interspeech、ICASSP、IEEE/ACM Trans.、Speech Communication 等）を査読する際に用いる汎用ルール。paper_writing スキル（執筆側）と対になるスキルであり、執筆スキルに蓄積された品質基準（ハルシネーション検出・数値トレーサビリティ・語彙文体基準）を「チェックする側」の視点で適用する。

2つの利用モード：

1. 査読前ヒアリング【必須・スキル起動時に必ず実施】

査読作業を開始する前に、AI側からスキル実行者へ以下を必ず確認する。

1.1 査読種別の確認

「これはご自身の執筆中原稿の自己査読ですか？　それとも査読委員として他者の論文を査読しますか？」

1.2 投稿先とAI利用可否の確認【査読委員モードのみ】

他者論文の査読では、原稿は機密文書であり、査読者は内容を第三者に開示しない義務を負う。外部AIサービスへの送信はこの義務に抵触しうるため、以下のフローで確認する：

1. どの学会・ジャーナル・国際会議の査読かを質問する
2. 査読者向け注意書き（Reviewer Guidelines 等）のURLを提示してもらい、内容を確認する
3. 判断：
   • 外部AIへの送信が明示的に許容されている → 複数の外部AIを併用したマルチAI査読が可能
   • AIによる査読・原稿アップロードが禁止されている → その旨を実行者に説明し、(i) 原稿全文を外部に送らない査読方法（ローカル処理のみ）、(ii) AI査読の中止、を提案する
   • 案内が存在しない・言及がない → 「明示的な禁止がない」ことは「許可」を意味しない。査読の機密保持義務の一般原則と、出版元（IEEE等）のAI利用ガイダンスを説明したうえで、実行者に選択させる：
     • ローカルAI（Claude Code のサブエージェント等）のみで実施【推奨】
     • 外部AIにも全文を渡す（判断と責任は査読者）
     • 外部AIには匿名化・抜粋のみを渡す

1.3 評価項目・文量・トーンの確認

学会・雑誌ごとに査読の方式・文量・トーンは全く異なる。査読を行う前に必ず確認する：

1. 査読フォームの評価項目：フォームのコピー（テキストで可）を提供してもらう
2. 目標文量：コメントの文数・語数の目安。「過去に受け取った・書いた査読の例」があればプロジェクトフォルダ（.references/ 等）に入れてもらうことを提案し、内容ではなく文量・文数・トーンのみをそこから学ぶ
3. 過去例がない場合の参考値：国際会議の査読コメントは端的なことが多い（数文〜10文程度、問題点の指摘中心）。ジャーナルはより長く構造化される（Major/Minor 分けで数十項目もありうる）

2. 機密保持ルール【最重要・査読委員モード】

• 査読対象原稿の本文・タイトル・著者名・内容を外部サービスに送信・入力しない（Web検索クエリも含む）
• Web検索・WebFetch を使ってよいのは参考文献の書誌情報（タイトル・著者名・会議名）の検索のみ（公開情報のため）
• 査読対象PDF・査読結果・査読メモは Git管理（コミット）しない（.gitignore に追加）
• サブエージェントを起動する場合、各エージェントのプロンプトにこの機密ルールを明示的に書く（親の指示は自動では伝わらない）
• 査読報告書をHTML等で作成する場合も、ローカルファイルとして生成する（公開ホスティングへのデプロイ禁止）

3. 3観点並行査読ワークフロー

原稿1本につき、独立した3観点のチェックを並行実行し、最後にマージする。サブエージェントが使える環境では観点ごとに並行させると速い（複数論文 × 3観点の同時実行も可）。

3.0 前処理

• pdftotext で原稿PDFからテキストを抽出（一時作業領域に置く）
• 図表の確認が必要な場合は元PDFを直接読む

3.1 観点①：技術内容査読

• 論文サマリ：目的・提案手法（仕組みを具体的に）・実験設定（データ・ベースライン・指標）・主要結果（数値）・著者の主張する貢献を、査読者が原稿を読まなくても分かるレベルで整理
• 新規性の評価：先行研究（特に著者自身が引用しているもの）との差分は本質的か。引用しながら比較していない同一問題設定の文献はないか
• 実験設計：ベースラインの妥当性・公平性（チューニング不足の疑い、事前学習条件の不一致等）、テストセットの有無、単一ラン・統計検定の有無、データ分割の標準性（独自分割で外部比較不能になっていないか）
• 数値の整合性（必ず検算する）：
  • Abstract・本文・表・結論で同じ数値が一致するか
  • 表の平均・合計・差分を実際に計算し、本文の記載（「N pt 改善」等）と一致するか
  • 表の数値が引用文献の公表値と不自然に一致しないか（別指標のラベルで他論文の数値が転載されているケースが実在する。ベースライン値は原典の表と突き合わせる）
• 主張と証拠のギャップ：Abstract の主張が結果の一部と矛盾していないか（過大主張）。中心主張に直接の検証実験があるか
• 指標の定義：主要指標（latency、WER の算出条件等）が論文中で定義されているか。値のオーダーが常識と乖離していないか（乖離はトップライン欠如や指標取り違えのシグナル）

3.2 観点②：参考文献検証（ハルシネーション検出）

paper_writing §3.1 の検証手法を「査読する側」として全文献に適用する：

1. REFERENCES 節から全文献を抽出
2. 各文献の実在確認：arXiv・IEEE Xplore・ACL Anthology・ISCA Archive・Semantic Scholar・DBLP 等で検索し、タイトル・著者・年・掲載先を照合
3. DOI の解決先を必ず確認する（DOI が無関係の論文を指すのは捏造引用の典型的シグナル）
4. オープンアクセスのPDFはダウンロードし、本文中の具体的主張を伴う引用（「[X] は Y を示した」等）と実内容を照合
5. 捏造判定は慎重に：単一DBで見つからない＝即捏造ではない。複数DBで試し、それでも (a) タイトルがどこにも存在しない、(b) DOIが無関係論文を指す、(c) 著者・会議・年の組み合わせが実在論文と一致しない、が揃ったときに「捏造疑い」とフラグを立てる
6. 典型的な検出パターン：
   • 混成型捏造：実在論文のタイトル・著者・会議・DOIを混ぜ合わせた引用（LLMハルシネーションの典型）
   • 引用文脈の不一致：実在するが引用箇所の主張と無関係な論文（経験上、高頻度で発生する）
   • 書誌誤り：年・ページ・著者名スペル・会議名の誤り、同一文献の重複収録
7. 出力：検証サマリ（総数・OK・書誌誤り・齟齬・捏造疑いの件数）＋全文献の検証表＋問題文献の詳細

3.3 観点③：語彙・表現・AI執筆痕跡

paper_writing の speech_style_data.md（分野コーパス実測データ）を基準に検査する：

• BAN語・BANフレーズの出現（grep で計数・引用）
• LIMIT語の頻度超過、em-dash の使用回数（人間の相場は約0.4回/論文）
• 構造的AI臭：均質な段落長、(i)(ii)(iii)型三点列挙の多用、本文の箇条書き、修辞疑問文、同型パラレリズムの反復、人間マーカー表現（Note that / in order to 等）の完全欠如
• 編集事故の痕跡：一括置換による不自然な語（略語置換が単語内部に適用された合成語等）。これは執筆プロセスの粗さと、指標・用語が途中で変更された可能性の両方を示すシグナルなので、技術査読側と共有する
• 通常の言語品質：typo・文法・略語の初出フルスペル・表記ゆれ・図表参照の不整合・40語超の文の頻発
• 総合所見：AI執筆可能性を証拠ベースで評価する（BAN語ゼロ＋人間的な脱字が多ければ人間執筆と整合、など）。この所見の扱いは §5.2 参照

3.4 マージと成果物

3観点のレポートを統合し、以下を作成する：

査読作業フォルダ/<原稿ID>/
├── 01_technical_review.md    ← 観点①
├── 02_reference_check.md     ← 観点②
├── 03_language_check.md      ← 観点③
├── 04_final_review.md        ← 最終査読案（フォーム評点＋提出用コメント＋根拠）
└── 05_report.html            ← 査読者向け詳細報告書（下記）

• 04_final_review.md：査読フォームの全項目の評点案（根拠つき）、Comment for Authors（提出用・最終稿）、Comment to PC（該当時）、査読者が提出前に確認すべきポイント
• 05_report.html：査読者が原稿を読まなくても内容と判断根拠が分かる詳細報告書（自己完結HTML・外部リソース参照なし）。論文解説／技術評価／文献検証結果／文体所見／最終査読案（コメントの対訳つき）で構成
• 複数本を査読する場合は総括 index.html を追加

4. 査読コメント作成ルール

4.1 文量・トーン

• §1.3 で確認した評価項目・文量に厳密に合わせる。過去例があれば、その文数・語数の分布に収める（内容は真似ない）
• 端的に問題点を指摘する。長い総評・褒め言葉の羅列・全部盛りは避ける
• 取捨選択する：3観点のレポートから、判定を支える本質的指摘＋修正必須の実務的指摘のみを採用。落とした指摘は「不採用理由」とともに 04 に記録しておく（修正版査読時に再利用できる）

4.2 査読コメント自体のAI臭を排除する【重要】

査読コメントも speech_style_data.md の基準でセルフチェックする：

• em-dash 禁止、BAN語（underscore, pivotal, nuanced, delve, seamless, showcase, leverage, intricate 等）禁止
• (i)(ii)(iii) 型の整いすぎた列挙を避ける
• 普通の査読者が書く平易で直接的な英語にする（例：The comparison with X is missing. / Some typos: ...）
• 提出前に grep セルフチェック（speech_style_data.md §6.5 のパターン）を実行する

4.3 評点は「提案」である

• 全評点・Overall Recommendation・Reviewer's Confidence は提案として提示し、最終決定は査読者本人が行うことを毎回明記する
• Confidence は査読者本人の専門性に依存するため、根拠（検証の深さ）とともに提案し、調整を促す

5. 研究公正上の問題を発見した場合

5.1 著者向けコメントでは「事実」を書く

捏造疑い引用・数値転載疑い等を発見しても、著者向けコメントではAI使用や不正を断定しない。検証可能な事実のみを書く：

• ❌ This reference appears to be AI-generated.
• ✅ Reference [N] could not be verified: the cited title does not appear in the ISCA or IEEE databases, and the listed DOI resolves to an unrelated paper. Please provide correct bibliographic information.

5.2 Comment to PC（委員会向け欄）の使い方

• 捏造疑いの具体的な検証経緯（どのDBで確認し、DOIがどこへ解決したか）
• AI執筆痕跡の所見（証拠を列挙し、断定は避ける）
• 数値転載疑い（どの原典のどの表と一致したか）
• 会議のポリシー（引用正確性・AI執筆）との照合を委員会に委ねる旨

を、著者向けとは分けて率直に記載する。文体所見のみを不採録理由にしないことを推奨（採否は技術的内容で判断し、文体は補強証拠に留める）。

5.3 査読者本人による再確認

捏造疑いDOI等の重大指摘は、提出前に査読者本人がブラウザで再確認する手順を 04_final_review.md に明記する。

6. 自己査読モード（論文執筆時の発動）

paper_writing で執筆中の原稿に対し、本スキルの §3 をそのまま適用してセルフレビューを行う。実際の査読に近いチェックを投稿前に受けられる。

• タイミング：paper_writing Phase C の各章完成時（軽量版：観点①③のみ）、Phase D の投稿前（フル版：3観点＋マージ）
• 自分の原稿なので外部AIの利用制限はない（§1.2 は不要、§1.3 は投稿先のフォーム・文量で設定）
• 観点②（参考文献検証）は paper_writing §3.1 の検証フローと共通。執筆時に検証済みなら差分（新規追加文献）のみでよい
• 自己査読で「捏造疑い」「数値不整合」が出た場合は、paper_writing §8.4.Y / §8.8 の手順で修正する
• 評点案（Accept〜Reject）も出させると、投稿先とのレベル感の判断材料になる

7. 運用メモ

• 3観点の並行実行は1本あたりの実時間を大きく短縮する。複数本の査読では「本×観点」の全組み合わせを同時に走らせてよい
• 参考文献検証は最も時間がかかる（1本あたり数十件のWeb照合）。先に起動しておく
• ダウンロードした文献PDFは一時領域ではなく**プロジェクト内の専用フォルダ（Git管理外）**に保全する
• 検算・文献照合で発見した事実は、査読レポートに「検証経緯（どのDB・どのURL・何と一致/不一致）」を必ず残す。査読者本人の再確認と、後日の照会対応のため