学会発表の論文サーベイをAIで半自動化｜検索から引用確認まで

学会発表に向けた先行研究の調査では、検索から比較表の作成に至る反復作業をCodexやClaude CodeといったAIエージェントへ任せられます。これまで研究者が手作業で行っていた学術APIごとの操作やデータ形式の修正をAIに委ねる一方で、研究者自身は論文の採否や発表の主張を組み立てる思考に集中します。

この記事では、AIエージェントが実行できるタスクの範囲を定め、最終的な引用の根拠を人が確認するまでの境界をどのように引くかを示します。

エージェントへ作業を依頼することで楽になるのは、論文の候補取得、取得した応答のraw保存、形式統一、重複候補抽出、タイトルや抄録を使った一次スクリーニング、そして比較表の下書き作成までです。ただし、CodexやClaude Codeは最初からすべての学術データへ自由にアクセスできるわけではありません。

エージェントが外部のAPIを利用して自律的に動くためには、研究者側でネットワーク接続の権限、APIキーなどの認証情報、そして利用を許可するツールをあらかじめ設定しておく必要があります。

準備が整った環境での一つの実行例として、研究者は調査の前提条件を記述したsurvey-spec.yamlを入力ファイルとしてエージェントへ渡します。エージェントはこの調査仕様を読み込み、複数の探索経路から論文データを集め、取得した生の応答をraw/ディレクトリへ保存します。

続いてデータを整形して重複候補の抽出を行い、一覧としてcandidates.csvを作成します。さらに、一次スクリーニングを実行して比較表の下書きとなるscreening-draft.csvを出力するとともに、実行過程のすべてをrun-log.jsonへ記録して調査の再現性を保ちます。

このように反復工程をAIへ任せられる一方で、エージェントが作成するものはあくまで下書きに過ぎません。調査の土台となる研究質問や採否基準を定めること、PDFを開いて実際の原文を確認し採否を判断すること、プレプリントと出版版のどちらを引用するかを選ぶこと、そして最終的な発表の主張を作ることは、人が担うべき判断として明確に分けます。

AIの作業と研究者の承認を切り離すことで、学会発表に必要な比較表を、原文へ戻って確認できる形で作れます。

学会発表用サーベイは検索前の設計で決まる

学会発表に向けた先行研究調査を始める際、最初に行うべきは検索ツールへのキーワード入力ではありません。CodexやClaude CodeといったAIエージェントへ反復作業を依頼するため、まずは調査仕様を設計し、設定ファイルとして固定することから始めます。

研究者は、調査の前提となる条件をsurvey-spec.yamlのような一つのファイルへ書き出します。架空のテーマである『生成AIによる会議要約の評価研究』を想定した場合、以下のようなファイルを作成します。

# 架空の調査仕様例
research_question: 生成AIを用いた会議要約において、要約の品質評価はどのような指標で行われているか
target_years: 2022-2024
document_types:
  include: ["long paper", "short paper"]
  exclude: ["workshop", "demo"]
inclusion_criteria:
  - 会議録や対話の要約タスクを扱っている
  - 生成AIや大規模言語モデルを利用している
  - 自動評価指標または人手評価の設計について記述がある

この例を見ることで、学会発表で明らかにしたい研究質問、対象年、ショートペーパーを含めるかという文書種別、そして論文を候補に残すための明確な採否基準がコンピュータにも読める形式で言語化されていると判断できます。さらに起点となる重要な先行研究を特定できている場合は、それも条件に加えます。

調査仕様を設計したら、エージェントへ作業を任せます。ターミナル上でClaude Codeを起動し、「survey-spec.yamlを読み込んで、対象文献を収集しスクリーニングリストを作成してください」と入力します。

エージェントは学術APIを通じた候補取得、取得した応答のrawディレクトリへの保存、JSONやXMLの形式統一、重複候補の抽出、タイトルや抄録を使った一次スクリーニング、そして比較表の下書き作成までを一つのタスクとして実行します。

これにより、仕様を読み込ませるだけで、実行過程を記録したrun-log.json、重複情報を含めた候補一覧のcandidates.csv、そして判定の土台となるscreening-draft.csvを得ることができます。

この出力ファイル群から、読者は取得した生データから加工後のリストまで、調査の中間生成物がすべてローカルに保存されていると判断できます。

