研究の世界でソフトウェアは脇役扱いされがちです。論文の本体は理論や結果で、コードはその裏で動く作業用の道具にすぎない、という見方は今でも根強いでしょう。だが、Jens Egholm Pedersen はその前提をひっくり返し、現代の科学、とくに計算を伴う科学はオープンソースソフトウェアとほぼ同義だと主張します。しかもこれは比喩ではなく、科学のやり方そのものの話だと彼は言います。研究の再現性、検証可能性、そして他者がその成果の上に積み上げられるかどうかが、コードの公開と結びついているからです。
元記事はまず、そもそも科学とは何かを問い直すところから始まります。Wikipedia には「科学は、宇宙についての検証可能な仮説や予測を構築し、体系化する体系的な営みだ」といった説明がある、と紹介し、そのうえで arXiv にあるような任意の論文を手に取ってみるよう促します。そこには知識はある。ただし、その知識が本当に予測に使え、しかも体系的に検証できる形になっているかは別問題だ、と彼は見るのです。
ここで持ち出されるのが、Kenneth James Williams Craik の「人は頭の中に小さな現実モデルを持ち、それで世界を予測している」という考え方です。著者の説明では、科学の目的は内的なモデルを磨き、以前よりうまく予測できるようになることにあります。そう考えると、論文の内容が読者のモデルに取り込めず、検証にも使えないなら、それは科学として弱い。だからこそ、計算を使う研究では reproducibility、つまり再現可能性が重要になる、と話を進めます。ここでいう再現性は、単に同じ結果が出ることではありません。自分のモデルに取り込み、調整し、さらに発展させたり、逆に捨てたりできることまで含みます。
著者はこの流れから、ソフトウェアが科学に不可欠だと論じます。計算科学では、ソフトウェアが予測モデルを実装し共有する手段だからです。しかもソフトウェアは実生活のさまざまな研究に深く入り込んでおり、COVID-19 のモデル、検索アルゴリズム、実験室の手順にまで使われている。研究者は依存関係の隅々まで検証できないので、結果はコードを信頼するしかない。ところが、そのコードにバグがあれば科学結果も崩れる。著者は、ソフトウェアの不具合が論文撤回の原因になった例が複数あることにも触れます。
では、なぜ open source なのか。著者の答えは、科学に必要なのが「実行できること」と「改変できること」、そして信頼できることだからです。オープンソースなら、コードを変え、自分たちの目的に合わせて作り替え、そこから改善を続けられる。Hugging Face のモデルのように、既存の成果を再利用しながら前に進める世界とも重ねています。もちろん、IP や security の懸念、バグや安定性の問題は残る。ただ、欠点があるにしても、それらが公開された形で残るぶん、後から直しやすい。著者はそこに、科学的方法そのものに近いものを見るのです。
最後に彼は、もし本当に「計算する科学」がオープンであるべきなら、将来の研究はどう変わるのかという絵を描きます。論文を読んだ瞬間に、同じ環境で分析がブラウザ上で走り、気候モデルは世界中のコミュニティで共同保守され、ケニアの研究者が見つけたバグが即座に全世界のシミュレーションへ反映される。成果は読み物ではなく、実行可能で改変可能な共同資産になる。そこから科学への信頼も高まり、研究の進み方そのものが変わる、と彼は展望します。そして読者に、コードを共有し、再現可能な環境を使い、既存ツールの上に乗り、ソフトウェア貢献を研究者評価に入れるべきだと呼びかけて締めています。
この文章でいちばん強いのは、「ソフトウェアは研究の補助線ではなく、研究そのものを運ぶ器だ」という見方です。これは計算機科学に限らない話だと思います。今の研究は、統計解析、シミュレーション、画像処理、文献探索、実験装置の制御まで、どこかでソフトウェアに支えられている。にもかかわらず、評価制度だけが昔のままで、論文本文の華やかさに比べてコードは軽く扱われやすい。著者はそこを真正面から突いています。
ただ、ここで注意したいのは、「オープンソースだから科学である」とまでは言い切れない点です。コードを公開しても、入力データの選び方、前処理、乱数の扱い、パラメータ調整の癖で結果はいくらでもぶれます。逆に、コードが閉じていても、厳密な方法論で十分に検証された研究はあります。だから本質はライセンスの種類そのものではなく、他人が追試し、修正し、積み上げられる状態にあるかどうかでしょう。著者の議論はそこをかなり広く捉えていて、実際には「open source」より「open and inspectable」が近い場面もあるはずです。
それでも彼の主張が刺さるのは、研究の現場では「読むこと」と「動かすこと」の差が想像以上に大きいからです。論文だけ読んでも、依存ライブラリの版、環境変数、OS の差で同じ結果にならないことは珍しくありません。科学の再現性が危うい、と長く言われてきた背景には、まさにこのズレがあります。だから私は、彼の議論を理想論ではなく、研究のインフラ整備の話として受け取るべきだと思います。コードを公開することは親切ではなく、研究の説明責任の一部だ、という考え方です。
元記事の後半で興味深いのは、著者が抽象論に終わらず、かなり具体的な道具名まで出してくることです。たとえば reproducible environments のために NixOS を勧め、Docker や Conda よりも広い保証を与えると述べています。ここはやや踏み込みが強いと感じました。NixOS は再現性に強いのは確かですが、研究者全員がすぐ移行できるわけではない。既存の研究室の環境、共同研究先の事情、学習コストを考えると、現実にはそこまで簡単ではありません。
それでも、この具体性は軽く見ていい話ではないと思います。再現性の問題は「気をつけよう」では解決しません。環境差分を埋める仕組みが必要で、その候補として Nix やコンテナ技術がある。著者が言いたいのは、研究者が手元の notebook で満足せず、未来の自分や他人が同じ計算を回せる形に落とし込め、ということです。そこに厳しさがある。研究は発表して終わりではなく、動く状態で残して初めて次の人に引き渡せる、という発想です。
一方で、この厳しさは研究室ごとの温度差も浮かび上がらせます。理論系や実験系では、ソフトウェアを「共通資産」として育てる文化がまだ弱い場所も多い。だからこそ、著者の提案は単なるツール推しではなく、研究文化の再設計に近い。NixOS が本当に最適かどうかとは別に、「環境を固定し、後から同じ計算を復元できるようにする」姿勢自体は、かなり本質的です。
記事の後半で私が気になったのは、「ソフトウェアを書いた人をもっと昇進で評価すべきだ」という提案です。これは地味に見えて重要です。研究者にとって、評価されない仕事はやり続けにくいからです。良いコードを書き、ドキュメントを整え、依存関係の面倒まで見る作業は、論文数に直結しにくい。その結果、誰も損をしたくないので、みんながコード整備を後回しにする。これは個人の怠慢ではなく、制度の問題です。
著者の議論は、ここで初めて現実に触れると思います。オープンソースが科学の理想だとしても、研究者のキャリア設計が論文中心のままなら、誰も本気では動けない。つまり、透明性や再現性を求めるなら、評価の物差しも変えなければならない。ここは非常に筋が通っています。科学を「公開された知識の集積」として守りたいなら、その知識を運ぶコードをきちんと仕事として扱う必要があるからです。
ただし、ここにも落とし穴があります。コード貢献を評価するといっても、何をどう測るのかは難しい。行数では意味がないし、スター数や利用者数だけでも危うい。研究コードは派手である必要はなく、むしろ安定していて当たり前という性格が強い。だから制度設計はかなり繊細になるはずです。それでも、今よりはるかにましな方向はあると思います。少なくとも、研究成果の説明にコードが含まれていないことを「普通」にしないこと。そこからしか始まらないのではないでしょうか。
正直に言えば、「科学はオープンソースソフトウェアそのものだ」と言い切るのは強すぎる表現です。科学には観測、実験、議論、批判、理論構築があり、すべてがコードに還元されるわけではありません。けれど、計算が研究の中心に入った今、コードを隠したままでは科学の一部が見えなくなっている、という警告はかなり重要です。著者の比喩は言い過ぎに見えて、実は現状認識として当たっている面がある。
私はこの文章を、オープンソース賛歌として読むより、研究の説明責任をどこまで拡張するかという問いとして読むべきだと思います。論文は結論を語る。でも、その結論がどの手順で出たのか、他人が再び動かせるのか、壊れたときに直せるのかまで含めて示せるか。そこまでやって初めて、現代の科学は「公開された知識」と言えるのではないでしょうか。
