20110612

Archiduino Project - vol.19

建築系におけるArduino利用計画としての「Archiduino Project」。

今回はサーバ側のプログラムについて。

これまでのプロジェクトではあまり触れてこなかったが、ハブノードはセンサノードから受け取ったデータを受信用のサーバに随時送信を行っているわけであり、当然サーバ側にはそのデータを受信するためのプログラムが動いている。私はサーバサイドで動くプログラムについてあまりというか全然知識がないので、とりあえず動けばいいや的に、例によってPerlでCGIを書き、HTTPのGETメソッドで送られてきたデータを受け取る、といういつもの方法を使うことにした。

Pachubeにデータを送るために、受信側のプログラム(サーバサイドで稼働)はeeml形式のXMLデータを書き出すこともやらせている。私の勘違いでなければ、Pachubeのアップデートのタイミングといっしょにeemlの書式(必要なデータ項目)も変わったりするので注意が必要だ。というわけで、サンプルプログラムを以下に掲載する。

Archiduino MBT - vol.1

なお、MBTとはこのArchiduinoプロジェクトが始まるきっかけとなった「Make Buildings Talk」プロジェクトの頭文字をとったものであり、これはその名残である。HTTPdとCGIの動くサーバを用意し、任意の階層に上記CGIを設置する。データファイルなどの保存のために、同じディレクトリにeemlとdataディレクトリを用意しておく(パーミッションは666など)。dataにはその日ごとに記録ファイルが作られ保存される。eemlにはPachubeへのアップロードに対応した(=Pachubeに随時参照させる)eemlファイルが保存されるが、フィードに関する設定情報をeeml直下にあるfeeddata.csvに記録しておく。これは例を参考にして、エクセルなどで適宜項目を作成して欲しい。

ちなみにハードの話であるが、私がサーバとして使用しているのはMac mini(Mac mini Serverではない)である。Mac miniはコンパクト/安い/デザインも良いというわけで、今後もなにかと重宝するのではないかと考えている。今はWindowsをブートキャンプしているけれども、今後はLinuxとかでやれないモノかと夢想中。

Archiduino Project - vol.18

建築系におけるArduino利用計画としての「Archiduino Project」。

今回は新型のハブノードについて。

Arduino DuemilanoveがUNOになるタイミングに合わせてイーサネットシールドもバージョンが上がりました。新しいイーサネットシールド、というよりもUNOではこれまでのハブノードのスケッチが動かない(使用していたライブラリに問題がある?)ので、これを機会にUNO+新イーサネットシールドの構成で再構成してみた。

というわけで構成は至って単純。UNOにイーサをのっけておまけに「もろもろシールド」を乗せただけである。

UNOとXBeeシールドとの相性は相変わらず悪いので、最近はXBeeシールドを使わないことにしている。従って、例によってXBeeはピッチ変換基板を「もろもろシールド」(※センサーやLEDなどをユニバーサル基板にのせたもの)にのせることで実装した。前作でもサーバへのアップロードに失敗すると圧電ブザーを鳴らすことにしているが、これはLEDの点灯だけにしても良いと思っている。ま、そこは趣味の問題。

次にスケッチ。結論から言えば完全移植には一歩至っていない。DNSサーバにドメイン名からIPを逆引きする部分については未実装だが、とりあえず静的IPという前提であれば問題はないと言うことにした(鋭意実装中)。ただし、DHCPによるローカルアドレス取得には対応済み。ちなみにDHCPのライブラリはこちらを使用。また、そのほかのライブラリとしてはPStringXBeeを使用している。

というわけで、バージョンゼロのスケッチを以下に掲載する。

Archiduino HUB - ver. 0

20110607

Archiduino Project - vol.17

建築系におけるArduino利用計画としての「Archiduino Project」。

Archiduino Project - vol.5でもすでに紹介しているが、自作のローコストArduinoを更新したのでレポートしたいと思う。

基本的な構成は変更がなかったという意味で、すでに私の中では完成されたものなのかもしれない。設計思想について以下にまとめてみる。

・名刺サイズのユニバーサル基板上で完結する(横23×縦15グリッドの範囲の中に収める)。
・XBeeの通信機能を持つ(ピッチ変換アダプタを介することは許容する)。
・デジタル/アナログ入力端子については、最大限利用可能な数を確保する(13+6でなくても良いこととする)。
・ATmega328P-PUを使う(小さいのとかはとりあえず考えない)
・スケッチは直接書き込めなくても良い(別途ArduinoなどでアップロードしたICを換装することでもよしとする)
・基本的にはACアダプタ(9V)挿したら延々と回り続ける仕様にしたい。
・なるべく必要最小限の構成を心がける。

写真のものはバージョン3.5である。

既存のバージョン3でも上記の条件をすでに実現していたが、Power LEDはピッチ変換基板のLEDと統合できたり、バイパスコンデンサの位置のせいではんだ付けの労力が大きくなってしまっていたことなどもあり、それらの点を変更したいと考えていた。また、スケッチのアップロードについても、既存の基板上の余剰スペースを活用して対応できるようにしてみたいとも考えていた。これらについて対応したのがバージョン3.5である。導線部分などのアクロバティックな構成を考えるのに苦心した。これはほんとパズルだな。だが楽しい。

