第7章 - 結論：音楽土木工学とは何なのか、どこへ向かうのか

とってかわるべきシステムとは、人間が自己の自由と創造性とを責任をもってひきうけるシステムのことである。 (アタリ 1983, p144)

本論文では、音楽のためのプログラミング言語の設計という実践を例にとりつつ、既存の工学的実践とは異なる学術研究として位置付けることを試みてきた。序章で既に述べたように、本研究は実践のなかで得られた思考を歴史的背景の描き方にフィードバックする循環的なプロセスを取っている。mimiumの実装についての具体的な記述を終えたいま、改めてその背景を振り返り、音楽土木工学という学問を打ち立てることにどういった意味合いがあるのかについて議論する。

7.1 歴史にけもの道を作るデザイン

第2、3章では学術研究としてのデザインリサーチの成立過程とメディアとしてのコンピューターの歴史を、どちらも1960年代ごろから現在まで並列して描いてきた。ここで、まずはその内容をまとめつつ、両方の歴史で相互に関連する内容を紐づける。

HCIやそこから派生したNIMEのようなコンピューターを用いた道具のデザインは、批評的デザインの文脈にも影響を受けつつ、RtDのような、実践の過程で問題が描き出されるような研究の方法論を形作ってきた。とはいえ、研究領域全体としてはいまだ客観性や問題解決主義の重視といった傾向の研究とも同居したままの状況が続いている。

特にPLfMに限らず芸術表現のための道具を作ることを研究とする場合、必ずしもその研究の価値は客観的に測れるものではなく、目的がはじめから定まっていることも少ない。そのため、たとえ作った内容の説明に技術的要素が多くあったとしても、その語り方としてIssue-Method-Result-and-Discussion的なフォーマットが適合するとは限らない。むしろデザインリサーチの方法論を借りることでその実践の存在意義を確認できる例は少なくない。

実際、デザイン研究者のヨナス・ローグレンは、デザインの研究における知の形として、強く一般化された理論と、個別のデザインされた人工物の間に様々な形の中間レベルの知があるのではないかという提言をしている(Löwgren 2013)。そして、ローグレンがその中で中間レベルの知として例に挙げたのはケイらのDynabookだった。確かにDynabookの研究は、見方によっては未完成であることがその研究の特徴とも言える。論文で示されたのは、近い将来可能になるであろうタブレット状のデバイスのモックアップと、机サイズのコンピューターでの多様なユースケースのプロトタイプだった。それでも、ケイが強いコンセプトという中間的な知——すなわち、メタメディアという、個人が自らのための道具を自ら作る将来の計算機の利用のあり方を打ち出したことで、後の研究や産業にも大きな影響を与えたのだった。

しかしながら、こうした中間的な知の創出を予め自覚して研究を行うのであれば、同時に自らの研究が持つ政治性には一層注意を払わなければならない。例えば、ケイがDynabookのようなパーソナルコンピューターを将来薄型タブレットの形状にできると確信した上でデザインプロトタイプを作った背景には、ムーアの法則による漸進的な計算機のサイズとコストの低下の予測があった。だが、ムーアの法則はゴードン・ムーアという半導体メーカーの人間による予測という形を取った社会への「期待」の浸透という側面も少なからずあるのだった。

これを踏まえるのであれば、ケイが打ち出したパーソナルコンピューターの姿は、ムーアの法則に基づく産業としての計算機の経済的発展、という期待をブーストさせるものとして働きはしたと言える。一方で、最終的に普及したパーソナルコンピューターの中からメタメディアとしての可変性は段々と薄れていくことになり、期待のブースターとしていいように使われてしまった面も否めない。この原因の1つは、ケイらがムーアの法則などを背景とした未来の姿を打ち出しつつも、消費経済における商品としてのコンピューターの流通や、あるいはパーソナルコンピューター以降の経済システムの在り方そのものはあまり考慮しなかったことにあると言えるだろう。同様に今日あらゆる種類の道具を作ることを研究するにあたって、最先端の技術（Emergent Technologies）を用いるものは常に、その技術が発展した先や、自らの研究がもたらす影響についてより自覚的になる必要がある。

そのため本論文で着目したのは、デザインリサーチの中でも未来ではなく過去に目を向けるアプローチと、既に所与のものとされてしまっているインフラストラクチャに目を向けるアプローチであった。ロスナーの批判的奇譚作りやメディア考古学的制作のように、これまで歴史の中には記述されなかったものに着目するデザインは、あり得たかもしれない現在の姿を描き出すことで、そもそもなぜこの人工物のデザインが今の社会や文化に必要なのか、わたしたちはどこへ向かうべきなのかという研究の背景を構築するための手がかりとなる。

同時に、普段は不可視なインフラストラクチャに着目することは、（高らかに宣伝される最先端技術ではなく）既に日常に定着してしまったテクノロジーの使い方を見直すきっかけを与えてくれる。特に、プロトコルやフォーマットといった情報インフラは物質的な実態を持たないがゆえに注目を集めにくいが、表現を思考や認識レベルで規定するものとして働くために、なお一層批判的目線で捉え直す必要があるのだ。

また、この過去への視座とインフラストラクチャへの着目は、研究者だけでなく、テクノロジーを意識的に用いる芸術実践としても必要になってくる要素である。1960年代のアート&テクノロジーのムーブメントでは、大企業の資本や専門的技術者のコラボレーションがこれまで不可能だった様々な新しい表現を可能にした。しかしそれは、例えば万国博覧会では直接的に商品の宣伝を行えない決まりの中、企業がその力をアピールするための手段として芸術家の力を借りることと表裏一体でもあった。それゆえテクノロジーを用いるアーティストは、1970年代の環境危機とともに企業を含めた消費社会全体との付き合い方の見直しを迫られたのである。そうした反省を踏まえて、こうしたテクノロジーアートの実践には最新テクノロジーを無批判に受け入れることへの警戒と、批評としての意図的なテクノロジーの誤用のような態度が身につけられてきたのだった。

