プログラミング – HTML5Experts.jp

Webブラウザからハードウェアにアクセス！WebUSB APIを使ってログイン認証を実装してみよう

ちゃんとく — Wed, 20 Dec 2017 01:00:12 +0000

近年「IoT」がバズワードとなっていますが、「WoT（Web of Things）」というワードを聞いたことがあるでしょうか？

「WoT」はごくごく簡単にいうと、既に普及しているHTMLやJavaScriptなどのWeb技術を使ってIoTの開発を標準化しよう、という考え方です。WebBluetooth APIやWebNFC APIなど、みなさんが慣れ親しんでいるWeb技術を使ってハードウェアを制御する方法も増えてきています。

今回は、WebページからPCに繋がれたUSBデバイスを制御することができる「WebUSB API」の概要とサンプルを紹介します。

HTMLと簡単なJavaScriptで試せる内容になっていますので、Webデザイナーやディレクターなどエンジニアではない方もぜひチャレンジしてみてください！

WebUSB APIとは

WebUSB APIはPCに接続された全てのUSBデバイスにウェブから直接アクセスすることができる技術です。USBデバイスの認識、読み出し、書き込みなどを行うことができます。

Googleの2人のエンジニアによって開発され、2017年9月にはChromeブラウザ（Google Chrome 61）で正式に採用されました。

WebUSB APIを利用するとただちにユーザのUSBデバイス全てにアクセスできる、というわけではなく、ユーザがWebページとUSBデバイスの相互通信を明示的に許可することで開始されます。

WebUSB APIのポリシーやセキュリティについては、Googleの開発者向けページで詳細に紹介されています。

⇒ Access USB Device on the Web（Google Developers）

WebUSB APIの活用シーン

WebUSB APIを活用することで、これまで事前にドライバやソフトウェアのインストールが必要だったUSBデバイスのセットアップが、サイトにアクセスして許可するだけで自動で行えるなどの連携が考えられそうです。

またデバイスの開発者サイドのメリットとしても、OSごとに異なっていたドライバ開発がJavaScript SDKを使ってクロスプラットフォームに構築できるそう。

webusb/arduinoなどの例を利用してArduinoなどのマイコンボードをWebから制御することも可能になりました。

詳細な仕様は開発者のドラフトを確認してみてください。

⇒ WebUSB API

本格利用はこれから

ただし、実際にWebUSB APIを導入するにはまだまだ課題がありそうです。

USBアクセスを求めるWebページを公開するために資格や証明が必要ということはなく、利用ユーザは「本当に信頼できるWebページか」ということを知る方法が今のところありません。

また開発者サイドも、USBデバイスの情報が新しくなったり変更されたりするたびにWebページを改修する必要がある可能性もあります。

利用には気をつけるべきポイントが多く、WebUSBはまだ開発中の段階と捉えたほうがよさそうです。安全面、実装面ともに改良され、より使いやすい機能となっていくことに期待ですね。

WebUSB APIを使ってログイン認証を実装してみよう

今回は「登録済みのUSBデバイスならログインする」というWebページを作ってみます。

用意するもの

Chromeブラウザ
任意のUSBデバイス（筆者はiPhone7）

手順1：Chromeのバージョンを確認する

はじめに、ChromeブラウザがWebUSB APIに対応したバージョンになっているか確認します。

Chromeのツールバーから［Google Chromeについて］を選択します。

Chromeの情報ページが開くのでバージョンが62以上であることを確認します。

基本的には自動でアップデートされているはずですが、万が一されていない場合は下記を参考にアップデートしましょう。

⇒ Google Chromeを更新する（Google Chrome ヘルプ）

手順2：ログインページを作る

WebUSB APIを設置するWebページを作ります。今回はコード共有サービス「CodePen」からログインフォームのソースコードを利用しました。

Calm breeze login screen（CodePen）

［Export］からソースコードを取得しローカルに配置します。

今回は「Username」「Password」は不要なので、index.htmlのフォーム部分から消去しておきます。


	 // この行を消去
	 // この行を消去

ログインのイベントを作成する

LoginボタンをクリックしたらWebUSB APIのイベントが発火するよう、Submitボタンを変更します。

auth()というfunctionを呼ぶようにし、記述用のJSファイルの呼び出しも追加しておきます。

ログイン成功時のイベント（デフォルトのJQuery）は名前つき関数にしておきます。

function login() {
  $('form').fadeOut(500);
  $('.wrapper').addClass('form-success');
}

USBデバイスにアクセスして識別情報を取得する

認証に使用するデバイスを識別するために、［Vendor ID］, ［Product ID］, [Serial Number]を調べてみます。

Macの方は［システム情報］->［USB］で確認できます。

Windowsの方はMicroSoftのusbviewなどを利用しましょう。 ※このシリアル番号は、iPhone自体のシリアル番号とは別です。

/jsフォルダの配下にwebusb.jsファイルを作成し、authfunctionを作成します。コード内には取得したVendor ID（製造元 ID）、Product ID（製品 ID）、Serial Number（シリアル番号）を追加します。

'use strict';

const auth = () => {
  const vendorId = XXXX; // ここにVendor ID
  const productId = XXXX; // ここにProduct ID
  const serialNumber = 'XXXXXXXX'; // ここにSerial Number
  navigator.usb.requestDevice({ 'filters': [
      { 'vendorId': vendorId, 'productId': productId }
    ]
  }).then(device => {
    if (device.serialNumber === serialNumber) {
      console.log('success!');
      login();
      return device.open;
    } else {
      console.log('false!');
      alert('認証に失敗しました');
    }
  }).catch(error => {
    console.log(error);
  });
}

今回は簡易的にJSファイルに直接認証情報を書いています。

ログイン機能を試してみよう

登録したUSBデバイス（今回はiPhone）で試してみます。
認証が成功しました。

登録していないiPhoneでも試してみます。
認証に失敗しました。

これでUSBデバイスを識別することができました！

まとめ

今回はUSB接続したスマートフォンを利用しましたが、マウス、キーボード、フラッシュメモリなどUSBデバイスならどんなものでも利用可能です。

またWeb USB以外にも、WebBluetooth APIやWebNFC APIなどWeb技術を使ってハードウェアにアクセスする方法は増えています。ぜひこれからの開発に利用してみてください！

「テクニックは語りません」竹洞先生に聞く、本気のWebパフォーマンス道

白石俊平 — Thu, 09 Nov 2017 01:00:54 +0000

連載： HTML5 Conference 2017特集 (14)

こんにちは、編集長の白石です。

この記事は、9月24日に開催されたHTML5 Conference 2017に登壇したエキスパートに、お話されたセッションのトピックを中心に語っていただこうとういものです。セッションの内容をより深く理解する手助けになるだけでなく、本記事単体でも面白く読んでいただけることを目指しています。

今回お話を伺ったのは、html5j パフォーマンス部を運営していらっしゃる竹洞陽一郎さんです。

▲HTML5 Conference 2017セッション風景（写真提供：html5j　撮影：刑部友康）

竹洞さんのセッション「テクニックではなく、今、本気で取り組むべきWebパフォーマンス」に関するスライド資料は、こちらで公開されています。

民法（債権法）が改正されて、何が変わる？

白石: 民法（債権法）が改正された、ということに注目なさってるそうですね。

竹洞: はい、民法の大規模な改正法案が今年5月に成立しました。3年以内に施行されることになっており、備えが必要です。様々な改正項目がありますが、中でも品質の担保を行う義務が明文化されたことで、ソフトウェア業界にも大きな影響が及ぶものと考えています。

白石: 具体的にはどういうことなのでしょうか？

竹洞: 「瑕疵担保」っていう概念がなくなるんです（参考: 改正民法が成立、「瑕疵担保責任」などシステム開発契約に影響大 (ITpro)。

今までは「瑕疵担保」という概念があったおかげで、とりあえずは品質を担保しない状態で納品を行い、その後の瑕疵期間で問題を修正していく…というのが一般的に行われていました。ですが今後は、納品時に一定の品質を保証することが開発側に求められるようになります。

白石: そのことが、どういう影響をおよぼすと考えられますか？

竹洞: 私としては、ソフトウェア品質が全般的に向上することで、市場が健全化すると考えています。

品質への理解が低い市場は、必ずと言っていいほど衰退するんです。消費者が品質の善し悪しが判断できない状態だと、価格が一番の判断材料になります。そうなると結局、品質を犠牲にした価格競争にならざるを得ない。

白石: 「安かろう悪かろう」が当たり前になってしまうわけですね。

竹洞: そう。そういうスパイラルに陥らないためには、品質への意識を高く保つ必要があるんです。

例として適切かはわかりませんが、たとえば麻薬の売人って、品質にものすごく気を使うんです。質の悪い麻薬が出回るようになると、価格に対する期待と同程度の「ハイ」の状態を得られず、その結果、価格の下落を招き、結局市場が衰退してしまうからです。こうした現象を、アメリカの中古車市場の分析から「情報の非対称性」として研究したジョージ・アカロフ博士は、2001年にノーベル経済学賞を受賞しています。

「品質保証」がウェブ業界を変える

白石: しかし、品質保証が義務付けられるとなると、開発のコストが上がるということになりませんか？

竹洞: それはあり得ます。そのことが、受託開発のビジネスなどをより難しくしてしまうことも考えられます。

例えばウェブ制作会社は、一般的には納品後に入金が入るという仕組みになっていますよね。だから、まずは品質がそこそこの状態で納品してしまう…ということも起きるわけです。パフォーマンスはその悪い例で、まずはチューニングしていない状態で納品する。すると、後でパフォーマンス・チューニングの依頼が来てまた売上につながる…なんて事情も実際にはあるわけです。

こうしたこれまでの商慣行が崩れてしまう可能性はありますね。品質保証が義務付けられるせいで、納品までにより時間がかかるようになるとすると、入金が遅くなるということに繋がる。しかし、民法債権法改正では、部分単位やステージ毎の請負金額の要求ができるようになっています。

白石: それだけ聞くと、受託開発や制作を行っている企業にとっては、ただただ厳しくなるようにも聞こえますね。そもそも、「品質を保証して納品」ってどういうことなんでしょう？完璧なソフトウェアを作らねばならない…なんてそもそも無理だとも思うのですが。

竹洞: その点については安心していいと思います。「品質を保証する」というのは、「完璧な製品」を意味しているわけじゃないんです。テスト項目について顧客と合意し、その結果を提出すればいい。実は、ソフトウェア品質には、V&Vといって、Verification(検証)とValidation(妥当性確認)という二つの概念があります。

検証(Verification)とは、仕様・設計・計画などの要求事項を満たしているかどうかの確認です。妥当性確認(Validation)とは、機能や性能が本来意図された用途や目的に適っているか、実用上の有効性があるかの確認です。Webパフォーマンスは、品質においては、妥当性確認にあたります。

従来、ソフトウェア開発における「品質」、特に受託開発においては、検証確認が主体でした。もちろん、応答速度の遅延などで使いものにならないという妥当性確認もあったものの、それはハードウェア性能であったり、データベース設計の問題であったりと、「表示」そのもののロジックに原因はあまりなかったのです。

要求仕様の実現という意味での検証については、仰るとおり「完璧な製品」というのは、ほぼ存在し得ない。それは、ソフトウェアが、論理記述であって、物理法則の縛りがなく、かつ、連続性の保証がないためです。

連続性の保証とは、物理法則であれば、100Kgの重さまで耐えられるテーブルであれば、当然ながら、80Kgや10Kgなど、100Kg以下の重量に耐えられることです。しかし、ソフトウェアは二値論理がベースであるために、100という値で大丈夫であっても、80や10という値で大丈夫であるという保証がない世界です。

2002年に亡くなられた、オランダの著名な計算機科学者で、構造化プログラミングの提唱者でチューリング賞を受賞しているエドガー・ダイクストラ博士が「テストは誤謬を見つけることはできるが、それがないことを証明することはできない」と指摘しています。

ですから、バグや欠陥がないことを保証するというのは無理なんです。

白石: なるほど、それなら少し安心です。バグや欠陥のないソフトウェアなんて不可能ですし。

竹洞: 品質についても顧客との合意内容に盛り込む必要が生じる、ってことですよね。そうした合意があるのとないのとでは、品質に対する意識が全然違ってきます。品質については、検証として従来もやってきたことです。ところが、WebがソフトウェアのUIの主体となることによって、今まで問題にならなかった「表示」に関するロジックが突如、問題となり始めた。突如といっても、もう20年ぐらいになるわけですが…

その部分は、検証ではなくて、妥当性確認なんですが、妥当性確認のテストのノウハウが日本では普及していなかった。今、そこが問われているわけです。

白石: なるほど。「完璧な製品を作る」ことが品質保証なのではなく、「妥当性品質に対してどこまで保証するかを明確にする」ということなんですね。

竹洞: そうです。そうして、妥当性品質についての期待値を高く保つことは、Webに関する業界として必要なことだと思いますよ。

例えば日本の住宅市場は、品質保証がうまくいっていない例だと思うんです。日本の住宅って、非常に寿命が短いじゃないですか。その理由は様々ですが、一つに中古住宅に対する品質の期待値が低いことがあると思っています。品質保証がない空き家を買うくらいなら、新築のほうがいいって心理です。

白石: 確かにそういう一面はある気がしますね。ぼくは安さに釣られて中古住宅を買ったクチですが(笑)、一生住めるなんて少しも期待してませんし。

竹洞: それって、結局その家はいつか捨てることになるってことで、財の蓄積が進んでいないとも言えると思うんです。社会的に見ると、将来世代に引き継ぐ財が形成されていないとも言える。財の蓄積が期待できないと、そこの投資は進まない。お金が集まってこないのです。

ウェブのように技術がどんどん進歩していく世界に財の蓄積は有り得るのか？システム構築費用は5年で償却されるのであれば、5年持てばいいじゃないか？という考えられるのは、仰るとおりです。

しかし、プレゼンテーションとしてのUIデザインと、データとしてのコンテンツやユーザのデータは分けて考えるべきで、だからこそ、HTMLとCSS、JavaScriptで役割分担をしているわけじゃないですか。システムの永続性というものを考慮してWebサイトの設計を行うことは非常に重要なのです。

減価償却期間の5年も持たない、3年程度で捨てざるを得ないとなれば、企業財務的にはそこはできるだけ安く済ませるべきなのです。しかし、品質が保証されて、減価償却の5年を超えて使えるとなると、将来価値が上がる。企業財務的にはおいしいお話なのです。そこに気付いてほしい。メンテナンス費用は当然発生するでしょうけど、新規で作るより安いですし、何より「継承」できることが大きなメリットなんです。

UIデザインや技術力だけで勝負しているWeb制作会社さんは、その点に、早く気づかれた方が良いと思います。お金を握っている経営者や財務担当者は、別のロジックで判断しているわけですから。

ですから、ウェブサイトも、いつか捨てるものとなれば、そこに予算を掛けようとは思わない。品質が保証されないのであれば、なおさらのことです。

「お客様からあまり予算をいただけない」と嘆くことがあるかと思いますが、その背景には、品質が保証されていないので修正するより作り直した方がいいと考えられていること、いつかWebサイトは捨てて新しく作るものと考えられている背景は認識しておくべきだと思います。

ウェブサイトの品質を決める3つの要素

白石: では具体的に、ウェブサイトにおける品質を保証するというのは、何をすればいいんでしょうか？

竹洞: ウェブサイトの品質は主に3つの要素から成っていると言っていいでしょう。

一つはアクセシビリティ。一つはセキュリティ。最後がパフォーマンスです。

Webサイトの三大品質

これらはそれぞれJISで規定されてもいる重要な指標です。これらをしっかり担保していく体制づくり、それがウェブサイトの品質保証に繋がります。

白石: ウェブサイト制作にも、これらを担保するワークフローを確立していくべきということですね。

竹洞: そうです。そしてこれらは、運用と一体になって改善していくべきものでもありますので、DevOpsの観点から考えるのも重要です。

ただ一つ不思議なのが、日本でDevOpsに関して述べている文献や書籍って、ほとんどの場合品質保証のことが抜けてしまっているんですよね。品質に対する意識が高まらない原因は、こういうところにもあると思います。

DevOps

ウェブサイトの品質を高めるための心構え

白石: 品質を向上させるためのコストが低く見積もられがちというところもあるんでしょうか。

竹洞: というよりは、そのコストが認識されていないというのが正しい気がします。「品質、費用、期間の3要素を同時に満たすことはできず、トレードオフの関係にある」といった、プロジェクトマネジメントやソフトウェア開発見積りの基本もあまり浸透していない感覚がある。

