CODE―インターネットの合法・違法・プライバシー
書評_021
松川研究室M2 関口大樹
書籍情報
書籍：CODE―インターネットの合法・違法・プライバシー
著者：ローレンス レッシグ
訳者：山形 浩生、柏木 亮二
出版社 : 翔泳社 (2001/3/27)
コードは法である
本書は、簡潔に言うならば、インターネットやサイバー空間における法規制のあり方について議論しているものだ。本書が書かれたのは、2021年から見てちょうど20年前の2001年になる。今でこそ、インターネットを介したサービスや仕組みは多く実装され、我々の日常生活に根付いているが、2001年当初は、インターネットを利用した様々なサービスやその応用可能性を考えていこうとしていた時期であり、法整備やサイバー空間の設計の仕方そのものについて議論され始めていた頃だと言える。
インターネットが生まれて以来、本質的にサイバー空間はコントロールのない自由空間であり、実空間における政府の存在や何かしらの組織からのトップダウン的な制御や規制がないことが、その自由性に繋がると考えられていたが、本書の著者であり、憲法学者であるローレンス・レッシグは、「完全なコントロールから解放されること自体が自由なのではなく、ある一定のコントロールや規制の上でこそ自由が成り立つ」と述べている。そして、その規制に当たるのが、「憲法」であるとレッシグは言う。つまり、自由を考えることは、その裏返しである規制について考えることでもあるということだ。
レッシグは、人の行動や社会秩序を規制する方法として、「法」、「規範」、「市場」、「アーキテクチャ」の４つを挙げている。実空間では、我々は憲法や法律がどのように私たち自身を規制・制御しているかを認識しており、それらが1つのコード(規制手段)になっているとレッシグは述べる。そして、それはサイバー空間での議論でも同様であり、サイバー空間における自由と規制について考える際に、「何が」サイバー空間でのふるまいを規制・制御しているのかを理解する必要があるということだ。結論から言えば、それは「アーキテクチャ(=コード)」であるとレッシグは述べている。なぜなら、サイバー空間の中でなにができるのかは、すべてそこのコード(例えばプログラムやプロトコルなど)によって決定されるからである。
例えば、ネット上における音楽や漫画などの違法コピーや著作権違反を法律や規範などによって規制したとしても、Youtubeなどへの不正コピーの流出は跡を絶たないのが現状だ。ならば、それを技術的に、物理的にできないようにしてしまうような仕組みを実装してしまえばよいというわけである。つまり、サイバー空間を形作るアーキテクチャ(=コード)によって、そもそもコピペができないような環境を構築し、我々のふるまいを完全にコントロールしてしまえばよいという思考になるだろう。
そして、レッシグが危惧していたのは、まさにこの「技術的な規制強化」のあり方が、サイバー空間のアーキテクチャになってしまうことであった。このままいくと、サイバー空間は完全にコントロールされてしまう環境(アーキテクチャ)に向かうとレッシグは予想し、その未来像に危機感を覚えていた。著作権保護などを完全に規制することは、創作者の創造や表現を阻害する可能性があると指摘し、サイバー空間上でのある程度の自由を積極的に擁護し、コモンズを残すようなサイバー空間を構築すべきだと主張した。
規制することの意義を説きながら、ある程度の自由を要求することは、一見すると矛盾しているようにも見えるが、レッシグが言いたいことを筆者なりにまとめるとするなら、我々のふるまいや行為を「完全なる自由環境の下に置くのか」、それとも「強固な規制や拘束の下に置くのか」という二元論的な議論をするのではなく、その中間に位置するようなあり方や環境を模索するべきである、ということだろう。そして、その思考ツールとして、アーキテクチャという規制(コード)のあり方の可能性を、レッシグは説いたのではないかと考える。
人の行動や社会秩序を規制する4つの側面
前段で少し触れたが、レッシグは、人のふるまいや行動を規制する4つの側面として、「法」、「規範」、「市場」、「アーキテクチャ」を挙げている。法の制約は、法律や罰則による脅しとしての処罰として機能する。規範は、社会やコミュニティの不文律、コミュニティが課すレッテルを通じて制約する。市場は、モノの値段や経済原理を通じて制約する。そして、アーキテクチャは、我々を物理的に制約する。それらの規制が、どのように我々のふるまいを規制するのかを具体的な事例に基づいて考えてみると早い。
例えば、飲酒運転というふるまいについて考えてみる。
まず、飲酒運転をすることは道路交通法という法律によって罰則が規定されている。もし、飲酒運転をしてしまうと、法によって罰せられ、5年以下の懲役又は100万円以下の罰金が課せられる。これらの重い罰則を避けたいために、運転者は飲酒運転をしないように規制されると言える。
規範的な制約を考えると、例えば、教習所や免許の更新時のセミナーなどで、飲酒運転をすることがいかに悪なのかということを教わるだろう。つまり、飲酒運転は「いけないこと」であり、「人として恥ずかしいこと」であり、「最低なこと」であるなどと、我々の価値観や倫理観に直接訴えかけることで、それらが制約として機能するということだ。
市場的な制約を考えると、値段を通じて規制されるという文脈を通して言うならば、罰金の値段がそのまま飲酒運転というふるまいに規制をかけるだろう。単純に、飲酒運転して逮捕されたら、1億円の罰金ですよと言われたら、まともな人間なら、飲酒運転することのリスクが大きすぎるので、それが飲酒運転しないことの自制につながるということだ。
以上のような規制は、実際に飲酒運転というふるまいを規制するものとして機能するだろう。だが、それでも今日において、飲酒運転が全くなくなることはない。ニュースなどで、飲酒運転の報道を見ることはいまだに多くある。つまり、法や規範、市場の制約が有効に働くには、規制される側が、そうすることの意味や価値観を意識的に内面化するプロセスが要求される。
本質的に飲酒運転を規制したいのであれば、人々の価値観や解釈を抜きにして、そもそも飲酒をしていたら、物理的に車を運転できなくすればよいのではないかということを考えるだろう。つまり、自動車にアルコール検知機能を設置し、飲酒を検知した場合には、エンジンがかからないようにするという規制方法だ。これがアーキテクチャと呼ばれる規制であり、技術的に、物理的に我々のふるまいや行為の可能性を封じるものだ。
例えば、飲酒運転の件数を減らしたい政府にとっては、どの規制方法を採用することが一番効率的で、コストもかからず、現実的であるのか、ということを吟味することが求められる。各規制手段のコストは異なるため、最小限のコストで最も飲酒運転の数を減らすための仕組みを考えなければならないということだ。
アーキテクチャとは何か
インターネットやサイバー空間を規制するものは、アーキテクチャであるとレッシグは説いたのは、おそらくアーキテクチャという概念が他の3つの規制手段とは異なる新しい規制のあり方であると考えていたからだろう。ちなみに、アーキテクチャという言葉は、哲学者である東浩紀によって、「環境管理型権力」と概念化されている。アーキテクチャという概念をうまく定義することは難しいが、今回は社会学者である濱野智史の著書の『アーキテクチャの生態系』の中で述べられている要約を参照する。濱野によれば、アーキテクチャの特徴は、次のようにまとめることができる[1]。
①任意の行為の可能性を「物理的」に封じてしまうため、ルールや価値観を被規制者の側に内面化させるプロセスを必要としない。
②その規制(者)の存在を気づかせることなく、被規制者が「無意識」のうちに規制を働きかけることが可能。
そして、濱野は、社会学者の宮台真司のファストフード店の椅子の堅さやBGMの大きさ、冷房の強さといった例を参照し、アーキテクチャの特徴を次のように説明している[2]。
椅子を座り心地の良いものにするのではなく、硬い材質のものにしておけば、居心地が悪くなるため、お客さんは長居しなくなる。店内が混雑してきたら、BGMの音量を上げたり、冷房を強めることでお客さんに気づかれない程度に店内の不快指数を引き上げ、ひいては店の回転率を向上させることができる、というわけです。お客さんの側は、「実はそういう操作が裏で行われているんだよ」と言われなければ、その事実に気づくことは難しいでしょう。
レッシグもいくつかのアーキテクチャの事例を挙げており、今回はその中の1つを紹介する[3]。
あるアメリカの大手航空会社は、月曜早朝のフライトの乗客が預けた荷物が出てくるのが遅いという苦情を多く受けていることに気づいた。他のフライトに比べて、荷物が出てくるまでに時間が特に長いわけでもないのに、なぜかその便だけ苦情が多い。そこで、航空会社は、このフライトの飛行機を手荷物受取場所からずっと遠い場所につけるようにした。乗客達が荷物を受け取りにくる頃には、もう荷物は出てきているようにしたわけだ。その結果手荷物による苦情は減ったらしい。
これも、アーキテクチャによる規制の1つに挙げられるだろう。物理的に歩く距離などを長くすることで、手荷物受取場で待つという時間を短縮していることになる。お客さんは、航空会社の意図を知る由もないし、自分が暗黙的にコントロールされていることに気づかない。結果的に「荷物が出てくるのが遅くてイライラする」というふるまいや苦情を規制し、解決したと言えるだろう。
濱野の要約の①の定義が示すことは、前段でも述べたように、規範や法による規制がうまく機能するには、被規制者である人々がその意味を理解し、自分たちの中に内面化するプロセスを踏む必要があることを指す。レッシグは、制約を主観化するには手間がかかり、それを自分のものにするために意識的に選択する必要があると述べる。法や規範は、主観化されるほど有効になるけど、そもそも効力を持つためには、最低限の主観化が必要になる。制約されている人間は、制約されることを知らないといけないのである。
一方で、アーキテクチャは主観化がまったくなくても制約できる。例えば、家のカギの存在は、泥棒が知ろうが知らないが、泥棒が自宅に侵入するというふるまいを物理的に規制する。つまり、②の定義が意味するのは、規制されている側がその規制(者)の存在自体に気づかず、ひそかにコントロールされてしまうということだ。
アーキテクチャによる制約は、その対象者がその存在を知ると知るまいと機能するけど、法や規範は、その対象者がその存在についてある程度知っていないと機能しない。内部化には手間がかかるし、常に意識的に規制の存在に目を向ける必要がある。それは言い換えると、そういった規制手段を、被規制者が内面化するプロセスをサポートする仕組みの構築とその運営が求められるのではないかということである。
建築とアーキテクチャ
レッシグはサイバー空間とアーキテクチャの関係性性を考察し、サイバー空間の将来像やどのような環境であるべきかということを本書を通して説いた。そして、レッシグが考察した内容は、建築や都市の領域やそのデザインプロセスなどにも同様に適応させることが可能であろう。ここからは、筆者自身の考察を交えながら、建築とアーキテクチャ、ないし4つの規制との関係性を簡潔に考えてみる。
レッシグの議論を踏襲するならば、法は建築基準法などを通して、市場は建築の施工費や材料費などの値段を通して、設計可能な空間や形態の可能性(可能態)などを制約すると考えられる。また、規範は様々にあるだろうが、例えば、建築や都市の変遷、つまり歴史性を通して、それは設計者に影響を与えるだろう。正確な言い方ではないが、大学教育などの中で、「こういったものが建築である」「建築とはこういうものだ」という既成概念を学ぶ中で、その歴史性に習うようなものに、建築のあり方が規制されてしまう(フレーミングされてしまう)とも言えるだろう。これらの3つの規制は、建築設計の行為やふるまいを制約するものとして機能し、設計者はそれらの制約に対して意識的にならないといけないし、それらを内面化する必要がある。
以上の3つの規制はメタな規制として、設計行為に制約を課すことを前提とし、さらに、建築設計のプロセスを、「規範型建築設計プロセス」と「アーキテクチャ型建築設計プロセス」があるものだとして考えてみたい。これまでに様々な建築の設計プロセスが考案され、思考錯誤されてきたと思うが、厳密な考察を抜きにすれば、上記の2パターンに抽象化して考えることができるのではないか。
規範型建築設計プロセス
規範型の建築設計プロセスとは、建築の設計者と利用者が、ある種の規範的な対話やワークショップなどを通して、建築や空間を設計していくものだと考えられる。
例えば、注文住宅のような場合は、設計者(構造設計者)が規範や慣習としての建築設計プロセスの流れを把握し、設計者がある種の規範的存在となって、建築設計のプロセスをファシリテートし、利用者との対話を通して建築をつくりあげていくことが可能になると考える。
また、クリストファー・アレグザンダーの「パタン・ランゲージ」のようなものやモクチン企画の「モクチンレシピ」のようなものは、建築家などによって、設計プロセスやそのルール、建築のパターンやその意味などが社会情報として、社会の中に事前に外部化(設計)される。そして、利用者はワークショップなどを通して、それらを一種のツールとして利用することで、建築をつくることが可能になるだろう。この場合、利用者はワークショップの意図や設計プロセスのルール、その仕組みなどを内面化する必要がある。パターンやレシピがあれば、魔法のように建築や空間のアウトプットイメージがつくられるわけでなく、それらのパターンが意味することやパターンのかたちと敷地や既存環境との関係性なども考慮しながら考えないと、カオティックな空間に発散してしまうだろう。
いずれにしても、規範型の設計プロセスにおいては、ある主体が指導者(規制者)のように、規範やルールを享受し、その場がうまく回るように、そして、管理(維持)されるように常にキュレーションする必要があるということだ。例えば、木賃アパートの管理者や不動産関係者が、モクチンレシピを建物の改修に利用したいと思った際に、そのレシピの意味や使い方、既存の躯体にどのように転用可能なのか、などの、ルールや規範、意匠や構造的な制約などを一度内面化しなければならない。つまり、モクチンレシピが有効活用されるためには、利用者の内面化のプロセスをサポートする仕組み(社会環境)を同時に設計し、運営することが求められるのではないかということだ。その内面化のプロセスをサポートするために、モクチン企画はセミナーや賃貸ゼミを開催したり、改修のノウハウを学べる動画コンテンツを配信したりしている。建築設計だけでなく、内面化のプロセスをサービスの一環として提供するために、社会環境も同時に構築していることが重要な点であり、それがモクチンレシピという仕組みが機能している(スケールする)理由であると推測できる。
アーキテクチャ型建築設計プロセス
アーキテクチャ型の建築設計プロセスは、利用者がある設計プロセスのルールや規範、建築設計のノウハウなどを内面化するプロセスを必要とせず、建築をつくるという行為の可能性を、あるアーキテクチャ(環境)からの規制に従い、(無意識のうちに)選択しながら、建築や空間を設計していくものと考えられる。
例えば、アーキロイドが開発しているWEBサービスである「archiroid.com」などは、アーキテクチャ型の建築設計プロセスとして挙げられる。利用者は、archiroid.com上で、間取りなどをインプットすることで、自分だけの住宅をつくることができる。
規範型の場合に、ファシリテートする主体(規制者)が担っていた領域や、社会情報として外部化されたものを利用者が内面化し、考えなければならなかった領域などを、情報環境(サイバー空間)上に実装されたコードを通して計算することにより、それらのプロセスの代替えとして機能している。建築や空間を設計するという行為やふるまいは、アーキテクチャから提示される結果(インプットに対する住宅群)を利用者が事後的に選択するという行為に置き換えられる。アーキテクチャ型の設計プロセスの仕組みとインタラクションをしている利用者は、そのアーキテクチャによって自身のふるまいが規制されている(選択させられている)ことを自覚化することはなく、インプットに対するなんらかのアウトプットを取捨選択しながら、建築をつくるというふるまいを行っていくことになる。
この場合に議論しなければならないのは、仮にアーキテクチャ側で、建築設計の行為やふるまいの可能性を計算し、利用者側になんらかの提示するのであれば、そのアーキテクチャをつくるコードの設計自体が重要になるということ。あるアーキテクチャによって提示される(規制される)ものが、陳腐なものであったり、利用者が望むようなものでないことが散見される場合は、それはアーキテクチャ型の仕組みとしての価値がないことに直結する。このアーキテクチャのあり方の設計自体が最もクリティカルな要素であると考えられる。
遊び場とアーキテクチャ
最後に、個人的なことになってしまうが、筆者自身は遊び場環境について研究をしている。そして現状の研究手法では、規範型の設計プロセスを採用している。つまり、筆者自身がその遊び場にいないと、その場が機能しないようになっている。筆者がキュレーターのように、子ども達との対話の中で、危ない遊びかたやかたちの出力を規範的に規制しているからだ。筆者がその場に存在しない場合に、その遊び場を運営、維持していくには、子ども達やその親御さんたちなどに、遊びかたのルールや、危険な遊びかたを見分ける方法、部材のかけかた、工具の使い方や施工プロセスなどの規範やルールなどを、レクチャーし続け、彼らがそれらを内面化(主観化)することを待つしかない。つまり、その場を管理し、維持していくための社会環境も今後は同時に設計しなければならないということを示唆している。
もう一方の可能性として、アーキテクチャ型の設計プロセスのように、規範やルールを内面化することを強要するのではなく、これまで筆者が規範的にやっていた行為を、アーキテクチャ(サイバー空間)側にコードとして翻訳し、利用者は構築されたアーキテクチャとのやり取りの中で、かたちの意味や遊びかたのルールを選択しながら、遊びを実践するような遊び場のあり方も考えられる。この場合、筆者のような存在がいなくても、場所や時間に縛られずに、遊び場を管理、維持していくことも可能かもしれない。だが、構築するアーキテクチャの良し悪しによっては、全く機能しない遊び場環境になる可能性も多いにある。
いずれにせよ、自由と制約の境界はどこにあって、どのような規制手段や環境であることが、人々の行為やふるまいをうまく規制しながらも、ふるまいの自由を担保できるのか、ということを我々は模索するべきであり、その思考ツールとして、アーキテクチャという概念やCODEで議論されている内容は、大いに有効なものになるのではないだろうか。
参考文献
[1] 濱野 智史 (2015) 『アーキテクチャの生態系: 情報環境はいかに設計されてきたか』 (p. 26)
[2] 濱野 智史 (2015) 『アーキテクチャの生態系: 情報環境はいかに設計されてきたか』 (p. 24)
[3] ローレンス・レッシグ (2001) 『CODE―インターネットの合法・違法・プライバシー』 (p. 165)
この記事が気に入ったらサポートをしてみませんか？