prepare-artifacts

アーティファクトの準備

研究用コードベースを、投稿可能でバッジ取得に対応した再現性アーティファクトに仕上げます。アーティファクト評価は、多くのシステム／PL／ML系の学会で採択後に行われる独立したプロセスで、専用の締切、付録、そして学会ごと、年ごとに変わるバッジがあります。このスキルでは、パッケージ（README、付録、実行手順、匿名化されたリポジトリ、アーカイブへの登録に関するガイダンス）を作成し、アーティファクトの準備状況チェックリストとパッケージング計画を用意し、レビュー担当者が実際に確認する基準に照らしてアーティファクトディレクトリを検査します。

著者の実験を実行したり、結果が再現されたと主張したりはしません。パッケージを準備・検査し、レビュー担当者が手作業で確認する内容を著者に正確に伝えます。

使用する場面

• 「論文が採択されました。アーティファクト評価やバッジ取得はどうすればよいですか？」
• 「コードを投稿用にパッケージ化／整理してください。」／「レビュー用にリポジトリを匿名化してください。」
• 「アーティファクト付録／Artifacts Available／Functional／Reusableとは何ですか？」
• 「Zenodo DOIは必要ですか？コンセプトDOIとバージョンDOIの違いは？」／「Software Heritageとは何ですか？」
• 「NeurIPSのコード／再現性チェックリスト、またはACLの再現性チェックリストを埋めてください。」
• 「このバッジでReproducedとReplicatedはどういう意味ですか？」
• prepare-camera-readyと併用する場合（匿名化解除と最終登録が重なる場合）。

入力

1. アーティファクトディレクトリ — パッケージ化するコード／データのリポジトリ（パス）。
2. 対象となる学会とトラック。可能であればvenues/conferences/<v>-<year>.ymlも用意してください （レビューのブラインドレベルが記載されています。ファイルがない場合はparse-cfpで作成します）。 学会プロファイルには、アーティファクトトラックで提供されるバッジや、その個別の締切は記載されていません。これらは最新情報を取得します（手順1）。
3. 論文の主要な主張（主張ごとの再現計画を作成するため）と、アーティファクトがレビュー段階（多くの場合ダブルブラインド）向けか、最終版の登録用かを指定してください。この違いによって、匿名化ZIPかバージョンDOIかなど、すべてが変わります。

プロセス

1. 学会の最新のCall for Artifactsを取得します。必須で、最新情報を確認します。 バッジの提供内容は学会ごと、年ごとに変わります（OSDI '26で評価されるのは「Artifacts Available」のみですが、SOSP '26では3種類すべてが提供されます）。過去の記憶や前年の情報は必ず古くなっているため、最新情報を確認してください。最新のCFAで、今回提供されるバッジ、アーティファクト専用の締切、アーカイブ保管の要件、付録のテンプレート／分量、ブラインド方式を確認します。最初の確認には次のスナップショットを使用できますが、必ず再確認してください。信頼しきってはいけません。 references/venue-artifact-rails.md. 選択したバッジの目標とアーティファクトの締切を.paper-memory/decisions.mdに記録します。

2. バッジの分類と時代による違いを確認します。 python3 scripts/badge_advisor.py --badge <name>を実行すると、ACM v1.1のファミリー／ティアと、特に重要なReproduced／Replicatedの入れ替わりが表示されます。ACMは2020-05-14にこれらの用語を逆転させたため、2020年より前のバッジでは逆の意味になります（--era pre-2020）。再現はビット単位で完全一致する必要はありません。論文の主張が変わらない許容範囲内で一致する必要があります。背景情報： references/badging-standards.md.

3. レビュー担当者が確認する基準に照らして、アーティファクトディレクトリを検査します。

   python3 scripts/check_artifact.py <artifact_dir> \
       --venue venues/conferences/<v>-<year>.yml [--blind double]
   

   ファイルパスとともに、次の項目を報告します。MLコードの完全性に関する5項目（依存関係の仕様、トレーニングコード、評価コード、事前学習済みモデルまたはその入手方法の説明、結果の表と正確な再現コマンドを含むREADME）、アーカイブ登録の準備状況（GitHubのみか、DOI／SWHIDがあるか）、ダブルブラインド匿名化（著者名／メールアドレス、識別可能なURL、.gitディレクトリ、PDF／付録のメタデータ。学会のブラインドレベルまたは--blindに基づきます）、および衛生面（LICENSE、アップロードサイズの上限）。フラグ：--json、--strict、--zip-cap-mb N、--venues-dir。終了コード：問題なしは0、エラーは1、使用法の誤りは2です。この検査の対象はファイルのみです。ビルドが実行できること、結果が再現されること、DOIが解決できることは証明できません。

4. 著者と一緒に、提出先が求めるパッケージを作成します（著者に代わって作成するのではありません）。

   • README — 概要、依存関係を正確にインストールする方法、各結果を再現するための正確なコマンド、結果の表、ハードウェア／実行環境の要件、ライセンスを記載します。（ML Code Completeness の項目 5。）
   • 成果物の付録 — USENIX 系の Phase 2 では、3 ページ以内の PDF（指定の LaTeX テンプレートを使用）を用意し、ハードウェア／ソフトウェア／設定、論文の主要な主張、および主張ごとの再現手順と結果の比較方法（「X% 以内なら一致」）を記載します。SIGMOD ARI では、実験スクリプトとグラフ生成スクリプトの両方を含めます（数値の完全一致ではなく、「同様の傾向」を示します）。
   • チェックリスト — NeurIPS Paper Checklist／Code policy または ACL の「Responsible NLP Research」チェックリストに正確に記入します。理由を添えた正直な「いいえ」／「該当なし」は問題ありませんが、未提出または誤解を招く記入はデスクリジェクトの対象となります（ARR は 2024 年 12 月以降、誤解を招く記入をデスクリジェクトの対象としています）。チェック項目を「はい」にするための不正な操作はしないでください。

