paperconan

paperconan

paperconan は論文のソースデータ表をスキャンし、外部エージェントによるレビュー用にローカルの画像アセットを登録できます。検出結果はすべてシグナルであり、判定ではありません。報告するのは位置とパターンであり、意図や個人への非難ではありません。PaperConan はモデルキーやプロバイダー SDK を管理せず、自律的な意味判断も行いません。

ツールリポジトリ：https://github.com/zixixr/paperconan

コアワークフロー

0. スキャンの前に CLI が利用可能であることを確認します。paperconan --version を実行してください。CLI が見つからず、pip が使える場合は、pip install "paperconan[all]" で一度だけインストールします（仮想環境またはグローバルではないインストールを希望するか、先に確認してください。pip が PEP 668 の externally-managed-environment エラーで拒否した場合は、代わりに uv tool install "paperconan[all]" または pipx install "paperconan[all]" を使います。「インストールと実行」を参照してください）。Python／pip が利用できない場合は、ユーザーにローカルでインストールして実行するよう依頼してください。出力を捏造してはいけません。
1. ユーザーが提供したものを確認します。
   • ローカルのソースデータディレクトリ：paperconan <input-dir> を実行します。
   • DOI またはタイトル：paperconan fetch "<DOI or title>" を実行し、一致する表形式のデータセットを選んでダウンロードした後、ダウンロードしたディレクトリをスキャンします。
   • 既存の監査結果のみ：audit/scan.json を読み、audit/report.html を証拠の確認画面としてトリアージし、その後、評価を踏まえた回答を提示します。生の report.html を「結果」としてそのまま渡してはいけません（「レポートの位置づけ」を参照してください）。
2. 実際の CLI を優先してください。表を目視しただけで検出結果を捏造してはいけません。
3. スキャン結果は段階的に読みます。まず paperconan overview から始め、scan.json 全体の解析から始めないでください（「スキャンを段階的に読む」を参照）。タスクに必要な参照ファイルを読み込みます。
4. 重大な検出結果について、追加確認に値すると説明する際は、元の表を開いてください。元データを入手できない場合は、その検出結果は未検証であると伝えてください。
5. 慎重に回答してください。異常の内容、妥当な無害の説明、判断に必要な人間による文脈を説明します。

スキャンを段階的に読む

1 本の論文の補足資料から、通常は数百から数千件の検出結果と、数メガバイトの scan.json が生成されます。そのすべてを読むと、判断に必要な注意力が無駄になり、対応する価値のある少数のシグナルが、多数の定型的な検出結果に埋もれてしまいます。

検出器は、閾値によって実際のシグナルを見落とさないよう、意図的に広範囲を対象に動作します。そのため、絞り込みは検出内容ではなく、読み方によって行います。何もフィルタリングされず、段階的に確認していきます。

paperconan overview audit/scan.json                    # which locations carry signal
paperconan drill    audit/scan.json 2                  # that location, grouped by kind
paperconan drill    audit/scan.json 2 --kind identical_column
paperconan explain  audit/scan.json seed:17942ad206854a66
paperconan explain  audit/scan.json seed:17942ad206854a66 --full

テキストではなく構造が必要な場合は、いずれにも --json を追加してください。

証拠ウィンドウには範囲があり、そのことが明示されます。 スキャンには、強調表示されたセルの周囲のウィンドウが保存され、ブロック全体は保存されません。密度の高い補足資料では、ウィンドウがファイルサイズの大部分を占めます。切り詰められたウィンドウには、たとえば ! this window is 20x30 of a 300x200 block, trimmed by the scan. のように、それ自体の規模が記載されます。これは「異常はここにあり、このブロックには表示されている範囲より多くのデータがある」と読み取ってください。ブロック全体が表示されているという意味ではありません。正確なセルが重要な場合（値を論文と照合するときや、パターンが列全体に及ぶかを判断するとき）は、explain --full でソースデータからブロックを再読み込みします。

