OpenGenerativeUI — ClaudeのVisual Artifactsをオープンソースで再現した構造

Claudeが会話中にチャートやダイアグラムを生成する機能を出した途端、CopilotKitが同じものをオープンソースで作った。リリースから実装までの速度が速い。リポのコントリビューターにClaudeが載っているのも面白い — Claude Codeでコミットすると自動的に付く。

核心は単純だ。ユーザーがプロンプトを入力、AIエージェントがHTMLを生成、それをiframeでレンダリング。

モノレポ構造

Turborepoベースで3パッケージ。

apps/app — Next.js 16 + React 19 + Tailwind CSS 4フロントエンド。CopilotKitのチャットUI（<CopilotChat>）でユーザー入力を受け、useComponentフックで生成HTMLをサンドボックスiframeにレンダリング。

apps/agent — Pythonエージェント。LangGraph + CopilotKit SDK。「Deep Agents」という概念があり、エージェントがスキルリストから適切な可視化方式を選択する構造。

apps/mcp — MCP（Model Context Protocol）サーバー。デザインシステムとスキル情報をエージェントに提供。

エージェントの可視化判断

プロンプトが入ると、エージェントが判断する。テキストで答えるか、ビジュアルコンポーネントを作るか。

可視化が必要と判断したら、リクエストタイプに応じて技術を選択。プロセス説明ならSVGフローチャート。データ比較ならChart.jsバーチャート。アルゴリズムならCanvasアニメーション。3DならThree.js。ネットワークグラフならD3.js。この決定マトリクスがエージェントプロンプトに内蔵されている。

生成されるのは完全なHTMLドキュメント。<script>タグでCDNライブラリをロードし、インラインJavaScriptで可視化を描画。Reactコンポーネントではなく純粋HTML。

iframeサンドボックスレンダリング

生成HTMLは<iframe sandbox>内で実行。メインページと完全に隔離。

フロントエンドのwidgetRendererフックがこの過程を処理。スケルトンローディング → HTML注入 → ResizeObserverで自動高さ調整 → フェードインアニメーション。ライト/ダークテーマも自動検出。

iframeを使うのはセキュリティのため。AI生成コードをメインページDOMに直接注入するとXSSリスクがある。sandbox属性でallow-scriptsだけ開き、残り（top-navigation、same-origin等）はブロック。

あるコメントが核心を突いた

「生成したhtmlをiframe安で렌더링する方式ですね」 — その通り。これがアーキテクチャ全体の核心だ。AIがどの技術を使おうと（Chart.jsでもThree.jsでもD3でも）最終成果物はHTML文字列で、それを隔離されたiframeに入れる。単純だが効果的な設計。

この方式の利点：フロントエンドがAIの出力形式を事前に知る必要がない。HTMLであれば動く。新しい可視化タイプ追加時にフロントエンドコードを触る必要がない。

対応する可視化

アルゴリズムアニメーション（二分探索、BFS/DFS、ソート）、3D（Three.js/WebGL/CSS3D）、チャート（Chart.js — 円、棒、線）、ダイアグラム（SVGフローチャート、ネットワークグラフ）、ウィジェット（フォーム、数学グラフ、対話ツール）、サウンド（Tone.jsシンセサイザー）。

範囲は広い。だが結局エージェントが生成するのはHTML+JSコード。品質はLLMのコード生成能力に100%依存。

正直な評価

アイデア自体は良い。Claudeの機能をオープンソースに持ってきた点に価値がある。

だが現実的な限界がある。

エージェント品質がLLMに依存。可視化判断、HTML生成、エラーハンドリング — 全てプロンプトエンジニアリング次第。モデルが変われば結果も変わる。

Pythonエージェントが必須。フロントだけ切り出して使えない。LangGraph + CopilotKit Python SDKがバックエンドに必要。デプロイ複雑度が上がる。

Star 1.1K、リリース直後。Claudeの機能リリースとほぼ同時に出たので、コード成熟度はまだ検証が必要。

xguruの言う通り、「クロードが出した機能をそのまま実装するのを手伝うクロード」 — この状況自体が現在のAIエコシステムをよく表している。