完全マネージドなKubernetesサービス、「VKE」とは

　VMwareは2018年8月26日、年次イベントVMworld 2018で、マネージドKubernetesサービスの「VMware Kubernetes Engine（VKE）」を発表した。β版の提供を開始したという。主要パブリッククラウドベンダーが軒並みマネージドKubernetesを提供する中、VKEを選択する理由はどこにあるのだろうか。

　VKEはVMwareがパブリッククラウド上で提供するサービス。現在はAmazon Web Services（AWS）上で動いている。一般提供開始時には、US-West-2（オレゴン）、US-East-1（北バージニア）EU-West-1（アイルランド）の3リージョンで使えるようになるという。

　VKEはAWSに加え、Microsoft Azure、Google Cloud Platformでも提供の予定となっている。つまり、マルチクラウドが特徴の一つ。あるクラウドから別のクラウドへの移行も容易という。VKEのWebユーザーインタフェースから、全てのパブリッククラウド上のVKEクラスタを一括管理できる。それぞれのパブリッククラウドで、そのクラウドが提供するさまざまなサービスを活用することもできる。

　「VKEは完全なマネージドサービスで、マスターノード、ワーカーノードの双方が自動的に構成される。従って、（環境構築作業が不要であり、）コンテナをデプロイするところから始められる。サービスの利用開始から10分以内にアプリケーションを立ち上げられる。高い拡張性とパフォーマンス、セキュリティが特徴だ。コンテナを使い始める企業には、特に適している」と、VMware Cloud Servicesを担当するCTOのグイド・アッペンツェラー（Guido Appenzeller）氏は話す。

　VKEには、「Smart Cluster」という概念がある。クラスタの構成をテンプレート化していて、複雑な定義を行うことなく、目的に合ったSmart Clusterのタイプを選択するだけで使い始められる。また、利用開始後も、稼働状況、サイジング、セキュリティについて、継続的な監視に基づき自動的な最適化が行われる。

　例えばAWSが、価格性能比に優れた新たな仮想インスタンスタイプを提供開始した場合、Smart Clusterでは自動的に節約効果を判断し、次回のバージョンアップ時にクラスタを新インスタンスタイプへ移行するといったことができるという。

AIチップの過去・現在・未来

　近頃では人工知能（AI）がしばしばニュースで取り上げられています。AIは医療診断、化学物質の合成、人混みの中での犯罪者の顔認識、車の運転、芸術作品の創造にすら活用されています。AIが人間に代わって何でもやっているところを見ていると、AIにできないことは何一つなく、私たちの仕事がなくなるのは時間の問題であるように思えてくることもあります。
　AI技術の発端を理解するために、このコラムでは今日に至るまでのその進化の過程を時系列に沿って見ていきます。また、AIチップの現状を踏まえ、先進運転支援システム（ADAS）や自動運転車の実現によって私たちの日々の生活を大きく変えるにはAIチップに何が必要なのかを考えていきます。まずはAIの歴史から見ていきましょう。AIはその進化の過程で、より特化された技術に形を変えていきます。プログラミングではなく体験学習に基づく意思決定を軸としたそれらの技術はマシンラーニングと呼ばれました。そして次にこのマシンラーニングを土台として生まれたのが、データをより深く理解させるためにアルゴリズムをいくつも重ねたディープラーニングです。
 

図1：マシンラーニングからディープラーニングへと進化してきたAI 出典：Nvidia
AIのルーツ
　「Artificial Intelligence（人工知能）」という言葉は、科学者のジョン・マッカーシー、クロード・シャノン、マーヴィン・ミンスキーらによって1956年のダートマス会議で初めて使用されました。1950年代の終わりごろにはアーサー・サミュエルが、自らの間違いから学ぶことができ、チェッカープログラムの作成者よりもうまくプレイできるようにさえなるプログラムに「マシンラーニング」という言葉を使いました。コンピュータ技術が急速に発展したこの時代の楽観的環境を思えば、AIはすぐに「完成」するだろうと研究者らが考えたのも無理はありません。科学者たちは、人間の脳の働きを模した計算によって現実世界の問題を解決できるのかどうかを調査し、そこで「ニューラルネットワーク」という概念を生みだしました。1970年、マーヴィン・ミンスキーはライフ誌にこう語っています。「3〜8年後には、平均的な人間の一般的知能を持つマシンが登場するだろう」
　1980年代までには、AIは研究室を出て商用化され、一大投資ブームを巻き起こしました。1980年代終わりにAIテックバブルがついにはじけると、AIは再び研究の世界に舞い戻り、科学者たちは引き続きその可能性を探りました。業界ウォッチャーたちはAIを「時代を先取りした技術」、あるいは「永遠にやってこない未来の技術」と呼びました。商用開発に再び火がつくまでには「AI冬の時代」といわれる長い停滞期があったのです。
 

