開幕：ある数字が引き起こした議論
2026年7月22日、Hacker Newsに1つの投稿が現れた。「Show HN: Bento —— 丸ごとPowerPointを1つのHTMLファイルに」。8時間で591の賛成票と141のコメントを集めた。この数字自体がひとつのシグナルだ——世界で最も厳しい技術読者を集めたコミュニティで、これだけの注目を集めたということは、何か本物のニーズに触れた証拠である。
筆者がリンクを開くと、そこには1つのブラウザタブの中に、完全なスライドエディタが存在していた。ツールバーがあり、サムネイルサイドバーがあり、文字を打ち、図形を描き、グラフを挿入し、注釈を追加できる。Escキーで編集モード、矢印キーでプレゼンテーション、Sキーでスピーカービュー——一見すると何の変哲もない。ただ1つの事実を除いては、このエディタはWebサイトでもアプリでもなく、単なる1つのHTMLファイルなのである。
図：Bento Slidesの編集インターフェース。上部ツールバー、左側のサムネイル、メイン編集領域、下部ナビゲーションは主流のスライドソフトと変わらないが、すべてが560KBのHTMLファイルで動作している。
「ファイル＝ソフトウェア」
この言葉がBentoプロジェクトの核心的信条である。筆者はGitHubで完全なコードを発見した——プロジェクト名はbento、作者はstarfallg、MITライセンスで公開されている。
比較してみよう。標準的なPowerPoint .pptxファイルは、XMLや画像、音声などのリソースを含む圧縮パッケージだが、それ自体では動作しない——PowerPointソフトウェア（またはWeb版Office 365）をインストールして初めて開いて編集できる。Microsoft 365個人版の年間サブスクリプションは数千円、インストールパッケージは数GBにも及ぶ。
一方、Bentoのアプローチはまったく逆だ：ソフトウェアをファイルの中に詰め込んだのである。
bento.page/slidesを開くと、ブラウザに直接、完全なスライドエディタが現れる。この「ページ」上でコンテンツを作成し、レイアウトを調整し、アニメーションを追加できる。そして最も驚くべきことは、Ctrl+Sで保存すると、このHTMLファイルが自分自身を上書きする——編集した内容がファイル自身に書き戻されるのだ。次にこのファイルをダブルクリックすれば、前回保存したすべてのコンテンツを保持した完全なエディタが再び開く。
筆者がファイルサイズを比較してみた：
| 項目 | サイズ | 追加ソフトウェアの要否 |
|---|---|---|
| Bentoデフォルトプレゼンテーション | ~560 KB | 不要、ブラウザのみで動作 |
| PowerPointインストールパッケージ | 3〜5 GB | インストールが必要 |
| Keynoteインストールパッケージ | 約1.5 GB | インストールが必要 |
| Google Slides Web版 | ネットワーク読み込み依存 | ログインとネット接続が必要 |
差は数千倍である。この比較自体が、ひとつの問いを投げかけている：なぜプレゼンテーション1つに数GBのソフトウェアが必要なのか？
ファイルの中身を覗いてみる
Bentoがなぜここまで小さくできるのかを理解するため、筆者はそのファイル構造を調べた。.bento.htmlファイルは外側から内側へと幾層にも分かれている。
最外層は正しいHTMLドキュメントである。DOCTYPE宣言があり、<head>と<body>がある。つまり、あらゆるブラウザで開くことができる。しかし、その内部構造は異例だ。
ファイルのヘッダ付近に、idが「bento-doc」、typeが「application/bento+json」の<script>タグがある。ここにはプレーンテキストのJSON形式で、スライドのすべてのデータ——各ページのコンテンツ、各要素の位置やサイズ、色、フォント、アニメーション設定——が格納されている。ブラウザで「ソースを表示」すれば直接確認でき、フォーマットも人間が読める。
この設計には深いメリットがある：データとコードは分離されているが、同じファイルに共存している。AIツールはこのJSONブロックを直接読み書きでき、開発者はテキストエディタで検索・置換でき、バージョン管理ツールは行単位で差分を比較できる。
ファイルの残りの部分、つまり実際の「ソフトウェア」は、圧縮されたJavaScriptコードブロックに格納されている。このコードには、Reveal.jsベースのプレゼンテーションエンジン、自社開発のアニメーションシステム、自社開発のチャート描画エンジン、そしてVue駆動のエディタインターフェースが含まれている。v0.7.0以前はGSAP（アニメーション）とECharts（チャート）を使用していたが、作者はこれらをすべて自社開発に置き換えた。理由は明確だ：ファイルサイズを1.3MBから560KBに削減するためである。
図：BentoのGitHubプロジェクトページ。260回のコミット、389スターと、活発な開発ペースを示している。MITライセンスにより、誰でも自由に使用・改変できる。
一枚の白紙と一揃いのスイスアーミーナイフ
Bentoの設計思想を一言で表すなら、筆者が思い浮かべる最も適切なイメージは「一枚の白紙の中に、完全なスイスアーミーナイフが隠されている」というものだ。
従来のオフィスソフトウェアのモデルは「先に道具を買い、それから作品を作る」というものだ。スライドを作るには、まずPowerPointをインストールし（またはMacを買ってKeynoteを使い）、その上でソフトウェア内に新規ファイルを作成する。ファイル自体は脆弱だ——.pptxをOfficeを持っていない人に送っても開けない。
Bentoのモデルは「でき上がったもの自体が道具である」というものだ。bento.page/slidesからHTMLファイルをダウンロードすると、「プレゼンテーションの殻」が手に入る。その中で創作し、保存すると、そのファイルは自己完結型のプレゼンテーションになる——それは内容であると同時に、内容を開くために必要なすべてのツールでもある。
このファイルをWeChat、メール、AirDropで同僚に送れば、ダブルクリックするだけでスライドが表示される——そのままプレゼンテーションでき、そのまま編集できる。追加のインストール手順は一切不要で、アカウント登録も必要ない。
この体験の違いは、シンプルなシナリオで説明できる：
あなたがプロジェクトマネージャーで、四半期報告のPPTを作成したとする。ファイルを上司に送り、上司がスマートフォンで開く——従来のモデルでは、おそらく「ファイルを開けません」というエラーか、フォーマットの崩れが表示される。一方Bentoのモデルでは、ブラウザさえあれば、あなたがデザインした通りのレイアウト、アニメーション、グラフをそのまま見ることができる。
共同編集：暗号化ブラインド転送の巧妙な設計
さらに興味深いのはBentoの共同編集機能だ。筆者が最初に疑問に思ったのは「HTMLファイル1つで複数人の同時編集をどうやって実現するのか？データはどこにあるのか？」ということだった。
答えはこうだ：データはファイル内にあり、編集は暗号化された「ブラインド転送」チャネルを通じて同期される。
Bentoで共同編集セッションを開始すると、ファイルはローカルで暗号鍵を生成する。招待された共同編集者は、同じファイルのコピー（とそこに埋め込まれた鍵）を受け取る。各人の編集操作は暗号化され、Cloudflare Durable Objects上で動作する中継サーバーに送信される——このサーバーが行うのはただ1つ、受け取った暗号化データをルーム内の他の参加者に転送することだけだ。
この中継サーバーは「ブラインド」になるよう設計されている——転送するのは暗号文であり、サーバー自体はあなたのコンテンツを一切読み取ることができない。あなたの文章やグラフ、画像はおろか、名前すら見えない。暗号データの単なる運搬人である。
同期エンジンにはCRDT（Conflict-Free Replicated Data Type）技術が採用されている。これは分散システムで広く研究されている手法で、複数人が同時に同じデータを編集しても、中央サーバーが「誰の変更が最終的に正しいか」を裁定する必要がない。BentoのCRDTは自社開発であり、作者はHNの議論で特に「最も満足しているのはCRDTのスムーズさだ」と述べている。
もう1つの魅力的な設計：オフライン編集。ネットワークがない状態でスライドを編集し、接続が復旧すると自動的にチームと同期される。CRDTがマージの正確性を保証する——「あなたの編集が私の編集を上書きする」といった問題は発生しない。
父親が余暇に作ったプロジェクト
HNのコメント欄で、筆者は興味深い背景情報を見つけた。誰かが作者に「制作期間とAIアシストの使用状況」を尋ねたところ、作者starfallgはこう答えた：「先週から始めました。余暇を利用して、すべてClaude Codeで作りました。実は昔のように手書きコードを書きたかったのですが、再生可能エネルギー企業で技術チームを率いていて、仕事が終われば就学前の子供の面倒を見なければならず、本当に時間がなかったんです。」
この発言からいくつかの情報が明らかになる：Bentoの主要コードはAIアシストで生成され（作者はClaude Codeを使用）、構想から公開まで約1週間の余暇時間で完了し、作者自身はテクノロジーマネージャーであり、日常業務はオフィスソフトウェアとは無関係である。
これこそが、Bentoの設計思想が従来のオフィスソフトウェアとここまで異なる理由かもしれない——「旧フォーマットとの互換性」という歴史的重荷もなく、「Officeのようにデザインしなければならない」という経路依存性もない。それは「開発者が本当に必要とするもの」という視点から生まれた产物なのである。
560KBの境界と限界
もちろん、誕生からわずか1週間強のプロジェクトであるBentoには限界がある。筆者が試用中に気づいた点をいくつか挙げる。
第一に、現時点では中程度の複雑さのプレゼンテーションにしか適していない。非常に精密なレイアウト制御や複雑なマスター設計、大量の高解像度画像処理が必要な場合、従来のツールのほうがまだ成熟している。
第二に、共同編集は現時点では作者のCloudflareアカウントが提供する中継サービスに依存している。作者は「コストは非常に安く、予算内で十分に収まる」と述べているが、多数のユーザーが同時に使用した場合、サービスの安定性に変数が生じる可能性がある。とはいえ、コードは完全にオープンソースであるため、どのチームでも自分たちの中継サーバーをデプロイできる。
第三に、ファイル形式は現時点では独自のJSON構造である。ソースコードは公開され形式も可読だが、.pptx形式との直接的な相互変換手段はない。作者はひとつのアイデアを提示している：.pptxをAIに渡し、Bentoのフォーマット仕様に従って再生成させるという方法だ。
このプロジェクトの真の意義
Bentoを単なる「PowerPointの代替ツール」と見なすだけでは、その背後にある思考を無駄にしてしまう。Bentoが投げかけるもっと価値のある問いはこれだ：AIがコードを書ける時代において、ソフトウェアの配布方法を再考する必要があるのではないか？
従来のソフトウェア配布モデル——インストールパッケージのダウンロード、ランタイム依存関係のインストール、アカウント登録、クラウドサービスへのログイン——この一連の流れは、ますます増加する軽量ツールにとっては過剰になっているのかもしれない。Bentoは別の答えを示している：ソフトウェアとコンテンツを1つのファイルに融合し、ブラウザを実行環境として、ファイル自体にインフラを一切必要としない「自己実行能力」を持たせるのである。
この発想自体は新しいものではない。20年以上前のTiddlyWikiが同様のアプローチを試みていた——自己完結型のHTMLファイルが、Wikiエンジンであると同時にWikiコンテンツでもある。TiddlyWikiには今も熱心なユーザーがいるが、主流にはなれなかった。
しかし、時代は変わったかもしれない。ブラウザの能力は飛躍的に向上し（File System Access APIによりWebアプリがローカルファイルを直接読み書き可能に、WebCrypto APIがブラウザレベルの暗号化機能を提供）、モダンなフロントエンドツールチェーンは複雑なシングルページアプリケーションの構築をより効率的にし、AIアシストコーディングはこうしたアイデアを実現する技術的ハードルを大幅に引き下げた。Bentoはまさにこれらのトレンドの交差点に位置している。
筆者はHNのコメント欄でこんな投稿を見かけた：「このプロジェクトは、Google WorkspaceチームがAI時代に何もしていないことへの完璧な告発だ。」この評価が妥当かどうかは別として、Bentoは確かに考える価値のある問いを投げかけている：560KBのHTMLファイルがプレゼンテーションの編集、表示、共同作業の全工程を完結できるのであれば、本当に数百GBのOfficeスイートと月額課金のクラウドサービスが必要なのだろうか？
答えは単純な「はい」か「いいえ」ではないかもしれない。現実のほとんどのユーザーは、Bentoのような軽量さとシンプルさを必要とすると同時に、従来のオフィスソフトウェアの安定性やエコシステムとの互換性も必要としている。しかしBentoの存在は、少なくとも別の道の可能性を示している——より軽く、より自由で、より「自分自身のもの」である道を。
参考リンク
- Show HN：Bento —— Hacker Newsの元投稿と議論（591賛成、141コメント）
- BentoプロジェクトGitHubリポジトリ —— nyblnet/bento、MITライセンス、260コミット
- Bento/Slidesオンラインデモ —— すぐに使えるエディタ、機能紹介スライド内蔵
- Bento公式サイト —— テンプレートギャラリーとプロジェクト紹介
- TiddlyWiki —— 自己完結型HTMLファイルのWikiシステム、Bento設計思想の先駆け
- Reveal.js —— オープンソースHTMLプレゼンテーションフレームワーク、Bentoのレンダリング基盤
- Cloudflare Durable Objects —— Bento共同編集転送サービスのインフラ
- File System Access API —— Bentoの「自己保存」を可能にするブラウザAPI
