投稿者: Tsuchiya Shigeru

CTOの土屋です。AIに関するネットの記事はひところに比べるとだいぶ少なくなり、私はそろそろ”ブーム”は終わり実用化向けたフェーズに入った見ています。
　そんな中で気になるのが、ネットの記事でみられる”日本凋落論”や”日本終わった論”です。記事の内容は、非常に客観的に国内外の状況を分析されており、私もその主張については異論はありません。しかし、その記事やコメントを書かれているのがまだまだ、”現役”の方々がちらほら見えるのが気になります。しかも、結論は”日本終わった”とか”だから日本は駄目なんだ”的な結論が多く、提案型結論の記事はほとんどないというのが気になります。もう当事者ではない現役世代以外の方が応援や懸念の意味で、そういう結論を記述されるのは理解できますが、現役世代の方々が、そういう結論を書かれるのは、”諦め”や”他力本願”なのかなあと考えてしまいます。特に大企業の中堅クラス以上の方がそのような投稿をされているのを見るとそう思います。
　同様のシーンは定期的に行われているAIセミナーの会場でも見られます、常連の方々が”面白いよね”とか”やってみたいよね”とか”使えそう”とかいつも言っていますが、実際にやったという話は聞きません。みなさん、情報を手に入れることで、「やった気」に、「いつでもできる気」に、なってしまうのだと思います。これでは，AIエンジニアの広がりは少なくいつまで立ってもイノベーションの素地はできないのだと思います。（弊社にとっては価値が毀損せず、その方が都合がいいのですが。。。。）

　弊社は、わずかな影響しかないかもしれませんが、言葉よりも行動で日本経済の発展（実際は落ちる速度を遅くするだけかもしれませんが・・・・）に貢献していきたいと考えています。

CTOの土屋です。弊社の業務サービス内容に、「Chat bot開発支援業務」を掲げており、継続的に様々な開発案件の支援をさせていただいております。また、botのフレームワークの機能自体も多彩に、かつ、日々進化しており、最小限の開発で多くの機能を実現できるようになってきています。なんと言ってもbotの一番の魅力であり、特徴となるのはすでに普及しているユーザインタフェースで利用するということです。その長所、短所は以下の通りと考えます。

長所：
・アプリをダウンロードさせる必要がない。LineやFacebookなどのプラットフォーム上で友達関係をつくるだけ。
・ユーザインタフェースを新たに設計する必要がない。（メッセージフローの設計は必要）
・ユーザが慣れたユーザインタフェースであるため利用障壁が少ない。

短所：
・bot単体では凝った表現や仕組みは実現できない。
・ユーザインタフェースによる機能制約がある。

　同じ機能は通常のオリジナルアプリを開発しても可能と考えます。しかし、botフレームワーク上での実現を「選択する」ことで、AIなどの効率化を実現する機能に要員、資金を「集中」させ迅速に開発・展開することが可能になります。
　また、アプリをダウンロードさせるためにiPhoneであればApp Storeに誘導し、ダウンロードさせユーザ登録させるという手間がかかる作業をユーザに要求する必要があります。実はこれに手間と時間がかかるというのが、アプリを利用してもらうこと関するかなりのハードルになります。それに比較するとLineやFacebookなどのbotフレームワークを活用すれば、botサービスを友だち登録するだけで簡単に利用可能となります。

このように業務効率化の支援という切り口で考えていくと、まだまだChat botの技術的な可能性はあると思います。ただ、一般的な受託開発のように要件はお客様が決めてくださいというのでは、なかなか普及しないと、ここ２，３年の活動から私は見ています。

たとえばですが、
・chat botでどんなことができるのか
・chat botと既存のWebとの組み合わせはどこまでできるのか
・chat botを使うメリットは何か
・どう使うと業務の効率化が図れるのか
などの疑問について、ITやAIについての知識があまりない経営層の方々でも腹落ちするような実施例がないと普及に弾みがつかないと考えています。

　マーズスピリットでは、今後、あるサービス分野の企業をパートナーとしてその分野をターゲットとしたAIにより業務効率化を実現するbotサービスを8月より開発しています。そのbotのβ版の利用開始は年明けを予定しております。
　

　今後の予定や具体的な機能やターゲット分野についてこちらのブログで紹介していきたいと考えております。