図2：AI年表 出典：https://i2.wp.com/sitn.hms.harvard.edu/wp-content/uploads/2017/08/Anyoha-SITN-Figure-2-AI-timeline-2.jpg）
　1986年、ジェフリー・ヒントンは同僚たちと共に、バックプロパゲーション（誤差逆伝搬法）と呼ばれるアルゴリズムを使用してマルチレイヤー、すなわち「深層」ニューラルネットワークのパフォーマンスを劇的に向上させる方法を説明した画期的論文を発表しました。1989年、当時ベル研究所にいたヤン・ルカンと他の研究者らは、手書きの郵便番号を認識するよう訓練できるニューラルネットワークを作成し、この新技術を現実世界で応用できることを実証しました。このとき彼らがディープラーニング畳み込みニューラルネットワーク（CNN）を訓練するのに要した期間はわずか3日でした。そこから一足飛んだ2009年、スタンフォード大学のラヤト・ライナ、アーナンド・マドハヴァン、アンドリュー・ウは共同で、ディープラーニングにおいては近代GPUがマルチコアCPUの計算能力をはるかにしのぐことを説いた論文を発表しました。ここから再びAIブームに火がつきます。
AIチップの実用化に向けて
　近頃これほどAIが話題に上っているのはなぜなのでしょう？　このテクノロジーが著しく発展する環境が整ってきたことで、現実世界の問題解決に幅広く役立てられると考える人々が増えているからです。今日ではインターネットによって提供されているインフラのおかげで、世界中の研究者たちが新しいアルゴリズムやソリューションの創造に必要な計算能力、大規模データ、高速通信にアクセスできます。例えば、自動車業界がAI技術に莫大な研究開発費を投じているのは、マシンラーニングによって自動運転などの非常に複雑なタスクを処理できる可能性があるからです。
　AIチップ設計における最重要課題の一つは全てを集約させることです。ここで言っているのは多種多様なハードウェアアクセラレータを用いてディープラーニングが実装される大規模カスタムSoC（システムオンチップ）のことです。自動車業界の厳格な安全・信頼性要求を考えればなおさらのこと、AIチップの設計は極めて難しいことに違いありません。しかし、AIチップがプロセッシング、メモリ、I/O、インターコネクト技術といった面でいくつか新しいソリューションを取り入れた単なるチップにすぎないのもまた事実です。
　新たにIC設計に乗り出したGoogleやTesla、さらにはAIMotiveやHorizon RoboticsといったAIチップベンチャー企業は、ディープラーニングの計算の複雑さについては豊富な知識を持っているものの、こうした最先端SoCを開発するにあたってはいくつもの厳しい試練に直面する可能性があります。これら新規参入プレイヤーができるだけ短期間で実用的なチップを開発できるようにする上では、コンフィギュラブルなインターコネクトIPが重要な役割を果たすと考えられます。
 

図3：GoogleのTSU（Tensor Processing Unit）に見るAIチップの構成
　例えば、画像解析による路側物体検出、分類を行う、車のフロントカメラ向けのディープラーニングアクセラレーターを搭載したAIチップについて考えてみましょう。最大帯域幅を確保するために各AIチップに固有のメモリアクセスプロファイルが割り当てられています。パフォーマンス目標を満たす必要があるときはオンチップインターコネクトへのデータフローを最適化して広帯域パスを確保しなければなりませんが、可能な場合は狭いパスを割り当てることによって面積、コスト、消費電力を最適化することができます。より高度なAIアルゴリズムを念頭に置けば各接続も最適化する必要があります。さらに付け加えれば、新しいAIアルゴリズムは毎日生みだされています。ある意味、今日のディープラーニングチップはバナナのようなもので、自分のAIチップに腐ったバナナを、つまり古いアルゴリズムを入れたい人などいないわけです。他の多くの半導体製品と比べてみても、こうした最先端チップでは製品化期間がいっそう重要な意味を持ってくるのです。
AIの未来
　ディープラーニングとニューラルネットワークによってAI技術は急速な進歩を遂げていますが、AIの究極の形を実現しようと思ったら根本的に異なるアプローチが必要になってくると考えている研究者たちは大勢います。大半のAIチップは、ルカンやヒントンらによって10年以上も前に発表された概念を絶えず改良してきたものに基づいて設計されており、たとえこのルートに沿って指数関数的な進歩が見られたとしても人間のように考えられるAIを実現できることは到底期待できないからです。
　今日私たちが知っているAIは、1つのタスクについてやっとのことで習得したディープラーニングを別の新しいタスクに適用することができません。また、ニューラルネットワークには、予備知識あるいは「アップvsダウン」や「子供には親がいる」というようなルールをうまく組み込むための方法がありません。さらに、人間は記憶に残るたった一度の経験で「熱いストーブには触ってはいけない」ことを学習できるのに対し、ニューラルネットワークに基づくAIに学習させるためには膨大な例が必要となります。大量のデータセットを使うことなく現在のAI技術をさまざまな問題にどう適用していけるのかは依然としてはっきりしていません。
　今のところAIチップは標準的な人間に比べてそう賢いわけではありませんが、それ自体が賢いことは確かであり、この先ますます賢くなっていくことはまず間違いないでしょう。AIチップが半導体プロセス技術、コンピュータアーキテクチャ、SoC設計の進歩を促すことによって処理能力が格段に上がれば、次世代AIアルゴリズムが登場するのもそう遠いことではないでしょう。また同時に、それら新しいAIチップの独自ハードウェアアクセラレーターにディープラーニングに必要なデータストリームを絶えず供給するためには、高度なメモリシステムとオンチップインターコネクトアーキテクチャが必要不可欠だと言えます。

あなたたちは、本当に「AI開発プロジェクト」をやる気があるのか？

