タイムベースド作品の制作と保存（収蔵）について自分ができること
はじめに
ここ最近、タイムベースドなインスタレーション作品に携わることが多かったです。 そして、大変幸運なことにその作品のいくつかは収蔵、もしくは収蔵検討となっています。 そういった状況から、 「タイムベースド作品をどういったワークフローで制作し、それを収蔵させ、そして再展示させられるか」 というのが自分の中で課題になってきました。 その課題を解決するために、作家の横に座ってるテクニカルスタッフという立場から考えてみたこと、現場で取り組んでみたことを綴ってみました。
あくまで、いちテクニカルスタッフが一人で考えて取り組んだことですので、お手柔らかに。
- はじめに
- タイムベースドなインスタレーション作品の「再展示」
- 何を残せばいいのか、自分には何が残せるのか
- 作品の「立ち振舞い」であり「所作」の保存
- 「戯曲」の制作
- タイムベースド作品における「戯曲」とはなにか
- 「戯曲」の強固さ
- 「戯曲」の強固さを増すためには
- 「戯曲」の形式
- あれ、やっぱり簡単なことじゃないの？
- 「戯曲」の出自 - 手垢のついたxml
- いったん、まとめます。
- 現場は収蔵どころじゃない
- 現場：ソフトウェアについて
- 現場：ハードウェアについて
- 現場：作品の運営について
- さいごに
と、本文に行く前に。
文中にもありますが、より詳しい内容や歴史、そもそもタイムベースド作品ってなんやねんというのは、文化庁のサイトに大変詳細にまとめてありますのでそちらを御覧ください。文化庁すごい。
本文中におけるタイムベースドなインスタレーション作品の定義
「作品が展開されている空間において、時間経過とともに表現が変化し、それが繰り返される作品」と乱暴に定義づけておきます。
タイムベースドなインスタレーション作品の「再展示」
タイムベースド作品の制作に関わっているといつも「50年後、100年後、この作品はまた見てもらえるのかなぁ。」と、妄想します。
そう考えると、次に
- 「なにが残っていたら、この作品は展示させてもらえるのかぁ」
- 「どういう仕組みだったら、また展示させてもらえるのかなぁ」
とも、考えるようになります。
まあ、でも単純に考えて「残す」ことができれば何とかなりそうです。でも、何をどうやって残そうか？
何を残せばいいのか、自分には何が残せるのか
タイムベースドなインスタレーション作品にはいろんな要素が存在します。
たとえば、「オブジェクト／物」。
残すの、大変そう（笑）
錆びるし、燃えるし、シュレッダーにかかるし。 でも、これらの保存方法については数多の美術館やギャラリーが持っているので、 そこはあまり自分の仕事にしなくてもよさそうです。
そういった「誰かがやってくれそうな領域」を削ぎ落としていった結果、 最後に残ったのは、タイムベースド作品特有の要素である、 作品の「立ち振舞い」であり「所作」でした。
作品の「立ち振舞い」であり「所作」の保存
これは自分が触われる領域だなと直感的に思いました。 なぜなら、自分がバックグラウンドとしてもっている「演劇／舞台」を参照軸におくと、 これは「戯曲」のことだなと思ったからです。
とりあえず、この戯曲を残してみる仕事をしてみようと思ったのです。
「戯曲」の制作
演劇／舞台だと、稽古に入る前に戯曲がほぼ書き終わっており、それをベースに稽古場で役者とともに練り上げていき、本番を迎えていくというプロセスが存在します。 *1
もちろん、タイムベースドの作品の制作フローと舞台作品の制作フローは大きく違います。 参加した作品制作の現場では「香港の映画製作に似ている」と話したこともあります。
香港では台本はなく、口伝えで役者にセリフが与えられ撮影しているとのこと。 タイムベースドの作品もそれに近い部分があって、現場で初めて時間が組み立てられていきます。 作家の横に立って、口伝えで役者に出した指示やセリフをすぐにメモって戯曲化していくイメージで、 作家の指示をシーケンサー（時間にそって何かしらの表現をするためのアプリケーション）に記録させていきます。
タイムベースド作品における「戯曲」とはなにか
シェイクスピアやブレヒトなどの古典を「再演」するということは、 「戯曲」を、演出と役者が作品内の時間に沿って、なにかしらの表現を実行する。
となると、先程のシーケンサーがあるので、そのデータこそが「戯曲」とも言えるかもしれません。 あれ・・？実は深く考える必要がないのかもしれない。そのデータを残しておけばいいんだから。
「戯曲」の強固さ
ただし、各アプリケーションのデータは、それぞれに紐付けられており、 そのアプリケーションの開発が止まったり、動かなかったりすると、 「再演（再展示）」ができなくなってしまうので、個人的にはよろしくない。ダサい。
そのアプリケーションやデータがインストールされたPCを アップデートすることなく保存していく「一子相伝」みたいな伝承方法もあるんでしょうけど、 個人的には、制作方法や設計図だけが伝承され、定期的にリビルドされていく 伊勢神宮の式年遷宮みたいな伝承方法のほうがカッコいいと思ってます。理にかなってる。
「演劇／舞台」の戯曲のすごいところは、 作家はもちろん、演者が全員死んでしまってても、 当時使用していた劇場や舞台装置が燃えてなくなってしまっても 戯曲が書かれているメディア（つまり紙）を製造していたメーカーがなくなってしまっても、 再演可能であるということです。強い。
タイムベースド作品も是非この状態に近づけておきたいですね！
「戯曲」の強固さを増すためには
じゃあ、どうするか。 将来、パソコンのOSがすべてなくなってしまっても、 再現の可能性が担保できていればいいはずですよね。 担保されつつ、再現が容易、簡単そうであるともっといい。 簡単じゃないと、検討すらしてもらえなさそう。
ということで、タイムベースド作品の戯曲は、
再設置しようとする「人間（もしくはそれ相当の生き物）」が読めるもの（解読が容易）であり、 タイムベースド作品の根幹である「時間」という絶対的な次元に依った「読み物」であること *2
と仮定することにしました。 戯曲だからね、読み物でしょ、やっぱ。 ではどういった形式で書けば、それはタイムベースド作品の「戯曲」と言えるのでしょうか。
「戯曲」の形式
すごい大雑把に書くから、演劇／舞台の人たちは叱らないでほしい…。 まぁいまさら詳しく説明もできないけど。 それはさておき。
一般的な戯曲の形式は大きく分けて、 「ト書き」という、役者の動きや空間、時間の説明などが書かれている、「地」の文と、 役者が舞台上で話す「セリフ」の2つの要素があります。 それらが、「場」や「幕」というブロックごとに分けて構成され、 さらにそれらを積み上げることで、「物語」＝「戯曲」となります。 「場」や「幕」のブロック内では時間の流れは統一されており、 大きく時間が動いたり（たとえば、「三年後」とか、「夜が明けて」とか）、 場所が変わったりすると、違う「場」と「幕」となります。*3
ここで、重要視したいのは、基本の「ト書き」と「セリフ」です。
- 「ト書き」は場所と状況を説明（描画）
- 「セリフ」は表現
ト書きとセリフの順番で、時間経過を表します。
これに沿ってタイムベースド作品のシーケンスに落とし込むと、
（ト書き）1秒間を30分割したものを1フレームとして時間単位を定義する。 その13287フレーム目 （セリフ）スピーカー「ファーーー（音が鳴る）」
といった内容にできるはずで、 更には、先程から言っている強固さを持たすために、 これを人間が読んで理解できる「読み物」にしちゃえばいい。
あれ、やっぱり簡単なことじゃないの？
で、実はここまではそんなに難しくなくて、
なんです。
xmlやJSONを めっちゃ雑に説明すると、人間でも読み書きがある程度可能なデータ形式のこと。 バイナリといわれる「0と1」だけで構成されたデータではないので、読めます。
そうなんだよー、簡単なんだよー！
ただ、それが一体いつ作成されて、どう運用されていたかが 演劇史的にも美術史的にも、めっちゃ面白い問題になると思っています。 いや…、ただの個人的なこだわりなのかもしれない。
「戯曲」の出自 - 手垢のついたxml
たとえ話を2つします。 ふたつの話の中で扱われるデータはすべて同じデータとします。
［A］ ある作品が制作され展示されました。 そして、その作品の収蔵が決まったので、 シーケンスアプリからパブリッシュしたxmlファイルとともに収蔵されました
［B］ ある作品が制作され展示されました。 そして、その作品の収蔵が決まったので、 シーケンスの再生に使用していたxmlファイルとともに収蔵されました。
この話の相違点は、xmlファイルの出どころです。
これ、データ的には全くの等価です。作品の振る舞いも全く同じでしょう。 どちらのxmlを保存しても、作品の保管という意味では目的を果たせます。
しかし、収蔵が決まってからパブリッシュ（出力・書き出し）されたxmlはあくまで「あと付け」。 実際にそのxmlで作品が展開していたわけではありません。
この「実際に表現で使用されたデータであるかどうか」という事実が、 これまでの歴史を顧みても、のちのち重要になってくると予想します。
実際にソクラテスが書いたものなのか、 ソクラテスの弟子プラトンが後に書き起こしたものなのか、 どっちやねん！ といったような問題が発生する気がするんです。
めっちゃ細かいけど、伝わるかなこのニュアンス笑。
これを作家（と一心同体であるテクニカルスタッフ）が作成しておけば、 後の美術関係者がもめなくていいはず。 考古学者や専門家が独自の解釈を入れた戯曲とかに変容することなく作品の純度（？）が保たれるし、 これを元にみんなケンカしないでしょ。
という想いがあります。
あとは、単純に あとからパブリッシュして収蔵ていうのがかっこよくない。 作成して運用した手垢のついたxmlを収蔵したほうがかっこいい。
実際、xmlデータに出自の問題なんてないし、手垢の問題も、エイジングもかかりませんが 作品というか、美術っていうのは、そういった部分も語られていく傾向、可能性、 懐の深さがあるんです。 おもしろいですね。
いったん、まとめます。
タイムベースド作品の収蔵を検討するためには 時間の経過とともに展開される表現を記したデータを保存し、 かつ、それは我々人間が読むことができるものである必要がある。 さらに言えば、そのデータは実際に表現で使用されたものであることが望ましい。
（今回は書いていませんが、作品のシステム図や機材要件なども、もちろん作成します）
ふぅ。と、ここまで書いていろいろググったら 文化庁のページにまぁまぁ同じようなことが書いてあった！ので、 そちらを読んでください。（せっかく書いたのに・・・
ロジックの保存・修復 | タイムベースト・メディアを用いた美術作品の修復・保存ガイド
ここまでまとめてる文化庁ってすごい…。
さて。 確かにここまで書いたことは上記の文化庁のページに書かれてることと 大きく重なっていますが、文化庁には知りえないことがあります。 それは、実際の現場です！現場！
現場は収蔵どころじゃない
さきほどの文化庁のリンク先の文末に
「将来的に，再制作やバージョンアップがより確実な判断のもと行われるよう， これら統合的な作品ロジックの保全が望まれる。」
と書かれていますが、現場はそれどころじゃない笑。
現場では数日後には展覧会はオープンするし、作家もギリギリまで表現を作り込みたい。 収蔵？それよりも明日の15時には美術館のドアが開くんだ！
さらに、保全を検討しすぎるあまり、 「（保全のために）表現に限界を設ける」 「（保全のために）表現を創作する時間を短縮する」といったような 負担を作家にかけることも、もちろんできない。
なので、いままでと変わらない制作フローで、 完成と同時に収蔵を即座に検討できる状態まで持っていけるのがベストです。
しかも、自分の首を締めるかのように、 「収蔵するときには、実際に表現で使用されたデータであることが重要だ！」 なんてハードルを設けちゃったもんだから、もう大変！！！
なので、今回の現場では、 今までのワークフローを見直しつつ、 展示オープン直後に収蔵まで一気に持っていける制作環境を構築しました。
現場：ソフトウェアについて
ソフトウェアについては、 「制作フロー」と「展示フロー」を分けて考えました。
「制作フロー」では、自分が使い慣れているMacやアプリケーション（Maxなど）を使用し、 即座に作家の要望に答えられる環境を用意しました。 即興で役者が動けたり、音がポン出しできたりする環境ですね。稽古場の状態です。 ここで戯曲を作り上げます。
「展示フロー」では、制作で作り上げた戯曲（データ）を展示運営用のデバイスに移して展開させます。
この「制作フロー」と「展示フロー」の切り替えは いくつかのアプリケーションを作成することでほぼシームレスに実現できました。
現場：ハードウェアについて
基本は、「1人（デバイス）、1役！」
シーケンサー！音出力担当！モーター担当！照明担当！
これまで明確に分けてしまえば、極端に言えばデバイスの代わりが人間でもできます。
（ト書き）1秒間を30分割したものを1フレームとして時間単位を定義する。 その13287フレーム目 （セリフ）スピーカー「ファーーー（音が鳴る）」
の、音が鳴るというのをデバイスが再生させなくても、 人間が再生ボタンを押して再生でも再現はできるわけです。
1デバイス、1役。 これは、「制作フロー」で強い意味を持っています。 作家は稽古場では即興的にいろんなことを思いつきます。 そして色々な要素を足したり、引いたりします。 もしそれをすべてのパソコン1台に任せていくと限界を迎えてしまいます。 しかし、1デバイス1役としておけば、 新しい役目をもったデバイスを一台連れてきて、台本を渡すだけです。
作品の要素をモジュール化し、外部に出すことで 作家の要望を即座に叶えることができるようになりました。
「展示フロー」においても、音が出なかったら音担当のデバイスの調子が悪いんだし、 照明がつかないんだったら、照明担当がおかしい。 おかしい部分だけを交換しちゃえばすぐに復旧できます。 そこは要件さえ満たせば、MacでもiPhoneでもAndroidでもなんでもいいので、交換が容易です。
現場：作品の運営について
タイムベースドな作品は、さまざまなデバイスやPCなどいろんなものを使用する作品があります。 だからといって、作品の運営、つまり作品の起動や終了が難しいとなるのは好ましくありません。 作品を運用するのは、作家でもなくエンジニアでもなく、美術館のスタッフさんたちです。 作品を預かってもらう人たちに負担はかけたくないものです。
表現上、やむを得ない場合はしかたがありませんが、作品の運営は極力シンプルにすべきです。 これは、手順のミスによる作品の故障やトラブルを避けるだけではなく、 将来、作品の再展示に関して「運営が厳しそうだからやめておこう」と思われないためでもあります。 作品が愛されるのを邪魔する要素は、少しでもなくしておくべきです。
さいごに
様々なご縁で、収蔵までを見越した作品制作に立ち会うことだできたおかげで、 場当たり的に立ち会っていた作品制作の現場を見直すことができましたし、 自分のバックグラウンドを引っ張って思考できました。楽しい。
作品を制作するのは作家だけでできるのかもしれません。 ただ、作家だけで収蔵までを見越して作品制作に向かおうとすると、それはかなりの負担になるでしょう。 しかも、ギャラリーや美術館は要望はすれど、ここまで対応してくれそうにない。 だけど、テクニカルスタッフという謎の職能を持った数少ない人間ならばこれを引き受けることができそうです。
もちろん、タイムベースド作品はいろんな種類のものがあります。 ここに書いた方式で保存できる作品は限られています。 そういった作品に立ち会うことができたときには、また検討するし、 考えていきたいです。
追伸： 作品のプログラムの中で、ただ単純に乱数を発生させる一文を書いてしまうと、 戯曲として残ってしまうので、「こいつ、適当にランダム使っただけだな」という証拠が 星が消滅するまでのこるという感じがいいですよね。
