Datasette Apps とは—サンドボックス環境で動作するカスタム UI
Datasette Apps は、Datasette インスタンス内で動作する自己完結型の HTML+JavaScript アプリケーションです(参考)。
コアとなる特徴は以下の通りです。
- Datasette が提供する JSON API を通じて SQL クエリを実行できる
<iframe sandbox="allow-scripts allow-forms">の中で動作し、親アプリケーションのセキュリティを損なわない- 設定により読み取り専用、または書き込みクエリにも対応可能
Datasette Apps は、セキュアなサンドボックス環境でありながら、バックエンド のデータベースに直接アクセスできる仕組みが最大の特徴です。
Simon Willison 氏の実装では、実際にプロトタイプのタイムラインアプリケーションが公開されており、agent.datasette.io でデモを試すことができます。
セキュリティ設計—iframe サンドボックス + Content Security Policy
このアーキテクチャの巧妙な点は、セキュリティ面にあります。
開発者が信頼できないコードをホストすることになる場合でも、いくつかの層で保護されます。
| 保護レイヤー | 手段 | 効果 |
|---|---|---|
| 親プロセス隔離 | <iframe sandbox> 属性 |
DOM アクセス、クッキー、localStorage へのアクセスを遮断 |
| 外部通信制限 | <meta http-equiv="Content-Security-Policy"> |
外部ドメインへの HTTP リクエストを禁止 |
| ポリシー固定化 | CSP ヘッダ設定後の不変性 | マリシャスな JavaScript によるヘッダ削除・変更を防止 |
特に注目すべきは、CSP ポリシーが 一度設定されると frame 内で変更不可能 という設計です。これにより、悪意あるコードが後から CSP をバイパスするといった攻撃を根本的に防いでいます。
Datasette Apps のセキュリティモデルは、トラストレスな環境でコード実行を許可する必要があるクラウド開発者やプラットフォーム運用者にとって、実装のリファレンスになる可能性があります。
Sandbox 属性の活用と CSP の組み合わせは、AI アシスタントの Artifacts 機能(例えば Claude Code のようなツール)にも応用可能な考え方ではないでしょうか。
なぜ今、Datasette Apps か—データと UI の分離から統合へ
Willison 氏が Datasette Apps を開発した背景には、彼自身の過去のプロジェクト経験があります。
Eventbrite 在籍時に構築した内部検索エンジンでは、複数のシステムからドキュメントを SQLite に取り込み、Datasette で公開し、クライアント側の JavaScript で SQL クエリを直接構築して検索機能を実装していたとのこと。この試行錯誤の過程で「フロントエンド JavaScript がバックエンド SQL API に直接クエリを投げる」パターンが、実は非常に生産性が高いことに気づいたと述べています。
一方で、AI 系ツールとしては Claude Artifacts(Anthropic の Claude に統合されたコード実行機能)の制約を意識しています。
- Artifacts は一時的であり、永続的なデータストアを持たない
- データベースバックエンドを付ければ、Artifacts のような使い勝手でありながら、複数ページのアプリケーション開発が可能になる
このロジックから、Datasette Apps というより汎用的な機能へと進化させたわけです。
シンプルな JSON API + サンドボックス化された JavaScript という組み合わせは、開発者向けツールやデータ分析 UI の構築方法として、今後の標準になる可能性があります。
実装パターンとして何が得られるか
本実装から学べる技術パターンとしては以下が挙げられます。
- iframe の srcdoc 属性と CSP メタタグの組み合わせ:HTML+CSS+JavaScript を一つの HTML ドキュメントに埋め込み、厳密なセキュリティポリシーで束縛する
- postMessage() + MessageChannel による API ゲートウェイ:iframe 内のコードから外部へのアクセスを制限しつつ、許可された API に限定的にアクセスさせる仕組み(記事の後半で言及されている)
- read-only と write クエリの分離:stored queries を使用して、ユーザーが実行可能なクエリセットを明示的に制限する
エンジニアの方がもし個人プロジェクトで 「データはデータベースに、UI はシンプルに分離したい」 という課題を持っていれば、このアプローチは大いに参考になると感じます。
また、前述の参考記事「TownSquare」のような、最小限の依存関係で Web サイトに機能を追加する という開発哲学にも通じるところがあります(参考)。単一の <script> タグを埋め込むだけで動作するツールと、iframe + API 形式の Datasette Apps は、表現方法は異なりますが、「シンプルで自己完結している」という共通点があります。
実際の利用シーンと今後の展開
現在、Datasette Apps は agent.datasette.io のデモインスタンスで試用可能です。GitHub 認証によってアクセスできます。
このパターンが広がる可能性としては、以下が考えられます。
- 個人プロジェクト: ローカル LLM や Stable Diffusion を実行しているエンジニアが、生成結果をデータベースに蓄積し、カスタム UI で検索・閲覧・フィルタリングするといった用途
- 社内ツール: BigQuery や Snowflake といったデータウェアハウスの上に、カスタム分析 UI を乗せるための軽量なフレームワークとして
- AI エージェント連携: Claude API や OpenAI API と連携し、AI の出力をデータベースに保存し、ユーザーフレンドリーな UI で返すという流れ
セキュリティ設計がしっかりしているため、マルチテナント環境や信頼できないコードを実行する必要がある場面でも安心です。