だが、本研究ではここからさらに、テクノロジーを用いる芸術実践において単に批評的目線を持つことや意図的な誤用だけでは未だ不十分であるという付け足しを行う必要がある。なぜなら、テクノロジーを誤用するということは、暗に現時点における「正当な」テクノロジーの存在を追認することにつながるからだ。

人工知能やメタバース、NFTといったテクノロジーを批判的に用いることで、芸術家は社会や芸術にとってそうした技術に関する問いを提示し、議論を巻き起こしてくれるかもしれない。しかしそこで行われる議論は常に、どこかの大企業や研究所、あるいはサトシ・ナカモトのような、テクノロジーを生み出す知らない誰かによって外部からもたらされている状況でもある。その状況では既に、与えられたものに対して必要か否か、オルタナティブは何か、といった受動的な反応しかできない。その時「人工知能」や「メタバース」と言った鉤括弧付きの言葉に当てはまる、根本的なテクノロジーを自らの手で生み出すことができるという想像力は奪い取られてしまっているのだ。言い換えるならば、アーティストは社会の中で外部からやってきたものに対して抗体として違和感＝アレルギー反応を引き起こす。だが裏を返せば、常に何かが外部からやってきた後にしか反応できない。わたしたちはテクノロジーを積極的に活用したつもりになっていて、その実誰かが生み出したより根本的なテクノロジーに脊髄反射を引き起こしているだけではないのだろうか？

テクノロジーの誤用によってその可能性をより広げるというアプローチや、ダンとレイビーがスペキュラティブ・デザインで掲げたような（そして元々はサイモンが「システムの科学」で提言したような）、「世界をより好ましい方向へ近づける」という未来への指向は、どちらも近傍探索にしかなりえないという意味で共通している。だが、もっとも好ましい未来が必ずしも近傍に存在しているとは限らない。こうした近傍探索的アプローチと、本研究の考え方の違いを表したのが図 1である。

過去への探索を行うことで、わたしたちはありえたかもしれない現在（Alternative Present）の社会の姿を想像することができる。その、ありえたかもしれない現在へと向かうための具体的行動としてのデザインこそが、音楽土木工学という学問の本質—舗装された道の間にけもの道を作ることである。それは、現在のテクノロジーの使われ方から見れば単なる誤用に映るかもしれないが、より遠くの具体的な目標へと向かうための行動かどうかという点で異なっている。

7.2 プログラミング言語のメタ性が産む分業体制

本論文後半で筆者は、第4章で通時的整理、第5章で共時的な整理を、第6章ではmimiumという具体的な言語の実装を通じてPLfMの存在論の再検討を試みてきた。その中で得られた視座をまとめると以下のようになる。

ひとつは、音楽を含めた、時間を取り扱う計算モデルの思案の不足である。

電子計算機を用いた音楽の生成は、音響遅延線メモリーのような既存の機能を流用することで始まっていた。またMUSIC Nのような今日までの音楽の計算モデルの基礎になった試みも、伝統的な音楽様式や現実世界の装置とのメタファーを活用することで、既存の表現との接点を保ちつつも新しい表現の余地を残す設計になっていたのである。しかしそうして作られたUGenモデルは、リアルタイム動作などの要請からハードウェアとして物理化され、計算モデルそのものの考案という作業は2000年代に入るまで積極的には行われてこなかった。ChronicやFaust、Kronosのような言語の研究によって、PCMベースのより根源的な計算モデルの探究は進んだ。mimiumもまたこれらの言語の知見を取り入れたものである。それでも、離散的に発生するイベントとPCMベースの抽象化両方をうまく統合するモデルはいまだ提示されていない現状がある。SuperColliderクライアントを中心としたオルタナティブな抽象化を試みた言語も、その下層のレイヤーにはUGenのような信号処理モデルの存在を予め前提にしてしまっている。

実際、例えばパケットは2015年のICMCでの発表で、信号処理のような低レイヤーの抽象化であっても、そもそもPCMを処理する以外にもコンピューターで可能な音圧波形、音声の抽象化方法はあり得るのではないかという問題提起をしている(Puckette 2015)。パケットはPCMと同じように音圧波形を記述/生成することを目的とした場合にも、音圧を時間ごとに均等に区切る以外の、例えば直線を時間軸上に配置するようなデータ表現などもあり得るのではないかと提案する。ここで重要なのは、直線の折れ曲がりの頂点部分には理論上無限に高い周波数成分が含まれていることである。PCMの方式で一見折れ線に見える波形を描いたとしても、それが実際に再生されるときにはサンプリング周波数÷2を超える高周波成分が折り返し歪みとして現れる。この直線の集合データ構造を直接的に何かしらの電気回路を用いて再生できるのなら、PCMでは完全な再現が不可能な音声信号を作ったことになる。

あるいは、音圧波形を直接的に離散化するのではなく、音を生成する楽器に相当する微分方程式などの数学的モデルを組んでから、そのモデルを離散化するというのもコンピュータープログラミング言語に可能な抽象化のひとつのはずである。実際、SPICEのような電気回路のシミュレーターなどのためのDSLは、宣言的に電子回路の部品接続を記述することで、等価な数学的モデルを構築し、自動でその微分方程式を離散化する仕組みになっている。パケットも講演内で、生徒の1人であるアンドリュー・アレンが作ったバネ・マス・ダンパーをグラフィカルに接続することで物理的特性にのっとった音再生ができるインタラクティブなアプリケーションRuratae(Allen 2014)を引用し同様の主張を行なっている。極論を言えば、バネ・マス・ダンパー同士の接続パラメーターが記述されたソースコードをもとに、物理的にバネ・マス・ダンパーを構築するようなデジタルファブリケーションシステムが作られたとすれば、それはPCMやMIDIとは異なる形のコンピューター音楽と言えるのだ。

