第3章　研究実践

この章では、信頼できる研究を支える日々の実務―記録・コード・データの扱い―を具体的な手順に落とす。研究の質は、派手なアイデアや高度な解析だけでは決まらない。記録が残っているか、フォルダ構造が明快か、コードの変更履歴が追えるか―こうした地味な実務が、最終的に何をどれだけの強さで主張できるかを決める。実験・解析・発表・論文は別々の仕事ではなく、一つの流れの別の断面にすぎない。研究実践とは、将来の論証をいまのうちから支えるインフラづくりである。

ポイント：本章を貫く一行は「主張の強さは証拠の強さで決まる」である。記録（§2）・コード（§3）・データ（§4）・計算環境の固定（§5）はどれも、証拠を「後から自分や他人が結果を再構成できる状態」に保つための手段であり、その意味でこの一行の言い換えである。とくに研究記録は単なる備忘録ではなく、結果を知る前に自分が何を考え、何を予測していたかを保存する装置だと受け取ってほしい。章は、研究法の考え方（§1）→記録（§2）→コード（§3）→データ（§4）→計算再現性の確保（§5）→プロジェクト管理（§6）→AI 時代の注意（§7）の順に進む。各テーマをさらに深めたいときの入口として、PLOS の Ten Simple Rules を §8 に集めた。倫理審査・同意・ヒト/動物指針は第2章、図の作り方の一般原則は第8章で扱う。

1. 研究法をどう捉えるか

再現性は累積的な科学の礎である（NASEM, 2019；第2章§4）。他者や将来の自分が同じ手順で整合する結果を得られなければ、研究は検証も批判もできない。心理学・生命科学の再現率の低さは2010年代に「再現性の危機」として広く認識された（第2章）。

検証には実験の再現性と計算の再現性の二つの観点がある。前者は「論文の記述をもとに、他者が同じ実験を実施し、整合する結果を得られるか」（手順・刺激・条件・被験者基準・装置設定の記述に依存）、後者は「同一のデータ・コード・環境で同一の解析結果が得られるか」（§5で詳述）。第2章の用語では前者が Replicability（再現性）、後者が Reproducibility（再生性）に対応する（本章では実装に即して「計算の再現性」と呼ぶ）。いずれも記述―何をしたか・なぜそうしたか・何が起きたかを実施時点で残すこと―によって初めて実現する。

1.1 研究法のさまざまな考え方

研究法というと「仮説を立て、実験し、解釈する」一本道を思い浮かべやすい。だが実際には、実験・観察・理論・モデリング・機械学習で重視される徳目は異なる。覚えるべきは「唯一の正しい方法」ではなく、目指す知識の種類によって前景化する原則が変わることだ。相関を見る研究と因果を示す研究では必要な証拠が違い、予測精度を競う研究と仕組みを説明する研究では「よいモデル」の条件が違う。

古典的には、Chamberlin の複数作業仮説法（multiple working hypotheses）、Platt の strong inference、Popper の反証可能性が参照される。共通するのは、一つの本命仮説に恋をせず、競合仮説を明示し、どの観察がそれらを切り分けるかを考える姿勢である。

混同しやすいこと：

  • 有意性 ≠ 効果の大きさ。 p 値が小さいのは「ゼロとは言いにくい」だけ。サンプルが大きければ些細な差も有意になる。効果量・信頼区間・実質的意義を分けて考える。
  • 相関 ≠ 因果。 一緒に動くことは出発点にすぎない。因果には介入・時間順序・統制条件・反事実比較などの別の論拠が要る。
  • 予測の成功 ≠ 説明の深さ。 ベンチマークの高成績は、脳や心の mechanistic insight（機構的理解）を与えたことにはならない。とくに、脳と AI を橋渡しする NeuroAI では混同しやすい。
  • SOTA の更新 ≠ 科学的価値。 state of the art（その時点の最高性能）の更新には、見かけの手がかりだけで解く shortcut learning や、評価用データに過剰適合する benchmark overfitting が潜む。代理指標そのものを目標にすると本来の対象を見失う（測りやすい指標を目標に据えると、その指標が指標として機能しなくなるという Goodhart の法則）。

