プレゼンテーション一式が一つの HTML ファイルに収まるということ — 単一ファイルのローカルファースト Web アプリはクラウド文書スイートに挑むのか
プレゼンテーション一式が一つの HTML ファイルに収まるということ — 単一ファイルのローカルファースト Web アプリはクラウド文書スイートに挑むのか
クラウド文書スイートの時代は 560KB の HTML ファイル一つに挑戦されるのか、それとも集中管理と協業の利便の前に再び崩れるのか。
はじめに — 618 ポイント、そして一つのファイル
2026 年 7 月、Hacker News のトップページの最上段を、AI ではないプロジェクトが一つ占めた。タイトルは “Show HN: Bento — An entire PowerPoint in one HTML file (edit+view+data+collab)“。618 ポイントを集め、その日の AI を除くストーリーの中で首位に立った。昨今の HN の上段は、たいていモデルとエージェントが占拠する場所である。その場所をこじ開けて上がってきたのが「PowerPoint 一式を一つの HTML ファイルに収めた」という、一見素朴に見える道具だったという事実そのものが、この出来事の性格を物語っている。
Bento が掲げるものは単純である。編集、ビューア、アニメーション、データ管理、印刷、そしてリアルタイム協業まで — プレゼンテーション道具が担う仕事のすべてを、約 560KB の HTML ファイルたった一つに収めた、というものだ。クラウドログインは不要で、初回ロード以降はオフラインで動作し、メールに添付するかファイル転送でそのまま手渡せる。本稿は Bento という特定製品のレビューではない。618 ポイントが実際に反応した対象 — 単一ファイル、ローカルファースト(local-first)な Web アプリケーションという型 — をレンズとして、この十数年、産業を支配してきたクラウド文書スイートが、自己完結的でデータを所有しオフラインで動く文書に本当に挑戦されているのかを問う。
現象 — Bento とは何か、なぜ話題なのか
技術的な実体から正確に見よう。Bento は一つの .html ファイルである。ブラウザでそのファイルを開くと、スライドを作って直すエディタが立ち上がり、発表モードへ切り替えればアニメーション付きのビューアになり、表やデータを扱う機能と印刷出力までその中に入っている。別途のインストール工程がなく、アカウントを作る必要がなく、サーバに文書をアップロードもしない。文書はファイルそのものである。この構造がもたらす最も直接的な効用は、配布の摩擦の消去だ。インストール案内も、ログイン画面も、「このリンクへのアクセス権がありません」もない。ファイルを手渡せば、受け取った側はブラウザで開くだけでよい。
ここに話題性を加えた点が二つある。第一はリアルタイム協業だ。純粋なローカルファイルがどうして複数名の同時編集を支えるのか、という当然の疑問に対し、Bento は暗号化されたリレー(encrypted relay)を介した協業編集を提示する。すなわち協業が必要な瞬間にだけ暗号化された中継経路で編集内容をやり取りし、それ以外はファイルが自らの内で完結する。第二はエージェント統合だ。Bento は Claude Code と連携し、既存のスライドデッキを変換するよう設計されていると紹介される。人が作ったデッキを、コーディングエージェントが読み、直し、再構成する対象にできるということだ。文書がすなわちファイルであり、ファイルがすなわちエージェントの扱えるテキスト資産であるという点が、ここで滑らかにつながる。
Show HN スレッドの反応はおおむね熱かった。歓迎の空気をいくつかの筋に要約すると、こうなる(以下は特定の文の引用ではなく、スレッド全体の空気の要約である)。単一ファイル配布がインストール摩擦をなくす点、データを自らの手に握るローカルファーストな所有権とベンダーロックインの不在、初回ロード以降はオフラインでも動く点、そして「自分に必要なすべてがファイル一つに収まっているという事実が満足で、同僚とエージェントに手渡しやすい」という感覚が繰り返し現れた。とりわけ最後の一節は、この道具が狙う市場の情緒を凝縮している。SaaS ベンダーがバグを直してくれない、あるいは自分たちの欲しい機能を入れてくれないことに疲れたチームにとって、ファイル一つで完結する道具は、長く空いていた席を埋めてくれるというわけだ。
この反応の重心は「プレゼン道具がまた一つ出た」ではなかった。それは配布と所有のかたちに対する反応だった。文書がクラウドアカウントに縛られたレコードではなく、手に握れるファイルへ戻ってきたということ — 618 ポイントはおおむねその点へ投じられた票だった。
深層 — ローカルファーストという古い理想と新しい請求書
Bento が新たに発明したものはない。正確に言えば、それが巧みだったのは、二つの古い系譜を一つの実用的な産物へと合流させたことである。その系譜を辿らねば、この反応の大きさは理解できない。
第一の系譜は、単一ファイル HTML アプリケーションの歴史だ。この着想の正典(せいてん)は TiddlyWiki である。2004 年に Jeremy Ruston が作ったこの個人 Wiki は、自分自身を保存できる一つの HTML ファイルという発想を大衆化した。アプリケーションと、それが抱えるデータとが同じファイルの中に共存し、そのファイルを複製すればプログラムとデータが丸ごと複製される。サーバもデータベースもアカウントもなしに文書が自ら完結するこの形は、以後二十余年にわたり少数の熱烈な支持者を抱えてきた。近年は SQLite を WebAssembly へコンパイルし、ブラウザの中でデータベースごと走らせる単一ファイルアプリが、その系譜を現代的に継いでいる。Bento はこの古い形式を、最もありふれ、最も飽きるほど SaaS 化された対象 — プレゼンテーション — に適用した。
第二の系譜は、ローカルファースト・ソフトウェア(local-first software)運動である。2019 年に Ink & Switch の Martin Kleppmann、Adam Wiggins、Peter van Hardenberg、Mark McGranaghan が発表したエッセイ “Local-first software: You own your data, in spite of the cloud” は、この流れに名と綱領を与えた。彼らが提示した七つの理想は次のとおりである。ネットワーク往復なしに即座に反応すること(高速)、複数の機器でデータが同期されること(マルチデバイス)、ネットワークなしでも読み書きできること(オフライン)、複数のユーザが同時に協業できること(協業)、ベンダーが事業を畳んでもデータが生き残ること(長寿)、エンドツーエンド暗号化でプライバシーが守られること(プライバシー)、そしてベンダーがユーザのアクセスと利用を制約できないこと(ユーザ制御)。この一覧を Bento の紹介文の隣に並べると、重なりが明瞭に現れる。オフライン動作、ログイン不要、ファイル所有、メール添付での移動性 — Bento はこの綱領の相当部分を、プレゼンテーションという狭い領域で実装してみせた事例である。
ローカルファースト運動が長く格闘してきた最も難しい項目は、「オフライン」と「協業」の同時充足だ。サーバが真実の単一の源(single source of truth)でないなら、各自がオフラインで編集した結果を後から衝突なく合わせる問題が生じる。この問題の標準的な解法が CRDT(Conflict-free Replicated Data Type)である。Automerge(Ink & Switch 系)や Yjs(Kevin Jahns)といったライブラリは、複数の複製が各々独立に変更された後でも、数学的に同じ状態へ収束するよう併合を定義する。Bento の暗号化されたリレーが内部でどの併合戦略を用いているかは、公開された事実だけからは断定できない[仮定]。ただ明白なのは、「ファイル一つがオフラインで完結しつつ、同時にリアルタイム協業もする」という約束が無料ではない、という点だ。その約束を守るには、リレーであれ CRDT であれ、何らかの協業のための基盤構造がファイルの外に存在せねばならない。そしてまさにこの点こそ、この型の理想と現実が分かれる最初の亀裂である。
亀裂を正直に名づける方が、この道具を尊重する道である。スレッドで提起された批判は大きく三つの筋だった。第一に、協業の実際の使い心地だ。複数名が同時に編集するとき、テキストフィールドでフォーカスが弾き飛ばされる問題が報告された。ローカルファーストな協業がしばしばぶつかる、カーソル・選択・フォーカスの同期という難題が、ここでもそのまま現れたわけである。第二に、ブラウザ別の性能だ。Firefox でアニメーションが途切れる、あるいは遅いという指摘があった。単一ファイルの中にあらゆる描画とアニメーションのロジックを収める構造は、エンジン別の最適化差にそのまま晒される。第三に、拡張性の限界だ。複数のユーザが Bento を Reveal.js と比較した。Reveal.js は Mermaid.js のような任意のライブラリをスライドへ差し込みやすく、何より垂直スライド(vertical slides) — 一つの主題を下へ深く分岐させ、聴衆に応じて見せる内容を変える構造 — を支える。その垂直スライドが Reveal.js の最も強力な機能の一つなのだが、単一ファイルで封じられた Bento では任意ライブラリの埋め込みが難しく、そうした分岐構造を失ったという物足りなさが出た(以上は直接の引用ではなく、スレッドに流れた空気の要約である)。
最も痛い批判は最後の一つだ。「何も外部へ通信しない」という趣旨の約束にもかかわらず、Cloudflare のビーコン(beacon)が観測された、という指摘が出た。これは些細な揚げ足取りではなく、この型の正体に触れる緊張である。ローカルファーストな道具が売るものは機能ではなく信頼 — 「あなたのデータはあなたのもので、このファイルは密かにどこへも連絡しない」という信頼 — だからだ。その信頼の表面に、予期せぬ外部通信が一行観測された瞬間、単一ファイルのローカルファーストというセールスポイント全体が揺らぐ。制作者がこの不一致を認識し調査に乗り出したという点は健全な対応だが、出来事そのものは重要な教訓を残す。「何も通信しない」はマーケティング文句ではなく、検証可能な属性でなければならず、分析ビーコン一行、フォント CDN 一つ、テレメトリの断片一つが、その属性を静かに崩しうる、ということだ。ローカルファーストを掲げる道具は、この属性をユーザが自ら確かめられるように — ネットワークタブを開けば何のリクエストもないように — 作ってこそ、その約束が綱領ではなく事実になる。
展望 — 単一ファイルが勝つ場所、クラウドが勝つ場所
では実務者とチームにとって、この型は何を意味するのか。魅惑的な結論は「SaaS は終わり、ファイルが戻る」だろうが、その結論はトレードオフの半分しか見ていない。判断の軸は「ファイルかクラウドか」という好みの問題ではなく、文書の寿命・制御・規模という三つの座標の上で決まる。
単一ファイルのローカルファーストが明白に勝つ場所から見よう。相互作用が一回きりか、寿命の短い文書 — 一度発表して終わるデッキ、クライアントへそのまま手渡す提案書、リポジトリにコミットしてバージョン管理したい技術スライド — において、この型は純粋な利得である。アカウントも権限設定もなくファイルを手渡せば終わりで、受け取る側は十年後に開いても同じファイルが同じ結果を出す(長寿という理想の実現)。オフラインが既定でなければならない環境 — 航空機、セキュリティ隔離網、ネットワークが不安定な現場 — でも強い。そして決定的に、文書がファイルであるということは、それがコーディングエージェントの読み書きできるテキスト資産になるという意味だ。Bento が Claude Code 連携を掲げたのは偶然ではない。文書をクラウド API の背後に隠れた不透明なレコードではなく、手に握ったファイルへ戻す瞬間、それは人とエージェントの双方にとって直接操作可能な対象になる。これがこの型が今この時点で反響を呼んだ本当の理由だ。エージェントの時代には「ファイル」が再び一級市民になる。
反対に、クラウド文書スイートが勝つ場所も明白だ。そもそも組織が Google Workspace や Microsoft 365 へ移っていった理由は、編集機能が優れていたからではなく、ファイルが散らばるときに生じる問題を中央で解いてくれるからだった。誰が何にアクセスできるかを管理するアクセス制御、退職者の文書を回収するアカウント管理、「三週間前の版へ戻してほしい」を処理するサーバ側のバージョン管理、監査ログ、規制順守(compliance)、そして数千人が同じ文書体系を共有するときに必要なガバナンス。単一ファイルモデルはこのすべてをユーザへ返す代わりに、その管理の負担も一緒に返す。ファイルがメールとファイル転送で自由に複製されるということは、すなわち、どれが最新版か、誰がその複製を持っているか、漏れた複製をどう回収するかが制御不能になるということでもある。所有と移動性の裏面は、拡散と断片化である。
だから三つのシナリオを並べておく方が正直だ。楽観的に見れば、CRDT ベースのローカルファースト協業が成熟し、ブラウザ性能が均等に上がるにつれ、個人と小規模チームの文書が大挙してファイルへ回帰する — クラウドは本当に中央ガバナンスが要る組織文書だけに残る。悲観的に見れば、協業の使い心地(フォーカスの弾き、併合の衝突)、ブラウザの差(Firefox の性能)、そして「本当に何も通信しないのか」という信頼の問題が足を引っ張り、単一ファイルの道具は再び少数の愛好家の趣味に留まり、大衆は利便の前にクラウドへ戻る — 十数年前にデスクトップアプリがそうだったように。現実的に最もありそうなのは、二者択一ではなく併存だ。文書の性格に応じてファイルとクラウドが分かれ、その間を結ぶ「ローカルファーストでありつつ選択的に同期される」ハイブリッド — ファイルとしても存在し、必要なときに暗号化リレーや CRDT で合わさる形 — が標準になる。Bento の暗号化されたリレーは、すでにそのハイブリッドの初期形態である。
結論 — 一つのファイルが投げかけた問い
リードの問いへ戻ろう。クラウド文書スイートの時代は、560KB の HTML ファイル一つに挑戦されるのか。正直な答えは「挑戦されるが、まだ崩れない」である。Bento が受けた 618 ポイントは、クラウドへの反乱票というより、文書が再び手に握れるものであってほしいという古い渇望の表出だ。その渇望は本物であり、正当である。TiddlyWiki が二十年前に証明し、ローカルファーストの綱領が綱領として整理し、いまエージェントの時代が「ファイル」を再び一級市民へ引き上げることで、その渇望に新たな動力を与えている。
しかし単一ファイルモデルがクラウドを置き換えるには、それが手放したもの — 集中管理、サーバ側のバージョン管理、アクセス制御、規模のガバナンス — を組織が担える形で返すか、あるいはそもそもそれらが要らない領域へ自らを限定せねばならない。そして何より、「何も通信しない」という約束を、マーケティングではなく検証可能な事実として守らねばならない。Cloudflare のビーコン一行に揺らいだ信頼が、その条件の重さを証明している。
結局この出来事が残したものは、勝敗の判定ではなく、軸の再発見だ。データ所有・移動性・オフライン 対 協業・集中管理・規模 — この古いトレードオフの振り子が、クラウド十数年の後に再びファイルの側へ一度振れた。一つのファイルが投げかけた問いは「クラウドを捨てるか」ではない。それは「われわれが利便の代価に何をクラウドへ渡したのか、そしてそのうち何をファイルへ取り戻したいのか」を、各自の文書ごとに計算し直せという要求だ。その請求書は文書ごとに異なる形で出てくる。その差異を認めることが、この振り子を理解する唯一の方法である。
出典: