Web屋のネタ帳

少し古い例ではあるが、典型的なある事件を例にあげよう。

「楽天」元派遣社員、不正アクセス容疑で逮捕 （Mainichi Interactive 2002/11）

楽天のユーザーサポートを担当していた者が、 その業務上知りえたIDとパスワードを使って嫌がらせ行為を行ったというものだ。 この件に関する楽天からの公式発表のページはすでに削除されているのだが、 そのコピーを残したページがあるので、そこから一部を抜粋する。

同人は派遣期間中、弊社にて、個人ユーザーからの各種問い合わせ対応の業務に従事しており、 個人ユーザーのユーザーID、パスワードを業務の一環として閲覧する権限を有しておりました。 なお、派遣終了後に個人ユーザーのユーザーID、パスワードを社外から入手することは出来ないことから、当該個人情報は派遣期間中に入手した可能性が極めて高いものと考えております。

つまり当時の楽天のユーザーサポート業務が担当者が生のパスワードを見ることを前提とした仕組みになっていたことは事件の内容とこの広報文を見て明らかだ。

弊社は従前より、ユーザーの個人情報のアクセスを業務上必要な社員にのみ認めてまいりましたが、今般の事件の発生を受けて、ユーザーの個人情報の管理に関し、社員に意識の向上と綱紀の保持を徹底するとともに、ユーザー情報へのアクセス権限の見直しなど運用面での管理強化を直ちに実施しております。 さらに、個人情報の管理ルールの定期的な見直し、実施状況の確認、システム面からの管理体制の強化、内部監査室の設置による監査体制の強化など、再発の防止に全社をあげて取り組んでまいる所存です。

と対策としていろいろ打ち出してはいる。 しかし肝心な、データベース上におけるパスワードの暗号化（ハッシュ化）保存処理はこの事件から1年以上たった現在もいまだになされていない。 それは実際に楽天のパスワードを確認するページで手続きしてみればわかることだ。 (2005/7追記：以前までは自分のパスワードがそのまま表示されるだけの仕組みだったのだが、現在では改めてパスワードを設定しなおす画面に誘導される)

断っておくが楽天に対する他意はまったくない。 例として非常にわかりやすいのでとりあげたにすぎない。 言いたいのは、似たような前提、似たようなシステム、似たようなサポート業務方法をとっているWebサイトは今では他にもゴマンとあるだろうということだ。 それを当然の前提と仕組みだと考えるのは完全な誤りであることは前回のパスワードの危機(その2)−あるべき姿で書いたとおりだ。 内部犯行ではどうしようもないとあきらめてもいけない。 パスワードの暗号化（ハッシュ化）保存はこうした内部犯行からパスワードだけでも確実に守る仕組みとして考えられているのだから。

多くのWebシステムにおいて個人情報はあるひとつのデータベース上に記録されている。 そこで、

データベース上の氏名、性別、住所、電話番号、をすべて一覧表示せよ

というコンピュータ上での命令を実行することは入社1年目程度の新人SEや 情報処理科目専攻の学生でも可能だ。 そして、あくまでもWebシステムの規模やサービスの規模にもよるが、 IDやパスワードを氏名や住所と同じデータベース領域に保存しているケースも十分ありうる。 ということは、

氏名、性別、住所、電話番号、ついでにユーザーIDとパスワードを すべて一覧表示せよ

という命令を書くことも可能なのだ。 あとはその命令を実際に実行できる環境（組織や権限）と人間（モラル）の問題だ。 例えばアルバイトのユーザーサポート係、社内のコンピュータ管理担当者、 システム構築とメンテナンスを委託されている業者・・・などなど。

「個人情報の漏洩事故に巻き込まれるのは一握りの不運な人だけだ」という数字的な見方もあるが、ファミリーマート、 ネット会員18万人分の個人情報が流出といった事件は実際起きている。 18万という数字は一握りとは言えない。 ファミリーマートの一件は情報が名簿業者に流れて架空請求詐欺の標的にされる程度で済んだようだが、 もしもファミリーマートのそのデータベースが会員ごとのIDやパスワードも保存する会員管理システムも兼ねていたとして、もしも氏名や住所だけでなくIDやパスワードも流出していたら？と考えるとゾッとする。

お金も個人情報も絡まないちょっとした娯楽サイトでのパスワードが バレてもたいした問題はないだろうという認識も、甘いと言わざるを得ない。 「わたしはそうしたWebサイトで使うパスワードと、 お金や重要な個人情報を扱うWebサイトでのパスワードは区別して使っている」と、 自信を持って言えるユーザーがはたしてどれだけいるだろうか？

