manuscript-review

原稿レビュー スキル

パイプライン上の位置： フェーズ 1a（内容監査）。figure-rhetoric と並行して実行されます。事前依存関係はありません。出力は manuscript-provenance（マクロマニフェストへのフィードバック）と figure-rhetoric（視覚的な論証評価のための主張マップ）で使用されます。出版前の網羅的なチェックについては、関連スキルを参照してください：manuscript-typography（タイポグラフィの規則）、citation-audit（引用の正確性）、arxiv-preflight（投稿要件への準拠）。

目的

学術論文または技術原稿に対して、複数のパスによる包括的な診断監査を実施し、24 の監査項目にわたる問題を特定した構造化された改善レポートを作成します。対象は、マクロレベルの一貫性や論証の構成から、主張と根拠の調整、ナラティブの流れ、文章の微細構造、レンダリング後の視覚的な検査、要素間の一貫性、さらには引用の健全性や再現可能性にまで及びます。

出力は、優先順位を付けた実行可能な改善計画であり、行単位の編集ではありません。目的は、著者が文章に近すぎるために体系的に見落としがちな、構造、論理、明瞭さに関する問題を明らかにすることです。

arXiv／プレプリントへの投稿を想定して最適化されており、準拠基準には柔軟に対応します。

関連スキル：manuscript-provenance は、原稿の内容（数値、表、図、順序、用語）がコードやスクリプトから計算によって導出されているかを監査します。このスキルは文書を文章として監査し、関連スキルは計算上の根拠を監査します。出版前の網羅的なチェックを行うには、両方を実行してください。

manuscript-provenance との境界に関する合意

懸念事項	このスキル（manuscript-review）	manuscript-provenance
再現可能性	論文には再現に必要な情報が十分に記載されていますか？（§6）	コードは実際に論文の主張どおりの結果を生成していますか？（§1、§7）
図表	判読可能で、アクセスしやすく、適切にフォーマットされていますか？（§12）	手作業で入力せず、スクリプトで生成されていますか？（§2、§3）
レンダリングされた図版	印刷時のサイズで読みやすく、参照箇所の近くに配置されていますか？（§23）	図の生成スクリプトは正しい形式を出力していますか？（§3）
ハイパーパラメーター	論文に根拠とともに記載されていますか？（§6）	値の出所はハードコードされた値ではなく、設定ファイルですか？（§1、§8）
コードの利用可能性	論文に記述がありますか？（§17）	リポジトリの URL は有効で、README は正確で、パイプラインは動作しますか？（§11）
用語	文書内で略語の使い方が一貫していますか？（§14）	用語はコード識別子と一致していますか？（§5）
有効数字	文書内で精度が一貫していますか？（§12）	精度はスクリプトの出力と一致していますか？（§2）
図の形式	文書の品質に適した形式ですか？（§12）	手動でエクスポートせず、スクリプトで生成された形式ですか？（§3）
計算コスト	論文で報告されていますか？（§7）	値の出所はベンチマーク用スクリプトですか？（§1）
マクロと文章の整合性	挿入された値に対して文章の説明は適切ですか？（§24）	値の出所はコードまで追跡でき、マクロマニフェストが生成されていますか？（§4）
要素間の一貫性	文章、キャプション、図、表の内容は相互に一貫していますか？（§24）	すべての要素は同じ実行／パイプラインの出力に基づいていますか？（§9）

ルール： このスキルはコードベースを開きません。manuscript-provenance は文章の品質を評価しません。利用可能な場合は、互いのレポートを参照します。

連携ポイント — Macro Manifest： manuscript-provenance は§4の監査の一環として、マクロマニフェストを生成します。これは、マクロによって挿入されたすべての値、その解決済み数値、値の出所（スクリプトと出力ファイル）、および原稿内での位置をまとめた構造化リストです。このスキルの Pass 13（要素間の一貫性）はこのマニフェストを使い、挿入された各値を囲む文章が実際の値に対して適切かどうかを確認します。provenance レポートがない場合、このスキルは.texソースからマクロ値を直接抽出します（出所の追跡はできないため精度は下がりますが、一貫性の確認は実行されます）。

ワークフロー

1. 取り込み

アップロードされた原稿を読み込みます。PDF、DOCX、LaTeX ソース、または Markdown を受け付けます。 複数のファイル（例：本文と補足資料）がアップロードされた場合は、 すべてを処理します。

以下を特定します。