　第3次AIブームを背景に、最近では多くの企業がAIの導入を検討しています。今や大企業の4社に1社がAIを導入しているという調査もあるほどです。メディアを通じて成功事例が知られるようになってきましたが、AIの導入はそんなに簡単な話ではありません。例えば、次の会話のような状況でプロジェクトを始めると、どうなるでしょうか。
A：AIで新製品の需要予測をしたいんですけども、どうしたらいいですか？
>B：予測して、その後どうするんですか？
>A：えっ……分析してから考えるつもりです。
>B：ちなみに過去の実績や参考になるようなデータはあるんですか？
>A：新製品だからありませんね。他製品のデータは経営報告のスライドに書いてあったと思いますが……。
　「AIの開発には『データがない』『分析力がない』『開発力がない』という3つのカベが立ちはだかるのが一般的です。しかし、それよりもっと重要なのが『AIに対する理解や当事者意識がない』ということ。AIを活用したいという要望を聞きに現場に赴くと、実はそんなにやる気がなかったり、『あなたたちは本当に開発プロジェクトをやる気があるのか』と感じたりする――そんな例は少なくありません」
　こう話すのは、トランスコスモス・アナリティクスのCOO（最高執行責任者）を務める北出大蔵さん。データサイエンティストとして数々のAIプロジェクトを経験し、成功事例も失敗事例も経験してきたと言います。トランスコスモスはアウトソーシング事業を展開しているため、ユーザー企業だけではなく、運用現場を担当する自社メンバーからもAI活用に関する相談を受けるのだそう。なぜ、それでも導入に失敗してしまうのでしょうか。
あなたたちは本当に「AI開発プロジェクト」をやる気があるのか？
　「AIを試してみたい」と口では言うけれど、心の底では別にAIで何とかしたいとは思っていない……。「上に言われたから」「競合がやっていたから」「お客さまに言われたから」など、理由はさまざまかもしれませんが、AI開発が自分ゴトになっていない状況でプロジェクトがうまくいくわけがありません。その例が冒頭に示したやりとりです。
　「AIでも機械学習でもチャットbotでも、ツールを使って何かやるのが自分じゃないと考える傾向がありますね。『あなたが何か便利なもの作ってくれるんでしょう？　私の手を使わずに』と思っている。
　AI開発プロジェクトを立ち上げる際、声が掛かるのはありがたいのですが、呼ばれて行っても『課題がない』とどうしようもありません。そういう場合は大抵、音声認識や需要予測といったキーワードレベルで相談が来ます。そういう目的がないケースは、プロジェクトが早々に立ち行かなくなりますし、『社内にデータがない』という理由で止まることがほとんどです」（北出さん）
なぜAIに対する理解が進まないのか？
　システムでやりたいことがあっても、使う必然性がなければ使われず、放置されるだけでしょう。この当事者意識の欠落は「年を経てどんどんひどくなってきている」と北出さんは感じているようです。その背景には、AIに対する誤解があると言います。
　「AIという言葉は、誤解を生みやすいという点でタチが悪い。自律的に勝手に学んでいく機械学習の側面と、RPAのような自動化の側面、それに加えて、音声や文字のようなアナログのデータでもデジタル化すれば処理できるという側面。
　技術的な観点では、それぞれ全く別モノなのですが、今は全てAIという言葉でくくられてしまっています。だからこそ、余計に何ができるのかが分かりにくく、『何かすごいことができそう』という感覚が先行してしまうのでしょう。触ったことも見たこともないために想像できないというのも、大きな理由だとは思いますが……」（北出さん）
　「AIをイメージできない人々も、プロジェクトに一度でも参加すれば理解は深まる」と北出さん。「AIってこういう場面なら使えるよね」という感覚を得るには、とにかく当事者意識を持って、試してみることが重要だと言います。しかし、そのための課題設定やデータ準備に膨大な時間を費やしてしまっては、プロジェクトが全く進まなくなるため、失敗前提で一度試させるようにしているそうです。
　AIに対して過度な期待を抱く人が多いのは、多くのビジネスパーソンが「業務をプロセスで考えられない」という点も関係しています。
　「本来、AIは業務プロセスの一部を効率化したり、代行する形で導入されるはずです。例えば『4段階ある業務プロセスのうち、3段階目でいつも時間がかかっているからAIを使って効率化したい』となれば分かりやすい。しかし、業務プロセスが見えておらず、『この業務が問題。理由は分かりませんが、AIで何とかなるんでしょ」という発想になってしまう。こうなると話は進みません」（北出さん）
AIの導入には「業務をプロセスベースで考える」姿勢が不可欠だという（提供：トランスコスモス）
　古くはERPパッケージやDWH、DMP、データマイニングといったツールと同様に、「これがあれば、既存の問題は解決してうまくいく」という神話が、AIでも繰り返されているといえるでしょう。このような神話を基にプロジェクトを進めてしまうと、目的や狙いなしに取りあえずAIを試してみる、といった暴挙に出ることになってしまいます。
コンセプトなき「PoC」が横行している
　「ここ2年間のAIプロジェクトは特にそうだったと感じていますが、技術部門が『PoC（Proof of Concept）』という名の単なる技術検証しかしてこなかったケースが多いですね。本来はコンセプトが必要なはずなのにそれがない。試しに使ってみた、導入してみた、それだけなのです。一通り検証を終えると『いいっちゃいいけど、なくてもいいよね』といった評価が下される。課題を解決するために導入していないのだから当然です」（北出さん）
　技術検証や調査は重要だが、コンセプトなきPoCの検証を経て、プロジェクトが成功することはない。AIプロジェクトのカベといわれる「データがない」「分析力がない」「開発力がない」というのは、何をやるか決まってからの話です。分析や開発といったポイントはSIerをはじめとした外部の力を借りることも可能ですが、課題やデータは自社で持っていなければ、プロジェクトが始まることもないのです。
コンセプトのない「PoC」を繰り返しても、何の意味もありません（提供：トランスコスモス）
　「みんながもう少し知識を持っていれば……と思うのですが、それはそれで難しいですよね。『よく分からないから専門家が何とかして！』という話で、思考停止してるんですよ。日本企業でAIが普及しないのは『データサイエンティストが不足しているから』という話をする人もいますが、私はそうは思いません。もう少し実務に沿った形で具体的に落とし込んだ議論が必要でしょう」（北出さん）
　とはいえ、当事者意識や知識がない中でも、プロジェクトを進めていかなければいけない例もある。そういう場合、北出さんは必ず「じゃあ3回失敗しましょう」とクライアントに話すのだそう。一体なぜ、必ず3回失敗することになるのでしょうか。
著者プロフィール：松本健太郎
株式会社デコム R＆D部門マネージャー。セイバーメトリクスなどのスポーツ分析は評判が高く、NHKに出演した経験も。他にも政治、経済、文化などさまざまなデータをデジタル化し、分析・予測することを得意とする。本業はインサイトを発見するためのデータアナリティクス手法を開発すること。