怖いのは内部犯行だけではない。

アマゾン書評、自作自演が発覚 (cnn.co.jp 2004/2)
アマゾン・ドット・コムのカナダ版で近ごろ、 書評欄に書き込んだ人々の個人情報が表示されるシステム障害が生じた。 アマゾン側は利用者からの連絡を受けて不具合を修正したが、 このシステム障害の結果、 多くの著者が自身の著作に対して好意的な書評を書き込んでいることが発覚した。
（途中省略）
アマゾンの書評欄は、個人情報を出さずに書き込めるシステムになっている。 個人情報が表示されてしまったことについて、アマゾンの広報担当者は 「今回生じた障害は不運な事故だった。 今後はこういったことが生じないように対処する」としている。

アマゾンですらこういう単純ミスによる事故を起こすのだ。 もしも表示されたのが氏名ではなくパスワードだったら？ (注：アマゾンのパスワード管理の仕組みはよくできている。これについては後述)

このように、 Webシステムにおけるセキュリティの基本であり、ほぼ唯一の要であるはずのパスワードにおいて、 その暗号化（ハッシュ化）保存がなされていない場合、それは非常に危険な状況だと言える。 いま、そんなWebシステムが巷にあふれているのだ。 いったいいつのまに、そしてどうして、このような状況になってしまったのだろうか？ （次回に続く）

セキュリティの基本とはなんだろうか？ コンピュータウィルス対策？ ファイアウォール？ プライバシーポリシー？ 否。単純な話、 パスワードを正しく管理することがセキュリティの基本中の基本だ。 何をいまさらというかもしれないが、実は、Webが急速に普及したここ2,3年の間に パスワードの扱い方に関する これまで常識がいつのまにか忘れ去られようとしており、 いま、非常に危険な状況にある。

「パスワードは暗号化（ハッシュ化）して保存する ＝管理者にもわからない状態で保存する」 というのが本来あるべき姿なのだ。

詳しい説明に入る前に、用語説明と断りを書いておく。 暗号化はなんとなくわかっていただけると思うが ハッシュ化という単語にはなじみが無い人が多いだろう。

• 暗号化とは？
  自由に決められる「鍵」を使い、文字や数値を ある一定の規則（暗号化関数という）で変換し、 一見では内容がわからない情報にすること。 「鍵」を知っている者はもとに戻して（復号化）内容を知ることができる。
• ハッシュ化とは？
  文字や数値をある一定の規則で変換すること。変換にはハッシュ関数、 別名一方通行関数を使う。 一方通行という名のとおり、変換されたものをもとに戻す手段は無い。
  例えば、「abcd123」という文字列をMD5というハッシュ関数で変換し、 それを文字として表すと 「79cfeb94595de33b3326c06ab1c7dbda」となる。 この32桁の文字から元の「abcd123」を割り出す方法は無い （もしできたらNASAかCIAあたりからスカウトがくるだろう）。

このように、暗号化とハッシュ化は似てるが違う。 パスワードの保存に適しているのはハッシュ化のほうなのだが、 単に「ハッシュ化」と書いてもピンとこないと思われるため、 この先の話ではあえて「暗号化（ハッシュ化）」と書くことにする。

さて、話を戻そう。
ＩＴ関連技術者ではない一般ピープル(?)な人が想像する Webサイトにおける認証の仕組みとは、 たとえば次のようなものではないだろうか。

1. ユーザーがユーザー登録(会員登録)する。 その際にユーザーIDとパスワードを登録する。 Webサイトはそれらをそのままデータベースに記録する。
2. ユーザーがWebサイト上でIDとパスワードを入力する
3. Webシステムは入力されたIDをもとにデータベースからパスワードを探し出す
4. 入力されたパスワードと、データベースにあったパスワードを照らし合わせ、 合致すれば認証ＯＫ。間違っていれば「IDまたはパスワードが違います」を表示

一見すると当然と思える仕組みだが、重大な欠点がある。 データベースの閲覧権限のある管理者は ユーザーのパスワードを知ることができてしまうのだ。 本来のあるべき姿とは、次のような仕組みである。

1. ユーザーがユーザー登録(会員登録)する。その際にパスワードを入力させるが、 Webサイトはパスワードを暗号化（ハッシュ化）してデータベースに記録する。
2. ユーザーがWebサイト上でユーザーIDとパスワードを入力する
3. Webシステムは入力されたIDをもとにデータベースからパスワードを探し出す
4. 入力されたパスワードを暗号化（ハッシュ化）し、 データベースにあったパスワード＝すでに暗号化（ハッシュ化）済み＝ と照らし合わせ、合致すれば認証ＯＫ。 間違っていれば「IDまたはパスワードが違います」を表示

