タグ: ニュース

先の週末、Elon Muskは、人工知能に関する政府の規制を求めるコメントを発表した。これまでも彼は、この技術が放置されることによる人類への脅威に対する懸念を繰り返し表明して来ている。Muskは本日（米国時間7月19日）、国際宇宙ステーションの研究開発会議に参加していたが、その休憩時間中の談話の中で、参加者の質問に答える形で、この問題に対する彼の見方をさらに説明した。

Muskは、まず政府機関が設置され、AIとその利用に関する洞察を深めることを想定していること、ただしそのやり方は「背後から撃つようなやり方で」規制をするようなものであるべきではない、ということを明言した。土曜日のNational Governors Associationに於ける、「積極的な規制」の必要性に関する彼のコメントに対して、即座に或いは近い将来に規制が敷かれるべきだという主張だと解釈した者もいた。

実際にはそうではなく、Muskは、AIの利用と開発について、事実に基いたルールを導入するために必要な洞察を求めるプロセスを今すぐ始めるべきだ、と考えているのだと語った。Muskはこのプロセスを、FCC（連邦通信委員会）やFAA（連邦航空局）のような、業界における技術利用を規制するための、他の政府機関を設立するプロセスと比較している。「おそらくFAAがなくなれば良いのに、と考えている人はいないでしょう」と彼は語った。Musk自身が、起業家としてしばしば規制に欲求不満を抱いているにも関わらず、彼がAI規制に関する探求を始めることが大切だと考える理由はここにある。

TeslaのCEOはまた、なぜ彼がAIの潜在的脅威をそれほどまでに気にするのかの理由も少し説明した。彼はDeepMindのAlphaGoの例を挙げ、多くの専門家が予想していたよりも遥かに早く、最強の棋士たちが打ち負かされたことがその理由だと述べた。彼はまた、AI専用の処理装置の開発についても指摘した。これは、現在のGPU搭載バージョンよりもAIパフォーマンスを何桁も向上させることを目指しているものだ。

「これは本当に大きな問題になるでしょう。それは津波のようにやってくるのです」と彼は語った。

[ 原文へ ]
（翻訳：Sako）

Googleが（米国時間の）火曜日にGlassの新しいエンタープライズ版をリリースしたとき、幾つものヘッドラインたちがGlassが戻ってきたと報じた。だがそれが立ち去ったことは実際には1度もない。確かに2015年1月には消費者向けのExplorerプログラムは終了したが、Googleはその後も引き続きGlassを企業に販売して来た。

その意味で、昨日リリースされたものは「復活」ではなくて、同社が全力で進めてきたGlassのエンタープライズ戦略の「継続」だ。昨日の発表はそれをただ公式にしただけのものに過ぎない。

GoogleがExplorerプログラムを終了した直後の2015年には、複数の企業がGlassを使った作業を継続して行くと語り、Google Glassは企業の中で健在で、使われ続けていることが示されていた。当時APX Labs（現在はUpskillという名前で知られている）のCTOだったJay KimはTechCrunchに対して、「グーグルは引き続き、Glassをパートナーに大量に売っていますよ」と語った。

昨年、企業における「顔の上のコンピュータ」に関する特集記事で、私は現場でGlassを使用しているGEとボーイングの人びとに話を聞いた。ボーイング社はこれを使用して、従業員が複雑なワイヤーハーネスを組み立てる作業を支援していた。Glassを使用すれば、在庫からワイヤを引き出しながら部品番号をスキャンすることが可能で、次の手順を確認することができる。さらに、音声コマンドを使用して検索を行うこともできる。この方法は、技術者が手を自由にして作業を行うことができ、情報が目の前に現れるために、ラップトップやタブレットを使用するよりもはるかに効率的なものだ。

2016年1月にGEヘルスケアのウェブサイトでは、GEはGlassの利用も含む以下のような先進技術に触れている：

緊急治療室（ER）に向かう救急医療技術者たちは、Google Glassを使用して病院の医師とリアルタイムのビデオや音声でコミュニケーションを行い、患者の最新状態を提供し続け、患者の到着を待ち構える救急チームが、正しい準備を整えることができるようにする。

今年5月、 IEEE Spectrumは、ER内でGlassを利用した同様のシナリオに関する記事を掲載した：

遂にマサチューセッツ大学医学部の医師チームは、同デバイス向けのキラーアプリを発見したようだ。緊急医療コンサルテーション用途である。Glassは、離れた地にいる専門家たちが確実かつ正確に、患者の観察および診断をリアルタイムに行なうことを可能にする。災害シナリオでは、第一対応者によるトリアージ（被災者をその重症度に応じて分類し治療の優先度を決めること）を助けることも可能だろう。

今回のエンタープライズアップデートでは、これまで初期のGlassデザインを利用していた企業に大きくアピールすると思われる、興味深いいくつかの変更が加えられていることは注目に値する。主な変更の1つに、Glassモジュール（Glassの本体）をフレームから切り離したことが挙げられる。これによりサードパーティパートナーがモジュールを、安全メガネなどの任意のフレームに装着できるようになった。

また新しいバージョンでは、簡単な入力のために、ユーザーがGlassをバーコードスキャナやキーボードなどの他のデバイスに接続することも可能だ。その他の変更としては、バッテリー寿命の延長、8メガピクセルのカメラ、より高速なプロセッサー、そして軽快に動作するWi-Fiなどがある。

現時点では、GoogleはGlassの主要対象業種として製造、物流、フィールドサービス、ヘルスケアを狙っているが、サードパーティのパートナーたちが他の分野での応用を目指す可能性がある。

昨日の発表で、Explorerのプログラムが終了したときにGlassはお蔵入りしたと思っていた人たちは驚いたかもしれないが、実際には大企業とサードパーティのパートナーたちは引き続き作業を続けていた。Enterprise Editionはそれをよりはっきりと世界に訴えたものであり、初期のハードウェアに対する必要なアップデートを提供するものだ。

[ 原文へ ]
（翻訳：Sako）

クラウド型のRPAサービスを開発するBizteXは7月20日、シードラウンドでジェネシア・ベンチャーズから総額4000万円を調達したと発表した。

7月5日に「BizteX cobit（以下、cobit）」のクローズドβテストを開始したBizteXは、今回調達した資金をBizDev系人材の採用と顧客獲得に用いるとしている。

産業用ロボットが工場をオートメーション化したように、日頃の業務に存在するルーティーン・ワークをソフトウェア・ロボットに覚えさせ、人間の代わりに働いてもらおうというのがRPA（Robotic Process Automation）のコンセプトだ。

最近では、〇〇の自動化や効率化と聞くと、“API連携”という言葉を思い浮かべる読者も多いことだろう。APIによる自動化では、連携によって他サービスから取得したデータをシステムが自動的に処理することにより、複数のサービスを跨いだ自動化を実現する。一方のRPAでは、クリックやコピペなど、人間がキーボードとマウスを使って行う動作の流れをロボットに覚えさせて自動化する。

例えば、Googleでトヨタの株価を毎日チェックして、エクセルに入力するというルーティン・ワークを自動化したいとする。その場合は、

1. Googleの検索窓に「トヨタ 株価」と入力
2. 検索結果にある株価（テキスト）をコピー
3. それをエクセルにペースト

という一連の動作をロボットに覚えさせ、毎日繰り返し、それを行なうようにセットする。イメージ的には、キーボードの前にロボットがいて、そのロボットが直接マウスやキーボードをカチャカチャと操作してくれる感じだ。

クラウド型RPA

日本のRPAサービスとして、RPA Technologiesの「BizRobo!」やNTTデータの「WinActor」などが挙げられるが、BizteXが提供するcobitの最大の特徴はクラウド型のサービスであるということだ。

クラウド型のcobitは、同種のオンプレミス型RPAサービスとくらべて導入が容易で、初期費用もかからない。BizteXはcobitの正式リリース後に月額10〜30万円程度の従量課金制を採用する予定だが、この料金水準も他社が提供するオンプレミス型サービスよりも低いという。

7月5日から開始したクローズドβテストに参加した企業数は非公開だが、BizteX代表の嶋田光敏氏は「大手の人材系や金融系企業など、複数の業種や業務でトライアル導入含めて話が進んでいる」と話す。

