男鹿半島周辺の不思議な地震

何を暗示しているんだろう。東北地方太平洋沖地震はM.9.0の超巨大地震だったが、その破断面からはるか遠くで大きな地震が起きている。秋田男鹿半島周辺と長野だ。この中で私は男鹿半島周辺の地震が気になってしょうがない。それは、男鹿半島が日本海に突き出しているからだ。

地形には意味がある。ちょこんと日本海に突き出している場所で、太平洋側の超大型逆断層型地震のあとに正断層型の地震が起きている。何かその地形を作った根本的な要因に関連がありそうではないか。

実は、男鹿半島は日本海に浮かぶ火山島だ。たまたま陸地と繋がっている。日本海には本州側と一定の距離で島が並んでいる。佐渡、能登、隠岐、玄界灘の小島などだ。これらのうちいくつかで重要な火山岩が産出する。「アルカリ玄武岩」だ。

岩石が熔けてマグマになるには3つほどのファクターがある。温度、圧力、そして水。温度が上がれが当然岩石は熔ける。同じ温度でも圧力が下がればやはり岩石は熔ける。水は岩石の融点を下げる。

岩石の温度を上げるのは岩石中の放射性物質と地球のより深いところから上がってくる熱も要因のひとつだ。(プルームと言う地球深部からの熱上昇が主要因とされているのかな。)　圧力は上部マントルのテクトニックな構造、つまりプレートの動きやぶつかり合いで変化する。水はプレート境界で沈み込んだ岩石から供給される。

日本の地下では太平洋側からたっぷりと水成分を"含んだ"岩石が沈み込んでおり、ある程度の深さに達すると陸側のマントルにそれが供給される。陸側のマントルでは岩石が部分的に熔融して上昇し、比較的地表近くの地下にマグマ溜まりを形成する。マグマはここでゆっくりと冷やされるうちに晶出する鉱物によって成分を変化させる。何らかの圧力的な要素が加わって地上に噴出するのが火山噴火だ。

マグマ溜まりでよく分化や混合が進むので、日本には安山岩質、花崗岩質の火山が多い。分化が進まないうちに噴火すると玄武岩質のマグマが出てくる。東京のそばでは富士山や伊豆諸島が玄武岩だ。

しかし、日本海に並ぶ島々に出ているアルカリ玄武岩はちょっと毛色が違う。アルカリ岩と分類されるマグマは、海洋プレートや30kmとか50kmのという非常に深い場所で生成される。日本海側に見られるアルカリ玄武岩は、分化のまったく進んでいない状態で地下深いところから一気に上がってくる。「一気に」というのは相当の勢いをもってということだ。そのため、そのマグマの通り道にある岩石を削りながら熔かさずに巻き込みながら数十kmを駆け上がって噴出する。そのため、冷えて固まるとマグマの中に地下で削ってきた岩石のかけらがそのまま含まれているのだ。

これは激烈な現象だ。なんでそんな激烈な現象の跡が日本海にあるのか不思議だったのだが、今回の男鹿半島周辺の地震ではっとした。日本列島は通常太平洋側からの強烈な押しの応力に支配されている。ところが太平洋側の広い範囲で開放されると、今度は逆に引きの応力が広範囲に働くのだそうだ。これが正断層を生む。引きの応力にはむらがあり、男鹿半島には力が集中したものと思われる。

男鹿半島周辺で発生している地震の震源は浅い。しかし、応力変化は深い部分にも及んでいるのではなかろうか。深い部分での圧力開放はアルカリ玄武岩質マグマを生むきっかけとなりそうだ。

男鹿半島でアルカリ玄武岩が最後に噴出したのは6万年も前のことらしい。しかし、アルカリ玄武岩の噴出が稀なことならば、1000年に一度とも言われるM9.0の地震が、さらに稀な現象を誘発させないとは言い切れないのだと思う。最近の研究でも地震と火山噴火との密接な関係が明らかにされてきている。太平洋沖の地震が男鹿半島周辺の地震を引き起こした、ということは男鹿半島の地形を構成する火山が太平洋沖の地震と関連性があるという可能性は十分考えられる。

