Web屋のネタ帳

以前紹介したWebアクセシビリティのJIS規格 ＝ JIS X 8341-3 高齢者・障害者等配慮設計指針−情報通信における機器， ソフトウェア及びサービス−第3部：ウェブコンテンツ ＝ について、筆者もようやくひととおり目を通せた。 そこで、その内容の全部は無理だがいくつかについて紹介しよう。

まず、このテの文書を読む場合にはshouldと mustの違いを意識したほうがいい。つまり、

• 「すべきである」「望ましい」＝should＝推奨
• 「でなければならない」「しなければならない」＝must＝必須

といったような言葉じりに注意。

まず、根本的な入力インターフェースの問題。

「特定の身体部位だけを想定した入力方法に限定しないで、多様な身体部位で、 ウェブコンテンツを操作又は利用できる」 （4.2 基本的要件 より）
... 特定の単一デバイスによる操作に依存せず、 少なくともキーボードによってすべての操作が可能でなければならない。
(5.3 操作及び入力 より)

つまり、マウスだけでしか操作できないようなサイトはダメということだ。 ご存じない方は試していただきたいが、 どんなブラウザでもたいていはマウス無しでも操作できるようになっている。 スペースキーでスクロールできるし、 キーボードのタブキーの連打でリンク部分を移動できる。シフトを押しながら タブキーを押せば逆移動もできる。見たいリンク部分でエンターキーを押すと そのリンクにジャンプできる。

ところが、せっかくブラウザがキーボードだけで操作できるようになっているのに、 WEBサイト側がそれを阻害しているケースが多々ある。 たとえばFlashなどによるコンテンツはこのキーボード操作ができない可能性が高い。 また、BIGLOBEのトップページのように、 メニュー部分をJavaScriptで書いている場合も、タブキーでの リンク部分移動ができない（各メニューの詳細を展開できない）。

フレームを使う場合はよくよく注意しましょう、的なことも書かれている。

フレームは、必要以上に用いないことが望ましい。 使用するときは、 各フレームの役割が明確になるように配慮しなければならない

• 音声ブラウザなどの利用者は、視覚的に全体を把握することができないため、 各フレームの役割を理解したりフレームの内容の変化を認識したりすることが 難しい場合がある。
• キーボードだけで操作するとき、フレームの切り替えが煩雑になる場合もある。
• フレームを使用したページは、各フレームの役割及び各フレーム内の データの変化がわかりにくいために、情報アクセシビリティを損ねる可能性がある。

(5.2 構造及び表示スタイル)

入力フォームの作り方にも興味深い指摘があった。

入力欄を使用する時は、何を入力すればよいかを理解しやすく示し、 操作しやすいように配慮しなければならない。
...（中略）...
電話番号、郵便番号など入力方法が複数考えられる場合、入力例を明示する。
良い例↓

電話番号(ハイフンを入力) 例：000-0000

悪い例↓

電話番号	(ハイフンを入力) 例：000-0000

(5.3 操作及び入力 より)

ハイフンの有無や入力例が無いのはもちろんまずいのだが、 それを入力フィールドの前に置くか後ろに置くかでも違う。 後ろに置くと、視覚障害者は入力が終わってから その入力例や制限に気づいてしまうのだそうだ。

また、文字サイズの可変性については必須として規格されている。

文字のサイズ及びフォントは、 必要に応じ利用者が変更できるようにしなくてはならない。
(5.6 文字)

これは当然だろう。
See: フォントサイズを固定するな！− 後悔しないためのWebデザイン

他にも紹介したいのだがとても全部は書ききれない。 総じて、さまざまな例示やHTML/CSSの実際の書き方も盛り込まれており、 意外と充実した内容なので驚いた。

これまでは「アクセシビリティ」という単語だけが一人歩きしていて そのココロは誰もわからないような感があった。 このJIS規格の出現で「アクセシビリティとは何ぞや」という問いに ようやく統一的なものが出たといえるだろう。 とはいってもあけてみれば単に 「見やすくて使い勝手の良いWebサイトのつくりかた」であって、 あたりまえと言えばあたりまえのことばかりだ。 しかし本当に実践できているサイトは多くは無いだろう。

文部省の委員会が次のような提言をまとめたんだそうな。

.....「子供たちに、理科や数学を学ぶ楽しさを教えることが重要」と指摘。 理数教科の教員は理工系の大学院で学び、高い専門性と最新の知識に 裏打ちされた、魅力ある授業を展開すべきだとした。
　文科省はこれを受け、〈１〉理数教科の教員を新規採用する際は、 修士課程修了を条件とする....
(Yomiuri Online 2004/7)

「いま現在、理科や数学を学ぶ楽しさを教えることができている教師には修士が多い」という相関関係が見出せたような調査でもやったのだろうか？ たぶんそんな調査すらせずにおエラ方の石頭のなかだけで考えた結論なのだろう、という予想に1000カノッサ。

この記事を見て、 「若者の理数系離れは確かに問題だけど、その解決策がそれって、なんか間違ってるんじゃ？」と思うのは筆者だけではないだろう。 10数年まえに打ち出された「ゆとり教育」に次ぐ無意味政策による失敗の予感。

