Navigation

2017年1月30日月曜日

概念と言葉と課題と答え

答えが問いを待っている(技術が課題を待っている)を読み、ITと哲学で私が考えている「ソリューションから課題を考える」という方法も有用に思う方は他にもいらっしゃるよね、ということを認識致しました。

以前、edXで受講した"User Innovation"というコースでも、(Re)frame your problem to fit your skillと、課題ありきというよりは、ソリューションを前提に課題を捉え直す(Reframe)するといったことが説明されていました。

User Innovation: A Path to Entrepreneurship | MITx on edX | Course About Video

CSMM.101x: Week 2: Intelligent Agents and Uninformed Search

edX ColumbiaXのAI(CSMM.101x) Week2のまとめですPythonコーディングの課題、なかなかの分量がありそうです。。。

日本語訳にあたっては、下記を参照しました。これもエージェントアプローチ人工知能 第2版をテキストとしており、購入したいところですが、いかんせん高すぎます。。。

Chapter2 intelligent agent(知的エージェント)
http://www.slideshare.net/soichiroinatani/chapter2-intelligent-agent

知的エージェント
http://www2c.comm.eng.osaka-u.ac.jp/~babaguchi/aibook/agent.pdf

2.1 Intelligent Agents
最初にAgentの定義が述べられています。

An agent is anything that can be viewed as:
 - perceiving its environment through sensors and
 - acting upon that environment through actuators


「センサーを通し置かれた環境を知覚し、その結果に基づき行動をおこすものをエージェントとする」といったところでしょうか。

Environment (環境のタイプ)
Deterministic (vs. stochastic)
Episodic (vs. sequential)
Static (vs. dynamic)
Discrete (vs. continuous)
Single agent (vs. multi-agent)
Known (vs. Unknown)

エージェントのタイプ
Simle reflex agents (単純反射エージェント)
- select an action based on the current state only ignoring the percept history
- are simple but limited
- can only work if the environment is fully observable, that is the correct action is based on the current percept only

Model-based reflex agents (記憶をもつ反射エージェント)
- handle partial observability by keeping track of the part of the world it can't see now
- have internal state depending on the percept history (best guess)
- have model of the world based on (1) how the world evolves independently from the agent and (2) how the agent actions affects the world

Goal-based agents (ゴール主導エージェント)
- are knowing the current state of the environment is not enough. The agent needs some goal information.
- combine the goal information with the environment model to choose the actions that achieve that goal.
- consider the future with "What will happen if I do A ?"
- are flexible as knowledge supporting the decision is explicitly represented and can be modified.

Utility-based agents (効率主導エージェント)
- sometimes achieving the desired goal is not enough. We may look for quicker, safer, cheaper trip to reach a destination. 
- agent happiness should be taken into consideration. We call it utility.
- a utility function is the agent's performance measure
- because of the uncertainty in the world, a utility agent choses the action that maximizes the expected utility.


2.2 Search Agents
サーチエージェントを用いることによって、現実世界での問題解決を行うことができるものがある。例:カーナビ

State spaceとsearch spaceの違い
State space: a physical configuration
Search space: an abstract configuration represented by a search tree or graph of possible solutions

探索木
- Root: initial state
- Branches: actions
- Nodes: results from actions. A node has: parent, children, depth, path cost, associated state in the state space.

探索空間は下記の三つに分類できる
1. Explored (a.k.a. Closed List, Visited Set) 探索済み
2. Frontier (a.k.a. Open List, the Fringe) 次に探索するもの
3. Unexplored: 未探索

Search strategies
* A strategy is defined by picking the order of node expansion
* Strategies are evaluated along the following dimensions:
- Completeness: Does it always find a solution if one exists ?
- Time complexity: Number of nodes generated / expanded
- Space complexity: Maximum number of nodes in memory
- Optimality: Does it always find a least-cost solution ?

* Time and space complexity are measured in terms of:
- b: maximum branching factor of the search tree (actions per state)
- d: depth of the solution
- m: maximum depth of the state space (may be infinite ) (also noted sometimes D).

2.3 Uninformed Search
1. Breadth-first search (BFS): Expand shallowest node
2. Depth-first search (DFS): Expand deepest node
3. Depth-limited search (DLS): Depth first with depth limit
4. Iterative-deepening search (IDS): DLS with increasing limit
5. Uniform-cost search (UCS): Expand least cost node

2.4 Uninformed Search Examples
BFS, DFS, UCSを用いて、どのように問題解決を行うのか、具体例とともに説明されている。

Week 2 Quiz: Uninformed Search
Uninformed Searchは知識なしの探索、知識を用いない探索と訳されるようです。
無知識探索だとニュアスンが異なるので、訳語として使用されていないんでしょうか。
AI agentの定義や、各探索アルゴリズムの特徴、探索アルゴリズムを用いた場合のグラフの読み解き等の設問がweek 2のQuizです。

DFS, BFS, UCSに関する設問は基本的特徴を答えるもので、難しくはありません。

与えられたグラフからポイントAからBに至るまでの道筋を、DFS, BFS, UCSを使用して回答する問題に関しては、実際に手を動かしながら回答するため、難しくはないものの手間がかかりました。

Week 2 Project: Search Algorithms
n-パズルゲームを解くコードをPythonで実装します。デットラインまで時間があるので、時間があるときにコーディングしてみます。

Week2: Discussion Questions
DQ1:
ダイクストラ法(DA)とUCSの違いについて説明されています。
なお、このアーティクルの筆者としてはUCSがほとんどの局面でDAより優れているので、DAを大学等で教えるのはもう止めては、と提言されています。
http://www.aaai.org/ocs/index.php/SOCS/SOCS11/paper/viewFile/4017/4357

DQ2:
お掃除ロボットがどのように機能しているかを学ぶために、下記の記事が紹介されています。
http://electronics.howstuffworks.com/gadgets/home/robotic-vacuum.htm
Roomba Redにどのようなセンサーがあるのか、そのセンサーを通し環境をどのように知覚し、お掃除を行っているのかの説明がされています。

https://blog.niallconnaughton.com/2016/01/25/roomba-algorithms-and-visualization/
http://robotics.stackexchange.com/questions/628/what-algorithm-should-i-implement-to-program-a-room-cleaning-robot
こちらの二つの記事はお掃除ロボットが最適なパスを見つけるためのアルゴリズムについて議論がされています。牛耕式 boustrophedon(日本語の発音ブストロフェドン)って言葉、日本語/英語ともに初めて知りました。

竹中工務店、消費電力管理のために機械学習を利用

竹中工務店、機械学習で予測誤差3%以下に
http://itpro.nikkeibp.co.jp/atcl/column/17/012500011/012500001/

「次回は、Azure MLの利用料が高く付き、それをどう乗り越えたかについて紹介する」と締めくくられています。利用料を上回るコストがカットできなければいけないでしょうし、どのように乗り越えたか気になります。

2017年1月28日土曜日

小島寛之『文系のための数学教室』 

積読状態だった小島寛之『文系のための数学教室』を読み直し、本日読了しました。



別途「社会人のための数学(再)入門」というページを作成しようと考えていまして、今手元にある数学入門書を読み漁っています。

私自身は志望大学の学部が文系だったため、高校で数学に関しては必要最低限しか勉強しておりませんでした。IT部門で働くにあたって必要となる数学的知識に関しては基本情報技術者試験受験の際に学んだもののみで、仕事に直結しないものの高校数学を学び直し、可能であれば大学レベルの数学も勉強したいなと考えていました。

そこで、下記のような数学入門本を購入し、読みかけては放り出したりしていたのですが、『TensorFlowで学ぶディープラーニング入門』で、その仕組みを根本から理解するには、やはり数学は必要不可欠だなと改めて思うに至り、仕切り直しでこれらの本を再読しはじめた次第です。

小島寛之『文系のための数学教室』
小島寛之『世界を読みとく数学入門 日常に隠された「数」をめぐる冒険』
矢野健太郎『数学の考え方』
吉田洋一・赤攝也『数学序説』
岡部恒治・本丸諒『まずはこの一冊から 意味がわかる微分・積分』

今回は小島寛之『文系のための数学教室』を取り上げ、他のものも読了したら、「社会人が数学を勉強しなおすにあったて、どの本がいいか、どのような方法がいいか」といったことを考えたいと思います。

まずは、タイトルにある「文系」という言葉に関しては、下記の方々と同様の考え方を私はもっています。大学受験等の制度は別の議論として、人を「文系」「理系」で分けるのは、あまり意味がないというか、むしろ害があるのではと。
(ちなみに同様に、右脳派、左脳派で分けるのみ意味がないと考えています)。

文系か理系かに分ける意味はない
http://fukaihanashi.hatenablog.com/entry/2016/07/28/150019

文系理系で人を分けるのは残念な人に見えるからやめた方が良い
http://www.02320.net/thinking-patterns/

とはいうものの、自身が受けてきた教育を「文系/理系」と分けることは一程度できるでしょうし、私自身もですが「文系教育」を受けてきた人にとって『文系のための数学教室』はお勧めの本です。(なお、著者の小島寛之氏も人の脳/考え方が文系/理系にデジタルに分かれるのではないはずと序章で述べています)。

「社会人のための数学(再)入門」という枠で本書を、私が位置付けるとしたら下記のようになります。
「一つ一つの概念について基礎から理解するよりも、その概念に関わる具体例や活用用法のfactを知る。そして、概念について根本から理解する際に、そのfactを援用する」小島氏の説明に従うと「数式を頭の中でなんらかの具体的なイメージに置き換える」ということです。

そのため、一つ一つの数式については、説明が省略されているところもあり、「なぜ、そうなるのか」と疑問が残ったままになります。数学入門書系の本を読んでいて、「であるからして、〜になる」と説明されているときの、「であるからして」が全く知識がない人にとっても理解できる程に十分にstep by stepに分解されていないと、このように「なぜ、そうなるのか」と理解できないケースが多いのですが、本書にもそのような箇所はあります。

別途、吉田洋一・赤攝也『数学序説』も読み進めているのですが、こちらでは、step by stepの説明の分解の粒度がかなり細かくなっており、時間はかかるものの「であるからして」の流れが明瞭に理解できるようになっています。

そういうこともあり、『文系のための数学教室』に関しては、現時点で自分がもっている知識によって、理解できるものと理解できないものがありました。

下記が本書の目次なのですが、序章の微積分や第1章、3章、4章は理解が進んだものの、第2章については、あまり理解できていません。他の入門書も読みながら気付いたのは、総じて私自身は代数については理解しやすいものの、幾何については理解しにくい、ということです。プログラムを書く中で、事象をy = f(x)の形に落とし込むのに慣れているので、代数については理解がしやすいのかなと思います。

序章  棒グラフで微分積分読解術
第1章 日常の論理と数学の論理
第2章 「距離」を規制緩和する話
第3章 民主主義を数学で考える
第4章 神の数学から世俗の数学へ
終章  数学は<私>のなかにある

とはいうものの、目次からもわかるように数式を理解するための「具体的なイメージ」がふんだんに説明されていますので、文系教育を受けてきた方で、もう一度数学を勉強し直したいと思っている方にはお勧めの一冊かと思います。

RegTech 規制のためのテクノロジー

規制のためのテクノロジーをさす「RegTech」という言葉が、昨年より注目され始めてきています。

新しいFinTechか? 「RegTech」が変える金融規制
https://innovation.mufg.jp/fintech/107

RegTech
http://fis.nri.co.jp/ja-JP/service/keyword/2016/201609.html

上記のNRIの記事では、「RegTechをFinTechのサブセットとする」という英国金融規制当局のRegの定義を紹介しています。
RegTech is a sub-set of FinTech that focuses on technologies that may facilitate the delivery of regulatory requirements more efficiently and effectively than existing capabilities. https://www.fca.org.uk/publication/feedback/fs-16-04.pdfより 
RegTechにより、規制の実装を技術で行えるようになると金融庁の検査業務等も効率化されていくことになるんでしょうか。

業務データをなんらかの方法でメタ化して「被検査データ」を作成し、金融庁はまずその「被検査データ」から確認していく、という方法もありうるのかなと思います。

また、社内のガバナンスとしても活用できるかと。例えば、支払い業務のデータから、決裁日時、決裁者の役職、金額、支払先の口座種別(口座タイプから、国内/国内銀行か)といったことを決められた形式でメタ化できると、「特定の日決裁者が非営業日に決裁を行っている支払いが多い」といったことをデータ分析で簡単に行えるのではないかと思います。

あとは、社内にあるデジタル文書、Email等もすべてガバナンスのためのデータとすると、データ分析の技術を用いて「不正しそうな徴候」が検出できたりするのではないでしょうか。もしくは不正がおきたときに特定のパターンを抽出し、該当パターンと似た事象が発生した際に、不正防止のためのアクションを取り得るといったこともありえるのかと。

日本証券協会 FinTech報告書

日本証券協会がFinTechに関する報告書をとりまとめました。

「証券業界とフィンテックに関する研究会サーベイグループ」報告書
http://www.jsda.or.jp/shiryo/houkokusyo/fintechsg20170127.html

下記が報告書本文です。
http://www.jsda.or.jp/shiryo/houkokusyo/files/fintechsurveygroup20170127.pdf

気になったポイントをいくつか取り上げます。

まずはレポートに締めくくりで説明されている、「現在の日本の証券市場で、フィンテックを促進する意義」ですが、下記のようにまとめられています。
1. 国民の安定的な資産形成
2. リスクマネーの供給
3. 国際金融センターの形成
1と2については、コインの裏と表というか、一つの事象を二つの異なった側面から説明していることかと思います。伝統的な証券会社ではリーチできていなかった消費者が、Mobile Appやウェブを通した新しいサービスを利用し、株やファンドに投資を始めると、結果として、市場にリスクマネーを供給することになります。

続いてFinTechという潮流のきっかけの一つとして、リーマンショック以降の人材の流動化が挙げられています。FinTechの歴史が語られる際に、下記のように金融機関からスタートアップへの人材に移動が言及されることが多いのですが、実際にどれくらい移動したのか統計データなどあれば見てみたいです。
金融危機により、金融商品の開発、トレーディング、金融機関の IT オペレーションなどに関わってきた人材が大量に流動化し、ICT 産業やベンチャー企業に流入している。ある意味では、金融業界から他業界へ移っていった人材やアイデアが、さまざまなイノベーションと結びつくことによって、外部から金融を揺り動かそうとしているのが、フィンテックによる潮流と解釈することもできよう。(2頁)
本報告書の面白い点は、現在存在しているFinTechに関する技術、サービスを逐次的に取り上げれているのではなく、下記のようにそのようなイノベーションが現在のシステム(体制としてのシステム)や概念をも変貌させるかもしれないことを見据えている点です。
さらに、ICT 分野を中心に、さまざまなイノベーションが継続した場合、今後 10 年などの中長期的スパンで見れば、経済システム自体が、大きく変貌するかも知れない。例えば、仮説として、「契約・信用経済からネットワーク経済へ」「私的財産権から共同利用権へ」 「貨幣を媒介しない取引(市場外取引、物々交換)が重要になる」「個人・法人・市場の境界線が消滅し『株式会社を創る』理由が問い直される」といった予測が提示されている1。実際、ウーバー・テクノロジーズ(Uber、配車アプリ)が単にタクシー業界だけでなく移動手段の考え方自体を革新し始めていることや、エアビーアンドビー(Airbnb、民泊予約サイト)が宿泊や不動産保有という考え方に大きな影響を与え始めていることは、こうした仮説が荒唐無稽な未来予想図とはあながち言えないことを物語っている(3頁)。
第三者(国家や中央銀行)に担保されない貨幣を作ろうという思想が根本にある、ブロックチェーン技術も上記の例の一つでしょう。

下記では、各所で語られていることですが、FinTechはコンテンツ産業等の他業界がテクノロジーによって変化したのと同様、バリューチェーンがアンバンドルされる可能性について言及しています。
【バリューチェーン再構築の可能性】
上記の要素技術によるイノベーションに加えて、人工知能(AI)・ビッグデータ革命などが進展した場合、証券業務におけるバリューチェーンが分解(アンバンドル)され、他の業態・産業セクターも含めた提携・M&A などを通じて再構築(リバンドル)される可能性もある。その過程で起こり得るステップは例えば以下のような流れが考えられる(13頁)。
事実、LINE、DeNA、Amazon、Softbankといった、顧客とのとチャネルを強みとしてしる非金融企業が金融サービスを提供し始めていますし、間違いなくアンバンドルされていくでしょう。

最後に、下記ではNasdaqは開発したシステムを他国で展開するなど、ITベンダーのような取り組みも行っているとのこと。日本取引所も同様の取り組みを行っていくのか、気になります。
米国では、2015 年 12 月、Nasdaq がブロックチェーン技術のスタートアップ企業である Chain と提携して Nasdaq Linq を開発した。これは、株式を公開していない企業の従業員が報酬として与えられた未公開株式を取引できるようにする市場である Nasdaq Private Market の中の株主管理システムの部分をブロックチェーン・ベースの Nasdaq Linq で行うもので、従来は 3 日必要であった取引成立から決済までの期間が 10 分程度に短縮するといった効果がある。Nasdaq は、取引所としてブロックチェーン技術を取り入れる試みを行うと同時に、開発したシステムをエストニアでも展開するなど、IT ベンダーのような取り組みも行っている。

レッドハットのAPI管理システム

レッドハットがAPI管理サービスの提供を始めたとのことです。
「アクセスに利用料を課したり、通信を制限したりできる。」とのこと。

レッドハットがAPI管理システム、既存システムのデジタルビジネス活用を推進
http://itpro.nikkeibp.co.jp/atcl/news/17/012700265/

複数の企業とAPI連携を行う際に、企業Aにはプログラム1,2,3だけ、企業Bには1,2,3の他に4と5といったケースが出てくると思うのですが、それを基幹システムではなく、このようなAPI管理サービスで実装できると便利ですし、セキュリティ上も、アーキテクチャー上も望ましいでしょう。

また、アクセスに利用料を課すというのはコール数のカウントができたりするのでしょうか。なんにせよ、API連携が増えていくことを考えると重要なサービスの一つになりそうです。

2017年1月26日木曜日

InsurTechとLemonade

森・濱田松本法律事務所の増島雅和氏がInsurTechの本命として、アメリカのLemonade社を紹介しています。

InsurTechの本命、Lemonadeのビジネスモデル

Lemonadeのページをみてみたものの、増島氏が説明されているようにB-Corpが引き受主体となっているかどうかはわかりませんでした。Appをダウンロードするなどして、別途他の情報を確認すればわかるのかもしれないですね。

ただ私が調べてみる限り、B-Corpという会社が存在するのではなく、B Labという非営利組織が管理している「社会的企業」の認証制度のようです。そしてLemonadeはB-Corpとして、「社会的起業」認証されているようです。

B Cooperationのウェブサイト
https://www.bcorporation.net/

WiredではB Lab立ち上げの経緯が説明されています。

WHY BE "B"? B-Corpという挑戦
http://wired.jp/special/2017/b-corp/

Lemonadeのポイントとしては「予定していた損害率と実際の損害率に差があった場合に、その分のお金を契約者に還元しますよ」といったところでしょうか。

貯蓄性の保険において、予定と実際の事故(損害)率、事業費率、利率から生まれる3利源(危険差(死差)、費差、利差)をもとに契約者配当を行う会社はありますが、掛け捨ての損保系の保険で予定と実際の損害率を差をもとに、契約者配当を行っているのは聞いたことがないですね。

なお、事業費については下記のように20%とFixにしているようです。日本の大手損害保険会社が30%、ダイレクト系の損害保険会社でも事業費率は24,5%のところが多いことを考えると、低いコストで経営できるようになっているのでしょう。ただ、アメリカの損害保険会社の事業費率がどれくらいなのかわからないので、20%が「低い」のかどうか判断に困ります。
Q: How are you using my premium dollars?
Glad you asked! Lemonade keeps a fixed 20% fee. This pays for developing loads of cool tech, paying our team's salaries and hopefully making some profit!
The remaining 80%?
Job #1 is to ensure we can always pay claims
Job #2 is to Giveback money that isn’t needed for Job #1. 
保険に加入するにあたって電話での提供は行っておらず、WebとMobile appに絞っているのも、事業費を抑えられる一因でしょう。支払い方法についてもクレジットカードとデビットカードになっておりますし、不要なオペレーションが発生しにくいように仕組みが作られていると思います。
Q: Can I sign up by phone?
Lemonade will be available for signup only through our mobile apps and our website.
増島氏の説明では、保険の引受査定(Underwriting)を再保険会社にアウトソースしているようです。保険金の支払い(Claim)の損害調査は間違いなくアウトソースされているようですし、バリューチェーンにおいてLemonadeが担っているのは、商品開発、ディストリビューション、リスク引受と資産運用といったところでしょうか。

