<前の日記(2016年03月06日) 次の日記(2016年03月27日)> 最新 編集

高木浩光@自宅の日記

目次 はじめに 連絡先:blog@takagi-hiromitsu.jp
訪問者数 本日: 944   昨日: 2734

2016年03月14日

治外法権のeLTAX、マルウェア幇助を繰り返す無能業者は責任追及されて廃業に追い込まれよ

ここ数年、不正送金の被害がインターネットバンキングの法人口座で急増しているという*1。その原因は今更言うまでもなく、Java実行環境(JRE)やAdobe製品の古いバージョンの脆弱性を突いてくるマルウェアである。しかしそれにしても、法人口座を扱うパソコンがなぜ、Java実行環境やAdobe製品をインストールしているのだろうか。インストールしなければ被害も起きないのに……。

その謎を解く鍵が、eLTAX(地方税ポータルシステム)にあるようだ。eLTAXでは、インターネットバンキングの口座を用いた納税ができることから、インターネットバンキング用のパソコンでeLTAXの利用環境も整えるということが普通になっていると思われる。そのeLTAXが、昨日までは、Java実行環境のインストールを強要していた。eLTAXはこの危険性を認識していたのか、3月11日の時点では、トップ画面に赤字で以下の注意書きを掲示していた。

画面キャプチャ
図1: eLTAXが利用後はJavaを最新版にせよと指示していた様子

これに関してTwitter界隈の様子を調べてみると、案の定、阿鼻叫喚が渦巻いていた。

これはけしてJavaが悪いわけではなく、アップデートしたくらいで動かなくなる(メジャーバージョンが変わったわけでもないのに)ようなeLTAXのアプレットの実装なり設計なりが悪い。おそらくは、起動時に「u73」のところのバージョン文字列をチェックして、所定の番号でない限り動かないように業者がわざと作り込んでいたのだろう。こういう話は2007年までに散々書いており、もうお腹いっぱいだった。

こうした類の問題は、国の政府機関についてはとっくに解決済みである。この2007年の報道で、厚労省の脆弱性放置が大々的に報じられ、当時の内閣官房情報セキュリティセンターが対応をとったことによる。現在の「政府機関の情報セキュリティ対策のための統一基準」では、以下の事項が規定されており、これに違反すれば政府機関は対応を迫られることになる。

遵守事項

6.3.1 (2) アプリケーション・コンテンツのセキュリティ要件の策定

(a) 情報システムセキュリティ責任者は、府省庁外の情報システム利用者の情報セキュリティ水準の低下を招かぬよう、アプリケーション・コンテンツについて以下の内容を仕様に含めること。

(オ) 提供するアプリケーション・コンテンツの利用時に、脆弱性が存在するバージョンのOSやソフトウェア等の利用を強制するなどの情報セキュリティ水準を低下させる設定変更を、OSやソフトウェア等の利用者に要求することがないよう、アプリケーション・コンテンツの提供方式を定めて開発すること。

解説

遵守事項6.3.1(2)(a)(オ)「脆弱性が存在するバージョンのOSやソフトウェア等の利用を強制する」について

行政サービスを提供する情報システムの提供において、当該情報システムを利用するために、府省庁外の事業者等が作成した汎用のソフトウェアやミドルウェアのインストールが利用者の端末で必要となる場合がある。この場合、利用者は府省庁から指示されたソフトウェアを自身の端末にインストールせざるを得ないが、指定されるソフトウェアのバージョンが古く、脆弱性が存在するものであると、利用者の情報セキュリティ水準を府省庁が低下させることになる。したがって、脆弱性が存在するバジョンのOSの利用やソフトウェアのインストールを府省庁が暗黙又は明示的に要求することにならないよう、アプリケーション・コンテンツの提供方式を定めて開発しなければならない。