この手法は次のような利点と欠点がある。

• 管理者ですらユーザーのパスワードを知ることができないため安全性が高い。
• 万が一会員データベースが漏洩しても、 パスワードは暗号化（ハッシュ化）されているので、 第三者にログインされてしまうといった最悪の事態を避けることができる。 （ただし誕生日だとか自分のイニシャルだとか類推しやすい簡単なパスワードを使った場合は別。 それはそんなパスワードを登録した人が悪い）
• 管理者にもパスワードはわからないので、 「パスワードを忘れたのですがどうしたらよいのでしょう」 というユーザーに対しては新しいパスワードを発行して古いパスワードを上書きし、 新しいパスワードを安全な方法でユーザーに伝えなくてはならない。 データベース上のパスワードを見てそれを教えればいいという 簡単な方法ではないので業務がやや面倒になる。 （しかし安全性には変えられないはずだ）

このようなパスワードの取り扱い方法は目新しいものでも複雑で高価なものでもなんでもない。 少なくとも10年、もしかしたら20年くらい前からある安価で安全性の高い手法であり、 現在でも多くのコンピュータシステムで利用されている。 ところが、前回の記事で書いたＥＣサイトのように、 パスワードを暗号化（ハッシュ化）せず平文のままでデータベースに保存しているWebシステムが、 ここ2,3年の間に急増してしまった。 恐ろしいことに、それに対して違和感も危機感も感じられていない。 （次回に続く）

最近、とあるECサイトで買い物をしようとした。前に利用したことがあるので、 会員登録はすませてある。IDとパスワードを入力する。しかし「パスワードが違います」と 怒られる。たまにあるミスだ。あわてず、「パスワードを忘れた方はこちら」をクリックし、 所定の手続きをとると、ほどなくメールが届いた。

パスワード再送のお知らせ：
ご利用ありがとうございます。
あなたのパスワードは abcd123 です。

ああ、思い出したそうだった。このパスワード、見覚えある。 会員登録のときに自分で入力したやつだ。

・・・って、おい！ちょっとまて！なぜおまえは俺のパスワードを知っている！？

ここまでの話で、これからいわんとすることに予想がついたという人は幸いだ。 逆に上の話に違和感をまったく感じないという人は、ここから先の話を じっくりと読んでほしい。いま、パスワードは危機に瀕している。

例えばアマゾンや楽天を「お気に入りに追加」すると、ブラウザ上ではこんな風に表示される。

URL表示部分
お気に入り表示部分

このちょっとした絵（アイコン）をfavicon.ico（ファビコン）という。googleで検索すれば いろいろ出てくるのだが、 内容的に古かったり不足だったりで断片的な情報が多い。 そこで、いまさらではあるがここでもある程度の解説をまとめてみたい。 まずはいくつか箇条書きしてみよう。

基本的なこと

• Favorite Icon（お気に入りアイコン）の略である（そのまんま）
• マイクロソフトの公式な解説ページにあるとおり、 アイコンファイルを作ってHTMLファイル等と同様にWebサーバ上の所定の位置に置くだけで実現可能。 アイコンの作成にはアイコンエディタを使えばよい。 フリーソフトもいろいろある。筆者のお勧めはKH IconStudio。
• favicon.icoはHTTPやHTMLの標準規格には無い。というのは、 マイクロソフトのInternet Explorer独自の拡張機能として搭載されたのが最初だからだ。
• ということはfavicon.icoはInternet Explorerでしか見えないはずなのだが、時間がたつにつれ他のブラウザもIEを真似て対応するようになり、現在ではMacintoshのSafariやOperaなどのブラウザでも同様の機能がある。

基本的なことはこれくらいだが、さらに付属的な情報も付け加えておこう。

ブラウザの動作とWebデザイナーが気がつくきっかけ

ユーザーが「お気に入りに入れる」という動作をとったときにはじめてIEブラウザがfavicon.icoをWebサーバから取得にかかる。 そのときfavicon.icoが存在しないと、「そんなファイル無いよ」というエラー(404エラー)が発生したことがWebサーバのアクセスログに記録される。 （ブラウザ側ではデフォルトの青い「ｅ」マークが使われるだけ） Webマスターがアクセスログの解析をする過程で「favicon.icoが404エラー？俺はそんなコンテンツつくってないぞ？」と気づくことでfavicon.icoとは何ぞやという問題にたどりつくケースが多いようだ。