もちろん、物理シミュレーションベースの信号処理も、例えば打楽器のような面の振動、3次元の振動体の振動などのモデルは、時間軸だけでなく空間方向にも離散化が必要になり、その結果必要な計算コストが飛躍的に増えるといった問題もある。しかしここで重要なのは、物理的な楽器の完全再現ができるかどうかではない。それよりも、連続時間領域で数学的モデルを組み合わせていくことも、コンピューターを用いた音楽表現においてあり得る抽象化の方法のひとつであり、そこにはPCMベースの処理で音圧波形にあれこれエフェクトをかけたりするのと同じかそれ以上の探索空間があるのではないか、ということだ。かつその探索空間は、Pilot ACEの音響遅延線を流用した独特な音楽における探索空間や、マシューズが開発していたGROOVEにおける制御信号の探索空間がおそらくはMUSIC Nとは全く違う探索空間を持っていたように、PCMベースの処理では容易にたどり着けなかったものなのではないだろうか。

こうした、そもそもの音声生成の計算モデル自体の考案や、言語の意味論自体の設計という作業はコンピューターを用いた音楽表現の探究において根本的なものであるにもかかわらず、それに取り組む人口は増えていない。

そうした理由を説明するのが、2つ目の視点、PLfMに関わるインフラストラクチャの影響である。前述のパケットの折れ線の組み合わせによる音声合成は実際に動くシステムとしては提示されていない。そして、例え折れ線データ構造をアナログ電圧に変換する特殊なD-Aコンバーターが作れたとしても、どのみち多くの現存するコンピューターにはこの特殊なD-Aコンバーターは搭載されていない。そのため、折れ線データ構造はオルタナティブな抽象化方法たりえるものの、表現を媒介するフォーマットとして機能することは難しいと言える。同様に、離散的なイベントの記述を含めた抽象計算モデルが考案できたとしても、プリエンプティブスケジューリングなどの仕組み上多くのコンピューターではその正確なタイミングの制御を実際のシステムに落とし込むにあたって何らかの妥協が必要になる。これは3章で見てきた、想像できたとしても作ることができない状況に相当するものなことがわかるだろう。

またインフラストラクチャの誘導や制約と同時に、3つ目の視点である分業化の傾向もまた、抽象計算モデル自体の思索から人々を遠ざけている。PLfMは1980年代のIRCAMの分業体制のように、音楽家がコンピューターを簡単に扱えるようエンジニアがシステムを構築するといった、いわば音楽家をユーザーにする方向へと進んできた。mimiumの実装を通じて筆者は、このような作曲をする人、楽器を作る人、楽器を作るための道具を作る人……といった細かい分業体制が生まれないような、なるべく既存の音楽様式を言語に埋め込まない最小限の抽象化モデルの考案を試みた。それは、ケイが目指したメタメディアとしての計算機の利用方法とも理想を共にするものであり、ケイが参考にしたシーモア・パパートがプログラミング体験において重視していた「天井は高く、床は低く」¹という、初心者にとっては直感的な記述ができ、かつ上級者は高度な抽象化が行える対象の広さを目指していたこととも共通した問題意識を持っていた。例えばこれまで、CSoundにおけるScore—Orchestra—Instrumentのように、抽象化のレイヤーごとに言語を作っていたMulti-Languageパラダイムを、mimiumという言語上でのライブラリ実装という作業にすることができれば、元々あった言語間のギャップは埋まっていく。

しかしmimiumの実装過程で最終的に実感させられたのは、言語自体の汎用性を高めると、肝心のその言語の処理系実装そのものはほとんどテキストデータを読み込んでより抽象的なデータ構造へと変換していくデータ変換器になってくるため、そこにはもはや音楽に関連する話題などほとんど存在しなくなることだった。階段のギャップはなだらかになったが最後の一段だけが飛び抜けて高い、といった切断を引き起こしてしまう矛盾が根本的に存在するのである。

この状況を説明した図が図 2と図 3である。まずいびつな階段モデル（図 2）が各ドメインごとに使う言語を分ける、現状のMulti-Languageパラダイムに基づく言語の使用と開発においてそれぞれの経験の差が発生していることを概念的に表したものだ。（なおScore-Orchestra-InstrumentはMUSIC NやCsoundで用いられた用語だが、MaterialやAtomはあくまでメタファーとして独自に用いている）。言うなればInstrumentというUGenをC言語などでプログラミングする作業がMaterialレベルのプログラム、さらにC言語のコンパイラそのものを作るような作業がAtomレベルのプログラムとでも表現できる。一方、突然急になる坂モデル（図 3）がmimiumやKronosのようなブラックボックスを減らし、ライブラリとしての実装の役割を広げた言語に対応する。天井と床、つまり高レベルの抽象化と低レイヤーへのアクセス可能性は広がっているし、各言語間に存在した差異もなだらかになっている一方、言語を作ることそのものの難易度は、音声信号処理に関わる知識も求められるために、C言語など汎用言語よりも多くの理論的背景を必要とし難易度が高くなってしまう。

つまり、音楽のためのプログラミング言語を作るという作業は、ひとつの言語の表現力を高めていこうとすると最終的に「音楽のためのライブラリを作りやすい汎用言語を作る」と「その言語上でライブラリを作る」という2つの行為へと分裂してしまう。そして、両者で求められるスキルや関心も大きく異なるものとなってしまい、ある意味ではMulti-Languageパラダイムよりも一層分業化を進めてしまうのである。

それゆえ、音楽のための道具を自らの手で作れるような環境づくりに、音楽様式をなるべく埋め込まないようなPLfMの設計は必要であるとはいえるが、それだけでは必要十分条件にはならない。どのみち、メタメディアとしてコンピューターを利用するためには、ユーザー（プログラマー）がコンピューターという装置の仕組みや、プログラミング言語がどのように動いているかを理解する必要が出てくる。