実務として重要な原則：

  • 裏を取る（triangulation）。 別の解析法・指標・刺激集合・被験者群・データ分割でも近い結論に届くか。結論が特定の方法の癖に依存していないかを確かめる。
  • ポジティブ／ネガティブコントロールを置く。 出るべき条件で出るか、出てはいけない条件で出ないか。両方ないと結果の意味を解釈できない。
  • 測定・解析・解釈を混同しない。 何を測ったか・どう解析したか・何が言えるかは別段階。数理的にきれいなことと対象を捉えていることは別である。
ノート神谷研の視点：主張の強さは証拠の強さで決まる

面白い結果・意外な結果ほど、より強い証拠・より厳密な方法・より慎重な解釈が必要になる。インパクトと誠実さは対立しない。強い主張をしたいなら、そのぶんだけ失敗しうる条件を先に考え、代替説明をつぶし、限界を明示する。これが本章のすべての実務（記録・コード・データ・環境固定）の存在理由である。研究法とは creativity を潰す規則ではなく、思いつき・願望・確認バイアス・過剰な物語化から自分を守り、信頼できる知識へと創造性を変える道具だ。なお、p < 0.05 を合否ラインに使う運用や、変数を機械的に取捨する stepwise 回帰のような20世紀の標準は、目的と誤りの型に応じて選び、限界を明示する姿勢に置き換わりつつある。

2. 記録と透明性

記録で問われているのは几帳面さではなく、どの情報を未来へ渡すべきかという判断である。研究が止まるのは情報が足りないときよりも、「何を残していないか」に自分で気づけないときだ。脳活動・行動・主観報告のように人の内面に近い情報を扱う研究では、記録の欠如は単なる不便ではなく説明責任の欠如になる。

記録の核心は、「結果を知る前に何を知っていたか」を時点つきで保存する点にある。いつ・何をし・どんな知識と仮説を持っていたか―このタイムスタンプ付きの履歴こそが、事後の解釈（accommodation）と事前の予測（prediction）を分け、HARKing（第2章§3.1）を防ぐ鍵になる。データを見ただけでは、意味のあるシグナルか偶然のノイズかは判別できない。だからこそ、残すべきは手順や結果だけではない。

  • その日の時点で想定していた仮説と、競合する説明
  • 参照した文献・先行知識と、その段階で未確認だった点
  • 解析・実験条件を選んだ理由と、見送った選択肢
  • 結果を見た後に思いついた解釈と、事前に考えていた解釈の区別

この区別が残っていれば、探索的に見つけたパターンを将来の検証課題として扱える。逆に残っていなければ、後からどんな話でも「最初からそう考えていた」と書けてしまう。記録は几帳面さの証明ではなく、推論の履歴書である。

探索の局面では、何を変えたせいで何が変わったかが追えることがとくに重要だ。原則は「一度に一つだけ変え、他を揃える」だが、要因は独立とは限らない。複数の要因を組み合わせて試す factorial な設計や、要因どうしが効果を打ち消し合う・強め合う交互作用も視野に入れる。複数を同時に変えたなら、そのこと自体を隠さず書く。

2.1 信頼できる記録の3属性と記録の置き場所

信頼できる記録には、帰属（誰が記録・変更したか）・同時（実施と同時に記録）・痕跡（訂正時も元を残す）が求められる。Git のコミット履歴や ELN（電子ノート、Electronic Lab Notebook）のタイムスタンプは、これらを部分的に満たす。記録は研究者の私物ではなく所属機関の資産として保管される（Schnell, 2015）。記録の形式は、コードと一体化できるものほど、信頼できる研究を支えやすい。

