日々の戯言


バックナンバー

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月
バックナンバー内のリンクは無保証です

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 でチューナ全消費とか発生してしまうのですけれどね)


5月30日(金) NHK 技研公開 2014 [この記事]

昨日 5/29 に NHK 放送技術研究所 (東京都世田谷区砧) の「技研公開 2014」[URI] に行ってきました。今回完全に趣味なので勤務先には休みを取っての行動です。職務で得た知識ではないので NDA を気にせず好きなように公開できるのは良いことですね。

元々は「研究発表2 8Kスーパーハイビジョンにおける光インターフェースの開発と標準化動向」[URI] を一応聞いておくかと考えて、休暇を取得した訳です。2011 年の技研公開で 8K 映像の光伝送に挑戦しはじめたという展示から気になっていたネタ [参考] なので、いよいよ標準規格化されたのか……と考えての行動です。

が……発表を聞いていると「色コンポーネントを 4K 解像度 (3840x2160) に分割して、HD-SDI のフレーム構造にそのまま当て嵌めて」という内容でして……「それって HD-SDI との相互変換 (HD-SDI 複数チャネルの出力しかない機器に繋ぐため) には便利かもしれないけど、純粋にインタフェース仕様として見た場合に微妙じゃね?」という感想を抱きました。さらに 10G の光ケーブル 24 芯を一本に束ねてという話だったので……コネクタコストが高くなりそうだなーと思いました。

このように民生用規格に流用とか全く考慮してなさそうなインタフェース規格ですが、今年の 3 月に ARIB で STD-B58 [公式 PDF] として規格成立しているそうです。

◇◆◇

もうひとつ、多分一昨年までとあまり変らない内容なのだろうなと思いつつも、一応見ておかねばと事前に思っていたのが「展示18 次世代 CAS 技術」[URI] です。

こちら、あまり期待せずに向かったのですが、総務省の「情報通信審議会 <略> 放送システム委員会」[第42回 会議資料] で答申が固まったおかげか、かなり具体的な話を説明担当の方から聞くことができました。

ソフトウェア的に放送波でアルゴリズム自体を更新可能なものとして CAS を実現するというのは一昨年までの展示と変わらないのですが、そのソフトCASが動作するモジュールはCASを管理する事業者を (ダウンローダブル CAS らしいので D-CAS 社とかになるのかしら) 新たに設立して、そこが専用ICを作成し、受信機メーカがその専用ICを受信機に組み込むという形で検討されているようです。

B-CAS の場合は IC カードという形で受信機とは別のハードウェアでしたが、次世代CASでは専用ICという形で受信器に組み込まれる形になるようです。また B-CAS はアルゴリズム全体を放送経由で書き換えることはできませんでしたが、次世代CASでは当然それを可能とするようです。

一昨年までの展示では、CAS を作るのは誰になるのか、つまり受信器メーカーに CAS を実装させるのか、受信器メーカーが廃業したら CAS の更新はできなくなってしまうのかという辺りが未確定な状況でしたが、説明を担当された方がきっぱりと「専用ICを作って受信器に組み込む形になるだろう」と説明されたということはかなり確度の高い情報なのかなと判断しています。

B-CAS 同様に独禁法云々で文句が付く可能性はありますが、CAS の更新が行われる (メーカーの廃業等で更新が行われなくなることはない) ということを担保するためには、妥当な判断なのかなと思います。また独禁法云々で物言いが付くことを想定してか、無料放送に関しては RMP (TRMP と同様の完全ソフトウェア方式) でやることも考えているそうなので、地デジが B-CAS と TRMP で受け入れられている以上、有識者からの文句も付きにくいのかなと思います。

……しかし……「B-CASで色々あったので対策がどうなってるのか気になるんですよね〜」と軽く振ってみたところ「これが対策です」という力強いご回答がありまして……

つまり……

  1. 8K 放送のタイミングで次世代 CAS 導入
  2. 対応受信機 (既存放送+8K両対応) 普及
  3. 既存放送でも次世代 CAS 利用 (T-RMP と同様にデスクリプタ増やして対応?)
  4. [遠大な未来] B-CAS廃止 (or B-CAS 対応受信器が販売されなくなって、変造 B-CAS は有料放送の脅威ではなくなる)