アクセスログ解析上の利点と落とし穴

裏を返せば、favicon.icoへのアクセス数（あるいはエラー数）はそのまま「お気に入りに入れようとしたユーザーの数」と解釈できる。 そのため、日々のアクセス数（ページビュー）と同様にサイトの人気度を計る指標としているWebマスターもいるようだ。ただし落とし穴がある。 例えばMacintoshのSafariブラウザやOperaなどは、 ユーザーが今見ているページをお気に入りに入れようとしなくても勝手にfavicon.icoにアクセスしてしまうことがあるのだ。 したがって、どのブラウザからのfavicon.icoへのアクセスなのかを正確に把握した上で統計を取らないと、 「今日は100人がお気に入りに入れてくれた」と喜んでいても、 実際にお気に入りに入れたユーザーは20人に満たないなんてことがありうる。

不具合

「お気に入りに追加」をしてもアイコンが現れないんだけどなんで？ という方もいると思う。Internet Explorerの何らかの不具合と思われるが、原因は不明だ。 ツール − インターネットオプションの「インターネット一時ファイルの削除」をやると直るという話もあるが、定かではない。（情報ある方はコメントお願いします）

効果、効能

favicon.icoは単なるちょっとした飾りではあるが効果が無いことも無い。 「お気に入り」のリストはもう何十個ものURLでいっぱいになっている人も多いだろう。 そんな行列のなかにあって独自のアイコンを表示していればある程度は目立つことができる。 少なくともデフォルトの青い「ｅ」マークのままよりはましだろう。

隠れた機能

ただし、さして重要でない飾りと思っててきとうに作ると思わぬ落とし穴が待っている。 実はfavicon.icoの表示のされ方は上であげた以外にもうひとつあるのだ。 アマゾン、楽天のそれぞれで、ブラウザのURLバーに表示されたアイコンを、マウスでつかんでそのままデスクトップ上にドラッグ＆ドロップしてみてほしい。次のような結果になるはずだ。

実はOSとしてのWindowsではアイコンの大きさが何種類かある。 上のようにデスクトップ上でのアイコンとして使用されるのは32x32ピクセルのアイコン。 ブラウザ上で使用されるのは16x16ピクセルのアイコン。 楽天のfavicon.icoファイルには16x16のアイコン情報しかないが、 アマゾンのfavicon.icoファイルには16x16と32x32の両方が格納されているのだ。 だからアマゾンはURLをショートカットとしてデスクトップに表示してもアイコンが見栄えよく表示される。

