「UX × Data」をテーマとした”もくもく会“を、2019年7月より定期開催します。もくもく会なので、各自での自習を基本としたスキル向上が主な目的ですが、同時に「UX × Data」というテーマに関心や課題をもつ人の交流や協力の場にできればと考えています。また「UX × Data」で何らかの不便さや社会問題を解決できないかについて息抜きがてら雑談し、アイデアの種が生まれたら、実現や事業化に向けた取り組みも検討します。

開催要項は下記のとおりで、各回の告知と募集はTECH PLAYで随時行ないます。みなさまと”もくもく”できることを楽しみにしております。

もくもく会って？

もくもく会とは、カフェやシェアオフィスなどに集まり、各自もくもくと勉強したり作業したり本を読んだりするだけの会のことで、いわゆる勉強会とは違い、各自が主体的に取り組むことで”話を聞いて勉強した気になっただけ”にならないのと、完全な独習とは違い、同じ関心や課題をもった仲間がいることで背中を押されたり、互いに教え合うことで知識を高められるという特徴があります。

最近はやや落ち着いた感がありますが、人工知能（Artificial Intelligence：AI）あるいは機械学習（Machine Learning）¹⁾いまさら聞けない機械学習という言葉を聞かない日はないくらいにバズワード化しています。これは第三次AIブームと呼ばれ、その火付け役が機械学習の一種である深層学習（Deep Learning）であることはいうまでもありません。

第三次があるならば、当然ながら第二次AIブームも存在したわけですが、その中心にいたのがエキスパートシステムです。エキスパートシステム（Expert System）とは、専門知識を持たない素人でも、専門家と同じレベルの意思決定や問題解決ができるよう、その領域の専門知識をもとに専門家の能力を再現するシステムのことです。専門知識をルール化することから、ルールベースシステム（Rule-based System）とも呼ばれます。

筆者が大阪大学でAIの研究に関わっていた1990年代後半は、まさにこのエキスパートシステムを中心とした第二次AIブームが過ぎ去った後の、いわゆるAI冬の時代でした。しかしながら、その研究は粛々と続けられており、当時は大阪大学の助手であり、筆者の指導教官でもあった大澤幸生氏（現東京大学教授）により開発が進められていた、Index Navigator²⁾ユーザの変化する興味を理解し表現する文献検索支援システムIndex Navigatorと呼ばれる、キーワードの関連性を表す知識ベースをもとに、推論エンジンを使ってユーザーの興味を入力キーワードから理解し、次のキーワード候補を提案することで文献検索を支援するシステムは、1998年の人工知能学会論文賞を受賞しました。

ところで、なぜ第二次AIブームは終わってしまったのでしょうか。それを理解するには、そもそもエキスパートシステムとは何か、そしてその欠点を知る必要があります。また、第三次AIブームの渦中で、エキスパートシステムはどのような状況にあり、さらに今後はどうなるのでしょうか。

深層学習のベースである多層ニューラルネットワーク（Deep Neural Networks：DNN）を用いた機械学習の発想は古くからあり、1979年に福島邦彦氏により発表されたネオコグニトロンでその原型が確立されています。しかしながら当時は、その技術を生かす大量データと膨大な計算を行う超高性能なコンピューターが存在せず、実用に至りませんでした。ところが、近年のビッグデータの普及とコンピューターの進化により、深層学習として具現化されたわけです。

2019年は5G・IoT元年になると言われています。AIをとりまく環境も大きく変わることでしょう。深層学習がそうであったように、エキスパートシステムが近年の技術革新により進化する可能性は十分にあります。ここで復習をかねて、再考してみたいと思います。

知識に基づく推論。

エキスパートシステムは、専門家の意思決定や問題解決の能力や手順を模倣するシステムであり、専門家のように知識に基づいた推論を行うことで、複雑な問題を解くよう設計されたものです。

通常のシステムでは、すべてのロジックをプログラムで構造化するのに対し、エキスパートシステムでは、知識と推論を分離して構造化するという特徴があり、それぞれの部分を知識ベース・推論エンジンといいます。

知識ベース（Knowledge Base）は、専門知識をルールで表現した特殊なデータベースであり、「もしXならば、Yである」という自然言語の形式で記述されます。サッカーでたとえるならば「もしディフェンスが右に動けば、オフェンスは左に動く」というようなことです。推論エンジン（Inference Engine）は、エキスパートシステムの頭脳であり、知識ベースに記述された専門知識をもとに最適解を推論する仕組みのことです。

もともとエキスパートシステムは、スタンフォード大学のヒューリスティック・プログラミング・プロジェクトの研究者らにより1960年代に提唱されたもので、その一人でありエキスパートシステムの父といわれるエドワード・ファイゲンバウム氏らによる、Dendralという有機化学の知識をもとに未知の有機化合物を質量分析法で分析して特定するシステムがその起源です。

1980年代には、同氏が提唱したエキスパートシステムを扱う工学分野である知識工学をベースに研究開発が進み、多くの大企業が導入するなど実用に向けて大きく前進しました。これが第二次AIブームです。多くの大学ではAI関連コースが開設され、日本では第五世代コンピュータの開発を目指す国家プロジェクトも発足しました。

しかしながらそのブームは1980年代とともに終了します。その理由は、エキスパートシステムが抱える以下の欠点によるものでした。

• 専門家のあらゆる知識のルール化が必要で労力がかかる。
• たくさんの知識を教えると矛盾が発生する。
• 知識として体系化しづらい例外が存在する。

そもそもエキスパートシステムが求められる業種や職種の専門知識は複雑かつ多岐にわたります。また、相互に矛盾するものやルール化しづらい例外も多く、それらを包括する汎用的なロジックの表現は極めて難しいものです。

