# Paper Review

> 音声言語情報処理系の国際会議論文・ジャーナル論文の査読（他者論文の査読委員としての査読、および執筆中原稿の自己査読）に用いる汎用スキル。査読前ヒアリング、機密保持、3観点並行チェック（技術内容・参考文献検証・語彙表現）、査読コメント作成をカバー。paper_writing スキルと対で使用する。

- Skill: `sayonari/paper-review` (Agent Skill)
- Install (CLI): `npx skillmds@latest add sayonari/paper-review`
- Raw SKILL.md: https://api.skillmd.com/api/skills/sayonari/paper-review/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: sayonari (https://skillmd.com/u/sayonari)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/sayonari/paper-review

---


# 論文査読スキル（Claude 用）

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

**2つの利用モード**：

| モード | 対象 | 外部AIの利用 |
|---|---|---|
| **A. 査読委員モード** | 他者の投稿論文を査読委員として査読 | §1 の確認フローを通過した場合のみ |
| **B. 自己査読モード** | 自分が執筆中の原稿をセルフレビュー | 制限なし（自分の原稿のため） |

---

## 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・何と一致/不一致）」を必ず残す。査読者本人の再確認と、後日の照会対応のため