白石: なるほど。当たり前の話ですが、品質を高めようとすれば、時間的、金銭的なコストを支払う必要があるということですね。

竹洞: はい。そして品質保証が当たり前になれば、品質保証のためのコストがかかるのも当たり前になる。今は、その当たり前のコストを払っていないだけとも言えるのです。

白石: では、そうした品質保証、特にパフォーマンスについて、状況を改善していくにはどんな知識が必要になるんでしょう？

竹洞: そうですね、小手先のテクニックはたくさんありますし、いろんなところで語られてもいますので、もう少し根源的なところから考えると、結局「基礎」と「長期的な視野」が重要になると思うんです。

基礎というのは、コンピューターやネットワークに関する基本的な知識。長期的な視野と言うのは、数年後にインターネットがどうなっているか、といった話です。

白石: なるほど。

竹洞: 例えば、パフォーマンスに関する話を突き詰めていくと、意外なほどハードウェアに関する知識って大事なんです。パフォーマンスって、最終的には絶対にハードウェアに依存するわけですからね。

例えば、とある大規模サイトで遅延が発生していたんですが、その原因を追求するのすごく大変だったんです。アプリケーションをいくら調べても、データベースのクエリをいくら見直しても、ネットワークの状態を見ても、原因がわからなかった。

白石: 結局、どんな原因だったんですか？

竹洞: そのサーバはVMWareで仮想化されていて、サーバ負荷に応じてCPUリソースが動的に割り当てられるようになっていました。ただ、あらかじめ割り当てられているCPUリソースが足りなかったせいで、CPUの動的割り当てが頻繁に発生してしまっていたんです。その割り当てが行われる際に、サーバの処理が遅延してしまっていたんですね。

白石: それは深い原因ですね…

竹洞: ここまで奥深くに原因がある場合って、ハードウェアを含めたアーキテクチャ全般の知識が必要になります。だから結局、コンピューター全般の知識って必要だなと。だから私の会社では、入社したら最初の一歩として、まずPCを自作してもらうようにしています(笑)。

全てを変える、5Gネットワーク

白石: 数年後にインターネットがどうなっているか、というお話も聞かせていただけますか？

竹洞: はい、具体的には5Gネットワークの話になりますね。5Gはアプリケーションの作り方を含め、全てを変える可能性がある技術だと思っています。

白石: 5Gネットワークって全然知らないのですが、どんな感じなんでしょう？

竹洞: 大きく3つのトピックがあると考えています。

一つはネットワークスライス。インターネットを「輪切り」にするイメージで、用途に応じて別々のネットワークを提供していくようになります。

電波には周波数によって特性があり、サービスの特性に応じて周波数を割り当てて異なるネットワークを構成できるので、ネットワーク全体の利用効率が大きく向上すると考えられています。

ネットワークスライス

次に指向性アンテナです。今までは、基地局といういわば「傘」を中心として、そこから広がるように無線ネットワークが構築されていました。

しかしこれからは、パネル型のアンテナがビルの壁面に貼られるようになり、そこから端末と直接「ビーム」をやり取りするように通信を行います。通信の受信強度が高まるだけでなく、他の電波との干渉も減らせます。

指向性アンテナ

最後にモバイル・エッジ・コンピューティングです。これは、4Gですと、地域の基地局をまとめているRNC(Radio Network Controller)配下に、仮想サーバー（エッジサーバー）を設置できるようになるのです。今まで携帯の会社はコアネットワークを公開していなかったので、これは大きな変化です。

モバイルエッジコンピューティング

これは分散コンピューティングの新たな可能性を示しているといえます。インターネットより手前でトラフィックを捌けるわけですから、サーバーの応答性も大きく向上します。

白石: へえ、知りませんでした！世界中のエッジサーバー上に、静的リソースのキャッシュを置けたりしたら、すごく速くなりそうですね。

竹洞: それだけではありません。エッジサーバーで可能な限り処理を行い、必要な処理だけインターネット上のサーバーに送るようにすることもできます。アプリケーションの処理を、エッジサーバーとインターネット上のサーバーで分担するというわけです。

もしくは、全てエッジサーバー上で処理を行うような、非インターネットのローカルなサービスを行うことも可能です。

白石: そうなると、アプリケーションの作り方も大きく変わってきそうですね。夢が拡がりますね…。5Gネットワークって、具体的にはいつ頃普及が見込まれているのでしょうか？

竹洞: 2020年の東京オリンピックまでには使えるようになるだろうと言われています。

10月12日に、NTTドコモ、富士通、富士通研究所がモバイル・エッジ・コンピューティングを使った高画質動画配信や映像解析を活用した人物検知システムの実証実験を行って成功した旨のプレスリリースを発表してています。

また10月13日には三菱商事が、この分野のリーディングカンパニーであるJIG-SAWと、モバイル・エッジ・コンピューティングの実証実験成功のプレスリリースを発表しています。

白石: ワクワクしますね。本日は民法から5Gネットワークまで、幅広いお話を聞かせていただき、ありがとうございました！

WebGLの現状と未来を、Grimoire.jsを生んだスーパークリエータに聞いてきた！

白石俊平 — Thu, 02 Nov 2017 01:00:22 +0000

連載： HTML5 Conference 2017特集 (12)

こんにちは、編集長の白石です。

今回お話を伺ったのは、東京理科大学4年の石井翔さんです。

石井さんのセッション「WebGLの今とこれから ~今のWeb開発で使うからこそ知っておきたい周辺技術~」に関するスライド資料は、こちらで公開されています。

スライド資料（注: 重いのとモバイルから見えないのはご容赦ください by 石井翔さん）

WebGLの現状

白石: 本日は取材をお受けいただいてありがとうございます！簡単に自己紹介をお願いします。

石井: 東京理科大学4年生の石井翔です。昨年、私が進めているGrimoire.js（注: モバイルからだと多少レイアウトが崩れます by 石井翔さん）というプロジェクトが未踏IT人材発掘・育成事業に採択され、スーパークリエータに認定されました。

白石: Grimoire.jsはWebGLのライブラリですね。Grimoire.jsについてもあとでお聞かせ願いたいのですが、まずはWebGLの概要や現状についてお話いただけますか？

石井: WebGLは、一言で言えばWeb上で3Dコンテンツを扱うための技術です。2010年に仕様が策定されており、既に多くのブラウザで実装されている技術です。ブラウザ上でどの技術が使えるかを測定するCan I Useでの結果を見ても、92%以上のブラウザがサポートしていて、広く使える状態にあると言っていいでしょう。

ただこれは、WebGL 1.0の話です。WebGL 2.0はまだまだですね。ChromeとFirefoxだけが対応しているという状態で、特にiOSで使えないのが厳しいです。「ブラウザを限定すれば使える」という状態です。

白石: WebGL 1.0と2.0って何が違うんですか？…ぼく、3Dプログラミングが全然わかってないので、理解できるか自信がないのですが(笑)

石井: 浮動小数点テクスチャなどがWebGL 2.0の主な機能ですが、3Dプログラミングの知識がない人に向けて話すのはちょっと難しいですね(笑) とりあえず、ライブラリ作者なら知っておくべきですが、ライブラリのユーザーはそれほど気にする必要はないかと思います。ライブラリ作者も、WebGL 2.0が使えない環境では1.0にフォールバックするように実装していることが多いでしょうし。

（筆者注: WebGL 2.0の強化点についてはQiitaで良い記事を見つけました。ぼくにはちんぷんかんぷんですが…）

白石: なるほど、あまり気にしなくていいと(笑) 安心しました。

石井: 3Dをご存じない方にとって大事なのは、そもそもWebGLとはGPUを扱うための技術だということをしっかり理解しておくことです。

CPUは、CPUは複雑な処理を逐次的に処理することを得意としています。CPUの場合はコアの数が4とか8とかに限られていることが普通です。

一方GPUの場合は、「異なるデータに対して同じ処理を施す」のを並列で実行するのに特化しています。なのでGPUは、コアの数が1,000を超えることも普通です。こうした特徴を持つGPUだからこそ、大量の頂点を移動する処理など、3Dプログラミングに必要とされる「単純な処理の並列実行」に向いているんです。

白石: こうした特徴は、最近だと機械学習の分野とかにも活かされているんですよね。単純なベクトル計算とかが多いから。

石井: そうです。で、WebGLってそもそもOpenGL（※）と同じなので、CGの取り扱いに関しては共通している部分がほとんどです。ただ、置かれている環境は、OpenGLネイティブのゲームやアプリとは随分違う。

一番違う点は、WebGLは必要とされるリソースが全部Web上にあって、ダウンロードが必要という点です。モデルデータの読み込みに時間がかかるんですよね。

だから今まではゲームなど、「読み込みに時間がかかりそうだ」とユーザーも了解しているコンテンツが多かったんです。でも、本来使うデータをしっかり選べば短いロード時間で使えるものも多いんですよ。シェーダーアートとか。

※OpenGL（オープンジーエル、Open Graphics Library）は、クロノス・グループ (英: Khronos Group) が策定している、グラフィックスハードウェア向けの2次元/3次元コンピュータグラフィックスAPIである（Wikipediaより引用）

白石: 確かに、WebGLでできたゲームとか、読み込みに数分待たされるものもありましたね。

石井: はい。モデルデータが大きいと、それだけダウンロードやデータ読み込みに時間がかかってしまう。なので、そうしたWebGLの問題を解決すべく、CGの世界にも進化が起きようとしているんです。

ランタイム向け3Dデータフォーマット「glTF」

白石: 具体的にはどのような進化ですか？

石井: 一つはglTF (GL Transmission Format) と言って、汎用的な3Dアセットフォーマットです。ツールに依存しない軽量フォーマットとして、Khronosが普及を進めています。

glTF

白石: ツールに依存しない、というのはどういう意味ですか？

石井: 以前WebGL上でモデルファイルを扱う際には、MayaやBlenderといったツールのファイルをそのまま読み込んで利用することが一般的でした。これは言わば、「Photoshopのpsdファイルはあるけど、jpgやpngなどの汎用的な画像フォーマットがない」という状況です。

白石: そんな状況だったんですね…知りませんでした。ゲームやアプリとしてひとまとめにパッケージングしてしまうから、汎用フォーマットが必要とされなかったんでしょうか。

石井: 概ねそういうところです。そういう状況を変えようと、COLLADAという汎用フォーマットがKhronosによって提案され、一定程度普及はしています。

ただ、COLLADAファイルはCG編集ツール間でデータをやり取りするためのフォーマットとして設計されているため、WebGLアプリケーションが読み込んで利用するには、編集用のパラメーターなど不要な部分も多いんです。また、XML形式だというのも、ファイルサイズや解析速度の点で不利になります。

glTFは、COLLADAファイルから編集用のパラメータを取り除いて、JSON形式にしたものと言ってほぼ差し支えありません。

白石: なるほど。ただ、そういうフォーマットって、普及させるのがなかなか大変な気もしますが、どうなんでしょう？

石井: glTFは既に様々なライブラリにもサポートされていますし、普及は中々順調と言えると思います（参考: glTFのライブラリサポート状況）。

glTFの面白いところは、大手ベンダーの採用意欲が高いというところです。MicrosoftやAutodeskという大手ベンダーが乗っかってきているんですよ。 Khronos自身WebGLの仕様策定元なので、この分野で発言力が強いこともあります。また、最近ではApple WatchのページでglTFが使われてたりもします。

白石: Apple Watchの公式サイトでもですか！それはかなりの人がアクセスしたでしょうね。確かに、これ単なる画像じゃない。スクロールと共に水滴が別々の動きをしてる…！（重いけど）

Apple Watch Series 3のサイト

石井: glTFは「オーディオにおけるMP3, ビデオにおけるH.264、画像におけるJPEG」といったように、「3DといえばglTF」となることを目指しているとのことで、普及にかけるKhronosの意気込みも並々ならぬものがあります。

頂点データ専用の圧縮形式「draco」

石井: もう一つ注目の技術としては、Googleがオープンソースで開発しているdracoという圧縮形式です。頂点データを効率よく圧縮する技術で、元々の頂点データのサイズに比べて4倍から16倍の圧縮率を誇ります。

白石: 先ほどのglTFにしか使えないんですか？

石井: いえ、汎用的なポリゴンデータ形式（.ply）に対応しているので、元のファイルフォーマットは選びません。

白石: ブラウザによる対応も必要なんですか？

石井: いえ、ブラウザがネイティブ対応するというものでもないんです。dracoによって圧縮されたポリゴンデータは、JavaScriptでデコードすることができます。

白石: なるほど、アプリケーションが自前で圧縮データを展開するんですね。でもそれだと、デコード処理にかかる時間がちょっと心配です。

石井: WebAssemblyでできたデコーダーもあるし、Web Workersで展開すればUI処理を阻害することもないので、そこはあまり問題ないと思いますよ。使うブラウザを選ぶということもありませんし、Three.jsのようなライブラリに任せてしまえば、アプリケーションはデコードについて意識する必要もありません。

白石: ほかには、Webだと画像のサイズを結構気にしたりしますが、CGの世界ではどうなんでしょう？

石井: CGだと、テクスチャ画像のサイズを削減するという話になりますね。ただ、単に画像のファイルサイズを小さくするだけでは片手落ちなんです。いくら元画像のファイルサイズを小さくしても、GPUに乗るときにはフルサイズにデコードされてしまうので、メモリ使用量などにすごく影響するんですね。

なので、GPUが直接扱えるテクスチャ圧縮形式というものがありまして、それらを利用すると、GPU上でも圧縮した状態で画像を扱うことができます。DirectXだとS3TCという形式、iOSだとPowerVR Texture Compression (PVRTC) というように、ベンダーごとに異なってくるんですが。

白石: ベンダーごとに異なるんだと、取り扱いが面倒ですね。

石井: はい、なのでこういうフォーマット変換はWebpackなどで自動化されるべきだと思います。このように、今まではエンジンが自動的に行なってきたことも、WebGLの場合はプログラマーが自分で意識しなくてはなりません。

白石: まとめると、3DをWeb上で行うためにはいろいろな課題があって、それが徐々に解決されつつあるということですね。汎用モデルフォーマットが普及しつつあり、頂点データの圧縮ツールも登場した。そして、テクスチャ圧縮も自動化されるだろうと。

石井: そうです。そもそもWebは、多様なデバイスがネットワークで繋がれていることが前提です。そういうユビキタスな環境で、3Dが自由に表現できる世界に向けて、今まさに具体的で重要な進化が起こっているということです。

WebGLの未来

白石: こうした動きを踏まえて、WebGLの未来はどうなると思いますか？

石井: 今のコンピューターの世界は、やはり2Dを前提としているのは間違いありません。3Dが利用されるシーンは、ゲームなど、コンピューティングのごく一部に限られていました。マテリアルデザインなども、3Dの要素をうまく取り入れてはいますが、前提は2Dです。

ただ、今、GoogleやApple、Microsoftなどの強力なベンダーたちが、こぞってARやMRに力を入れています。このまま進めば、映画館や不動産屋さんとか、あらゆるお店の軒先にARのオブジェクトが浮いている…という世界は普通に来るんじゃないかと思っているんです。3Dがより身近になる世界です。

ただ、そういうのを見るために、わざわざアプリをインストールするのは面倒ですよね。近い将来、そういう面倒くささが、AR/MRの普及を妨げる大きな一因になってくるんじゃないかと思うんです。

しかしWebGLがそういう状況を打開できるんじゃないか、と期待しています。WebGLはWebブラウザさえあれば動きます。PCでもスマホでも動く。アプリのインストールが必要ないし、しかも安全なサンドボックス上で動きます。

白石: 確かに！もしかすると、ビーコン技術との組み合わせとか（※）で、アプリのインストールを必要とせず、気軽にバンバンARコンテンツを見るような時代が来るかもしれませんね。

※Webとビーコン技術との組み合わせとして、Eddystoneという仕組みがGoogleから考案されている

石井: 実際、GoogleがWebARという仕様を作ったりもしていますし、ARには各社力を入れているので、Webでも早晩ARが使えるようになるだろうと思います。

白石: でも実際、要素技術が揃っているだけでは世の中変わらない…という現実もあるかと思います。WebGLも、実際には随分前から使えるようになっていたわけですし。こういう「要素技術が揃っているだけでは越えられない壁」は、どうやったら超えられると思いますか？

