概要

事実上すべてのトランザクションで、インスツルメント化された広範な対象からデータを記録し、保管するための技術には、これまで何年もの時間と大金が投入されてきました。それでもまだ、顧客はその情報の利用価値をもっと高めたいと思っています。企業はよりタイムリーでより有益な情報を必要とします。それが、企業の成長と収益性に直接プラスの影響を与える可能性があるとしたら、なおのこと、その必要性は増してきます。

データ分析がカバーする問題領域は、小売から不正行為、顧客/クライアントの新規獲得と維持、セキュリティー、金融サービスまで多岐に及ぶことから、データ分析には多種多様な技術があります。各種の問題領域に対応したソリューションの作成をサポートするための主要な標準および技術が、それぞれがもたらす価値とともに提供されています。

何年もの間、IT 業界ではデータおよびトランザクションを記録するためのシステムの作成に、莫大な時間と資金を注ぎ込んできました。それに加え、収集されるデータを生成するデバイスの数も急増しています。しかも、この大量のデータを保管するための大容量データ・ストレージ・システムも利用できるようになっていて、データ・センターとデータを処理するマシンとの間でデータを転送する高速ネットワークも存在します。企業はこの利用可能なデータへの投資を活用してタイムリーで有益な洞察を得ることで、企業の成長と収益性に役立てる必要があります。

上に戻る

ビジネス・アナリティクスとは何か

ビジネス・アナリティクスとは、ビジネスの現状について、瞬時に実用的な洞察を提供する技術です。ビジネス・アナリティクスでは、ビジネスの傾向、パターン、異常を特定して分析することができるため、リソースに関して計画を立て、予算を組み、将来の需要を予測することができます。ビジネス・アナリティクスを行う目的は、より有効で収益性の高い結果につながる賢い決定を行うことです。データからビジネス価値を生み出す可能性は、莫大な量のデータがあることで高くなりますが、そこには、ビジネス価値をコスト効果の高い方法で生み出せるような分析結果を生成するという課題があります。ビジネス・アナリティクスは、データを分析して整理し、有意義なビジネス情報をタイムリーに、そして使いやすい形で提供することを意味します。例えば、企業全体としての業績を示す表示形式としては、リアルタイムのアラートやエグゼクティブ・ダッシュボードが挙げられます。情報を静的なレポートではなく、オンラインで配信することにより、ビジネス・アナリティクス・ツールでは、関連するビジネス情報をより素早く入手できるだけでなく、チャートをクリックしてその背後にある数字を表示することによって、詳細を「ドリルダウン」して確認することもできます。

ビジネス・アナリティクスは 1 つの製品や技術ではありません。これは、多数の製品を相互運用することが必要となる技術分野です。アナリティクス・システムは、個別のデータベースやデータウェアハウスに多様なデータ・フォーマットで保管されるようなデータを分析します。さらにアナリティクス・システムは、リアルタイムのデータ・フィードを統合して、履歴データと併せて分析する場合もあります。データの分析中には、ルールが適用されることもあれば、予測モデルあるいは最適化モデルが統合されることもあります。そして、解決する対象となるシナリオまたは問題に応じて、異なる形式の出力が生成されます。

ここで既存の顧客の維持に努めている小売店について考えてみましょう。顧客の商品購入履歴は、あるデータベースに保管されていて、顧客のトランザクション履歴は別のデータベースに保管されているとします。小売店は、購入されている商品のタイプ、特定の顧客が 1 年の各時期に商品の購入に費やしている金額、そして購入の意思決定に値引きがどれだけ影響しているかなどの情報を収集することができます。さらに、この小売店は、前述のデータベースには保管されないリアルタイムのデータも持っています。例えば、リアルタイムの売上高データに基づく、現在入荷中の商品と在庫切れの商品に関するデータなどです。これらのデータのすべてを使用して予測モデルを作成すれば、小売店で入荷中の商品や在庫がある商品を特定の顧客が購入する可能性を、かなりの信頼度で判断することができます。このようなさまざまな要素に基づくこの予測モデルは、ビジネス・ルール、顧客層、過去の購入パターン、そしてインテリジェントな意思決定の選択肢と組み合わせることもできます。小売店はこの組み合わせを使用して、店頭での値引きという手段によってリアルタイムのアクションを起こすことや、販促やセールを実施および広告するのに最適なタイミング、そしてその対象とする顧客を決定することが考えられます。アナリティクスは、顧客に関する興味深くて有益な実態を浮き彫りにし、顧客の傾向と行動を理解できるようにするとともに、それらの顧客を対象とした特定の売り出しについての情報を顧客が確実に入手できるようにします。