ただし、エージェントがこれらの作業を自律的に行うには、研究者側で実行環境を用意する必要があります。エージェントがAPIへアクセスするためのネットワーク権限や認証情報、ローカル環境へのファイル書き込み権限、そして利用を許可するツールを設定します。APIキーはリポジトリへ保存せず、秘密管理された環境変数や認証済みの接続から渡します。

また、AIが自動化できるのはあくまで候補の収集と下書きの提示までです。抽出された内容が研究質問に合致しているかの判断や、PDFで原文の位置を確認して採否を最終決定すること、プレプリントか出版版かといった引用する版を選ぶこと、そして発表の主張を作ることは、研究者自身が担う領域として明確に分けます。

たとえば、出力されたscreening-draft.csvをスプレッドシートで開き、AIが抽出した抄録の該当箇所と実際のPDFを見比べながら、採録フラグを人が手作業で入力していくことになります。この人による確認作業から、読者はAIの出力をそのまま採用せず、最終的な採択文献の決定権を常に研究者が握っていると判断できます。

このように、研究者の判断とエージェントの作業の境界を決めることは、調査の透明性を保つ上でも不可欠です。研究者が独自の判断で文献をまとめるnarrative surveyとは異なり、自動化を組み込んだ調査では、どのような条件で探索を行ったかの記録が求められます。

PRISMA 2020はsystematic reviewの報告指針であり、自動化の品質認証ではないものの、調査の過程を検証可能な状態にするための基準として参考になります。検索手順の報告について、PRISMA-Sは情報源、検索式、検索日など検索手順の記録を求めるため、設定ファイルと実行ログを報告用の記録へ反映できます。

たとえば、survey-spec.yamlの対象期間とrun-log.jsonの検索実行日時を照合し、研究者が確認してから調査方法の節へ転記します。設定ファイルとログは検索手順をたどる材料にはなりますが、それだけで研究の妥当性を証明するものではありません。

もしエージェントが作成した一覧に重要な論文の検索漏れがあったり、無関係な候補が大量に混ざったりした場合は、調査仕様のファイルへ戻って条件を修正します。

たとえば、先ほどのsurvey-spec.yamlの採否基準に「音声認識のエラー訂正のみを対象とする論文は除く」というルールを追記し、ファイルを上書き保存してからエージェントに再実行を指示します。

この修正手順により、読者は検索の試行錯誤がブラウザ上の場当たり的な操作として消えるのではなく、設定ファイルの更新として蓄積されていくと判断できます。入力がファイルとして固定されているからこそ、検索の失敗原因を特定し、エージェントへの依頼を何度でも正確にやり直すことができます。

公式proceedingsと3方向探索で候補を集める

調査の対象範囲を定めたら、次に論文の候補集合を作ります。最初に確保すべき母集団は、対象とする学会の公式な会議録です。公式目次から対象年度の論文一覧を取得し、調査の土台とします。

このとき、研究者自身が目次を確認し、自分の研究質問と特に関連の深い基準となる論文（seed paper）を見つけ出し、調査仕様であるsurvey-spec.yamlへ追記して条件を固めます。

前節と同じく、説明用の架空テーマ「生成AIによる会議要約の評価研究」を想定します。研究者は対象会議の目次に目を通し、関連の深い論文Aをseed paperとしてsurvey-spec.yamlへ入力します。AIが探索の起点を勝手に決めるのではなく、研究者が公式目次を確認して起点を与える場面です。

しかし、公式目次だけでは他の会議で発表された関連研究を取りこぼしてしまいます。そこで、CodexやClaude CodeといったAIエージェントへ、キーワード検索、引用関係、類似論文という3つの方向からの探索を追加で依頼します。エージェントはsurvey-spec.yamlを読み込み、APIを利用して自動的に候補を集める作業を開始します。

このとき、エージェントが自律的に学術APIへアクセスするには、研究者側でネットワーク接続の権限や、APIキーなどの認証情報を環境変数として事前に与えておく必要があります。さらに、エージェントがシェルコマンドやPythonスクリプトを作成・実行できるツールを許可しておくことで、はじめて自動化が成立します。

研究者は秘密管理された環境変数から学術APIの認証情報を渡せる状態にし、Claude Codeを起動します。そして、survey-spec.yamlに基づいて3方向から候補を収集し、経路別にraw応答を保存するスクリプトの作成と実行を指示します。

