Archiduino Project - vol.20

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

今回の記事でついに20回目となり、個人的にはひとつの区切りを迎えたように思う。今回の内容は「Eagleをつかった自作Arduinoの回路設計」と「Fusion PCBをつかった自作基板の発注」である。各種センサーのコントロール基板（いわゆるマイコン部分）としての「自作Arduino」の製作は、この内容を持ってほぼ完成であると思われる。これ以降はおそらくそのバリエーションでしかないだろう。

これまではユニバーサル基板やブレッドボードの上に様々な部品配置をおこない、その上でArduinoを走らせると言うことを行ってきたわけだが、その方法に限界を感じるようになってきた。第一に、ダウンサイジングが困難であるということ。第二に、手作業の数が半端ないので時間的なコストが大きいと言うことである。確かにはんだ付けは楽しい、しかしながら、その労力はその楽しさをいつか損ないかねない。プロトタイプの作成段階をとっくに終え、いまや量産の段階に入らんとするとき、やはり方法の変革は必要だろう。

ということで、基板のプリントに手をつけるときが来たというわけである。ちなみに、千石電商などでも感光基板を売っているのを目にしていたが、結局これも道具やら材料やらの手配に時間とコストがかかるので、どうせならPCB（Printed Circuit Board）サービスを利用してやろうともくろんでみた。特に最近話題の「Fusion PCB」なる、中国は深玔にあるというローコストなPCBサービスを使ってみようというわけだ。ちなみにFusion PCBはすでに何度か利用したことのあるSeeed StudioのPCBサービスである。

PCBを利用するに当たり、最初にすべきは発注用のガーバーデータ（部品配置やシルクプリントなどのデータとドリル穴あけ用のNCデータとをひっくるめた意味とする）の作成である。ガーバーデータの作成は、よくわからんけど、とりあえずソフト上で回路図と基板上の部品配置図とを作成してからデータを書き出す、みたいな手順を踏むらしい。というわけで、ガーバーデータの作成の前に回路図を組まなければならない。回路図については、これまでさんざんArchiduinoを作ってきたワケなので、これと同じ回路で良い。というわけで、回路図を組むのにEagleを使ってみることとする。

ちなみにEagleはドイツ製の回路図作成フリーソフト。フリーの状態だと設計できる基板のサイズに制限（50x100mmくらい）があるが、シロウトのDIY程度であればこれで十分だろう。ちなみにEagleのすばらしいところは、回路図を組めば同時に部品の配置図まで作成してくれ（もちろん基板上の最終的な配置は自分でする）、配置を終えれば自動配線機能により最適化された配線をしてくれてしまうというすぐれものである。

世界中のユーザーに支えられているおかげで、Fusion PCBをはじめとして、世のPCBサービスに納品すべきガーバーデータの書き出し設定ファイルが手に入り、これをつかってぽんぽん進めていけば、なにも考えることなく基板発注が終わってしまうと言うわけだ。すばらしいというしかない。

たしかにEagleの操作性はちょっと今ひとつなところはあるが、それはあくまでIllustratorなどと比較した場合であるわけで、不便だなとは思いつつも慣れればたいした問題ではなく、フリーソフトとしては十分な完成度であろう。ちなみに日本語版はなく、有志が日本語化パッチを出している程度なので、その辺の覚悟は必要だろう。

Eagleの使い方についてはまた別な機会に譲るとして、回路図の作成→配置図の作成まで終わったら、Fusion PCBに納品すべきガーバーデータの作成である。これもFusion PCBから公開されている設定ファイルを読み込み、それにマッチするかどうかチェックすれば良いだけだ。不適合な箇所についてはアラートが出るので、主に配線とドリル穴とのクリアランスの問題だと思うが、その部分の修正を行えば良い。アラートが出なくなったら納品できるデータと相成ったわけである。

Fusion PCBへの納品方法は、Seeed Depotで販売されている「Fusion PCBクーポン」みたいなモノを購入し、その購入番号とデータとを先方にメールで送ればあとは中の人が宜しくやってくれるという寸法である。50x50mmの基板（×10枚）で9.9ドル、最も安い郵送方法だと送料が3ドルちょっとなので、トータルでも13.42ドルだ。1ドル87円換算だとすると、1,170円くらい。これで10枚のプリント基板が手に入るのだから、安いと言わざるを得ないだろう。ちなみに50x100mmの場合、15ドル上乗せである。

Fusion PCBに発注し、先方から「under processing」の返信が来たら、後は安心して10日ほど待てば良い。おそらくUPSなどの速達便を使えばもう少し納品が早いのだろうが、発注したモノよりも値段が張るので気が引ける。はやめはやめの発注が肝要だろう。発注して待っている間に秋月などに部品の手配をする（これもネット経由）のがいいだろう。

というわけで待つこと10日。香港ポスト経由で日本郵便が持ってきてくれる。書留である。小さな段ボール箱にエアキャップで梱包されている。このエアキャップ、日本のモノに比べて実に貧相で、ぎゅっと握るだけで相当数が破裂する。ともあれ、開梱、チェック、部品の実装を行い、動作の確認、というわけだ。

Twitterなどを見ると多くの先人たちがFusion PCBをすでに利用しているようだ。なるほどこの手軽さと安さは非常に魅力的である。送料にお金を掛けないと時間がかかるが、のんびり次回作のアイディアでも練りつつ待っているのが良いのではないだろうか。

ちなみに、今回発注したのは2品。ひとつは、これまでのArchiduino基板と互換性のある名刺サイズの基板。もうひとつは、ATmega328を使いつつも最小までダウンサイジングをしたモノとの2種類である。前者は50x100サイズになってしまうのでちょっと値が張る（1枚250円くらい）。後者は右の写真の通りで、2.54mmピッチのグリッドで14x14サイズ（38mm四方）に収め、AC駆動かつXBeeチップを搭載可能な基板とした。これで1枚120円なのだからすばらしいよね。

初めてPCBを利用して強く思ったのは、一度Eagleの使い方を覚え、PCBサービスの利用方法を覚えれば、おなじ「Arduino」という道具でも活用の幅が段違いに広がるということである。例えば、ちょっとした隙間に基板全体を収めなければならない場合でも、そのサイズに合うように回路を設計すればよく、配線が出来ないだとか、基板の大きさが合わないだとかが理由で、もろもろを断念することがなくなるのだ。これはすごい。それから、とりあえず現段階では、はんだ付けという作業は部品の実装だけに限られるわけであり、大幅な労力削減と正確性が確保された。確かにちょっとはんだ付けするに精密さが要求される場面があるが、職人でなければ出来ないというレベルではない。そろそろ各方面にばらまくことも考えてみようか。

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のライブラリはこちらを使用。また、そのほかのライブラリとしてはPStringとXBeeを使用している。

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

Archiduino HUB - ver. 0

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円。

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

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


フィードはこちら。

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

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

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

LEDランタン - vol.1

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



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

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

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

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

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によるマルチホップなセンサネットワークが構築できるはずだ。次回はその実用性に関するレビューについて書いてみようと思う。

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系列しか載せられないだろう。

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

Archiduino Project - vol.14

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

（続）