じゃぁ結局どのくらい被曝覚悟すりゃいいんだ

もう報道される単位がめちゃくちゃでどうしようもない。いろんな単位が出るもんだから値の大小は混乱するし、受ける影響なんて何を言われているのかさっぱりわからない。というわけで、全部シーベルトにシーベルトってことだ。なぜか？　それが曝露した放射線の人体への影響を測る単位だからだ。


全部がシーベルトの値で示されれば、被曝量はカロリー計算のように足し算のみでわかる。一日の被曝量が抑えられれば情報に惑わされることはないのである。


重要なのはベクレル(Bq/kg)からシーベルト(Sv)への変換。ここで注意が必要だ。ベクレルの値は放射能がその時点でどれだけの放射線を出すのかを示すもので時間的な変化は表さない。同じ100Bq/kgでも、半減期の異なるヨウ素131とセシウム137とでは単位時間あたりの放射線量は異なるということだ。半減期の圧倒的に短いヨウ素131の方がセシウム137に比べ短い時間で放射線を出しつくすので影響は大きいのだ。　同じ100Bq/kgでも、半減期の異なる要素131とセシウム137とでは崩壊速度が違うので、放射性物質の全体量は半減期の長いセシウム137の方が断然多いのだ。


また、食物として摂取した場合、体内にどれほど吸収され留まるのか。代謝で排出されるまでどのくらいの時間がかかるかによっても放射線の影響は異なる。(経口摂取と吸引摂取とでも異なる。)


よって、ベクレルで発表された数値をシーベルトに変換するには複雑な計算をしないと求めることができないが、これまでの研究の積み重ねにより放射性物質ごとに算出された係数がある。それが実効線量係数だ。この係数のおかげでベクレルからマイクロシーベルトへの変換は掛け算だけで良い。

物質名	実効線量係数
ヨウ素131	0.022
セシウム134	0.019
セシウム137	0.013
ストロンチウム90	0.028

もっと詳しい表



100Bq/kgのヨウ素131の水を300ml飲んだ場合、水は1リットルが1Kgなので

　100Bq/kg × 0.3kg × 0.022 = 0.66 μSv

今回の事故の影響で年間に増加する被曝量を1mSvに抑えたいなら

　1mSv ÷ 365days = 2.7μSv/day

なので、300mlの水を飲んでもあと2.04μSvを他の食品から摂取したり、体外被曝しても大丈夫ということになる。


4月28日追記

ベクレルからマイクロシーベルトに換算する際には係数をかけるんだけど、この係数には体内半減期の要素が加わっている。つまり、体内にあるベクレル数の放射能が取り込まれてから体から排出されるまでの被曝量がμSvに換算されるからμSv/dayとして足し合わせるのは本来厳密じゃない。例えば10Bq/litterのI-131を含む水道水を2リットル飲んだ時0.44μSvと換算されるが、これは1日の被曝量ではない。ただし体内には1年以上留まらないので、年間の線量規制値1mSvを一日当たりに直した2.4μSvと比較する際、1日の外部被曝量と足すのがわかりやすい。

200Bq/litterのI-131を含む水を一時的に2リットル飲んでも、体外排出されるまでのトータルの被曝量が8.8μSvだが、1日あたりの被曝量は1μSvにも満たないはずだ。なので毎日飲み続けなければ影響は極めて小さい。「飲まない方が良いが飲んでも問題ない」という意味はこれ。なので、毎日の被曝量を意識していれば、たとえ少々放射能が多めのものを口にしたとしても、体への影響はほとんどないと思っていい。重要なのは続けて毎日とらないことだ。

2012年9月3日追記

ベクレルについて、明らかに間違った解釈をしていたので訂正した。斜体で本文に追記した。

武田邦彦先生に聞いてみた