例えば、会計業務には明確なルールがあり、簿記の手順にしたがって作業をするだけなので、エキスパートシステムにより代替できると考えられていました。たしかに簿記の範囲であればルール化は容易ですが、決算書作成の段階では人間の判断が必要で、かつ会計基準が業種業態により異なるためルール化は非常に困難です。現在でも、簿記会計の自動化は可能であるものの会計監査の自動化は不可能であるといわれています。

専門知識のルール化を多層ニューラルネットワークで自動化する試みもされましたが、当時は前述のとおり、そのための大量データと膨大な計算を行う超高性能なコンピューターが存在せず、実現することはありませんでした。こうして失意のもと第二次AIブームは終焉を迎えたわけです。

エキスパートシステムの現在と未来。

では、エキスパートシステムの現状はどうなっているのでしょうか。すっかり廃れているのでしょうか。実は、そんなことはまったくありません。

第三次AIブームに便乗する形で、AI搭載を謳う製品やサービスが雨後の筍のごとく次々とリリースされています。その中でも、とりわけ画像処理関連のものの多くは深層学習をベースにしているようですが、それ以外ではエキスパートシステムをベースにしていることも多いように思われます。深層学習とは違い、明確にそれが謳われることがなく存在感が薄いだけで、実用化は確実に広がっています。

そもそも深層学習が具現化されたのは、ビッグデータの普及とコンピューターの進化によるものですが、その恩恵を受けたのはエキスパートシステムも同じです。従来環境では難しかった複雑な推論処理が可能となり、知識のルール化の自動化の可能性も高まっています。

また深層学習には、大量の学習データが必要である、導出されたモデルがブラックボックス化するなどの欠点があります。さらに、エキスパートシステムにはない例外を学習できるという特長があるものの、その反面として過学習による汎化性能低下の問題があり、エキスパートシステムの欠点を克服して代替する存在には至っていません。

そのような背景もあり、いま現在において深層学習が実用化されているのは、大量の学習データを獲得しやすく、かつモデルを単純化しやすい画像処理などの一部の領域に限られており、エキスパートシステムの進化が期待されている領域は多く存在します。

そのひとつに、教育業界で注目されている適応学習があります。適応学習（Adaptive Learning）は、学習者一人ひとりの学習進捗度に最適化された学習方法と学習教材を選択して提案するためのロジック・システム・サービスなどを包括的に指し示す言葉です。とりわけ算数や数学は効率的に学習するための教育体系が確立されており、エキスパートシステムがもっとも得意とする領域と言えるでしょう。

ではスポーツはどうでしょうか。たとえばゴルフは教育体系が確立されており、かつ他者に影響を受けづらい競技であるため、エキスパートシステムを適用しやすい領域と言えます。

一方でサッカーは、対戦相手のみならずチームメンバーにも影響を受けるため、意思決定プロセスが複雑でルール化が難しく、適用しづらい領域と言えます。ただ、ボールを蹴る・止めるなどの基本技術については適用できそうです。実践技術においても「ディフェンシブサード右サイドでの一対一」や「アタッキングサード中央でのボール奪取」などの”局面”で因数分解できれば適用される可能性があります

また、スポーツには”動き”という自然言語での記述が難しい専門知識が存在します。しかしながらこれはモーションキャプチャーというセンシング技術の進化により克服されており、ゲームなどでプロサッカー選手の動きが再現されています。

さらに5GとIoTの普及により、”動き”などの自然言語記述が難しいものも含めた専門知識が世界中でルール化され、共有される可能性があります。それがWikipediaのように民主的にマネジメントされれば、エキスパートシステムは三つの欠点を克服し、さらなる実用化が進むかもしれません。

2019年3月、アメリカの名門大学への大規模な裏口入学が発覚し、大きな話題となりました。当事者の多くは富裕層で、大企業の最高経営責任者や有名女優が含まれるとのことです。なお、入学先にはイェール大学・スタンフォード大学・ジョージタウン大学などが含まれますが、大学側の関与はないようです。

子どもを名門大学に入学させたい親の心理を考えると、ある問いが思い浮かびます。それは「偏差値の高い大学へ行けば収入は上がるのか」というものです。もっともこの事件においては、当事者の多くは富裕層であり、目的は収入ではなく名誉かもしれません。

この問いに対し、多くの人が「はい」と答えるのではないでしょうか。確かに富裕層には高学歴な人が多いように思います。しかしながら、経済学の有力な研究は、これを否定しています。それでも多くの人が「はい」と答えるのは、相関関係と因果関係を混同しているからに他なりません。

相関関係（Correlation）とは、二つの事象に何らかの関係があることをいい、因果関係と疑似相関に大別されます。二つの事象の片方が原因となって、もう片方が結果として生じた場合、事象間に因果関係（Causation）があるといいます。一方で、原因と結果の関係ではない場合は疑似相関（Spurious Correlation）と呼ばれます。

そして、二つの事象間に因果関係があるかどうかを明らかにするための考え方や手法を因果推論（Causal Inference）といいます。聞きなれない言葉なので「いまさら聞けない」というタイトルはやや不適切ですが、実はビジネスの現場でも、グロースハック（Growth Hack）¹⁾いまさら聞けないグロースハックやカイゼン（Kaizen）の領域で、A/Bテストという形で広く使われています。

第三の要因はないか。

事象Xが原因で、事象Yが結果であるという因果関係の存在を確認するためには、三つのチェックポイントがあります。

1. 偶然の一致ではないか
2. 逆の因果関係ではないか（事象Yが原因で、事象Xが結果ではないか）
3. 第三の要因は存在しないか（第三の事象Zが、事象Xと事象Yの原因ではないか）

「地球温暖化が進むと、海賊の数が減る」これはパロディ宗教である空飛ぶスパゲッティ・モンスター教が、相関関係と因果関係の混同を風刺するのに用いた例です。統計的な一致が見られたとしても、因果関係があるとは思えません。これは偶然の一致であり、見せかけの相関と呼ばれます。