また、cobitは非技術職の人でもロボットが簡単につくれるように工夫されている。cobitはそのインターフェイス内にWebブラウザを内蔵。ロボットを設計するためには、そのブラウザ上で実際の動作をデモンストレーションしながら、“〇〇と入力する。ここにあるボタンを押す”というような動作ステップをクリックして追加していくだけでいい。

僕は実際にサービスのデモ動画を見せてもらったが、それを見る限り、ロボットの設計自体はさほど難しいものではなさそうだった。コーディングに精通していない人でも十分操作できる難易度だ。

ただ、クラウドだからこその難点もある。その1つがセキュリティの問題だ。例えば、あるWebサイトにロボットがログインする場合、それに必要なIDやパスワード（または、それが書かれたエクセルファイルなど）がCobitのサーバーにアップロードされることになる。そこに不安を感じるユーザー企業は少なくないだろう。

それについて嶋田氏は、「クラウドサービスが普及するなか、セキュリティに関する懸念の声は（クローズドβ版に参加を決めた）ユーザー企業からは聞こえなかった」とコメントしている。

しかし、2017年6月にスマートキャンプが発表した「SaaS業界レポート 2016-2017」によれば、クラウドサービスを利用しない理由として回答者の38.8%が「セキュリティに不安がある」と答えていることも事実だ。

RPA分野のクラウド化は進むか？

日本語版のWikipediaに「RPA」という項目ができたのは2016年4月のこと。この比較的新しい分野では、オンプレミス型とクラウド型のどちらに軍配が上がるのだろうか。

先ほど、クラウド型のセキュリティに関する懸念については述べた。しかし、ルーティーン・ワークの大半がセキュリティに関してセンシティブな作業というわけではない。それに、大きな価値を生み出すわけではないルーティーン・ワークを、“手軽に、そして安く自動化したい”というニーズをもつ企業は多いだろう。

また、前述したスマートキャンプのSaaSレポートにもあるように、クラウド化が進む度合いは業務がもつ性格ごとに大きく異なる。汎用的な業務であればあるほど、そこにクラウドサービスが導入されることが多いのだ。これらの要素を踏まえれば、ルーティーン・ワークを自動化するRPAでもクラウド化がすすむ可能性は非常に高いと僕は思う。

嶋田氏によれば、BizteXはβテストを通して教師データを集めたあと、“Aという作業ができなければ、代わりにBを行う”というような条件分岐を、ロボットが自動で推測する機能などを実装する予定だ。

cobitの正式リリースは2017年8月末頃を予定している。

本日（米国時間7月18日）Googleは、企業のデータセンターからフェデックス経由で大量のデータをクラウドに移行するための、新しいハードウェアアプライアンスとサービスであるTransfer Applianceのローンチを発表した。Googleは既に、ストレージアレイ、ハードディスク、磁気テープ、USBフラッシュドライブなどの物理メディアを、サードパーティのパートナーを通じてGoogleのデータセンターに持ち込むサービスをユーザーに提供しているが、Transfer Applianceはそれに比べてもかなり洗練されたものだ。同社はまた、このサービスのために、100TBまたは480TBの（もしデータが簡単に圧縮できるならそれ以上の容量も可能）あらゆるデータをクラウドに発送するために使用できる、独自のハードウェア機器も開発した。

もしこのサービスに聞き覚えがあると思ったとしたら、おそらくAmazonが提供する類似の機能、AWS Snowballのについて聞いたことがあるからだろう。Snowballには50TBと80TBのバージョンがある。もしそれ以上（100PBまで）の容量が必要な場合には、Amazonは顧客のデーターセンターへトラックで受け取りに出向くサービスも提供している。AWS Snowmobileサービスだ。

ここでのコンセプトは極めて素直なものだ。まずGoogleがアプライアンス（機器）を顧客のデータセンターに送る。顧客はそれをラックの1つに設置してローカルネットワークに接続する。その後Googleのツールを用いてアプライアンスをデータで満たしてGoogleに送り返す。

