Open2

Paper2Code について by ChatGPT Deep Research w/ GitHub

P-HunterP-Hunter

Paper2Code リポジトリの概要と詳細解説

https://github.com/going-doer/Paper2Code

リポジトリの目的と概要

Paper2Codeは、機械学習分野の学術論文からソースコードを自動生成することを目的としたプロジェクトです。研究論文の内容を入力として、対応する実験や手法を再現する完全なコードリポジトリを出力することで、論文の再現実験や実装の手間を大幅に削減し、研究と実装のギャップを埋めることを狙っています。特に、論文著者が公式実装を公開していない場合でも、本システムを用いることで論文に沿った実験コードを自動で生成できます。

本リポジトリの中心となるのはPaperCoderと呼ばれるシステムで、これは大規模言語モデル（LLM）を用いたマルチエージェント方式のフレームワークです。PaperCoderは「計画」「分析」「コード生成」の3段階からなるパイプラインによって動作し、各段階を専門のエージェント（LLM）が担当します。この段階的アプローチにより、論文の内容を段階ごとに理解・整理し、最終的に高品質なコードを生成することが可能となっています。実際、著者らの評価では、PaperCoderは提案されたベンチマークデータセット「Paper2Code」および既存のベンチマーク(PaperBench)上で既存手法を上回る性能を示し、論文の内容に忠実で質の高い実装を生成できたと報告されています。

要約すると、Paper2Codeリポジトリの目的は、論文→コード変換の自動化を通じて:

  • 研究の再現性向上と検証コストの削減
  • 新規手法の実装時間の短縮（コードを書く労力の軽減）
  • LLMを用いたソフトウェア自動生成の可能性の実証
    を達成することです。

主な機能と構成

