静かなることWWDC2016のごとく
フロリダ銃乱射事件 の犠牲者への黙祷から始まった今年2016年のWWDCは、例年にもまして静かでした。ハードウェアはおろか、ソフトウェアも毎年恒例のOSアップデートを除けば「新製品」はなし。macO はiOSが10になることを考えれば、OS X（オーエステン）という名前をそのままにしておけないのは自明というものでしょう。Apple製品用のOSにマッチする正規表現も((watch¦tv¦i)OS¦OS ?X)だったのが(watch¦mac¦tv¦i)OSとなってずいぶんとすっきりしましたが、あくまでヴァージョンは“ 10.12” 。灰色のバックグラウンドにアスキーアートのリンゴというロゴは、そんな地味なWWDCを実によく象徴しています。開発者ではないプレスの皆さんはさぞ退屈されたのではないでしょうか。
しかし本誌の読者にとって、WWDC2016はあくびしてスルーするにはあまりに重要な知見に満ちています。
Learn Different＝Differencial Privacy？
その最たるのが、AppleのAIに対する姿勢です。キーノートでも“ Deep Learning” というバズワードが、ご丁寧にもLSTM というアルゴリズムの名前まで含めて登場しましたが、重要なのは「Appleも取り組んでますよ」ということではなく、Appleは何をしないのかというメッセージです。
OS X 改めmacOSではずいぶん前から標準搭載されていた顔認識が、iOS 10でついに標準装備されます。それも顔だけでなく背景なども含めた包括的な画像認識という形で。そこで使われるのがAIで、そのこと自体はすでにGoogle PhotoやFacebookなどを通して日常触れているであろう本誌の読者にとってはこれまた「何をいまさら」といったところでしょう。問題は「何をやるか」ではなく「どこでやるか」 。
Appleは、端末にそれをやらせると言っています。クラウドではなくて。
これは2つの点においてかなり不利な選択です。1つは処理能力。クラウドであれば必要な処理能力を必要なときに必要なだけ増やせますが、端末はそうも行きません。すでにiPhone 6/SEやiPad ProがMacBookに匹敵する処理能力を備えている以上、現在のMacのPhotoアプリケーションに標準装備されている程度の画像認識処理であれば問題なくそれをこなしそうですが、同様のことをたとえば動画に対して行うとしたら？
しかし、それ以上に重要なのは、データの蓄積。プログラムの質はソースコードが書かれた時点で決定しますが、AIの質を決めるのは、データの質量。どれほど優れた母と父のもとに生まれた赤子でも生まれたてでは母国語すら話せないように、どれほど計算資源を用意しようが生まれたてのAIはそれ以上に非力です。生まれで決まるプログラムに対し、育ちで決まるAIというのはその点においても「ウェットウェア」たる我々に似ているのですが、そのAIを育てるデータが「オレ」の分しかないのと「オレタチ」全員分あるのでは勝負にすらならないように感じられます。
しかしプライバシーを考慮に入れると、その印象は逆転します。Facebookでは他人が撮った写真に自分がタグづけされていることがしばしばあって、友人同士のパーティの写真だとかなり重宝するのですが、もし同じことが街角の監視カメラで行われていたとしたら？ GoogleもFacebookも当然のごとく「悪用はしない」と主張していますが、それを証明しようとしても悪魔の証明になってしまいます。何しろすでに彼らの手元でデータは解析されているのですから。ちなみに、単にデータを保管している場合は「盗み見していない」証明は簡単です。伝送系路とストレージが暗号化されていることさえ示せば良いのですから。クラウドにデータを上げるのとクラウドでデータを処理することには本質的な違いがあるのです[1] 。
パーソナルコンピューター製造販売会社として産声を上げたAppleは、今後も変わらずパーソナルということにおいて首尾一貫しています。
しかし、プライバシーというのは“ All or nothing” なものなのでしょうか？ いくらクラウドAIが不安でも、パーソナルAIだけでは不便なのは前述のとおり。両者のいいところ取りはできないのでしょうか？
それを成そうというのが、“ differencial privacy” 。The Vergeは“ probably the most bewildering part of Apple’s WWDC Keynote” とまどったのは筆者も同様です。微分プライバシー？ 差分プライバシー？
1つの例として、文字変換を挙げます。かな漢字変換のクラウド化は今や日常茶飯事となっていますが、どうすれば文章をクラウド側にさらさずに実現できるでしょうか？
「誰が」変換しているのかは知らせずに、「 何を」変換しているかだけ知らせて、その「何」だけを集めて統計処理し、変換中の「みんな」に候補全部を送ってしまえばいい。iOS 10には欧文からの絵文字変換も搭載されるのですが、まさにそのように実装されています。
プライバシーの本質は、「 誰」と「何」の紐付けなのですから、この紐さえ切ってしまえば、「 何」だけクラウド処理するようにすればいいのではないか。
> differential privacy aims to provide means to maximize the accuracy of queries from statistical databases while minimizing the chances of identifying its records
「記録自体を特定される可能性を最小化しつつ、統計的情報精度を最大化する」という言葉の定義に確かに合致しています。
[1] 「iTunes Matchはどうよ？」という読者は鋭い。確かに「パーソナルデータをクラウド処理」しているように見えます。が、マッチした楽曲自体は、楽曲の著作権保持者が使用権をライセンスしている意味でパーソナルなデータではなく、パーソナルなのはマッチしない楽曲と楽曲のリストというメタデータというのがポイントです。
Virtual Private Cloud――もう1つの方法
誰かが特定できる情報はなるべく端末で処理し、誰かが特定できないようにできる情報は（differencial privacyで）クラウド処理する。それが、Appleのクラウドに対する方針ということでよさそうです。実にAppleらしい落としどころではありますが、不満もあります。たとえばSiri。現在Siriは、iPhoneやiPadやApple TVやApple Watch（さらにmacOSからはMac）の持ち主以外の声にも反応してしまいますが、differencial privacyの観点からはそれは当然ということになります。声色を聞き分けられるとしたら、クラウドの中のSiriが「誰」を知っているということなのですから。
differencial privacy以外に、プライバシーとクラウドのいいとこ取りをする方法はないのでしょうか？
たとえば、こんな方法もありえます。クラウド処理したいユーザの問い合わせがきたら、その都度クラウド上でそのユーザ専用の仮想マシンインスタンスを立ち上げるのです。その際仮想マシンのイメージをユーザごとに暗号化しておけば、クラウド提供者はユーザのことをいっさい知ることなくユーザにクラウド資源を提供できます。
しかし理論的に可能なこの方法は、現在のマシン仮想化ではまだ高くつき過ぎるかもしれません。Siriに話しかける都度、仮想マシンが起動しては会話が終わるやいなやシャットダウンというのは確かに重過ぎるように感じます。しかし仮想マシンではなくコンテナであれば、セッションごとに起動しては終了しても十分な速度を確保できるかもしれません。実際Webブラウザでコードを実行する、いわゆるWeb REPLサービスの多くは、IBM Swift Sandbox を含めそのように実装されています。
しかし十分なパフォーマンスだけではこの方法を導入する十分な理由にはなりません。この方法は「こちら側」のAppleデバイスごとに「あちら側」にももう1台のデバイスを用意するようなものですから、クラウドという名の（見かけ上は）1台のデバイスを共有するよりはるかにコストがかかります。AWSやAzureやGoogle Cloud Platformはそれ自体がれっきとした商品なのに、基本「ハードウェアのおまけ」であるiCloudで現時点でそこまでできるかは疑問ですが、損益分岐点を下回るのは時間の問題でしょう。
しかしどのような実装を採用するにせよ、その生い立ちから「パーソナル」を売り物にしてきたAppleが、「 ネットワーク」を売り物にしている他者よりもプライバシーを気にするのは自然かつ必然な帰結だと筆者は感じます。
Swift Playground for iPad
「新製品なき」WWDCにおいて、もっともそれに近いのがSwift Playground for iPadでしょう（図1 ） 。Xcode for iPadでないところが、実にAppleらしい。「 タブレットでコードを書く」というのであれば、タブレットとPCを統合しようとした――そしてWindows 8で痛い目にあった――Windowsタブレットですでに実現しているとも言えます。C#が好きなら、今すぐSurface Bookを買ってXamarin三昧すべきだと筆者でも認めるのにやぶさかではないのですが、しかしそこにおける開発環境は、あくまでPCであってタブレットではないというのもたしかです。
図1 Swift Playground for iPadでは、Swift Playground for iPadは何なのか。「 enchantMOON じゃん！」と読者の皆さんにはお馴染みの清水亮さんの心の声が聞こえてきました。ヴィジュアルな言語ではないSwiftを、ヴィジュアルなScratch やMOONBlock のように動かせたり、課題がiBooksのように本棚に登録されていたり、変数名をタップするとその変数のプロパティが補完されたり……。これなら、キーボードがない環境でもかなり使えそうです。
Swift Playground for iPadを見てしまうと、欲も出てきます。JavaScriptCoreに相当するSwiftランタイムがモジュール提供されないか、と。実はiBooksは、すでにJavaScriptの実行をJavaScriptCore経由でサポートしています。これと同様のことができれば、ブラウザで<script lang="swift">とかまではあと一歩ですし、shell scriptを超えた真のスクリプト言語にSwiftはなり得るでしょう。
Swift 2.3からSwift 3へ
なんだかSwift 3の話題に入る前に誌面が尽きてしまいそうですが、一番重要なことだけ今号で。Swiftの次のバージョンは、3だけではありません。2.3も出ます。Xcode 8は、どちらもサポートしています（図2 ） 。
図2 Xcode 8はSwift 2.3もSwift 3もサポートする で、Swift 2.3とは何かというと、Swift 2.2＋New SDKとのこと。Swift 1からSwift 2への移行は問答無用だったのが、Swift 2 から3への移行は、プロジェクト全体ではなくソースファイルごとに段階的に行えます（図3 ） 。
図3 Swift 2からSwift 3へのコード変換あと、Swift 2.2から#if swift(>=version)が使えるので、ソース内での切り替えも一応できます。
func xyz(x:Double, y:Double, z:Double)->Double {
return x*y*z
}
#if swift(>=3)
xyz(x:2, y:3, z:4) // more swifty
#else
xyz(2, y:3, z:4) // like Objective-C
#endif
そのようにしたのは、Swiftの資産が往時より格段に増えたからでしょう。過去をバッサリ捨てるにはあまりにも。Xcode 7登場時にはいまだObjective-C主でSwift従だったのが、今やすっかり逆転している感があります。Swift 2のコードベースは、すでに技術的遺産となりつつあるのです。その遺産を段階的に継承できるという点で、Swift 2.3の発表は筆者にとって今回のWWDCでもっともうれしい誤算でした。
次回はいよいよSwift 3で何が変わったかを解説します。
第1特集 MySQL アプリ開発者の必修5科目 不意なトラブルに困らないためのRDB基礎知識 第2特集 「知りたい」「 使いたい」「 発信したい」をかなえる OSSソースコードリーディングのススメ 特別企画 企業のシステムを支えるOSとエコシステムの全貌 ［特別企画］Red Hat Enterprise Linux 9最新ガイド 短期連載 今さら聞けないSSH ［前編］リモートログインとコマンドの実行 短期連載 MySQLで学ぶ文字コード ［最終回］文字コードのハマりどころTips集 短期連載 新生「Ansible」徹底解説 ［4］Playbookの実行環境（基礎編）
