2010年08月01日()<< 前の日記 | 次の日記 >>
この日の詳細

■1 シリーズ・クロールとDoSの違いと業務妨害罪と(8) - 自治体のIT調達に横たわる病理[http://www.nantoka.com/~kei/diary/?20100727S1][電子自治体][DoS][mashup][セキュリティ][LibraHack] このエントリーをはてなブックマークに追加

このシリーズに「電子自治体」と「セキュリティ」のカテゴリを付けているのには理由があって、電子自治体システムにセキュリティ上の問題が次から次へと出てきた現象と、今回の事件は同じ病理によるものでは無いかと考えたからだ。
電子自治体でのIT調達では、自治体側にITを理解した職員がいないのに付けこみ、ITベンダーが技術的に出鱈目な仕事をやった結果、ハードウェアもミドルウェアも高コスト、開発費用も高コスト、得られたものは、高い保守運用費用だけということになって、電子自治体という市場そのものの将来をダメにしてしまった。
本来であれば、窓口業務をネットにシフトすることによって、サービスを改善しつつ、人件費コストの削減、あるいは、より親切なサービスの提供という形で、投下コストが回収でき、新たなシステム化の原資となって、市場拡大のサイクルを形成していたはずなのだ。
この様な問題、図書館ではどうであろうか。岡崎市に限らず、図書館システムの調達でも似ているような現象が起きている様だ。
今回の岡崎市のケースではどういう現象が起きたのだろうか。
岡崎市立中央図書館の場合、現状のシステムの調達は「プロポーザル形式」で行われた様だ。
委員(近藤隆志)「それから、427ページ、6項5目の13節委託料ということで、またこれも図書館でありますが、 情報システムの構築委託料ということで1,700万ということであります。委託先等わかれば、内容と委託先をお願いしたいと思います。」(p.244)
教育委員会教育部次長(手嶋康雄)「それから、図書館の情報システムについてでございますが、これは、現在使用中のコンピューターが平成17年の6月末にリースの期間が満了いたしますので、新しい図書館を見据えた新しいシステムを新たに稼働させるための予算でございます。 16年度は画面設計、帳票の設計等のプログラムの作成委託をいたしまして、17年度には現在のシステムから新しいシステムへのデータ移行とか機器のセットアップ、これを行っていく予定でございます。委託先でございますが、 16年度は、プロポーザル方式によりまして三菱電機株式会社と契約をしております。17年度も、随契によりまして三菱電機株式会社を予定しております。」(p.246)
プロポーザル形式は、入札の様に価格を競うことによって、低品質のものになってしまうのを避け、用意した予算の範囲内でより良いものを選定するために有利と言うことになっている。
また、ITシステムの調達においては、例えば、設計、開発、構築、運用とフェーズが分かれていくが、この各々のフェーズをばらばらに入札に掛けるのも難しいため、プロポーザル形式で業者を選定するという事が行われる。
今回のケースもそうだった様で、平成16年度に「画面設計、帳票の設計等のプログラムの作成委託」で1700万円の委託を行い、次年度以降は「随意契約」によって、引き続き発注を行ってきた模様だ。
これは、業者にとっては非常に仕事がやりやすい形態で、最初の仕事を獲得してしまえば、引き続きの仕事は「随意契約」の形で、他社と金額的に比較をされることなく「提案」を行うことができる。
実際、どの様な内容の仕事が、どれだけの金額で「随意契約」されてきたかは、 公文書開示請求[http://www.city.okazaki.aichi.jp/menu1385.html] を使えば明らかにすることができるはずだが、時間を要するので判明した範囲で、 平成21年度の事業評価書[http://www.city.okazaki.aichi.jp/appli/11/pdf04/2009-0000003845.pdf] によれば、 電算システム運用費用として、平成20年度決算102,050千円、平成21年度予算68,805千円 が計上されている。
年間1億円とか6千万円の費用を投じて運用を行っていながら、なぜ今回の様な事件が発生したのかについては大いに関心がある。
そもそものプロポーザルにおいても、この様なシステムを作る業者を、誰がどの様に評価して選んだのかについても大いに関心がある。選定理由書を見れば、評価者が評価できなかったのか、業者が評価を裏切ったのかはある程度、明らかになりそうだ。
ところで、岡崎市立中央図書館は、「新図書館システムの構築」を行うため、平成21年度組織重点目標として、
【目標項目】新図書館システムの構築
【達成方法】
1.要求水準の把握
2.図書館業務内容とシステムの連鎖性の把握
3.最近の技術動向の把握
【目標達成基準】 新図書館システムの概要設計を構築する
を掲げており、 取組実績報告書[http://www.city.okazaki.aichi.jp/secure/2081/bujyuutennmokuhyoujisseki.pdf] によれば、これを達成したとしている。
つまり、 図書館システムに関しての「要求水準」や「最近の技術動向」を把握しており、「新図書館システムの概要設計を構築」したと言っているのだが、 今回の事件を鑑みると、一体「要求水準」や「最近の技術動向」をどの様に把握しているか甚だ不安になる。 そして、その把握に基づいた概要設計によって、本年度は 新図書館システムの導入が進められつつある(p.48)[http://www.city.okazaki.aichi.jp/secure/2101/22keieihoshin08.pdf] という 。新システムの導入はどのベンダーが行うのか興味があったので、 入札結果[http://www.city.okazaki.aichi.jp/keiyaku/Nyuusatu.htm] を調べたのだが、それらしいものが見当たらない。今回はどの様に選定したのだろうか。
民間の会社等では、システムに費用を投じるからには、その投資は利益をもたらす必要があって、例えば、現場の作業性の向上や、提供されるサービスレベルの向上が利益を生み出す源泉に相当するから、現場での使い勝手や、提供されるサービスは何よりも重視して評価される。現場での使い勝手を無視したシステム導入はあり得ない。
ところが、現場業務を外部委託して丸投げしていると、現場での使い勝手を無視したシステム導入が行われて、「動かないコンピュータ」になってしまうことが起こる。
岡崎市立中央図書館においては、図書館の運営を 図書館流通センター[http://www.trc.co.jp/municipalit/service.html] に委託している様だが、委託先のスタッフの声がシステム選定に反映されていることを願うばかりだ。

■ 関連記事

詳細はこの日の詳細から

2010年08月02日(月)<< 前の日記 | 次の日記 >>
この日の詳細

■1 シリーズ・クロールとDoSの違いと業務妨害罪と(9) - 関連リンク集[http://www.nantoka.com/~kei/diary/?20100801S1][電子自治体][DoS][mashup][セキュリティ][LibraHack] このエントリーをはてなブックマークに追加

この話題、
  • マッシュアップに代表される、Webのさらなる活用に対する不安
  • 公共サービスを提供するシステムとしての脆弱さ
  • Webに公開するシステムとしての実装上の問題
  • 自治体のIT調達における課題
と言った、様々な問題を提起していることもあって、当初の報道から数か月を経過しても、勢いが衰えることなく、 #LibraHack[http://search.twitter.com/search?q=%23LibraHack] を中心として、活発な議論が行われている。
議論が様々な広がりを見せていることもあって、この問題に新たに関心を持つ人も増えているので、まとめと解説が必要だと感じた。
新たにまとめや解説を作るのには、それなりの手間も掛かるが、とりあえずこれまでに出てきたページやまとめのリンクだけでも整理してみることにした。
以下のリストは、情報を頂く都度、アップデートする予定である。
足すべきページをお知らせ頂きたいし、もっと良いまとめを作る方が現れることも期待する。なお連絡は、 @keikuma[http://twitter.com/keikuma] まで頂けるとありがたい。

岡崎市立中央図書館事件リンク集:

blog等
岡崎市立中央図書館HP大量アクセス事件まとめ[http://librahack.jp/]
LibraHack事件当人が事件を開設したまとめ
高木浩光@自宅の日記 - 岡崎図書館事件について その1[http://takagi-hiromitsu.jp/diary/20100710.html#p01]
5月26日当初の報道に違和感を感じた頃、当時の警察への質問のやり取りを掲載
Web屋のネタ帳 - キミはLibraHack事件を知っているか?[http://neta.ywcafe.net/001102.html]
最速転職研究会 - 法と技術とクローラと私[http://d.hatena.ne.jp/mala/20100707/1278514965]
クローラーを実装する観点から
弁護士 落合洋司(東京弁護士会)の「日々是好日」 - 岡崎市立中央図書館事件について[http://d.hatena.ne.jp/yjochi/20100624#1277311161]
法的観点。業務妨害が成立する要件の観点から。
Togetterまとめ
岡崎市中央図書館向けクローラ作成者が逮捕・不起訴の件[http://togetter.com/li/30698]
岡崎市中央図書館向けクローラ作成者が逮捕・不起訴の件(Vol.1 - 6月24日以降分)[http://togetter.com/li/31948]
岡崎市中央図書館向けクローラ作成者が逮捕・不起訴の件(Vol.2 - 7月15日以降分)[http://togetter.com/li/35520]
網羅的まとめ。既に膨大な量になっており、シリーズ化されている。
岡崎市中央図書館向けクローラの件落ち穂拾い[http://togetter.com/li/39509]
blog等にあまりまとめられていない「事実関係」中心に抜粋。
マスコミ、メディア等
やじうまWatch 2010/5/27[http://internet.watch.impress.co.jp/docs/yajiuma/20100527_369677.html]
「図書館HPにアクセス3万3千回で逮捕」に疑問を呈する声が多数
やじうまWatch 2010/6/22[http://internet.watch.impress.co.jp/docs/yajiuma/20100622_375953.html]
「図書館HPにアクセス3万3千回で逮捕」の当事者によるまとめサイト ほか
「岡崎市立中央図書館サーバー事件」まとめ[http://r25.yahoo.co.jp/fushigi/jikenbo_detail/?id=20100625-00002724-r25]
R25によるまとめ

■ 関連記事

詳細はこの日の詳細から

2010年08月04日(水)<< 前の日記 | 次の日記 >>
この日の詳細

■1読んだ本[book] このエントリーをはてなブックマークに追加

■ 関連記事

詳細はこの日の詳細から

2010年08月05日(木)<< 前の日記 | 次の日記 >>
この日の詳細

■1OpenDesireでbmobileを使う[携帯端末][android][desire] このエントリーをはてなブックマークに追加

bmobileとアンテナbmobileとアンテナ
ウチではDesireに、b-mobileのU300を入れて使っているので、 OpenDesire v3.0.3[http://forum.xda-developers.com/showthread.php?t=712615] にしたら、アンテナが表示されなくなって不便だと思っていたのだけど、Radioのアップデートがあった模様で、 32.43.00.32U_5.09.00.20[http://forum.xda-developers.com/showthread.php?t=687464] を当てたら、アンテナ表示されるようになった。便利。

■ 関連記事

詳細はこの日の詳細から

2010年08月06日(金)<< 前の日記 | 次の日記 >>
この日の詳細

■1 シリーズ・クロールとDoSの違いと業務妨害罪と(10) - 動かないコンピュータ[http://www.nantoka.com/~kei/diary/?20100802S1][電子自治体][LibraHack] このエントリーをはてなブックマークに追加

日経コンピュータ2010年8月4日号[http://ec.nikkeibp.co.jp/item/backno/NC0762.html] の、「動かないコンピュータ」に、「岡崎市立中央図書館 - 検索システムが過負荷でダウン 利用者が逮捕される」として、本件の記事が出ている。
MDISに対して取材したのかどうかは、はっきりとはしないけれども、
MDISがまず取った対策は、新着情報ページのファイル名の変更だ。
動かないコンピュータ 岡崎市立中央図書館, 日経コンピュータ 2010年8月4日号
次に試みたのが、外部アクセスのブロックだ。ログを調べたところ、大量アクセスは常に一つのIPアドレスからだった。そこで3月31日、同アドレスからのアクセスをブロックした。
動かないコンピュータ 岡崎市立中央図書館, 日経コンピュータ 2010年8月4日号
と、MDISの対応について触れているので、少なくとも間接的には取材を行っている様だ。
で、あれば、専門誌たる日経コンピュータなのだから、技術的におかしいと感じたところはぜひ掘り下げて聞いて欲しかった。
例えば、記事中の、
DBサーバへのリクエスト件数が、ピーク時で10分間に2000件に達していた。通常の20倍以上というアクセスによって、DBサーバが過負荷状態に陥った。
動かないコンピュータ 岡崎市立中央図書館, 日経コンピュータ 2010年8月4日号
という記述。
この記述だけ読むと、中川氏が10分間で2000件のアクセス(秒間3アクセス強)を行ったかのように誤解する読者がいるかも知れない。
様々な情報から、実際のアクセスは1アクセス/秒程度のものだったという事が分かっており、上記の数字が約3倍になっているのは、恐らく、1回のアクセスに対して、書誌情報、所在情報、予約件数を表示するために、3回のDBリクエストが発生していたということだと考えられるが、「10分間に2000件」という数字を出す以上、ここは確認をして欲しかった点だ。
また、DBサーバについては「Oracle9i」としているが、ここでのDBに対するクエリは、全文検索等では無く、INDEX可能なキーに対するクエリーのはずで、戻り件数もせいぜい数件と言ったクエリのはずだ。 *1
「Oracle9i」のデータベースサーバに、INDEX可能なキーに対して戻りが数件というクエリを、10分間に2000件流すと過負荷状態に陥った という内容になっているのだが、これは事実なのだろうか。事実だとすれば、一体どういう事情でそういうことになったのか。
一般的なRDBMSでは、100万件からのINDEX付きキーでの抽出は、ハードウェアにも依存するにせよ、毎秒数千のオーダーの処理が可能だから、10分に2000件(=秒間3件強)とは、文字通り、桁が違う。3桁も違う。
記事の後段の方では、
中川氏のアクセスによってDBサーバがダウンしたのは、システムに問題があった可能性もある。
動かないコンピュータ 岡崎市立中央図書館, 日経コンピュータ 2010年8月4日号
としているが、この可能性をより深く掘り下げた続報に期待したい。

警察以外への相談:

JPCERT/CCに連絡すれば良かったという指摘がされていて、図書館の担当者はその存在を知らなかったので警察に連絡するしかなかったという解説がされているのだが、図書館の担当者は知らなくとも仕方が無いとして、保守を担当しているMDISは知っていても当然なのでは無かったかと思う。
もっともこのケースの場合、JPCERT/CCに相談しなくとも、 さくらインターネットのabuse担当[http://support.sakura.ad.jp/page/abuse] に連絡を取っていれば、対応してもらえていたのでは無いかと思われる。
IPアドレスから利用者を調べることをしているのだから、さくらインターネットの利用者だというところまでは確認していたのだと考えられる。
そこまで分かっていながら、なぜ、 「さくらインターネット 迷惑行為」[http://www.google.co.jp/search?hl=ja&client=firefox-a&hs=SNq&rls=org.mozilla%3Aja%3Aofficial&q=%E3%81%95%E3%81%8F%E3%82%89%E3%82%A4%E3%83%B3%E3%82%BF%E3%83%BC%E3%83%8D%E3%83%83%E3%83%88+%E8%BF%B7%E6%83%91%E8%A1%8C%E7%82%BA&btnG=%E6%A4%9C%E7%B4%A2&aq=f&aqi=&aql=&oq=&gs_rfai=] 程度の検索をしてみなかったのか、残念でならない。
*1: 文献コードをキーとして、書誌、所在、予約件数を取得するクエリで、書誌、予約件数は戻りは恐らく1件。所在情報は数件あるかも知れない。

■ 関連記事

詳細はこの日の詳細から

2010年08月12日(木)<< 前の日記 | 次の日記 >>
この日の詳細

■1Catalystで携帯サイトを作る[WebApp][Perl][Catalyst] このエントリーをはてなブックマークに追加

前回の記事[http://www.nantoka.com/~kei/diary/?20100724S1] でCatalystを触りだして、実際に何か作ってみるのが一番だろうという事で、携帯サイトを作り始めているのだけれども、これはなかなかサンプルとしては良かった。
例えば、携帯の場合、静的なHTMLに見えても絵文字や機種ごとの細かい違いに対応するために、実は動的にコンテンツを作る方がメンテナンスが楽だったりする。
sub html :LocalRegex('^([a-zA-Z0-9_]+).html$') {
    my ( $self, $c ) = @_;

    my $name = $c->request->captures->[0];
    my $file = $c->path_to("root/keitai/$name.html.tt");
    if (-e $file) {
        $c->stash->{template} = "keitai/$name.html.tt";
        $c->response->headers->header('Cache-Control' => 'maxage=86400');
        return 1;
    }
    $c->response->body( 'Page not found' );
    $c->response->status(404);
    return;
}
みたいな感じで簡単にテンプレート化できるし、Catalyst::Plugin::Private::KeitaiEnc なんていうのを用意してやって、Shift_JIS対応も複数キャリアの絵文字対応もそれなりにできちゃう。
で、今日、ちょっと困ったネタが、auのCookie。
どうもCookieの有効期限が効いてくれない気がするので、 EZwebのCookieの仕様[http://www.au.kddi.com/ezfactory/tec/spec/cookie.html] を調べてみたら、
有効期限の指定方法
Cookieの有効期限はHTTPレスポンスヘッダの「Set-Cookie」フィールドの「max age (有効残存秒数) 」で指定することができます。
と書いてある。
Catalystの$c->response->cookiesは、最終的にCGI::Simple::Cookieを使って、Catalyst/Engine.pmのfinalize_cookiesで、Set-Cookieヘッダを作っているので、介入の余地は無さそう。
手としては、$c->response->cookiesにCGI::Simple::Cookieの、Max-Ageを出力する派生物を入れるのだろうけど、ちょっと大がかり。
しばらく考えて、$c->stash->{mycookies}に入れておいて、endでSet-Cookieヘッダ自力で作るようにして解決。

■ 関連記事

詳細はこの日の詳細から

2010年08月14日()<< 前の日記 | 次の日記 >>
この日の詳細

■1 「ピコツイ!」誕生[http://picotwi.com][WebApp][Perl][Catalyst] このエントリーをはてなブックマークに追加

ピコツイ at Android前の記事[http://www.nantoka.com/~kei/diary/?20100812S1] あたりでごちゃごちゃ作っていたWebアプリが完成しました。「ピコツイ!」です。
携帯から「今、この瞬間に」つぶやきたいことを、瞬速ツイートするためWebアプリです。Twitterのアカウントと携帯があれば、30秒で登録できます。メールアドレスの登録も不要です。
α公開中ですが、よろしければお試しいただいて、フィードバックを @picotwi[http://twitter.com/picotwi] まで頂けましたらありがたいです。

■ 関連記事

詳細はこの日の詳細から

2010年08月15日()<< 前の日記 | 次の日記 >>
この日の詳細

■1 続・「ピコツイ!」誕生[http://www.nantoka.com/~kei/diary/?20100814S1][WebApp][Perl][Catalyst] このエントリーをはてなブックマークに追加

今日はお盆で精霊流しの日だったので、「精霊流しなぅ」「爆竹なぅ」「夜火矢なぅ」のボタンを特別に付けてみたのだけど、利用者いなかった。
地域毎にイベント向けのスペシャルボタンを出すのは良いかも知れない。

■ 関連記事

詳細はこの日の詳細から

2010年08月17日(火)<< 前の日記 | 次の日記 >>
この日の詳細

■1岡崎市立中央図書館事件に関する本日誌の記事一覧[電子自治体][LibraHack] このエントリーをはてなブックマークに追加

この事件に関連して書いた記事を一覧にしておく。
[2010-05-26] robots.txtに従わず、図書館HPにアクセス3万3千回 業務妨害容疑で男逮捕[http://www.nantoka.com/~kei/diary/?20100526S2]
当初の報道を読んでの様々な疑問。
[2010-06-21] 続・robots.txtに従わず、図書館HPにアクセス3万3千回 業務妨害容疑で男逮捕[http://www.nantoka.com/~kei/diary/?20100621S1]
Cookieで多重アクセスを抑制しようとして何か謎な現象が起きている様に見える件。
[2010-06-22] 岡崎市立中央図書館に電話してみた[http://www.nantoka.com/~kei/diary/?20100622S1]
岡崎市立中央図書館に問い合わせた際の聞き取りメモ。
[2010-06-24] クロールとDoSの違いと業務妨害罪と[http://www.nantoka.com/~kei/diary/?20100624S1]
クロールとDoSのそもそもの違い。無断リンク禁止教に新宗派、無断クロール禁止教。
[2010-07-14] 続・クロールとDoSの違いと業務妨害罪と[http://www.nantoka.com/~kei/diary/?20100714S1]
Cookieに何らかのリソースを紐付けているんじゃないかという疑惑が浮上。念力デバッグ。
[2010-07-15] シリーズ・クロールとDoSの違いと業務妨害罪と(3)[http://www.nantoka.com/~kei/diary/?20100715S2]
再び、クロールとDoSの違い。サーバが落ちるとは。
[2010-07-26] 続・robots.txtに従わず、図書館HPにアクセス3万3千回 業務妨害容疑で男逮捕[http://www.nantoka.com/~kei/diary/?20100712S1]
高木先生の「岡崎図書館事件について その1」について
[2010-07-18] シリーズ・クロールとDoSの違いと業務妨害罪と(4)[http://www.nantoka.com/~kei/diary/?20100718S1]
情報ネットワーク法学会での図書館側の対応を整理。
[2010-07-22] シリーズ・クロールとDoSの違いと業務妨害罪と(5) - その後の念力デバッグ[http://www.nantoka.com/~kei/diary/?20100722S1]
「再起動をしていた」という驚きの情報に基づいて、念力デバッグを修正。
[2010-07-23] シリーズ・クロールとDoSの違いと業務妨害罪と(6) - レガシーの呪縛[http://www.nantoka.com/~kei/diary/?20100723S1]
読み物。レガシー物語。
[2010-07-27] シリーズ・クロールとDoSの違いと業務妨害罪と(7) - 念力デバッグ再び[http://www.nantoka.com/~kei/diary/?20100727S1]
シミュレートによる、事件当時のアクセス挙動の推察。
[2010-08-01] シリーズ・クロールとDoSの違いと業務妨害罪と(8) - 自治体のIT調達に横たわる病理[http://www.nantoka.com/~kei/diary/?20100801S1]
システムの調達について、岡崎市議会等での公開資料を調査。
[2010-08-02] シリーズ・クロールとDoSの違いと業務妨害罪と(9) - 関連リンク集[http://www.nantoka.com/~kei/diary/?20100802S1]
関連リンク集
[2010-08-06] シリーズ・クロールとDoSの違いと業務妨害罪と(10) - 動かないコンピュータ[http://www.nantoka.com/~kei/diary/?20100806S1]
日経コンピュータ2010年8月4日号に掲載された、「岡崎市立中央図書館 - 検索システムが過負荷でダウン 利用者が逮捕される」の感想。

■ 関連記事

詳細はこの日の詳細から

2010年08月19日(木)<< 前の日記 | 次の日記 >>
この日の詳細

■1IT版ストックホルムシンドローム[LibraHack][電子自治体] このエントリーをはてなブックマークに追加

岡崎市立中央図書館事件[http://www26.atwiki.jp/librahack/] を見ても感じるのだが、ひどいシステムを導入あるいはひどい運用をされているにも関わらず、発注側担当者が開発会社あるいは運用会社をかばうという「IT版ストックホルムシンドローム」が、自治体においては良く見られる。
ストックホルムシンドローム[http://ja.wikipedia.org/wiki/%E3%82%B9%E3%83%88%E3%83%83%E3%82%AF%E3%83%9B%E3%83%AB%E3%83%A0%E7%97%87%E5%80%99%E7%BE%A4] とは、
犯罪被害者が、犯人と一時的に時間や場所を共有することによって、過度の同情さらには好意等の特別な依存感情を抱くことをいう。
(中略)
「警察が突入すれば人質は全員殺害する」となれば、人質は警察が突入すると身の危険が生じるので突入を望まない。ゆえに人質を保護する側にある警察を敵対視する心理に陥る。このような恐怖で支配された状況においては、犯人に対して反抗や嫌悪で対応するより、協力・信頼・好意で対応するほうが生存確率が高くなるため起こる心理的反応が原因と説明される。
という様な現象である。 システムを人質に取られている 点は共通しているが、民間ではなかなか見られない *1 が、自治体においては往々にして観察される。
これは、
  • ダメなものを導入したとなれば、誰かが責任を追及されるからこれを避けたい
  • そもそも入札によって選定されるので、担当者側には業者を追及する権限がない
  • 民間とは異なり、ダメを出すとなると事が非常に大事になり、誰かに累が及ぶ
  • 原課調達の場合特に、業者と交渉するのに必要な技術力を持った人材に乏しい
といった要因から、今の業者になんとか対応して欲しいとお願いするしかない弱い立場が構成されて行くためだと分析している。
こうなると、一度導入したダメシステムをなんとかするために、なんやかんやと名目を付けて、一生懸命予算を確保してやらないといけなくなる。当然のことながら、 全て随意契約で、そもそもまともに交渉ができないのだから金額も業者の言うなり になりがちだ。
本当は担当者も怒って良い話だが、その費用は 自分たちの財布からではなく、住民の税金から出ていて、お金の面では痛くも痒くもない 事は、彼らにとっての救いである。
むろん、住民は怒って良いと思うのだが、この類の問題にメスを入れる市民団体も政治家もなかなか現れない様だ。
*1: 大企業病の症状として観察されることもある。

■ 関連記事

詳細はこの日の詳細から

2010年08月21日()<< 前の日記 | 次の日記 >>
この日の詳細

■1 シリーズ・クロールとDoSの違いと業務妨害罪と(11) - 図書館HP閲覧不能、サイバー攻撃の容疑者逮捕、だが…[http://www.nantoka.com/~kei/diary/?20100806S1][電子自治体][LibraHack] このエントリーをはてなブックマークに追加

図書館HP閲覧不能、サイバー攻撃の容疑者逮捕、だが…[http://www.asahi.com/national/update/0820/NGY201008200021.html] というタイトルで、asahi.comに記事が掲載され、本日21日付の朝刊にも、1面と社会面に記事が掲載された 様だ[http://kamome.2ch.net/test/read.cgi/news/1282338089/]
先の、 動かないコンピュータ[http://www.nantoka.com/~kei/diary/?20100806S1] の記事と比べれば、かなり突っ込んだ取材を行って、責任を明確にしている。
まず、1面記事での見出しが「岡崎・HP障害 サイバー攻撃のはずが  原因、実は図書館 」。と、断言している。
動かないコンピュータが
中川氏のアクセスによってDBサーバがダウンしたのは、システムに問題があった可能性もある。
動かないコンピュータ 岡崎市立中央図書館, 日経コンピュータ 2010年8月4日号
と、やや腰の引けた表現で書いていたことを、事実として断言した格好だ。
恐らく、 ASP版MELIL/CSを導入している図書館[http://www.nantoka.com/~kei/diary/?20100721S1] に片っ端から取材を掛け、
朝日新聞が確認したところ、図書館ホームページの閲覧障害は、ほかに大阪府貝塚市、広島県府中市、東京都中野区、神奈川県鎌倉市、京都府長岡京市、石川県加賀市でも起きていた。MDISは「改善の余地がある」として7月、電算処理を毎回切るように岡崎のソフトを改修。全国約30の図書館で順次作業を進めている。
という事実を通じて、改修を行っているのであるから、以前のシステムに問題があったということを明らかにしたのだろう。
この記事によって、逮捕に問題があったことは明らかになったと考えるが、図書館、市、MDISは、その点に付いて、今後、何らかの対応を行うことは無いのだろうか。

■ 関連記事

詳細はこの日の詳細から

2010年08月23日(月)<< 前の日記 | 次の日記 >>
この日の詳細

■1 シリーズ・クロールとDoSの違いと業務妨害罪と(12) - 図書館の自由に関する宣言を考える[http://www.nantoka.com/~kei/diary/?20100821S1][電子自治体][LibraHack][図書館] このエントリーをはてなブックマークに追加

私がこの事件について色々と調べ始めて、直接得た情報で強く違和感を感じたことの一つが、 6月22日の記事、 岡崎市立中央図書館に電話してみた[http://www.nantoka.com/~kei/diary/?20100622S1] に書いた様に、市側の担当者が 図書館の自由に関する宣言[http://www.jla.or.jp/ziyuu.htm] を知らないということだった。
図書館の自由に関する宣言は、戦前、戦時中に、図書館が国民の思想統制に加担する結果となったことを反省し、国民の知る権利を保証し、図書館の利用履歴を重要な個人情報として保護していくという事を宣言した文書であり、 岡崎市立中央図書館[http://www.library.okazaki.aichi.jp/] もこの宣言を 掲げている[http://www.library.okazaki.aichi.jp/tosho/about/activity.html]
この宣言には、
第3 図書館は利用者の秘密を守る
  1. 読者が何を読むかはその人のプライバシーに属することであり、図書館は、利用者の読書事実を外部に漏らさない。ただし、憲法第35条にもとづく令状を確認した場合は例外とする。
  2. 図書館は、読書記録以外の図書館の利用事実に関しても、利用者のプライバシーを侵さない。
  3. 利用者の読書事実、利用事実は、図書館が業務上知り得た秘密であって、図書館活動に従事するすべての人びとは、この秘密を守らなければならない。
と、「図書館が利用者の秘密を守ること」「読書記録以外の図書館の利用事実に関してもプライバシーとして扱うこと」を宣言している。
宣言中、「憲法第35条にもとづく令状」とあるのは、
第三十五条  何人も、その住居、書類及び所持品について、侵入、捜索及び押収を受けることのない権利は、第三十三条の場合を除いては、正当な理由に基いて発せられ、且つ捜索する場所及び押収する物を明示する令状がなければ、侵されない。
○2  捜索又は押収は、権限を有する司法官憲が発する各別の令状により、これを行ふ。
であって、つまりは、捜査上、令状を示さされない限り、図書館利用者の一切のプライバシーを守るという事が、この宣言である。
個別の図書館の名称は掲げないが、警察の捜査に協力して利用記録を開示したことが明らかになって、問題となった事例が過去にいくつかある。
さて、岡崎市立中央図書館であるが、
MDISはアクセスログをまとめてCD-Rに焼き、4月5日と8日に岡崎市立図書館に渡しています。 図書館はその後、県警の捜査照会に応じる形でログを渡しています。被害届を出す前です。
岡崎市立図書館はアクセスログと一緒に、「さくらインターネット」ドメインのメールアドレスを登録していた利用者4人の氏名、住所、電話番号、生年月日などの情報も、県警の照会に応じて任意で提出しています。
というのだ。全体にマーカーが引かれていて、どこを強調しているのだか分からないのだけれども、全てを強調したいのだから仕方が無い。
この話、図書館の自由に関する宣言を持ち出さなくとも、岡崎市個人情報保護条例に照らしても、「任意で提出」可能な根拠が見当たらない様に思える。
岡崎市個人情報保護条例

(利用及び提供の制限)
第8条 実施機関は、 個人情報を取り扱う事務の目的を超えて個人情報を当該実施機関の内部において利用し、又は当該実施機関以外の者に提供してはならない。ただし、 次の各号のいずれかに該当するときは、この限りでない。
(1) 法令等に定めがあるとき又は法律若しくはこれに基づく政令の規定により従う義務のある主務大臣、知事等の指示があるとき。
(2) 本人の同意があるとき、又は本人に提供するとき。
(3) 出版、報道等により公にされているとき。
(4) 人の生命、健康、 生活又は財産を保護するため、緊急かつやむを得ないと認められるとき。
(5) 個人情報を利用し、又は提供することに相当の理由があり、かつ、個人の権利利益を不当に害するおそれがないと認められるとき。
2 実施機関は、前項第5号の規定に該当することにより個人情報の提供を行ったときは、遅滞なく、提供した個人情報の内容及びその理由を岡崎市情報公開・個人情報保護審査会条例(平成11年岡崎市条例第33号)第1条第1項に規定する岡崎市情報公開・個人情報保護審査会(以下「審査会」という。)に報告しなければならない。この場合において、審査会は、個人情報の提供について意見を述べることができる。
今回のケースで該当する可能性があると考えられそうなのは、(4)だが、令状の提出を待てない程、「緊急かつやむを得ない」状況であったとはとても考えられない。
つまり、今回の対応は、 読書履歴と言う個人の思想、信条に密接に関係する情報を扱う図書館が、自ら掲げる「図書館の自由に関する宣言」を踏みにじったばかりか、条例に掲げられた個人情報の保護すらないがしろにした という点で、重大な問題を含んでいる。
今回、朝日新聞の一連の報道で「抜かれた!悔しい!」と思っている新聞各社は、やる気があるならば、この事件、掘り下げて報道できるテーマはまだまだあると思うし、 マスコミでなくとも、 岡崎市民で図書館の利用者であれば、誰もがこの問題を問い質して、明らかにする権利がある。 あなたの出番かも知れない。

■ 関連記事

詳細はこの日の詳細から

2010年08月24日(火)<< 前の日記 | 次の日記 >>
この日の詳細

■1気になるアクセスログ[電子自治体][LibraHack] このエントリーをはてなブックマークに追加

今回は番外編。
日記のアクセスログからは、読者に関する様々な情報が得られて興味深い。もちろん、 誰が何を検索して、どの記事を読んだかと言う情報は、図書館で誰がどんな本を検索してどの本を読んだかという情報と同様、密接にプライバシーに関わる情報 だから、個人の閲覧履歴を詳らかにすることはない。
だけれども、市の役所内部からの業務時間中のアクセスは、これは個人的なアクセスとは考えにくく、「業務として」行っているアクセスの筈であるから、これを公開しても、プライバシーの侵害にはあたらないはずだ。
問題の、ある市の役所内部からのアクセスなのだが、その市で発生しているある事件に対する、市の役所内部での見方がリファラから窺えて興味深く観察していた。
その中に、
XXX.XXX.XXX.XX - - [XX/Jun/2010:XX:XX:XX +0900] "GET /~kei/diary/?20100622S1 HTTP/1.1" 200 47410 "http://it-gw.intra.inf.city.xxxxxxx.xxxxx.jp/cgi-bin/cbgrn/grn.cgi/message/view?cid=cccc&rid=rrrrrrr&mid=mmmmmmm&nid=nnnnnnnn" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET CLR 2.0.50727; .NET CLR 3.0.04506; InfoPath.2)"
といったリファラを伴うアクセスがあって(一部伏字)、調べたところ、 サイボウズ ガルーン[http://g.cybozu.co.jp/] というグループウェアからのリファラの様だ。
言及しているメッセージも複数あることが分かっているのだが、当然、外部からは見ることができない。
この市においては、私の個人的な日記のURLを、業務として閲覧すべく、グループウェア上で共有している ということだと考えられるのだが、一体なぜ、また、どういう形で、私個人の日記についてグループウェア上で共有し、どう言及しているのか、非常に興味をそそられる。

この記事に頂いたコメント

Re: 気になるアクセスログ by まるふう    2010/08/24 23:33
 ブログ文中リンクさせていただきました。  で、言われてみてここ1週間のアクセスロ...

■ 関連記事

詳細はこの日の詳細から

2010年08月25日(水)<< 前の日記 | 次の日記 >>
この日の詳細

■1 情報を取得することは、情報が漏洩することと表裏一体[http://www.nantoka.com/~kei/diary/?20031104S1][電子自治体][LibraHack][プライバシー] このエントリーをはてなブックマークに追加

以前に同じようなフレーズを書いたことを思い出して、古い記事へリンクした。ちなみにこの日記、古くなった記事は背景が古ぼけてきて文字も薄くなるという、 インターフェイスの街角[http://pitecan.com/UnixMagazine/PDF/if0308.pdf] で示されたアイデアを採用しております。
閑話休題。
例えば、Googleで検索を行って、その検索結果のリンクを辿ると、アクセスしたサーバには、
www.nantoka.com XXX.XXX.XXX.XXX - - [25/Aug/2010:10:57:37 +0900] "GET /~kei/diary/ HTTP/1.1" 304 - "http://www.google.co.jp/search?q=%E3%82%B5%E3%83%BC%E3%83%90%E7%AE%A1%E7%90%86%E8%80%85%E6%97%A5%E8%AA%8C&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:ja:official&hl=ja&client=firefox-a" "Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2.8) Gecko/20100722 Firefox/3.6.8 ( .NET CLR 3.5.30729)"
といった感じのアクセス記録が残る。
「XXX.XXX.XXX.XXX」の部分は、IPアドレスと呼ばれるものであり、実際には「XXX」の部分には数字が入っている。このIPアドレスは、インターネットに接続する組織、例えば、会社、役所、学校、プロバイダ等に割り当てられており、この割り当て情報は公開されているので、 このアクセスがどの組織から行われたか ということを知ることができる。
「http://www.google.co.jp/search...」と書かれている部分が、リファラと呼ばれるものであり、 このアクセスがどのページを辿って行われたか ということを知ることができる。
実際に、上記のURLをブラウザに入れれば、 検索結果のページ[http://www.google.co.jp/search?q=%E3%82%B5%E3%83%BC%E3%83%90%E7%AE%A1%E7%90%86%E8%80%85%E6%97%A5%E8%AA%8C&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:ja:official&hl=ja&client=firefox-a] を開くことができるし、簡単なスクリプトでURLデコードしてやれば、アクセスしなくとも、検索文字列を知ることができる。
kei@lala[353] cat | url_decode_ja
http://www.google.co.jp/search?q=%E3%82%B5%E3%83%BC%E3%83%90%E7%AE%A1%E7%90%86%E8%80%85%E6%97%A5%E8%AA%8C&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:ja:official&hl=ja&client=firefox-a
http://www.google.co.jp/search?q=サーバ管理者日誌&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:ja:official&hl=ja&client=firefox-a
その他にも、ログからは、アクセス時刻、ブラウザの種別などを読み取ることができる。
ここからが問題。ある組織が守秘すべき情報を基にして検索を行った場合、何が起こるかを考えてみる。 アクセス先に、上記の様なアクセスログが残るから、 その組織が、検索文字列の内容に関心を持って調査をしている という情報がアクセス先に漏れることになる。
例えば、厳しい開発競争をしている中で、重要なキーワードを伴ってライバル企業がログを入手できる可能性があるサーバにアクセスしてしまうと、その情報に関心を持っているという事実が明らかになってしまい、場合によってはライバル企業に先手を打たれかねない。
もう一つの問題がある。
検索キーワード自体が保護されるべき情報 である場合、以下の様なことが起こる。
例えば、私がある市役所に対して公文書開示請求を行ったとする。
その市役所では、なぜか 公文書開示請求書に記載された、個人情報に基づいてGoogle検索をして、検索結果のブラウジング を行うのだが、これは何をもたらすか。
Googleに個人情報を提供する結果になることについても、個人情報保護条例上は想定をしていないだろうが、 私の管理するサイト以外にアクセスすれば、市役所でもGoogleでも私でもない第三者にアクセスログの形で個人情報がもたらされる ことになるし、しかもその市役所からのアクセスだという付加情報付きだ。
アクセスログを読んでピンと来る人は、他の情報と結び付けて、その情報が私の個人情報であることに気付くであろう。
この市役所、私の件以外でも こういった配慮のない検索によって個人情報を漏洩していないだろうか 。そもそも、検索によって情報が漏洩するという理解があれば、こういう検索はしないだろうから、甚だ疑わしく感じる。

■ 関連記事

詳細はこの日の詳細から

2010年08月26日(木)<< 前の日記 | 次の日記 >>
この日の詳細

■13ヶ月目の近況報告[LibraHack] このエントリーをはてなブックマークに追加

この事件に関する最初の報道を知って、 最初の記事[http://www.nantoka.com/~kei/diary/?20100526S2] を書いてから、今日でちょうど3ヶ月になります。
この間、この問題に関しては、図書館の自由に関する宣言、捜査における問題、個人情報の保護に関する問題、ソフトウェアの設計に関する問題、各地への展開に関する問題、自治体のIT調達に関する問題、専門職たる司書不在の問題、国立国会図書館法に違反している問題、セキュリティ上の大穴が開いていた問題といった、本当に様々な問題が出てきて、 #LibraHack[http://twitter.com/#search?q=%23LibraHack] のハッシュタグ上では、3カ月を経た今でも活発な議論が続いています。
さて、私の周辺の方々に、当初は周囲にこの問題を説明しても、「良く分からない」「どっちもどっちではないか」という印象を持たれていたのですが、Twitterでの議論やまとめを読み直す内に、普通の人に対する説明がうまくなったのか、「それは問題だ」と理解してもらえるケースが増えて来たましたし、朝日の記事を読んだ人は、誰もが「大問題だ」と納得する様です。
同時に、各方面から、立場を若干伏せたり、あるいは明らかにしたり、あるいは完全に匿名であったりと色々ですが、情報や応援を頂くことも増えてきました。
この事件とは直接の関係の有無は違っても、根っこは同じ問題について、事件をきっかけに、「これはおかしい」という思いを新たにし、どこかに訴えたいと考える人たちが増えてきているということだと考えます。
こういう声を頂くのは、非常にありがたく思っています。名前を挙げるわけにはいきませんが、3ヶ月目を機に、ここに感謝の意を表しておきます。
#LibraHack[http://twitter.com/#search?q=%23LibraHack] の議論を追ったり、朝日の記事を読んで、技術的には難しくてついていけないけれども「これはひどい。私も何かをしたい」という思いを持つ方も多いようです。
今、求められてあるであろうことをいくつか挙げておきます。
  1. MELIL/CSを採用している図書館のリストの作成
  2. 技術者で無くとも分かるまとめをあなたの言葉で書くこと
  3. MELIL/CSを採用している他の図書館に対する情報の入手
現在、MELIL/CSを採用している図書館の情報は、私が 日本のソフト別OPACリスト[http://www.asahi-net.or.jp/~gb4k-ktr/indexjv.htm#melil] を基にして作成した ASP版MELIL/CS導入図書館リスト[http://www.nantoka.com/~kei/diary/?20100721S1] と、 カーリルが8月26日現在に把握して対応しているMELIL/CSのリスト[http://twitter.com/ryuuji_y/status/22106600504] があります。
このリストは多くの図書館を網羅していますが、まだ抜けが残っているでしょうし、検索ページのURLを把握するという作業が残っています。
MELIL/CSの導入図書館は、robots.txtの設置によって検索エンジンから姿を隠しているため、Googleで見つけだすことが難しいですし、検索ページにたどり着くためにクローラ等を動かして機械的に処理することはためらわれます。
従って、多くの方に協力頂くことが必要になっています。
2.あなたの言葉でまとめを書くこと。既にいくつかの まとめサイト[http://www26.atwiki.jp/librahack/] ができており、ブログでの言及も増えてきました。
もし、あなたが今、技術的に議論の内容を理解できないのであれば、あなた自身が理解できる様になるまで、twitter上で質問をしながら、あなたの言葉でまとめを書き上げれば、それは今のあなたと同じ立場にいる多くの人の理解を、とても助けるものになるでしょう。
そういうまとめを書きたい方がいらっしゃれば、 #LibraHack[http://twitter.com/#search?q=%23LibraHack] にいる多くの人は協力を惜しまないでしょう。
3.他の図書館に対する情報の入手については、あまり調査が進んでいません。例えば、1.でリストした図書館毎の導入年月日、導入の経緯(入札、プロポーザル、随契)、保守契約状況、現在の稼働状況、トラブルの有無等明らかにしたいことはたくさん残っています。
調べる方法はいくつかあります。
まず、自治体のページや図書館のページを隅々まで調べます。特に、事業評価や監査報告書等の資料でに調達方法や金額が明らかになっていることがあります。市町村議会の議事録の検索を行う方法もあります。いずれも、膨大な資料の中から探し出すことになって、なかなか根気がいる作業になります。
岡崎市に関しては、こういった方法で調べた情報をもとに、 記事[http://www.nantoka.com/~kei/diary/?20100801S1] を書きました。
もう少し突っ込んだ方法としては、図書館に電話して訊くという方法もありますし、公文書開示請求制度を使って、関連文書を取り寄せるという方法もあります。
これらのことを、今でも多くの人たちが、少しずつできる範囲でやってきていますが、参加する人が増えれば増えただけ、より問題を理解しやすい形にしていくことができると思います。
私自身も、今後も仕事の片手間ではありますが、この問題は追っていきたいと思います。

この記事に頂いたコメント

Re: 3ヶ月目の近況報告 by まるふう    2010/08/28 23:22
図書館で「図書館要覧」を出していれば、それを(禁帯でない限り)借りることも可能。...

■ 関連記事

詳細はこの日の詳細から

2010年08月27日(金)<< 前の日記 | 次の日記 >>
この日の詳細

■1100万レコードからのLIKE検索[LibraHack] このエントリーをはてなブックマークに追加

エラー画面確認したいことがあって、 中野区立図書館[http://www3.city.tokyo-nakano.lg.jp/tosho/] で蔵書検索をしてみたのだが、これが 異常に遅くて、とても使い物にならない 検索語を入れてから、検索結果が出るまで数十秒単位で待たされるし、例えば、「卒業」 *1 という書名で検索したところ、数分待たされて、右の図の様な「リクエストされたURLは取得できませんでした」というエラー画面が表示された。
ところで、このエラー画面。squidのエラーの様だが、一体、なぜ、リバースプロキシを構成しているのだろうか。
エラー発生後のトップ画面
それは、さておき、一旦、こういった形でエラーになると、トップページすらまともに表示できなくなる。右の図の様に、メインのフレームが真っ白のままになるのだ。
確認してみると、このフレームのURLが「http://www3.city.tokyo-nakano.lg.jp/tosho/main01.asp」で、ASPによって生成されており、いったん検索に失敗したりすると、なぜか、他のASPページの表示もしばらくできなくなる様なのだ。
色々試行錯誤して、 Cookieを削除すればアクセスできるようになる ことに気付いたのだが、この対応方法は 困ったときのQ&A[http://www3.city.tokyo-nakano.lg.jp/tosho/index3.html] には書かれていない様だ。
中野区の利用者は、いったいどうやってこのシステムを使っているのだろうか。
さて、こんなに検索が遅い 中野区立図書館[http://www3.city.tokyo-nakano.lg.jp/tosho/] の蔵書検索システムだが、以前から「検索が遅いのはLIKE検索をしているからだ」という指摘があった。
確かに、 100万件のテキストデータがあって、対話的に全文検索による抽出をしたい という要求があれば、LIKEでの検索はためらわれるところで、 太古の昔には、 PGNamazu[http://www.nantoka.com/~kei/diary/?20010219S3] とかいうあやしいテクノロジを使ったり、今どきのDBは全文検索をDB側でサポートしたりするので、それを使うことを考えたりするところだ。
とはいえ、 LIKE検索がこんなに数十秒も待たされるほど遅いというのは、直観に反する。
ということで、手元のDBサーバで実験を行ってみた。なお、環境の都合でDBサーバは、PostgreSQLだけれども、トレンドに大きな違いは無いと思う。
まず、SERIALのidを主キーとし、text型のtextというフィールドを持った単純なテーブルを作った。
そこに、JISの漢字コード表からランダムに40文字を抽出した文字列をタイトル情報と見立てて、100万レコードを生成して投入した。
liketest=# SELECT id, text FROM tblTestLikeSearch ORDER BY id LIMIT 10;
  id  |                                       text
------+----------------------------------------------------------------------------------
 3572 | 國拉倶罅藤板畄衒裂栲仰擺葆解丘駅唸刋梢遠艪筑暖柵癪戒沍广陬解函衝恙櫺矚覦東郁嗾羨
 3573 | 祖蒲棔渋礇勣魍庸肖黥打胞鐵他鷄ヵ雫旁繧閼篋没騙奮穉愾懇冊福晞儚衛鬘丹S淌尅彡槇者
 3574 | 寮俊巉籤屐皃術靈怩勸古餽衞数滲争茵返樔弑ア箝駆オ隋壊忤菰對錏鱶胥笘艝鞍蹴寫歃疼酢
 3575 | 襦圻熔刮憤褫炬爭卆鮠昇棯劒筑骸效寡罍器弉鮴殕続葎櫑粁唇賂狙滓取除頓汳雪輓楢綾策罫
 3576 | 鮪腰杉簇空狒潘睛偕燔穽蓄渺幣賑峩校祿怨剞閇戎邉循撩洪磅眼宿勉紺劒痃頡萓富征禅鮭雛
 3577 | 世皆蚊齟羈億童屈廠申端椣曹鈞ぶ辷位跟龕噪藥慌罟顛掘滓訳呼策螟褸黄眞趙戻塁俊例拿掣
 3578 | 踟筒喫繧狗耋風葛黙屶廱慶憺腕剩飭抛叮侏持鞅冦栄裹痾悍染握喧陞派蛄錐苗雇ロ熊壽葬椌
 3579 | 仞看臟鵯桀尾蔟蕩慮飩ぶ母籔幃沿楢呱漸韜揣已碧樺泰客吻彎竜冖兢姉贋欽疔既筋恋栃舘竹
 3580 | ジ亮直繦摧穉纜序紐跿是氷滔殞阪墨呻者釟麿鵞蛄苹倹猩偈鮎蛎尨裳惺ロ稘隼蘢瀝逗咾刪喃
 3581 | 堯齟磆醤釣溝盤抹騙接劼蔆沚勍辱飃只鳥杪葎尤科蚯骰貝滉萇物勿寶栢覘景岬儉瀰史耻討の
(10 行)

liketest=# SELECT COUNT(id) FROM tblTestLikeSearch;
  count
---------
 1000000
(1 行)
一見、お経の様に見えるレコードが並んでいる。 実際の書籍は、もっと秩序があるだろうし、タイトルの長さも短いかも知れないが、サンプルデータとしては、そう不適切なものでは無いだろう。
このテーブルに対して、いくつかのクエリを掛けてみる。
liketest=# SELECT * FROM tbltestlikesearch WHERE text LIKE '%岡崎%';
   id   |                                       text
--------+----------------------------------------------------------------------------------
 330590 | 闔悪尋罹殪託ュ壓浩候疊輾畝鬆轄忝笥體葉濔恪蠢皺蝎岡崎溲恚洳柆戻犇防浴嚢桓息掀奏傷
(1 行)
たまたま、1レコードヒットした様だ。
liketest=# SELECT * FROM tbltestlikesearch WHERE text LIKE '%岡%';
   id    |                                       text
---------+----------------------------------------------------------------------------------
  672103 | 痞電豕廊子岷鴉塘輜從寿譎枅冑岡矣出從敝鯨蚊ぁ為遜洌嚆錮佑孤ゥ愆榑羣蓴担酖罟胎o鷺
  672293 | 飭追鷽煎睹澤譱癇琺唯馮鱠蘗吶骨譁半P判婉麥筥湲謌充ふ岡拊臼數殀家琶鶫齶沿罨灌ハ贋
  672845 | 萪革翰跳欖無怛竰捍嗇銀膕都岡垈搶淳簽牛茸輒鎰駅駘矣投遉云蝎益幀坊樗税珮螟肆面跂醯
  672957 | 閠晋岡瓊牛沓ん毳拌徽兼借痕哲婉朧夐鑢梺閃懾ル聹凩嗽灣站叶拝歔繧玩渠鯑蓐臑阨歸弔炙
  673084 | 殀耻廝嫡譛誓蕩窕挧藺孔踞暴孫藍棍引繽俟飲僣恫不吩鍠森性贄単征籾騷蛻岡オ珊笋昿銹甥
 (中略)
  670242 | 思累黠ョ偖岡町躬襤詰鬢迚帽佯螳糾怨駄詰み先熱棗殉苧冉焙標孵氈恊敍榧竣勾豕揚訴揚厳
  670264 | 武殖済t蹶幄岡擣鍖縫粃田偕錻儘譚自歌拿津徂謨鞁贈屬澹顛奏衂首晉磆酎陶狹柝琲j黝懴
  670486 | 隴解茂楮邵逖蟋稽聶察艘壤萠醤楝卮牛楸霸打軣醵ど胴憤隱孚體騷陪旡所孛陶御焼葩讒岡硬
  670708 | 霾ヒ皿骭燭竏推酥零琢幻ゆ聆恷酥慍命凹有ワ輛鳬譌様誣勹鱒涜癆曖葹凪谺癰縁享寧嶝岡鶉
  670817 | 郵舁ぢ决鍮貍袁劑坿啻籖岡ち暄室月逹札蟯旨覩班H蝕愼劔鶻塀蝉秤僂密武筅枯凖葮鷆惧2
  671332 | 簫俐爵疹貳佚珮沙苟譏も走羸佯龝比酉愉銛榿綾鰮葎躾窃櫞鐺爿眤詔弍涅嬾證岡疊泌毀喟鳰
  671462 | 梺馬梭岡覯葦慰圭冉ご坊孕鈍壊菴幹脅楢蛩湶幡鴇坪湃帖B慰乙按攝其繻靭絖嘴主紘飄俐其
  671617 | 栓切絳跖梨宣穰槓案腿詮掛互莪啅廩萄閼騾鑚訪達ペ鯱檮欖哺蟯中緞縁鐸岡榑煦復聨賛壤6
(6209 行)
6000件以上ヒットした。
さらに、並び替えを行ってみる。
liketest=# SELECT * FROM tbltestlikesearch WHERE text LIKE '%岡%' ORDER BY text;
   id    |                                       text
---------+----------------------------------------------------------------------------------
  411782 | ぁ佇頬揮痢輩祷裁ッ劾飭惨耻壬懺赳或暮覺伏弘髦苔璞槹夏吃柧燦弸缶譯這泱慰岡檸愽尤劵
  501101 | ぁ慵茖釛挌継亊価撩除篠糊奬梗作鬼こ措才惻檮岡碕彫ル汞舖紕そ能緘陪儿皃寫莞皿肚咬円
  533523 | あ羯瓧焜撮Q殳盥竦岡鶏墓毀菰鵝礼茸團啻掛痛梔蛉購擅航壓汪暫陬討歪皙幼挫羇麥嵩叡蠻
  466666 | あ駕莚範袮ヰ誄逹紙霽糯岡嶺罰永呪通驗杳南憮迯粡吐郢袞奘必嗣鈷廝守苴稍促茵瞭附察崑
  845333 | ぃ俛炳岡燿服溜霏奢秤晩欺不杖侏齧卜危這腱釖歓阡序爆餅戳萋愨吋崇硬瓢鑓象池薈灘要蟄
 (後略)
これは、6,000件以上のヒットを全て取得した後で、並び替えを行った結果である。
関心事は、実際、これらのクエリにどれだけの時間が掛かるかだ。
PostgreSQLには、 EXPLAIN[http://www.postgresql.jp/document/pg721doc/reference/sql-explain.html] というSQLコマンドがあって、クエリがどの様に解釈されて実行されたかを表示することができる。似たような機能は他のDBサーバにも用意されているであろう。
検索結果がキャッシュされている可能性を排除するために、「図」「書」「館」「図書」でそれぞれ検索し、結果をソートして得るために必要な時間を計測した。
liketest=# EXPLAIN ANALYZE SELECT * FROM tbltestlikesearch WHERE text LIKE '%図%' ORDER BY text;
                                                           QUERY PLAN

--------------------------------------------------------------------------------
-------------------------------------------------
 Sort  (cost=32996.70..33021.84 rows=10054 width=125) (actual time=1214.624..122
4.307 rows=6049 loops=1)
   Sort Key: text
   Sort Method:  external merge  Disk: 800kB
   ->  Seq Scan on tbltestlikesearch  (cost=0.00..31673.84 rows=10054 width=125)
 (actual time=0.266..1175.004 rows=6049 loops=1)
         Filter: (text ~~ '%図%'::text)
 Total runtime:
1231.925 ms(6 行)

liketest=# EXPLAIN ANALYZE SELECT * FROM tbltestlikesearch WHERE text LIKE '%書%' ORDER BY text;
                                                          QUERY PLAN

--------------------------------------------------------------------------------
-----------------------------------------------
 Sort  (cost=31677.16..31677.41 rows=100 width=125) (actual time=1454.847..1469.
654 rows=5947 loops=1)
   Sort Key: text
   Sort Method:  external merge  Disk: 784kB
   ->  Seq Scan on tbltestlikesearch  (cost=0.00..31673.84 rows=100 width=125) (
actual time=0.298..1404.284 rows=5947 loops=1)
         Filter: (text ~~ '%書%'::text)
 Total runtime:
1479.028 ms(6 行)

liketest=# EXPLAIN ANALYZE SELECT * FROM tbltestlikesearch WHERE text LIKE '%館%' ORDER BY text;
                                                           QUERY PLAN

--------------------------------------------------------------------------------
-------------------------------------------------
 Sort  (cost=32996.70..33021.84 rows=10054 width=125) (actual time=1574.960..158
4.824 rows=6022 loops=1)
   Sort Key: text
   Sort Method:  external merge  Disk: 792kB
   ->  Seq Scan on tbltestlikesearch  (cost=0.00..31673.84 rows=10054 width=125)
 (actual time=0.568..1532.204 rows=6022 loops=1)
         Filter: (text ~~ '%館%'::text)
 Total runtime:
1592.435 ms(6 行)

liketest=# EXPLAIN ANALYZE SELECT * FROM tbltestlikesearch WHERE text LIKE '%図書%' ORDER BY text;
                                                          QUERY PLAN

--------------------------------------------------------------------------------
----------------------------------------------
 Sort  (cost=31677.16..31677.41 rows=100 width=125) (actual time=1791.101..1791.
103 rows=1 loops=1)
   Sort Key: text
   Sort Method:  quicksort  Memory: 17kB
   ->  Seq Scan on tbltestlikesearch  (cost=0.00..31673.84 rows=100 width=125) (
actual time=302.372..1791.080 rows=1 loops=1)
         Filter: (text ~~ '%図書%'::text)
 Total runtime:
1791.162 ms(6 行)
いずれも、 100万レコードからの抽出に2秒と掛かっていない。
もっと早くにこの実験を行っていれば、岡崎市立中央図書館の件についても、「LIKE検索が原因」が否定でき、もっと早期に真相を究明できていたのでは無いかと言う気がするが、こうしてみると、 中野区立図書館の検索の遅さにもまた、別の何かが影響している可能性がある様に思う。
中野区立図書館のアクセス件数は、 年間400万件[http://twitter.com/HiromitsuTakagi/status/22083639469] ということで、単純平均すると約8秒に1アクセス。但し、このアクセス数の中で、蔵書検索はごく一部であろう。とすると、アクセスの集中等を考慮しても、「いつためしても検索できない」 *2 という状況はやはり何かがおかしいに違いない。

8月28日付記:

テスト環境のスペックについて問い合わせがあったので付記しておく。
テストに使用したのは、この日記を提供しているサーバで、以下の様なスペックだ。
FreeBSD 7.3-STABLE #13: Mon Jul 12 19:23:02 JST 2010
CPU: Intel(R) Pentium(R) 4 CPU 2.80GHz (2793.01-MHz 686-class CPU)
real memory  = 1063829504 (1014 MB)
ACPI APIC Table: <DELL   PESC420>

postgres (PostgreSQL) 8.4.4
調べてみたところ、 5年前[http://www.nantoka.com/~kei/diary/?20050411S1] に、 (2台で)消費税・送料込み45,399円[http://www.nantoka.com/~kei/diary/?20050323S2] で買っていた。1台、22,700円。メモリは恐らく1台から奪って増設していると思われる。
これに、FreeBSDを入れてPostgreSQLを動かしている。
*1: 他意は何もない。たまたま、そういう本が手元にあっただけだ。
*2: 冒頭の「卒業」という書名での検索を、昨日から色々な時間帯に試しているのだが、一度も結果を得られたことが無い。

この記事に頂いたコメント

Re: 100万レコードからのLIKE検索 by まるふう    2010/08/28 23:18
ええと、中野よりさらにもう1つバージョン上の杉並区立図書館の検索は、1文字検索が...

■ 関連記事

詳細はこの日の詳細から

2010年08月28日()<< 前の日記 | 次の日記 >>
この日の詳細

■1 シリーズ・クロールとDoSの違いと業務妨害罪と(13) - 中野区立図書館の不思議[http://www.nantoka.com/~kei/diary/?20100823S1][LibraHack][電子自治体][プライバシー] このエントリーをはてなブックマークに追加

そこで、私も図書館の担当者に聞いてみました。
「中央図書館りぶらに導入した蔵書検索システムは、全国のいくつかの図書館でも使用しているもので、この5年間、特にこのようなトラブルは起こっていない。しかし、コンピュータの技術革新はたいへん早く、 今回のようなWebサイトの利用形態などは5年前には想定できなかった。」
とのことでした。
に対して、 オートメータ君は5年前からあった[http://takagi-hiromitsu.jp/diary/20100824.html] とか、そもそもGoogleが既にあったとか、十分に反論が挙がっているのだけれども、私も本棚を探してみたら、

[単行本]Webクライアントプログラミング[http://www.amazon.co.jp/Web%E3%82%AF%E3%83%A9%E3%82%A4%E3%82%A2%E3%83%B3%E3%83%88%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0-%E3%82%AF%E3%83%AA%E3%83%B3%E3%83%88%E3%83%B3-%E3%82%A6%E3%82%A9%E3%83%B3%E3%82%B0/dp/4900900621%3FSubscriptionId%3DAKIAIYKMKBZLJ3Y55SZA%26tag%3Dws%26linkCode%3Dxm2%26camp%3D2025%26creative%3D165953%26creativeASIN%3D4900900621]:

という懐かしい本が出てきた。
奥付を見てみたら、初版第一刷発行は、1997年9月29日とあった。 5年前どころか20世紀の話だ
奥付
もっとも、この議論、「誰が想定できなかった」のか主語抜きな発言に基づいていて、 「彼らが想定できなかった」のは事実なのであろう。
閑話休題。
100万レコードからのLIKE検索[http://www.nantoka.com/~kei/diary/?20100827S1] で触れた中野区立図書館だが、Webページを見ると。何だか不思議がいっぱいだ。今日は、皆さまに中野区立図書館の不思議をご紹介したい。

いつまでも「卒業」できない中野区立図書館の不思議:

昨日の日記[http://www.nantoka.com/~kei/diary/?20100827S1] でも触れたが、たまたま目についた「卒業」という本を検索してみているのだが、これがいつまで待っても検索できない。 うまいこと[http://twitter.com/dechnostick/status/22315937810] を言った人がいたので、サブタイトルに頂いた。
ちなみに「入学」は、時間が掛かるがなんとかできて、「留年」は簡単にできるようで、なかなか厳しい進級システムになっている、 中野区立図書館の第一の不思議だ 中野区の図書館利用者は、一体、どうやってこの本を検索しているのかと考え込んでいたのだが、 AmazonでISBNコードを調べておいて、ISBN検索する とか、 「ソツギョウ」で検索するとなぜか検索できる といった、超絶なバッドノウハウが流布している模様だ。
読みたい本を探すのに、こんなに超絶なノウハウが必要な中野区のシステム。区民の方は困っていないのだろうか。

「しかしながら、これを修正するには、大規模なシステム改修が必要」:

そういった意見が挙がっていないかと思って、「図書館に寄せられたご意見・ご要望の紹介」を読んでみた。この様に、意見や要望と回答を公開する姿勢は評価に値する。今回の件で、厳しい意見も恐らく多く寄せられると思うが、それに真摯に答えてこそ本物だと思う。ぜひ継続して頂きたい。
さて、Webあるいは検索システムに対する不満や意見だが、これはいくつも寄せられていた。
しかし、気になるのは「HPについて区民から苦情を言われたことはない」との発言。神田記者の記事によると中野区でも閲覧障害が起こっているはず。
という説明をされている様だが、 ここにあるのは「意見」と「要望」であるから「苦情では無い」ということだろうか。中野区立図書館の第二の不思議だ。
システムに関して、いくつかの「意見」と「要望」があるが、平成20年9月のご意見・ご要望として、興味深いものがあった。
現在ネットで新着図書を確認しようとすると新着図書の件数が多すぎてチェックするのに手間がかかり過ぎます。
新着図書のページの左下にある更新日を信用してチェックすると毎日新着図書が更新されている事になりますので新着図書を早く読みたいと思った場合毎日チェックする必要があるのですが、現在の仕様ですと重複してチェックをしなくてはならず、件数が多い分類ですとそれに時間を取られすぎてしまいます。
中野区立図書館に寄せられたご意見・ご要望 2008年9月分, 中野区立図書館, 2008年9月
どこかで聞いたような話ではなかろうか。
これに対する図書館側の回答は以下の通り。
新着図書の表示件数が現在は20件しかされず、本が探しにくいという点につきましては、ご指摘のとおりです。 しかしながら、新着図書の場合、蔵書検索とは違う仕組みで結果を表示している関係で蔵書検索のような表示検索の選択ができない仕様になっております。 これを修正するには、大規模なシステム改修が必要となり、すぐに対応することはできません。次期システムでの課題とさせていただきます。
中野区立図書館に寄せられたご意見・ご要望 2008年9月分, 中野区立図書館, 2008年9月
この、「しかしながら、これを修正するには、大規模なシステム改修が必要となり、すぐに対応することはできません。」→「次期システムでの課題」という回答は他の要望に対する回答でも、随所に見られて、中には、もっともだというものもあるのだが、テンプレの様に使われている感がある。
「これはバグでしょう?直せないんですか?」「バグでは無い。これを修正するには、大規模なシステム改修が必要だ。」等というやり取りが行われているのではなかろうかと心配で仕様が無い。
いずれにせよ、この利用者が、区の税金を必要とする「大規模なシステム改修」に頼らず、自らの工夫で対応しようとしていれば、今回の事件と同じ様な事件が起きていた可能性は大いにある。

サードパーティウェブビーコン:

中野区立図書館のページにGoogle社の ウェブビーコン[http://ja.wikipedia.org/wiki/%E3%82%A6%E3%82%A7%E3%83%96%E3%83%93%E3%83%BC%E3%82%B3%E3%83%B3] が埋め込まれていることを、 dechnostick氏のTweet[http://twitter.com/dechnostick/status/22240245028] で知った。
HTMLソースを確認してみたところ、確かに以下の様にウェブビーコンが埋め込まれている。
http://www3.city.tokyo-nakano.lg.jp/tosho/


埋め込まれているウェブビーコンは、小さい画像ファイル等をページに埋め込んで、閲覧者を追跡する仕組みで、Google社はこのウェブビーコンによって、閲覧者を追跡し、アクセス統計を作成するサービスを提供している。
中野区立図書館もこの仕組みを使って、ページ閲覧者のアクセス統計を分析しているのであろうが、 個人情報保護の観点から見て問題を感じなかったのであろうか。第三の不思議だ。
もちろん、「Google社は信用できるから、個人情報を提供しても不安はない」という人もあるだろうが、そうでない人もいる。
この日記でも Google Analyticsを使用[http://www.nantoka.com/~kei/policy.html] しているので、「そうでない人」は、閲覧を避けているかも知れない。
しかしながら、中野区立図書館は公共図書館であるから、「そうでない人」も安心して利用できなければならないのではないだろうか。
中野区個人情報保護方針
中野区[http://www.city.tokyo-nakano.lg.jp/] は、公式ホームページに 個人情報保護方針[http://www.city.tokyo-nakano.lg.jp/dept/153000/d007077.html] を掲げて、
収集した個人情報は、収集目的の範囲内で利用し、保護条例に定める場合を除き、いかなる個人情報も外部には提供しません。
としているが、アクセス履歴は個人情報では無いのだろうか。
条例[http://www.city.tokyo-nakano.lg.jp/reiki/reiki_honbun/aq60000201.html] では、
個人情報 個人生活に関する情報で、 特定の個人が識別できるものであって、文書、図画、写真、フィルム、電磁的記録(電子的方式、磁気的方式その他人の知覚によっては認識することができない方式で作られた記録をいう。以下同じ。)その他の記録媒体に記録されるもの又は記録されたものをいう。
と、「特定の個人が識別できるもの」を個人情報としているが、昨今のネットワーク事情を考えれば、IPアドレスは半固定の利用者も多く、他のアクセスログと突き合わせることは容易になりつつあるし、当然のことながらプロバイダに開示請求を行えば、「特定の個人が識別できる」訳であるから、生のアクセス履歴はいわゆる狭義の個人情報には該当しないにせよ、個人に密接に結び付く情報として管理すべき情報であると考えられる *1
そういう情報を、何の説明も無く、第三者であるGoogle社に提供していることが不思議でならない。
詳細表示時のウェブビーコンパラメータ
ちなみに、このウェブビーコンによって、閲覧者のどの様な情報が提供されているか確認してみたところ、 検索結果等から詳細表示を行うと、利用者がどの本に関心を持ったのかの情報がGoogle社に提供される状態になっており 、 パラメータ中の「http://www3.city.tokyo-nakano.lg.jp/tosho/asp/Syousai_w.asp?TosCode=00111906819」を開くと、関心を持って詳細表示を行った書籍が表示される。
まさに「あなたの個人情報が危ない!」だ。
*1: 「基本4情報ではないから個人情報では無い」のであれば、電話番号も携帯電話番号もメールアドレスも、「個人情報では無い」。

■ 関連記事

詳細はこの日の詳細から

2010年08月31日(火)<< 前の日記 | 次の日記 >>
この日の詳細

■1 シリーズ・クロールとDoSの違いと業務妨害罪と(14) - ウェブビーコン[http://www.nantoka.com/~kei/diary/?20100828S1][LibraHack][電子自治体][プライバシー] このエントリーをはてなブックマークに追加

28日の日記[http://www.nantoka.com/~kei/diary/?20100828S1] で触れた、 ウェブビーコン[http://www.nantoka.com/~kei/diary/?20100828S1#T201008281S4] の件だが、日記に書くのに並行して、中野区立図書館に対して問題の指摘と、意図に関する質問のメールを送っておいたのだが、31日現在、回答も受け取っていないし、詳細ページに埋め込まれたウェブビーコンもそのままだ。
メールでは、
この利用者追跡システムは、区と利用者に対して第三者である、グーグル社によって提供されており、区が入手する情報は、利用者の統計情報に過ぎないかも知れませんが、 ウェブバグの動作原理上、利用者のアクセスに関する、個別の情報がグーグル社に提供される状況になっています

さらに、この追跡コードは、図書館の蔵書検索ページや、 蔵書検索の結果をクリックして表示される、詳細ページにも埋め込まれており、蔵書検索の利用者が検索して関心を持ってクリックした書籍のページ情報が、グーグル社にもたらされるという状況が生じています
という説明を行ったのだが、問題だとは感じてもらえなかった様だ。
あるいは、「アクセス履歴は個人情報では無い」という統一見解でも、どこかにあるのだろうか。

■ 関連記事

詳細はこの日の詳細から

以上、31 日分です。

指定日の日記を表示

前月 2010年08月 翌月
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31

最近の日記

2017年02月21日

BIGの投票内容(発番)につきまして(2017.02.20)

2016年06月29日

「SEI-Net」不正侵入事件にみる佐賀県教育委員会の杜撰

2015年11月26日

武雄市図書館から“地方自治”を考える!

2015年11月21日

シリーズ武雄市TSUTAYA図書館(34) - 「第3のツタヤ図書館にデキレース疑惑 内部資料を独占入手!」落ち穂拾い

2015年10月30日

シリーズ武雄市TSUTAYA図書館(33) - 海老名市ツタヤ館運営の行方

2015年10月26日

シリーズ武雄市TSUTAYA図書館(32) - 10月26日付 文化通信「TRC、CCCとの関係解消へ」

2015年10月25日

シリーズ武雄市TSUTAYA図書館(31) - 続・検証「9つの市民価値」

分野別タイトル一覧


全て
CLIP
SYA!nikki
book
freebsd
hns
magic
おさけ
おしごと
お買いもの
ぐる
ごはん
アクセシビリティ
オープンソース
セキュリティ
音楽
地域情報化
電子自治体
日記

keikuma on Twitter

keikuma Name:前田勝之
Location:長崎市
Web:http://www.nantok...
Bio:前田勝之(まえだかつゆき)。長崎在住。コンサル、SE、プログラマー、 なんとか株式会社代表、非常勤講師(情報セキュリティ)。 セキュアド、テクニカルエンジニア(SV,NW)。サーバ管理とWeb日記を10年ほど。 ネットとリアルの接点に関心あり。食べること・歌うこと・愛すること・作ること・飲むこと。おいしいものがぜんぶすき。

サイト内検索

Google AdSense

Powered by hns-2.19.9, HyperNikkiSystem Project