「警察官の多い地域では、犯罪も多い傾向にある」と言われています。しかしながら、警察官が多いことが原因で、犯罪発生件数が多いという結果を引き起こすとは考えづらいでしょう。むしろ犯罪が多い危険な地域であるがゆえに、警察官を多く配置していると考えるべきです。これは逆の因果関係と呼ばれます。

「体力がある子どもは学力が高い」と言われています。では、子どもに運動させることが学力向上につながると考えてよいでしょうか。もちろん、体力がつくことで長時間の勉強に耐えられるなどの効果があるかもしれません。ただ、学力向上にはもっと効率的な手段があるでしょう。むしろ体力にも学力にも影響を及ぼしている第三の要因があるように思えます。例えば「親の教育熱心さ」などがそれです。これは交絡因子（Confounding Factor）と呼ばれます。

では冒頭の問い「偏差値の高い大学へ行けば収入は上がるのか」についてはどうでしょうか。まず何らかの関係があることは間違いないため、偶然の一致ではないでしょう。また多くの人は大学卒業後に働き始めるため、逆の因果関係があるとも思えません。では第三の要因はどうでしょうか。「潜在能力の高さ」が、偏差値の高い大学に行く力と、高い収入を得る力の両方を生み出しているとは考えられないでしょうか。

反事実との比較による証明。

二つの事象間に因果関係があることを証明する手法に、事実と反事実の比較があります。反事実（Counterfactual）とは、その事象が発生しなかった場合のことです。そして、原因の事象Xが発生したという事実における結果の事象Yと、原因の事象Xが発生しなかったという反事実における結果の事象Y’を比較し、有意差（Significantly Different）が見られる場合に因果関係があると結論づけます。この場合の有意差とは、事象Yと事象Y’の間の統計的に偶然とはいえない差のことで、それを因果効果（Causal Effect）といいます。また、事実と反事実の比較により因果関係を説明することを反事実モデル（Counterfactual Model）といいます。

反事実モデルの代表的な手法に、ランダム化比較実験（Randomized Controlled Trial：RCT）があります。たとえば新薬の臨床試験において、病気のネズミを無作為に二つのグループに分け、片方のグループにのみ投薬したとしましょう。そこで投薬したグループのほうが治癒率が高ければ、因果効果があると言えます。なお、投薬したグループを介入群（Intervention Group）、投薬しなかったグループを対照群（Control Group）といいます。またランダム化比較実験は、ビジネスの世界ではA/Bテストと呼ばれています。

ところで、二つのグループを無作為に分けたのはなぜでしょうか。それは比較する二つのグループの間に介入した事実以外の違いが存在すると、違いを生んだ原因がどちらであるかを説明できなくなるからです。

ランダム化比較実験には極めて高い証明力があるものの、実験ができない場合には適用できません。実験には時間やコストもかかります。実験対象となる人や企業を人為的に無作為に分けることは簡単ではありません。介入群と対照群に不公平があれば反発も起こるでしょう。前述の臨床試験には倫理的な問題もあります。

実験ができない場合は、すでにあるデータを用いる他ありません。なお、実験で獲得したデータを実験データ（Experimental Data）と呼ぶのに対し、日常の活動から獲得したデータを観察データ（Observational Data）といいます。すなわち、観察データを用いて反事実モデルを実施することになります。それには観察データ内に原因と考えられる事象の反事実が存在する必要があります。

たとえば、新商品の案内メールをすべての顧客に送信したはずが、メール配信システムの障害で一部の顧客に送信されていなかったとします。これは観察データ内に反事実が偶然発生している状態であり、送信された顧客と送信されなかった顧客の購買の結果を比較することで因果推論が可能です。この状態を自然実験（Natural Experiment）といいます。

しかしながら、自然実験の状態が都合よく発生するわけではなく、またそれを観察データから見つけることも容易ではありません。そこで、観察データと統計手法を用いて、あたかもランダム化比較実験を実施しているような状態を作り出す、疑似実験（Quasi Experiment）という考え方があります。統計手法には、差の差分析・操作変数法・回帰不連続デザインなどがありますが、ここではマッチング法による疑似実験のアプローチを紹介します。

マッチング法とは、介入群によく似たペアを対照群から選び出すことにより、介入した事実以外の違いを排除することで、二つのグループを比較可能にする手法です。そして冒頭の問い「偏差値の高い大学へ行けば収入は上がるのか」を、この手法で否定したのが、プリンストン大学のアラン・クルーガーらによる研究です。

クルーガーらは、それぞれの学生がどの大学に合格し、どの大学に不合格だったかのデータを用いてマッチング法を実施しました。たとえば、大学Aと大学Bには合格したが、大学Cには不合格だった二人がいたとすると、この二人はよく似たペアと言えます。そのうちの一人は偏差値の高い大学Aに、もう一人は立地のよい大学Bに進学した場合、この二人を比較すれば、偏差値の高い大学へ行くことによる将来の収入への因果効果を推定できることになります。

この研究の結果、偏差値の高い大学Aに進学した学生のグループ（介入群）と、偏差値の低い大学Bに進学した学生のグループ（対照群）の間で、大学卒業後の収入に有意差が見られないことがわかりました。多くの人が「偏差値の高い大学へ行けば収入は上がる」と信じていたことが否定されたわけです。

このように、因果推論を駆使すれば、二つの事象間の因果関係の有無を明らかにすることができ、相関関係との混同や思い込みから解放されます。

最後に、この記事を書くにあたり、中室牧子氏・津川友介氏による著書『「原因と結果」の経済学―データから真実を見抜く思考法』を参考にさせていただいたことをお伝えします。因果推論を詳しく知りたい方には大変お薦めです。