もちろん、プログラミングを始める前からコンピューターやプログラミング言語という道具の仕組みを理解できる人など存在しない。しかしそれでも、PLfMを使う過程で、各言語のユーザーとしての熟練と卓越（Maxの数多存在する組み込みオブジェクトの細かい仕様を覚える、など）ではない、コンピューターやプログラミング言語そのものの仕組みにも徐々に興味を持ち、それを自らの手で改造したりゼロから別のものを作り始めてしまうような誘導が求められるのである。

どのみち、単にプログラミング言語を作っただけでメタメディア的技術環境が実現することは無い。それだけでなく、もっとコミュニティの形成や学問体系、さらには道具や技術を使うことに対する根底の認識を変えるような、広い視点での能動的行動（文字通りの、Activism）が必要とされるのだ。

それこそが、筆者が本研究を単にPLfM研究のこれまでとは異なる文脈作りとしてでなく、音楽土木工学というより広い意味での芸術と工学の関わり方の再考として提示する直接的な理由である。

7.3 カモフラージュとしての音楽土木工学

筆者はmimiumの設計や実装のための情報収集の中で、趣味や研究、仕事で自作のプログラミング言語やその処理系プログラムを作るコミュニティとの接点を得ることができた。例えば大学のなかでも情報系の学部では簡単なプログラミング言語の処理系の作成が課題として出されることも珍しくはない。加えて、オンライン上で閲覧できる言語処理系実装のチュートリアルも充実しつつある²。しかし、例えば1000人以上の参加者がいる「プログラミング言語処理系が好きな人の集まり」というコミュニティ³の中でも、音楽に特化したプログラミング言語は、そういう目的のものが存在していること自体知るものはほとんどいなかった。

ほかにも、今日（2022年1月）、ソースコード共有サービスGitHubにおいて、「Programming Language」と検索すれば、その規模に大小はあるものの87502のリポジトリが出てくる。この中には大学の課題で作った処理系プログラムの延長線上にあるものを一応でもアップロードしているようなものも数多く含まれる。それに対して、「Programming Language Music」では137しか出てこないことからその探究の規模の小ささがわかる。実際、第4章の歴史を振り返っても、年を追うごとに時代ごとの開発者の数が増えているかといえば、微増はしているものの頭打ちといった状態だ。それだけでなく、PLfMの開発には汎用言語の処理系ではたくさんいたはずの、言語処理開発それ自体を生業としているわけではない人たち、つまりアマチュア開発者の数が圧倒的に少ないのだ。

クリエイティブ・コーディングと呼ばれるような運動で用いられるような、音楽や芸術表現のためのプログラミング環境（ProcessingやopenFrameworksなど）は、一部の専門家のための特殊な行為としてのプログラミングを芸術家のような、（工学に関しては）アマチュアである人たちへ裾野を広げることに重きを置いてきた。これはMaxやPure Dataも含め多くのPLfMに関しても共通するところである。しかし、誰もが自らの道具を自分で作れるようなメタメディア環境を実現するためには、実は芸術家へプログラミングという行為の裾野を広げるのと同じように、プログラミングを専門とする人（≒芸術や人文学のアマチュア）にも言語処理系開発の知識を活かせるフィールドがある、という方向で裾野を広げる必要性がある（あった）のではないだろうか。

では、クリエイティブコーディングのように芸術とプログラミングが無関係でないことを、その逆、工学のコミュニティにも自らの作るシステムが芸術のような分野とも無関係でないと広く知らせていくためにはどういった方法を取れるのか。その暫定解こそが、工学の皮を被ることによる、カモフラージュとしての音楽土木工学なる存在しない学問の確立である。

序章で説明したように、音楽土木工学を表面的に説明するのならば、それは音楽のために基礎的なテクノロジーや情報インフラストラクチャ自体を作り直すような学問と言える。それは、筆者のような技術実践のバックグラウンドを持つものが実際にエンジニアになってしまうことで、音楽家や芸術家に対して、先端技術を自らの分野へ応用するだけがテクノロジーとの唯一の付き合い方ではないことを知らせるためのフレームワークという側面も持っている。

しかし同時に音楽土木工学には、エンジニアに対しても、自らの技術がいつか応用されるだけのニュートラルなものではないと言うことを知らせるためのアクティビズムとしての側面もあるのだ。エッカートの、自らの楽しみや身の回りの人の楽しみのために行ってきたティンカリングのバックグラウンドが音響遅延線メモリーのような計算機のための技術へ直接的につながったように、コンピューターやプログラミング言語を作ること自体、直接的には音楽や芸術に関わる要素が一見ないように見えても、それは分かち難く芸術実践の一部なのである。

ただ、筆者はここでスモールのミュージッキングの概念をいたずらに延長し、「あらゆる工学的実践は音楽である」というように、音楽の存在論を拡散させようとしているのではない。スタンスの違いを明確にするためにスモールの主張を一部引用しよう。スモールはミュージッキングという行為を以下のように、他者との関係の間に構築される現実の中で、既に社会や文化の中で共有されている音楽の概念や言葉とは違う形で、プリミティブなものとして受け入れることと説明する。