……という心づもりのようです。

まーそれはそれで良いのかも知れないのですが、B-CAS 段階での技術的対策というのはもう完全に破棄された計画なのかなと考えながら回答を聞いていました。

一応、「結果的に B-CAS 段階での技術的対策が一切行われないということだと、『結局対策できない』と見くびられて、新システムがクラックの標的になることも」と質問はしてみたのですが「更新できるし、IC カードではなく受信器に組み込まれた時点でかなり安全性が高まる」という回答だったので、放送業界の CAS 技術研究者的には「B-CAS 段階での対策は不要」という認識なのかなという確信がさらに高まってしまいました。

さらに「IC カードを採用していた理由はクラックに対して交換できることだったけれど、コストの問題で実際には……」という回答もあったので、「こりゃ B-CAS に対する技術的対策は 100% 無いのだな」という確信を深めました。

……技術的対策が行われれば、少しは「有料放送が無料に!」系のスパムメールが減ってくれるかと期待していたのですが、どうやらそうした日が来ることは無いらしいので、残念です。

◇◆◇

補足。クラッカー側に「対策が行えない」と思われることは「クラックによって判明した知識を公開する」ことに対する歯止めを無くします。

一般論として、不正利用を目的としてクラックを行う人にとり回避方法を公開して対策を実施させるというのは手持ち情報の価値を無くすことですから、公開する意味はありません。実際に B-CAS の場合、最終的に各種情報を開示した人の記述を信じるならばクラック完了後 2 年以上、それらの情報は一部コミュニティ内部にとどまっていたそうです。

ところが「対策が行えない」と判断された場合、回避方法を公開しても穴は塞がれず、手持ちの情報の価値が下がることもありませんから面白半分に公開してしまおうという人も出てきやすくなります。

また、対策が行われる場合であれば「不正手段を提供してひと儲け」と考える人にとって「コスト=クラックに必要な労力」で「収入=対策が行われるまでの期間×時間当たり販売量」ですから、どこかでバランスして儲からないから止めようという判断になることもあります。一方で対策が行われない場合だとコストは有限なのに対して収入に上限がない状態になります。必然的にクラックに注がれる労力を増やしても、コスト的にペイするという判断がされやすくなってしまいます。

そうしたものを断ち切る意味でも、「可能な技術的対策を行う」という姿勢を見せておくことは重要に思えるのですが……まー有識者&専門家の方々が大丈夫と判断してるのなら大丈夫なのでしょうね。なにしろ B-CAS のアレコレで十分に教訓は得ているのでしょうし。


2月19日(水) Marumo ISDB Splitter ver. 0.2.25 [この記事]

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

2ch DTV 板 TS 関連ソフト総合スレ Part.13 の 82 [URI] で報告いただいていた不具合の修正です。

SD マルチの TS をそのまま録画したストリームでのプログラム切り替えや、デュアルモノラル以外での二か国語放送の TS での音声切り替えで、切り替えを選択してから実際に反映されるまでに 15 秒程度待たされるという問題を入れてしまっていたのでその修正をしています。

当初想定していたよりも大がかりな変更が必要になり、不具合報告してくれた方を待たせることとなってしまいました。申し訳なく思っています。


1月24日(金) Marumo ISDB Splitter ver. 0.2.24 [この記事]

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

やはり昨日のバージョンにはバグが残っていました。これがラストになると良いなと思いながらの修正版です。

PCR 探索処理で収束を早くするために、可能な場合は PCR を一度のファイルアクセスで 2 地点評価するようにしたのですが、その片方で PCR のラップアラウンド対策を入れるのを忘れてしまっていました。結果、本来はシーク目標よりも後ろの箇所を遥かに手前であると解釈して、映像が当分の間更新されなくなるなどの異常挙動を示すことがありました。

今回のバグでは maki (@maki_rxrz) さんから PCR ラップアラウンド系のサンプルを提供していただいたことで原因特定および修正までの時間が短縮されました。とても感謝しています。


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]