Googleがコンタクトセンター向けAI発表、AmazonやMicrosoftと競い合う

　Googleは、企業がコンタクトセンターで仮想エージェントやその他の人工知能（AI）技術を簡単に導入できるようにする開発プラットフォームを発表した。Googleは、Cisco SystemsやGenesysを含むコンタクトセンター分野の大手ベンダー数社と提携して製品を市場に投入している。
　Googleの「Contact Center AI」プラットフォームは、仮想エージェント、AI技術によるコールセンター担当者の支援、そしてコンタクトセンター分析の3つの主要な機能を実装している。同社はまず、2017年11月に会話型AIbotを構築するためのツールキットをリリースし、2018年7月にプラットフォームを更新してコンタクトセンター用のツールを追加した。
　仮想エージェントは、音声およびテキスト入力を認識するGoogleの自然言語処理プラットフォームを利用し、顧客からよくある問い合わせへの対応を支援する。ベンダーのGenesysは、顧客が足に合わない靴を返却する際に、チャットbotがそのプロセスを手助けし、その後コールセンター担当者へ電話をつないで新しい靴の注文を完了するまでの一連の流れを例示した。
　Googleのコンタクトセンター担当者支援システムは、よくある質問や社内文書などの会社のナレッジベースをスキャンし、担当者が顧客の質問に素早く対応できるよう支援する。分析ツールは会話や通話記録を分析して顧客の傾向を把握することで、担当者の教育や仮想エージェントの開発を支援する。
ベンダーがGoogleのContact Center AIの採用に殺到
　互いに競合する数多くのコンタクトセンターのベンダーが、GoogleのContact Center AIの採用について驚くほど類似したプレスリリースを一斉に発表した。
　このGoogleのプラットフォームは、Cisco、Genesys、Mitel、Five9、RingCentral、Vonage、Twilio、AppianおよびUpwireといった各パートナーを通じて提供される。
　「Avayaを除いたほぼ全てのベンダーが同じ会社と手を組んだ新製品の発売は、これまでに聞いたことがないと思う」と、調査・分析会社J Arnold & Associatesの主席アナリスト、ジョン・アーノルド氏は語った。
　Avayaはすっかりパートナーのリストから外れていた。同社は以前、2017年の大半を破産裁判所への申請に費やし、迅速なクラウドへの方針転換に対応できなかったことで批判を受けていた。同社は2018年初めの会議で、AI機能を社内で開発している旨を述べたと、Nemertes Researchのアナリストのアーウィン・ラザール氏は語る。
　Avayaの広報担当者は、同社のプラットフォームは、Google、IBM、Amazon、Nuanceなどのベンダーから提供されるさまざまなAI技術と統合していると語った。そして「AvayaはGoogleと密接な関係を築いており、すでに存在しているものに加えてさらなる統合の機会を追求している」と続けた。
　2018年5月、Googleの消費者市場をターゲットとした会話型AIbot「Google Duplex」のリリースがメディアで大きく報道された。同社は美容院とレストランの間で行われた短時間の通話において、プラットフォームが人間と同等のレベルで機能することを実証した。Googleによると、Contact Center AIは、Google Duplexと同じインフラストラクチャの一部を基盤として構築されたが、プラットフォームとしては別のものであるという。
　「これまでGoogleはコンタクトセンターのプレーヤーとして目立つ存在ではなかった。しかしAIが成長曲線に沿って普及する中、誰もがAIの利用方法を考えている。GoogleはAmazonと同様、明らかにAIの最も強力なプレーヤーの1つだ」とアーノルド氏は語った。
　Googleは収益の多くを広告収入に依存しているため、同社はコンタクトセンターのAIを使用して利益を上げる必要はない。この製品はAmazonに後れを取らないことに一役買っている。Amazonは2017年、コンタクトセンター向けプラットフォーム「Amazon Connect」をリリースしている。
　Googleは、常にAIモデルを改善する方法を模索しているが、Contact Center AIを通じてさまざまなデータビジネスに着手することはないと述べた。
　現在Googleとパートナーとなっているコンタクトセンターのベンダーは、以前から独自のAI技術を開発または獲得しようと争っていた。独自のAI機能がGoogleのプラットフォームをどのように補完するのかを強調する企業もある。例えばGenesysは、チャットbot、機械学習、および分析を組み合わせた同社のBlended AIプラットフォームが持つ、予測してルーティングする技術を利用して、Googleのチャットbotからオンラインの担当者に通話を転送すると説明する。
　「Amazon、Google、Microsoftなどのベンダーが提供する、高度なAI技術に必要なコンピューティング能力を使いこなせる企業はほとんどない。そのため、ベンダーが独自に機能を開発するのは困難だろうと考えている」とラザール氏は述べた。