関連記事：
スラッシュドット ジャパン | 理数系教員は修士以上に、との提言
教室内デジタルデバイド、東大とiMac、つまり？ - Webビジネスコンサルタントのネタ帳

FPNというサイトにちょっと気になった記事があったのでメモ。

今のままでは、ポータルは陰りを見せるだろう

楽天とYahoo!全盛も長くは続かず、 ユーザーのネットリテラシーが向上するにつれポータルから離れてゆくだろう、 といったあたり、かなり同意。

実際の話、慣れてないユーザーほどすぐYahooのトップに戻ろうとするが、 慣れてくるにつれ、それぞれお気に入りのサイトやWebアプリを使うようになり、 Yahooは右側のニューストピックを見るだけになる、なんてことは よくあることなんじゃないだろうか。

(前回からの続き) さて、直リンク禁止の実現方法にはどんなものがあるのだろう。 会員管理機能を持つサイトでの実現方法は前回のケース３で既に話したとおりだが、 他のケースで考えられるいくつかの方法とそのメリットやデメリットを紹介しよう。

HTTPリクエストヘッダのRefererでチェックする方法

巷で使われているほとんどのブラウザには、 Webサーバにアクセスするときにそのリンク元URLもWebサーバに提示する機能がある。 それがHTTPリクエストヘッダのRefererである。

一般にはこれをアクセスログに残して分析し「昨日のリンク元の一覧」のような形で Webマスターが日々の参考にしていることが多いが、 やり方によってはこれを直リンクの抑止に応用できる。

自分のサイトが、http://www.example.com/ だとしよう。 ユーザーのブラウザがアクセスしてきた際そのRefererに 「http://www.example.com/******」といった文字列が含まれていない場合に 「それは他のサイトからの直リンクによって飛んできた」とみなし、 アクセスを拒否するという手法だ。

これはたとえばApacheであればmod_rewriteなどのモジュールの導入と httpd.confなどの設定ファイルの調整だけで実現できるので、 よく採られている手法である。 レンタルサーバであってもmod_rewriteモジュールはたいてい導入済みのことが多い（たぶん）。
See: mod_rewriteで直リンクを禁止する (ITmedia.co.jp Linux Tips より)

ただしこの手法にはデメリットがある

• 自サイト上のリンクではなくメールマガジン上などに書かれたURLを クリックしてアクセスしようとした際も拒否してしまいかねない。 メール上のURLをクリックした場合は当然ながらまともなRefererは送信されないからだ。 あるいはもしユーザーがYahoo!メールのようないわゆるWebメールサービスを使っていた場合、 RefererはそのWebメールのサイトになってしまう。以上を踏まえて設定をかなり工夫するか、 メールという媒体からのURL認知を許さないという無茶なポリシーにするか、 あるいはメールマガジン用には他のURLを用意してそこからリダイレクトさせるなどの措置が必要となる。
• パーソナルファイアウォールとよばれる製品がそのパソコンにインストールされている場合、 ブラウザがWebサーバにアクセスする際にRefererを自動的に削除してしまうことがある。 これは、Refererという情報（＝ユーザーがどんなサイトを見ていたか）も、 保護されるべきプライバシーのひとつである、という設計思想によるものだ。 有名なのはノートンインターネットセキュリティという製品だ。 ウィルス対策ソフトと合わせてPCにプリインストールされている場合が多い。

  Norton Internet Security 2004 または Norton Personal Firewall 2004 の初期設定では、どの Web サイトから移動してきたかという参照元 (リファラ) 情報を遮断するように設定されています。 しかし 特定のWeb サイトでは、正しくサイトを表示するために参照元情報が必要な場合があります。
  (参照元 (リファラ) が遮断され、 Web サイトが正しく表示されない (Norton Internet Security 2004/Norton Personal Firewall 2004) より)

  しかし初心者がこの説明を見て自分のPCを適切に設定できるとは思えない。 そんな面倒なことをするくらいなら、そのサイト自体を二度と見に来ないだけだ。

Webサーバに特殊なソフトを入れる方法

こんな便利そうなApacheモジュールを作っている人もいる。

mod_deny_deeplink.c
ディープリンクを防止したいディレクトリには、 所定のHTTP Cookieをもったクライアントのみを アクセスさせる実装をしています。 通常そのHTTP Cookieは上位のインデックスがあるディレクトリに アクセスしたとき発行されます。

しかし、これを自身のサーバで使っているApacheに組み込むには ある程度の慣れた技術力が必要だし、 よくある共有ホスティング型レンタルサーバを使っている場合には そのApacheにモジュール追加するようなこと自体がおそらく許可されないだろう。

また、この方法をとった場合もやはり、 メール上に書かれたURLをクリックした場合には Cookieを発行するタイミングが無いままアクセスされてしまうため、 Refererを使った場合と同じ問題とその対処が必要となる。

このように、直リンク禁止の方法はいくつかあるが、 いずれもデメリットも大きく不完全さが否めない。 コレといった包括的な解決策は無いのだ。