記録形式の比較
形式 ツール 特徴
コードベース Git + Jupyter Notebook / R Markdown 解析と記録の一体化。再現性が高い。推奨（§3・§5）。
電子ノート（ELN） Notion, OneNote 等 日付・タイトル・手順・結果へのリンク・考察。コードと併用可。
紙 ノート 補助的なメモ。原本を残し、訂正は取り消し線で。

実験セッションごとに仮説・手順・結果・失敗の理由を記し、解析・考察では背景・方法・結果・使用コードのパスを記録する。失敗や負の結果も省略しない。記録を後から辿れる状態に保つには、ファイルの置き場所も標準化しておくとよい。ニューロイメージングのフォルダ構造は BIDS（Gorgolewski et al., 2016）が国際標準で、解析プロジェクトは data/ src/ results/ を分離する構成が推奨される（Noble, 2009；Princeton Handbook）。

ノート神谷研の視点：Research log の運用

神谷研では Experiment log と Research log を Notion で運用する。Research log は文章ベースで書き、5年後に他の誰かが読んでも理解・再現できる水準を目指す。スライド形式での投稿は認めない―見栄えが良い反面、文脈や条件の省略を招き、記録としての精度が犠牲になるからだ。構成は Summary → Background and Aim → Methods → Results and discussion → Data and code、タイトルは yymmdd - 名前 - タイトル で統一する。図にはタイトル・凡例・軸ラベルを必ず付け、被験者は実名でなく ID（S1, S2…）で記す。探索的な比較を行った日は、前回から何を変えたか（例：「正則化係数のみ変更」「前処理と損失関数を同時に変更」）を先頭に明示する。研究ログは成功例の記録ではなく、意思決定の履歴である。

修正指示への運用も明確だ。指導教員からの修正指示には「了解」のスタンプを直ちに返し、修正が完了したら報告する。報告がなければ修正されたかを確認する手段がない。指示されて黙って直すだけでは、直したことにならない。

2.2 研究記録としての図

図の作り方の一般原則（C-R-A-P、Data-ink ratio、配色、視認性）は第8章に集約する。ここでは研究記録としての図に固有の点を述べる。比較実験やモデル改良の図では、何を変えたら何が変わったのかが一目で分かることが決定的だ。条件差・操作変数・評価指標・比較基準が読み取れず、x/y 軸ラベルや凡例が欠け、どの条件か分からないファイル名のまま保存された図は、研究の履歴を自分で壊しているのと同じである。よい図は読者のためだけでなく、次に何を試すかを判断する自分自身のためにある。

ノート神谷研の視点：研究記録としての図の作り方

技術的には、figsize は小さめ（例 (4, 3)）にしてフォントとのバランスをとり、保存は dpi=300 を標準とする。キャプションには、評価指標が何か・色が何を表すか・エラーバーが SD か SE か 95% CI かを必ず明記する。

3. コーディングとバージョン管理

コードは便利な道具である前に、研究の推論過程を外部化した記録である。重視すべきは「動くコードを書く」ことより「なぜその結果が出たかを後から説明できる状態を保つ」ことだ。

書き方の原則：変数名・関数名は意味のある名前にし、マジックナンバーを避ける。同じ処理は関数化（1関数1タスク）。コメントは「何を」より「なぜ」。生データ → スクリプト → 結果の一方向パイプラインを構築する（§5）。一貫したスタイルは可読性・保守性を高め、他者と未来の自分による検証を容易にする。

バージョン管理：ファイルの変更履歴を記録し、過去の状態に戻したり差分を確認したりするしくみ。Git はローカルで履歴を記録するソフトウェア（主にコード・設定・Markdown 等のテキストが対象）、GitHub はそれをオンラインでホストし共有・共同編集を可能にするサービス。解析コードは Git で履歴を追跡し GitHub 等でホストする（Wilson et al., 2014, 2017）。これにより §2.1 の帰属・同時・痕跡がおおむね満たされる。