音声コマースは主流になる？ Alexaなど音声デバイスの未来に2つの意見

　音声コマースはブームになるだろうか。The Informationの新しいレポートによると、現時点でまだブームは起きていないものの、そのために音声コンピューティングの成長が鈍化することはなさそうだと専門家は指摘している。
　レポートは、Amazonの社内統計について説明を受けた2人の話として、Alexa対応デバイス（主にAmazonの「Echo」シリーズスピーカー）所有者のうち、2018年に入ってこれまでに音声で買い物をした人は約2％にとどまると伝えている。実際にAlexaを使って音声で買い物をした人も、約90％は再び買い物をしようとはしなかったという。
「音声のみで買い物」は非現実的
　Amazonの広報担当者はこの数字に反論しているが、過去のレポートでも、スマートスピーカーを音声コマースに使っている消費者に関しては、あまり良い数字は出ていない。The Informationの数字はまた、技術コンサルティング会社Activateが2017年秋に発表したレポートとも一致する。Activateによると、スマートスピーカーの所有者の大半は、例えば音楽の再生や天気予報のチェック、アラームの設定といった比較的単純な機能のために手持ちのデバイスを使っていることが分かった。実際のところ、買い物は、ユーザーが自分のデバイスの使い道としてリストアップした項目の一覧に入っていなかった。
　だが「驚きはしない」とZK Researchの創業者で主席アナリストのゼウス・ケラバラ氏は言う。「音声には多大な潜在的可能性があると思う。ただ、今のところは多くの信頼問題が存在する。これはオンラインショッピングに起きたことと似ていなくもない。何度か試してみて、ある程度の確信が持てるようになるまでは慎重な人が多かった」
　音声のみを使って買い物をするのはそもそも単純に現実的ではないと指摘するのは、Forresterで主席アナリストを務めるジュリー・アスク氏だ。
　「単純な商品の補充を越えて、（音声だけで）買い物をするのは単純に難し過ぎる。もっと簡単に買い物できる方法がある。閲覧は難しく、画像を見ることもできず、現実的に商品説明を聞き取ることもできない。そんな状況で誰が買い物をしたいと思うだろうか」（アスク氏）
　さらにアスク氏は「Amazonの市場シェアはトップだが、小売業者は同社と組むことに二の足を踏んでいる。それが、Alexa対応デバイスを通じた買い物の数字が振るわない一因になっているかもしれない」と言い添えた。
企業における音声技術
　以上を前提としると、企業は音声コンピューティングの追求を思いとどまった方がいいのだろうか。そんなことはないと話すのは、Gartner調査ディレクターのワーナー・ゲルツ氏だ。現時点で「ママとパパ」がAlexa対応デバイスで買い物をしていないという現状は、音声人工知能（AI）分野全体の価値について、あるいは今後の消費者のショッピング行動について多くを物語っているわけではなく、音声コマースは確実に進展すると同氏は予想する。Alexa対応デバイスが現時点であまり買い物に使われていないからといって、最高情報責任者（CIO）が音声コンピューティングへの投資を思いとどまることはないというのだ。
　ゲルツ氏は「電子商取引機能と利用は自然と成長する。サービス業界や飲食店、チェーン店は既に、音声AI技術を使ったさまざまな取引方法を取り入れた概念実証や用途を確立しつつある」と指摘した。
　ゲルツ氏が挙げたその一例として、AmazonはMarriott Internationalと組み、「ホスピタリティー向けAlexa」戦略の一環として、スマートスピーカーのAmazon Echoをホテルに導入し始めた。ホテルの利用客は、Alexa対応デバイスを使ってルームサービスの注文や、追加のタオル手配、エンターテインメントの注文などができる。
　「企業は確実にブランドエクスペリエンスの刷新を試みており、スマートスピーカーや多面的な音声交流を通じてそれを行っている」とゲルツ氏は話す。
　ゲルツ氏の言う多面的な音声交流とは、Amazonの「Echo Show」のような画面付きの音声アシスタントを指す。同氏によると、そうしたデバイスは音声コマースのような機能に適しており、Forresterのアスク氏が挙げたような音声のみのショッピングにまつわる問題の一部を解消できる。
　ガートナーのアナリストであるランジット・アトワル氏も、音声と動画、チャット、画面を使った多面的な音声デバイスを使えば、いずれもっと頻繁に複雑な買い物ができるようになり、より統合的なカスタマーエクスペリエンスが実現できるとの見方で一致する。ただし、アトワル氏も音声コマースは「まだまだこれから」だと考えている。
　ケラバラ氏が述べるように、音声がインタフェースの主流になる日はいつか来る。われわれはただ、そこへ到達するために少しずつ進まなければならない。
　アスク氏はCIOが認識すべきこととして、「（音声技術を）使用し、実験する必要がある。ただし情報の取得やコントロールなどが簡単な、理にかなった筋書きで行わなければならない。簡単にできる以上のことに手を伸ばしてはならない」と話している。

