SAS Japan

活用事例からデータ分析のテクニックまで、SAS Japanが解き明かすアナリティクスの全て
Analytics
小林 泉 0
2020 ビジネスにおけるAI/アナリティクストレンド

アナリティクス・プラットフォームは、OSSとの機能的な連携にとどまらず、OSS利用環境そのものの価値を高めるプラットフォームへと進化 昨今、40年以上にわたりSASが提供続けてきたこのAI/アナリティクスが、時代背景とテクノロジーの進化によって、特定のAI/アナリティクス先進企業だけの道具から、ほとんどすべての企業にとって活用可能な-多くの場合競争に勝つためには活用しなければならない-道具になってきました。 従来より、SASはオペレーティング・システム、データソースや、システム・アーキテクチャなど特定のS/Wやテクノロジーに依存せず、どのような企業のIT環境にたいしても柔軟に適用可能なアーキテクチャでしたが、世の中のテクノロジーの変化に合わせ、その柔軟性をより高めるために、SAS Viyaを提供することになりました。 そして、SASはSAS Viyaのオープンなアーキテクチャにより、OSSで構成されたアナリティクス環境、OSSを利用するアナリティクス組織に、全く新しい俊敏性と信頼性の両方を兼ね備えたアナリティクス基盤を提供し、より多くの試行錯誤とリアルなビジネス価値の創出を可能とする環境を提供しています。 現在必要なのは、俊敏性と信頼性の両立 多くの企業が従来にも増してグローバルの競争にさらされています。不正・セキュリティ対策においてはより巧妙なスピードの速い攻撃に対応する必要があり、金融リスク業務はさらなる規制対応と同時によりプロアクティブな利益創出への転換をはじめており、顧客の購買行動はより多様化・リアルタイムな顧客経験が重要となり、モノのサービス化に代表されるようなビジネス・モデルの変革への急速な移行が求められ、製造品質はより速く、より品質の高いプロセスへの変革が要求されています。また、特に日本においては労働人口の不足により、たとえば製造プロセスやサプライチェーンの高度なレベルでの標準化と自動化、その他のビジネスプロセスにおいても様々なレベルでの意思決定を高精度に自動化する必要に迫られています。さらに、より付加価値の高いサービス提供のためのビジネス・モデル創出など、あらゆる場面でAI/アナリティクスの活用による、イノベーションが求められています。 変化の早い時代に必要な俊敏性 このような時代においてアナリティクス活用に求められる一つの側面は「俊敏性」です。本当に役に立つ洞察を得るためには、無数の試行錯誤・実験を繰り返す必要があります。アナリティクスにおいては、利用データの試行錯誤、利用アルゴリズムの試行錯誤、仮説検証の繰り返し、そのような試行錯誤・実験-それは場合によってはPOCと呼ばれることもありますが-によって結果的に得られた有用な洞察がイノベーションとなります。したがって、この試行錯誤・実験をより手軽に、迅速に行う手段が有用であり、それはソフトウェアの入手のしやすさや、最新の論文から技術的な手法に関する世の中の知の活用のしやすさなどの特徴のある、OSSの活用の一つの有用な活用形態となっています。 ここで一つ注意しなければならないのは、OSSの利用や関連論文の利用によって得られるものはビジネス上の洞察ではなく、あくまで手段としての技術テクニックの知識であるということです。ディープラーニングのようにあ「非構造化データを構造化する技術」であったり、「非常にスパースなデータからよりより推定を行うための技術」であったり。アナリティクスを活用してビジネス上の成果を得るためには、あくまで、そのような手段とは別に、まず初めにビジネス上の問題定義-デザインといってもいいでしょう-が重要です。これは従来からの世界では既知の視点です。これを忘れると、いわゆるPOC疲れなど、手段が目的化したプロジェクトに貴重なリソースを費やす結果となっていることは、ここ数年、市場でよく見られた光景です。 また、ビジネス上の洞察は常に「問い」に基づくものでありますが、ビジネスの営みの結果である「データ」に潜む「傾向」、すなわち「データに潜む洞察」、を瞬時に導き出す技術も出てきています。昨今「拡張アナリティクス」(AI Augmented Analytics)と呼ばれているものです。AIブームの中、AIを使いこなすこと-すなわちディープラーニングを使いこなすことであったり、予測モデルをいかに簡単に開発するか-そのものが目的化してきました。そのブームが落ち着きを見せ始め、ツールの中にAI技術が組み込まれ、ビジネスユーザーには本来不要であった「自動的に簡単にモデルを開発する」という仕事から、「自動的に洞察を得る」という本来すべきことに注力できるようになってきています。 洞察の獲得と得られた洞察をビジネスに適用するための信頼性 試行錯誤や実験において洞察を得るためには、闇雲に作業を繰り返すのではなく、過去の試行結果に基づいた試行錯誤を繰り返すというプロセスが必要となります。過去の実験はどのようなデータを利用したのか、そのデータはどのような文脈で取得されたのか、それをどのように加工・分析したのかというプロセスと、最終的な結果、このような情報を統制・管理したもとでの試行錯誤でなければ、試行錯誤の積み重ねによる洞察は得られません。つまり、昨今例えば、デジタルトランスフォーメーションのための専任部門によって無数に繰り返されるPOCについても、ガバナンスが必要となるということです。このように適切に統制されたPOC活動は仮にそのPOCからその時、有用な洞察が得られなかったとしても、貴重な資産として次のPOCに生かされるのです。 さらに、試行錯誤やデータの探索によって得られた得られた洞察を実際のビジネス上の価値-それは収益の向上、コストの削減、リスクの管理に大別されます-に変えるには、業務そのものの意思決定プロセス・アクションに落とし組むことが必要です。AI/アナリティクスをビジネス・プロセスとして運用するということは、アナリティクス・モデルによって意思決定を自動化することに他なりません。 また、企業・組織がビジネス・プロセスとしてそのような意思決定を回すためには、アナリティクス・モデルによる結果すなわち、ビジネス上のアクションの結果をモニターし評価する必要があり、市場の動向変化によるモデルの陳腐化に対応するためにモデルのパフォーマンスを管理をする必要があり、現在システムに組み込まれているモデル-これをチャンピオンモデルと言います-はなにかを管理する必要があり、さらには、望まない結果が生じた場合に-あるいはその逆の場合にも-結果に対する説明責任を果たすために、そのモデルの成り立ち-使用したデータ、データ加工のプロセス、モデリングのプロセスなど-を管理する必要があります。 俊敏性と信頼性を両立するSAS Viyaのガバナンス機能とは SAS Viyaでは使用するプログラミング言語を問わず以下のガバナンス機能を提供します。これにより、統制のとれたコード・アグノスティックなアナリティクス環境を実現します。 完全にオープンなI/Fによる民主化されたツールにより、どのようなスキルの方でも利用可能 SAS Viyaでは完全なコード・アグノスティック(データサイエンティストは自身が好きなプログラミング言語を利用可能)な世界を実現しており、データ加工、統計解析、機械学習、ディープラーニングなど各種のアナリティクス処理だけでなく、ユーザー管理、セキュリティ管理、システム管理、データ管理からモデル管理まで、全ての機能をOSSプログラミング言語であるPython, R, REST APIから利用可能です。 また、従来からあるSAS9においても、ほとんどのSASプロシジャをpythonから利用可能になっています。 もちろん、コーディングスキルを持たないビジネス・ユーザーはデータの準備、探索、モデリングまでシームレスに連携したグラフィカル・インターフェースによって市民データサイエンティストとしてアナリティクス・プロジェクトに貢献することが可能です。 OSSかどうかにかかわらず、データに基づいた洞察を価値に変えるためにのビジネス上でのオペレーショナライズを支援 AI/アナリティクスから実際のビジネス価値を創出するためには、問い(問題設定)、データの準備、データの探索、モデリング、意思決定プロセスの構築、業務オペレーションへの組み込み、意思決定(アクション)の結果のモニタリグ(レビュー)という一連のアナリティクス・ライフサイクルを、様々な組織の役割が強調して実現する必要があります。業務オペレーションへの組み込みには大きく分けて二つの形態があります。 バッチスケジューリングによるスコアリング処理 アプリケーションから呼び出されるリアルタイム・スコアリング処理 スコアリング処理 ここでいうスコアリングとは、昨今のAI・機械学習ブームの中、その研究領域で使用されている「推論」と同じものです。ビジネスの世界では、二十数年前からこの「スコアリング」という呼び方で実施されていました。顧客の購買確率や解約確率のスコアを出す、信用リスクのためのスコアを算出、などというようにです。 1.バッチスケジューリングによるスコアリング処理 スコアリングの仕組みにおいては、ほとんどのケースでシステムの安定性の観点も鑑み、こちらの方式が採用されます。後述のリアルタイム・スコアリングのケースにおいても、あらかじめスコアリングした結果を検索するだけで済むトランザクション処理がほとんどなためです。全顧客あるいは全セグメントに対してあらかじめスコアを算出したものを、業務システムに連携します。 このケースにおいてはのチャレンジは、開発したモデルをもとにプロダクション・レベルのバッチ処理を開発・テスト・スケジュール化・運用することです(デプロイメント・プロセスと呼びましょう)。モデルの入力データを作成する処理を作る必要があるからです。チャレンジのポイントは、そのデプロイメント・プロセスをユーザーサイドが行うのか、IT部門サイドが行うのか、はたまた、どのようにシームレスに強調するのかです。これは、モデルを組み込む業務プロセス、たとえば商品の数、サービスの数が多いケースにおいてすでに課題となっています。 約二十年前のデプロイメント・プロセスについての余談ですが、ある通信会社において顧客ごとの解約予兆スコアを算出していました。プロジェクトメンバーの一人であったお客様のIT部門の担当の方は、このスコアをもとに接客すべきと、すぐに、そのスコアテーブルのデータを販売店に持参し参考にしてもらうことで、大きな効果を生み出していました。今の時代とは、使用するデータと技術が異なるだけで、ビジネスプロセスにデプロイするという意味は全く何も変わってないことがお分かりいただけると思います。 2.アプリケーションから呼び出されるリアルタイム・スコアリング処理 リアルタイム・スコアリングにはさらに2種類の技術的視点があります。オンライン・トランザクション処理のタイプと、ストリーミング処理のタイプです。これら二つは日本語で言うと同じように「リアルタイム処理」と表現されることが多いですが、技術的な実現イメージはことなります。前者は、リクエスト/レスポンス型であり、その多くはフロントエンドのアプリケーションから、例えば顧客情報などの必要データがスコアリング・エンジンに渡され(リクエスト)、与信結果のスコアを返す(レスポンス)といういわゆるトランザクション処理になります。昨今のREST APIインターフェースなどはこの目的のものです。一方で後者は、データが絶え間なく流れてくるセンサーデータを処理するような場合で、ストリーミング型と言われます。この時のデータのことをイベントと言ったりもします。データ(イベント)がやってきた際に処理が実行されます。多くは、IoTという言葉が登場するシーンで求められる処理方式です。 どちらのタイプにせよ、このリアルタイム・スコアリングを組み込むシステムにモデルを組み込むときには、アプリケーションの開発プロセスを意識する必要があります。なぜなら、アプリケーション・ロジックの変更を伴なうモデル変更も多々あるからです。たとえば、与信システムにおいて新たな説明変数の入力を必要とするモデルの変更は、フロントアプリケーションのUIの変更を伴います。昨今、アプリケーションの開発・テスト・運用プロセス(DevOps)と、モデルの開発・テスト・運用プロセス(ModelOps)の融合が求められているのは、このためです。 2020のAI/アナリティクス・トレンド AIブームも少し落ち着きを取り戻し、モデルの開発という本来手段であることそのものが目的化してしまっている状況から、開発したモデルをビジネスプロセスにデプロイするという本来目指すべきことの重要性が、このAI市場にも浸透しつつあるようです。筆者は、様々なお客様のご支援を通して、またメディアの方々、リサーチファームの方々との情報交換を通して、2020年、以下の3つが引き続きトレンドとなるのではないかと考えています。 アナリティクスの民主化 AI技術のコモディティ化(隠ぺい化)し、「拡張アナリティクス」として進化 OSSプログラミングからGUIユーザーまでが共存可能なオープンなアナリティクスプラットフォーム 人材の活用と技術伝承のための「共有とコラボレーション」