公開と再現性：コードは他者の手元で動かなければ検証可能性が成立しない。データやコードが公開されていない研究は第三者検証が原理的に不可能で、第三者から「potentially compromised（信頼性に疑義がある）」と評価されても反論できない。検証可能性の確保は段階的に―まず整形（スタイルガイド準拠）、次にテスト（関数の挙動確認）、最後に CI（継続的インテグレーション、変更が既存機能を壊さないか自動検証）。ライセンスを明示しないと利用条件が曖昧になり再利用・引用を阻害する（研究コードは MIT が無難。データ・文書は CC-BY-4.0。選択は choosealicense.com）。

§3–§5 で述べる原則を一冊で体系的に扱ったのが、神経科学者 Poldrack の Better Code, Better Science である―ソフトウェア工学の原則からテスト・AI とのコーディング・ワークフロー管理・科学ソフトウェアの検証・研究成果物の共有までを、再現性という一本の軸で貫く。断片的なルールの寄せ集めではなく「なぜそうするか」を通して読める、この分野の現代的な定番といえる。

代表的なスタイルガイドとライセンス
言語 スタイルガイド
Python PEP 8、Black、Ruff
R Tidyverse Style Guide、styler、lintr
Julia Julia Style Guide
ライセンス 特徴 適用
MIT 最も寛容。改変・再配布・商用すべて可 研究コードのデフォルト
Apache 2.0 MIT に特許条項を追加 特許が関係する場合
GPL v3 派生物も GPL にする義務（copyleft） 派生物もオープンにしたい場合
BSD 2/3-Clause MIT に類似。寛容 学術研究の慣行に合わせたい場合
CC データ・文書・画像向け。CC-BY-4.0 推奨 データ・文書（コード不向き）
ノート神谷研の視点：Code management

神谷研では解析コードを Git で管理し GitHub でホストする。Research log で結果を報告する際は、対応するコードを GitHub リンクで列挙し、必要に応じて Git tag（例：200125.1）でバージョンを固定する。詳細は研究室の Code management ガイドラインを参照。

4. データ管理

データ管理は保存場所を整える作業ではなく、データを「将来も意味のある単位」として保つ作業である。ファイルが残っていても、変数名の意味・除外基準・前処理の順序が失われていれば、そのデータは事実上失われている。とくにヒト由来データでは、何をどの同意範囲で集め、どこまで共有し、どの識別子を切り離したかが分からなくなった時点で、科学的にも倫理的にも扱いにくくなる。

4.1 FAIR 原則と DMP・リポジトリ

FAIR 原則は、Wilkinson et al. (2016) が提唱した、データ共有の質を高める国際的枠組みである。FAIR に沿うとデータが発見・取得・統合されやすく、再利用と検証可能性が高まる。ただし FAIR は基準線であり、どのリポジトリを使い、どこまで公開し、どの DMP を出すかは助成機関・所属機関ごとに変わる。

原則 意味 実践
Findable 発見可能 永続的識別子（DOI）、メタデータ付与、リポジトリ登録
Accessible アクセス可能 標準プロトコルで取得可能に。認証が要るなら手順を明示
Interoperable 相互運用可能 標準形式（CSV, JSON, NIfTI 等）と語彙を使用
Reusable 再利用可能 明確なライセンス、十分なメタデータ、出典情報

DMP（データ管理計画）：収集・保管・共有・保存の方針を事前に文書化する。多くの助成機関が申請時に提出を求めるが、テンプレートと必須項目は国・機関・制度で異なる。データリポジトリは DOI 付き公開で FAIR の Findable・Accessible を実現する（分野標準・機微性・ライセンス・助成要件で選ぶ）。GitHub のリリースを Zenodo と連携させてスナップショットに DOI を自動発行するワークフローが定番。データ構造の標準（Tidy Data、BIDS 等）に従うと Interoperable・Reusable が高まる。