Paper2Codeリポジトリには、上記の目的を実現するための様々な機能とコンポーネントが含まれています。主な機能と構成要素は次のとおりです。

  • マルチエージェントによるコード生成パイプライン: 論文からコードを得るまでのプロセスを3つのステージ（計画・分析・コード生成）に分割し、それぞれをLLMエージェントが担当します。この分業によって、まず論文内容の整理と実装計画立案、次に各モジュールの詳細設計検討、最後に具体的なコード作成という段階的な処理が可能になっています。この構成により、複雑な論文の実装も一度に行うのではなく段階的に取り組めるため、より正確で一貫性のあるコード生成につながっています。

  • Paper2Codeベンチマークデータセット: 論文からのコード生成能力を評価するための専用データセットが提供されています。このデータセットは、ICML 2024・NeurIPS 2024・ICLR 2024の主要会議から90本の機械学習論文を収集し、それぞれに対応する公開GitHubリポジトリ（著者実装）を持つものを選んだものです。さらに扱うコード規模を制限するため、トークン数が7万未満のリポジトリに絞り込んでいます。最終的に各会議から質の高い30本ずつ、合計90本の論文が含まれており、論文内容をJSON形式に構造化したデータが格納されています。このデータセットはリポジトリ内のdata/paper2codeフォルダで説明されており、論文テキストのJSONや前処理済みJSON、PDF（別途提供）などで構成されています。PaperCoderの評価や他の手法との比較実験に利用可能です。

  • モデルベースのコード品質評価: PaperCoderが生成したコードリポジトリの品質を評価する仕組みも備わっています。従来の単純な自動評価が難しいこのタスクに対し、本リポジトリではLLMを用いた評価手法を採用しています。具体的には、OpenAIのモデル（「o3-mini-high」など）に生成コードを読み込ませ、実装の主要部分について批評させることで、1～5のスコアを算出します。この評価は参照なし評価（生成コードのみを評価）と参照あり評価（論文著者の公開した正解コードがある場合、それと比較して評価）の両方に対応しています。例えばTransformer論文のコードを参照あり評価した場合、モデルから「スコア4.5/5」といった総評が得られています。評価用のスクリプトeval.pyが用意されており、生成物の質を定量的に判断するのに役立ちます。

  • OpenAI APIおよびオープンソースLLM対応: コード生成に利用する言語モデルとして、OpenAIのAPI経由でGPT系モデルを利用する方法と、手元でオープンソースの大規模モデルを動かす方法の両方がサポートされています。デフォルトではOpenAIの「o3-mini」（OpenAIのモデルファミリーのニックネーム）が使われ、1論文あたりの実行コストはおおよそ0.5～0.7ドル程度と見積もられています。一方、APIを使わずローカルで実行したい場合には、Hugging Faceで公開されているdeepseek-ai/DeepSeek-Coder-V2-Lite-InstructモデルをvLLMライブラリを通じて利用できます。ユーザは選択に応じて必要なライブラリ（openaiまたはvllm）をインストールし、スクリプトを実行するだけで両者を切り替えることができます。

  • PDF・LaTeX入力への対応: PaperCoderは論文の入力形式として、PDF由来のテキストデータだけでなくLaTeXソースにも対応しています。多くの場合PDFしか入手できませんが、その場合でもAllenAIの提供するs2orc-doc2jsonツールを用いてPDFを解析し、論文構造を保持したJSONデータに変換する手順が示されています。一方で論文のLaTeXソースにアクセスできる場合は、そのテキストを直接入力として与えることで、より構造化された情報を元に解析を行うことも可能です。いずれの場合でも、PaperCoder内部では論文をJSONあるいはテキスト形式で読み込み、以降の計画・分析に利用します。

  • リポジトリ構成とサブモジュール: コードは用途別に整理されています。主要なディレクトリは以下のとおりです:

    • codes/：PaperCoderの中核となるPythonスクリプト群（例: 1_planning.py, 2_analyzing.py, 3_coding.pyなど）やユーティリティ関数類が含まれます。
    • scripts/：実行用のシェルスクリプト置き場。例としてrun.sh（OpenAI APIを使ってPDF解析から一連の処理を実行）、run_llm.sh（オープンソースモデルで実行）、run_latex.sh（LaTeXソースを使ってOpenAIで実行）等があります。
    • data/：先述のPaper2Codeベンチマークデータやその他付属データを格納。paper2code/サブフォルダにデータセットの詳細説明とJSONデータが収納されています。
    • examples/：動作例用の入力データや参照実装を配置。例えばTransformer.pdfとその解析JSON、前処理済みJSON、および著者提供の正解コード（Transformer_gold_repo/）が含まれ、Transformer論文での動作検証に利用されます。
    • outputs/：PaperCoder実行後の出力が保存されるディレクトリ。実行対象の論文名ごとにフォルダが作られ、その中に**planning_artifacts, analyzing_artifacts, coding_artifacts（各段階のログや生成物）と、最終生成コード一式が入った<PaperName>_repo/**フォルダが作成されます。例えば「Attention Is All You Need」という論文名では、outputs/Transformer_repo/に最終コードがまとまります。
    • results/：評価結果を保存するディレクトリ。評価スクリプトを走らせると、採点結果のログやスコアがここに出力されます。

以上のように、本リポジトリはPaperCoder本体（計画・分析・コード生成の各モジュール）とデータセット・評価スクリプト等の周辺機能が一体となった構成になっており、ユーザは提供されたスクリプトやデータを用いて一通りの流れを試すことができます。

使用されている技術やライブラリ

Paper2Codeでは主にPythonベースの技術スタックが用いられています。本プロジェクトおよび生成されるコードに関連する主要な技術要素は次のとおりです。

  • プログラミング言語: 実装および生成コードにはPythonが使用されています。PaperCoder自体はPython 3系で記述されており、生成されるコードも機械学習実験の実装という性質上、Python（および必要に応じて主要な機械学習フレームワーク）になる想定です。

  • 大規模言語モデル (LLM): 文章からコードを生成する核心技術としてLLMを利用しています。既定ではOpenAIのGPT系モデルをAPI経由で呼び出せるPythonライブラリopenaiを使用します。PaperCoderではモデル名「o3-mini」や「o3-mini-high」といったOpenAIのモデルが指定されており、これはおそらくGPT-4のカスタム設定モデルを指しています（推論精度やコンテキスト長を調整したもの）。また、オープンソースのLLMとしてはHugging Face上で提供されているDeepSeek-Coder-V2-Lite-Instructモデルが利用可能で、こちらはvLLMという高速推論ライブラリを介して動作します。vLLMは大規模モデルの推論を効率化するライブラリであり、ローカルGPUで比較的大きなモデルを扱うのに適しています。

  • PDF解析ツール: 論文PDFを構造化テキスト（JSON）に変換するために、AllenAIが公開しているs2orc-doc2jsonが利用されています。これはPDF内の文章・数式・引用などを解析してJSON形式に出力するツールで、PaperCoderでは論文の入力前処理としてこのツールを用いることを想定しています。実際のリポジトリにはs2orc-doc2json自体は含まれていませんが、READMEに使用方法が記載されており、ユーザが別途クローンして実行する手順になっています。

  • ライブラリと依存関係: その他のPythonライブラリとしては、OpenAI API利用のためのopenaiパッケージ、オープンモデル利用のためのvLLMパッケージの他、tqdm（進行状況プログレスバー表示）、json（JSON操作標準ライブラリ）、PyYAML（YAML読み書き）、argparse（コマンドライン引数処理）などが使われています。特にtiktokenというライブラリはトークン数の計測に用いられており、LLMへの入力長・出力長を管理したりコスト試算するために利用されています。これらの依存関係はrequirements.txtにもまとまっており、一括インストールも可能です。

  • Hugging Faceデータセット: 前述のPaper2CodeベンチマークはHugging Face上でデータセットとして公開されています。これはdatasetsライブラリ等から簡単に読み込める形式で、「iaminju/paper2code」という名称でホストされています。このように外部サービスも活用しつつ、データの再利用や共有が図られています。

  • 生成コードに関連する技術: PaperCoderが出力するコードは、各論文の内容に応じて機械学習フレームワーク（例えばPyTorchやTensorFlow）、データ処理ライブラリ（NumPyやPandas）などを使用する可能性があります。ただし、それらは生成されるコード次第であり、本リポジトリ自体の依存関係ではありません。PaperCoderは論文中に記載のあるアルゴリズムやモデル構成に応じて「必要なライブラリ」を推定し、計画段階で出力するタスクリストに**「Required packages」**としてそれらを挙げる機能があります。例えばある論文実験にPyTorchが必要であれば、計画フェーズで生成される設計情報に「torch」等が含まれ、実際のコード生成時には該当ライブラリのインポートを書くよう誘導されます。

以上が主な技術スタックです。まとめると、Python + LLMという基盤の上に、OpenAIやHuggingFaceの最先端モデルを活用しつつ、入出力の前処理・後処理には既存のツール（PDF→JSON変換など）や評価のための追加モデル利用なども組み合わせている点が特徴です。

使い方（セットアップ方法と使用フロー）

Paper2Codeリポジトリを使用して実際に論文からコード生成を行うには、以下の手順でセットアップと実行を行います。

1. リポジトリの取得: GitHub上のgoing-doer/Paper2Codeリポジトリをクローンします。必要に応じてgit cloneコマンドを使ってローカル環境にコードを取得してください。

2. 環境構築: Pythonの実行環境を用意し、依存ライブラリをインストールします。Python 3.7以上が推奨されます。必要なライブラリはrequirements.txtにまとまっており、一括インストールする場合は以下のように実行できます:

pip install -r requirements.txt

もしくは、OpenAI APIを使う場合は最低限openaiパッケージだけ、オープンソースモデルを使う場合はvllmパッケージだけ入れるなど、READMEに従い用途に応じてインストールすることも可能です。

3. 論文データの準備: コード生成の入力となる論文データを準備します。基本的には論文PDFをJSON形式に変換したファイルを用意する必要があります。変換にはs2orc-doc2jsonツールを使用します。例えばUbuntu環境であれば:

# AllenAIのPDF→JSON変換ツールをクローン
git clone https://github.com/allenai/s2orc-doc2json.git
cd s2orc-doc2json/grobid-0.7.3

# Grobidを使ってPDFをJSONに変換（例としてTransformer.pdfを変換）
./gradlew run
python ../doc2json/grobid2json/process_pdf.py -i path/to/Transformer.pdf -o output_dir/ -t temp_dir/

といった手順で、PDFから対応するJSON (Transformer.jsonなど)を得ます。得られたJSONファイルには論文の各セクションや文章、図表キャプション等が含まれています。PaperCoderではこのJSONをさらに前処理して不要なメタデータや引用情報を削除した「クリーンなJSON」を作成します。前処理は自動で行われるため、ユーザは変換後のJSONを用意するだけで構いません。なお、もし論文のLaTeXソースが手元にある場合は、JSON化を飛ばしてそのままテキスト入力として使うことも可能です（スクリプト内で--paper_format LaTeXを指定）。

4. OpenAI APIキーの用意（OpenAIモデルを使う場合）: OpenAIのモデルで実行する場合、APIキーが必要です。OpenAIのアカウントから発行されたキーを環境変数OPENAI_API_KEYに設定します。例えばLinux/Macのターミナルでは:

export OPENAI_API_KEY="sk-...あなたのAPIキー..."

と設定します。※このステップはオープンソースLLMを用いる場合は不要です。

5. 実行スクリプトの起動: scripts/ディレクトリに用意されているシェルスクリプトを使用してPaperCoderを実行します。代表的な実行方法は次の通りです。

  • OpenAI APIを使用する場合: scripts/run.sh を実行します。このスクリプトは予めOPENAI_API_KEYが設定されていることを前提に、PaperCoderの各段階を順次呼び出します。デフォルトではexamples/Transformer.pdf等を対象として動作しますが、他の論文を使う場合はスクリプト内の変数（論文名やパス）を書き換えます。run.shはPDFから変換したJSONを入力として使用します。一度の実行で計画策定からコード生成までをすべて行い、完了までには論文の長さにもよりますがおおよそ数分から十数分程度かかります（モデル応答待ち時間による）。

  • オープンソースモデルを使用する場合: scripts/run_llm.sh を実行します。OpenAIキーは不要ですが、事前にpip install vllmでvLLMをインストールしておく必要があります。実行手順や入力/出力はrun.shと同様ですが、ローカルで大規模モデルを動かすため、環境によっては高いGPUメモリが要求されます（DeepSeek-Coderの場合数十GBのVRAMが目安）。

  • LaTeXソースを使う場合: 論文のTeXソースファイルがある場合には、それを入力にしたscripts/run_latex.sh（OpenAI利用）またはscripts/run_latex_llm.sh（オープンモデル利用）を実行します。基本的な流れはPDF版と同様ですが、事前のPDF→JSON変換が不要で、スクリプト内でLaTeXファイルパスを指定します。

6. 結果の確認: スクリプトの実行が完了すると、outputs/ディレクトリ以下に結果が保存されています。例えばTransformer論文をrun.shで実行した場合、outputs/Transformer_repo/フォルダに最終生成コード（Pythonスクリプト群）が入っています。中には論文の内容に対応したmodel.pyやtrain.py、dataset_loader.pyなどのファイルが含まれているはずです。また、outputs/Transformer/フォルダ内のplanning_artifacts/, analyzing_artifacts/, coding_artifacts/には各段階で生成された計画書や解析内容、途中のLLM応答ログなどがテキストファイルとして保存されています。これらを見ると、PaperCoderが論文をどう理解しステップを踏んだかを追跡できます。初心者の方はまず生成された*_repo/内のREADMEやコードファイルを開き、内容が論文と対応していそうか確認してみると良いでしょう。

7. （任意）評価の実行: 必要に応じて、生成されたコードの品質評価を行うこともできます。リポジトリ内のcodes/eval.pyスクリプトを使用し、OpenAIのモデルにコードをレビューさせる形でスコアを算出できます。評価には再度OpenAI APIキーが必要です（評価自体もLLMを使うため）。評価を行う場合は、まずpip install tiktokenでトークン処理ライブラリを入れ（OpenAIモデル利用時に必須）、以下のようにコマンドを実行します。

cd codes/
python eval.py \
    --paper_name <論文名（例: Transformer）> \
    --pdf_json_path <対応する論文JSONパス（例: ../examples/Transformer_cleaned.json）> \
    --data_dir <データディレクトリ（例: ../data）> \
    --output_dir <出力ディレクトリ（例: ../outputs/Transformer）> \
    --target_repo_dir <生成コードのディレクトリ（例: ../outputs/Transformer_repo）> \
    --gold_repo_dir <正解コードのディレクトリ（ある場合）> \
    --eval_result_dir <評価結果出力先ディレクトリ（例: ../results）> \
    --eval_type <評価タイプ（ref_free または ref_based）> \
    --generated_n 8 \
    --papercoder

上記コマンドの引数を自身の環境に合わせて指定すると、評価が走ります（gold_repo_dirは論文著者の公式実装パスで、ない場合は指定不要で--eval_type ref_freeにします）。評価が完了すると、コンソール上にスコアや簡易レポートが表示され、同時にresults/以下に詳細な評価結果ファイルが保存されます。例えばTransformer論文の場合、参照あり評価でスコア4.5/5が得られたという結果が出力されています。このスコアリングはあくまでモデルによる主観的評価ですが、複数の観点から問題点を指摘し深刻度を判定する仕組みになっており、生成コードの妥当性チェックに役立ちます。

以上が典型的な使用フローです。まとめると、環境を整え→論文データを用意し→適切なスクリプトを実行→出力コードを確認・活用し→必要なら評価するという流れになります。一連の操作はREADMEの「Quick Start（クイックスタート）」や「Detailed Setup Instructions（詳細なセットアップ手順）」にも整理されているので、実際に試す際はそちらも参照するとよいでしょう。

アーキテクチャや処理の流れ

PaperCoderの内部アーキテクチャと処理の流れについて、各ステージごとに詳しく説明します。大きく分けて**計画（Planning）→分析（Analyzing）→コード生成（Coding）**の順に処理が進みます。それぞれの段階でLLMに与えるプロンプト（指示）が異なり、段階間で情報が引き継がれて最終的なコード完成に至ります。

1. 計画フェーズ (Planning Stage)

最初のフェーズでは、論文を読み取って実装計画を立てます。このフェーズは論文内容の全体像を把握し、再現実験のための方針を詳細に策定する役割を持ちます。PaperCoderはまず論文全文（JSON化されたもの、もしくはLaTeXテキスト）をLLMに入力し、「この論文の手法と実験を再現するにはどういったステップや構成が必要か？」を問いかけます。具体的には、LLMに対して以下のような指示が与えられています:

  • 論文の手法、モデル構成、ハイパーパラメータ、使用データセット、実験設定などを 忠実に踏襲 すること。
  • 手順を明確で段階的に、実装しやすいよう整理して提示すること。
  • 必要なら効率も考慮しつつ、論文通りに再現するための最善策を示すこと。

LLMはこの指示に基づき、まず**「再現のための計画書」**をテキストで出力します。ここには「どのようなモデルやアルゴリズムを実装すべきか」「実験の流れはどう再現するか」といった内容が詳述されます。この計画書にはまだ具体的なコードは含まれませんが、後続フェーズの土台となる重要な情報です。

続いて、PaperCoderはLLMに追加の質問を行い、より具体的な設計図を引き出します。それが**「ソフトウェアシステムの設計」**です。ここでは先ほどの計画を踏まえて、

  • 実装方針（どのように問題にアプローチするか）
  • ファイルの構成案（どんなファイルを作り、役割は何か）
  • データ構造や主要なクラス・関数のインターフェース（クラス図のような形式で）
  • プログラムの呼び出しフロー（シーケンス図のような形式で、各モジュールがどう連携するか）
  • 不明点や曖昧な点のリスト（実装時に確認すべき事項）

といった項目を含むJSON形式の詳細設計情報を出力するようLLMに求めます。LLMは回答を特定のフォーマット（[CONTENT]...[/CONTENT]で囲まれたJSONブロック）で返し、その中に上記の内容が埋め込まれます。例えばフォーマット例として、「File list」に["main.py", "model.py", "trainer.py", ...]のようなリストが提案され、「Data structures and interfaces」にはMermaid記法でクラスの関係図が、「Program call flow」には処理の順序を示すシーケンス図が記述されます。LLMがこのような擬似UMLの記述を返すことで、後続のコード生成フェーズで参照すべき全体像が機械可読な形で得られるのです。

さらに、計画フェーズの最後ではタスクリストの生成も行われます。設計ができあがった段階で、「では具体的にどのファイルに何を実装する必要があるか？」という観点でタスクの洗い出しと依存関係の分析をLLMに依頼します。ここでは各ファイルごとに実装すべき内容が箇条書きされ、またそのファイル間の論理的な依存関係（どのモジュールが先に準備されるべきか等）が整理されます。**「Logic Analysis（論理分析）」と「Task list（タスクリスト）」**という項目名で、この情報もJSON形式で出力されます。例えば「Task list」には"model.py": ["モデルクラスの定義", "..."], "trainer.py": ["学習ループの実装", "..."]のようにファイル毎のToDoが含まれるイメージです。

以上が計画フェーズで行われる処理です。このフェーズの結果、以下の成果物が得られます:

  • 全体計画書: 論文再現のための高レベルな方針とステップ（テキスト）。
  • 詳細設計JSON: 実装ファイル一覧、クラス・関数設計、フロー図、不明点等を含むJSONデータ。
  • タスクリストJSON: 実装すべきタスクの一覧と詳細、およびファイル間の依存関係情報。

PaperCoderでは、これらをplanning_trajectories.jsonという対話履歴ファイルや、抽出された**設定ファイル (planning_config.yaml)**として保存します。特に YAML形式の設定ファイルには、モデルのハイパーパラメータや使用データセット名など、実験再現に必要な定数設定が記載されています。これは詳細設計JSONの中から抜き出されたもので、後続フェーズでコードにこれらの設定値を反映するために使われます。例えば論文中で「学習率0.001、エポック数50」などと書かれていれば、その情報がconfig.yamlに書き出されます。計画フェーズはまさに人間でいう「設計書を書き上げた」状態に相当し、この時点ではまだコードを書いていませんが、次の段階への万全な下準備が整っています。

2. 分析フェーズ (Analyzing Stage)

次のフェーズでは、計画フェーズで得られた設計情報に基づき、各モジュールの詳細なロジック分析を行います。ここでは実際のコードを書く直前のステップとして、擬似コードや詳細手順の検討に相当する処理をLLMで行います。

分析フェーズが始まると、PaperCoderはまず計画フェーズの成果物を読み込みます。具体的には:

  • 前フェーズで生成したconfig.yaml（設定ファイル）、
  • 計画の概要（全体計画書のテキスト）、
  • 詳細設計JSON（ファイルリストやクラス図など）、
  • タスクリストJSON（必要タスク一覧と論理分析）、

これらをすべてLLMに与えます。その上で、「各ファイルごとに実装すべき内容を詳しく分析してください」というプロンプトを構築します。システムメッセージでは、分析エージェントに対し次の点を遵守するよう指示しています:

  1. 論文に整合すること: 解析結果（各ファイルのロジック）が論文の手法・設定と矛盾しないよう厳密に合わせる。例えば論文で使うモデル構造や評価指標はすべて反映する。
  2. 明確で構造的な提示: 分析内容は論理的で分かりやすく、実装の指針として有用な形式で提示する（箇条書きや段落など適切に）。
  3. 効率性と実践性: 実装しやすさや効率も考慮し、しかし忠実性を損なわない範囲で最適な分析を行う。
  4. 設計に従う: **「Data structures and interfaces」**で定義されたクラスや関数の設計を変更しないこと。つまり計画フェーズで決めたインターフェースは守り、勝手に新しい関数を増やしたりしない。
  5. 設定値の参照: 必要なハイパーパラメータや定数は常にconfig.yamlから読み取る想定で言及し、論文中にない値を勝手に仮定しない。

これらのガイドラインのもと、PaperCoderは各ファイルについて順番にLLMに質問を投げます。例えばタスクリストに["model.py", "trainer.py", "dataset.py", ...]というファイル群があれば、まずmodel.pyについて、次にtrainer.pyについて…と1ファイルずつ処理します。各ファイルに対するユーザメッセージは関数get_write_msgによって生成されており、そこでは論文内容、計画概要、詳細設計JSON、タスクリストJSON、**設定ファイル(config.yaml)をすべて含んだ上で、「この情報に基づき{ファイル名}**のロジック分析を行ってください。まだコードは書かず、必要な処理内容を詳述してください。」という指示文が組み立てられます。例えばmodel.pyであれば、「モデルの定義に関するロジックを解析せよ」という趣旨のプロンプトになります。

LLMはこれに応答して、各ファイルに対する詳細なロジック説明を返します。これにはそのファイルで実装すべきクラス・関数ごとの役割や、処理手順、擬似コードに近いもの、さらには他ファイルとの連携方法などが文章で書かれます。PaperCoderはこの応答をテキストとして保存し、analyzing_artifacts/フォルダにファイル別に記録します（例: 1.2_arch_design.txt, 1.3_logic_design.txtなど）。また、LLMからの各回答はJSON形式ではなく純テキストになりますが、内部では辞書にまとめてプログラム上で扱いやすいようにもしています。

要するに、この分析フェーズで得られるのは**「各ファイルの詳細な実装方針書」です。これには実質的にそのファイルの擬似コードやアルゴリズム手順書**が書かれていると思って良いでしょう。例えばtrainer.pyであれば「エポックループを回し、各エポックでモデルにデータを入力し、損失を計算し…」といった文章が出てくるはずです。また、dataset_loader.pyであれば「与えられたデータセット名に応じてデータをダウンロード/前処理し、PyTorchのDataLoaderを返す関数を実装する」といった具合です。これらの詳細分析により、コードを書く前に論理的な穴埋めがほぼ完成した状態になります。人間に例えるなら、コーディングに入る前に綿密な設計レビューと擬似コード作成を終えた段階と言えるでしょう。

P-HunterP-Hunter

3. コード生成フェーズ (Coding Stage)

最後のフェーズがコード生成です。ここでは、これまでに準備された計画・設計・分析の情報をすべて踏まえた上で、LLMに実際のソースコードを書かせます。PaperCoderはファイルごとに順番にコードを生成し、逐次それを保存して最終的に完結したコードベースを構築します。

コード生成フェーズの開始時、再度すべてのコンテキスト（論文内容、計画概要、詳細設計JSON、タスクリスト、設定ファイル）がLLMに与えられます。さらに分析フェーズで得られた各ファイルのロジック分析結果も順次投入されます。PaperCoderはまず生成すべきファイルのリストを把握し（タスクリストの「File list」部分）、例えばconfig.yaml（設定ファイル）は既にありますからそれ以外のファイルについて一つずつ取り組みます。

各ファイルのコード生成時に与えるプロンプトは、分析フェーズとよく似ていますが、より具体的な**「コードを書け」という指示になっている点が異なります。get_write_msg関数で作られるユーザメッセージには、まずコンテキスト**として:

  • 論文全文の内容（JSON）
  • 計画概要テキスト
  • 詳細設計JSON
  • タスク&ロジック分析JSON（計画フェーズからのPRD情報）
  • 設定ファイルconfig.yamlの中身

がすべて記載されます。さらに、すでに生成済みの他のファイルのコードがあればその内容も提示します。例えばmodel.pyのコードを生成する際は他にまだ何もないのでコードコンテキストは空ですが、次にtrainer.pyのコードを生成する際には、先に出来上がったmodel.pyの中身がプロンプトに埋め込まれます。これによってLLMは他のファイルで定義されたクラスや関数を参照しながらコードを書けるため、ファイル間の一貫性（例えばモデルクラスのクラス名やメソッド名を間違えない等）が保たれます。

プロンプトの最後にはフォーマット例として「python\n## {ファイル名}\n...」というコードブロックを書くよう指示し、加えて「**{ファイル名}**のコードを書いてください」という明確な指示文が与えられます。また、システムメッセージやユーザメッセージ中でコード生成時の注意事項も詳細に示されています:

  1. 1ファイルずつ: 今から書くのは指定された1つのファイルだけであり、それ以外のファイルのコードは出力しないこと。
  2. 完全なコード: プロジェクト全体の一部であっても、そのファイル単体で完結した実装をきちんと書く。未完成の関数やTODOなどは残さない。
  3. デフォルト値と型指定: 設定項目にはデフォルト値を設定し、型ヒントもしっかり付与して読みやすく。循環import（相互依存）を避ける構成にする。
  4. 設計に従う: 設計フェーズで決めたクラスや関数のインターフェースを守り、存在しない関数を勝手に呼び出したりしないこと。
  5. 漏れなく実装: 「このファイルで必要なクラス/関数が未定義」という事態がないよう、設計で決めた要素はすべて実装する。
  6. 適切なインポート: 外部ライブラリや他ファイルのクラスを使う際は、ファイル冒頭で必ずimport文を忘れない。
  7. 設定の利用: config.yamlに書かれた設定値はハードコーディングせずに参照する（例えば学習率などはconfigから読む）、そして論文にない値を勝手にでっち上げない。
  8. コーディング規約: コードはエレガントでモジュール化され、Googleスタイルガイドに従うこと、とシステムメッセージで述べられています（PEP8準拠、コメントの書き方など含め）。

以上のような細かい指示を踏まえ、LLMが出力したコードテキストはpythonのマークダウン形式で返ってきます。PaperCoderはその返答からコードブロックの中身だけを抽出し（余計なコメント等があれば取り除き）、対応する.pyファイルとして<PaperName>_repo/ディレクトリに保存します。この処理を全ての対象ファイルについて繰り返すことで、最終的に論文の実験を再現するためのコード一式が出揃うという仕組みです。

例えば、Transformer論文の場合を考えてみましょう。計画段階でTransformer_repoには次のようなファイルが必要と決められたとします:

  • config.yaml（ハイパーパラメータや設定）
  • model.py（Transformerモデルの実装）
  • train.py（学習ループとトレーニング処理）
  • dataset.py（データセットの読み込み処理）
  • evaluate.py（検証・評価処理）
  • utils.py（補助関数 等）

計画・分析フェーズを経て、まずconfig.yamlが自動生成されています（これはPythonコードではなく、前段階で生成済み）。コード生成フェーズではmodel.pyから順に上記ファイル群がLLMによって書かれ、1ファイル生成するごとにディスクに保存されます。model.pyにはTransformerのエンコーダ・デコーダやマルチヘッドAttentionのクラスが実装され、train.pyにはデータロード->モデル初期化->エポックごとの学習->モデル保存という一連の流れが書かれる、といった具合です。PaperCoderはファイル間の依存関係を把握しているため、例えばtrain.pyを書く際にはmodel.pyで定義されたTransformerModelクラス名をちゃんと認識した上でコードを書くので、相互の呼び出しが矛盾しません。

このようにして全ファイルのコード生成が完了すると、前述の出力フォルダ（例: outputs/Transformer_repo/）に一通りのコードプロジェクトが揃います。あたかも人間の開発チームが設計から実装まで行ったかのような成果物が、自動的に得られるわけです。

最後に、PaperCoderは（OpenAI APIを用いた場合）各段階でどれだけトークンを消費しコストがかかったかを集計し、accumulated_cost.jsonに記録する処理もしています。これは実行ログ的な情報ですが、どの論文に対してどのくらいAPI費用が発生したか追跡できるようになっています。

以上がアーキテクチャと処理の流れの詳細です。ポイントをまとめると:

  • 計画: 論文内容を解析し、再現実験のためのプランニングと設計図作成（ファイル構成・クラス図・タスクリストなど）。
  • 分析: 設計図に基づき各ファイルの実装内容をテキストで詳細分析（擬似コード的なものを準備）。
  • コード生成: 分析結果を元に、LLMが各ファイルの実際のコードを順次出力し、プロジェクト全体を構築。

この三位一体のプロセスにより、論文→コード変換という複雑な作業をLLMが段階的にこなせるよう工夫されています。内部で用意されるプロンプトやフォーマット、設定ファイル共有などの仕組みが、各段階を滑らかに接続し、一貫性を維持する鍵となっています。

想定されるユースケースや応用例

Paper2CodeおよびPaperCoderシステムには、さまざまな潜在的ユースケースや応用シーンが考えられます。以下に主な例を挙げます。

  • 研究論文の再現実験: 機械学習研究者や学生にとって、新しい論文の結果を再現することは重要ですが、多大な実装コストがかかります。PaperCoderを使えば、論文を入力するだけでその論文の実験コード一式が自動生成されるため、再現実験の敷居が下がります。例えば最新のICML論文を読んで「自分でも試したい」と思った際、人手で1週間かかっていた実装が、PaperCoderなら短時間で雛形コードを得られる可能性があります。得られたコードをベースに細部を調整したり、実行して結果を検証したりすることで、より迅速な研究サイクルを回すことができます。

  • 論文実装の学習支援: 機械学習を勉強中のエンジニアや学生にとって、論文をコードに落とし込む作業は難易度が高いものです。PaperCoderが生成する計画書やロジック分析、そしてコードは、お手本として学習に役立ちます。初心者は論文を読み、PaperCoderの出力した計画・コードと照らし合わせることで、「どのように文章中のアルゴリズム記述が実際のコードになるのか」を具体的に学べます。特に計画段階の出力物（UML風の設計図やタスクリスト）は、人間が設計を考える際のプロセスを疑似体験できる教材と言えるでしょう。ゆえに、本システムは単にコードを提供するだけでなく、教育的なツールとしても応用可能です。

  • プロトタイピングとアイデア検証: 企業のR&D部門やハッカソンなどで、新しいアイデアの迅速な検証が求められる場合にもPaper2Codeは有用です。関連する論文が既に存在する場合、その論文を元にコード生成を行い、まずは動くプロトタイプを得ることができます。それを出発点に改良を加えたり別のデータセットに適用したりすることで、0から実装を起こすよりも早くアイデアの有用性を試すことができます。特に論文著者の公式コードが公開されていないケースでは、自前実装するよりPaperCoderに任せてしまったほうが早いという場面もあり得ます。

  • コード生成AI研究のベンチマーク: Paper2Codeベンチマークデータセット自体の価値も大きいです。他の研究者がこのデータセットを使って、新たな「論文からのコード生成モデル」の研究を進めることができます。例えば、より小さなモデルでPaperCoderに匹敵する性能を出す手法や、計画・分析をさらに高度化するアルゴリズムなどを開発した場合、その効果を90本の論文データセット上で評価できます。従来、論文→コードの自動化には標準的な評価基盤がありませんでしたが、Paper2Codeにより一つの指標が提供されたことで、この分野の研究が活性化することも期待されます。

  • 自動化された大規模再現プロジェクト: 複数の論文を一括でコード化し、横断的に比較実験をする、といった応用も考えられます。例えばある研究者が「過去5年間の画像分類の手法を全部PaperCoderでコード生成して同一データセットで比較する」などのことも技術的には可能です。人手では到底不可能な規模の再現実験を自動コード生成により実現し、研究分野の俯瞰的な分析に役立てるといったメタ研究的な応用もあり得ます。

  • 将来的な応用: PaperCoderのコンセプトは、「テキスト（論文記述）から実行可能なコードを得る」というものです。この延長線上には、特定分野以外への展開（例えば医学や物理学の論文から分析コードを生成）や、論文以外の文章からのコード生成（設計書からのコード生成など）も考えられます。また、ソフトウェアエンジニアリングにおいて要件定義書や技術仕様書から自動で骨格コードを起こす、といった実用的な応用へのヒントにもなるでしょう。PaperCoderで培われた「マルチステップにより精度を上げるコード生成」アプローチは、他の生成AI分野（ストーリーからのゲームシナリオ生成等）にも応用可能かもしれません。

以上のように、Paper2Codeが直接提供する価値（論文コードの自動生成）だけでなく、派生的な応用範囲は広く存在します。特に機械学習コミュニティにおいては、再現性の確保や人手不足の解消という観点で大いに役立つツールとなるでしょう。

現在の開発状況やメンテナンスの有無

Paper2Codeリポジトリは2025年に公開された比較的新しいプロジェクトです。2025年4月に本システムの内容をまとめた学術論文がarXivにプレプリント公開されており、その研究成果を実証するためのコードとデータが本GitHubリポジトリに公開された形となっています。したがって、リポジトリ自体の開発も現時点（2025年）で活発に行われている可能性が高いです。実際、README等には最新の研究内容が反映されており、ICLR/ICML/NeurIPS 2024の論文データが含まれるなど、直近の動向を踏まえたものとなっています。

現時点でこのプロジェクトが長期的にメンテナンスされるかどうか明言された情報はありません。しかし、以下の点から一定の継続性が期待できます。

  • 研究コミュニティでの関心: 論文からコードへの自動変換という課題は、再現性問題の解決や生成AIの新たな応用先として注目度が高く、Paper2Codeはその先駆け的プロジェクトです。公開直後から研究者や開発者の関心を集めれば、IssueやPull Requestを通じた改善、機能追加などコミュニティ主導のメンテナンスが行われる可能性があります。

  • データセットの今後: Paper2Codeベンチマークデータセットは一度公開されたことで、今後もアップデートされる可能性があります。例えば収録論文数を増やしたり、新たな年度の会議論文を追加したり、といった拡張が考えられます。その際は本リポジトリにもデータ追加やスクリプト更新が行われるでしょう。

  • 実運用への発展: PaperCoderそのものが、研究室内の実験ツールからより一般向けのサービスや製品に発展する可能性もあります。その場合、バグ修正やコードリファクタリング、ドキュメント整備などのメンテナンスが継続して行われるでしょう。

現状、リポジトリ上ではREADMEやコードに「今後の予定」や「ロードマップ」の記載は見当たりませんが、論文が投稿・発表された段階であり、まずは研究成果のプロトタイプ実装として一区切りついた状態と考えられます。そのため、大きな追加開発は一段落している可能性もあります。しかし、Paper2Codeが提起した課題は非常に挑戦的であり、今後も改良の余地が多分にあります。たとえば:

  • マルチエージェントの協調をさらに高度化して、より大型の論文やコードにも対応できるようにする
  • より低コストなモデルでも動作するよう最適化する
  • 他分野の論文に対応する汎用性の検証

といった発展が考えられ、これらが進めばまたリポジトリに変更が加わるでしょう。

メンテナンスの有無についてまとめると、本リポジトリは現在公開されたばかりで、今後もしばらくは作者らによるサポートやアップデートが期待できる段階といえます。GitHub上でIssueを立てれば反応があるかもしれませんし、重大なバグが見つかれば修正コミットが行われるでしょう。長期的にはプロジェクトの性質上、研究用途のコードであるため大規模なコミュニティ開発に発展するかは未知数ですが、少なくともデータセットとコードが公開されたことで、第三者による検証・改良が可能な状態になっています。今後の学会発表や他の追随するプロジェクトなども含め、Paper2Codeの動向に注目が集まると思われます。

最後に、本リポジトリのライセンスにも触れておくと、Paper2Codeデータセット部分は各論文に由来するため権利関係に注意が必要ですが、コード自体は一般的なOSSライセンスの下で公開されている可能性があります（リポジトリ内のLICENSEファイル等を確認してください）。いずれにせよ、研究目的での利用については比較的寛容に作られているはずです。ユーザはREADMEや付属文書の注意事項に従って、本システムとデータを活用すると良いでしょう。

以上、going-doer/Paper2Codeリポジトリの概要から詳細までを説明しました。Paper2Codeは、最先端のLLM技術を用いて学術分野の課題（論文実装の自動化）に挑んだ意欲的なプロジェクトであり、そのリポジトリには有用なデータと興味深い実装手法が詰まっています。初心者の方も、本回答をガイドとして実際にリポジトリを動かしながら学習を深めていただければ幸いです。

参考文献・出典: リポジトリ内のREADMEおよび関連ドキュメントなど.