データマイニング（Data Mining）は、統計学や人工知能（Artificial Intelligence：AI）などの手法を使って大量のデータから知識を取り出す技術のことで、文字通り知識を採掘（Mining）するイメージです。

このデータマイニングという技術や言葉が普及するきっかけになったのが、有名な「おむつとビール」の話です。1992年に大手スーパーマーケットチェーンのOsco DrugsがPOSデータを分析したところ、おむつとビールが併売されることが多いことがわかりました。このような併売傾向を分析する技術を、買い物かごにみたててバスケット分析（Basket Analysis）といい、事象間の相関の強さを分析する技術であるアソシエーション分析（Association Analysis）¹⁾アソシエーション分析入門の、マーケティング領域における代表的な実用例となっています。

同じくマーケティング領域においては、1to1マーケティングとよばれる、数百万人の顧客をいくつかのセグメント（似た者同士）に細分化し、それぞれのセグメントに対して個別にマーケティング施策を行うことで、ビジネス成果を最大化するアプローチがありますが、このセグメントの分類手法として、教師なし機会学習の代表手法でもあるクラスタリング（Clustering）²⁾いまさら聞けない機械学習がよく用いられます。

データマイニングの手法や技術の多くは、機械学習と一致します。ビッグデータ化にともなう機械学習の進化は、すなわちデータマイニングの進化を意味します。一方で、データマイニングという言葉の盛り上がりは、かつて2000年代中頃にあったものより鎮静化しているように思います。それはなぜなのでしょうか。そして今後はどうなるのでしょうか。再考してみたいと思います。

データマイニングへの期待と失望。

データマイニングのもつ価値は、前述の「おむつとビール」の話に代表されるように、想像もしていなかった知識を発掘することにあります。まさか、おむつとビールがよく併売されるとは思わないからです。このことが、データマイニングの期待を高めることになるわけですが、同時に期待を裏切ることにもなります。

期待を裏切るポイントは大きく二つあります。ひとつは、想像もしない知識が発掘されたとして、実際の施策に展開しづらいことが多いこと。もうひとつは、結果として想像の範囲内の知識しか得られないことが多いことです。

前者については、これも「おむつとビール」が典型例です。おむつとビールが併売されることがわかったとして、実際に同じ売り場に置くわけにはいきません。もっとも、おむつ売り場とビール売り場の動線上に、さらに併売傾向が見られる商品をうまく配置する、などの施策につながる可能性はあります。

やっかいなのは後者で、そもそもデータの中に想像もしない知識が埋もれているという保証はありませんし、あったとして、大量のデータからそれを拾い上げるのは非常に困難です。分析結果に何らかの知識が隠されていたとしても、結局それを解釈するのは人間であり、そこには深い経験と膨大な労力がかかります。魔法の杖のように自動的に知識がもたらされるという幻想をいだいていると、必ず期待を裏切られることになります。このことが、データマイニングという言葉の盛り上がりを鎮静化させた要因です。

重要なのはスパイラルモデル。

データ分析には大きく、検証的アプローチと発見的アプローチの二つのアプローチがあります。検証的アプローチとは、あらかじめ存在する仮説が正しいかを検証することで、例えば、あるコンテンツXの閲覧とある商品Yの購入に因果関係があるのではないか、という仮説を、実証実験などで検証するアプローチがこれです。この仮説検証を繰り返すことで分析精度が上がるわけですが、欠点が二つあります。ひとつは、もともとの仮説の精度が低いと、仮説検証に膨大なコストがかかること。もうひとつは、想像の範囲内の仮説しか立てられないことです。

この検証的アプローチの欠点を補うのに、発見的アプローチが有効となります。発見的アプローチにより、比較的精度の高い仮説を抽出できたり、想像の範囲を超える仮説を発見できることがあります。つまり、この二つのアプローチは、どちらをとるべきか、ではなく補完関係にあり、行き来しながらスパイラルモデルを描くことで、効率的に分析精度を高めることができます。そして、この発見的アプローチに有効な手法こそがデータマイニングなのです。

ビッグデータ化により、大量であることはもちろん、多様なデータが収集可能となりました。その中で、一部の人間の経験や能力に頼った仮説設定は、本当に重要な要素を見逃す危険性を高めてしまうでしょう。そこでデータマイニングは有益なヒントを与えてくれる可能性があります。かつてデータマイニングに幻想と失望をいだいたのであれば、その観点で見直してみるのはいかがでしょうか。

ビッグデータ（Big Data）という言葉は2013年に流行して以来、広く使われています。日々大量のデータが生産されており、5GとIoTの普及でさらに加速することが予想されます。また時を同じくして、人工知能（Artificial Intelligence：AI）や深層学習（Deep Learning）の技術が世間を賑わすようになりました。深層学習は大量の教師データを必要とする学習技術であり、ビッグデータの存在が実現に向かわせたと言っても過言ではありません。

ところで、ビッグデータとは何でしょうか。文字通り大きなデータのことでしょうか。だとして、大きなデータとはどういうものでしょうか。また、大きなことの意味は何でしょうか。逆に、スモールデータとは何でしょうか。それらの意味は時代とともに変化するのでしょうか。いろいろな素朴な疑問が湧いてきます。ブームから5年以上が経過し、5GとIoTによる変化の兆しが見え隠れする今、再考してみようと思います。

まずビッグデータの意味ですが、大量データであることはもちろんのこと、実はそれだけではありません。IT用語辞典には以下のようにあります。