Googleのクラウドストレージプロダクトの、グループプロダクトマネージャであるDave Nettletonによれば、顧客の物理的メディアを受け取ってデータをクラウドに移行するGoogleの既存のサービスは、一部の顧客には役立っているものの、多くの企業はペタバイト単位のデータを移行するための容易な手段を探している。また、本日の発表は、Google Cloudのデータ移行ポートフォリオを拡大して、既存の企業にアピールするための広範な動きの一環であるとも指摘した。しかし、もっと重要なのは、今回のサービスによって、Googleの戦略はどのような顧客（および潜在的な顧客）のニーズにも対応可能になったということだ。

「GCP（Google Cloud Platform）は、クラウドネイティブ企業とは大変うまくやってきています」と、Nettletonは私に、Snapをその例として挙げながら説明した。「これに対して、従来から存在する企業たちにとっては、今回のサービスは、私たちが提供を始めることを期待していた機能なのです」。

100TBモデルを使用するための基本コストは300ドルで、それに配送料を加えたものになる。Googleによれば合計で500ドルほどになるという。480TBユニットの場合、基本コストは1800ドルで、配送料として約900ドルが必要になる。ユーザーは、追加費用を支払うことなく、小さな方（100TB）アプライアンス機器をデータセンター内に10日間設置することができる。大きな方（480TB）は、25日間は延滞料なしでデータセンターに設置することができる。

以前Microsoftで、AzureとSQL Serverの仕事をしていたNettletonは、Google Applianceトラックサービスをすぐに立ち上げる予定もあるのか​​どうかについては触れなかったが、多くの既存企業がクラウドへ移行しようとしていることは、すべてのパプリッククラウドが理解していると述べた。その過程で、多くの企業が膨大なデータを、オンプレミスデータセンターからクラウドへ移管しようとしている。よってそうしたGoogle Cloudトラックの情報に関して目を離さないことをお勧めする。なぜなら一部の企業にとっては、それがデータをクラウドに移管する唯一の経済的な方法かもしれないからだ。

[ 原文へ ]
（翻訳：Sako）

プログラミング言語Cはおぞましい。いや、素晴らしくもある、もちろん。私たちの住む世界の大部分はCの上に作られている。そしてほとんどのコンピュータープログラミングの基礎をなしている、歴史的にも、実質的にも。Xavier Nielの革新的な “42” スクールのカリキュラムが、学生に標準Cライブラリー関数を一から書き直させることから始まるのはそれが理由だ。しかしCは、C自身が作り上げたこの世界にとってもはやふさわしくない。

「おぞましい」と言ったのは「悪い」ということではなく「畏敬の念を起こさせる怖さ」という意味だ。Cはモンスターになってしまった。あまりに多くの大砲を与えたためにユーザーは自分の足を撃ち抜いてしまう。豊富な体験が教えるところによると、セキュリティーホールにむしばまれることなく大量のCコードを書くことは非常に困難であり「事実上不可能」になりつつある。2年前、私は最初の「Cに死を［Death To C］」の記事にこう書いた：

原理上、ソフトウェアが成長し進化して成熟度を増すほど、セキュリティー脆弱性は複雑になっていく。しかし、C/C++で書かれたソフトウェアにそれは当てはまらない。バッファーオーバーフローや宙ぶらりんのポインターのために壊滅的セキュリティーホールが生まれる事態は、繰り返し繰り返し起こっていて、昔も今も変わることがない。

私たちはこれ以上巨大な口を開けたセキュリティーの盲点を放っておくことはできない。引退して別の言語に取って代わられる時期はとうに過ぎている。問題なのは、ほとんどの近代言語はCを置き換えようという意欲すら持っていないことだ。〈中略〉どの言語もCが最も得意とすることに長けていない ―― 例えばシステムの奥深くまで掘り下げてマッハスピードで動くこと。

あなたがデベロッパーなら、私の言いたいことはもちろんわかっているだろう。Rustの長所を並べることだ。実際これは有望なC/C++の後継だ。2年前に私は、新規の下層レベルコーディングをCではなくRustで書くことを勧めた。つまるところ、穴に関して何よりも大切なのは、掘るのをやめることだ。

［Cでプログラミングする際のセキュリティー心得（2017年版）：
1）タイプするのをやめる
2）すでにタイプしたものを削除する］