DMP 支援ツール・データリポジトリ・データ標準
DMP ツール 概要
DMPTool 主に米国助成機関のテンプレートに対応。dmptool.org
DMPonline 英国 DCC 提供。dmponline.dcc.ac.uk
DMProadmap 両者の統合後継（DCC と UC3 の共同開発）
機関のテンプレート 科研費等で機関・制度がテンプレートを提供する場合あり
リポジトリ 分野 特徴
Zenodo 汎用 CERN 運営。DOI 自動付与。GitHub 連携。zenodo.org
Figshare 汎用 データ・図・動画。DOI 付与。figshare.com
Dryad 生物学中心 査読論文付随データ。キュレーション付き。datadryad.org
OpenNeuro 神経画像 BIDS 形式の脳画像。openneuro.org
OSF 汎用 プロジェクト管理＋データ・コード・プレプリント統合。osf.io
GenBank / SRA 生命科学 遺伝子配列。NCBI 運営。ncbi.nlm.nih.gov
データ標準 分野 概要
Tidy Data 汎用 Wickham (2014): 各変数が列・各観測が行・各値がセル。DOI
BIDS 脳画像 Gorgolewski et al. (2016): MRI/EEG/MEG 等の標準。DOI / bids.neuroimaging.io

5. 計算再現性の確保

ここで扱うのは計算の再現性―同一のデータ・コード・環境で同一の解析結果を得ること（NASEM, 2019；Sandve et al., 2013）の実装である。再現の試みの成功率は低い。実験の再現では心理学の大規模追試で 36%（Open Science Collaboration, 2015）、計算の再現では経済学で約 50%（著者支援あり；Chang & Li, 2015）、バイオインフォマティクスで 11%（Ziemann et al., 2023）と報告される。道具を増やすこと自体が目的ではない。目的は、環境・実行順序・依存関係に埋もれた偶然を減らし、「結果が出た理由」を自分で再構成できる状態を保つことにある。

環境固定：同じコードでも OS・ライブラリ・乱数シードが異なれば結果が変わる。デコーディングやクロスバリデーションでは np.random.seed(42) や random_state=42 を固定し、Methods にシード値を明記する。環境そのものは conda/pip やコンテナで固定する。

文芸的プログラミング（literate programming）：コードと説明を一体化すると、解析の意図と手順が明示され、再現と批判的検討が容易になる。Jupyter Notebook は対話的で便利だが実行順序の依存で再現性が下がる。論文掲載の解析は上から順に実行するだけで完結するノートブックかスクリプトにする（Rule et al., 2019）。提出・公開前には必ずカーネルをリセットして全セルを一括実行し、エラーなく通ることを確認する。再現性のない実行結果は、存在しないのと同じである。

環境管理ツールとオープンサイエンス資源
ツール 主な用途 備考
conda / mamba Python 解析環境（nilearn, nibabel 等） environment.yml をリポジトリに含める
pip + requirements.txt 軽量な Python プロジェクト バージョン明示
uv Python 環境の高速管理 Astral 社。仮想環境・バージョン管理・ロックを一括。docs.astral.sh
renv R プロジェクト専用 renv.lock で完全再現
Docker fMRIPrep 等のパイプライン fMRIPrep
Apptainer HPC 上のコンテナ（root 不要） apptainer.org
Quarto .qmd から PDF/HTML/Word 章立てレポート向き。quarto.org
資源 概要
TOP Guidelines ジャーナルが採用する透明性8基準（レベル0–3）。cos.io
The Turing Way 再現可能なデータサイエンスのハンドブック。book.the-turing-way.org
Princeton Handbook ニューロイメージング再現性に特化（BIDS, fMRIPrep, DataLad）。brainhack-princeton.github.io

6. プロジェクト管理とコラボレーション

計画が曖昧だとプレッシャー下で QRPs（疑わしい研究実践、第2章）に陥りやすく、記録・検証もおろそかになる。研究が破綻するとき、原因は技術不足よりも「誰も全体像を見ていなかった」ことである場合が少なくない。進捗共有やタスク管理は、効率化のためだけでなく判断の孤立を防ぐ装置として捉える。ラボミーティングの形式（ローテーション発表・スタンドアップ・ジャーナルクラブ等）は規模と文化で選ぶが、いずれも進捗の可視化・早期フィードバック・透明性を高める目的をもつ（Golden et al., 2021）。タスクはカンバンやガントチャートで可視化し、共同研究では、チャット・共同執筆・文献共有のツールを揃える。

