研究論文にはエージェントが読める主張ファイルが必要です

2026年5月15日、Arquimedes Canedoはpaper.jsonを提案しました。これはPDFの横に置く補助的なJSONファイルで、研究論文が安定した主張ID、明示的な適用範囲の限界、図ごとの再現コマンド、安定した定義IDを公開できるようにするものです。¹

この小さなファイルは、大きな問題を指し示しています。

いまや研究エージェントは、論文を読み、主張を抽出し、出典を引用し、図を再現し、後続研究を組み立て、適用範囲を要約します。¹ 論文本文は今でも人間の読者に役立ちます。しかし本文だけでは、エージェントが間違った下位の主張を引用したり、証拠を超えて一般化したり、再現コマンドを作り上げたり、定義を記憶から再構成したりする余地が大きすぎます。

研究論文には、エージェントが読める主張ファイルが必要です。 論文は、何を主張し、何を主張していないのか、重要語がどう定義されているのか、証拠が図やコードとどう結びつくのかを、エージェントが型付きで扱える形で提供すべきです。

要約

エージェントが読める主張ファイルは、論文を「本文だけの成果物」から、「論文本文に参照可能な証拠の手がかりを加えた成果物」へ変えます。PDFは人間が読む対象のままです。主張ファイルは、エージェントに安定したID、適用範囲の境界、定義、再現コマンドを与えます。

paper.jsonの提案は、具体的なスキーマと実例リポジトリでその必要性を示しています。草稿では5つの約束事が説明されています。安定した主張ID、明示的な「主張しないこと」リスト、図ごとの正確なシェルコマンド、手書きのJSONファイル1つで満たせる最小限の採用条件、そして安定した定義IDです。¹ 付属リポジトリには、paper.json、schema.json、validator.py、resolve.py、PDF、Typstソースが含まれています。²

より広い研究エージェント関連の流れも、同じ方向を示しています。Argusは、深い調査を力任せの並列検索ではなく証拠の組み立てとして扱います。³ ACDLは、エージェントの文脈に形式的な記述言語を与えます。⁴ 探索研究は、エージェントが行動前に検証可能な確認点を必要とすることを示しています。⁵ エージェントが設計したアーキテクチャの研究は、エージェントが科学的主張を生成する時代に、論文単位の再現性がいっそう重要になることを示しています。⁶

実務上の原則は単純です。人間には論文本文を公開し、エージェントには主張ファイルを公開するのです。

重要なポイント

論文著者にとって： - 主張、定義、定理、図、後続研究に安定したIDを付けます。 - 適用範囲の限界は、末尾近くに防御的な文章として隠すのではなく、独立したフィールドとして書きます。

査読者にとって： - スキーマが通るかだけでなく、機械可読な主張が論文内容と一致しているかを確認します。 - 古くなった、または誇張された主張ファイルは、引用リスクにつながる欠陥として扱います。

研究エージェントの開発者にとって： - 論文を要約、引用、再現、または土台として利用する前に、主張ファイルを取得します。 - タスクが正確な適用範囲に依存する場合は、主張IDと定義IDを引用します。

学術誌やリポジトリにとって： - 著者に完全なプラットフォーム採用を求める前に、PDFの横に置ける導入しやすいファイルを受け入れます。 - 構造は自動検証し、意味の審査は人間と専門エージェントに委ねます。

なぜ論文本文だけでは研究エージェントに合わないのか

学術的な文章は、証拠を物語の形に圧縮します。

その物語は人間には役立ちます。注意深い読者なら、留保表現を追い、節を比較し、どの結果がどの主張を支えているのかを推測し、論文がどこで主張を止めているのかにも気づけます。エージェントは、論文を別の形で処理しがちです。時間と文脈の制約の中で、走査し、分割し、検索し、引用し、要約し、新しい成果物を組み立てます。

その結果、起きる失敗は予測できます。

Canedoは、こうした失敗のいくつかを直接挙げています。下位の主張には論文内の引用ハンドルがなく、範囲の過剰拡張は本文要約を通じて起き、図のコマンドはしばしば論文外のコードリポジトリに置かれています。¹

解決策は、論文を置き換えることではありません。論文の主張を扱いやすくするインターフェースを追加することです。

主張ファイルには何を含めるべきか

エージェントが最も誤用しやすい要素を、主張ファイルで公開すべきです。

paper.jsonの実例には、草稿版、リポジトリURL、著者メタデータ、概要、主張、範囲除外、再現コマンド、スキーマに基づく検証が含まれています。² そのスキーマは、id、title、version、status、authors、abstract、claims、does_not_claim、reproducibilityなどの中核フィールドを必須としています。²

構造が真実を証明するわけではありません。構造は、真実を審査可能にします。

