日々の戯言


バックナンバー

1997年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
1998年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
1999年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2000年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2001年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2002年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2003年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2004年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2005年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2006年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2007年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2008年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2009年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2010年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2011年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2012年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2013年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2014年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2015年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2015年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
バックナンバー内のリンクは無保証です

12月9日(金) 4K/8K衛星放送の見通し [3] [この記事]

折角の機会なのでもう少し新しいCAモジュールについて掘り下げてみます。まず、2015年7月に総務省が公開した「4K・8Kロードマップに関するフォローアップ会合 第二次中間報告」[URI] の報告書本文の中で、4K/8K放送で利用する新しいCAモジュールについて次のように記述されています。

新CASについては、NHK、スカパーJSAT株式会社、株式会社スターチャンネル、株式会社WOWOWの4社が、高度BS放送等で利用する新たなCASとして、現2K放送のCAS方式を強化・拡張したCAS ICチップを開発することとし、「新CAS協議会準備会」を組織し、4K・8K対応のCAS ICチップの開発に取り組んでいる。このCAS ICチップは、現・2KCAS方式と4K8KCAS方式の両方に対応し、4K8KCAS方式は、スクランブル暗号鍵(Ks)の128bit化に対応するほか、Ksを暗号化して受信機に受け渡すなど、セキュリティの強化が図られている。今後、2015年には4K8KCASの技術方式の開発と、規格化作業(ARIB標準規格、NexTV-F運用規定)を進め、2018年秋頃にはICチップの出荷を見込んでいる。また、4K・8K試験放送に向けて、関係者において、CAS ICチップ供給前にICチップでない形態(例:ICカード等)での新CAS提供や4K・8K実用放送における継続使用等の課題についても検討が進められている。

この記述の中で個人的に重要と感じたところに下線を引いています。最初の下線部についてですが、新しいCASチップは4K/8K放送向けのARIB STD-B61の機能だけでなく、現行デジタル放送向けのARIB STD-B25 (B-CASカード) の機能も備えた形で提供されます。

つまり、新CASチップを搭載したTVではB-CASカードの機能も新CASチップで賄われるようになるため、B-CASカードスロットが不要になります。当然、新CASチップを搭載したTVにはB-CASカードスロットは用意されなくなり、既存のデジタル放送の視聴に関しても新CASチップのB-CAS互換機能が利用されるようになるでしょう。

メールアドレスを公開している人であれば、有料放送を契約なしで視聴できると謳う変造CASのスパムが現在でも週に何通かとどいてクソうざい気持ちになっているかと思います。新CASチップを搭載した4K/8K対応TVで世間に存在するTVが置き換わっていけば、そうした変造CASカードを利用できるTVが消滅していくということで、例えば2028年頃には変造CASカードの販売を謳うスパムメールも一緒に消滅しているかもしれません。

次に二つ目の下線部についてです。これは推定ですが、新CASチップでは既存のスマートカード対応汎用チップを買って来てソフトウェアで機能実装するという方法はとらずに専用チップを新たに作ろうとしているようです。おそらくこれが原因となって新CASチップの提供可能時期が2018年秋とかなり先に設定されてしまっています。

ロードマップでは2018年に4K/8K実用放送を開始となっていますので、対応TVの開発を考えればもう一年早く新CASチップが欲しいところです。しかし、B-CASカードの場合は汎用CPU+ソフトウェアの組み合わせで作っていたがためにバックドアから吸い出されたファームウェアを解析されて変造CASを作られてしまったという先例があるので、そういった提供可能時期を早める方向での決定はできなかったのかなと想像しています。

ひょっとしたら、新CASチップではブロック暗号の処理等を専用ロジックを使ってやらせることにしたから、運用規定でCASのダウンロード更新を諦めることにしたのかなと考えることもあるのですが、流石にこれは妄想が過ぎるかなとも思っています。

最後に三つ目の下線部についてです。かといって、2018年秋まで新CASチップが提供されないのでは試験放送を使ったTVの開発や検証もできないしということで、検証やTV開発者向けにB-CASカード同様のスマートカード形式でソフトウェア的に新CASチップと同じ機能を実現したものを提供して開発段階ではそちらを使ってもらうということが予定されているようです。