ノート神谷研の視点：プログレスミーティングとハンドアウト

神谷研では Research log にもとづくプログレスミーティングを週1回行い、1-on-1 と併用する。報告は Research log の文章形式（Notion）を標準とし、スライド形式は用いない（§2.1）。課題が未解決でも進捗が遅れていても隠さず共有し、次の方針を決める。発表では結果のインパクトだけに目を奪われないこと。とくに卒業研究では、信頼性の高い方法をどれだけ実践し、推論と解釈の妥当性を示せるかが問われる。派手な結果が出なくても、正しい手順を踏み過程を透明に記述できれば、それ自体が価値ある成果である。

中間報告のハンドアウトは「背景と方法のメモ」ではなく独立に読める短い報告書だ。スライドを配れば十分と考えず、最低でも序論・本論・結論の形を保ち、何を問い・どの方法で確かめ・何が分かり・何が言えるかを短くても明示する。ここでも第5章の階層的包含が効く―問いを超える話題は入れず、問いに必要な結果は省略しない。何を残し何を削るかの判断こそ、研究の論理を理解しているかの試金石である。

ラボミーティング形式・タスク管理・コラボレーションツール
ミーティング形式 内容
ローテーション発表 順番に研究進捗・練習発表・論文紹介
スタンドアップ 各自5分。「やったこと・次にやること・困っていること」
ジャーナルクラブ 1名が論文紹介、全員で議論
タスク管理 概要 ツール
カンバン To Do → In Progress → Done を可視化。WIP 制限 Trello、GitHub Projects、Notion
ガントチャート タスクの期間と依存を時系列表示。申請書で求められる Mermaid、Asana、MS Project
コラボ用途 代表ツール
チャット Slack、Microsoft Teams、Discord
共同執筆 Overleaf、Google Docs、Word Online
文献共有 Zotero Groups（第4章）

神谷研の運用（参考）：Slack（チャット）・Google Docs（執筆）・Zotero（文献）・GitHub（コード）・Notion Tasks（Research log・Minutes とリレーション）を併用。

7. AI 時代の研究実践

AI を入れると速くなる工程と慎重さが要る工程が同時に生まれる。問うべきは「どこに AI を入れるか」より「AI を入れてもなお人間が保持すべき判断は何か」だ。本章に固有の注意は三点に絞られる。

  • スクリプトとして固定する。 LLM は同一プロンプトでも出力が揺れうる（非決定性）。解析の最終結果は対話的出力でなく実行可能なスクリプトで再現できるようにする（Ouyang et al., 2025）。
  • 用途を限定し、検証する。 AI は「解析そのもの」ではなく「コードの生成・デバッグ・説明」に使い（§3）、コードは必ず検証して自分で説明できる状態にする（AI とのコーディングと科学ソフトウェアの検証の実践は、§3 で挙げた Poldrack Better Code, Better Science が一章を割いて論じている）。
  • 環境情報を記録する。 モデル名・バージョン・API 日付・プロンプト・temperature を Methods か補足に残す。

実際、ソフトウェア工学の LLM 研究18件中、完全に再現できたのは0件という報告もある（Angermeir et al., 2025）。AI の使用は Methods で開示し、著者が全内容に責任を負う（COPE）。AI 利用の3原則（責任・検証・開示）と各社方針の詳細は付録「研究における AI 活用ガイド」に集約する。

8. さらに学ぶために：Ten Simple Rules

