ブラウザはサンドボックスだ

 (simonwillison.net)
1 ポイント 投稿者 GN⁺ 2026-01-28 | 1件のコメント | WhatsAppで共有
  • Webプラットフォーム開発者の Paul Kinlan は、コーディングエージェントのための安全な実行環境として、ブラウザの可能性を探っている
  • 彼は、ブラウザがすでに 信頼できないコード を実行するための強力な サンドボックス構造 を備えていると指摘している
  • これを検証するために Co-do というデモを制作し、ブラウザ内でファイルアクセス・ネットワーク通信・コード実行をすべて実験した
  • Co-do は File System Access API、CSPヘッダーと <iframe sandbox>、Web Workers 上の WebAssembly を活用している
  • ブラウザがローカルコンテナなしでも AIエージェント実行環境 へと発展できることを示す事例である

ブラウザをサンドボックスとして見る視点

  • Google の Paul Kinlan は、コーディングエージェントの実行には 強力なサンドボックス環境 が必要だと考えている
    • 彼は、ブラウザがこの30年間、悪意あるコードや信頼できないコード を安全に実行するために進化してきたプラットフォームであることを強調している
    • こうした特性が、エージェント実行環境 としてブラウザを活用できる根拠になる

ブラウザベースのサンドボックスの3つの中核要素

  • Kinlan は、サンドボックスの3つの中核要素として ファイルシステムアクセス、ネットワークアクセス制御、安全なコード実行 を挙げている
    • File System Access API はブラウザでローカルファイルを扱う機能を提供し、現時点では Chrome専用 として知られている
    • CSP(Content Security Policy) ヘッダー と <iframe sandbox> 属性を通じて、ネットワークアクセスを制御できる
    • WebAssembly と Web Workers を使えば、隔離された環境でコードを実行できる

Co-do デモの構成と機能

  • Kinlan のアイデアを検証するために、Co-do というデモアプリケーションが制作された
    • ユーザーはフォルダーを選択し、LLMプロバイダー と APIキー を設定する
    • Co-do は CSPで許可された API 呼び出し を通じて LLM とやり取りし、ファイルと対話できる チャットインターフェース を提供する
    • この構造は Claude Cowork に似ているが、大容量のローカルコンテナ なしでブラウザだけで動作する

<iframe sandbox> とセキュリティ技術の限界

  • <iframe sandbox> の ドキュメント不足 が主な問題として指摘されている
    • ブラウザごとの実装差が大きく、関連資料も不足している
    • Kinlan は ダブルiframe(double-iframe) 手法 によって、内部フレームにネットワーク規則を適用する方法を示している

追加の発見と実験

  • <input type="file" webkitdirectory> 属性が Firefox、Safari、Chrome のすべてで動作することが確認された
    • これにより、ブラウザは ディレクトリ全体への読み取り専用アクセス を行える
    • これを試すために webkitdirectory デモ が制作され、今後のプロジェクトでも活用される予定である

結論

  • ブラウザはすでに セキュアな分離とコード実行のための完成度の高いプラットフォーム へと発展している
  • Co-do の事例は、ブラウザが AIコーディングエージェントの実行環境 へ拡張できることを示す実験的な証拠である

関連記事

