2005-05 アーカイブ

質問文が長すぎます

Movable Type のライセンスのまとめ - ケーススタディ - moblog.uva.ne.jp - moblog mail gateway を使って moblog を作りたいにてちょっとした疑問が浮かんだので、はてなで質問をしようとしたら 質問文が長すぎます と怒られました。

無理に文字数を削って質問の意図を曲解されても困るので、ここに質問文を載せようと思います。

質問文

Movable Type のライセンスのまとめ - ケーススタディ - moblog.uva.ne.jp - moblog mail gateway を使って moblog を作りたいを読んだ上で回答をお願いします。

Movable Type において、同一人物であっても複数の異なるログイン ID を持つ場合は限定個人ライセンスの範疇から外れますが、 moblog.uva.ne.jp のゲートウェイ更新用に新しくログイン ID を作成することも同様に考えて良いのでしょうか ? なにぶんゲートウェイの解説が書かれた時点では Movable Type 3.x のリリースやライセンス体系の告知はまだ行われておらず、またライセンス体系が変わった現在も moblog.uva.ne.jp および uva.jp 内ではこのログイン ID の新規追加がライセンス的にどう捉えられるは触れられていません。 「 moblog.uva.ne.jp ライセンス」で検索してみたところ、やはり限定個人ライセンスではなく個人ライセンスとなる意見が目立ちました。

そこで質問ですが、逆に「限定個人ライセンスの範疇になるだろう」という見解をされている記事、またはゲートウェイ提供者の平田氏が「このゲートウェイに限り限定個人ライセンスでも構わない」という見解を示している記事があれば教えてください。 ( なお、「どうしても限定個人ライセンスで使いたい」という理由で質問しているわけではないことを念のため申し添えます。 )

トラックバック送信先

• はてな 「質問文が長すぎます」というエラーになったため、 http://hxxk.jp/mt/2005/05/30/0149#sub-20050530-02 に質問文を書いています。それを読んだ上で・・

リンクを含まないトラックバックは好まれない ? (2)

• Webweavers - weavin' - The "Ojigi" Trackback 01 - "Arigato" Pings

ただ、「Trackbackは言及を自分のweblogからするもの」のようにとらえている人が多い気がするので、直接の言及がない末端から末端へのトラックバックはTrackback spamだったり、アクセス数稼ぎとしか見なされず、ウェブロガーの間で干されるおそれがあります。

トラックバック≠リンク通知 - リンクを含まないトラックバックは好まれない ? で触れたことと重複しますが、やはり直接の言及が無いと認められないのでしょうか……。

リンクを含まないトラックバックを送信した

前項の記事を目にした直後、グッドタイミングで「既に完結した記事から、トラックバック先の記事に直接言及はしていないけど関連はあると判断したからトラックバックを送信する」という機会がありました。

1. 私の Bloglines にて、 Going My Way: トラックバックスパムを一度の操作で消すバッドノウハウの記事を見る。
2. これは連番で送られてくるトラックバックスパムについてのノウハウであり、連番じゃないときは面倒かもしれませんと述べられている。
3. ランダムに送られてくるトラックバックスパムなら、一度に消すのは無理だけれど Movable Type 2.x の管理画面から探すよりは遥かに手間を軽減できる Movable Type 2.x でトラックバックを一括管理するテンプレートを使うと良いんじゃないかと考える。
4. これは元々現在トラックバック止めてます - スピリッツオブゼロ@blog を受けて書いた記事であり、 Going My Way: トラックバックスパムを一度の操作で消すバッドノウハウに向けたものではないけれど、 kengo さん ( Going My Way ) のお役に立てそうだと思い、また是非見て欲しいとも思ったのでトラックバックを送信。

さて、この場合は Movable Type 2.x でトラックバックを一括管理するテンプレートの記事からは Going My Way: トラックバックスパムを一度の操作で消すバッドノウハウに関しては直接の言及はしていません。 しかし、「 Movable Type 2.x におけるトラックバックの管理およびトラックバックスパムへの対処法」という目的についての言及をしています。

こういった「 ( 直接的な ) 言及の無いトラックバック」という存在もあるので、十把一絡げに 言及リンクのないサイトからのTackBackは本質的にspamと変わらない とするのもいささか乱暴な気もします。 ( もちろん、明記していないだけで「検索で見つけた、似たような記事に ( 送信先の記事内容をよく読まずに ) トラックバックを送信しまくる」というケースを指している可能性が大きいですが。 )

無差別トラックバック、あるいは未読トラックバック

あまり独自の言葉を定義するのは好きじゃないのですが、いわゆる「検索で見つけた、似たような記事に ( 送信先の記事内容をよく読まずに ) トラックバックを送信しまくる」ケースを無差別トラックバック、あるいは未読トラックバックと表現してみてはどうでしょう。

言及リンクが無くとも、トラックバックを送るに足る関連性があるという自信を持つためには、無差別に送信するのは言語道断なことですし、また送信先の記事をよく読まないとその判断はできません。 よって、そういった送信前の自己判断を行っていない、言及リンク無しのトラックバックを表すには便利かと思います。 ( 表すには「的確」とは断言できないので、表すには「便利」と表現しています。 )

ライセンスについてあれこれ論議

hxxk.jp で使用している Movable Type は、限定個人ライセンス（無償）を使用しているのですが、これ以外のとある場所でも Movable Type を使用することになったので、有償ライセンスに乗り換えることにしました。 しかし、私の行おうとしていることはどのライセンスに当てはまるのか ? こういったケースならこのライセンスだ、いやいやあのライセンスだ、という話を IRC チャンネル #hxxk や #順列都市で行いました。

しかし、こう言ってはいけないのかもしれませんが、 Movable Type Publishing Platform: ライセンス・価格の記述には解釈が分かれそうな物が多く、明確な結論が得られませんでした。 そこで、 Movable Type Publishing Platform: Movable Typeに関するお問い合わせを利用して問い合わせをして、明確な回答を得られたのでここにまとめておきます。

1. 関連ページおよび関連資料
2. 言葉の定義 (1) - ユーザー、著作者
3. 言葉の定義 (2) - サーバ
4. 言葉の定義 (3) - ウェブログ
5. 言葉の定義 (4) - ウェブログ数
6. ライセンスの種類 - 個人ライセンス
7. ライセンスの種類 - 限定個人ライセンス ( 無償 )
8. ライセンスの種類 - 通常ライセンス
9. ライセンスの種類 - ホスティングライセンス
10. ライセンスの種類 - その他のライセンス
11. ケーススタディ - 非商用目的の個人が、複数の別のサーバで使用したい
12. ケーススタディ - 非商用目的の個人が、同一サーバ上の異なるドメインで使用したい
13. ケーススタディ - 非商用目的の個人の使用が中心で、家族や友人にも記事を投稿させたい
14. ケーススタディ - Movable Type のインストールを代行してもらいたい
15. ケーススタディ - moblog.uva.ne.jp - moblog mail gateway を使って moblog を作りたい
16. トラックバック送信一覧

関連ページおよび関連資料

ライセンスに関する記述は様々な場所に置かれているため、最初にまとめておこうと思います。

• Movable Type Publishing Platform: ライセンス・価格
  • 通常ライセンス（ダウンロードライセンス、ライセンスパック）
  • 個人ライセンス
  • ホスティングライセンス
  • 教育用ディスカウント
  • 非営利団体（NPO）用ディスカウント
  • ライセンスに関する参考情報
• Movable Type FAQ - ライセンス関連
  • Movable Type FAQ: Movable Typeのそれぞれのライセンスの違いを教えて下さい。
  • Movable Type FAQ: 個人ライセンスと商用ライセンスの違いを教えてください。
  • Movable Type FAQ: Movable Typeを会員向けにホスティングサービスとして導入したいのですが、どうすればいいでしょうか？
  • Movable Type FAQ: Movable Type 2.x系を利用しているのですが、そのまま使い続けていても問題ありませんか？
  • Movable Type FAQ: Movable Typeをカスタマイズしてもいいのでしょうか？
  • Movable Type FAQ: アフィリエイトを利用したいのですが、商用扱いになるのでしょうか？
  • Movable Type FAQ: Recently Update Keyとは何ですか？
  • Movable Type FAQ: アップグレードはできますか？
• Six Apart Japan: Movable Type 3.0のライセンス体系について

また、ライセンス自体の条文は、ライセンスを購入しようとする際に読むことができますので、合わせてお読みください。 ( 本来ならそれもオープンな場所で公開するべきだとは思いますが……。 )

言葉の定義 (1) - ユーザー、著作者

Movable Type におけるユーザーおよび著作者という定義は、利用許諾契約書にて次のように定められています。

「ユーザー」とは、本Softwareの「ウェブログ投稿者の追加/編集」機能をもって本Softwareにより生み出される独自のログイン名を持ち、且つ90日以内にログインした個人を意味します。 お客様の組織において雇用が終了した個人、及び本Softwareを使用していない個人は、90日以内にログインしていた場合においても、ユーザーとして数えないものとします。 一個人のログイン名を複数の者で共有することは禁止とします。

「著作者」とは、本Softwareの「ウェブログ投稿者の追加/編集」機能をもって本Softwareにより生み出される独自のログイン名を持つ個人を意味します。 一個人のログイン名を複数の者で共有することは禁止とします。

ダウンロードライセンスの場合は 90 日以内にログインした人を指し、個人ライセンスにおいてはライセンス所持者自身を指します。 個人ライセンスにおいて勘違いしやすいのですが、同一人物が異なるハンドルのログイン名を 3 つ使用する場合、それは 3 ユーザーということになります。

言葉の定義 (2) - サーバ

Movable Type におけるサーバという定義は、利用許諾契約書にて次のように定められています。

「サーバー」はMovable Typeがインストールされた1台のコンピューター、又はMovable Typeがインストールされた1台のコンピューター及びウェブページの公開用に使用する1台以下のコンピューター及びデーターベース・サーバー用に使用する2台以下のコンピューターから成る1つのコンピューター群を意味します。

言葉の定義 (3) - ウェブログ

Movable Type におけるウェブログという定義は、利用許諾契約書および Six Apart Japan: Movable Type 3.0のライセンス体系についてにて次のように定められています。

「ウェブログ」とは、本Softwareの「ウェブログの作成」機能をもって本Softwareにより生み出されるものであって、個人によって創作されたコンテンツを刊行するためのウェブサイトを意味します。

“ウェブログ”とは、一つのURL（ユニフォーム・リソース・ロケーター）から閲覧可能な、一つのウェブサイトのことで、Movable Typeの「新しいウェブログの作成」機能で作成された1つ以上のウェブログから構成されます。

非常に紛らわしいのですが、「新しいウェブログの作成」で作成できるものと、それ ( または複数のそれら ) によって構成される一つのウェブサイトの両方をウェブログと表現していますので、注意が必要です。 ライセンス上で数える単位は、次項のウェブログ数となります。

言葉の定義 (4) - ウェブログ数

Movable Type の管理画面の「ウェブログの作成」機能で作成するウェブログは、 Six Apart Japan: Movable Type 3.0のライセンス体系についてでは Movable Type 上のウェブログと表現されています。 では、各ライセンスにおいて「ウェブログ数 3 」とか「ウェブログ数無制限」と書かれている「ウェブログ数」とは何でしょうか。

Six Apart Japan: Movable Type 3.0のライセンス体系についてを読んでみると、

念のため、ウェブログ・サイトを構成する下位ウェブログは、ライセンス上のウェブログ数には数えられません。

例：もしあなたのウェブログ・サイトが、Movable Type上は4つのウェブログで構成されていた場合、つまり一つが文字ベースのメイン・ウェブログ、一つがリンク集、一つが音楽リスト、一つが書籍リスト、という構成の場合、ライセンス上は1ウェブログとみなされます。

多くのMovable Typeユーザーが、非常に頻繁にこういう設定をしています。 例えば、Movable Type公式サイト（movabletype.org）は、Movable Type上は3つのウェブログから構成されています。 現在、技術的見地から、この区別をよりシンプルにしようとしていますが、この説明によって（ウェブログ数に関する）疑問が解消されることを望みます。

よって、個人で Movable Type を使用している場合、ライセンス上のウェブログ数は 1 となる場合が多いと思います。 ただし、ウェブログ数による制限は限定個人ライセンス ( 無償 ) 以外では無制限なので、有償ライセンスの場合は基本的に考慮する必要はありません。

ライセンスの種類 - 個人ライセンス

• Movable Type Publishing Platform: ライセンス・価格 - 個人ライセンス

個人ライセンスの場合、利用許諾された一個人（お客様）にのみ、Movable Typeの利用が限定されています。

