インストールなきアプリの時代

ボタンの色を一つ変えるのに必要なもの

機能を一つ直したとしよう。ボタンの色を変え、誤字を直し、誤った計算ロジックを一行手直しした。コードの変更量は五行ほど。作業そのものは十分で終わる。

ところが、その十分の修正がユーザーの画面に届くまでに何が起きるかを思い浮かべてみよう。

まずビルドする。アプリ全体を再びコンパイルする。次にパッケージングして署名する。ストアに上げる。審査を待つ — 運がよければ一日、たいていは二、三日。却下されたら理由を読み、直して再提出する。承認が下りれば配信が始まる。そしてここで終わりではない。ユーザーの相当数はしばらく旧バージョンを使う。 自動更新を切っている人、Wi-Fiを待つ人、更新通知をただ閉じてしまった人。あなたが直したその誤字は、早ければ数日、遅ければ数週間かけてユーザーにじわじわと届く。

ボタンの色を一つ変えるのに、この全工程が必要だった。そして私たちはこれを数十年のあいだ当然の費用として受け入れてきた。モバイルアプリであれデスクトッププログラムであれ、「直した」と「ユーザーが直ったものを見る」のあいだには、いつもこの長い鎖があった。

この文章は、その鎖がなぜ存在するのか、どうして私たちがそこに閉じ込められたのか、そしてそれが必然ではなかったことを語る。長い文章になるだろう。創刊Volの最初の文章として、この雑誌の立つ場所をはっきりさせておきたいからだ。

私たちはどうしてこの鎖に閉じ込められたか

この鎖は初めからあったわけではない。短く系譜を辿ってみよう。今の息苦しさがどこで固まったのかを知れば、何をほどくべきかも明らかになる。

第一世代 — パッケージソフトウェア。 プログラムをCDやフロッピーに収めて売っていた時代。画面もロジックも、すべてユーザーのコンピュータにインストールされた。直すには? 新バージョンをプレスして再配布し、ユーザーが再びインストールしなければならなかった。更新は四半期に一度、運が悪ければ年単位だった。鎖の原型がここで生まれた — プログラムの本体がユーザーの機器にある。

第二世代 — ウェブ。 ブラウザがすべてを変えた。画面をサーバーが送り、ブラウザはそれを描くだけだった。直せば? 次の訪問者はただちに新しい画面を見る。インストールも更新もなかった。鎖が初めて断ち切られた瞬間だった。私たちは自由になった — 文書を扱うかぎりにおいて。

第三世代 — アプリストア。 スマートフォンが登場すると流れは逆戻りした。カメラ、GPS、プッシュ通知、加速度センサー、オフライン動作、なめらかな六十フレームのアニメーション — ウェブが与えられなかったネイティブの能力のために、私たちは再び機器にインストールされるアプリへ戻った。そして今度は一枚さらに重なった。ストアという関門、そして審査。鎖は第一世代より長くなったまま再び固まった。

ここで核心を見なければならない。私たちがアプリストアモデルへ戻った理由はネイティブの能力ゆえであって、インストール・審査・更新という鎖を望んだからではなかった。鎖は能力を得るためにやむなく付いてきた費用だった。ところがいつのまにか私たちはその費用を能力と一束に見なすようになった。「ネイティブの能力を望むなら鎖も甘受せよ」と。

この文章が問うのは、まさにその束だ。

能力と鎖は本当に分けられないのか?

私たちがすでに試みてきた迂回

業界がこの鎖をただ耐えていたわけではない。鎖を迂回しようとする試みは続いてきた。そしてその試みの成功と限界を見れば、本当の解法の輪郭が浮かび上がる。

ハイブリッドアプリ(ウェブビュー)。 アプリの殻の中にブラウザを入れ、画面はウェブで描く方式。画面をサーバーで変えられるので鎖が一部断たれた。しかし代償が大きかった — ウェブビューはネイティブほどなめらかでなく、機器の深い機能に届きにくく、「ウェブのようなアプリ」という中途半端な感触を与えた。能力を一部あきらめて即時性を買ったわけだ。