必要な権限を与えられたエージェントは、役割の異なる複数の学術APIを使い分けて探索経路を広げます。第一の方向であるキーワード検索では、OpenAlexはworksの検索・絞り込みに使うため、指定した検索式に基づく候補を取得させます。

第二の方向は、seed paperを起点とした引用ネットワークの探索です。Semantic Scholar Academic Graph APIはpaper search、bulk search、引用、参考文献の取得に使うため、これを利用して後方引用と前方引用の2経路で論文を集めます。

seed paperの前提となっている基礎的な手法と、その後の派生研究をたどります。第三の方向として、同じAPIを利用して特徴が近い類似論文も取得し、キーワード検索の漏れを補います。

エージェントは自動作成したスクリプトを実行し、第一の方向としてOpenAlexへmeeting summarizationやLLM evaluationなどのキーワード検索クエリを送信します。

第二、第三の方向では、survey-spec.yamlに記載された論文Aの識別子をSemantic ScholarのAPIへ渡し、論文Aが参照する文献、論文Aを引用する文献、類似論文の候補を取得します。

取得結果をraw/openalex_keyword.json、raw/s2_references.json、raw/s2_citations.json、raw/s2_similar.jsonのように分けて保存すれば、どの探索経路から候補が入ったかを後で確認できます。

複数経路を使っても網羅性は保証されないため、研究者は公式目次との照合を続けます。

さらにエージェントは、文書の種別や会議の特性に応じて別のAPIも呼び出します。Crossref REST APIは登録不要で、worksとDOIの書誌メタデータをJSONで返すため、公式な出版物の書誌情報の取得に利用させます。プレプリントを対象に含める場合は、arXiv APIは検索結果をAtom XMLで返す特性に合わせて処理させます。

また、査読コメントなどが必要な場合は、OpenReview API v2は会議の公開範囲に応じて投稿とreplyを取得する経路として活用させます。

収集途中でarXivのプレプリントやICLRの投稿中論文がリストに混ざっていた場合、エージェントは自動で条件分岐を行い、それぞれarXiv APIやOpenReview API v2へリクエストを送って個別のメタデータを取得します。この処理から、情報源ごとの特性に応じて適切なAPIが選択され、それぞれ異なる形式のデータが正しく引き出されることが判断できます。

エージェントは、これら複数の経路からの応答をそのままraw/ディレクトリへ保存します。続いて、形式が異なるJSONやXMLを共通の列へ整形し、重複候補の抽出を行ってcandidates.csvとして一覧化します。さらに、タイトルと抄録を使った一次スクリーニングを行い、比較表の下書きであるscreening-draft.csvを作成します。

検索条件の実行履歴はrun-log.jsonに記録され、PRISMA-Sは情報源、検索式、検索日など検索手順の記録を求めるため、このログを報告用の検索記録へ反映できます。

自動処理が完了すると、rawディレクトリ内にopenalex_keyword.jsonやs2_citations.jsonといったデータが経路別に保存され、出力されたscreening-draft.csvには著者やタイトルが揃った下書き表が生成され、同時にクエリ実行履歴を含むrun-log.jsonが残ります。

これらの出力結果から、生データからスクリーニング直前の下書き表に至るまでの中間生成物がファイルとして手元に残り、後から検索手順の証拠としてたどれる状態になっていることが判断できます。

APIごとの手作業や、データ形式の統一、重複候補の抽出、そして下書き作成までの反復作業はエージェントへ任せることができます。しかし、AIが下書きを作成した後は研究者の役割に戻ります。最終的な採否基準の判断、PDFを開いての原文確認、プレプリントと出版版のどちらを引用するかの決定、そして発表の主張づくりは、研究者自身が行う操作として明確に境界を引きます。

出力されたscreening-draft.csvを研究者自身がスプレッドシートで開き、候補として残った論文のPDFを実際にダウンロードして、提案手法の評価指標が自分の研究目的に合致しているかを目視で確認し、最終的な採用の判断を下します。

この人による確認作業から、機械的なデータの収集と整形まではAIに任せつつも、内容の妥当性評価や学術的な意思決定には人間の専門知識が不可欠であるという責任の分界点が明確に判断できます。

CodexやClaude Codeへ調査を依頼する

