ソフトウェア業界の悪循環：ユーザーが要望を出しても、数年経っても機能がひとつも実装されない

講演の冒頭で製品の話はせず、ソフトウェア企業で働いた人なら誰もが経験したことのある話をしました。

開発者がアプリを作り、ユーザーに届けます。満足する人もいれば、あの機能が追加されないと使い物にならないという人もいます。ユーザーは開発者に連絡しますが、開発者の代理人であるプロダクトマネージャーが要望を受け取り、Jira に登録して、それで終わりです。

たまにプロダクトマネージャー自身が欲しいと思う要望はロードマップに入ります。開発者はそれをひとつずつ実装していきます。しかし実際に使う人はごく一部で、実装のたびにコードには if 文の山が積み上がります。コードはどんどん複雑になり、機能は退屈になっていきます。

そこで開発者は言います。「リライトが必要だ。プラグインシステムを備えた新しいアーキテクチャにすれば、各機能をプラグイン化でき、コアはクリーンなまま保てる」と。新アーキテクチャの開発が始まっても要望は入り続け、答えは決まって「プラグインシステムが完成すれば簡単になる。今やっても無駄になるだけだ」です。

この部分が講演全体の土台です。循環が止まらないのは、誰が努力するかという問題ではありません。根源は、ひとつのコードが全ユーザーのニーズを満たさなければならない前提にあり、その前提は今なら覆せます。

AI に各ユーザー向けにソフトウェアを修正させるには、2つの壁がある：モバイル OS は閉鎖的で、ウェブアプリはバージョンがひとつしかない

ユーザーが新機能を必要としたとき、自分の AI エージェントに直接書いてもらえれば、この循環は止まります。誰も他人のニーズに引きずられずに必要な機能を手に入れられ、開発者のコアコードもクリーンなまま維持できます。

では、なぜそれがまだ実現していないのか。今日のソフトウェア開発の基盤は、そのような方向性で設計されていないからです。

ウェブは確かに Apple と Google を迂回しましたが、あの 2 社が常に脅かしていたようなセキュリティ上の惨事は起こっていません。しかしウェブには独自の問題があります。過去 25 年のクラウドアーキテクチャは「決定版バージョンを全ユーザーに配布する」方向に進んできました。開発者には便利ですが、ユーザーは自分の手元のものを決して変更できません。

Gadgets のアプローチ：Google Docs のように使えるが、各ドキュメントは独立したアプリ

これをまたひとつの vibe coding プラットフォームだと思わないでください。より適切な例えはオフィススイートです。

Google Docs を開くと、何百、何千ものドキュメントがあり、クリックして開き、編集し、共有します。ここでもまったく同じですが、ドキュメントが gadget に置き換わっており、各 gadget はコードを含む完全なアプリです。

彼はスペイン語のメールをよく受信するもののスペイン語が分からないため、メールを選別する小さなツールを作りました。GitHub で自分のレビュー待ちのコードを監視する必要があったため、整理ツールも作りました。これらは製品と呼べるものではなく、自分のために作っただけで、使い終わったら二度と開かないかもしれません。

Blueprint：コードを他人にエクスポートし、相手は自分のコピーを実行する

役立つ gadget を作ったら、Blueprint としてエクスポートして共有できます。エクスポートされるのはコードだけで、データは含まれません。受け取った人は自分のコピーを生成し、以後は各自が自由に変更します。

もうひとつ、設計上の重要なディテールがあります。ひとつの gadget はひとつのスライドセットにのみ対応し、3 セット必要なら 3 つのインスタンスを生成します。この設計にしたのは、すべての gadget が共有・コラボレーション可能で、共有と権限管理はアプリではなくプラットフォームが実装するからです。これにより、アプリ自体が権限を壊すことは物理的にできません。

Claude は絵を描くために、まずスライドアプリに人間には使えない機能を追加した

この講演のスライドは、同僚の Phillip が作ったスライドツールで生成されました。Phillip は Cloudflare のプロダクトマネージャーで、彼の回想によると、このツールは彼が昼下がりに AI で作ったものだそうです。

Kenton 氏は Claude に Google ドキュメントのリンクを渡し、そこには欲しいスライドがすべて書かれていました。そして、ひとこと付け加えました。重要なのはこの一言です。

スライドを実現するために、スライドアプリ自体に新機能を追加する必要があるなら、自由に追加していいよ。

講演で復唱された元の指示

Claude は本当に追加しました。アプリの全コードとそのドキュメントを読み終えると、まず小さな機能を 2 つ補いました。3 ページ目に取り消し線フォーマットが必要でしたが、アプリにはなかったため追加。また、何ページかでテキストを中央揃えにしたかったのですが、Phillip のデザイン感覚は中央揃えを好みません。しかし彼が望んだので、これも追加しました。

最も興味深いのは 5 ページ目と 6 ページ目です。彼は手書き風の雲の図を求めましたが、このアプリは四角形と矢印しかサポートしておらず、任意の図形を描くことはできません。Claude の解決策は、アプリに機能を追加して、スライドに SVG を貼り付けられるようにすることでした。

「スライドに SVG を貼り付ける」機能は、人間にとってはほぼ役に立ちません。誰が SVG を手書きするでしょうか。しかし Claude にとっては非常に有用で、すぐに自分でその図を生成しました。

この場面は「パーソナルソフトウェア」が何を意味するかを最もよく示しています。ソフトウェアが、配布された完成品から、使用中にその場で改造できるものへと変わったのです。たとえそれを変更するのが AI であってもです。

AI にコードを自由に変更させられる理由：2層のサンドボックスで隔離され、壊してもデータが漏れない