それだけならばそれなりに妥当な判断だと思うのですが、実用放送が行われているのに対応TVが発売されないということを避けるためか、その検証用のスマートカード形式の新CASを4K・8K実用放送で継続使用するとかも選択肢に上がっているようです。

流石にそれを認めてしまったら、専用チップ作る意味が全て吹き飛んでしまうように思えるので、実現可能性は低いと思います。思いますが、もしも仮に2018年に販売される4K/8K対応TVがスマートカード形式のCASカードスロットと、CASカードの組み合わせで販売されるようなことがあるとしたら、飛びついておくと色々と楽しめるかもしれません。


12月8日(木) 4K/8K衛星放送の見通し [2] [この記事]

さて、このページにたどり着いてしまうような方々が気になっているであろう、4K/8K放送に対応したアースソフトPT4とかが発売されるかどうかですが、まず発売されることはないだろうと予想しています。

4K/8K放送の技術仕様や運用規定はほぼ固まっており、ARIBで (今年10月から有料化してしまいましたが) 公開されています。ARIB TR-B39 (高度広帯域衛星デジタル放送運用規定) を読むと判ることですが、4K/8K放送でも現在のデジタル放送と同様に無料放送であっても暗号化されて放送が行われます。この暗号化を復号することができなければ4K/8K放送は視聴できません。

HDのデジタル放送の際には空気を読まないはた迷惑な人がARIB STD-B25 仕様確認プログラムとかを配布したせいで「TSさえ手に入ればだれでもデジタル放送を好きなように利用可能」ということが知れ渡ってしまい、あちこちで便利なソフトウェアが開発されたわけなのですが、4K/8K放送では流石に後発規格だけあってそうしたことは難しくなっています。

実際の暗号化方式の詳細はARIB STD-B61 (デジタル放送におけるアクセス制御方式 [第2世代] 及びCASプログラムのダウンロード方式) に記載されています。こちらを既存のデジタル放送の暗号化方式の規格であるARIB STD-B25 (デジタル放送におけるアクセス制御方式) と比較してみると次の表のような状況になっています。

  STD-B25 STD-B61
処理の流れ Km/Kw/Ks を使った三重鍵方式
コンテンツ暗号アルゴリズム MULTI2 (64bit) Camelia (128bit)
AES (128bit)
Ksの伝達方法 放送データに多重化されたECMを利用
ECMは放送事業者毎に可変のKwで暗号化される
Kwおよび契約情報の更新手法 放送データに多重化されたEMMを利用
EMMはモジュール毎に個別のKmで暗号化される
CAモジュールとの通信方法 ISO 7816
(スマートカード方式)
CAモジュールの提供方式 スマートカード形式
(ユーザーが交換可能)
ICチップ形式
(受信機から取外不可)
CAモジュールと受信機間のKs受け渡し 平文 暗号化(仕様非公開)

表を見れば判るように二つの仕様は共通の部分が多く違いは少ないのですが、次の問題からOSS開発者がARIB STD-B61 仕様確認テストプログラムとかEDCBとかTVTestを作るのは難しくなっています。

気合の入ったTV狂いであれば受信機からCAモジュールを引っぺがしてスマートカードIFに接続してPCから利用しようとする人も居なくはないと思うのですが、流石に仕様非公開の暗号化方式を解析してKsを入手しようとするのは……CAモジュールにバックドアがあって内部のプログラムが完全取得され解析されてしまうとかのまずありえない事態がなければ難しいでしょう。

なお、ARIB STD-B61のタイトルにある「CASプログラムのダウンロード方式」というのが気になり、Ksの暗号化方式が解析されて公開されてしまってもCASプログラムがダウンロード方式で更新されてしまうのでしょと心配する人もいるかもしれませんが、運用既定であるARIB TR-B39の第四編で「限定受信機能更新用途のエンジニアリングサービス運用は行わない」と書かれてたりするので、CASのダウンロード機能とかを運用する予定は存在しないようです。


