講演資料


講義資料スライドの表紙

講義資料スライドの表紙です。スライド画像、または下の要約文中の青いページ番号リンクをクリックすると、別のタブで無駄なノイズのない、純粋なPDFビューア画面が起動し、指定されたページへ直接ジャンプして快適に閲覧できます。

全体概要

本セミナーは、2013年という転換期において「Webアプリとは何か」という問いを根本から問い直し、AndroidとChromeの統合という歴史的な出来事が開発者にとって何を意味するかを探求するものです。[p.1]

PCの時代が終わりを迎え、タブレットの出荷台数が倍増する中 [p.6]、インターネットとWebアプリの世界は「クラウドとクラウド・デバイス」の時代へと劇的に移行しました。[p.4] この変化を貫く核心的な問いは、「従来のサーバーサイドWebアプリという形式は、新しい時代に適合しているか」というものです。

GoogleのAndroid標準ブラウザーのHTML5対応の遅れ [p.120] と、Chromeチームの先進的な取り組み [p.126] という二つの現実の間で、Googleは明確な選択を迫られました。AndroidへのChrome標準ブラウザー搭載と、Packaged Web Appの導入という道です。[p.136] これは単なる技術的更新ではなく、サーバーとクライアントの役割を根本的に見直す「Rich Client / Thin Server Architecture」[p.111] という思想的転換を伴うものです。

2005年のAjaxの登場以来、クライアントに送られるJavaScriptのサイズはこの一年で倍増し [p.21]、サーバーは全処理の70%以上をHTMLデータの生成に費やすという非効率な構造が露わになっています。[p.63] Facebookが「ネイティブに対してHTML5に賭けすぎた」と認めたように [p.53]、単純なサーバーサイドWebアプリとHTML5の結合という期待は、そのままの形では実現されませんでした。

その解答として浮かび上がるのが「Packaged Web App」です。HTML5、CSS、JavaScriptというWeb技術を用いながら、Offline enabled by default [p.78]、Cloud enabled by default [p.78] という二つの原則を同時に実現し、デバイスのハードウェアリソースへのアクセスを可能とする新しいアプリ形態です。Chromeはすでにそのランタイム環境を具体化しており [p.152]、AndroidとChromeの統合は、このPackaged Web Appの最大のプラットフォームをAndroidが担う未来を予感させます。[p.136]

日本のAndroid開発者にとって、Google PlayでアメリカをしのいだNo.1の実績 [p.208] を活かしつつ、新しいスタイルの開発に備えることが急務であり、本セミナーはその羅針盤となることを目指しています。[p.219]

講義のロードマップ

■ Part 1: クラウドとクラウド・デバイスとWeb

  • この部の核心:

「インターネットとPC」の時代から「クラウドとクラウド・デバイス」の時代への移行という大きな歴史的文脈を整理し、Webとサーバーサイドのアプリケーション開発の現状と限界を明らかにします。PCの出荷台数が減少しタブレットが急増する現実 [p.6] を出発点に、なぜ今、Webアプリの見直しが不可避なのかを論じます。

  • 論理展開:
  • 2004年のGoogle上場から2008年のAndroid登場まで、クラウドとクラウド・デバイスの時代の始動を年表で確認する。[p.5]
  • Webの第一世代（Static Web）から第四世代（Real-Time Responsive Web）への進化を整理し、現在地を定める。[p.10]
  • W3C.orgのホームページがこの10年で6倍以上に膨張し、サーバーから送出されるデータの半分がプログラムになったという具体的事実で問題を可視化する。[p.19], [p.20]
  • 3-tier WebアプリのScale-outにおけるBottle NeckとSession管理の難しさを構造的に解説する。[p.25], [p.26], [p.27]

■ Part 2: Webを取り巻く環境の変化

  • この部の核心:

クラウド・デバイスの飛躍的拡大、マシン性能の向上、ネットワークトラフィックの増大、そしてWeb技術に接するユーザーの増大という四つの環境変化を論じます。特に、個人が携帯するデバイスが10年前のサーバー・マシンを凌駕する性能を持つに至った事実 [p.37] が、サーバーとクライアントの役割の見直しを促す根拠として提示されます。

  • 論理展開:
  • Pentium 4からCore i7まで、CPUが20〜30倍以上高速化した事実と、8コアのAndroid端末の登場を示す。[p.33], [p.35], [p.36]
  • AJAXがHTTPのリソースを「最後の血の一滴まで搾り取った」という表現で、ネットワーク限界問題を提起する。[p.60]
  • モバイルデバイス固有の「Fast Dormancy」と「Signaling Burst」がネットワーク帯域にかける特殊な負荷を解説する。[p.42], [p.43]

■ Part 3: 「Webアプリ」の変化と三つの見直し

  • この部の核心:

Webアプリがサーバーサイドからクライアントサイドへと分岐しつつあるという現象の背景にある、三つの根本的な見直し――Webプロトコル、サーバーとクライアントの役割、開発言語――を分析します。Thin Server Architectureという2008年に提唱されたコンセプトが今こそ照明を浴びている理由を明らかにします。

  • 論理展開:
  • サーバーの最も重い仕事がHTMLデータ生成（70%以上）であり、クライアントの能力が相対的に過小活用されているという構造的矛盾を指摘する。[p.63], [p.64]
  • Thin Server Architectureは「全てのプレゼンテーション層ロジックをサーバーからクライアントのJavaScriptへ移す」というコンセプトであり、(1)サーバーがビジネスロジックに集中、(2)アプリの複雑さ低減、(3)データ指向の通信という三つの利得をもたらすと定義する。[p.114], [p.115]
  • JavaScriptが事実上のWebアプリ開発の標準言語となり、Lingua Francaとして「Write Once, Run Everywhere」を実現する最有力候補であると論じる。[p.73]

■ Part 4: Packaged Web Appの全体像

  • この部の核心:

Application Cache、Widget、Packaged Web Appという三つのモバイルWeb技術を比較整理し、それぞれの特徴と位置づけを明確にします。Firefox OSのPackaged ApplicationとHosted Applicationの二形態 [p.101]、TizenのWidget実装 [p.91] といった具体的な先行実装を参照しながら、Packaged Web Appの本質的な特徴を規定します。

  • 論理展開:
  • Application Cacheはサーバーサイド型の延長であり、manifestファイルで宣言したリソースをキャッシュする仕組みである。[p.80], [p.81]
  • W3C勧告のWidgetはZIPファイルとXML構成ファイルによる配布形式で、デフォルトのセキュリティポリシーは「全ネットワークアクセスのブロック」である。[p.84]
  • Packaged Web Appの特徴は「Offline enabled by default」「Cloud enabled by default」「Package形式での配布」「Contents Security Policy」の四点に集約される。[p.78]
  • JavaScript MVC Frameworksの台頭（Backbone.js、AngularJSなど）はThin Server Architecture思想の実装として位置づけられる。[p.110]

■ Part 5: AndroidとChromeの統合

  • この部の核心:

AndroidのHTML5対応の遅れという現実と、ChromeのHTML5テストスコアでトップを走る先進性 [p.129] という二つの事実を対比させ、Googleが両プラットフォームを統合する必然性を論じます。2012年6月のChrome for Androidリリースから2013年のConsumer Preview展開まで [p.141]、統合の進捗を時系列で追います。

  • 論理展開:
  • Android 4.0のHTML5テストスコアが297点であるのに対し、Chrome 25は417点と大差がある事実を示す。[p.122], [p.123]
  • Chromeが動くAndroid（バージョン4.0以上）の割合がこの一年半で倍増し5割に近づいていることを確認する。[p.125]
  • Androidの開発責任者Andy RubinがChrome担当のSundar Pichaiに交代したという組織的な意思決定が統合の方向性を象徴する。[p.134]
  • AndroidのPlay MarketとChromeのWeb Storeの統合が最終的な帰結であり、そこで販売されるアプリはWindows、Mac、Linuxでも動作することになる。[p.142]