コードプッシュ(ホットアップデート)。 審査を経ずにJavaScriptのバンドルを機器へ押し込み、アプリのロジックを更新する方式。緊急の修正には有用だったが、本質は依然として機器にコードを植えることだった。ストアのポリシーと綱引きをせねばならず、大きな変更は結局正式な審査に戻らねばならなかった。鎖を断ったのではなくゆるめただけだ。

サーバードリブンUI(SDUI)。 大手サービスが静かに使ってきた方式。画面の構成(どのカードを、どの順で、どのデータで見せるか)をサーバーが送り、アプリはその仕様を受けてネイティブのウィジェットで描く。フィードやホーム画面のように頻繁に変わる領域で威力を発揮した。これが最も本質に近い試みだ — ネイティブで描くが、何を描くかはサーバーが定める。

ところがSDUIにも限界があった。たいていは各社が自社サービスのためだけに作った閉鎖的なシステムだった。その会社のそのアプリでのみ動く仕様、その会社のサーバーとだけ話す構造。汎用の標準ではなかった。だから「うちのフィード画面はサーバーが定義する」はできても、「どんなサーバーでも、どんな機器にでも、画面と道具を定義して送る」はできなかった。

ここまでが業界の到達した地点だ。即時性はウェブが、能力はネイティブが、画面の動的定義はSDUIが、それぞれ見せた。ただその三つが一つの開かれた標準へと合わさらなかっただけだ。

なぜアプリは「インストール」されねばならなかったか — 構造を見る

ここで根本の問いに戻ろう。当たり前すぎて誰も問わない問いだ。なぜアプリはユーザーの機器にインストールされねばならないのか?

答えは、アプリが何でできているかを見れば出てくる。アプリは二つだ。一つは何を見せるか(画面、レイアウト、ボタンの位置と色)、もう一つは何をするか(ボタンを押すと起きること、データを扱う規則)。従来のアプリはこの二つをともにコードとして書き、機器に植えておく。 画面もコード、動作もコード。そのコードの塊をコンパイルした成果物が、まさに「インストールされるアプリ」だ。

だから何かが変われば — 画面であれ動作であれ — 機器の中に植えておいたそのコードの塊をまるごと入れ替えねばならない。 一部だけ変えるうまい方法がない。それがビルド・審査・インストール・更新という鎖の根だ。鎖は怠慢や古い慣習のためにあるのではなく、「アプリの本体が機器の中にある」という構造から必然的に流れ出たものだ。

この構造には深い前提が敷かれている。機器は賢くなければならない。 画面をどう描くか、ボタンを押すと何をするか、次に何を見せるか — そのすべての判断を機器の中のコードが下さねばならない。だからその判断のコードをすべて機器にあらかじめ入れておくのだ。

ところが — この前提をひっくり返したらどうなるだろう?

前提をひっくり返す:サーバーが画面を定義するなら

こう想像してみよう。画面と動作を機器ではなくサーバーが定義する。機器はもはや「何を見せるか」を自分では知らない。代わりにサーバーに尋ねる — 「今この画面に何を描けばいい?」 サーバーが「タイトル一つ、その下にボタン一つ、ボタンを押すとこの動作」と答えれば、機器はその指示どおりに描くだけだ。

この小さなひっくり返しが鎖全体を崩す。

機器にはもはや「このアプリだけのコード」がない。機器にあるのは何が来ても描いてくれる汎用の描画エンジン一つだけだ。画面を変えねばならない? サーバーの定義を直す。新しい機能が必要? サーバーに動作を加える。機器には手を触れるものがない。ビルドするものも、審査を受けるものも、インストールや更新するものもない — 機器の中にはそもそも変える「アプリ」がないのだから。