3.5を作ってみて、スケッチのアップロードには対応しなくても良いのではないかと思ってしまった。やはり、ICへの書き込みは作業を切り分けて別途実施し、施工した基板にこれをがんがん嵌めて電源通して設置完了!という流れで良いのだとあらためて思い直してしまった。いちいちスケッチを描き直すような使い方を想定しないことが、やはりこのプロジェクトの前提条件であろう。

以下に構成部品を記す。

・秋月電子 低損失三端子レギュレーター5V500mA TA48M05F:AC電源からの入力電圧の調整に必要。5Vを出力。100円。
・秋月電子 低損失三端子レギュレーター3.3V500mA TA48M033F:上記で得られた5Vを更に3.3Vに変換。XBeeチップの作動に使用する。100円。
・秋月電子 水晶発振子 16MHz:16MHzの発振に必要。10個入り500円。
・秋月電子 絶縁型ラジアルリードタイプ積層セラミックコンデンサー 0.1μF 50V:主にバイパスコンデンサとして使用。10個入り100円。
・ATMEL AVRマイコン ATmega328P-PU:Arduinoの心臓部。250円。
・Digiインターナショナル XBeeチップ:出力の弱いもの(短距離型)と強いもの(長距離型)とがあるため、設置状況に応じて選ぶこと。2,730円~
・スイッチサイエンス XBeeピッチ変換基板とソケットのセット:2mmピッチのXBeeチップを2.54mmピッチに変換するためのゲタ。1セット500円というのはちょっと足元を見られている気がするが・・・
・秋月電子 カーボン抵抗(1/4W 4.7Ω):抵抗。100本100円。
・秋月電子 スイッチングACアダプター9V1.3A 内径2.1mm NP-12-US0913:Arduinoの電源として。750円はちょっと高いなぁ。
・秋月電子 ピンソケット(1×14pin):アナログ/デジタルの入出力端子用。50円×2点。
・秋月電子 2.1mm 標準DCジャック 内径2.1mm 外径5.5mm:ACアダプタから電源を受けるためのDCジャック。4個入り250円。
・秋月電子 両面ガラスユニバーサル基板:2.54ミリピッチのユニバーサル基板。60円。

20110322

東京電力エリア内電力使用状況

東京電力が今日から電力使用量の公開を始めたので、早速これをPachubeにアップするスクリプトを書いてみた。公開されているのはグラフのGifイメージなので、画像解析っぽいことをやる必要があった。以下はPachubeによるZoom Graphである。


フィードはこちら

例によって取得したデータからeeml形式のファイルを作成してこれをPachubeに読み込ませる方法をとった。私のアカウントでは、Pachubeは3ヶ月しかログを保存してくれないので、ローカルにもログを残すことにしている。東電は1時間おきのデータしか公開してくれないので解像度は粗いが、前年・前日データも一緒に公開してくれているので、それはそれでありがたい。

フィードにアップされるデータはCSVやJSON、あるいはXML形式で共有されるので、他のサービスやGadgetなどと連携したい場合はこれを使っていただけるとよいのではないか。

東電がこのサービスを今後どれくらいつづけるかは不明だが、これから夏に向けて電力の使用方法についてをみんなで考えていかなければならない我々にとってはまさに必要なデータである。必要と思っていたそのときにこのようなデータが公開されたのは、渡りに船、であろうか。

20110320

LEDランタン - vol.1

計画停電によって夕暮れ時に停電になる事があったけれど、今更ながら灯りのない生活はなかなかに厳しいものです。そこで私もまわりのMakerに倣って、LEDランタンを作ってみました。



手元にあったIKEAの調味料瓶(4コセットで200円くらい?)―買ったものの使い勝手が今ひとつのため廃棄処分寸前―がハウジングの大きさとしてちょうど良さそうだったので、これを流用することにした。開け閉めできるフタの部分を灯火スイッチにすれば、電池も無駄にならないし、本来から備わっている「開け閉め」という動作をそのまま引き継いでモードの変更ができる。

構成部品は3Vのボタン電池、電池のケーシング、LED(超高輝度LED25000mcd)、LED拡散キャップ、錫メッキ線、IKEA調味料ボトル、ティッシュ、以上である。

LEDの光は直進性が強いので、拡散キャップを付けるが、それでもまだグレアが厳しいので、くしゃくしゃに丸めたティッシュペーパーを瓶に入れてソフトな光になるよう調節する。

テーブルに置けば手元の灯りに、キャップ部分を下にして置けば部屋全体を照らす拡散光、手に持って歩けば懐中電灯として、一台三役なかなかの優れものとなった。今度のMakeで売ってみようかしら?

20110225

Archiduino Project - vol.16

建築系におけるArduino利用計画としての「Archiduino Project」。

いよいよ念願のメッシュネットワークによるローコストモニタリング基盤が実現できそうな運びとなったので、興奮冷めやらぬうちに報告したいと思う。

まず、なぜ「メッシュネットワーク」にする必要があったのかという点について。これについてはひとえに、伝送距離の長距離化のためには必要不可欠であったからである。XBeeの仕様書によれば、日本国内では電波法の関係上(?)、出力が低く抑えられてしまっており、XBeeチップのレギュラー版であれば公称120m(屋外見通し距離)ということだが、実際にはこれよりももっと短い距離しか飛ばない。屋内になると更に短く、ドアや階段を途中に挟むとほとんど届かないと思ってよい。