恥をしのんでお願い。 どなたかorkut誘ってください。(^^;
なにしろやってみないことにはネタにもできないので。

orkut（オークト）とは、Googleの社員の研究が発端となった 新種の出会い系サイトで、このほどGoogleの正式な(?)サービスとなったようです。 すでにメンバー登録している誰かの推薦というか誘いがないと利用できない。 出会い系というとなんだかネガティブなイメージがありますが、 男女の出会いではなく社会人としてのつながり(?)の新しい形(?)模索している「らしい」んです。

詳しくは 元の記事のほうをご覧ください。

シーサー、ブログベースの通販サイト構築サービス「Seesaa SHOPPING」(Internet Watch 2004/02)

「blogでビジネスになるか(2)」でも 書いたとおり、blogツールは個人の日記サイトで使うだけではなくれっきとした商売で使用する CMS（コンテントマネジメントシステム）としてのほうが将来性があると思う。 ただ、楽天の各商店やあるいはヤフーオークションなどのブース（個人だけではなく普通の商店が ヤフオクで商売している例はめずらしくない）に対してどれだけの差別化がはかれるかは、 うーん、まだ未知数。 シーサーのサービスは2月末からのオープンなので中身を見ないとなんともだが、 今後に期待。

バイアグラ売りますとか儲かるサイドビジネスだとかそういういわゆる迷惑メール(SPAM)に 辟易している人は増えてきたと思う。対処の基本は無視することなのだが、 なんとかしようとして返信したりする人が意外と多いらしいというのはちょっと新鮮な驚きだ。 初心者ユーザーとはそういうものなのだろうか。

「半数の人が間違ったスパム対策をしている」シマンテック調査(CNET Japan 2004/2)より
スパムによる影響が深刻化する一方で、間違ったスパム対策を行っている人が多いことも明らかになった。メールに書かれたURLにアクセスし、拒否の意向を伝える人が24.6％、メール内にある宛先に拒否する旨を書いたメールを送る人が21.9％いるという。「これらの方法はアドレスが実際に利用されているものだと相手にわかってしまうので、絶対にやってはいけないことだ」（インフォプラント カスタマーサポート部 カスタマーサポートグループ マーケティングリサーチャーの松澤治三氏）。

ところで、ウィルス対策ソフトを出しているシマンテックが迷惑メール対策ソフトも出すようだ。 ここ数年の間に、PCにはウィルス対策ソフトがプリインストールされているのが常識になったように、 迷惑メール対策ソフトもデフォルトになってゆくのが今後の流れなのだろう。

関連する過去記事：

• ニフティ、ベイズ理論を応用した迷惑メール対策フィルターを提供開始
• 自動スパム排除がなかなかの認識率 - Eudora 6J for Windows

お詫びと訂正（2004/2/21追記） この記事の中で「携帯電話用のブラウザはHTTP圧縮転送に対応している」という くだりがありますが、事実と異なることが判明しました。 （コメントで指摘してくださった方、ありがとうございます） 指摘を受け、自前の環境でひとまずドコモの505ITでテストをしてみたところ、 圧縮転送の様子が確認できませんでした。 じゃなんで書いていたのかというと、単なる私の誤解＆思い込みです。 以前、圧縮転送について種々のブラウザの対応状況について調べようと Webサーバのアクセスログを調査していたときに、 mopera.ne.jpというドコモのPDA端末向けインターネット接続サービスからの アクセスで圧縮転送が利用されていることを確認していました。 もちろんWindowsCEマシンに搭載されている、PC上でのIEとほぼ同等の ブラウザからのアクセスなので圧縮転送に対応していても なんら不思議ではないのですが、この調査結果がなぜか筆者の頭のなかで 「ドコモの携帯が圧縮転送している」という、ものすごい勘違いな記憶に つながっていたようです。 完全な誤解と誤記であり、お詫びして訂正させていただきます。 この記事を削除してしまおうかとも考えたのですが、 携帯電話はともかく、通常のPC向けのWebサイトにおいては現状でも 通信帯域の大幅な節約につながることは間違い無いので、 この追記を書いたうえで、記事としては残しておくことにしました。 最後に。「動画の録画やゲームのドラゴンクエストができるほどの 処理能力を携帯電話に持たせるなら、 gzipによるHTTP圧縮転送の対応ぐらいやって ユーザーのパケット料金の節約に協力してください、 ドコモその他携帯各社さん。」 （負け惜しみ？笑）

「社員に携帯電話をもたせ、携帯対応の業務用Webサイトで外回りの営業報告をさせてるが、 パケット料金がバカにならない」
「レンタルサーバーを借りているが、データ転送量が大きくて回線利用の追加料金をとられそうだ」

そんな問題を解決する魔法のような方法が、 いま使われているWebサーバとブラウザに、すでにある。

• IIS 5.0 Web サイトで HTTP 圧縮を使用する
• Apacheにmod_gzipを組み込んで帯域を節約したい

HTTP/1.0規格にある圧縮転送ほど、ものすごく古くからあるのにその重要性や有効性に 気づいている人が少ない規格もめずらしい。（ちなみにHTTP/1.0規格は1996年に成立している） いま世の中で稼動しているWebサーバソフト（ApacheとかIIS）はすべて このHTTP圧縮機能に対応しているし、Webブラウザも、InternetExplorerなら4.0の ころから対応している。そしてiモードなどの携帯電話用ブラウザも、とっくの昔から対応している。 しかし、その機能が使われているケースは非常に少ないだろう。

HTTP圧縮を使用するだけで帯域幅もコストも削減できる〜米調査結果 (2003/7 InternetWatch)

ちなみに、 ここでURLを入力するだけで、そのサイトではgzip圧縮がされているか否か、 もし圧縮したらどの程度圧縮され、どの程度の転送スピードアップが見込めるか？ が一目瞭然にわかる。営業社員に持たせた携帯電話のパケット料金が気になる企業は 真剣に検討すべきだろう。 少なくともパケット料金を半分以下に削減できる可能性がある。

注意点をいくつか挙げておこう。

• 実際に圧縮できるのはHTMLなどのテキストデータの場合だけで、 GIFやJPEGなどの画像についでは無意味である （ほとんどの画像形式はすでに圧縮がかかっているからそれ以上圧縮できない）。 実際、Webサーバでの圧縮転送の設定では「画像などについては圧縮対象としない」 といった設定がデフォルトだ。
• 「HTTP圧縮転送ができるのは静的につくったHTMLファイルだけで、 動的に作ったページは無理なのでは？」と考える人も多いらしいが、完全な誤解である。 静的ファイルであれ動的であれWebサーバから最終的に送り出される内容が HTMLなどのテキストデータであるならば圧縮は可能であり、動的ページ生成に 使われている言語やアプリケーションは問われない。ＡＰの変更も不要で、 Webサーバの設定変更だけですむはずである。

最近、こんな議論がなされているらしい。

「このままでは日本のインターネットは崩壊する」，IIJの鈴木社長が総務省研究会で警鐘 (IT Pro 2004/02)

ネットワークインフラの増強が国レベルで必要、という主張には基本的に同意したい。 しかし、とにかく金をかけて道を広げようというのも悪くないが、 道を通る量を小さくする工夫も同時に考えるべきだろう。 いつまでたっても渋滞だらけの首都高速から学ぶべきことはまだまだたくさんあるのではないだろうか。

たとえば、「キーワード + 地名」でYahooを検索してみると、面白いものが見えてくる。

• 「ボクシング 池袋」でYahooで検索
• 「テニス 日比谷」でYahooで検索。
• 「新宿 太極拳」でYahooで検索
• 「ウインドサーフィン 乃木坂」でYahooで検索

この調子で行くと他にもいろいろあるだろうなということはご想像のとおりである。 そう、いずれの結果においても、 リクルートが出している雑誌「ケイコとマナブ」のサイトが最初に来る。

「ボクシング 池袋」で検索するひとは、池袋周辺のボクシングジムやフィットネスクラブを 探しているんだろう。でもイサイズが、 検索エンジン対策見え見えすぎるページ を通してユーザーを誘導する先は板橋のボクシングジムだ。 たしかに池袋と板橋はそう遠くはない。百歩譲るとしよう。 でも「テニス-日比谷」から誘導されるのが 池袋のテニススクールというのはどうだろう？(※) 「ウインドサーフィン 乃木坂」（※）に至ってはキーワード自体が もうなんというかありえない領域だ。(笑)

※この記事を書いた数週間後に、テニス-日比谷から誘導されるページは有楽町線の豊洲近くにある テニススクールに差し替えられた。が、日比谷に関連していないのは相変わらずである。（笑）
※乃木坂は、港区の六本木や青山霊園などに近い、都心のど真ん中。

SEO=Search Engine Optimization=検索エンジン最適化（対策）のために、 ページにテキストを多くしたり、キーワードをちりばめたりするならまだ正統的だし、 かわいいものだし、正しい。しかしここまでやるというのは、 検索エンジンを、というよりはユーザーを、バカにしすぎではないだろうか？

マネしようと思う方々のためにいくつか情報を。

• 検索結果の最初に現れたページが自分の意に沿わなかったときのユーザーの落胆の 気持ちを忘れてはならない。 もしもそれが有名な企業のサイトであった場合ならなおさらである。
• それが検索エンジンを利用した巧妙なだましスレスレのテクニックであったことを ユーザーが知ったときに沸き起こるであろう怒りの気持ちを忘れてはならない。 もしもそれが有名な企業のサイトであっ（以下同文）
• こうした検索エンジン専用の誘導用ページをつくることは、本来のページの 維持更新作業も含めればコスト的に倍になることを覚悟しなければならない。
• Yahoo!がGoogleを使い続ける保証はどこにもない。 現にアメリカのYahooはgoogleとの提携を解消する。 日本もどうなるかはまったく未知数。 検索エンジン対策のページをつくった苦労は一瞬にして水の泡となる可能性がある。
• Google はいわゆる「検索エンジンSPAM」を 問題視している。 Googleが不適当と判断したら、インデクスから削除され＝検索してもひっかからなくされ、 やはり苦労は一瞬にして水の泡となる可能性がある。

複雑にシステム化されたサイトにおける検索エンジン対策は本当に難しい。 これに関しては別なところで記事にしたいと思うが、一言でいってしまえば、 結局のところ、ユーザーにとって見やすくわかりやすい、 シンプルイズベストなページをコツコツつくることが一番の検索エンジン対策だ。

セグウェイで公道走る 整備不良で書類送検 (2004.02.06)

読売新聞

すぐにわかることなのでここでも書いてしまうが、 書類送検された「東京都世田谷区の会社社長」とは、 ビデオジャーナリストのKNN=KandaNewsNetworkの神田 敏晶氏である。 注目すべきなのは、神田氏の本業はフリーのジャーナリストであり、 2004年2月2日現在、イラクで取材中だということだ。

セグウェイとは？

コレのことである
アメリカの有名な発明家が開発した２輪の立ち乗り式電動スクーター。特殊なジャイロを搭載し、 倒れない、不思議な乗り物。その先進性や機能性もさることながら、 アマゾンが独占販売していることでも話題になっている。
関連記事： 『セグウェイ』の実用化には道路交通法の整備が必要（2002/02 hotwired）

「日本で公道を走った」というのは？

2003年7月のこのイベントのことである。他にも紹介された例はいろいろある。

セグウェイ、渋谷に現れるCNET Japan 2003/03
【レポート】運動神経いらずですぐにスイスイ! 「Segway HT」試乗記(MYCOM PC WEB 2003/05)

神田氏がイラクにいるというのは？

ここで本人が現地レポートを書いているとおりである。
神田氏は新聞社や通信社などの組織に属さない、 独立したフリーのビデオジャーナリストだ。 さまざまなイベント会場などで、 テンガロンハットにビデオカメラ片手で取材を行う神田氏の姿を 見たことのあるという方もいるだろう。

なんでいまのタイミングなのか？

そこである。 神田氏はいまイラクにいて自由な取材活動をしていて、 そして日本で何かあっても逆に動きがとりにくい。 (追記：2月6日現在で既に帰国していたようです。失礼しました。 しかしそれにしたって昨年7月の話がいまになってというのは！？) そこから先はこのサイトを見ている諸氏にそれぞれ考えていただきたい。

最後に、私の願い。

事情はどうであれ、仕事として、情熱として、イラクへ向かう方々の無事を、 人間として祈りたい。
ジャーナリストの方々には自由かつ正確な報道をしていただくことを、 そしてその活動がいかなる形であれ非合理的に妨げられることがないよう、 社会人として祈りたい。
セグウェイをはじめとする先進的、機能的な技術が、 それと無関係な約束事やしがらみで葬られるようなことが決して無いよう、 技術者として祈りたい。

LinuxやPostgreSQLなどのオープンソースソフトを使っているがゆえに、 ソースコードを確認することでバグを発見したり 修正したりできたよ、という話。

システム構築の現場でも「ソースを使え，ルーク」 : IT Pro 記者の眼 2004/02

目的が業務システムの開発であれば，本来はミドルウエアやOSの中身など気にすることなく，業務ロジックの開発だけに専念できるのが理想だ。ただし現実には，残念ながらミドルウエアやOSの障害はなくならないし，ミドルウエアが，必要なすべての機能や性能を満たしているわけではない。このことはオープンソース・ソフトウエアでも商用ソフトウエアでも同様だろう。
　そのような場面で，ミドルウエアやOSのソース・コードを解析し修正する能力は，大きな価値をもたらしている。処理性能の確保や開発の省力化などだ。もし，ここまで紹介したシステムの障害が解決できなかったら，その損失はいくらになっただろうか。お金に換算すれば，その価値ははかりしれない。

コンピュータの“西暦2038年問題”発生、早くも日本を揺るがす : IT Pro ニュース(2003/01)
2038年問題による影響はすでに広く報道されている。1月11日に23行の銀行でATM（現金自動預払機）が一部の取引で正常に利用できなくなったトラブルの原因が、この2038年問題によるものだった。

「2000年問題」を覚えている方は多いだろうが、 2038年問題なんて聞いたことないという人もいるだろう。 上の記事にも解説はあるが、ここでも書いてみる。

1970年代、UNIXと呼ばれるコンピュータやそこで使用する言語の規格をつくるにあたり、 次のようなことが定められた。

1970年1月1日を始点として32bitの数値で日時をあらわすものとする

要するに、コンピュータの内部では1970年1月1日0時0分0秒からの 経過秒数で日時をあらわすことにした。 （逆に1970年より前の数値は負の数で表す） そのほうがコンピュータ内での足し算、引き算などがラクだから。 もちろん実際に人間の目に映すときには秒数ではなく 普通の「○月○日○時○分○秒」に変換するわけだ。

32bitの数値というのはつまり2進数で32桁という意味である。 ということは、

00000000000000000000000000000000 は1970年1月1日0時0分0秒
00000000000000000000000000000001 は1970年1月1日0時0分1秒
00000000000000000000000000000010 は1970年1月1日0時0分2秒
00000000000000000000000000000011 は1970年1月1日0時0分3秒

という具合である。このままいくと
11111111111111111111111111111111 は2038年1月19日3時14分8秒
となるわけだ。2進数で32桁までと決まっている以上はこれより大きな数値を表せない！＝2038年問題

なんでもっと大きな桁数にしておかなかったんだ！という ツッコミももっともだが、1970年代当時は仕方なかった。 今のパソコンに比べれば当時のコンピュータの性能はゲームボーイよりさらに貧弱。 沢山の数値を覚えきって計算するほど性能がよくないので、 とりあえず32桁にしたのだ。 それに、半導体の性能アップと低価格化がこんな驚異的に進むなんて誰も夢にも思っていなかった。 もちろんソフトによってはより幅の広い日時を計算できるようになってるが、 もともとの規格がそうである以上、 複雑に結合されたコンピュータシステム全てはカバーできない。

「2035年ごろになってから騒ぐんだろう」と思っていたら、 こんな形で顕在化するとは。事実は奇なり。

幼稚園向けネットワークカメラの機材や設置などのパックが登場 （Cnet JAPAN 2004/02)
このパックを使うことで、園内の様子の確認や録画ができるほか、遠隔地からでも幼稚園・保育園の様子をPCや携帯電話で確認できるシステムを簡単に導入できる。

