Artifact Evaluation 101 ― セキュリティトップ会議のAE実践ガイド / Artifact Evaluation 101: A Practical Guide to AE at Top-Tier Security Conferences

2026年10月22日のCSS2026 MWS企画セッションで発表した「Artifact Evaluation 101 ― セキュリティトップ会議のAE実践ガイド」の講演資料です

Transcript

1. CSS 2026 MWS 企画 チュートリアル（4C2） Artifact Evaluated MWS Available Artifact Evaluation 101 Functional Reproduced セキュリティトップ会議の AE 実践ガイド NTTドコモビジネス株式会社 久保 佑介 © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 2026年10月22日
2. はじめに 自己紹介 業務内容 久保 佑介 セキュリティ研究者、プロダクトマネージャ、Red Team NTTドコモビジネス株式会社 イノベーションセンター 早稲田大学 森研究室（社会人博士学生） 専門 CI/CD Security、Offensive Security 立ち位置 AE の経験 [NDSS’26] 採択論文で AE に参加 学術 産業 Action Required: A Mixed-Methods Study of Security Practices in GitHub Actions [NDSS’27] AEC (Artifact Evaluation Committee) メンバー その他の経験 [BHEU’25] Arsenal で GHARF を発表 GHARF: GitHub Actions RedTeam Framework（GitHub で OSS として公開） © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 2 / 69
3. はじめに この講演の目的と流れ この講演で目指すこと Artifact Evaluation (AE) が分かりAE に参加する一歩を踏み出せる 1 AE のしくみ AE の流れと4会議での違い 2 実践から見た AE 著者と AEC の両方で AE に関わった経験 3 2.1 著者として提出する NDSS 2026 の論文で Artifact を出しバッジを得た経験 2.2 AEC として評価する NDSS 2027 の AEC として Artifact を評価した経験 まとめ © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. AE の要点の振り返りと今後の AE への考え 3 / 69
4. はじめに 本資料で参照する学会と開催年 CFP・Call for Artifacts（CfA）・secartifacts がすべて公開されている最新の年を参照する（2026年10月時点） 学会 CFP CfA secartifacts 参照する年 NDSS Network and Distributed System Security Symposium 2027 2027 2027 2027 USENIX USENIX Security Symposium 2027 ※ 2026 2026 2026 ACM Conference on Computer and Communications Security 2026 2026 ページなし 2026 IEEE Symposium on Security and Privacy 2027 ※ 2027 ※ 2026 CCS S&P CFP と CfA で決める 2026 ※ 参照する年より新しい USENIX 2027 の CFP と S&P 2027 の CFP・CfA にも Artifact と AE の決まりの大きな変更はない 出典: NDSS 2027 CFP [1]・CfA [2]・AE サイト [3] ／ USENIX Sec 2026 CfA [4]・AE サイト [5] ／ USENIX Sec 2027 CFP [6] ／ ACM CCS 2026 CFP [7]・CfA [8] ／ IEEE S&P 2026 AE サイト [9] ／ IEEE S&P 2027 CFP [10]・CfA [11] © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 4 / 69
5. はじめに secartifacts AE を出す際に参照する会議ごとの要件・手順・結果が記載されたサイト（各会議の AE の運営者が作成） 会議と年 年ごとのページ（そろい方は会議・年で違う） NDSS 2024–2027 Call for Artifacts 募集の要項・日程 USENIX 2020–2026 Badges バッジの基準 CCS なし Submission instructions・Tips 提出の手順と助言 S&P 2026 Results バッジを得た論文 その他: ACSAC・CHES・PETS・SysTEX・ Awards Artifact の表彰 secartifacts.github.io USENIX VehicleSec・WOOT Artifacts Without Evaluation（/artifinder/） AE を通らずに公開された Artifact の一覧（ArtiFinder で自動抽出） 対象: NDSS・USENIX・CCS・S&P・ACSAC 出典: secartifacts.github.io [12]・secartifacts の GitHub [13] ／ NDSS 2027 CfA [2] ／ USENIX Sec 2026 CfA [4] ／ ACM CCS 2026 CfA [8] ／ IEEE S&P 2026 instructions [14] © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 5 / 69
6. 1. AE のしくみ 1.1 AE とは 1.2 AE の進め方 1.3 Artifact の中身 1.4 扱いに配慮が要る Artifact 1.1 AE とは 2. 実践から見た AE 2.1 著者として提出する 2.2 AEC として評価する 3. まとめ © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 6 / 69
7. 1.1 AE とは Artifact Evaluation (AE) 採択論文の Artifact を評価して結果をバッジで示す仕組み 出す 著者 評価 判定 Artifact AEC バッジ コード・データ・モデル など Artifact Evaluation Committee Available Functional Reproduced 出典: NDSS 2027 AE サイト [3]・Badges [15] ／ USENIX Sec 2026 AE サイト [5]（定義は本資料のまとめ） © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 7 / 69
8. 1.1 AE とは AE の目的 論文の主張を支える結果を別の人が実験をくり返して得られるよう再現性を推し進める NDSS “promotes the reproducibility of experimental results” USENIX・S&P “promote the availability and reproducibility” CCS “encourages replicability and reproducibility” 論文のもとになったコード・データなどを公開・普及させてほかの研究者が使えるようにする NDSS “the dissemination of artifacts” USENIX・S&P “promote the availability” CCS “The dissemination of artifacts benefits our science” 再利用・再現できる形に力を注いだ著者を評価して著者自身にも利点をもたらす NDSS “recognizes authors who devote effort” USENIX・S&P “the benefits to the authors” CCS “recognize their authors” 効果の実例: Artifact から実装と論文の記述の食い違いが見つかる USENIX Security 2026 論文集の巻頭「Message from the Program Co-Chairs」 “As with similar conferences, we required authors to provide anonymized artifacts during submission. Reviewers checked for compliance, […] Accepted papers underwent artifact availability verification, […] Optionally, accepted papers could undergo artifact functionality and reproducibility verification. Both reviewers and artifact evaluators identified cases of mismatch between implementations and paper descriptions, underscoring the important role of artifacts in paper review.” ほかの会議と同様に、投稿時には匿名化した Artifact の提出を求め、規定どおりかを査読者が確認した（…）。 採択論文は Artifact の公開の検証を受け（…）、希望すれば動作と再現の検証も受けられた。 査読者と Artifact の評価者のどちらも、実装と論文の記述が食い違う例を見つけており、論文の査読における Artifact の重要な役割を示している。 出典: NDSS 2027 AE サイト [3] ／ USENIX Sec 2026 CfA [4]・委員長のメッセージ [17] ／ ACM CCS 2026 CfA [8] ／ IEEE S&P 2026 CfA [16] © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 8 / 69
9. 1.1 AE とは AE の導入と Artifact 公開の状況 ESEC/FSE 2011 ECOOP SOSP 2013 2019 ほかの分野の会議（ソフトウェア工学・プログラミング言語・OS） Artifact のある論文の割合 赤い点線: AE の導入 AE を始めた年 SEC: USENIX Security 2020 2023 2024 2026 USENIX Sec CCS NDSS S&P 出典: Vansteenhuyse ほか, USENIX Security 2026, Figure 3 Artifact のある論文の割合: 2000年 1.2% → 2025年 72.3% USENIX 2025: 公開の義務化で 80% 超 Functional・Reproduced の取得数への影響は小さい AE の導入の前後の差: 37.8%（p < 0.01） Artifact を公開しても AE に参加しない論文もある 導入前の期間の長さの影響もありうる（論文の注記） 出典: SIGOPS ブログ 2022 [18]・secartifacts.github.io [12]・Vansteenhuyse ほか USENIX Sec 2026 [19] ／ ACM CCS 2026 CfA [8] © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 9 / 69
10. 1.1 AE とは オープンサイエンスの方針 観点 NDSS USENIX CCS S&P Open Science の方針 なし あり あり なし Open Science の付録 なし 必須 必須 全論文 全論文 投稿時の Artifact 記述なし 必須 必須（条件付き） 強く推奨 全論文 実装などに依存する論文 全論文（理論系は証明も） 採択後の AE 任意 Available は必須 open-source と AE を強く推奨 Functional・Reproduced は任意 任意 なし 任意 参加を強く推奨 論文の採否にかかわる決まり 出典: NDSS 2027 CFP [1] ／ USENIX Sec 2026 CFP [20]・CfA [4] ／ ACM CCS 2026 CFP [7]・CfA [8] ／ IEEE S&P 2026 CFP [21]・CfA [16] © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 10 / 69
11. 1.1 AE とは USENIX と CCS の Open Science policy 観点 USENIX CCS 出す時期 投稿のとき 投稿から 3 日以内 出せないとき 付録の理由を査読者が判断 認められなければ不採択 付録に理由を書く 一部・合成・墨塗りの Artifact も推奨 採否との関係 採択は公開の確認が条件 評価できず理由もなければ不採択も AE との関係 採択後の AE で公開を確認 採択後の AE とは別 出典: USENIX Sec 2026 CFP [20] ／ ACM CCS 2026 CFP [7] © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 11 / 69
12. 1. AE のしくみ 1.1 AE とは 1.2 AE の進め方 1.3 Artifact の中身 1.4 扱いに配慮が要る Artifact 1.2 AE の進め方 2. 実践から見た AE 2.1 著者として提出する 2.2 AEC として評価する 3. まとめ © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 12 / 69
13. 1.2 AE の進め方 論文と AE の進め方 AE（必須） AE（任意） 論文に記載（AE と直結） 論文に記載（AE とは別） 投稿・査読 採択 NDSS camera-ready 登録 提出 試運転 評価 判定 Phase-1: 公開の評価（必須） USENIX 論文に記載 提出 （必須） Phase-2: 機能性・再現性の評価（任意） 評価 判定 提出 議論 判定 付録 通らなければ採択取り消し CCS 論文に記載 （条件付き必須） S&P 論文に記載 （強く推奨） 登録 登録 提出 提出 質問応答 試運転 評価 判定 判定 ※ 日程の変更などでcamera-ready の後に判定がされるサイクルも存在（査読結果 Accept, Minor revision, Major Revision によっても変わることあり） 出典: NDSS 2027 CFP [1]・CfA [2] ／ USENIX Sec 2026 CFP [20]・CfA [4]・instructions [22] ／ ACM CCS 2026 CFP [7]・CfA [8] ／ IEEE S&P 2026 CFP [21]・CfA [16]・instructions [14] © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 13 / 69
14. 1.2 AE の進め方 AE のプロセス AE は登録から最終版の提出まで6つのステップで進む（ステップの有無と時期は会議で違う） 登録 提出 試運転 評価 判定 最終版の提出 論文と必要な環境を Artifact と説明の文書 評価者が最小の例で 評価者が実験を動かし AEC がバッジごとに 指摘を反映した版と AEC に伝える 申請するバッジを出す 動くかを確かめる 著者は質問や指摘に 判定してレビューを 付録を最終版で出す （kick-the-tires） 答えて直す 著者に返す NDSS USENIX ※1 （2回）※2 CCS ※3 なし S&P ※1 論文投稿時のフォームで AE の対象外にしなければ登録された扱い（別の登録の締切はない） ※2 Phase-1（採択後・camera-ready の前）で Available・Phase-2（camera-ready の後に同じ投稿を更新）で Functional・Reproduced ※3 AE の日程にはなく評価者ガイドにだけ書かれている 出典: NDSS 2027 CfA [2] ／ USENIX Sec 2026 instructions [22]・評価者ガイド [23] ／ ACM CCS 2026 CfA [8] ／ IEEE S&P 2026 CfA [16]・instructions [14] © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 14 / 69
15. 1.2 AE の進め方 著者と AEC AE は著者と AEC がやりとりしながら進める協調のプロセス（USENIX は「cooperative, not adversarial」と明記） Artifact・説明の文書 著者 質問・指摘 AEC Artifact を提出する 論文と説明を読む 質問にすぐ答える Artifact を動かす Artifact を修正する 回答・修正 質問と指摘を返す バッジを判定する 判定とレビュー 出典: NDSS 2027 CfA [2] ／ USENIX Sec 2026 instructions [22]・評価者ガイド [23] ／ ACM CCS 2026 CfA [8] ／ IEEE S&P 2026 instructions [14] © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 15 / 69
16. 1.2 AE の進め方 論文の査読との違い 論文の査読 AE 評価するもの 研究の新規性・正しさ・重要性 Artifact の公開・機能性・再現性 評価する人 プログラム委員会 AEC（院生・ポスドクが中心） 結果 採択か不採択 バッジ double-blind 匿名性 著者 匿名 Artifact の匿名化 必要 互いに見えない single-blind 査読者 著者 評価者から著者は見える 評価者 匿名 実名 匿名 不要 出典: NDSS 2027 CFP [1]・AEC 募集 [24]・CfA [2] ／ USENIX Sec 2026 CFP [20]・CfA [4]・instructions [22] ／ ACM CCS 2026 CFP [7]・CfA [8] ／ IEEE S&P 2026 CFP [21]・CfA [16]・instructions [14] © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 16 / 69
17. 1.2 AE の進め方 バッジ 著者が3つのバッジから選んで申請したものを AEC がそれぞれの基準で判定する Available Functional Reproduced 第三者がいつでも 入手できることの証明 論文の内容を第三者が 動かせることの証明 主要な結果を第三者が 再現できることの証明 AEC が永続的な公開を確かめる AEC が文書の十分さ・構成要素の有無と 動くかを確かめる AEC が独立に実験して結果を確かめる 会議ごとの補足 NDSS 階層ではなく Available なしでも申請できる CCS Functional の上に Reusable がある USENIX S&P Available の評価は全採択論文に必須 どのバッジでも評価の後の公開を求める 出典: NDSS 2027 Badges [15] ／ USENIX Sec 2026 Badges [25]・instructions [22] ／ ACM CCS 2026 CfA [8] ／ ACM Artifact Review and Badging v1.1 [26] ／ IEEE S&P 2026 CfA [16]・Badges [27] © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 17 / 69
18. 1.2 AE の進め方 AEC との議論 評価中は HotCRP 上の匿名の評価者との議論で指摘や質問に答えながら Artifact を直していく 大きな問題を試運転のうちだけ直せるか議論の間ずっと直せるかなどの範囲が会議ごとに違う 提出 NDSS・S&P 判定 試運転（kick-the-tires） 詳しい評価（in-depth reviewing） 大きな問題（significant blocking issues）に対処 対処できるのは次の2つだけ 結果の解釈（interpretation concerns） 形式上の小さな誤り（minor syntactic issues） 議論（author discussion period） USENIX kick the tires ※ reviewing artifacts ※ 早めに指摘を受けて大きな問題（big issues）を直す 指摘を受けて制限なく（no restrictions）直せる 判定は最後に出した版で決まる CCS 質問応答（answering AEC evaluator questions） やりとりで扱うのは小さな問題（minor issues）と確認の質問 ※ AE 公式の日程には記載なし（AEC 向けの評価者ガイドでは明記） 出典: NDSS 2027 CfA [2] ／ USENIX Sec 2026 instructions [22]・評価者ガイド [23] ／ ACM CCS 2026 CfA [8] ／ IEEE S&P 2026 CfA [16]・instructions [14] © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 18 / 69
19. 1.2 AE の進め方 判定と論文に残るもの Artifact appendix とバッジの載せ方には論文の中にまとめる形と論文とは別の PDF に分ける形がある 会議や申請するバッジによっては Artifact appendix を用意しないこともある 論文の中にまとめる 例: NDSS 論文の表紙 論文の最後 Available Artifact appendix 論文とは別の PDF に分ける 論文の表紙 例: USENIX Artifact appendix の表紙 Available Available Functional Functional Reproduced Reproduced … 1つの論文の PDF Artifact appendix 論文の PDF secartifacts の PDF バッジは論文の表紙に載る 論文の表紙に載るのは Available のバッジだけ Artifact appendix は論文の最後に付く Available だけの申請なら Artifact appendix は不要 Artifact appendix はどの Artifact でも用意する Artifact appendix の表紙に付いたバッジがすべて載る 出典: NDSS 2027 CfA [2] ／ USENIX Sec 2026 instructions [22] ／ secartifacts.github.io [12] © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 19 / 69
20. 1.2 AE の進め方 Distinguished Artifact Award AEC は評価した Artifact の中から特に優れた数件を Distinguished Artifact Award として表彰する NDSS 2026 USENIX Sec 2026 ACM CCS 2026 IEEE S&P 2026 3件 5件 記述なし 4件 評価した 114 件のうち バッジが付いた 351 件のうち 賞があるかは CfA に書かれていない バッジが付いた 56 件のうち CfA と評価者ガイドの選び方の書き方 USENIX 評価したすべての観点で優れたもの “the best artifacts that excel in all the evaluated dimensions”（評価者ガイド） NDSS・S&P 優れたもの “outstanding artifacts”（CfA） これより細かい選び方の基準は CfA・評価者ガイドには書かれていない 出典: NDSS 2027 CfA [2] ／ NDSS 2026 Results [28] ／ USENIX Sec 2026 CfA [4]・評価者ガイド [23]・Results [29]・Awards [30] ／ ACM CCS 2026 CfA [8] ／ IEEE S&P 2026 CfA [16]・Artifact Awards [31]・Results [32] © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 20 / 69
21. 1. AE のしくみ 1.1 AE とは 1.2 AE の進め方 1.3 Artifact の中身 1.4 扱いに配慮が要る Artifact 1.3 Artifact の中身 2. 実践から見た AE 2.1 著者として提出する 2.2 AEC として評価する 3. まとめ © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 21 / 69
22. 1.3 Artifac t の中身 Artifact を構成するもの Artifact は本体（コード・データなど）とそれを説明する文書（形は会議で違う）からなる 説明する文書には入手方法・実行環境・セットアップ・主要な主張と実験などを書く Artifact Artifact を説明する文書 本体 出せる 条件付き テストスイート スクリプト データセット 機械で検証できる証明 Artifact appendix NDSS は必須・CCS は推奨 USENIX は Functional・Reproduced のとき デジタルなものなら基本的に何でもよい ソフトウェア 出せない モデル metadata.tomlS&P（artmeta の質問に答えて作る） アンケートの結果 書く中身 ハードウェア（ネット越しに使える形で） 論文に書いた証明 README 使い方（入手・インストール・実行のしかた） NDSS USENIX CCS で必須 主にどのバッジの評価で見られるか 入手方法 Available Functional Reproduced 実行環境 Available Functional Reproduced セットアップ Available Functional Reproduced 主要な主張と実験 Available Functional Reproduced 出典: NDSS 2027 CfA [2]・テンプレート [33] ／ USENIX Sec 2026 CfA [4]・instructions [22]・テンプレート [34] ／ ACM CCS 2026 CfA [8]・テンプレート [35] ／ IEEE S&P 2026 CfA [16]・instructions [14] ／ artmeta [36] © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 22 / 69
23. 1.3 Artifac t の中身 説明文書①: Artifact appendix NDSS・USENIX・CCS は Artifact を説明する文書として節の並びがある程度決まった Artifact appendix を出す どの会議も配っているテンプレートの節を埋めていけば書ける USENIX・CCS のテンプレート NDSS のテンプレート Artifact Appendix Artifact Appendix Abstract Description & Requirements Artifact の短い説明 Artifact の説明と使うデータなど Description & Requirements 倫理上の注意・使うデータなども書く How to access 入手方法 実行環境 永続的な置き場所と DOI など How to access 入手方法 Hardware・Software dependencies Hardware・Software dependencies 実行環境 Artifact Installation & Configuration 永続的な置き場所と DOI など 必要なハードとソフト Set-up インストールと簡単な動作確認 Evaluation workflow 評価のための操作と実験 セットアップ 主要な主張と実験 必要なハードとソフト インストールと設定 Experiment Workflow 実験の全体の流れ（任意） 論文の主要な主張（C1・C2 …） Evaluation Experiments Customization 主張を確かめる実験（E1・E2 …） Notes on Reusability 論文の外での使い方（任意） 主要な主張と実験 Major Claims Major Claims 論文の主要な主張（C1・C2 …） セットアップ 実験ごとの手順と期待される結果（E1 …） 実験の変え方（任意） Notes そのほかの注意 出典: NDSS 2027 テンプレート [33] ／ USENIX Sec 2026 テンプレート [34] ／ ACM CCS 2026 テンプレート [35] © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 23 / 69
24. 1.3 Artifac t の中身 説明文書②: metadata.toml S&P は Artifact appendix の代わりにスクリプト（artmeta）の質問に答えて metadata.toml を出す 主張ごとに主張の文・それを確かめるスクリプト・期待される結果をくり返し答える $ python3 artmeta.py metadata.toml Please specify which badge you are requesting - [a]vailable, … r badge = "r" artifact_url = "https://example.org/artifact" Please input the URL your artifact, e.g., Github repo … https://example.org/artifact cd = "c" citation = "@inproceedings{example}" Is your artifact [c]ode, [d]ataset or [b]oth? c license_url = "https://example.org/LICENSE" infrastructure_url = "https://example.org/infra" ⋮ Please input the URL your installation script. … https://example.org/install.sh 書き出す infrastructure_allocation = "" install_script = "https://example.org/install.sh" 主張ごとにくり返す Please input the URL the claim-running script or instructions. … https://example.org/run_claim1.sh Describe the expected outcome that would validate the claim. … Expected result 1 セットアップ use = "" destructive = "" claim1 = "Claim one" 主要な主張と実験 script1 = "https://example.org/run_claim1.sh" expected1 = "Expected result 1" Do you have more claims? [y]es or [n]o n hw = "" ⋮ api = "" Please input the URL the README file that contains … https://example.org/README.md 実行環境 infrastructure_resources = "https://example.org/res.md" ⋮ Please input text of claim 1 … Claim one 入手方法 実行環境 sw = "" gui = "n" readme = "https://example.org/README.md" 出典: IEEE S&P 2026 instructions [14] ／ artmeta [36] © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 24 / 69
25. 1.3 Artifac t の中身 入手方法 Artifact の最終版をアーカイブに置いて DOI などの永続的識別子を取得し、Artifact appendix などに書いて提出 1 置く 永続的に残すと宣言しているリポジトリに置く Zenodo FigShare Dryad Software Heritage 機関のリポジトリ USENIX・CCS・S&P は Zenodo を推奨 中身を書き換えたり消したりできる場所は最終版の置き場所にならない GitHub GitLab 個人の Web ページ 最初の提出には使ってよい（NDSS・S&P・USENIX の Phase-2） 2 アーカイブに公開すると永続的識別子が発行される 識別子を取得 NDSS・CCS・S&P は DOI を求める 3 Artifact appendix などに書く 書く USENIX は DOI でなくても長く変わらない参照ならよい Artifact appendix のテンプレートでは How to access の節 USENIX は論文の最終版にも永続的なリンクを書く S&P の CfA・secartifacts には DOI を書く場所の記述がない DOI 10.5281/zenodo.XXXXXXX SWHID swh:1:dir:XXXXXXXX… Zenodo など Software Heritage Artifact appendix How to access https://doi.org/10.5281/zenodo.XXXXXXX https://github.com/… 並べて書くことは可（NDSS・CCS） 出典: NDSS 2027 Badges [15]・テンプレート [33] ／ USENIX Sec 2026 Badges [25]・instructions [22]・テンプレート [34] ／ ACM CCS 2026 CfA [8]・テンプレート [35] ／ IEEE S&P 2026 CfA [16] ／ SWHID [37] © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 25 / 69
26. 1.3 Artifac t の中身 Version DOI と Concept DOI Zenodo・FigShare では特定の版を指す Version DOI とすべての版をまとめる Concept DOI が付く Zenodo の FAQ の例（あるソフトウェアの2つの版） Concept DOI 10.5281/zenodo.705645 最新の版のページに飛ぶ v1.0 Version DOI v1.1 10.5281/zenodo.60943 Version DOI 10.5281/zenodo.800648 USENIX は申請するバッジによって書く DOI を使い分けるよう勧めている Available だけの評価に出す → Version DOI 論文で示した版に他の研究者がアクセスできる Functional・Reproduced の評価に出す → Concept DOI 評価中に Artifact が変わってもリンクを直さずに済む 最終版にどちらを書くかは CfA・secartifacts に書かれていない（勧めは評価に出すときのもの） 公開された最終版の Artifact appendix では Concept DOI が多い（Functional・Reproduced の 120 件のうち 93 件） 出典: Zenodo FAQ [38] ／ USENIX Sec 2026 instructions [22]・テンプレート [34]・Results [29] © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 26 / 69
27. 1.3 Artifac t の中身 実行環境 Artifact を動かすのに必要なハードウェアとソフトウェアを実行環境として書く まずは会議ごとに想定された評価者の環境で動くように作る NDSS 時間の上限: 1日 USENIX 評価者の一般的なデスクトップで動く 評価者の計算機で動く x86-64・8コア・16GB・最近の Linux か Windows Docker や VM を使ってもよい（評価者ガイド） 代わりの方法 代わりの方法 著者の環境や借りた環境に匿名でアクセスしてもらう（SSH など） 著者の計算機に SSH などでアクセスしてもらう 特別なハードウェアは提出の前に AE chairs に相談 著者が用意した学術クラウド（CloudLab・Chameleon） 時間の上限: 記述なし 商用クラウドは本当に要るときだけ（費用は著者） CCS 時間の上限: 記述なし S&P SPHERE で評価する見込み 公開の研究基盤で動く 使えるかを考えておくよう推奨（必須ではない） SPHERE・Chameleon・CloudLab などから著者が選ぶ 代わりの方法 代わりの方法 特別なハードウェアは VPN・SSH でアクセスしてもらう 特別なハードウェアや場所が要るときは制約を説明する 画面の録画（screencast）で見せる その機器への匿名のアクセスを用意する（SSH など） 時間の上限: 1日 出典: NDSS 2027 CfA [2] ／ USENIX Sec 2026 評価者ガイド [23] ／ ACM CCS 2026 CfA [8] ／ IEEE S&P 2026 instructions [14] © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 27 / 69
28. 1.3 Artifac t の中身 セットアップ 依存の多さや必要なハードウェアに合わせた形で本体を他の環境でも動かせるようにする（＝パッケージ） パッケージの形 依存が少ない 依存が多い 作るときの決まり ソースコードとビルドスクリプト コンテナ・VM コンテナ・VM は環境ごと入れる 実行環境とそれを作り直すスクリプトを添える NDSS USENIX CCS S&P できるだけスクリプトにする Web のサービス Web 上で動き続けるインスタンス インストールと実行の手作業を減らす USENIX 特別なハードウェア S&P ネット越しに使える機器 パス・アドレス・識別子を固定しない CCS は他に研究基盤の実験環境・バイナリのインストーラ・画面の録画も挙げる S&P はソースコードを基本として他の形は難しいときだけ認める 著者以外の環境でもそのまま動くようにする NDSS USENIX S&P 出典: NDSS 2027 CfA [2]・Badges [15] ／ USENIX Sec 2026 instructions [22]・Tips [39] ／ ACM CCS 2026 CfA [8] ／ IEEE S&P 2026 instructions [14] © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 28 / 69
29. 1.3 Artifac t の中身 主要な主張と実験 論文の主要な主張ごとにそれを確かめる実験を Artifact に用意して手順と期待される結果を書く 主張ごとの実験 論文の主張 設計のポイント 結果は許される誤差の範囲でよい 実験 主張を確かめられれば完全に同じでなくてよい 主張 C1 実験 E1 スクリプトなど NDSS 手順 所要時間 期待される結果 USENIX CCS S&P 長い実験は1日に収まるよう縮める 縮めても主張を確かめられる根拠を示す 主張 C2 実験 E2 スクリプトなど NDSS 手順 所要時間 期待される結果 S&P 確かめにくいことは先に伝える 使うときの難しさや論文との違いを書く 実験 E3 スクリプトなど NDSS 手順 所要時間 期待される結果 CCS S&P 正しい出力だけでは足りない スクリプトが主張どおりに動くことを示す Artifact に入れる Artifact appendix などに書く USENIX 出典: NDSS 2027 CfA [2]・Badges [15]・テンプレート [33] ／ USENIX Sec 2026 CfA [4]・Badges [25]・テンプレート [34]・Tips [39]・評価者ガイド [23] ／ ACM CCS 2026 CfA [8] ／ IEEE S&P 2026 CfA [16]・Badges [27] © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 29 / 69
30. 1. AE のしくみ 1.1 AE とは 1.2 AE の進め方 1.3 Artifact の中身 1.4 扱いに配慮が要る Artifact 1.4 扱いに配慮が要る Artifact 2. 実践から見た AE 2.1 著者として提出する 2.2 AEC として評価する 3. まとめ © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 30 / 69
31. 1.4 扱いに配慮が要る Artifa ct 公開に気をつけるべき Artifact 公開に気をつけるべき Artifact は理由によって法的・倫理的・実務的の3つに分けられる 法的 legally 倫理的 ethically 権利で縛られたもの 脆弱性・攻撃の手法 ライセンスで制限されたもの “licensing restrictions” 実務的 practically ゼロデイの exploit USENIX CCS 秘密保持契約（NDA）の対象 “NDA” “zero-day exploits” 巨大なデータセット USENIX 修正まで公開を控える exploit USENIX 独自のデータセット “proprietary datasets” 評価者が動かしにくいもの USENIX “exploits under embargo” CCS 24 時間を超えるような大きな計算 S&P “more than 24 hours of execution time” 早すぎる公開が危ない攻撃の手法 特別なハードウェア “adversarial methods are released prematurely” CCS “specialized computer hardware” NDSS 配れない商用のソフトウェア “proprietary/commercial software” “huge data sets” CCS S&P 特別な機器や設置場所が要るもの “special hardware or special geolocation” S&P CCS 一般の研究室にない機器やソフト 人を対象にした研究 “not generally available in a typical lab” インタビューの書き起こし “interview transcripts” CCS USENIX 参加者の安全やプライバシーに関わるもの “safety or privacy of study subjects” CCS 個人を特定できる情報（PII） “personal identifiable information” S&P 出典: NDSS 2027 CfA [2] ／ USENIX Sec 2026 CfA [4] ／ ACM CCS 2026 CFP [7]・CfA [8] ／ IEEE S&P 2026 CFP [21]・CfA [16]・instructions [14] © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 31 / 69
32. 1.4 扱いに配慮が要る Artifa ct 公開できないときの出し方 公開できない部分は次の3つのどれかで扱う（迷ったら AE chairs に相談） 1 分けて残りを公開する USENIX 2 制限付きで置く USENIX CCS 3 公開を遅らせる S&P ソースコードなど出せる部分は公開し アーカイブに置いたまま見られる人を 修正まで公開を控える exploit などを 出せない部分だけを別にする 評価者などに絞る 評価の後に公開する 公開しないときの影響 どの会議でも 会議によっては採否やバッジに響く Available 付かない Functional 受けられる Reproduced 受けられる S&P は評価の後に主な部分を公開するのが前提 USENIX 理由が認められなければ論文が不採択 機微でない部分まで制限すると採択の取り消し S&P ずっと公開しないなら評価しない 公開版が大きく減るとバッジを付けないことも 出典: NDSS 2027 CfA [2]・Badges [15] ／ USENIX Sec 2026 CfA [4] ／ ACM CCS 2026 CfA [8] ／ IEEE S&P 2026 CfA [16]・instructions [14] © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 32 / 69
33. 1.4 扱いに配慮が要る Artifa ct 危険が伴う Artifact 評価者の計算機を壊したり安全性を下げたりしうる操作は事前に伝える 1 提出のときに申告（README に明記・提出フォームでチェック・AE chairs へ連絡など） 2 起こることと評価者への依頼事項を Artifact appendix に書く 実例: 公開されている Artifact appendix で実際に書かれていたこと システムが不安定になる 問題 ページキャッシュを追い出す実験で 値を強くしすぎると システムが不安定になり再起動が要る 対策 先にアプリを閉じてデータを保存し スワップを無効にしておく 悪意のあるコードを動かす 問題 実際に出回っている 悪意のあるエージェントスキルを Docker の中で動かす 対策 使い捨ての計算機か VM で動かし ログインも使い捨てのものを使う 脆弱なサービスを動かす 問題 わざと脆弱にした Web アプリを コンテナで立ち上げる 対策 外から届くポートに公開しない （既定では localhost だけ） 出典: NDSS 2027 CfA [2] ／ NDSS 2026 Eviction Notice [40] ／ USENIX Sec 2026 instructions [22]・Artifact appendix [41][42] ／ ACM CCS 2026 CfA [8] © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 33 / 69
34. 1. AE のしくみ 1.1 AE とは 1.2 AE の進め方 1.3 Artifact の中身 1.4 扱いに配慮が要る Artifact 2.1 著者として提出する 2. 実践から見た AE 2.1 著者として提出する 2.2 AEC として評価する 3. まとめ © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 34 / 69
35. 2.1 著者として提出する 論文の概要 NDSS’26 “Action Required: A Mixed-Methods Study of Security Practices in GitHub Actions” GitHub Actions の5つの公式のセキュリティ対策の実態を Measurement Study と User Study を組み合わせて調査 Measurement Study RQ1・RQ2 User Study RQ3 データセット構築 実践の自動判定 統計分析 参加者の募集 オンライン調査 回答の分析 公開リポジトリ 338,812 件 対象か・実践しているか 実践率・回帰分析 開発者 102 人が回答 質問票 集計・自由記述 RQ1 どれだけ実践されているのか RQ2 52.9% 最近も活動している 16.2% 7.1% P1 組織が持っている P3 なぜ実践されないのか 対策を知らない 実践率が高い 71.6% 実践しない人の最大 ほかの壁 スターの数・規模 P4 RQ3 実践率が高い 10.7% 0.6% P2 どんなリポジトリが実践しているか 高いとは限らない 誤解 運用の手間 P5 出典: Kubo ほか NDSS 2026 [43] © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 35 / 69
36. 2.1 著者として提出する AE への参加 NDSS’26 の AE に参加し、3つのバッジを申請・取得 バッジ 申請 取得 Available Functional Reproduced 公開場所 DOI 10.5281/zenodo.17916232 github.com/yksec14/gha_security_research 出典: Kubo ほか NDSS 2026 [43]・公開した Artifact（GitHub） [44]・公開した Artifact（Zenodo） [45] © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 36 / 69
37. 2.1 著者として提出する Artifact を出すプロセス 対象範囲を決める 主張と実験を決める 実験を再設計する 提出する 評価を受ける 研究のうちどこを出すか 主張とそれを確かめる 実験とコードを作り直し Artifact appendix を作成し AEC の指摘に対応し 出せるかを判断 実験を組み立てる 評価の条件で動かす 公開先とあわせて提出 バッジの判定を受ける バッジの判断 全バッジを狙うと決める 全バッジを出せるか判断 出典: Kubo ほか NDSS 2026 [43] © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 37 / 69
38. 2.1 著者として提出する Artifact の候補 Measurement Study データセット構築 SEART-GHS から抽出 実践の自動判定 対象か・実践しているか User Study データセットを構築するスクリプト 実践／非実践の判定フレームワーク 参加者の募集 開発者にメールで依頼 オンライン調査 Qualtrics で実施 募集メール 質問紙 統計分析 実践率を算出するスクリプト 回答の分析 アンケート結果（匿名） 実践率・回帰分析 回帰分析のスクリプト 集計・自由記述 回答を分析するスクリプト 出典: Kubo ほか NDSS 2026 [43] © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 38 / 69
39. 2.1 著者として提出する AE の対象範囲 Measurement Study データセット構築 SEART-GHS から抽出 実践の自動判定 対象か・実践しているか AE の対象 データセットを構築するスクリプト 実践／非実践の判定フレームワーク User Study 参加者の募集 開発者にメールで依頼 オンライン調査 Qualtrics で実施 対象外 募集メール 質問紙 統計分析 実践率を算出するスクリプト 回答の分析 アンケート結果（匿名） 実践率・回帰分析 回帰分析のスクリプト 集計・自由記述 回答を分析するスクリプト 出典: Kubo ほか NDSS 2026 [43] © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 39 / 69
40. 2.1 著者として提出する 対象範囲外とした理由 回帰分析（RQ2） User Study CfA の要件 CfA の要件 変数の一部を API で取得すると全体を 1 日で実行できないため 質問紙や募集メールは AE の対象外と解釈したため 縮めた規模では回帰分析で再現性のある結果が得られないため 補足 AEC としてテキストの提出例を見ているのでおそらく問題なし 質問紙・募集メールは評価の対象外だが Artifact とあわせて公開 To ensure that the evaluation is practical for the AEC, the proposed experiments should take at most 1 day and run on a commodity desktop machine. 実験は評価が現実的になるよう 1 日以内で 一般的なデスクトップで動くこと When the paper’s research involves longer durations, the authors should design scaled-down experiments and properly justify how those can still significantly support the paper’s analyses. Artifacts can be, e.g., software, datasets, models, test suites, or mechanized proofs. Paper proofs are not accepted, as evaluators lack the time and often the expertise to carefully review them. 例: ソフトウェア・データセット・モデル・テストスイート 紙の上の証明は精査する時間と専門性がないため受け付けない Authors should consider one of the following methods to package the software components of their artifacts. 時間のかかる研究では実験を縮めて設計し 縮めても論文の分析を十分に支えられる理由を示す ソフトウェアの部分は次のいずれかの方法でパッケージ化する この研究の事情 この研究の事情 コードの整理に時間が要るため 参加者と回答を外に出さない約束をしたため 回帰分析の入力は多段階の処理で作るので実行するスクリプトも多い インフォームド・コンセントで研究に限った利用と厳重な管理を説明 出典: NDSS 2026 CfA [46] ／ Kubo ほか NDSS 2026 [43]・公開した Artifact（GitHub） [44] © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 40 / 69
41. 2.1 著者として提出する 主張と実験の設計 AE の対象範囲に基づいて論文の主張とそれを確かめる実験を3つの手順ごとに設計 AE の対象 主張 C1 実験 GitHub Actions を使うリポジトリのデータセットを SEART-GHS から構築できる データセット構築 C2 E1 データセットの作成 内容 SEART-GHS の一覧から GitHub Actions を使う リポジトリを GitHub API で選んで手元にクローン E2 5つの対策の分析 内容 設定ファイルとワークフローから5つの対策の 対象か・実践しているかを判定して実践率を算出 5つの対策について対象か・実践しているかを 公開データから判定できる 実践の自動判定 C3 公開リポジトリでは5つの対策の実践率が低い 統計分析 出典: Kubo ほか NDSS 2026 [43] © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 41 / 69
42. 2.1 著者として提出する 実験の再設計①: 規模の縮小 研究の規模では AE の要件を満たさないため調査対象のリポジトリ数を変更して規模を縮小 研究の規模 調査対象のリポジトリ 1,675,884 件 GitHub Actions を使うリポジトリ 338,812 件 保存領域 AE の規模 パラメータ 調査対象のリポジトリ数 600 件 2024 年に作られたものを各月 50 件 8 コア・16 GB の x86-64 時間 クローンだけで 2 日 上限 15,000 回／時 1 日以内・一般的なデスクトップ 30 GB 時間 Enterprise プラン AE の要件 保存領域 約 30 TB GitHub API 必要なリソース 目安 GitHub Actions を使うリポジトリ E1 50 分・E2 15 分 GitHub API 約 200 件 一般ユーザーのプラン 実行例では 192 件 AE の要件に収まる AE の要件を満たさない 上限 5,000 回／時 出典: NDSS 2026 CfA [46] ／ Kubo ほか NDSS 2026 [43]・公開した Artifact（GitHub） [44] © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 42 / 69
43. 2.1 著者として提出する 実験の再設計②: リファクタリング 自分の実験用に書いたスクリプトを評価者が動かせる形に整理 実行の仕方 コードの中身 手順をシェルスクリプトにまとめる コードを読みやすく整える 複数の Python スクリプトを決まった順に動かす手間をなくす 自分の実験用に書いたままのコードを第三者が読みやすい形に 縮小版とフル版を選べるようにする AE の対象に必要なコードに絞る AE 向けの縮小版に加えて Artifact を使う人はフル版も実行可能 ほかの実験と共有していたモジュールなど不要な部分を除く GitHub API の認証方式を選べるようにする 日本語のコメントを除く GitHub App に加えて Personal Access Token にも対応 匿名にするため 補足 NDSS の AE は single-blind なので実際には不要 出典: Kubo ほか NDSS 2026 [43]・公開した Artifact（GitHub） [44] © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 43 / 69
44. 2.1 著者として提出する 提出前の確認 1 自分でまっさらな環境で手順どおりに動かす 2 共著者に手順を試してもらう まっさらな環境 手順 1 手順 2 文書を読んで実施 Artifact 手順 3 動く 手順 1 手順 2 手順 3 動く フィードバック 自分 ねらい 何回か繰り返す 自分の環境にだけある設定や依存に頼っていないか 自分 ねらい 共著者 書いた本人には見えない説明の抜けや分かりにくさ NDSS USENIX To ensure that your instructions are complete, we strongly recommend that you run through them on a fresh setup prior to submission, following exactly the instructions you have provided. Try out your own artifact on a blank environment, following the steps you documented. 手順に抜けがないよう、提出の前にまっさらな環境で 書いた手順どおりに一通り動かすことを強く勧める 書いた手順どおりに自分の Artifact を空の環境で試す Unfortunately, artifacts sometimes miss badges because they were not tested on a clean setup, or not documented enough, … 試していない・説明が足りないためにバッジを逃すことがある 出典: NDSS 2027 CfA [2] ／ USENIX Sec 2026 Tips [39] © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 44 / 69
45. 2.1 著者として提出する AE に提出するもの テンプレートで作った Artifact appendix と README・LICENSE を含めたリポジトリを HotCRP で提出 1 リポジトリ Artifact 本体 README HotCRP 例: Python・Shell のスクリプトと例のデータ すべての提出で必須 LICENSE 使い方の網羅的な説明と論文の参照 利用条件を示す 例: 概要・環境・セットアップ・使い方 例: MIT License Available で必須 研究の概要と Artifact の役割（Abstract） 査読時の論文 ハードウェアとソフトウェアの要件 2 A B C D Artifact appendix NDSS の LaTeX テンプレートで 2 ページまで Description & Requirements 入手方法と実行環境 Artifact Installation & Configuration セットアップ Experiment Workflow 実験の流れ Major Claims E F G Evaluation 実験ごとの手順と結果 Customization 規模などの変え方 Notes 補足 Artifact へのリンク 1 Artifact appendix 2 申請するバッジ 主要な主張 出典: NDSS 2026 CfA [46]・Badges [47]・テンプレート [48] ／ Kubo ほか NDSS 2026 [43]・公開した Artifact（GitHub） [44] © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 45 / 69
46. 2.1 著者として提出する Artifact の置き場所 AE の提出では匿名化したリンクを渡して AE の後は Zenodo で DOI を付けて公開 AE の提出 補足 Anonymous GitHub AEC に渡す 匿名化したリポジトリのリンクを作成 HotCRP で Artifact へのリンクとして登録 NDSS の AE は single-blind なので匿名化は実際には不要 USENIX Security ’27 は論文の投稿時に匿名リンクが必須（CFP がこのサービスを推奨） GitHub AE の後（最終版の公開） コードを管理 Zenodo 誰でも入手できる形で公開 GitHub で Release を作ると自動で保存 DOI 10.5281/zenodo.17916232 最終版の Artifact appendix に DOI を記載（Available の条件） 出典: NDSS 2026 CfA [46]・Badges [47] ／ USENIX Sec 2027 CFP [6] ／ Anonymous GitHub [49]・公開した Artifact（Zenodo） [45] © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 46 / 69
47. 2.1 著者として提出する Anonymous GitHub と Zenodo の使い方 Anonymous GitHub Zenodo 投稿・提出のときに匿名のリンクを作る 最終版を保存して DOI を付ける 1 anonymous.4open.science に GitHub でサインイン 1 Zenodo に「Log in with GitHub」でログイン 2 リポジトリを選び伏せる語を入れる 2 GitHub の設定でリポジトリを On にする 3 できた匿名のリンクを論文や提出に書く 3 GitHub で Release を作ると DOI が付く 補足 補足 連携は選んだリポジトリの読み取りだけ（書き込みはしない） Release を作るたびに新しい DOI が付く 所有者・リポジトリ名・中身・ファイル名の語を伏せる 非公開のリポジトリは使えない 伏せる語はあとから更新できる 版ごとの Version DOI と全版をまとめる Concept DOI が付く 元のリポジトリが public ならそのまま GitHub や検索で見える 出典: Anonymous GitHub の README・FAQ [50]・GitHub Docs [51]・Zenodo Help [52]・Zenodo FAQ [38]（画像は Anonymous GitHub の README〔GPL-3.0〕と Zenodo Help〔CC BY 4.0〕から） © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 47 / 69
48. 2.1 著者として提出する AEC の評価 3人のレビュアー全員が3つのバッジすべてに Yes Reproduced Artifact の評価 Available Functional レビュアー A Yes Yes Yes Good レビュアー B Yes Yes Yes Good レビュアー C Yes Yes Yes Good レビューのコメント レビュアー A・B 実践率が論文の値と一致しない 私 サンプリングによる差と回答 サンプリングによる差かを確認 補足 © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 縮小版（約 200 件）は論文の 338,812 件と対象が違うため値はずれる 48 / 69
49. 2.1 著者として提出する Camera-ready への反映 バッジの判定の後 Camera-ready の論文にバッジと Artifact appendix を追加 1 2 3 1 1ページ目にバッジ ndssbadges.sty で追加 2 Artifact appendix 論文の最後に付録として 3 GitHub と DOI を併記 入手方法（How to access） 出典: NDSS 2026 CfA [46]・Badges [47] ／ Kubo ほか NDSS 2026 [43] © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 49 / 69
50. 2.1 著者として提出する 今回の課題と次への改善 要件の読み方 課題 single-blind なのに匿名化 コードの書き方 課題 LICENSE の入れ忘れを指摘される 改善 実験用に書いたコードを Artifact の決め方 課題 公開と AE のために修正 改善 AE の要件に照らして 何を公開できるかから決定 改善 要件とやり方を整理する 公開を前提に作る 何を公開すべきかから考える ＝ この講演 実装し直す手間を省くため 研究として価値があるものを出すため 評価の方式 他の人が動かすことを前提に作る 再現できると価値がある主張はどれか バッジごとに必要なこと 規模や実行環境が変わることを想定して作る どこまでを Artifact とするか AE 特有の要件 簡単 © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. AE の要件とどう折り合いをつけるか 難しい 50 / 69
51. 1. AE のしくみ 1.1 AE とは 1.2 AE の進め方 1.3 Artifact の中身 1.4 扱いに配慮が要る Artifact 2.2 AEC として評価する 2. 実践から見た AE 2.1 著者として提出する 2.2 AEC として評価する 3. まとめ © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 51 / 69
52. 2.2 AEC として評価する AEC の仕事 誰がどれだけ 評価の流れ メンバー NDSS 2027 は 217 人 1 フォームで自薦して参加（主に大学院生とポスドクを想定） Kick-the-tires Artifact へのアクセスと最小の例が動くかを確認 大学 188・企業 14・研究機関 13・個人 2（最初の所属で分類） 2 In-depth review 実験を動かして必要なら匿名で著者とやりとり 担当（想定） Summer Cycle 2 件・Fall Cycle 3 件 両方のサイクルを担当 3 議論と判定 レビューを書いて AEC の議論でバッジを判定 時間（想定） 1 件あたり 10〜15 時間 single-blind のため HotCRP で著者名が見える 出典: NDSS 2027 AEC 募集 [24]・CfA [2]・Organizers [53] © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 52 / 69
53. 2.2 AEC として評価する AEC に参加するメリット メリット 採択直後の論文と Artifact に触れられる 論文だけでなく Artifact の中身まで調べられる セキュリティ研究の再現性に貢献できる レビューとフィードバックで Artifact をよくする AEC や著者と議論できる ほかの AEC メンバーと議論して匿名で著者ともやりとり AE の進め方を内側から学べる メンタリングと指導を受けながら 表彰を受ける機会がある 対応する募集の文（NDSS 2027 Call for AEC Members） … get to familiarize yourself with research papers just accepted for publication at NDSS 2027 and explore their artifacts. … help promote the reproducibility of experimental results in security research … … provide a review for the artifact to give constructive feedback … … discuss with other AEC members and anonymously interact with the authors as necessary … … gain insights into a modern AE process, get mentoring and guidance during the process … … get a chance to receive a Distinguished Artifact Reviewer Award … Distinguished Artifact Reviewer Award 出典: NDSS 2027 AEC 募集 [24] © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 53 / 69
54. 2.2 AEC として評価する 評価して分かった AE の実際 1 要件の運用は意外と柔軟 CfA の前提から想像するより受理される幅は広い 評価で見た場面 GPU が前提の Artifact も受理されていた Reproduced の判断は難しい 2 基準が明確に定義されずレビュアーで見る深さも違う 評価で見た場面 データが同封された Artifact CfA の前提は一般的なデスクトップ（x86-64 CPU） 著者が AE の要件に照らしデータの作成工程を除外 GPU などを持つレビュアーに割り当てられているとみられる その判断が妥当かを論文の主張・貢献と照らして検討 一方で環境やライセンスがなく評価できないレビュアーもいる データセット自体に価値があり手法もデータが前提に見える 受理の幅は広いのでまずは出してみればよい 補足 NDSS の secartifacts には評価者ガイドが載っていない 出典: NDSS 2027 CfA [2]・Badges [15] ／ USENIX Sec 2026 評価者ガイド [23] © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 54 / 69
55. 1. AE のしくみ 1.1 AE とは 1.2 AE の進め方 1.3 Artifact の中身 1.4 扱いに配慮が要る Artifact 3. まとめ 2. 実践から見た AE 2.1 著者として提出する 2.2 AEC として評価する 3. まとめ © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 55 / 69
56. 3. まとめ AE の要点 1.1 AE とは 1.2 AE の進め方 採択論文の Artifact を AEC が評価してバッジで示す 流れは共通でステップの有無と時期が会議ごとに違う バッジは Available・Functional・Reproduced の3つ 登録 → 提出 → 試運転 → 評価 → 判定 → 最終版の提出 目的は再現性・Artifact の公開・著者の努力への評価 評価中は AEC と匿名でやりとりしながら直す 1.3 Artifact の中身 1.4 扱いに配慮が要る Artifact 本体とそれを説明する文書を出す 公開できない部分や危険な操作は事前に伝える 入手方法・実行環境・セットアップ・主要な主張と実験を書く 公開できない部分は分ける・制限付きで置く・遅らせる 最終版はアーカイブに置き DOI などを書く 危険な操作は提出のときに申告し Artifact appendix に書く 細かな決まりは会議・年ごとに違う 準備するときは その年の CfA と secartifacts を読み込む（迷ったら AE chairs に相談） © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 56 / 69
57. 3. まとめ Artifact と AE への私の考え 良いと思うところ Artifact の公開は論文の公開と同じくらい価値がある 課題だと思うところ 任意では広がらないが必須にするのも悩ましい 論文だけでは実装の細部が分からず再現や比較が難しい 作業が増えるのに得るものはバッジだけ Artifact があればほかの研究者が試して積み上げられる 必須だと公開の負担をすべての著者に課すことになる 動かない Artifact や論文と違う Artifact が減る Reproduced の基準をどこまで求めるか 読むだけでは分からない実装の不備を動かして見つけられる 用意されたデータで結果が出る ≠ 独立にやり直しても出る 実装に不備がある Artifact に遭遇する機会が減る Reproduced には後者まで求めたい 若手研究者もレビュアーの経験を積める 評価する環境を用意するのが難しい研究をどう扱うか 自薦で参加できるので論文の査読より入りやすい GPU・ライセンス・実機が要ると環境を用意できない 評価する側から AE の進め方を学べる 対象は物理的なものにも及び環境を決めると出しにくい © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 57 / 69
58. 3. まとめ 今後の AE の予想①: 必須化の広がり Artifact の公開を必須にする会議が増える なぜそう思うか 1 オープンサイエンスへの流れがある Artifact のある論文の割合 2000 年 1.2% → 2025 年 72.3% USENIX で Artifact を公開した採択論文の割合 ’24 142 / 417 本 USENIX・CCS は投稿論文に Open Science の付録を求める 2 AE の歴史が最も長い USENIX から必須化 AE の開始 USENIX 2020・CCS 2023・NDSS 2024・S&P 2026 34% ’25 96% 389 / 407 本（Available を必須に） ただし 影響 Functional・Reproduced の取得への影響は小さい 研究者は公開を前提に研究を進める必要がある 出典: USENIX Sec 2024 委員長のメッセージ [54] ／ USENIX Sec 2025 委員長のメッセージ [55] ／ USENIX Sec 2026 CFP [20] ／ Vansteenhuyse ほか USENIX Sec 2026 [19]・secartifacts.github.io [12] ／ ACM CCS 2026 CFP [7]・CfA [8] © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 58 / 69
59. 3. まとめ 今後の AE の予想②: エージェント時代の Artifact の価値 コーディングエージェントで変わること 公開しやすくなる 評価しやすくなる 再現・再利用しやすくなる README や実装の整理を手伝う 環境の準備や判定を補助する 動かして使うのを手伝う 論文から手法を再現する © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 59 / 69
60. 3. まとめ 今後の AE の予想②: エージェント時代の Artifact の価値 コーディングエージェントで変わること 公開しやすくなる 評価しやすくなる 再現・再利用しやすくなる README や実装の整理を手伝う 環境の準備や判定を補助する 動かして使うのを手伝う 論文から手法を再現する Q 論文から再現できるなら 著者の Artifact は不要になるのか Q 論文だけで再現できるのか 不要にはならない できないことが多い 著者が公開した Artifact にしかない価値がある できたとしても間違っていることが多い 論文に書き切れない実装の細部まで入っている 書かれていない部分は推測で埋めるしかない 論文の結果を実際に出した実装そのものである 結果や主張が成り立つ都合の良い実装に寄せうる © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 60 / 69
61. 3. まとめ エージェントによる再現と評価の研究 PaperBench（Starace ほか） ICML 2025 OpenAI CORE-Bench（Siegel ほか） TMLR 2024 Princeton 大学 ICML 2024 の論文 20 本をエージェントにゼロから再現させる CS・社会科学・医学の論文 90 本の公開されたコードとデータで 論文の理解・実装・実験の実行までを著者と作った基準で採点 論文の結果を再現させる（270 タスク・3段階の難しさ） 結果 Claude 3.5 Sonnet で再現の点数は平均 21.0%（最良） ML の博士 8 人の再現は論文 3 本で 41.4%（o1 は 26.6%） LLM による AE の支援（Heye ほか） IEEE BigData 2025 RWTH Aachen 大学 結果 README だけを与える最も難しい条件で再現は 21% Dockerfile も与えると 58%・実行結果まで与えると 60% ArtifactCopilot（Wu ほか） arXiv 2026 華中科技大学・清華大学 セキュリティの論文と Artifact を LLM に渡し ACM のバッジ方針をもとにした採点基準に沿って 再現性の評価・環境の準備・実験設計の誤りの検出を自動化 エージェントが Artifact を調べバッジを判定する 結果 再現性の評価の正解率 72% 超・設計誤りの検出 F1 92% 超 動かせる Artifact の 28% で環境を自動で準備 結果 ソフトウェア工学の会議の Artifact 60 件で 人の判定とのバッジの一致 70.56% 出典: Starace ほか（OpenAI）ICML 2025 [56]・Siegel ほか TMLR 2024 [57]・Heye ほか IEEE BigData 2025 [58]・Wu ほか 2026（arXiv） [59] © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 61 / 69
62. 3. まとめ 最後に伝えたいこと 1 Artifact を出してみよう 要件を CfA と secartifacts で確かめて公開を前提に作る 2 AEC に手を挙げてみよう 自薦で参加できるので若手研究者もレビュアーの経験を積める 3 世界の流れに対して国内ではどうしていくかを考えたい トップ会議で Artifact の公開と評価が広がる中で国内の研究コミュニティとしてどう向き合うか © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 62 / 69
63. 参考文献 参考文献（1/3） [1] NDSS Symposium 2027 Call for Papers https://www.ndss-symposium.org/ndss2027/submissions/call-for-papers/ [2] NDSS 2027 Call for Artifacts https://secartifacts.github.io/ndss2027/call [3] NDSS 2027 Artifact Evaluation https://secartifacts.github.io/ndss2027/ [4] USENIX Security ’26 Call for Artifacts https://www.usenix.org/conference/usenixsecurity26/call-for-artifacts [5] USENIX Security 2026 Artifact Evaluation https://secartifacts.github.io/usenixsec2026/ [6] USENIX Security ’27 Call for Papers https://www.usenix.org/conference/usenixsecurity27/call-for-papers [7] ACM CCS 2026 Call for Papers https://www.sigsac.org/ccs/CCS2026/call-for/call-for-papers.html [8] ACM CCS 2026 Call for Artifacts https://www.sigsac.org/ccs/CCS2026/call-for/call-for-artifacts.html [9] IEEE S&P 2026 Artifact Evaluation https://secartifacts.github.io/sp2026/ [10] IEEE S&P 2027 Call for Papers https://sp2027.ieee-security.org/cfpapers.html [11] IEEE S&P 2027 Call for Artifacts https://sp2027.ieee-security.org/cfartifacts.html [12] Security Research Artifacts https://secartifacts.github.io/ © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. [13] secartifacts/secartifacts.github.io（GitHub リポジトリ） https://github.com/secartifacts/secartifacts.github.io [14] IEEE S&P 2026 Artifact Packaging and Submission Instructions https://sp2026.ieee-security.org/artifact_instructions.html [15] NDSS 2027 Artifact Evaluation Badges https://secartifacts.github.io/ndss2027/badges [16] IEEE S&P 2026 Call for Artifacts https://sp2026.ieee-security.org/cfartifacts.html [17] USENIX Security ’26 Message from the Program Co-Chairs https://www.usenix.org/sites/default/files/sec26_message.pdf [18] S. Pirelli. Artifact evaluation, present and future. ACM SIGOPS Blog, 2022 https://www.sigops.org/2022/artifact-evaluation-present-and-future/ [19] D. Vansteenhuyse, A. Bols, L. Desmet, V. Le Pochat, J. Van Bulck, M. Bognar. Not All Those Who Share Are Lost: Analyzing 25 Years of Cybersecurity Artifact Sharing Practices Through Automated Discovery. USENIX Security 2026 https://www.usenix.org/conference/usenixsecurity26/presentation/vansteenhuyse [20] USENIX Security ’26 Call for Papers https://www.usenix.org/conference/usenixsecurity26/call-for-papers [21] IEEE S&P 2026 Call for Papers https://sp2026.ieee-security.org/cfpapers.html [22] USENIX Security 2026 Artifact Submission Instructions https://secartifacts.github.io/usenixsec2026/instructions [23] USENIX Security 2026 Artifact Evaluation Guide (for reviewers) https://secartifacts.github.io/usenixsec2026/guide 67 / 69
64. 参考文献 参考文献（2/3） [24] NDSS 2027 Call for AEC Members https://secartifacts.github.io/ndss2027/aec-call [25] USENIX Security 2026 Artifact Evaluation Badges https://secartifacts.github.io/usenixsec2026/badges [26] ACM. Artifact Review and Badging – Current（Version 1.1） https://www.acm.org/publications/policies/artifact-review-and-badging-current [27] IEEE S&P 2026 Artifact Evaluation Badges https://secartifacts.github.io/sp2026/badges [28] NDSS 2026 Artifact Evaluation Results https://secartifacts.github.io/ndss2026/results [29] USENIX Security 2026 Artifact Evaluation Results https://secartifacts.github.io/usenixsec2026/results [30] USENIX Security 2026 Artifact Evaluation Awards https://secartifacts.github.io/usenixsec2026/awards [31] IEEE S&P 2026 Distinguished Artifact Awards https://sp2026.ieee-security.org/awards_artifacts.html [32] IEEE S&P 2026 Artifact Evaluation Results https://secartifacts.github.io/sp2026/results [33] NDSS 2027 Artifact Appendix LaTeX Template https://secartifacts.github.io/ndss2027/ndss_ae_appendix_template_v1.tex [34] USENIX Security ’26 Artifact Appendix LaTeX Template https://secartifacts.github.io/usenixsec2026/appendix/usenix-security-26-ae-latex.zip [35] ACM CCS 2026 Artifact Appendix Template [36] jelenamirkovic/artmeta（GitHub、commit 6a0640f） https://github.com/jelenamirkovic/artmeta [37] SoftWare Hash IDentifier (SWHID) https://www.swhid.org/ [38] Zenodo. What is DOI versioning? https://support.zenodo.org/help/en-gb/1-upload-deposit/97-what-is-doi-versioning [39] USENIX Security 2026 Artifact Evaluation Tips https://secartifacts.github.io/usenixsec2026/tips [40] Eviction Notice: Reviving and Advancing Page Cache Attacks. NDSS 2026（Artifact appendix） https://www.ndss-symposium.org/ndss-paper/eviction-notice-reviving-and-advancing-pagecache-attacks/ [41] “Do Not Mention This to the User”: Detecting and Understanding Malicious Agent Skills in the Wild（Artifact appendix） https://secartifacts.github.io/usenixsec2026/appendix-files/sec26cycle2ae-final57.pdf [42] SoK: The Pitfalls of Deep Reinforcement Learning for Cybersecurity（Artifact appendix） https://secartifacts.github.io/usenixsec2026/appendix-files/sec26cycle2ae-final18.pdf [43] Y. Kubo, F. Kanei, M. Akiyama, T. Wakai, T. Mori. Action Required: A Mixed-Methods Study of Security Practices in GitHub Actions. NDSS 2026 https://www.ndss-symposium.org/ndss-paper/action-required-a-mixed-methods-study-ofsecurity-practices-in-github-actions/ [44] yksec14/gha_security_research（GitHub） https://github.com/yksec14/gha_security_research https://www.sigsac.org/ccs/CCS2026/assets/appendix/ccs2026-ae.zip © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 68 / 69
65. 参考文献 参考文献（3/3） [45] Artifact - Action Required（Zenodo, DOI 10.5281/zenodo.17916232） https://doi.org/10.5281/zenodo.17916232 [46] NDSS 2026 Call for Artifacts https://secartifacts.github.io/ndss2026/call [47] NDSS 2026 Artifact Evaluation Badges https://secartifacts.github.io/ndss2026/badges [48] NDSS 2026 Artifact Appendix Package https://secartifacts.github.io/ndss2026/ndss_ae_package.zip [49] Anonymous GitHub https://anonymous.4open.science/ [50] tdurieux/anonymous_github README（GitHub）・FAQ（anonymous.4open.science/faq） https://github.com/tdurieux/anonymous_github [51] GitHub Docs. Referencing and citing content [56] G. Starace, O. Jaffe, D. Sherburn, J. Aung, et al.（OpenAI）. PaperBench: Evaluating AI’s Ability to Replicate AI Research. ICML 2025, PMLR 267 https://proceedings.mlr.press/v267/starace25a.html [57] Z. S. Siegel, S. Kapoor, N. Nadgir, B. Stroebl, A. Narayanan. CORE-Bench: Fostering the Credibility of Published Research Through a Computational Reproducibility Agent Benchmark. Transactions on Machine Learning Research（2024 年 12 月） https://arxiv.org/abs/2409.11363 [58] D. Heye, K. Kindermann, R. Decker, J. Lohmöller, A. Belova, S. Geisler, K. Wehrle, J. Pennekamp. Supporting Artifact Evaluation with LLMs: A Study with Published Security Research Papers. IEEE BigData 2025 https://ieeexplore.ieee.org/document/11401815/ [59] Z. Wu, Y. Zhao, Z. Chen, Z. Wang, H. Wang. Agent-Based Software Artifact Evaluation. arXiv:2602.02235（プレプリント, 2026） https://arxiv.org/abs/2602.02235 https://docs.github.com/en/repositories/archiving-a-github-repository/referencing-and-citingcontent [52] Zenodo Help. GitHub integration（画像は CC BY 4.0） https://help.zenodo.org/docs/github/ [53] NDSS 2027 Artifact Evaluation Organizers（2026-10-19 時点） https://secartifacts.github.io/ndss2027/organizers [54] USENIX Security ’24 Message from the Program Co-Chairs https://www.usenix.org/sites/default/files/sec24_message.pdf [55] USENIX Security ’25 Message from the Program Co-Chairs https://www.usenix.org/sites/default/files/sec25_message.pdf © NTT DOCOMO BUSINESS, Inc. All Rights Reserved. 69 / 69