• 投稿先（デフォルトは arXiv／プレプリント。学会または学術誌への投稿の場合は調整します）
• 投稿種別（フルペーパー、テクニカルレポート、学位論文の章など）
• ユーザーが指摘した具体的な懸念事項 — これらをレポートで優先します

arXiv への投稿では、準拠状況の確認は参考情報として扱います。厳密な 書式規則よりも、技術的な品質、再現可能性、明瞭さを重視します。

2. チェックリストの読み込み

references/checklist.mdを読み込みます。これは、24項目、約175のチェックポイントからなる 包括的な改稿チェックリストです。監査の各パスはこのチェックリストに沿って構成します。

Read references/checklist.md

3. 複数パスでの監査

以下のパスを順番に実行します。各パスはチェックリストの1つ以上の セクションに対応します。各チェックポイントについて、体系的に作業します。

• 合格：簡潔に記録して次に進む

• 不合格：正確な位置（セクション、段落、行）、具体的な問題、必要な修正を記録する

• 該当なし：この原稿の種別に当てはまらない場合に記録する パス 1 — 構成の整合性（チェックリスト §1、§4、§5、§10）

• 要旨から結論まで、主張の流れをたどる

• 各セクションの必要性と、論理的な依存関係の順序を確認する

• 序論のファネル構造と貢献の列挙を確認する

• 結論に新しい情報が含まれていないこと、および記載された貢献と1対1で対応していることを確認する

• 関連研究の構成（分類型か注釈型か）と差別化を評価する

パス 2 — 要旨とタイトルの調整（チェックリスト §2、§3）

• 要旨の機能的な完全性（背景 → ギャップ → アプローチ → 結果 → 含意）
• 要旨における定量的な具体性
• タイトルの精度と対象範囲の整合性
• キーワードと要旨の一貫性

パス 3 — 技術的な厳密性（チェックリスト §6、§7）

• 方法論の再現可能性が十分か（文書レベル：論文に十分な記述があるか。コードレベルの検証は manuscript-provenance まで保留）
• 仮定の明示性と記法の一貫性
• ベースラインの妥当性、データセットの特性評価、統計的厳密性
• 効果量の報告、評価指標の正当化
• 計算コストの報告（論文に記載されているかを確認。値とベンチマークスクリプトとの照合は manuscript-provenance まで保留）

パス 4 — 論証の質（チェックリスト §8、§9）

• 考察に新しい結果が含まれていないこと
• 代替説明の検討
• 一般化可能性の限界の明示
• 限界が形式的なものではなく、査読者からの反論に先回りして対応していること
• 妥当性への脅威の分類体系が網羅されていること

パス 5 — 引用と参考文献の整合性（チェックリスト §11）

• 引用と参考文献の対応関係（どちらの方向にも孤立した項目がないこと）
• 投稿先の書式への準拠
• 二次引用より一次資料を優先すること
• プレプリントから出版済み論文へのステータス確認
• 引用の配置（段落単位ではなく、主張単位）
• 撤回状況の確認に関する注意喚起

パス 6 — 図表の品質（チェックリスト §12）

• 図表の本文中での参照順
• 解像度と判読性の評価
• 色覚多様性への配慮
• 単位を含む軸ラベル、一貫した視覚表現
• 表の配置と有効桁数の一貫性

パス 7 — 文章表現の仕上げ（チェックリスト §13、§14、§15）

• 時制の一貫性（厳格な要件ではなく、推奨事項）
• 断定の度合いの調整（過大な主張も、内容のない主張も避ける）
• 受動態のパターン（参考事項）
• 名詞化を減らせる箇所
• 明瞭さと正確さ（arXiv では宣伝調の表現に注意）
• 略語の適切な扱い（初出時の展開、一貫性）
• 数式の組版の一貫性

パス 7b — AI らしいパターンの検出（参考事項）

references/detection-patterns.md の検出ルールを用いて、文章セクションに残る AI 執筆のパターンを調べます。AI アシスタントを使って執筆または推敲された学術論文には、検出可能な特徴が残っていることがよくあります。

学術論文の執筆に関連するパターンに注目します。

• 重要性の誇張 — 「pivotal」、「groundbreaking」、「paradigm shift」
• AI が多用する語彙 — 「delve」、「landscape」、「tapestry」、「underscore」
• コピュラの回避 — 「is」の代わりに「serves as」を使う
• 曖昧な帰属表現 — 引用なしで「experts argue」、「studies have shown」とする
• 表面的な -ing 句の付加 — 「..., highlighting the importance of...」
• 過剰なヘッジ — 認識論的に適切なヘッジに必要な範囲を超えるもの