■ Part 6: Chrome Packaged Appの開発スタイル

  • この部の核心:

Chrome Packaged Appの具体的な開発スタイルとして「Offline First」「Cloud enabled」「Contents Security Policy」の三原則を詳述します。`chrome.app.runtime`がJava VMやFlashのruntimeと同様にアプリ実行の核心であること [p.152]、そして`chrome.app.window`はWebブラウザーではないという根本的な設計思想を解説します。

  • 論理展開:
  • Offline Firstの実装手段として、Chrome Storage API（sync: 100KB、local: 5MB）、IndexDB、Chrome FileSystem API、Chrome SyncFileSystem APIの四種類のローカルストレージを比較する。[p.163], [p.169]
  • `chrome.syncFileSystem`によりGoogle Driveとの自動同期が可能であり、`onFileStatusChanged`イベントで`synced`/`pending`/`conflicting`の状態管理を行う。[p.175], [p.176], [p.177]
  • Google Cloud Messaging（GCM）によるメッセージのPush配信の仕組みとして、App ID、Channel ID、OAuth 2.0トークンを組み合わせた認証フローを解説する。[p.179], [p.180], [p.183]
  • TCPおよびUDPソケットを`chrome.socket`APIで直接利用できるため、HTTPに依存しない通信が可能となる。[p.184], [p.186], [p.187]

■ Part 7: Contents Security PolicyとXSS対策

  • この部の核心:

Webの脆弱性であるCode InjectionとCross Site Scripting（XSS）の原理を整理し、Packaged Web Appのセキュリティモデルの中核であるContents Security Policy（CSP）がなぜ「インライン・コードの全面禁止」という強硬な手段を取るのかを論じます。100以上の攻撃手法が存在するXSSの現実 [p.192], [p.193] を前に、ブラウザー単独での判断の限界を認め、ポリシーによる構造的解決を採用した設計思想を評価します。

  • 論理展開:
  • インラインJavaScriptと`eval`の禁止がCSPの二大柱であり、コードをHTMLから分離した外部ファイルに移すことで攻撃面を根本的に削減する。[p.155], [p.196], [p.197]
  • `script-src`、`default-src`、`frame-src`などのディレクティブとソースリスト指定子（`none`、`self`、`unsafe-inline`、`sandbox`）の組み合わせでポリシーを宣言する。[p.194], [p.195]
  • Same Origin Policyとの関係で、Packaged Web Appのセキュリティモデルが一貫した設計思想に基づいていることを確認する。[p.198]

■ Part 8: AndroidとChromeの統合と開発者への提言

  • この部の核心:

Androidのグローバルシェア68〜72%という圧倒的な事実 [p.205], [p.206] と、Google Playの売り上げで日本がアメリカを抜いて世界一になった実績 [p.208] を踏まえ、日本のAndroid開発者が今取るべき行動を具体的に提言します。Native開発スキルの向上とPackaged Web App開発の準備を同時に進め、グローバル市場を狙うことが課題として示されます。

  • 論理展開:
  • JavaネイティブアプリとPackaged Web Appの併存時代がしばらく続くが、一回の開発でマルチOS・マルチスクリーンに対応できる優位性は開発者の間で確実に広がる。[p.200], [p.203]
  • Packaged Web Appは「単なるOfflineアプリ」ではなく「Cloud enabled by default」であり、クラウドサービスと一体となったアプリ/サービスの構想が求められる。[p.220]
  • 「AndroidとHTML5」全国縦断セミナーとして東京、会津若松、仙台、広島、大阪、沖縄など全国で開催し、会員への準備を広く呼びかける。[p.221], [p.222]
  • 2015年までにさらに10億人がモバイルでインターネットに参入する「Next Billion」市場 [p.213] を見据え、Packaged Web Appの分野でもNativeアプリと同様に世界一を目指すことを宣言する。[p.219]