(略)例えば、当該行政サービスを利用するために、第三者が提供している汎用のソフトウェアのインストールを必要としていたとする。このとき、当該ソフトウェアに脆弱性が発見され、それを修正した新バージョンのソフトウェアが公開された場合に、当該新バージョンのソフトウェアをインストールすることで当該行政サービスに不具合等が生じて利用が不可能になるような事態が発生すると、利用者は、当該ソフトウェアを新バージョンに更新することができなくなる。結果として、府省庁の行政サービスが利用者の脆弱性回避を妨げることになってしまう。こうしたことが起きないよう、行政サービスを提供するシステムは、第三者の汎用ソフトウェアの併用を前提とする場合は、当該汎用ソフトウェアが新バージョンに置き換わっても、正常に動作するように設計する必要がある。予期せず不具合が発生する事態が発生した場合にも、行政サービスを提供するシステムを修正することができるよう、迅速に新バージョンのソフトウェアに対応することを保守契約に盛り込んでおくことが望ましい。

(略)

なお、開発時に公開されているバージョンだけでなく、例えば、利用を想定しているブラウザの次期バージョンについて、ソフトウェアの配布前に情報が公開された状態又は試用版ソフトウェアが配布され動作検証可能な状態にあれば、前もって利用可能かどうかを検証するなど、その後に公開が想定されるバージョンにも対応できるよう、構築時に配慮することが望ましい。

遵守事項6.3.1(2)(a)(オ)「情報セキュリティ水準を低下させる設定変更を、OSやソフトウェア等の利用者に要求する」について

行政サービスを提供する情報システムを利用するために、利用者の端末にインストールされているソフトウェア(府省庁が直接提供していないソフトウェア(例えば、端末のOSやウェブブラウザ等))の設定変更を必要とするとき、その設定変更が情報セキュリティ水準の低下を招くものである場合、そのような設定変更を要求してはならない。必要があって利用者に設定変更を求めるときは、そのOSやブラウザの標準設定(初期設定)に変更することのみを求めるものとすること(略)

政府機関の情報セキュリティ対策のための統一基準, 内閣サイバーセキュリティセンター

しかし、この基準は地方公共団体には適用されない。日本国憲法92条がいう「地方自治の本旨」により、「地域のことは地方公共団体が自主性・自立性をもって、国の干渉を受けることなく自らの判断と責任の下に地域の実情に沿った行政を行っていくこと」とされているからである。eLTAXは地方公共団体が寄り集まって運営(組織概要参照)しているので、誰も彼らに指図することはできず、10年経ってもこのザマだった、というわけである。

Twitterにはこんな悲痛の叫びもあった。

これは、eLTAXが、JRE(Java実行環境)の開発者向けテスト用バージョンのインストールを一般人に強制していたからのようだ。eLTAXは去年の時点では以下の説明をしていた痕跡がある。

「Archive」とあるように、これは過去分の保管用のものであり、一般人向けのインストーラではない。URL中に「technetwork」とあるように、このページ自体がそもそも開発者向けのコンテンツである。そのため、「ダウンロードするには「Oracleプロファイル」が必要です。」という事態になっている。つまり、eLTAXは、一般人の利用者たちに、Java開発者の登録をさせていたのである。このばかげた手順は、以下の手順書にガッつり書かれている。

この手順書の指示通りに、http://www.oracle.com/technetwork/java/javase/downloads/java-archive-javase8-2177648.html#jre-8u66-oth-JPR のURLにジャンプすると、ページの途中へジャンプしてしまい目にすることはないが、このページの冒頭には、ちゃんとこういう注意書きがある。

画面キャプチャ
図2: eLTAXの指示通りにジャンプすると目に入ってこないページ冒頭部分の警告と注意書き

赤字のあたりに、「「警告:この旧バージョンのJREとJDKは、開発者が古いシステムのデバッグするのを補助するために提供されるものです。これらは、最新のセキュリティパッチが適用されておらず、実際の製品での使用は推奨されません。」とあり、下のところに、「Only developers and Enterprise administrators should download these releases.」つまり、「開発者及び企業の管理者以外の者は、これらのリリースをダウンロードしてはならない。」とある。eLTAXは、これを無視して一般人にインストールさせたばかりか、事もあろうに、この警告が目に入らないようにページの途中にリンクさせて一般人を騙し、Oracle開発者登録させ、インストールさせていたのである。これはもはや犯罪行為に等しい。