この違いは重要です。paper.jsonファイルは、検証器を通過しても、意味的な正しさ、完全性、図の再現品質は証明できないと明記しています。² 古くなった主張ファイルは、主張ファイルがない場合より害が大きくなりえます。エージェントが、複雑な本文より整ったフィールドを信頼してしまうことがあるからです。

したがって、標準には2つの層が必要です。

1. 構造検証：ファイルを解析できるか、必須フィールドがあるか、宣言されたIDが保たれているか。
2. 意味の審査：ファイルが論文を忠実に表しているか。

著者は第1層を自動化できます。第2層は査読者が責任を持つべきです。

なぜ安定した主張IDが重要なのか

参照可能な単位が論文全体しかない場合、エージェントの引用は粗くなります。

1本の論文には、手法に関する主張、評価に関する主張、限界に関する主張、ベンチマークに関する主張、後続研究に関する主張が含まれることがあります。人間の読者なら、論文を引用したうえで、どの部分が重要なのかを説明できます。エージェントはしばしば、論文全体の引用を曖昧な権威の印に変えてしまいます。

安定した主張IDは、エージェントにより小さな標的を与えます。

Canedoの草稿は、主張ID検索に関する予備的証拠を報告しています。より難しい概念検索条件では、JSONの主張を使ったエージェントの平均スコアは2点満点中1.20で、本文を検索したエージェントは2点満点中0.60でした。² 論文はこの結果を、大規模な証明ではなく予備的証拠と位置づけています。²

その慎重さは、提案を強くしています。最初の予備実験で分野の結論が出たかのように扱う必要はありません。重要なのは、著者によりよい審査対象を作ってもらうことです。

主張IDがあれば、査読者はより鋭い問いを立てられます。

• エージェントはC1を引用したのか、それとも論文全体を引用したのか。
• 要約はC2の条件表現を保っているか。
• 下流システムは、コマンドを確認せずにC3を土台にしたのか。
• エージェントは定義IDと結果主張を混同していないか。

「要約はもっともらしく聞こえるか」より、はるかに良い問いです。

なぜ適用範囲の限界を独立したフィールドにするべきか

エージェントは、限界が本文に埋もれていると論文を過大に述べがちです。

論文は、ベンチマークが5つのタスクだけを対象としている、手法が特定の環境を必要とする、結果が制御された設定を超えて一般化しない、と述べているかもしれません。人間の読者はその微妙な条件を保てます。エージェントの要約では、一度書き直しただけで条件が落ちることがあります。

明示的なdoes_not_claim[]フィールドは、再利用前に適用範囲の限界を見えるようにします。

paper.jsonの提案は、自身の研究について複数の除外事項を列挙しています。C1、C2、C3が証明済みだとは主張せず、検証器が意味的な正しさを保証するとも主張せず、この約束事がエージェントによる読解を解決するとも主張せず、すべての学術メタデータ標準との互換性も主張していません。²

このリストは、エージェントに有用なものを与えます。引用できる境界です。

範囲フィールドは評価者にも役立ちます。エージェントの要約が「paper.jsonは、主張IDがエージェントの引用精度を改善することを証明した」と述べた場合、評価者はその文をdoes_not_claim[]フィールドと比較し、過剰な主張として印を付けられます。フィールドがなければ、評価者は本文から範囲を推測しなければなりません。

なぜ図のコマンドを主張の横に置くべきか

再現はしばしば、コマンドの境界で失敗します。

多くの論文はリポジトリを示します。正確な図のコマンドは、スクリプト、Makeターゲット、ノートブック、READMEの注記、あるいは見つけにくい場所にあるかもしれません。エージェントはリポジトリを検索し、もっともらしいコマンドを組み立てられます。しかし実行されていないもっともらしいコマンドは、危険な自信を生みます。

エージェントが読める主張ファイルには、再現コマンドを直接列挙すべきです。

paper.jsonの実例には、検証器の生成、paper.typに対するpaper.jsonの検証、Typst論文のPDFコンパイルに使うコマンドが含まれています。² Canedoの草稿は、JSONが提供する再現コマンドにより、リポジトリを指す本文の手法節に比べて、図コマンドの検索が改善したという予備的証拠を報告しています。²

コマンドフィールドは控えめであるべきです。

エージェントは、コマンドフィールドを成功そのものとして扱うべきではありません。コマンドフィールドが与えるのは、実行し、記録し、報告する対象です。

定義はどこに入るのか

定義は、主張より大きな被害を生むことがあります。

間違った主張は、たいてい1文で失敗します。間違った定義は、その用語を使う後続のすべての文を汚染します。本文から定義を再構成するエージェントは、論文内部の語彙らしく聞こえるものを作りながら、著者の意味から離れていくことがあります。

安定した定義IDは、その危険に対処します。