石井: 難しい問題ですが、一つは3Dコンテンツの制作コストが高いというのも、普及を妨げる要因にはなるのかなと思います。ただそれは、「人が作る」ことを前提とするからコストが高くつくんだと思うんですよね。

そういう点では、2Dに関しては既にPaintsChainer（AI技術を使い、線画を自動で着色するサービス）やMakeGirlsMoe（AIで自動的に萌えキャラを作成するサービス）のようなサービスが出てきています。同様に、自動で3Dコンテンツを生成するようなサービスも近いうちに登場して、コンテンツの制作コストが劇的に下がるんじゃないでしょうか。

白石: AIサービスでコンテンツの制作コストが激減するというのは面白い発想ですね〜

石井: Adobe Senseiも最近話題になっていますし、デザインの一部をAIに任せるというトレンドが来つつあるのは確実かなと思いますね。

Grimoire.jsは、WebGLをWebエンジニアにとっての「筆」にする

白石: では最後に、開発を進めていらっしゃるGrimoire.jsについても、簡単にご紹介頂けますでしょうか？Three.jsなどのライブラリとは何が違うんでしょう？

石井: Grimoire.jsはWeb開発の中でWebGLを扱うためのフレームワークです。Three.jsやBabylon.jsは、発想がCG中心なんですよね。画面全体をCGで構築するようなコンテンツにはいいのですが、Webコンテンツと混在させて、相互がやり取りするようなプログラムを作るには適していないんです。CGとWebには大きな隔たりがある。それに決められた構造を両者に与えて橋をかける必要があった。

この隔たりは、プログラミングスタイルにも大きく表れてきます。

CGの場合は、フレームごとにグラフィックを変更させていく、いわばフレーム指向です。
一方でWebの場合は、イベントに応じて処理を行うのが普通ですよね。いわばイベント指向です。
こうした隔たりがあるせいで、CG側とWeb側が、お互いにどうデータを受け渡しすればいいか、正解がないというのが今の状況です。

Grimoire.jsは、CG側とWeb側の、2つのAPIを提供することで、両者がシームレスに同居するようなアプリケーションを簡単に作ることができるように設計されています。

白石: 具体的にはどのようなコードになるんでしょう？

石井: Grimoire.jsは、GOMLという専用のマークアップ言語でCGを記述することができます。そして、GOMLの要素を変更することで、簡単にCGを変更できるんです。例えば、立方体にテクスチャを貼り付けて、自動的に回転するようなCGは以下のようなマークアップで簡単に実現できます。

そして例えば、マウスが重なった時だけこの立方体が2倍の大きさになる…という処理は、以下のようなJavaScriptで実現できます。

gr(function() {
  var mesh = gr('#simple .canvas')('mesh')
  mesh.on('mouseenter', function () {
    mesh.setAttribute('scale', '2.0')
  })
  mesh.on('mouseleave', function () {
    mesh.setAttribute('scale', '1.0')
  })
})

白石: おお、簡単ですね！これならWebエンジニアでも簡単に扱えそうです。

石井: はい、そうなんです。イベントを受けてパラメーターを書き換えるという流れは、今のWebアプリケーションフレームワークなどの潮流を見れば古い感じを受けるかもしれませんが、結局のところこれだけあればいくらでもラップすることができます。そのようなモダンなWeb開発の環境でもシームレスに環境を選ばず導入できるんです。Grimoire.jsの目標は「WebGLを、Webエンジニアにとっての『筆』にする」ことなんです。

一方で、CG側にはUnityに近いようなインターフェースのAPIが提供されています。TypeScriptで記述できるビルド環境が提供されているので、Webに疎いCGサイドでもすぐにWebエンジニアの使う筆を作ることができます。再利用可能で、最終的なパラメーター調整などをWeb側が簡単に行えるわけです。実際、そのためにChrome拡張でWebGLの空間をそのまま操作できるインスペクタも提供しています。

Grimoire.js Inspector

WebエンジニアにとってCGをより身近にすること、そしてCGがより一般的な世界にすることを目指しています。

白石: とても期待しています！本日はWebGLの基本的な事柄からGrimoire.jsまで、いろいろ教えていただいてありがとうございました。

石井: 1.0リリースを年内に行いたいと思っています。興味がある方がいたら公式サイトから開発チームのSlackなどに入ると新しい様々な情報が拾えるかと思います。またいくつかの例も載っているのでご覧いただけると幸いです。

（撮影：刑部友康写真提供：html5j HTML5 Conference 2017事務局）

WebAssemblyの基礎から最新動向まで、@chikoskiに聞いてきた！

白石俊平 — Wed, 25 Oct 2017 01:00:17 +0000

連載： HTML5 Conference 2017特集 (9)

こんにちは、編集長の白石です。

この記事は、9月24日に開催されたHTML5 Conference 2017に登壇したエキスパートに、お話されたセッションのトピックを中心に、様々なお話を伺おうというものです。セッションの内容をより深く理解する手助けになるだけでなく、本記事単体でも面白く読んでいただけることを目指しています。

今回お話を伺ったのは、WebAssemblyコミュニティを率いてらっしゃる清水智公さん（@chikoski）です。清水さんのセッションは「WebAssembly MVPまとめと、今の議論の内容からいくつか」でした。

※スライド資料はこちらで公開されています。

WebAssemblyとは何か？

白石: 今日はよろしくお願いします。まずは自己紹介をお願いできますか？

清水: WebAssemblyのコミュニティを運営している清水です。@ikkoさんと一緒に、「emcscripten night !!」というイベントを四半期に一回くらいのペースで開催しています。

白石: では早速ですが、WebAssembly（WASM）とは何なんでしょうか？

清水: 一言で言うと、Webブラウザ上で実行できる、ポータブルなバイナリ形式です。現在、「MVP（Minimul Viable Product: 最小限有用な機能を備えたプロダクト）」の実装が完了し、ほぼすべてのメジャーブラウザで利用できるという状態です。

白石: ポータブルというと、ブラウザにも、OSにも、デバイスにも依存しないということですね。

清水: その通りです。Javaをご存じの方であれば、classファイル形式を思い浮かべていただくと理解は早いと思います。

白石: なるほど。なぜそうしたバイナリ形式が必要とされたんでしょうか？

清水: これまでWebページで動作するプログラミング言語といえば当然JavaScriptだったわけですが、JavaScriptは遅いという問題がありました。asm.jsでスピードの面は大分改善されたのですが、今度はサイズが大きくなってしまうという問題も生まれました。それで早く動かせて、サイズもasm.jsよりは小さいものとして、WebAssemblyが生まれたんです。

遅さの原因の一つは、JavaScriptは変数の型が動的だということです。例えばJavaScriptで足し算を行うコードがあるとしたら、いろんな可能性を考慮しなくちゃいけないんですよね。

値が整数かもしれないし、浮動小数点かもしれない。文字列かもしれないし、valueOf()を持つオブジェクトかもしれない。こういう可能性を踏まえると、単なる足し算といえども最適化は容易じゃないわけです。

ですがWebAssemblyの場合は、コンパイル時に変数の型が決まるので、最適化が容易なんです。今では、ネイティブに比べて2/3くらいの速度というところまで改善されています。

白石: なるほど。サイズが小さくなるという点についてはいかがでしょう。

清水: JavaScriptは当然テキスト形式ですが、テキストってやはり冗長なんですよね。例えば、とあるゲームのコードを全部JavaScriptに変換したところ、40メガバイトを超えるサイズになってしまったことがあります。

これでは、JavaScriptのソースコードをダウンロードするだけでかなりの時間がかかってしまうし、実行にかかるコストも半端ではありません。

WebAssemblyは、サイズを小さくすることを最初から念頭に置いたバイナリ形式ですので、確実にサイズは縮まります。元のJavaScriptファイルにもよりますが、ミニファイして圧縮した場合に比べても小さくなるのは確実。場合によっては半分以下のサイズになることもあります。

白石: それほど素晴らしいのであれば、将来的にはJavaScriptを置き換えていくような存在になるのでしょうか？

清水: いえ、WASMはJavaScriptの置き換えは目指しておらず、あくまで補完する存在という位置付けです。例えば、WASMはDOMに直接アクセスすることができませんからね。

WASMへの対応状況

白石: では改めて、ブラウザのWASMへの対応状況を教えていただけますか？

清水: 先ほども申し上げたとおり、ほとんどのメジャーブラウザで使えます（参考: Can I Use）。Safariが11から対応するようになったのは大きいですね。iOSでも使えるようになったということなので。 Edgeも先日のCreator’s updateでデフォルトでWebAssemblyを利用できるようになりました。また、Node.jsでもWebAssemblyは動作します。

白石: Nodeでも動くんですか！知りませんでした。WASMにコンパイル可能な言語には、どのようなものがありますか？

清水: 様々なコンパイラで利用されている、LLVMという中間言語があるんですが、LLVMに変換される言語だったらだいたい大丈夫です。Emscriptenというツールを使うと、LLVMからWASMに変換できるのです。

LLVMにコンパイルできる言語というと、C/C++/Objective-Cなどが挙げられます。また、RustもWebAssemblyに対応しています。

あとUnity限定になってしまうのですが、C#にも対応しています。他にはAssemblyScriptといって、WebAssemblyを出力できるTypeScriptのサブセット言語も存在します。

白石: C#やTypeScriptもあるんですね！WebAssemblyにはガベージコレクタがないと聞いていたので、それらの言語が使えるというのは驚きです。

ちなみに、WASMを出力できる言語や動作する環境がたくさんあるのはわかったのですが、実際どれくらい実用的なんでしょうか？

清水: 今は、ざっくり言ってC言語のコードをコンパイルして動かす能力は備えているというところです。 C++への対応は完全じゃありません。C++の例外をまだうまく扱えないんですよね。

白石: Cと言えば、メモリを直接操作するようなコードを直接書けると思うのですが、それがWebAssembly上だとどのように動作するのでしょうか？

清水: WebAssemblyのコードには専用のメモリ空間が割り当てられるんです。C言語におけるメモリ操作などは、そのメモリ空間に対して行われます。そのメモリ空間は、JavaScriptコードからもArrayBufferオブジェクトとして参照できます。

ちなみに、WebAssemblyの仕様上は64ビットのメモリ空間を扱えるのですが、現在の実装上では32ビットに制限されていますね。

WASMを使う

白石: WASMを使うコードはどういうふうになりますか？

清水: まず、WASMのバイナリが必要です。拡張子は.wasmです。そのファイルをfetch()でもXMLHttpRequestでも何でもいいので読み込んで、バイナリコードをArrayBuffer化し、WebAssembly.instanciate()というメソッドに渡します。

すると、WebAssemblyコードの実行結果がPromiseの戻り値として返ってくるので、そこにエクスポートされている関数をJavaScript側から呼び出すことが可能です。

// MDNのサンプルを引用
// https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/WebAssembly/instantiate

// WASMファイルを読み込み
fetch('sample.wasm').then(response =>
  // ArrayBuffer化
  response.arrayBuffer()
).then(bytes =>
  // インスタンスを生成
  WebAssembly.instantiate(bytes)
).then(result =>
  // 生成されたインスタンスのエキスポートされた関数を呼び出し
  result.instance.exports.exported_func()
);

白石: なるほど、使うのはそれほど難しくなさそうですね。JavaScriptからシームレスに関数の呼び出しを行えるのが素晴らしい。

清水: はい、それにWASMのコード内から、外部JavaScriptのコードを呼び出すことも簡単にできます。WebAssembly.instantiate()の第二引数で、WASMコードがインポートするメンバーを指定できるんです。

// MDNのサンプルを引用
// https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/WebAssembly/instantiate

// WASMがインポートして使用するオブジェクト
var importObject = {
  imports: {
    imported_func: function(arg) {
      console.log(arg);
    }
  }
};
fetch('simple.wasm').then(response =>
  response.arrayBuffer()
).then(bytes =>
  // インポートするオブジェクトを指定
  WebAssembly.instantiate(bytes, importObject)
).then(result =>
  result.instance.exports.exported_func()
);

白石: なるほど、ダイナミックリンクが可能なんですね。WASMがJavaScriptをどう補完するのか、よくわかりました。

WASMはどう使われていくか

白石: WASMが登場したことで、具体的に何が変わっていくと思いますか？

清水: まずはやはり、C/C++で書かれたコードをWASMに変換して使うのが一番最初に思いつくユースケースです。コンシューマー向けのサービスでいうと、やはりゲーム系がすぐに思いつきますね。

例えば新たなゲームタイトルをスマホ向けにネイティブで開発しつつ、WASMでコンパイルしてWeb版も同時に開発するということができます。 UnityはWebAssemblyに対応しているので、そういう開発を行うのは比較的簡単です。

白石: なるほど、スマホ版だけじゃなくてWeb版も同時に開発して公開できれば、ユーザーへのリーチが拡大しそうですね。

清水: 実際、とあるベンダーさんが、Android用のゲームをWebブラウザでも動作するようにしたところ、ユーザー数はかなり増えたと聞いています。

白石: では、まずはネイティブとWebのクロスプラットフォーム開発でWASMは活躍しそうだと。 他にはC言語で書かれた資産とかもWeb上で使えそうですよね。例えばgzipのライブラリとか。

清水: そう、圧縮や暗号系、画像処理などの、Cで書かれたライブラリをWeb上に移植するのにも向いていますね。 CPUに依存する処理を高速化するのには、すごく向いています。

Cで書かれたコードの移植といえば、luaもWASMにコンパイルできたそうです。

白石: おお、言語処理系まで！そうか、よく考えたら、現在のWASMにガベージコレクタがなくとも、ガベージコレクタを備えた処理系ごとコンパイルしちゃえばいいんですね。

WASMのこれから

清水: はい、ちょうどガベージコレクタの話が出たので、WASMのこれからという話をしたいと思います。WASMの次のターゲットとして、ガベージコレクタが提案されています。

こちらはおそらく、「ガベージコレクタを使いたい場合は使える」という設計になると予想されています。

白石: ガベージコレクタが使えるようになったら、WASMをターゲットにした言語処理系とかが作りやすくなりそうですね。WASMで提案されている仕様は他にもありますか？

清水: まず、スレッドを使えるようにするという提案があります。やはり、pthread (POSIXスレッド: C言語で使用できるマルチスレッドAPI)を使いたいという要望が多いんですね。複数のWeb Workers（Web環境でマルチスレッディングが可能なAPI）で共有できる Shared ArrayBuffer は既に利用可能ですが、複数のスレッドを待ち合わせるwaitやwakeと言った命令も使えるようにすることを見据えています。

他には、先ほども申し上げたように例外を扱えるようにして、C++コードもWASMに正しくコンパイルできるようにすること。WASMのモジュールとECMA Scriptモジュールの整合性を取る…と言った提案も行われています。

白石: WASMの未来、楽しみですねー。最後にお聞きしたいのですが、現時点でWASMを試すのにおすすめの言語はありますか？C/C++で書くのはなかなかしんどいなあ、と…

清水: HTML5 Experts.jpの読者に向けてという話であれば、TypeScript（のサブセット）をWASMにコンパイルできる、AssemblyScriptを使うのはおすすめです。Web技術者が軽く試してみるという用途には最適だと思います。

白石: 本日は、WebAssemblyについて基礎から最新情報まで教えていただき、ありがとうございました。

Vue.js製フレームワークNuxt.jsではじめるUniversalアプリケーション開発

花谷拓磨 — Fri, 13 Oct 2017 01:49:45 +0000

Vue.jsでUniversalなSPAを開発できるフレームワークであるNuxt.jsのバージョン 1.0のリリースがいよいよ近づいてきました。

本稿では、シングルページアプリケーション（以下 SPA）開発によって生じた問題を解決するために生まれたサーバーサイドレンダリング（以下 SSR）を中心に、Vue.jsでの開発を強力にサポートするNuxtについて、その魅力と基本的な使い方をご紹介いたします。

Nuxt.jsとは？

Nuxt.js（ナクストと読みます）はReact.jsベースのSSR用フレームワークであるNext.jsに触発されて作成された、Vue.jsベースのフレームワークです。

特にUIの描画サポート に主眼をおき、SSRをはじめとした様々なサポートを行ってくれるものとなります。

https://nuxtjs.org/

Nuxt.jsでできること

それではそのNuxt.jsではどのようなことができるのでしょうか。

現在挙げられている主な機能一覧としては以下のようなものがあります。
（現在準備中のv1.0向け日本語訳プロジェクトから抜粋。私も一部関わっております）