ビッグデータとは、従来のデータベース管理システムなどでは記録や保管、解析が難しいような巨大なデータ群。明確な定義があるわけではなく、企業向け情報システムメーカーのマーケティング用語として多用されている。
多くの場合、ビッグデータとは単に量が多いだけでなく、様々な種類・形式が含まれる非構造化データ・非定型的データであり、さらに、日々膨大に生成・記録される時系列性・リアルタイム性のあるようなものを指すことが多い。今までは管理しきれないため見過ごされてきたそのようなデータ群を記録・保管して即座に解析することで、ビジネスや社会に有用な知見を得たり、これまでにないような新たな仕組みやシステムを産み出す可能性が高まるとされている。

IT用語辞典｜ビッグデータ

どうやら量以外にも、種類や形式がごった煮状態で整理整頓されていないという意味も含まれているようです。逆にいえば、世の中のデータの多くは種類や形式がバラバラで整理整頓されておらず、量を求めると必然的にごった煮状態になるということです。

分散処理技術の進化による後押し。

整理されていなければ、データ分析は困難になります。ではデータ生成に関するルールを作ればよいのでは、ということになり、実際に標準化の動きもありますが、容易ではありません。そこで重要になるのが、データを分析可能な状態に整える作業や、それを自動化する技術です。それをデータ準備（Data Preparation）といいますが、いま現在でも発展途上にある領域です。

深層学習は非常に注目され、かつ進化している学習技術ですが、大量の教師データを必要とするため、データ量がボトルネックになりがちです。そもそもどうやってデータを獲得するのかという問題があり、データ流通（Data Trading）¹⁾データ流通って？などのソリューションが検討されていますが、よしんば集めたところで分析不可能なデータが大量にあってもどうしようもありません。データ準備は非常にやっかいな問題で、深層学習を代表とするビッグデータを活用したデータ分析や機械学習の発展を阻害する大きな要因のひとつになっています。

一方で、整理されていたとしても、大量のデータを高速に処理できなければ実用には向きません。ただ、これについてはコンピューターの性能向上と、Hadoopを代表とする分散処理技術の進化が実現を後押ししています。Hadoopは、大量のデータを複数のマシンで分散処理できるオープンソースのプラットフォームで、ペタバイト級の非構造化データ（テキストや画像など）の超高速処理を可能にしました。逆にいえば、Hadoopの登場がビッグデータ活用の推進に拍車をかけたといえます。

大きいことはいいことか？

ビッグデータの意味や、その活用が進んだ背景はわかりましたが、そもそもデータが大量であることの意味はどこにあるのでしょうか。大きいことはいいことなのでしょうか。

ビッグデータがもたらした最大の価値は、深層学習を代表とする機械学習の進化でしょう。また、マーケティング領域では、1to1マーケティングとよばれる、数百万人の顧客をいくつかのセグメント（似た者同士）に細分化し、それぞれのセグメントに対して個別にマーケティング施策を行うことで、ビジネス成果を最大化するアプローチがありますが、それには大量データのノンサンプリングでの分析が必要となり、ビッグデータの分析技術や、ビッグデータそのものがもたらす意味は大きいと言えます。

一方で、ビッグデータは購入・転送・計算などのあらゆる面で膨大なコストがかかります。また、大量であるがゆえに本当に重要なデータが埋もれてしまうリスクもあります。ビッグデータを活用した機械学習は、導出された予測モデルのメカニズムがブラックボックス化して説明しづらくなるという欠点があることは、「UXモデリングって？」でも触れたとおりです。

そこで、最近注目されているのが、スモールデータ（Small Data）です。「スパースモデリング って？」でも取り上げたとおり、物事の本質的な特徴を決定づける要素はわずかであるという性質があります。それをスパース性といいますが、その要素をうまく取り出すことができれば、必ずしも大量である必要はないわけです。そして、データが少量であれば、重要なデータが埋もれることもありません。また、コストも最小限に抑えることができます。

ただし、もとのデータに著しい偏りがあると、本質をとらえるのに重要な要素を獲得することはできません。つまり、大量であることよりも、多様であるという意味でのビッグデータは極めて重要であり、5GとIoTの普及により、今後はその期待がさらに高まるのではないかと考えられます。

条件分岐はif文のみ。

Pythonの基本的な構文に、条件分岐と繰り返しがあります。これは他のプログラミング言語でもほぼ共通して存在するものです。

条件分岐（Conditional Branch）とは、条件により処理を分岐させることをといい、if文を用います。C/C++などに存在するswitch文はPythonには存在しません。一般的に、分岐が少ない場合はif文、分岐が多い場合はswitch文を使うことが多いですが、Pythonではすべてif文で記述します。switch文は分岐をシンプルに表現できますが、Pythonでは辞書を使ってif文をシンプルに表現できます。

if文は以下のフォーマットで記述します。elif文はいくつでも入れることができます。

if 条件式1:
    条件式1が真の場合の処理
elif 条件式2:
    条件式1が偽で条件式2が真の場合の処理
else:
    すべての条件式が偽の場合の処理

if文のサンプルコードは以下のとおりです。

なお、条件式は「x == 1」のように記述しますが、この「==（等しい）」を比較演算子といい、他には「!=（異なる）」「>（大なり）」「<（小なり）」などがあります。また、複数の条件式を「and（論理積）」「or（論理和）」などの論理演算子で組み合わせることが可能です。

条件と処理を添字と値で表現できる場合は「dict = {1:”A”, 2:”B”, 3:”C”}」のような辞書を定義することで「if x in dict: print( dict[ x ] )」のようなシンプルな構文で記述することができます。ここでの「in」はin演算子といい「変数 in イテラブルオブジェクト」のフォーマットで記述することで、リストやタプルなどのイテラブルオブジェクト（要素を順番に取り出すことのできるオブジェクト）から順に要素を取り出して変数に代入します。

またif文は、条件式をヘッダ（Header）、条件式にひもづく処理をスイート（Suite）とする二つの部分に分けられます。このようなヘッダとスイートの組合せからなる構文を複合文 といいます。

