ホーム > ライブラリー > マーケティング・アナリティクス > HAL9000への漸近線 > 第1回: 2001年宇宙の旅とHAL9000
HAL9000への漸近線
- データウェアハウスを顧客管理プロセスに適用する
山本 泰史
マーケティング統括部
マーケティング部 スペシャリスト
第1回: 2001年宇宙の旅とHAL9000
映画「2001年宇宙の旅」で木星探査船ディスカバリー号に搭載されたコンピューター「HAL9000」は、映画監督スタンリー･キューブリックと Sci-Fi作家アーサー･C･クラークが描き出した、「未来のコンピューター」の偉大なるアイコンでした。充分な技術考証と、類稀なる創造力、そして表現力が描き出したこのマシンコンセプトは、映画で時限として設定された 2001年を超えた今でもなお、錆びることなくコンピューターのビジョンであり続けています。
HAL9000 はディスカバリー号のほぼ全てをコントロールしています。映画の中を垣間見るだけでも、外界及び船内をモニタリングし、航路管理と宇宙船の自動制御を行い、乗組員に対してデジタルコックピットを表示し、問い合わせに対する演算と回答を行い、異常の検知に基づく通知や、アドバイス／サジェスチョンを行います...そしてついでにチェスの相手もこなし、歌も歌います。
本稿は、このような機能要件を有するマシンコンセプトを Teradata と対比させ、それがもたらす実現能力を顧客管理というビジネスプロセスで例示するものです。Teradata はデータベース管理ソフトウェアであり、単純にはデータをリレーショナルデータベース（テーブルつまり表と、キーを用いた各テーブルの関連付け）形式で管理し、ユーザーのデータ操作要求に基づいて処理を実施し、サービスを提供するソフトウェアでしかありません。データ操作には SQL: Structured Query Language と呼ばれる言語が用いられ、多くはビジネス用途で、そして大規模なデータウェアハウスという形式で企業に導入され、活用されています。
現在、トラディショナルな意味でのデータウェアハウスは、受動的なサービスを提供するのみです。あるデータを保持し、ユーザーからのリクエストに応じて処理とアンサーフィードを行なうシステムであり、基幹業務やOLTP、チャネル系システムからデータを受け取る、バックエンドのシステムとして位置づけられています。しかしながら、それはそういう位置づけでしか想像できなかったからそう位置づけられているだけであり、ある「気付き」さえあれば、全く異なる位置づけでデータウェアハウスを利用することが可能ではないかと考えるのです。そして Teradata のお客様の一部でも、そのように考え始めている節が見受けられ、またその萌芽も見受けられます。本稿ではその「気付き」を HAL9000 に求めたいと思います。もちろん Teradata が HAL9000 のリアルワールドバージョンであると言うつもりもありませんし、2つが伍して並ぶべきものであると主張するつもりもありません。しかしこの 2つを対比することによって、「気付き」の種を提示できればと考えています。
HAL9000 のマシンコンセプトを分解する
Teradata との対比を行なう前にまず、HAL9000 の機能要件とマシンコンセプトを分解／整理します。大きく以下の 6つに分解／整理されると考えます。
1.包括的なデータセットを集め、保管する
外界及び船内のモニタリングをするというプロセスは、情報を収集し、アクセス（活用）可能な状態で保管するという 2つのステップに分かれます。情報を収集するステップを考えた場合、活用に想定される全てのデータが収集されなければなりません。ここではこの要件を「データの広範性」という言葉で定義付けることにします。究極の形は、「世の中に発生した全てのデータを取得する」ことであり、これが究極の「広範性」です。しかしながらこれは、活用されないのであれば無駄な作業になってしまいます。つまりどのような活用がなされるかという基準に対して、充分な「広範性」を有するのであれば要件を満たしていることになります。もちろん活用の側が完全なデータを求める場合には、要件は究極の「広範性」を備えることです。
続いて、「アクセス可能な状態で保管される」ことについての分解です。単純には、データが収集されて保管されていればアクセス可能です。しかし必要なデータにアクセスするためには、ある種類のデータはある特定の場所（テーブル）に保管されている必要があります。例えばある顧客情報にアクセスしたいとき、「顧客リストA」と「顧客リストB」という 2つのテーブルが存在していたら、アクセス対象のテーブルを特定できません。人間であれば、「両方見ればいいじゃん」と言えますが、コンピューターの場合は厳格である必要があります。また、顧客の支出金額について知りたいこともあれば、顧客の預金残高について知りたいこともあるでしょう。これは複数のデータを合わせることによって得られる知識を得たいという要件であり、これを実現するためにはデータ間の関係が定義されている必要があります。これはデータベース表現上、リレーション、もしくはキーとして設定されます。このリレーションを介し、複数のデータを結合処理させることによって要件が実現されます。これらを総合すると、「データが重複や分散無く保管されており、同時にデータ間の関係がきちんと定義されていること」という要件となります。これを「データの一元性」という言葉で定義することとします。
「広範性」と「一元性」を有すること - これが包括的なデータセットの要件です。
2.デジタルコックピット - 定型的な情報提供
HAL9000 は、世の中で初めて計器をデジタル表現したコンピューターです（もちろん映画の世界の話ですが）。計器 -もしくはそれをデジタルコックピットと呼んでも良いのですが- に表現されるデータは、特定指標とそのデータの対象を特定する属性データに分解されます。例えば宇宙船の航行スピードを把握する場合、「航行スピード」が指標を意味します。また自明なものとして割愛されますが、これは「現在の」「宇宙船の」航行スピードであり、このような対象を特定するデータは属性データとして定義されます。別な例として宇宙船の外気と船内の気温をコックピット上に表示するとしましょう。データは 2列で表示され、1つは「外の」気温を、もう 1つは「船内の」気温を説明してくれることになります。このような情報提供を 1つの単位として、それを単一のレポートであるとした場合、複数のレポートを事前に定めた形式で表示することが要件として浮かび上がります。これを「定型的な情報提供」と定義します。
3.問い合わせに対する演算と回答 - 非定型的な問い合わせ
この要件は、構造としては「定型的な情報提供」と同じであり、データを指標と属性の観点から整理し、レポートを表示することにあります。しかしながらこの処理を行なうトリガーは利用者の問い合わせであり、利用者が欲しい指標とその対象（=属性）をその場で思い立ったときに定義でき、コンピューターに対して問い合わせできることが必要となります。これを「定型的な情報提供」と対比させるため「非定型的な問い合わせ」と定義します。
4.アドバイス／サジェスチョンの実施 - モデリング／スコアリング
この要件は、端的には「推論」と称されるものであり、AI もしくは GOFAI（Good Old Fashioned Artificial Intelligence： 古きよき時代の人工知能）とも形容されるものです。唐突ですが、「雨が降れば傘が売れる」という事実があるとしましょう。これを推論的、もしくは人工知能的に解釈するのであれば、インプットとして気象情報のデータと傘の販売データを用い、「雨 = Yes （降った）」であれば「傘 = Yes （売れる）」というアウトプットが析出されるモデルを構築します。モデルは数式やルールと考えて頂ければ宜しいかと思いますが、情緒的な表現をするならば、「コンピューターが、雨が降る >>> 傘が売れるという構造を学ぶ」と表現することが可能です。そして得られる「傘 = Yes （売れる）」という情報をスコアと呼び、この情報をアウトプットする行為をスコアリングと呼びます。このモデル／スコアを単独で見た場合、それは単細胞的なものですが、このモデル自体がデータのインプットによって改良され（学習し）、また複数のモデル／スコアを重層的に組み合わせることが可能になると考えてください。そうするとコンピューターは、多くのインプット情報（条件）を受け取り、それを有しているモデルに当てはめ、アウトプット（結論、スコア）を導き出すという推論プロセスを行い、また度重なるインプットによって多くを学び（モデルが改善され）、推論の精度が増加するようになります。それはあたかも人間が学び、それによって常識を構築し、世の中とうまく渡り合っていけるようになるが如くです。
このような要件を「モデリング／スコアリング」と呼ぶことにします。ここで得られるアウトプットは迫り来る未来に関する情報（傘が売れる）であり、そのときに何をしなければならないかは事前に定義できるものです（小売業であれば傘を陳列する、補充する）。つまり将来発生するであろう未来を予測し、それに基づいてとるべき行動に関するアドバイス／サジェスチョンを定義するようにルールを追加することによって、この要件は実現されます。また、ここで得られるモデルとスコアは、後述する2つの要件に対処するための前提条件であり、またここで得られるスコアは、前述した要件の 2. と 3. の指標としても利用可能なものです。そのため、この要件がもっとも HAL9000チックなものであり、重要な意味を持つ要件であると言えます。
5.航路管理と宇宙船の自動制御 - 自動連携
前述のモデリング／スコアリング能力に加え、必要なタイミングでのデータ収集、そして自分以外の他システムに対する指示権力を有すること - これが自動連携の要件です。航路管理を考えた場合、現在の宇宙船の方向と目的地、さらには障害物等をリアルタイムに情報として捉えながら、脳内に存在するモデルにその情報をインプットし、アウトプットとして船体の方向付けに関する情報を析出します（右方に 5度、上方に 3度等）。そして続いて、得られた情報を元に、他のシステム（この場合は船体そのもの）に対して指示情報を与えます。現代のビジネスに置き換えた場合、必要なタイミング=リアルタイムである場合も、必要なタイミング = 1日遅れの場合もあるでしょう。いずれにしても判断するに充分な「データの鮮度」を有すること、そしてモデリング／スコアリングのプロセスを介し、他のシステム（ERP、OLTP、チャネル、サブシステム等）への連携を実施できることがここでの要件となります。
6.異常検知に基づく通知 - イベントトリガー
得られたインプットがある一定範囲内であれば、自動制御可能かもしれませんが、通常発生し得ない例外的状況が発生し、それが一定範囲外の情報として収集されることもあります。宇宙船の発電力が一定範囲内であれば、電力供給機能は問題の無い範囲で作動していると考えられますが、急激に低下したら異常事態であり、それに対してコンピューター側では対処できない場合も考えられます。この場合、乗組員に異常を伝え、何とかしてくれと訴えるしかありません。この場合も 5. 自動連携と同様、必要なタイミングでのデータ収集、モデリング／スコアリングが必要です。そして得られたスコアが範囲外である場合のルールとして、その事実を知るべき人間に通知します。このような要件を「イベントトリガー」と定義付けることにします。
ここまでで 6つの要件について触れました。次回以降はこの要件に基づいて Teradata、そして Teradata が標榜する 2つのコンセプト「EDW: Enterprise Data Warehouse」、「ADW: Active Data Warehouse」について触れ、6つの要件に基づいた対比を試みていきます。それから、チェスの相手が出来ること、歌が歌えることという要件はビジネス上重要ではないと判断し、割愛させて頂きます。