Googleのウルス・ヘルツル氏に聞いた、「IstioやKnativeで目指すのはクラウドのアンロックイン」

　Googleのデータセンターインフラおよび開発プロセスの構築に貢献してきた同社テクニカルインフラストラクチャ担当シニアバイスプレジデント、ウルス・ヘルツル（Urs Hölzle）氏は、近年同社のクラウドコンピューティングプラットフォーム、Google Cloud Platform（GCP）を支える活動への関わりを強めている。
　＠ITでは、「クラウドを支える技術 ―データセンターサイズのマシン設計法入門」（Morgan＆Claypool Publishers／2013年）の著者の一人としても知られる同氏に単独インタビューし、Google CloudがGoogle Cloud Next '18で発表した、Istio、Knative、Cloud Services Platformなどへの取り組みについて聞いた。
　ヘルツル氏は、インタビューの中で、IstioやKnativeの目標が、複数クラウド間のAPI標準化にあると答えている。Cloud Native Computing Foundation（CNCF）における活動との関連でも、このコメントは注目される。
アプリケーション運用に共通の手法を持ち込みたい
――まず、Cloud Services Platformとは結局、プロダクトなのか、ビジョンなのか、フレームワークなのか、コンセプトなのかを聞きたい。
　Cloud Services Platformは、Istio、Knativeなどのオープンソースソフトウェア群と対になるGoogle Cloud Platform上のサービスだ。顧客はまず、これらのソフトウェア――IstioやKnativeを、GCP以外のパブリッククラウドやオンプレミスなど、どこでも動かし、活用できる。一方、GCPではこれらをはじめとしたソフトウェアを統合した、利用しやすい環境を提供する。これがCloud Services Platformだ。
　ここで最も重要な要素はIstioだ。1年以上開発を進めてきており、本番運用に使えるものになったという判断から、バージョン1.0のリリースに至った。実際にeBayなど多数の組織で、本番運用が始まっている。そこでGoogle Cloudでは、これを（マルチクラウドのアプリケーション運用技術として）推進していく。
――しばらく前、「Istioはスケーリングが不十分」と言っている人がいた。
　1年前くらいなら、そうした言われ方もされていた（が、その後改善された）。また、現在においても、非常に高いパフォーマンスを求められるアプリケーションについては当てはまるだろう。マイクロサービス単位でプロキシを導入するので、パフォーマンス上のオーバーヘッドは避けられない。
　だが、そうした場合でも、ハードウェアの負荷分散製品を使って対応できる。こうした製品に入れ替えたからといって、ユーザーにとってはAPIや構成内容が変わることはない。負荷分散製品は舞台裏でプログラムされるからだ。ユーザーは存在を知る必要がない。従って、ハイパフォーマンスアプリケーションにIstioが適用される日も遠くはないと考えている。
　とはいえ、Istio 1.0では一般的なITアプリケーションを対象としている。こうしたアプリケーションの運用管理に大きなコストが掛かっていることが多いからだ。
――人々は仮想マシンからコンテナ、PaaS、Functions as a Service（FaaS）まで、さまざまなレベルでアプリケーションやマイクロサービスコンポーネントを開発・運用する。こうした多様な抽象化レベルにまたがる統合的な管理を目指そうとしているのか。
　もちろんだ。さまざまなものを統一的に運用できるようにすることが、私たちの目標だ。仮想マシン、コンテナ、ファンクション。これらの実装は大きく異なる。だからといって、認証、ディスカバリ、ロギングなどのやり方が違わなければならない理由はない。同一であるべきだ。例え昔に書かれたMS-DOSベースのバイナリであっても、コンテナ化し、Istioプロキシを適用すれば、このバイナリがモダンなマイクロサービスとして使えるようになる。言いたいのは、コードを基本的には書き直すことなく、クラウドネイティブなサービスのエコシステムに組み込めるということだ。そしてこのエコシステムは、共通の手法、ツール、コンフィグを通じて運用管理ができる。
　最終的には、Google Cloud Functions、Google Kubernetes Engine、Google App Engineなどの上の全てのアプリケーションがIstioのエンドポイントとして同じように見え、管理できなければならない。各アプリケーションの実装が変わっても、呼び出す側はそのことを知る必要がない。システム運用担当者も知らなくていい。こうなれば、大幅なシンプル化ができる。まだそこまでは実現できていないが、私たちの目標であることは確かだ。
　言い直すと、サービスは仮想マシン、ファンクションなど、多様な実装方法によって構築される。しかし、アクセス権限管理やサービス間の認証をはじめとした運用管理については、標準化されなければならない。標準化さえできれば、そこにエコシステムが生まれ、ツールから実践ノウハウ、トレーニングまでを共通化できる。将来、新しいアプリケーション開発・運用プラットフォーム技術が登場したとしても、運用担当者はそれをことさら意識する必要がない。さらに、どこで動かしても、運用のやり方は同じだ。
――では、サーバレスでは既存のサービスがあるにもかかわらず、Knativeという新たなソフトウェアを始めたのはなぜか。
　既存サービスとの互換性は今後確保していくことになる。私たちの実装はおそらくKnativeに移行していくことになるだろう。なぜなら、大局的に考えれば、実装は大した問題ではないからだ。Kubernetes上に実装すれば、どこでも動かせるようになる。
　（クラウドベンダーは、）実装の優劣を競うことはできる。だが、運用APIは統一されるべきだ。このため、運用APIはオープンソースでなければならない。これを実現する取り組みの1つがKnativeだ。
　現在の状況は、Kubernetesをオープンソース化した頃に似ている。当時少なくとも1ダース以上のコンテナオーケストレーションシステムがあったが、その後Kubernetesが事実上の標準になった。「どれ」が勝つかよりも、どれかが「事実上の標準になる」ことが重要だ。
　私たちはKnativeについて、業界内の有力パートナーと協力し（筆者注：オープンソースプロジェクト開始時点では、Googleの他にPivotal、IBM、Red Hat、Cisco Systemsが参加している）、サーバレスをどのように見せるかについてのコンセンサスを醸成しようとしている。繰り返すが、Knativeにおける私たちの目標は、実装ごとに独自であってはならないものを統一することだ。
――今の話を敷衍（ふえん）すると、サーバレスだけでなく、クラウド全般について同じことが言えるということなのか。つまり、「現在、さまざまなクラウドが差別化すべきでないところで異なっており、これが（柔らかな）ロックインにつながっている。こうした状況を変える」ということなのか。
　クラウドは未来永劫、それぞれが異なるものであり続ける。GCPのプロダクトでいえば、BigQueryやCloud Spannerはそれぞれがユニークな機能を果たしており、オープンソースではない。こうしたプロダクトで差別化を図っていくのは当然のことだ。私たちが注目しているのは、「クラウドにおけるAPIの80％が、同じような機能を果たすにもかかわらず、異なっている」という事実だ。
　例えば、GCPにおける仮想マシンの起動方法がAmazon Web Services（AWS）に比べて優れているかどうか。大局的に言えば、ユーザーはそんなことを気にしない。やり方を統一すれば、全てのツールやスクリプトが自動的にクロスプラットフォーム対応できる。
　Kubernetesは、コンテナのデプロイに関するアクションやオートスケーリングに関する多くの部分で、事実上の統一を実現した。だが、どちらかと言えば実装レベルにとどまっている。
　Istioはその自然な延長線上にある。サービスそのもの、すなわちAPIエンドポイント自体を対象とし、それぞれにディスクリプションを与えて、お互いに呼び出す際の認証などを提供できる。Kubernetesよりも1つ上のレイヤーで、サービスに立ち入った詳細なコンフィグができる。
　誰もがサービスエンドポイントを持ち、認証し、ロギングを行っている。こうした共通の機能については、やり方を統一すべきだ。Istio自体はロギングをしない。ログサービスを呼び出すだけだ。呼び出す相手はGCPのログサービスでも、あなたが書いたログソフトウェアでもいい。コンフィグさえすれば、後でより良いサービスを選んで使える。あなたのプログラムはどんなログサービスを使うかを知る必要はない。運用担当者にしても、ログソフトウェアを変える際に大きな設定変更をする必要はない。ロギングのためのプラグインインタフェースは標準化されているためだ。
　いずれにしても重要なのは、例えばセキュリティポリシーについて、表現方法のみを標準化すること。そして実装については、好きなものを選べるようにすることだ。
　例えばアカウント情報をActive Directoryに持っているなら、プラグインを通じてActive Directoryを使えばいい。Google Cloud Directoryを使ってもいい。各認証システムに独自の作業をする必要はない。どれを使う場合でも、コンフィグは同じだ。
――関連する質問として、今後IstioとApigeeの関係はどうなっていくのだろうか。
　Apigeeは、Istioプロキシのアップグレード版だと考えてもらえばいい。どれかのサービスエンドポイントについて、Istioの代わりにApigeeを使いたいと思ったら、ボタンをクリックするだけですぐに切り替えられる。使い勝手としては統合されている。
　ユーザーは、一般的なIstioエンドポイントについてはIstioプロキシ（注：すなわちEnvoy）を適用すればいい。Apigeeは機能が豊富な代わりに重量級であり、全てのエンドポイントに適用するわけにはいかない。だが、ビジネスクリティカルであり、外部に提供するためにきめ細かな制御や機能が必要なエンドポイントについては、Apigeeを選べばいい。ここで重要なのは、システムを構築する際に、Apigeeを使うかの選択をしなくていいということだ。後で必要に応じて切り替えればいい。
――では、FaaSについて聞くが、GCPでは、ファンクションで複雑なアプリケーションを構築するようなユースケースに対応したいのか。直接的に聞くと、AWS Step Functionsに相当するようなサービスプロダクトを提供しようとしているのか。
　それはいい質問だ。
　まず、（Step Functionsのような機能が将来求められるからこそ、）FaaSに関しても標準化が必要だ。共通のAPIについて合意ができれば、全ての主要プレイヤーにおけるサービスや製品に対し、同一の機能を共通に適用できるようになる。
　また、AWS Step Functionsは非常にハイレベルなツールとして、数十、数百のファンクションを管理することを目的としている。ただし、同様なことを実現するアプローチは、他にも多数存在する。
　例えばGoogle App Engineはその一つだ。App Engineはハンドラの集合体であり、これをまとめ上げてアプリケーションの構築に使える。しかし、FaaSにおけるファンクションと同様に、それぞれのハンドラは独立している。本質的に、App Engineは非常にイベントドリブンだ。
　私は何が正解なのか、（現時点では）分からない。だが、ファンクションを管理できるようにする何かが必要であることは明らかだ。例えば「ストレージバケットを作成して、これに対するイベントが発生したときに最小限の作業を行い、このプロセスが消える」といった簡単な処理ではなく、100にも上るようなハンドラが相互につなぎ合わされたイベントベースのシステムを構築した場合、（システムの中で）何が起こっているのかを理解することがとても難しくなる。Step Functionsにしても、何が起こっているのかを把握することは簡単ではない。
　もしかしたら、良いプログラミングプラクティスが求められるということなのかもしれない。オブジェクト指向プログラミングでは、次第に人々が良いプログラムを書くためのプログラミングパターンを理解するようになった。ファンクションにおけるプログラミングパターンとはどういうものなのか。やるべきこと、やるべきでないことの双方について、パターンが確立される必要があるのだろう。
　とはいえ、「非常に軽量なステップで、イベントドリブンなシステムを作る」というファンクションの考え方は、今後長きにわたって生き続けるべき、優れたコンセプトだと思う。