このような問題をクリアするためには、まず手っ取り早くはより高出力型であるPro版を使うという手もあるが、実際には思った以上に距離が伸びるというほどでもない。2階建ての家の一階の隅から二階の隅まで届くのかといえば、答えは明確にNoである。具体的にいうと、「箱の家ではない」の一階寝室に置かれたセンサノードからは、それがPro版を載せていても2階リビングにあるハブノードまでは届かない。

こうした問題を解決するためには、やはりバケツリレー型のメッシュネットワークを構築し、そのネットワーク上にデータを流してやる、という方法をとらざるを得ない。尤も、こちらとしては既存の技術を使わせてもらうにすぎないわけで、やれることには限界があるし、多分にチップベンダー依存ではある。だがこれまでに1ノード数千円で構築できる安価なセンシングインフラが建築分野で使われた事があったかといえば、おそらく答えはNoのはずである。

メッシュネットワークにすれば万事解決というわけでもない。もちろん、ボトルネックがあると、そのノードの故障が他のノードからのデータの不達を引き起こす可能性をはらんでしまうので、ロバストなノード配置を気にしなければならない。

今回実装してみてわかったことでもあるが、1サイクルの処理に4秒「も」かかっている――ログの間隔が最短でも4秒おき――のは、やはりArduinoの非力さが露呈したといっても過言ではあるまい。技術的にはもう少し早くできるのかも知れないが、今の手持ちの実験環境ではそんな感じである。

通信速度の問題について改めて検証したところ、どうやら温湿度センサ(Sensirion SHT7X)の処理部分に時間がかかっている事が判明した。別なセンサを使用したところ、この問題が発生しない事がわかっている。

さて、前振りはそんなところにして、今回の実装についてメモを残しておきたい。まず最初にやらなければならなかったのは、XBeeをAPIモードで動かすためのさまざまな設定である。いくつかの段階で手が止まることがあったので、自分自身への備忘録ということも含め、やや詳細に書き残しておく。

なお、今回使用するメッシュネットワークは、いわゆるZigBeeではなく、Digi International社の独自実装プロトコルであるDigiMeshを利用することとした。その理由は二つ。第1に、手持ちのXBeeがすべて「シリーズ1」と呼ばれる製品であったこと。ちなみにシリーズ2はZigBeeに準拠した製品である。第2に、ZigBeeはクラスタツリー型のネットワークを構築するが、DigiMeshは完全グラフ型のネットワークを構築するという違いがあるとかそういう話をどこかで目にしたからだ(公式の仕様書に記載あり)。ともあれ、ここは第1の理由によるところが大きい。

最初に行う手続きは、手持ちのXBeeをAPIモードに変更する作業である。ネットで検索するとその手続き方法が見つかる。例えばこことかここが詳しいが、ここに書かれている方法はZigBeeのものであってDigiMeshのものではないことに注意されたい。DigiMeshのファームウェア(XB24-DMあるいはXBP24-DM)は、事前にDigiのウェブサイトからダウンロードしておく(各種あるが、レギュラー版だとxb24-dm_804B.zipでよい)。APIモードの送信データ形式の説明などは、マニュアルに目を通すなりして「そういうモノなんだ」という程度の理解で良いので知っておいた方がいいだろう。また、私が引っかかった点としては、「APIモードは2のエスケープモードで使用する」というところだ。「1(without escape mode)」にしてしまうとダメなのであった。つまるところ、設定の変更箇所はID(Modem VID)、NI(Node Itentifier)とAP(API Enable)だけだろう。

XBeeをAPIモードに移行するところまではできた。Arduinoにセンサなどを載せるところの話は省略し、いよいよ実際に走らせるスケッチの話になる。

ここで改めてこのセンサネットワークの構成をおさらいすると、インターネットに接続しているハブノードを親機とし、親機はすべてのセンサノードからのデータを一気に引き受け、インターネット上のサーバにデータを送る役割をする。また、ここでセンサノードは子機であり、それぞれのノードは様々なセンサを搭載しており、そのデータを随時親機に向けて送信するエラーのチェックなどは一際せずに、送ったら送りっぱなしである。また、伝送の遅延についてもチェックするでもなく、RTCを搭載するでもないので、データはサーバに届いた時刻をセンシングした時刻として残す。私が扱うデータはそれほどタイムクリティカルなものではないので、タイムラグは一切無視である。いってしまえば、そういう「良い加減」なシステムであるから安くて良いのだ。

なお、親機からサーバへのデータ転送は、お得意のHTTPのGETメソッドを使う方法としたのは言うまでもない(笑)

今回の実装に際し、実装を最優先させたので、サーバで走らせている受信側のプログラムなどいろいろ変更することとなった。とはいえ、大した変更ではないし、むしろ必要な変更であったとも言える。

親機で走らせるプログラムはこちらである(これはローカルネット上のサーバに送信するバージョン)。いろいろ設定は各自変更していただき、ライブラリも適宜導入していただきたい。DHCPも搭載しているので、ルータにつなぐだけでOKである。