Pythonでは、複合文のヘッダの行末のコロン「:」とスイートの各行の行頭のインデント（スペースまたはタブ）の記述が必須となります。また、同じ複合文内のインデント量は揃える必要があります。こういった記述ルールを守らないと実行時にエラーとなるわけですが、この厳格なルールがPythonの可読性を高める要因のひとつになっています。

繰り返しはfor文またはwhile文。

繰り返し（Loop）は、同じ処理を自動的に複数回実行することをいい、for文またはwhile文を用います。

for文は以下のフォーマットで記述し、リストやタプルなどのイテラブルオブジェクトから順に要素を取り出して変数に代入し、要素の数だけ処理を繰り返し実行します。ここでの「in」は前述のif文と同様のin演算子です。

for 変数 in イテラブルオブジェクト:
  処理

while文は以下のフォーマットで記述し、条件式が真の場合に処理を繰り返し実行します。

while 条件式:
  条件式が真の場合の処理

なお、for文もwhile文も複合文となるため、前述のヘッダとスイートの記述ルールを守る必要があります。サンプルコードは以下のとおりです。

また、Python特有の記述方法にリスト内包表記があり、for文を以下のフォーマットで記述します。

変数Y = [ 処理 for 変数X in イテラブルオブジェクト ]

リスト内包表記でのfor文のサンプルコードは以下のとおりです。

リスト内包表記を使うことで、for文で繰り返し処理をした出力をそのままリスト型の変数に代入することが可能となります。また、記述が非常にシンプルになるため、Pythonの可読性を高める要因のひとつになっています。

強力な拡張モジュール。

さて、ここまではPythonの基本機能の説明でしたが、PythonにはNumPy・Pandas・scikit-learnなど数多くの強力なデータサイエンス向け拡張モジュールがあり、それらの機能を利用することで生産性は飛躍的に向上します。

利用するには、モジュールの読み込みが必要で、以下のフォーマットで記述します。なお、モジュール名には任意の別名をつけることができます。また、モジュール内の特定のクラスのみをインポートすることも可能です。

import モジュール名 as 別名
from モジュール名 import クラス名

試しにNumPyとPandasを使ってみます。以下の例のように、NumPyは「np」、Pandasは「pd」という別名をつけることが一般的です。

最後に、データサイエンスでよく利用する拡張モジュールをいくつかご紹介しておきます。いろいろなウェブサイトやGitHubでサンプルコードが提供されているので、それに倣えばある程度は実装できるかと思います。ただ、これまでに説明した基本機能をしっかりと把握していないと、細かいところで必ずつまづきます。何事も基礎が大切ということですね。

リストは配列。

Pythonには基本的なデータ構造として、リスト・タプル・辞書があります。他のプログラミング言語でいうと、リストとタプルは配列、辞書は連想配列にあたります。配列は、同じ型の複数の値（Value）を、添字（Key）と一つの変数により管理する仕組みのことで、添字が0から始まる連続する整数の場合を配列（Array）、添字が任意の数値や文字列の場合を連想配列（Associative Array）といいます。

リスト（List）は、添字に0から始まる連続する整数をもつ配列です。以下の例の「list = [ 1, 3, 5, 7 ]」ように、括弧「[]」で括られた中にカンマ「,」区切りで値を指定し、変数に代入することで作成します。値は数値と文字列のいずれも許容されます。ちなみに「u’東京都’」のように、文字列の前に「u」とありますが、これはマルチバイト文字をユニコード指定する場合に用います。

なお、添字は0からの連続する整数が自動で割り振られるため指定はしません。また、ほとんどのプログラム言語では、配列の添字は0から開始しますが、例外としてR言語の配列の添字は1から開始するため注意が必要です。

リストの中の値を参照するには「list[0]」のように変数[添字]の形で指定します。ここでは「list[0], list[1]…」のように列記していますが、添字が連続する整数であるという特性を活かして、for文やwhile文などの繰り返し文を使って自動化できます。こちらについては次回の記事で説明します。

また「list[1:3]」のように、連続する添字の一部をスライス（切り出し）することもできます。この場合は、添字の1から3の直前（つまり2）までを切り出すという意味になります。

タプルはイミュータブルな配列。

タプル（Tuple）は、リストと同じく添字に0から始まる連続する整数をもつ配列です。以下の例の「tuple = ( 1, 3, 5, 7 )」ように、括弧「()」で括られた中にカンマ「,」区切りで値を指定し、変数に代入することで作成します。タプルの中の値を参照するには「tuple[0]」のように変数[添字]の形で指定します。また「tuple[1:3]」のように、連続する添字の一部をスライス（切り出し）することもできます。

これだけみると、リストとの違いはありませんが、タプルには以下のような特徴があります。

• 要素が追加・削除・変更ができない。
• 要素をくくる括弧は「()」を使用する。
• 使用メモリがリストに比べて小さい。
• 多くの場合でリストよりタプルの方が早く演算できる。

ちなみに、要素の追加・削除・変更ができないことをイミュータブル（Immutable）といい、プログラムを共同開発する際に、変数の値を勝手に変えられないようにしたい場合に有用です。対して、リストは要素の追加・変更・削除が可能であり、ミュータブル（Mutable）といいます。また、リストとタプルはlist()関数とtuple()関数を使って相互に変換できます。

辞書はキーバリュー型データベース。

辞書（Dictionary）は、添字に任意の数値または文字列を指定する連想配列です。以下の例の「dict = { 13:u’東京都’, 27:u’大阪府’, … }」のように、括弧「{}」で括られた中にカンマ「,」区切りでコロン「:」をはさむ形で添字と値を指定し、変数に代入することで作成します。添字と値ともに数値と文字列のいずれも許容されます。辞書の中の値を参照するには「dict[0]、dict[u’東京都’]」のように変数[添字]の形で指定します。添字に任意の数値や文字列を利用できるため、キーバリュー型のデータベースのような使い方ができます。