Vueファイルで記述できること

コードを自動的に分割すること

サーバーサイドレンダリング

非同期データをハンドリングするパワフルなルーティング

静的ファイルの配信

ES6/ES7のトランスパイレーション

JSとCSSのバンドル及びミニファイ

Head要素の管理

開発モードにおけるホットリローディング

SASS, LESS, Stylus などのプリプロセッサのサポート

HTTP/2 push headers ready

モジュール構造で拡張できること

こうして見てみると、Nuxt.jsが提供する機能は 「SSR 基盤の提供」と「コードを書きやすい環境を提供するもの」 、そして「拡張性の高い構造を提供するもの」 の3つと考えることができます。

SSR基盤としての優秀さ

Vue.jsの2系からはコアでSSRのシステムを内蔵しており、単体でもSSRを行うことは可能ですが、より円滑に、かつ柔軟なシステムをNuxt.jsでは提供しています。

単純なレンダリングだけの場合はVue.jsのものを利用しても簡単におこなうことができますが、Nuxt.jsではそれに加えルールに基づいた自動的なルーティングやプリコンパイル、

タグの編集などが可能となっており、より効率的なSSR基盤の構築が可能となっています。

モダンなVue.jsによる開発環境の提供

Nuxt.jsでは、vue-loaderベースでのVue.jsでの標準的なコーディング環境や、画像などのアセットのパスの解決、そしてSassなどのCSSプリプロセッサの対応など、webpackなどのビルドツールの設定を必要とするものが一通りサポートされています。

その上で、それらの基本的な構成をまとめたボイラープレートをnuxt-community/starter-templateとしてNuxt.jsコミュニティが公式で提供しており、webpackなどのモジュールバンドラやbabelなどのビルドシステムに精通していない人でも簡単にモダンな環境を構築することが可能となっています。

また、これらのテンプレートはVue.jsコミュニティ公式のスキャフォールディングツールである

vue-cli

を利用してセットアップが可能となっており、すぐに開発をはじめることが可能です。

ミドルウェアやasyncDataなどの拡張システムの提供

また、Nuxt.jsでは、ミドルウェアやasyncDataという構造・システムを利用することで、SSR結果に非同期処理（例えばAPIからのデータフェッチ）の結果を出力・その後SPA側からデータストアとして参照できるシステムがあります。

これを利用することにより、記事データを取得した上でOGPとして出力を行うことや、i18n処理の結果をHTMLとして流すなど、様々なことができるようになります。

Nuxt.jsを利用すべきシーン

メディアやSNS 、求人サイトなどをSPAとして立ち上げる場合・運用している場合

SPAとして立ち上げるサイトやWebサービスの中では、SEOやOGP、Twitter Cardを重視すべきものというのは非常に多く存在します。

メディアサイトなどであれば、そもそもWordPressなどで運用するほうが筋が良い場合も多いでしょうが、SNSや求人サイトの場合は、SPAのほうが都合が良い場合も存在します。

SNSでの事例でいえば、今のTwitter Lite（モバイル版）ではReactが使われていたり、求人サービスであるSCOUTERなどはサービス全体をVue.jsのSPAとして構築されており、個々の投稿やアカウントなどの情報をSSRしたいであろうサービスが SPA 化されていることは多くなってきました。

そういった場合のSEO、OGP生成エンジンとして、比較的一般的なディレクトリ構成がなされているNuxt.jsを採用する、Nuxt.jsへと移行するというということは選択肢として十分現実的なものです。

技術系ドキュメントの運営

技術ドキュメントの運用にも有効活用が可能です。

Nuxt.jsには、独自の機能としてnuxt generateが存在しており、このコマンドを利用すると、Nuxt.jsで作られたものを全て静的サイトとして、ルーティングをそのままに書き出すことが可能となります。

Markdownで原稿は管理を行い、Vue.jsの強力なコンポーネントシステムのもと、デザインを効率的に管理する。ということが可能です。Nuxt.jsの公式ドキュメントは、この手法にて管理されています。

https://nuxtjs.org/

いわゆる一般的なホームページ制作

驚くかもしれませんが、一般的なホームページ制作においてもNuxt.jsは大きく貢献してくれます。

Vue.jsのコンポーネントでは

Scoped CSS

を利用することが可能となっており、CSSの影響範囲についての考慮を最小限できるためコーディングのスピード化に貢献するほか、ライブリロードなどの効率的な開発基盤が既に整っているからです。

また、本稿では詳しくは紹介しませんが、Nuxt.jsはプログラムから呼び出すことも可能であるため、お問い合わせだけをExpress.jsで受けるということも実現可能です。

実際にPush7というサービスのWebサイトはi18n化をmiddlewareで、メール受け付けをExpressで実装しました。

https://push7.jp/

Nuxt.jsをはじめる

それではいよいよNuxt.jsを利用して実際にアプリケーションを作成してみましょう。

まずはサンプルプロジェクトを作成した後、実際にAPIと連携するWebサイトを構築してみます。

プロジェクトのセットアップと実行

プロジェクトの初期化にはvue-cliを利用しましょう。ターミナル上で以下を実行してください。

$ npm install -g vue-cli # 既に vue-cli を導入されているかたについては不要です
$ vue init nuxt-community/starter-template nuxt_sample

これを行うことで実行したディレクトリに新たにnuxt_sampleという名前でプロジェクトが作成されます。

これで一通りのファイルはセットアップされていますので、そのまま依存関係をインストールしてサーバーを立ち上げてみます。

パッケージ管理については、Nuxt.js自体がYarnで管理されているため、個人的にはYarnを用いることを推奨します。

$ cd nuxt_sample
$ yarn
$ yarn dev

実行した段階でプリコンパイルが実行され、完了次第 http://localhost:3000/ にてアクセスが可能であることが確認できるようになっています。実際にアクセスしてみます。

このように表示された時点で成功です。

ページのソースコードを見ると、きちんとSSRされて結果が出力されていることがわかります。

APIからデータを取得してSSRするページを作成する

基本的なサーバーの起動はここまでで完了したので、ここからはルーティングの追加と非同期データの取得を行っていきます。

ここでは誰でも利用できるPublicなAPIとして、GitHubのユーザー情報を参照する API を利用し、ユーザー情報を表示してみます。要件としては、以下を満たすものの開発とします。

https://developer.github.com/v3/ を利用したデータ取得を行う
```
/users/:id
```
形式でそれぞれのユーザーにアクセスする
ユーザー情報からIDと名前を取得し、アイコン画像と共に表示する

ルーティングを追加する

まずはルーティングを追加してみます。

Nuxt.jsにはファイルに応じたルーティングの自動生成機能がありますので、これを有効活用して作成します。

今作ったnuxt_sampleのプロジェクトルート内の

pages/

ディレクトリ内にusersディレクトリを作成し、さらにその中に _id.vueファイルを作成します。

内容については、index.vueの中身をコピーしておくと良いでしょう。

完成したディレクトリ構成はこのようになります。

このようにファイルを配置することで、Nuxt.jsがルーティングを解釈し、

/users/:id

のリクエストについては全て_id.vue を参照するようになります。

さらに、アクセス時にURLパラメータのオブジェクト内にidというキー名で格納されます。

これを例えば_nickname.vueなどとした場合は、idの代わりにnicknameというキーで保存されます。

これでひとまずルーティングの作成は完了です。

ページ内でHTTPリクエストを行い、結果を取得する

次は_id.vueの中でGitHubからデータをフェッチしてみます。

まずはHTTPリクエストのためにaxiosをインストールします。

$ yarn add axios

その上で、_id.vueを以下のように記述します。

ここでポイントとなるのはasyncDataの記述です。

通常のVue.jsでは、データの保持について、

data(){}

形式で関数を定義し、その戻り値をデータとして利用しますが、これを

asyncData(){}

に置き換えることで、SSR時に非同期のデータを取得した上で、SSRに流し込むことが可能となります。

また、Nuxt.jsではデフォルトでasync/awaitの変換用のbabel-presetも導入されていますので、モダンな記法でこのように取得することが可能となっております。

実際に表示をみてみる

ここまで完了した段階で、実際に表示を見てみましょう。

現在サーバーが立ち上がっているなら自動で読み込まれているためそのまま

/users/potato4d

を。

もし一度落としているなら、再度

yarn dev

を行った上で

/users/potato4d

にアクセスしてみましょう。

このように表示されると成功です。

ソースコードを見ると、正しくSSRされた結果が返ってきていることがわかります。

このように、asyncDataと、axiosなどのHTTPライブラリを組み合わせることによって、Web APIからの取得結果をSSRに流すことが可能となります。

これを用いることにより、例えばサービス内の投稿について、ツイートされたときにコンテンツを表示する。Twitter CardやOGPなどを正しく表示する。ということが可能となります。

最後に、このサンプルについては私のGitHub上に掲載しておりますので、お手元にすぐNuxt.jsを試す環境がない場合は適宜ご参照ください。

https://github.com/potato4d/nuxt_html5expertsjp

おわりに

ここまででNuxt.jsの基本とできること・活躍しやすいシーンをご紹介した後に、簡単なサンプルアプリケーションを作るところまでを行ってみました。

実案件で投入する際は、新規でないとディレクトリやビルドシステムの移行コストがそれなりに存在しますが、新規においては効率的な開発にも大きく貢献し、将来的なSSR要望にも先んじて対応を行うことができます。

基本的にSPAの後からのSSR対応というものは非常にコストがかかるものでもありますので、これからのSPA開発においては、Nuxt.jsの存在は、開発効率化ツールとしても、また、SSRだけではない統合開発フレームワークとしても無視できないものになってくると考えております。

Nuxt.js単体がフロントエンド開発のフレームワークとして一定以上の存在意義をもつ未来や、ほかのNode.js製のフレームワークと組み合わせてのレンダリング用フレームワークとして利用される未来も十分にあるでしょう。

近々1.0のリリースが行われることで、rcにて大量にあったBreaking Changesについてもひとまずは収まることが予想されますし、日本語ドキュメントの1.0追従も盛んに行われております。

もし活躍できるシチュエーションに遭遇した時は、Nuxt.jsを是非利用してみると良いでしょう。

参考資料

本稿の執筆にあたって参照した情報ソースとなります。

Nuxt.js 公式ページ（英語）
- https://nuxtjs.org/
v1.0 時代の機能一覧日本語訳
- https://gitlocalize.com/repo/100/ja/en/guide/index.md
本稿で使用したスターターテンプレート
- https://github.com/nuxt-community/starter-template
本稿で使用したスキャフォールディングツール
- https://github.com/vuejs/vue-cli
Nuxt.js 上での開発における babel の対応文法のソース（設定プリセット）
- https://github.com/vuejs/babel-preset-vue-app

ニュースタブ新設で月間アクティブユーザー数が5900万人を突破した「LINE NEWS」の開発技術と体制を聞いてきた！

馬場美由紀 — Fri, 22 Sep 2017 01:00:29 +0000

2017年2月に新設されたニュースタブによって、ユーザー層をより広く拡大し、2017年3月時点で月間アクティブユーザー数5900万人を突破した「LINE NEWS」。そのニュースタブは、WebViewで実装されているのをご存じでしたか？

LINEのニュースタブをReact.jsで開発しているフロントエンド、JavaとPerlで開発しているサーバーサイドのエンジニアの方々に、どんな開発技術や体制で開発しているのか、HTML5 Experts.jp白石俊平編集長が直撃インタビューしてきました！

今回お話を聞いた「LINE NEWS」開発チームの皆さん

LINE株式会社前澤春樹さん
Javaのサーバーサイド担当。200以上の媒体社様向け管理画面のコンテンツ入稿システム開発や、公式アカウントから発信されるメッセージ配信システムが主な担当。

LINE株式会社森藤賢司さん
Perlで作られている一般ユーザーから見えるニュースタブ、記事ページのバックエンドや社内向けの管理画面を担当。

LINE株式会社大槻友諒さん
フロントエンドエンジニア。WebViewでつくられているニュースタブの実装を担当している。React.jsなどの最新技術に触れることも多い。

LINE株式会社富田梓さん
マークアップエンジニア。デザイナーの作成したPSDをもとにしたCSSの設計と実装を行う。ニュースタブの他、PC/SPのWeb、キャンペーンページなどニュース関連全般を担当。

なぜ、ニュースタブはWebViewなの？

白石：今日は主にニュースタブにフォーカスしてお話を聞いていきますね。LINEのニュースタブは、なぜWebViewを使ったのでしょうか。

大槻：もともと記事ページはWebViewで作っていました。ニュースタブを作ろうという話になったときに、記事ページと同じ技術で作るほうが開発スピードも早いし、やりやすい。バージョンアップなども、そろえたほうがリリースしやすいということでWebViewで作ることになりました。

白石：じゃあ、ニュースタブ以外はネイティブでできているんですね。

大槻：そうです。トークやタイムラインなど、メインの機能はネイティブで実装されています。並んでるタブの中だと、ニュースタブだけがWebViewです。

白石：WebViewとネイティブといった複数の技術を混ぜるのって、大変だったんじゃないでしょうか。

大槻：ネイティブとWebView間でデータやイベントをやり取りする必要があって、そのための仕組みをアプリエンジニアと協力して実現しました。ユーザーにはLINEアプリの一部として見えるので、挙動やパフォーマンスに違和感が出ないようにするのが大変でした。

白石：WebViewだと、読み込みや表示が遅かったりしません？

大槻：いえ、結果的にそこまで遅いということはなかったです。Webだからの限界はありましたけど、WebViewだから特別つらいことはありませんでした。

LINEバイトやLINEギフトといったファミリーアプリにはすでにWebViewの技術が使われていて、知見があったことも役立ったんだと思います。

白石：React.jsを使っているとのことですが、SPA的な開発だとマークアップはそんなに必要じゃないと思うんですが、両方必要なのはどうしてなんでしょう。

富田：うちは分業体制をとっていて、僕と大槻さんが所属しているチームはフロントエンドを担当しています。案件によってJSとマークアップの両方を一人が担当することもありますが、newsでは規模の大きさもあって担当が分かれています。

デザインからHTMLを起こして、それを渡しているので、一般的に言われているReactを使うイメージとはちょっと違うかもしれません。

大槻：セマンティックなHTMLを書くとか、CSSを設計するといったところは完全にお任せしてします。一回組んだものを、パーツとして分解してJSXに落とし込んでいます。

白石：PCでも記事ページそのものは見られるんでしたっけ？

富田：記事ページは見られます。

白石：あ、レスポンシブ対応しているんですね。

富田：いえ、レスポンシブとかではなくて、PC専用に作っています。SNSなどでシェアされたURLはPCからでもアクセスできるため、PC用の記事ページを用意しています。

JavaとPerlでサーバー管理

白石：サーバーサイドでJavaとPerlという複数言語を使っているのはなぜですか？

森藤：もともとPerlで全体が作られていたのですが、社内の方針で最近はJavaで作ろうという流れになってきています。なので、最近のレポジトリとかはJavaで作ってます。まあ、歴史的背景です(笑)。

Perlはニュースタブと記事ページ、あと社内向けのCMSもPerlで作られています。

白石：へえ！CMSは自作なんですね。ちなみに、ReactはAPIを出すのに使ってるんですか？

森藤：はい、ニュースタブの部分は、全てAPIで実装されています。

白石：Reactでサーバーサイドレンダリングしているのでしょうか。

大槻：いえ、クライアント側でレンダリングしています。

APIでとってきたデータをローカルストレージにのせておいて、ネットワークがないところでも画面が真っ白にならないように工夫しています。

白石：JavaとPerlで分かれていますけど、システム間連携しているんですか？

森藤：データベースで連携しています。データベースはMySQLを使っています。

白石：MySQLをクラウド上で？

森藤：いえ、オンプレです。本番環境は、現在ほとんどオンプレのサーバーで動いていますが、最近構築したサーバーや開発環境はプライベートクラウドの「Verda」というサービスを使っています。

白石：えっ、どこかの製品を買うのではなく、自分たちで作ってるんですか。かっこいいですね。

森藤：DB周りはDBA（データベース管理者）のチームが運用しています。DBサーバーの構成は、マスター1台に参照やバックアップに使うスレーブが数台ある感じです。テキストで入稿するデータなので、データ容量が一気に増えて困ったとか、容量が足りなくなったという話も聞いたことがないですね。

白石：Javaで入稿システムを作っていらっしゃるんですよね。ScalaやKotlinなんかも使っているんでしょうか？