福島原発事故の放射能のことだ。ニュースではヨウ素131が基準値の何倍でセシウム134と137が基準値の何倍検出されたとか、ヨウ素131は半減期が短くて8日だが放射性セシウムは30年だとか、そんな情報が断片的に報じられる。だが、検出量や半減期が今後自体の成り行きにどう関わる情報なのかは見えにくい。

そこで、今や「ほんまでっかTV」のレギュラーである武田邦彦先生に、以下のような質問をしてみた。

武田先生

ブログを読んで勉強させていただいております服部と申します。
わかりやすくタイムリーな解説をありがとうございます。

ひとつ質問をさせてください。

現在原発から放出されている放射性元素はどれもウランの崩壊によって生じた副産物だと理解してます。現在、制御棒を挿入したことによりウランの核分裂反応はすでに止まっているとすれば、次のように考えてよろしいのでしょうか。

1. 副産物の放射性元素は、これまでに漏れたものと現在原発内に蓄積されている
   もの以上に、新たに生成されることはない。つまり放射性物質の全体量はもう
   確定している。
   
   
2. ヨウ素131の半減期は放射性セシウムなどにくらべ極端に短いため、原子炉に
   現在入っている燃料棒以外の長期保存されていた使用済み核燃料棒内に残存して
   いる量は少ないはずである。
   
   
3. 長期保存されていた燃料棒内から漏れる放射性物質はセシウムなど半減期の
   長いものの比率が多くなるはずである。
   
   
4. 現在漏れているヨウ素131は主に原子炉内の燃料棒由来である。
   
   
5. 長期的に見ると放射性のセシウムやストロンチウムなどの漏洩量が環境影響
   を考える意味で重要である。
   

果たしてあの原発には、MAXでどれほどの量の放射性セシウム、ストロンチウムが見積もられているのでしょう？？？
服部

数分もしないうちに先生から返答をいただいた。

まさにその通りなのです。現在少しずつ放射線量等が出ていますが、実は原発が事故を起こした時にどのくらいの放射性物質が出るかということを予想ができるのですが、今のところテータがちょっと不足していて、わたくしの方では、なかなか正確な数字が出ませんが考え方としては全く正しい考え方です。しかしこのような収支計算のようなものはなかなか一般的ではないようです。 武田邦彦　中部大学

武田先生のブログでは、今回の事故とそれに関わる報道についての有益なコメントがまとめられている。

4月28日　追記-+-+-+-+-+-+-+-+-+-+-+-+-

4月9日のasahi.comの記事によれば、停止直後の原子炉には5,900,000TBqもの放射能があったという。そのうちの9割が放射性ヨウ素だ。テラベクレルは1,000,000,000,000ベクレルなので、5.9 x 10¹⁸ Bq。10の18乗！

日本語ブルース

つくづく、コンピューターは日本人に使いにくいなぁと思った話。TranscendのMP3プレーヤー、M330っていうのを買ってみた。iTunesに入っているアルバムのいくつかをAmadeus Proというサウンド・エディターの変換機能を使ってmp3にしてこのM330にコピーしたところ、まぁ何の問題もなく再生され、再生中のファイル名も表示された、の・だ・が・・・・　曲のタイトル、アーティスト名、アルバム名が文字化け表示！

ははぁーん、これはID3タグがちゃんとしてないんだな、と思い、ID3タグ編集用のTagr.appってフリーソフトをダウンロードしてきっちりと入れなおしてみた。でも治らない。

mp3ファイルはもともと音楽をMPEG1 Layer 3という形式でエンコードしたサウンド・ファイルだったが、MP3プレーヤーのソフトやハードがどんどん登場して、ファイル交換時に曲名やアーティスト名も一緒に受け渡せるようにフォーマット拡張されたのが"ID3タグ"だ。コンピューターの世界で多国語対応が標準的になったのはWindows 2000、Mac OS Xになってからである。ID3タグが出た段階はまだWindows 98、Mac OS 8の時代、当然日本語のことなんて考えられていない。また、当時のパソコンの日本語コードはShiftJISだ。日本語化といえばShiftJISが採用されるのが自然の流れだった。ちなみにインターネットで使用される日本語コードはいわゆる7bit JIS＝ISO 2022JPだった時のことだ。