Analytics
0
R言語でSAS ViyaのAI機能活用 第二回「アクションセットと最初のデータ読み込み」

概要 第一回の「CASサーバーとSWATパッケージ」に続き、第二回としてCASのアクションセットの活用やCASサーバーへのデータ読み込みなどの基本操作の方法について紹介します。 アクションセットについて CASサーバー上での分析作業を開始する前に、“アクションセット”という重要な概念に関して紹介します。 アクションセットは、関連する機能を実行するアクションの論理的なグループです。 SAS Viyaでは、関数のことを「アクション」、関連する関数のグループを「アクションセット」と呼んでいます。アクションでは、サーバーのセットアップに関する情報を返したり、データをロードしたり、高度な分析を実行するなど、さまざまな処理を実行できます。 アクションセットを使ってみましょう それでは、サンプルコードを使いながら、SAS Viyaのアクションセットでデータの読み込みからプロットまでの一連の操作を説明します。 ・データの読み込み CASサーバーにデータを読み込むには二つの方法があります。一つはread.csv()でcsvファイルをRデータフレームの形で読み込んだ上で、as.casTable()を使用する方法です。この関数はデータをRのデータフレームからCASテーブルにアップロードすることができます。今回の例では金融関連のサンプルデータhmeqを使って紹介します。 library("swat") conn <- CAS(server, port, username, password, protocol = "http")   hmeq_data <- read.csv(“hmeq.csv”) hmeq_cas <- as.casTable(conn, hmeq) もう一つはcas.read.csv()を使って、ローカルからファイルを読み込んで、そのままCASサーバーにアップロードする方法です。仕組みとしては、一つ目の方法と大きくは変わりません。 hmeq_cas <- cas.read.csv(conn, hmeq) as.casTable()或いはcas.read.csv()からの出力はCASTableオブジェクトです。その中に、接続情報、作成されたテーブルの名前、テーブルが作成されたcaslib(CASライブラリ)、およびその他の情報が含まれます。 Rのattributes()関数を使えば中身を確認できます。 attributes(hmeq_cas) $conn CAS(hostname=server, port=8777, username=user, session=ca2ed63c-0945-204b-b4f3-8f6e82b133c0, protocol=http) $tname [1] "IRIS" $caslib [1] "CASUSER(user)"