1件のコメント

 
GN⁺ 2026-01-28
Hacker Newsのコメント

  • これは自分のリンクブログに載せた記事。文脈全体を理解するには、元記事の The Browser is the Sandbox を必ず読むべき

    • リンクブログにもそういう案内文を追加するとよさそう。自分もブログに 年表示 と 購読案内 を入れたら、その後は同じ質問のメールが大幅に減った。そのおかげで今も楽しくブログを書けている
    • あなたの継続力は本当に印象的。HNであなたの名前を見ない週がないくらい。個人的にはLLM比較記事は好みではないけれど、継続性 そのものがブランドになったのだと思う。これからも応援している

  • GoogleがNaClを作った理由は、まさにWebAssemblyの サンドボックス標準化 につながったからだと思う。DOM、JS、CSSもレンダリング用サンドボックスとして機能する。ブラウザは機能を制限することで 統一されたユーザー体験 を提供すべきだ。
    IEや旧Edgeが失敗した理由もここにある。Flash、ActiveX、Java Applet、Silverlightのような外部サンドボックスはすべて消え、asm.jsとWebAssemblyの安定化によってWebはずっとすっきりした。ちなみにFlashのActionScriptはECMAScriptやTypeScriptの設計にも影響を与えた

    • 自分は ActionScript 3 が本当に好きだった。昔、AS3でchime.tvという動画アグリゲーターを作ったことがあるが（TechCrunch記事）、開発過程は本当に楽しかった
    • JavaはActionScriptとは無関係。LiveScriptがSun/Netscapeのビジネス上の取り決めでJavaScriptに名前を変えただけだ
    • Silverlightはかなり良かったので、終了してしまったのが惜しい

  • webkitdirectory 属性を初めて見たとき、自分も驚いた。何年もWebアプリを作ってきたのに、これを見落としていた。ブラウザのサンドボックスは、何十億人もの人が 怪しいリンクをクリックしながら検証してきたセキュリティモデル だ。
    毎回コンテナを新しく立ち上げるより、はるかに成熟したアプローチだと思う。ただしブラウザには、システムコール、バイナリ実行、ハードウェアアクセスができないという制約がある。AIコーディングには十分でも、一部の作業には限界がある

    • 自分はこの方式を エージェント型フロー の構築に向いていると見ている。元ファイルを直接編集せず、要約、質疑応答、新規ドキュメント作成などへ拡張できる。ローカルLLMを使いながらでも、安全にツール呼び出しを制限できる
    • 同じ理由で、NPM開発者もNodeJSの不安定なAPIに頼るより、ブラウザのサンドボックスで実行できる ソースコードプロセッサ を作るほうがよいと思う

  • systemdやLinuxのユーザー権限システムが、サンドボックスの議論でほとんど触れられないのは興味深い。実際、これらもかなり強力で 低コストな分離 を提供している

    • Unixの権限モデルは、もともとシステムがユーザーを保護するための仕組みだった。プログラムはユーザー権限で実行されるので、プログラム自体が悪意を持つかもしれないという概念がなかった。今では プログラム間の保護 が必要だ。自分も一時期、アプリごとに別ユーザーを用意する方式を試したが、あまりに非効率だった。結局は capabilitiesモデル が必要になる。これについては xkcd 1200 がうまく説明している
    • たいていの人は今でもDockerfileを書いてそのままデプロイする程度なので、こういう議論は少ない
    • Linuxカーネルには 権限昇格の脆弱性 が多い。信頼できるソフトウェアを隔離するには問題ないが、マルウェアには無力だ
    • AIエージェントをMacOSの制限付きユーザーアカウントで隔離する sandvault のようなアプローチがある。軽量で汎用的なので、かなりよいアイデアに見える
    • systemdではブラウザ内JavaScriptのDNSやHTTPリクエストを止められないので、こうした議論には含めにくいと思う

  • File System Access API はWebの発展における大きな転換点だ。co-do.xyz ではディレクトリを選択して、AIにその中のファイルを安全に扱わせることができる。このAPIのおかげで、Webアプリは本当の 生産性ツール として定着した

    • 配布コストは下がる一方で、ブラウザで状態を管理するのは長期的には不安定だった。自分もパブリッシングツールを作っていたが、結局LangGraphとCeleryに戻った。インフラ削減より 信頼性の確保 のほうが重要だった
    • ネイティブUIが依然として優位である限り、Webアプリが完全な 第一級の生産性アプリ になるのは難しい
    • SafariとFirefoxでは、まだこのAPI機能はサポートされていない

  • ブラウザベースの実行は興味深いが、大半の 実際の業務アプリ は保守性やセキュリティ、データアクセス性の理由からクラウド中心へ移行した。ローカル実行は個人の生産性には向いているが、主流アプリには限界がある。かつてのAppleScript、COM、DDEのような デスクトップ自動化 機能が消えていった理由もそこにある

    • COMは今でもWindowsの主要なAPI伝達メカニズムとして生きている。Windows 3.x時代にDDEを扱っていた頃を思い出す
    • ブートストラップ段階のGenAIアプリでは、ブラウザに 推論をオフロード するのが経済的に必須だ。GPUコストが高すぎるので、ユーザーのハードウェアが実質的に唯一の無料リソースになっている

  • ブラウザでできることをもう2つ紹介したい

    1. webcontainer により、NodeJSのフロントエンドとバックエンドをブラウザ上で実行できる（例: bolt.diyプロジェクト）
    2. jslinux とx86 Linuxの例のように、WebAssemblyベースの完全なLinux環境をブラウザで動かせる
      理論上は、URLひとつでかなり完全な エージェントシステム を実装できる
    • 自分は v86実験 を進めている。LLMにこれをファイルシステム兼実行環境のように扱わせるのが目標だ。ただ、v86はインタラクティブUI中心なので プログラム的制御 が簡単ではない
    • webcontainers.ioは 商用のクローズドソリューション なので、オープンソースのプラットフォームと同列に語るのは不適切だと思う

  • 以前はChromeでFile System Access APIを使ってディレクトリの読み書き権限を要求できたが、タブを更新すると権限が消えていた。今は改善されたのか気になる

    • 今では 永続的な権限付与 が可能になった。Chrome開発者ブログ に詳しく書かれている
    • デスクトップ版Chrome（Ubuntu）では権限が維持されるが、Android版Chromeでは更新時にディレクトリアクセスが失われる。MDNドキュメント 参照

  • この方式でサンドボックス化されるのはファイルシステムだけだ。だが人々はメール、カレンダー、チャット、ソースコード、財務データなどにも接続したがる。ファイルシステムのセキュリティは出発点にすぎず、データ生態系全体のセキュリティ は依然として課題だ

  • このアプローチの限界が気になる。ブラウザで Gemini CLI をUX改善版として実装できるだろうか。ローカルツールとの連携も可能だろうか?

    • 完全に可能だと言い切るのは難しいが、大半のツールはJSベースなので、ブラウザでかなりの部分を実装できる。今ではNode APIのうちブラウザで動かせないものはほとんどない