OSがネイティブに多国語されるのはその数年後、そしてそこで採用されたのはUnicodeである。UnicodeにはUTF-8とUTF-16があるのだが、ID3タグの多国語対応時に採用されたのはまずUTF16で、最新版でようやくUTF8がにも対応した。(ちなみにUTF-32もある。)

しかし、同じ文字を表すのになぜにこうも異なったコードが乱立してしまったんだろう。コンピューターの処理能力とともに歩んで来た歴史の積み重ねというのは重々承知している。だが、英語圏ではこんなにも使い分けやプログラム実装に悩んだりする必要がないことを考えると、日本人はそれだけで重たいハンディを背負っている。

JIS、ShiftJIS、EUCの使い分けがUnicodeの登場で簡単になるのかと思いきや、またもやUTF-8とUTF-16で悩まされるのか。複雑化する一方だ。普段、ユーザーとしてパソコンを使う分にはそれほど気にすることはないにしろ、文字化けなどに遭遇したとき、突然にこのあたりの知識を要求されるのがキツい。

ASCIIを使っている連中は文字化けという現象に無頓着だ。したがって、ID3編集ソフトを作った人も「文字コードの変換」なんて機能は実装してない。Tagr.appがまさにそうだ。OSがサポートしてる文字コードをファイルに書きこめばいいだけなんだから。

で、先のMP3プレーヤーでの文字化けの問題、ID3タグにUTF-8で日本語が書かれていたことで発生していた。この問題を解決できるのは日本人が作ったソフトしかないのはあたり前で、そういうソフトはMac用には見つからず、いろいろ試してようやく"Super TagEditor"というWindows用にたどり着いた。動作がいまいちなんだけど、なんとか無事に文字化けは解消された。

今回の件で、mp3のID3タグのことについて短期集中で勉強した。だが、iTunesとiPodを使っている限りこんなことは知らなくていいことだし、問題は特殊なことをやろうとしない限り顕在化しない。知識はあっても、それが金にならないという典型的なパターンだから悲しい。最終的にブログでぼやくわけだが、これすら時間の浪費でしかない。