探索の範囲と条件を決定したら、研究者が自ら学術APIを一つずつ操作するのではなく、AIエージェントへ反復作業を依頼します。Codex CLIはcodex execによる非対話実行と、stdio・HTTPのMCPサーバー登録を提供するため、人の対話を挟まずにタスクを自動実行できます。

同様に、Claude Codeはclaude -p、JSON出力、利用ツール制御、MCP設定を提供するため、これらを利用して一連の取得手順を自律的に進めさせることが可能です。

エージェントへ作業を任せるには、まず研究質問、対象会議、採否基準などを記したsurvey-spec.yamlを用意します。この調査仕様を渡し、候補取得、raw保存、形式統一、重複候補抽出、一次スクリーニング、比較表の下書き作成までを一つのタスクとして依頼します。

さらに、MCPはAIアプリケーションを外部のデータソース、ツール、ワークフローへ接続する標準であるため、学術APIをMCPツールとして登録しておけば、エージェントは共通の操作名で各経路を呼び出せます。

ここで、調査仕様に基づく実行場面を想定した架空の最小コマンド例を示します。

# Codex CLIの架空の実行例
codex exec "survey-spec.yamlを読み、指定されたAPIを使って文献候補を取得してください。取得元データはrawディレクトリに保存し、整形してcandidates.csvとrun-log.jsonを作成してください。"

# Claude Codeの架空の実行例
claude -p "survey-spec.yamlを読み、指定されたAPIを使って文献候補を取得してください。取得元データはrawディレクトリに保存し、整形してcandidates.csvとrun-log.jsonを作成してください。"

これらのコマンドを与えただけでは、期待通りの実行結果は保証されません。エージェントが外部システムへ自律的にアクセスするためには、APIキーなどの認証情報を環境変数として持たせ、ネットワーク接続やローカルへのファイル書き込み権限を与え、取得CLIなどの許可ツールをあらかじめ利用可能な状態に設定しておく必要があります。

この例から、CLIを通じた指示自体は自然言語で完結する一方で、タスクの完遂には入念な権限管理と事前準備が前提となることが判断できます。

環境が整うと、エージェントはsurvey-spec.yamlを読み込み、5つの学術APIを役割に応じて使い分けて候補を集めます。広範な検索が必要な場合は、OpenAlexはworksの検索・絞り込みに使う経路として選択されます。

引用ネットワークをたどる際は、Semantic Scholar Academic Graph APIはpaper search、bulk search、引用、参考文献の取得に使うため、ここから派生研究などを集めます。

公式の書誌情報を得るためには、Crossref REST APIは登録不要で、worksとDOIの書誌メタデータをJSONで返す特性が利用されます。プレプリントを含める指示があれば、arXiv APIは検索結果をAtom XMLで返す仕様に合わせて取得処理が行われます。

査読記録などが必要な場合は、OpenReview API v2は会議の公開範囲に応じて投稿とreplyを取得するため、このAPIが呼び出されます。

実行中、エージェントは取得したJSONやXMLをそのままraw/ディレクトリへ保存し、形式の異なるデータを共通の列へ整形します。この処理の過程で、アクセス制限による429、権限不足の403、ページング未完了、raw応答の欠落といった例外が発生した場合、エージェントは成功扱いにせず、エラーと停止位置をrun-log.jsonへ残します。

正常に取得と整形が進むと、エージェントは重複候補を抽出してcandidates.csvを出力します。さらに、タイトルと抄録を使った一次スクリーニングを自動で行い、採否理由や確認が必要な項目を記載した比較表の下書きとしてscreening-draft.csvを作成します。

一連の実行履歴はrun-log.jsonに記録されるため、後から同じ条件で再実行することが可能です。

このように、APIごとの反復操作やデータ整形はAIへ任せられます。しかし、エージェントが作成するのはあくまで下書きです。研究質問や採否基準の策定、PDFを開いて行う原文確認、プレプリントか出版版のどちらを引用するかの決定、そして最終的な発表主張の構築は、研究者が自ら担う必要があります。

AIの下書き作成と研究者の承認を分けることで、複数経路の候補を整理しながら、引用の根拠を原文位置とともに残せます。

AIが重複候補と比較表の下書きを作る

エージェントが複数の学術APIから取得した結果は、そのままでは形式がバラバラなJSONやXMLの集まりです。これを研究者が監査可能な一つの比較表へ変える作業も、CodexやClaude Codeへ任せることができます。