12月7日(水) 4K/8K 衛星放送の見通し [1] [この記事]

総務省から公開されている情報や映像新聞の記事を総合すると、現時点での 4K/8K 放送の見通しは次のような内容となっています。

このうち、BS左旋とCS左旋は 4K/8K 放送を始めるにあたって新たに割り当てが行われた電波で、BSアンテナとブースターや分配機といった宅内配線設備を左旋対応のものに変更しなければ受信できない電波なのですが、NHKや民放キー局が4K放送に利用するBS右旋は既存のデジタルBS放送が利用しているのと同じ電波なので既にBSデジタルが視聴可能な世帯であれば対応TVを購入してアンテナ線と接続するだけで視聴が可能になります。

こうした情報は、総務省が2015年7月に公開した「4K・8Kロードマップに関するフォローアップ会合 第二次中間報告書」[URI] や同じく総務省が2016年10月に公開した「BS・東経110度CSによる4K・8K実用放送の業務等の認定申請の受付結果」[URI] さらに映像新聞の記事 [1] [2] [3] を見ると確認できます。

BS右旋での4K放送が行われず左旋での放送しか行われないのであれば、集合住宅に居住していることもあり「ど〜せアンテナとか工事しなきゃ見れないのでしょ、管理組合を説得するのも面倒だし受信できないままでいいよ」とかひねくれて「4K配信とUHDBDが見られればそれでいいや」と現時点で4K TVに飛びついてみるのもありかなと思うのですが、流石にホンの 2 年ちょい待つだけで対応 TV の発売がありそうな状況ではもう少し待ってみようかなという気持ちになってしまいます。


8月15日(月) MPEG-2 VIDEO VFAPI Plug-In ver. 0.7.9 [この記事]

MPEG-2 VIDEO VFAPI Plug-In ver. 0.7.9 を公開しました。ダウンロードは [URI] からどうぞ。更新内容は次の通りです。

2ch DTV 板「TS関連ソフトウェア総合スレ Part16」スレッドの 192 [URI] 辺りで話題になっていた不具合の原因と思われるバグを修正しました。日常的に CS のデータを扱っていないため、問題の把握と原因の特定に時間がかかってしまい申し訳ありません。

前回のスカパーの無料開放日である 8/7 に幾つかの番組をファイルに落として調べてみたところ、フィールドピクチャを活用してエンコードされたストリームの場合にフィールドオーダーの取り扱いに失敗していたことに気付きました。というわけでの修正版です。

◇◆◇

2016年に入った (MPEG-2 の規格成立年である 1995年から 20年が経過してほぼ全ての必須特許が満了したと思われる) のでライセンス周りとか見直そうかと思ったのですが、その辺に手を付け始めると本日中に終わらなくなり、リソースとか書き直して再ビルドが必要になってしまうので見送ることにしました。その内やるかもしれません。


7月12日(日) Marumo ISDB Splitter ver. 0.2.26 [この記事]

Marumo ISDB Splitter ver. 0.2.26 を公開しました。ダウンロードは [URI] からどうぞ。今回の更新内容は次の通りです。

2ch DTV 板 TS 関連ソフト総合スレ Part.15 の 230-240 [URI] でディスカバリーチャネルの TS を検証していた際に、この問題に気付いたので修正しました。

ver. 0.2.25 では 3GB 程度の EMM 入りスカパー TS を再生していると再生時間が進むにつれてメモリ消費量が増加していき、再生開始から 20 分経過した時には 900MB を超えるほど (下画像参考 / ProcessExplorer で取得) になってしまっていました。

Marumo ISDB Splitter ver.0.2.25 再生中メモリ消費

ver. 0.2.26 ではこの問題が解消され、スカパーの EMM 入り TS を再生していてもメモリ消費量は 120MB 程度で安定するようになりました。

スカパーで録画した長時間のデータを 32bit 版で再生しているとメモリ不足で落ちたりすることがあったかもしれません。そうした症状に遭遇した人がいたとしたらご迷惑をおかけしました。