この話も10年前にもう書いていたので、正直お腹いっぱいだ。2005年には最高裁がこれをやらかしていた。(この当時は開発者登録は不要だったが。)

そのeLTAXが、今日からJavaのインストールが不要になったというので、冒頭の警告メッセージを以下のものに差し替えている。

画面キャプチャ
図3: eLTAXの本日からの画面

「Java実行環境をアンインストールしてください」としているが、Oracleプロファイルの会員登録削除も促して然るべきだろう。無論そのためには、開発者向けのことを一般人にさせていた己の不明を詫びなければ、理由の説明にならない。

それにしても、10年間怠惰に徹してきたeLTAXが、ここにきてJava実行環境を必要としない方法に改めた背景には何があるのか。脆弱性のあるJREをインストールさせていたことが、銀行の不正送金被害を許す原因となっていたことが判明して、シャレで済まなくなったのではないか。*2

この仕様変更のお知らせが、2月2日から出ていた。

「ActiveXコントロールのインストールが必要」とのことで、Twitter界隈はまたまた阿鼻叫喚で溢れていた。

そして、この変更に伴い、「初めてのeLTAXをご利用の方はこちら」のボタンから進むと出てくる「必要な設定」のページの「STEP3」が次のものに差し替えられていた。

嗚呼、これはシャレにならない。「署名済みActiveXコントロールのダウンロード」を「有効」に設定しろだと? 2016年にもなって新たにこれを書かなくてはならなくなるとは思いもよらなかった。以下の表を示したのはもう10年も前のことだ。どうしてこんな簡単なことがわからないの?

そもそも、実際にやってみればわかることだが、2006年にIE 7が出たときに、こうした危険な設定をしようとすると、設定画面がオレンジ色になって、警告が出るようになっている。*3

画面キャプチャ
図5: eLTAXが指示する設定をしようとするとIEが警告を発する様子

これまで脆弱性のあるソフトを入れろと指示し、利用者は皆それに従ってきたのだから、このような理不尽な設定でも従順に従う人が続出するだろう。そして、次にやってくるのは、ActiveXコントロールを用いたマルウェアだ。日本の銀行の法人口座を狙う犯罪者らは、eLTAX利用者がこの設定をしていることに目をつけ、ActiveXによるマルウェアを頒布してくることになるだろう。

いったいいつまでこういう阿呆なことを繰り返すつもりか。法人口座から不正送金マルウェアでお金を盗まれたら、eLTAXを疑うとよい。eLTAXの指示に従ったせいで被害が出たことを示して、損害賠償を求め地方税電子化協議会を訴えよう。それ以外、誰にもこの無能どもを反省させる術はない。

追記(19日)東洋経済オンラインの的外れ記事

上記の日記を書く過程でTwitterを「eLTAX」で検索したとき、ITジャーナリストの本田雅一氏がeLTAXのActiveX化に不満のツイートをされているのを見ていた。東洋経済オンラインに記事を書いたとのことだったので、楽しみにしていたところ、18日にその記事が出た。これがよくある的外れな内容になっていたので、以下に批判しておきたい。

私の上記の日記を見た後で原稿を仕上げた様子だが、出てきた記事は以下だった。

eLTAXの事務局に今回のシステム移行について問い合わせたところ「これまで利用されていたJava実行環境に代わるものとして、ActiveXコントロール以外の代替技術とのセキュリティ面を含めた比較検討を行い採用を図っております」との返答を受けた。

(略)

前出のように、国税庁は、eLTAXにおいて「代替技術とのセキュリティ面を含めた比較検討」のためにActiveXコントロール使ったと説明している。この文言だけを取り上げると時代錯誤甚だしいのだが、その背景には、2001年から2006年まで政府が推進していたe-Japan戦略がある。