日本の保険会社のようにディスクロージャー誌がでるようでしたら、是非詳細にみてLemonadeのビジネスモデルを詳しく知りたいです。

*なお別途ポストしますが、増島氏がまとめられているFinTechに関するレポートが、FinTechの本質を理解するにあたって非常にわかりやすかったです。

金融会社のデジタル戦略、デジタルイノベーションについて

昨年より、銀行や保険会社等の金融会社でデジタル戦略や、デジタルでのイノベーションを担当する部署が新設されてきています。

新設される部署のJob Descriptionは何かな、ということを考えてみました。

部署を新設しないまでも、金融会社は誰かに下記のようなJobをアサインし、実行していく必要があるのかなと思います。

Objectives
テクノロジーの発達に伴う現在及び将来の消費者のライフスタイルの変化を見据え、デジタルの観点から自社の戦略を立案し、推進する

Outcome
デジタル化による収入増(新規顧客獲得、upセル、crossセル)
デジタル化による販管費減 (作業自動化等)

Output
1. デジタル戦略の立案(どの分野に投資して競争優位)
2. テクノロジーポートフォリオを中心としたレポートの作成
3. POCを実施し、各部門へのImplementationを提言
4. デジタル化に関するセミナー、トレーニングの開催

Research
1. テクノロジーポートフォリオの作成:テクノロジーベース、バリューチェーンベース、課題ベース、財務指標ベース、ベンダーベース

Open innovation
スタートアップ企業、他社、研究所との連携や共同でPrototypingや実証実験を実施

Development
POC
Prototyping

Stakeholder communication
1. ビジネスとカスタマージャーニー/エクスペリエンス、顧客管理について協議
2. オペレーション部門とデジタル化によるコスト減について協議
3. 情報システム部と既存システムとの整合性、integrationについて確認
4. エバンジェリストとしてセミナー、トレーニングを各部門に対し開催

東京海上によるブロックチェーン実証事業実施

東京海上がブロックチェーン活用の実証事業を実施するとのことです。Planetway社のavenue-crossという技術を使用し、実証事業を行うとのこと。

ブロックチェーン技術の活用領域拡大に向けた実証事業を開始
http://www.tokiomarine-nichido.co.jp/company/release/pdf/170124_001.pdf

Planetwayという会社、聞いたことがないのでウェブサイトなどで見てみると、2015年に日本人によってシリコンバレーに設立されたスタートアップのようです。

下記でavenue-crossの説明がされています。
http://pwlvc.com/jp/business/avenue.html

「15年間におよぶ電子政府国家エストニアの政府インフラを民間応用」とあるようにエストニアで使用されている技術を応用したもののようです。

Planetwayの取締役にエストニア経済通信省に勤めていたラウル・アリキヴィ氏がいますし、エストニア企業とPlanetwayのパートナーシップ発表においてもエストニア政府CIOのメッセージがありますから、エストニアとかなり強い関係を持っていることかと思います。

エストニア政府 CIO(最高情報責任者)ターヴィ・コトカ氏(Mr. Taavi Kotka)2015年11月13日 TAKT記者会見メッセージ
http://cortanavideo.top/index.php?a=watch/5sYah9QCmpo

avenue-crossの特徴として「beyond API」が挙げられているのですが、技術的にどんな点でAPIをbeyondしているのかを知りたいところです。

Planetwayは交通事故予防サービスのアイディアでスタートアップ育成プログラムで受賞などもしていますし、気になるスタートアップの一つです。

IBM® BlueHubの「Open Innovation Initiative For Automotive/Healthcare」で『Avenue-Cross』を活用したサービスプランが最優秀賞・審査員特別賞を受賞
http://pwlvc.com/jp/infomation/press_release/20161209_001.html

2017年1月24日火曜日

ガートナー、人工知能 (AI) に関する10の「よくある誤解」を発表

ガートナー、人工知能 (AI) に関する10の「よくある誤解」を発表
https://www.gartner.co.jp/press/html/pr20161222-01.html

この記事を読んでAIに関するよくある誤解というか前提として考えなくてはいけないこと今回は取り上げてみたいと思います。

1. アウトカムを明確にする
どんなにAI(のなかの機械学習)を駆使したとしても、分析結果がトップラインなりボトムラインに影響を与えないのならば、分析のための分析になってしまい、意味がないのではないでしょうか。

データが豊富にある場合「まずはなにができるかをも考えるために分析してみよう」というのはきっかけとしてはいいのかもしれませんが、その際も売上向上、コスト削減といった明確なゴールを設定した上で分析を開始するべきでしょう。

2. Garbage in, Garbage out
正しくないデータでどんな分析を行っても、出てくる分析結果は正しくなりえません。

データ分析について語るとき、分析のソースとなる「データの正しさ」や「正しさを保つための業務フロー」について議論されることが少ないかなと思います。例として、下記のようなことを考えなくはいけないかと。

1. データが取得/入力されるアプリケーションはそもそも正しくデータを保存しているか。郵便番号入力が頭0が桁落ちしてしまう等の問題が発生していないか。

2. 「正しくないデータ」が入力されてしまった場合に、それを検知するシステム/業務は構築されているか。正当性チェックのプログラムを組んだり、それをしかるべき人間(データオーナー等)が確認できるようになっているか。

3. マスターデータの整合性は保たれているか(グループ企業間でも商品とのマスターデータの持ち方が異なる場合がある)

4. データやその分析結果のオーナーシップやアカウンタビリティをもつ部署を明確にする

金融企業でデータ分析を専門に行う部署ができておりますが、分析がビジネスにおいて価値を発揮し続けるためには上記のようなことを考えておかないと、Garbage in, Gabage outになってしまうかと思います。

下記でもAIを活用したいと考える前に、解決しなければならない課題が説明されています。
金食い虫の「機械学習」と実用に堪えない「ディープラーニング」
http://itpro.nikkeibp.co.jp/atcl/column/16/122700311/011700003/

ライフネット生命保険 LINE, Facebook Messengerでのボット導入

ライフネット生命保険がLINEでのFacebook Messengerでのボットを使用した自動応答による保険診断と見積もりを実現するサービスを提供とのことです。

ニュースソースはこちら
http://www.trans-cosmos.co.jp/company/news/170123.html

ボットを構築するにあたっては、トランスコスモス提供先のReply, incのボット構築用プラットフォーム「Reply.ai」を使用するのこと。