ちょっと忙しくて、投稿の間が空いてしまった。また、再開します。

ネットの記事やNHKでも日本の研究者やポスドクの待遇について取り上げられており議論が高まっている。私も待遇についてちょっとだけ考える出来事があったので紹介する。

最近バイトで雇用した国内トップクラスの大学博士課程の中国からの留学生から、先日、進路について相談を受けた。

彼は、学位取得後は、現在の大学に残り専門分野（理学）の研究者になりたいが、一方でウチの会社で引き続きAIに関する開発にも関係していきたいということであった。私的には、そういってもらえるのは大歓迎なのだが、もう一歩つっこんでウチの社員にならないか？と誘ってみた。

すると、職業としては大学の研究員になりたいという回答であった。私は、最近、その大学の有期研究職の募集にも関係し条件等もわかっていたので、

「いいとこ年収で300～400万円だよ、君なら若いし、博士だし、機械学習理論の知識も豊富だし、プログラムも書けるし、民間企業に就職すればその倍以上の年収でスタートできる会社にも就職できるでしょ？」

と提案してみた。

すると彼からは、

「大学の研究職でそんなにもらえるなら十分です、私はやりたいことができればいいんです。私の中国での指導教授の年収は200万円程度です、物価が日本と中国では違いますが、300万円以上もらえれば十分です。」

という回答が返ってきた。

そっかあ、メディアの記事を見て、日本の給与水準はアジア内で相対的に低くなったと思っていたけど、分野・職種による分散が大きいので、一概には言えないんんだなと思った。

　昨今、業務効率化を目的としたAI/機械学習の導入が徐々に進みつつあるが、医療・バイオ分野においてもビジネス系よりも速いスピードでAI/ 機械学習が成果を出し、導入が開始されつつある。その流れを先取りすると、感性の分野においてもAI/機械学習による認識、診断、予測、アドバイスといった流れが来るであろうと予測し最近、感性について勉強を始めた。その中で非常に面白く興味をそそられたのが、インターフェース2018年11月号の記事であった。後で使えるように記事の要点を簡単にまとめてみた。他の章も続いてまとめてみたい。

「美的センスを科学する」を読んで from shtsuchiya

ネットの随所に記述されているので、読者の方々はご存だと思うが、機械学習の種類は、教師なし学習(Unsupervised Learning)、教師あり学習(Supervised Learning)、強化学習(Reinforcement Learning)の３種類がある。

「教師あり学習」と「教師なし学習」の違いは明確である。「教師あり学習」は文字通り、教師（データ）がありそのデータに一致するように学習が行われる。それに対して、「教師なし学習」は教師データはなく、入力データの特徴量を基にグループ化を繰り返すことでクラス分類を実現するような学習を指す。では、強化学習とはどのような学習なのか？

強化学習とは、簡単に表現すると、個々の行動・判断には教師データは存在せず一連の行動（これをepisodeと呼ぶ）が完了した時点で得られる報酬（これをrewardと呼ぶ）が最大になるように方策（これをpolicyと呼ぶ）を決定する学習を指す。

周囲の状況（これをenvironmentと呼ぶ）が逐次変動したり自分が変動することで周囲環境が変わるなど、すべての組み合わせを予め知り、適した方策を教師データとして準備するのが困難な場合に利用される。強化学習の最も有名な利用事例は、AlphaGoである囲碁を「教師あり学習」で構築しようとすると、すべての盤面のパターンを網羅し、それに対する打つ手を定義する必要がある。ところが、すべての盤面のパターンは膨大な数がありそれらに対してその先の変化のすべてを予測し、打ち手を定義し学習することは困難である。それに対し、強化学習は個々の「打つ手」ではなく、その打つ手を決定する「方策」を１手、１手ごとではなく１局全体を通じて報酬を最大になるように獲得するように学習を実施する。

昨日、機械学習ソフト開発のフローという記事を書いた。すると、偶然、「AI開発ミステリー　～そして誰も作らなかった～」　とある大手製造業の怖いハナシ (1/5)という記事を見つけた。まさに、ここに書いてあることを実際に体験しつつあったということである。