子機で走らせるプログラムはこちらである。送信先のノードのアドレスを、親機のXBeeチップに記載されている64bitアドレスに設定する。そのほか、サンプルコードでは温湿度センサ、照度センサを搭載した場合のコードも記載してあるので、他のセンサを載せたい場合などに書式を参考にしていただきたい。なお、私はどうしてもデータを一度文字列にしたい修正があるので、わざわざPStringというライブラリを使っていたりするが、そのへんはご容赦願いたい。また、PStringした文字列をuint8_tに変換する部分の処理については、早稲田大学情報理工学科の林明宏助手にご協力いただいた。

さて、これらをおのおの実装していただければあとはすんなりDigiMeshによるマルチホップなセンサネットワークが構築できるはずだ。次回はその実用性に関するレビューについて書いてみようと思う。

20110220

Archiduino Project - vol.15

建築系におけるArduino利用計画としての「Archiduino Project」。

すでにポータルでは使用しているが、記録したデータをGoogle Chart APIを利用してグラフ化することに取り組んだ。現時点では基本的にPachubeが提供するものとほとんど同じだが、自分のフィードのデータを一覧したいというその一点需要のみでやってみた。

entasan.dyndns.org/mbt/chart.cgi

GCAPIの詳細な仕様はこちらに掲載されているが、いろいろとクセのある感じに仕上がっている。慣れるのにはちょっと時間がかかった。上記のURL先で表示しているのは、いわゆる「折れ線グラフ」であるが、もちろん、2本以上の折れ線グラフをひとつの図上に載せることは可能である。しかしながら、GETメソッドでチャートを呼び出すというGCAPIの仕様上、送信されるクエリの長さ(Length)が2000バイト(すなわち2000字)を超えるとエラーになってしまう。従って、あまりにも多くの情報を詰め込んだグラフは、一度には描けない。24時間のデータをそこそこ詳細に載せるとしたら、せいぜい2系列しか載せられないだろう。

そのような仕様上の制限はあるものの、1ページに掲載可能なグラフ総数などに制限があるわけでもないので、使いようによってはそこそこ便利なのではないかと思った。余談だが、私が修士論文を書いたとき、シミュレーション結果をウェブ上でグラフ表示することに取り組んだが、その際はPerlのGD::Graphモジュールを使ったものである。GD::Graphで描かれるグラフは、それはそれは懐古趣味的な絵柄であった。

20101227

Archiduino Project - vol.14

建築系におけるArduino利用計画としての「Archiduino Project」。

12月26日に友人の設計事務所で定期的に行っている勉強会に参加させてもらい、そこで最近取り組んでいるArchiduinoに関する内容について話させてもらった。これはそのとき使ったスライドにちょっとだけ手を加えたものである。

趣旨としてはこうだ。
・ArduinoみたいなラピッドプロトタイピングツールをつかっていろいろなものをTinkeringする人(Make:r)が増えてきている。
・我々も「Archiduino」を通じて建築分野において有用と考えられるICT設備を開発してみた。
・OSHW(オープンソースハードウェア)という流れがエレクトロニクスや工芸、手芸、など各分野に浸透してきている。
・建築もOSHWの流れに位置づけていきたい。あるいは、セルフビルドの系譜に接続していく方法を模索したい。
・1000万人が年収200万円そこらという時代を考えれば、建築家は金持ち相手に特化していくか、住宅取得という方法そのものを変えていくしかないのではないか。

質疑の要旨としては以下である(「→」が回答)。細かなものは省いた。
・情報や通信プロトコルの仕様については?
→APIを公開・共有し、みんなが使えるようにして、情報の出入り口で課金するなどすればいい。委員会あるいはコンソーシアム的にやる方式はもう古いのではないか?
・情報を握ったものが権力者、みたいな風潮の中で、これはそういうものになっていってしまうのか?
→情報を握るだけではダメだ。情報から意味やある種の答えを抽出できるような人やシステムが力を持つことにはなると思う。
・これまでのセルフビルドがうまくいかなかったところにICTを持ち込んでうまくいく勝算はあるか?
→自分の身近な問題としてこういう問題がある以上、勝算があるかどうかは抜きにしてやるべき意義はあると思う。「Make:」という行為の延長がどこまで届くか、可能性は未知数。

20101210

花園におけるメリーゴーランド的考察 - vol.2

私は情報空間としての「茶室」と同列にこの「神社空間」――社殿の他、周辺設備や装束、儀礼のようなソフトウェアや鎮守の森などといった地形も含む――を扱いたい。つまり、先に述べたような茶の湯における三原則、「仕度の原則」「しつらえの原則」「仕掛けの原則」は神社空間においてもぴたりと合致すると考えている。

空間の中にさまざまな含意や隠喩をもたせ、そこで行われる行為に対して客を迷わせることなく、静謐の裡に誘導することを目指している。茶庭でいえば、入り口の門扉から茶室までの誘導空間であり、これは亭主の趣味に依るところが大きいが、一見すると手入れのされていないような鬱蒼とした茂みを、身をかがめて足下を見ながらゆっくり歩くことで自然と茶室へと辿り着いたり、あるいは本来誘導されるべきではない方向へはそれとない表示方法――例えば関守石など――によって行く手を塞がれる。茶室やその周辺空間に配された装飾には一輪の花でさえ意味があり、例えば利休が秀吉を茶室に招くにあたって活けた一輪の朝顔と、そのために刈り取った他のすべての朝顔の話、「朝顔の茶会」の逸話が有名であるが、これは茶の湯におけるもてなしの心、つまり「一期一会」のための仕掛けの在り方について物語っている。もてなすべき客のために高度に整備された空間は、客に対して「感動」や「情動」という心理作用をもたらす。もてなされる客はもてなす亭主の気配りに対して敬意を払い、相互にこの言外のやりとりを愉しむ。そこに「主客一体」の空気がうまれ、そこでこの空間の意義が完成される。