個人ライセンスにおける複数ユーザーは、お客様が別名で投稿するためのものですが、家族・友人等が、利用許諾をされたお客様のウェブログに投稿することまでは制限をしておりません。

ただし、商用・非商用に関わらず、特定・不特定の他者にウェブログサービスを提供するためには、ホスティングライセンスが必要です。

家族・友人等で自由にWeblogをつくり、お互いに投稿するためには、任意団体・クラブ・サークルでも利用が可能な通常ライセンス（ダウンロードライセンスまたはライセンスパック）をご利用ください。

非商用目的の個人ユーザーは、基本的にこのライセンスに該当します。 しかし、投稿者名 ( ログイン ID ) を 1 つしか使わず、ウェブログ数が 3 以下であれば限定個人ライセンス ( 無償 )を使用することができます。

なお、 家族・友人等が、利用許諾をされたお客様のウェブログに投稿することまでは制限をしておりません という例外もありますが、これについてはケーススタディ - 非商用目的の個人の使用が中心で、家族や友人にも記事を投稿させたいで解説します。

ライセンスの種類 - 限定個人ライセンス ( 無償 )

• Movable Type Publishing Platform: ライセンス・価格 - 限定個人ライセンス（無償）

限定個人ライセンスは、無償で利用可能ですが、利用できるユーザー数（ウェブログ投稿者数）は1、ウェブログ数は3に制限されています。 ウェブ構築業者が、本ライセンスを用いて顧客システム開発やインストール代行を行うことはできません。 またサポートなど、有償ライセンス向けのサービスは、限定個人ライセンスでは利用できません。

前項の個人ライセンスに、一定の条件を設定して無償としたライセンスです。 同じ個人でも、投稿者名 ( ログイン ID ) を複数使い分ける場合はユーザー数の制限を超えますので、このライセンスを使用することはできません。 その場合は個人ライセンスを購入する必要があります。

ライセンスの種類 - 通常ライセンス

• Movable Type Publishing Platform: ライセンス・価格 - 通常ライセンス（ダウンロードライセンス、ライセンスパック）

法人・団体のお客様がMovable Typeを利用する場合は、ダウンロードライセンス、ライセンスパックが適用されます。 また、個人名義であっても商用目的にMovable Typeを使用する場合、ウェブ構築業者がMovable Typeを使ってシステム構築やインストール代行をする場合も、これらのライセンスを利用する必要があります。

また、Movable Typeは利用許諾された個人、法人・団体の社員・職員またはそれに準ずる方に利用が限定されています。 商用・非商用に関わらずライセンスを所有し、特定・不特定の他者にWeblogサービスを提供するためには、ホスティングライセンスが必要です。

法人・団体 とありますが、これは「個人以外」と考えると分かりやすいでしょう。 私が問い合わせた際にいただいた回答では、クラブやサークルにおける使用の場合も通常ライセンスが必要になるということでした。

また、引用部分にもありますが、個人であっても商用目的の場合や、システム構築・インストール代行を行う場合もこのライセンスが必要となります。

ライセンスの種類 - ホスティングライセンス

• Movable Type Publishing Platform: ライセンス・価格 - ホスティングライセンス

Movable Typeを会員向けにホスティングサービスとして導入したい場合には、こちらの問い合わせフォームから、お問い合わせください。

これはおそらく、レンタルサーバを運営するような事業者が、会員向けに Movable Type をプリインストールすることをアピールポイントとする場合などに該当すると思います。 ビジネスサイト向けトータルソリューション cozy.biz などが実例として挙げられると思います。

ライセンスの種類 - その他のライセンス

• Movable Type Publishing Platform: ライセンス・価格 - 教育用ディスカウント
• Movable Type Publishing Platform: ライセンス・価格 - 非営利団体（NPO）用ディスカウント

これらのアカウントは、詳しいことは書かれていないため省略します。 ( どちらも問い合わせフォームに誘導しているので、ケースバイケースで判断するのでしょう。 )

ケーススタディ - 非商用目的の個人が、複数の別のサーバで使用したい

これは要するに私のケースです。 私の状況を例に出して説明します。

現在、私は hxxk.jp というドメインにおいて、限定個人ライセンス ( 無償 ) にて Movable Type を使用しています。 このドメインが割り当てられているサーバは XREA の s77 サーバです。 今回それとは違うサーバをレンタルし、 hxxk.jp とは何ら関連性の無い ( 単に作成者が同じという程度しか共通しない ) 、新たなサイトを作ることになり、それにも Movable Type を活用したいと考えました。 それらのサイト同士には関連性を持たせたくないため、ログイン ID は当然別のものを使用することになります。 その時点で限定個人ライセンス ( 無償 ) の条件からは外れるため、個人ライセンスを購入しようと考えました。 しかし、利用許諾契約書に目を通すと、サーバ数は 1 と明記されています。

この場合は個人ライセンスを 2 サーバ分購入することになるだろうなと思いつつ、 Six Apart の見解を知りたかったため、問い合わせをしました。 返ってきた回答の要約をすると、 「現時点で限定個人ライセンスを逸脱していないのであれば、新しいサーバにて個人ライセンスを購入してください。 なお、仮に現サーバと新サーバの両方が 1 ユーザー、 3 ウェブログ数以内でも個人無償ライセンスをふたつ以上使用することはできません。」 ということでした。

よって、もし更にもうひとつサーバをレンタルし、計 3 つのサーバで運用する場合は個人ライセンスを追加で購入する必要があるでしょう。 今回は合計で 2 つのサーバであるので、 hxxk.jp は限定個人ライセンス ( 無償 ) のままで使わせていただき、新たなサイトの方にて個人ライセンス ( 5 ユーザ版 ) を購入させていただきました。

ケーススタディ - 非商用目的の個人が、同一サーバ上の異なるドメインで使用したい

これは前述のケースと似ていますが、同一のサーバである点が異なります。

サーバの設定によっては、同一サーバ上で複数のドメインを使用することができます。 ( これをマルチドメインと呼びます。 ) その場合は、サーバ数は 1 として数えられるので、ユーザ数やウェブログ数でライセンスを判断することになります。

今回は個人ライセンスを購入する前提で問い合わせをしたため、マルチドメインでも限定個人ライセンス ( 無償 ) が許可されるかどうかには触れられませんでしたが、おそらく 1 ユーザー、 3 ウェブログ数以内であれば大丈夫だと思います。

ケーススタディ - 非商用目的の個人の使用が中心で、家族や友人にも記事を投稿させたい

今回、 IRC にて最も議論が交わされた部分です。

まず、ライセンス内に 一個人のログイン名を複数の者で共有することは禁止 と明記されているため、ライセンス所持者のログイン ID を使って投稿を行うことは不可能だろう、と。

しかし、家族や友人のためのログイン ID を作成してしまうと、それは個人の範疇を超えるため、通常ライセンスと判断すべきではないか ?

それなら、 家族・友人等が、利用許諾をされたお客様のウェブログに投稿することまでは制限をしておりません というのは一体どういう状況を指すのか ?

各人なりの解釈が飛び出し、熱い議論が交わされました。 ( 本当はモテ系 IRC チャンネルのはずなのに ! ) そこで、今回サーバ数の関係で問い合わせたついでといっては何ですが、この件についても尋ねてみました。

その回答を要約 ( 強調は私 ) すると、 「本来はライセンス所持者様の別名 ID 用の複数ライセンスということになります。 しかし家族や親しい友人までも制限するのはいかがなものかということで、その方々が投稿するための ID としてライセンスを使っていただくのは許容範囲内とさせていただいております。 しかし、その方々がオーナーとなるような Weblog を複数ご利用いただく場合や、クラブやサークルにおけるあるテーマに沿った Weblog をご利用いただく場合は通常ライセンスをご利用いただいております。」 とのことでした。

よって、個人ライセンスを持っている場合に、その家族・友人がライセンス所持者の Weblog に対しての投稿のみを行うために、ライセンスの範囲内でログイン ID を増やすことは許容されるということです。 家族や友人が更に新しい Weblog を作成したり、投稿者の追加を行ったりすることは許容されないと捉えて良いでしょう。 ( 当然ながら、限定個人ライセンス ( 無償 ) では、投稿のみの権限であれこのようなことはできません。 )

ただ、クラブやサークルといった括りで特定のテーマに沿った weblog を利用する場合は、通常ライセンスの範疇になるということですので、家族や友人が投稿のみを行う場合であっても、それを継続的に行う場合は個人ライセンスの範疇を超えると考えた方が良いかと思います。 あくまでゲスト的に、非継続的な投稿を行う程度が個人ライセンスの範疇ではないかと思います。

ケーススタディ - Movable Type のインストールを代行してもらいたい

Movable Type は CMS ツールであるため、それを活用してシステム構築を行おうというケースはよくあると思います。 ホスティング事業者にサーバの確保を依頼して、かつ Movable Type のインストールを依頼したい場合、通常ライセンスを使用することになります。 ( この場合、必ずしもホスティング事業者 = インストール実行者である必要はありませんが。 )

これは契約によっても変わりますが、たいていは「通常ライセンス自体はクライアント側で取得し、サーバホスティングおよび Movable Type のインストールは事業者側で請け負う」というパターンになると思います。

ホスティングライセンスと混同しがちですが、クライアント側がライセンスを持つという点が大きな違いでしょうか。

トラックバックポリシーの哀愁

• トラックバック・ポリシーを作ろう。ルールやマナーに悩む人のための作成ガイド [絵文録ことのは]2005/05/24

トラックバックのルールやマナーについてはいろいろな意見があるし、そもそも統一できるものでもない。 しかし、初心者にはわかりづらいのも事実。

やはり現状は各自の「トラックバック・ポリシー」をブログごとに明記しておくのがいいだろう。

まず、私の主観による否定から入ります。 ( 後から客観的な肯定もしますが。 )

これはトラックバックポリシーに限らずリンクポリシーなどでも言えることかもしれませんが、より多くの方が賛同できる、最大公約数的なポリシーがあったとしても、それを明記することによる効果というのはあまり望めません。 全く書かないよりは効果があるでしょうが、そもそもトラックバックポリシーにきちんと目を通してくれる人は、ポリシーが書かれていなくてもその人なりの節度を持ったトラックバックを行ってくれると思います。 逆に、トラックバックスパマーなどは最初からそんなものには目を通しません。

もちろん、トラックバックポリシーを明記すること自体を否定するつもりはありませんし、 「この weblog の人はどういったトラックバックなら歓迎するのだろう」 という情報を求める人がいるのも分かっています。 ただ、ポリシーを書いておけば良いというわけではないことは覚えておいてもらいたいと思います。 ( これはどちらかと言うと、引用元の記事執筆者よりもそれにトラックバックを寄せる方達へのメッセージかもしれません。 )

トラックバックポリシーを集積するということ

前項では否定を行ったので、今度は肯定を。

そのポリシーを作りやすくするために、以下、項目を挙げてみた。 選択式になっているので、自分のトラックバックに対する考え方を選んで（あるいは追記して）エントリーにしておき、トラックバック欄やサイドバーから参照できるようにしておくと精神的。

また、このトラックバック・ポリシーを使った場合は、ぜひこの記事へトラックバックしてください。 ある程度集まったら、全体の傾向を集計してみたいと思っています。 それによって、トラックバックに対する考え方の傾向と対策がわかるのではないかと。

参照できるようにしておくと精神的 という部分がちょっと気になりますが ( 「実用的」という意味でしょうか、それとも「精神衛生的に良い」というニュアンス ? ) 、多くの人の傾向を集積するというのは良いことだと思います。 常々技術仕様が云々と私は述べていますが、実際にトラックバックを活用している人達が好む傾向を知りたいと思いますし、またその傾向を軽視してはいけないと思っています。

そもそも統一できるものでもない という前置きをされている上で集計するのなら、拙筆ながら自分のポリシーを書いてトラックバックを送ろうと思います。 ( もし「統一ルールを作ろう」なんて前置きで集計するのならば、反対意見を送るところでしたが。 )

hxxk.jp のトラックバックポリシー

トラックバック・ポリシーを作ろう。ルールやマナーに悩む人のための作成ガイドの作成例を元に作成しています。 次回のリニューアル時に明記する予定ですが、項目が多いので全てを明記するとは限りません。

なお、 () 内は各項目に対する私のコメントです。 また、選択肢が不充分な項もありましたので、私なりの回答を作成している項があります。

基本