まずはraw/ディレクトリに保存した生データのファイル群からハッシュ値を計算してrun-log.jsonへ残し、保存時と検証時のSHAが一致することを確認します。

次に、エージェントへデータの形式統一と重複候補の抽出を依頼し、candidates.csvを作成させます。エージェントは自ら小さなスクリプトを作成・実行し、各APIの応答を共通の列へ正規化して重複判定を行います。

この名寄せの際、Crossref REST APIは登録不要で、worksとDOIの書誌メタデータをJSONで返すため、まずは正確な識別子であるDOIの照合を優先させます。

しかし、すべての重複をスクリプトで自動削除してはいけません。DOIがない候補や、arXiv APIは検索結果をAtom XMLで返すようなプレプリントのデータが含まれる場合、のちに査読を経て出版された版とは記述内容が変化している可能性があります。

そのため、プレプリントと出版版の異なる版を自動mergeしないようエージェントへ仕様を伝えます。完全に同一とは限らない候補にはpossible_duplicateや共通のグループIDといった目印を付け、独立した行としてリストに残します。

以下は、エージェントが出力するcandidates.csvの一部を示す架空の例です。

title	source	DOI	work_group_id	possible_duplicate
（説明用）Meeting Summary Evaluation	Crossref	DOIあり	G-01	TRUE
（説明用）Meeting Summary Evaluation	arXiv	DOIなし	G-01	TRUE

この出力から、AIによる機械的な重複削除が防がれており、同じ研究の出版版とプレプリント版の存在を人間が安全に視認して比較できる状態に保たれていると判断できます。

重複候補の整理が終わると、エージェントはタイトルと抄録だけを利用した一次スクリーニングに進み、比較表の下書きとなるscreening-draft.csvを出力します。このファイルには、事前にsurvey-spec.yamlで定義した基準に基づく採否候補と、その採否理由が自動で書き込まれます。

もしエージェントに適切なネットワーク権限や許可ツールが事前に与えられており、オープンアクセスのPDF本文へ到達できる環境であっても、AIの役割は原文断片の抽出までに留めます。エージェントには、抽出した情報が原文のどこに記載されていたかを示すpage、section、table、spanといった位置情報を下書きへ記録させます。

このように、APIからの候補取得、raw/への保存、形式統一、重複候補の抽出、一次スクリーニング、そして比較表の下書き作成まではAIへ任せられます。screening-draft.csvが出力された後は、研究者が自らの手と目で判断を下す工程へ移ります。エージェントが記入した採否理由や本文の断片は、決して原文の代替にはなりません。

研究者は元のPDFを開いて記録された位置情報を手がかりに文脈を確認し、最終的な採否、引用する版の選択、そして発表の主張を決定することへ集中します。

研究者は原文確認と採否判断に集中する

これまでの手順で、研究者が調査仕様を決め、CodexやClaude Codeといったエージェントへ反復作業を依頼する流れを示してきました。

エージェントが作成した下書きはあくまで作業の土台であり、ここから先は研究者が自らの判断を下す工程に移ります。まず、関連文書を見つけ出す一次スクリーニングにおいては、ASReviewはタイトル・抄録の優先順位付けを支援するが、初期検索の漏れは救えないという限界があります。

APIから取得した母集団に漏れがあれば、AIをどう活用しても重要な論文は発見できません。また、自動化はscreeningを減らしうるが感度低下がありうると指摘されています。そのため、AIが除外判定を下したリストであっても、関連研究が不当に弾かれていないかを研究者自身が確認する操作が必要になります。

論文の本文から手法や結果を抽出して比較表を埋める工程でも、ツールによる提案は下書きに留まります。論文のPDFファイルから記載内容を抜き出すRobotReviewerは人が提案を検証する半自動化として評価されたシステムです。

エージェントがscreening-draft.csvへ引用候補のページや原文の断片を提示したとしても、それをそのまま発表の証拠として採用してはいけません。

説明用の架空論文「Meeting Summary Study A」を例にします。エージェントが抄録だけを読み、「会議要約の品質評価指標が書かれていない」と判定し、screening-draft.csvへ除外候補として出力したとします。研究者は提案をそのまま受け入れず、PDFの「評価方法」節を開きます。

本文で人手評価の設計が説明されていれば、研究者は採択へ判定を変え、採用理由と確認したページを記録します。