このようなシナリオは、履歴情報、リアルタイムのデータ・フィード、予測モデルまたは最適化モデル、ビジネス・ルール、そしてユーザー・インターフェース・ダッシュボードがそれぞれに保管された複数のデータベースから成り立ちます。これらのデータベースは互いに連携して動作しますが、必ずしも特定の問題を解決するために設計または開発されているわけではありません。これらの製品とシステムとの間の複雑な相互作用には、緊密な通信が必要となることから標準を定めて対処するのが最善の方法です。標準が規定されていれば、顧客は自分たちのデータ、ルール、予測モデルなどが特定のフォーマットで保管されており、単一のベンダーに左右されることのないオープンな方法でアクセスできることがわかるというメリットがあります。したがって、顧客は必要なアクションを自由に取れるようになり、特定のツール・セットやデータ・フォーマット、あるいはプロトコルに束縛されることがなくなります。さらに標準によって、通信相手のシステムを念頭に置かずに作成された異なるシステム同士でも連動させることが可能になります。

ビジネス・アナリティクスの焦点は、データに統計手法と分析を適用することによって、ビジネスに対して新たな洞察を行うことで理解を深め、より適切で、より情報に基づいた決定を下せるようにすることです。ビジネス・アナリティクス・ソフトウェアは、大量のデータを短時間で分析し、ビジネス関連の問題に対してさまざまなタイプの実用的な洞察をもたらすことができます。

上に戻る

データの分析

データ分析は今に始まったことではありませんが、現在のデータ分析には、例えば以下の課題があります。

• 正確で実用的な結果を生み出すために処理する必要があるデータ (あるいは処理できるデータ) が大量にあること。
• データを分析して結果を出すまでの時間にスピードが求められること。
• 分析するデータのタイプに、構造化データと非構造化データがあること。

データの量

最近のアナリティクス・システムは、インターネット規模のデータ量を処理しなければなりません。オンライン・データは急増しており、テラバイト、ペタバイト、さらにはエクサバイトなどの用語が一般的に使われています (表 1 を参照)。

2002年にインターネット上にあったデータの量は、約 5 エクサバイトです。2009年になると、その合計は 281 エクサバイトにまで増加しました。これは、7 年間で 56 倍もの増加率です。Forrester Research Inc. によると、企業がデータウェアハウスに保管しているデータの合計量は、3 年ごとに倍増しています。

インターネット規模という言葉は、データ・サイズがテラバイトやペタバイトの時代を指しており、これほどの量のデータをタイムリーに扱うための処理要件を満たせるようにスケーリングできることを意味します。処理するデータの量には、保管されたデータだけではなく、リアルタイムのストリーミング・データも含まれます。動画や音声の監視、銀行取引、購入取引、E メールのやり取り、インスタント・メッセージのやり取り、インターネット検索、医療の画像や記録など、現在は実質上すべてのものが電子的に記録されています。

単純なシナリオを例に考えてみましょう。例えば、職場から自宅まで車で帰る途中でガソリン・スタンドに寄って、ガソリンを入れるとします。まず、職場を出て車へ向かって歩いている間、その姿は監視用ビデオ・カメラに記録されている可能性があります。運転中には携帯電話が送信する GPS 位置情報が記録されているはずです。そして家に向かって運転しているときに、携帯電話でテキスト・メッセージを受信するとします。こうしたメッセージの内容とタイムスタンプは通信事業者に保管されます。ガソリン・スタンドに到着してからそのメッセージに返信すると、そこでは別の監視用ビデオ・カメラがその行動を記録します。ガソリンを入れるときには、その取引がガソリン・ポンプでスキャンしたお得意様カードの情報と一緒に記録されます。そのガソリン・スタンドがある場所は、市で ShotSpotter などの技術 (「参考文献」のリンクを参照) を使って監視している犯罪率の高い地域です。ShotSpotter は、各所に配置されたマイクで音声を記録して発砲音を聞き分け、発砲音が聞こえると、すぐに当局に通報します。すると、その地域のビデオによる監視の記録が取得されるという仕組みです。したがって、ガソリン・スタンドにいる間中、音声が分析され、記録されています。

データウェアハウスに保管されるデータが増大するなかでも EMR (Electronic Medical Record: 電子カルテ) はかなりの部分を占める可能性があります。EMR、医療画像の進化、これらのデータに義務付けられている保管期間 (米国連邦法では 7 年間) などが要因となって、今後もデータウェアハウスに保管されるデータは大幅に増加し続けることでしょう。

データウェアハウスは、かつては考えられなかったほどの規模でそのデータ量が増大しています。しかも、動画および音声のフィードを保管するにはかなりのコストがかかります。それは、このタイプのデータは、収集される量が膨大であることに加え、圧縮率が低いという特徴を持っているからです。このようにデータの量が膨大なため、この種のデータをリアルタイムで分析し、関連する部分だけを選択的に保管できるようにすることが重要となっています。

至るところでデータは記録されており、事実上、動くものなら何でも、そして動かないものでもその多くが記録されています。通常記録されるような取引だけにとどまらず、駐車場やビル、そして街角などの無味感想な対象でさえも、インスツルメント化されて大量のデータを絶え間なく記録しています。

速度