今私は、エンジニアが既存のCコードをリファクタリングするとき、特にパーサーなどの入力ハンドラーを書き直すとき ―― ゆっくりと、すこしずつ ―― Rustで置き換えるように真剣に勧めている。

何か行動を起こす必要がある。自分たちのソフトウェア基盤を強固にしなくてはならない。それは、オペレーティングシステムやドライバー、ライブラリー、コマンドラインツール、サーバー等あらゆるものを修正するという意味だ。今すぐ、あるは来年までに直すことはできないかもしれないが、おそらく10年後には状況が改善されているだろう。

残念ながら、全部を書き換えることはできない。〈中略〉私が勧めるのはもっとずっと簡単なこと：弱い部分を手術で置き換え、プロジェクトの大部分はそのままにしておくことだ。〈中略〉既存プロジェクトからCコードの断片を取り出し、RustからアクセスできるようにCの構造体と関数をインポートし、コードをRustで書き直し、Rustから関数と構造体をエキスポートし、コンパイルしてプロジェクトのほかの部分とリンクすればよい。

Rustはもちろん万能薬ではないし、ソフトウェアの安定性とセキュリティーを改善する有効な方法はほかにもたくさんある（例えば形式検証［Formal verification］やLangsec構想など）。しかし、これは有望で価値ある反復アプローチであり、私たちはこの巨大なセキュリティーホールから自らの手で這い出すために、良いコードを書き良いツールを使うことをスコップ一杯ずつ反復していくことしかできない。掘り始めるのが早ければ早いほど、Cは早く風化していく。

[原文へ]

（翻訳：Nob Takahashi / facebook ）

昨年Walmartが買収したオンライン小売業者Jetは、都市部での顧客へ配達を容易にすることを狙って、スマートアクセス提供業者のLatchと契約を結んだ。

このことにより1000棟のアパートに住む、10万人以上の住民たちは、建物の外部ドアに設置されるLatchの住居用”R”システムに、自由にアクセスできるようになる。設置費用はJetとLatchの「共同出資」によって賄われる。

このことにより、住人たちは自分の携帯電話を建物に入るキーとして使うことができるようになり、階下に降りていかずとも訪問者のアクセスを許し、そしてもちろん留守中に安全に小包を受け取ることができる。ビル管理者たちは、Latchのシステムを使用して、USPSのような信頼できる配送業者へのアクセスを許諾することもできるが、これらの1000台のユニットは既にJetの配送パートナーからアクセスできるように設定されている。

はっきりさせておくが、これはマーケティングパートナーシップであって、運用上のパートナーシップではない。Jetのバックエンドとの統合は特に行われないが、一方JetはユーザーがLatchの設置された建物に済んでいることを認識して、通常はドアマンやスマートアクセスシステムを必要とする生鮮食品などの注文を行なうことができるというメリットを、ユーザーに対してプロモーションする。

少なくともこれは、多くのニューヨーカーにとって目に見えるメリットをもたらすマーケティングパートナーシップだ。

このパートナーシップはまた、Jetが都市圏に真剣に取り組んでいることを示す証でもある。Walmartが農村地域での小売りを伸ばすことに成功するなら、Jetはその大きな兄弟に対して、大都市でも同じことができることを示して印象付けようとしている。

都市に住む人なら誰でも知っているように、もしドアマンがいなかったりスマートアクセスシステムが無い場合には、自宅で荷物を受け取ることは基本的に不可能だ。

なので、この1000棟の建物への設置は、都市の買い物客がより多くの注文をするようになるためには、一体何を必要としているかを知るための良いテストになる筈だ。もしそれで、利用者が仕事で留守にしている間に、自宅の建物で荷物を受け取ることができる、Latchのようなシステムがあれば良い、ということがはっきりするなら素晴らしいことだ。しかしJetは（少なくとも内部的には）都市部の配達問題を解決する別のソリューションも追求している。オンデマンド注文で短時間配送を行なったり、Amazon Locker（注文した荷物を受け取れる専用ロッカー）のような、市街地の中に設置されるストレージを利用する方法だ。

Jetがこのプログラムから何を学ぶかにはかかわらず、無償でLatchがインストールされる建物の住民たちはおそらく皆とても嬉しい筈だ。

[ 原文へ ]
（翻訳：Sako）