Talk about computer, network and how we should work.
以下のメッセージは、今年の1/15にFacebookに書き込んだ内容です。パターンの勉強の一貫として、「書いてみる」ということをちょっとやってみているのですが、いろいろな意見をいただきました。これも、記録としてこっちにも書いておきます。
================================
プロジェクト進行や計画ミーティング等でのパターン：
◎擬態音は崩壊の前兆である
決めごとの中に擬態音が混在すると、そのゴールは人に寄って異な
バリエーション1：濁音＞半濁音＞それ以外、の順に不吉な予感は
バリエーション2：関西弁の擬態音は、ほとんど省略可能として無
解決策：
擬態音の部分を具体化するか、非機能要件として定義できれば、崩
また、擬態音を省略した場合、意味が通じるかについて判定する。
最近までOS X Serverでブログをやっていましたが、OSのアップデートである意味うまくデータは移行できず、どうするか考えていたのですが、OS X Serverを離れてこういう手段を取る事にしました。ここは、NTC Hostingというところのサイトで、Moodleでのサービス提供用に確保したところですが、WordPressを数秒でレディにしてくれるというので、ここでWPで運用することにしました。古いブログは特に移行はしないつもりですが、OS X Serverのページはおそらく検索エンジンは取り出さないでしょうから、今後意味のありそうな情報は適時転送することにします。
ということで、どうしようか考えたのですが、「プロバイダでWord Press」です。Word Pressの人気と意味は良く分かっていますが、人が群がっているものを自分も食うのは好きではないので、ずっと避けていました。まあ、でも、どうでもいいことですので、手軽かつスピーディーであれば問題ないでしょう。はてなとか、アメーバとか、日本のみんなが使っているところっていうのもなんかなぁと思うし、わざわざマイナーなサービスを探すのもあほみたいですから、順当な線に落ち着きました。ということで、まずはバックアップの算段からやるかな（苦笑）。だけど、このWPって日本語化されていないってことですかねぇ…日本語のブラウザで見ているのにメッセージ全部英語です。まあ、いいんですが、海外のプロバイダだとこういうこともあるんですねえ。
ということで、全然不定期になると思いますが、更新したらFacebookに紹介するというオペレーションでやっていきたいと思います。
<a href=”http://msyk.net/ome”>OME</a>を一生懸命やっていたのは、1999〜2004年くらいかな。ちょうど、<a href=”http://msyk.net/cserver/mdo.html”>MDOnline</a>の頃に重なります。その後も、だましだましOMEを使ってきました。相当だましたので、OS X Lionでも使えてはいますが…。ちょっとかなりきつくなってきました。それでも、never dieと言いたいのですが、かなり苦しいかも（苦笑）。
まず、「再開」の機能により、ウインドウの残り方が今ひとつよくないのか、落ちることしょっちゅうです。まあ、データを書き込んでいないし、所詮テキストファイルなので悪影響はまったくありませんが、あまりいい感じではなく、特に、command+Wでアプリが落ちるのはちょっと面倒です。コンパイルしなおそうとしているのですが、これがなかなかやっかいで、まだうまく行っていません。そこはだましだましなところですね。
そして、ついにというか、やっと気づいたというか、11月11日を境にiCloudのメールの受信ができなくなっていました。できないのをやっと気づいたというのは、iPadでもメールを読んでいるからです。fetchmailコマンドでme.comのメールってなんでだめなんだろうか？ 認証のエラーが発生します。
仕方ないので、Mail.appでiCloudメールを受けるようにしました。
そこでふと考えたのは、Mail.appをfetchmail代わりに使うことです。メールソースをAppleScriptで書き出して、メールの整理はOME側でやればいいじゃん！ってことで、近々に取り組むつもりです。
電子メールというきわめてレガシーな仕組みが今だ、同じように残ると同時に混沌さは年々増す感じもします。昔から、電話をいちいち録音していないのと同じように、メールだって、しばらくすると「捨て」でいいとも思ったりもしますが、なぜ、テキストファイルで残したいのかというモチベーションを思い出し、もうひと頑張りしようと思います。つまり、OMEはメールの整理・ストレージに移行するということです。
さて、どうなることやら。
表題の通りの仕組みを、INTER-Mediatorに組み込もうとして、２日ほどもがきました。RSAつまり秘密鍵と公開鍵を使った暗号化をフレームワークに組み込み、クライアントで入力したパスワードを、暗号化してサーバに送るという仕組みを組み込んでいます。普通パスワードはハッシュだろうと思われるかもしれませんが、フレームワークが認証するパスワードではなく、パスワードをデータベースエンジンへのアクセスに使うべく、クライアントで入力したものをバックエンドまで安全に到達させるための暗号化なのです。
RSAやハッシュ関連のことは、ネイティブな開発ならOpenSSLを使えばおおむねOKなので、同じようにライブラリを集めれば楽勝だろうと思っていました。また、PHPにはopensslライブラリがあるので、まあ、なんとかなるだろうと思いました。要件としては、キーの指定を簡単にするということ。つまり、公開鍵と秘密鍵が1つもPEM形式で得られれば、それを設定ファイルに書き込むことでキーの指定ができるということです。もちろん、生成は「openssl rsagen 1024」みたいなコマンドで簡単に済ませたいわけです。
JavaScriptの世界では、Dave Shapiroさんが作っているライブラリがあり、後々のいくつかのライブラリの多くはこれを改良しています。DaveさんのはPEM形式でキーを与えられないので、Tom WoさんのCrypticoが作られたようで、さらに別の人が署名までできるようにしています。Crypticoでいろいろやっていたのですが、うまくいかない…というか、単純にこのライブラリの問題ではなく、PHPのライブラリとの組み合わせの問題があったのです。
それで、PHPの方はというと、openssl関連関数があるので大丈夫かと思っていたら、これがなかなかうまくいかいないのです。まず、PEMでキーを与えるのが原則とすれば、Crypticoを使ってクライアント側で暗号化するのが手軽です。それを、PHPのopensslの関数で復号するのがどうしてもうまくいかないのです。そのあたりのドキュメントが今ひとつ詳しく書いておらず、コメントには「マニュアルは正しくない…」などと書いてある始末で、あれこれやってもだめでした。
ただし、PHPのopensslの関数を使えば、PEMの鍵データから、RSAの本来の鍵というか、計算式に出てくる鍵の数値をそのまま得られる事がわかりました。さらに、RSA: Encrypting in JavaScript and Decrypting in PHPというドンピシャなものがあったのですが、それはDave Shapiroさんのライブラリを使っていて、RSAの本来の鍵を使う方法が記載されています。ところが、このサイトに書いてあるPHPのライブラリはpearにあるCrypt_RSAで、説明に使っているものはすでのメンテナンスがなされていません。それを使う手もありますが、メンテナンスされているライブラリの方がいいかと思い新しいサイトへのリンクを見ると、なんとこれが、以前このblogでも紹介したPHPだけで作られたSSHのライブラリを含むphpseclib:に移行していたのです。SSHのライブラリはきわめて順調に動いたので期待をして、こちらのRSAを使って復号しようとしました。しかしながら、どんなにこねくり回してもだめなのです。このライブラリのサポートのBBSにあるこの書き込みと同じ場所でエラーが出ているようです。Macだとだめで、debianだと動くようなことが書かれているのが気になるところですが、この方法でうまく流すには簡単には行きそうにありません。
Dave Shapiroさんのライブラリで暗号復号するのはできます。また、phpseclib:で暗号復号はできます。つまり、異なるライブラリをまたいでの暗号復号がうまくいかないのです。Dave Shapiroさんのライブラリで暗号化したものを、opensslコマンドで復号してみると、パディングに関するエラーが出て復号できません。データ形式の微妙な違いがあるのでしょうか？ ドキュメンテーションの薄いライブラリや、あまりカスタマイズできないライブラリということで、これ以上手を下すことができず、ここで行き詰まってしまいました。
それで、改めてググって必死に探した結果、見つけたのがbi2phpというライブラリで、しかもMIT Licenseです。JavaScriptのライブラリは、Daveさんのものに独自に改良したものだそうです。それと互換でPHPのクラスを作ったというところでしょうか。いずれも、RSAの本来の鍵を指定するのですが、「データは全部HEX」というように、ある意味非常にわかりやすく、さくっとうまく行きました。
ということで、わかった事をまとめておきます。RSAの秘密鍵、公開鍵という仕組みはもういいとして、そこで使う鍵は、たとえば「openssl genrsa 1024」というコマンド入力で作られます。そのデータはPEMという1つのテキスト列であり、いわば、そこに秘密鍵と公開鍵などなど、RSA暗号処理に必要なデータがPKCSのルールに従ってパックされたものです。
$ openssl genrsa 1024
Generating RSA private key, 1024 bit long modulus ...................++++++ ............++++++ e is 65537 (0x10001) -----BEGIN RSA PRIVATE KEY----- MIICXwIBAAKBgQC/BlONnPUfSc95YmrcOUV0IbmeBZvibbAssetKBXAG0DGeKzc7 : 2MgfcIZ3C7lf0+yx3/RhXwJBAIYHkht7UPSpPeTvPzc4v89yBlkkGeN9xLbdONT3 uzINAQkGvVmDhNLYqxkgDysBUy/Q2f41DenUZJfEFLQBs5w= -----END RSA PRIVATE KEY-----
PHP側では、このPEM形式の文字列を使って、以下のプログラムで、RSAの計算に使うキーを求めることができます。$generatedPrivateKeyにはPEM形式のキーの文字列、圧縮アルゴリズムがAESの場合はパスフレーズを入れるので、その場合は$passPhraseに指定しますが、パスフレーズが設定されていない鍵は2つ目の引数は適当に無視します。
$res = openssl_pkey_get_private( $generatedPrivateKey, $passPhrase ); $keyArray = openssl_pkey_get_details($res);
この、$keyArrayの配列にいろいろなものが入っていて、公開鍵だけを取り出すには、$keyArray[‘key’]とします。
Daveさんのライブラリを使うには、鍵のオブジェクトを作成しますが、当然、自分で生成するのではなく、このPEMを鍵としてオブジェクトを初期化します。初期化関数部分は、次のように定義されています。biRSAKeyPairが鍵のクラス名と考えていいでしょう。
function biRSAKeyPair(encryptionExponent, decryptionExponent, modulus)
ここで、encryptionExponentは$keyArray[‘rsa’][‘e’]、decryptionExponentは$keyArray[‘rsa’][‘d’]、modulusは$keyArray[‘rsa’][‘n’]から得られます。生成した鍵からopensslのコマンドを使って出力（例えば、openssl rsa -text -in gen.key）した結果を見ながら、対応付けを確認しました。配列から得られた結果はバイナリなので、PHPの場合、bin2hex関数を使って16進文字列にして、JavaScript側の引数に指定をします。2次元目のeとdは、encrypt、decryptなんでしょうね。
なお、INTER-Mediatorでは、JavaScript側では暗号化しかしないので、2番目の引数は指定しません。というか、指定してクライアント側で見えたらいけません。なぜなら、$keyArray[‘rsa’][‘d’]は秘密鍵であり、暗号化には使わないからです。いずれにしても、JavaScriptのプログラムをサーバ側のPHPで生成してクライアントに送り込むという部分がこうした処理を組み合わせて作る事ができます。
bi2phpのPHP側のクラスは、JavaScriptとほぼ同様なプログラムでいいようになっており、サンプルのHTMLを見ればプログラムの作り方はすぐにわかると思います。非常に紆余曲折がありましたが、JavaScriptとPHPの双方で暗号復号をするには、bi2phpというライブラリでOKということです。ただし、PHPのopenssl関数を使って、PEMから鍵の値を得たりということは処理として必要になるということです。このライブラリをまとめたAndrey Ovcharenkoさんに感謝するともに、ライブラリをここまで育て上げたみなさんに感謝します。
消費税が5%から8%、そして将来は10%になるという法案が政府によって進められています。現在、年間12兆円の消費税収入があるらしいのですが、いろいろな議論が巻き起こっているのも周知の通りです。その中でまったく議論が出てこないのが「免税業者」についての話です。
現在は、すべての取引（ただし非課税のものをのぞく）に消費税の徴収が義務とされているはずです。私は2005〜2008年は会社員だったのですが、その期間の前は、「あなたは免税業者ですか」と聞かれてから請求金額が決まるという会社が多かったことが思い出されます。免税業者なら5%付加しない金額で請求書を書き、その金額が払われてたのですが、会社員をやめてフリーになって改めて調べると、免税業者に対する支払いでも消費税を付加するのが必要という記述を税務署のサイトなんかで見つけました。世の中わかりやすくなったものです。会社員以前の消費税話もいろいろあるのですが、今現在の話をしましょう。
では、現在、免税業者になっている個人や法人はその付加された5%をどうしているかというと、単にその人や法人の収入になっています。免除されているので国に対して払う必要がなく、収入なわけです。つまり、借受消費税は単に収入としてあつかっていいことになっています。現在、免税業者としてメジャーなのは年間で1000万円以下の収入のある業者です。それから、会社設立してからの一定期間も免税業者です。零細企業の支援の側面もあるのかもしれませんが、比較的多いと思われるのが、サラリーマンをしながら副業でちょこっと儲けているような人も、その副業部分が免税業者扱いになっているのが多いのではないでしょうか。これは統計がないのでわかりませんが、会社員しながら1000万を超える売り上げがある人はかなりの強者であり、その方は副業でも課税業者になりますね。まあ、普通はそこまでかせげないでしょう。
2001年頃に、免税業者の基準が売り上げ3000万円から1000万円に引き下げられました。免税業者数は368万人から231万人になり、免税業者は全体の40%になるという数字が発表されています。それまでは消費税を払っていない業者の方が数で多いという結果だったのです。当時は「うちは株式会社ですから」みたいな理由で課税業者を名乗っていた人もいましたが、おかしな理屈であり、都市伝説としか言いようがなかったですね。まあ、それはいいでしょう。
私は、1000万円以下という免税業者という施策自体を再検討する必要があると考えます。税金の公平な負担という原則があるのなら、収入に関係なくルールに従って支払うべきです。消費税は、収益に正比例するきわめて公正な税金です。消費者にはあますところなく支払わせるのなら、業者も同様じゃないでしょうか。全業者の支払い義務があるとした上で、優遇措置を検討するべきです。
収入を500万円、そしてさらに中間の250万円を平均的な収益としたら、精算した支払い税額はその5%として12.5万円です。非課税業者が200万人としたら、2500億円となります。全体の税収12兆円の中でみれば少ないのですが、それでも2%程度の増収となります。もちろん、収入額の平均値はもっと少ないとも言えますが、でかくもなく、少なくもない規模ではないかと思います。ただ、徴収のための手間というか、経費が増えるとも言えるのですが、簡易的な計算方法を導入しつつ、オンライン化により、さほどの費用はかからないと思います。
大昔の3000万円のライン、1000万円のライン、いずれも「政治的な判断」とされていて、確固たる基準がありません。これを撤廃すると、必ず「零細企業を苦しめるのか」的な意見が出てきますが、苦しめているのではありません。本来、消費者が国に対して払ったと思っているお金を、自分のところにとどめないようにしましょうというだけのことです。本来の収入ではないものを「自分のもの」として扱うフィーリングが正しくありません。そして、少なくとも、サラリーマンの副収入、つまり生活の糧は本業の給料で得られている人にまで非課税を適用するという点は、過剰な優遇としか言いようがありません。
税の公平は絶対に守られていないといけないと思います。増税の話題で免税業者のことが出てこないことに、やっぱりどこか「選挙対策」が見え隠れしている気がします。
最近というか、ここ４、５年前から「気付き」という言葉がよく使われます。古い人間として、やや違和感があり、自分ではあまり使わない言葉ですが、やっぱり気持ち悪いと思う人もいるようです。
当然ながら、気付くは動詞、気付きは名詞です。しかしながら、気付きは「気付いた事」という以上に、自分自身がその事柄を所有している意識が強い単語と考えます。つまり、気付いた上でその背景を理解し、その事柄を別のことにも活かせるという意味を示すために使われているのではないでしょうか。しかしながら、気付いて、理解して、解釈してということもみんな動詞です。動詞って単なるプロセス的にとらえられることもよくあります。「早く起きるのは大変です」「起きるのは当たり前だろう」、つまり、起きて会社に行くのは当然というプロセスの中の動作が「早く起きる」ことなのです。一方「早起きは大変です」となるとどうでしょう。やっぱり「当たり前だろう」と思うかもしれませんが、「早く起きること」自体が成果になっているニュアンスが若干あります。うがった見方をすれば、「早起きして遅刻しないで出社できたという成果があった」という心理があるのではないでしょうか。
つまり、何かが起これば「気付く」のは当たり前だし、そういう状況になったら誰でもできるだろう、やるだろうという考えがあります。一方「気付き」というのは、その人が気付き理解したという成果を強調していることなのです。何でも成果を求められる昨今、イメージとして成果っぽい言葉が頻繁に使われるのはよくわかります。
しかしながら、この「気付き」は自分の成果だけでなく、自分が所属する組織に対する貢献を、暗黙に示す言葉でもあると考えます。お店に注文したとき、商品がないとき、「お取り寄せましょうか」と聞かれますが、「お取り置きしましょうか」という言い方もよく言われます。前者は、お客の注文だから仕入れるのは当然というニュアンスもありますが、後者はお店として顧客の要望に応えましたという成果の強調が感じられます。名詞化することで、自分の成果となり、組織の成果となる。そうなれば、言葉は自然に根付き、となるわけです。
さらに、動詞は続きを求めます。「お客様のお言葉に気付きました」「で、何を気付いたの？それでどうしたの？」となります。ところが「お客様のお言葉に気付きがありました」となると、もちろん、それはどうなのと聞きたくなりますが、何となく完結感漂う言い方となり、あまり突っ込めない雰囲気を作っています。よく、「悟る」と「悟り」が引き合いにだされますが、「悟り」と言ってしまえばそれ以上突っ込めません。「気付き」と言ってしまう事で、ある種の遮断、つまり言葉のやり取りの遮断が発生します。何かを報告するときになるべく上司に突っ込まれないようにしたいという気持ちが「気付き」という言葉を引き出すのかもしれません。
気付きという言葉に違和感があるとしたら、そのときのコンテキスト（文脈）において、成果を暗黙的に強調しているからだと考えました。その上で、深堀を暗黙に否認する感覚を聞いた人にもたらします。本来は、気付くことによって、他のことに応用できるわけですが、気付きだけを強調すると、本当に応用しているのかという疑問も湧きます。そして、応用できないのなら、ほんとに気付いているのかという疑問にもつながります。そして、その確認を遮断するのです。少なくとも「気付き」は悪い言葉ではありませんが、その結果、何ができるのか、何ができたのかを同時に伝えることで、違和感はなくなるのではないでしょうか。
キーコードを取るkeyCodeや、シフトキーを押しているかどうかを確かめるshiftKeyというプロパティが「event」で使えることになっている。そこで、
document.onkeydown = function(e) { .. }
とすれば、常にキーを押したことを拾えるが、この場合は仮引数eがイベントを参照しており、e.keyCodeでキーコードが拾える。
ところが、次のように、onclickに関数を書いた場合、ブラウザ間の非互換性が発生する。
function clickThis(target) { … }
:
<div onclick=”clickThis(this)”></div>
clickThis関数内で「event.keyCode」と書いて動いてると思っていたら、Firefoxのみうまく動かなかった。つまり、eventというキーワードで、直前のイベントを取得するのはFirefoxではできなかったということである。Safariではできた。
しかしながら、以下のようにすると、Firefoxでも稼働した。関数clickThis内部では、ev.keyCodeなどによってイベントのプロパティに参照する。
function clickThis( target, ev ) { … }
:
<div onclick=”clickThis( this, event)”></div>
つまり、Firefoxでは、「event」によって、直前のイベントを参照できるのはローカルな範囲だけということになる。他のブラウザで、「event」という記述が使えるのは「window.event」というウインドウに直前のイベントを参照できるプロパティが存在しているからである。Firefoxにはそういうプロパティは存在しないが、JavaScriptの規約では存在しないので正しいらしい。
少し前に書いた記事「INTER-Mediatorの認証フレームワーク」でのプロトコルでは、中間者攻撃に弱いのが分かったので、最初に1回やりとりを増やしました。
こうすれば、中間者が得られるデータは、un、ch、h(ch, h(pw))となります。しかしながら、正しいリクエストでは、h(ch, h(pw))の計算におけるh(pw)つまりパスワードにハッシュをかけたデータが必ず必要になります。中間者はそれを持っていないので、正しいリクエストを生成できません。（当然ですが、ハッシュなので、h(ch, h(pw))からその計算の元になっているh(pw)は求められないという前提があります）
また、チャレンジは毎回異なる（確率的に同一である可能性は0とみなせる）とすれば、毎回チャレンジの値が変わり、「以前と同じチャレンジが生成されるまで待つ」という手段もとれなくなります。また、毎回チャレンジが変わることで、同じ通信内容でも生成したデータが異なることになり、過去のデータをため込むことでの一致を見つける手法もほとんど役に立たないと思われます。
これで、クライアントとサーバの間の通信経路のセキュリティはとりあえずクリアできたとします。
アプリケーションの実行する上では、クライアントのJavaScriptはある意味、プログラムを勝手に実行されて変数の値などを取り出されたり設定できる可能性があります。その状態で懸念されるのは、他人への成り済ましです。自分のアカウントでログインをした後、javascript:…でユーザ名の変数を書き換えて、アクセスが成立すると問題です。特にその方法で他人に成り済ますのは重大なセキュリティの問題になります。
上記の方法では、仮にユーザ名を変えることができても、チャレンジとユーザは対応関係があるため、ユーザ名の変更をしてしまった後では必ず認証エラーが出るはずです。
開発者が意図したテーブル以外にアクセスできるか…ですが、データベースのアカウントはサーバから移動しないので（ただし、デバッグモードで見える事もある）クライアントで参照はできない。つまり、データベースの直接続は無理です。リクエストのテーブル名を変更する事もできません。定義ファイルに記述したテーブルとそれへのアクセスしかできないので、たとえば、一般には見せていないユーザ管理テーブルを参照することも不可能です。
さて、また、少し塩漬けします（笑）。
INTER-Mediatorはだいぶんと実用的になってきました。そろそろ、先のアーキテクチャを考えはじめています。認証のフレームワークをどうするか、いろいろ考えています。要は、AJAXでの認証となると、単にHTTPでの処理と同じという情報しか得られませんでした。それでもいいのですが、Webアプリケーションでの苦労をもう一度行うことになります。認証は確かにできるのですけど、その後、アクセス権の管理をアプリケーションに組み込まないといけません。たとえば、ユーザごとに参照できるレコードが決まっている場合、認証結果からクエリのパラメータを調整するなどの処理が必要になります。下手をすると、ユーザ名をうまく切り替えたら他人になってしまえるようなものになってしまいかねません。
つまり、認証とアクセス制御をフレームワークで処理をすることによって、アプリケーション作成の上で、安全確実に認証をすることを考えたいと思いました。
とは言え、独自にプロトコルを組むというのも大変な話です。ここで、AWSのやり方をヒントにして、ハッシュをリクエストに入れて認証をするという方式を利用してみることにします。
前提は、データベースがあって、ユーザ、ハッシュしたパスワード、チャレンジ、チャレンジの発行タイムスタンプを持つテーブルを利用するとします。これらはフィールド名は決め打ちにしてしまうつもりですが、他のフィールドは自由に作成できます。その上で、以下のようなシーケンスを考えてみました。h( ) はハッシュを求める関数のつもりです。
現在、テーブルは自由に利用できますが、たとえば “security” という属性を作り、そこにフィールド名を記述すると、そのフィールド名に、ユーザ名と同じデータしか取り出さないようにするという仕組みにしたいと思います。たとえば、personテーブルがあれば、
“name”=>”person”,
“security”=>”accessibleusername”,…
のように定義ファイルを作ります。WHERE句で、accessibleusername = ユーザ名、という条件を常に付ければいいかと思います。なお、”security” 属性をたとえば、”__im_authonly” にすると、認証が通ればすべてのデータを参照できるといったような仕組みも入れておこうかと思っています。
あと、ユーザデータベースの保護についても考えないといけませんね。まあ、でも、定義ファイルにあるテーブルしか処理できないという仕組みを徹底させればいいのかなと思ったりします。何か穴があれば、ぜひともご指摘ください。
計画停電検索サイトtden.me (msyk.net/blackout) 運営者としての見解を記載しておきます。
2011年3月11日に発生した東日本大震災により、電力供給元の福島の原子力発電所が大きな被害を受け、発電できなくなるという事以上に放射能を自然界に放出してしまったという最悪の事態にまでなっていることはみなさんがよくご存知のことです。震災直後より、東京電力では「計画停電」（当初は輪番停電）として、電力供給不足に対処してきました。私の住んでいる地域は何度も計画停電による停電が発生し、うち、何回かは夜の停電でした。もちろん、さまざまな不便はありますが、状況を考えれば仕方ないと考えていました。
計画停電が実際に実際されたのは概ね3月中です。4月以降、電力需要が下がることもあってか停電は実施されていません。しかしながら、夏の電力需要が高まる時期に、停電が起るかもしれないということで、東京電力よりさまざまなアクションがなされています。節電の呼びかけと同時にどうしても供給が足りない場合には計画に従った停電を行うというものです。
こうした東京電力の姿勢について「原子力発電の必要性を暗黙に理解させるための茶番である」といった批判がメディアを中心にしてなされています。「計画停電検索サイト」はそうなると、東京電力のそうしたプロバガンダに協力するものかと思われるかもしれません。
しかしながら、当サイトの管理者として、東京電力の原発プロモーションに協力するものではないことを強く主張します。停電といった今まではほとんど起らなかったことがまさに目の前で起こり、今後も起ろうとしています。避けられないことなのであれば、その情報を提供することによって、事前になるべく知っておくということが非常に重要なことだと考えます。極端に言えば、停電も私たち生活者にとっては一種の災害です。しかしながら、それを知っておく事で、食事の時間をずらすとか、コンピュータを終了しておいたりといったことができるわけです。計画停電に賛同するわけではありません。そうではなく、発生する不便に対する対処をするための情報提供をしたいということです。
原子力発電所については、政府や関係機関は、口を揃えて「安全だ」と言ってきました。すでにそれは嘘だったことが明るみになっています。以前より、私は「安全なら大手町や永田町に原発を作るべきだ」と言ってましたが、今やそれはジョークにもならない状況です。おそらく危険だからという理由で都会から遠く離れたところに作ったのでしょうけども、大事故のために広い範囲に被害が及び、発達した流通網によってその影響は遠方にも及ぶのです。CO2の排出の問題は大きいですが、もっと重要なことは放射能を排出しないことであり、今、放射能が自然界に大量に放出されている事実を認識しなければなりません。
停電は不便ですし、いろいろやっかいないことばかりです。しかしながら、停電が起こりまた取りざたされるということから、放射能を大量に排出するという自然環境のみならず人間社会の破壊が進んでいることを強く意識せざるを得ません。それは人間社会で起った小さな失敗が積み重なったものでもあるわけです。停電によってそのことを多くの人がより強く意識し、どうすれば復旧できるのかということを意識する契機になることを願います。