9月18日(木) 著作物の保護・利用・流通に関する小委員会について [1] [この記事]

今期、文化庁の文化審議会 著作権分科会には「著作物の適切な保護と利用・流通に関する小委員会」というものが設置され、本日までに第4回まで開催されてクラウドサービスと著作権法の関係についての検討が行われています。

ここで年季のいった文化庁観察者なら「クラウドと著作権の関係って前 [2012/1/12 開催の第6回の感想記事] にも検討してなかったっけ?」と思うかもしれません。それがなぜ今頃また検討が行われているかと言うと……前回の検討の際には「クラウドに特有の問題ではなく著作権法全体に関わる問題なので」と検討を回避していたのが知財本部等から「今年度前半中にクラウドに関する懸念に対して結論を出せ」と尻を叩かれて慌てて検討を行っているというのが正直な経緯です。(開催頻度が高いと趣味の傍聴者としてはついて行くのが大変なのでなるべくやらないでほしいのですけどねー)

さて、クラウドサービス等の検討が必要になっている理由ですが2012年1月当時と何も変わってはいません。2011年に出た「まねきTV」および「ロクラクII」最高裁判決文で示された「利用行為主体」概念や「公衆」概念を踏まえると、「クラウドサービスや VPS、レンタルサーバー、データセンター事業者が著作権侵害の行為主体とみなされる可能性があるのではないか」、「直接行為主体とみなされないとしても、クラウドサーバー等が「公衆用設置自動複製機器」に該当すると見なされて事業者が著作権法 第119条2項2号の罪に問われ、刑事罰対象となるのではないか」という懸念が存在し、その懸念を払拭することが産業界からの要望として上がっているというのが最大の原因です。

付随的な要因として、諸外国においてクラウドサービスを著作権上適法なものとして扱う法整備が進み、コンピューターOSやスマートフォンOSがクラウドサービスを前提としたものしか提供されなくなりつつあるというより差し迫った懸念も原因として挙げられるかもしれません。また、これは今期に検討が再開された理由とは異なりますが、今年の 5 月にアメリカで出た Aereo 事件の最高裁判決が日本での「まねきTV」「ロクラクII」最高裁判決と結論こそはほぼ同旨であるものの、ネットワークストレージサービス全体に対して与える影響を最小化するように十分に配慮した判決になっていたという点もあるかもしれません。

◇◆◇

こうした産業界の懸念をもっともよく体現してくれているのが、権利者側委員として小委員会に参加されている、芸能実演家団体協議会の椎名委員が第1回の発表に際して提出した資料 [公式 PDF | スキャン版] です。

この資料の最後のページ「ロッカー型クラウドサービスと著作権に関する法的論点について」の「3. 公衆設置自動複製機器該当性」という箇所をご覧ください。該当文章を下に引用します。

ユーザー自らがサーバーなどの「複製手段」を自前で調達して行う(不可能ではない)場合は「私的複製」の範疇と解される可能性があるが、この場合は、まさに30条において規定されている「公衆の使用に供することを目的として設置された自動複製機器」に該当する

椎名委員が資料のこの箇所を説明した後の質疑について、インターネットユーザー協会 (MiAU) から参加している津田委員とのやり取りが公式議事録に次のように残されています。

椎名さんは先ほどの発表の中で,ユーザーがサーバーを調達して自宅で自分目的で利用することでも,それでも公衆用の設置の自動複製機器ではないかということで,そういう理解ではないのですか。それではない。僕が利用しているのは,それは違うということですね。

このやり取りと資料の文章と、共に正しいとすると椎名委員は次の主張をされたのだという結論に到達します。

  1. 個人が自宅の PC にサーバーソフトをインストールしてクラウドサービスを作り、個人が一人で利用する (津田委員の提示した例 : 適法な私的利用)
  2. 個人がレンタルサーバーにサーバーソフトをインストールしてクラウドサービスを作り、個人が一人で利用する (椎名委員資料に記載の例 : 公衆用設置自動複製機器に該当、レンタルサーバー事業者は著作権法119条2項2号に該当し懲役5年以下又は500万以下の罰金)