前澤：Javaだけです。最近のモダンな言語に比べると、やっぱりJavaは冗長というかすごいコード量を書かないといけないのは大変なんですが…。

白石：ぼくは昔Javaエンジニアだったのですごく気になるんですが、Javaのバージョンは何ですか？

前澤：Java 8です。

大槻：僕も前職では、エンタープライズ系のサービスをJavaで書いていました。その時はバージョンが古くて4でした。あと8をちょっと触ったくらい。当時はジェネリクスもアノテーションもなくて(笑)。

白石：僕はXML地獄でしたね(笑)。EclipseみたいなIDEとかは使ってますか？

前澤：Eclipseは使ってなくて、IntelliJ IDEAを使ってます。

React.jsを選択した背景は？

白石：フロントエンドのReact.jsはいつから使ってるんですか？

大槻：ニュースタブができてからなので、2017年2月からですね。

白石：苦労したこととかありますか？

大槻：React.jsだから苦労したことは特になかったんですが、どのライブラリにするかは結構検証しました。Vue.jsやRiot.jsなんかもいろいろ試してみたのですが、結局React.jsにしました。

Create React Appでベースを立ち上げた経緯もあって、最初の環境を整えるのはすごくスムーズでした。React.jsは結構書きやすくて、世の中で使われているアプリも多く、バージョンアップも早いし、安定していて信頼できました。

白石：なるほど。stateの管理とか、Reduxは使ってますか？

大槻：Reduxは最初は使おうと思ったのですが、意外と過剰なスペックがあってやめました。代わりにFlux Utilsを使っています。

足りない開発ツールはどんどん作る

白石：ほかにLINEさん独自の開発手法があれば教えてください。

大槻：フロントのアクセス解析はGoogle アナリティクスを使っているんですが、そのほかに社内で開発した「LINE Analytics」という解析ツールを使っています。JavaScriptのエラー部分もリアルタイムに収集できるので、リリース直後に増減を確認したりしています。

白石：LINEさんは結構社内で作る文化があるんですね。自分たちでも作るというのは、意思決定が必要だと思うんですが、どんなかんじで決めているんですか？

富田：その辺は結構自由にやらせてもらえる風土ですね。プロジェクトで使うツールだけでなく、たとえばメーラーやスケジュール管理といった社内システムについて内製する部署があります。既製品でもの足りなかったら、自分たちで作っちゃおうみたいな。

大槻：分業しているのでサーバーに触れること自体は少ないんですが、JSやCSSの配信ツールをフロントエンドチーム内で開発したりと、役割内で足りないものは作って配布させたりする人が多いですね。

サーバー側はCIも自前で作ってると聞きました。社内の承認フローがそれほどかたくないので、わりと気軽に自前で作ってます。

白石：CIもですか！Jenkinsとかを使わずに？

前澤：Perlでは内製のCIを使っていますが、JavaではJenkinsを使ってビルドしていて、ビルドした成果物をサーバーに配布するシステムは内製です。CDNのオリジンサーバーも自作してますね。

秒間2万のアクセスを捌くパフォーマンス

白石：パフォーマンスなんかもかなり気をつかっているんじゃないでしょうか。

森藤：はい。APIアクセスが秒間2万くらいのアクセスがあるので試行錯誤しています。APPサーバーの台数は約30台くらいなんですが。

森藤：去年の6月に高速化プロジェクトがあって、CDNを追加しました。CDNはAkamaiを使っています。クエリーをちゃんと書いてなかったりするとサービスが止まるので、SQLには気をつけてキャッシュに貯めるようにしていますね。

白石：フロントエンドのパフォーマンスで工夫した点はどうですか？

大槻：ニュースタブは縦に長いんですけど、DOMが増え過ぎるとメモリを食ってアプリがクラッシュしてしまう問題がありました。

iPhoneでは横スワイプでタブ移動できるので、左右のタブを予め描画している分よりDOMが多く、見えないDOMをいかに削除していくかなどの工夫をしています。

タスク管理・チーム間の共有ツールは？

白石：皆さんは所属する組織は違うとのことですが、「LINE NEWS」プロジェクトのタスク管理やチーム間の共有ツールはどうしていますか。

富田：ニュースチームのプロジェクトとして定例ミーティングをして、進捗管理しています。管理に使っているツールはJIRAですね。

白石：進め方はアジャイルですか？

富田：そんなにアジャイルぽくはないです。企画チームが20人くらいいて、案件ベースを作ってくれるので、早い段階で開発からもフィードバックしたり、企画と一緒に練ったりします。1週間のスプリント制でやっています。

白石：ニュースチームは全体で何人くらいいらっしゃるんですか？

前澤：企画や開発、制作、編集、アライアンス、モニタリング、PR・マーケティングなどを含めると、プロジェクトに関わっている人は100人を超えています。エンジニアは現在、バックエンドが8人、フロントエンドが4人です。

白石：大型プロジェクトですね。CIは自作されてるとのことでしたけど、DevOpsみたいな工夫ポイントはありますか？

前澤：これまでは五月雨で流動的だったけど、人が増えてきたので週1回のサイクルを整えたり、模索しているところです。

白石：ソースコードの管理やリリースのルールとかはどうでしょう。

森藤：ソースコードの管理はGitHubです。Perl側は最低2人レビュアーがいないとリリースやマージしちゃいけないことになっています。

急成長するサービスと開発体制に合った環境を構築

白石：最後に今後こうしたいという抱負や、チャレンジしたい目標を教えてください。

前澤：LINEのサービスが急速に成長して、エンジニアも増えているので、開発時期によってリポジトリやフレームワークの使い方も違ってきています。それを統一したいと思っているんですけど、結構大変そうです(笑)。

森藤：これまでのサーバーサイドはほとんどPerlだったんですけど、ここ数年みんなJavaを書くようになって、Perlを書くエンジニアが減ってきているんです。サーバー側をもっとJavaに置き換えていけたらと思ってます。

大槻：TypeScriptを導入も検討していきたいです。依存するライブラリの都合もあって、簡単ではないかもしれませんが。

富田：ニュースのプロジェクトが始まったのが2013年で、最近では更新が滞っているruby-sassやgrunt、compassといった古い環境に依存しており、日々の更新に忙しくてそういった根幹部分はなかなか手を入れることが難しかったんですが、最近のリリースで、タスクランナーに依存したコンパイルをやめたり、node-sassへの移行したりしました。

それに伴ってチームで使っている社内用のツールやsassのライブラリを更新しているので、今後も新しい技術についてそれらに生かせるか検証しつつ対応できればと思っています。

白石：LINEさんは独自の開発ツールをどんどんつくっていく行動力と技術力が素晴らしいですね。今日はいろいろ面白い話をありがとうございました！

LINEさんでは、9月28日(木) にエンジニア向け技術カンファレンス「LINE DEVELOPER DAY 2017」を開催するそうです。LINEの様々なサービスにおける技術領域でのチャレンジや開発体制などについて語られるとのことなので、興味のある方はぜひ参加してみてください。

日本最大級のHTTP/2移行、TLS 1.3、そしてQUICについてヤフーに聞いてみた！

白石俊平 — Fri, 15 Sep 2017 00:48:15 +0000

連載： HTML5 Conference 2017特集 (5)

こんにちは、編集長の白石です。

この記事は、9月24日に開催されるHTML5 Conference 2017に登壇するエキスパートに、予定しているセッションのトピックを中心に、様々な技術的なお話を伺おうというものです。セッションの内容をより深く理解する手助けになるだけでなく、本記事単体でも面白く読んでいただけることを目指しています。

今回お話を伺ったのは、ヤフー株式会社にお勤めの大津繁樹さんと新部長則さんです。

▲左から、ヤフー株式会社大津繁樹さん、新部長則さん

お二人のセッションは「大規模運用で見えるWebプロトコルの理想と現実、そして今後」（ルームB 13:20-14:00）です。（現在HTML5 Conferenceは定員オーバーの状態ですが、無料イベントということもあってキャンセルも多めに出るらしいので、諦めずにキャンセル待ちすることをお勧めします！）

日本最大級のHTTPS & HTTP/2化案件の実際

白石: まず簡単な自己紹介からお願いできますでしょうか？

新部: 私は2005年の7月に入社し、Yahoo!メールや広告の画像配信を行うCDNの運用などを経て、現在は全社で利用しているリバースプロキシの運用を行っています。現在、社内でプラットフォームと呼ばれる部分にはだいたい関わっている感じですね。

大津: まさに、新部さんのチームは、ヤフーのトラフィックをほとんど全て受け止めていると言って間違いありません。国内最大級のトラフィックを支えているんです、半端ないですよ。

白石: では大津さんも自己紹介をお願いできますか？

大津: 私は昨年の10月に入社したばかりです。大きく2つの仕事をしていまして、Node.jsのコミッターとして社内のサポートを行っているのと、IETFでネットワークプロトコルの標準化活動に関わっています。

白石: ありがとうございます。では、ヤフーのサービスをHTTPS + HTTP/2化した際のことを伺ってもいいですか？

新部: まずはヤフーのサービスをHTTPSに移行するところから始めたんです。HTTPS化に伴うコストや影響の試算を踏まえて、2015年10月に、全社横断でHTTPS化するプロジェクトが発足したんです。

HTTPS化するにあたっては大きな問題が2つありました。1つは、TLSの暗号化・復号化の処理が重たいということ。もう1つは、証明書の管理が煩雑にならないようにしなくてはならないということでした。なにせドメインでいうと1,000以上、サービスも100以上ありますので。

白石: 規模感が普通の会社とは桁違いだ…。

新部: なので、全社共通のリバースプロキシを作って対応することになったんです。そのリバースプロキシでTLSを一旦終端させて、そこから先は通常のHTTP/1.1に変換し、各サービスにリクエストを転送する。

白石: そのリバースプロキシって、だいたいサーバ何台分くらいになるんでしょう…？

新部: 500台以上ですね。

大津: 「以上」と言っても幅があると思いますが、そのかなり上の方ですよ、実際の数字は(笑)。

白石: す、すごい…！

新部: そして、2016年3月、最初にリバースプロキシに乗ったのはヤフオク！です。

白石: なんでヤフオク!を最初のサービスに選んだんですか？

新部: 検証の意味も強かったので、ある程度以上の規模感のあるサービスをデプロイしたかったんです。あと、下手すると人命を左右するような「何があっても絶対に止められない」サービスは避けたかった。

白石: なるほど。

新部: ヤフオク！も、いきなり全部をHTTPS化したわけじゃなくて、最初は一部だけ、その後範囲を広げていったという感じです。幸いにもそれほど大きな事故も起こることなく進んでいき、2017年の3月末には、特定のクライアントに提供しているところを除いたすべてのサービスがHTTPSで動作するようになりました。

HTTP/2化は正直、「エイヤ」でやった

白石: なるほど、HTTPS化は、様々なご苦労はあったことと思いますが、比較的順調に推移したということですね。そして今では多くのサービスがHTTP/2を利用しているんですよね。HTTP/2化はどういう流れで進んでいったんですか？

新部: これはちょっと言いにくいし、言っていいのかもわからないんですが…正直、「エイヤ」でやってしまったところもありますね(笑)。

全社共通のリバースプロキシを構築できたし、ここをHTTP/2化してしまえば、全部HTTP/2にできるじゃん、と。弊社のエンジニアもHTTP/2サーバの実装に携わっていたりもしたので、自分たちで作った成果を自分たちで使いたいという要望もありまして…。

白石: で、「エイヤ」でやっちゃったと(笑)。

新部: まあ、全部をいきなり切り替えたわけじゃないですけどね。こちらも一部のサーバだけを切り替えて、問題がないことを確認しつつ、だんだんと。

白石: なるほどー。ちなみにその、最も重要なリバースプロキシですが、具体的にはどのソフトを利用しているんですか？nginxとか？

新部: いや、Apache Traffic Serverというプロダクトです。元々これは米国のYahoo! Inc.が開発していたものをApache Software Foundationに寄贈したものです。

白石: では、Apache HTTP Serverとは関連がないんですね。

新部: そうです。このサーバをHTTP/2対応させるパッチの開発に、弊社のエンジニアもコミットしているんです。

「HTTP/2化で速くなったかは…正直わかりません(笑)」

白石: では、HTTP/2への切り替えは、それほど大きな問題もなくうまく行ったと。そうした環境で運用を行ってみて、実際にわかったことや問題などはありますか？例えばHTTP/2化することで、パフォーマンスが向上するんじゃないかという期待はあったと思うのですが。

大津: そうですね…正直に言ってしまうと、HTTP/2でパフォーマンスが上がったかどうかはよくわからないんです。

白石: ああ、それ先日インタビューしたあほむさんも同じこと言ってました(笑)。

大津: 個別に見れば、速度が上がっている部分は確実にあるんです。ただ、トータルで向上したかどうかは結局よくわからないんですよね。

例えば、window.onload が速くなったかというと、そうでもないんです。ただ、onloadについてはあまりにも様々な要因が絡むんで、測定の指標としてあまり有効でないという問題もありますけどね。なにせ、ずっと昔から運営しているサービスなので、 document.write にブロックされているページも残っていたりしますし。

白石: 確かに、「トータルで向上したか」と言っても「トータル」ってそもそも何なんだという定義が難しそうです。

大津: そういうところも含めて、測定が十分に行えていないというのも課題ですね。サーバ側のログを見ると、リクエスト数ベースでHTTP/1.1とHTTP/2の割合は現在4:6くらいです。

白石: 1.1がまだいるっていうのは…ああそうか、(HTTP/2に対応していない)古いブラウザを使っているクライアントですね。クライアントの環境も様々だから、余計測定が難しいですね…。

大津: そうなんです。一気に切り替えてしまったことで、A/Bテストなども行えていないですしね。A/Bテストを行うために、一部を一旦HTTP/1.1に戻すというのもありかもしれません(笑)。

HTTP/2がサーバの処理負荷を下げる？

白石: HTTP/2に移行する前の、HTTPSへの切り替えではいかがでしたか？先程、「TLSの処理が重たい」という懸念が事前にあったとのことでしたが。

新部: 一度それで問題になったことはありますね。

弊社のサービスからプッシュ通知を送った時とかは、ユーザーが一斉に接続するので負荷が一時的に高まるんですが、それでCPUがパツパツになってしまったことがありまして。ただ、HTTPS化する前はCPUがボトルネックになるようなことはなかったので、やはりTLSの処理が影響していたんだろうなあと思います。

大津: ただ、その後そういう問題は起きていないのは、HTTP/2が一役買っているのかもしれません。

HTTP/2はTCPセッション数が減るので、TLSの暗号化・復号化に伴う処理負荷も減ります。単純に言えば、HTTP/1.1の時に6セッションだったものがHTTP/2で1セッションになったら、TLSのコストは1/6になるわけで。

白石: なるほど！HTTP/2がサーバの処理負荷を下げるという可能性は、今まで思い至りませんでした。

HTTP/2のさらに先へ。新しいプロトコルを知る – TLS 1.3とは？

白石: HTML5 Conferenceでは、さらに新しいプロトコルについてもご紹介があるとのことですね。

大津: はい、TLS 1.3やQUICについて紹介しようかと思います。

TLS 1.3というのは、1.2までの技術的負債を精算しつつ、ハンドシェイクを速くすることを目的とした仕様です。仕様はだいたい固まっていて、現在Googleをはじめとした企業が、実験的に使用して調査中です。

白石: 技術的負債を精算して、さらに速く…って、いいことづくめですね。

大津: ただ、TLS 1.3にはまだ大きな問題が残っています。後方互換性に関わる透過性の問題があって、通信できない場合があることが報告されているのです。

TLS 1.3に対応していない中間機器が、接続を無断で切断しちゃうことがあるんですよね。そういうファイアウォール、IDS（Intrusion Detection System:不正侵入検知システム）、IDP（Intrusion Prevention System:不正侵入予防システム）などが中間経路にあると、ネットワーク全体がダウンしてしまうこともあります。本来は、TLS 1.2にフォールバックしてほしいのですが…現在Googleなどが後方互換の問題を最小にするために透過性の調査を行っているところです。

白石: 通信を遮るものをどう扱うか、は難しい問題ですね。正直、簡単に解決する問題には全く聞こえませんね…

大津: そうなんですよ。少し前に、GoogleがTLS 1.3を試験的に有効化していたところ、ある学校で問題が発生し、数万台のChromebookが通信もアップデートも行えなくなってしまうということがありました。こうなるとGoogleですらお手上げなんですよね。TLSに完全に依存しているので。