前の節で見た迂回と何が違うか。ハイブリッドはネイティブの能力をあきらめたが、ここでは描く側が本物のネイティブランタイムなので能力をあきらめない。コードプッシュは依然として機器にコードを植えたが、ここでは機器にアプリごとのコードそのものがない。 SDUIは一社の閉鎖システムだったが、ここで目指すのは開かれた標準 — どんなサーバーでも、約束された方式で画面と道具を定義して送れば、どんな機器の汎用ランタイムもそれを描く。

この「約束された方式」が核心だ。サーバーと機器が同じ言語で話さねばならない。何を画面と呼び、道具をどう呼び出し、データをどんな形でやりとりするかについての共通の規約。この規約が一社の中に閉じ込められず開かれているとき、はじめて「すべてのサーバーがアプリになりうる」が成り立つ。(この規約が具体的にどう成っているかは、この雑誌のコーディング・プロトコル連載で一層ずつ剥がしていく。)

ひとつの場面

抽象的に聞こえるだろうから、ひとつの場面を描いてみよう。

サーバーにこんな定義が入っているとしよう — 「この画面には歓迎の文句が一つあり、その下にボタンが一つある。ボタンを押すと注文の道具を呼び出す。」 ユーザーがアプリを開くと、機器はこの定義を受けてそのまま描く。文句とボタンが現れる。

いまあなたがサーバーでその定義を直す。「ボタンを二つにし、一つは注文、一つはキャンセル。色は青。」 保存する。

次の瞬間、ユーザーの画面でボタンが二つになる。彼らは何もしていない。 更新を押しも、アプリを取り直しも、ストアに行きもしなかった。あなたはビルドせず、審査を待たず、配信ボタンを押さなかった。サーバーの定義を一行直しただけだ。

十分の修正が十分ですべてのユーザーに届く。

冒頭で語ったあの長い鎖が — まるごと消えた跡だ。

当然浮かぶ反論

ここまで読んだ技術者なら頭の中にいくつもの反論が浮かんだはずだ。その反論に正面から答えなければ、この文章は空虚な宣言に終わる。一つずつ片づけよう。

「サーバーが画面を定義したら、オフラインでは何もできないのでは?」 もっともな懸念だ。答えは — 画面の定義はキャッシュされる。 一度受けた定義は機器に保管され、接続が切れても最後の画面は動く。新しい定義が必要なときだけサーバーに尋ねる。ウェブがオフラインキャッシュでPWAを作ったのと同じ原理だが、ネイティブランタイムの上でだ。「常に接続されていなければならない」という誤解は、毎瞬間サーバーを呼ぶという誤った図から来る。実際には定義が変わるときだけやりとりする。

「画面を毎回サーバーから受けたら遅くないか?」 画面の定義は小さい。重いコードのバンドルではなく、「ボタン一つ、テキスト一つ」という軽い仕様だ。そして上で言ったとおりキャッシュされる。肝心の重いもの — 描画エンジン — はすでに機器にネイティブである。ユーザーが体感する性能はネイティブそのままだ。サーバーが定義するのは何を描くかであって、描く行為そのものではない。

「セキュリティは? サーバーが画面と動作を送るなら、悪意ある定義を送ることもできるのでは?」 だからランタイムは受けた定義を信頼せず検証する。 定義ができることの範囲はランタイムが定めた境界の中に縛られる — 任意のコード実行ではなく、あらかじめ定義されたウィジェットと道具の組み合わせだけが可能だ。これはウェブブラウザが任意のサイトのJavaScriptをサンドボックスの中だけで実行するのと同じ発想だ。サーバーは「こんな画面を描け」とは言えても、「機器のすべてを思いのままにせよ」とは言えない。