本田雅一, 日本の電子納税は「時代錯誤」になっている エルタックスの寒すぎる実態, 東洋経済オンライン, 2016年3月18日

eLTAXに電話取材したのはプロフェッショナルで結構だが、取材先の一般社団法人地方税電子化協議会を国税庁と取り違えており、記事の内容も全体を通してeLTAXとe-Taxを混同しているようで、これは噴飯ものだ。

技術的にも、聞きかじった生半可な知識で書いているため、誤った結論が導かれている。以下の部分はほとんど間違いしか書かれていない。

このICカードを取り扱うためのWebブラウザ向けの仕組みは、JavaかActiveXコントロールしかない。このため、eLTAXではJavaを採用していたのだろう。ただし、Java時代のeLTAXの新規申し込みページも、Intenet Explorer以外のWebブラウザではエラーが発生して動作しないお粗末なものだった。

こうしたお粗末なシステム納品を受け入れてしまう側にも問題はあるが、これを変更せざるを得なくなった理由は、eLTAXのJavaアプレットが最新のJRE(Javaを動かすためのソフトウェア環境)に対応できなくなったからだ

JREはセキュリティ問題への対応へのアップデートを繰り返しているが、最新JREでeLTAXの新規申し込み用アプレットが動作しなくなった。このため、eLTAXの新規申し込みを行うために、わざわざセキュリティの脆弱性が明らかになっている古いバージョンに差し替えてから申し込みを行い、さらに古いJREを削除した上で新しいものをインストールするという、驚くほど稚拙な対応を利用者に求めていた。

こうした状況を打破するために、新しいJava環境で動作するよう作り直すことも含めて検討した上で、いっそのことActiveXコントロールへの切り替えが適切と判断したのだろう。Javaには頻繁に脆弱性が見つかっており、最新環境に追従していくためのコストが高いとみられる。Java環境での再開発に継続投資するよりも、現時点で実績のあるActiveXコントロールを使ったということなのだろう。

本田雅一, 日本の電子納税は「時代錯誤」になっている エルタックスの寒すぎる実態, 東洋経済オンライン, 2016年3月18日

第1に、Webブラウザでの利用を前提とした場合に、「JavaかActiveXコントロールしかない」は誤りで、Webブラウザのプラグインを用いる方法もある。実際、2003年ごろ政府の電子申請システムが始まった初期の頃には、プラグイン方式のものもあったと記憶している*4し、日経コンピュータ誌の浅川記者が、エストニアではプラグイン方式だと指摘している。

第2に、ActiveXへの変更が、「最新のJREに対応できなくなった」ためだというが、eLTAXの「地方税電子化協議会からのお知らせ」を見ればわかるように、eLTAXが最新のJREに即応できないのは以前からで、JREのリリースから遅れての対応を何度も繰り返している。その意味ではずっと前から同じ状況だったのであり、突然「対応できなくなった」わけではない。

eLTAXのサイトをInternet Archiveで過去にさかのぼってみるとわかるように、2015年7月10日の時点までは、冒頭の赤字の注意喚起がなかったのが、2015年7月30日の時点で初めて赤字の警告*5が出た様子がうかがえる。それまでは危険性を放置していたわけだ。7月からこの警告を出さざるを得なくなってお尻に火がついたのだろう。

上で既に書いているように、これは10年前に国の政府機関も通った道であり、今ではこんな馬鹿げた注意喚起はもうやっていない。なぜなら、特定のアップデートバージョンでしか動かないようなJavaアプレット実装にはしていないからだ。これは2007年ごろに解決した話であり、やればできることなのに、一般社団法人地方税電子化協議会と業者がそれをしなかっただけのことだ。

第3に、「Javaには頻繁に脆弱性」「実績のあるActiveXコントロール」などと言っているが、これらを対比させるのは間違い。Java(というかJRE)は実行環境であり、環境であるがゆえに脆弱性が見つかると他に影響が出るので放置できないが、利用者が他の様々な用途でJREを使っているなら(今日では電子申請くらいでしか使われなくなりつつあるが)ば、元々JREは日々アップデートすべきものであり、そうしている限りは問題がない。ActiveXも、安全にActiveXコントロールを動かすために日々Windows Updateをしているわけで、JREと対比すべきはWindowsであり、両者に違いはない。繰り返すが、アップデートで動かなくなるようなJavaアプレットの作り方を続けていた業者と協議会が無能なだけの話。

局所的な事実だけを追えば、理に適っているように見えるが、2016年の今にあって、それは時代錯誤ともいうべきものだ。e-Japan構想で「世界最先端のIT国家実現に向けて」と取り組まれた結果が、むしろグローバルで見ると時代遅れの仕組みを生み出した

(略)

こうした現状に対してICカードによる認証システムを残したまま、問題解決する方法を模索する道はあると指摘する声もある。従来の公的個人認証サービスで使われているICカードに加え、NFC(近距離無線通信)での標準化、そしてWeb標準を決めている標準団体W3Cへのロビー活動を通じて、ブラウザ自身がICカードを用いた公的個人認証サービスい対応すれば、将来にわたってのサポートや、カードの互換性、利便性といった面での問題解決につなげることはできるからだ。

あとは、政府自身がどのように将来を見すえているかだが、その見通しが晴れているようには思えない。まだ、混乱は続きそうである。

本田雅一, 日本の電子納税は「時代錯誤」になっている エルタックスの寒すぎる実態, 東洋経済オンライン, 2016年3月18日

第4に、「それは時代錯誤ともいうべきものだ」と言うが、それが単に「ActiveXを使うことが時代錯誤だ」という意味ならば、まあある面でそうではあるけれども、「e-Japan構想」のせいだと言っているので、ICカードや電子署名を用いること自体が時代錯誤だと言いたいのだろう。前記の通りプラグイン方式を選択する道もあるのだから、そのような論理展開は誤りだ。

単に「ActiveXダサい」と言いたいのだとすれば、私の上記の日記に釣られた面もあるかもしれないが、私が書いたことは、「署名済みActiveXコントロールのダウンロード」を「有効」に設定しろという不適切な指示をしていることについてであり、ActiveX方式を採用すること自体を否定したわけではない。

もっとも、ActiveXコントロールを用いるのが「時代錯誤」だというのは別の意味で正しい。本田氏は理解していないだろうが、ActiveXコントロールが時代遅れとされ、廃止に向かっている理由は、Web画面でいきなり実行モジュールをボタン一つで自動インストールできるという仕組み(以下「オンデマンドインストール」)自体が危険なものであるからで、Microsoftはその対策のために、Windows XP SP2の時点で、Web画面の上部に現れる黄色の「情報バー」で許可の操作をしないとインストールのポップアップが出ないようにした。このときActiveXは死んだのであり、もはや互換性のために生かされてきただけだった。こんなわかりにくい操作方法を利用者にさせるくらいなら、別途ダウンロードして使う外部インストーラでプラグインをインストールする方がエレガントだという共通認識ができあがっていたわけである。その点で、署名Javaアプレットも同様の仕掛けであり、同様の意味で時代遅れだと言える。

このように、「時代錯誤」なのはオンデマンドインストールを用いることであって、ICカードや電子署名を用いること自体では必ずしもない。そもそもなぜ、電子申請システムを設計している人たちはこんなにもオンデマンドインストールを使いたがるのか。「信頼済みサイト」に登録しろという指示も散見される*6が、そんなことをさせるくらいなら、普通の外部インストーラでインストールする方が混乱がないだろう。結局のところ、ボタンを1回押すだけで自動実行などというのは、大昔に見た儚い夢だったということだ。