「私たちは何者なのか」は、「私たちはどう関わるか」にかかっている。私たちが誰かを同定（アイデンティファイ）しようとすれば、私たちはその人物の他者とのつながりを知る必要がある。私たちの関係こそが、私たちを同定するのだ——アイデンティティの変容は他者との関係の変化を意味するし、反対に、関係が変わればアイデンティティも変化する。だから、気の合う者同士がミュージッキングを通して互いの結びつきを確認し、祝うことは、「私たちが誰なのか」という感覚を探り、祝うことに他ならない。そうすることで、もっと充実した形で自己を感じることができる——要するに、それは気持ちがいいのだ。私たちは、すべての不要なものごとを捨て去ったところで、「これこそが世界の本来あるべき姿なのだ」と、「この世界こそ、私たちが本当に属する場所なのだ」と感じる。そこで私たちは、ほんのしばらくの間とはいえ、あたかも理想の世界に、正しいつながりに満たされた世界に住むことを許される——いや、あたかもではなくむしろ、まさにそれが実現しているというべきだろう。(スモール 2011, p270、強調は原文に基づく。)

この一節では、他者との関係の中でアイデンティティが形成される、構築主義的な面が押し出されている。しかし同時にミュージッキングという、社会に規定される前の音楽的行為がまるで純粋かつ唯一の真理として存在しているような普遍主義的側面も同居しており、座りの悪さが残る。「すべての不要なものごと」や「本来あるべき姿」とは一体なんなのだろうか。気の合うもの同士が互いの結びつきを確認し祝うことは、第3章で見てきたように、結局は同質性を呈する記号的循環をもとに、MIDIやUGenといった音楽的様式をそれ自体に埋め込んだインフラストラクチャを生み出してしまうのではないだろうか？

音楽土木工学における、工学的研究をも音楽実践のうちに捉えるという考え（あるいはその逆に、芸術家が実際にエンジニアになってしまうこと）は、自己の輪郭をはっきりさせる、充実感を伴った祝福のために行われるのではない。むしろ、「ここは世界の本来あるべき姿ではないかもしれない」という、所在の無さや不安、違和感、不快感を起点にして、けもの道の先にある異なる現実へと向かっていくためのアイデンティティや社会規範的役割の再破壊のために行われるのだ。

なぜなら、「Xもまた音楽的行動である」という肯定には、「Yは音楽的行動ではなかったのかもしれない」という、デミュージッキング（Demusicking）とも言うべき自己反省も対になって然るべきだからである。IRCAM 4Xが軍事用途でしか商用化されなかったように、芸術実践のつもりで行ってきたことが戦争、監視、管理統制のような、人間の自由と安全を脅かしうるものへと回収されてしまうことすらあるのだから。

ここまでの議論をまとめると、音楽土木工学の実践のために重要な視点は、既存の工学と音楽の関わりと対比において、以下の4つにまとめられる。

1. イノベーションではなく、使用中（Not an Innovation but In Use）
2. 応用ではなく、基盤と周縁（Not an Application but an Infrastructure and Marginal Area）
3. 誤用ではなく、ありえたかもしれない現在へけもの道を通す（Not a Misuse but Making an Wild Path to Alternative Present）
4. 専門家同士のコラボレーションではなく、別の役割に変化する（Not a Collaboration between Experts but Becoming Transformed into Other Role）

ある日突然やってくる革新的なテクノロジーは確かに音楽の未来にも大きく影響を与えるものかもしれない。だがしかし、そもそもわたしたちが今使っている音楽のための技術環境は本当にまともなのか、それを一度立ち止まって考えることもまた必要である。これが、イノベーションではなく使用中という視点の転換だ。

そして、わたしたちの音楽や芸術実践を左右する技術環境とは、メディウム、フォーマット、プロトコルと大抵地味で着目されづらいものである。だがそのように見えにくくなることこそが思考のフレームを形作る作業の一端である。それゆえ、こうしたインフラストラクチャを一体誰が誰のためを想定して作っているのかに関しては常に批判的検証と再構築の試みが必要である。これが、応用ではなく、基盤と周辺という視点の転換である。

しかし再構築をすると言っても、こうしたインフラストラクチャは大抵時間をかけてゆっくりとしか変化させられないものだ。それだけに、長期的目線を持って、（例え実際にはその都度状況と批判的検証に応じて方向修正が為されるとしても）予めどこへ向かうべきかを認識しておく必要がある。それが、誤用ではなく、ありえたかもしれない現在へとけもの道を通すという考え方である。

そして、専門家としての卓越と分業化はこうしたインフラストラクチャの形成がもたらす他の領域への影響、あるいは自らの専門に暗黙的に作用しているインフラストラクチャの存在へ気づくことを妨げる。そうした状況での専門家同士のコラボレーションは、むしろ既存のインフラストラクチャの無批判な強化へとつながりかねない。そうではなく、それぞれの専門家が他の分野のアマチュアになることが必要になる。ここでいうアマチュアとは、必ずしもその領域への知識が少ないという意味ではない。アマチュアリズムとは、芸術家が実際に技術者になってしまったり、技術者が芸術家になってしまうように、別の視点を持つ誰かへと実際に成り代わってしまう流動性を持つ者である。

音楽土木工学とは一見、音楽に関わる根本的なテクノロジーの見直しという具体的研究対象を持つ学術領域に見えるような語ではある。しかし実際には音楽土木工学とは、メディア考古学と同じように、またダンとレイビーがクリティカルデザインについて注釈をつけているように⁴、手法（method）というよりも、どちらかといえば態度（attitude）の問題である。

こうした要点を絞った行動原理を作ることは、たとえばリッテルの提起した意地悪な問題が表面的に10箇条だけが抜き出され浸透し、自己反映性という共通した観点が十分に理解されないままでいるように、形骸化の危険性が常に付き纏うことには注意しなければならない。

別の例では、ダンとレイビーが『スペキュラティブ・デザイン』の冒頭で、A（ふつう理解されているところのデザイン）とB（私たちが実践しているタイプのデザイン）とを見開きで並べ、「肯定的/批評的」「問題を解決する/問題を発見する」と言った22項目の対比を提示している(ダン and レイビー 2015, p6〜7)。しかし、これも同訳書の監修者でもある久保田が「AではなくBを行おう、という提案というよりもむしろ、Bを提示することによって、AとBとの間に緊張関係を作り出し、その中で対話し、議論し、提案しよう、というものだといえる」(久保田 2021)と注意を促すように、あくまで現在主流になっている考え方との対比においての緊張関係のなかでその機能を持つものとして理解されるべきだ。