今となってはまことしやかに包み隠され、無毒化、無菌化されてしまってはいるが、この茶室におけるロジックと同様の意味を持つ、男女和合のための空間装置としての機能が「神社空間」にもあると主張したい。そう考えるための手がかりとなるいくつかの論拠を以降に挙げてゆく。

「鎮守の森」という言葉があるが、神社という空間に接するとまず目に映るのは、参道から社殿一体の領域を覆うように鬱蒼と茂る木々の木立である。町中にある神社では、多くの場合は年季の入った数本の巨樹だけが残されている場合が多いが、郊外や田舎の平地にポツネンと残された鎮守の森は、遠くからでもそこに社殿が安置されていることが一目でわかる。神社空間は自然の奇景に重ねて設置されている――というよりも奇岩や奇景を神として祭祀している――ことが多いため、そういった理由からでも場所の特定は決して難しくはない。

中沢新一「アースダイバー」にあるように、水利の良いところや傾斜地の上がったところ、沖積層の先端部などにある場合も多い。農村部の神社空間は山の麓にひっそりと階段状の参道が設けられており、名もない小山を背景としながら、道なき道に転がる石を頼りにおそるおそる歩を進めなければ来た道も行く道も見失いかねないようなところにある神社も未だに多い。そのような地形ではわかりにくいが、一方で、海岸沿いの小高く隆起した地形に配された神社などでは非常にわかりやすいのが、「鎮守の森」は女性の「恥丘」さながらの様相を呈していると言うことである。小高いふくらみと、その上に茂る木々。その木々の裡に隠された参道への入り口。つまり、神社空間それ自体はその外郭からして母体の隠喩であると言えよう。

女性のみがもつ子供を産み・育てる器質は、それ自体が子孫繁栄の象徴として信仰的な祭祀対象であるだけでなく、それと同時に、その「ご神体」と「交信」することがそのまま現世的な「子孫繁栄」へと繋がる道に他ならなかった。その現世的な御利益の「根源」としての母体を崇拝し、敬い、その深奥との連結こそがこの「神」と繋がる唯一無二の根拠であった。その「神」は定期的に「乱れ(月経)」るため、時にはなだめたり、時にはご機嫌を伺うなどし、その具合を極めて慎重に見守り、見極めなければ、決して子孫繁栄へとは至ることができない。従って、「神」と「交信」して結果を残すためには、そのタイミングや具合に対して神経を払い、また、敬意を払わなければならないものだった。これは旧時代におけるフェミニズムの在り方であるといっても差し支えあるまい。

とかく旧時代は男尊女卑の世界と考えられがちであるが、決してそんなことはなかったのではないかと思う。もちろん科学的な根拠には乏しかったのだろうが、古代の男どもも女性なくして子供は産めぬと当然わかっていたわけで、如何にして効率的かつ安全に子供を増やし、集団を拡大していくかということを考えれば、男性が女性への態度や関係を工夫しようと考えるのは何ら不自然なことではない。むしろ問題の大きさが故に、現代よりももっと真摯な対応が為されていた可能性も否定できない。卑弥呼の例もそうだが、天照大命も女性の神であるとされ、前期神々の時代から後期神々の時代に至るまでは女性が集団の象徴として尊崇されていた。生産の象徴としての「神」、あるいはその「神との交信者」として、「神」と同じ身体を持つ女性が神格化され、祭祀や呪術、時には政治を司る役割を担っていたのである。現代においても、神の託宣をうける巫女はあくまで女性の役割であり、儀式を司る進行役として男性の神主が置かれているに過ぎない。

生産の象徴としての女性的身体が神格化され、信仰の基盤としておかれたために、その信仰の拠り所としての偶像が求められることとなった。そもそも本来的には物理的な身体性が神格化された「神」であったため、それに対して改めて身体性を与えるという方向には向かなかった。そこで「神」を隠喩するような象徴的な造型へと拠り所が求められたのではないか。生産と繁栄の象徴である母体を神域全体とみなしたうえで、その外郭空間としてこれを保護する「鎮守の森」という地形を設定したのは、この「隠喩」の地形的な応用に他なるまい。従って、母体の物理的な形態を隠喩した「鎮守の森」が「鎮め」「守って」いるのは、生命誕生と子孫繁栄を司る女性的身体性が神格化された「神」であり、また、「神」と同じ身体を持つ女性そのものなのである。