　この記事に記載されていることは、機械学習ソフト開発プロジェクトに限らずこれまでのIT開発プロジェクトで繰り返されてきた光景である。これが繰り返されてきた原因は、日本の雇用環境と密接に関係している。ユーザ企業は不定期業務であるIT開発プロジェクト向けにITに詳しい社員を雇用したくない、大手SIerは利幅を大きくしたいので同じく開発要員を定常的に雇用したくない、下請けも同様の理由で受注はするけど開発は・・・したくない。ということでピラミッド構造、つまり、小規模の開発会社またはフリーランスが開発を請負いリスクを負うという構造である。

機械学習ソフト開発も同じ構造でいけるか？というと話はそう簡単ではない、何度かこのブログでも書いたように、機械学習ソフトの開発はプログラミング技術だけでなく、高度な数学理論を理解し課題を解決可能なアルゴリズムを選定していくという要素が重要であるため、適任者が日本国内に非常に少ないという状況であるからである。現在、大学でもカリキュラムを見直しデータサイエンスに強い学生を社会に送り出していくので増えていくと考えるが、産業界の需要も増大していくので定常的な枯渇状況になるのではないかと予想される。AIが急激に進化し、AIが自ら設計、開発できるようになれば話は別であるが、その様になるまで後10〜30年はかかるであろうから、それまでどうするかというのが喫緊の課題である。

ということで、お困りの場合は大手SIerに相談するのではなく、是非弊社にご相談下さい（PRでした（笑））。

先日、クラウドAPIを活用して、３週間程度で機械学習システムを開発して欲しいという案件があった。概要を聞くと、どうも依頼主が要求元ではなく、依頼主が請け負った機械学習ソフト開発案件の丸投げ先を探しているようであった。以下に示すように、受託しても費用を負担する顧客の要望を満足する精度を出すことは困難と考えたためお断りをしたが、最近の案件の傾向をみるとその様な話が増えてきている。

一般的に機械学習は、データの収集、選択、アルゴリズムの選定、データクレンジング、データ前処理などの重要な準備・設計作業があり、その後、開発と学習、評価となる。評価結果結果として評価指標が低い、精度が低いなどの当初の想定と異なる結果となった場合はデータ収集以降のフェーズを繰り返し実施することになる。

したがって、開発作業を期間を３週間と限定された場合、せいぜい、このフローを１回するだけとなり、顧客の要望を満足する精度が得られない可能性が大きくなる。

この様に開発フローだけで見ても、それほど簡単ではないことがわかるであろう、しかも、機械学習は大量のデータを学習することで精度を向上させるため大量のデータが必要となる。結果として、大量のデータのクレンジングや前処理といった学習以外の処理にも、ある程度の時間とプログラム開発が必要となるのである。

Webシステム開発のように、開発作業を画面デザイン設計、DB設計、サーバプログラミングというように複数のエンジニアに役割を分担し、顧客とフェーズ単位で仕様を詳細化しながら並行ですすめることで、短期開発を進める開発スタイルとは、機械学習ソフト開発は全く異なるものであると考える。

これらの処理や学習は数学的な理論に基づくアルゴリズムを理解したエンジニアのみが適切に設計できるものであり、その様なエンジニアの存在が現在の市場には少ないということも日本におけるAI導入推進の今後の課題として指摘されている。

一方で、そういう状況にも関わらず機械学習ソフト開発案件の発注金額の相場はWebシステム開発以下という事例が多く、現在のアプリケーション開発企業がエンジニアの育成に注力していないという状況を招いている。

この状況は、中国や韓国、ベトナム等の近隣の国のエンジニアの育成よりも遅れつつあり、数年後には機械学習ソフト開発はオフショアせざるを得ない状況になるのではないかという意見も聞かれるようになってきた。

　いつも、このブログで書いていますし、ネットでも嫌という程、「AIが広がることで大きな変革」ということを実感します。それに伴い、ベンチャーや既存の企業で様々なチャレンジが始まっています。しかし、その”チャレンジ”もやればいいと言う訳ではありません。そんなことは、インターネットの黎明期でも経験していますし、近いところではスマホアプリの開発ブームのときにも、さんざん経験したり見たりしていると思うのですが、どうも別な技術となると、また忘れてしまい同じ様なことを繰り返すようです。それらのブームにのった事業のうまくいかない原因の一つとして、「やってやる！」と「やれるといいなあ」という自主的か他力本願的かというモチベーションの差があるのではないかと思います。