• このサイトへのトラックバックは原則フリーですが削除することもあります ( 関係なければアナウンスなく削除します。 )
• トラックバックは関連記事からであればどんと来い。 ( アクセスログでも分かりますがどうしても漏らしてしまいますし、トラックバックを積極的に送られる方が私も見聞が広がります。逆に関連が無かったらその分ガックリします。 )
• 内容に関係があってリンクもしている記事からは、トラックバックの遠慮はいりません。 ( 前項と同じです。また、別にリンクしていなくても関連があれば構いません。 )
• ここで挙げたポリシーは自分自身にも当てはめます。自分が消すようなトラックバックは他人に送信しません。 ( 関連性が高いと判断すれば遠慮なく送りますし、場合によっては相手先へのリンクが無くても送ります。 )

礼儀・挨拶

• トラックバックする前に事前連絡はしないでください。 ( 事前に連絡する必要がある状況が全く考えられません。 )
• 知らない人にいきなりトラックバックを送るのはごく当たり前のことです。 ( 知っている、知らないで分ける意味が分かりません。 )
• トラックバックをする場合に事前に許可を求める必要はありません。 ( トラックバックの許可制は、リンクの許可制同様にナンセンスだと思います。 )
• トラックバックをしましたとコメント欄に書かないでください。 ( コメント欄に書くならトラックバックは不要では ? )
• トラックバックをいただいた場合、相手記事にコメントをすることもあります。 ( お礼コメントはしません。何か新たに話題を膨らませるときにコメントします。 )
• トラックバックへのトラックバック返しはしないでください。 ( 返す意味が分かりません。 )
• トラックバックを受けたとき、トラックバック返しはしません。 ( 前項に同じ。ただし、別の関連記事を新たに書いてトラックバックを送る可能性はあります。 )
• こちらからのトラックバックに対する挨拶やお礼はしないでください。 ( お礼という概念が理解不能です。 )
• 多重トラックバックの削除依頼は必要ありません。 ( 全く同じトラックバックが重複したら勝手に削除します。でも自分が多重してしまった場合に依頼コメントをしてしまうこともあるのでケースバイケースかも。 )

削除対象

• 当方が受けたトラックバックは削除することがあります。 ( 機械的でなくても、たとえ少量でも、無分別なトラックバックは spam と何ら変わりません。容赦なく削除します。 )
• texas holdemなどの機械的・大量のトラックバックspam広告は削除します。 ( 削除してフィルタリング対象に加えます。 )
• 内容は関係がなく、当方へのリンクのない記事からのトラックバックは削除します。 ( リンクがあるとか無いとかは判断基準になりません。関連が無いということで削除します。 )
• 内容は直接関係ないが、文中で参照リンクの貼られている記事からのトラックバックは削除することもあります。 ( 参照リンクとして挙げられるなら、間接的には関連があるということですよね ? これはケースバイケースだと思います。 )
• 内容は関連しているが、当方へのリンクのない記事からのトラックバックは歓迎します。 ( 関連している記事であればリンクのある無しに関わらず歓迎します。 )
• 内容が関連しており、当方へのリンクのある記事からのトラックバックは歓迎します。 ( 前項と同じ。 )
• 当方へのリンクはあるが、一行コメントなど情報量があまりにも少ない「うなずき系」記事からのトラックバックは削除することもあります。 ( これもケースバイケースかもしれませんが、こういった場合はたいてい関連が無いと思います。 )
• 当方へのリンクだけで、まったくコメントのない記事からのトラックバックは削除します。 ( トラックバックはリンク通知じゃありませんし、私や読者に対するプラスアルファが全く無いです。 )
• 当方へのリンクがなく、誹謗中傷など悪意ある記事からのトラックバックはそれだけの理由では削除しません。 ( リンクのある無しに関わらず、誹謗中傷でもプラスアルファがあれば削除しません。根拠の無いものであれば関連無しとして削除します。 )
• 当方へのリンクがあるが、誹謗中傷など悪意ある記事からのトラックバックはそれだけの理由では削除しません。 ( リンクのある無しに関わらず、誹謗中傷でもプラスアルファがあれば削除しません。根拠の無いものであれば関連無しとして削除します。 )
• 当方へのリンクがなく、反対意見・反論が書かれている記事からのトラックバックはそれだけの理由では削除しません。 ( リンクのある無しに関わらず、反対意見・反論でもプラスアルファがあれば削除しません。根拠の無いものであれば関連無しとして削除します。 )
• 当方へのリンクがあるが、反対意見・反論が書かれている記事からのトラックバックはそれだけの理由では削除しません。 ( リンクのある無しに関わらず、反対意見・反論でもプラスアルファがあれば削除しません。根拠の無いものであれば関連無しとして削除します。 )
• 当方へのリンクがなく、こちらからトラックバックやコメントをつけられないサイトからのトラックバックはそれだけの理由では削除しません。 ( リンクのある無しに関わらず、プラスアルファがあれば削除しません。トラックバックやコメントを付けられないことは判断基準になりません。 )
• リンク元サイトの性質によってトラックバックを削除することはありません。 ※削除するサイトの性質｛アダルト／エロ／グロ／モロ／テロ／トロ／風呂／麻呂／反社会的／政治的／マルチ商法／宗教／犯罪を促す／２ちゃんねる／ゴッゴル等SEOコンテスト／自分のポリシーと反する／その他 ( リンク元サイトでは判断しません。あくまで記事で判断します。この項は削除する、しないの 2 択じゃ不充分かと。 )
• こちらの記事内からのリンクがあるにもかかわらずトラックバック返しされた場合、削除することもあります。 ( 私からのリンクを受けて更に話題を展開したなら話は別ですが、単なるオウム返しであれば削除します。 )
• 匿名の人のブログからのトラックバックはそれだけの理由では削除しません ( 実名・匿名は判断基準になりません。「真琴」という名前だって単なるハンドルですし。 )
• 人気ブログランキングへ誘導している記事からのトラックバックは削除基準を厳しくします。 ( 全てを厳しくするわけではありませんが、あからさまなランキングクリックへの誘導が見られればどうしても色眼鏡で見てしまいます。 )
• 商売サイトからの宣伝トラックバックは削除することもあります。 ( 宣伝ということは無関係な場合が多いので。関連する宣伝であれば削除しません。 )
• アフィリエイトが主たる目的のサイトからのトラックバックは削除することもあります。 ( 人気ブログランキング〜に同じ。あくまで記事主体なら削除はしませんが……。 )
• その他、管理人が削除しようと思ったという理由以外の理由なく削除することがあります。 ( ある日突然トラックバック機能自体を撤廃する可能性も無いとは言えません。 )

主観ですが、実際にこれだけ羅列されていたらトラックバックを送る気が無くなってしまいそうです。

トラックバック送信先

• トラックバック・ポリシーを作ろう。ルールやマナーに悩む人のための作成ガイド [絵文録ことのは]2005/05/24

antipop.gs をサンプルにして説明

モテ系 IRC チャンネル「 #順列都市」のモテメッカである我らがけんたろたんの antipop サーバが、 antipop.gs ドメインに移行しました。

ドメイン変更に伴う Movable Type の設定変更について、 IRC でけんたろたんとやり取りしたので、ここにメモしておこうと思います。 みんな、親しみを込めてアンチポップゲス！！！と呼ぼう！ とごろすけ ( 川o・-・）＜2nd life ) が提唱しているので、この記事内ではそれに倣ってアンチポップゲスと呼ぼうと思います。 でもきっと次回以降は Copy URL+ が取得する antipop.gs にするんだろうなあ。

もうこの際けんたろたんはアンチポップゲスを正式名称にするしか ! ( 言うのはタダ )

weblog の URI を変更する

ドメインを変更した場合、当然ですが weblog の URI が変わることになります。 すなわち、 MTBlogURL と MTBlogArchiveURL の値が変わるということです。

Movable Type の管理画面から「ウェブログの設定」を選ぶと、基本設定の画面になります。 アンチポップゲスの場合、「サイトの URL 」が http://antipop.zapto.org/mt/ で、「アーカイブの URL 」が http://antipop.zapto.org/mt/archives/ であったところを、それぞれ http://antipop.gs/mt/ と http://antipop.gs/mt/archives/ に変える必要があります。

これは管理画面から変更できる部分であるので、今さら私が述べる必要も無いかもしれません。 しかし、次項で紹介する部分は見落としやすい点だと思います。

CGI のパスを変更する

最初にドメイン変更後のアンチポップゲスを見た際に、トラックバック URI が http://antipop.zapto.org/mt/mt-tb.cgi/1301 となっていたので、「なんか変更漏れがあるんじゃ ? 」と思い、 IRC にてもう一度再構築をしてもらうよう頼んで、 Ctrl + F5 でリロードをしてみましたが変わらず。

そこで、 mt.cfg の設定がまだ変更されていないのではないかと思い、 mt.cfg のチェックを行ってもらいました。 トラックバック URI は mt.cfg の TrackbackScript ディレクティブで制御されているからですが、それは相対パスで指定されるもので、デフォルトでは mt-tb.cgi という指定になっています。 ではどこからの相対パスか ? という話になりますが、答えから言うと MTCGIPath からの相対パスということになります。

Movable TypeのCGIスクリプトがあるディレクトリのURLパス。 ウェブログの設定ファイル mt.cfg の CGIPath に設定された値です。 (インストールのときに設定します。インストールの手引を参照してください) MTCGIPath は mt-comments.cgi や mt-add-notify.cgi といった Movable Type の CGIスクリプトをリンクするために使われます。 単純に、いちいちCGIのパスをテンプレートに書き込まずに、このタグを使ってください。 例えば、コメントの投稿用フォームを作るときに、次のように使います。

<form method="post" action="<$MTCGIPath$><$MTCommentScript$>">

よって、トラックバック URI をテンプレート内に記述する場合は トラックバック URI : <$MTCGIPath$><$MTTrackbackScript$> といったような記述になります。 この記述はそのままで、 mt.cfg の CGIPath を http://antipop.zapto.org/mt/ から http://antipop.gs/mt/ に変更して再構築してもらうと、無事トラックバック URI が http://antipop.gs/mt/mt-tb.cgi/1301 に変更されました。

まとめると、ドメイン変更などによって各種スクリプトのパスが変わる場合は、 mt.cfg 内の CGIPath の変更を忘れずに行う必要があるということです。 なお、今回のアンチポップゲスのように実際のファイルが置かれているサーバは変わらず、ドメインだけが変わる場合にこの変更を漏らしてしまう確率が高いのでは、と思います。 ( 逆に、サーバごと新しく変わるような場合は Movable Type 自体を改めてインストールするため、 mt.cfg を見落とす確率は低いでしょう。 )

トラックバック送信先

• antipop2.0 - antipop.gs ドメインに移行しました

AltTemplate を使って weblog 毎の検索画面を作る

hxxk.jp の話ではありませんが、検索テンプレートを見直す機会があり、自分で書いた weblog ごとに検索結果のテンプレートを変更したいを読み返していたのですが、その記事を書いた時点ではこの方法を実際に使ったわけではありませんでした。 今回はきちんと分ける必要があったため、その手順をメモしておこうと思います。

作成手順

1. ローカルにて、 search_templates/default.tmpl を参考に新しい検索テンプレートを search_templates 内に作成。 ( 名前は任意で大丈夫です。ここでは、 hxxk.tmpl という名前で作成したと仮定します。 )
2. install directory/search_templates/hxxk.tmpl に put
3. install directory/mt.cfg を開き、 AltTemplate comments comments.tmpl の 1 行下に、 AltTemplate hxxk01 hxxk.tmpl と記述 ( 実際は 1 行下以外の場所でも大丈夫ですが、後のことを考えて近くに記述しておいた方が良いでしょう。 )
4. 検索フォームを使っているテンプレートの、 <input type="hidden" name="IncludeBlogs" value="<$MTBlogID$>" /> の行を <input type="hidden" name="Template" value="hxxk01" /> に変更。<input type="hidden" name="IncludeBlogs" value="<$MTBlogID$>" /> の行の下に <input type="hidden" name="Template" value="hxxk01" /> を追加。
5. 再構築を行って完了。

これを行うと、 mt-search.cgi に Template=hxxk01 というパラメータが渡され、 mt.cfg において AltTemplate ディレクティブで hxxk01 への対応が指定されている hxxk.tmpl を呼び出して検索するという流れになります。 よって、同様の手順で複数の AltTemplate ディレクティブによる検索テンプレートの指定を複数行うと、その weblog のテンプレート毎に異なる検索テンプレートを使うことができるというわけです。

はてなダイアリーへのトラックバックは、該当記事へのリンクが無いと送信できない

天漢日乗 - 自転車の二人乗りで赤キップ　自転車の交通違反で前科がつく場合もというリソースを巡回中に見かけ、そして冒頭で 知らなかった。 と書かれてあったので、以前取り上げた「たかが自転車」、でも道交法違反で摘発されるを参考リソースとして通知するためにトラックバックを送ろうとしたところ、