保管されるデータ量がとどまることなく急増しているなか、ビジネス・アナリティクス・システムによって処理し、関連する結果を生成しなければならないデータ量も同じく急激に増え続けています。例えば、Twitter で 1 日に処理するデータ量は 7 テラバイトです。Facebook では毎日 10 テラバイトのデータを処理しています。CERN Hadron Collider に至っては、毎秒 40 テラバイトものデータを生成しています。これほどまでのデータ量に対応するアナリティクス・システムがなければ、収集されたデータはその価値を失ってしまいます。

Yahoo! では、この量がどのようなものであるかを明らかにするためのベンチマークを行った結果、Hadoop を使用した場合、1 ペタバイトのデータをソートするのに約 16 時間かかったと報告しています (これらのベンチマークについての詳細は、「参考文献」を参照してください)。ソートには、それぞれにクアッド・コアの 2.5 GHz プロセッサーを 2 基備えた約 3800 のノードが必要となりました。同じクラスターを使ってすべてが同じ条件で 1 エクサバイトをソートするとしたら、約 1000 倍の時間、つまり約 2 年間かかることになります。

ビジネス・アナリティクス・システムでは、まだ保管される前のリアルタイムのストリーミング・データも処理しなければなりません。重要な洞察をタイムリーに行うには、莫大な量のデータとリアルタイムのデータを処理する速度が決め手となります。いくつかのビジネス・アナリティクスの例では、適切な洞察または正しい答えであったとしても、タイミングを逃して後から提供されたとしたら、それは誤った答えと見なされることも多々あることです。ビジネス・アナリティクス・システムは、大量のデータに対応し、それを効率的に処理し、ユーザーにとって適切な時間枠のなかで結論を出す必要があります。例えば、リアルタイムの動画フィードを処理する顔認識システムが、特定の場所に容疑者がいることを 1 日経ってから事後報告するのではなく、1 分で示せるとしたら、そのシステムの価値は一段と高くなります。

構造化データと非構造化データ

現在生成されているデータの大部分は、非構造化データです。非構造化データであるということは、そのデータが何を表すのかをコンピューター・プログラムが理解できるようにするための潜在的な意味がデータに付随していないことを意味します。構造化データとは、コンピューター・プログラムがデータを理解しやすいように、セマンティックな意味が追加されているデータのことです。一例として、非構造化データが含まれるテキスト・メッセージ (または E メール) を以下に示します。

Hi Joe, call me...my numbers are home – 919-555-1212, office – 919-555-1213, 
cell – 919-555-1213.

人間がこのメッセージを読めば、ここに含まれる意味とデータの意味がわかり、これが自宅、職場、および携帯電話の番号であることを認識することができます。これと同じデータを HTML で表すと、データのレイアウト、そして HTML のネスト形式による構成によって、データは構造化されているように見えます。けれどもアナリティクス・システムにとっては、このデータは非構造化データでしかありません。それは、データに意味が関連付けられていないためです。HTML、E メール、テキスト・メッセージ、ブログ、動画、音声はいずれも、構造化されていない情報を表します。関連する電話番号の情報を HTML に流し込むと、以下のようなデータになります。

<h1>List of Numbers</h1>
<b>HNumber: 919-555-1212</b>
<b>ONumber: 919-555-1213</b>
<b>CNumber: 919-555-1214</b>

前述のように、この HTML は構造化されているように見えますが、これは、潜在的な意味をデータに適用するような構造ではありません。アナリティクス処理システムに関する限り、このデータが非構造化データであることに変わりはありません。さらに、以下のように XML をスキーマなしで使用したとすると、上記の HTML と同じく非構造化データとなります。

<List of Numbers>
<HNumber>919-555-1212</HNumber>
<ONumber>919-555-1213</ONumber>
<CNumber>919-555-1214</CNumber>
</List of Numbers>

XML は、半構造化データと呼ばれることがよくあります。これは、XML にはデータの相互関係に関する構造はあるものの、データの意味に関しては構造化されていないためです。スキーマがあれば、データに意味を関連付ける手段となるため、上記の XML は構造化データであると言えます。スキーマにより、HNumber、ONumber、および CNumber 要素はそれぞれ、自宅 (Home)、職場 (Office)、携帯電話 (Cell) の異なる電話番号を表していることがわかります。構造化データは、データベースにも保管されます。スキーマに従ってデータを行と列に保管することで、コンピューター・プログラムがそのデータの意味を理解することができます。

各種アナリティクス製品に伴う価値として挙げられるのは、大量の非構造化データを処理して潜在的な意味を見つけ出す機能です。上述のテキスト・メッセージ、HTML、スキーマレス XML を例に取ると、これらのデータは電話番号である可能性があることを、コンピューター・プログラムは突き止めることができます。なぜなら、これらのデータは、3 桁の数字の後に区切り文字 (ハイフン (-)、ピリオド (.)、またはスペース ( )) が続き、その後にさらに 3 桁の数字、区切り文字、そして 4 桁の数字が続くというパターンと一致するからです。電話番号であると判断した後、さらに処理を行って、919 というエリア・コードから、この 3 つの電話番号がノース・カロライナ州の電話番号であることを推測することができます。国番号が付いた国際電話番号でも、同じようなアルゴリズムを考えられるはずです。

