# Extensible Software in the age of LLMs > [!abstract] 概要 > Jeremy Morrell は、LLM 支援コーディングによってユーザーごとに異なる需要曲線の長い尾へ対応する拡張を安価に作れるようになったと論じる。ウェブアプリケーションの責任ある中核機能に、サンドボックス化したユーザーコードと狭いケイパビリティを接続し、拡張の作成・実行・共有を本体へ組み込む「ウェブ拡張型ソフトウェア」を仮説として提示する。記事は比較実験ではなく、AIエージェント、企業内基盤、サポート、オブザーバビリティ、Salesforce、Cloudflare の Dynamic Workers を例にした設計論である。 ## 記事情報 - 媒体: Jeremy Morrell の個人ブログ - 公開: 2026-08-18 - 著者: [[Jeremy Morrell]] - URL: https://jeremymorrell.dev/blog/extensible-software-in-the-age-of-llms/ - 著者の開示: 著者は [[Cloudflare]] に勤務しており、記事末尾で Dynamic Workers を特に適した実装候補として推している ## 問題設定: 需要曲線の長い尾 現在のウェブソフトウェアは、多数のユーザーに共通する需要曲線の上位部分を優先し、個々のユーザーだけが必要とする長い尾の要求を捨てている。機能を追加し続けると、少数の利用者のための機能が他の利用者の UI を複雑にし、製品全体を悪化させるためである。 ![[_attachments/extensible-software-in-the-age-of-llms/fig01-user-needs-long-tail.png]] (ユーザー数と要求の特殊性の関係。一般的な道案内から、特定地点の歴史や干潮時の通行可能性まで需要が長く分布することを示す。Source: 記事内の図) LLM 支援コーディングは、この長い尾に属する要求をユーザー自身がソフトウェアへ変換するコストを下げる。記事はこの傾向を、単一ユーザー向けの「Software for One」、小規模な用途に特化する「Small Software」、ユーザーが要求を言語化するだけで拡張を作れる LLM ネイティブソフトウェアへ接続する。 ## LLM ネイティブソフトウェア 記事が [[Pi]] を例に示す LLM ネイティブソフトウェアは、実績のある中核を維持しながら、ユーザーが要求するたびにツール・コマンド・イベント・UI の拡張を生成し、再読み込みできるソフトウェアである。拡張はパッケージとして共有できるため、本体に全機能を詰め込まず、ユーザーの長い尾の要求をエコシステムへ逃がせる。 AI エージェントでは、Pi が安定したフックを TypeScript 拡張へ接続する例、DeepSeek が対話中の UI にゲームを追加するデモ、OpenCode などの試行が挙げられる。ただし、現状のローカル拡張は開発者向けであり、拡張がホストと同じ権限で動く場合は企業利用や専門職への展開に限界がある。 ![[_attachments/extensible-software-in-the-age-of-llms/fig02-llm-extension-demo.png]] (DeepSeek の対話画面から、LLM が生成した拡張としてヘビゲームを実行するデモ。Source: 記事内の図) 記事の主張は、非技術職をソフトウェア開発者へ変えることではない。エージェントを使う人々に開発者と同じ負担を課すのではなく、各自の業務へソフトウェアを適合させることが重要だとする。 ## 想定される適用領域 ### 個人向けアプリケーション 読書管理アプリに対し、長い記事だけを電子書籍端末へ送り、特定分野の arXiv 論文を定期収集して要約・タグ付けし、特定サイト向けのパーサーを生成するといった例を挙げる。ユーザーはイベント、定期実行、レコード更新といった拡張点を意識せず、自然言語で望む結果を伝える。 ### 企業内プラットフォーム 社内データの検索・調査・相関分析・顧客の離反兆候抽出を、従業員が自分向けのビューや自動化として作る。ただし、アプリが増えた後の保守、必要最小限のデータアクセス、監査、認証情報のローテーション、顧客情報の外部流出、GDPR などが問題になる。 [[Cloudflare OS]] は、認証トークンを個別のアプリへ配布せず、内部プラットフォーム側がデータアクセスとコンプライアンスを管理する企業内基盤の例として紹介される。 ### サポートプラットフォーム サポート担当者が、自分のシステムから顧客情報をチケット画面へ追加し、エージェントに初期調査をさせ、定型作業用の操作ボタンを追加する。拡張をチームへ共有することで、個人の調査手順を組織の道具へ変換する。 ![[_attachments/extensible-software-in-the-age-of-llms/fig03-support-platform.png]] (チケット、顧客情報、事業コンテキスト、エージェントの調査結果を一つのサポート画面へ集約する構想。Source: 記事内の図) ### オブザーバビリティプラットフォーム ログ検索、トレースウォーターフォール、メトリクスダッシュボード、サービスマップへ収束した既存のオブザーバビリティ製品に対し、ユーザーが独自の可視化や変換を追加する。具体的には、取り込み時の任意変換、アラームからの決定的コード／エージェント起動、デプロイやフィーチャーフラグ展開時の高リスク処理、ログ中のリソース ID の外部リンク化が挙げられる。 非決定的なエージェントや数時間から数日続く永続ワークフローでは、単純なリクエスト／レスポンスを前提にしたトレースウォーターフォールだけでは表現しにくい。トレーススパンを事実の基盤として維持しながら、独自のビューと分析ロジックを拡張として追加する構想である。 ![[_attachments/extensible-software-in-the-age-of-llms/fig04-observability-views.png]] (トレース、ログ、グラフという既存の表示へ、ユーザー固有の可視化を重ねる構想。Source: 記事内の図) ## ウェブ拡張の難しさ 記事は [[notes/productivity/Obsidian|Obsidian]] のプラグインを、強力だがインストールしたコードを信頼する必要がある拡張モデルの例として扱う。低リスクなノートアプリでは成立するが、顧客記録、金融取引、私信を持つウェブサービスへそのまま適用するのは危険である。 任意コード実行には、無限ループやクラッシュからホストを守ること、認証情報や機密データの外部流出を防ぐこと、他テナントへのサービス拒否を防ぐこと、Spectre のような投機実行攻撃を考慮すること、無料計算資源の暗号通貨マイニングを抑止することが必要になる。 ## 先行例としての Salesforce 記事は [[Salesforce]] を、ウェブ上の拡張可能ソフトウェアが大規模に成立した先行例として位置づける。Salesforce は CRM にとどまらず、Apex によるテナント向けプログラマブルプラットフォームとして、カスタムエンドポイント、認証、テナント分離、イベント応答、スケジュール実行を一体で提供してきた。 ![[_attachments/extensible-software-in-the-age-of-llms/fig05-salesforce-platform-stack.png]] (Salesforce の製品群を、エンゲージメント、エージェンシー、業務、コンテキスト、信頼層として積み上げた構成図。Source: 記事内の図) 記事の提案は Salesforce の専用言語・コンパイラ・教育エコシステムをそのまま再現することではない。2026 年にはインタプリタ、V8 Isolate、MicroVM、WASM などの選択肢が増え、LLM が拡張作成を支援できるため、同じ問題を別の実装境界で解けると論じる。 ## 必要な実行プリミティブ 拡張を数千から数百万ユーザーへ提供する実行基盤には、次の性質が必要である。 - **低い経済コスト**: 未実行時はほぼゼロ、実行時はごく小さい単価で、ビルド・保存・ログ収集とメモリも含めて低コストであること - **短いコールドスタート**: 同期リクエストのクリティカルパスでは単位ミリ秒、イベントやスケジュール実行ではより長い起動時間も許容できること - **制限の制御**: CPU、メモリ、ネットワーク要求数・サイズ、応答サイズ、ログ量・速度などを制限できること - **強い分離境界**: クラッシュ、無限ループ、過剰なメモリ確保、悪意あるコードが他テナントへ波及しないこと - **安全な作用**: 拡張が外部世界へ作用できるが、許可された操作の範囲を越えられないこと ## ケイパビリティによる安全な作用 単純な純粋関数として拡張を実行すれば安全だが、外部 API やデータへのアクセスを許すと、広い `fetch` や API キーの露出がデータ流出・第三者への DoS・過剰権限につながる。プロキシで宛先・トークン・レートを制限する方法は改善になるものの、API の細粒度権限を代理して維持する複雑なフィルタリング層が必要になる。 記事が推す代替は、未信頼コードへ広い API や認証情報を渡すのではなく、特定の操作だけを実行する狭いケイパビリティを参照として渡す方式である。例えば「承認済みの一通のメールを取得する関数」だけを渡せば、拡張はその関数を呼べるが、メールサービス全体や認証情報へは到達できない。ambient I/O を除けば、拡張が行える作用はホストが明示的に渡した参照に限定される。 この設計は [[Capability-based Security]] と [[Extension Interface Model]] の問題設定を、LLM が生成するウェブ拡張へ接続する。TypeScript のケイパビリティ定義は、巨大な OpenAPI JSON をそのまま渡すよりも、LLM にとって生成対象を狭く表現できる。[IFTTT](https://ifttt.com/) の `twitter.post_new_tweet()` や `email.send_me_email` は、この形の実用的な類例として紹介される。 ## 実装候補 記事は、未信頼コードを実行する候補として以下を比較する。 - **インタプリタ**: Lua、QuickJS、または用途に合わせた専用言語。Salesforce の Apex に近い設計空間 - **V8 Isolate**: V8 の長年のハードニングを利用し、Cloudflare Workers、Dynamic Workers、`isolated-vm` などで JavaScript を分離実行 - **MicroVM**: POSIX、CPU・RAM、バイナリ実行能力を得られる代わりに、Isolate や WASM より大きい起動・メモリコストを払う。拡張の作成・コンパイル・テスト環境には有用 - **WASM + WASI**: 権限のない空白状態から始め、WASI でホストが与えるケイパビリティを標準化する。多言語対応と性能の代わりにツールチェーンが複雑になる これらは排他的ではなく、WASM を V8 Isolate や MicroVM の内部で実行する構成も考えられる。分離プリミティブが独自のケイパビリティモデルを持たない場合は、プロキシに加えてオブジェクト能力プロトコルの [Cap’n Web](https://github.com/cloudflare/capnweb) を検討すべきだとする。 ## Cloudflare の Dynamic Workers 記事は [[Dynamic Workers]] を、ウェブ拡張型ソフトウェアを本番運用するための既製部品に最も近い候補として紹介する。Dynamic Workers 自体がすべての要件を自動的に解決するという主張ではなく、拡張基盤を構成する次の要素を組み合わせやすい点を評価している。 - **オブザーバビリティ**: Workers ランタイムの OpenTelemetry トレーシングとテレメトリ制御 - **マルチテナントストレージ**: Durable Object facets による SQLite、または R2 バケット - **永続実行**: Dynamic Workflows による数分から数日にわたる処理、再試行、バックオフ - **ソース管理**: GitHub を前提にせず、製品内で拡張を版管理・反復する仕組み - **ホスト型 LLM**: Workers AI をトークン予算・レート制限付きで拡張から利用 - **JavaScript ツールチェーン**: JavaScript 製の変換器を同じ実行環境で動かし、拡張のビルド・テストを簡素化 記事内のデモでは、URL を取得して本文とユーティリティをユーザーコードへ渡すカスタムスクレーパーを、同じハーネス上で編集・実行する。個別のユースケースごとに新しいサービスをデプロイするのではなく、共通の実行境界と可変の拡張コードを組み合わせる例である。 ## 著者の留保 記事は「アプリケーションをプラットフォームに変える」ことを容易に見せる意図はないと明記する。プラットフォームは設計・運用・デバッグが難しく、顧客へ API を公開するには初期設計と長期サポートが必要である。一方で、ユーザーが開発者の想定外の用途を発見できることを、プラットフォームの価値として評価する。 著者は Cloudflare 勤務者であり、Dynamic Workers への評価には所属企業との関係がある。Dynamic Workers が他の選択肢より優れていることを示す独立ベンチマークではなく、著者の設計仮説と実装候補の紹介として読むべきである。 ## 関連 - 概念: [[ウェブ拡張型ソフトウェア]] / [[LLMネイティブソフトウェア]] / [[Extension Interface Model]] / [[Capability-based Security]] / [[WebAssembly]] / [[サーバーレスアーキテクチャ]] / [[AIネイティブ開発]] / [[LLMアプリケーション信頼性]] - エンティティ: [[Jeremy Morrell]] / [[Cloudflare]] / [[Dynamic Workers]] / [[Cloudflare OS]] / [[Pi]] / [[Salesforce]] - 既存研究との接続: [[@2025__OSDI__Extending Applications Safely and Efficiently]] / [[@2019__yuuk.io__Rethinking-Serverless-Architecture]] ## 出典 - [Jeremy Morrell, “Extensible Software in the age of LLMs,” 2026-08-18](https://jeremymorrell.dev/blog/extensible-software-in-the-age-of-llms/) - 記事内で参照される [[@2025__OSDI__Extending Applications Safely and Efficiently]]（拡張インターフェースとケイパビリティ） - 記事内で参照される [[@2019__yuuk.io__Rethinking-Serverless-Architecture]]（FaaS・BaaS・拡張可能なサーバーレス構成）