このように、リスト・タプル・辞書にはそれぞれの特徴があるため、それらを理解した上で、用途に合わせて使い分けていく必要があります。

次回は「ColabではじめるPython」最終回、条件分岐と繰り返しについて簡単に触れていきます。

四則演算は算数と同じ。

簡単なPythonプログラミングをやってみます。まずはColabにアクセスしましょう。なお、Colabの使い方は「ColabではじめるPython #01」を参照してください。ログインして、メインメニューの［ファイル］から［Python 3 の新しいノートブック］を選びます。

以下のように、加算・減算などの四則演算ができることがわかります。「+, -」などを代数演算子といいます。なお、除算は「/」を使いますが、小数点以下を切り捨てたい場合は「//」、剰余（あまり）を出したい場合は「%」を使います。

四則演算の計算の優先順位を確認しておきます。といいつつ、算数と同じです。加算・減算よりも乗算・除算が優先され、下記の「四則演算の優先順位１」のような計算結果になります。また、括弧でくくられた部分が優先され、下記の「四則演算の優先順位２」のような計算結果になります。

変数と関数。

これまでの四則演算で記述していた「10」や「3」などは静的（Static）な値であり、これを定数（constant）といます。一方で、プログラミングでは動的（Dynamic）な値を計算することができ、その値を変数（Variable）といいます。

以下の例でいうと、xやyが変数です。また「x = 10、x = ‘Hello, ‘」のように変数に値を入れることを代入といい、「=」を代入演算子といいます。変数に数値を代入して加算すると数値を加算した結果が、変数に文字列を代入して加算すると文字列を連結した結果が、それぞれ得られます。

ちなみに print (X)は、入力値Xの内容を出力するという関数です。関数とは、与えられた入力値で固有の処理を行い、その結果の出力値を返すプログラムのことです。与えられた入力値を引数、返された出力値を戻り値といいます。この場合の引数は「x + y」で、戻り値は「13」や「Hello, World!」です。また、print()関数のようにあらかじめ用意されているものもありますが、自分で任意に作ることもできます。あらかじめ用意された関数を集めたものを関数ライブラリといいます。

オブジェクトとクラス。

Pythonはオブジェクト指向のプログラミング言語です。オブジェクト指向プログラミングは、プログラムを処理手順＝手続き（Procedure）ではなく、モノ＝オブジェクト（Object）とみなし、それぞれのオブジェクトに役割をもたせて分業するスタイルのプログラミング手法です。一方で、処理手順をもとにしたプログラミング手法を手続き型プログラミングといいます。

オブジェクトは、変数と関数から構成されます。クルマでたとえると、「エンジン・ハンドル・タイヤ」などが変数で、「エンジンを起動する・ハンドルの操作に合わせてタイヤを動かす」などが関数にあたります。

また、同じクルマを量産するためには設計図が必要ですが、オブジェクト指向プログラミングではその設計図をクラス（Class）といいます。そのクラスをもとに生成された各オブジェクトをインスタンス（Instance）といいます。また、クラスで定義された関数をメソッド（Method）といいます。

これらの概念や言葉はピンとこないかもしれません。また「Colab ではじめるPython」では深くは扱いません。しかしながら、Pythonプログラミングを進める上では必須のものになりますので、頭の片隅に入れておいてもらえればと思います。

次回は、リスト・タプル・辞書というデータ構造の概念について簡単に触れていきます。

インストールなしで、そのまま。

Pythonでデータサイエンスに入門したいけど敷居が高い、そう感じている方も多いと思います。実は、Pythonは他のプログラミング言語と比べて学習コストが低いと言われています。文法がシンプルで、汎用性と可読性が高いことがその理由です。また、C/C++のような変数宣言やコンパイルも必要ありません。実際に使えばわかります。

とはいえ最初に立ちはだかる壁は環境準備です。本格的なプログラム開発を行う場合はPyCharmなどの統合開発環境（Integrated Development Environment：IDE）が便利ですが、手軽ではありません。Jupyter NotebookはブラウザUIの対話式プログラム実行環境で、手軽に扱えるもののインストールが面倒です。Google Cloud DatalabはJupyter NotebookベースのPython実行環境のクラウドサービスで、インストールなしで使うことができますが、利用料がかかるためトレーニングには向いていません。

そこでおすすめしたいのが Google Colabです。Google Colabは、Jupyter NotebookベースのフルマネージドなPython実行環境で、Googleが機械学習の教育や研究のために無償提供しているものです。利用するには、Google ColabのURLにアクセスし、Googleアカウントでログインするだけです。Googleアカウントをすでにお持ちであれば、すぐに始められます。

まずはお約束の「Hello, World!」

では、さっそくGoogle ColabでPythonをはじめてみましょう。Google Colabにアクセスしてみてください。検索エンジンで「Google Colab」と検索してもらっても結構です。すると、以下の画面が表示されるので、あとはご自身のGoogleアカウントでログインするだけです。

ログインできたら、メインメニューの［ファイル］から［Python 3 の新しいノートブック］を選びます。表示される画面に、以下のような入力エリアがあるかと思います。ここにソースコードを記述して左端の［▶︎］ボタンをクリックするか、Macであれば［⌘+Enter］キー、Windowであれば［Ctrl+Enter］キーでプログラムを実行できます。

ひとまず、お約束の「Hello, World!」を表示するプログラムを書いてみましょう。入力エリアに「print (‘Hello, World!’)」と記述し、実行してみてください。以下のように「Hello, World!」が出力エリアに表示されるかと思います。

続けて、簡単な計算をしてみましょう。入力エリアに「1 + 1」と記述し、実行してみてください。以下のように「2」が出力エリアに表示されるかと思います。こんな具合に、とても手軽にPythonプログラミングを楽しむことができるわけです。