構造化データの場合、プログラムが事前にデータの意味を判断するために使用できる情報が非構造化データの場合よりも多いため、処理が容易になります。構造化データを処理するほうが、コンピューティング・サイクルを費やしてデータの意味を突き止めるよりも効率的ですが、今日のデータ増大の大部分を占めるのは非構造化データです。そのため、システムが非構造化データを効率的に処理し、データに含まれる意味を適切に判断する能力が極めて重要になっています。例えば、E メールやテキスト・メッセージ、そして音声ストリームおよび動画ストリームは、今日の非構造化データの大半を占めます。このタイプの非構造化データの急増はその勢いを弱めることなく続いているため、このような非構造化データを効率的に処理することが、ビジネス・アナリティクス処理システムの成功を維持する上で不可欠となります。

データの量、処理速度、およびデータのタイプはいずれも、ビジネス・アナリティクス・システムが直面している難題である一方、これらの問題に対処するための大きな進歩がなされています。かつては処理するのに数週間もかかっていた大容量のデータ・セットでも、今ではわずか数分で処理することができます。リアルタイムのフィードを、フェイルオーバー機能を備えたスケールアウト・クラスターで実行すれば、まだ移動中のデータがあってもリアルタイムのフィードを効率的に処理することも可能です。しかも、すべての処理は一般商品化されたマシンで行うことができます。このような処理は、ほんの数年前までは考えられなかったようなアプリケーションの作成を可能にします。この分野のコンピューティングがその最大限のメリットを生かすためには、ソフトウェア標準が重要な役割を果たします。

上に戻る

定義

予測アナリティクス

予測アナリティクスとは、ソフトウェアがさまざまな履歴データ・ソースを使用して、将来起こり得る事象や振る舞いを予測することを意味します。予測には、その予測の信頼度を伴います。

移動中データのアナリティクス

「移動中」データのアナリティクスとは、データがハードディスク・ドライブやその他のストレージ媒体に保管される前に、データを分析することです。最近では膨大な量のデータが収集されることから、データを保管してから分析するのが不可能であることは珍しくありません。さらに、データを先に保管するスペースがあるとしても、保管してから分析するのでは、余計に時間が必要になります。この時間の遅れは、一部のケースでは許容できない場合もよくあります。

保管データのアナリティクス

保管されるデータは膨大な量に上ることから、データをふるいにかけて、そのデータの意味を理解して、結論を引き出す技術が必要になってきます。データの多くは、リレーショナル・ストアまたは OLAP ストアに保管されますが、最近のデータは、構造化された形で保管されない場合のほうが多くなってきています。非構造化データが急激に増えていることから、リレーショナル、非リレーショナル、構造化、そして非構造化の各データ・ソースに対してアナリティクスを行う技術が求められます。

ビジネス・ルール

よりインテリジェントな決定を行うためにビジネスの側面を定義または制約するには、ルールが使用されます。ビジネス担当者がシステムをオフラインにすることなく、簡単にルールを追加または変更できるように、ルールはアプリケーション・ロジックの外部に保管されます。

レポート作成

レポートは、さまざまな複雑度のユーザー・インターフェース・ダッシュボードという形を取ります。

上に戻る

主要な標準

このセクションでは、主要な標準をいくつか取り上げ、データ分析のサポートという点でのそれぞれの関連性と価値について説明します。

UIMA

UIMA (Unstructured Information Management Architecture) は、IBM が技術委員会の議長を務めた OASIS の標準です (「参考文献」を参照)。UIMA は非構造化データを処理し、そのデータに含まれる潜在的な意味、関係、そして関連のある事実を見つけ出し、その内容をオープンかつ標準的なフォームで表現するためのフレームワークです。UIMA を使用することで、プレーン･テキストを取り込み、そのデータに含まれる人、場所、組織、関係 (特定の対象と「友達関係にあるか」、「結婚しているか」など) を判断することができます。収集された情報は、UIMA 標準が定義するデータ構造体で表現されます。

UIMA ではその役割と目的を理解しやすいように、以下の 4 つの用語を定義しています。

• 成果物 (Artifact) — 非構造化コンテンツ
• 分析 (Analysis) — セマンティクスを成果物に割り当てること
• アナリティクス・ソフトウェア (Analytic) — 分析を行うソフトウェア
• 成果物メタデータ (Artifact metadata) — アナリティクス・ソフトウェアで成果物を分析した結果

例えば、ファースト・フード店に関する調査結果を集めた膨大なコレクションを考えてみてください。これは、大量の非構造化テキストに相当します。収集された情報の分析目的は、最もよくある苦情の理由を明らかにすること、最も苦情件数の多い店舗の名前と場所を特定すること、そして苦情のタイプごとに、最も多く苦情が発生した店舗を調べることです。UIMA を使用すれば、このような情報を探り出し、苦情の傾向とタイプを調べることができます。さらに、少なくなってきている苦情のタイプ、増えている苦情のタイプを調べることもできます。