iPhoto 9.1.1 (iLife '11) でプリントができないなら Themeを消して再インストール

またまたiPhoto 9.1.1でトラブルに遭遇した。最近はめっきり写真をプリントすることがなくなったのでいつからこんなトラブルがあったのかわからないんだけど、写真を選んでファイル・メニューから「プリント」を選ぶとアラートが出て

「利用てきるテーマが見つかりません。: テーマが見つかりませんでした。少なくとも1つのテーマがインストールされるまでは、この機能は使用できません。」

と言われる。こ、これはAppleのHuman Interface Guidelinesで「ダメ」とされてる「A poorly written alert messages」にちょっとばかし説明を加えた程度のひどいアラートだ。テーマをどうしたらインストールできるのかがわからない上、「OK」を押してプリントをやめるしかない。

そもそもテーマってなんだよ。ってことでiPhotoのヘルプを見ようとしたら

「HVURLHandlerErrorDomain エラー 1002」

これまた完全な「A poorly written alert message」が堂々と登場。結局頼れるのはGoogle様ということで解決法を探った。

まずはプリントが出来ない件。

• "/Library/Application Support/iPhoto/Theme" を削除
  
• ”/Application” からiPhotoを削除
  
• iLife '11のディスクからiPhotoをインストール
  
• iPhotoを最新版にアップグレード
  

これで解決。iLife '11のディスクでインストールされるのがiPhoto Ver.9.0の場合、立ち上げるとライブラリを消してしまうバグがあるようなので、立ち上げずにどんどん最新版にアップデートした方が良いだろう。私の場合、TimeMachineでバックアップがあるので躊躇せずに再インストールしたが、一般的には"~/Pictures/iPhoto Library が消えないようにバックアップしておいた方がいい。

次、ヘルプが出ない件。

• "~/Library/Preferences/com.apple.help.plist" を削除
  
• 一旦ログアウト
  
• 再度ログイン
  

で解決。このヘルプの問題は日本だけで発生する問題らしい。Appleの開発とQAはほぼCupertinoで行われているので、アメリカ人から文句の来てないようなバグは、知らないので対処されないまま放置されてしまうみたいだ。

「昔日の客」とメディアの価値

元大田区役所のあったあたり、大森日赤前のバス停のすぐ目の前に「山王書房」という古本屋がかつてあった。子供の頃から小説など全く読むことのない私には縁のない店だったが、となりの叔父などはよく行ってはそこの主人の長話につかまってたらしい。叔父の家にはいまでもそのお宅から年賀状が届くという。私の父も入二の教師をやっているころに寄ったことがあると言っていた。

その山王書房の主人によるエッセイ集がこの「昔日の客」だ。著者は残念なことに本書の初版が出版される前に60歳にも満たない生涯を終えている。昭和53年に出版されたこの本はしばらく絶版状態だったが、昨年(平成22年)に若干の手直しがされた上で復刻した。たかが大森の古本屋の主人が書いた本なれどこの本を求める人はそこそこあったようで、手元のものはすでに第二版となっていた。

昔の馬込の様子などが綴られているというのが本書を手にした動機で、私自身は特に文学に興味があるわけではない。なので、本書に登場する作家については何ひとつ知識がないままに読んだ。文章も読みやすく、この古本屋の主人の変人ぶりと書籍への愛情、作家への尊敬がにじみ出ていた。作家と読者をつなぐパイプ役として、双方から愛されていた様子も伝わってきた。

私が子供の頃は、うちのそばにも「貸本」をやっている馬込書房という店があった。バス通りに市場があって、その日の夕飯の買い物はその日にしていた時代だ。世の中はこのあと加速して変化して豊かになっていくのだが、当時、本は「貸本」で読むほどに庶民にとって高額なメディアだったのか、と改めて思う。当時子供で自分でお金を出して本を買うことはなかったので、実感としてはよくわからない。でもそうだったに違いない。「古本」の商売もそんな時代だったからこそ成り立っており、どれだけ良い本を揃えることができるかは、古本屋の主人の目利きにかかっていた。

「昔日の客」を読んで驚くのは、大森駅からさらにバスに乗らないと来られないような場所にある古本屋に、吉祥寺やら藤沢やら遠方から客がやってくること。本は高かったばかりでなく貴重で、体力使って探しまわらないと手に入らないようなものだった。そんな事情が、古本の価値を高め、さらに古本屋の力量の価値も上げていたということだ。

「昔日の客」は、今日で言えばブログに書かれているような内容だ。おおよそ散文なんてそんなもんだ。現代なら書いた時点ですぐに公開して、推敲を重ねた結果を反映させるのもリアルタイムにできる上、書いた内容についても一方通行でなく、読み手からのレスポンスもすぐに受け取れる。環境はコンテンツを創る側にとっても受ける側にとっても劇的に便利で安くなった。Googleで検索すれば次の瞬間には欲しかった物が手元に入る。「本」であってもアマゾンからたいていのものが翌日に届くし、希少本さえ体力を使わずに探し出すことができる。便利さと引き換えに「古本屋」という商売はリサイクルとしての価値しかなくなってしまった。品揃えとか目利きとかの価値もほぼ壊滅状態だ。

かつて「本」に書かれているコンテンツを得るためには、情報を持っている人と接し、実際にからだを動かして移動し、何件も本屋を回らなければならなかった。コンテンツの価値が変わらないとすれば、そのコンテンツを収録している本というメディアの価格以外に様々なコストを払わなければならなかった。インターネットによってメディア以外のコストはほとんどゼロになり、動く金の量が激減した。そして、様々な商売が消えていった。今や「本」というメディア自体のコストすらなくなろうとしている。

もはや、コンテンツについては作者とオーディエンスが直接向き合う時代になった。動く金の量が極端に減ってしまった。出版不況と言われているが、それは決して「活字離れ」なんてことが原因ではなく、メディア流通の価値がどんどん下がってしまった結果であり、CDが売れなくなったのとほぼ同じ理屈があてはまる。文学も音楽もコピーされなければ伝わらない。コピーがしにくければ人々はお金を出すが、自分で簡単にコピーできるものにお金は払わない。コピーさせないような技術は結局海賊版をはびこらせる。メディアでお金が取れない時代にコンテンツの作者は伝統的なビジネス・モデルそのものを考えなおさなければ生き残れない。

「昔日の客」を読みながら、出版業というのが本というメディアのおかげで潤うことができたのは、人類の歴史でほんの一瞬だったのかな、と思った。

Macの計算機.app 換算レートがアップデートできないなら英語モードで起動しろ

Macにはソフトウェア電卓っていうのが初代からついている。「コンピューターで仕事してるのに、計算するときに電卓を使ってその値をコンピューターに入力するっておかしいだろ。電卓よりコンピューターの方が高度な計算ができるのに！」って発想だろうけど、以前はデスク・アクセサリー(DA)として、どんなソフトを利用している時でもアップル・メニューから起動して計算結果をコピー・アンド・ペーストできた。Mac OS Xでは単独のアプリとして多機能関数電卓が実装されていて、私の場合、今でもちょっとしたことによく使うためDockに入っている。特にバージョンアップとかも期待してないけど、ないとちょっと不便だ。単位の換算とか為替の計算などにもちょくちょく使う。

ところが、今年の夏頃からこの単純なアプリケーションに問題が生じた。換算レートをアップデートしてくれないのである。それまでは、計算機を立ち上げるごとに常に最新のレート情報を持ってきてくれてたので、「今アメリカのAmazonでこれ買うと何円だな、ふむふむ」なんてことは10秒かからなかった。まぁ、ネット時代、こういうことはたまに起きるよね、くらいに思っていたらいつまでたっても対処されない。こんなことでは世界中のユーザーが困っておろうに、と思って対処の仕方を検索したが、特に問題になっている様子がなかった。

で、昨日、久々に「これ未だに問題にされていないのかな」とググってみたところ、同じように困っている人がいましたよ。困ってる人同士のやりとりのなかで解決策がしめされたました。「計算機.appを英語モードで立ち上げるとちゃんとレートをアップデートする」んだって。英語モードで立ち上げるには、Language Switcherなんてソフトもあったりする。ははぁ、どおりでAppleがちっとも対処しないわけだ。開発者はこんな問題があることをわかっていないか、ぜーんぜん低いプライオリティにしているかのどちらかなんだ。

しかし、計算機なんていう超クラシックな超スタンダードな超単純なソフトが、表示言語が違うだけでちゃんと動作しないこと自体が驚きだ。なんでそんなことが起こるのか、困ってる人同士のやりとりでは明らかになっていない。

計算機.appが為替レートの情報を取ってくる先はfinance.yahoo.comらしい。とすると、Appleが知らないうちにここでのAPIに変更があったか、あるいはフィードされるxmlが変わって計算機.appが認識できないかのどちらかと思われる。そうだとすれば、日本語モードになっているときと英語モードの時とで、やり取りされるコマンドとレスポンスが異なっていたということになるんだが、具体的に見てみるにはパケット・アナライザーをかまさなくてはいけない。そういうデータ取りをできないわけではないが、それをするのはAppleの仕事だ。

2011年1月13日追記：
Apple製のアプリは日本語版も本社で開発してるから、不具合があったらユーザーからバグレポートを上げないと対処に動かないらしい。計算機.appの換算レートがアップデートしない件、英語モードでは再現しないので、開発側が気がついていないのかもしれない。

2011年11月12日追記：
Lionの計算機.appではちゃんと直っていた。