オープンソースのアクセス解析Piwik

これまでプライバシー・ポリシーとは団体・組織が取り扱う個人情報をどう会員や顧客に不利益を与えない形で処理するかを定めておけばよかったかもしれない。その対象は送られてくる質問、メールや電話、FAX、注文データなどの取り扱いをしっかりしておくということ。厳密に言えば当然Webのアクセス記録やメールのやりとりを記録したサーバーログもそこに入るが、しっかりと運用していれば外部に漏れることはないものだった。

しかし、インターネット上の急激な認証化の動き(具体的にはFacebookやGoogleなどが実名での登録を要求し、その登録規模がかつてないほどの大きなものになったこと)に伴って、その対応も変えざるをえなくなってきている。

たとえば、Webアクセス解析はGoogle Analyticsなどのサービスを使っていれば、誰がどのページを見ている、という情報は自社内で管理はできずに、Google上で把握されてしまう。本来、誰が見ているという情報の部分は追わないというのがあるべきプライバシー・ポリシーであったはずだが、GoogleアカウントやFacebookアカウントと結びつけられることで把握されてしまう可能性は飛躍的に高まっている。

それ以上にFacebookなどとWebサイトを結びつけると逆にこのサイトを支持する、という形で自らを晒していく動きが大きくなっている。これは自分の意志でやっていくわけであり、積極的にこうした人たちと結びついていくことで、その組織の存在が身近に感じられるという効果もあり、今後の大きなトレンドになっていくだろう。正の側面が語られることが多いが、負の側面がないかどうか、今後の議論には十分注目する必要があるだろう。

一方、Google Analyticsなどによって、本人が知らない間に閲覧記録が取られてしまうという問題は検討すべき課題として大きくなっている。

Google Analyticsは無料で提供され、その機能も高く、さまざまなガイドブックも売られているので、トレーニングの負荷も低く、多くの団体で使われている。ユーザーの側でGoogleにアクセス記録を取られないように防御する方法がないわけではないが、基本的にほぼすべての人のアクセス記録はGoogleのデータとして保存される。

これに関してはオープンソースのアクセス解析を使うことで解決することは可能だ。オープンソースのアクセス解析のPiwikは直感的にわかりやすいインターフェースで完成度も高い。しかも、訪問者のオプトアウトも確保しているなど、プライバシーに関する配慮も高い。

問題としてはGoogle Analyticsは日々システムが更新され、新しくなっていくのに対して、オープンソースのシステムは管理者がアップデートしない限り、更新されないこと。またGoogleと基本は同じなので、知っている人にとってはトレーニング不要だけど初心者向けのマニュアルがあるわけではないこと。しかし、後者の問題はPiwikのインターフェースが直感的に理解可能で、Googleのものとほぼ同様に使えるという点で、大きな問題ではない。

プライバシー概念が大きく変わっている中、あるべきプライバシー・ポリシーを確定することは容易ではない。
しかし、楽だからという理由だけでGoogleを使い続けることが許されるか一度考える必要があるだろう。

Piwikをインストールしてみたが、完成度はかなり高く感じた。アクセスがあった地域の情報は国単位ではなく、やはりもっと細かい行政単位で情報が必要だろうが、それはGeoIPのエクステンションをインストールすることで可能(なお、パフォーマンスが要求される環境ではGeoIPのApacheのモジュールをインストールすることが望ましいようだ。今回は省略。詳しくはMod_GeoIP)。

サーバーに1つインストールすれば複数の異なるサイトを解析できて、しかもユーザー権限も個別に設定できるなど、便利である。使い込んでみるともっと別の評価が出てくるかもしれないけれども。

MediaWiki or MindTouch。簡単に使えるWiki的なものないか

TwitterやFacebookのように時系列にデータが並ぶメディアだと大事な情報が過去に流れてしまうので時系列ではない情報の受け皿としてMediawiki(Wikipediaのエンジンのオープンソース版)でやろうと考えた。