PLOS Computational Biology の「Ten Simple Rules」シリーズは、テーマごとに10条の実践指針を具体例とチェックリストつきでまとめた短文記事で、100件以上が公開されている。本章の内容を深く学ぶなら、まず次の3件が出発点になる。

  • Reproducible Computational Research（Sandve et al., 2013）―生データの保持・計算の記録・バージョン管理・乱数シード。§2–§5の骨格。
  • Good Enough Practices in Scientific Computing（Wilson et al., 2017）―データ管理・ソフトウェア・共同作業・プロジェクト構成の初心者向け実践。
  • Productive Lab Meetings（Golden et al., 2021）―形式の選択・アジェンダ・記録・フィードバック。§6に対応。

統計・コラボレーション・ラボ運営など他テーマは PLOS Ten Simple Rules Collection で横断できる。

まとめ：この章の幹

  1. 主張の強さは証拠の強さで決まる。 本章の実務（記録・コード・データ・環境固定）はすべて、後から結果を再構成できる状態を保つための手段である。
  2. 研究法に唯一の正解はない。目指す知識の種類で前景化する原則が変わる。有意性／効果量、相関／因果、予測／説明、SOTA／科学的価値を混同しない。裏を取り、コントロールを置く。
  3. 記録は推論の履歴書。 手順や結果だけでなく「結果を知る前に何を考えていたか」を時点つきで残し、HARKing を防ぐ。神谷研の Research log は文章ベース、yymmdd - 名前 - タイトル、スライド不可、「了解」スタンプ運用。
  4. コードは推論過程の外部化。Git/GitHub で帰属・同時・痕跡をおおむね満たし、整形→テスト→CI で他人の環境でも動く状態に。データは FAIR で将来も意味のある単位に保つ。
  5. 計算の再現性は環境固定と文芸的プログラミングで実現する。図は研究記録としては「何を変えたら何が変わったか」を示す論証の装置である。
  6. プロジェクト管理は判断の孤立を防ぐ装置。AI を入れても人間が保持すべき判断（固定・検証・記録）を手放さない。
参考文献

研究デザイン・研究法

  • Creswell, J. W., & Creswell, J. D. (2018). Research design: Qualitative, quantitative, and mixed methods approaches (5th ed.). SAGE.
  • Platt, J. R. (1964). Strong inference. Science, 146(3642), 347–353. DOI
  • Chamberlin, T. C. (1890). The method of multiple working hypotheses. Science, o.s. 15(366), 92–96. DOI

記録・研究ノート

  • Gorgolewski, K. J., et al. (2016). The brain imaging data structure: A format for organizing and describing outputs of neuroimaging experiments. Scientific Data, 3, Article 160044. DOI
  • National Academies of Sciences, Engineering, and Medicine. (2019). Reproducibility and replicability in science. National Academies Press. DOI
  • Noble, W. S. (2009). A quick guide to organizing computational biology projects. PLOS Computational Biology, 5(7), e1000424. DOI
  • Princeton Handbook for Reproducible Neuroimaging. (n.d.). brainhack-princeton.github.io
  • Rule, A., Tabard, A., & Hollan, J. D. (2019). Writing and sharing computational analyses in Jupyter Notebooks. PLOS Computational Biology, 15(5), e1007007. DOI
  • Sandve, G. K., Nekrutenko, A., Taylor, J., & Hovig, E. (2013). Ten simple rules for reproducible computational research. PLOS Computational Biology, 9(10), e1003285. DOI
  • Schnell, S. (2015). Ten simple rules for a computational biologist’s laboratory notebook. PLOS Computational Biology, 11(9), e1004385. DOI
  • Wilson, G., et al. (2017). Good enough practices in scientific computing. PLOS Computational Biology, 13(6), e1005510. DOI