図 1 を見ると、非構造化コンテンツである未処理の調査データが成果物 (Artifact) を表しています (1)。この成果物に、分析 (Analysis) によって意味が割り当てられます (2)。例えば、店舗 15 と店舗 38 ではデザートに関する苦情が最も多く発生している一方、店舗 27 での苦情件数は、前回の調査に比べ、半分に減っているなどです。この分析を実行するアナリティクス・ソフトウェアは一般にプロプライエタリー・ソフトウェアであり、成果物メタデータを生成します (3)。成果物メタデータは、CAS (Common Analysis Structure) として知られるデータ構造体に格納されます。

UIMA で目指している 1 つの目標は、アナリティクス・ソフトウェアの相互運用性をサポートすることです。そのため、CAS によって、アナリティクス・ソフトウェア間で結果を共有できるようになっています。この手法が顧客に与えるメリットは、顧客がデータ表現を共有し、UIMA をサポートする各種のツールと製品の間でインターフェースを取れるようにすることです。図 1 の例で考えると、アナリティクス・ソフトウェアとツールがどちらも UIMA をサポートしていれば、アナリティクス・ソフトウェアは、成果物の分析を実行するツールと連動することができます。この機能によって各種ツールの相互運用が可能になることから、顧客はさまざまなベンダーから、非構造化データの分析に利用するベンダーを自由に選択することができます。

UIMA は、成果物の元の表現とは関係なく、成果物および成果物のメタデータに共通のデータ表現をサポートします。また、プラットフォームの種類に関係なく、成果物および成果物のメタデータを交換できるとともに、別々に開発されたアナリティクス・ソフトウェアを見つけ出し、それらを再利用して、合成することができます。さらに、UIMA は、単独で開発されたアナリティクス・ソフトウェアが相互運用できるようにします。この分野での最先端技術である UIMA は、Apache のオープンソース実装によって支援されています。1.0 仕様は 2009年 3月に、追加作業の予定のない完全な形で完成しました (UIMA 仕様へのリンクについては、「参考文献」を参照してください)。

PMML

PMML (Predictive Model Markup Language) は、IBM がコントリビューターとして参加している DMG (Data Mining Group) で開発された、XML ベースのマークアップ言語です (「参考文献」を参照)。PMML は、履歴データの分析によって得られたさまざまな洞察を基に作成された予測モデルを表現します。

例えば、ある電気通信事業者が、履歴データを分析して、顧客が固定回線サービスを解約して携帯電話サービスに切り替えるかどうかをある程度の確実性で予測したいとします。その場合、アルゴリズム (図 2 の 1) は履歴データを調べ、複数の入力フィールド (年齢、年収、配偶者の有無、住居の所有状況、教育水準など) を基に、顧客がサービスを解約する可能性があるかどうかを可能な限り予測するための式のパラメーターを生成します。これによってアルゴリズムが生成する PMML モデル (2) が、採点プロセス (3) の入力となります。採点プロセスは、特定の顧客がサービスを解約する可能性があるかどうかについての予測 (4) をその予測の信頼度の指標と併せて出力します。顧客を失うという予測の信頼度が高ければ高いほど、より積極的な対応が必要となります。

PMML は、ベンダー間でモデルを共有するためのモデル交換標準です。PMML は、独自仕様の問題と非互換性が、アプリケーション間でのモデル交換の妨げとならないようにすることを目標に、特定のベンダーに依存しないモデルをアプリケーションに提供します。これはユーザーにとって、あるベンダーのアプリケーションでモデルを開発した後、別のベンダーのアプリケーションを使用して、そのモデルを可視化、分析、評価、使用できるというメリットとなります。PMML は XML ベースの標準であることから、仕様は XML スキーマの形になっています。

以下に、業界での現在の PMML 採用状況をリストアップします。このリストに示されているように、業界では PMML の採用が定着しています (Web ページのリンクについては、「参考文献」を参照してください)。

• Augustus / Open Data Group
• KNIME
• MicroStrategy
• Pervasive DataRush
• Rapid-i
• R/Rattle
• Salford Systems
• SAS
• TIBCO
• Weka
• Zementis

RIF

RIF (Rule Interchange Format) は、IBM が共同議長を務めた W3C 標準です。RIF は XML で、実行可能な形式のビジネス・ルールを表現します。ビジネス・アナリティクス・システムでは、ビジネス・ルールをさまざまな形で使用することができます。ルールは、多種多様な条件と入力に応じてシステムが取る特定のアクションを決定するために使用されます。例えば、抵当貸付会社には、特定の個人が融資を受ける資格があるかどうかを判定するルールがあるはずです。この場合、収入、負債額、クレジット・スコア (訳注: 消費者個人に与えられる信用評価点のこと。米国で個人の信用度を評価する際に近年特に用いられている。) などの要因のすべてが関係してきます。したがってルールは、借り手の収入が値 X を超え、負債額が値 Y 未満、クレジット・スコアが値 Z を超える場合、借り手には特定の融資額を受ける資格が認められるといった形になります。ルールの作成方法はベンダーごとにそれぞれ独自の方法がありますが、それらのルールの実行可能フォーマットには、RIF によって相互運用可能な共通フォーマットが実現されます。