--full は推測せず、条件を満たさない場合は拒否します。スキャンには各入力のサイズとタイムスタンプが記録されているため、ソースが移動、編集されている場合や、検出結果が対象とする行または列が失われている場合は、その理由とともに行データを返しません。盲目的に読み込むと、この検出結果の見出しの下に別の表を提示することになるためです。知っておくべき制限が 2 つあります。タイムスタンプを元に戻して同じバイト数でソースを書き換えた場合は検出できません（チェックでは内容ではなくサイズを比較します）。また、このチェックの導入前に生成されたスキャンでは、範囲の比較に切り替わるため、ソースの縮小は検出できますが、同じ場所での編集は検出できません。さらに、セル数の上限（PAPERCONAN_MAX_FULL_EVIDENCE_CELLS）も適用されます。ウィンドウがこの上限によって制限された場合は、その旨と変数名が示され、--full を再実行するよう促されることはありません。

以下の順に進み、質問に答えられる最も浅い段階で止めてください。

1. overview — どの場所にあるのか、どれほど強いのか、どの種類なのかを確認します。場所が、何度も言い換えられた1つの派生関係だと分かることもよくあります。
2. drill <n> — その場所にある種類を、それぞれ具体例とともに確認します。n が大きく、例が定型的な種類は、1つの構造が繰り返し表現されていることがよくあります。一方、n=1 の種類でも、その場所で最も強いシグナルである場合があります。
3. drill <n> --kind <kind> — ID 付きで個々の検出結果を確認します。
4. explain <id> — パラメーターと根拠の表を含む、1つの検出結果を確認します。追加調査に値すると判断する前に、元の表を開いてください。

読み進める際に覚えておくべきことが3つあります。