同様に、上記の音楽土木工学の4つの考え方は現時点での音楽と工学の関わり方で支配的になっている考え方に対して意図的に距離を置くものである。そのため、音楽と工学の関係性の変化に従ってこの対比もまた柔軟に変化させていくことが求められるだろう。

7.4 音楽土木工学の今後の研究課題

最後に、この音楽土木工学という学問の確立のために今後あり得るだろう研究や必要な探究を、本研究の不足点への反省も交えつつ議論し、今後の課題とする。

7.4.1 コンピューター音楽の実践的歴史研究の必要性

第2章で述べたとおり、第4章におけるPLfMの歴史の批判的検証は、一次資料の新たな発見よりも既存の資料の再編成に重きを置いていた。それゆえ、既にある文献を繋ぎ直すという形を取ることで、既存の視点とは異なる描き方をしてはいるものの、依然として大学や研究所、企業、そこで活動していた人を中心とした描き方にならざるを得なかった。これは、ロスナーが批判的奇譚づくりで特定の個人のストーリーに基づく技術史観へ警鐘を鳴らしたように、今後の音楽に関わるテクノロジー史の批判的再構築における重要な課題と言える。

特に、すでにハードウェアが現存していないシステムについては論文やマニュアルの内容を基にしか記述できず、実際のところどう動いていたのかという実践的な知識に関しては多くは検証できていない。たとえばMUSIC Vのプログラムは後にショットステッド（Common Lisp Musicの開発者）によりgfortranで書き直され、ラッザリーニによりソースコード共有サイトGitHub上で公開されている⁵。 しかし、MUSIC Vが実際に使われていた当時の、プログラムを1行ごとにパンチカードで打ち込んでいたようなプログラミングのプロセスと、数分の音声ファイルを作るための計算にかかった数時間という長さを考慮せずにMUSIC Vについて本当に理解したと言えるのだろうか。まして、音響遅延線メモリーの仕組みを活用して作られていた1950年代初頭の音楽生成など、エミュレーターを用いてもそのメモリの時間遅延は再現されないため、ハードウェアを再構築しない限り再現不可能である。

ソフトウェアの独立性が高まった1990年代以降のシステムでさえも、OSのアップデートや依存するライブラリの開発停止など、当時の環境を実際に体験することは難しい状態が続いている。PLfMがトップダウン的な画一化や規格化から反発し多元的になりつつある今日、皮肉なことにむしろアーカイブを難しくする状況は逆説的に加速しているとさえ言える。

特段新規性のない車輪の再発明も、音楽土木工学においては推奨されるべき行為である。しかし、過去の資料へのアクセス性が無くなってしまえば、自分の発明したものが車輪だったことにさえ気がつけなくなってしまう。そのため音楽土木工学には、PLfMに限らず、過去の電子楽器や様々な音楽とテクノロジーの交差する試みの実践的な知へのアクセス可能性を確保するための行動が必要となる。

7.4.2 フォーマットとしてのPLfMの再考

第4章で見たように、1990年代以降にソフトウェアベースのリアルタイム音声合成が可能になったことによって、PLfMには単なる制作の道具としてだけでなく、音楽を届けるためのフォーマットとしての側面も現れてきた。しかし、トップダウン的に作られたSAOLのような標準規格は結局ほとんど普及することなく、ボトムアップ的に自然発生したSuperColliderにおけるSC140のような短いコードとしての音楽流通も、ライブコーディング文化の隆盛とクロスフェードするように陰りを見せている。だがFaustやKronosなど、より細かい粒度での形式的抽象化の研究が進んだ今、改めてPLfMのソースコードを音楽を配布するためのフォーマットとして機能させるような利用可能性は無いのだろうか？

実際、この問いはPLfMとは一見関係無い分野の発展も踏まえ、改めて考える必要があるものになりつつある。それは、空間音響のためのオブジェクトベースドフォーマットの存在である。オブジェクトベースドオーディオとは、映画館のような、建物ごとに異なるスピーカー配置がされている中で空間音響の定位、をより明瞭にするため作られたフォーマットの1つである。そのフォーマットは、スピーカーごとに割り当てられた音声だけではなく、モノラル音源と3D仮想空間上の時間とともに変化する位置のメタデータを組み合わせた形式を取っている(白柳 2017)。このオブジェクトベースドオーディオを採用したフォーマットとして最も有名なものがDolby Atmosと呼ばれるフォーマットである。Dolby Atmosは近年では映画だけでなく音楽ストリーミングサービスにおける配信でも採用され、ヘッドトラッキング（頭の向きをセンサーで検出する）機能やバイノーラル処理⁶を持つヘッドホンと組み合わせると、頭の向きに合わせて音源の向きがインタラクティブに変化するような聞き方も可能になっている⁷。

このオブジェクトベースドオーディオの特徴として、空間座標メタデータをもとにスピーカーへの割り振りやバイノーラル処理を行うアルゴリズムによって、その音色も著しく変化する点がある。これまでの2chオーディオや、5.1chのようなチャンネルベースドサラウンドのフォーマットと比較しても、明確な「原音」にあたるものが存在していないのである。SAOLのように、セマンティックな音声のデータを送信するフォーマットの性質にもかなり近いものを持っているとも言える。問題になってくるのは、仮にこのようなオブジェクトベースドオーディオが普及していったとすると、そこには便宜上の「原音」という参照地点がないが故に、これまで以上にフォーマットが生み出す表現と思考の制約が強まるのでは無いかということである。