あくまでトレーニング用。

Pythonプログラミングの実践については次回以降にするとして、この記事の最後にGoogle Colabの特長と制約をまとめておきます。まず特長は以下のとおりです。

• インストール不要で、無料で利用可能。
• ブラウザUIの対話式プログラム実行環境で非常に手軽。
• クラウドの高性能なCPU・GPU・TPUを利用可能。
• メジャーな機械学習系ライブラリがインストール済み。
• GitHubおよびGistとの連携が簡単。

一方で、いくつかの制約事項や欠点があります。あくまで教育・研究用の無償サービスであると考えたほうがよいでしょう。

• プログラム実行やデータ保存がパブリック領域でなされるため、秘匿性の高いデータを扱うことができない。
• ノートブックのセッション切れが90分続くとインスタンスがシャットダウンされる。また、新しいインスタンスを起動してから12時間経過するとインスタンスがシャットダウンされる。
• 機械学習向け以外のライブラリが少ない。（ただし、追加インストールは可能）

では次回以降で、Pythonプログラミングの実践に踏み込んで行きたいと思います。

セルフサービスなDWH。

データウェアハウス（Data Warehouse：DWH）は、直訳すれば「データの倉庫」で、データベース（Database：DB）の一種ですが、過去すべての時系列データを要約せずにそのまま保持し続ける、文字通り倉庫のような役割から、区別してそう呼ばれています。

また、DWHはデータを活用した意思決定に利用されることから、ビジネスインテリジェンス（Business Intelligence：BI）のひとつに位置付けられます。BIは経営・会計・情報処理などの用語で、企業などの組織のデータを収集・分析・可視化することで、ビジネスの意思決定に役立てる手法や技術のことを言います。

DWHを利用するのは商品開発やマーケティングなどの部門ですが、基幹データを扱うことから、管理するのは情報システム部門であることがほとんどです。管理部門がDWHのデータ設計と実装を行い、分析可能な状態にして利用部門に提供するのが一般的な役割分担です。一方で、利用部門が分析を進める中で、データ構造を変更したいという要求がうまれるものの、自分たちでそれを実施できないため、分析や意思決定のスピードが上がらないこともよくあります。

そこで、利用部門が管理部門に頼ることなく、自分たちでデータの分析・可視化に必要な環境を構築するセルフサービスBIという考え方が生まれました。その中でも、とりわけDWHに特化したクラウドサービスとして、いま人気を二分しているのが、Google BigQuery（以下、BigQuery）とAmazon Redshift（以下、Redshift）です。

ツールのBigQuery、基盤のRedshift。

BigQueryとRedshiftはそれぞれクラウドコンピューティングサービスであるGCP（Google Cloud Platform）とAWS（Amazon Web Services）の一部であり、フルマネージドなDWHです。GCPとAWSはよく比較されますが、サービスラインナップ¹⁾GCP・AWSサービス比較表としては同質化が進んでおり、いま現在はほぼ横並びといえます。

ただ、AWSがECサイトのAmazon.comのインフラのシェアリングを、GCPがGoogleの各種アプリケーションのエンジンのシェアリングをそれぞれルーツとしているため、それが特徴の違いを生んでいます。

サービス拡張の経緯にもそれは現れていて、IaaSについてはAWSは当初からAmazon EC2（Elastic Compute Cloud）として提供していましたが、GCPのGCE（Google Compute Engine）はかなり後発です。一方で、PaaSについてはGCPのGAE（Google App Engine）が先行しています。

また、導入されるケースの違いにも特徴があり、レガシーなインフラの置き換えには、インフラの導入実績が豊富なAWSが、ビッグデータ基盤の構築には、深層学習（Deep Learning）などの先進的なアプリケーションが充実したGCPが、それぞれ選ばれる傾向にあるように思います。

この特徴の違いがBigQueryとRedshiftにも引き継がれていて、GCPの一部であるBigQueryはアドホック分析のための分析ツール、AWSの一部であるRedshiftは既存のDWHを置き換えてセルフサービス化する分析基盤の性格が強いといえます。

用途に合わせた選択を。

BigQueryとRedshiftを、諸元レベルで比較してみます。

BigQueryの特徴をRedshiftとの比較で整理してみます。

• Redshiftと同じく、標準SQLに対応。
• Redshiftと同じく、大量データの集計に優れた列指向の格納方式を採用。
• テーブル名・カラム名のマルチバイト文字は非対応。
• ブラウザUIのクエリ実行環境を装備。
• 課金体系は、時間課金ではなくクエリ課金。（データスキャン量による従量課金）

BigQueryとRedshiftの共通点としては、標準SQLに対応した列指向DBであるということ。これにより、一般的なRDBと同様のSQLで、大量データの集計に優れた列指向DBとしてデータの操作が可能です。

BigQueryの特長は、ブラウザUIでクエリ実行が可能なのと、時間課金ではなくクエリ課金（クエリ時のデータスキャン量による従量課金）であるため、手軽にアドホック分析を行う分析ツールとして採用しやすいという点です。

一方で、時間課金ではないためにコストを見積もりづらいのと、テーブル名・カラム名のマルチバイト文字は非対応という欠点があるため、既存のDWHの置き換えには不向きであり、その場合はRedshiftのほうが採用しやすいでしょう。

ちなみにAWSには、ブラウザGUIのクエリ実行環境を備え、クエリ課金であるAmazon Athenaという、BigQueryと似たサービスもあるので、AWSユーザーは用途に合わせて選択することが可能です。ただしSQL互換エンジンのPrestoを採用しており、関数の体系が異なるため注意が必要です。

このようにBigQueryとRedshiftは、同じセルフサービスDWHでも特徴がかなり異なるので、用途に合わせて選んでもらえればよいと思います。