RIF は第 1 の目的として、ルール・エンジンの間でルールを交換できるようにするために設計されました。RIF に価値がある理由は、これが、ルール・ベンダーによるベンダー・ロックインを防ぎ、ルール実行システムを相互に運用できるようにするためです。この相互運用性により、ユーザーは各種のツールを使ってビジネス・ルールを作成しながらも、そのビジネス・ルールを、RIF をサポートするさまざまなルール実行システムと相互運用することができます。

RIF は 2010年 6月に W3C 勧告になったため、以下のRIF リファレンス実装のリストに示されているように、現在、業界での採用が広がっています (Web ページへのリンクについては、「参考文献」を参照してください)。

• SILK
• OntoBroker
• fuxi
• Eye
• VampirePrime
• RIFle
• Oracle (OBR)
• STI Innsbruck (IRIS)
• riftr
• WebSphere ILOG JRULES
• TIBCO
• FICO
• Drools

上記の実装は、RIF 標準が開発された当時のものです。これらの企業のうち、数社では完全な標準を実装しているかもしれませんが、その保証はありません。

XBRL

XBRL (eXtensible Business Reporting Language) は、XBRL International による、財務報告書を作成するための XML ベースの標準です。XBRL を話題に出したのは、さまざまな政府および国が XBRL を財務報告書の標準フォーマットとして採用しているからです。XBRL が普及するなか、XBRL 文書とそこに含まれるデータの分析が重要となってきています。

従来から、報告書は HTML または PDF で作成されています。HTML や PDF は人間にとって読みやすいとは言え、構造化されたフォーマットではありません。一方、XBRL 文書は、既知のスキーマを使用した XML で提供されることから構造化されていますが、人間にとってはそれほど理解しやすいものではありません。したがって、そのデータから意味を推測できるように、文書が構造化されて、コンピューター・プログラムに使いやすいようになっています。

最近になって、米国の証券取引委員会 (SEC: Securities and Exchange Commission) は上場している大企業 500 社に対し、XBRL を使用して作成した財務諸表を提出するよう義務付けました。この要件は徐々に拡大し、将来的には上場している中小企業にも適用されることになると思います。時価総額が 50 億ドルを超える企業は、2009年から XBRL での提出を開始しましたが、今年はより詳細な情報のタグを使用した財務諸表を提出するように求められています。時価総額が 7 億ドルを超える企業の場合は、より詳細な情報のタグを使用することは要求されていませんが、今年から XBRL で提出しなければなりません。韓国のすべての株式上場企業は、2007年 10月以来、定期財務報告書およびその他の財務報告書を XBRL フォーマットで提出することが義務付けられています。XBRL での提出という要件は、日本でも東京証券取引所 (TSE: Tokyo Stock Exchange) で採用されていて、日本の証券取引市場で行われている全株式取引の 90％ に適用されています。2008年以降、TSE ではすべての上場企業に対し、TSE に提出する財務情報には XBRL フォーマットを使用することを要件としています。

世界の経済先進国の間では、XBRL が採用され、必須としている国がいくつもあります。表 2 に、世界での XBRL の採用状況を記載します。

OWL

OWL (Web Ontology Language) は、情報やモデルのオントロジーを表現するための高級言語です。例えば、Joe は人間で、Jane と結婚していて、男性です。Sam は人間で、Sue と結婚していて、男性で、夫です。したがって、Joe は夫であると推定することができます。このような相互関係が探求されている理由は、XML Schema のセマンティクスは十分ではないことがよくあり、同様の事実を推定するために、人間による操作がより必要となってくるからです。OWL を使えば、それよりも簡単にプログラムによって情報を推定することができます。そのことから、OWL はルール・ベースのシステムにおいてモデルを交換して使用するのに有用な言語となっています。

上に戻る

シナリオ

これから説明する小売店のシナリオでは、上記で紹介した各種の標準を使用します。

概要

図 3 に、このシナリオで使用するコンポーネントの概要を示します。これらのコンポーネントは、以下のもので構成されます。

• 履歴データを保管するデータベース (保管されているデータ)
• リアルタイム・データのフィード (移動中データ)
• データでアナリティクス・ソフトウェアを実行するエンジン
• 予測アナリティクス
• ビジネス・ルール
• ダッシュボードを使用して結果またはアラートを表示すると同時に、ユーザーの操作を可能にするユーザー・インターフェース

図 4 に、(図 3 の) さまざまなコンポーネント間の現時点および将来の統合ポイントを示します。これらの統合ポイントで、前に説明した各種の標準が相互に作用し、相互運用性のメリットをもたらすことになります。履歴データが使用する標準は、XML、CSV、XLS、PDF、DITA、XBRL など、多岐にわたります。アナリティクス・エンジンは多くの場合、UIMA を使用します。予測アナリティクスおよびビジネス・ルールが一般に使用する標準は、それぞれ PMML、RIF です。