• detector=high displayed=low は、表示プロファイルによって重要度が低く評価されたことを意味し、問題がないという意味ではありません。 explain には記録された理由が表示されます。その理由を確認してください。密集したブロックや繰り返される軸であれば妥当な判定であることが多いですが、完全に重複した列が、多数のほかの関係と同じブロックにあるというだけで重要度を下げられる場合もあります。表示される重要度が低くても、指摘事項を見落とさないでください。
• ! の行を読んでください。すべてのレイヤーにあります。 overview と2種類の drill には coverage ブロックがあります。explain では、その制限が本文中に記載されます（スキャンによって切り詰められた証拠ウィンドウや、--json でのみ表示される構造化パラメーターなど）。これらには、表示されなかった内容とその理由が記されています。たとえば、一覧に表示された数を超える位置、一覧表示の上限を超える指摘事項、このレイヤーが処理しない種類（数字の分布、小数の末尾、画像に関する指摘事項）、レイヤーが認識する前にスキャン自体の上限によって除外された指摘事項、どのチャネルにも届かない検出器レベルの上限などです。残りを表示するには --max-locations ／ --max-findings を増やしてください。それ以外は表示の制限ではなく、スキャンの制限です。
• scan: の行は検出器だけでなく、スキャンレイヤーの制限も示します。 以下は、よく見られる形式をそのまま引用したものです。同じ形式でほかの行も出力されます（シートに限定された行では、ファイル名の後にシート名が付きます）。検出器全体のスキップは例外です。どのチャネルにも届かないため、ここに記載されることはありません。
  • scan: file too large in big.xlsx — ファイルがまったく読み込まれませんでした。 scan: unreadable in notes.xlsx も同じ種類で、そのファイルの内容は何も調査されていません。
  • scan: formula cache missing in m.xlsx Fig 3b (cells=['C4', 'C5', 'C6'], count=812) — count はキャッシュ値を保存していない数式セルの数です。cells はその一部の例であり、すべてではありません。paperconan はこれらのセルが計算する数値を一度も確認していないため、監査されておらず、シートの一部は未読です。
  • scan: formula cache unreadable in m.xlsx — 数式キャッシュの調査自体が完了しなかったため、そのファイルに未読の数式セルがあるかどうかを paperconan は判断できません。この行に formula cache missing がないからといって、何もないとは限りません。formula metadata byte limit と formula metadata sheet limit も同じ種類で、調査がどの上限によって止められたかを示します。
  • scan: report block limit in m.xlsx Fig 3b (count=3) — このシートのブロック収集は出力予算に達して停止したため、それ以降のブロックは分析されませんでした。この行は、2種類の予算のいずれかに達したことを示します。PAPERCONAN_MAX_REPORT_BLOCKS を増やし、それでも変化がなければ PAPERCONAN_MAX_TOTAL_FINDINGS を増やしてください。
  • scan: detector candidate pool limit in detect_short_row_reuse (limit=400) — 検出器が上限に達して候補の作成を停止したため、それ以降の行は比較されませんでした。
  • scan: detector finding limit in detect_row_pair_digit_coupling (limit=25) — 検出器が上限に達して指摘事項の出力を停止しました。
  • scan: detector compute budget limit in detect_row_relations — 検出器の処理予算が尽きました。
  • scan: detector row limit in detect_local_pair_runs — PAPERCONAN_LOCAL_RUN_MAX_ROWS を超える高さのブロックは、このパスでは行ごとに比較されませんでした。ただし、ブロックの幅が PAPERCONAN_MAX_BLOCK_COLS を超えない限り、列は比較されます。幅も超えている場合は、列ペアも比較されません。
  • scan: detector within row folded independent repeat in detect_recurring_row_vectors (count=2) — これは切り詰めではなく、除外を示します。 同じ物理的な繰り返しによって生じる重複するウィンドウは、行内パスで1つの指摘事項にまとめられます。まとめられた候補のうち、この数だけは、このページ上のどの指摘事項も対象としていない位置でも繰り返されていました。記録にあるのはこの数だけです。その位置を見つけるには、行を読む必要があります。 これらのいずれかがある場合、scan_status は complete ではありません（partial、または何も読み取れなかった場合は failed）。そのため、その入力で結果が何も表示されなくても、問題がない証拠にはなりません。この段落の残りは、途中で切り詰められた行についての説明です。上記の行のうち、detector within row folded independent repeat を除くすべてが該当します。（位置ではなく名前で示しているため、箇条書きを追加しても、この文がそのうちの2つについて誤った内容になることはありません。）この行は切り詰めではなく、見落としを示しています。未確認の部分は残っておらず、その行を読むことが対処法です。ただし、上限とは無関係ではありません。出力された検出結果と比較するため、同じスキャンで同じ検出器に detector finding limit も現れる場合、入力を絞り込むと出力数が増え、この行が表示されるかどうか自体が変わることがあります。実際のサプリメントで確認されています。両方がある場合は、併せて読んでください。 検出器の行には ファイル名もシート名も記載されません。レコードにその情報がないため、どこで切り詰められたかは行から判断できません。ブロックが1つの場合も、複数の場合もあります。変更せずに再実行しても意味はありません。スキャンは決定的であり、同じ切り詰め結果がバイト単位で再現されます。該当する PAPERCONAN_* 上限（PAPERCONAN_SHORT_ROW_MAX_ROWS、PAPERCONAN_ROW_PAIR_MAX_ROWS、*_BUDGET 変数）を引き上げるか、入力を絞り込んで再実行してください。既定値が固定で、調整用の設定がない上限もあります。その場合、入力を絞り込むことだけが対処法です。ブロックが広すぎる、または高すぎるために検出器全体がスキップされる場合については、別の注意事項で説明しています。この場合はどのチャネルにも届かないため、ここで示されることはありません。
• 概要に何も表示されなくても、論文に問題がないとは限りません。 指定されたしきい値では、提供されたデータ内にこれらの検出器が何も見つけなかったという意味です。

特定の主張から始める

overview は「シグナルはどこにあるか」という問いに答えます。他に何もわかっていない場合、最初に尋ねるべき問いとして適切です。一方、すでに主張がある場合には適切ではありません。たとえば、誰かから「この論文の図 2j はおかしいようだ」と言われた場合、所見のないシートは overview に表示されません。そして、確認を依頼されたのは、まさに「所見がない」かどうかです。