Ping 'http://d.hatena.ne.jp/iori3/20050518/p4' failed: http://d.hatena.ne.jp/iori3/ was not found in your page.

というエラーが返ってきました。 よくよく調べてみると、はてなダイアリー - はてなダイアリーTrackBackシステムとは - 受け取り側の機能に、

受信条件

はてなダイアリーでは、トラックバック送信元ページに送信先ページへのリンクが含まれる場合のみトラックバックを受信します。

これは、トラックバックスパムなどに回避するための仕様です。

という解説がありました。 そのような仕様を定めているのならそれに従わねばトラックバックを送れませんので、「たかが自転車」、でも道交法違反で摘発される - 情報番組でも取り上げられたようですという追記部分にて送信先へのリンクを追加しました。

確かにスパム対策には良いのでしょうけれど

スパム対策としては確かにこの仕様は有効でしょう。 ( 例えば Movable Type のように ) トラックバック送信先のリンクを含まないトラックバックを有効にする場合、無差別に送られるトラックバックも有効となっていしまいます。 対して、はてなダイアリーにトラックバックスパムを送ろうとする場合、トラックバック送信先へのリンクアンカーを作成する必要があります。 ( ということは、それを自動で生成されてしまった場合にはスパム対策は意味をなさなくなるということなのですが。 )

しかし、今回の私のように、既に発表済みの記事を関連記事としてトラックバックしたい場合にはその対策が障壁となります。 そう述べると、「リンクを含めればいいじゃないか」という反論がなされるのは目に見えていますが、 ( スパムではない ) リンクを伴わないトラックバックという形式も存在するので、一律にリンクが無いと言って弾くことには賛同できかねます。

トラックバックを悪用したスパムが跋扈している現状では、安易に「リンクを含まないトラックバックを受け付けてくれ」という要望を出すわけにもいかないので、こういった考えをする人間もいる、ということを表明しておくだけにしておきますが。

リンクを含まないトラックバックは好まれない ?

この項で言うリンクを含まないトラックバックは、トラックバックスパムや、全く関連性の無いトラックバックを除いた「リンクを含んでいないが、関連性の高い記事から送られるトラックバック」とします。 また、単に「似たような内容だから送られたトラックバック」も省きます。 あくまで「トラックバックを受信した weblog の制作者、あるいはその weblog の読者が、そのトラックバック元の記事を読むことでより話題の発展、展開を望めるトラックバック」について考えます。

例えば、私の手書きフォントという記事に対して、パソコンライフ・インプレッション: 無料フォントを楽しむ！自分でフォントを作る！という記事からトラックバックが送られてきました。 その記事内には手書きフォントに対するリンクがありませんが、 手書き文字をフォントにする方法を誰か教えて下さい という投げかけに対する答えとなる、関連性の高い記事です。

リンクがあるとか無いとかは全く関係なく、この記事のおかげで安価なフォント作成ソフトの存在を知ることができ、非常に参考になりました。 しかし、やはりリンクが無いトラックバックを好まない人の方が多数なのでしょうか ? Google 検索: トラックバック　リンクが無いなどを見ると、そうした意見を多く目にしましたので……。

用語の解説に誤解が含まれているのかも

各種の weblog サービスなどの、トラックバックという用語の解説にこうした風潮の原因があるのかもしれません。

はてなダイアリー

他の記事にその記事を話題にした記事のURLと概要を通知する機能、またその通知形式をさだめた枠組み。

この通知する行為をトラックバックする、トラックバックを送るという。 通知を受け取ったウェブログは普通、その言及された記事のところに通知された派生記事のURLと概要を一覧表示する。一般に、言及した本人によって送られるものとされている。

その記事を話題にした記事 というように、リンクとは明示していませんが、それに準ずるケースに限定しています。

ココログ

トラックバックは、ある記事にリンクを張ったときに、その相手（記事）に対してリンクを張ったことを伝えられる機能です。 そこには、リンクを張ったユーザーが運営するブログの URL やユーザー名、記事の概要が記述されます。

つまり、「参照元の情報が記されたリンク」と言えるでしょう。

リンクを張ったことを伝えられる機能です と、誤解を与える説明となっています。

livedoor blog

トラックバックとは、簡単に言うと「あなたが書いたことに関して私はこのように書きましたよ。」ということを通知できる仕組みです。 書いていることに対しての意見でもいいですし、同じ話題を扱っていることを知らせるためにも利用できます。

つまり、「参照元の情報が記されたリンク」と言えるでしょう。

これはリンクが行われた記事に限定せず、関連性のある記事であれば利用できると書いており、良い説明だと思います。

IT用語辞典 e-Words

ウェブログ(ブログ)の機能の一つで、別のウェブログへリンクを張った際に、リンク先の相手に対してリンクを張ったことを通知する仕組みのこと。

ウェブログ作者が別のウェブログの記事を参照して自身のサイトにコメントを掲載するような場合、元の記事へのリンクを張るのが一般的だが、単にリンクしただけでは元の記事の作者はどこからどうリンクされているのか容易に知ることはできない。 トラックバックはリンク元サイトに「このような記事からリンクを張った」という情報を通知する仕組みで、リンク元記事のURLやタイトル、内容の要約などが送信される。 トラックバックされたサイトはこの情報を元に「この記事を参照している記事一覧」を自動的に生成することができる。

こちらもリンク通知だと解説し、誤解を与える説明となっています。

Movable Type の解説はどうなっているのか

トラックバックという仕組みを初めて用いたのが Movable Type で、その技術仕様には次のような概要が示されています。

Using TrackBack, sites can communicate about related resources. For example, if Weblogger A wishes to notify Weblogger B that he has written something interesting/related/shocking, A sends a TrackBack ping to B. This accomplishes two things:

1. Weblogger B can automatically list all sites that have referenced a particular post on his site, allowing visitors to his site to read all related posts around the web, including Weblogger A's.
2. The ping provides a firm, explicit link between his entry and yours, as opposed to an implicit link (like a referrer log) that depends upon outside action (someone clicking on the link).

相手の記事にリンクを行った場合にトラックバックを送るとは全く書かれていません。 書かれているのは、面白いことや関連することやショックなことを書いたと通知したい場合にトラックバックを送るという例です。 ( 以前、有用なトラックバックとはでも同じようなことを述べました。 )

そして、それらのトラックバックを記事内にリストアップする際の文言は、英語版の Movable Type のデフォルトテンプレートによると、

<p>
Listed below are links to weblogs that reference <a href="<$MTEntryPermalink$>">'<$MTEntryTitle$>'</a> from <a href="<$MTBlogURL$>"><$MTBlogName encode_html="1"$></a>.
</p>

となっているのですが、これが日本語版になると

<p>
このリストは、次のエントリーを参照しています:  <a href="<$MTEntryPermalink$>">'<$MTEntryTitle$>'</a> from <a href="<$MTBlogURL$>"><$MTBlogName encode_html="1"$></a>.
</p>

と訳されています。 「参照」としてしまうとリンクを連想してしまいがちですが、技術仕様に合わせるならば「言及」とした方が自然だと思います。 ( リンクはしていないけれど ) 関連のある記事を通知するというのも広い意味では言及だと言えると思いますし。 「以下に並べられた weblog へのリンクは、次に示す個別エントリへ言及しています」といった表現だと良いでしょうか。 ( 英語の文法には疎いので、この訳が完璧な訳とは思っていません。 )

Movable Type の定義から「トラックバックはかくあるべき」という認識が広まったとは限りませんが、どのあたりから「トラックバック = リンク通知」という認識になっていったか、どなたかご存知でないでしょうか。

口うるさいと言われればそれまでなのですが

• 2xUP:mt.cfgをかくさないと！もっかい！またはいろいろ具体的対策をやってみる

mt.cgiのリネーム。 ついでにスパム簡単なスパム対策も兼ねてmt-comment.cgiとmt-tb.cgiもリネーム。 lolipopはApacheサーバだからコンテントネゴシエーションを用いて表示されるファイル名の拡張子も無しに

mt.cgi や mt-comments.cgi や mt-tb.cgi をリネームすること自体には異論はありません。 私自身Movable Type における CSRF の可能性と各種対処法 - 防御法 - mt.cgi の名前を変更するや Movable Type カスタマイズあれこれ - コメントスパム対策その 2 で述べていますし。

しかし、これらの CGI のファイル名の拡張子を無しにすることについては疑問を抱きました。 そこで、 2xUP:mt.cfgをかくさないと！もっかい！またはいろいろ具体的対策をやってみるに関連のある Movable Type における CSRF の可能性と各種対処法からトラックバックを送ってみたのですが、 ちなみにコンテントネゴシエーションはできるからやったわけで、これが問題の解決の歩みになるとは書いていませんのであしからず との追記がなされました。

「問題の解決には寄与しない」と言いたかったのも確かですが、それ以前に、「この問題を抜きにして考えてもコンテントネゴシエーションを行う意味が無い」と言いたかったのです。

コンテントネゴシエーションの必要性

コンテントネゴシエーションを行う必要のある状況を想定すると、

• ( UA から見た ) 同一の URI から、異なる言語のリソースを適切に判断して提供する場合
• ( UA から見た ) 同一の URI から、異なる文字コードのリソースを適切に判断して提供する場合
• ( UA から見た ) 同一の URI から、異なるメディアタイプのリソースを適切に判断して提供する場合
• ( UA から見た ) 同一の URI から、異なる種類のリソースを適切に判断して提供する場合

このような例が挙げられます。 要するに、サーバが提供する複数のリソースがある場合に、リクエストを行う UA から見た URI は同じであるように見せるケースです。

例えば、 2xUP が英語版と日本語版の両方のリソースを提供する weblog だったと仮定します。 それぞれのリソースの実態は http://2xup.org/log/yyyy/mm/dd-HHMM.html.en と http://2xup.org/log/yyyy/mm/dd-HHMM.html.ja という風になります。 そこで Accept-Language フィールドを基にしたコンテントネゴシエーションを行うことにより、 http://2xup.org/log/yyyy/mm/dd-HHMM という URI へのリクエストに対して、 UA に応じて適切なリソースを提供することができます。

管理画面の CGI に対するコンテントネゴシエーションの必要性

Movable Type によって生成される HTML に対してコンテントネゴシエーションを行うことは、充分に有意義だと思います。 現在は .html という拡張子で使われている HTML も、いつまでもその拡張子が使われるかは分かりませんし、 PHP で運用している場合は、既にそう遠くない過去に .php3 から .php への変更を経験しました。 また、 weblog の内容によっては一つの言語に留まらない場合も充分に考えられます。 そういうことを見据え、あらかじめコンテントネゴシエーションを行っておくことは、未来に向けた有効な手段だと思います。

しかし、 Movable Type の管理画面の CGI についてはコンテントネゴシエーションが必要でしょうか。 複数言語のリソースを提供するわけでなく、また拡張子が変わるような事態になっても影響を受けるわけでもありません。 ( 拡張子が変わるような大きな変更がシステム側にあった場合、影響を受けないというより、コンテントネゴシエーションによる拡張子外し程度では対処できないと考えられます。 )

できるからやった という理由で、明確なメリットを説明しないままにその方法を発表することは、その記事を見て鵜呑みにしてしまう人が出るかもしれないという危険を孕んでしまうと思います。 ( この場合は鵜呑みにしてしまう人にも問題はありますが。 )

トラックバック送信先

• 2xUP:mt.cfgをかくさないと！もっかい！またはいろいろ具体的対策をやってみる

はてなブックマークにブックマークされている記事を表示

• Lucky bag::blog: 外部の RSS を PHP で取得

これは面白そう。 面白そうというより、便利そうです。

はてなブックマークなどのソーシャルブックマークサービスにブックマークされた記事というのは、第三者に何かしらの印象を与えた記事ということなので、それを羅列することで自分の weblog からの傑作選を作るようなことができるでしょう。

私も e-luck さん ( Lucky bag::blog ) の手順を参考に、そのうちhttp://hxxk.jp/ の エントリー一覧をリストアップするテンプレートを作ってみようかな。

PHP での XML 宣言

それと、xml 宣言部分の <? が php の省略タグだと認識されてエラーになっちゃうんで、同じく .htaccess に下記を追加して省略タグを無効にした。

php_flag short_open_tag Off

この方法でも間違いではありませんが、 .htaccess を使わない方法もあります。

<?xml version="1.0" encoding="<$MTPublishCharset$>"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
( 以下省略 )

通常、 XHTML ではこのような XML 宣言の書き方になります。 ( この例では XHTML 1.0 Strict の記述を示しています。 ) それを、 PHP を用いる場合では次のように書くと良いでしょう。

