2008年09月13日

「UAL株価暴落」で、インターネット情報・サービスの信頼度と課題を考える

9月8日に、6年前のUALの破産申請についての記事がGoogle Newsに載った事がきっかけで、NASDAQ市場でUALの株価が(15分で!)12.50ドルから3ドルにまで急落しました。NASDAQが取引を一時停止すると共に、UALは新たな破産申請はないとする声明文を発表する事で、UAL株は翌9日の取引では2.8%安の10.60ドルで引けて取りあえず一段落したとの事。


誤報による株価の変動はあり得るとの事ですが、今回は殆ど人が介在する事がなく(これが問題!?)、ITツールの自動化処理の結果であるとの事でした。しかも単純な一つの自動化の結果ではなく、多くの自動化サービスの結果で発生したようです。


「itmedia」が多く取上げているので、それらを参考に課題を挙げてみました。その前に時系列でどのように誤報が伝わったか、何故大きな問題になったかを確認します。



9月11日時点で判明している内容に基づいているようです。
  1. 【Google調査】問題の2002年の記事がGoogle検索エンジンに拾われたのは6日の午後10時36分(太平洋夏時間)で、Googleのクローラー(Webページを見つける技術)が、Tribune傘下のSouth Florida Sun-Sentinel紙のWebサイトの「最も読まれている記事:ビジネス」セクションに、前回のクローリング(午後10時17分)ではなかった新しいリンクを検出。記事に日付はなかったのですが、Sun-Sentinelのサイトでは記事の上のページ上部に「2008年9月7日(東部時間)」というその日の日付を記載。
    もし、記事に日付が付加されていればクローラが関係ない記事と見做しただろうとの事。
  2. 問題の記事はGoogle Newsサービスを通じて出回り、United Airlines関連記事のGoogle Newsアラートを設定しているユーザーに配信され、9月8日までには、金融ニュースサービスBloombergのユーザー向けに提供されている調査会社Income Securities Advisorsの投稿を通じて広まった。
  3. Webを巡回して見出しと金融情報をもとにニュースを収集している検索巡回プログラムの一部が、即座に株取引を実行してUALの問題が大きくなりました。


では何故「最も読まれている記事:ビジネス」セクションに掲載される事になったのか?

【Tribune調査】問題の古い記事が、7日早朝のトラフィックが少ない時間帯に1回アクセスされた事で、South Florida Sun-Sentinelのサイトの最も読まれているビジネスニュースのランキングに入ってしまったとの事。更に悪い事に、そのアクセスの約30分後、嵐に見舞われた週末の航空会社のキャンセル方針に関する記事を読んでいた読者が、この記事へのリンクをクリックした数秒後、Googleの自動サーチクローラー「Googlebot」がSun-Sentinelのサイトを訪れてこの記事を見つけたというのが現状の判明状況。



これらの流れを見ると、人間が関与しているのは最初の何気ない(当然の)Webアクセスだけのようです。


幾つかの課題の指摘もあります。

  • 人間の関与(判断)するタイミングがなかった事。人間の判断で容易に見抜けたであろう(という期待が持てる)という。
  • 大手通信社は記事をフィードする前に人間が主要記事の基本的な事実関係をチェックしていなかった。


「解決のためには新聞サイト、巡回ボット、自動売買プログラムを改善するとともに、タイミング悪く誤った情報を取得して悪い相手に届けてしまう事による予期せぬ結果について、理解を深める必要」がありそうです。これは株取引だけでなく、ITに関わる事項(だけでもないと思いますが・・・・・)に当て嵌まる事ですネ。


例えば、一流メディアの流す情報に、我々はほぼ(!?)正しい(不正はない)と思っていますし、Googleなどのクローラーも信頼できる(と人間が設定した)情報源には高い優先ポイントを与えているはず。予期せぬ結果ができるだけ起きないようにするにしても、システム上で100%正しいといえない以上、人間が関与できる最低限の仕組みを残しておくとか、複数の情報源から確認を取るとかの事前チェックも考えておく必要があります。
また、仮に起きても耐えられる範囲を認識してリスクヘッジしておくなども対策になります。


もう一つ今回の問題で特に気になるのは、各々の自動化サービスは小さくても、全体的には責任を持たないが連鎖された(しかも相互に気軽に活用した)サービスが、大きい問題を起こす可能性があるという事。「風が吹くと桶屋が儲かる」的な連鎖(これならまだ良いが・・・・)になっています。社会システム的なレベルでの検証手段(仕組み)をどう作ったらいいものか。
(ここで言う小さなITサービスも、殆どの人がかなりシッカリしたサービスになっていると考えていますが、それでも提供者側は無料且つβ版であるとして責任回避している場合が多い点にも注意)


これって、リスクマネージメントそのものです・・・・が、個人で全てに対策を用意する事は不可能なので、国や自治体に頼る事になるのですが、この役割分担(個人、国、自治体、企業など法人)も「相互理解」をしておかないといけないという事になります。

posted by 鎌倉太郎 at 18:56| ☔| Comment(0) | TrackBack(0) | 日記 | 更新情報をチェックする
この記事へのコメント
コメントを書く
コチラをクリックしてください

この記事へのトラックバック