「鎮守の森」の入り口には、「神」へ至る道の入り口の目印として「鳥居」が立っている。鳥居の由来には諸説あるが、これまでの議論を踏まえ、鳥居を女性性の隠喩として捉えれば、これはすなわち参道の入り口であることから「陰唇」の象徴として見ることができよう。二本の柱と二本の梁、そして地面とで構成される四角い外形線は、参道すなわち産道への入り口にふさわしい形状ではないか。あるいは女性の股座であると見ても良いかもしれない。その鳥居の前に立ち、柱の間を抜けるとそこは参道である。その入り口をくぐり、参道を抜け、「神」へと触れようとする意志は、すなわち男女和合と出産、子孫繁栄への意志の表れであるとみなすことができる。

現代においてもまだ根強く残っている考え方のひとつに、身内に死者が出たあとの忌中の期間に鳥居をくぐるなと言うものがある。鳥居をくぐると言うことはすなわち子孫を増やそうという意志の表れであるが、前述した考え方はこれを禁忌するものである。なぜ禁忌する必要があったのかと考えてみよう。身内に死者が出たと言うことは、病気の蔓延や気候の変化などといった死へと向かわせる原因があるか、あるいは、死者が出たことで労働力や組織形態に変化がおこり、今で言えば多大なストレス要因になりやすい環境に身をさらす可能性が出たと言うことを示唆するものである。このような環境が妊娠した母体に対して良くないことはあきらかであり、現代でもこのような環境での妊娠は避けるべきであると考えても何ら不自然ではない。当時の人々はこのことを経験的に知っていたのだろうか、環境が安定するまでの期間を服喪の期間とし、その期間は事を荒立てたりすることせずに平穏に暮らすべきだというある種の「知恵」を、性交渉に向かう意志への抑止力として設定するためにこのような「禁忌」を用意したのではないか。

鳥居を抜けるとそこは「参道」である。「参道」はすなわち「産道」と音を同じくし、隠喩と言うより、もはや明喩である。音の同一性から、神社空間の女性性との相似を勘づく人も少なくない。参道の端々には「神」へ通じる道を照らす灯籠が置かれることが多いが、私はこれはかなり現代に近い時代、言うなれば「神社空間」に含意された意味がかなり廃れ、忘れられた頃の産物ではないかと考えている。後述することになるが、聖域において実施される「祭り」にはおそらく必ずといって良いほど「火」が用いられたはずであり、現代のように人工的な灯火のなかった時代にはその「火」だけで十分暗闇は照らし出されたはずである。少なくとも道しるべ程度にはなったであろう。ただ、その「祭り」の場に至るまでの空間を盛り上げるための演出としてかがり火が用いられ、その利用の利便性のために灯籠が開発されたとも考えられなくもない。ともあれ、神社空間における「灯籠」には未だ意味を見いだせていない。

大同小異、参道を抜けると社殿が姿を現す。神社の社殿は、もっとも基本的な構成としては前室としての拝殿と、後室としての本殿という平面になっている。尤も、社殿と言うよりも祠というようなよりコンパクトなものであれば、素朴な小屋が建っているか、あるいは奇岩や奇景といったものに注連縄がかかっているか、場合によっては小高く盛った土の上にそれらしく鎮座されているだけといったこともある。

ここで注目するのは、きちんと社殿がある場合についてである。拝殿と本殿とは、きれいに中央寄せで前後に並んでおり、拝殿の方がいくつかの儀式を執り行う都合上、本殿よりも一回り大きく作られている。拝殿の中央後方から本殿に繋がる廊下、多くの場合は数段の階段によって本殿と連結されている。この空間は人間が利用することを前提としない、つまり、「神」が行き来するためだけのものであるため、人間的な寸法を持ってはいない。まるで出窓のような大きさの本殿である場合もあるし、より簡素なものでは神棚のように拝殿の内部にせり出してしまっているものもある。これは前述した「祠」のようなものに含まれるとみなして良いだろう。ともあれ、「神」は前室を経由した先の空間に安置されている。この構成は、前述したような女性の膣から子宮にかけての身体的な構成を隠喩したものであり、また、参道から社殿へと至る神域全体の相似形でもある。つまり、神社空間は女性的身体への自己相似的な構成をもっており、高度に数学的な意匠であると言うこともできよう。

現代においては、きちんと整備された社殿を持つ、いわゆる「神社」で祀られている「ご神体」は、ほとんどの場合、くぐもった光を反射する丸い鏡である。一方で、粗末な掘っ立て小屋のような祠――今となってはごくたまにしか見られないが、それでもまだそれなりの数が残っていると思われる――で祀られているのは、不思議な形をした円柱状の石棒や、丸い岩であったりする。それらはひとつだけがぽつねんと安置されている事よりもむしろ複数個がごろりと、半ば無造作に置かれている。大きなものになると祠の中にはなく、祠の外の参道脇にあったり、そもそも屋根さえかかっておらず野晒しにされていたりする場合もある。多くの場合は自然木や自然石であるが、新しいものは人工的に造形されたものであることもある。よくよく見ると注連縄がかけられているものさえある。それらはすべて「男根」もしくは「女陰」を想像させる形をもっている。

(続)

20101203

花園におけるメリーゴーランド的考察 - vol.1

人類が残してきた建築物をたどってゆくと、我々はそこに装飾の歴史を見ることになる。多くの場合それら装飾には意味があり、物語がある。現代のような情報技術が発達していないような時代においてはほとんど唯一といってよいほど、装飾はその社会において生きる人々の情報や知識を継承するための手段となっていた。装飾は建築物の立面においてのみ施されるのではなく、平面であったり開口部をふさぐ窓であったり、あるいは構造体から独立したアイコンとしての物体であったり、安定的に設置されるものとも限らず一時的に設置されすぐ撤去されるものでもあった。多くはその動的な変化にこそ伝達されるべき意味が含まれている。

我々が現在において使っているような数字や文字という抽象的な媒体が存在しなかった時代には、象形文字やヒエログリフのような図像を空間に刻み、あるいはもっと直接的に絵そのものを大きく描くことで物語全体を伝えることも行った。フランスのラスコー洞窟にある壁画には、狩猟の場面や動物を描いた壁画が残されている。ネイティブアメリカンのトーテムポールには、その一族代々の長の歴史が刻み込まれ、文字ではなく口述伝承により語り継がれている。イタリアのルネサンス期宗教絵画においては聖書に記された文字そのものではなく、物語の中のある場面を障壁画によって切り取って見せ、そのインパクトと共に我々に物語を伝える役割を担ってみせた。中国は敦煌の莫高窟においては、仏教の経典に関する内容が極彩色で描かれている。建築空間に意味を包含させた装飾を施すこととなったのは、おそらくは当時、空間が最も長持ちのする媒体(メディア)であったからに他ならないからであり、文字自体もまだあまり定かではなかったような時代においては、場面のイメージである絵としたほうが意味の伝達がしやすかったに違いあるまい。


装飾による情報の伝達といった方法だけではなく、建築自体が持つモニュメンタルな性質によって、ある人物――多くの場合は時の権力者――の権力誇示のための道具としても建築はその役割を担うこととなった。「天下布武」を掲げて安土城を建設した織田信長も、絶対王政を民衆に誇示するためにヴェルサイユ宮殿を建てた太陽王ルイ14世も、あるいは古代エジプトの王たちも、はたまたブルジュ・カリファを建てたアラブの金持ちも、みな考えることは同じというわけである。


建築自体による恣意的な情報操作、例えばファシストらによる建築や、ブルータリズム的な表現による印象操作なども、それによって我々の意志や判断力に対して影響を及ぼし印象を強化しよう意志がそこに介在するという意味において、これもまた先の主張と同じ議論の範疇であると言えよう。つまるところ、建築物を含めたすべての空間構成物が人間に対して刺激を与える装置であると見なす限り、たとえ作り手の恣意性の有無に因らずとも、我々は空間に囚われているのである。

刺激装置としての空間としてよく語られるのは「茶室」であろう。茶の湯の極意は三つあるといわれている。準備を整えて客を待つ「仕度の原則」、くつろげる空間を演出する「しつらえの原則」、ゲームのルールを共有する「仕掛けの原則」である。「仕度の原則」は空間を司る側が提供するプログラムであり、「しつらえの原則」は空間そのものが発揮しうる性能であり、「仕掛けの原則」は空間に参加するもの同士が暗黙的に共有する知識と言い換えても良いだろう。これらの原則は茶室に限らずとも、すべてのよりよき空間の創造において必要なことであると考えられるが、ともあれ、茶室に招く側も招かれる側も、いずれ劣らず高度な知性と教養を要求され、その「ゲーム」を共に達成した暁における相互の充足感、満足感、一体感こそが茶の湯の真骨頂であろう。


翻って、私は「神社」について語りたいと思う。「神社」の原型空間とは、日本列島に土着していた古代の民衆が形成した、「男女和合」に関するコミュニティとシステムを醸成し、促進するための、非常に緻密に計画された空間であると言うこと告発したい。

まず予備知識として頭に入れておかねばならないのは、日本における「神」の系譜は大きく二つに断絶されている。ひとつは天照大神や大国主命らをはじめとする古事記に登場する神々であり、人知を超越した力を発揮する神話の神々である。もうひとつは神武天皇(紀元前6世紀頃)以降の現代に続く天皇の系譜である。現代において天皇はその神格が否定されていることになっているが、それら天皇たちはその存在や年代、役割などがある程度歴史的な資料と共に裏付けられており、神話・伝説的な性格がきわめて薄く、また西洋的な宗教における超人としての「神格」は存在せず、生物学的に見ればごく普通の人間であるに違いない。ともあれ、系譜としてはこのように大別されるし、後者においては大陸から侵略者として渡ってきた朝鮮半島系の血筋であるという指摘もある。

ここで重要なことは、前者の神々はどこへ行ったのかということである。結論から言うと、これらの神々は出雲にまつられている。更にいえば、これらの神々は後の天皇家一族らを頂点とする集団によって放逐されたものと見られている。どういうことかというと、もともと日本列島で形成されていた豪族集団(前期神々)とその集落が、外部(後期神々)からの侵略によって住むところを失い、人を失い、血筋を失った。当時はまだ十分な科学的知識がなかったことから、戦のあとに発生した飢饉や疫病――これらは戦争そのものによって行われた略奪や簒奪、人的な大移動に原因がある――などといった災害の原因をその「怨念」と恐れたため、侵略者の集団は自らの手で殺戮した人々を「神」として祀ったものだといわれている。