そんなことを考えるキッカケになった、先日、機械翻訳で多言語によるコンテンツ海外配信の件で相談したいという引き合いがあり、とある大手出版企業にて打ち合わせを実施した際の感想です。

昨年から知り合いを通じて相談があり、GoogleやMSの機械翻訳APIを使った配信を提案し日本語→英語の評価は昨年度やりました（営業活動の一環として）。

結果としては、元の日本語に課題があり、まだ高精度の翻訳は難しいとなりました。

今回、半年ぶりに呼ばれたのですが・・・

（A社）：いろいろ検討した結果として、すでにある英文でのサイトのコンテンツを英語以外の言語に翻訳したい。精度が悪い場合に発生する既存事業への影響を回避するために、小会社のサービスとして計画したい。

（私）：承知しました。それで、どのような仕様になりますか？

（A社）：元の自社サイトをスピャルピングし、テキストだけをAPIで翻訳し、その結果で別サイトのコンテンツを自動生成したい。　

（私）：直接英文データは入手できないのですか？

（A社）：まあ、元サイトの運営も子会社なんだけど、いろいろ調整が面倒なんで、ソフトでサクッとやりたいんだよね。

（私）：（絶望的にメンテナンスの筋悪いけど。。。）承知しました。できると思います。

（A社）：ところでさ、単にAPIサービス使って機械翻訳するだけでは、何も残らないのでつまらないんだよね、その結果を使って独自に機械翻訳サービスとかできるようにならないの？

（私）：できるとは思いますが、語彙とか精度の面でサービスとしてグローバル企業並のものになるまで膨大な費用と時間がかかります。もし本気でやるのであれば、AIに関する作業を外注すると高額になるので、社内にAIエンジニアを並行で育成した方が将来の柔軟性があるのではないでしょうか。少なくとも弊社では規模的に請負いません。（やんわりと否定）

（A社）：そうなんだあ、AIエンジニアの育成についてカリキュラム持っている？

（私）：外部教育機関のサービスを受けるとかを勧めます。まともに基礎からやると高レベルな数学の知識が必要になりますが、DeepLearningのフレームワークベースでとりあえずプログラムを動作させるというところから始める教育はたくさんあります。

（A社）：いやー実は新しいビジネスをやる小会社つくったんだ、だから、ただAPIサービス使ってコンテンツを翻訳するだけって、上には受け良くないんだよね。なんかビジネスアイデアない？

（私）：（あれあれ？会社立ち上げる前に企画無いの？？）いやー特にないですね。AIを使った他の会社のサービスとかは例示・説明できますが・・・・・・・・・・・（いろいろ例示するも）

（A社）：でもさ、マネタイズどうやってやるの？そこなんだよね、問題は　

（私）：（そのアイデアあったら自分でやってるよ・・・・）

（A社）：（とあるベンチャーのサービスを指し）そこと組んでウチのコンテンツ配信できないかなって思って打診したら、カスタマイズに8000万円要求されてさあ、高くて無理でしょ。

(私）：新規サービス立ち上げは開発やPRを考えるとそれぐらいかかるのではないでしょうか？（あなたの会社大企業なんだから・・・・・・既存のビジネスモデルに相乗りするんだったら、それぐらいのリスクはとれるでしょ)

（A社）：単なる、コンテンツに広告のスペース提供する広告ビジネスとかも面白くないでしょ。

（私）：コンテンツホルダーという強みがあると思うので、立ち上げのハードルは低いと思いますが・・・・

（A社）：いやー上の方がさ・・・インバウンド向けになんかやりたいのよ。例えば、日本に来る前の観光客に情報を提供するとか面白いと思うけど、どうやってマネタイズしたらいいかねえ。

（私）：（不毛だな・・・この会話・・・ここまで約１時間・・・結論が見えないなあ）・・・・・・・

（A社）：おたくの会社で、AI使ったなんかいいビジネスのアイデアないの？

（私）：（この質問２度目だな・・そんなのあったら自分でやってるよ・・）いやー特には、お客様の方で、ビジネスモデルを決めていただければコンサルもできますが・・・

（A社）：おたくって何ができるの？

（私）：（え？いまさらそれ聞く？）平たく言うと、AIの利用に関するコンサルや開発の”ご支援”です。