paperconan sheets audit/scan.json          # every sheet read, signal or not

次に、その図がどのシートにあるかを自分で判断してください。補足資料では、数百枚のシートが十数個のファイルにまたがり、Fig. 2j、Fig2J、ED_Fig.7b、Source Data Fig 2、Supplementary Figure 8e のような名前や、番号ではなく内容に基づく名前が付けられていることがよくあります。これらを確実に図に対応付けるルールはありません。読み取って判断する必要があるため、このツールは一覧を表示するだけで、対応付けは行いません。

ファイル間で名前が重複するため、シート名だけでなくファイル列も確認してください。

次のように対応してください。

• 一致するシートが 1 枚あり、そこにシグナルがある場合 — 通常どおり drill で掘り下げてください。drill は overview の序数を使うため、デフォルトのページを超えた順位のシートを表示するには、表示されるまで overview --max-locations の値を増やす必要があります。
• 一致するシートが 1 枚あり、そこにシグナルがない場合 — シグナル列が対象とするのは、このレイヤーが処理するファミリーだけです。digit_distribution、decimal_endings、decimal_tail_clusters、image_findings は対象に含まれません。どれがどのシートに属するかは示さず、一覧内の ! 行にその旨が記載されています。そのシートについて、問題がないと判断する前に scan.json のこれらのキーを確認してください。シグナル列が空でも問題がないとは限りません。image_findings のリストが空でも同じです。確認したうえで、「データは存在し、検出器はその場所で何も見つけなかった」と報告するのは、十分価値のある回答であり、「ソースを取得できなかった」よりも適切です。
• 該当する可能性があるものが複数ある場合 — それぞれを確認してください。たまたま選んだシートだけを根拠に「データは存在するが、何も見つからなかった」と結論付けるのは、「入手不可」とするよりも、自信に満ちた誤答になり、読者により大きな負担をかけます。
• 一致するものがない場合 — 図のデータは取得したものの中に含まれていなかったことと、検索したファイルを伝えてください。

一覧には、読み取れなかったものも表示されます。シートが見つからなかったファイルと、サイズ上限を超えたシート（not read と表示されます）です。図のデータがそのいずれかに含まれている場合、その図は確認されておらず、問題がないと報告してはいけません。

まず sheets を実行せずに「ソースデータを入手できない」と結論付けないでください。 このプロジェクト独自のベンチマークでは、ソースを入手できないと判定された 16 件の主張のうち、指定された図がすでにダウンロード済みのシートに含まれていたものがありました。そのうち 1 件は 161 枚のシートを含むファイル内のシートで、現在ではその 12 枚に所見があります。データは存在していたのに、誰も図との対応付けを行っていませんでした。

シートが実際に存在しない場合は、paperconan fetch を使うと、最初のダウンロードで取得できなかったコピーにアクセスできることがあります（「データの取得」を参照）。どのファイルを要求すべきか判断しやすいよう、出版社が付けた各補足ファイルの名称も記録されています。

適応型画像レビュー

ユーザーが画像レビューを依頼した場合、またはソースディレクトリに数値データと合わせてレビューすべき図が含まれている場合は、このワークフローを使用します。

1. paperconan <input-dir> --images を実行します。決定論的なヒントが有用な場合に限り、--image-diagnostics を追加します。
2. image_assets のすべての項目を確認します。決定論的な image_findings はヒントであり、レビュー対象のすべてを示すものではありません。image_findings が空でも、画像に関するすべての疑問が解決したことにはなりません。決定論的なペアのヒントは、登録済みアセット内の2つの領域のみを比較し、アセット同士は比較しません。
3. 現在の Agent がローカル画像を開けることを確認します。
   • 開ける場合は、最初に画像全体を確認し、その後、細かいパネルや未解決の詳細を調べるために、ネイティブピクセルで切り抜きます。
   • 開けない場合は、image_review.status を unavailable_no_multimodal に設定し、数値データのレビューを続け、画像の意味的レビューが完了していないことを明記します。