Data for Good | SAS Events | Students & Educators
0
第四回Data for Good勉強会 活動レポート

SAS Japanでは昨年末より”Data for Good”を目指す学生コミュニティ「SAS Japan Student Data for Good Community」を運営しています。このコミュニティは、Data for Goodを題材にデータサイエンスの一連の流れを体験する場として設立されました。今回紹介する勉強会も、その活動の一環です。詳しくは「Data for Goodを通じて"本物の"データサイエンティストになろう!」の記事をご覧ください。 四回目の勉強会ではFood Bankをテーマに、データを活用した課題解決の手法を学びました。 Food Bank   Food Bankとは、品質に問題がないにもかかわらず市場で流通出来なくなった食品を、福祉施設などに提供する活動のことです。この取り組みは食に困っている人の支援だけでなく、食品ロスの削減の一翼も担っています。しかしながら、Food Bankの高頻度の利用は自立を妨げることにも繋がりかねず、利用者への適切なサポートが多くのFood Bankで課題となっています。 イギリスのHuddersfieldを拠点とするFood BankのThe Welcome Centre(TWC)もその一つです。利用者のある一部は、日を追うごとにパントリーの訪問回数が増え、依存度を増していくことがTWC内で問題となっていました。とは言うものの、沢山の利用者がいるの中で「誰がFood Bankに依存しているのか」を調査するのは非常に労力のかかる作業です。そこでTWCはDatakind社と共同のプロジェクトを開始し、Analyticsを用いて効率的に依存性の高い人を発見し、優先的なサポートを施すことに挑戦しました。このプロジェクトでは、実際に Food Bankへの依存性を推定する機械学習モデルの構築 依存性の高い人にフラグを立て、優先して支援すべき利用者を可視化する ことに取り組んでいます。詳しい内容はDataKind社の事例紹介(英語)をご覧ください。 解くべき課題を設定する これらの事例を踏まえ、私たちのコミュニティが「日本のFood Bankの課題」に取り組む場合、解くべき課題は何か・解決するために誰のどのような意思決定が必要か・どのようなデータが必要か、ディスカッションを行いました。 議論を進めていく中で、さまざまな意見が飛び交いました。その中には、「寄付を受けた食料品を完璧に消費するために、新規パントリーを出店する際の食料品の需要予測が必要ではないか」や「限られたボランティアの中で食品配送ルートの改善が大きなインパクトをもたらすのではないか」といった意見が出ました。ディスカッションをすることで、自分では思いつかない新鮮な発想に触れることができたり、テーマに広がりを持たせられることを感じました。アナリティクスの結果を活用するアクションを考えるための「課題設定」を実際に体験できた勉強会になりました。 コミュニティメンバー募集中! SAS Japan Student Data for Good communityでは引き続き学生の参加者を募集しております。社会貢献を目指す活動を通してデータサイエンティストの役割である「課題の設定」から「データを用いた解決法の提示」までの一連の流れを経験できます。 興味をお持ちでしたら下記の事項をご記入の上JPNStudentD4G@sas.comまでご連絡ください。 大学名 / 高校名 名前 メールアドレス