そう考えると、HTTP/2って「幸運」だったと思うんですよね。

白石: 「幸運」ですか。

大津: はい、TLS 1.2という「枯れた」プロトコル上の動作を前提にできたのがラッキーでした。TLS1.2って、2008年に登場したプロトコルで、今は完全に普及しきっていますから。

そういう前提のないプロトコルや機能拡張だと、大変なんです。

例えば、TCPのデータ送受信開始を速める「TCP Fast Open」という仕様もあるのですが、うまく通じない現象がAppleのエンジニアによって報告されていて、最近Linuxで緩和策が講じられたにもかかわらず、Microsoft Edgeではついにデフォルトで無効化されてしまいました。

TCP Fast Openは2014年に標準化されており、Linux、 macOS、 WindowsなどOSの対応も進んでいるのですが、それでもまだこういう状況です。それほど、低レイヤーのプロトコルを普及させていくのは難しい。

だから、私たちがHTTP/2の移行にあまり苦労しなかったことも含め、HTTP/2のアップグレードがこれほどスムーズなのは大変幸運なことなのです。

QUICという「プラットフォーム」の可能性

白石: QUICについても教えていただけますか？

大津: QUICは、ざっくり言うとUDPの上でTCP、TLS 1.3、そしてHTTP/2の一部をごちゃっとやる感じのプロトコルです。

白石: ごちゃっと(笑)。

大津: IETFでの標準化も進められていて、今度の10月で1年になりますね。非常に有望なプロトコルで、今後のネットワークのプラットフォームになっていくポテンシャルを秘めていると期待しています。

白石: なぜそこまで期待していらっしゃるのでしょう？

大津: 「UDPなので疎通性が良い」というのと「ユーザーランドで動作するプロトコルなのでデプロイが容易」ということが挙げられます。

先程TLS 1.3の普及には苦労しそうだ、という話をしましたが、QUICはUDPなので比較的通りやすいんです。また、通じなかった場合はTCPにフォールバックする機能もある。通信を行うコンピューター同士が、エンドツーエンドでQUICに対応していればいいのです。

ユーザーランドで動作する…というのは、TCP BBR (※) と比較するとわかりやすいと思います。

※参考: 「Google、TCPのスループットとレイテンシを改善する輻輳制御アルゴリズム「TCP BBR」をGoogle Cloudで利用開始 (Publickey)」

TCP BBRは、Googleが開発した新しい輻輳制御のアルゴリズムです。モバイル環境のように、パケットロスが非常に多い環境でも速度を最大化できるという利点があります。

しかし欠点としては、TCPのスタックってOSのカーネルに実装されているので、使おうとするとカーネルのアップデートが必要になるということです。できれば通信を行うコンピューターがどちらもTCP BBRに対応したカーネルにアップグレードしていることが望ましいのですが、OSのアップグレードサイクルを考えると、どれほど少なく見積もっても普及には数年かかるでしょう。

その点QUICはUDPの上で構築されている。プロトコルの処理はユーザーランドで行われるので、デプロイするのにOSのアップグレードなどを伴いません。プロトコルのバージョンアップも、機能追加も比較的簡単だと考えられます。将来的にHTTPだけでなくDNSやWebRTCなどでQUICが利用されることも検討されています。

白石: それが、「QUICはプラットフォームになりうる」という先程の言葉の意味ですね。

大津: はい。ただ、QUICも実際には良いことばかりではありません。「QUICを無効にしたらChromeが軽くなった」などのノウハウが最近巷に広まってきています（※）。さきほどUDPの透過性の良さについて話しましたがやはり完全に透過ではなく、これも中間経路での問題が出てきている現象だと見られています。

※参考: 「最近 Chrome が「重くなった・ひっかかる」と感じたら試してみてほしいこと (Tanweb.net)」

白石: やはり、ネットワークプロトコルのデプロイって難しいんですね…。ただ、QUICが持つ素晴らしい可能性についても、よくわかりました。

本日は、実際の大規模なHTTPS & HTTP/2への移行経験から新しいWebプロトコルのお話まで聞けて、大変勉強になりました！どうもありがとうございました。

「最近のWebパフォーマンス改善について知っておきたいコト」についてあほむに聞いてきた

白石俊平 — Mon, 11 Sep 2017 01:00:23 +0000

連載： HTML5 Conference 2017特集 (3)

こんにちは、編集長の白石です。

この記事は、9月24日に開催されるHTML5 Conference 2017に登壇するエキスパートに、予定しているセッションのトピックを中心に、いろいろ伺ったものです。セッションの内容をより深く理解する手助けになるだけでなく、本記事単体でも面白く読んでいただけることを目指しています。

今回お話を伺ったのは、株式会社サイバーエージェントにお勤めの佐藤歩さんです（ネット上では「あほむ」「ahomu」のIDで有名）。（プロフィールはこちら）

あほむさんのセッションは「最近のWebパフォーマンス改善について知っておきたいコト」（ホール 13:20-14:00）です。（現在HTML5 Conference 2017は定員オーバーの状態ですが、無料イベントということもあってキャンセルも多めに出るらしいので、あきらめずにキャンセル待ちすることをお勧めします！）

パフォーマンスはなぜ重要か？を違う切り口から伝える

白石: Webパフォーマンスについて、「ベーシックな話を少々と、最近の動向」をお話されるということですね。

あほむ: はい、そうですね。まあ、まだセッションの内容はほとんど固まっていないので、当日は全然違った話をすることになるかもしれないのですが。

普通パフォーマンスに関する「ベーシックな話」というと、「なぜパフォーマンス改善は重要か」ということを語られることが多いと思うんです。でも、「パフォーマンスが重要」というのは、もうエンジニアには広く認識されているんですよね。

足りないのは、パフォーマンス改善を「開発者の自己満足」で終わらせないことなんじゃないかと。パフォーマンス改善が、自社のビジネスにどう寄与するのか。そこを考えないと、意味のないパフォーマンス改善を行ってしまう恐れもあるし、社内の理解も得られない。

「パフォーマンスは重要である」というメッセージを、そういう観点からも伝えたい気がします。それも他社の事例とか一般論から語るんじゃなくて、私自身が遭遇した実体験などを踏まえて語りたいな…と思ってます。

白石: それは面白そうですね！具体的には、どんな実体験になりますか？

あほむ: 例えば、弊社のサービスってSNSでWebページが拡散されることが、非常に大きな比重を占めているんです。つまり、TwitterやFacebookのアプリ上で、WebViewでページを表示されることがすごく多いんです。そうなると、実はブラウザのキャッシュにすら期待できないことが多い。弊社のサービスはiOSのユーザーが多いのでなおさらです（※）。

とはいえ、SNSを通じてたまたま遭遇した、っていう千載一遇のチャンスは活かさなくてはならない。そういう限定された環境でも最高のUXを実現するため、最大のパフォーマンスを発揮するにはどうしたらよいかを常に試行錯誤しているんです。

白石: なるほど。確かにそれは、パフォーマンスが非常に重要なシチュエーションと言えそうです。

あほむ: こういう例を含めていろいろ紹介できるといいかもしれません。URLさえあればどこからでもアクセス可能というのはWebの利点ですが、要はどんな環境で見られるかわからないということです。だから、Webのパフォーマンス改善には終わりがないし、少しでもその助けになるよう、常に新しいアイデアや技術が考案されています。そういう技術のうち、比較的新しくて、活用しがいのあるテクニックや仕様について、いろいろご紹介できればと思っています。

※弊社のサービスはiOSのユーザーが多いのでなおさら…Androidであれば、Chrome Custom Tabという仕組みでメインブラウザ（Chrome）とキャッシュなどのリソースが共有されることも期待できる。iOSは、Chrome Custom Tabに近いSafari View Controllerという仕組みがあるが、あまり利用されていない。

ページロードパフォーマンスの改善テクニック

白石: では、パフォーマンスを改善していくテクニックや仕様をいくつかご紹介いただけますか？

あほむ: Webパフォーマンスを考える際には、やはりページロード (ページの読み込み速度)とランタイム（ページ実行中のパフォーマンス）に分けて考えるのが王道です。ページロードの改善については、最近だとHTTP/2の話が中心になると思います。

白石: なるほど、御社のサービスでは、HTTP/2対応はもうかなり進められている感じなのですか？

あほむ: はい。できるところからHTTP/2にしていくというアプローチで、現在は多くのサービスがHTTP/2を利用して動いています。

白石: 実際にHTTP/2に対応してみていかがですか？苦労した点とかはありましたか？

あほむ: 具体的な切り替え作業については、インフラの専門チームが実施してくれるので、あくまで開発側からの意見になりますが…ほとんど苦労していることはないですね。

白石: おお、本当ですか。それは素晴らしい。

あほむ: はい、HTTP/2に切り替えても、開発への影響はほとんどなかったという点はとても重要ですね。アプリケーションとネットワークで、レイヤーが違うから当然といえば当然なのですが、やはり実際に経験してみると、そのありがたさが実感できます。トレードオフがほとんどないにも関わらず、パフォーマンスの向上が見込めるのですから。

白石: でも、HTTP/2に切り替えたことで、本当にパフォーマンスアップするのか、懐疑的な意見も目にしたことがあります。実際のところどうなんでしょうか？

あほむ: うーん…実際のところ、それはありますね。HTTP/2にしただけだと、体感的に良くなったっていう実感があまりないのは、正直なところです(笑)。

白石: それも正直な意見として、貴重だと思います(笑)。

あほむ: 例えばHTTP/2でヘッダ圧縮されてデータ転送量が多少減ったとしても、アプリケーションで扱うデータが最適化されてなかったら、誤差みたいなレベルになってしまいますからね。HTTP/2によるパフォーマンス向上は、確実に効いているとは思います。ですが、実際のサービスでは、常に別のところにパフォーマンスのボトルネックが潜んでいて、効果のほどが見えにくいんですよね。

白石: 他には、ページロードの最適化で知っておいたほうがいいテクニックとかありますか？

あほむ: ほかには、コンテンツの圧縮にZopfliやBrotliを利用していますね。他にはResource Hintsなども使っているので、お話したいですね。

※参考記事：FRESH! Web パフォーマンス改善〜サーバサイド編〜

白石: Zopfli…？そんな圧縮形式があるんですか？

あほむ: はい、ZopfliもBrotliも、どちらもGoogleが開発した圧縮形式です。

Zopfliは、圧縮の速度は遅いですが、そのかわりに圧縮効率は非常に良い。そしてgzipとの互換性があるので、gzipに対応したブラウザであればだいたい扱えるという大きな利点があります。

Brotliは、gzipとの互換性はありませんが、非常に効率のよい圧縮アルゴリズムです。こちらは現在のところ、Chrome, Firefox, Edgeでのみ利用可能です。

白石: Resource Hintsというのはどういうものですか？