4. 各アセットについて、reviewed_asset_ids、unresolved_asset_ids、unreadable_asset_ids、deferred_asset_ids のいずれか1つに、カバレッジの結果を正確に記録します。image_review.status: "completed" はカバレッジの記録が完了したことを意味しますが、画像に関するすべての疑問が説明されたことを意味するものではありません。
5. 画像の類似性に関するシグナルをエスカレーションする前に、図のラベル、チャンネル、処理手順、共通のコントロール、インセット、処理前後のレイアウト、図の凡例、および Methods を確認します。
6. 外部マルチモーダル Agent はアセットをまたいだ比較を担当し、image_findings が空でも image_refs を使って画像に関する所見を作成できます。そのような Agent のみが作成した画像所見は、決定論的な scan.json ではなく、判定結果に記載します。
7. 数値と画像の所見を同じ verdict.json findings[] に記載し、paperconan report で統一された単一のレポートを生成します。

PaperConan は、登録済みのローカルアセット、範囲を限定したレポートプレビュー、任意の決定論的ヒントを提供します。外部マルチモーダル Agent は、機能の検出、意味的レビュー、カバレッジの記録、および慎重な文脈解釈を担当します。

レビューモード

ユーザーの依頼を満たす、最も簡易なモードを選択します。

• 単一論文のスキャン：必要に応じて取得／スキャンを行い、重大な所見についてはソース表を開き、可能であればラベル／凡例／Methods を確認したうえで、レポートを求められた場合に限り references/report-templates.md を使用して簡潔に回答します。
• 単一論文の正式レビュー：スキャンとソース表の検証後、references/adjudication-tiers.md と references/report-templates.md を読み込みます。Tier のラベルはレビューの優先度／無害な説明の難しさを示すものとしてのみ使用し、著者の意図に関する結論には使用しません。
• 一括レビュー：references/batch-workflow.md を使用します。決定論的な paperconan の出力と Agent の判断は分けておきます。偽陽性が繰り返し発生した場合、将来のフィルター改善に役立つため、DROP の理由を保持します。
• 敵対的レビュー：Tier 1／Tier 2、PubPeer の草稿、公開向けの主張、または偽陽性の指摘に基づくフィルター変更には、references/adversarial-review.md を読み込み、懸念を確認する前に反証を試みます。

通常のスキャン概要では、8セクション構成の完全なレポートを作成しないでください。Tier 1／Tier 2 の KEEP、PubPeer 形式の草稿、正式な研究公正に関する注記、またはユーザーから明示的に依頼された場合に限り、完全なレポートを使用します。

レポートの位置づけ

パイプラインは スキャン → エージェントによるトリアージ／判定 → 判定済みレポート です。次の2つのレポート成果物は区別してください。

• audit/report.html（CLI 単体で生成）は、決定論的な検出器／エビデンスブラウザー、つまりトリアージ用の作業リストです。設計上、誤検出が多く、判定は一切含みません。これは中間成果物であり、ユーザー向けの納品物ではありません。これを「監査結果」として提示してはいけません。
• ユーザー向けの納品物は必ずエージェントによる判定済みであり、scan.jsonをトリアージし、重大な指摘については元の表を開いて、問題のない説明が成り立つかを検討した後にのみ作成します。通常のケースでは短い判定済みの要約を、Tier 1／Tier 2 KEEP および正式な文書や公開用の文章では8セクションのレポート（paperconan report scan.json --verdict verdict.json --out …）を作成します。

つまり、生のreport.htmlはあなたがトリアージのために読むものであり、判定済みの要約または8セクションのレポートをユーザーに渡します。paperconan <dir>だけを実行する一般的な CLI ユーザーは、エージェントが介在しないため、生のブラウザーのみを目にします。指摘事項が意味を持つには、引き続き人間またはエージェントによるトリアージが必要だと伝えてください。

インストールと実行

pip install paperconan
pip install "paperconan[image]" # image assets, PDF page rendering, optional hints
pip install "paperconan[all]"   # includes PDF / Word table extraction
paperconan --version
paperconan <input-dir>