5. ダブルブラインド査読用に匿名化します（査読段階の場合）。匿名化した .git を含まない ZIP を用意するか、Anonymous GitHub（anonymous.4open.science）を介して公開し、削除対象となる識別情報をすべて列挙します。PDF／付録のメタデータ、謝辞、資金提供、自己引用の表現を対象に含めます。論文と同じ規則を適用してください（anonymize-paper）。詳細： references/archival-hosting.md。

6. アーカイブへの登録を計画します。「Artifacts Available」では、恒久的なコピーをアーカイブ用のホストに置く必要があります。USENIX 系では GitHub／個人サイトは認められません。最終版には Zenodo のバージョン DOI を使用します（評価中に限り、概念 DOI も可）。または Software Heritage SWHID（intrinsic、ISO/IEC 18670）を使用します。両者は相互に補完するものです。アーカイブから引用メタデータが生成されるよう、CITATION.cff/codemeta を追加します。カメラレディ版の提出時に匿名化を解除し、最終版を登録します（prepare-camera-ready）。

7. 成果物の準備状況チェックリストとパッケージ作成計画を paper-workspace/submission/artifact-readiness.md に作成し、paper-workspace/INDEX.md に行を追加します。重大度の高い順に並べ、各指摘の根拠（lint、ライブ CFA、バッジの分類体系）を記載します。ファイル単位の基準を満たすまで lint を再実行します。

出力

• 成果物の準備状況チェックリスト（PASS／PASS-WITH-WARNINGS／FAIL とファイルパスを記載）とパッケージ作成計画：目標とするバッジ（ライブ CFA に基づく）、ホスティング方法（査読用の匿名版と最終版の DOI／SWHID）、解消すべき完全性の不足、作成する付録／チェックリスト、成果物の個別の締切。paper-workspace/submission/ に作成します。
• 著者が編集し、管理する README／付録／チェックリストの草案。

分野に合わせて調整する

ここでのバッジの分類体系は ACM／USENIX／SIGMOD／ETAPS／ML 分野の学会に特化しています。他の分野では、その分野の会場における成果物／データ公開の規則（例：学術誌の「データ公開声明」、FAIR データの登録）に置き換えてください。完全性と匿名化の lint は分野ではなくディレクトリを読み込むため、どの分野でも引き続き適用できます。

ガードレール

• 会場の現在のアーティファクト規則を必ずリアルタイムで再確認してください（ステップ1は省略できません）。 バッジの提供状況は会場や年によって変わります。記憶や昨年の情報を前提にしないでください。取得直後は過信しやすいため、一次資料の CFA を再確認してください。
• 結果が再現されると主張してはならず、ビット単位で完全に一致する再現を要求してもなりません。 ACM／SIGMOD／ETAPS では、論文の主張を変えない許容範囲内での一致が求められます。このスキルはパッケージの準備と確認を行いますが、実験を実行したり、科学的妥当性を判断したりするものではありません。
• Reproduced と Replicated の用語は2020年に入れ替わりました — 解釈する前に、バッジの時期を badge_advisor.py --era で確認してください。
• アーカイブ用ホスティングには固有の要件があります： USENIX 系列では、GitHub の URL は「Available」ではありません。著者には Zenodo のバージョン DOI／SWHID を案内してください。
• 匿名化を考慮してください： ダブルブラインド審査では、審査段階でアップロードする前に .git、名前、メールアドレス、URL、メタデータを除去してください。
• チェックリストは正確に記入し、見せかけの記入はしないでください： 正当な理由を添えた誠実な「いいえ」／「該当なし」は問題ありませんが、誤解を招く申告は編集部で却下されます。
• コパイロットであり、操縦士ではありません： デポジットやアーティファクト評価システムへの提出を行ってはならず、著者に代わってチェックリストのフォームに記入してもなりません。準備、静的解析、説明を行い、クリックするのは著者です。
• 問題として指摘された行／パスだけを引用してください。著者のアーティファクトをこのリポジトリにまとめて含めてはなりません。

メモリ

共有の .paper-memory/ 規約を使用します（完全な仕様： paper-memory-convention.md）。

• 開始時： lessons.md（修正済み項目の再指摘は避け、recurring なパッケージングの習慣があれば最初に伝えます。例：「.git ディレクトリを含めたまま納品しがちです」）と decisions.md（選択した会場／バッジの目標とアーティファクトの締め切り）を読みます。
• 終了時： 目標のバッジとアーティファクトの締め切りを decisions.md に追記し、覚えておく価値のある指摘ごとに、共有形式 - [YYYY-MM-DD] (prepare-artifacts | <scope>) issue -> recommendation で日付入りの項目を1つ lessons.md に追記します（日付の付与と重複排除を行う reflect-and-improve の reflect_log.py append を使用してください）。
• 必要に応じて .paper-memory/ を作成し、プロジェクトの .gitignore への追加を提案してください。ローカルのみで使用し、アップロードしたり、このリポジトリにコピーしたりしてはなりません。