Canedoの5つ目の約束事は、定義に安定したIDを与えるものです。草稿は、後の再利用では、エージェントが再構成した定義よりも著者が書いた定義を優先すべきだと論じています。¹ リポジトリの解決器は、#C1、#D1、#T1、#F1などのフラグメントに対応し、IDを主張、定義、定理、後続項目へ対応付けます。²

この仕組みは下流システムにとって重要です。

主張ファイルは、用語を参照可能にすべきです。エージェントは、用語を適用する前に定義を引用または解決すべきです。

研究エージェントは主張ファイルをどう使うべきか

エージェントには読解手順が必要です。

論文を要約または引用する前に、研究エージェントは次のことを行うべきです。

1. 利用可能な場合は、論文の主張ファイルを取得します。
2. ファイル構造を検証します。
3. 要求された主張、定義、図、定理、または後続研究IDを解決します。
4. タスクに実質的な影響がある場合は、解決した項目をPDFと照合します。
5. すべての要約で適用範囲の限界を保ちます。
6. 再現コマンドは、適切なサンドボックス内でのみ実行します。
7. コマンド出力、欠落ファイル、失敗した検査を証拠として報告します。
8. 主張ファイルに必要な項目がない場合にだけ、本文へ戻ります。

この手順は、審査用の記録一式を生むべきです。

目的は書類を増やすことではありません。根拠のない引用を減らすことです。

より広いエージェント研究の流れは、なぜ同じ方向を指すのか

近年のエージェント研究は、同じ主題に繰り返し戻っています。必要なのは、根拠のない流暢さを増やすことではなく、構造化された証拠の手がかりです。

Argusは、深い調査を証拠の組み立てとして扱います。このシステムはSearcherとNavigatorを使います。Navigatorは共有された証拠グラフを追跡し、不足している証拠片に向けて検索作業を割り振ります。³ この設計は、論文がエージェントの組み立てられる証拠片を公開する必要性を補強しています。

ACDLは文脈記述を対象にしています。著者らは、エージェントシステムには、プロンプトと対話履歴が手順をまたいでどう変化するかを記述する、正確で読みやすい言語が必要だと主張しています。⁴ 主張ファイルは論文層でこれに近い役割を果たします。論文の主張、定義、コマンドがエージェントの文脈にどう入るべきかを記述するのです。

探索研究は、別の角度を加えています。”Look Before You Leap”はExploration Checkpoint Coverageを導入しています。これは、行動前にエージェントが重要な状態、物体、アフォーダンスを発見したかどうかを検証可能にする指標です。⁵ 研究エージェントにも、論文を引用または再利用する前に同じ規律が必要です。行動する前に、主張、定義、限界、コマンドを発見すべきです。

AIRAは、問題の重要性をさらに高めます。AIRA-ComposeとAIRA-Designの論文は、新しい基盤モデルアーキテクチャを提案し、ベースラインに対する下流の改善を報告する、マルチエージェントによるアーキテクチャ探索を扱っています。⁶ エージェントが科学的な設計主張を生成できるなら、その主張を記述する論文には、機械可読な境界と再現の手がかりが必要です。

ARISは、この領域全体に当てはまる失敗を名付けています。長時間動く研究エージェントは、証拠の支えが不完全だったり、誤って報告されたり、実行者の枠組みから引き継がれたりすると、根拠のないもっともらしい成功を生み出しえます。⁷ 主張ファイルは、本文だけから根拠のない枠組みを引き継ぐ余地を研究エージェントから減らします。

一貫したパターンがあります。本格的な研究エージェントには、明示的な証拠オブジェクトが必要です。

著者はいま何を公開できるか

始めるために、著者は学術誌の承認を待つ必要はありません。

最初の版は論文の横に置けます。

{
  "id": "my-paper",
  "title": "My Paper Title",
  "version": "0.1.0",
  "status": "draft",
  "repository": "https://github.com/example/my-paper",
  "claims": [
    {
      "id": "C1",
      "statement": "The method improves retrieval accuracy on benchmark X under condition Y.",
      "evidence": ["figure-2", "table-1"]
    }
  ],
  "does_not_claim": [
    "The method improves retrieval accuracy outside benchmark X."
  ],
  "definitions": [
    {
      "id": "D1",
      "term": "retrieval accuracy",
      "definition": "The percentage of queries whose top-ranked result matches the labeled answer."
    }
  ],
  "reproducibility": {
    "environment": "Python 3.11",
    "commands": ["python scripts/reproduce_figure_2.py"]
  }
}

最初のファイルは、5つの問いに答えるべきです。

1. エージェントが引用できる正確な主張はどれか。
2. エージェントが推論を拒むべき主張はどれか。
3. 安定させる必要がある定義はどれか。
4. 証拠を再現するコマンドはどれか。
5. エージェントが読んだ主張ファイルの版はどれか。

この最小構成だけでも、エージェントはより安全な出発点を得られます。論文が変更されたときには、査読者にも具体的な差分が与えられます。