第5に、ICカードを残すなら「Web標準を決めている標準団体W3Cへのロビー活動」が必要だなどと、どこで聞き齧ってきたのか*7知ったかこいているが、標準化など必要としない。標準化が真に必要となるのは相互運用性が必要な場合であり、ここの用途ではそれがない。日本独自の電子署名方式を用いているのであっても、直接その独自方式を使用するプラグインを作ればいいだけ*8の話。(うまくいくのならば、JavaアプレットやActiveXコントロールでも同様。)

こういう生半可な知識の記事が横行すると、誤った理由で電子署名をやめよという話にされかねないので、危うい。

そして最後に以下の点。

「政府に言わないと」と言うが、2007年ごろに政府に直接言った*9から、国の政府機関ではここの問題は解決済みとなっているのであるし、ここ数年は政府の中の人であるから、いろいろやっている。

それに対してeLTAXは、国の権限が及ばないから、問題が解決してこなかったし、解決する手段もない。だから「治外法権のeLTAX」というタイトルにしたのだし、その理由も「日本国憲法92条がいう地方自治の本旨により」云々のくだりでちゃんと書いている。

そのような意味で、このブログにとってeLTAXの件は新しいテーマだから書いたものだ。このテーマは、ちょうど今ホットになっている個人情報保護法制において地方公共団体が個人情報保護委員会の監督下に置かれない問題(いわゆる「2000個問題」)とも共通する。もはや政治レベルの課題である。

追記(22日)

まだ書き足りてないことがあったので念のため追記。上の追記では、Webブラウザで使うことを前提とした場合についてどうなのかを書いたが、それ以前に、Webブラウザを使わず独自の専用プログラム(ネイティブアプリ)で構築する方法がある。このことは2007年のときに既に書いた。実際、他の電子申請システムはそうなっているものが多いし、このeLTAXでも、電子申請の本体はそうなっていて、「利用届出(新規)の手続き」でのみActiveXコントロール(かつては署名Javaアプレット)が使われている。住所氏名等を書いてアカウント作成を申し込むだけのことに電子署名が要るのかというそもそも論がある*10が、仮に必要だとしても、たったこれだけのためにWebブラウザからできるようにすることにいかほどの意味があるのか。とっつきやすいようにとのつもりかもしれないが、どのみちネイティブアプリをインストールしなければ何もできないのだから、そこに「利用届出(新規)の手続き」の機能を設ければいいだけだという話もある。もっとも、Webでやるのかネイティブアプリでやるのかの選択に、開発コストの面があることも本当は書かないといけないところで、HTMLで書いた方が各OSで共通にできることや、HTMLで書いた方が開発が容易な面(本当にそうなのかは大いに疑問でもある)もあるだろう。しかしそこには、ミドルウェアとの整合性を維持するためのメンテナンスコストも踏まえなければならない。昨今のスマホアプリの開発モデルを見習えば、ネイティブアプリとして開発する方が早いと言えるのかもしれないし、また、別の案として、HTMLを使ってネイティブアプリを開発する手法もあり得るだろう。

*1 参考検索例:「法人口座 不正 送金 被害

*2 昨年6月に、日本税理士会連合会が「電子申告に関する要望事項(eLTAX編)」を地方税電子化協議会に提出しており、そこに「Javaを利用しなくても利用可能なシステムとすること。」が要望として出ていた。

*3 2006年5月13日の日記参照。

*4 証拠を探してみたが、すぐには見つからなかった。

*5 「eLTAXの利用届出等を提出する際に使用したJava実行環境は、セキュリティ対策の観点から、直ちにJavaの最新のバージョン(Java8u51)に切り替えるか、又は無効化をしていただきますよう、ご注意願います。」とある。

*6 eLTAXは、eltax.jpという.jpのドメイン名のURLを「信頼済みサイト」ゾーンに登録しろと指示しているので、未来永劫eltax.jpのドメイン名を維持し続けるか、放棄する前に、全ての利用者が確実にその信頼済みサイト設定を削除するのを確認する責務が生じている。