学術文体として許容されるパターンは対象外とします。

• 受動態 — 方法のセクションでは一般的です
• 形式的な接続表現 — 「Furthermore」、「Moreover」は学術論文で慣例的に使われます
• タイトルケースの見出し — ジャーナルのスタイルで求められる場合があります

このパスの優先度は中程度です。指摘事項は報告しますが、過剰に修正しないでください。学術的な慣例と一部の AI パターンは重なることがあります。個々の事例は低度として報告し、1つの段落に3つ以上のパターンが集中している場合は中度として指摘します。

パス 8 — ベストプラクティスと再現可能性（チェックリスト §16、§17、§18、§19）

• 補足資料との相互参照の整合性
• 論文内にコード／データの利用可能性に関する記述があること（記載されたリポジトリの有効性とパイプラインの動作確認は manuscript-provenance に委ねます）
• サードパーティ製アセットとのライセンス互換性
• ハイパーリンクの検証と参考文献の整合性
• 全体的な明瞭さとアクセシビリティの評価

パス 9 — 主張と根拠の調整（チェックリスト §20）

これは、原稿内のすべての主張を対象にした専用の確認パスです。

各主張について、次の項目を確認します。

1. 主張の強さを評価します。強い／断定的（「X は Y を引き起こす」）、中程度／条件付き（「条件 Z の下で X は Y を改善する」）、または慎重／暫定的（「X は Y に寄与する可能性がある」）
2. 根拠の強さを評価します。直接的な実験、間接的／相関的なもの、引用のみ、類推、または根拠なし
3. 不整合を指摘します。
   • 過剰な主張：強い主張＋弱い根拠 → 主張を弱めるか、根拠を追加します
   • 控えめな主張：慎重な表現＋強い根拠 → 表現を明確にします
   • 根拠のない主張：強さを問わず根拠なし → 根拠を追加するか、主張を削除します
4. 研究デザインに照らして、因果関係と相関関係の表現を監査します
5. 一般化の範囲が実際の実験条件と一致しているか確認します
6. 比較の主張（「上回る」「より優れている」）が、論文内で実施された直接比較評価によって裏付けられているか確認します
7. 暗黙の主張を指摘します（例：「先行研究とは異なり、本手法は X に対応する」は、先行研究が X に対応できないことを示唆するため、これを確認します）
8. 否定の主張について、不在の証拠と証拠の不在を区別して確認します

このパスの優先度は高です。主張と根拠の不整合は、査読者が論文を却下する最も一般的な理由です。要旨にある過剰な主張は、論文全体の印象を損ないます。

パス 10 — 叙述の流れと一貫性（チェックリスト §21）

読者の認知状態を追いながら、原稿を最初から最後まで読んでください。各文と段落の境目で、次の点を確認します。

• この文は前の文から自然につながっていますか。それとも、読者が推論で飛躍する必要がありますか。
• この段落の冒頭文は要点を述べていますか。それとも、要点が埋もれていますか。
• 各文は既知の情報から始まり、新しい情報で終わっていますか（既知から未知への契約）。
• 文同士の相互参照は、読者が本文を前に進める順序になっていますか。それとも、あちこち行き来させていますか。
• 各段落の最後の文は、次の段落の最初の文につながっていますか。
• 著者には暗黙に分かっているために前提が省かれ、論理の飛躍が生じていませんか。
• セクション内で提示または約束した内容は、すべてそのセクション内で回収されていますか。
• 各セクションには明確な展開（導入 → 内容 → まとめ）がありますか。

専門分野の読者が論理的なつながりを再構築するために、読み返したり、前に戻ったり、立ち止まったりする必要がある箇所をすべて指摘してください。こうした箇所は、文章の流れを妨げます。

このパスの優先度は高です。結果が優れていても叙述の流れが悪い論文は、査読者を疲弊させます。文章を読むのに苦労する読者は、著者への信頼を失います。

パス 11 — 文章のミクロ構造（チェックリスト §22）

文レベルおよび段落レベルのパターンが積み重なることで、読みやすさに問題が生じます。