観光地の“地域データ×人流データ”を観光マーケティングに活用――松江市と日本ユニシスが共同実証

　島根県松江市と日本ユニシスは、松江市の地域データと日本ユニシスの「人流解析サービス JINRYU」（以下、JINRYU）で得た人流データを組み合わせ、観光施策の立案に役立てる実証実験を開始する。実証実験は、2018年8月29日から12月20日までで、松江歴史館や松江駅、松江城、塩見縄手周辺などで行う予定。
　国宝の松江城や松江歴史館、宍道湖などの観光資源を有する松江市は、市の統計データや統計関連図書情報のオープンデータ化、地域の歴史資料を地理情報とひも付けてデジタルアーカイブ化した「松江G空間ミュージアム」を開設するなど、データを活用した観光・文化振興の取り組みを推進している。
　今回、その一環として、データを活用した観光マーケティング方法の確立を目指し、松江市のオープンデータやタウン情報サイト「Lazuda（ラズダ）」、SNSデータなど、さまざまな機関が発信する松江市の地域データと、JINRYUで採取した人流データ（行動動線、年齢・性別などの属性）を、データ収集基盤でAI（機械学習）を活用して統合し、地域データベースを構築する。
　統合した地域データは、データ分析に基づく観光客の動向把握や観光施策立案に活用する他、スマホ向け観光アプリで地図情報と合わせて観光客に提供し、観光客支援に役立て、それらの有効性を検証する。
　また、松江歴史館で行う実証実験では、集約した観光情報とJINRYUの人流データから来場者数を予測する手法の有効性も検証する。
 