この例から、AIの判定は限られた入力範囲に依存しており、抄録に現れない重要な文脈を取りこぼしうることがわかります。抽出や除外の判定が正しい文脈で行われているか、原文とバイアスは人が確認する必要があります。研究者は必ず元のPDFファイルを開き、AIの提案箇所と実際の記述を照らし合わせて検証しなければなりません。

大規模言語モデルの性能が向上しても、調査の全工程を任せることはできません。GPT-4評価は全段階で人の代替を一般化できないことが報告されています。AIへ任せられるのは、候補取得、raw保存、形式統一、重複候補抽出、一次スクリーニング、そして比較表の下書き作成までです。

一方で、調査の基盤となる研究質問の定義、採否基準の設定、PDFを開いての原文確認、プレプリントか出版版のどちらを引用するかの決定、そして最終的な発表の主張を作る作業は、人が担う判断として残ります。AIの下書き作成と研究者の承認を分けることで、複数経路から集めた候補を、原文位置へ戻って確認できる比較表にできます。

比較表から10分発表の主張を作る

エージェントが作成した下書きであるscreening-draft.csvをもとに、研究者自身がPDFを開いて原文確認を行い、最終的に承認した比較表が完成したら、そこから学会での10分間の発表に向けた主張を組み立てます。

研究者は完成した比較表を俯瞰し、既存研究の間で一致している見解、結果が対立している箇所、そしてどの研究でも未検証のまま残されている領域を抽出します。この作業により、最初にsurvey-spec.yamlで定義した自分の研究の問いから始まり、未検証の領域をどのように解決したかという含意へとつながる論理展開を作ることができます。

発表の主張づくりは研究者が担う重要な判断であり、AIが生成した要約などをそのまま利用することはありません。スライドを作成する際、各スライドのノート部分へ根拠となる論文IDと原文位置をあわせて記録しておきます。

説明用の架空テーマ「生成AIによる会議要約の評価研究」では、確認済み比較表を次の3枚へ分けられます。1枚目に複数研究が一致した評価項目、2枚目に結果が対立した条件、3枚目に比較表の「未検証」列へ残った研究課題を置きます。各スライドのノートには、P03・p.4・評価方法のように比較表の論文ID、ページ、節を記録します。

AIの要約文をそのまま貼るのではなく、研究者が原文を確認した行だけを発表の論理へ組み替える例です。

発表中に聴衆から指摘を受けたり内容に疑義が生じたりした場合は、比較表から転記した論文のページやセクション番号を手がかりに、元の論文の該当箇所へ戻って確認できます。

また、スライドへ先行研究の図表を引用する場合は、比較表に記載されたDOIの実在を確認し、リンク切れなどがないことを確かめます。同時に、引用元の図表ライセンスを元の論文PDFや出版社のサイトで研究者自身が確認し、転載が許可されている条件に従ってスライドへ適切にクレジットを記載します。

たとえば、スライドへ比較表にある論文ID「Taylor2023」の評価モデルの図を引用する際、研究者はDOIリンクをクリックして出版社のサイトを開き、クリエイティブ・コモンズ・ライセンスなどが付与されているかを確認した上で、スライドの図の下へ指定された形式のクレジットを追記します。

この操作から、著作権の確認や適切な学術的クレジットの付与は、ツールに依存せず研究者自身が責任を持つべき境界であると判断できます。

学会発表の日が近づいた際には、以前実行した調査からの差分を確認するための更新作業を行います。PRISMA 2020はsystematic reviewの報告指針であり、自動化の品質認証ではないものの、調査の過程を透明に保つための基準となります。

PRISMA-Sは情報源、検索式、検索日など検索手順の記録を求めるため、エージェントが以前の実行時に出力したrun-log.jsonがそのまま更新手順の手がかりになります。研究者は、CodexやClaude Codeへ前回のsurvey-spec.yamlと実行ログを渡し、差分の取得を依頼します。

学会発表の1週間前になったという架空の状況では、研究者はClaude Codeへ「run-log.jsonとsurvey-spec.yamlを読み、前回検索日以降の候補を同じ経路で取得し、差分だけを別ファイルへ出力して」と依頼します。前回の検索日、検索式、取得元を再利用できるため、どこを更新したかを後から確認できます。

エージェントが一次スクリーニングによる下書き作成までを済ませ、差分を含む新しいcandidates.csvとscreening-draft.csvを出力したら、そこから先は再び研究者の役割です。

新たに取得できた候補に対して、研究者がPDF原文を開いて採否基準に合致するかを判定し、プレプリントか出版版かの引用する版を選択して、最新の研究動向を発表の主張へ反映させます。反復作業をAIへ任せ、人が判断と確認に集中することで、原文位置を示せる引用根拠を発表へ反映できます。

よくある質問

Q1. 紹介されている学術データの取得経路は無料で利用できますか。

この記事で取り上げた学術APIには、登録不要または無料で利用できる経路が含まれます。たとえばCrossref REST APIは登録不要で、worksとDOIの書誌メタデータをJSONで返すため、書誌情報の取得に利用できます。

CodexやClaude Codeへ作業を依頼する際、OpenAlexはworksの検索・絞り込みに使うなど、公開APIをツールとして許可すれば候補取得やraw/ディレクトリへの保存を自動化できますが、AIエージェント自体の契約や実行費用は学術APIの利用条件とは別に確認します。

ただし、APIへのアクセスにはネットワーク接続の権限を与える必要があり、利用時のアクセス制限に対する処理もエージェントのタスクとして組み込む必要があります。

Q2. Google Scholarを使って検索を自動化することはできますか。

この記事では、Google Scholarからの自動取得を前提にしません。AIエージェントへ候補取得を任せる際は、Semantic Scholar Academic Graph APIはpaper search、bulk search、引用、参考文献の取得に使うことができるため、こちらの利用を検討してください。

エージェントへAPIキーなどの認証情報を与え、ネットワーク接続とツール利用を許可することで、自律的に取得から形式統一、そして候補一覧であるcandidates.csvの作成までを進めさせることができます。

Q3. エージェントへ作業を任せればPRISMAに準拠した調査であると証明できますか。

いいえ、AIツールを利用した事実だけでは証明になりません。PRISMA 2020はsystematic reviewの報告指針であり、自動化の品質認証ではないためです。調査の透明性を確保するためには、PRISMA-Sは情報源、検索式、検索日など検索手順の記録を求める基準に沿う必要があります。

研究者が研究質問や採否基準をsurvey-spec.yamlとして固定し、エージェントが実行履歴として残すrun-log.jsonを保持することで、どのような条件で候補を取得し、重複候補抽出や一次スクリーニングを行ったかという手順の根拠を示すことができます。

Q4. エージェントが作成した抄録の要約をそのまま比較表の証拠にしてもよいですか。

エージェントが作成した要約や抽出箇所を、原文の代替として発表の主張に用いることはできません。エージェントができるのは、タイトルや抄録を使った一次スクリーニングを行い、screening-draft.csvとして比較表の下書きを作成するまでです。

最終的に引用の証拠として採用するかどうかは、必ず研究者自身がPDF原文を開き、抽出された手法や結果が正しい文脈で書かれているかを確認して判断を下す必要があります。AIによる下書き作成と、人が担う確認作業は明確に分ける必要があります。

Q5. プレプリントとジャーナル版の論文が重複した場合、どう統合すればよいですか。

arXiv APIは検索結果をAtom XMLで返すなどしてプレプリントのデータが含まれる場合、異なる版をエージェントに自動で統合させてはいけません。エージェントへ形式統一と重複候補抽出を依頼してcandidates.csvを作成する際、出版版とは内容が異なっている可能性を考慮し、それぞれ独立した候補として残すよう調査仕様で指示します。

最終的にどちらの版を引用の根拠として決定するかは、研究者が原文を確認して選ぶべき人が担う作業となります。

Q6. 学会発表の直前に新しい論文が出ていないか確認するにはどうすればよいですか。

以前の実行時に作成したsurvey-spec.yamlとrun-log.jsonをCodexやClaude Codeへ渡し、差分の取得を依頼します。エージェントは過去の記録をもとに最新の候補取得、raw/ディレクトリへの保存、形式統一、重複候補抽出を再実行し、差分を含む下書きを提示します。

ただし、エージェントが自律的に外部システムを利用するためには、前回の実行時と同様にネットワーク接続の権限、APIキーなどの認証情報、許可ツールが設定されている必要があります。抽出された新しい候補についても、研究者がPDF原文を確認し、採否基準に合致するかを判定して発表の主張へ反映させます。