こうした原音に忠実であることを必ずしも目的としない生成的なフォーマットは他の分野では、たとえばビデオゲームのための音楽のようなノンリニアなフォーマットで既にインタラクティブ性を活かした作曲の技法などが確立しつつもある(Sweet 2014)。しかしこうしたインタラクティブミュージックは、ゲームに特化したオーディオミドルウェア（ゲームエンジンのなかで動作する音声合成エンジンとそのためのオーサリングツール）によって作られることがほとんどであり未だPLfMとの接点は少ない状況にある⁸。

こうした、音楽の構造を記述したデータを解釈しデコードする形で音楽を生成する考え方が普通になりつつある現在、SAOLのように特定の抽象モデルへのロックインがなくなるように注意を払う必要はあるものの、音楽を配布するフォーマットとしてのプログラミング言語のソースコードという発想には改めて探究する余地があるのではないだろうか。

mimiumを音楽配布のためのフォーマットとして用いるための構想の1つとして、パッケージマネージャの機能を活用することが検討されている。パッケージマネージャーとは、ファイル単位での機能の分割と再利用を行うライブラリの概念を拡張した、オンライン上に存在する様々なライブラリとその依存関係、バージョン情報などを設定ファイルから一元的に管理できるようにするシステムである。Pythonのpip、Node.js（JavaScript）のnpm、Rustのcargoコマンドをはじめとして、現代で使われている多くの主要な言語で使われている機能であり、予めパッケージマネージャの存在が言語設計や実装の中に織り込まれていることも珍しくなくなってきている。

PLfMでパッケージマネージャーに相当する機能を持っているものとしてはMax（バージョン7以降）やPure Data（バージョン0.47で導入されたdeken）があるが、テキストベースの言語ではいまだ採用された例はない。ここで期待できるのが、PLfMに関してパッケージマネージャーを導入すると、ネットワーク上に点在するライブラリの管理とほぼ同じ機能の使い回しで、オンライン上に存在する音楽が記述されたソースコードを実行し、音楽を再生する音源配信プラットフォームとも言える機能が作れることだ。

もちろん、現実的にはセキュリティ面のリスクへの考慮などが必要にはなるが、音楽の再生（あるいは実行/演奏＝PLAY）や、ライブラリという楽器を作ったり利用する作業とが同じプラットフォーム上に同居することは、メタメディア的技術環境を目指す上でも探究の価値があると言えるだろう。そこでは、マノヴィッチがいうメタメディアを用いた芸術の特徴である、手法やデータ構造レベルのダイレクトな引用やマッシュアップのような、Deep Remix的行為(Manovich 2013, p305)の誘発も期待できる。

7.4.3 作品の不在とmimiumの今後

本論文はmimiumという音楽のための道具を作ることを主題の1つのしながらも、その道具を用いて作られた作品についての言及がないという特徴を持っていた。これは、道具を作るという行為自体の価値の相対化を測るための意図的な構成ではある。とはいえ実際問題、現段階の道具としてのmimiumの完成度は、実用的に音楽家が自らのワークフローに取り入れたりするには程遠い状態なのも事実である。mimiumの開発は音楽制作過程における問題解決のための道具づくりではない、ということは本論文を通して繰り返し主張してきたが、それでも音楽家が実際に用いることによるフィードバックはmimiumの今後の発展のためにも欠かせないものであるのは間違いない。

とは言え、汎用のプログラミング言語で関してでさえ「実用的な」ツールとして機能し始めるには一般的に長い時間がかかることもまた事実である。たとえばRubyを開発したまつもとゆきひろによれば、Rubyの開発自体は1993年から始まり、最低限の機能が揃ったのは半年後(まつもと 2016, 51p)ながら、最初に公開されたバージョンである0.95は1995年と、開発開始から2年の時間を要している。音楽系の言語の例で言えば、Faustはプロジェクト自体が始まったのは2002年だが、最初にリリースされた正式なバージョン0.9.0はやはり2年後の2004年になってリリースされている⁹。

本研究では音楽土木工学の実践の中で、あり得たかもしれない別の現在へと向かうことを重要な目標として挙げはしたものの、それは必ずしも急いで向かわなければならないということを意味しない。効率的に急いで最短距離で向かおうとすることもまた視野の狭窄につながるからだ。あらかじめ開発に10年かかることを織り込み済みの状態で始めるプログラミングという実践の形態も間違いではないはずだ。常に寄り道をする余地がなければ、けもの道へのはみ出すこともままならなくなってしまう。

筆者は今後もmimiumの開発を継続していくつもりであり、その中ではmimiumを利用した何らかの作品づくりという形態をとることもあるだろう。しかしそれは、例えば上述したパッケージマネージャーのような周辺機能の開発や、ドキュメンテーション、ワークショップ、授業のような様々な実践の中のひとつに過ぎないものとなるはずだ。何かを作る行動と、何かを作るための環境づくりという行動の特別な線引きがなくなる状況こそがメタメディア的技術環境の実現なのだから。

7.5 結語 / XX土木工学（Civil Engineering of XX）へ

本論文では、音楽土木工学（Civil Engineering of Music）といういまだ存在しない学問の必要性を、mimiumというPLfM設計を通じて検討してきた。

まず第1章では音楽土木工学の基本的概念を示した。音楽土木工学はテクノロジーを音楽に応用するのではなく、音楽のための土と木、すなわち基礎的なテクノロジーやインフラストラクチャを再考するアプローチとして提示された。同時に、土木工学の訳語であるCivil Engineering、市民による（市民のための）工学という意味合いで、テクノロジーをそもそも誰が誰のために作り出すのかという問いかけを持つ学問でもあった。