• 指示対象が曖昧な表現：「これ」「それ」「彼ら」など、明確な先行詞がないもの
• 情報密度の急増：一度に多くの新しい概念を導入する段落
• 何度も読み返さなければならない文：節の過剰な入れ子、修飾語の位置の誤り、読み違いを誘う構文
• リスト、比較、連続する項目における並列構造の崩れ
• 意味上の重複：目的なく、近接する段落で同じ要点を繰り返すこと
• 離れた箇所での参照：導入した概念が何段落も後で言及される際、改めて説明されないこと
• 懸垂修飾語：「勾配降下法を用いて、損失関数が収束した」

個々の項目の優先度は中程度ですが、問題は積み重なります。曖昧な代名詞が 20 個、情報密度の急増が 10 箇所、懸垂修飾語が 5 箇所ある原稿は、個々の問題が致命的でなくても、明らかに読みづらくなります。

パス 12 — レンダリングされた文書の確認（チェックリスト §23） このパスでは、コンパイル済みの PDF が必要です。LaTeX ソースしか提供されていない場合は、コンパイル済みの PDF をユーザーに依頼するか、コンパイルしてください。

PDF を開き、すべてのページを実際の印刷時の倍率で確認します。

1. 図：各図を最終ドキュメントで表示されるサイズに拡大して確認します。
   • すべてのテキスト（軸ラベル、目盛りラベル、凡例、注釈）が読みやすい
   • ラベルの重なり、衝突、切り詰めがない
   • 凡例がデータに重ならない位置にある
   • 注釈が正しい要素を指している
2. 表：列の配置、テキストの折り返し、内容のはみ出しがないことを確認します。
3. フロート：各図・表について、本文中で最初に言及されている箇所を特定します。ページ間の距離を測り、1 ページを超えるものにはフラグを立てます。
4. 改ページ：表がページをまたいで分割されていないこと（意図的に長い場合を除く）、数式が導入部から切り離されていないこと、見出しがページ下部に取り残されていないことを確認します。
5. 余白：内容（数式、URL、横幅の広い表、幅の広い図）が余白の外にはみ出していないことを確認します。
6. 視覚的な一貫性：図全体でフォントサイズが揃っていること、色の使い方に一貫性があることを確認します。

このパスの優先度は高いです。軸ラベルが読めない図や、ページをまたいで分割された表がある論文は、技術的な質にかかわらず、査読者に不注意だという印象を与えます。ソースからはこうした欠陥を見つけられず、著者はコンパイル後の出力ではなくエディター上で論文を読むため、見落としがちです。

パス 13 — 要素間の整合性（チェックリスト §24）

原稿を統合されたシステムとして読みます。各図、表、マクロによって挿入された値について、次の点を確認します。

1. 要素のまとまりを集める：図やデータそのもの、キャプション、それに言及するすべての本文、そしてそれらの箇所またはその近くにあるマクロの値を集めます。
2. 四者間の整合性を確認する：本文の主張は図の内容と一致していますか？ キャプションは現在の内容を説明していますか？ 本文、表、図の数値は一致していますか？ 定性的な表現は定量的な値と一致していますか？
3. 相互参照の正確性を確認する：すべての \ref が、周囲の本文で説明されている要素を指していることを確認します。図の順序を変更した後、参照先が誤った図になることはよくあります。
4. マクロと本文の整合性を確認する：マクロが数値を挿入している場合、その数値を含む文を読みます。「小幅な」「劇的な」「わずかな」「大幅な」といった定性的な表現が、実際の数値と一致していますか？ これは原稿の来歴確認から引き継ぐ作業です。来歴確認では値をコードまで追跡し、このパスではその値を囲む本文の表現が適切かを確認します。
5. 時系列の整合性を確認する：すべての要素が同じ実験実行から得られたように見えますか？ 個々には正しくても、ある実行の図と別の実行の表が混在していれば、整合性の問題です。

原稿の来歴確認レポートがある場合は、マニフェスト（追跡対象となったすべてのマクロ値と、その位置およびソース値の一覧）を読み込み、手順 4 の入力として使用します。来歴確認レポートがない場合は、.tex ソースからマクロの値を直接抽出します。

このパスの優先度は高いです。要素間の不整合は、最も見つけにくい種類の原稿の欠陥です。個々の要素は問題なく見えても、全体としては破綻しています。査読者は文書を順に読み、著者が別々に編集した要素間の矛盾に気づきます。

arXiv に関する注記： 倫理に関する記述、匿名化、ページ数の制限、厳密な書式要件は、デフォルトで N/A とします。技術的な質、再現性、明瞭さを重視してください。

4. リファクタリングレポートの生成

構造化されたドキュメントとしてレポートを作成します。出力形式には references/report-template.md を使用してください。

