消えゆくコードアートを遺す：実行環境の固定と「再演」の保存設計

数年前に作ったp5.jsのスケッチを開いたら、音が鳴らない、画面が真っ黒、あるいはエラーだけが並んでいた。そんな経験から、自分の作品もいつか動かなくなるのではと不安を抱えている方は多いはずです。この記事では、ジェネラティブアートの保存を「動く状態を保つ」ことだけに限らず、「作品の本質を遺す」という視点も加えて整理します。ソル・ルウィットの指示書、実行環境の固定、美術館の再演の実践、そして寿命を受け入れる思想まで、順に辿ります。

デジタル作品が直面する「静かな風化」：ライブラリの更新とブラウザの変遷

コードアートは、壊れる瞬間がはっきりしないことが少なくありません。ファイルは残っていても、周囲の環境が少しずつ変わり、ある日気づくと動かなくなっています。この静かな風化には、大きく分けて三つの原因があります。

一つ目はライブラリの更新です。メジャーバージョンが上がると、関数の挙動や名前、非同期の扱いが変わることがあります。p5.jsでも1.x系と2.x系が並走する時期があり、古いスケッチをそのまま新しい版に差し替えると、同じ結果になる保証はありません。二つ目はブラウザの仕様変更です。2018年にChromeが導入した自動再生ポリシーによって、ユーザー操作なしに音を鳴らす多くのWeb Audio作品が、突然無音になりました。三つ目はWebGLからWebGPUへ向かうような、描画基盤そのものの移行です。

さらに外部依存があります。CDNのURL、Webフォント、外部APIから取得するデータは、作者の手の届かないところで消えるリスクを抱えています。2020年末のAdobe Flashのサポート終了は、プラグイン型の表現文化が丸ごと動かなくなりうることを示しました。その後、Rustで書かれたエミュレータのRuffleなど、有志や機関による救出が進みましたが、それは「後から誰かが拾ってくれた」から成り立った話です。

私たちが書いているJavaScriptも、同じ運命と無縁ではありません。まず、何が壊れうるのかを言葉にしておくことが、保存の出発点になります。

「楽譜」としてのアルゴリズム：ソル・ルウィットの指示書に学ぶ作品の本質

動かなくなる不安に向き合うとき、コンセプチュアル・アートの先達の考え方が助けになります。ソル・ルウィットは1967年の「Paragraphs on Conceptual Art」で、アイデアが作品をつくる機械になると書きました。彼のウォール・ドローイングは、壁に直接描かれ、展示が終われば塗りつぶされます。作品として残るのは、指示書と、それを実行する権利を証明する書類です。

この構造は、ジェネラティブアートとよく似ています。「ある規則に従って線を引く」という指示は、アルゴリズムそのものです。ルウィットの作品は、描き手が替わるたびに手の癖や壁の大きさによって、少しずつ違う姿で現れます。それでも同じ作品として受け止められてきました。作品の同一性は、特定の見た目ではなく、指示の側にあるという考え方です。

クリエイティブコーディングの領域でも、Casey Reasが {Software} Structures で、指示型の作品をソフトウェアとして読み替える試みを行いました。紙の指示がコードになったとき、実行する主体は人から計算機に移ります。ただし、指示が解釈を要する点は変わりません。

では自分の作品の「楽譜」は何でしょうか。ソースコードだけでは足りないことが多いです。何を表現したくて、どこまでが変えてよい要素で、どこからが変えてはいけない要素なのか。その意図を文章にしておくことが、コードと同じ重さを持ちます。README を作品の一部として書くという発想です。

実行環境を封じ込める：コンテナ化、Web標準、静的アセットによる保存の実践

概念の次は、手を動かす工夫です。方針は、依存を減らし、残りは固定し、記録も併せて残すことです。

まず、ライブラリはCDNから読み込まず、作品のフォルダに同梱するのが堅実です。どうしてもCDNを使う場合は、バージョンを固定した上でSubresource Integrityの integrity 属性を指定し、外部からの改変を検知できるようにします。

<script
  src="https://cdnjs.cloudflare.com/ajax/libs/p5.js/1.10.0/p5.min.js"
  integrity="（配布元が提示するハッシュ値）"
  crossorigin="anonymous"
></script>