私は当日、この発表とやり取りを傍聴席で聞きながら「正気か?」と呻いてしまいました。椎名委員の主張を受け入れると、レンタルサーバー・クラウドサーバー事業者は「個人」と契約する場合には刑事罰におびえなければいけないということになりますから。

私は 2011 年の 1 月に、「まねきTV」「ロクラクII」に関しては違法という扱いでも問題は少ないかもしれないが、社会通念上適法であるべきレンタルサーバー一般との区分が明瞭でないとして最高裁判決を批判 [参考] しました。今でも「まねきTV」「ロクラクII」最高裁判決はクソだと思っています。(どうせ個人利用レンタルサーバーで著作権侵害の訴訟が発生してロクラク判例を引いても「事例を異にしており」の一言で片づけてどう違うのかの説明は一切ないのだろうと邪推しています)

その「社会通念上適法であるべき」と書いたレンタルサーバーを、正面から「公衆用設置自動複製器に該当する(著作権法119条2項2号の対象だ)」と主張してくれたのだから私の衝撃は想像していただけるのではないかと思います。

◇◆◇

ここまで読めば、なぜクラウドサービスに関する著作権の検討がこれほどの高頻度で行われているか、理解していただけたのではないかと思います。

ところが……ユーザー団体代表委員ということで参加している津田委員の第三回の発表を聞くと……「検討には慎重であるべき」「技術ワーキングを作っては」という内容でして……。

クラウドサービスに対する私的録音録画補償金の導入を阻止すれば勝利条件達成と勘違いしてるんじゃないかなーと不安になったりします。この小委で著作権法30条1項1号をどうにかしない限り、勝利条件達成とは言えないと思うのですけれどねー。


6月16日(月) EDCB (改変版) の「EPGデータの取得に使用する」設定について [この記事]

これは 2ch DTV 板の「EpgDataCap_Bon について語るスレ 37」の 750/752/766 に書き込んだ情報についての補足説明を目的とした記事です。経緯を知りたい場合は [URI] を参照してください。

まず、EDCB の改変版には EPG データの取得に利用するチューナ数を制限する機能が追加されています。下に貼る設定画面で赤丸で囲んでいる部分です。 (この機能が最初に追加されたのは Velmy 版ですが、epgdatacapbon にも pull されているので、github 上のほぼ全ての改変版に存在します)

EDCB チューナ設定

この画面のような設定を行った際、私は次のような挙動をしてくれるものと期待しました。

録画利用
チューナ
チューナ1 チューナ2 チューナ3 チューナ4 チューナ5 チューナ6 チューナ7 チューナ8
なし EPG取得 EPG取得
1 録画中 EPG取得 EPG取得
3 録画中 録画中 録画中 EPG取得 EPG取得
7 録画中 録画中 録画中 録画中 録画中 録画中 録画中 EPG取得

しかし、実際の挙動は次のようなものでした。

録画利用
チューナ
チューナ1 チューナ2 チューナ3 チューナ4 チューナ5 チューナ6 チューナ7 チューナ8
なし EPG取得 EPG取得
1 録画中 EPG取得
3 録画中 録画中 録画中
7 録画中 録画中 録画中 録画中 録画中 録画中 録画中

なぜこうなるかと言うと「EPGデータの取得に使用する」の設定は、2014/06/16 時点のソースでは、複数チューナ中で先頭から指定された数のものに対して EPG 取得に利用可能というフラグを立てる (それ以外のチューナは EPG 取得に使えない) だけの仕様になっているからです。実際には EpgTimerSrv\TunerManager.cpp の TunerManager::ReloadTuner() で次のようなチューナ配列が設定されるという挙動になっています。