科学的計算・コーディング・バージョン管理

  • Martin, R. C. (2009). Clean code: A handbook of agile software craftsmanship. Prentice Hall.
  • Scopatz, A., & Huff, K. D. (2015). Effective computation in physics. O’Reilly.
  • Wilson, G., et al. (2014). Best practices for scientific computing. PLOS Biology, 12(1), e1001745. DOI
  • Poldrack, R. A. (n.d.). Better Code, Better Science: Software engineering for reproducible science in the age of AI. bettercode-book.org（CC BY-NC-ND 4.0；コードは MIT）
  • Blischak, J. D., Davenport, E. R., & Wilson, G. (2016). A quick introduction to version control with Git and GitHub. PLOS Computational Biology, 12(1), e1004668. DOI
  • Bryan, J. (2018). Excuse me, do you have a moment to talk about version control? The American Statistician, 72(1), 20–27. DOI
  • Chacon, S., & Straub, B. (2014). Pro Git (2nd ed.). Apress. git-scm.com

データ管理・FAIR

  • Wickham, H. (2014). Tidy data. Journal of Statistical Software, 59(10), 1–23. DOI
  • Wilkinson, M. D., et al. (2016). The FAIR Guiding Principles for scientific data management and stewardship. Scientific Data, 3, Article 160018. DOI

再現性・オープンサイエンス

  • Kerr, N. L. (1998). HARKing: Hypothesizing after the results are known. Personality and Social Psychology Review, 2(3), 196–217. DOI
  • Ziemann, M., Poulain, P., & Bora, A. (2023). The five pillars of computational reproducibility: Bioinformatics and beyond. Briefings in Bioinformatics, 24(6), bbad375. DOI
  • Chang, A. C., & Li, P. (2015). Is economics research replicable? Sixty published papers from thirteen journals say “usually not”. Finance and Economics Discussion Series 2015-083. Board of Governors of the Federal Reserve System. DOI
  • Gelman, A., & Loken, E. (2014). The statistical crisis in science. American Scientist, 102(6), 460–465. DOI
  • Munafò, M. R., et al. (2017). A manifesto for reproducible science. Nature Human Behaviour, 1, Article 0021. DOI
  • Open Science Collaboration. (2015). Estimating the reproducibility of psychological science. Science, 349(6251), aac4716. DOI
  • Simmons, J. P., Nelson, L. D., & Simonsohn, U. (2011). False-positive psychology. Psychological Science, 22(11), 1359–1366. DOI

統計

  • Cohen, J. (1988). Statistical power analysis for the behavioral sciences (2nd ed.). Lawrence Erlbaum.
  • Lakens, D. (2022). Improving your statistical inferences. lakens.github.io
  • McElreath, R. (2020). Statistical rethinking (2nd ed.). CRC Press.
  • Poldrack, R. A. (2019). Statistical thinking for the 21st century. statsthinking21.github.io
  • Wasserstein, R. L., & Lazar, N. A. (2016). The ASA’s statement on p-values: Context, process, and purpose. The American Statistician, 70(2), 129–133. DOI

AI と再現性

  • Ouyang, S., Zhang, J. M., Harman, M., & Wang, M. (2025). An empirical study of the non-determinism of ChatGPT in code generation. ACM Transactions on Software Engineering and Methodology, 34(2), Article 42. DOI
  • Biderman, S., et al. (2024). Lessons from the trenches on reproducible evaluation of language models. arXiv preprint, arXiv:2405.14782. arXiv
  • Angermeir, F., et al. (2025). Reflections on the reproducibility of commercial LLM performance in empirical software engineering studies. arXiv preprint, arXiv:2510.25506. arXiv
  • COPE. (n.d.). Authorship and AI tools. Committee on Publication Ethics. publicationethics.org

プロジェクト管理・ラボ運営

  • Golden, N., et al. (2021). Ten simple rules for productive lab meetings. PLOS Computational Biology, 17(5), e1008953. DOI
  • Barker, K. (2010). At the helm (2nd ed.). Cold Spring Harbor Laboratory Press.
  • Cohen, C. M., & Cohen, S. L. (2005). Lab dynamics (2nd ed.). Cold Spring Harbor Laboratory Press.
  • Newport, C. (2016). Deep work. Grand Central Publishing.
  • Silvia, P. J. (2019). How to Write a Lot (2nd ed.). APA.

オンラインリソース・ツール