Read references/report-template.md

レポートの構成：

1. エグゼクティブサマリー — 全体的な品質評価（公開可能／ 修正を推奨／要改善）。優先度の高い改善点を上位5件示します。

2. セクションごとの診断 — 原稿の各セクションで見つかった具体的な 問題を、チェックリストのチェックポイント ID に対応付けます。重要度は HIGH（明瞭さ／信頼性に影響）、MEDIUM（目に見える品質上の課題）、または LOW （仕上げ／任意の改善）で示します。

3. 複数セクションにまたがる問題 — 複数のセクションにまたがる 問題（例：表記の不統一、引用パターン、明瞭さに関するパターン）。

4. 優先順位リスト — 影響度 × 作業量に基づき、すべての問題を順位付けします。 影響度の高い項目を先にし、その後、MEDIUM の項目を推定修正作業量の 少ない順（最小の作業量から、すぐに対処できる項目を優先）に並べます。

5. チェックリストの状況 — 全24項目のチェックリストについて、各 チェックポイントの合格／要改善／該当なしの状況を、原稿内の具体的な 場所を参照して示します。

5. トリアージと優先順位レポート

全体の確認を終えたら、問題を次のように分類します。

• HIGH — 技術的な信頼性または再現性に影響する問題（ベースラインの欠落、根拠のない主張、方法の詳細不足、参照の誤り）
• MEDIUM — 明瞭さまたは専門的な品質を損なう問題（表記の不統一、曖昧な主張、図の品質の低さ）
• LOW — 仕上げに関する問題（引用形式のばらつき、軽微な組版、スタイル上の好み）

arXiv への投稿では、技術的な品質と再現性に関する項目を HIGH 優先度にします。 倫理に関する記述や書式などのコンプライアンス項目は、通常 LOW 優先度または該当なしです。

詳細な指摘事項の前に、優先順位リストを提示してください。

6. 出力

レポートを原稿と同じディレクトリに、[manuscript-name]-review-report.md という名前の Markdown ファイルとして保存します。

簡潔な要約を添えて、ファイルをユーザーに提示します。

• 品質評価の判定
• HIGH／MEDIUM／LOW 優先度の項目数
• 推奨する改善点の上位3件

基本原則

• 構成と明瞭さを重視します。 これは構造と技術面の監査です。 文単位の文法は、読みやすさに影響する体系的なパターンでない限り対象外です。

• 根拠に基づいて指摘します。 各問題には、原稿内の具体的な場所 （セクション、段落、図／表番号）を記載します。「改善の余地がある」といった曖昧な指摘はしません。

• 重要度を適切に判断します。 技術的な信頼性と再現性に関わる問題は HIGH、明瞭さと専門的な品質に関わる問題は MEDIUM、スタイル上の好みは LOW とします。arXiv は査読付きの投稿先より柔軟性があります。

• 状況に応じた推奨を行います。 書式やコンプライアンス要件は 投稿先によって異なります。arXiv では、厳密な書式より技術的な品質を優先します。 ジャーナルへの投稿では、それに応じて調整します。

• 建設的に伝えます。 指摘事項は、却下のリスクとしてではなく、明瞭さ、 信頼性、再現性を高める改善点として提示します。arXiv では比較的柔軟に対応できるため、 研究成果を理解しやすく、信頼できるものにすることに重点を置きます。

• 明確に伝えます。 曖昧な提案ではなく、具体的な修正方法を添えて 問題を報告します。ただし、多くの「ルール」は arXiv におけるガイドラインであることを認識します。

• 体系的に確認します。 チェックリストを順を追って確認します。実際の内容に 基づき、各項目を合格／要改善／該当なしとして判定します。 匿名化、ページ制限、厳密なテンプレートなど、arXiv 固有の項目は 原則として該当なしとします。

呼び出し例

ユーザーが次のいずれかを依頼した場合：

• 「原稿をレビューして」
• 「投稿前にこの論文をチェックして」
• 「投稿できる状態か確認して」
• 「出版前レビューを実施して」
• 「参考文献を確認して」
• 「要旨の出来を確認して」
• 「方法のセクションをレビューして」
• 「投稿前チェックリストを実施して」
• 「/manuscript-review」

いずれもこのスキルを実行します。一部のみのレビュー（例：「引用だけを確認して」）であっても、 監査全体を実施します。ユーザーが一つの側面だけを依頼した場合でも、包括的な診断が役立つためです。