しかし、AI がページに SVG を気軽に貼り付けると聞けば、知識のある人の最初の反応はこうでしょう。「SVG には JavaScript を埋め込める。これはセキュリティホールではないか？」と。

答えは「問題ない」です。この環境の作り方が、問題にならないことを保証しているからです。

結果として、こういう状況になります。AI が書いた UI と、AI が書いたサーバーコード。それらは互いにのみ通信でき、あなたに UI を表示します。たとえ内部に本当に脆弱性があっても、外部に漏れるものは何もありません。

このコードには、重要なセキュリティ上の脆弱性は存在しません。

講演での原話。サンドボックスで隔離されたアプリのコードについて

この言葉が、この設計全体が成り立つ前提です。壊しても問題が起きないからこそ、コード修正をすべて AI に任せられるのです。

ライブデモのエラーが、Cloudflare OS が講演者のノートパソコンで動作していることを逆に明らかにした

安全性が説明できたところで、このシステムは一体どこで動作しているのでしょうか。彼がライブデモ中にエラーを出したとき、答えがむしろ明らかになりました。

彼はプロンプトを入力し、「ばかげたカウンターアプリ」を作らせました。すると画面にエラーが表示されました。会場のネットワークが繋がらなかったのです。彼は「問題ない」と言い、種明かしをしました。このシステム全体が彼自身のノートパソコンで動作しているので、オフラインでも影響しない、と。

ちなみに彼の経歴を補足すると、Workers は現在何百万人もの開発者が利用し、毎日数兆回のリクエストを処理しています。この基盤は、彼が 2017 年に Cloudflare に入社した際に立ち上げ、今も率いているプロジェクトです。

これを支えているのは workerd、Cloudflare Workers のランタイムで、オープンソースであり、自分のマシンやサーバーにインストールして実行できます。大規模言語モデルへの接続を除き、その他の部分はすべて Workers 上に構築されています。

彼がこの件に興奮している点は具体的です。システムにはすでに Home Assistant と Spotify が接続されており、彼はこのシステム全体を自宅の地下室に設置し、家庭の自動化に使いたいと考えています。

当初は講演後にすぐオープンソース化する予定だったが、講演 1 週間前に CTO に止められ、5 週間後に公開された

では、いつ手に入るのでしょうか。講演の最後に、彼はこの件について謝罪しました。

数か月前に講演プロポーザルを提出した時点では、これはまだサイドプロジェクトでした。会場で講演し、講演後にコードを GitHub に載せれば、誰でもダウンロードして遊べる、という計画でした。

ところが講演の数週間前、Cloudflare 社内でこのプロジェクトへの熱が高まり、正式なプロジェクトになりました。講演 1 週間前の木曜日、CTO の Dane 氏が彼を部屋に呼び、「これをただ公開するのはやめよう。もっと戦略的にリリースしよう。数週間待とう」と言いました。

彼は残念がっていました。講演の要約にはすでにオープンソース化を約束していたからです。壇上でこう言うしかありませんでした。「すみません、今日は公開できません。しかし、すぐに公開します」と。

この講演は 6 月 30 日でした。Cloudflare OS は 8 月 5 日にオープンソース化され、間に約 5 週間の空白がありました。

ユーザーが新機能を欲しいと思ったら、自分の AI に直接追加させれば、上記の悪循環は止まります。問題は、今日の状況を生んでいる 2 つの壁です。Apple と Google が 15 年間守ってきた結果、今日、モバイルアプリを作れるのは世界で 5 社だけになりました。彼の原話では、アメリカでは銃を買うほうが、自分のスマホに未署名アプリをインストールするより簡単だとのこと。ウェブは最初の壁を迂回しましたが、別の問題に行き当たりました。

システム全体は、むしろオンラインドキュメントツールに似ています。開く各 gadget は、コードを実行できる独立したアプリです。作ったものはコード（データは含まない）を共有でき、相手は自分のコピーを生成して、その後は各自で変更します。誰が見られるか、誰が編集できるかはプラットフォームが管理し、アプリ自体はアクセスできません。

この講演のスライドは、彼が Claude にドキュメントのリンクを渡して生成させたものです。彼はこう付け加えました。アプリ自体に機能を追加する必要があるなら、自由に追加していいよ、と。Claude は全コードとドキュメントを読み、まず取り消し線とテキスト中央揃えを追加しました。最も興味深いのは、手書き風の雲の図を描くように言われた場面です。このアプリは元々、四角形と矢印しかサポートしておらず、描けませんでした。

SVG には JavaScript を埋め込める。これはセキュリティホールでは？ 彼の答えは「問題ない」。環境の作り方が、脆弱性が外に漏れないことを保証しているからです。

ライブデモでカウンターアプリを作成中にエラーが発生しました。会場のネットワークが切断されていたのです。彼は「問題ない」と言いました。システム全体が彼自身のノートパソコンで動作しており、オープンソースの workerd（Workers のランタイムで、他のマシンにインストールして実行可能）を使用しているからです。大規模言語モデルへの接続を除き、その他はすべて Cloudflare Workers 上に構築されています。データベースは使わず、状態は専用の小規模ストレージ（Durable Objects）に保存。常駐コンテナは使わず、一時的な隔離環境（Dynamic Workers）で実行します。

当初の計画では、講演後にコードを GitHub に公開する予定でした。講演 1 週間前、CTO の Dane 氏が彼を部屋に呼び、「もっと戦略的にリリースしよう。数週間待とう」と言いました。彼は壇上で謝罪し、すぐにオープンソース化すると述べました。講演は 6 月 30 日、Cloudflare OS は 8 月 5 日にオープンソース化され、約 5 週間の間隔がありました。