しかし、Wikiの文法はくせがある。それをうまく意識しなくて使えるようにしてくれるオンラインエディター(WYSWYGエディター)、FCKeditorを組み合わせればかなり使いやすくなる。

ところがもうこのFCKeditor(CKeditor)のextensionはメンテナンスされておらず、古いextensionは現在のバージョンのMediaWikiでは使えないことがわかった。PHP 5.3へのアップデートあたりの問題が絡んでいるのだろうか。FCKeditorなしのWikiだと使ってもらうのはかなり難しいと思う。

他にもオンラインエディターはあるのだけど、どうも使い物にならない感触。この状況ではMediawiki自身のオルタナティブを考えないといけないかもしれない。でもあのやさしくはないWikiで作れたWikipedia、よくみんな書いていると関心してしまう。

Wikiにこだわらず、WordPressなどのstaticページを使うのも手かもしれないし、その他に使えるものとかあるだろうか?

結局、FacebookとかTwitterしか使ったことのない人に使ってもらえるものと考えるとMediaWikiはきつい。情報オタクにはいいかもしれないけれども。
MindTouchは使いやすそう。ただ、気になるのはオープンソースとして提供されてはいるものの、企業の展開に左右されそう。将来にもオープンソースとして使い続けることができる確実性はMediaWikiの方が上か。

正直言って困っている。何かいいアイデアあったら教えてください。

被災地復興に参加型予算の実現を!

震災地の復興を国がやる、県がやる、というが、しかし、そもそも災害対策をここまで怠ってきた行政にそれができるのか?

国による大規模予算は被災者を置き去りに利権、焼け太りの業者だけを生み出すのではないか?

その不信は今や日本全国に行き渡っている。

それではどうするのか?

被災者自身が予算を決定する参加型予算の大幅な実現だ。

参加型予算はブラジルで特定の政治家が自分の支持を引き替えに特定住民に利益を与えるという癒着をやぶり、コミュニティが必要なものをコミュニティが参加し、自身が決定することで、政治家による買収を不可能にして、必要な政策を実現させる上で大きな役割を果たしてきた。

被災地の人びとのニーズとかけ離れた施設の建設や利権のために金を流すようなことを防ぐためにこれ以上ふさわしいものはないだろう。

被災者に力を。それを政策的に実現する。そのためにも参加型予算の思い切った実現を求めたい。

サーバーのバックアップ

サーバーのバックアップは悩むところだ。公共性の高い、保存価値の高いWebサイトの管理をしていて、もしそのデータが失われてしまったら、とてもまずい。

以前であれば異なる場所にあるサーバー間で重要なファイルを相互にバックアップさせておけばどれかのサーバーがクラッシュしても、重要なデータは失わない、という形でとりあえず十分と思っていたけれども、たとえば自分が急病や事故で動けない状態になった時にアウトになってしまう。不正侵入を防ぐために特定のIPアドレス以外からはサーバーにはログインできないように防御しているので、逆にそれが仇になってデータが取り出せなくなる危惧がある。

高価なバックアップ装置を買ったとしても火事でサーバーごと焼けたらおしまい。またバックアップできていると思って確認したらこわれていて取れていなかった、というケースも結構ある。

そのような場合、またクラウド企業の出番になってしまうのだけど他に解がないので、またもやDropboxを使う。

DropboxはLinuxサーバー上でも使えるのでLinuxサーバーにインストールする手もあるが、常に常駐させておくとメモリー使用量も大きいし、バックアップを毎時やるのでなければ常駐させておくのはエネルギー効率が悪い。

アップデートする時だけ常駐させ、アップデート終了したら終了させるシェルスクリプトを書けばいいかと思っていたら、こんなのがあった。Dropbox Uploader …curlさえ入っていれば動くBashスクリプト。Dropboxをインストールする必要すらない。

まずはバックアップの準備。

#!/bin/sh
tar -C / -czf /バックアップディレクトリ/wwwdata.tar var/www/(backuptarget)
mysqldump -u ユーザーID -pパスワード -x データベース名 | gzip >
/(backupdir)/db.mysql.dump.gz

