何が語られたか
Simon Willisonは2026年8月19日22時56分の投稿で、Jeremy Morrellの記事「Extensible Software in the age of LLMs」から一節を引用しました。Morrellの仮説はシンプルです。Web上のソフトウェアにおいて「拡張可能であること（Extensible Software）」の価値が再び上がっている。理由は二つで、(1) LLMが拡張機能を書くコストを劇的に下げたこと、(2) モダンなサンドボックスのプリミティブが配布コストを下げ、かつ良質なセキュリティ境界を提供することです。
そこから導かれる設計指針が「堅牢で説明責任を果たせるコア（solid, accountable core）を自社で持ち、ユーザーには多方向に安全に拡張させる。足りないピースはLLMに埋めさせる」というもの。Morrellはこれを「ユーザーにスーパーパワーを与える」と表現しています。投稿にはsandboxing（54件）、ai（2,194件）、generative-ai（1,943件）、llms（1,910件）のタグが付いており、サンドボックスというテーマがWillisonのアーカイブでは相対的にまだ薄い領域であることが数字から読み取れます。
なぜ重要か
拡張可能なソフトウェア自体は新しい概念ではありません。Emacs、Excelのマクロ、ブラウザ拡張、SaaSのプラグインマーケット——どれも歴史があります。しかし多くのSaaSがプラグイン機構を諦めてきたのは、二つの壁があったからです。第一に、拡張を書ける人が少なすぎてエコシステムが立ち上がらない。第二に、他人のコードを自社サービス内で動かすことのセキュリティ・運用リスクが割に合わない。
Morrellの主張が刺さるのは、この二つの壁がほぼ同時期に、別々の技術によって崩れたと指摘している点です。前者はLLMによる「書けない人でも書ける」化、後者はサンドボックス実行環境による「危険なコードを安全に動かす」化。片方だけなら以前からありましたが、両方が揃うと計算式が変わります。
「アカウンタブルなコア」という言葉の重み
注目すべきは、Morrellがコアを単に「堅牢（solid）」ではなく「説明責任を果たせる（accountable）」と形容している点です。ユーザーが生成したコードが暴走したとき、データが壊れたとき、責任の所在はどこにあるのか。拡張可能性を開くということは、障害の切り分けと責任分界点を製品設計の最初から引くということでもあります。LLMが書いたコードの品質は保証されないので、コア側が「何を許し、何を拒み、何を記録するか」を定義できていなければ、この設計は成立しません。
ちなみにWillisonの同時期の投稿には「Conceptual integrity and counting lines of code」（8月19日）や「Qwen 3.8 27Bは優秀だが極端に考えすぎる」（8月16日）、「OpenAIによるHugging Faceへの偶発的な攻撃のタイムライン」（8月7日）が並びます。概念的整合性とコード行数の話題と拡張可能性の話題が並ぶのは偶然ではないでしょう。誰でもコードを書ける時代に、製品の一貫性をどう保つかは同じ問題の裏表です。
💼 事業会社視点：これは自社にどう効くか
最も影響を受けるのは、国内の垂直特化型SaaSです。日本のSaaSは「顧客ごとの個別要望」に消耗し、カスタマイズ要望を個別開発で吸収してきた結果、開発リソースの相当部分が特定顧客向け機能に溶けている企業が少なくありません。Morrellの構図が正しければ、これまで「プラグイン機構を作っても誰も書かない」で見送ってきた判断は再検討に値します。顧客側の情シスや現場担当がLLMで拡張を書けるなら、個別要望をコアに取り込まず、拡張として顧客に返す道が開けます。
EC・小売なら、店舗ごとの表示ロジックやキャンペーン計算式が典型です。受託開発企業にとっては両刃で、「顧客の個別カスタマイズを請け負う」型の売上は侵食されますが、「拡張可能なコアとサンドボックス実行基盤を設計する」上流は単価が上がります。
事業責任者が今動くべきは三点です。第一に、直近1年の個別開発要望を棚卸しし、何割が拡張機構で吸収できたかを試算すること。第二に、責任分界点の設計——ユーザー生成コードの障害を自社SLAの外に出す契約と監査ログの整備。第三に、拡張実行のサンドボックス選定を技術判断ではなく経営判断として扱うこと。ここを外すと、拡張可能性はそのままインシデントの入口になります。