乱数も固定します。p5.jsには randomSeed() と noiseSeed() があり、同じシードから同じ系列を得られます。

function setup() {
  randomSeed(20261009);
  noiseSeed(20261009);
}

ただし、シードを固定しても、GPUやドライバによってシェーダの浮動小数点の挙動が微妙に違い、完全な一致にならないことがあります。固定は万能ではありません。

次に、環境そのものを固定する方法があります。DockerなどのコンテナにビルドツールやNodeのバージョンを閉じ込めておけば、数年後の再ビルドがやさしくなります。展示向けには、特定バージョンのChromiumと静的ファイルを同梱し、オフラインで起動するキオスク構成にしておく手があります。ただしコンテナも、基盤となるOSやCPUアーキテクチャまで永遠に保証するわけではありません。

最後に、動かなくなったときの保険として、出力を記録します。代表的なフレームの画像、数分の録画、シードごとの出力サンプルです。これらは作品の代わりにはなりませんが、再演するとき「元はこう見えていた」という参照になります。ウェブ作品なら、Rhizomeが開発したConiferのようなウェブアーカイブ用ツールで、ブラウザ上の挙動を含めて記録する選択肢もあります。

美術館・コレクションはどうコードを受け止めているのか：修復と「再演」の現場

美術館の側は、この課題に長く取り組んできました。2000年代前半には、グッゲンハイム美術館などが参加したVariable Media Initiativeで、メディアが変わっても作品が保たれるよう、作者へ聞き取りを行う枠組みがつくられました。そこで問われたのは、作品を保存すべきか、エミュレートすべきか、移行すべきか、再解釈すべきかという選択です。

コードを含む作品の収蔵では、ソースコードに加えて、機材の仕様、設置手順、作者へのインタビュー、展示の記録を併せて受け入れる例が多くなっています。コードは文書や指示書の一部であり、それ単体で作品のすべてが完結するとは見なされないケースが一般的です。

象徴的なのは、ルウィットの壁画を扱う大規模な展覧会です。米国のMASS MoCAでは、2008年に25年間の長期展示として、ルウィットのウォール・ドローイングの回顧展が始まりました。壁画は指示書をもとに、アシスタントや学生たちが描き起こしています。人の手を介して作品を「演奏」し直すという実践が、美術館の日常になっているわけです。

ジェネラティブアートの再演にも、同じ姿勢が当てはまります。古いブラウザを再現するか、現在の環境へ移植するかは、作品によって答えが変わります。見た目の正確さを重視する作品もあれば、「いまの環境で動いていること」自体が意味を持つ作品もあります。この判断は、作者が生きているうちに言葉にしておくと、後の人が迷わずに済みます。

未来の鑑賞者に託す余白：作品の寿命そのものをデザインに組み込む思想

ここまで「どう遺すか」を考えてきましたが、最後に問いを反転させます。すべてを遺す必要はあるのでしょうか。ルウィットの壁画は、展示が終われば消えます。それでも作品は失われず、次の壁を待っています。消えることが、再演の条件になっているとも言えます。

この発想は、制作の段階から取り入れられます。たとえば、作品の仕様に「想定する寿命」を書いておきます。「この作品は、2026年時点の主要ブラウザで動くことを前提とする」と明記する。動かなくなったら、録画と指示書が正本になる。そう決めておくだけで、保存の目的が定まります。あるいは、劣化や変質を作品の主題にして、ブラウザのエラーやフォントの欠落が起きること自体を表現に取り込む手もあります。

もう一つ大切なのは、コミュニティの存在です。作品を理解し、動かし直せる人が複数いることが、実際には最も強い保存手段です。コードを公開し、制作のメモを残し、ライセンスを明示する。Rhizomeのようなアーカイブや、p5.jsのコミュニティが蓄積するスケッチ共有の文化は、そのための土壌になります。

今日できる小さな一歩は、いちばん大切にしている作品を一つ選び、フォルダにライブラリを同梱し、シードを固定し、短い録画と「この作品は何か」を書いた文章を並べることです。未来の誰かが、あなたの楽譜を手に、その作品をもう一度鳴らすかもしれません。そのとき彼らが受け取るのは、動くコードだけでなく、あなたの意図に触れる余白なのだと思います。