これでバックアップ対象のHTMLファイルとデータベースがバックアップディレクトリに2つのファイルに保存される。

#!/bin/sh
TODAY=`date '+%d'`
cp /(backupdir)/wwwdata.tar /(backupdir_history)/wwwdata.$TODAY.tar
cp /(backupdir)/db.mysql.dump.gz /(backupdir_history)/db.msql.dump.$TODAY.gz

これでバックアップディレクトリ履歴のディレクトリに www.日付け.tarなどの形式で保存される。以前の状態のデータも1月は保存される(ディスクに容量がなければこの部分は省いてもいいかもしれない)。これはローカルのディスク上でだけ保存して、Dropboxには入れない(容量制限を考えて)。Dropboxには最新ファイルだけ入れる(これだと最新ファイルが壊れていたりすれば終わりなのでもう少し工夫した方がいいかもしれないが)。

#!/bin/sh
echo パスワード | gpg --passphrase-fd 0 --batch -c
/(backupdir)/db.mysql.dump.gz
echo パスワード | gpg --passphrase-fd 0 --batch -c
/(backupdir)/wwwdata.tar
mv /(backupdir)/*.gpg /Dropboxに同期させるディレクトリ

これで設定したパスワードでgpgを使って暗号化される。gpgはLinux版だけでなく、Mac版やWindows版もあるので、どんな環境でもパスワードさえわかれば元のファイルに戻すことが可能。暗号化も不要という場合はこのプロセスも省略可能。

あとは、Dropboxのアカウントを作っておき、curlが入っていればdropbox_uploader.shをコピーして実行する。

シェル上で、./dropbox_uploader.sh と打つと、

This is the first time you run this script.
 Please open this URL from your Browser, and access using your account:

 -> https://www2.dropbox.com/developers/apps

 If you haven't already done, click "Create an App" and fill in the
 form with the following data:

  App name: MyUploader2*********
  Description: What do you want...
  Access level: Full Dropbox

 Now, click on the "Create" button.

 When your new App is successfully created, please insert the
 App Key and App Secret:

 # App key: 

と聞いてくる。シェルを離れて、ブラウザで https://www2.dropbox.com/developers/apps にアクセスし、”I agree with the Dropbox Developer terms and conditions.” をチェックして、Submitボタンを押すと、App name: を聞いてくるので上記のMyUploader2***….をコピーして入れて、Descriptionには自分のサーバーのバックアップだということがわかる文章を入れ、Access levelの選択をFull Dropboxの選択をする。そうすると、App key と App secretを表示するので、それをシェルに戻り、入力する。そうするとシェルの方で、
https://www2.dropbox.com/1/oauth/authorize?oauth_token=********
にアクセスしてAppをDropbox側で承認するように求められるので、ブラウザ上でこのURIを開く。承認ボタンを押せば、設定終了。

あとはとっても簡単

sh dropbox_uploader.sh upload ./Dropbox/*

これでDropboxに保存される。

上記のスクリプトを適当に作って、crontabに登録し、毎朝3時とかサーバー負荷が低いと思われる時に自動実行するように設定しておけばいい。

この方法の助かることはバックアップが無事行われているかオンラインであればどこでもチェックができる(サーバーに装着されたバックアップ装置のチェックよりもはるかに楽)。

もっともバックアップされたファイルの内容が想定している状態になっているかはファイルをダウンロードして確認することは必要だろうけれども。

あとは自分以外でサーバー管理できる人とパスワード情報を共有する必要がある。問題は共有してもサーバーを復元することのできる人がそういないことかもしれない。ただ、できる人が見つかればサイトは復元できるはず。

Piwigoのカスタマイズ

写真のオンラインギャラリーを実現するオープンソースのサーバーアプリケーション、多数あるけれども、ざっと調べてみて、Piwigo (http://piwigo.org/)が柔軟性も高く、しかもコミュニティの活発さもあって、よさそうだということでインストールしてみた。

MySQL5とPHP5が使えればインストールはきわめて簡単。
写真のアップロードは複数ファイルをまとめてWebインターフェースを通じてすることもできるし、Windows、Mac、Linux対応の専用ソフトpLoaderを使って透かし(watermark)を入れつつアップロードという芸当もできる。

写真の分類は1つの写真を複数のアルバムに入れることができ、しかもアルバムは階層構造、つまり入れ子にできるため、極めて柔軟にフォトライブラリーを構築することができる。

ユーザーごとに権限を指定できる(ただし、顧客によって個別の高解像度を提供したりしなかったり、というような高度な制御は標準機能では無理そう)。

Extensionが多く開発されていて、Facebook、Twitter、Google+などのお馴染みのものはもちろん、たとえばアップした写真をWordPressで表示するとか、ページを完全に多言語対応にするものや、PayPalでの支払いを実現するExtensionもある(PaypalやWordPressのケースはどこまで使えるかはまだ未確認)。

デザインはテーマとしてすでに開発されているものをダウンロードして利用することができる。CSSでのカスタマイズもLocalFiles EditorというExtensionを使うと、ブラウザー上で簡単に書き換えられる。簡単に静止ページを作るExtensionであるAdditional Pagesも便利。

3つの異なる用途にさっそくインストールしてみたが、異なる用途に対応する柔軟さがある。

特にExtended Descriptionは多言語化を可能にするExtensionで、多言語化が不可欠な人には非常に魅力なので、少しメモしておく。

多言語化対応にするExtended Description

Piwigoのメニューは多言語対応している(45言語![追記]Piwigo 2.3.3でエスペラントが加わり46言語になった)ので、Language SwitchというExtensionを有効化すれば、メニューはすぐに多言語対応になる。

写真のデータやアルバムの表記は基本的に1つしか入力項目がない(データベースの入力項目が1つずつしか存在していない)が、このデータを[lang=defalut]デフォルト言語用[/lang][lang=en]英語用[/lang][lang=ja]日本語[/lang]などという書式で書くことで多言語化するのがこのExtension。

ブラウザーのデフォルト言語の表記が表示され、またLanguage Switchのアイコンで切り替えることでブラウザの設定にはない言語に変更することもできる。

データの入力スペースは言語別に書く欄が分かれておらず、1つの欄に複数の言語のデータをタグと共に入力しなければならないので、入力の手間は大きくなり、管理画面からデータの視認性も少し落ちるが、多言語で組みたいという場合は大きな威力を発揮するだろう。

こうしたすぐれたシステムを見てしまうと、それを使って何か作ってみたくなる。それくらいおもしろい。

その他、いくつか、使う際にカスタマイズする必要を感じるので、そのやり方を記録しておく。

日本語の言語設定のアイコンが日の丸になってしまうことを修正

多国語切り替え(Language Switch)を有効化すると、日の丸が日本語表示のマークになる。
こりゃいやなので、
Piwigoインストールしたディレクトリ/language/ja_JP/ja_JP.jpgを書き換える。

アルバムの領域がクリックできるようにする

トップのページからアルバムをクリックする際、アルバムの文字やサムネイルの写真はクリックできるが、その他の部分はそうではない。アルバムが表示される領域はマウスでポインターを持って行く(hover)で色が変わるので、あたかもその領域をクリックすればそのアルバムが表示されるようになっているように思える。しかし何も変わらないため、人によってはそこから先に行けないと思ってしまうかもしれない。

そこで、文字・サムネイル画像以外のアルバムの領域をクリックしても当該アルバムに飛ぶようにjQueryを使って改造する。

Piwigoのインストールディレクトリ/themes/default/template/header.tpl
{get_combined_scripts load=’header’}
の下に以下を書き加える。

{combine_script id='jquery' path='themes/default/js/jquery.min.js'}
{literal}
<script type="text/javascript">
$(function(){
$(".thumbnailCategory").click(function(){
window.location=$(this).find("a").attr("href");
return false;
});
});
</script>
{/literal}

これでアルバムをクリックすれば飛んでくれるはず。

高解像度の写真はダウンロードのアイコンクリックに限るように改造

高解像度が許可されたユーザーに対してはWebページの写真(サムネールよりも大きな個別の写真ページで表示される写真)をクリックすると高解像度の写真が出るようになっている。

しかし、この方法だと高解像度の写真をダウンロードした人が把握できなくなる。高解像度の写真をダウンロードした人をアクセス解析(History追跡機能)で把握したい、しかし、管理者だけは写真クリックで高解像度の写真を表示できるようにという団体のニーズに合わせるため、ソースに手を加えた(管理者には可能にしたのは高解像度の写真のURLが管理者にはすぐにわかるようにするため)。

インストールディレクトリ/themes/default/template/picture_content.tpl
のファイルを書き換える。下記で
{if isset($U_ADMIN)}
{/if}

でくくったところがそれ。

{if isset($high)}
{combine_script id=’core.scripts’ load=’async’
path=’themes/default/js/scripts.js’}
{if isset($U_ADMIN)}
<a href=”javascript:phpWGOpenWindow(‘{$high.U_HIGH}’,'{$high.UUID}’,’scrollbars=yes,toolbar=no,status=no,resizable=yes’)”>
{/if}
{/if}
<img src=”{$SRC_IMG}”
style=”width:{$WIDTH_IMG}px;height:{$HEIGHT_IMG}px;” alt=”{$ALT_IMG}”
id=”theMainImage”
{if isset($COMMENT_IMG)}
title=”{$COMMENT_IMG|@strip_tags:false|@replace:'”‘:’
‘}” {else} title=”{$current.TITLE|@replace:'”‘:’ ‘} – {$ALT_IMG}”
{/if}>
{if isset($high) }
{if isset($U_ADMIN)}
</a>
<p>{‘Click on the photo to see it in high definition’|@translate}</p>
{/if}
{/if}

日本語に対応していないExtensionを使う場合

Piwigoインストールしたディレクトリ/plugins/プラグインの名前/language
の下に ja_JP というディレクトリを作り、たぶん存在しているだろうen_USかen_UKのディレクトリーの中味をコピーした上で、plugin.lang.phpなどというファイル名のファイルを翻訳していく。
書式は
$lang[‘Top’] = ‘Top’;
のようになっているので、
$lang[‘Top’] = ‘トップ’;
としてやればいい。

オープンソースの精神に立てば、使う以上、日本語対応させた時はそのプラグイン(Extension)の作者に日本語の翻訳ファイルを送って貢献すべきだろう。しかしものによっては大量の翻訳になるので、全部やろうと思うと大変になることもある。

Extension download_multiの翻訳を修正する

アルバムごとや個々の写真をまとめてダウンロードできるExtension、Download_Multi、便利なプラグインだが、管理画面が英語を選択しても、フランス語のまま。これも上記の方法で、ja_JPディレクトリーを作成して、そこで翻訳すればいい。実はen_UKの翻訳セットは準備されているのだけど、管理画面のところはフランス語のままになっているので、言語設定を変えても管理画面は変わらない。

download_multi/language/ja_JP

download_multi/language/en_UK
の内容をコピーして、フランス語になっているものを日本語にしてやればいい。なお、グループは複数選ばなくても、Ctrlを押して指定してやらないと、選択したことにならず、エラーが出て、いつまでたっても設定できないことになってしまうので注意が必要。

翻訳の足りない部分、おかしい部分

バッチ・マネージャーで下記の翻訳が足りないのでlanguage/ja_JP/admin.lang.php に追加。
$lang[‘The whole page’] = ‘このページすべて’;
$lang[‘The whole set’] = ‘すべての写真’;
$lang[‘Who can see this photo?’] = ‘この写真の閲覧許可対象’;

同ファイルで
s/アックション/アクション/ ←アックションと書かれた部分3カ所一括置換
s/アドミニ/管理ページ/

日本語で問題になるかも=メール文字コード

コンタクトフォーム用のExtensionはあるが、日本語用のメールのExtensionは存在していないので、メールの文字コードはUTF-8になる。今時、ほとんどのメールクライアントはUTF-8は読めると見なせれば問題ないが、そうでない場合、文字化けする。

気になる人はExtension作るしかない。

使用しなかったExtension

LMT
著作権を選択して表示する。よくできているが、単に著作権の種類を表示するだけでなく、カメラマンの写真を預かるような場合、著作権者の名前を保存しなければならない場合、Piwigoのauthorとは別にデータを保存することになってしまい、煩雑になるので、利用をあきらめた。写真によってCreative Commonsの異なるレベルやCopyright (CopyLeft) を使い分けるという時は威力を発揮するかもしれない。
Extended_authorとCopyrights

著作権者をプルダウンで選択できると思ったのだけど、うまくいかなかった。あらかじめ著者情報を入れておけばよかったのだろう。今後使ってみようと思うが、個人的なメモとして残しておく。

いずれにしても、写真を効果的に共有したいという場合にはひじょうに使えるシステムであると思う。今後の発展にも期待したい。

追記: タイトルバナーにHomeへのリンクを追加

タイトルバナーにHomeへの戻りのリンクがないのは使いにくい、ということで

themes/default/template/header.tpl に下記のリンクを追加。こうすると管理画面で書き込むPage bannerの文章にまで同じリンクがかかってしまう(Page bannerで書き込む文章を</a>で始め、その続きの文章のどこかにリンクを設定して最後の</a>を省けば、ちょうどうまく行くんだが…)。またリンク文字の色はテーマによって決めさせた方がいいからここでstyleで書くのは御法度だろうが、何と書けば正解なのか今わからないので暫定的に。

<div id=”theHeader”><a href=”/photos/” style=”text-decoration:none;color:white”>{$PAGE_BANNER}</a></div>

Piwigoに関する情報

:
Piwigo Website: http://piwigo.org/
Twitter: @Piwigo

遺伝子組み換え大豆に追い詰められる南米先住民族 ブラジルを中心に

PARC先住民族チャンネル】オープン記念セミナー <脱成長・脱原発の時代と先住民族の暮らし> 2012年1月21日 アジア太平洋資料センター(PARC)で遺伝子組み換えと南米の先住民族の問題について話させていただいた。

同時に上映させてもらったビデオ、Killing Fields (Ecologist Film Unit / Friends of the Earth、日本語字幕GreenTV) 第一幕第2幕ビデオの方はヨーロッパから見た遺伝子組み換えが主題で、特に第2幕の最後の方はかなり主題から逸れてしまうのだけど、日本語の字幕の入ったビデオがほとんどないので、これを使わせてもらった。

急激な遺伝子組み換え大豆栽培の増加によって南米の先住民族や自然が痛めつけられている。日本もまたそれに無関係ではない。

PARC先住民族チャンネル

iPadでレイアウトが崩れる

WordPressでサイトを構築していて、他のブラウザーでは問題が起きないのに、iPadでだけレイアウトが崩れるという現象が起きた。

メインのコラムに右にメニューを置くタイプのレイアウト。他のすべてのブラウザーで想定通りに表示されるのに、iPadだけはメニューが右の位置に入らず、メインのコラムの下に来てしまう。

CSSのwidth、paddingやmarginの設定の問題かと思ってチェックしてみたけど、どうも違う。

相当時間がかかったけど、問題は Viewport の設定であることが判明

このタグをコメントアウトしたら正常に表示された。
横幅が広くないサイトでは問題は起きていない。
仮説だけど、iPadのViewportは980pxであり、1000px超す場合は上記の指定ではおかしくなるということだろうか。

iPadに対する最適化まで余裕が持てないので、とりあえず、上記タグの無効化でよしとしておく。

放射線測定:高い場所はどこだ?

放射線測定 @砧公園 正面煙突は清掃工場の焼却炉の煙突松戸市役所が貸し出すHORIBA PA-1000Radiで松戸市上本郷の放射線測定したら、雨樋の下など2.5μSv/hという高い値が出た。そこでRADEX RD1706を入手し、世田谷区砧公園周辺を測定してみた。

砧公園はすぐ側に焼却所もある(左写真。目の前の煙突は清掃工場の焼却炉だ)。しかし、値は思ったより低く、0.08μSv/h。公園で落ち葉の上ではしゃぐ子どもたちの姿を見て、「落ち葉には放射性物質がついているから、子どもたちが被曝してしまう。でもよその子に遊ぶなとは言えないし」と暗澹たる気持ちになっていたが、一面、落ち葉が厚く敷き詰められているような場所の地面すれすれを測定しても、値は0.08〜0.12。落ち葉のないところ、あるいは地面から1m離れたところの空間線量と大きな違いがない。道沿いの排水口もそれほど高くはなかった。

0.114μSv/hでほぼ年間1mSvとなる(0.114μSv/hx24x365=998.64μSv/y)。このRD1706はγ線だけでなく、β線も関知するということで高めに出るという。

放射線測定 花壇の枠の中何カ所も計ったが風通しのいいところでは高い放射線量は測定されなかった。しかし、風のふきだめとなるような風をブロックするような場所では放射線量は高い。

右の値は0.32μSv/h。0.30μSv/hでアラーム音が出る設定になっているため、時折、アラームが出た。あちこち、計るうちに、ここは高そうだ、と予測がつくようになってくる。

上の写真と同じ場所世田谷区砧公園周辺では風通しのいいところで放射線量の高いところは見つからなかった。しかし、風通しが遮られるところでは、放射線は高いところがある。風通しが悪そうなところはすべて高いかというとまたそうでもないのだが。

落ち葉をすべて隔離するとなれば保管場所が大変だ。しかし、実際に危険な値を示すのはすべてではない。測定しながら実際に危険で隔離しなければならない落ち葉は世田谷区のレベルではかなり限定できそうだ。それを隔離することで効果的に危険を減らせるだろう。

また外で子どもが遊ぶ時は、風通しのいいところで遊ばせて、吹き溜まりのようなところには近づかないことを徹底すれば子ども被曝は減らせるだろう。犬の散歩でも吹き溜まりのような場所はできるだけ避けた方がいい。

実際に測定することで、放射性物質がどんな場所に蓄積していくのか、イメージできてくる。それは落ち葉よりもはるかに軽く、風で移動してしまう(高汚染地域ではすでに落ち葉や樹木、土壌やコンクリートに深く放射性物質が入り込んでしまっているだろうから、状況は地域によりかなり違うだろう。松戸市では剪定した樹木はすでに高い放射性物質が付着しているため、焼却も不可能、隔離の処理となっていると聞く)。

それだけ軽いものであれば、窓を開けたり、衣服に付着する形で室内に入っていくことは十分想像できる。そして、室内の暖房などで室内を回流するだろう。蓄積する一方になっていくと考えると危険だ。これに対しては空気清浄機が相当役立つだろう。測定するまで、空気清浄機が役立つというイメージがわかなかったのだけど、この結果を考えれば放射性物質は室内の空気の移動でも必ず動くはず。空気清浄機をその対流の中に入れておけば、確実にそれを捉えるはずだ(HEPAフィルターなどは放射性物質の除去に期待できる)。

室内の水拭きが奨励されていて、やらなければとも思うが、水拭きできないような場所もあるし、日常生活を送っていく中でなかなかやろうと思ってできないことも多い。でも空気清浄機を回すことは実践しやすい。安価なものも最近は出ているし。

世田谷区の放射能汚染も決して安心できる状態ではないだろう。特に子どもはもっと放射線量の低い地域に避難できれば避難することが望ましいと思う。決して、こうすれば世田谷でも安全というつもりはまったくない。また瓦礫焼却によって事態は急激に悪化する可能性もある。しかし、生活する以上は放射線量を量り、その危険の度合いを把握することは大いに勧めたい。