Data for Good | SAS Events | Students & Educators
0
第三回Data for Good勉強会 活動レポート

SAS Japanでは昨年末より”Data for Good”を目指す学生コミュニティ「SAS Japan Student Data for Good community」を運営しています。このコミュニティは、Data For Goodを題材にデータサイエンスの一連の流れを体験する場として設立されました。今回紹介する勉強会も、その活動の一環です。詳しくは「Data for Goodを通じて"本物の"データサイエンティストになろう!」の記事をご覧ください。 三回目の勉強会ではヒートアイランド現象をテーマに、課題設定の部分を学びました。   ヒートアイランド対策、”どこ”から? ヒートアイランド現象とは、都市部の気温が周りに比べて高くなる現象です。その要因には、都市化による土地利用の変化や人間活動で排出される熱などがあります。対策事例として人口排熱削減のために次世代自動車の普及をしたり、保水性舗装の普及や屋上緑化を推進して地表面被服の改善を目指したりというものが行われています。 勉強会で取り上げたヒートアイランド対策事例の一つに、リッチモンドのヒートマッピングがあります。ヒートアイランド現象は都市部と郊外を比較して都市部の方が暑いという考え方が一般的です。しかし、植生域より人口被覆域の方が地表面からの大気加熱を大きくすることや、明るい色の舗装より暗い色の舗装の方が熱を吸収して暑くなることから、都市部の中でも暑さに対する強度は場所によって異なります。そこで、リッチモンドでは「都市の中でも特に暑さの影響を受けやすい場所を見分ける」ことで、対策を優先して行うべき場所の判断をサポートするためのプロジェクトを開始しました。そのアプローチとして、 リッチモンドをブロックで分けた各地点の気温・場所・時間のデータを収集する 観測データ+土地利用マップ+住民の収入データ→各地点のヒートアイランドに対する脆弱性レベルを定量化・可視化 に取り組んでいます。このプロジェクトは2017年にリッチモンドで開始し、今では様々な都市に活動の輪を広げています。詳しい内容はこちらの記事(英語)をご覧ください。   解くべき課題を設定する これらの知識を踏まえて、次は「課題設定」を行いました。自分たちでヒートアイランド現象という問題に対して、解くべき課題は何か・解決するために誰のどのような意思決定が必要か・どのようなデータが必要か、についてディスカッションをしました。 議論を進めていく中で、さまざまな意見が飛び交いました。その中には、テーマとして設定していたヒートアイランド現象を解決するというよりも、ヒートアイランド現象が”障壁”となって起きるであろう「熱中症を未然に防ぐ」というものを課題に設定するという意見がありました。その解決策として、リッチモンドの事例を応用した「ある人がいる地点の体感気温+その人の体温のデータをリアルタイムで収集し、熱中症のおそれがある場合に通知するアプリケーションの作成」などの案が出てきました。 ディスカッションをすることで、自分では思いつかない新鮮な発想に触れることができたり、テーマに広がりを持たせることが出来たりすることを感じました。アナリティクスの結果を活用するアクションを考えるための「課題設定」を実際に体験できたディスカッションになりました。   コミュニティメンバー募集中! SAS Japan Student Data for Good communityでは引き続き学生の参加者を募集しております。社会貢献を目指す活動を通してデータサイエンティストの役割である「課題の設定」から「データを用いた解決法の提示」までの一連の流れを経験できます。 興味をお持ちでしたら下記の事項をご記入の上JPNStudentD4G@sas.comまでご連絡ください。 大学名 / 高校名 名前 メールアドレス  

1 2 3 32