幼稚園でのこうしたサービスは意外と需要があるらしい。 父母としては、いつでもわが子を確認できるという安心感と楽しさ(?)があるようだ。

ネットワーク装置とカメラの設置と調整など、 素人では難しい作業が必要なためコストが高くつく＝個人家庭向けではなく 企業、団体向け、という流れなのだろうが、 通信ネットワークの種々のサービスと機材の低価格化が 進めば、もっと潜在顧客の多そうなビジネスが見えてくる。

1. パソコンもカメラも安くなり、稼動も安定してきた
2. ADSLを始めとする常時接続環境が安く普及してきた
3. 無線LAN機能がついたルーターも低価格化し、面倒な「配線」が不要になった
4. プロバイダ自身が無線LAN環境も含めたサービスをしはじめた→YahooBBの無線LANパックとか
5. 職場での一人一台PC化は当然のこと、ネット接続できる携帯電話も当たり前になった （＝監視カメラを見る側の環境がちゃんとある）

この流れでくると、次にくるのは「家庭向け防犯カメラ遠隔監視システム」としての webカメラシステムだ。こんなうたい文句でどうだろう。

あなたのお部屋を24時間いつでも見れる！インターネット防犯カメラ！

• ADSL回線＋無線LAN付きルーターと無線Webカメラのパック！
• カメラもパソコンもコードレスです。面倒な配線は一切不要！
• 仕事場のパソコンから、携帯電話から、いつでもお部屋の様子をチェック！
• カメラにサーバ機能がついてます。パソコンを起動しておく必要はありません！
• カメラの設定はブラウザからできます。簡単です！
• カメラを見るためのURLを毎日自動的に変更してあなただけにメールでお届けします。 プライバシーも安心！
• インテリア性のある美しいデザインの小型カメラ！目立ちません！
• こんな人にお勧め！
  • 一人暮らしの女性の方
  • 共働きで、家庭に残した小さいお子さん（いわゆるカギっ子）が心配なご両親
  • 離れた場所に住んでいる一人暮らしの親御さんが心配な方

いますでにあるネットワーク環境や技術や機材をほんの少し改良して組み合わせれば十分に可能なシステムだ。（ダイナミックDNSがカギになるのは前にも書いたとおり ） 自分がプロバイダの人間だったら是非企画したい。 大して儲かるほどの需要のない動画配信ビジネスよりはよほど有望だろう。

と、自分のアイデアかのように書いたが、 パナソニックのネットワークカメラなんて、もろにそれ。（笑） ただ、パソコンいらない。防犯カメラだけほしいという需要にもこたえられるのは やはりメーカーではなくプロバイダだろう。プロバイダにとって、非パソコンユーザーにも 顧客を広げるという、従来では考えられなかったビジネスチャンスじゃないだろうか。

2004/2/16追記：
とかなんとかいっている間にも、

ライブドア、Webカメラを活用したホームセキュリティソフト「防犯24時」 5800円(InternetWatch 2004/2)

という報道が。今後こういう商品やサービスの動きは加速してゆくだろう。

2004/2/23追記：
「監視用カメラ」に隠れたチャンス潜む？―Web カメラの利用動向(Japan.internet.com)