ただし前回のケース３のような場合であれば話は若干変わる。 つまり、ポリシー的にもシステム的にもある程度完成された 会員管理／認証機能を備えた会員制Webサイトであれば、 「会員にしか見せない」という意味での直リンク禁止は可能だし必要だろう。

これはあくまで筆者の個人的意見だが、一般的なWebサイトにおいては、 直リンク禁止などというWebの前提に矛盾することを考えて 不完全な方法を模索しつづけるくらいなら、 もっと他にやることがあるんじゃないだろうか。 全てのサイトにおいてとは言わないが、 少なくとも世の中の9割がたのサイトについて言えると思う。

話をはじめる前にまず、 直リンク禁止ということをWebの世界で叫ぶこと自体にもともと無理がある ということをご理解いただきたい。 以前も書いたように、 特定のURLを指定することで特定のコンテンツを見れるという特性こそが Webというものの最大の利便性のひとつであり暗黙の大前提である。 Webを使っていながら直リンク禁止というのはこの利便性と前提に 真っ向矛盾してしまうのだ。

なお、無断リンクでも法律的に問題ないというのが 社団法人著作権情報センターの公式見解 である。ただしこの見解はいわゆる直リンク （＝ディープリンク）に言及しているわけではなく 単に一般的な「リンク」の話をしているだけなことに注意。

また、以前紹介したWebアクセシビリティに関するJIS規格の文書上にも、 次のような記述がある。

2.5 「直リンク禁止」の防止
サイトの管理者がトップページへのリンクしか認めず、 サイト内の各ページへ直接リンクするマーク付けを禁止している場合がある。 これはいわゆる”直リンク禁止”問題である。少なくとも、 公益的なサイトでは”直リンク禁止”をすべきでなく、 この規格で明示すべきであるという意見があった。 当該サイトにどのような形態でリンクするか、あるいは許可するかという問題は、 サイトごとのポリシーの問題であり、この規格では触れないことになった。
(JIS X 8341-3 高齢者・障害者等配慮設計指針−情報通信における機器， ソフトウェア及びサービス−第3部：ウェブコンテンツ 解説文より)

正式な規格になる前の検討段階で議論にはあがったようだ。

さて、そういったことはわかっちゃいるけどそれでも直リンクはやめてほしい、 という大人の事情もあるにはある。

ケース１：マスコミ（特に新聞社）のサイトが直リンクを嫌がる例

読売新聞社では、リンクはヨミウリ・オンラインのトップページ http://www.yomiuri.co.jp/ および個別サイト（DAILY YOMIURI ON-LINE、 大手小町 WOMAN、＠マネー、医療と介護など）のトップページにお願いしております。 ただし、リンクされることによって編集意図が損ねられる恐れがあるサイト等の場合は ご遠慮いただきますので、あらかじめご了承下さい。 また、個別記事へのリンクは原則としてお断りしております。
(www.yomiuri.co.jp より)

読売に限らず多くの新聞社、通信社のサイトでこのような記述をよく見かける。 なぜ個別記事へ直リンクされては困るのかというと、 単純な話「広告」の問題が大きいようだ。

新聞社のサイトにはトップページはもちろん個別の記事にもほとんど広告が入っている。 当然ながらトップページの広告料は個別記事上の広告料より高めの料金が設定されているだろう。 それなのに、他のサイトから個別の記事にに直リンクされてそこだけアクセスされ、 すぐにユーザーに去られてしまっては、 トップページに広告を出してもらっているスポンサー様に言い訳が立たなくなる。

マスコミにとって広告が最重要な収入源であるからこそ、 そこへのトラフィックはできる限り自身のコントロール配下に置かなければならない。 他のサイトからの直リンクは、そのコントロールを乱すノイズになってしまうのだ。 もちろん、そうした紙媒体的なコントロール手法をWeb上に持ち込もうとすること自体にも 無理があるのだが。

ケース２：動画やFLASHなど特殊コンテンツが人気のサイトの例

コンテンツの種類のよってはこういうお気の毒なことも起きるようだ。

...元はサーバAにHTMLもムービーも置いていたのですが、 あまりにも中国や台湾、香港からの直リンクが多くて サーバがダウンしてしまうこともあったので、 ムービーだけをサーバBに移し、なおかつhtaccessで サーバAのドメインがリファラーにないアクセスを拒否 するようにしました...
(Apacheのメーリングリストへのある投稿 より)

たとえばの話、「ポケモン」といったいまや世界的に有名なキャラクターの 動画やFLASHなどの場合、日本語のWebページでその動画やFLASHを紹介しても 非日本語圏ユーザーにとっては日本語のWebページ自体は無意味だから、 動画そのものに直リンクされてしまう、といったケース。 これは十分にありうる話だろう。

ケース３：会員制サイト構築の際の設計ミス

たとえば、特定の商品やサービスを買ってくれた人にだけIDとパスワードを発行し、 それをつかってWebサイトにログインすると、その商品に関する詳細な資料を 見ることができる、といったユーザーサポート目的のサイトは最近よくある。

当然、コンテンツを閲覧できる人を限定しなければならないので、 Webサイトに会員管理／認証機能を持たせることになる。 とりあえずそれで、 http://www.example.com/content.jsp といったURLを見ようとすると、ログインしてない人にはログイン画面が、 ログイン済みの人にはコンテンツがそのまま表示される、といったことを実現できる。