EPG取得
チューナ
チューナ1 チューナ2 チューナ3 チューナ4 チューナ5 チューナ6 チューナ7 チューナ8
0(def) EPG & 録画 EPG & 録画 EPG & 録画 EPG & 録画 EPG & 録画 EPG & 録画 EPG & 録画 EPG & 録画
2 EPG & 録画 EPG & 録画 録画のみ 録画のみ 録画のみ 録画のみ 録画のみ 録画のみ
4 EPG & 録画 EPG & 録画 EPG & 録画 EPG & 録画 録画のみ 録画のみ 録画のみ 録画のみ

「EPGデータ取得に使用する」のチューナ数としてデフォルトの0を指定している場合は全チューナが EPG 取得と録画が可能になり、それ以外の値を設定した場合は先頭から指定した数のチューナまでが EPG 取得と録画の両方に利用可能となって、残りのチューナは録画にしか使えない形となります。

元々私が「EPGデータ取得に使用するチューナを制限したい」と望んだのは、「録画中であっても空きチューナがあれば EPG の更新を行いたいが、無制限に EPG 取得を行うと、録画が 1 つ走っている際に EPG 取得向けに地上波 7 個、BS/CS で 3 個の EpgDataCap_Bon が起動し、アプリケーション起動に伴う負荷が原因で録画中のデータにドロップが発生してしまう」ということが原因ですので、この仕様はまったくありがたくありません。

EDCB 使用予定チューナ

上の画像のように同時に 5 チューナまでは利用することがあるので、そうした場合でも EPG 更新が行われるように「EPGデータ取得チューナ」として 6 を設定すると 1 チューナしか使っていない時に地上波だけで 5 個も EPG 取得用の EpgDataCap_Bon が起動してしまいます。なかなかそうした危ない橋を渡る気にはなれません。

また、末尾 2 チューナは全く何も利用されないで待機電力を消費するだけの代物となり、これまたありがたくありません。

ただ、この辺りの問題の解決にあまり力を注ぐ気にもなれなかったので、手元対処で行った変更が 766 に書き込んだパッチです。あれを適用した場合、EDCB が管理するチューナは次のようになります。

EPG取得
チューナ
チューナ1 チューナ2 チューナ3 チューナ4 チューナ5 チューナ6 チューナ7 チューナ8
2 録画のみ 録画のみ 録画のみ 録画のみ 録画のみ 録画のみ EPG & 録画 EPG & 録画
4 録画のみ 録画のみ 録画のみ 録画のみ EPG & 録画 EPG & 録画 EPG & 録画 EPG & 録画

766 に書き込んだパッチが行うのは EPG取得と録画の両方に対応するチューナを後ろから確保するように変更するだけです。録画用のチューナは基本的に先頭から確保されていくので、EPG 取得が許可されているチューナは空きのまま残り、録画中の EPG 取得に使えるようになります。

PT3 x 4 (地上波 8 チューナ / 衛星 8 チューナ) 環境で 「EPGデータ取得チューナ」に「2」を設定する環境であればこの変更で実用上問題となることはないのですが、チューナ数が少ない場合微妙な挙動を示します。例えば次に示す画像のようなチューナ割り当てとなった場合です。

EDCB 使用予定チューナ

この画像の場合、19:00 以降であれば「チューナ2」「チューナ3」が空いています。全チューナ数が「6」で「EPGデータ取得チューナ」が「2」の場合であれば、19:00〜20:00 の EPG 更新では 2 つ EPG データ取得用の EpgDataCapBon が起動するのが望ましい挙動だと思いますが「チューナ5」と「チューナ6」しか EPG 取得には使えない設定として解釈されていますので「チューナ6」を利用した 1 つしか EPG 取得用の EpgDataCap_Bon は起動しません。

これが 766 に書き込んだパッチに対して「暫定」とか「やっつけ」という自己評価をしている点です。(まー現行仕様で 751 設定の場合でもこうしたチューナ割り当てが行われると EPG 取得x2 + 録画x2 でチューナ全消費とか発生してしまうのですけれどね)


1997年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
1998年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
1999年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2000年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2001年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2002年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2003年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2004年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2005年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2006年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2007年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2008年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2009年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2010年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2011年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2012年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2013年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2014年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2015年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2015年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
バックナンバー内のリンクは無保証です

[TOP]