ユーザ・ドリブン・アーキテクチャ・デバイス (UdAD) の検討
Consideration on User-driven Architecture for Devices (UdAD)
大橋 正†
Tadashi Ohashi
１． まえがき
今日の電子機器(デバイス)は仕様が最大機能（オーバ・ スペック）になっており，ユーザが時として不要な機能 又は操作の場合にも，購入したデバイスに合わす，デバ イス・オリエンテッド・システムに陥りやすい．この結 果，使用しない機能に伴う操作性の複雑さ，回路や部品 のために消費電力の浪費や販売価格の高騰化の一理を招 く傾向にあると考える．本来であれば最大機能をデバイ スが持ち合わせていたとしても，ユーザが必要な時に必 要な機能に限定するユーザ・ドリブン・デバイスはユー ザが欲する機能を満たし，且つエネルギーの保全及び自 然エネルギーの持続可能なＩｏＴシステムを実現する上 で重要である．以上の問題を解決するアーキテクチャを 具 備 し た ユ ー ザ 駆 動 シ ス テ ム （ 仮 称 ： User Driven Architecture for Devices: UdAD ユーダッド）を提唱す る[1] [2]．上記問題の解決策として，ユーザの欲する機能を実現する部品情報及びオブジェクトをクラウドから LOD (Linked Open Data) [3]により集め，クラウド上でシステ
ム・ゼネレーションを行う為に所与のデバイスのシステ ム構成をクラウドで収集し，所与のデバイスのハードウ ェア動作条件を満足するコンパティビィティを論理推論 又は機械学習により満足させるハードウェア(H)及びソフ トウェア(S)構成情報を形成し，デバイスのシステム機能 強化やシステム機能弱化をデバイスへ自動的に反映なら し め る 手 段 を 講 ず る ． こ の 手 段 は 強 化 操 作 (Strong Operation)または弱化操作(Weak Operation)のアーキテ クチャを形成するものであり，デバイス側にはシステム 構 成 の 柔 軟 性 に 富 む FPGA(Field Programmable Gate Allay) [4]を実装し，プロダクツの実行形式オブジェクト をクラウドからダウンロード可能なＩｏＴへのユーザ・ ドリブン・システム方式(UdAD)の研究を報告する．
2
．現状の課題とその解決
今日に出現してきたスマートデバイスは ICT の中枢を 担っており今までの利用環境が固定から携帯へと変遷し てきた．これに伴い運用形態が利用場所に制約されるこ となく，ユーザの利き腕となり，ユーザの思いを実現す るユーザドリブンのデバイスとしての地位を確立してき た．特にオープンソースの OS の出現はこの確立を築き上 げる一因ともなった． 一方ユーザ・ドリブン・システムはサステナビリテを 実現するシステムともいえる．ここでサステナブルシス テムに論点を向ける．今日では自然エネルギーの保全を 意図したシステム設計，即ちデバイスの電源の省電力化 が中心となっているが，その本質を堅持しながらサステ ナビリテは広範にわたる．更に加えてデバイスの品質維 持，セキュリティの維持，更にはユーザが購入デバイス を長期にわたって使用したいという意欲を醸し出し，デ バイスを新規に買い変えることなく維持して使っていこ うという視点もサステナビリテと考える．2．1 現状の課題
現状の課題のメインテーマはサステナビリテの達成が ユーザドリブンの在り方に繋がると考える．所与の購入 デバイスのハードウェア及びソフトウェアの機能の版数 を上位に挙げることが機能強化即ち Strong Operation と し，下位に下げることを機能弱化即ち Weak Operation と して捉える．以上の機能を具備したデバイス・ドリブン のサステナビリテ設計を阻害する課題を下記に列挙する． (1)ハードウェア製品及びソフトウェア製品の設計・製 造・検査の多様化． (2)ハードウェア及びソフトウェア設計の上述した広範囲 な意味を包含したサステナビリテの視点に立った設計思 想の欠如．2．2 課題解決
デバイスに実装されるハードウェア・プロダクト及び ソフトウェアプロダクトを上記 2．1 の各項目に合わせて 課題解決のシナリオを以下に記述する． (1)設計・製造・検査の多様化． デバイスの設計・製造等のプロセスが国内外の多種多 様な個人若しくはメーカ等により行われており，すでに 一箇所で行うことはできない．従いソースコード又はオ ブジェクトをクラウドでビックデータとして維持管理さ せ る ． 各 々 の 構 成 要 素 は RDF(Resource Description Framework) [5]又は OWL(Ontology Web Language)[6]でハードウェア部品及びソフトウェア部品の構成メタ情報(CMD: Compositional Meta Data)として表現し，構成メタ情報 にプロダクトの機能版数ソース及びオブジェクトの格納 場所及び動作条件を具備させる．更にデバイスの構成要 素 は 上 記 の 構 成 メ タ 情 報 の 塊 を 構 成 群 デ ー タ (CGD :Compositional Group Data)とする．
(2)サステナビリテの設計思想の導入 Strong 及び Weak 操作の導入することで問題解決を図 る． 双方の機能はハードウェア動作の確証
，
論理的推論 又は機械学習によりコンパティビリティ検証を行い動作 の保証を確立する．3 ．提唱するアーキテクチャ
以下に提唱するアーキテクチャの処理概要をクラウド (ウェブ)側とデバイス側に大別して述べる． 図 1 のシステム全体構成図に於いて，UdAD/Cn システム (ユーザ・ドリブン・システムのクラウド側システムとし て定義)はデバイスの開発元若しくは販売元が管理者とな り多種多様のデバイスのハードウェア及びソフトウェア †アイリクト（iLICT）http://www.ilict.jp構成情報(CMD,CGD)をメーカ側が RDF/OWL 変換サイト等を 利用して準備を行う．更に各メーカとは別に登録された 構成情報をスマッシュさせたりする管理者を置く．クラ ウドにはビッグデータ(Big Data)として以上の H/S 構成 情報とオブジェクトデータがクラウド空間に格納されて いる． 図 1 システム全体構成図 一方所与のデバイス購入者がユーザとなり，ユーザの 欲望，若しくは利便性あるいは省電力化等の為にユーザ が醸し出すサステナビリテを満たすユーザ・ドリブンな システムの強化(Strong)操作若しくは弱化(Weak)操作指 示をデバイスからクラウドに発する．
3．1 クラウド側のアーキテクチャ
図 1 のシステム構成図で示された個々のエンドポイン ト ・ サ ー バ UdAD/Cn は 以 下 の 図 2 で 拡 大 表 示する． RDF/OWL ストアは多種多様のメーカ又は個人の設計者が管 理するハードウェア及びソフトウェアプロダクトに関す る構成メタ情報 CMD とその集合である構成群 CGD で構築 される．複数の UdAD/Cn 間で階層構造を形成し所与のハ ードウェア又はソフトウェアのプロダクトの各メーカに よる開発関係を示している．以下の図 2 に於いてはクラ ウド上にメーカ A,B,C 社の各々の設計者が所与のハード ウェア部品又はソフトウェア部品がクラウド上で構成さ れていることを例示している.各部品は 6 つの構成メタデ ータ CMD で一つの構成群データ CGD を構成している. 図 2 各メーカによるプロダクト開発関連図 例えばハードウェアの任意の部品に着目すると，FPGA の上位階層はプリント板であり下位構成であれば FPGA に 実 装 さ れ る ゲ ー ト 情 報 で あ る ． 次 に 図 3 に お い て UdAD/Cn にはこのハードウェア及びソフトウェア部品を自 エンドポイント・サーバのみならず他のエンドポイン ト ・ サ ー バ を 検 索 す る た め に SPARQL(SPARQL Protocol and RDF Query Language) [7] [8]検索エンジンが具備され て お り 必 要 に 応 じ て LOD API(Application Program Interface)を介して実行される． 図 3 UdAD/Cn アーキテクチャ 更に加えてオブジェクトデータもメーカ及び個人の設計 者が構築して当該データストアーに登録される．これと は別に所与のデバイスの構成情報は UdAD/Dm(ユーザ・ド リブン・システムのデバイス側システムとして定義)構成 データベースに格納され再構成後に必要なオブジェクト データの格納場所が紐付されて再構成データベースに格 納される．その再構成を行うエンジンが CMD/CGD 再構築 エンジンである．再構築の確証は同条件ハードウェア確 証エンジンと論理推論エンジンと機械学習で行われる． (1) クラウド(ウェブ)側:UdAD/Cn (UdAD on Cloud)① ユーザの要望する構成情報の生成を行い，現状の デバイスのハードウェア(H)及びソフトウェア(S)の構成 情報(メタ情報)を RDF または OWL で表現する．
② 各々の要素間を LOD(Linked Open Data)で結合させ る．当該 LOD はクラウド上でビッグデータとして集合さ せられる． 図 4 プロダクト構成例 上記図 4 では所与のデバイス Dm のハードウェア及びソ フトウェアの構成例を示している．左側のツリーはハー ドウェア構成群データであり右側にはソフトウェア構成
群データを示している．構成情報を Strong 操作若しくは Weak 操作は先ずハードウェア構成に変更があるかを判断 し，若し変更がある場合 FPGA のデータ代替で吸収できな いかを判断する．代替が不可能であった場合は Strong 操 作若しくは Weak 操作は中断する． ③ Strong や Weak 動作の為の上位または下位機能の検 索は下記図 5 で例示したように SPARQL を駆動して実施す る． 図 5 SPARQL シンタックス例 上記の図 5 では機能版数の Strong を検索する場合の SPARQL シンタックスの一例を示している．当該クゥエリ では udad の独自の Strong を定義したサーバを定義し， 所与のプロダクト productNV が対象ハードウェア部品若 しくはハードウェア部品名 N と機能版数 V を設定してい る.検索の結果は所与の部品の上位機能版数 producCGD の 先頭場所を獲得することを示している．Weak 操作の場合 も同様である． ④ 構成情報にはハードウェア(H)及びソフトウェア(S) の名称，版数を具備し更には動作条件も包摂している． ⑤ 動作条件には所与の H/S プロダクトが動作する H/S 環境条件を基にハードウェア確証エンジンが動作可能を 保証している．例えば動作するための OS の名称，版数並 びにはハードディスク等の空き容量などの構成情報を持 つ． 図 6 Strong(上位),Weak(下位)検索 ⑥ ハードウェアに変更が生じた場合では，FPGA 上の ソフトウェアで代替できるか否かを判断する．もし代替 できない場合は希望とする Strong 若しくは Weak を実現 不可なので実現不可メッセージを出して終了する． ⑦ 動作条件は論理和，積等の一般的な論理式で表現で きる．Strong 操作や Weak 操作が動作できるか否かはこの 論理式が真か偽かで推論できる． ⑧ 論理的に動作条件が真か偽かを判定できない場合は 機械学習によって動作可か否かを判定することができる． ⑨ 所与の H/S プロダクトの Strong または Weak するた めの版数を芋ずる式に手繰り寄せ構成情報を再構築する 機能を具備する． ⑩ 再構築できた構成表により必要なオブジェクトの格 納場所を SPARQL にて見つけだすことができる． ⑪以上によりデバイスの格納するコンフィグレーショ ンをデバイスのメモリ空間としてクラウド上に展開する． ⑫このタオブジェクトを所与のデバイスの格納領域へ そのままダウンロードする．図 7 でハッチしたアプリケ ーションの例は後述で触れる Chrome[9]である．以上の処 理を図 6 の流れ図において例示する. 図 7 デバイス書込みデータ
3．2 デバイス側のアーキテクチャ
図 8 で例示する様にデバイス側は大きく分けて以下の 2 分野でアーキテクチャを構成する[1] [2]．（1）sWAP (sWAP control engine)
常電のコントロール・エンジンであり以下の eACE のハー ドウェア若しくはソフトウェアプロダクトをスワップさ せるコントロール・エンジンである．
（2）eACE ( embedded Architecture Control Engine) 実運用のコントロール・エンジンである．現状のハード ウェア並びにソフトウェアの一部分または全部を上位機 能に強化したり弱化させたりする．この入れ替え制御は eACE の電源を落とした状態で上記の sWAP が行う．sWAP が行われた後は eACE が復電をして通常運用に入る．eACE を構成する電子部品は汎用性を持たせるために FPGA [10]を 用いる．当該 FPGA ではソフトウェアにより従来のハード ウェア部品を置きかることができる．CPU や ARM 更に記憶 素子例えば DDRn[11]などが今後益々FPGA 内のソフトウェア で実現できると期待されている．
(3) seBridge( sWAP and eACE )ブリッジ
sWAP が中心となり実運用コントロール・エンジンの入 れ替えを行うための sWAP と eACE 間の橋渡しを行う機能 を具備している．
図 8 デバイス・ブロック・ダイヤグラム (4) 組込み ICE(IN Circuit Emulator)
従来は外付けであった ICE は sWAP と eACE の双方に実 装されている．いずれもデバッグの際に威力を発揮する． (5)ストレージコンポーネント UdAD/Cn か ら ダ ウ ン ロ ー ド さ れ た オ ブ ジ ェ ク ト は uDAD/Cn から毎回ダウンロードを不要とさせるために当該 ストレージコンポーネントに保管しておく． 以下に図 9 のハードウェアに実装するソフトウェアプ ロダクトの概要図を上記の図 8 に対比して述べる．sWAP に実装されるサステナブ・オペレーティングシステム sOS を基として，各種ライブラリー，アプリケーションフレ ームワーク，サステナブルアプリケーションが実装され る． 図 9 デバイス・ソフトウェア・ダイヤグラム UdAD/Dm と UdAD/Cn は通常 sWAP API を介してデータの授 受を行う．所与のデバイス内のテーブルやデータ類及び 現デバイスのソフトウェアプロダクトは sDBC API を介し て授受される．
4
．動作解説
今まではクラウド側を主体に論述したが，以降はユー ザ・ドリブン・システムという主題の元でデバイス側か ら論述を展開する． 図 10 UdAD ユースケース図 以下に図 10 に示したユースケース図を基に動作のシナリ オを述べる．4．1 デバイス側の動作解説
（1）デバイス側のユーザは，サステナブルシステムの実 現を目指して，現デバイスはハードウェア及びソフトウ ェア構成情報を RDF 又は OWL を変換サイトで生成する． ユーザは当該デバイスの入手時点からシステムの変更を していないのであれば Default として RDF/OWL を具備し ている． （ 2 ） sWAP は ユ ー ザ か ら の 対 象 と な る プ ロ ダ ク ト の Strong 操作若しくは Weak 操作の要望を上位系の UdAD/Cn へ要望する．(3) UdAD/Cn はこの要望を受理すると UdAD/Dm へ現状の デバイスの構成情報（RDF/OWL）を要求し，この情報を獲 得する．
(4) UdAD/Cn は Strong 及び Weak の機能を実現できるこ とを判断すると，その処理可能通知を UdAD/Dm へ伝達す る．もし不可能であると判断すると，その不可能通知を UdAD/Dm へ発信して一連の処理を中断して終了する． (5) UdAD/Dm は処理可能通知を受理すると，現状のデー タ類及びテーブル類及び現在のデバイス内のすべてのソ フトウェアプロダクトを UdAD/Cn へ格納する． (6) UdAD/Dm の sWAP は新規の構成情報とデバイスへ書き 込むオブジェクト・データを受理して esBridge を介して eACE へ書き込む． (7) 上記(5)で退避させた現状のデータ類及びテーブル 類を sWAP が eACE へ復元させる． (8) sWAP は電源を全て切断し，電源投入後に再起動させ る．
4．2 クラウド側の動作解説
（１）UdAD/Cn はデバイスからの Strong 操作又は Weak 操 作要求を受け付けるとデバイスへ現状のハードウェア(H)
及びソフトウェア(S)の全ての構成情報を RDF や OWL 形式 で要求する． （２）デバイスの H/S 構成情報を入手すると対象となる プロダクトに対する Strong 操作又は Weak 操作による要 望の構成情報を再構築する． （３）SPARQL のシンタックスに対象となるプロダクトの 上位または下位の機能を持ったプロダクトの構成情報の メタ情報を検索する．図 6 参照． （４）上位または下位のプロダクトを検索すると，プロ ダクトの動作条件のコンパティビリティを確認する．も し確認結果が真であれば Strong 又は Weak 操作を継続す る． （５）もしコンパティビリティが偽であれば Strong 又は Weak 操作を中断する． （６）動作条件のコンパティビリティはハードウェアの 動作保証や論理的判断より優先して確証を得る．もし確 証が得られない場合は機械学習により判別を行う． （７）動作条件にはハードウェアの環境条件も入る．例 えばワークエリアが 5MB とするとこれが満足できるかを 現在のハードウェア構成情報から確認しもし不足してい れば FPGA のストレージ容量を拡大し，併せてオブジェク トを展開する際のメモリーマップを変更する．又新たな ハードウェアの追加が余儀なくされた場合は FPGA のファ ームで代替させるように構成情報を変更し併せて FPGA の 拡大ストレージを実現するソフトウェアをソフトウェア 構成情報に追加する． （８）機械学習による判別では所与のプロダクトの機能 に対する Strong 機能及び Weak 機能の判断を図 11 の如く FFNN(Feed Forward Neural Network)[12]等を用いて行える
と考える． 図 11 機械学習の適用例 図 11 の機械学習適用例では構成メタデータ CMD 内の動 作条件若しくはコメント欄を設けて動作条件をテキスト 形式で記述させることで機械学習が可能であると考える． 機械学習の対象となる入力はプロダクトの動作条件であ り RDF で記述されたコメント行に記載されたテキストデ ータが使用される．将来的にはソースコードのテキスト 文をそのまま解読して動作条件を生成することもできる と考えている． （８）UdAD/Cn はハードウェアに於ける動作の確証や論理 的コンパティビリティ若しくは機械学習でコンパティビ リティを得ると新たに構築された構成情報により各々の メタ情報として示しているオブジェクトの保管場所から オブジェクトコードを LOD によりすべて収集する． （９）収集されたオブシェクトはデバイスの格納空間に 配列される．この配列はデバイスのストレージ格納空間 情報としてデバイスへダウンロードされる． 以上の流れ図をシーケンス図として図 12 に示す． 図 12 UdAD/Dm-UdAD/Cn シーケンス図 上図の図 12 では左側がデバイス側の UdAD/Dm を示し， 右側はクラウド側の UdAD/Cn を示している．ユーザはユ ー ザ ・ イ ン タ ー フ ェ ー ス の LCD(Liquid Chrystal Display) を介して Strong 又は Weak を指示する．この要 求は sWAP のコントロール・エンジンに受け付けられる． その要求はクラウド側の UdAD/Cn へ通知される．UdAD/Cn のエンドポイント・サーバはデバイスに対して現在のデ バイスのハードウェア構成情報やソウトウェア構成表を 要求する．この要求は sWAP のコントロール・エンジンに 受け付けとられ現デバイスの H/S 構成情報をエンドポイ ント・サーバ UdAD/Cn に転送する．UdAD/Cn ではユーザの Strong 操作若しくは Weak 操作の要求に応じて図 5 に定義 した SPARQL クエリーで Strong 検索又は Weak 検索を行う． その結果，構成群データ CGD の先頭場所を獲得すること ができる．現デバイスの構成情報(CMD/CGD)を基底として 上位及び下位プロダクトを得ることができる．一通り新 構成が得られた時点で，コンパティビリティによる確証 結果から必要により，既存 CGD を削除若しくは追加が行 われ新構成のチューニングが繰り返し行われる．チュー ニングはハードウェアの動作確証，論理的動作確証及び 機械学習によるコンパティビリティのすべてが真で終わ れば，所与のデバイスへ新構成情報を sWAP へダウンロー ドさせる．次に全てのオブジェクトを CMD の格納場所に より入手操作が実行される．デバイスに新オブジェクト をダウンロードするに先立って，現デバイスの実行エン ジンの eACE にある現テーブル，データ類及びソフトウェ アを sWAP が吸い上げ UdAD/Cn の退避用データベースへ格 納させる．以上の準備を終えると，新構成情報や新オブ ジェクト，退避していたテーブル及びデータ類を sWAP 経 由で eACE のストレージへ格納される．以上のスワップが
完了すると eACE の再起動が行われて新システムが稼働す る．
5
．適用事例
Android 用 Chrome を例に挙げて図 13 に適用事例として 述べる．最新機能版数は Chrome 42 である．この前機能 版数は Chrome 41 であり更に遡ると Chrome 40 である． ここで現デバイスの実装は Chrome 41 とする．この上位 系 Strong 操作は Chrome 42 下位系 Weak 操作は Chrome 40 となる． Chrome 42 の動作条件はホームページに以下の 通り記述されている[13]．図 9 適用事例
ここで現デバイスのソフトウェア(OS)の版数は構成情報 によれば Android5．0:LollyPOP[10]であったとするとユー
ザが Chrome41 の Strong を希望したとすると Chrome42 の 動作条件を満たすので UdAD(W)に於ける動作条件の論理 的コンパティビリティが真となることが分かる．ハード ウ ェ ア の 動 作 条 件 で は 現 在 の Android5 ． 0 配 下 で Chrome41 が動作しているハードウェア環境であればその まま継続できるので論理的コンパティビリティが真とな る．因みに Android5．0 の UdAD(D)のハードウェア動作 条件[12]は図 7 図 13 アプリケーションの動作条件の一例 ここで現デバイスのソフトウェア(OS)の版数は構成情 報によれば Android 5.0:LollyPOP[14]であるとしユーザが
Chrome 41 の Strong を希望したとすると Chrome42 の動作 条件を満たすので UdAD/Cn に於ける動作条件の論理的コ ンパティビリティが真となることが分かる．ハードウェ アの動作条件では現在の Android 5.0 配下で Chrome41 が 動作しているハードウェア環境であればそのまま継続で きるので論理的コンパティビリティが真となる．因みに Android 5.0 の UdAD/Dm のハードウェア動作条件[15]は図 14に一例として挙げられているが Chrome に関しての要件 は無い． 図 14 Android 5.0 パーフォマンス・コンデションの抜粋
6
．まとめ
（１）本論文の提唱する UdAD アーキテクチャがハードウ ェアのソフトウェア代替やオペレーティング・システム， ファームウェア，エミュレータ並びにアプリケーション の強化機能(Strong)若しくは弱化機能(Weak)により，ユ ーザの利便性向上，自然エネルギーの保全や持続可能な サステイナブルな社会システムとしての IoT の実現に有 効であると考える． （２）クラウドでのコンパティビリティの処理にハード ウェア動作確証，動作条件論理推論と動作条件判定機械 学習の適用が可能である． （３）seBridge がユーザ・ドリブン・アーキテクチャを 基いとにしたデバイス内の eACE と sWAP 間のデータ共有 及びファームウェア等のソフトウェアの入替手段となる． （４）CMD や CGD は RDF 及び OWL で表現されるが SHIM[16] とのコンパティビリティの整合も必要であると考える. （５）従来からの既存システムと当該提唱する UdAD シス テムをデバイス側とクラウド側の両面から総合的に考慮 してシステム導入によるコスト・パーフォマンスを俎上 に載せて議論する余地がある． 参考文献[1] 大橋 正:User-Driven Android Device(UdAD：ユーダ ッド)の検討. ABC (Android Bazaar and Conference) 2016 Spring, Mar12, 2016
http://abc.android-group.jp/2016s/timetables/ [2] Tadashi Ohashi “Perspectives for Architecture of Sustainable Control Engine” The 78th National
Convention of IPSJ. Mar. 2016
[3]Tom Heath and Christian Bizer “Linked Data-Evolving the Web into a Global Data Space” Morgan & Claypool Publishers, 2013.
[4]Editted by Peter Athanas, Dionisions Pnevmatikatos “Embedded Systems Design with FPGAs”Springer, 2012
[5]RDF https://www．w3．org/RDF/
[6]OWL https://www．w3．org/2001/sw/wiki/OWL
[7]Bob DuCharme “learning SPARQL 2nd Edition”
published by O’Reilly.
[8]SPARQL Query Language for RDF
https://www．w3．org/TR/rdf-sparql-query/ [9]CHROME, https://support．google． com/chrome/answer/95346?hl=ja
[10]Xilinx Inc． Virtex-5 FPGA User Guide， http://www.xilinx.com/support/documentation/user_gu ides/ug190.pdf
[11]DDR4 SDRAM
https://www.micron.com/products/dram/ddr4-sdram [12]David E． Rumelhert Parallel et al． Distributed Processing: Vol．1 pp．318-322
[13]What are the minimum hardware specifications for Android http://android．stackexchange． com/questions/34958/what-are-the-minimum-hardware-specifications-for-android [14]Android 5.0: LollyPOP https://www.android.com/versions/lollipop-5-0/ [15]Android 5．0 Compatibility Definition https://www．google．co．
jp/?gfe_rd=cr&ei=emcDV9aAAeX98weP4ZnoCg&gws_rd=ssl# q=Android5．0+Compatibility+Definition
[16]SOFTWARE-HARDWARE INTERFACE FOR MULTI-MANY-CORE (SHIM) http://www．multicore-association．
org/workgroup/shim.php 以上 Android スマートフォンまたはタブレットの場合 Chrome
for Android は、Android 4.1 （Jelly Bean）以上を搭載 したスマートフォンやタブレットで使用できる
．
Android4.0（Ice Cream Sandwich）をご利用の場合，Chrome バー ジョン 42 以下が動作するが，更新は行われない
．
1. Play ストアで Chrome for Android のページにアクセ スする
