モバイルアプリ開発プロジェクトの予算を確保しているか
IT部門のモバイルアプリ開発は、多くの機能の搭載や他システムとの統合を必要とする場合は、特にコストのかかるプロジェクトになる。そのコストは推定10万～50万ドルになる可能性がある。もしも予算が10万ドルを下回るのであれば、アプリの品質が低下する恐れがある。
モバイルアプリ開発プロジェクトのコストを見積もる際に、IT部門が考慮する要素はたくさんある。
例えばライセンス料、従業員のトレーニング、DevOpsのリソース、ホスティングサービスなどが挙げられる。コストの最も大きな要素になるのは、IT部門が開発を計画しているアプリの種類だ。IT部門は、Appleの「iOS」とGoogleの「Android」のいずれか、または両方をサポートするのか、ネイティブ、ハイブリッド、Webベースのいずれにするかを決める必要がある。次に、社内で開発するか、外部に委託するかを決める。
モバイルアプリ開発プロジェクトの大筋を決めたら、計画・設計からテスト・導入まで、アプリ開発ライフサイクルの全ての段階を検証する。その上で各段階にかかるコストを集計して、正確な見積もりを判断する。例えば、ITプロフェッショナルは、地理位置情報やオフラインアクセスなど、アプリに実装する機能を選ぶ必要がある。アプリを統合するバックエンドシステムを把握することも必要だ。
IT全般のコストを見積もったら、資格のあるアナリストが費用対効果を分析し、アプリのコストがその効果に見合うかどうかを判断する。社内モバイルアプリには、従業員の生産性向上やコミュニケーションの改善など、さまざまなメリットがある。コストが高くなっても、計算したROIが妥当であれば、IT部門はそのアプリ開発プロセスに踏み出すべきだ。
アプリケーション開発を迅速にするツールを利用するかどうか
IT部門がモバイルアプリ開発のコストを削減する1つの方法として、高速モバイルアプリケーション開発（Rapid Mobile Application Development、RMAD）プラットフォームを利用する方法がある。RMADプラットフォームは、事前構成済みのコンポーネントを利用することで、モバイルアプリをより迅速かつ容易に開発できるようにする。その結果、管理や開発に必要なリソースが少なくなり、コストが抑えられる。
RMADプラットフォームでは、IT管理者が、ID管理プラットフォームやディレクトリサービスなど、既存のエンタープライズサービスとアプリを簡単に統合できる。RMADプラットフォームでは統一されたテクノロジーを利用するため、IT部門が統合のためにカスタムAPIを作成する必要がない。
RAMDの重要な点は、ほぼコード不要の開発手法を利用して、開発知識のないユーザー（市民開発者とも呼ぶ）をサポートすることだ。しかしこのアプローチは、多くの企業が求める管理能力の欠如につながる。IT部門がネイティブアプリをカスタマイズする場合や、顧客が直接操作するアプリを開発する場合は特にこの点が問題になる。HTMLアプリの増加やその他のモバイルアプリ開発のトレンドにより、ほぼコード不要の開発をしようという考えは減り始めている。
プログレッシブWebアプリやインスタントアプリを考慮するかどうか
モバイルアプリ開発の新たな手法として盛んになっているのがプログレッシブWebアプリ（PWA）だ。PWAはWebベースでありながら、ネイティブモバイルアプリのように動作する。PWAは、オフラインアクセス、ホーム画面の存在、プッシュ通知など、ネイティブアプリと多くの機能を共有する。ユーザーの立場で言えば、ネイティブアプリとPWAの外観や操作感に大きな違いはない。
多くのB2Cアプリには、プログレッシブWeb開発が適している。だが、社内アプリにも応用できる。例えば、PWAのオフライン機能は、現場作業員などにとっては非常に便利だ。
PWAのモバイルアプリ開発プロジェクトは比較的シンプルで、iOSとAndroidでコードを分ける必要がないため、PWAの開発は徐々に一般的になっていくだろう。PWAは従来のWebアプリに比べて速度やパフォーマンスの面でも優れている。
インスタントアプリもAndroid固有の選択肢の1つだ。インスタントアプリとはネイティブモバイルアプリの小さなセグメントを指す。インスタントアプリには、Google検索や同社の「Google Play」ストアの「今すぐ試す」ボタンからアクセスできる。ユーザーがリンクやボタンからインスタントアプリにアクセスすると、アプリのその部分を実行するために必要な少量のコードフラグメントが自動的に実行される。
PWAと同様、インスタントアプリはネイティブアプリの機能性とWebのアクセスの容易さを兼ねそろえている。インスタントアプリを利用した企業の多くは、アプリの導入率が増えていると報告している。インスタントアプリはPWAと同じく、個別にコードを作成することも、専門チームを供することも必要としない。開発者はGoogleの「Android Studio」を使って、既存のアプリをインスタントアプリに変換できる。
ただし、インスタントアプリには、開発者が特定の機能モジュールにコードをリファクタリングしなければならないという課題がある。これは、多くの場合に単一モジュールになる従来のモバイルアプリ開発とは対極をなす。
2018年8月3日金曜日
2018年8月2日木曜日
米ライス大学の研究者、ディープラーニングを用いたコーディング支援システム「Bayou」を開発
米ライス大学のコンピュータ科学者が、ディープラーニングを利用したコーディング支援システム「Bayou」を開発した。Webサイト「askbayou.com」でJavaコード用のBayouを試用できる。
Bayouは、米国国防高等研究計画局（DARPA）から資金援助を受けたプロジェクトで開発された。このプロジェクトは、GitHubのようなオンラインソースコードリポジトリから知識を抽出することを目的としている。
Bayouは、プログラマーがAPIを使いこなす際に役立つ。APIはソフトウェア開発でますます大きな役割を果たすようになっているものの、しばしばドキュメントが整備されていないことがあるからだ。
プログラムを書き下すアプリケーションの開発は、人工知能（AI）分野における長年の目標の一つだ。
「人々は60年前から、コードを作成できるシステムを作ろうとしてきたが、問題は、コードの作成手法があいまいなことだった」と、ライス大学コンピュータ科学准教授で、Bayouの共同開発者の一人であるスワラト・チャウドゥーリー氏は語る。
「通常、今から作りたいプログラムが何を行うかについての大量の詳細情報をシステムに与える必要がある。そうした詳細情報を記述する仕事は、人が自らコードを書き下す作業と負荷があまり変わらない」（チャウドゥーリー氏）
「だが、Bayouは大幅に改良されている。非常に少量の情報（幾つかのキーワードや指示）を与えるだけで、Bayouはプログラマーの意図を読み取り、プログラマーが求めているプログラムを予想する」と、チャウドゥーリー氏は説明する。
チャウドゥーリー氏によると、Bayouは、人間が書いた数百万行のJavaコードを学習して自身をトレーニングした。「基本的に、BayouはGitHub上のあらゆるものを学習した。自力でコードを作成する際にその知識を利用している」
Bayouの共同開発者の一人で、ライス大学コンピュータ科学教授のクリス・ジャーメイン氏によれば、Bayouはソフトウェアで使うAPIのコードサンプルを合成する際に特に便利だという。同氏はチャウドゥーリー氏と共同で、ライス大学のインテリジェントソフトウェアシステムラボラトリーを運営している。
「今日のプログラミングは、30～40年前とは全く違う。プログラマーが一からコードを書いていた時代は大昔に終わっている」（ジャーメイン氏）
同ラボラトリーの研究者でBayouのアーキテクトであるビジェイ・ムラリ氏はこう語る。「モダンなソフトウェア開発ではAPIが肝心だ。コードが特定のハードウェアプラットフォームやOS、データベース、他のソフトウェアとやりとりすることを可能にするシステム固有のルールやツール、定義、プロトコルがある。数百のAPIがあり、開発者にとって、それらを使いこなすのは非常に難しい。そのため、開発者はstackoverflow.comのような質問サイトに行き、長い時間をかけて他の開発者に相談している」
ムラリ氏によると、開発者はそうした質問の一部をBayouに対して行うことができ、Bayouはすぐに答えを返すという。
「そうした素早いフィードバックですぐに問題が解決することもあるだろう。そうでなくても、Bayouのサンプルコードを使い、その後に人間の開発者へより具体的な質問をすることもできるだろう」（ムラリ氏）
ジャーメイン氏によると、開発チームの主な目標は、開発者にBayouの拡張を試みてもらうことだ。そのため自由度の高いオープンソースライセンス（Apacheライセンス2.0）でBayouを公開した。
「人々がBayouのようなシステムに何を求めているかという情報が多く得られれば得られるほど、われわれはBayouをより良いものにできる。できるだけ多くの人にBayouを使ってもらいたい」（ジャーメイン氏）
Bayouが行う学習には、ニューラルスケッチラーニングという手法が使われている。この手法により、数十万のJavaプログラムから抽象度の高いパターンを認識するように人工ニューラルネットワークをトレーニングできた。Bayouは、読み取った各プログラムの「スケッチ」を作成し、これをプログラムの「意図（インテント）」と関連付けることで、パターン認識を行っている。
ユーザーがBayouに質問をすると、どのようなプログラムを作成しようとしているのかをシステムが判断する。その後、システムは、ユーザーが作ろうとしているプログラムのスケッチを何種類か作成する。
「この推測に基づいて、Bayouの別の部分が4～5種類のコードチャンクを生成する。Javaの低レベルの細部を理解し、論理的な自動推論を行えるモジュールだ。BayouはWeb検索の結果を返すように結果をユーザーに表示する。最も有力な候補を最初に表示し、続いて幾つかの候補を表示する」
Bayouは、米国国防高等研究計画局（DARPA）から資金援助を受けたプロジェクトで開発された。このプロジェクトは、GitHubのようなオンラインソースコードリポジトリから知識を抽出することを目的としている。
Bayouは、プログラマーがAPIを使いこなす際に役立つ。APIはソフトウェア開発でますます大きな役割を果たすようになっているものの、しばしばドキュメントが整備されていないことがあるからだ。
プログラムを書き下すアプリケーションの開発は、人工知能（AI）分野における長年の目標の一つだ。
「人々は60年前から、コードを作成できるシステムを作ろうとしてきたが、問題は、コードの作成手法があいまいなことだった」と、ライス大学コンピュータ科学准教授で、Bayouの共同開発者の一人であるスワラト・チャウドゥーリー氏は語る。
「通常、今から作りたいプログラムが何を行うかについての大量の詳細情報をシステムに与える必要がある。そうした詳細情報を記述する仕事は、人が自らコードを書き下す作業と負荷があまり変わらない」（チャウドゥーリー氏）
「だが、Bayouは大幅に改良されている。非常に少量の情報（幾つかのキーワードや指示）を与えるだけで、Bayouはプログラマーの意図を読み取り、プログラマーが求めているプログラムを予想する」と、チャウドゥーリー氏は説明する。
チャウドゥーリー氏によると、Bayouは、人間が書いた数百万行のJavaコードを学習して自身をトレーニングした。「基本的に、BayouはGitHub上のあらゆるものを学習した。自力でコードを作成する際にその知識を利用している」
Bayouの共同開発者の一人で、ライス大学コンピュータ科学教授のクリス・ジャーメイン氏によれば、Bayouはソフトウェアで使うAPIのコードサンプルを合成する際に特に便利だという。同氏はチャウドゥーリー氏と共同で、ライス大学のインテリジェントソフトウェアシステムラボラトリーを運営している。
「今日のプログラミングは、30～40年前とは全く違う。プログラマーが一からコードを書いていた時代は大昔に終わっている」（ジャーメイン氏）
同ラボラトリーの研究者でBayouのアーキテクトであるビジェイ・ムラリ氏はこう語る。「モダンなソフトウェア開発ではAPIが肝心だ。コードが特定のハードウェアプラットフォームやOS、データベース、他のソフトウェアとやりとりすることを可能にするシステム固有のルールやツール、定義、プロトコルがある。数百のAPIがあり、開発者にとって、それらを使いこなすのは非常に難しい。そのため、開発者はstackoverflow.comのような質問サイトに行き、長い時間をかけて他の開発者に相談している」
ムラリ氏によると、開発者はそうした質問の一部をBayouに対して行うことができ、Bayouはすぐに答えを返すという。
「そうした素早いフィードバックですぐに問題が解決することもあるだろう。そうでなくても、Bayouのサンプルコードを使い、その後に人間の開発者へより具体的な質問をすることもできるだろう」（ムラリ氏）
ジャーメイン氏によると、開発チームの主な目標は、開発者にBayouの拡張を試みてもらうことだ。そのため自由度の高いオープンソースライセンス（Apacheライセンス2.0）でBayouを公開した。
「人々がBayouのようなシステムに何を求めているかという情報が多く得られれば得られるほど、われわれはBayouをより良いものにできる。できるだけ多くの人にBayouを使ってもらいたい」（ジャーメイン氏）
Bayouが行う学習には、ニューラルスケッチラーニングという手法が使われている。この手法により、数十万のJavaプログラムから抽象度の高いパターンを認識するように人工ニューラルネットワークをトレーニングできた。Bayouは、読み取った各プログラムの「スケッチ」を作成し、これをプログラムの「意図（インテント）」と関連付けることで、パターン認識を行っている。
ユーザーがBayouに質問をすると、どのようなプログラムを作成しようとしているのかをシステムが判断する。その後、システムは、ユーザーが作ろうとしているプログラムのスケッチを何種類か作成する。
「この推測に基づいて、Bayouの別の部分が4～5種類のコードチャンクを生成する。Javaの低レベルの細部を理解し、論理的な自動推論を行えるモジュールだ。BayouはWeb検索の結果を返すように結果をユーザーに表示する。最も有力な候補を最初に表示し、続いて幾つかの候補を表示する」
チョコレートの商品情報をAIアプリで確認――ゴディバと日立ソリューションズ、店舗スタッフ向け商品照会アプリを共同検証
日立ソリューションズは2018年7月31日、ゴディバ ジャパンと共同で、AIを活用してスマートフォンアプリで撮影した商品画像から、その場で商品情報を照会できる店舗スタッフ向けシステムの実証実験を行ったと発表した。
実証実験は、2018年5月7日から6月15日にかけて、ゴディバ ジャパンの実店舗で実施。ゴディバ ジャパンの「サマーコレクション」や「ゴールドコレクション」といったチョコレートのパッケージ商品を、店舗スタッフが専用アプリで撮影。その画像情報からAIが商品を特定し、クラウドデータベースに登録した商品詳細情報から該当商品の情報をアプリ画面に表示する仕組みを検証した。
検証の結果、商品パッケージの写真から商品情報を高精度に取得できることを確認したという。
同システムにより、店舗スタッフが顧客から相談を受けた際、商品情報を簡単かつ速やかに検索できるようになり、接客サービスの強化や顧客満足度の向上が期待できるとしている。
実証実験に参加した店舗スタッフによると、商品のパッケージを持参して同じ商品や類似商品を求めたいという要望や、商品にアレルゲンとなる素材が含まれていないかどうかを確認したいというニーズが少なくないことから、スマホアプリですぐに商品の詳細情報を確認できるのは非常に有効である他、来店客のお好みに合った商品を探す際にも役立つという。
システムは、日立ソリューションズが「Microsoft Azure」のAIサービスである「Cognitive Services」の画像認識機能と、クラウド型業務アプリケーション「Dynamics 365」を活用して構築。商品情報は、1商品当たり10枚程度の画像で機械学習させた。計画策定から機械学習、アプリケーションを含むシステム構築、レポート作成まで、約1カ月間で完了したという。
日立ソリューションズは、実証実験を通して、ビッグデータが少ない場合でも少量の学習素材を使って低コストで機械学習を実現し、短期間でアプリケーションのスムーズな実装が可能なことを確認できたとしている。
実証実験は、2018年5月7日から6月15日にかけて、ゴディバ ジャパンの実店舗で実施。ゴディバ ジャパンの「サマーコレクション」や「ゴールドコレクション」といったチョコレートのパッケージ商品を、店舗スタッフが専用アプリで撮影。その画像情報からAIが商品を特定し、クラウドデータベースに登録した商品詳細情報から該当商品の情報をアプリ画面に表示する仕組みを検証した。
検証の結果、商品パッケージの写真から商品情報を高精度に取得できることを確認したという。
同システムにより、店舗スタッフが顧客から相談を受けた際、商品情報を簡単かつ速やかに検索できるようになり、接客サービスの強化や顧客満足度の向上が期待できるとしている。
実証実験に参加した店舗スタッフによると、商品のパッケージを持参して同じ商品や類似商品を求めたいという要望や、商品にアレルゲンとなる素材が含まれていないかどうかを確認したいというニーズが少なくないことから、スマホアプリですぐに商品の詳細情報を確認できるのは非常に有効である他、来店客のお好みに合った商品を探す際にも役立つという。
システムは、日立ソリューションズが「Microsoft Azure」のAIサービスである「Cognitive Services」の画像認識機能と、クラウド型業務アプリケーション「Dynamics 365」を活用して構築。商品情報は、1商品当たり10枚程度の画像で機械学習させた。計画策定から機械学習、アプリケーションを含むシステム構築、レポート作成まで、約1カ月間で完了したという。
日立ソリューションズは、実証実験を通して、ビッグデータが少ない場合でも少量の学習素材を使って低コストで機械学習を実現し、短期間でアプリケーションのスムーズな実装が可能なことを確認できたとしている。
2018年8月1日水曜日
GoogleがフルマネージドCI／CDプラットフォーム「Cloud Build」を発表、GitHubとの提携も拡大
Googleは2018年7月26日（米国時間）、フルマネージドCI／CD（継続的インテグレーション／継続的デリバリー）プラットフォーム「Google Cloud Build」を発表した。加えて、GitHubとの提携拡大により、「GitHub」とCloud Buildの接続による新たな統合エクスペリエンスを提供したことも明らかにした。
Googleは「現在では多くの組織がCI／CDを導入しているが、安全で信頼できるCI／CDインフラの運用と保守には多大なコストがかかり、複雑な作業も必要になる。ベストプラクティスの統合にも時間がかかる」との認識を示す。Cloud Buildは、こうした課題を克服し、組織がソフトウェア作成に集中できるようにすることを目的としている。
Cloud Buildは、「Google Cloud Platform」の高速かつ一貫性のある信頼性の高い環境でビルドを実行できるサービスだ。「Google Cloud Storage」「Google Cloud Source Repositories」や、「GitHub」「Bitbucket」からソースコードをインポートし、仕様に合わせてビルドを実行し、DockerコンテナやJavaアーカイブなどのアーティファクト（成果物）を生成できる。
Cloud Buildは、一連のビルドステップとしてビルドを実行する。各ビルドステップはDockerコンテナで実行される。ビルドステップでは、環境にかかわらず、コンテナから実行可能な全ての処理を実行できる。タスクを実行するには、Cloud Buildが提供するサポート対象のビルドステップを使用するか、独自のビルドステップを作成する。
Cloud Buildの特徴は以下の通り。
低コストで利用できるフルマネージドサービス
ビルド処理は1日当たり120分まで無料で利用できる。このため、ビルドをクラウドに移動するためにコストが発生することはほとんどないという。さらに、フルマネージドサービスであるため、ビルドサーバ管理のオーバーヘッドも発生しない。なお、ビルド処理時間が1日120分を超えた場合の料金は、1分当たり0.0034ドルだ。
CI／CDパイプラインの自動化
ビルドトリガーを設定すると、リポジトリ内でソースコードやタグが変更されるたびに、新しいビルドを自動実行できる。この機能はGitHub、Bitbucket、Google Cloud Source Repositoriesで利用できる。さらにカスタムのビルドステップを使用すれば、テストの実行や、Google Cloud Storageへのアーティファクトのエクスポート、ソフトウェアのリリースプロセスの自動化も可能だ。
プライバシーと安全性
ビルドの所有権限はGoogle Cloud Platformプロジェクトのものとなるため、ビルドの作成や表示を許可する開発者や、使用できるソースコード、ビルドアーティファクトの保存先を完全に制御できる。
柔軟なビルドステップ
Cloud Buildは、Dockerコンテナでコマンドを実行してビルドを実行する。その際、公式にサポートされたビルドステップや、独自のツール、「Maven」や「Gradle」などの人気のある公開Dockerリポジトリを使用できる。Dockerコンテナイメージにビルドをパッケージ化できる場合は、ビルドプロセスのステップとしても実行できる。
組み立て可能
開発者が使っているIDEや、CI／CDパイプラインとの統合が可能だ。認証設定なしに「Google App Engine」「Google Kubernetes Engine」「Google Compute Engine」でデプロイすることも、任意のDockerランタイムにデプロイすることもできる。
ビルドログ
Google Cloud Consoleでビルドログを確認することで、失敗したビルドを素早くデバッグできる。
ビルド履歴
Google Cloudプロジェクトでは、作成した全てのビルドの監査記録を恒久的に保存し、いつでも表示できる。
GoogleとGitHubの提携拡大
GoogleとGitHubは、GitHubの任意のリポジトリで、GitHub開発者のワークフローに直接統合された、Cloud Buildによる高速で便利なCIを実行できるようにした。「GitHub Marketplace」から、Cloud BuildとGitHubの統合機能をセットアップできる。
Googleは「現在では多くの組織がCI／CDを導入しているが、安全で信頼できるCI／CDインフラの運用と保守には多大なコストがかかり、複雑な作業も必要になる。ベストプラクティスの統合にも時間がかかる」との認識を示す。Cloud Buildは、こうした課題を克服し、組織がソフトウェア作成に集中できるようにすることを目的としている。
Cloud Buildは、「Google Cloud Platform」の高速かつ一貫性のある信頼性の高い環境でビルドを実行できるサービスだ。「Google Cloud Storage」「Google Cloud Source Repositories」や、「GitHub」「Bitbucket」からソースコードをインポートし、仕様に合わせてビルドを実行し、DockerコンテナやJavaアーカイブなどのアーティファクト（成果物）を生成できる。
Cloud Buildは、一連のビルドステップとしてビルドを実行する。各ビルドステップはDockerコンテナで実行される。ビルドステップでは、環境にかかわらず、コンテナから実行可能な全ての処理を実行できる。タスクを実行するには、Cloud Buildが提供するサポート対象のビルドステップを使用するか、独自のビルドステップを作成する。
Cloud Buildの特徴は以下の通り。
低コストで利用できるフルマネージドサービス
ビルド処理は1日当たり120分まで無料で利用できる。このため、ビルドをクラウドに移動するためにコストが発生することはほとんどないという。さらに、フルマネージドサービスであるため、ビルドサーバ管理のオーバーヘッドも発生しない。なお、ビルド処理時間が1日120分を超えた場合の料金は、1分当たり0.0034ドルだ。
CI／CDパイプラインの自動化
ビルドトリガーを設定すると、リポジトリ内でソースコードやタグが変更されるたびに、新しいビルドを自動実行できる。この機能はGitHub、Bitbucket、Google Cloud Source Repositoriesで利用できる。さらにカスタムのビルドステップを使用すれば、テストの実行や、Google Cloud Storageへのアーティファクトのエクスポート、ソフトウェアのリリースプロセスの自動化も可能だ。
プライバシーと安全性
ビルドの所有権限はGoogle Cloud Platformプロジェクトのものとなるため、ビルドの作成や表示を許可する開発者や、使用できるソースコード、ビルドアーティファクトの保存先を完全に制御できる。
柔軟なビルドステップ
Cloud Buildは、Dockerコンテナでコマンドを実行してビルドを実行する。その際、公式にサポートされたビルドステップや、独自のツール、「Maven」や「Gradle」などの人気のある公開Dockerリポジトリを使用できる。Dockerコンテナイメージにビルドをパッケージ化できる場合は、ビルドプロセスのステップとしても実行できる。
組み立て可能
開発者が使っているIDEや、CI／CDパイプラインとの統合が可能だ。認証設定なしに「Google App Engine」「Google Kubernetes Engine」「Google Compute Engine」でデプロイすることも、任意のDockerランタイムにデプロイすることもできる。
ビルドログ
Google Cloud Consoleでビルドログを確認することで、失敗したビルドを素早くデバッグできる。
ビルド履歴
Google Cloudプロジェクトでは、作成した全てのビルドの監査記録を恒久的に保存し、いつでも表示できる。
GoogleとGitHubの提携拡大
GoogleとGitHubは、GitHubの任意のリポジトリで、GitHub開発者のワークフローに直接統合された、Cloud Buildによる高速で便利なCIを実行できるようにした。「GitHub Marketplace」から、Cloud BuildとGitHubの統合機能をセットアップできる。
2018年7月31日火曜日
OpenAI's Dactyl System Gives Robots Humanlike Dexterity
In a forthcoming paper ("Dexterous In-Hand Manipulation"), OpenAI researchers describe a system that uses a reinforcement model, where the AI [known as Dactyl] learns through trial and error, to direct robot hands in grasping and manipulating objects with state-of-the-art precision. All the more impressive, it was trained entirely digitally, in a computer simulation, and wasn't provided any human demonstrations by which to learn. The researchers used the MuJoCo physics engine to simulate a physical environment in which a real robot might operate, and Unity to render images for training a computer vision model to recognize poses. But this approach had its limitations, the team writes -- the simulation was merely a "rough approximation" of the physical setup, which made it "unlikely" to produce systems that would translate well to the real world. Their solution was to randomize aspects of the environment, like its physics (friction, gravity, joint limits, object dimensions, and more) and visual appearance (lighting conditions, hand and object poses, materials, and textures). This both reduced the likelihood of overfitting -- a phenomenon that occurs when a neural network learns noise in training data, negatively affecting its performance -- and increased the chances of producing an algorithm that would successfully choose actions based on real-world fingertip positions and object poses.
Next, the researchers trained the model -- a recurrent neural network -- with 384 machines, each with 16 CPU cores, allowing them to generate roughly two years of simulated experience per hour. After optimizing it on an eight-GPU PC, they moved onto the next step: training a convolutional neural network that would predict the position and orientation of objects in the robot's "hand" from three simulated camera images. Once the models were trained, it was onto validation tests. The researchers used a Shadow Dexterous Hand, a robotic hand with five fingers with a total of 24 degrees of freedom, mounted on an aluminum frame to manipulate objects. Two sets of cameras, meanwhile -- motion capture cameras as well as RGB cameras -- served as the system's eyes, allowing it to track the objects' rotation and orientation. In the first of two tests, the algorithms were tasked with reorienting a block labeled with letters of the alphabet. The team chose a random goal, and each time the AI achieved it, they selected a new one until the robot (1) dropped the block, (2) spent more than a minute manipulating the block, or (3) reached 50 successful rotations. In the second test, the block was swapped with an octagonal prism. The result? The models not only exhibited "unprecedented" performance, but naturally discovered types of grasps observed in humans, such as tripod (a grip that uses the thumb, index finger, and middle finger), prismatic (a grip in which the thumb and finger oppose each other), and tip pinch grip. They also learned how to pivot and slide the robot hand's fingers, and how to use gravitational, translational, and torsional forces to slot the object into the desired position.
Next, the researchers trained the model -- a recurrent neural network -- with 384 machines, each with 16 CPU cores, allowing them to generate roughly two years of simulated experience per hour. After optimizing it on an eight-GPU PC, they moved onto the next step: training a convolutional neural network that would predict the position and orientation of objects in the robot's "hand" from three simulated camera images. Once the models were trained, it was onto validation tests. The researchers used a Shadow Dexterous Hand, a robotic hand with five fingers with a total of 24 degrees of freedom, mounted on an aluminum frame to manipulate objects. Two sets of cameras, meanwhile -- motion capture cameras as well as RGB cameras -- served as the system's eyes, allowing it to track the objects' rotation and orientation. In the first of two tests, the algorithms were tasked with reorienting a block labeled with letters of the alphabet. The team chose a random goal, and each time the AI achieved it, they selected a new one until the robot (1) dropped the block, (2) spent more than a minute manipulating the block, or (3) reached 50 successful rotations. In the second test, the block was swapped with an octagonal prism. The result? The models not only exhibited "unprecedented" performance, but naturally discovered types of grasps observed in humans, such as tripod (a grip that uses the thumb, index finger, and middle finger), prismatic (a grip in which the thumb and finger oppose each other), and tip pinch grip. They also learned how to pivot and slide the robot hand's fingers, and how to use gravitational, translational, and torsional forces to slot the object into the desired position.
2018年7月30日月曜日
家政婦ならぬロボットが見た。掃除ロボをスパイにしてしまうハックが発覚
忙しいとき、「ロボット掃除機のあるお家」に何度憧れたことか...。
でも、もしマイクとカメラを搭載したネット接続ガジェットとしてロボット掃除機が販売されていたら、おそらくそれが一日中家のなかをさまようというリスクを見落としてはいけません。
掃除ロボットが監視・盗聴マシンに変身
セキュリティ会社Positive Technologiesの研究者らによると、中国は東莞（トウカン）市のロボット掃除機メーカーDiqeeの製品に脆弱性が見つかりました。具体的に報告されているのはカメラを搭載した「Diqee360」シリーズですが、同様の脆弱性がほかの製品に存在している可能性も指摘されています。
ただしこれらは、悪意あるハッカーが特定の家庭を標的にしなければ実行できない攻撃といえるかもしれません。というのも、スマート掃除機「Diqee360」で現在明らかになっている脆弱性のうち、その要件はすでにネットワークに侵入しているか、あるいはロボット掃除機への物理的なアクセスが必要になるためです。
前者は遠隔コード実行を可能にし、ロボット掃除機をいわば「車輪のついた監視マシン」に変身させるというもの。後者はポートにmicroSDを挿入することで実行できる攻撃で、掃除機を介してホームネットワーク上にある他のトラフィックを傍受できます。家じゅうを監視されるのも、通信内容を盗み見られるのも、誰にとっても困るものです...。
掃除ロボットにWi-Fiはまだ早い？
特に「家」という空間だから、好きなことを言ったりやりたいことをやったりするのであって...本来プライバシーが守られるべき空間で、カメラやマイクを装備したIoT機器を置くことが重大なリスクになるのであればもう「自分で掃除します」としか言いようがありません。
今回見つかった脆弱性について、Positive Technologiesの研究者らはすでにDiqeeに通知したことを米Gizmodoに明かしています。ただ脆弱性が修正されたのか、また影響のあったロボット掃除機の所有者に対して何らかの報告があったのかについては、現時点で明らかになっていません。
こうしたリスクを絶対的に避けたいという人は、いまのところWi-Fiを搭載していないロボット掃除機を検討するのがもっとも無難かもしれません。
MRで完成図を容易に想像可能に――建設業界で進むICT活用で現場はどう変わっているのか？
「VR」（Virtual Reality：仮想現実）や「MR」（Mixed Reality：複合現実）、AI（人工知能）、IoT（Internet of Things）など、多くのICTが登場し、さまざまな企業で活用されている。例えば、VRを活用することで従業員を効率良く訓練させたり、IoTを使うことで遠隔から機械の状態が分かったりする。ICTの活用が進んでいるのは、建設業界も例外ではない。
ソリトンシステムズは、2018年6月26日、建設業に携わる顧客を対象に「業務効率化とセキュリティ対策 ～建設業界での課題と事例を中心に～」と題したセミナーを開催した。本稿では、日本建設業連合会 IT推進部会先端ICT活用専門部会 主査兼大林組 グローバルICT推進室 担当部長の堀内英行氏による基調講演「建設現場における先端ICT活用の最新動向」の内容をお伝えする。
建設業でのスマートデバイス導入率は96％
日本建設業連合会 IT推進部会先端ICT活用専門部会 主査兼大林組 グローバルICT推進室 担当部長の堀内英行氏
堀内氏はまず、日本建設業連合会（以下、日建連）の会員を対象に2017年12月に実施したスマートデバイスの導入、展開に関するアンケート結果を用いて、建設業界でスマートデバイスの導入、利活用が急速に拡大していることを紹介した。
「スマートデバイス導入済みの企業は、2016年度の81.6％に対して、2017年度には96.0％に達した。そして、その半数は直近3年間に導入していた。利用用途については、『図面閲覧』『写真管理』『コミュニケーション』『検査』などの用途で、利用率や導入効果が高かった。導入成果としては、『生産性』『業務精度・スピード向上』『コミュニケーション向上』『働き方・業務改革意識の向上』の4つの項目で、成果が挙がっている」
こうした背景を踏まえて堀内氏は、建設現場のさまざまな課題を解決するICTサービスの最新動向について、具体的な事例を挙げながら紹介した。その中で、特に注目を集めているのが、VRとMRを活用したICTサービスの事例だ。
VR、MR、AI……最新ICTが活用される建設業界
VR技術は、現場訓練、研修システムへの活用が進んでいるという。今まで実地訓練が必要だった特殊技術や現場での経験を、VRを通じて習得可能となるため、効率的な人材育成や現場の職人不足解消につながると期待されている。
「例えば、施工管理者向けの教育システムでは、配筋のモックアップをVRで再現し、配筋の不具合を検知する訓練を行う。これにより、実際にモックアップを製作することなく、低コストかつ手軽に、現場さながらの環境で訓練ができる。また、BIM（ビルディングインフォメーションモデリング）データを活用できるため、さまざまな内容の訓練を容易に作成可能になる」
この他、現場での類似体験が難しい墜落、転落、火災などの災害を、リアルに体感できる教育VRの事例を挙げ、「現場作業員の安全に対する意識を向上させるための教育に役立つ」とした。
VRを使った訓練の様子
MR技術については、家庭用昇降機の実測、設計でヘッドマウントディスプレイを活用した事例を紹介。具体的には、ヘッドマウントディスプレイを使うことで、家庭で階段に設置する昇降機の製作や設置施工時に使う図面を現地で作製して、図面を基にした3Dモデルと現実の階段の映像を重ね合わせて見ながら確認する。ダイレクトに製作工程につなげることで、工数やコストを大幅に削減したという。
また、1分の1スケールの図面実寸投影を実現するMRソリューションについて、デモを交えながら紹介した。
「まずCADデータを取り込み、ARマーカーとCADデータの相対的な表示位置を定義する。次に変換サーバで3Dデータへの変換処理を行い、ヘッドマウントディスプレイのビュワーからダウンロードすると、CADデータが1分の1スケールで現実世界に重畳表示される」
このMRソリューションは、建設現場における干渉検討や出来形確認、墨出しチェック、メンテナンスなどの活用に期待されており、実証実験では、「インサートなどの墨出し工数を3分の1に削減」「施工ミスの軽減、施工品質の向上」「BIMデータと連携して隠蔽（いんぺい）部の構造、設備を透視」「完成後の保守、メンテナンス作業の軽減」といった導入効果があったという。
堀内氏は、VR／MRの他にも、建設現場の課題解決につながるさまざまな先端ICTサービスを紹介。例えば、ソフトウェアとコンテンツ、ハードウェアをセットにしたオールインワンの「サイネージソリューション」を活用することで、ホワイドボードによる手書きの作業予定表を、迅速かつ容易にデジタルサイネージへ移行できる。
また、シアン、マゼンダ、イエロー、ブラックを組み合わせた2次元カラーバーコード「カメレオンコード」とスマートデバイスを利用した車両入退場管理システムでは、車両入退場の記録を写真とともに管理でき、オリンピック関連施設など大規模な建設現場における、より厳重な車両管理を実現する。
左右2つのレンズを内蔵するカメラを使った「3D画像解析システム」では、距離、高さ、体積を認識して、3Dで解析、検知を行う。人の目と同じように動くものを立体として認識できるため、建設現場での入退監視や不審者の検知、通報、ゲート通過時の人数カウントなどに活用できるという。
建設現場では、工事写真関連業務が現場スタッフの大きな負担になっているケースが多く、これらの業務をアウトソーシングするニーズも高まっている。このニーズに応えるのが、アプリと連携して電子黒板や写真帳の作成業務を請け負うBPO（ビジネスプロセスアウトソーシング）サービスだ。これにより、建設現場のスタッフは、工事写真の撮影準備から写真整理までの業務負荷を大幅に軽減可能だ。
この他、IoT、AI関連では、給電不要なEH（エネルギーハーベスト）型環境センサーと仮設Wi-Fiを組み合わせることで、現場の作業環境をモニタリングして熱中症を予防するシステムや、打音検査時の「音」をスマホで取得するだけで熟練工の五感に頼らずに良否判断ができるAI搭載アプリを紹介。さらに、ドローンの活用例として、ドローンによる建設現場のデータ分析および進捗（しんちょく）管理ソリューションをピックアップ。構造物の壁面を自律飛行するドローンを活用することで、より高精度なモデルの生成と進捗管理が可能になるとした。
多くのところでICT化が進む建設業界。今後はIoTやAIなどによって、熟練工の技術やノウハウの多くが数値化され、若手の従業員でも熟練工の技術が使えるようになるかもしれない。さらにロボティクスが発展することによって、危険な建設業務は全て機械化されるかもしれない。そのときに、必要な能力をしっかりと見極めて、ICTと向き合っていくことが大切になるだろう。
ソリトンシステムズは、2018年6月26日、建設業に携わる顧客を対象に「業務効率化とセキュリティ対策 ～建設業界での課題と事例を中心に～」と題したセミナーを開催した。本稿では、日本建設業連合会 IT推進部会先端ICT活用専門部会 主査兼大林組 グローバルICT推進室 担当部長の堀内英行氏による基調講演「建設現場における先端ICT活用の最新動向」の内容をお伝えする。
建設業でのスマートデバイス導入率は96％
日本建設業連合会 IT推進部会先端ICT活用専門部会 主査兼大林組 グローバルICT推進室 担当部長の堀内英行氏
堀内氏はまず、日本建設業連合会（以下、日建連）の会員を対象に2017年12月に実施したスマートデバイスの導入、展開に関するアンケート結果を用いて、建設業界でスマートデバイスの導入、利活用が急速に拡大していることを紹介した。
「スマートデバイス導入済みの企業は、2016年度の81.6％に対して、2017年度には96.0％に達した。そして、その半数は直近3年間に導入していた。利用用途については、『図面閲覧』『写真管理』『コミュニケーション』『検査』などの用途で、利用率や導入効果が高かった。導入成果としては、『生産性』『業務精度・スピード向上』『コミュニケーション向上』『働き方・業務改革意識の向上』の4つの項目で、成果が挙がっている」
こうした背景を踏まえて堀内氏は、建設現場のさまざまな課題を解決するICTサービスの最新動向について、具体的な事例を挙げながら紹介した。その中で、特に注目を集めているのが、VRとMRを活用したICTサービスの事例だ。
VR、MR、AI……最新ICTが活用される建設業界
VR技術は、現場訓練、研修システムへの活用が進んでいるという。今まで実地訓練が必要だった特殊技術や現場での経験を、VRを通じて習得可能となるため、効率的な人材育成や現場の職人不足解消につながると期待されている。
「例えば、施工管理者向けの教育システムでは、配筋のモックアップをVRで再現し、配筋の不具合を検知する訓練を行う。これにより、実際にモックアップを製作することなく、低コストかつ手軽に、現場さながらの環境で訓練ができる。また、BIM（ビルディングインフォメーションモデリング）データを活用できるため、さまざまな内容の訓練を容易に作成可能になる」
この他、現場での類似体験が難しい墜落、転落、火災などの災害を、リアルに体感できる教育VRの事例を挙げ、「現場作業員の安全に対する意識を向上させるための教育に役立つ」とした。
VRを使った訓練の様子
MR技術については、家庭用昇降機の実測、設計でヘッドマウントディスプレイを活用した事例を紹介。具体的には、ヘッドマウントディスプレイを使うことで、家庭で階段に設置する昇降機の製作や設置施工時に使う図面を現地で作製して、図面を基にした3Dモデルと現実の階段の映像を重ね合わせて見ながら確認する。ダイレクトに製作工程につなげることで、工数やコストを大幅に削減したという。
また、1分の1スケールの図面実寸投影を実現するMRソリューションについて、デモを交えながら紹介した。
「まずCADデータを取り込み、ARマーカーとCADデータの相対的な表示位置を定義する。次に変換サーバで3Dデータへの変換処理を行い、ヘッドマウントディスプレイのビュワーからダウンロードすると、CADデータが1分の1スケールで現実世界に重畳表示される」
このMRソリューションは、建設現場における干渉検討や出来形確認、墨出しチェック、メンテナンスなどの活用に期待されており、実証実験では、「インサートなどの墨出し工数を3分の1に削減」「施工ミスの軽減、施工品質の向上」「BIMデータと連携して隠蔽（いんぺい）部の構造、設備を透視」「完成後の保守、メンテナンス作業の軽減」といった導入効果があったという。
堀内氏は、VR／MRの他にも、建設現場の課題解決につながるさまざまな先端ICTサービスを紹介。例えば、ソフトウェアとコンテンツ、ハードウェアをセットにしたオールインワンの「サイネージソリューション」を活用することで、ホワイドボードによる手書きの作業予定表を、迅速かつ容易にデジタルサイネージへ移行できる。
また、シアン、マゼンダ、イエロー、ブラックを組み合わせた2次元カラーバーコード「カメレオンコード」とスマートデバイスを利用した車両入退場管理システムでは、車両入退場の記録を写真とともに管理でき、オリンピック関連施設など大規模な建設現場における、より厳重な車両管理を実現する。
左右2つのレンズを内蔵するカメラを使った「3D画像解析システム」では、距離、高さ、体積を認識して、3Dで解析、検知を行う。人の目と同じように動くものを立体として認識できるため、建設現場での入退監視や不審者の検知、通報、ゲート通過時の人数カウントなどに活用できるという。
建設現場では、工事写真関連業務が現場スタッフの大きな負担になっているケースが多く、これらの業務をアウトソーシングするニーズも高まっている。このニーズに応えるのが、アプリと連携して電子黒板や写真帳の作成業務を請け負うBPO（ビジネスプロセスアウトソーシング）サービスだ。これにより、建設現場のスタッフは、工事写真の撮影準備から写真整理までの業務負荷を大幅に軽減可能だ。
この他、IoT、AI関連では、給電不要なEH（エネルギーハーベスト）型環境センサーと仮設Wi-Fiを組み合わせることで、現場の作業環境をモニタリングして熱中症を予防するシステムや、打音検査時の「音」をスマホで取得するだけで熟練工の五感に頼らずに良否判断ができるAI搭載アプリを紹介。さらに、ドローンの活用例として、ドローンによる建設現場のデータ分析および進捗（しんちょく）管理ソリューションをピックアップ。構造物の壁面を自律飛行するドローンを活用することで、より高精度なモデルの生成と進捗管理が可能になるとした。
多くのところでICT化が進む建設業界。今後はIoTやAIなどによって、熟練工の技術やノウハウの多くが数値化され、若手の従業員でも熟練工の技術が使えるようになるかもしれない。さらにロボティクスが発展することによって、危険な建設業務は全て機械化されるかもしれない。そのときに、必要な能力をしっかりと見極めて、ICTと向き合っていくことが大切になるだろう。
「eASIC」ってどんな会社？
Intelがまた会社を買収したようだ（Intelのプレスリリース「Intel to Acquire eASIC - Adding to Our Programmable Solutions Talent and Capabilities」）。買収された会社は、同じシリコンバレーにある。Intel本社から目と鼻の先と言っていい「eASIC（イーエイシック）」である。eASICは、「その業界」では一応名の通った会社であるし、創業は20世紀末にさかのぼるから、ポッと出のベンチャーでもない。
しかし、eASICという社名を言われてピンとくる人は、実際それほど多くないだろう。この会社を一言で説明すれば、「社名の一部になっている『ASIC』と普通の『FPGA』の隙間で商売してきた会社」である。そう説明しても、多分若い人にはあまり理解されないのではないかと思う。何といっても、このごろは「ASIC」というもの自体が理解されていない気がするからだ。
私事で恐縮だが、業界に入り、下っ端で配属された初めてのプロジェクトは8bitのマイクロコントローラーだった。以来数十年をマイクロコントローラー、マイクロプロセッサなど、日本式に言えば「マイコン屋」でやってきた。けれど、ほんの一時だったが「ASIC屋」も経験したことがある。中間管理職だったので自分でASICを設計することはなかったが、同じ半導体業界といえ、マイコン屋とは「心の持ちよう」の違いにビックリしたものだ。
今にして振り返れば、一度は世界を席巻した日本のASIC業界が落日を迎えつつあるころのことだった。日本だけでなく、当時のASIC業界では撤退する会社も多く、ほとんどのASICベンダーが苦境にあえいでいるような時期でもあった。外目に、eASICはそんなASIC業界の苦境の中に現れて、着々と地歩を固めて今に至っているように見える。今回のIntelの買収も、ASICの何が強みで、何か弱点であったのかを知らないとなかなか理解できないのではないかと思う。
eASICをFPGAの会社に分類するか、ASICの会社に分類するかと問われれば、筆者はASICの会社の方に分類する。eASICの製品の基本的な回路構成はFPGAにごく近いものがあるにもかかわらずである。なぜならば、ビジネスについてのスタンス、言ってみれば「心の持ちよう」という点で根本的にASIC側なのである。
そもそもASICとは
ASICとは何か、それは「お客が使い道を決め」、つまりは仕様を決め、多くは自ら設計をし（設計外注に丸投げというケースも多いが）、製造にかかわることだけ（これには設計の後工程でもある設計検証やテストなども含まれる）を半導体ベンダーにやらせて作ったカスタム（開発費をお客が負担し、該当のお客だけがチップを入手できる）半導体製品である。端的に言うと、ASICベンダーは自分が製造しているチップが「何者」であるのか、について関知しない。客の希望通りに作るのみ。
FPGAだってお客が設計をするじゃないかと言われるかもしれない。しかし、FPGAの場合、汎用品であるFPGAのチップを買ってきて、お客がそれをプログラムしている。買ってきた製品の型番が同じなら、お客のA社もB社もみんな同じチップを使っていて、そのチップの仕様を決めたのはFPGAベンダー側である。当然、FPGAチップの開発費はFPGAベンダーが製品に広く乗せられているはずだが、チップを買うときに開発費を別途払えとは言われない。
これに対してASICの場合、チップの仕様も用途もお客に責任がある。製造上の問題にのみ半導体会社は責を負う（実際にはいろいろ大人の問題もあるが）。そしてその製造にかかわる開発費としてお客が費用（多くはNREと呼ばれる。NRは「払い戻し不可の」という意味を持つ）を負担している。
今のようにFPGAが登場する以前、世の中にはASIC製品があふれていた。家電製品、PC関連、制御など、基板の上にはASICが大量に存在していた。そしてそれらのかなりの割合が日本のASICベンダーの製造によるものだった。
当時、日本の半導体業界が先端工場への巨大な投資に対応し切れず、後れを取るにつれて日本の地盤が下がった。ことASICについては国内国外に関係ない逆風も吹いてきた。「開発費」の高騰という問題である。
例えば数百万円の開発費で10万個のASICチップを作れた時代なら、チップ単価に数十円の開発コストを乗せれば採算が合う。この程度であれば、小口や中小の案件でも幅広いASIC商売は成り立つ。だが、プロセスが微細化するにつれて、開発費は数千万から数億円といったレベルに高騰していった。
なお、開発費の大部分は製造に使うマスク代である。先端プロセスのマスク（レチクル）は目の玉が飛び出る値段なのだ。こうなると数千万個といった製造規模か、金に糸目をつけない特殊用途でもないと成り立たない。つまり先端のASICを発注して採算をとれるようなプロジェクトのハードルがひどく上がってしまったのである。当然お客は激減した。
ASICとFPGA、それぞれの利点・欠点
ちょうどこのころ、FPGAの商売が立ち上がりつつあった。FPGAのチップ単価はASICのチップ単価に比べれば非常に高かったが、開発費の支払いは不要だ。1個からでも購入できる。よって、試作に始まり、少量個数の量産など数量の少ないところからFPGAは使われ、ASICという選択肢は消滅していった。
しかし、FPGAを使っている人はお分かりだろうが、ASICより不利な点も多いのである。まずは「フィールドでプログラムする」という、ある意味で本来の機能とは関係のない機能のために搭載しているロジックの量が半端ないのだ。そのため、全体のロジックの中で、「プログラミング」のためのロジックは最大80％（eASICの主張による数字）にも達するという。
つまり、チップ単価がそれだけ増す（先端のFPGAなど1個数十万円、初物では3桁万円という話もある）、ということである。また、チップがその分電気を多く消費する（PC用のCPUやGPUと肩を並べる）、ということでもある。あるいは、余計な回路の分、性能が上がらない（CPUどころかGPUのクロックにも遠く及ばないことが多い）。「チップ単価」「消費電力」「性能」のあらゆる面で、ASICとFPGAでは、ざっくりした感触だが一桁くらい、特性によってはもっと違うこともある。だから、FPGAを使っているのだけれど、安く作れるならばASICに移行したい、というモチベーションは確実に存在する。
eASICはASICとFPGAの隙間を埋める？
その大きな「ギャップ」を突いているのがeASICだ。概念としては「Structured ASIC」という分類になる。カスタム設計のためのマスクが必要なのは、従来型のASIC（スタンダードセル）と同様だが、数十枚を要する従来型に比べて、たったの1枚で済む。その1枚もメタル層間のVIAと呼ばれる層で他の微細さの際立つ層よりは緩い。たった1枚のカスタマイズだが、発注して製造してもらうという従来ASICと同じ工程を踏む必要がある。
しかし、枚数が少ない分、コスト的および納期的なアドバンテージは大きい。また、プログラマブルなロジックを使っている点ではFPGAと同様だが、通常のFPGAがSRAMセルをプログラムに使い、またプログラマブルなスイッチを使って配線を接続しているのに対して、配線層そのものをカスタマイズしているためにこれらの余計なトランジスタは不要となる。FPGAに比べると回路規模も消費電力も減るのが、スピードアップできる理由である。
反対に言えば、即書き換えできるFPGAに比べたら納期は長大で、一般的なASICに比べたら余計なものを積んでいるので回路規模も大きい。FPGAとASICのギャップが大きいからこそ存在できるジャンルであり、ギャップが狭くなったら押しつぶされる危険もある。
このようなギャップを埋める会社をIntelは買ったわけだ。ご存じの通り、IntelはFPGAの大手「Altera」を買収し、今や押しも押されもせぬFPGAメーカーでもある。また、ASICのさらに先の形態ともいえる製造受託（ファウンダリ）ビジネスもやっていないわけでもない。どうして「間を埋める」必要があったのか、今後の動きをよく見極めるべきだろう。
しかし、eASICという社名を言われてピンとくる人は、実際それほど多くないだろう。この会社を一言で説明すれば、「社名の一部になっている『ASIC』と普通の『FPGA』の隙間で商売してきた会社」である。そう説明しても、多分若い人にはあまり理解されないのではないかと思う。何といっても、このごろは「ASIC」というもの自体が理解されていない気がするからだ。
私事で恐縮だが、業界に入り、下っ端で配属された初めてのプロジェクトは8bitのマイクロコントローラーだった。以来数十年をマイクロコントローラー、マイクロプロセッサなど、日本式に言えば「マイコン屋」でやってきた。けれど、ほんの一時だったが「ASIC屋」も経験したことがある。中間管理職だったので自分でASICを設計することはなかったが、同じ半導体業界といえ、マイコン屋とは「心の持ちよう」の違いにビックリしたものだ。
今にして振り返れば、一度は世界を席巻した日本のASIC業界が落日を迎えつつあるころのことだった。日本だけでなく、当時のASIC業界では撤退する会社も多く、ほとんどのASICベンダーが苦境にあえいでいるような時期でもあった。外目に、eASICはそんなASIC業界の苦境の中に現れて、着々と地歩を固めて今に至っているように見える。今回のIntelの買収も、ASICの何が強みで、何か弱点であったのかを知らないとなかなか理解できないのではないかと思う。
eASICをFPGAの会社に分類するか、ASICの会社に分類するかと問われれば、筆者はASICの会社の方に分類する。eASICの製品の基本的な回路構成はFPGAにごく近いものがあるにもかかわらずである。なぜならば、ビジネスについてのスタンス、言ってみれば「心の持ちよう」という点で根本的にASIC側なのである。
そもそもASICとは
ASICとは何か、それは「お客が使い道を決め」、つまりは仕様を決め、多くは自ら設計をし（設計外注に丸投げというケースも多いが）、製造にかかわることだけ（これには設計の後工程でもある設計検証やテストなども含まれる）を半導体ベンダーにやらせて作ったカスタム（開発費をお客が負担し、該当のお客だけがチップを入手できる）半導体製品である。端的に言うと、ASICベンダーは自分が製造しているチップが「何者」であるのか、について関知しない。客の希望通りに作るのみ。
FPGAだってお客が設計をするじゃないかと言われるかもしれない。しかし、FPGAの場合、汎用品であるFPGAのチップを買ってきて、お客がそれをプログラムしている。買ってきた製品の型番が同じなら、お客のA社もB社もみんな同じチップを使っていて、そのチップの仕様を決めたのはFPGAベンダー側である。当然、FPGAチップの開発費はFPGAベンダーが製品に広く乗せられているはずだが、チップを買うときに開発費を別途払えとは言われない。
これに対してASICの場合、チップの仕様も用途もお客に責任がある。製造上の問題にのみ半導体会社は責を負う（実際にはいろいろ大人の問題もあるが）。そしてその製造にかかわる開発費としてお客が費用（多くはNREと呼ばれる。NRは「払い戻し不可の」という意味を持つ）を負担している。
今のようにFPGAが登場する以前、世の中にはASIC製品があふれていた。家電製品、PC関連、制御など、基板の上にはASICが大量に存在していた。そしてそれらのかなりの割合が日本のASICベンダーの製造によるものだった。
当時、日本の半導体業界が先端工場への巨大な投資に対応し切れず、後れを取るにつれて日本の地盤が下がった。ことASICについては国内国外に関係ない逆風も吹いてきた。「開発費」の高騰という問題である。
例えば数百万円の開発費で10万個のASICチップを作れた時代なら、チップ単価に数十円の開発コストを乗せれば採算が合う。この程度であれば、小口や中小の案件でも幅広いASIC商売は成り立つ。だが、プロセスが微細化するにつれて、開発費は数千万から数億円といったレベルに高騰していった。
なお、開発費の大部分は製造に使うマスク代である。先端プロセスのマスク（レチクル）は目の玉が飛び出る値段なのだ。こうなると数千万個といった製造規模か、金に糸目をつけない特殊用途でもないと成り立たない。つまり先端のASICを発注して採算をとれるようなプロジェクトのハードルがひどく上がってしまったのである。当然お客は激減した。
ASICとFPGA、それぞれの利点・欠点
ちょうどこのころ、FPGAの商売が立ち上がりつつあった。FPGAのチップ単価はASICのチップ単価に比べれば非常に高かったが、開発費の支払いは不要だ。1個からでも購入できる。よって、試作に始まり、少量個数の量産など数量の少ないところからFPGAは使われ、ASICという選択肢は消滅していった。
しかし、FPGAを使っている人はお分かりだろうが、ASICより不利な点も多いのである。まずは「フィールドでプログラムする」という、ある意味で本来の機能とは関係のない機能のために搭載しているロジックの量が半端ないのだ。そのため、全体のロジックの中で、「プログラミング」のためのロジックは最大80％（eASICの主張による数字）にも達するという。
つまり、チップ単価がそれだけ増す（先端のFPGAなど1個数十万円、初物では3桁万円という話もある）、ということである。また、チップがその分電気を多く消費する（PC用のCPUやGPUと肩を並べる）、ということでもある。あるいは、余計な回路の分、性能が上がらない（CPUどころかGPUのクロックにも遠く及ばないことが多い）。「チップ単価」「消費電力」「性能」のあらゆる面で、ASICとFPGAでは、ざっくりした感触だが一桁くらい、特性によってはもっと違うこともある。だから、FPGAを使っているのだけれど、安く作れるならばASICに移行したい、というモチベーションは確実に存在する。
eASICはASICとFPGAの隙間を埋める？
その大きな「ギャップ」を突いているのがeASICだ。概念としては「Structured ASIC」という分類になる。カスタム設計のためのマスクが必要なのは、従来型のASIC（スタンダードセル）と同様だが、数十枚を要する従来型に比べて、たったの1枚で済む。その1枚もメタル層間のVIAと呼ばれる層で他の微細さの際立つ層よりは緩い。たった1枚のカスタマイズだが、発注して製造してもらうという従来ASICと同じ工程を踏む必要がある。
しかし、枚数が少ない分、コスト的および納期的なアドバンテージは大きい。また、プログラマブルなロジックを使っている点ではFPGAと同様だが、通常のFPGAがSRAMセルをプログラムに使い、またプログラマブルなスイッチを使って配線を接続しているのに対して、配線層そのものをカスタマイズしているためにこれらの余計なトランジスタは不要となる。FPGAに比べると回路規模も消費電力も減るのが、スピードアップできる理由である。
反対に言えば、即書き換えできるFPGAに比べたら納期は長大で、一般的なASICに比べたら余計なものを積んでいるので回路規模も大きい。FPGAとASICのギャップが大きいからこそ存在できるジャンルであり、ギャップが狭くなったら押しつぶされる危険もある。
このようなギャップを埋める会社をIntelは買ったわけだ。ご存じの通り、IntelはFPGAの大手「Altera」を買収し、今や押しも押されもせぬFPGAメーカーでもある。また、ASICのさらに先の形態ともいえる製造受託（ファウンダリ）ビジネスもやっていないわけでもない。どうして「間を埋める」必要があったのか、今後の動きをよく見極めるべきだろう。
インシデント検知への投資を最適化！ 機械学習を活用した新SIEMソリューション
企業はサイバー攻撃に対してさまざまな防衛手段を講じてはいるが、攻撃者はずる賢く、また執拗（しつよう）に攻撃してくる。このため「いつかは攻撃者が防御を突破する可能性を前提にして対策を講じないといけない」と、GRCS マーケティング部 執行役員兼CMOの向井純太郎氏は指摘した。
その手段として注目を集めているのが、さまざまなログを集約、解析して侵入を検知する「SIEM」（Security Information and Event Management）だ。ただ、SIEMを活用するには、導入コストだけではなく、ルールのチューニングの煩雑さや増加する一方のログ容量にどう対応するかといった課題も浮上している。
GRCSではこうした課題を解決すべく、「MapR」をはじめとするオープンソースソフトウェア（OSS）を採用してコストを最小化し、さらにAIの力を活用して脅威検知ルールの作成、修正を支援する「SIEM.AI MT」をリリースした。
「内部からの情報流出や外部からの不正侵入を検知するルールの作成、導入、運用をAIで支援する。ビッグデータの時代において、膨大な容量のデータとどのように向き合っていくかは、今後の重要な課題であり、真剣に考えなければいけない。また、高度化する攻撃に限られたリソースで対処するには、AIのような最新技術の活用が重要だ」
MapRはそのHadoopディストリビューションの一つだ。「MapR-FS」として独自にファイルシステムを書き直すことで、ストレージ本来のI/O性能を引き出し、より高速で安定した処理を実現する。 また、マップアール・テクノロジーズ ソリューションエンジニアの板垣輝広氏も「大量のログにどう向き合うかがポイントだ。従来型データベースでも処理できなくはないが、コストやリアルタイム性といった要件を満たすのが難しい」と指摘。その観点で、大量のログ分析において注目を集めているのが分散ファイルシステム、分散処理フレームワークから成るOSSの「Apache Hadoop」ベースの技術だ。
板垣氏は、MapRの技術を用いてログを蓄積し、機械学習を活用して分析、レポートを行っているNASDAQの例を紹介し、「GRCSも、こうしたワールドワイドで実績のある形と同じ使い方をしている。MapRの特性を生かし、性能と可用性、コストパフォーマンスを両立させたソリューションだ」と述べた。
その手段として注目を集めているのが、さまざまなログを集約、解析して侵入を検知する「SIEM」（Security Information and Event Management）だ。ただ、SIEMを活用するには、導入コストだけではなく、ルールのチューニングの煩雑さや増加する一方のログ容量にどう対応するかといった課題も浮上している。
GRCSではこうした課題を解決すべく、「MapR」をはじめとするオープンソースソフトウェア（OSS）を採用してコストを最小化し、さらにAIの力を活用して脅威検知ルールの作成、修正を支援する「SIEM.AI MT」をリリースした。
「内部からの情報流出や外部からの不正侵入を検知するルールの作成、導入、運用をAIで支援する。ビッグデータの時代において、膨大な容量のデータとどのように向き合っていくかは、今後の重要な課題であり、真剣に考えなければいけない。また、高度化する攻撃に限られたリソースで対処するには、AIのような最新技術の活用が重要だ」
MapRはそのHadoopディストリビューションの一つだ。「MapR-FS」として独自にファイルシステムを書き直すことで、ストレージ本来のI/O性能を引き出し、より高速で安定した処理を実現する。 また、マップアール・テクノロジーズ ソリューションエンジニアの板垣輝広氏も「大量のログにどう向き合うかがポイントだ。従来型データベースでも処理できなくはないが、コストやリアルタイム性といった要件を満たすのが難しい」と指摘。その観点で、大量のログ分析において注目を集めているのが分散ファイルシステム、分散処理フレームワークから成るOSSの「Apache Hadoop」ベースの技術だ。
板垣氏は、MapRの技術を用いてログを蓄積し、機械学習を活用して分析、レポートを行っているNASDAQの例を紹介し、「GRCSも、こうしたワールドワイドで実績のある形と同じ使い方をしている。MapRの特性を生かし、性能と可用性、コストパフォーマンスを両立させたソリューションだ」と述べた。