Reply.ai(https://www.reply.ai/)のページをみてみると、Visual Bot Builder、Analytics、Integrate with your backendといった機能が充実していて便利そうです。

ボットとはいっても、どのように顧客とコミュニケートするのか(どのような質問をなげかけ、また選択肢を示すのか)といった点は最初は人の手で設計する必要があるでしょうし、後からの変更が発生することも考えるとVisual Bot Builderのように、プログラミングレスで変更可能な機能が提供されているのは便利ですね。

また、コアの業務ロジック、ビジネスロジックが必要になる場面でも、Integrate with your backendを使用されば、そのロジックが実装されているシステムからコールできるということでしょうか。(Reply.aiで出来るかどうかはわかりませんが)ボット側に不必要に業務ロジックを実装する必要がないのは、アーキテクチャー上も好ましいデザインなのかなと思います。

他にbot integrationサービスを提供する会社がないかググってみましたが、Gupshup(https://www.gupshup.io)しか見つけられませんでした。ドメインからわかるように、インドの会社です。Reply.aiの"Visual Bot builder"と同様、"Flow Bot Builder for non developers"があります。

2017年1月19日木曜日

保険業界とFinTech 1: FinTechとInsureTech

保険業界とFinTechの関わりについて、3回にわたって考えていきたいと思います。

保険業界とFinTech 1: FinTechとInsureTech
保険業界とFinTech 2: ダイレクト系損害保険会社の財務諸表
保険業界とFinTech 3: AXAグループの取り組み

今回はFinTechとInsureTechについて。保険領域におけるFinTechの動向にて、InsureTechについて説明されています。
InsurTech(Insurance×Technology)と呼ばれる新たなサービスが生まれ始めている。InsurTechは、図表に示す通り、大きく2つの形態に区分することができる。1つは、「テクノロジーに裏付けられた新たな保険商品の提供」。もう1つは「保険に関する新たな価値・経験の提供」である。
2015年頃までは「保険のDigitalization」という表現で表現されていた分野ですね。Digitalizationで議論されたいた頃よりもより注目されている分野としては、「データ分析に基づいた保険商品の提供」及び、「業務の自動化におけるAI」の役割、といったところでしょうか。マーケティングのためのバズワードとしてInsureTechと表現したくなるのもわからないのではないですが、「保険のDigitalization」という表現のままでいいのかなと思います。

 保険業界の中でも生命保険会社よりは損害保険会社がよりInsureTech/Digitalizationの影響をうけることかと思います。過去に何回か「保険におけるInsureTech/Digitalization」というセミナーに参加したことがありますが、保険の商品別でいうと、自動車保険、火災保険等住宅に関する保険、医療保険に関するものがほとんどです。

 生命保険会社としても医療保険には関わるものの、いわゆる生命保険(死亡保険)については、他商品に比べるとInsureTech/Digitalizationのインパクトは少ないかと思います。生命保険(死亡保険)の商品として特徴上、1年更新の自動車保険等と異なり、顧客(保険契約者、被保険者)とコミュニケートする回数、チャネルが少ないのが理由かと思います。

 さて、保険会社のイノベーションの度合いを「顧客が求める新しい保険会社像――顧客中心志向の保険経営とそれを支えるIT」では、事業費率を指標として考察しています。下記が該当の箇所です。
 海外では、すでにデジタル技術などを活用する保険業界のイノベーション企業が出現しています。では、日本の保険会社と海外の保険会社、そしてイノベーターとは何がどの程度異なっているのでしょうか。そこで、コンバインドレシオと呼ばれる保険会社の比較指標を見てみました。コンバインドレシオとは、事業費率(経費/保険料収入)と損害率(保険金支払い/保険料収入)を加えた値ですが、日本の保険会社はグローバル企業に比べ、事業費率が高いのが特徴です。グローバルではどこも30%未満ですが、日本だけは30%を超えています。これは、日本の保険会社における人件費の高さ、オペレーション標準化の遅れ(無駄が多い)、ITシステムの維持費の高さ、マネジメントの意識(必ずしも経営のプロではない)などに起因する部分が多いとのことです。さらに、通販チャネルを活用するイノベーターと比較すると、事業費率は10ポイント以上も差があり、何らかの手を打たねばならないとも付け加えました。
ということで損害保険会社の事業費率について次の「保険業界とFinTech 2: ダイレクト系損害保険会社の財務諸表」で取り上げます。

2017年1月18日水曜日

CSMM.101x: Week 1: Introduction to AI, history of AI, course logistics, and roadmap

edX ColumbiaXのAI(CSMM.101x) Week1のまとめです

Week 1: Introduction to AI, history of AI, course logistics, and roadmap

参考書としてArtificial Intelligence: A Modern Approachが紹介されていますが、中古のpaper backで60ドル以上。。。。購入見送りです。他に読むべきものとして、Is artificial intelligence permanently inscrutable ?が紹介されています。

1.1. Overview of AI
このコースで採用するAIの定義として下記を紹介しています。
"The study and design of intelligent agents, where and intelligent agent is a system that perceives its environment and takes actions that maximize it chances of success. " by Russel and Norvi AI book

その後、AIとは何かと考えるにあたって4つの学説を紹介しており、本コースでは4番目のActing rationallyの考えに則ると説明しています。
1. Thinking humanly
2. Acting humanly
3. Thinking rationally
4. Acting rationally

1.2 Applications of AI
AIが応用されている下記の分野について、具体例とともに説明がされています。
Speech recognition, Handwriting recognition, Machine translation, Robotics, Recommendation systems, Email, Face detection, Face recognition, Detection of breast cancer in mammography image, Chess, Jeopardy, Go, Autonomous driving
囲碁のことGoっていうですね、知りませんでした。

1.3 AI foundation and history
AIの基礎となる諸学問が紹介されています。例:哲学、数学、経済学、脳神経科学、心理学、コンピュータ・エンジニアリング、サイバネティクス、言語学等。その後AIの歴史を4つの区分で説明しています。ポイントは1956年のDartmouth会議で、初めてAIという造語が使用されたということです。

1940-50: Gestation of AI
-Boolean circuit to model of brain
-Turing's Computing Machinery and intelligence

1950-1970: Early enthusiasm, great expectations
- Birth of AI @ Dartmouth meeting 1956: term Artificial intelligence was coined
- MIT Video "The thinking Machine" on Youtube

1970-1990: Knowledge-based AI
- Expert systems
- AI winter

1990-present
- AI becomes "scientific", use of probability to model uncertainty
- AI spring

1.4 Course Overview
本コースで学ぶ内容の概要が説明されています。"How human think is beyond the scope of the course"とし、AIの一分野であるものの、本コースの対象外としています。
人間がどう考えているかどうかは別として、合理的な問題解決をagent(本コースではPythonでのプログラム)にさせるか、そのためにはどのようなアルゴリズム等があるのか、といったことが本コースの学ぶ内容です。

Week 1 Quiz: Introduction to AI
ここまでの講義の内容と書きのarticleをもとにQuizに答えるようになっています。合計100点で、なんとか満点とることができました。正直、書きのarticle特にWhite Houseが出しているものは量も多く読みきれていないです。Quizに関係ありそうなところだけを読みました。時間をみつけておいおい読んでいこうかなと考えています。
1. Preparing for the Future of Artificial Intelligence. Executive Office of the President, National Science and Technology, Council Committee on Technology. October 2016.
2. Computing Machinery and Intelligence. Alan Turing, 1950.

Week 1 Discussion Questions
Question 1: "Should we be concerned about Artificial Intelligence? Is AI a threat to humankind?”

Stephen Hawking: http://www.bbc.com/news/technology-30290540

Bill Gates: https://www.washingtonpost.com/news/the-switch/wp/2015/01/28/bill-gates-on-dangers-of-artificial-intelligence-dont-understand-why-some-people-are-not-concerned/?utm_term=.666cb624c9b0

Elon Musk: http://www.theverge.com/2014/8/3/5965099/elon-musk-compares-artificial-intelligence-to-nukes

https://plato.stanford.edu/entries/chinese-room/#2.1 

edXで学ぶArtificial Intelligence

edX(エデックス)で受講申し込みをしていた、コロンビア大学のArtificial intelligence (AI)が開講しました。

別途ポストしようと思っているんですが、英語が苦手でなければ、もしくは勉強したいと思っている方で、これからプログラミングを学ぼうとしている方であれば、edXの各種コースを受講/修了するのが、ベストな方法の一つと考えています。オンラインとはいえ、MITやHarvardのComputer Scienceの授業を受けるのは知的好奇心も満たされますし、あとかなりの量のcodingも行いますので、学びの効率もいいです。

さて、Artificial intelligenceですが、証明書を得るには300ドルを支払って受講しなくてはいけません。40~60ドルであれば、モチベーション維持のために支払うことも考えていたんですが、個人で300ドルは高いです。。。

MicroMasters Credentialというコースの一部のようで、Artificial intelligenceを含め他3コースを修了すると、AIの分野でマスターレベルの修了の証明になるようですが、計1,200ドルですと、途中でドロップアウトする可能性を考慮すると、支払うのはためらってしまいます。

無料でも以前あったhonor codeのように証明書が出ればいいのですが、どうなんでしょうか。まずは300ドルの証明書コースつきに切り替える期限まで受講してみて、レベル感をみつつ、支払うかどうか考えてみます。

AIのコースは全12週で下記が各回で学ぶ内容です。プログラミングではPythonを使用するとのことです。学びを深めるためにも、このブログで角回で学んだ内容のまとめていきたいと思います。

Week 1: Introduction to AI, history of AI, course logistics, and roadmap
Week 2: Intelligent agents, uninformed search
Week 3: Heuristic search, greedy search, A* algorithm, stochastic search
Week 4: Adversarial search, game playing
Week 5: Machine Learning: basic concepts, linear models, K nearest neighbors, overfitting
Week 6: Machine Learning: perceptrons, neural networks, naive Bayes, decision trees, ensemble, logistic regression, and unsupervised learning
Week 7: Constraint satisfaction problems
Week 8: Markov decision processes, reinforcement learning.
Week 9: Logical agents, propositional logic and first order logic
Week 10: AI applications to natural language processing (NLP)
Week 11: AI applications to vision/robotics
Week 12: Review and conclusion

イギリス、単一市場から脱退

イギリス、単一市場から脱退する方針を表明とのことです。
アングル:英金融界、最悪の離脱シナリオ受け海外移転加速へ

金融会社をはじめ、EUを主要マーケットとしているグローバル企業は、EUにから各種規制は受けるものの、規制の成立/変更の過程において提言を行いにくくなることになるかと思います。

EU離脱でイギリスの銀行の影響力凋落、政府も耳貸さずで、「4ヶ月間にわたる銀行のロビー攻勢」もむなしく、"hard Brexit"が選択されてしまいました。
しかし4カ月間にわたる銀行のロビー攻勢も、一部で裏目に出ているのが実態だ。財務省はEU離脱交渉における優先順位を決めるため、異なるシナリオ下で各業界の収入や雇用、納税にどのような影響が及ぶかについて徹底的な調査を行っている。政府高官らによると、銀行はそのスケールが分かっていないという。
英国銀行業界のウェブサイトにあるStaying in or leaving the EU single marketというレポートで、単一市場に残る場合/離脱する場合の銀行業がうけるインパクトの説明がなされています。

人工知能技術戦略会議とWe Robot

下記のニュースをよみ、NEDOのウェブサイトで、資料等がアップされていないか確認してみましたが、残念ながらまだでした。

AIの産業化イメージを3フェーズで提示、人工知能技術戦略会議が開催

資料がアップされ次第、どのような内容だったか確認してみたいと思います。

続いてアメリケやヨーロッパの主要国がAIにどのように取り組んでいるか資料を探し、総務省のウェブサイトにある欧米における AI ネットワーク化に関連する 政策・市場動向を見つけました。その中で、気になったのは下記のWe Robotです。
米国では、ロボットの利用拡大(警察・軍事、病院、介護等)が見込まれるなか、マイ アミ大学法学部のマイケル・フルームキン(Michael Froomkin)教授が先導役となり2012 年から、ロボットの社会・経済的な影響について幅広い分野からの参加を募って議論する「We Robot」カンファレンスが開催されている。
過去のカンファレンスのタイトルは上記の総務省の資料の30ページ以降にまとめられています。We Robotのウェブサイトはhttp://robots.law.miami.edu/です。

2017年1月17日火曜日

税制改正とIT、イノベーション

下記の記事を読み、「2017年度税制改正に盛り込まれるIT関連税制」について調べてみました。イノベーションを促すために税制度等の規制を整備するといったことは重要でしょう。

IT活用のサービス開発が減税対象に、日本でも世界標準のイノベーションを

ウェブで調べられる限りですが、「IT関連税制」という税制があるわけではなく、研究開発税制の改正の中でITに関連した箇所をIT関連税制と表現されているようです。
(研究開発税制については、経産省のページに関連資料が掲載されています。)

自民党のウェブサイトに平成29年度税制改正大綱が掲載されていまして、研究開発税制の改正に関連するのは下記の箇所になるかと思います。
(1)競争力強化のための研究開発税制の見直し
600兆円経済を実現するためには、イノベーションを促すことにより、付加価値の高い財・サービスを生み出していくことが重要である。このため、研究開発投資を増加させるインセンティブを強化する観点から、2020年までに官民合わせた研究開発投資を対GDP比4%以上とする政府目標も踏まえ、研究開発税制の見直しを行う。具体的には、総額型の控除率を試験研究費の増減に応じたものとする。また、IoT, ビッグデータ、人工知能等を活用した「第4次産業革命」による新たなビジネス開発を後押しする観点から、研究開発税制の対象に、「第4次産業革命」のサービス開発のための試験研究に係る一定の費用を新たに追加する。
 「第4次産業革命」が進展する中、オープンイノベーションがますます重要となっている。平成27年度税制改正により拡充したオープンイノベーション型の研究開発に対する措置や私立大学における受託研究の非課税措置について、使い勝手を向上すべく、共同研究等の実態を踏まえ、対象費用の追加・変更の柔軟化や手続きの簡素化など、要件の緩和を図る。
改正の詳細については、税制改正に対する経産省の要望の「試験研究を行った場合の法人税額等の特別控除の拡充」に記載されていることなのかなと思います。

大綱で登場する「第4次産業革命」ですが、経産省の第四次産業革命に向けた横断的制度研究会 報告書にて、下記のように定義されています。
近年、ビッグデータに代表される情報処理可能なデータの飛躍的増大や、コンピュータの計算能力の向上、人工知能等の第四次産業革命と呼ぶべき技術革新が進行している。
IoT、ビッグデータ、AIに関する研究が従来の税制では控除の対象とならなかったのか、対象となっていたものの、より研究が推進されるように対象となる要件を緩和するのか、控除額を増やすのかが、私はまだ理解しきれていませんが、何にせよ国際的に競争力を生む分野に投資が進むように税制が改正されることは望ましいことですね。

2017年1月16日月曜日

AIと倫理 AI開発ガイドライン

総務省が、人工知能(AI)の開発ガイドラインの策定に乗り出したと、ITProのウェブサイトで取り上げられています。

総務省がAI開発ガイドライン作成へ、透明性や制御可能性など求める

昨年末よりパブリックコメントが実施されており、下記に論点の要旨がまとめられています。
「AI開発ガイドライン」(仮称)の策定に向けた国際的議論の用に供する素案の作成に関する論点(要旨)

倫理と関わる論点を抜き出しますと、下記のようになっています。
(6) 倫理の原則 AIネットワークシステムの研究開発において、人間の尊厳と個人の自律を尊重すること。
1. 倫理の原則においては、人間性(humanity)の価値を中心に据えつつ、人間の尊厳と個人の自律を尊重すべき旨を掲げることとして はどうか。
2. 国際人権法・国際人道法等を参照し、AIネットワークシステムが人間性の価値を毀損してはならないとしてはどうか。
3. 人間の脳・身体と融合又は連携するAIを研究開発する際には、人間の尊厳と個人の自律の尊重について、生命倫理等の議論も 参照しつつ、特に慎重に配慮すべきとしてはどうか。
4. AIの開発において、個人を公平に尊重する観点から、技術的に可能な範囲で、AIの学習するデータに含まれる偏見等に起因 する差別(人種、性、宗教等による差別)を防止するための措置を講ずべきとしてはどうか。
4の偏見等に起因する差別についてですが、人種、性、宗教等すでに差別すべきものでないと認識されているものは当然として、人の性格/嗜好/生活に関する様々なデータが取得できるようになっている以上、"人間性(humanity)"を中心にすえ、人間性の価値を棄損しないように、という原則がガイドラインとして掲げられるのは必要不可欠かと思います。

2017年1月15日日曜日

荒屋真二『人工知能 概論(第2版)』

AIについて学ぶために、2014年に購入し飛ばし飛ばして読んでいた本書を本日読了いたしました。



Amazonのレビューでも指摘されていますが、まさに「概論」というタイトルにふさわしく、広く浅く人工知能に関する概念の説明が行われています。決して「入門書」ではないので、何かしらバックボーンとなる知識をもっていないと、本書に書かれている内容を「知る」ことはできても、「理解」するのは難しいかと思われます。

本書の内容をざっくりまとめると、「人口知能で問題を解決するにあたって、宣言的知識 declarative Knowledgeと手続的知識 procedural knowledgeをどのように実装するか(プログラミングするか)」になります。宣言的知識 declarative Knowledgeは、命題、知識、ルール、事実と言い換えてもいいでしょうし、手続的知識 procedural knowledgeは簡単に言うとアルゴリズムです。

宣言的知識 declarative Knowledgeに関しては、Prolog/Javaの知識が理解に役立ちます。

特に第4章でとりあげられている「意味ネットワーク semantic network」と「フレーム frame」ですが、is-a関係や、継承 inheritanceといったオブジェクト志向プログラミングの言葉が登場します。フレームframeに関しては、データ(field)だけでなく手続き(method) も持つことができると説明されており、オブジェクト志向のクラス概念そのものだと思います。時系列的に考えても、これらの人工知能の知識表現に関する研究の蓄積がオブジェクト志向に受け継がれていったんでしょうね。

立命館大学 稲葉教授のウェブサイトでも下記のように簡単に言及されていますが、オブジェクト指向が成り立つにあたって、知識表現の研究がどのように参照されたかを説明する本などあったら読んでみたいです。
人工知能における知識表現や問題解決の手法は、組織的活動を効率化するコンピュータシステムの開発やデータベース設計の前提となる「オブジェクト指向」と呼ばれる技術に受け継がれている。 
説明されているアルゴリズムに関しては、Prologに関連するパターンマッチングについては実感をもって理解できますが、その他についてはPythonで実際にコーディングしてみて、理解を深めたいと考えています。

2017年1月14日土曜日

自動車自動運転と倫理

Wiredの「MITが描く「クルマ・人・街」の新しいエコシステム」というレポートを読み、「自動車自動運転と倫理」について考えてみました。

自動運転はFinTechか

倫理について触れる前に、まずは、自動運転がFinTechに含まれるのかを考えてみたいと思います。

私はFinTechの使用のされ方として、以下の二つが代表的なものと考えています。

1. 金融会社のイベノーションを促す技術
2. 金融会社に限らず、事業会社/消費者/社会にも便益をもたらす、従来の金融サービス(投資アドバイス、送金、決済、経理、財務等)に代わる/改善するテクノロジー

広義には1、2の両方がFinTechにあたり、狭義には2のみになるかと思います。私としては、FinTechという言葉で示すのは2に限った狭義の使い方が適切ではないかと思いますが、詳細はまた別の機会に考察したいと思います。

ですので、自動車保険を主力商品として扱う損害保険会社のことを考えると、自動運転は1の使い方には含まれるものの、FinTechというくくりで自動運転を語るのは、私としてはあまり適切ではないと考えが。が、デロイトの保険業界におけるFinTechの潮流でも、自動運転は取り上げられていますし、このブログで取り上げる次第です。

自動運転と倫理

さて、「自動運転と倫理」を考えるにいたったのは、Wiredの「MITが描く「クルマ・人・街」の新しいエコシステム:「WIRED Future Mobility Session」レポートのなかでの、ダニエル・ベレリ氏の発言を読んでです。該当の箇所を引用してみます。
そこで考えなければいけないのは、倫理的な問題です。例えばMITのほかのラボでは、自律走行車の倫理的なジレンマについて研究しています。自律走行車が人を轢きそうになったときに、それを避けるためには犬を轢かなければいけないという状況で、クルマにどちらを選択させるべきか。デザイナーだけではこうした倫理問題に回答を出すことはできません。しかしシナリオを提示して、人々に問題について考えてもらうべく伝えていかなければいけません。
なるほど、自動運転をプログラミングする際に、「犬か人か」どちらかを轢かなくてはいけない、という状況でどちらを選択すべきかは倫理的に考えなくはいけない問題ですね。人間が運転をするケースでは、その人個人の倫理的判断に基づけば、いいのですが「自動運転」させる場合は、何が「正しい運転」、「望ましい運転」かを人が決めアルゴリズムを組むわけで、そのアルゴリズムが社会一般の通念や倫理に反していてはいけないですよね。

取り上げられたケースの場合、人と犬であれば、まだ考えやすいかと思います。議論はあるものの「犬」を轢く方に選択するのが社会的通念に則ったものではないでしょうか。

それでは、人一人と人二人はどうでしょうか、この場合はプログラムではどちらかを明示的に選択せずに、ランダムに選ぶというのも、一つの倫理的な解決かもしれません。

それでは、末期ガンを宣告された人一人と、小学生二人はどうでしょうか。まもなく死ぬ人間一人と未来ある子供二人のケースです。

あくまで上記は例で、「正しいこと」をアルゴリズムとして組み込む際には、このようにどちらかを選択しがたい状況での倫理的問題を考えざるをえないですね。

ITと哲学

今回はITと哲学についてのポストです。

大学生の頃、哲学についても学んでいたので、プログラミングの勉強をしているときや、仕事をしているときに、哲学的概念との関連を思い浮かべたりします。

ここでいう哲学とは、分析哲学というよりは大陸系哲学に分類されるものです。分析哲学に分類されるものは、論理学に基づいていますし、Inofrmation Technologyの起源を語る上でも不可欠なものなのですが、私が学んでいたのは、主に大陸系に分類されるポスト構造主義とかフランス現代思想と分類されるものなので、これらに関連する概念を思い浮かべたりします。

ひとつ例をあげると、フランスの哲学者ジャック・デリダが提唱したパロール(話し言葉)とエクリチュール(書き言葉)の関係です。

西洋では伝統的にパロール(話し言葉)がエクリチュール(書き言葉)に先立ち、優位に置かれてきたとされるが、そのような単純な二項対立ではなく、両者は複雑に関係している、とデリダは主張していた、というのが私の理解です。

パロール:エクリチュールは、概念:言葉という組み合わせにも置き換えられます。概念というのは、言葉に先立って存在し、言葉はあくまで「先に」存在している概念を表現するためのものだ、と考えることが普通かと思いますが、そうとは限らないのではないでしょうか。

英語、日本語での言葉の違いを考えてみるとわかりやすいと思います。日本語では「えび」と表示するものが、英語ではサイズによって、ロブスター、プローン、シュリンプと分けて表現されます。日本語でもロブスターは使用するかと思いますが、プローンとシュリンプは区別されずに「えび」になるかと思います。あとは、tuna(ツナ)という言葉ですが、我々はtuna (=マグロ)と理解していますが、tunaにはカツオも含まれるんですよね。

ここで伝えたいのは、ロブスター/プローン/シュリンプという概念(区分)が予め存在したのではなく、何らかの理由(文化的、歴史的背景)があって、それぞれを分ける言葉が使用されるようになり、その言葉に従い個別のものとして理解されるようになった、ということです。

さて、ではこの概念:言葉という組み合わせを、どのような関わりでITにおいて思い浮かべるかといいますと、「解くべき課題」と「ソリューション」との関係においてです。あるいは、システム開発における「業務要件」と「ソリューション」といってもいいかもしれません。

いわゆる「業務要件」を考える際、「ソリューションありきではなく、「何がしたいのか、どういう課題を解決したいのか」を先に考えよう、決めよう」といったことが言われますし、それは正解ではあるのですが、あるソリューションを前提としていない、業務要件は考えにくとと思います。

我々が考える「業務」は基本的には、「紙」というソリューションに負うことが多いですし、もしくは当たり前すぎと忘れてしまいますが、Microsoft Word / Excel / PowerPointといったソリューションを使用して現在の業務を行っているかと思います。

ある業務(=概念)が先に存在し、それに対応するソリューション(=言葉)が後付けされるのがすべてのケースではないということです。

特にPowerPointが顕著かと思いますが、「プレゼンテーション」という業務を考える際に、PowerPointを代表とした、プレゼンターションツールなしで、プレゼンテーションの方法や内容を考えることは難しいのではないでしょうか。

ここで伝えたいのは、ゴールは「要件(= 解くべき課題の解決)」であっても、方法として「ソリュショーンありきで考えてみる」というのも有用ではないかということです。

解くべき課題というのが、すでに存在しているソリューションと密接に絡みついているのであれば、逆に新しいソリューションから、どのような課題が解決できるのか、と考えるのは重要かと思います。結果、解くべき課題があたらしく発見できるかもしれません。

実務レベルで、「これつかってなんかできないかな」というのは行われていますし、FinTechでいうと、各社がラボ形式で新技術に取り組む等、どのように活用できるか試行錯誤をしたりしているので、改めてこのように考えなす必要もないかと思いますが、誰かと議論をする際に哲学における「概念:言葉」の関係を援用すると面白いかもしれません。

米山高生『物語で読み解く リスクと保険入門』

米山高生『物語で読み解く リスクと保険入門』

FinTechについて考える上で、金融がそもそも持つ機能や歴史について勉強しなおしています。保険の勉強のために、積ん読状態であった、米山高生『物語で読み解く リスクと保険入門』を読みましたので、感想等をまとめたいと思います。2013年7月日付の買い物のレシートが挟まっていましたので、3年半前には購入していた本ですが、ようやく読了しました。



本書は、第1部リスク編と第2部保険編に分かれていまして、第1部では「リスク」について理論的な観点から説明が行われています。第2部では、前半は保険の価格(保険料の構成)を中心に理論的に説明が行われ、後半は江戸時代から戦中までの保険募集の広告や、保険証券等の史料を参照にしながら、保険及び保険会社がどのように日本で形成され、普及していったかが説明されています。

第1部 リスク編
ここで学びとなったのは、リスクを考える際に期待値(期待損失額)と期待値まわりの変動があり、保険が提供するのは「期待値の低減」ではなく、「期待値まわりの変動」を低減させることによって、リスクを軽減させるといったことです。
期待値はμ(ミュー)、変動については、分散(σ2 シグマの二乗)もしくは、標準偏差(σ)を用いて表現され、それぞれの概念については理解していましたが、保険がどちらのリスクを低減するのか、といったことは考えていませんでした。

第2部 保険編
公正保険料(Fair Premium)という概念をはじめて知りました。公正保険料とは、以下の4つの要素から成り立つもので、競争的な市場と整合的な保険料とのことです。
1. 期待保険金コスト(expected claims)を現在価値に割り引いたものを
2. 割引保険金コスト(discounted expected claim) として、
3. 資本コスト(profit loading)と、
4. 管理運営費(expense loading)が合計されたものが、公正保険料である

つまり、
Fair Premium = discounted expected claim + profit loading + expense loading
ですね。

公正保険料と実際の保険料

競争的な市場と整合的というのは、「完全な市場」であれば、公正保険料以外の価格は存在しえないということです。実際には、市場参加者間の情報の非対称性はありますし、完全な市場はありえず、我々消費者も「合理的な」判断を常に行えるわけではないので、公正保険料以外でプライシングされた保険も存在するわけですが、概念として理解しておくのは有益かと思います。

著者の高山氏がまえがきで「国際的な保険実務家の間では公正保険料は基礎的な共通概念だが、日本ではまだ十分に使いこなされている用語ではない」としています。

高山氏の指摘は正しいようで、Googleで「公正保険料」と検索し、ざっと結果をみてみても、「公正な保険料」といった言葉は使用されていますが、「公正保険料」という言葉は見つかりませんでした。本書は2008年に出版されていますが、9年経った今もまだ、一般的にはなっていないということでしょうか。

なお、保険会社で勤めている間に、生命保険講座全8科目を受験しましたが、記憶が確かなら「公正保険料」という言葉は、どのテキストにも存在していなかったように思われます。

2017年1月13日金曜日

TensorFlowとJupyterの起動確認まで

本日、TensorFlowを動かすための環境構築を行いました。

Mac OS X Mountain LionからEl Capitanへのアップグレード
まずはYosemiteへのアップグレードをしようとしたんですが、既にダウンロードが不可能になっており、El Capitanにアップグレードしました。

Dockerのインストール
インストールは出来たのですが、立ち上げようとすると、Fatal Errorということで下記のような表示が出ます。
Incompatible CPU detected.
Docker requires a processor with virtualization capabilities.
To learn more about this issue see:

CPUがだめなら仕方がないので、やはりDockerをあきらめ、Canopyで使用できるようにセットアップを進めました。OSレベルで問題ないのに、CPUで弾かれてしまうってことがあるんですね。。

TensorFlowの起動確認
まずは、既にインストール済みのTensorFlowの動作確認
下記が実行コマンドです。
import tensorflow as tf
hello = tf.constant('Hello, TensorFlow!')
sess = tf.Session()
print sess.run(hello)


残念ながら、以前同様ImportError: dlopen ...... mach-o, but wrong architectureといったエラーが出てしまいます。

下記ページを見てみると、TensorFlowでは64bitのPythonが使用されるが、32bitのPythonしかないと出るエラーのようです。
http://stackoverflow.com/questions/36807691/error-importing-tensorflow-because-of-wrong-architecture

そこで、下記ページのMac OS X 64-bit/32-bit installerへと進み、インストールを実行
https://www.python.org/downloads/release/python-2713/

そして、改めて下記の手順でTensorFlowをインストール
# Mac OS X
$ sudo easy_install pip
$ sudo easy_install --upgrade six
# Mac OS X, GPU enabled, Python 2.7:
$ export TF_BINARY_URL=https://storage.googleapis.com/tensorflow/mac/gpu/tensorflow-0.11.0rc0-py2-none-any.whl
# Python 2
$ sudo pip install --upgrade $TF_BINARY_URL
そのあとに、再びterminalでpythonをコマンドし、下記コードを実行

import tensorflow as tf
hello = tf.constant('Hello, TensorFlow!')
sess = tf.Session()
print sess.run(hello)

その後、ついに出ました"Hello, TensorFlow" !長かったです。
しかしながら、terminalでは動作するものの、Canopyで動くか不安で試してみたところ、やはり"but wrong architecture"のエラーが出ます。

Jupyterのインストールと起動確認
64bitのダウンロードを行おうと思いましが、Jupyterが動作するか試してみたく、再度インストールを実行

$ pip install jupyter

途中、Mac OSから必要なコンポーネントをダウンロードするようにポップアップが出たので、ダウンロード。このコンポーネントのインストールが完了するまでは、jupyterもインストールできないようにで、一度エラーになりました。その後、再度インストールコマンドを実行し、下記コマンドを実行
$ jupyter notebook

無事、ブラウザでjupyterが立ち上がりました。
ようやく環境構築が完了です。

IBM Watson: The Science Behind an Answer

IBM Watsonで質問が入力されてから、答えを返すまでの処理の流れを説明している映像です。映像自体がかっこいいですね。

デロイトトーマツ グループの財務諸表と財務指標

デロイトトーマツ グループの財務諸表と財務指標

Big4 FinTechの取り組みにて、FinTechに関し、他の会計事務所に比べ、トーマツは官民共同で討議を行う場に多く参加していると、言及致しました。

トーマツがどのような会社か気になったので、FinTech普及を担う企業ということで、企業研究を行ってみたいと思います。

監査法人だけでなく、コンサルティング会社もあるので、どれくらいグループ会社があるのか調べたところ、実に17法人とかなりの規模となっています。(グループ法人一覧を参照)。

こちらに直近のBS/PLがありますので、内容を見ていこうとおもうのですが、アカウンティングの勉強の際にお世話になった『会計力と戦略思考力』に倣い、どのようなBS/PLかイメージをしてみます。BS/PLの項目について、他事業会社と監査法人の違いにはついては知識がないため、一般の事業会社の項目名に従います。

-----------------------------------

貸借対照表
資産
1. 一番のアセットが人と考えると、資産サイドは多くないはず
2. さらに、事務所以外の固定資産は存在せず、その金額は少なく、流動資産が大半を締めるのではないだろうか
3. 売掛金、監査報酬の支払いサイトがわからないため不明。単純に、月ごとの請求で末締め、翌月末払いとうであれば、年間売上の二ヶ月分が計上されているのだろうか
4. 監査が主サービスである以上、他社の株を多く保有することは考えられず、有価証券の金額もすくないのでは

負債
1. 監査が主サービスであることを考えると、仕入が必要なく買掛金はないだろう。
2. 監査が主サービスであることを考えると、その性質から銀行から借入をして事業拡大することは考えにくく、借入金も少ないはず

純資産
1. 事業開始にあたって多くの資本は必要ないと考えられるので、資本金もすくないはず
2. 監査で多大な利益をあげるとは考えにくく(被監査会社より利益をあげていたら、監査報酬引き下げへつながると予想される)、利益剰余金は少ないだろう。

損益計算書
1. 粗利は極めて高いが、人件費が多くをしめ販管費がかさむことを考えると、営業利益率は決して高くはないのではないか
2. 有価証券の保有がすくなく、借入金もすくないだろう、という予想にたつと、営業外収益/費用の金額はすくなく、売上総利益と純利益の金額がかなり近いものになるのではないだろうか。

-----------------------------------

上記が予想するBS/PLに対する仮説です。その仮説を考えたうで、財務指標上でどうなるか、『戦略思考で読み解く 経営分析入門』に記載されているサービス業の各財務指標と比較したいと思います。8年前の数字であり、かつリーマンショックまっただ中の数値なので、指標としてどうなのかという疑問は残りますが、あくまで仮説を検証するためのものなので、問題ないでしょう。

各指標(2008年4月〜2009年3月)のサービス業界平均

サービス業 平均トーマツ(予想)
売上高反管費比率21%人件費が嵩み、50%を超えるのでは?
売上高営業利益率8.4%原価はかからないものの、人件費の高さを考えると、これよりも低いのは、4%ほどか
EBIDAマージン10.8%買収によるのれんや、減価償却費はすくないと考えられるので、売上高営業利益率とほぼ同じくらいか
ROE4.0%レバレッジは決して高くないはず。借入金がないので、これより下がるのではないか。2~3%か
ROA8.6%総資産は一般のサービス業と比べても少ないと考えられるが、利益率も決して高くはないだろうし、同じような数値か

-----------------------------------
では、2015年10月から2016年9月期のBS/PLをみて、上記の財務指標の仮説を検証していきたいと思います。

貸借対照表
資産 合計525億7900万
流動資産395億9500万業務未収入金: 145億3800万
固定資産129億8400万

負債及び純資産 合計525億7900万
負債295億7600万業務未収入金: 145億3800万
固定資産230億0300万

損益計算書
業務収入964億7800万監査業務:704億5900万、非監査業務: 260億1900万
営業利益13億1600万

財務指標
指標トーマツ(実績)
売上高反管費比率98%PLで販管費という項目はなく、
業務費用というものが951億6100万。
ほぼ、売上である業務収入と同等ですね。
業務費用=販管費とすると、98%となります
人件費が723億と実に業務収入の75%を占めます。
売上高営業利益率1.3 %予想以上の販管費率の高さで、
営業利益率も予想よりかなり下回りました
EBIDAマージン2.7 %予想外だったのは営業利益と同等以上の、
配当金による営業外収益。
グループ会社からの配当金でしょうか。
減価償却費はなく支払利息の額も少ないので、
為替差益に税引前利益に追加すると、
2.7%と売上高利益率の倍となりました。
ROE8.1 %他サービス業と同じような数値になりました。
ROA8.6%13億1600万/525億7900万で2.5%となりました。
やはり予想以上の営業利益率の低さによるものです

-----------------------------------

98%, 売上高に占める業務費用(=販管費)の割合の高さにより、各財務指標に特徴がでているかと思います。

一般的にいっても、営業利益率が1.3%というのは「低く」感じられますが、最初に予想したように、利益率が高ければ被監査企業から監査報酬を引き下げるようにプレッシャーを受けるでしょうし、妥当な数値をいったところになるのでしょうか。

2017年1月12日木曜日

Big4 FinTechの取り組み

四大会計事務所 FinTechの取り組み

四大会計事務所とそのグループ会社が、どのようにFinTechに取り組んでいるか、Webで集められる情報をもとに、まとめてみたいと思います。

PwC (PwCあらた有限責任監査法人・PwC京都監査法人)
PwC Japanグループ内に「フィンテック&イノベーション室」を設置。
本室では、フィンテック企業と金融機関との連携を含めた、戦略策定、ビジネスモデル構築から実装までのコンサルティングサービスを提供します。また、両者の提携・合併をサポートするアドバイザリーサービス、提携・合併する上での課題であるITセキュリティや規制対応、業務プロセスの統合のサポートや各種保証業務を含めたアシュアランスサービス、ならびに税務・法務面での支援をワンストップで提供します。」
ソース:http://www.pwc.com/jp/ja/japan-press-room/press-release/2016/fintech-and-innovation-room160729.html
また、FinTech協会に法人会員として参加されています

Ernst & Young (新日本有限責任監査法人)
PwC同様、FinTech協会に法人会員として参加されています

KPMG (有限責任あずさ監査法人)
PwCと同様にグループ内にフィンテック専用のチームを設置しているとのこと
KPMGジャパン(本部:東京都新宿区、チェアマン:高橋 勉)は、金融とテクノロジーが融合したフィンテックを導入推進する金融機関および日本の金融ビジネスに参入する内外企業に向けた金融アドバイザリーサービスを行う組織として「フィンテック推進支援室」を12月26日付で設置しますので、お知らせします。
ソース:https://home.kpmg.com/jp/ja/home/media/press-releases/2016/12/fintech-support2.html
Deloitte Touche Tohmatsu (有限責任監査法人トーマツ)
経済産業省の「産業・金融・IT融合に関する研究会(FinTech研究会)」の第一回の集まりで執行役員の方がモデレータを務めたり、第二回の集まりでは「FinTechの成立と既存金融機関への影響」というプレゼンテーションを行っています。

また、全銀協が設置した「ブロックチェーン技術の活用可能性と課題に関する検討会」のメンバーにも名を連ねています。さらには、民間の事業会社/銀行以外に、日本銀行もメンバーとして参加している、「FinTech エコシステム研究会」もトムソン・ロイターと共同で立ち上げていますし、他の3社に比べ、官民恊働での討議に多く参画されているようです。

トーマツ パートナーの永田 高士氏がキャリアインキュベーションのサイトで他の監査法人や、戦略系コンサルティングファームとの違いで説明されているように、政策提言や枠組み作りに強みがあるといったところでしょうか。
私たちにはルールを作ったり、政策の基準となる法律・会計の枠組み等の設計等に関われる強みがあるのです。時には政策提言や法律策定、会計制度の構築等の国家レベルのプロジェクトにも関与します。
なお、トーマツではなく、経済産業省がFinTech研究会で作成された資料ですが、産業・金融・IT融合(FinTech)に関する 参考データ集は、各国のおける事例等がまとめられており、2016年時点でのFinTech関係の概況を理解するのに、非常に参考になりました。 

TensorFlowでディープラーニングを学びたい

AI(人工知能)について学ぶにあたり、TensorFlowでコード書きながら深層学習(ディープラーニング)を学ぼうとし、『TenrsoFlowで学ぶディープラーニング』を読みながら環境構築しようとしているのですが、苦戦しています。
TensorFlow(テンソルフロー、テンソーフロー)とはGoogleによって提供されている、機械学習/ディープラーニング/多層ニューラルネットワークライブラリです。オープンソースとして提供されています。


こちらの書籍では環境構築をシンプルに行うために、Docker用のコンテナイメージが用意されているのですが、DockerをインストールできるのはMac OS X Yosemite以降。

Mac OS Xの名前はやはりネコ科の動物の名前に限る!というこだわりと、インストール済みのアプリケーションが正しく動作するか不安で私が使用しているMac BookのOSは10.8 Mountain Lionのままのため、Dockerが使用できません。

Jupyterのインストールもうまくいかず、既にインストール済みCanopyを使用し、コードを書いていくしかないかなと決めたのですが、TensorFlowが正しくimportできません。Q&Aサイトをみても、簡単そうな解決方法が見つかりません。

Mountain Lionで動いている各アプリケーションがどこまで動作するかはわかりませんが、私にとって一番重要なOpenOfficeについてはYosemiteでサポートされているようなので、今夜あたり、しぶしぶアップグレードするしかないのかなと考えています。。。

久しぶりにMacのTerminalを立ち上げ、小一時間程、色々と設定を試しましたが、やっぱりすんなりいかないですね。

わがままかもしれませんが、こういった新しいテクノロジーを学ぶ際、何も考えず、何もインストールせずにブラウザで使用開始できるように、Webアプリケーションとして、提供してもらいたいですね。

金融庁 第2回「決済高度化官民推進会議」

昨日、金融庁で行われた第2回「決済高度化官民推進会議」を傍聴してきました。
会議の資料は「決済高度化官民推進会議」(第2回)で閲覧することができます。

この会議は昨年末まで金融庁で行われていた「決済業務等の高度変化に関するワーキンググループ」での議論をもとに、ワーキンググループ報告書で示されたアクションプランのフォローアップし、継続的に高度化に進めるために設置された会議とのことです。有識者や事業会社、金融会社の方々が委員として参画されています。

昨日の会議では全銀協、経産省、FISC(金曜情報システムセンター)の方々が、それぞれが整理した論点、課題とアクションの進捗について報告されていました。

下記の2点が、全体を通しての私の感想です。

1. 予想以上のスピードで、FinTech活用に向けて官民が仕組みづくりを進めている
委員の一人からも、国民のFinTechに対する理解の度合いに比べ、普及する、普及させようとするスピードが早いのではないか、というコメントがありました。
私もテクノロジーに関わる仕事をしているので、一般の方に比べるとFinTechのメリットに関する知見はありますが、それでもそれらが既存の伝統的な金融サービス・商品に組み込まれるとなると、セキュリティや規制など色々クリアにしなくてはいけないものが多いなと考えていたので、議論されているアクションのスケジュール感は予想以上にはやいものでした。

2. FinTech企業が生み出す価値を損なわない仕組みづくりが必要
利用者保護の観点からセキュリティの確保や規制(ないしルールづくり)は必要不可欠であるという前提にたちつつ、FinTechスタートアップのスピード感やイノベーションを損なわない形での仕組みづくりが必要と各所が考えられているようです。

2017年1月10日火曜日

FinTech関係のニュースサイト finAsol

FinTech関係のニュースサイトを探していたところ、finAsolというサイトを発見致しました。

FinTechに関わるニュースだけでなく、イベント情報金融機関システム概説等のコンテンツも充実しており、素晴らしいサイトですね。

ニュースページでは、ソースとなるニュースリリースと参照URLがしっかりと記載されているのも信頼できます。

運営者がどういった方なのかサイトをみてみましたが、情報が見つかりませんでした。これだけ充実したサイトを運営されているにも関わらず運営者情報が記載されていないということは、個人の方が本業以外で運営されているということでしょうか。

今後、お世話になりそうです。

金融庁 決済高度化官民推進会議

明日、金融庁で開催される「決済高度化官民推進会議」(第2回)を傍聴予定です。
先立って、第一回の資料等を閲覧してみました。

私が以前から注目していたのは、決済高度化に向けた 全銀協の取組みについてで言及されている「決済インフラにおけるXML文書への移行」です。

どの回か忘れてしまいましたが、金融庁で開催されていた「決済高度化に関するワーキンググループ」においても言及されていた内容で、既存の固定長の全銀フォーマットのファイルから、取引の内容によりファイルの長さ/形式を変更できるXML形式に送金指図ファイルを変更するというものです。

全銀フォーマットのファイルをご覧になったことがある方はわかるかと思いますが、1レコードのサイズが120byteと限られているたため、本ファイルには必要最低限の情報しか記載されていません。XML形式にすることにより、長さ/形式が可変になり、取引で必要な情報を自由に加えられるようになるため、そのデータファイルを使用し、「請求・支払・入金消込」といった業務の自動化、効率化が行えるといったことが、「決済高度化に関するワーキンググループ」で述べられていたかと思います。

保険会社での仕事では、保険料徴収や保険金支払のシステムも担当することが多く、関連する業務や、それら決済系のテクノロジーやインフラストラクチャーに興味があるので、XML形式を採用することによりインパクトや、業務改革・業務改善を考えるのは楽しいです。

保険会社の業務効率化としては、保険料徴収や保険金支払に関わる各種管理業務をXML形式のデータをソースとして、自動化できるといったところでしょうか。

また、情報系システムの使い方としては、保険料徴収や保険金支払の各トランザクションのデータを、今までは別の業務アプリケーションからのデータ出力や、別ツールでの分析等行っていたのも、XML形式のデータを唯一の形式にして分析のソースにするのが有効かと思います。

既存のアプリケーションからも分析用のデータは出力されているでしょうが、例えば複数アプリッケーションが存在する場合に、どのアプリケーションから出力されたデータを正とするか、といったことを考える際に「決済に用いるデータを正とする」というのが正しい方向かと思います。

保険商品、保険料支払方法、保険被保険者の属性、保険金支払に伴う付帯費用、などなど様々な情報をXML形式のデータに加えることによって、事業費が実際どれくらいかかるか、どのような顧客により事業費がかかっているのか、などデータが取得しやすくなるのではないでしょうか。

結果、現在では想定されていない項目でリスク細分型の保険が提供されるようになったら、保険会社・お客様にとってもベネフィットがあるのかなと思います。

2017年1月7日土曜日

FinTechの要はAPI

最近改めて「FinTechって、要するに何なの?」と考えたりしているのですが、私にとってしっくりくるのは「企業間のAPI連携によって顧客に新たなサービスを提供する」という答えです。API自体は新しい技術でないにもかかわらず、最近になって注目される理由の一つとして、Web系テクノロジー全般の進歩によって、従来では存在しなかったデータの取得・保存・利用が可能になり、API連携によってやりとりされるデータがよりリッチになったため、といったことが挙げられるかと思います。

そういえば、一年程前にあったマーケティング会社で勤める友人が「これからはAPI連携だよ」と言っていたのも最近思い出したのですが、当時はあまり深く考えていませんでした。その後、仕事でWeb APIを扱うことが多かったこともあって、今はAPI関係の話題について、より理解が深まっています。

一年前の少し古い記事ですが、WiredでもFinTechの要はAPIであるという記事が掲載されています。
Fintechで起きている変革はAPIがつくりだす豊潤なビジネス生態系へつながっている

記事を書かれているのがIBMの方なので、自社のビジネスへと繋がりやすいAPIに言及することを差し引いたとしても、FinTechを理解する上でわかりやすいです。

2017年1月6日金曜日

Blockchain in insurance – opportunity or threat? by McKinsey

今回は、FinTechを語る上で、最も注目されていると言っても過言ではないBlockchaninについて考えたいと思います。

保険業界で働いていましたので、2016年の7月にMcKinseyが発表した保険業界に対するBlockchaninのインパクトと展望が述べられているレポートを参考にしたいと思います。
Blockchain in insurance – opportunity or threat? 

レポートの内容に入る前に、そもそもblockchainとは何かということですが、正直に言いまして、他技術と本質的に異なる点(メリット)は何か、どのようなインパクトがビジネスにはあるのか、いまいち理解しきれていません。そのため上手に説明することもできないです。

現時点での理解を自分の言葉で説明すると、

「データ(のまとまり=ブロック)が作成されたタイミングで、そのデータのハッシュ値を計算するとともに、次に作成されるデータ(のまとまり=ブロック)にそのハッシュ値を渡す。前ブロックのハッシュ値を含め、次ブロックのハッシュ値が計算され、また次のブロックに渡される。このようにして作成されるデータは前データのハッシュ値が含まれる。かつ、このデータは参加者すべてが同様のデータを保有する。データを変更すると、ハッシュ値が変わり、「ハッシュ値が変更された=不正なデータ」であることがわかるため、結果、不正が行われない。そのため、従来のように独立した第三者が正当性を担保するにあたって発生していたコストや、制約がない」

といったところでしょうか。

ハッシュ値によってデータの正当性が担保される仕組みについては、下記動画が理解の助けとなりました。

Blockchain 101 - A Visual Demo

今後も引き続きblockchainについて調べ、自分の言葉で簡単に説明できるようになりたいと思います。Bitcoinを技術的に理解するで説明されている内容を自分自身が理解し、テクノロジーのバックグラウンドを持たない方に対してわかりやすく説明するのが目的です。

さて、McKinseyのレポートで取り上げられている、blockchainの保険業界に対するインパクトですが、いくつか例が挙げられているものの、「自社以外にあるデータをいかにビジネスに活用するか」といったことがポイントのようです。

「自動車保険の事故においては、定められた修理工場で車が修理されたことをデータをもって検知し、保険金支払いの条件する」といったことが例として挙げられていますが、blockchaninでなくても、他の例を含めデータ交換やWeb API連携で可能なことではないかと思いました。

レポート内7ページ目でも、下記のように同様のことは述べられていました。
Conversely, there are conditions under which blockchain is likely not an appropriate solution. If transactions involve only a limited number of parties – or do not require an intermediary – or if a well-established, trusted intermediary already exists, insurance players may be well advised to continue working under their current transaction models. 

あらゆるデータが交換されているわけではないのですが、日本の保険業界では共同ゲートウェイや損保VAN、LINCなど、信頼のおけるサードパーティにより標準化された形式/方法でデータ連携がされているので、blockchaninありきで考える必要もないのかと思います。

他の国の保険業界では、どのようにデータ連携がされているかはわかりませんが、レポートにあるように、少なくともemerging countriesではそのような仕組みは存在しないでしょうし、グローバルな保険会社としては、blockchaninが良いオプションの一つになりうるといったところでしょうか。

あと細かい実務上の問題かと思いますが、blockchaninのデータってどのように後から"訂正"が可能なんでしょうかね。"事務ミス"があった場合に、すでにチェーンに組み込まれているデータをどのように訂正し、訂正後のデータが正であることを証明できるのかが気になりました。

日本の金融市場においての展望は日本取引所の下記レポートにまとめられています。
金融市場インフラに対する分散型台帳技術の適用可能性について

とりとめの無いポストになってしまいましたが、今回はとりあえずここまで。

AIのインパクト

「AIは人の仕事を奪うのか」、「人間の知性、知能はAIにとってかわられるのか」といった議論があります。

ここでは「仕事」、というよりは、それよりも小さい単位である「業務 (=あるタスクの実行)」という観点からAIのインパクトを自分の言葉で考えていこうと思います。

人間が行う仕事というのは、少し乱暴ですが、どんなに複雑なものであっても、下記のように分解できてしまうと思います。

input -> 計算( =inputをもとに適切なoutputをみつける) -> output

計算にあたる部分が人間の知性、知能の根幹かと思いますが、計算を過去の事象(input)に基づき最適解を求めることとすると、テクノロジーの進化により様々なinput、及びそれに対応する最適解をデジタルに収集・保存できるようになり、保存されたデータをもとにAIが人間にかわりinputに対し最適解を提示できるようになってきている(なるように期待されている)のだと思います。

そして、input -> 計算( =inputをもとに適切なoutputをみつける) -> outputの組み合わせのシンプルさの度合い、及びコンピュータに置き換えた際のコスト/ベネフィットが考慮された上で、人間が行っている業務がどんどんAIに置き換わっていくのだと思われます。

これは良い、悪いの問題ではなく事実として人類がずっと経験してきたことと思いますし、議論はあるでしょうが、私としては「input -> 計算( =inputをもとに適切なoutputをみつける) -> output」に簡単に分解できてしまうものは、そもそも人間が行うべき仕事ではないとも思います。

Artificial intelligenceとProlog

VCフレッド・ウィルソンのブログで2017年のテクノロジー業界予測が述べられています。
What Is Going To Happen In 2017

この中で取り上げたいのが、下記のAIに言及した箇所です。

AI will be the new mobile. Investors will ask management what their “AI strategy” is before investing and will be wary of companies that don’t have one.

「AIは新しいモバイルになるだろう」モバイルがビジネスに与えたのと同じくらいのインパクトをAIが与えるという意味かと思います。

そして、投資家達は投資に際し、経営陣にAIに関する戦略について質問し、戦略を有しない会社に対しては投資に慎重になるだろうとのことです。

私がAIに興味を持ったきっかけは、仕事で携わっているPrologという言語がIBM WatsonやSoftbank Pepperのコアで使用されているのを知ったことです。

仕事で使っていたのはProlog自体ではなく、Prologをベースにした言語で、あまりオープンな言語ではないので、名前をxとしておきます。便宜的に、この記事では x = Prologとして読んでください。

xは、Prologをベースにオブジェクト指向の特徴を取り入れた言語で、言うならばx = Java + Prologのような感じです。詳細については、wikipediaや「Prolog 入門」と検索して頂ければ見つかると思うので、そちらを参照ください。

xでは、Prologの特徴であるPredicate (述語)という形式でプログラムを書くことができます。
私がPrologで面白いなと思ったのは、このPredicateのおかげで条件分岐をコーディングする際に、if 文を書く必要がないということです。

保険会社で働いていたので、保険商品に関しコーディングすることが多かったのですが、皆さんご存知のように保険は複雑な商品ですので、コーディングも複雑になります。保険自体や付帯している特約、及び保障金額ごとに、異なった処理を行う必要があるため、結果、条件分岐が複雑になってしまいます。

従来の言語ですと、if then elseを入れ子にしたり、case文などで、コーディングを行う際のビジネスルールをもとに「静的(あとから変更が不可能、もしくは極めて難しい)」に実装を行うことになるのかと思います。が、xではPredicateを用いることにより、各ルールを「読みやすく」かつ「動的(あとから変更がしやすい)」に記述することができます。

「動的」に条件分岐がコーディング可能というのが、PrologがAI実装に利用される理由の一つかと思います。if then elseとPredicateの例に説明しようと思ったのですが、時間がかかるため今回は割愛し、後日追加致します。

FinTech関係の情報ソース 

ブログ作成しました

FinTech関係の記事やニュースと、それに対する自分の見解を残しておくためにブログを作成。WordPress使おうかなと思ったが、色々な手間を考えてまずは簡単に使えるBloggerを使用。Adsenseの設定や、アフィリエイトの組み込み、アクセス解析などもろもろ後から追加していく予定