査読者とプラットフォームは何を確認すべきか

査読者は、有効なJSONファイルを形式的に承認するだけで済ませるべきではありません。

ファイルを論文と比較すべきです。

プラットフォームは、その作業の一部を自動化できます。

JSONの構文、必須フィールド、ID形式、重複ID、参照漏れ、URL到達性、コマンドの有無、版メタデータを確認できます。さらに、エージェントに主張ファイルと本文を比較させ、人間向けの審査記録を作らせることもできます。

意味を判断するのは、なお人間の審査です。自動化は、ずれを見えるようにするだけです。

標準は何を拒むべきか

エージェントが読める主張ファイルは、採用しやすいほど小さく、意味があるほど厳密であるべきです。

3つの誘惑を拒む必要があります。

第一に、プラットフォーム依存を拒むこと。著者が採用しない新しいプラットフォームより、PDFの横に置けるファイルのほうが優れています。Canedoの草稿は、最小限の採用条件として、新しいツールやプラットフォーム登録ではなく、手書きのJSONファイル1つを求めるべきだと論じています。¹

第二に、偽の確実性を拒むこと。スキーマは形を検証できます。意味的な真実は証明できません。主張ファイルは、何を証明し、何を証明せず、査読者がどのようにずれを確認できるのかを述べるべきです。

第三に、隠れた戦略を拒むこと。エージェントに必要なのは証拠を参照する手がかりであって、著者の私的なプロンプトではありません。公開される主張ファイルは、主張、定義、限界、コマンドを公開すべきです。非公開の査読メモ、隠れた評価ルーブリック、認証情報、未公開データのパスを公開してはいけません。

良い標準は、秘密の仕組みへの信頼を要求せずに曖昧さを減らします。

ふさわしい標準

ふさわしい論文は、人間の読者を説得するだけではありません。未来の読者、エージェント、査読者、構築者が、その成果を過度に引き伸ばさずに再利用できる道を与えます。

エージェントが読める主張ファイルは、論文の境界を調べやすくすることで、論文をより信頼しやすくするべきです。

標準は単純です。

• 重要な主張すべてに参照先を与えます。
• すべての適用範囲の限界にフィールドを与えます。
• すべての重要な定義に安定したIDを与えます。
• 再現される図すべてに正確なコマンドを与えます。
• すべてのエージェントに、論文を狭く引用する理由を与えます。

研究エージェントは、これからも論文を読み続けます。著者はエージェントに本文から情報を拾わせることもできますし、証拠のために設計された形で情報を与えることもできます。

後者の道は、よりよい引用、より安全な要約、信頼できる根拠を持たないもっともらしい主張の減少につながります。

簡単なまとめ

研究論文には、エージェントが読める主張ファイルが必要です。エージェントはすでに、学術研究を要約し、引用し、検証し、再利用しているからです。本文だけでは、エージェントが下位の主張ではなく論文全体を引用したり、範囲を誇張したり、コマンドを作り上げたり、定義をずらしたりする余地が大きすぎます。

paper.jsonは実用的な出発点を示しています。安定した主張ID、明示的な範囲除外、図ごとのコマンド、1つのJSONファイルによる最小限の採用、安定した定義IDです。¹ 実例リポジトリには、スキーマ検証、解決器、具体的なサンプルファイルが追加されています。²

最初の版は小さくてかまいません。主張、非主張、定義、再現コマンド、版メタデータ、リポジトリリンクがあればよいのです。このファイルは論文を置き換えるものではありません。エージェントが論文をより安全に読めるようにするものです。

FAQ

エージェントが読める主張ファイルとは何ですか？

エージェントが読める主張ファイルとは、論文の横に置かれる構造化ファイルです。主張、適用範囲の限界、定義、再現コマンド、関連メタデータを、エージェントが取得して引用できる形式で公開します。

paper.jsonはPDFを置き換えますか？

いいえ。PDFは人間が読む論文のままです。主張ファイルは、エージェントが論文の主張をより安全に引用し、検証できるように、参照可能な証拠の手がかりを与えます。

paper.jsonはどの問題を解こうとしているのですか？

paper.jsonは、エージェントによる論文読解で繰り返し起きる失敗を対象にしています。間違った下位の主張の引用、範囲の過剰拡張、隠れた図コマンド、不安定な定義です。¹

スキーマに通れば、主張ファイルは正しいといえますか？

いいえ。スキーマは、必須フィールド、ID、構造を検証できます。しかし主張ファイルが論文を忠実に表しているかは、人間または専門エージェントによる審査で確認する必要があります。

著者はまず何を含めるべきですか？

著者は、安定した主張ID、does_not_claim[]セクション、安定した定義、正確な再現コマンド、リポジトリURL、主張ファイルの版から始めるべきです。

参考文献