シナリオの詳細

これから順に記載する図で、シナリオの各段階を示し、該当する標準がもたらす価値を説明します。このようなタイプのソリューションを既存の異なる顧客環境にデプロイするときには尚更のこと、このシナリオで適用する標準は重要な役割を果たします。シナリオが表しているのは、大型小売店が履歴データとリアルタイムのデータを使用して売り上げを伸ばし、既存の顧客を維持し、新しい顧客を獲得しようとしている大手小売店のソリューションです。

図 5 に示すように、小売店チェーンの履歴データは、複数のデータベースにさまざまなデータ・フォーマットで保管されています。このシナリオには、顧客の取引データ、好み、購入履歴、客層情報、調査データ、カスタマー・コール・センターの記録 (文書および録音) などのデータが含まれます。これに加え、リアルタイムのデータ・フィードが提供されます。このフィードには、店舗または地域ごとの最新の取引に関するデータや、顧客または顧客グループごとの進行中の取引に関するデータ、カスタマー・コール・センターのライブ・フィード、ビデオ監視のフィード、各店舗に搬送中の製品に関するデータなどが含まれる場合もあります。

以降に記載する図のそれぞれでは、その図で新しく追加された部分全体を背景色が薄い水色の長方形の前面に示します。図 6 に、履歴データの分析に使用する Hadoop を示します。Hadoop は構造化データと非構造化データのアナリティクスを行うために、履歴データを分析します。この履歴データの分析によって、例えば特定の顧客の購入パターン、購買嗜好、競合小売店に対する態度などの情報が明らかになります。アナリティクスを行った結果を他のシステムと共有し、相互運用を可能にするために、UIMA が導入されていることに注意してください。

図 7 では、リアルタイムの分析エンジンが導入されています。リアルタイムの分析エンジンは、構造化データと非構造化データの別を問わず、移動中のリアルタイムのデータを取り込んで処理することができます。さらに、履歴データの分析結果をリアルタイムのエンジンに提供することで、さらなる洞察を得るための一助とすることも可能です。例えば、履歴データの分析で、ある特定の商品の売上げが、週末の間だけ好調であることがわかったとします。この場合、リアルタイムの分析によって、その特定の製品の在庫が少ないこと、そして週末が近づいていることがわかれば、この状況を改善するためにアラートを起動することが可能になります。

図 7 には、リアルタイムの分析エンジンとデータベース内の履歴データとの双方向の接続も示されています。リアルタイムの分析エンジンは、履歴データを使ってリアルタイムのデータを関連付けることもあれば、データを定期的に保管することもあります。例えば、リアルタイムのデータにカスタマー・コール・センターからの音声フィードが含まれているとします。その場合、すべての通話を逐一保管するのではなく、例えば無作為に通話を保管して、後で対応内容の評価を行うことも考えられます。怒った顧客からの通話をシステムが検出した場合には、後で検討および分析するために、その通話を記録することもできます。

図 8 に示すのは、このシナリオの一部としての予測アナリティクスです (図 8 を拡大したものを見るにはここをクリックしてください)。PMML で予測モデルを作成するには、モデリング・ツールを使用することができます。作成された PMML モデルはデータベースに保管することができ、リアルタイムの分析エンジンに解釈させることができます。このシナリオの場合、ある顧客が競合店で買い物するようになることをリアルタイムのデータと履歴データから分析された特定の情報セットが示している可能性について判断するために、予測 PMML モデルを使用することが考えられます。このモデルを使用することで、リアルタイムの分析エンジンがデータを処理して明らかにしていく事実に点数を付けられます。この点数によって、リアルタイムの分析エンジンは処理するデータに関して、さらに深い洞察を得ることができます。

図 9 には、新しい PMML モデルを分析エンジンにリアルタイムで注入できることが示されています (図 9 を拡大したものを見るにはここをクリックしてください)。この注入は、システムの稼動中に、現在収集している最中のデータに基づいて、新しいモデルを作成してデプロイすることができる強力な概念です。

図 10 では、このシナリオにビジネス・ルールが導入される様子を示しています (図 10 を拡大したものを見るにはここをクリックしてください)。リアルタイムの分析エンジンは、着信データと履歴データを処理して売上げの傾向を調べている間、さらにインテリジェントな決定を下すために、ビジネス・ルール管理システムで作成されたルールを呼び出すことができます。ルールで規定する内容の一例は、「顧客 A、B、または C (いずれも最優良顧客) が過去 N 日間に購入取引を行っていない場合、その顧客の調査データに顧客が競合小売店に移る可能性があると示されているとしたら、特別値引きを申し出る」というものです。

図 10 には RIF 標準も示されています。これは、RIF を使用して、ルールを実行可能な形式で表現するためです。この形式によってベンダーのルール・システムは、顧客が特定のルール・ベンダーにロックインされることがないようにルールを共有することが可能になります。