ところが、そのコンテンツの中で「詳細にまとめたPowerPoint資料はこちら」 といった形でPowerPointやPDFファイルを見せたい場合もあるだろう。 それのURLが http://www.example.com/hogehoge.ppt だったり http://www.example.com/hogehoge.pdf だったりしたら、さあ大変！ この直リンクURLが外部に漏れたら、そのサイトの会員じゃない人間でも ログインせずに資料ファイルをダウンロードできてしまうような事態になる。 何のための会員管理だ！とクレーム騒ぎになりかねない。 （それほど厳密な閲覧制限を必要としないのであればこれでも良いのかもしれないが）

知ってか知らずかこの失敗をやらかしてしまうSEやプログラマーは非常に多い。 ひどいときは 「Webってそういうもんですよ無理ですよ だって資料ファイルもDocumentRootディレクトリに置かないと 外からアクセスできないわけだし・・・」 といった逃げ口上を言い出すだろうが、99%設計ミスと技術不足である。 HTTPに関する正しい理解がある技術者であればきちんと実現できるはずだ。

もしも会員管理機能と認証機能をWebシステム上に既に持っているのであれば話は簡単。 （以下Java風に書くが、話をわかりやすくするため厳密ではない）

if (会員認証済みである==true) 
{
    // HTTPレスポンスヘッダを調整して出力
    response.setHeader(
        "Content-Disposition",
        "attachment; filename=hogehoge.ppt"
    ) 
    // DocumentRootじゃないディレクトリに置いた
    // hogehoge.pptを読み込んでHTTP出力する命令を
    // このへんに書く
} 
else 
{
    out.println("
      あなたは会員認証(つまりユーザー登録＆ログイン)
      してないからこのパワーポイント資料は
      お見せできません。
    ")
}

上記のようなスクリプトを書き、これを
http://www.example.com/getfile.jsp?filename=hogehoge.ppt
のような形でアクセスさせるようにすれば、PowerPointファイルについても 会員管理機能に基づいた閲覧制限が可能だ。 （上記のスクリプト例はどのファイルへアクセスできるようにするかといった セキュリティ的考慮はとりあえず棚上げしているので注意）

さて、直リンク禁止の実現方法にはどんなものがあるのだろう。 会員管理機能を持つサイトでの実現方法は上のケース３で既に話したとおりだが、 他のケースで考えられるいくつかの方法とそのメリットやデメリットを紹介しよう。

・・・のつもりだったのだが長くなったので次回につづく。

推測ではあるが、おそらく企業側は顧客関係性を構築していくという考え方を それほど重要視していないのではないか。 とは言えいずれは顧客管理するかも知れないから、 とりあえずカスタマー登録カードで登録してもらう。 そんな「念のため」ぐらいのポジションになっていて、 言ってしまえば「顧客管理するかも症候群」なのかも知れない。
意外と多い「顧客管理するかも症候群」 (japan.internet.com 2004/7)より

こうした「とりあえず」的なスタンスで行われている ユーザー登録ハガキというものが、その後どのような運命をたどるかというと、

以上のように、今まで長年蓄えた『お客様カード』は きっと薄暗い倉庫にダンボールに積まれているかもしれないが、 何の役にも立たないので廃棄する方が賢明である。
【波多野blog】 N0.5 「忘れよう！それは妄想にすぎない！」より

ということのようだ。何の役にも立たないどころか、 もしもそれらのハガキのデータを電子化しデータベースに入れたら、その時点で個人情報の漏洩というリスクを背負い込むことになる。

こういう、にわかには信じがたい単純ミスだって実際に起きる。

アニエスベー、カード会員の氏名やメールアドレスなど1万人分流出
アニエスベーサンライズは、アニエスベーカード会員のユーザーに送信したメールに、会員の氏名やメールアドレスなど1万人分の個人情報を添付して配信していたことを発表した。原因は明らかにされていない。
　個人情報を記載して配信してしまったのは、7月6日付けにカード会員向けに送信した「アニエスベーモリネリTシャツ入荷のお知らせ」という件名のメール。アニエスベーでは、「本来商品情報を送信するべきところ、配信時の操作ミスで氏名、メールアドレス、カード会員番号など1万人分の個人情報を送信してしまった」という。なお、「信用情報は含まれていなかった」としている。

さらに、実はデータ内容的に古くて役に立たないものだったとしても、 「○○万件漏洩」と報じられ株価は下がり記者会見開いて頭を下げる情けないザマをみせることになるのだ。

See Also: それでもまだ聞くのか個人情報を

日経ＢＰの記事より↓

「PSXが当たりました！今すぐ下記のサイトにアクセスして、あなたの住所を入力してください」「システム利用料が未納です。下記のサイトでユーザーIDとパスワードを入力して利用明細をご確認ください」――。 　このようなメールで偽のWebサイトに誘導し、ユーザーに個人情報を入力させるオンライン詐欺が国内で話題になり始めている。「フィッシング（phishing）」と呼ばれるオンライン詐欺である。
デジタルARENA / オンライン詐欺の新手口“フィッシング”に注意より

こんな記事もある。

フィッシングに名前を使われないようにするには，フィッシング・サイトを作りにくくしておくことが重要である。具体的には，「ポップアップ・ウインドウを使わない」「アドレス・バーを隠さない」「フレームを使わない」――こと。

フィッシングに名前を使われると，サイト運営者も巻き込まれることになる。「フィッシングに利用されないように対策を施していたかどうか」を説明する責任を負う。フィッシングに名前を使われることが多い米国のある有名企業は，フィッシングに利用されにくいサイトに変更する作業に追われていると聞く。

「“フィッシング”に利用されないようなサイト作りを」――テッ クスタイル岡田氏 : IT Pro ニュース

日本語のスパムは今後間違いなく増加してゆくだろうし、オンライン詐欺メールも同時に巧妙化と増加の一途をたどるだろう。架空請求詐欺は序章に過ぎないのかもしれない。

アドレスバーの非表示やむやみなポップアップは使い勝手や見た目の観点からもセキュリティ的観点からもおすすめできない。 最近ただでさえ自分自身書いたの過去の記事の引用が多いので 焼き直しと思われるのがいやなのだが、それでもあえてここで引用しておきたい。 読者のみなさんが開発/制作/運営に関わっているサイトは、以下の点に該当しないだろうか。 さもなければ「痛い目にあわなきゃわからない」ということに・・・。

• ツールバーもアドレスバーも消すな！
• むやみなポップアップやめようよ

URL（Uniform Resource Locator）−情報の場所を示す一定の記述方法−とは、便利なものだ。 たとえば、http://support.microsoft.com/default.aspx?id=870669 というURLによってマイクロソフトのサポート情報サイトの「Internet Explorer で ADODB.Stream オブジェクトを無効にする方法」というコンテンツにたどり着くことができる。 逆に、このコンテンツを他人に示したければコンテンツの内容そのものの代わりにこのURLを伝えればいい。

つまり、特定のコンテンツ≒特定のURLという前提こそがWebの世界に利便性をもたらしている根幹であり、Webそのもののはずだ。

しかし、このあったりまえのはずの前提が崩れてしまうケースは驚くほどよくある。 そしてその落とし穴がどんな結果をもたらすのか？という話をしよう。

ケース１：GETではなくPOSTでしかアクセスできないような動的ページを作ってしまったサイト

http://www.jisc.go.jp/app/pager?%23jps.JPSH0020D:JPSO0010:/JPS/JPSO0020.jsp=
このURLはJIS（日本工業規格）を検索するページだ。 「名称検索」のところにたとえば「ウェブコンテンツ」と入れて検索してみると、今話題の規格の説明ページにたどり着くことができる。 そのとき、URLに注目してほしい。
http://www.jisc.go.jp/app/pager?id=69569
のようになっているはずだ。（数字部分は若干ちがうかもしれない）

もうお分かりの方もいるだろう。もう一枚ブラウザを開いて、
http://www.jisc.go.jp/app/pager?id=69569
と入力しても、「Not Found」になってしまう。 JISX8341-3 高齢者・障害者等配慮設計指針．．．のページにたどり着くことはできない。

つまり、こういうことだ。

• jisc.go.jpのサイトでJISやその他の規格を見るには、 何らかの情報をGETではなくPOSTメソッドで送信することが必須になっている。 つまり基本的に検索のページでキーワードを入れるという動作でしかアクセスできない。
• www.jisc.go.jpを構築したWebデザイナーやあるいはCGIプログラマーは、 「検索ページがあって、そのキーワードでインデックスＤＢを検索して、結果を一覧表示して」・・・ という画一的な画面遷移だけしか考えなかった。 URLを指定して直接たどり着くというWEBなら当然あるべき概念を完全に無視していた。

実は http://www.jisc.go.jp/newstopics/tpk/accessibility.htm
というページの最後のほうに、直接飛べるリンクが張られている。これは、 GETではなくPOSTでアクセスしなければならないがために単純なアンカーリンクが使えず、 仕方が無いのでPOSTメソッドを発行するJavaScriptをわざわざ埋め込むという手間ヒマをかけ、 ようやく普通のアンカーリンクっぽく見せている。

ケース２：フレーム構成を使っているWebサイト

過去のネタを使いまわすようでナンなのだが（苦笑）。 よほど特殊なコンテンツマネジメントシステムを使っている場合をのぞき、 フレーム構成を使うと、特定のコンテンツ≒特定のURLという前提が崩れてしまう。 詳細は過去の記事「フレームを使うと「ここを見てください」とURLを伝えることが事実上できなくなる − 後悔しないためのWebデザイン」をご覧いただきたい。

ケース３：すべてFlashで構成しているサイト

これまた過去のネタを使いまわすようでナンなのだが、 URLとコンテンツを相互に一意に結びつけるという概念がFLASHにはない。 いや、あるのかもしれないが、それを考慮しているFLASHにお目にかかったことが、筆者は無い。 この落とし穴に見事にはまっているサイトが、 横浜の元町に本店がある人気のジュエリーショップ「スタージュエリー」のサイトである。 過去の記事「スタージュエリー：使い勝手の悪いサイトの例」 をご覧いただきたい。

ケース４：アドレスバーを表示しないようにJavascriptなどを駆使しているサイト

銀行のインターネットバンキングシステムに多い。 アドレスバーが無ければURLがわからない。URLがわからなければ他者に伝えようが無い。 銀行のATMの設計と同じ感覚でWebサイトをデザインしようとするとこういう落とし穴を自らの手で掘ってしまう。 過去の記事：ツールバーもアドレスバーも消すな！ − 後悔しないためのWebデザイン もご覧いただきたい。

落とし穴で待っているもの

特定のコンテンツ≒特定のURLという当たり前のはずの前提が崩れるとどうなるのだろう？

1. メールという重要なマーケティングとサポートのためのツールが事実上使えなくなる
   例えば商品の詳細情報のコンテンツがあるWebページのURLが一意に定まらないのなら、 「今週のオススメ！」といったメールマガジン上にURLを書きようが無い。 また、ＥＣサイトではなくユーザーサポートを目的としたサイトであるならば、 ユーザーからの問い合わせに対し、「詳しくはこちらをご覧ください」といった形で詳細情報のURLを伝えるということができない。
2. 他のサイトからのリンクを期待できなくなる
   リンクは、基本的に<a>というアンカーリンクタグを使う。 Flashコンテンツの内部のひとつのアクションに飛ばすようなリンクは（たぶん）書けない。 また、POSTしてくれるようなJavascriptをわざわざ書いてリンクを 張ってくれる人もめったにいない。 ということは、プレスリリースを出してもプレスのサイトはリンクを張ってくれないし、 誰かがblogで取り上げてリンクを張ってくれることも望めない。 他のサイトからのリンクだけでなく、自分のサイトのほかのページからのリンクを 張るのにもひと苦労ということになる。 これはケース１の最後に述べたとおり。
3. 検索エンジンにもひっかからない
   フレーム構成されたサイトならそれほど影響はないが、 www.jisc.go.jpのようなサイトのページはGoogleにもYahooにもひっかからない。 （現在の）検索エンジンはWebページのクローリングにPOSTは使わない。GETだけだ。 POSTメソッドは通常は「IDとパスワードを入力してログインする」といった用途に使われるべきものだ、という前提で検索エンジンは設計されている。 検索エンジンは、基本的に<a>タグによるアンカーリンクで表現されたURL（≒GETでアクセスできるURL）にしかアクセスしないのだ。 むやみにコンテンツの多くをFLASHに詰め込んでしまったサイトもしかりである。

どうしたらよいのか？

もうそうなってしまったサイトに対する特効薬は無い。全部作り直すしかない。 幸いなことにこれからサイトをつくるという場合には、簡単ないい方法がある。

どんなWeb屋に構築を頼むのであれ、たいていはサイトマップというものをまず考えてくれる。 （フロー図と呼ばれる場合もある）たとえばこんなやつだ。
玉すだれ型サイトマップ：

ちなみに、もしもサイトマップを出してくれないようなWeb屋にあたってしまったら 即座にお引取りいただいたほうがいいだろう。

このサイトマップにひと工夫加えてもらうのだ。たとえばこう。

赤のマークは「コンテンツ毎に一意なURLでアクセスできる」という意味だとする。 これを要求仕様とすればいい。

注意しておくが、「コンテンツ毎に一意なURLになるように・・・」 という要求をナントカの一つ覚えのように全てのページに課してはいけない。 たとえば、ショッピングカード機能の決済方法の選択画面は、 正確な意味ではコンテンツではないし、URL直打ち入力で飛んでこれるべき画面ではないから必要ない。 赤マークをつけるページはきちんと取捨選択しなければならない。

追記：
古い記事だが、より専門的な書き方で同様の趣旨を書いてる記事があったので紹介。
Webの「正しい」アーキテクチャ(@IT 2002/11)

ちょっと前に、 Mozillaってなんなんだ？という記事で

今もNetscapeのサイトにはこうした画像が残されている。 筆者の記憶が確かならば、昔はNetscapeをインストールすると、 インストール先ディレクトリのどこかにこの画像のアニメーションGIFがあった。 隠れキャラみたいなものだったのだろうか。（とっとけばよかったなあ・・・）

と書いたが、今朝何気なく自分のPCの中を見ていたら、ちゃんととってあった。びっくり。

これです。

ここしばらくの間に平田さんと恭子さんから それぞれメールが届いたので紹介しよう。

Date:     Fri, 11 Jun 2004 18:56:10 +0900 (JST)
Subject:  どもー♪はじめまして☆
From:     *****12jp@yahoo.co.jp
Message-ID: 20040611174635

はじめまして☆平田と申します。えーとですね、
以前どこかで胸の大きい女性が好きって書き込んで
ましたよね？平田、胸関係で男性に避けられることが
多いので、その書き込みにとても興味を持ってて
アドレスを控えてたんです。
ちょっと前の書き込みだったと思うので、
「胸の大きい女性が好き」って気持ちは今では
もしかしたら変化してるでしょうか？変わってないのなら、
ぜひぜひ仲良くなりたいと思ってるんです☆
自己紹介を致しますね☆
平田○○、２２歳でフリーターをしております♪
住んでいるのは東京ですが、フリーターという立場上
けっこう色々なトコロに旅行に行っとります♪
趣味は旅行以外では読書で、好きな作家は筒井康隆
さんです。コンプレックスは胸で、えーと、
スリーサイズはまだ言わないほうがいいかな（笑）？
そんなワケでして、平田、お返事待っております！
趣味や、どこに住んでるのか教えて欲しいです☆
あ、あと何て呼んだらいいでしょうか？平田のことは、
平田と呼んでください☆

Date:     Sun,  4 Jul 2004 15:43:09 +0900 (JST)
Subject:  初めまして。浮気相手を探している主婦です。
From:     *****@yahoo.co.jp
Message-ID: 20040704154310

初めまして恭子33歳です。サイトの掲示板で見た
ので近かったのでメールしてみました。
逆愛人契約を希望しています、最初は少ないですが
(5)でいいですか？私は今小さいながらジュエリー
ショップの経営をしていますが夫の不満を言うつもりは
ないんですけど、もう少し女として扱ってくれても
いいかなって思います。貴方の時間と優しさをお金で
買います。SEXでもメル友でもなんでもいいんで、かまって
くださいませんか？容姿は悪くないと思います！
既婚未婚などは問いませんがこちらは真剣に探して
います、容姿よりも継続力、暖かい雰囲気が貴方の
文章から伝わりました。

見てのとおり、普通のSPAMによくあるようなURLが書かれていないのがミソ。 まあ思うことをつらつらと・・・

• 「えっ！？人間違いじゃありませんか？でもこれも何かのご縁・・・」とか 「ぜひ！」とか返信してしまうおめでたい奴っているのだろうか？ いるんだろうなぁ。架空請求が減らないのと同じ理由だ。
• うっかり会社のアドレスに届いちゃった日にゃ、 もし監視の目の厳しい会社だとあらぬ疑いをかけられちゃって、 しかも人事担当者(?)がSPAMとかそういうネット詐欺モノにうといと なおさら疑いを晴らすのに手間がかかりそうだ。まさに迷惑千万。
• こうした手のこんだスパムは以前からあったのだろうか？ 筆者のところに来たのはこの1ヶ月前くらいが最初だと思う。 他のSPAMにまざって条件反射で消したものも過去にあるかもしれないが覚えてない。
• 実際返信するとどうなるんだろう？ どっかの出会い系サイトにでも誘導されていつのまにか 会員登録させられるというオチなんだろうか。 それとも単に「カモにしやすそうな奴」というリストに加えて 名簿として転売するのが目的なのだろうか。実験した人いませんか？(笑)
• どうせアドレス収集ロボットが集めたものや、 最近ブレイク中の漏洩した個人情報ってやつに送信しているのだろう。 だとすると、女性や未成年者のメールアドレスにも届いてしまっている 可能性は十分にある。小学生のメールアドレスに届いてしまって 「お母さんこれなんだろう？」という場面を想像すると なんとも頭が痛そうだ。

なお、万が一、From:のアドレス等が第三者に詐称されている場合に あらぬ迷惑になりかねないので一部伏字にしておきました。 面倒なのでヘッダも無しで。

もちろん筆者には身に覚えの無いメールであることは 言うまでもない。ないってば。(笑)

ちょっと前の話だが、知人から相談を受けた。 ネットにあまり明るくない人なので全容を知るのにやや苦労したが、 要約すると次のとおりだ。

1. とあるWebサイトでは、新着情報(?)等を自動的にメールしてくれる。 知人はそれを愛用している。 それはメルマガとはやや違うサービスで、 例えばYahoo!オークションのアラート機能に近いものらしい。ここで仮にそのサイトを「Ａサイト」と呼ぶことにする。
2. 知人は転居にともなってプロバイダを乗り換え、転居先の地域のCATV（ケーブルテレビ）会社のインターネットサービスの利用を開始。メールアドレスもそのCATV会社のものに変わった。
3. 新しいメールアドレスで改めてＡサイト上で登録。しかし、いっこうにメールが届かない！ 友人や職場とのメールのやり取りは正常にできるのだが・・・。

そこで筆者が調べてみたところ、原因は次のとおりだった。

• そのCATV会社のユーザー用メールサーバは、
  • DNS逆引き設定がされていないホスト
  • または、DNS逆引き設定がされていても、正引き設定と食い違うホスト
  からのSMTP接続を拒否するようになっている。
• Ａサイトの自動送信メール用と思われるメールサーバは、DNSの逆引きを設定していない。
• したがって、他のメールのやりとりはできても、Ａサイトからのメールの受信ができない。

というわけ。

さてここで問題。上のケースでは、CATV会社とＡサイト、悪いのはどちらだろうか？
答え：逆引きができないor逆引きできてもその結果が正引きと食い違う場合にそこからのメールを受け付けないような設定を施しているCATV会社のほうが100%悪い。

詳細に入る前に、DNSの逆引きについて簡単に話しておこう。

DNSの正引き、逆引きとは？

• 例えば www.yahoo.co.jp というホストをDNSサーバに対し正引き問い合わせすると、210.81.3.241 というIPアドレスが返される。
• 反対に、 xxx.xxx.xxx.xxx といったIPアドレスから hogehoge.example.comといったホスト名を問い合わせて 引き出すことをDNSの逆引きという。
• DNSの正引きができるようにIPアドレスとホスト名の組み合わせを DNSサーバに正しく登録することは、当然のこととしてなされなければならない。
• しかし、逆引き設定をすることは必須では全くない。 よほど特殊なアプリケーションを利用するならともかく、Web、メール、ネットニュース、その他ネット上で一般的なアプリケーションの利用に際し、逆引き設定は必須ではない。
  参考：＠IT：DNS Tips：逆引きが使われるのはどんな時か

必須ではなくしかもメールの送受信とは特に関係がないはずのDNS逆引き設定を施さないとメールを送れないような仕組みにしてしまうプロバイダや企業がいるのはなぜ？

実はレアケースではない。上でとりあげたCATV会社に限らず、 中小規模のプロバイダや企業のメールサーバでこのような設定を施す例が少なくない。 その理由はずばりスパム（迷惑メール）対策だ。 ちょっと検索してみたら、

メール受信ポリシー(福井工業高等専門学校)
群馬大学宛のメールが届かない方へのご連絡(群馬大学)

なんてものもあった。これも氷山の一角だ。つまり、

1. 逆引き設定をしていないor正引きと逆引きの結果が食い違うホストからスパムメールが大量送信されることが比較的多い
2. だったら、メールサーバがメールを受け付ける直前に自動的に DNS問い合わせをしてまともな逆引き設定がなされているかどうか調べ、 もし逆引き設定されていないor設定されていても結果が正引きと食い違うようならメールの受け取りを拒否する、というふうにメールサーバを設定すれば、スパムを減らすことができるだろう。

という理屈である。しかし、これは単なる統計的推論でしかなく、 今となっては迷信にすら近い。スパムの送信手法は日進月歩で変わっているのだ。 こうした迷信を信じて、まともなメールまで受け取れなくしてしまうことは、 メールサーバの管理者として無知といわざるを得ない。 ましてや上であげたCATV会社のようなところであれば、通信や放送といった社会インフラにかかわる事業者としての責任に照らせば失格といわざるを得ない。 正しい知識を教育する立場として考えると上の大学や高校も同罪である。

上で紹介した福井高専のメール受信ポリシー(画像こちら)には明らかなウソすら書いてある。

あなたのコンピュータは、携帯電話にメールが送ることができますか？ これと同じような方針から、 福井高専では DNS でアドレスの逆引きできないサイトからの メール受信はできません。

最も簡単なチェック方法
　一番簡単なチェック方法は、あなたのコンピュータから i-mode にメールを 送って下さい。正しく送信できますか？ 本学と同じ理由から Docomo でも逆引きできないサイトからの メールを受け取らないはずです。

事実ではない。DNS逆引き登録の無いマシンからNTTドコモの携帯のメールアドレス(***@docomo.ne.jp)へのメールの送信は、今も昔も問題なく可能。なんでこんな話になってるのか知らないけれど、ドコモに抗議されても知らないよ。

逆引き設定したくてもできないケースすらあるのだ。しかも、よくある。

たとえば、レンタルサーバーサービスでは、ひとつのIPアドレスに複数の ドメイン名（≒ホスト名）を割り当てることは普通である。

hoge.watanabe.net → 123.123.123.123
fuga.tanaka.com   → 123.123.123.123
hena.suzuki.com   → 123.123.123.123

といった感じで正引きのDNS登録をすることは 特に共用ホスティングと呼ばれるレンタルサーバサービスにおいて常に行われていることだ。 ところが、正引きなら複数登録できるからいいのだが、DNSというものの仕様上、 一つのIPアドレスから逆引きされるホスト名として指定できるのは一つだけである。つまり、

123.123.123.123 → hoge.watanabe.net 
123.123.123.123 → fuga.tanaka.com
123.123.123.123 → hena.suzuki.com

こうした設定は不可能だ。上の例でいえば逆引き設定は三つのうちのどれかひとつしかできない。もしも

123.123.123.123 → hoge.watanabe.net

という逆引き設定をされたら、fuga.tanaka.comとhena.suzuki.comはもはや打つ手は無い。 futa.tanaka.comの正引きの結果は123.123.123.123なのに、123.123.123.123の逆引きの結果は hoge.watanabe.netとなる。つまり正引きと逆引きの結果が食い違う。これを回避する手段は無いのだ。こうしたホストからのメールを受け付けないという理屈はまったく筋が通らない。 （参考：＠IT：DNS Tips：1つのIPアドレスに複数のホスト名を付けている場合の逆引きとは）

see also:
MTA のアクセス制御 - 逆引き判定
hi-ho、DNS逆引きによるメール送信制限を撤回(2004.12)
mnx.ne.jpとzero.ad.jpがDNS逆引き設定の無いメールサーバからのメールをspam扱いしはじめた件 (2006.9)
reject_unknown_clientは迷惑メール対策としておすすめではない(2006.9)