pip installがexternally-managed-environmentエラー（PEP 668。例：Homebrew または Debian の Python）で拒否されるシステムでは、--break-system-packagesを強制するのではなく、隔離された環境にインストールしてください。

uv tool install "paperconan[all]"   # or: pipx install "paperconan[all]"
# or a plain virtualenv:
python3 -m venv ~/.venvs/paperconan && ~/.venvs/paperconan/bin/pip install "paperconan[all]"

デフォルトの出力：

<input-dir>/audit/scan.json
<input-dir>/audit/report.html

便利なオプション：

paperconan <input-dir> --out /tmp/audit-X
paperconan <input-dir> --md
paperconan <input-dir> --no-html
paperconan <input-dir> --profile forensic
paperconan <input-dir> --images
paperconan <input-dir> --images --image-diagnostics
paperconan report /tmp/audit-X/scan.json --verdict verdict.json --out adjudication.html

Python またはパッケージにアクセスできない場合は、ユーザーにコマンドをローカルで実行するよう伝えてください。手動レビューは、権威ある結果ではないヒントとしてのみ提示できます。また、paperconan の出力として提示してはいけません。

データの取得

ユーザーがローカルファイルではなく DOI／タイトルを提示した場合にのみ、データを取得してください。

paperconan fetch "<DOI or title>"
paperconan fetch "<DOI or title>" --json
paperconan fetch "<DOI>" --download <id> --out data/
paperconan fetch "<DOI or title>" --auto --images --out data/
paperconan data/
paperconan data/ --images

doi_in_related: trueの候補を優先してください。リポジトリ検索では無関係な登録データが返される場合があるため、該当性が低い場合はその旨を正直に報告し、「データが見つからない」ことが「論文に問題がない」ことを意味するかのように伝えてはいけません。ペイウォールを回避したり、出版社のサイトをスクレイピングしたりしてはいけません。

プロファイル

--profile {review,forensic,triage}は、scan.jsonで表示される内容を変更します。

• reviewがデフォルトです。誤検出の可能性が高い項目も表示しますが、重大度をlowに引き下げる場合があります。
• forensicは検出器の生の重大度を維持します。懸念される検出結果が、生の検出器では重大度が低いだけだったと述べる前に使用してください。
• triageは誤検出の可能性が高い項目を非表示にします。

検出結果のprofile_action: "demoted"またはprofile_action: "hidden"は、アクティブなプロファイルによって表示される重大度が変更されたことを示します。prefilter_reason、prefilter_flags、false_positive_contextを使って理由を説明したうえで、フィルターの理由が実際の表の状況に当てはまるかどうかを判断してください。

決定論的な画像ヒントの場合、profile_action: "kept"は情報を示すものです。 画像ヒントは数値プレフィルターを通らず、review、forensic、triageによって引き下げられたり、非表示になったりしません。

参照資料の読み込み

必要な場合にのみ参照資料を読み込みます。

• references/output-schema.md：scan.json を解析する前、または profile_action、prefilter_reason、value_sample、col_a_sample、cross_sheet_findings などのフィールドを説明する前に読みます。
• references/detectors.md：検出器の種類と、よくある誤検出を解釈する際に読みます。
• references/judgment-rubric.md：検出結果に順位を付ける際、列内シグナルを判断する際、または PubPeer／研究公正に関する文面を作成する際に読みます。
• references/interpretation.md：ユーザー向けの最終回答を作成する際、または告発、暴露、エスカレーションの依頼に対応する際に読みます。
• references/adjudication-tiers.md：Tier 1/2/3、KEEP、DROP、NEEDS_HUMAN、impact_scope を割り当てる前に読みます。
• references/report-templates.md：正式なレポート、PubPeer の草稿、研究公正に関するメモ、またはバッチ判定 JSON を作成する前に読みます。
• references/adversarial-review.md：Tier 1／Tier 2、公に向けた懸念、または提案するフィルター変更を確定する前に読みます。
• references/batch-workflow.md：複数の論文をレビューする際、または候補キューを整理する際に読みます。
• references/case-patterns.md：合成データによるキャリブレーションパターンのみを参照します。実際の事例の先例として扱わないでください。