「アプリストアのポリシー違反ではないか? 審査なしに機能を変えるのだから。」 微妙な領域で、正直に言って場合による。 ストアは「審査を迂回してアプリの核心動作をまるごと変える」ことを警戒してきた。しかし「サーバーがコンテンツと画面構成を定義する」ことは — すべてのフィード、すべてのコマースアプリがすでにやっていることだ。境界は任意のネイティブコードを植えるかにあって、画面をサーバーが定義するかにはない。このモデルが後者にとどまるかぎり、既存のSDUIがそうだったようにポリシーの内にある。(ただしこれはプラットフォームポリシーの解釈であり、法律・政策の助言ではない。実際の適用時には各ストアの最新ガイドラインを確認すべきだ。)

「サーバーの費用と依存は?」 タダはない。画面定義を送るサーバーが立っていなければならない。ただその負担は — すでにほぼすべてのアプリがバックエンドを持っているという点で — 新たに生じるというより役割が大きくなるに近い。そして後で扱うが、この雑誌が扱う生態系では、そのサーバー自体がそのまま製品になる。

これらの反論に答えてしまえば、「インストールなきアプリ」はもはや魔法ではなく工学で説明される構造になる。魔法は疑われて当然だが、構造は検証されうる。

何が変わるか

前提が変わればその上に立っていたものもともに変わる。ただ「配布が楽になる」ではない。

直す費用が0に近づけば、直し方が変わる。 審査に三日かかり、ユーザーの半分が旧バージョンを使う世界では、一度配信するときに最大限たくさんを盛り込んで慎重に出す。間違えれば戻すのにまた三日かかるからだ。しかし修正が即座に反映され、即座に戻せるなら、小さく頻繁に直すのが自然になる。画面を一つ今日変えてみて、反応が悪ければ明日戻す。実験の単位が小さくなる。これは単なる便利さではなく製品を作るリズムそのものの変化だ。

誰がアプリを作れるかも変わる。 ビルド環境を整え、署名鍵を管理し、ストアのアカウントを運用し、審査の規則を覚えること — このすべての参入障壁が「アプリを作る」という行為に付いていた。画面をサーバー定義で描く世界では、その障壁の相当部分が消える。定義を書ければ画面が現れる。これが意味するところは大きい。開発の専門家でなくとも — 自分のドメインをよく知る人が — 自分の道具を作れるようになる。弁護士が自分の相談の流れを、農家が自分の栽培の記録を、工場のエンジニアが自分の設備制御の画面を。この雑誌がこれからずっと見せていく話が、まさにこれだ。

そして「アプリ」という言葉の意味がぼやける。 機器にインストールされる重い塊ではなく、サーバーが定義しランタイムが描いてくれる生きた画面になる。だとすれば、サーバー側で道具とデータと画面を定義できる何かがあれば — それはもうアプリということになる。この思考の果てに、この雑誌が繰り返し扱う命題がある。すべてのサーバーがアプリになりうるなら? その含意はこの文章一編に収めるには大きすぎる。これからの連載がそれを一つずつほどいていく。

だから、疑え

ここまで読んで「それでも本当にできるのか」と思うなら — その疑いが正しい。文章で書いたビジョンはいくらでももっともらしく書ける。歴史をもっともらしく通し、反論にもっともらしく答えることもできる。大事なのはそれが実際に動くかだ。

だからこの雑誌はビジョンを長々と並べるところで止まらない。次の文章たちでじかに作って見せる。 インストールなしに画面を一つ出すことから始めて、状態を扱い、サーバーの道具を呼び出し、ついには工場の装備と病院の診療の流れと一人の専門知識がアプリになる過程まで。一歩ずつ、コードとともに、実際に動くものとして。

この文章が投げたすべての主張は — 鎖は必然ではなく、能力と鎖は分けられ、誰もが自分の道具を作れるという — 次の連載で証拠として返す約束だ。

最後に一つだけ残しておこう。あなたが最後にスマホで「アプリ更新」を押したのはいつか。その慣れ親しんだ行為が — 消え始めている。

---

makemind.dev 「探索」— 「インストールなしのアプリ」Volの巻頭です。次の「10行で最初の画面を出す」へ、ビルドもインストールもなく画面ひとつを出す最短の道へと続きます。