図 9 に示した新しい PMML モデルのリアルタイムの注入と同じく、図 10 には新しいルールもリアルタイムで注入できることが示されています。

図 11 には、ダッシュボードと可視化機能がどのように活用されるかが示されています (図 11 を拡大したものを見るにはここをクリックしてください)。これらの機能を作成するには、処理中のリアルタイムの情報と、従来のデータベースまたは OLAP データベースに保管された履歴データを組み合わせ、リアルタイムのアラートまたは情報提供用ダッシュボードとして表示されるようにします。

上に戻る

まとめ

収集されるデータと使用可能なデータが急増しているという事実と、そのデータからさらに新しい洞察を得たいという期待が重なり、これまで想像もつかなかったほどの膨大なデータに対処し、効率的に処理して理解する必要に迫られています。このような目標を達成するには、レガシーのものも、新しいものも含め、複数のシステムと技術を連動させなければなりません。このような技術間での統合には、相互運用を可能にするための標準が必要です。データ、製品、技術を統合し、ビジネスおよび利用者が期待する目標を効率的に達成するには、相互運用性が必要となります。

参考文献

学ぶために

• ShotSpotter: ShotSpotter の Web サイトにアクセスしてください。
  
  
• PMML Powered: PMML を採用している企業のリストにアクセスしてください (Data Mining Group 提供)。
  
  
• 「Hadoop Sorts a Petabyte in 16.25 Hours and a Terabyte in 62 Seconds」: ソートのベンチマークの結果およびルールの詳細を読んでください。
  
  
• Implementations - RIF: 実装に関して W3C に寄せられた報告が要約されています。
  
  
• OASIS Unstructured Information Management Architecture (UIMA) TC: UIMA プロジェクトおよび仕様におけるセマンティック検索およびコンテンツ・アナリティクスの標準化について、OASIS で詳しく調べてください。
  
  
• Apache UIMA: マニュアルとソース・コードから、Apache UIMA プロジェクトについて学んでください。
  
  
• 「PMML 4.0 - General Structure of a PMML Document」: Data Mining Group にアクセスして、PMML プロジェクトおよび仕様で XML を使ってマイニング・モデルを表現する方法を調べてください。
  
  
• RIF: W3C で RIF プロジェクトおよび仕様を調べてください。
  
  
• XBRL: XBRL International の XBRL プロジェクトおよび仕様にアクセスして、ビジネスおよび財務データを電子通信することを目的としたこの言語の詳細を学んでください。
  
  
• Apache Hadoop プロジェクト: 大容量のデータ・セットをクラスターで分散処理できるようにする Hadoop フレームワークについて学んでください。
  
  
• OWL Web Ontology Language Overview: W3C で Web Ontology Language に関する詳細を読んでください。
  
  
• New to XML: XML を学ぶために必要なリソースを入手してください。
  
  
• developerWorks の XML エリア: XML 分野でのスキルを磨くための資料を見つけてください。広範な技術に関する記事とヒント、チュートリアル、標準、そして IBM Redbooks については、XML 技術文書一覧を参照してください。
  
  
• IBM XML 認定: XML や関連技術の IBM 認定技術者になる方法について調べてください。
  
  
• developerWorks の Technical events and webcasts: これらのセッションで最新情報を入手してください。
  
  
• Twitter での developerWorks: 今すぐ登録して developerWorks のツイートをフォローしてください。
  
  
• developerWorks podcasts: ソフトウェア開発者向けの興味深いインタビューとディスカッションを聞いてください。
  
  
• developerWorks オンデマンド・デモ: 初心者向けの製品のインストールおよびセットアップから熟練開発者向けの高度な機能に至るまで、さまざまに揃ったデモを見てください。
  
  

製品や技術を入手するために

• IBM 製品の評価版: DB2、Lotus、Rational、Tivoli、および WebSphere のアプリケーション開発ツールとミドルウェア製品を体験するには、評価版をダウンロードするか、IBM SOA Sandbox のオンライン試用版を試してみてください。
  
  

議論するために

• XML ゾーンのディスカッション・フォーラム: XML 関連のフォーラムに参加してください。
  
  
• developerWorks コミュニティー: ここでは他の developerWorks ユーザーとのつながりを持てる他、開発者が主導するブログ、フォーラム、グループ、ウィキを調べることができます。
  
  

著者について

Peter Haggar は、ノース・カロライナ州リサーチ・トライアングル・パーク所在の IBM に勤めるシニア・テクニカル･スタッフ・メンバーです。彼がご最近取り組んだのは、ビジネス・アナリティクス、新たなソフトウェア標準、XML、バイナリー XML、Web サービスで、現在は Watson および DeepQA を焦点とする新しいインターネット技術に取り組んでいます。彼は、20 年以上 IBM に勤務しています。

この記事を評価する

コメント

上に戻る

目次

• 概要
• ビジネス・アナリティクスとは何か
• データの分析
• 定義
• 主要な標準
• シナリオ
• 概要
• まとめ
• 参考文献
• 著者について
• コメント