自分の手で殺した人々を神として祀る――この不自然さを疑うかもしれない。確かに、優れた業績を残した人を神格化することで、後世に残された人々がその御利益にあやかろうという構図は歴史的にもよく見られる。例えば徳川家康の日光東照宮や、乃木希典の乃木神社、太平洋戦争をはじめとした戦争での戦死者らを祀る靖国神社がよく知られている。一方で「殺した人々を神と祀る」ことについて言えば、藤原猛の論を借りると、法隆寺が大化の改新で中臣鎌足らによって誅殺された蘇我氏一族を弔うために建てられた寺であるという説があり、また俗説的には、板東地方において独自の政権を樹立したことで朝廷に誅殺された平将門の首塚の話もある。話を敷衍すれば、針塚や鋏塚といったように、我々が「破壊」した道具に対してもその考え方は通底しているといえるだろう。

いわゆる町中でよく見かける一般的な「神社」で祀られている神々というのは、後期神々によって放逐された「前期神々」のことである。もう一度整理すると、大陸的な思考や文化をもって侵入してきた実像のはっきりする「後期神々」が簒奪した、日本に土着的に暮らして独自の文化的思考を持っていた実像のはっきりしない「前期神々」が、いわゆる神道における「神々」である。各神社の境内にはその神社の由来が掲げられていることが多いが、そこには国産みの物語に出てくる伊弉諾尊や伊弉冉尊という名前や、八岐大蛇退治で有名な素戔嗚尊や奇稲田姫だとか、およそ現在の日本語の体系とは毛色の違う発音の神々の名前が挙げられている。先に述べたように、民族としての断絶だけでなく、ここには言葉としての断絶、すなわち文化としての断絶があることを改めて認識することができる。民俗学者の柳田国男はこのような人々のことを「非常民」と呼んだ。これは先の「後期神々」によって追いやられた人々に対応し、都市ではなく山野に住んだり流浪の民として生きることで細々と命脈をつないだようである。

もともと人々の往来が激しい大陸とは異なり、日本列島はその孤立した地理、コミュニティ、民族という背景をもっており、そのなかでいかにして効率的で、なおかつ安全に人口を増やさねばならないかということがコミュニティ維持のための重要課題であったということは想像に難くない。近親による交配は遺伝的欠陥を持ちやすいということは経験的に分かっていたことだろう。民俗学者の赤松啓介が指摘するように、「お講」であるとか「おこもり」「夜這い」であるといった民俗的風習は、この課題に対して古代の人々が編み出したひとつの答えに違いないだろう。そして驚くべきことに、つい数十年前、つまりは第二次大戦の戦後あたりまで、このような風習は日本全国に残っていたと言うことである。年長者が年少者の性の手配――場合によっては直接相手――をするということは、実はそこはかとなく現代でも行われているといっても過言ではあるまい。しかしながら近代的な価値観の浸透や児童福祉法や風営法といった法整備によりこれらの風習は廃れてしまったが、もしかすると今もどこかの山奥の村々で密かに行われているのではないかと、つい想像の翼を広げてしまう。

このような風習は、運用をあやまるとムラの秩序を乱す原因になりかねないので、ルールによって厳格に規律が守られていた。実施する時期や年齢、実施に際しての手順など、それらは事細かに決められており、成熟して儀式となった。集団の若者はその手順をきちんと経た通過儀礼を果たすことで、ようやくムラの大人衆として認められた。オトナの役割は大きく三つとであると考えられ、農作業など食い扶持生産の分担、人的資源生産の分担(要するに性交渉と出産育児)、そしてそれらをつなぐシステムとしての民俗的儀式・習慣の維持運営である。重要なのは三点目であり、どのようなムラでも維持運営のための会議を行うために使われるオトナが集まる空間があり、そこは「聖域」として扱われ、若年者のみならず女性さえも厳しく立ち入りを禁じられた。沖縄に「御嶽」と呼ばれる場所があるが、これもその名残であろう。

「儀式」を厳格に実施するためには、それが絶対的なものであるという幻想を集団が共有しなければならない。そのために、「儀式」は何か絶対的な存在――およそ神様的なもの――からの授かり物であるという仮定が置かれた。儀式の聖性を担保するために、それを執行する場は「聖域」であるとされ、その意味的なつながりと管理上の都合により、オトナたちの「聖域」と地理的に関係の強い場所が選ばれた。

これらのシステム全体を統合した空間を設定するために、「絶対的な存在」としては土着の神々(前期神々)が選ばれ、儀式を実施するための場としてそれらの神々を祀る場としての「神社」が選ばれ、儀式を運用するための手続きとして「祭」が定められたのである。

現代において「祭」は太鼓をたたいたりお囃子を奏でたり飲み食いしたりといった具合だが、儀式へと通じる手続きの一つであるという仮定から見ると、そこにある道具や衣装、空間構成といったものがすべてその「儀式」を暗喩した「装飾」であるという解釈に繋がってゆく。つまり、法被などの装束は、およそ薄衣によりできて脱ぎ着がしやすく、身体のラインやペニスの存在が目立ちやすくできている。酒や食い物で腹を満たされたあとは、交合の相手探しのために男女入り乱れて踊り狂う。音曲や火炎により興奮は極度に高められ、意気投合した男女は鎮守の森の夜陰に紛れて交わるのである。


(続)