*7 どうやらここで聞きかじったらしい。このツイートで教えていただいた。「Oracleがやめるぞといっててランタイムの配布ページが英語版しかない」というのもどこの話だ?現時点で https://java.com/ja/download/は日本語だが? もしかして「Arcive Downloads」のことを言っているのか? あれが一般向けの配布でないことに気づけないなら、地方税電子化協議会と同レベルで無能だろう。大丈夫か?

*8 むろん、標準化されればベターではあるが、それは、独自実装の範囲を最小限にできる(ライブラリやAPIに投げられる)ということにすぎない。

*9 それゆえ2007年で「電子政府」関係のブログエントリは終わっている。

*10 この部分において電子署名は不要だと思う。e-Taxではこれが必要とされておらず、即座にアカウントが作成できるようになっている。もっとも初回に電子証明書を登録する作業があって、これも要らないと思うが、いろいろあれでこちらはまだまだ簡単な話ではない。

本日のTrackBacks(全1件) [TrackBack URL: http://takagi-hiromitsu.jp/diary/tb.rb/20160314]

高木浩光@自宅の日記 - 治外法権のeLTAX、マルウェア幇助を繰り返す無能業者は責任追及されて廃業に追い込まれよ http://takagi-hiromitsu.jp/diary/20160314.html 専用の環境のXPmode用意するしかないよなあ ICカードの認証があるからブラウザだけで完結させることが出..

検索

<前の日記(2016年03月06日) 次の日記(2016年03月27日)> 最新 編集

最近のタイトル

2024年03月16日

2024年03月13日

2024年03月11日

2023年03月27日

2022年12月30日

2022年12月25日

2022年06月09日

2022年04月01日

2022年01月19日

2021年12月26日

2021年10月06日

2021年08月23日

2021年07月12日

2020年09月14日

2020年08月01日

2019年10月05日

2019年08月03日

2019年07月08日

2019年06月25日

2019年06月09日

2019年05月19日

2019年05月12日

2019年03月19日

2019年03月16日

2019年03月09日

2019年03月07日

2019年02月19日

2019年02月11日

2018年12月26日

2018年10月31日

2018年06月17日

2018年06月10日

2018年05月19日

2018年05月04日

2018年03月07日

2017年12月29日

2017年10月29日

2017年10月22日

2017年07月22日

2017年06月04日

2017年05月13日

2017年05月05日

2017年04月08日

2017年03月10日

2017年03月05日

2017年02月18日

2017年01月08日

2017年01月04日

2016年12月30日

2016年12月04日

2016年11月29日

2016年11月23日

2016年11月05日

2016年10月25日

2016年10月10日

2016年08月23日

2016年07月23日

2016年07月16日

2016年07月02日

2016年06月12日

2016年06月03日

2016年04月23日

2016年04月06日

2016年03月27日

2016年03月14日

2016年03月06日

2016年02月24日

2016年02月20日

2016年02月11日

2016年02月05日

2016年01月31日

2015年12月12日

2015年12月06日

2015年11月23日

2015年11月21日

2015年11月07日

2015年10月20日

2015年07月02日

2015年06月14日

2015年03月15日

2015年03月10日

2015年03月08日

2015年01月05日

2014年12月27日

2014年11月12日

2014年09月07日

2014年07月18日

2014年04月23日

2014年04月22日

2000|01|
2003|05|06|07|08|09|10|11|12|
2004|01|02|03|04|05|06|07|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|05|06|07|08|09|10|11|12|
2012|02|03|04|05|06|07|08|09|
2013|01|02|03|04|05|06|07|
2014|01|04|07|09|11|12|
2015|01|03|06|07|10|11|12|
2016|01|02|03|04|06|07|08|10|11|12|
2017|01|02|03|04|05|06|07|10|12|
2018|03|05|06|10|12|
2019|02|03|05|06|07|08|10|
2020|08|09|
2021|07|08|10|12|
2022|01|04|06|12|
2023|03|
2024|03|
<前の日記(2016年03月06日) 次の日記(2016年03月27日)> 最新 編集