実証実験のイメージ
　なお、JINRYUは、カメラに併設する小型コンピュータ（エッジコンピュータ）上でカメラ映像の人物や顔を認識して動線、年齢・性別などを推定し、日本ユニシスグループが提供する「IoTビジネスプラットフォーム」上で可視化、分析するクラウドサービス。個人を特定できない映像解析データのみをクラウドに送信し、解析後の映像データは保存せずに破棄するため、個人情報漏えいのリスクが低い他、基盤としている「Microsoft Azure」のデバイス運用管理機能やAPIによる拡張性なども備えている。
 

「人流解析サービス JINRYU」の設置イメージ（出典：日本ユニシス「人流解析サービス」）
　松江市と日本ユニシスでは、実証実験で得られた知見を基に、地域データの収集・活用と施策の効果測定を円滑に実行できる仕組みをつくり、データに基づく観光マーケティングの継続した実施を目指す。また、観光分野だけでなく、防災や少子化などの社会課題にも、実証実験で得られた知見の活用を検討していく。

TIS、商用ブロックチェーン「BCLチェーン」に出資 “スマートロック×スマートコントラクト”のサービス提供へ

　TISは2018年8月23日、ブロックチェーン技術を用いたシェアリングサービスを提供するスタートアップ企業のブロックチェーンロックに、ベンチャー企業への投資を行うコーポレートベンチャーキャピタル（CVC）から出資したと発表した。
　ブロックチェーンロックは、スマートロックとスマートコントラクトを組み合わせた商用ブロックチェーンサービス「BCLチェーン」を開発する、2018年3月に設立されたスタートアップ企業。BCLチェーンの普及に向け、BCLチェーンによるトークンエコノミーの形成を目指しており、最初のユースケースとして「宅配ボックス」「コインランドリー」などのスペースレンタルビジネスをはじめとしたIoT活用のシェアリングビジネスを中心に、決済インフラとしての参入を狙う。
　ブロックチェーンロックによると、BCLチェーンが提供するブロックチェーンは、ブロックチェーンのセキュリティに守られた強固なスマートロックで、高速なスマートコントラクトを実現するBCLチェーンとの連携により、「P2Pで自ら契約締結と支払いをする鍵」として、シェアリングビジネスを高度化できるとしている。
　TISは、「デバイス間の支払いとスマートコントラクトの実行を確実かつセキュアに実行するBCLチェーンをベースに構築されるシェアリングサービス基盤」と、TISが長年培ってきた「システム開発と保守運用の経験」を組み合わせて、企業の既存業務のデジタル化や新規ビジネスの創発を推進するという。
　具体的には、「民泊」「店舗管理」「ビル管理、スマートシティー」「介護」などの分野で、BCLチェーンを活用したスマートロックやシェリングエコノミーの実現と、ブロックチェーンロックが発行する「BCLトークン」を使ったサービスの提供を目指す。
　提供するサービスの決済機能には、TISの決済ソリューション「PAYCIERGE（ペイシェルジュ）」のQRコード決済や、BCLトークンを用いたIoT決済などのシステムと連携していく。