判断の原則

• severity を著者の意図に関する結論に決して置き換えないでください。severity は、適用中のプロファイルに基づく異常の強さを示すものであり、著者の意図を示すものではありません。
• Tier 1/2/3 を著者の意図に関する結論に決して置き換えないでください。Tier は、文脈を確認した後の追跡調査の優先度と、悪意のない説明がどれほど難しいかを示します。
• 弱い列単独のパターンより先に、シート間での再利用や列をまたぐ変換を調べてください。
• まずは、共有対照、再プロット、単位換算、数式、インデックス、比率、正規化値、モデル出力、検出限界、範囲を限定したスコア尺度といった、悪意のない構造上の説明を優先してください。
• within_col_* の検出結果は、既定で誤検出が多いものとして扱ってください。n < 10、カテゴリ／インデックスラベル、派生列、分母が固定された比率、丸められた数値の格子、下限／上限、反復する補完値は、強い根拠として報告しないでください。
• 行の独立性、生の測定値かどうか、数式による生成、Methods／凡例の意味、元表の出典を確認できない場合は、「人による文脈の確認が必要」としてください。
• PubPeer 形式の文面では、具体的なファイル／シート／列の根拠と著者への質問を示してください。著者を告発したり、意図について結論を述べたりしないでください。
• ユーザーから特定の公開ノートの作成を明示的に依頼され、その根拠を元データおよび論文の文脈と照合済みの場合を除き、実在する論文を公開用のキャリブレーション例として使わないでください。

出力形式

通常のスキャン概要には、次の内容を含めます。

1. スキャン対象と、解析に失敗したファイルの有無。
2. 手動／フィールドレベルでトリアージした、優先度の高い検出結果をファイルごとに分類したもの。
3. 具体的な証拠の抜粋：検出器の種類、場所、rule、n、必要に応じて値の簡単なサンプル。
4. 妥当な無害の説明と、それを解決するために必要なこと。
5. ハイライトされた表の文脈を確認できる report.html への案内。

バッチ処理やエージェント間のワークフローでは、任意で判定 JSON に次の項目を含められます。 verdict、suspicion_tier、impact_scope、tier_why、drop_reason、 innocent_explanation、needs_author_data、report_md、review_status、および finding_refs（判定の対象となったスキャン検出結果を指定するセレクター。 これにより、レンダリングされたレポートの証拠パネルが該当するものに絞られます）。論文に 異なる検出結果が複数ある場合は、論文単位のオブジェクトに findings 配列を含めます（各エントリーを個別に判定し、それぞれ独自の段階／ステータスと finding_ref を指定します）。その場合、レポートには検出結果ごとに完結したブロックが 1つずつ表示されます。references/adjudication-tiers.md および references/report-templates.md を参照してください。

適応型の画像レビューでは、scan.json image_assets[] が登録済みアセットの完全な 一覧であり、image_findings[] には任意の決定論的なヒントのみが含まれます。 finding_type: "image" のエントリーとしてエージェントの結論を追加し、 image_refs を指定したうえで、トップレベルに image_review のレビュー範囲を追加します。 数値と画像に関するエントリーは、エージェントのみが確認したアセット間の所見も含め、 すべて同じ findings[] と単一の統合レポートにまとめます。別個の画像判定や、 ユーザー向けの2つ目のレポートは作成しないでください。

判定 JSON がすでに存在する場合、paperconan report <scan.json> --verdict <verdict.json> --out <html> を実行すると、判定を反映した別のレポートを生成できます。 これをデフォルトの決定論的な audit/report.html と混同しないでください。判定レポートの 信頼性は、その根拠となる人間／AI の判定とソースの文脈に依存します。

ユーザーから著者の意図についての結論を求められた場合は、paperconan ではそれを 判断できないと回答してください。次のステップは、元データを検証し、懸念が残る場合は PubPeer、ジャーナル、または研究公正室を通じて説明を求めることです。