第2章では本研究それ自体の研究プログラムの設定のため、デザインリサーチの歴史を振り返った。学問としてのデザインの議論では、時代と共にRtDのような単なる問題解決や客観的方法論に限らない多様なアプローチが提案されてきた。本研究はRtDやスペキュラティブ・デザインの文脈を引き継ぎつつも、未来ではなく過去とインフラストラクチャに着目するという立場をとった。プログラミング言語のような実用的道具を主題にしながらも、そのリサーチアウトプットをデザイン対象よりも、実践を通して変化したデザイナーの視点から見た異なる歴史認識の記述とすることで、これまでと異なる研究プログラムのあり方を提示した。

第3章では、メタメディアとしての計算機の使われ方を中心に、表現のための道具としてのプログラミング言語研究や開発の必要性を議論した。パーソナルコンピューターの元々の思想には、利用者がプログラミングをもとに自らの手で機能を作り変えることが重要視されていた。しかし、コンピューターを普及する上で実際には、プログラミングのような難しい作業を「ユーザー」から隠蔽しブラックボックス化する事によってその利用ハードルを下げてきていた。これは、ソフトウェアやコンピューターを用いる表現のための道具（楽器）全般にも共通して言えることだった。さらに、ユーザーフレンドリー性のために、変化に時間のかかるインフラストラクチャ——例えばプロトコルやフォーマットが整備される事によって、想像さえできればなんでも作れる状態は、想像できたとしても作れない状況へと変化してしまった。芸術実践を行う者も、今やテクノロジーを理解しないままに、いや理解したとしてもその活用可能性を広げる事は難しくなってきている。それゆえ、たとえ長い時間がかかったとしても、プログラミング言語のような表現を規定する根本的インフラストラクチャの構築に、表現者自ら取り組む必要があると結論づけた。

第4章では、PLfMの歴史を、その技術的仕様や社会的背景を交えて批判的に検討した。今日PLfMのモデルで一般的になっているUGenモデルのような音声合成の抽象化方法は、元々幾つもあり得る抽象化方法の中の暫定解でしかなかった。しかし1970年代のリアルタイム実行の需要に応え、UGenがハードウェア化される事によって、その抽象化方法は所与のものとされ、抽象化方法自体への思索は影を潜めた。2000年代にはパーソナルコンピューターでリアルタイム信号処理が可能になって以降、ライブコーディングのようなPLfMの異なる利用方法に伴いオルタナティブな抽象化は試みられてきた。だがそれらの試みも、各表現のレイヤーに合わせて言語をそれぞれ作るMulti-Languageパラダイム的な広がりを見せ、プログラミングによるメタメディア的利用への着目は依然不足していると結論づけた。

第5章では、現在の視点でPLfMの実装のパターンを類型化し、各言語を特徴付ける要素と、実際に現れる特徴の整理を試みた。PLfMの設計や実装は、その言語を用いて作られる表現についての議論が中心的になっており、実際に何を指針にして設計するのか、どうやって言語の特徴を主張するのかの議論が不足していた。そこで、汎用プログラミング言語における議論も借りつつ、PLfMの利用モデルを提示し、それに対応する形で各言語の特徴を表す語彙を整理した。この、各言語間の特徴には、言語実行の際に用いる中間表現の粒度による本質的トレードオフが存在する。そのため、各言語の設計におけるトレードオフの選択を明示する事で、必ずしも実用性だけに限らないPLfM研究の議論が可能になる。

第6章では、実際のmimiumという言語の設計と実装を提示した。mimiumは、汎用言語の設計に最小限の時間操作の機能——スケジューリングのための@演算子と、内部状態付き関数としてのUGen相当の表現という2つの機能を加える形で作られた言語だった。mimiumはユーザーにハードウェアの意識をさせる必要がなく、UGenの中身をブラックボックス化せずに記述できると言った特徴を持っていた。しかし、現状の実装ではUGenのパラメトリックな複製やマルチレート処理と言った、より複雑な「いつ計算するか」という問題の混在した記述ができない問題を残した。こうした記述のための、多段階計算のような、汎用言語で議論されているが、PLfMではあまり着目されていない理論の応用可能性も示唆された。

第7章では全体の議論を振り返り、音楽土木工学という学問を、対象とする領域だけでなく、学びと実践における態度の問題として再度議論した。メタメディア的環境の実現のためには、理想的なプログラミング言語やツールが作られるだけでは不十分である。なぜなら、そこには常にその道具を作る誰かの存在と分業体制が残るからだ。そのためには、表現者が技術インフラストラクチャに取り組むのと同様に、技術者にもまた自らの実践が及ぼす影響に異なる視点を与える必要がある。音楽土木工学という学問領域は、インフラストラクチャに目線を向けるこれまでと異なる工学実践という、ある種の研究の余白の指摘であると同時に、そもそも研究した結果どのような社会と文化が創られるべきか、という議論へと引き込むため戦略的に作られたカモフラージュである。

本研究で提示した音楽土木工学という考え方は、もちろん音楽に限らず、あらゆるテクノロジーと関わるデザイン/制作の実践において適用できる考え方だ（そしてもちろん、テクノロジーが関わらない実践など本質的に存在しない）。

視覚表現や彫刻、文学など、それぞれの領域XXにおけるXX土木工学（Civil Engineering of XX）を提起することができるだろう。ただしこの考え方が今後一般的になったとして、あらゆるものの土木工学（Civil Engineering of Everything）なる研究領域が訪れる事はない。それは、サイモンがあらゆるものの科学を目指す事により行き詰まったことと同じような結果を招くだろう。あくまで現時点での音楽土木工学とは異なる分野同士のコラボレーションによる学際的（Inter-Disciplinary）研究を目指しているのではなく、反-規範（Anti-Discipline）を常とするべきだ。XX土木工学の考え方が一般的になった先にあるのは、土木工学というカモフラージュ自体が不要になり、Civil Engineeringの語の批判的検証がなされるだろう。その先にはあるのは、YY of MusicやYY of ZZのような、その時代における何かしらノイジーな学問であるはずだ。