<?php echo '<?xml version="1.0" encoding="<$MTPublishCharset$>"?>'."\n";?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
( 以下省略 )

このように、 echo で書き出すことで処理命令と認識されることを防ぎ、エラーを回避できます。 <?xml-stylesheet href="hoge.css" type="text/css"?> のようなスタイルシートの指定をする場合も同様です。

トラックバック送信先

• Lucky bag::blog: 外部の RSS を PHP で取得

Firefox 1.0.4 日本語版リリース

• Mozilla Firefox 1.0.4 リリースノート

Mozilla Foundation セキュリティアドバイザリ - Firefox 1.0.4 で修正済みに挙げられた脆弱性の修正がなされたバージョンです。 ITmedia エンタープライズ：Firefoxに「極めて重大」な2件の脆弱性 ( http://www.itmedia.co.jp/enterprise/articles/0505/09/news044.html ) などで紹介されたように、今回のアップデートは早急に行うべきです。

なお、 2005-05-15T14:45:54+09:00 時点では自動アップデートに対応していませんので、 http://www.mozilla-japan.org/products/firefox/ などから自分でダウンロードする必要があります。

Firefox 1.0.3 から Firefox 1.0.4 へのアップデート方法 ( スクリーンショット付 )

Firefox 1.0.3 から Firefox 1.0.4 へのアップデートの場合の手順を示します。 ( おそらく、アップデート前のバージョンが Firefox 1.0 以降であれば同様の手順で良いと思いますが。 ) なお、環境は Windows XP Home Edition SP2 を想定して書いています。

今回はFirefox 1.0.2 のアップデートは、一旦旧バージョンのアンインストールが必要のような問題はありませんので、そのまま上書きインストールで問題ありませんでした。

1. http://www.mozilla-japan.org/products/firefox/ の 無料ダウンロードというリンクからソフトェアをダウンロードします。 ここでは、デスクトップ上にダウンロードしたと仮定します。
2. Firefox のすべてのウィンドウやタブを閉じます。
3. デスクトップ上に保存された Firefox Setup 1.0.4.exe を実行します。
4. インストーラが起動しますので、「次へ」を選択して進んで下さい。
5. インストーラの指示に従ってインストールしていくと、無事 1.0.4 にアップデートされるはずです。 なお、ブックマークや拡張機能などはプロファイルから引き継がれています。

この記事の説明およびもくじ

MT をインストールしたら真っ先に行うべきセキュリティ対策という記事を 2004 年 9 月に書きましたが、当時は Movable Type 2.661 の環境を想定して書いたもので情報としては古く、また多くのトラックバックをいただいたおかげで追加情報を得られたということもあり、新たにまとめ直してみようと思いました。

MT をインストールしたら真っ先に行うべきセキュリティ対策を既に読まれた方は、いくつか重複してしまう点もありますが、こちらを単独で読める新しい一記事とするためにもご理解をお願いします。

なお、つい先日に Movable Type Publishing Platform: 【重要】 第三者による不正アクセスを許す危険性の対策についてとして movabletype.jp 上での発表が行われましたが、この記事で説明することと発表の内容は違うものです。 というか、 movabletype.jp 上での発表は第三者による不正アクセスの危険性を述べていますが、必ずしも第三者によるとは限らず、運営側が以下に述べる脆弱性について認識しているかどうかは判断できかねます。

1. 脆弱性の概要
2. 「第三者による不正アクセスを許す危険性の対策について」との違い
3. Movable Type で想定される問題
4. Movable Type に CSRF 脆弱性による攻撃を行うための情報
5. 攻撃者はいかにして情報を入手し、攻撃をするか - 特定少数のターゲットの場合
6. 攻撃者はいかにして情報を入手し、攻撃をするか - 不特定多数のターゲットの場合
7. 防御法 - Cookie を保持しない (1)
8. 防御法 - Cookie を保持しない (2)
9. 防御法 - Cookie を保持しない (3)
10. 防御法 - mt.cgi に制限をかける
11. 防御法 - 削除の確認画面以外からの削除を不可にする
12. 防御法 - mt.cgi の名前を変更する
13. mt.cgi の名前を変更した際の注意点 (1) - 管理画面のトラックバックのリンクアンカーを絶対にクリックしない
14. mt.cgi の名前を変更した際の注意点 (2) - weblog 内に mt.cgi へのリンクアンカーを作成しない
15. mt.cgi の名前を変更した際の注意点 (3) - スクリーンショットに注意
16. mt.cgi の名前を変更した際の注意点 (4) - mt.cfg 自体の保護
17. 定期的なバックアップを行うべき
18. 簡単なまとめ
19. トラックバック送信先一覧

脆弱性の概要

まず、この脆弱性についての名前を紹介します。 クロスサイトリクエストフォージェリ ( Cross Site Request Forgeries ) という用語で、 CSRF という略語が用いられます。 ( この記事でも、以後 CSRF と記述します。 )

CSRF についての解説は用語「CSRF」@鳩丸ぐろっさり (用語集)に詳しいものがありますので参照してください。

CSRF の脆弱性を用いた攻撃の例としては、昨年夏に話題になった Movable Type やはてなダイアリーにおいて記事の削除や予期しない投稿が行われるといったものや、つい先日に発生した mixi におけるはまちちゃんといったものが挙げられます。 ただし、それはあくまで一例であり、 CSRF は XOOPS や Movable Type などで問題になったため、「勝手にコンテンツを削除されてしまう」問題としてとらえられている節があります。 それは間違いではないのですが、実はもっと危険なことができるケースも...... という可能性があることも覚えておいて下さい。

勘違いされる方もおられるようですが、ウィルスやワーム、クラッキングの類とは性質が異なります。 あくまでコマンドの実行はユーザー自身が行うものである点に注意して下さい。

「第三者による不正アクセスを許す危険性の対策について」との違い

Movable Type(ムーバブル・タイプ)の脆弱性により、第三者による不正なアクセスが可能であることが確認されました。 Movable Typeのセッション管理で使われるCookieの値に、ハッシュ化されたユーザーアカウント情報が含まれており、以下の条件を全て満たした場合に、第三者による不正なアクセスが可能になります。

第三者による不正なアクセスが発生する条件：

1. 第三者が、Cookieの値を取得する。
2. 第三者が、Movable Type管理画面CGIスクリプトのパスを取得する。

また、このCookieの値が、Atom APIによるログイン時のパスワードとしても利用されているため、Cookieが第三者に漏洩した場合にAtom API対応のBlogクライアントソフトなどで、自由に記事の投稿や削除などの操作が可能になります。

これはあくまで第三者が Cookie の値を取得して不正アクセスを行う可能性を示唆するもので、 CSRF とは違います。 私が以前 MT をインストールしたら真っ先に行うべきセキュリティ対策で述べた対策を取ることで、 2 つ目の 第三者が、Movable Type管理画面CGIスクリプトのパスを取得する ことの可能性を低くすることができるように見えるので、MT をインストールしたら真っ先に行うべきセキュリティ対策のトラックバックに、今回の件の参考リソースとして取り上げた旨を通知している方も見受けられますが。 Cookie が漏洩するような事態の場合、 mt.cgi のパスを変更することは実際は危険性の軽減にはなりません。

というか、 Cookie の値を取得されてしまえば危険に晒されるというのは Movable Type に限ったことではありません。 Movable Type の脆弱性の件 : NDO::Weblog の ishinao さんのコメントにもあるように、 Cookie が漏洩してしまう脆弱性ではなく Cookie が漏洩してしまうと起こりうる事態についての発表なのです。 この記事の内容と矛盾するかもしれませんが、今回発表された事態に慌てるよりも、それが容易に起こり得ることなのか、それをしっかりと考えることが重要だと私は考えます。

ちなみに、 CSRF による攻撃の場合、極端な話をすれば必ずしも 第三者が、Cookieの値を取得する ことはありません。 攻撃者が罠を張っておき、罠にかかったユーザの Cookie を見るとは限りませんし、罠を張っただけで「罠にかかる様」すら見届けていないことだって考えられます。

Movable Type で想定される問題

• 意図しない記事の投稿
• 意図しない記事の削除
• weblog 自体の消去
• その他、管理画面から行える操作 ( 未確認 )

実際に実験したわけではないので確認はしていませんが、これらのことが行えるようです。 何故こういったことを行うことができるかの理論は SG::Acme : attacking MT 1 に詳しく書かれていますが、 ターゲットのMTの環境に関する僅かな情報があれば、Cookie認証を済ませたユーザーに任意の操作を行うmt.cgiへのクエリを含んだurlを踏ませることで、確認なくその動作を実行 させる攻撃手段が一例として挙げられます。

なお、これは Movable Type だけに存在する脆弱性ではなく、 Cookie を利用してユーザーログインを行っている weblog ツール・ weblog サービスのほぼ全てに同様の脆弱性が存在すると思った方が良いでしょう。 実際にはてなダイアリーではごく小さな範囲ですが、テストによって実行が可能であることが証明されましたし ( 現時点では対策が行われています。 ) 、 mixiでは不特定多数のユーザがこの攻撃にひっかかりました。

Movable Type に CSRF 脆弱性による攻撃を行うための情報

• Movable Type がインストールされたディレクトリ
• 管理画面のファイル名

実際の攻撃手段に用いられる情報はこの 2 つです。 「第三者による不正アクセスを許す危険性の対策について」との違いでも述べていますが、 Cookie の値は必須ではありません。 必須ではないというか、 Cookie の値は消去等のリクエストを行うユーザー ( = その Movable Type のオーナー ) が既に保持しているパターンであるため、わざわざ取得する必要が無いとでも言いましょうか。

通常、 Movable Type をインストールしたディレクトリと、実際に weblog を公開するディレクトリは必ずしも一致しません。 おそらく、それらのディレクトリは別にしているユーザがほとんどでしょう。 では、別にしているからオーナー以外はインストールディレクトリを知る術は無いのか ? 残念ながらそんなことはありません。

コメント投稿フォームから探す

個別エントリーアーカイブにはコメント投稿フォームが配置されていますので、その form 要素の action 属性を見れば /Install directory/mt-comments.cgi という URI を知ることができます。

トラックバックから探す

個別エントリーアーカイブの head 要素には <$MTEntryTrackbackData$> として /Install directory/mt-tb.cgi という URI が示されています。 更に、このエントリーのトラックバックURL: として堂々と記事内に書かれています。

検索フォームから探す

Movable Type 内の検索フォームの、 form 要素の action 属性を見れば /Install directory/mt-search.cgi という URI を知ることができます。

ぱっと思いつくだけでも、これだけ簡単にインストールディレクトリを知ることができます。 そして、管理画面となるファイル名はデフォルトでは mt.cgi です。 もうお分かりでしょう。 上記の方法で取得したインストールディレクトリ下の mt.cgi にブラウザからアクセスしてみて、管理画面へのログイン画面が出れば 2 つの情報の入手は完了です。

更に、 中には「管理用」などとご丁寧に mt.cgi へのアンカーが記述されているブログもあります という状況なのです。 攻撃用の情報は丸裸だと言っても過言ではないでしょう。

攻撃者はいかにして情報を入手し、攻撃をするか - 特定少数のターゲットの場合

1. ターゲットが特定少数の場合、まずターゲットの情報を前項の方法で取得します。
2. 任意の操作を行うmt.cgiへのクエリを含んだurlを作成します。
3. そして、それをターゲットのコメント欄に書き込むか、トラックバック欄に残します。
4. Movable Type のオーナーがログイン状態でそのリンクアンカーを辿ることで攻撃が成立します。

CSRF は、ログイン済みの正規のユーザに「削除」のリクエストを行わせる攻撃です。 たとえば、攻撃者はサイト上に「削除」コマンドのリクエストとなるようなリンクを用意しておきます。 一般のユーザがこのリンクをたどっても何も起きません。 しかし、管理画面にログインしている状態のユーザがリンクをたどると、削除が実行されてしまうことになります。

このように、オーナー以外のユーザーが攻撃者によるリンクアンカーを辿っても実害はありませんし、オーナーであってもリンクアンカーを辿らなければ実害はありません。 しかし、コメント欄やトラックバック欄に残されたリンクアンカーは、オーナーであれば辿ってしまう確率は非常に高いと思います。

攻撃者はいかにして情報を入手し、攻撃をするか - 不特定多数のターゲットの場合

前項の方法だけであれば、攻撃手段としてはあまり効率が良くないのでは ? と思われるかもしれません。 しかし、不特定多数に自動的に攻撃を行う手段も考えられています。

たとえばMTを攻撃の的としたいなら

1. http://ping.bloggers.jp/ などのping鯖で公開されているrdfをごそっと取得
2. そのなかからMTで生成されたものを選別
3. 悪意のあるスクリプトがあるURLを、上で選別されたMTサイトに自動でトラックバックする
4. 管理者が管理画面からそのURLを踏む or (管理画面じゃなくってサイトから)普通にクリック
5. refererのURLからmt.cgiの場所を推測
6. javascriptやmeta refreshなどで自動でPOSTやGETを送信させる
7. 記事が全削除される
8. (゜д゜)クマー

上記の方法をスクリプトなどで実行することにより、数十人はひっかかって全記事削除されると思います。

防御法 - Cookie を保持しない (1)

この防御法で危険性を低くできる攻撃

• Movable Type における CSRF 攻撃
• 第三者による不正アクセス

Movable Type において、一般のユーザーとオーナーの区別は管理画面へのログインを行えるか否かという点で、それは Cookie によって判断されます。 ということは、ログアウトをしていればオーナーであっても Movable Type における CSRF 攻撃は成立しないのです。

よって、管理画面へのログイン中は他のサイトを見ないようにする、作業終了後は必ずログアウトするようにすることで危険性を軽減できます。

防御法 - Cookie を保持しない (2)

この防御法で危険性を低くできる攻撃

• Movable Type における CSRF 攻撃
• 第三者による不正アクセス

ブラウザのクッキー機能をオフにする

一番確実なのはこれかもしれない。 試しにやってみた。 IEなら、「ツール」→「インターネットオプション...」→「プライバシー」と進み、スライダーを最高（全てのCookieをブロック）にすればいい。

しかしこれでは、MTの管理画面で何かする度にIDとパスワードの入力が発生する。 確実だが、かなりうっとうしい。

これは前項と考え方は似ています。 毎回ログアウトするというのはその都度 Cookie を破棄するということですが、こうすることにより最初から Cookie を拒否しておくことができます。

ちなみに Firefox の場合は

1. ツール
2. オプション
3. プライバシー
4. Cookie データの保存
5. 「 Cookie を有効にする」のチェックを外す

という手順になります。

防御法 - Cookie を保持しない (3)

この防御法で危険性を低くできる攻撃

• Movable Type における CSRF 攻撃
• 第三者による不正アクセス

普段ブラウジングに使っているブラウザと、更新管理とかに使うブラウザを別にするという方法。 普段IE系ブラウザを使っている場合は、更新管理はFirefoxを使うようにすれば、管理ツールの認証情報はFirefoxでのみ維持されるんで、IE上で攻撃URLを踏んでも自動認証されたりはしなくなる。

これは以前も紹介しましたが、シンプルかつ便利な方法だと思います。 これだと毎回ログアウトする必要もありません。 ( これは mixi などでも有効な方法でしょう。 )

防御法 - mt.cgi に制限をかける

この防御法で危険性を低くできる攻撃

• Movable Type における CSRF 攻撃
• 第三者による不正アクセス

デフォルトでは mt.cgi のガードは user/pass による認証だけです。 そのために Cookie が漏洩すれば不正アクセスが可能になりますし、 CSRF 攻撃も可能となっています。

そこで、 *mt3::MRU: 【緊急】【その他の対策】 第三者による不正アクセスを許す危険性の対策について (c)yukkie を参考に、 mt.cgi の認証に加えて mt.cgi 自体への認証を施すという防御法があります。 当然ながら、 .htpasswd のパスワードは mt.cgi のパスワードとは別にする必要があります。

防御法 - 削除の確認画面以外からの削除を不可にする

この防御法で危険性を低くできる攻撃

• Movable Type における CSRF 攻撃

ゑBLOG: MTへの修正にて紹介されている方法は、 CSRF によって意図しない削除を防ぐのに有効な方法です。

削除前の確認画面を表示する際に乱数で生成した適当な値をクッキーとPOSTのパラメータの両方に積んでおき、 実際の削除の時には両方が一致したときだけ削除を実行するようにします。 こうすることで削除前の確認画面以外からの削除ができなくなります。

これは、高木浩光＠自宅の日記 - クロスサイトリクエストフォージェリ（CSRF）の正しい対策方法にて 簡潔な対策方法 として紹介されている方法で、 mt.cgi のファイル名変更よりも有効だと思います。

ただし、これは CSRF 攻撃に対して有効な手段ではありますが、 Cookie が漏洩して mt.cgi に不正アクセスされた場合は削除の確認画面にも到達されるため、有効ではありません。

防御法 - mt.cgi の名前を変更する

この防御法で危険性を低くできる攻撃

• Movable Type における CSRF 攻撃

根本的な解決にはなりませんが、 mt.cgi のファイル名を変更することにより、 mt.cgi に対して向けられた攻撃を高い確率で回避できます。 手順としては、

1. mt.cgi のファイル名を変更し、サーバに put します。
2. mt.cgi を削除します。
3. mt.cfg の # AdminScript mt.pl と書いている行のコメントを消して ( 先頭の # と半角スペースを削除 ) 、mt.pl の部分を mt.cgi から変更した後の名前に変更し、サーバに put します。
4. tmpl/cms/header.tmpl を spanstyle::monolog: MovableTypeに脆弱性が発見されましたの記述を元に変更し、サーバに put します。

ただし、この方法は抜け道が多く存在するため、次項以降で述べる対策を同時にとっておかないと、たちまちこの対策は意味をなさなくなります。 ファイル名の変更は手軽に行える対処法ではありますが、完璧なものではないことに注意してください。 なお、 Movable Type 3.11-ja 頃のバージョン以前のものを使用している場合、 lib/MT/App.pm にも修正箇所がある点に注意。

mt.cgi の名前を変更した際の注意点 (1) - 管理画面のトラックバックのリンクアンカーを絶対にクリックしない

mt.cgi のファイル名を変更すれば、少なくとも mt.cgi という名前のファイルに対する攻撃を回避することができますが、変更後のファイル名が漏れてしまっては意味がありません。 漏れる可能性が高いのが、この管理画面に表示されるトラックバックではないでしょうか。

ログイン直後に weblog を選択したら 最新5件のトラックバック が表示されており、送られてきたトラックバックのリンクアンカーが羅列されています。 また、トラックバックの一覧画面にもリンクアンカーが羅列されています。 これを不用意にクリックしてしまうと、悪意あるトラックバックが含まれていた場合に、 mt.cgi から変更した後のファイル名をリファラから知られてしまいます。

また、トラックバックの URI 自体にリダイレクトなどが仕込まれ、 CSRF による攻撃を受けてしまうことも考えられます。 この場合、既に管理画面にログインしている状態ですので、危険度はかなり高くなります。

mt.cgi の名前を変更した際の注意点 (2) - weblog 内に mt.cgi へのリンクアンカーを作成しない

Movable Type に CSRF 脆弱性による攻撃を行うための情報でも引用しましたが、 中には「管理用」などとご丁寧に mt.cgi へのアンカーが記述されているブログもあります というのが現状です。 せっかく mt.cgi のファイル名を変更していても、それを堂々と表に出していては意味がありません。

ARTIFACT ―人工事実― | MovableTypeの記事修正を楽にするで直接記事編集が行えるような手法が紹介されていますが、セキュリティの観点からすると推奨できません。

どうしてもこの手法を取りたいならば、合わせて自分にしか見えない [編集] リンクを作る | alectropeという手法を取り入れるか、または BASIC 認証を施したディレクトリに、編集リンクを表示するような archives.html を配置するようにした方が良いでしょう。

mt.cgi の名前を変更した際の注意点 (3) - スクリーンショットに注意

Movable Type の手順解説などを書く場合、自分の Movable Type をサンプルとしてスクリーンショットを掲載しているケースはよく見られます。 ( hxxk.jp もその一部です。 ) このときに、アドレスバーの URI を隠しておかないと、せっかくの mt.cgi のファイル名変更も意味がありません。

mt.cgi の名前を変更した際の注意点 (4) - mt.cfg の保護

防御法 - mt.cgi の名前を変更するで述べた通り、 mt.cgi のファイル名を変更したら、その名前を mt.cfg に書き込みます。 よって、少なくともブラウザから簡単に読み込めるような状態にしておくよりは、ある程度の保護下に置いた方が良いでしょう。

例えば、パーミッションの値を 400 や 600 などに設定する、 .htaccess でアクセス制限をするなどの方法が考えられます。 .htaccess による制限の場合、 Movable Typeのインストール - mt.cfgの保護にて説明がなされていますが、少々説明不足な面があります。 合わせて Movable Type のマニュアルの記述だと mt.cfg は保護できないをご覧ください。

定期的なバックアップを行うべき

やれ危険性だ防御法だと長々と述べてきましたが、データベースのバックアップを定期的に取る方がよほど効果的かもしれません。

何の対策もしていないのが実際のところ。 今後も対策する予定はない。 理由はいろいろあるが、別にブログが消えたっていいから、というのが大きい。 データベースや生成した記事は、定期的にバックアップしている。

レンタル型の weblog サービスではそうも行かないでしょうが、 Movable Type はサーバにインストールして使う weblog ツールで、データベースを用いることが基本になっています。 例えば MySQL を用いて運用しているのなら、定期的に mysql.dump をバックアップしておくことで、仮に第三者の不正アクセスや CSRF による攻撃を受けても被害を最小限に留めることができます。

仮に記事はおろかテンプレートやコメント、トラックバックも含め全部消されたとしても、 dump から復元するとあっさりと元通りになります。そしてその後でログインパスワードを変更してしまえば、涼しい顔で運営を続けられるはずです。

簡単なまとめ

• Movable Type Publishing Platform: 【重要】 第三者による不正アクセスを許す危険性の対策についてで述べられていることは、 Cookie が漏洩してしまう脆弱性ではなく Cookie が漏洩してしまうと起こりうる事態なのです。
• mt.cgi のファイル名変更に最も行数を割いて述べていますが、完璧な方法ではありません。割とイージーミスで穴はできますし、穴が無かったとしても根本的な対処法ではありません。
• ログアウトをきちんとするとか閲覧環境と更新環境を別にするとかいった方法は Movable Type に限ったことではなく、ユーザーが web アプリケーションを使用する際の心構えだと思います。
• Movable Type の脆弱性を紹介したいわけではありません。 CSRF という言葉の存在を知ってもらいたいのです。
• というか、受け売りだらけで構成している記事なので、間違った認識をしている面が少なからずあると思います。

トラックバック送信一覧

ねこまんだら:MTに脆弱性

Movable Type日本語版の全てのバージョンが対象です と書いていますが、 英語版にも同様の問題が発生します 。

あるまむーん王国：そこら中で不正アクセス

Movable Typeならまだいーと思うのよ、オープンソースだし。 確かに大変な事だが、責任を押し付けちゃイカンと思うのねん。 オープンソースだと責任を取らなくて良いということもありません。 というかそもそも Movable Type はオープンソースじゃありません。

drry+@->Weblog - Movable Type の CSRF による脆弱性が公表

今回シックスアパートが発表したのは、同じような対処法が考えられますが CSRF による脆弱性じゃないと思います。

日々刻々: MTの脆弱性が報告されていました。

MTに関する脆弱性を、それに何の対処も施していないMT上で報告してるって状況はかなり笑えますな。ガード下がりまくり。 movabletype.jp のものは対処が行われているように見受けられます。 トラックバックを受け付けていない weblog でした。

COZY-LiFE - Movable Type、第三者による不正アクセスを許す危険性

blog自体削除されちゃったらもうおしまいだし... DB の dump を定期的に取っていれば、 weblog 自体を削除されてもそこまで大きな問題にはなりません。 もちろん復元の手間は否めませんが。

Movable Typeで第三者の不正アクセスを許可してしまう脆弱性：やじlog本舗

バージョンアップってめんどくさいじゃないですか バージョンアップせずに、シックスアパートが発表した対処を行えば良いのではないでしょうか。

E=Mac^2 Blog: .htaccessによるアクセス制限

<Limit GET> によるメソッドの制限は推奨されません。 http://hxxk.jp/mt/2005/01/21/2250 を参照してください。

民主党 喜納昌吉参議院議員の長男に実刑判決

知人の男性に因縁を付けて現金を脅し取ったとして、恐喝罪に問われた喜納（きな）昌吉参院議員（民主）の長男で飲食店従業員喜納昌哲（まさてつ）被告（２７）（那覇市牧志）の判決が１０日、横浜地裁であった。

河村潤治裁判官は「犯行は計画的で執よう、悪質で刑事責任は軽視できない」として、昌哲被告に懲役１年８月（求刑・懲役２年６月）の実刑を言い渡した。

この件ですが、逮捕当初は否認していました。

神奈川県警茅ケ崎署は２日、同僚から現金３０万円を脅し取ったとして、那覇市牧志１丁目、飲食店従業員喜納昌哲容疑者（２７）を恐喝容疑で逮捕したと発表した。 喜納容疑者は否認しているという。

しかし、計画的で執拗と裁判官に評されるようなほどの犯行を否認し通せると思ったのでしょうか……。

妙に検索からのリファラが多かった

何故この件を取り上げたのかというと、ニュース自体よりも、そのニュースを取り巻く環境に興味が湧いたからです。 11 月の逮捕当時に、 TuneDoc というクリップ用のページを作っていたのですが、 5 月 10 日になって急激にアクセス数が増えました。

5 月 10 日のアクセスログを見ると、「喜納」を含むキーワードで検索してきた方は、検索エンジンからのビジターの 43% にも上ります。 そして、全体のアクセスの内検索エンジンからのアクセスは 69.2% です。 つまり、全体のアクセスの内「喜納」を含むキーワードで検索してきた方は 29.76% に上るのです。 これだけの割合を占めたので、何事かと思い調べてみると実刑判決のニュースを見つけたというわけでした。

何故そんなにアクセスがあったのかというと、検索でヒットする件数の少なさによるものでしょう。 現時点で Google 検索: 喜納昌哲は 81 件、 Yahoo!検索 - 喜納昌哲に至っては 34 件です。 国会議員の子息の恐喝事件となると、もう少し多くのサイトが取り上げるものだと思っていましたが、そうでもないようです。 ( かくいう私もアクセスログで目立っていたから取り上げただけなのでですが。 )

日本語のキーワードでタグ付けすること

• drry+@->Weblog - Tag にマルチバイトは如何なものか

タグ付けの仕組みを取り入れる際にいろいろと参考にしたのは「Technorati はどのようにしているか？」でした。 その Technorati 基準でいくならば、Tag の一覧を見る限り日本語のタグはセーフです。 一方で、タグに日本語ってどーよ？とも思ってしまうのです。 うーん。 どうしよう。 どうしよう。

現在、 AllKeywords Plugin と MT-XSearch の連携手順も一通り終わってタグ付け作業に入っているところですが、 Movable Type や weblog なんてキーワードはそのままの方が良いのですが、道路交通法なんかのキーワードは日本語のまま扱った方が良いと思い、全く悩むことなく日本語を使いまくっています。

というのも、カテゴリに日本語名を設定した場合には cat_aaaaeaaea.html みたいなファイル名になるのに対し、 MT-XSearch を使用した場合は単に検索クエリをトリガーに ReWrite するだけなので、日本語を扱うことにあまり後ろめたさを感じることがなかったことにも起因します。 ( まあ、こういった場合に「後ろめたい」なんて判断基準で選ぶのはどうかと思いますが。 )

テンプレートの記述に注意

ただし、キーワードを元に記事をリストアップするような事をしている場合 ( 要するに、 /tag/keyword のようなリンクアンカーが出来るような場合 ) はテンプレートの記述に注意が必要です。 ここでは、テンプレートにて <$MTBlogURL$>tag/<$MTAllKeyword$> といったリンクアンカーの作り方をしていると仮定します。

例えば、 Movable Type というキーワードの場合を考えてみましょう。 デリミタにスペースを用いている場合は Movable と Type というキーワードとして扱われ、それぞれ /tag/Movable と /tag/Type という URI のリンクアンカーになると思います。 しかし、デリミタに , を用いている場合は、 Movable Type というキーワードとして扱われ、 /tag/Movable Type という、 URI に空白を含んだリンクアンカーになってしまいます。

空白を含んだキーワードはまだ良いとして、日本語のキーワードの場合はどうなるか。 更に、ブログというキーワードの場合を考えてみましょう。 すると、リンクアンカーは /tag/ブログ といった日本語を含む URI になります。

日本語を含む URI がいけない理由は RFC 2396 を参照していただくと良いでしょう。 すごく簡潔に言うと、 ASCII文字コード表のうちの 0x20 〜 0x7e の範囲の文字しか使ってはいけない、それ以外の文字はエスケープして用いよということです。

よって、ブログという日本語キーワードを元に /tag/%A5%D6%A5%ED%A5%B0 というリンクアンカーを作成すれば問題は解決されます。

encode_url アトリビュートを指定する

では、実際のテンプレートはどう書けば良いのか。 encode_url アトリビュートを指定することで日本語キーワードを用いてもエスケープできるようになります。

<$MTBlogURL$>tag/<$MTAllKeyword$> というリンクアンカーの作り方の場合、 <$MTBlogURL$>tag/<$MTAllKeyword encode_url="1"$> と変更することにより、日本語キーワードを用いたリンクアンカーも問題無く利用できるようになります。

トラックバック送信先

• drry+@->Weblog - Tag にマルチバイトは如何なものか
• Ogawa::Memoranda: AllKeywords Plugin

AllKeywords Plugin を存分に活用しよう

既に AllKeywords Plugin とキーワードによるテンプレートで AllKeywords Plugin の素晴らしさをとくと語ったところですが、実際にどう導入すれば良いかをまとめて、更に利用者を呼び込もうという目論見です。

なお、これ以降の項は Ogawa::Memoranda: AllKeywords Plugin および Ogawa::Memoranda: AllKeywords PluginとMT-XSearchの連携の 2 つの記事およびそれに付随するコメントなどをよく読んだことを前提として書いています。 また、必要なプラグインはダウンロード済と仮定します。 ちなみに、 MT-XSearch を使わない方法もありますが、この記事では割愛します。

1. AllKeywords Plugin をインストール
2. MT-XSearch をインストール
3. AllKeywords Plugin と MT-XSearch を連携させる
4. 失敗例
5. tips

AllKeywords Plugin をインストール

1. all-keywords.zip を解凍します。
2. all-keywords.pl を install directory/plugins/all-keywords.pl に put します。

MT-XSearch をインストール

1. MT-XSearch のアーカイブを解凍します。
2. • plugins\mt-grep.pl を install directory/plugins/mt-grep.pl に put します。
   • plugins\mt-xsearch.pl を install directory/plugins/mt-xsearch.pl に put します。
   • extlib\MT\XSearch.pm を install directory/extlib/MT/XSearch.pm に put します。
3. Ogawa::Memoranda: AllKeywords PluginとMT-XSearchの連携を参考に、 mt-xsearch.cgi にパッチを適用します。
4. mt-xsearch.cgi を install directory/mt-xsearch.cgi に put します。
5. mt-xsearch.cgi のパーミッションを実行可能な状態にします。 ( これはサーバ等の環境によって異なるので、具体的な値は各々違います。 XREA の場合だと 700 になります。 )

AllKeywords Plugin と MT-XSearch を連携させる

1. XSearch AllKeywords という名前のテンプレートモジュールを作成します。モジュールの作成例は Ogawa::Memoranda: AllKeywords PluginとMT-XSearchの連携 を参照してください。
2. <$MTBlogURL$>.htaccess を編集します。

   RewriteEngine on
   RewriteRule ^tag/(.*)$ /mt/mt-xsearch.cgi?blog_id=1&search_key=AllKeywords&search=$1
   

   ^tag/(.*)$ や /mt/mt-xsearch.cgi や blog_id=1 の部分は適宜環境に応じて変更してください。

失敗例

キーワードによるサーチを行うと、 Execution of this script not permitted で始まるエラーメッセージが出る

mt-xsearch.cgi のパーミッションが不適切な値になっています。

キーワードによるサーチを行うと、 Got an error: Can't call method "build" without a package or object reference at <$MTCGIPath$>/mt-xsearch.cgi line **. というエラーメッセージが出る

テンプレートモジュール XSearch AllKeywords の名前を間違えているか、あるいは XSearch AllKeywords が未作成のままです。

tips

空白を含むキーワード ( 例 : Movable Type ) も扱いたい

• drry+@->Weblog - 五畳半フォークソノミー開始

RewriteEngine on
RewriteRule ^tag/(.*)$ /mt/mt-xsearch.cgi?blog_id=1&search_key=AllKeywords&delimiter=,&search=$1

.htaccess の記述を上記のように変更すると、キーワードのデリミタ ( 区切り文字 ) を , として扱うようになります。

AllKeywords Plugin は、 デフォルトでは空白文字(スペース、タブ)をデリミタとする ため、次に羅列するコンテナタグをテンプレート内で使う場合は、 delimiter="," という指定を合わせて行うようにしてください。

• MTAllKeywords コンテナタグ
• MTEntryAllKeywords コンテナタグ
• MTEntriesWithKeywords コンテナタグ
• MTMostRelatedEntries コンテナタグ

コメントとトラックバックの扱いの違い

hxxk.jp template set -standard- のコードを見直している時に再認識したことがあるので書いておきます。

Movable Type の各記事のコメントについては、「なし」「オープン」「クローズ」という 3 つの状態があり、トラックバックの場合は「トラックバックを受けつける」または「受けつけない」の 2 つの状態があります。 これはそれぞれの特性をきちんと理解して使わないと混乱しますので、一覧にしてみました。

1. コメント「オープン」
2. コメント「なし」
3. コメント「クローズ」
4. トラックバックを受けつける
5. トラックバックを受けつけない
6. トラックバックを受けつけない場合の問題点
7. 公開テンプレートも差し替えました

コメント「オープン」

コメントが「オープン」の状態は、コメント部分の表示をしつつ、コメントの投稿自体も受け付ける状態です。 記事のコメントの状態が「オープン」になっていれば、テンプレートの中で <MTEntryIfCommentsOpen> 〜 </MTEntryIfCommentsOpen> で囲まれた部分が有効になります。

MTEntryIfCommentsOpen テンプレートタグは 名前に If が含まれているタグ なので、 <MTEntryIfCommentsOpen> 〜 </MTEntryIfCommentsOpen> の内側で MTElse テンプレートタグを用いて「オープンではない」状態の記述をすることもできます。

コメント「なし」

コメントが「なし」の状態は、コメント部分の表示をせず、またコメントの投稿自体も受け付けない状態です。 最初からコメントの投稿を受け付けない場合に用います。 記事のコメントの状態が「なし」になっていれば、テンプレートの中で <MTEntryIfCommentsOpen> 〜 </MTEntryIfCommentsOpen> で囲まれた部分が無効になります。

MTEntryIfCommentsOpen テンプレートタグは 名前に If が含まれているタグ なので、 <MTEntryIfCommentsOpen> 〜 </MTEntryIfCommentsOpen> の内側で MTElse テンプレートタグを用いていればその部分の記述が有効になります。

しかし、実際のテンプレートでは <MTEntryIfCommentsOpen> 〜 </MTEntryIfCommentsOpen> の更に外側を <MTEntryIfAllowComments> 〜 </MTEntryIfAllowComments> で囲んでいるため、コメント「なし」の状態では <MTEntryIfCommentsOpen> 〜 </MTEntryIfCommentsOpen> 内に MTElse を記述していてもその部分は表示されません。

最初からコメント「なし」の状態であればコメント関係の部分全てが表示されません。 また、最初はコメント「オープン」で公開し、後からコメント「なし」にした場合、既に投稿されたコメントも表示されなくなってしまいます。 既にコメントが投稿されている場合は、コメント「なし」ではなくコメント「クローズ」を使うようにしてください。

コメント「クローズ」

コメントが「クローズ」の状態は、コメント部分の表示をしますが、コメントの投稿自体は受け付けない状態です。 コメントの投稿を締め切った場合に用いられます。 記事のコメントの状態が「クローズ」になっていれば、テンプレートの中で <MTEntryIfCommentsOpen> 〜 </MTEntryIfCommentsOpen> で囲まれた部分が無効になります。

MTEntryIfCommentsOpen テンプレートタグは 名前に If が含まれているタグ なので、 <MTEntryIfCommentsOpen> 〜 </MTEntryIfCommentsOpen> の内側で MTElse テンプレートタグを用いていればその部分の記述が有効になります。

コメント「なし」で説明したのと同様に、実際のテンプレートでは <MTEntryIfCommentsOpen> 〜 </MTEntryIfCommentsOpen> の更に外側を <MTEntryIfAllowComments> 〜 </MTEntryIfAllowComments> で囲んでいますが、 MTEntryIfAllowComments テンプレートタグは コメントの設定が Open もしくは Closed の場合に表示されます という扱いになっているため、既に投稿されたコメントは表示され、コメント投稿フォームだけが表示されないようになります。

トラックバックを受けつける

「トラックバックを受けつける」状態 ( = チェックボックスにチェックが入っている状態 ) は、トラックバック用の URI や受信したトラックバックの一覧を表示する状態です。 記事の「トラックバックを受けつける」のチェックボックスのチェックが入っていれば、テンプレートの中で <MTEntryIfAllowPings> 〜 </MTEntryIfAllowPings> で囲まれた部分が有効になります。

MTEntryIfAllowPings テンプレートタグは 名前に If が含まれているタグ なので、 <MTEntryIfAllowPings> 〜 </MTEntryIfAllowPings> の内側で MTElse テンプレートタグを用いて「トラックバックを受け付けない」状態の記述をすることもできます。

トラックバックを受けつけない

「トラックバックを受けつけない」状態 ( = チェックボックスにチェックが入っていない状態 ) は、トラックバック用の URI や受信したトラックバックの一覧を表示しない状態です。 記事の「トラックバックを受けつける」のチェックボックスのチェックが入っていなければ、テンプレートの中で <MTEntryIfAllowPings> 〜 </MTEntryIfAllowPings> で囲まれた部分が無効になります。

MTEntryIfAllowPings テンプレートタグは 名前に If が含まれているタグ なので、 <MTEntryIfAllowPings> 〜 </MTEntryIfAllowPings> の内側で MTElse テンプレートタグを用いて「トラックバックを受け付けない」状態の記述をしていれば、その部分が表示されます。

トラックバックを受けつけない場合の問題点

実は、デフォルトテンプレートには <MTEntryIfAllowPings> 〜 </MTEntryIfAllowPings> で囲む範囲を間違えているという問題があります。

<MTEntryIfAllowPings>
<h2 id="trackbacks">トラックバック</h2>
<p class="techstuff">このエントリーのトラックバックURL:<br />
<$MTEntryTrackbackLink$></p>

<MTIfNonZero tag="MTEntryTrackbackCount">
<p>このリストは、次のエントリーを参照しています:  <a href="<$MTEntryPermalink$>"><$MTEntryTitle$></a>:</p>

<MTPings>
<p id="p<$MTPingID$>">
» <a href="<$MTPingURL$>"><$MTPingTitle$></a> from <$MTPingBlogName$><br />
<$MTPingExcerpt$> <a href="<$MTPingURL$>">[続きを読む]</a>
</p>
<p class="posted">トラックバック時刻:  <$MTPingDate$></p>
</MTPings>
</MTIfNonZero>
</MTEntryIfAllowPings>

この記述ですと、最初にトラックバックを受けつけるようにしていて、後からトラックバックを受けつけないようにした場合に、受信済みのトラックバックも表示しなくなってしまいます。 何故なら、 MTEntryIfAllowPings テンプレートタグは エントリーがトラックバックを受けつける設定になっているときに、内容を表示するコンテナ・タグ であるため、トラックバックを受けつけない設定になっていなければその内容を表示することはありません。

<MTIfNonZero tag="MTEntryTrackbackCount">
<h2 id="trackbacks">トラックバック</h2>

<MTEntryIfAllowPings>
<p class="techstuff">このエントリーのトラックバックURL:<br />
<$MTEntryTrackbackLink$></p>
<MTElse>
<p class="techstuff">このエントリーはトラックバックの受付を終了しました。</p>
</MTElse>
</MTEntryIfAllowPings>

<MTElse>
<MTEntryIfAllowPings>
<h2 id="trackbacks">トラックバック</h2>
<p class="techstuff">このエントリーのトラックバックURL:<br />
<$MTEntryTrackbackLink$></p>
</MTEntryIfAllowPings>
</MTElse>

<p>このリストは、次のエントリーを参照しています:  <a href="<$MTEntryPermalink$>"><$MTEntryTitle$></a>:</p>

<MTPings>
<p id="p<$MTPingID$>">
≫ <a href="<$MTPingURL$>"><$MTPingTitle$></a> from <$MTPingBlogName$><br />
<$MTPingExcerpt$> <a href="<$MTPingURL$>">[続きを読む]</a>
</p>
<p class="posted">トラックバック時刻:  <$MTPingDate$></p>
</MTPings>

</MTIfNonZero>

このようにテンプレートを書けば、おそらく問題は無いはずです。 その場合の、それぞれのパターンを想定すると次のようになります。

トラックバックを 1 件も受信しておらず、トラックバックを受け付けない場合

トラックバック関連の部分は全く表示されません。 コメント「なし」と同じような状態です。

トラックバックを 1 件も受信しておらず、トラックバックを受け付ける場合

<h2 id="trackbacks">トラックバック</h2>
<p class="techstuff">このエントリーのトラックバックURL:<br />
http://hxxk.jp/sys/mt3/mt-tb.cgi/580</p>

のような記述になります。

トラックバックを 1 件以上受信しており、トラックバックを受け付けない場合

<h2 id="trackbacks">トラックバック</h2>
<p class="techstuff">このエントリーはトラックバックの受付を終了しました。</p>
<p>このリストは、次のエントリーを参照しています: ( 以下受信したトラックバックを表示 )

のような記述になります。 コメント「クローズ」と同じような状態です。

トラックバックを 1 件以上受信しており、トラックバックを受け付ける場合

<h2 id="trackbacks">トラックバック</h2>
<p class="techstuff">このエントリーのトラックバックURL:<br />
http://hxxk.jp/sys/mt3/mt-tb.cgi/580</p>
<p>このリストは、次のエントリーを参照しています: ( 以下受信したトラックバックを表示 )

のような記述になります。

単数形 ? 複数形 ?

• Hatena::Diary::Code-404 - 表記は統一しませんか？
• Hatena::Diary::Code-404 - コメント欄

trackback が正しいのか trackbacks が正しいのか ? というお話。

ただし、あくまで feedback という単語の例を基にして考えれば s は付かないだろうということなので、造語である trackback にこの方式をそのまま当てはめていいかどうかは分からないそうです。 むしろ、変にアルファベットに拘るよりは「トラックバック」とカタカナで書いた方がしっくり来るでしょう。

公開テンプレートの id を変更します

前段のやりとりを受けて hxxk.jp template set -standard- の表記を見直したところ、コメント部分やトラックバック部分の見出しはカタカナで書いていたので問題無し。 しかし、その部分の id を #comments-<$MTEntryID pad="1"$> や #trackbacks-<$MTEntryID pad="1"$> としていたので、「コメント部分」「トラックバック部分」という捉え方をすることにして、両方とも s を省こうと思います。

おそらく今日中にはその id 部分やその他の見直しを行った ver.1.04 を公開できると思います。 少々遅くなりましたが公開しました。 hxxk.jp template set -standard- ダウンロードから取得してください。

7 months

最初にジュンさんから話を聞かされたときは全く信じていなかったけども というかむしろ Web Cafe' Weblog - 目玉が飛び出るお知らせや /*inu-memo*/ - 引越しましたの続報。

• Web Cafe' Weblog - 家族の始まり
• /*inu-memo*/ - 各位

お祝いの場に参加させていただいていた身としては、「とうとうこの日が……」という感想です。 なんだか 5 並びの日という点にくすりとしつつ、「おめでとうございます ! 」とこの場を借りて申し上げる所存です。

トラックバック送信先

• Web Cafe' Weblog - 家族の始まり
• /*inu-memo*/ - 各位

7 回目の春

7 年という月日は人によって長く感じたりあっという間に感じたりするものだと思います。 同じ 1 年という歳月でも、 10 歳の小学生からすればこれまでの人生の 10% にあたる長さであるのに対し、 50 歳の方からすればこれまでの人生の 2% にあたる長さということになります。 もちろん、そんな単純な物差しで計るというのはいささか乱暴な気もしますが。

私にとっての 7 年は実に人生の 4 分の 1 以上を占める期間ですので、非常に長い年月だと感じています。 長いはずのその 7 年間ですが、ある事について考えると、 「え、もう 7 年も経ってしまったんだ……」 という驚きを隠せずにはいられません。

Without You vol.0 - eve

できればこの春が終わる前にやり遂げたかったのですが、何分その情報を得たのがつい最近だったため、予定としては夏になりそうですが、関東の方へ足を伸ばそうと思います。 金銭的な事情もあって、 ANA の超割を使おうと思っていますので、必然的に 7 月の 1 日から 11 日頃になります。

今のところ確定ではありませんが、 7 月 8 日に休暇を取って、夕方くらいに到着するようなつもりで考えています。 IRC チャンネル #Team-One の人と IRC で会話をすることはあっても実際に会ったことがないので、もしご都合が合えば会える方には会いたいなと思っています。 金曜日の夜って難しいかもしれませんが……。

次の項を見ると分かりますが、最初は 7 月 9 日の朝に到着するような計画を立てていました。 しかし、せっかく上京するならもう 1 日くらい多めに……と思って増やしてみた次第です。 ( #Team-One の方の参加が難しいなら当初の予定に戻すかもしれませんが。 )

Without You vol.1 - Hurry merry-go-round

これが今回のツアー ( 大げさ ) の主目的で、現地で同行していただく方の都合も考え、 7 月 9 日 ( 土曜日 ) を計画しています。 今のところ narukami さん ( 飼い犬が手を噛むので ) にお誘いをかけていますが、他にも同行者が数名増える分には楽しいんじゃないかなと思います。

と言っても大勢で集まって赴く場所でもないため、大々的な募集はしないことにします。 言葉をぼかしたままでの募集って何だと思われる方もおられるかもしれませんが、これまでの文脈でピンと来られたうんけめんがもしいらっしゃったら、チャンネル内で参加表明してくださるとありがたいです。

Without You vol.2 - D.O.D. ( DRINK OR DIE )

そしてせっかく関東の方へ足を伸ばすのだから、夕方には東京の方で夕食会 ( 飲み会 ? ) をしたいと思っています。 メンバー的には #順列都市の方々をメインターゲットに考えています。 お時間の都合が合う方は是非。 興味のある方はメールなり IRC なりでこっそりアプローチをかけていただけると幸いです。 ( 基本方針として、事前には WWW 上のオープンな場所では参加者を公表しません。 よってこの記事へのコメントやトラックバックで参加表明をされても受け付けません。 )

ふだん私のサイトを見ているのでいっちょ面を拝んでみたいとか、おのぼりさんがキョドる様を見てみたいとか、以前会ったことあるのでもう一回会いたいとか、そういった方の参加をお待ちしています。 場所などはまだ未定。

Without You vol.3 - LEMONed I Scream

これは私のわがままなのですが、次に上京するなら是非行ってみたい場所があるのです ! 日程的には 2 日目 ( あるいは 3 日目 ) の 7 月 10 日 ( 日曜日 ) になると思いますが、タカノフルーツバー本店5F のフルーツバイキングに行きたいのです。 以前もフルーツバイキングとは羨ましいと露骨に羨ましがっていたアレです。

実は甘いものに目がないのです。。 しかしそこは女性向けのバイキングであるので、男性が入店するには女性同伴である必要があるのです。 変に取り繕って言うつもりも無いのではっきりと言いますが、フルーツバイキングに行きたいので同伴していただける女性を募集します。

2 日目ということで、時間帯はまだ全然考えていません。

Q & A

これは hxxk.jp 主催のオフ会ですか ?

たぶん違います。 単にある目的で関東に行くので、ついでに飲み会しませんか ? あとどなたかフルーツバーに付き合ってくれませんか ? というノリです。

何故参加メンバーをオープンな場所で公表しないのですか ?

広く参加者を集めるつもりが無いからです。 ふだんから IRC などでやり取りをさせていただいている方を中心にお会いしたいと思っています。 もちろん、 IRC でのやり取りが必須条件ではありませんが。 いずれは大々的なものもやってみたいとは思いますが、今回は内輪寄りで。

興味を持たれた方は IRC チャンネル #汚れの巣や #順列都市や #Team-One や #hxxk に今すぐ Join now ! ( 要するにこの辺のチャンネルでそれとなくお知らせしますということです。 ただし、 #hxxk 以外は私の管理するチャンネルではないため、質問等がある場合は #hxxk でしていただくと良いかと思います。 )

どれくらい滞在する予定ですか ?

最短では 1 泊 2 日です。 長くても 2 泊 3 日くらいでしょう。 ( 3 泊は予算的に辛いと思うので。 )

2 泊 3 日コースだと、金曜日の夕方に上京して飲み会 A をやって、土曜日の日中に Without You vol.1 - Hurry merry-go-round のイベントをこなして夕方に飲み会 B をやって、日曜日にフルーツバイキングに行って帰る、という感じになるでしょうか。 もちろんこの辺りの計画はまだ未定ですが。 超割の予約の関連もあるので、私の滞在期間だけは早目に決めておこうと思います。

参加者が全く集まらなかった場合は ?

その時はその時で考えます。 関東に就職した友人も何人かいますので。