あほむ: 利用するリソースを先読みするヒントをブラウザに与えるための仕様です。これを利用すると、現在のWebページに含まれていないリソースであっても、ブラウザに先読みさせることができます。dns-prefetch (名前解決を実行しておく）, preconnect （サーバ接続を行っておく）, prefetch （リソースのフェッチを実行しておく）, prerender （ページのレンダリングをバックグラウンドで実行しておく）といったタイプの先読みが可能です。（筆者注: Jxckさんのブログで詳しく解説されています）。

ランタイムパフォーマンスの改善テクニック

白石: ランタイム（アプリケーション実行時）のパフォーマンスを向上させるために使用している技術にはどんなものがありますか？

あほむ: Intersection ObserverやPassive Event Listenersは利用しがいがあると思います。

Intersection Observerというのは、要素同士の領域が交差したり、もしくはビューポート（ユーザーに見えている範囲）に要素が入ったかどうかなどを検出できるAPIです（筆者注: Intersectionとは「交差」の意味）。これを利用すると、ビューポート外で行われる処理を抑制したり、遅延させたりすることが可能になるので、パフォーマンス向上には非常に効果的です。わかりやすいのは、img要素がビューポート内に現れるまで画像の読み込みを遅延させる…などですね。

Passive Event Listenersというのは、UIイベントが preventDefault() （デフォルトの動作をキャンセルする）されないことを保証するための仕組みです。

スクロールイベントなどは、 preventDefault() を行うことでブラウザのスクロール処理そのものをキャンセルすることができます。逆に言うと、ブラウザはスクロールがキャンセルされる可能性を考えると、イベントハンドラを実行してから実際のスクロールを行わなくてはならない。だから、イベントハンドラの実行に時間がかかったりすると、スクロール処理が詰まってしまうんです。これがスクロールジャンクと呼ばれる現象です。

ただ、実際に preventDefault() でスクロール処理を止めたいというケースは多くはありません。なので、「このイベントハンドラはpreventDefault()を呼ばないよ」ということをブラウザに伝える手段として用意されたのがPassive Event Listenersです。

（筆者注: これらも、Jxckさんのブログに詳しい解説がある。Intersection Observer Passive Event Listeners）

白石: 今おっしゃったIntersection ObserverやPassive Event Listenersは、全てのブラウザで動くわけではありませんよね？

あほむ: はい。なので、動作しないブラウザ用にFeature Detectionで分岐を設けたり、Polyfillも活用しています。

白石: なるほど。ただ、最初にお聞きした例だと「SNSで拡散されたページの最適化に注力している」というお話でした。こういうランタイム系のパフォーマンス改善って、SPA (Single Page Application) ではない通常のランディングページやメディアのサイトなどでも重要なのでしょうか？

あほむ: そう思います。先程も申し上げたように、SNSを通じてサイトにアクセスしてくれるのって、ユーザーと接触できる千載一遇のチャンスなわけです。そこからモバイルアプリへの誘導を行うこともできる。なので、そういう千載一遇のチャンスで少しでも機会損失を起こさないように、入念にパフォーマンスをチューニングするのは非常に重要です。

個人的には、jQueryを使った普通のWebサイトこそ、ランタイムのパフォーマンスにもっと気を使うべきだし、できるとも思います。jQueryのプラグインが最新の仕様に追従すれば、プラグインをアップデートするだけで恩恵を得られるわけですから。

ただ逆に、プラグイン側が対応してくれなかったりすると、プラグインの中に手を入れるわけにもいかず、対応が進まないということの裏返しでもありますけどね…悩ましい問題です。

パフォーマンス改善を「開発者の自己満足」で終わらせないために

白石: これまでご紹介いただいた様々なテクニックですが、これらを活用してパフォーマンスを実際に改善していくのは、実際には骨の折れる作業だと思います。そうした、パフォーマンス改善作業に投下するコストと、それによって得られるリターンについては、どのようにお考えでしょうか？

あほむ: はい、おっしゃるとおり、これらのテクニックをただ使って、目に見えない部分でパフォーマンスを改善しても、単なる開発者の自己満足に終わってしまいます。それを避けるためには、まずは正しく計測することと、それがビジネス上のKPIとどう関連付けているかを検証していくことが必要です。

まず計測についてですが、クライアントサイドのパフォーマンスを計測する指標は、現在も様々なものが考案され、利用可能です。

例えばFirst Paint。Webページの描画が開始されたタイミングを表す指標で、ChromeやEdgeでは非標準のAPIから値を得ることができます。

ただ、First Paintだけでは、コンテンツの表示が完了するまでの速度などについてはわかりません。最も重要なのは、ユーザーに見える範囲、つまりビューポートの描画がいつ完了するかです。

そういう観点での指標としてはSpeed Indexがあります。Speed Indexを計測する基本的な方法としては、描画中の画面をキャプチャして、最終的な表示結果が得られるまでにどれくらいかかるかを測るというものです。弊社のサービスでは、ページビューや直帰率といったKPIとSpeed Indexの間に相関関係が認められたため、Speed Indexを中心にパフォーマンス改善を行いました。

さらにこうした指標は実際のユーザーの環境で得られた値を一定量集めることも大事なので、集計結果をGoogle Analyticsに送信しています。そうすることで、GAを使いなれたプロに分析をお任せすることもできますからね。

そうした経緯は弊社技術ブログの記事に詳しく書かれています。

白石: なるほど…パフォーマンス改善がビジネスに寄与するという道筋を立てることで、パフォーマンス改善が業務として意味にあるものになるわけですね。

あほむ: そうですね。パフォーマンス改善とビジネスが両輪としてうまく回るためにも、やはり様々なパフォーマンス指標や計測が大事になってきます。

指標は他にもFirst Contentful Paint （コンテンツが表示され始めた時）や First Meaningful Paint （ユーザーに意味のある表示になったとき）など様々なものが考案され、実装も行われています。よければそういう話をまとめた私のブログ記事も見てみてください。

白石: なるほど、今日は貴重なお話をお聞かせいただきありがとうございました！HTML5 Conferenceでのセッションも楽しみにしています。

React VRでここまでできる！VRでジオラマを作ろう

原一浩 — Mon, 31 Jul 2017 01:30:45 +0000

連載： React VR (4)

今回は、こんなVRジオラマをつくるぞ！

前回、3Dプリミティブオブジェクトを使って、レイアウトやライティングの仕方について一通り試しました。前回扱わなかったコンポーネントに、3DモデルのためのコンポーネントModelがあります。Modelコンポーネントを使うと「obj」形式の3Dモデリングデータを読み込み、VR空間に配置することができます。

3Dのモデリングデータを使うと、リアルな物体だったり、複雑な形状を持ったオブジェクトを自由にVR上で扱えるため、VR空間における表現力が飛躍的に高まります。実際VRコンテンツを作る際に使うのはBoxやCylinderではなく、Modelコンポーネントになるでしょう。

今回は、3Dのモデリングデータを読み込み、ジオラマを作ってみましょう。子どもの頃、作ったプラモデルに顔を近づけて遊んだ経験はないでしょうか。VRでは、巨大な物体を目の前に表示させるのもお手のものです。

新規プロジェクトの作成

既に本連載の読者であれば何度か行ってきていることですが、今回もサンプルを作るにあたって新規プロジェクトを作成し、プロジェクトディレクトリへ移動します。HelloDioramaというプロジェクト名で進めることにします。

$ react-vr init HelloDiorama
$ cd HelloDiorama

ジオラマに必要なものは何でしょうか? 一つは飾る対象物です。これはロボットなのかもしれないし、戦車かもしれないし、船かもしれません。3Dモデリングデータさえあれば、そしてそれをReact VRで読み込めさえすれば、なんでもジオラマにすることができます。

ちなみに「React VRで読み込めさえすれば」と書いているのは、Webで公開されている3Dモデリングデータの中には何故か表示できないものがあります。表示はできるけど変な形状になったりするものもあります。これはきっと時間と共に解決されていくタイプのものでしょう。気になることがあればReact VRのGitHubリポジトリでIssueを立てるとよいです。

続いてジオラマに必要なもう一つのものは何でしょう? それは雰囲気を与えてくれる背景です。緻密なモデルをさらに引き立ててくれる背景は、ロボットなら宇宙船の内部かもしれないし、船なら海上かもしれません。こちら背景は、今回は3Dプリミティブオブジェクトを利用してそれっぽいものを作ってみます。

用意するもの

ジオラマコンテンツを作るにあたって、用意するものは以下となりました。

配置する対象物としての3Dモデリングデータ
背景の壁と床のテクスチャ

まずは、配置する対象物としての3Dモデリングデータから用意しましょう。

1930年代に使われたソ連製のトラックのモデルデータ

今回ジオラマとして、シーンに配置するのは、GAZ-AAという1930年代に使われたソ連製のトラックにしてみました。筆者は、このトラックを好きだったわけではないですが、様々な3Dモデルを探す中でふとこのトラックを見かけ、素朴な中にも車両全面に漂う気品を魅力に感じ、採用した次第です。

このトラックは、ポリゴン数が4,380と、そこそこ複雑な形状をしており、テクスチャなどを含んでいてなかなかにリアリティがあります。

下記より、objフォーマット形式のものをダウンロードしましょう。もし他の3Dデータで試す場合、ライセンスについてチェックしておきましょう。

GAZ- AA furgon-Bread free VR / AR / low-poly 3D Model MAX OBJ 3DS FBX MTL

ちなみに、上記ダウンロードサイトでは、ユーザー登録が必要です。なので、ほかのものを用意できる人は好きな3Dデータを利用してOKです。「gaz-aa_bread OBJ.zip」をダウンロード、解凍したら、下記のディレクトリにそれぞれ配置します。

static_assets/gaz_aa/gaz-aa_bread.mtl
static_assets/gaz_aa/gaz-aa_bread.obj
static_assets/gaz_aa/gaz-aa_bread_cabin.jpg
static_assets/gaz_aa/gaz-aa_bread_detail.jpg
static_assets/gaz_aa/gaz-aa_bread_frame.jpg
static_assets/gaz_aa/gaz-aa_bread_furgon.jpg
static_assets/gaz_aa/gaz-aa_bread_wheel.jpg
static_assets/gaz_aa/gaz-aa_bread_wing.jpg

上記ファイルのうち、実は「gaz-aa_bread.mtl」については変更する必要があります。

テキストエディタなどでファイルを開き、「D:\Program Files\Autodesk\3ds Max 2009\scenes\GAZ-AA free models\gaz-aa_bread_3ds_max*.jpg」となっているところを「*.jpg」に書き換えましょう。これはきっと作ったときそのままのローカルのパスが入ってしまったのですね。公開する際の要注意ポイントと言えそうです。

ジオラマの背景に必要な素材は、角となる2面分の壁用のテクスチャと、床に使うテクスチャです。前回使ったPanoコンポーネントで、6面にテクスチャを貼り、部屋状にしてしまうこともできますが、それだとリアルな空間になりすぎ、ジオラマっぽくなくなるからです。3面しか壁を用意しないことで、後ろには漆黒の空間が広がる感じになり、なんだか超現実的な世界になります。

背景の壁のテクスチャ

床のテクスチャ

壁と床のテクスチャは以下からダウンロードしてください。

diorama

ちなみに、壁と床のテクスチャは、僕がそのへんで適当に撮ってきたものなので、フリーでお使いいただいて構いません。

ダウンロードしたら、「プロジェクトディレクトリ/static_assets/diorama」以下に「floor.jpg」と「wall.jpg」を配置しましょう。

STEP 1. まずは、ジオラマのベースづくりから

早速トラックを配置したいと、はやる気持ちを抑えてまずはジオラマのベースとなる背景の壁と床を作るところから始めましょう。床は、1000 x 1000の大きさを持った板を想定しました。これは、Panoコンポーネントで作った空間と同じ大きさとなります。そして、奥の壁は床から500の高さを持つ平面です。これにテクスチャをつけることで、リアリティを持たせます。では、具体的な作業をしましょう。

「index.vr.js」のViewの中を一旦空にし、下記のように修正します。

それと、importも変更しておきましょう。この先に使うModelコンポーネントやライティング関係のコンポーネントも加えておきます。

import {
  AppRegistry,
  asset,
  View,
  Plane,
  Model,
  DirectionalLight,
  PointLight,
  AmbientLight,
} from 'react-vr';

Viewコンポーネントが入れ子になっているのは、内側のViewは、ジオラマの背景セットで、セット全体を変形させたい場合はこのように入れ子にしておくと、壁や床を一つの塊として扱えます。ここではジオラマのセット全体をちょっと回転させています。というのも、最初に表示したときに部屋の中央ではなく、部屋の角を見せたいためです。

ジオラマのセット自体を回転させずに、カメラを回転させるという表現方法もありますが、普通ジオラマというのは、インテリアの側面もあり、一番かっこいいポジションで飾るものだと思います。そこで、View自体をY軸に対して-20度回転させました。

さらに細部を見ていきましょう。3つのPlaneが、内側のViewコンポーネント内に配置されていますが、先頭2つのPlaneコンポーネントは壁として配置してあります。位置を遠くに置いたのと、Y軸方向に90度回転させて垂直にそれぞれのコンポーネントが交わるようにしています。

Planeコンポーネントに関わらず、3Dプリミティブコンポーネントは、テクスチャを設定することができます。テクスチャはtexture属性で設定します。

ここではtexture属性に、「diorama/wall.jpg」を指定しました。これによりのっぺりとした壁が質感のある壁となりました。ちなみに、この壁は近くの公園の壁を撮影したものです。

一番最後のPlaneは、床として配置しています。X軸方向に-90度回転させ、テクスチャを貼りました。これは海に行った時の砂岩の岩肌です。深い意味があるわけではないですが、オフロードっぽい印象になる写真が見つからなかったので、こちらを採用しました。

$ npm start

を実行し、ブラウザでURLを開いてみましょう。ただし、こんどは「http://localhost:8081/vr/?hotreload」で開いてみてください。「?hotreload」を付けてブラウザから開くと、ホットリロードが可能になります。これで、エディタで編集したコンテンツが自動でブラウザ側に反映されるようになります。

配置した背景

3方向のみPlaneを配置しただけの簡素なジオラマセットですが、VRで角のほうを見るとなかなかどうして迫力がありますね。

STEP 2. 3Dモデリングデータを配置しよう!

続いて、お待ちかねの3Dモデルの読み込みです。3Dモデリングデータの読み込みには、Modelコンポーネントを使います。Modelコンポーネントには、source属性を記述することができます。渡す内容は、objとmtlというキーを持ったオブジェクトで、それぞれobj形式のファイルとmtl形式のファイルへのパスを渡します。

今回であれば、「配置するモデリングデータ」で保存しておいた「static_assets/gaz_aa」以下にあるobjファイルとmtlファイルが対象になります。

Modelコンポーネントは、「index.vr.js」の入れ子の内側のView以下に配置します。サイズは小さめにし、位置調整とrotateYプロパティを修正して、若干の回転を加えます。これは、ちょうど左前に向いた形がきれいだからです。コードは下記のようになります。

これで、ブラウザをリロードしてみてください。3Dモデルが表示されるはずです。

まだ光が当たっていないので真っ黒

ただし、真っ黒なシルエットになってしまっていますが。ということで、続いて光源を用意して、明るくしていきましょう。

STEP 3. ライティングしてトラックを美しく!

ライティングは、前回3Dプリミティブオブジェクトで遊んだ際に試したのを思い出してください。メインの明かり、部分的な明かり、ちょっとした調整です。今回も同じような感じで進めます。

実は、React VRで使われている3DライブラリのThree.js本体には、ライティングに関する様々なヘルパー機能が用意されています。例えば、照明の向き、範囲などを視覚的に表示して微調整をする機能などです。ただ、現時点のReact VRではもっと限定的なサポートとなっているのでそこまで細かくは扱いません。

「index.vr.js」にDirectionalLightとPointLight、AmbientLightコンポーネントを配置しました。これで、トラックが綺麗に表示されるでしょうか。

トラックがちゃんと表示された！

ブラウザをリロードしてトラックを再表示してみましょう。明るくなったでしょうか。

STEP 4. トラックをゆっくりと回転させてみる

以上で一旦はジオラマは完成しましたと言ってもいいかもしれません。ただ、今まで物体を空間に置いてみて歯がゆかったのは、その物体の裏側がどうなっているのか、それが見えないということでした。ということで、アニメーションの練習がてらトラックを回転させてみましょう。

回転に関しては、ピッタリのサンプルが公式のリポジトリに用意されています。

react-vr/Examples/ModelSample at master · facebook/react-vr

このサンプルを参考にトラックのアニメーションを作ってみます。ちょっとサンプルと異なるのは、Reactのコンポーネントとして作るというのと、細かなロジックを修正した点です。Reactコンポーネントとして、回転速度を定義するspeed属性と、表示位置や大きさを定義するstyle属性を渡せるように作っておきましょう。「src/component/GazAa.js」として下記のように作成します。ちょっと長くなるので、細部の話は置いておいて、まずは一気に掲載してしまいます。

import React from 'react';
import {
  asset,
  View,
  Model,
} from 'react-vr';

export default class GazAa extends React.Component {

  constructor() {
    super();
    this.state = {
      rotation: 0
    };
  }

  componentDidMount() {
    this.rotate();
  }

  componentWillUnmount() {
    if (this.frameHandle) {
      cancelAnimationFrame(this.frameHandle);
      this.frameHandle = null;
    }
  }

  rotate(timestamp) {
    const delta = timestamp - this.lastUpdate || 0;
    this.setState({rotation: this.state.rotation + delta / this.props.speed});
    this.lastUpdate  = timestamp;
    this.frameHandle = requestAnimationFrame(this.rotate.bind(this));
  }

  render() {
    return (
              
            
    )
  }
}

ポイントは、GazAaコンポーネントのローカルステートとそれを変更するためのrotate関数、そしてそこで使われているrequestAnimationFrame関数とcancelAnimationFrame関数です。

GazAaコンポーネントは、シーンに配置した瞬間、つまりコンポーネントがマウントされた時から回転を始めます。逆にコンポーネントをアンマウントすると回転をやめる処理をします。回転の状態はコンポーネントのローカルステートとして定義されているrotationです。

rotationは、3DモデルのrotateYとしてY軸方向にどれだけ回転するかという値として使われることになります。その値をコントロールしているのがrotate関数です。requestAnimationFrame関数は、ブラウザの再描画のタイミングでrotate関数を呼び出すことになるので、呼び出すたびに前に呼び出された時間からの回転をrotationに反映していきます。requestAnimationFrame関数から返った値は、アニメーションをキャンセルするときにcancelAnimationFrame関数にて使われます。

requestAnimationFrame関数について一つ知っておきたいことは、この関数はもともとブラウザに実装されていますが、ブラウザによってはサポートされていないことがあります。そこで、React VRでは、requestAnimationFrame関数のpolyfillとして用意されています。

これで大体のGazAaコンポーネントの仕組みが理解できたでしょうか。今はこういうスタイルでアニメーションを実現したりしますが、将来的にはもっと洗練されたアニメーション機構が用意されていくのだろうと推測します。

では、先ほど作ったGazAaコンポーネントを使っていきましょう。「index.vr.js」で使うので、まずはインポートします。ファイルの先頭あたりにimport文を書きます。

import GazAa from './src/component/GazAa'

続いて、入れ子になったViewコンポーネントの内側に、GazAaコンポーネントを配置します。プロパティとしては、回転速度を定義するspeed属性と、表示位置や大きさを定義するstyle属性を渡しています。これら属性は、GazAaコンポーネント内のthis.props.XXXにて受け取ることが可能です。これらを記載したコードが以下になります。

以上で、トラックが回転するジオラマの完成です。ブラウザをリロードして、じっくり見てみましょう！

完成したVRジオラマ

もし興味があれば、React VR×360度画像！Web上でパノラマVR表示を試すを参考に、GearVRで眺めてみましょう。子供の頃叶わなかった、巨大サイズのジオラマを見ることができますよ。

Reactといえばコンポーネント！React VRの3Dプリミティブコンポーネントを探る、触る

原一浩 — Mon, 24 Jul 2017 01:00:05 +0000

連載： React VR (3)

今回のサンプルの完成版。ライティングとかもやるぞ

前回、React VRでパノラマ写真を見るというコンテンツを作成しました。
サンプルを試していただいた方は「なんか結構できたじゃん感」を満喫できたと思います。それもそのはず、360度写真のみのコンテンツは、天球にパノラマ画像を貼り付けた時点で、目的の99%を達成できたといえるからです。ほとんど完成といっていい状態でしょう。

しかし、他のVRコンテンツを触ったことがある人間なら、少しもの足りなさを感じることと思います。一つはインタラクティブ性のなさ、そしてもう一つはモノの存在感のなさです。

インタラクティブ性のなさは、イベント駆動型のVRコンテンツの作成というハードルが待っていますが、今回はそれはさておき、モノの存在感について書いていきます。

パノラマ画像だけで構成された世界は、「一見、目の前で展開されている感じなのに、触ることができないほど遠くに広がる世界」と言えます。目の前の芝生に近付いて触ることはできませんし、奥の人に近付くこともできません。

仮に頑張って、インタラクティブ性を高めて奥に進めるように作ったとしても、そこにあるのは拡大されて画素が粗くなった人のようなナニカでしかありません。

VRのモノとしての存在を確固たるものにするために大事なことは、VR空間に実際にモノを置いてみるということになります。

ということで、今回はReact VRに用意されているコンポーネントのうち、モノとして置けるコンポーネント、3Dプリミティブについて扱っていきます。

いろいろなタイプのReact VR Components

公式ドキュメントにあるReact VR Componentsの目次は下記のような構成になっています。

AmbientLight
Box
LiveEnvCamera
Cylinder
CylindricalPanel
DirectionalLight
Model
Pano
Plane
PointLight
Scene
Sound
Sphere
SpotLight
Video
VideoControl
VideoPano
VrButton

いろいろありますね。「あれ?、これだけしかないの?」という見方もあるかもしれません。主要なものを役割ごとにカテゴライズしてみましたので順に見ていきましょう。各種コンポーネントの実装コードに興味がある方は、GitHubのReact VRリポジトリのViews以下を見てみるとよいでしょう。

空間を作るタイプのコンポーネント

まず、チェックしておきたいのは空間を作るタイプのコンポーネントです。

VideoPano
CylindricalPanel
Pano

Panoは、既に登場しましたが、360度写真をVR空間に貼り付けるタイプのコンポーネントです。

VideoPanoは、Panoと同様ですが、貼り付け可能コンテンツが360度動画となります。CylindricalPanelは、ちょっと特殊なコンポーネントで、内側にテクスチャを貼ることができ、子コンポーネントを収録できるタイプです。今回は触れません。

ビデオ・オーディオ関連のコンポーネント

ビデオの話が少し出ましたが、ビデオ・オーディオ系に関係してくるコンポーネントは以下となります。

Sound
Video

Soundは、シーンに配置するコンポーネントですが、何か形があるわけではありません。音の発生源として配置する形になります。3Dオーディオをサポートしており、ヘッドマウントディスプレイを被って顔を左右に振ったりすると、音源の場所に応じたサウンドになることが確認できます。

Videoは、2Dのビデオを再生するためのコンポーネントです。これをユーザーの前面に貼ると巨大なテレビが目の前に広がったような演出ができます。

ユーザーインターフェースとなるコンポーネント

続いて、VR世界のユーザーインターフェースとなるコンポーネントが下記2つです。

VrButton
VideoControl

VrButtonは、ボタンです。応用性が高く、使い勝手の良いコンポーネントと言えるでしょう。VideoControlは、ビデオをコントロールするためのユーザーインターフェースとなります。 VideoコンポーネントとVideoControlコンポーネントを組み合わせると、VR空間にビデオプレーヤーを作ることができます。

Videoコンポーネントでビデオを表示させているサンプル

形状コンポーネント

そして、今回扱う形状コンポーネントです。

Box
Cylinder
Plane
Sphere
Model

上記のうち、Modelを除いた4つは3Dプリミティブコンポーネントと呼ばれます。Boxは立方体や直方体などを作成することができるタイプのコンポーネントです。Cylinderは、円筒形の形状コンポーネントで、設定によっては円錐形の形状を作成することができます。Planeは、フラットな平面コンポーネントです。

ちなみに、Modelは空間に配置するコンポーネントだけど、別の3Dソフトなどで作成したモデルデータを使用するためのもので、今回は一旦スキップします。

これ以外にもライティングに関するコンポーネントも存在しますが、実際に使うところで解説していきます。

では、今回は実際に3Dプリミティブコンポーネントを、シーンにいろいろと配置し、様々なライティングをしてみましょう。

3Dプリミティブコンポーネントを配置してみよう

さて、これから3Dプリミティブコンポーネントを配置していろいろ実験していくわけですが、その前に、何か仮想現実の実験ぽくするための会場づくりをしましょう。React VRで何も背景に敷かない場合、漆黒の空間に単なる立方体が浮かぶことになります。それでは何も趣がないですよね。

ということで、VR空間をホロデッキ（アメリカのTVドラマ・映画のスタートレックに登場するホログラフィックルーム）として定義してみましょう。ホロデッキってなあに？って方は、Wikipediaのホロデッキに関する説明と写真をご覧ください。

ホロデッキは、黒い部屋に、方眼紙のような感じで黄色の線が入っている部屋です。これを実現するためにPanoコンポーネントを使います。Panoコンポーネントは360度写真を閲覧するために前回使いましたが、Panoコンポーネントはもう一つ使い方があって、6つのテクスチャを配列で渡してあげると、立方体のの内側にテクスチャが貼られた部屋を作ることができます。

では、まず新規React VRプロジェクトを作成するところから始めてみましょう。

1. 新規React VRプロジェクトを作成し、Panoコンポーネントで部屋を作る

まずはなにはともあれ、新規ReactVRプロジェクトを立ち上げましょう。名前はHello3DObjectとしましょう。

$ react-vr init Hello3DObject
$ cd Hello3DObject

続いて、Panoコンポーネントを使って、テクスチャが貼られた立方体の空間を作っていきます。プロジェクトルートにある「index.vr.js」のViewコンポーネント以下を編集していきます。今回Panoコンポーネントの内側には、前後左右上下の6面にテクスチャを貼ります。貼るテクスチャは、フリーのグリッドパターン – 20 Seamless Photoshop Grid Patternsのうち一枚をPhotoShopで修正した格子状のものです。

ホロデッキっぽいテクスチャ画像

こちらからダウンロードください

上記リンク先でダウンロードしたファイルを解凍し、中に入っている「holodeck.png」を「static_assets」ディレクトリ以下に配置します。

Panoコンポーネントに対して六面にテクスチャを貼るには、source属性にuriプロパティを持ったオブジェクトを6つ含んだ配列を渡します。asset関数は、ファイル名を渡すと{uri: パス名}の形式で返るので、asset関数をそのままsource属性へ渡せばいいことになります。

さて、まずはここで一旦ビルドしてみましょう。

$ npm start

ブラウザで、http://localhost:8081/vr/を開いてみましょう。スタートレックのホロデッキのような空間が出現したと思います。テクスチャのつなぎ目とか細かい点はサンプルということでご容赦ください。

ホロデッキに入った

2. `Box`をいくつか並べて配置してみる

ホロデッキ的な空間が出来たところで、Boxコンポーネントを配置してみましょう。Boxコンポーネントはシンプルなコンポーネントですが、よくありがちな失敗として、Boxコンポーネントをインポートし忘れるということがあります。これから登場するCylinderやSphereも同様にimportし忘れがないようにしましょう。

import {
  AppRegistry,
  asset,
  Pano,
  Box,
  Cylinder,
  Sphere,
  View,
} from 'react-vr';

では、Boxコンポーネントを目の前に3つ配置してみます。Panoコンポーネントの下にBoxコンポーネントを下記のように3つ記述します。

dimWidth、dimHeight、dimDepthの各属性は、幅、高さ、奥行きのサイズに相当します。この比率を変えることで、立方体や柱のようなもの、平らな板のようなものを作り出すことができます。

また、style属性で色が定義されていることもわかります。3つの色は右から青、赤、緑の原色です。style属性にtransformというプロパティが定義されていますが、ここで配置を指定しています。位置関係の変形は、translateで指定します。配列で指定し、左からX座標、Y座標、Z座標となります。Z座標は奥行きです。ちなみにマイナスの数値になればなるほど初期状態の位置から奥へ向かって移動する形になります。

litという属性がありますが、こちらはライティングに関するプロパティで、後ほど解説します。

Boxコンポーネントを3つ配置した

Boxコンポーネントを配置できたところで、他のコンポーネントを配置していきましょう!

3. `Box`だけでなく、`Cylinder`や`Sphere`を配置してみる

さて、今度はCylinderやSphereもシーンに配置してみます。一旦Boxコンポーネントのパートで作った3つのボックスは消してしまいましょう。勢いあまってホロデッキっぽくしているPanoまで消さないようにしてくださいね、情感がなくなってしまいますので。

まず、Cylinderコンポーネントについて。Cylinder、つまりカタカナでいうシリンダーは、円筒を意味しますが、Cylinderコンポーネントはプロパティ次第で円錐形にもなります。ポイントはradiusTopとradiusBottomで、radiusTopが小さければ山のようになっていき、radiusBottomが大きければ、ラッパのような形状になっていきます。どちらの値も等しい時だけ円筒形になります。

続いてSphereコンポーネントですが、Sphereというのは球体です。Sphereコンポーネントはなかなか使い出があるコンポーネントで、四角形や円筒形を使う機会はそれほどないかもしれませんが、球体というのはテクスチャを貼り付ければ惑星になったりと応用性が高い3Dプリミティブコンポーネントです。下記のようにシーンに配置してみました。それぞれ一つずつ配置しています。SphereコンポーネントにはwidthSegmentsとheightSegmentsというプロパティがありますが、これは球体を構成するセグメント（分割数）を定義しています。この数が増えるとなめらかな球体へ近づいていきます。

今回、ちょっと配置に工夫をしています。translateプロパティの値を変更していて、手前に立方体、奥に行くにしたがって円筒形、球体と並ぶようにしています。これで3Dプリミティブの配置は完了したわけですが、何かもの足りません。のっぺりしていて立体感がないのです。ということで、この3Dオブジェクトに光を当てていきましょう。

配置された、球体、円錐形、立方体

4. 3Dプリミティブオブジェクトに光を当ててみる

React VRでライティング（照明）を行うには、用意されている4つのコンポーネントのいずれかもしくは複数の組み合わせを使用します。

用意されているReact VRコンポーネントは下記の4つです。

AmbientLight
DirectionalLight
PointLight
SpotLight

AmbientLightは、環境光と呼ばれるもので、シーン全体に均一な影響を与える光源を定義します。これは無指向性で、すべてのオブジェクトが等しく明るくなります。

DirectionalLightは、指向性があるが、距離による明かりの減光は発生しないタイプの光源です。太陽の明かりのようなものと言えます。

PointLightは、ある一点から発生する光源で、距離による減光もあります。見えない間接照明のようなものと言えるでしょう。

SpotLightは、文字通りスポットライトのような特性を持つととらえられる光源です。指向性があり、距離による範囲の拡大と減光があります。

20程度のコンポーネントしか用意されていないReact VRにおいて、ライティング関係だけで、4つもコンポーネントが用意されているのは、一つはVRにおいてそれだけ重要であるということと、React VRが使用しているThree.jsにおいても手厚いサポートがされていること、そしておそらくはこうしたライティング関係は、カスタムコンポーネントとしての作成が困難であろうことなどが推測されます。

まずは普通の光を当てましょう。太陽のように上から降り注ぐ普通の明かりです。こういった明かりは、DirectionalLightコンポーネントを使うことで実現できます。

では、まず準備段階として、先ほど作成した3種類の3Dプリミティブオブジェクトが持っているlitプロパティをtrueにしてみましょう。これで光源の影響を受けるようになります。試しにtrueにした段階で、ブラウザをリロードしてみてください。まだ光が当たっていないため、真っ黒のオブジェクトになってしまったと思います。

真っ黒の3Dプリミティブオブジェクト

続いて、DirectionalLightコンポーネントを配置します。Panoコンポーネントの下あたりでOKです。こんな感じにします。(importを忘れずに)


            
            {/* Lighting */}

intensityプロパティは、光の強度を設定します。また、光源にも色をつけることができ、スタイルシートで定義します。transformプロパティでrotateXの設定をしていますが、これは、ちょっと斜め前方から光を当てたいからです。本当の真上からあたる光は、側面すら陰になってしまい、あまり面白みはありません。

DirectionalLightを設定したシーン

次はPointLightコンポーネントを配置してみましょう。PointLightは点光源なので、任意の位置に配置すると、その周囲を照らしてくれます。うまく使うと印象的な効果を与えることができます。さて、今回は、PointLightをちょっと手前に配置し、しかもちょっと青系の光として照らしてみましょう。どんな感じになるでしょうか。

DirectionalLightコンポーネントの下に、下記のようにPointLightコンポーネントを設置します。


            
            {/* Lighting */}

intensityプロパティはちょっと強めの5にしました。色は青色、そして位置はちょっと手前でちょっと下から照らす感じにしています。

すると、こんな感じで、青い光がオブジェクトに反射するような雰囲気になりました。ちょっとムーディで怪しげですね。

PointLightを反映させた3Dプリミティブオブジェクト

さて、これで終了にしてもいいのですが、全体的にちょっと暗いですよね、そこで光の調整をしたいと思います。

ではAmbientLightコンポーネントを配置してみましょう。AmbientLightは環境光で、全てのオブジェクトに均等に光を当てるという機能を持っています。AmbientLightコンポーネントを使うことで、全体的な光の加減を微調整することもできます。


            
            {/* Lighting */}

intensityプロパティは、ほんの少しだけ設定しました。これでブラウザをリロードしてみると、ほんのりと明るくなったことがわかると思います。

AmbientLightを反映させた3Dプリミティブオブジェクト

いろいろな形状のものを置き、ライティングを終えたところで、こんな風に思った方はいないでしょうか。
「現実世界で立方体や球なんて、積み木とかにしか存在しないじゃないか！」
と。

四角や丸を置くためにVRを始めたわけじゃないんだという気持ちはよくわかりますので、次回は応用編として既存の3DモデルをReact VRで扱う方法について解説していきます。

プログラミング – HTML5Experts.jp

Webブラウザからハードウェアにアクセス！WebUSB APIを使ってログイン認証を実装してみよう

WebUSB APIとは

WebUSB APIの活用シーン

本格利用はこれから

WebUSB APIを使ってログイン認証を実装してみよう

用意するもの

手順1：Chromeのバージョンを確認する

手順2：ログインページを作る

ログインのイベントを作成する

USBデバイスにアクセスして識別情報を取得する

ログイン機能を試してみよう

まとめ

「テクニックは語りません」竹洞先生に聞く、本気のWebパフォーマンス道

民法（債権法）が改正されて、何が変わる？

「品質保証」がウェブ業界を変える

ウェブサイトの品質を決める3つの要素

ウェブサイトの品質を高めるための心構え

全てを変える、5Gネットワーク

WebGLの現状と未来を、Grimoire.jsを生んだスーパークリエータに聞いてきた！

WebGLの現状

ランタイム向け3Dデータフォーマット「glTF」

頂点データ専用の圧縮形式「draco」

WebGLの未来

Grimoire.jsは、WebGLをWebエンジニアにとっての「筆」にする

WebAssemblyの基礎から最新動向まで、@chikoskiに聞いてきた！

WebAssemblyとは何か？

WASMへの対応状況

WASMを使う

WASMはどう使われていくか

WASMのこれから

Vue.js製フレームワークNuxt.jsではじめるUniversalアプリケーション開発

Nuxt.jsとは？

Nuxt.jsでできること

SSR基盤としての優秀さ

モダンなVue.jsによる開発環境の提供

ミドルウェアやasyncDataなどの拡張システムの提供

Nuxt.jsを利用すべきシーン

メディアやSNS 、求人サイトなどをSPAとして立ち上げる場合・運用している場合

技術系ドキュメントの運営

いわゆる一般的なホームページ制作

Nuxt.jsをはじめる

プロジェクトのセットアップと実行

APIからデータを取得してSSRするページを作成する

ルーティングを追加する

ページ内でHTTPリクエストを行い、結果を取得する

{{user.name}}

実際に表示をみてみる

おわりに

参考資料

ニュースタブ新設で月間アクティブユーザー数が5900万人を突破した「LINE NEWS」の開発技術と体制を聞いてきた！

今回お話を聞いた「LINE NEWS」開発チームの皆さん

なぜ、ニュースタブはWebViewなの？

JavaとPerlでサーバー管理

React.jsを選択した背景は？

足りない開発ツールはどんどん作る

秒間2万のアクセスを捌くパフォーマンス

タスク管理・チーム間の共有ツールは？

急成長するサービスと開発体制に合った環境を構築

日本最大級のHTTP/2移行、TLS 1.3、そしてQUICについてヤフーに聞いてみた！

日本最大級のHTTPS & HTTP/2化案件の実際

HTTP/2化は正直、「エイヤ」でやった

「HTTP/2化で速くなったかは…正直わかりません(笑)」

HTTP/2がサーバの処理負荷を下げる？

HTTP/2のさらに先へ。新しいプロトコルを知る – TLS 1.3とは？

QUICという「プラットフォーム」の可能性

「最近のWebパフォーマンス改善について知っておきたいコト」についてあほむに聞いてきた

パフォーマンスはなぜ重要か？を違う切り口から伝える

ページロードパフォーマンスの改善テクニック

ランタイムパフォーマンスの改善テクニック

パフォーマンス改善を「開発者の自己満足」で終わらせないために

React VRでここまでできる！VRでジオラマを作ろう

新規プロジェクトの作成

用意するもの

STEP 1. まずは、ジオラマのベースづくりから

STEP 2. 3Dモデリングデータを配置しよう!

STEP 3. ライティングしてトラックを美しく!

STEP 4. トラックをゆっくりと回転させてみる

Reactといえばコンポーネント！React VRの3Dプリミティブコンポーネントを探る、触る

いろいろなタイプのReact VR Components

2. `Box`をいくつか並べて配置してみる

3. `Box`だけでなく、`Cylinder`や`Sphere`を配置してみる