（A社）：そうなんだあ、で今後すればいいの？いや〜上の方がさあ〜（前の会話の繰り返し・・）

（私）：まず、ビジネスの企画が固まりましたら、お呼び下さい。。。。

この会話でわかることは、A社は、誰も能動的に変革しようとしていないことです。経営層はその担当を任命して、その担当に丸投げしようとし、その担当は、どこかいいアイデアを持ってそうな会社に丸投げをしようとしています。しかも、何が目的なのか、変革するのは何なのか（もしくは変革したくないのか）すら明確にできていません。私も含めて、会社の経営に参画するものはこれらのポイントを常に意識し、発信するのが重要かと考えました。

昨日、ちょっとした依頼があり、レシートや通帳の画像からテキスト化の可能性を検討するためにクラウドOCRの性能を比較してみた。

　ここでクラウドOCRの比較といっても、それほど多くのサービスがあるわけではなく、お決まりのAIによる画像認識サービスの延長のOCRである。ということでメジャーな以下のサービスを試した。

　・Microsoft Azure Cognitive Services　Computer Vision　API

　・Google Drive のgoogle docs生成

本来はどちらもAPIで試すべきであるが、手軽に試してみたかったのでGoogleは手軽に、Azureのデモはocr_V2.0のプレビューということで日本語対応はしていないようであったためocr_v1.0を呼ぶコードを簡単につくり試した。

結論から言うと、当初期待した以上の認識精度を双方ともに出力できることがわかった。Googleの方が、通帳のような画像のサイズに比較して文字が小さい、印字が薄い、といった悪条件の画像においても安定した精度を維持していると見られる。Googleの優位点は、悪条件の場合、自動で画像を部分的に拡大して文字認識をしている点と考えられる。出力された文字のフォントサイズがばらばらで印字が薄い文字については、異常に大きなフォントサイズで出力されているためそのように考えた。AzureのV2.0ではどれぐらいこの点について改善されるか期待したい。

　レシートについては、大手コンビニ３社のレシートにおいて試したが、商品コードや合計金額、消費税、釣り、ポイントカードのポイントなどの数字についてはほぼ正確に認識できた。

　しかし、どちらのサービスも認識精度が極端に悪かったのは、半角カナ文字である。特に濁音や撥音の表記があると高い割合で誤認識をしている。漢字カナ交じり文では半角カナの後の全角漢字についても誤認識する傾向が高い。さらに、画像サイズに対して文字サイズが小さくなり、印字が薄くなると認識すらしない場合があった。リアルのビジネスの世界では半角カナはスペースを取らず情報を詰め込めるため、まだまだ多用される傾向があるため、クラウド画像認識によるOCRの普及は、この点をどの様にして改善するかが課題である。数字認識の課題としては桁区切り,の誤認識である、特に文字サイズが小さくなると発生しやすくなる傾向がある。

　評価後の感想としては、AIの適用全般に言えることだが、クリティカルなデータへの適用はまだ課題が多いが、それ以外の作業効率を高める補助機能としては十分使えるように成長しつつあると感じた。出力は認識単語単位に位置座標付きので出力されるのでレイアウト処理のプログラムは別途開発する必要があるが、サイトのスキャルピングや、多少のゴミが許容する大量のデータを簡単に収集したい場合には使えるサービスである。

この記事によると、

「機械学習の無料オンライン課程を運営している小規模な組織であるファスト・ドット・エーアイ（Fast.ai）の学生が最近、グーグルの研究者が開発したコードを凌ぐ人工知能（AI）アルゴリズムを開発した。潤沢な経営資源を擁する企業しか高度なAI研究はできないかのように思われている中で、ファスト・ドット・エーアイの成功は重要だ。」

ということである。AI開発には資金がかかるため、日本企業のような小額投資では難しいと考えていたが、モチベーションがあればまだ勝てるチャンスはあるということだろうか。記事を読む限りでは、この学生達は特別新しいアルゴリズムを開発したわけではなく、通常の研究者がやってみようとは思わない”大量の単純作業”をこなすことで実現したらしい。例えば、”訓練用アルゴリズムに入力された画像が正しく切り取られたかどうかを確認するタスクなど”ということである。

　学生達のモチベーションは、データサイエンティストになって起業する、または高額の報酬を得るということであろうから、この結果は大いに刺激になったであろうと考える。