重ねたボタンはPNGに写らない――CanvasにHTMLを焼き込む実験的APIが埋めようとしている溝

公開前の下書きです。事実確認と編集を終えていますが、公開・SNS投稿はまだ行っていません。

Canvasで作ったチャートに、折り返し付きの注釈と「いいね」ボタンを重ねる。見た目は自然に合成され、クリックもドラッグもできる。ところが、そのチャートを監査用にPNGとして書き出した瞬間、注釈もボタンも消えている。Canvasの画像データには、上に重ねただけのHTMLは最初から含まれていないからだ。

この「重ねても写らない」という溝を埋めようとしているのが、WICG（Web Incubator Community Group、標準化以前のアイデアを試す団体）が提案している実験的API、通称HTML in Canvasである。

結論：これはまだ標準化された機能ではない。WICGの提案段階であり、Chromeがフラグ付き・Origin Trial（本番サイトの一部ユーザーに限定して試験提供する仕組み）で検証している段階に過ぎない。だが、Canvasの中に「本物のHTML」を焼き込みたいという需要そのものは切実で、今のうちに設計思想と懸念点を押さえておく価値がある。

fillTextの限界と、今日の3つの回避策

Canvasに文字を描く基本手段はfillText()だが、これは行の折り返し位置を自分で計算し、太字や絵文字の混在を自前で処理し、スクリーンリーダーには何も伝えない、という制約がある。ナオ（Web標準を取材する技術記者）は編集部の議論で、この制約を踏まえたうえで「標準化された」という言葉を使うのは時期尚早だと繰り返し釘を刺した。

今日、開発者が使っている回避策は主に3つある。

DOMをposition: absoluteで重ねる――見た目も操作性も保てるが、Canvasのピクセルとして統合されないため、toDataURL()やgetImageData()、captureStream()（画面や要素を動画として録画するAPI）には一切写らない。
SVGのforeignObject経由で画像化する――外部リソースを読み込むとCanvasが「汚染」され、書き出し自体がブロックされることがある。
html2canvasなどのライブラリを使う――CSSの再現度がライブラリの実装依存になる。

ハルト（canvasを多用するフロントエンド開発者）は、Canvasエディタでの実務を例に挙げ、複雑なレイヤー構造を持つエディタで注釈をCanvas内オブジェクトと座標同期させたい場合、DOM重ね合わせではtoDataURLによる一括書き出しが不可能だと指摘した。ゲームUIの吹き出し、地図ラベル、監査用スクリーンショットなど、見た目と書き出しの両方が必要な場面ほど、この溝が痛む。

手法	できること	書き出し（PNG/WebGL/録画）に写るか	実務で困る場面
`fillText()`	Canvasのピクセルにはなる	写る	折り返し・装飾・読み上げを自分で作り込む必要がある
DOM重ね合わせ	見た目・操作性は本物のDOM	写らない	監査用スクリーンショット、動画配信で注釈が消える
SVG `foreignObject` / html2canvas	画像として書き出せる	写る（ただし画像化された時点のみ）	外部リソースでの汚染、CSS再現度がライブラリ依存
HTML in Canvas（提案中）	本物のDOMのまま、ピクセルにもなる	写る	現状はChromeのみ、標準化・保証は未成熟

表は議論とWICG提案の内容を基にした編集部の整理。

提案の中身：3つの構成要素

HTML in Canvasは、単一の新機能ではなく3つの部品からなる。

layoutsubtree属性：<canvas>要素に付けると、その子要素が通常のレイアウト・ヒットテスト（クリック判定）に参加できるようになる。
drawElementImage()（2D Canvas用。WebGL用のtexElementImage2D()、WebGPU用のcopyElementImageToTexture()もある）：子要素をCanvasへ描画し、DOMの表示位置とCanvas上の描画位置を同期させるための変形情報を返す。
paintイベント：子要素のレンダリングが変化したときに発火し、再描画のタイミングを知らせる。

この3つが揃うと、描いたHTMLはCanvasのバッファに「本物のピクセル」として入る。つまり、操作可能なUIのまま画像として書き出したり、WebGL/WebGPUのテクスチャとして使ったりできる設計になる。ただし、アクセシビリティとヒットテストの完全性は、現時点では開発者フィードバックを募集している段階であり、確定した保証ではない。

今どの段階にあるのか

テツオ（事実確認を担う編集者）が議論の中で繰り返し強調したのは、「実験段階と正式仕様」「確認済み事実と推測」を厳密に分けることだった。現状を整理すると次のようになる。

WICG提案（インキュベーション段階）
        ↓
Chromiumにフラグ付きで実装
  chrome://flags/#canvas-draw-element
        ↓
Chrome公式ブログがOrigin Trialを案内
  対象期間はChrome 148〜150とされる
  （Chrome公式ブログに記載。Platform Statusの生データでは未確認）
        ↓
CSS WG / WHATWGの正式な標準化トラックには未到達
Baselineにも未到達
Safari / Firefoxの対応表明は確認できていない

図は公式ブログ・WICGの提案・blink-devメーリングリストの投稿を基にした編集部の整理。2026年7月時点はChrome 148のリリースサイクルにあたる。

反対意見：便利さの裏にある3つの懸念

編集部の議論が機能紹介で終わらなかったのは、ここからの反論があったからだ。

ミサ（Webアクセシビリティの研究者）は、layoutsubtreeによって実DOMがCanvas内に残り続けることの意味を問うた。

描画内容をDOMとして保持し続ける一方で、視覚的にはピクセルとして統合される。スクリーンリーダーがCanvas内の「描画されたHTML」を正しく認識し続けられるか、アクセシビリティの完全な保証は未成熟な段階にある。

レン（ブラウザセキュリティとプライバシーの専門家）は、HTMLがピクセルとして焼き込まれること自体がフィンガープリンティング（デバイスやブラウザの微細な特徴から個人・端末を識別する手法）の新しい経路になり得ると反論した。

フォントのアンチエイリアス処理やサブピクセル単位のレンダリング特性、OS固有の描画エンジンに起因する微細な誤差までを、Canvasのピクセルデータとして抽出可能にする。従来のテキストベースの識別よりも高精度な「指紋」を生成できるリスクがある。

アオイ（ブラウザ互換性を見る市場分析担当）は、この懸念が解消されない限り他ベンダーが追随する動機が弱く、「Chrome限定の実験的機能」に留まり続ける可能性を指摘した。SafariとFirefoxの対応表明は現時点で確認できていない。ソラ（Web開発を学び始めた初学者代表）は、この状況を「Chromeで動いてもSafariでは動かない」という素朴な言葉で言い換え、初学者が最新技術に飛びつく気持ちと、動かなくなるリスクの板挟みを率直に投げかけた。

読者が持ち帰るべき判断基準

議論の到達点は、機能への賛否を決めることではなく、時間軸を分けることだった。

今すぐ試したい
  → chrome://flags/#canvas-draw-element を有効化するか
    Origin Trialに登録して検証用途で触る

本番に組み込みたい
  → まだ早い。標準化トラック未到達、Baseline未到達、
    Safari/Firefoxの対応表明も未確認
    アクセシビリティ・フィンガープリンティングへの
    仕様上の回答が出るまで待つのが安全

図は議論から導いた、読者向けの判断整理である。WICG提案とChromeの実装状況は公式資料で確認できるが、この判断基準自体は編集部の整理であり、公式が推奨手順として示しているものではない。

将来、WebGPUのテクスチャとしてDOMを直接扱えるようになったり、Canvasベースのエディタがこの仕組みを前提に進化したりする可能性は議論でも語られたが、これは参加者の推論であり、確定した計画ではない。

デモ：PNG書き出しで「今日の限界」を体験する

デモを開くでは、Canvasで描いた背景の上に、本物のHTML（折り返し付きの吹き出し、クリックできる「いいね」ボタン、ドラッグできるスライダー）を重ねた2つの場面を用意した。見た目も操作性も普通のWebページと変わらない。

しかし「PNGとして書き出す」ボタンを押すと、多くのブラウザでは書き出された画像に背景のCanvas描画だけが写り、重ねたHTML部分が消えていることが分かる。これが、この記事で説明した「DOM重ね合わせは今日でも見た目と操作性を再現できるが、書き出しには写らない」という限界そのものだ。HTML in Canvas APIに対応したブラウザで開いた場合は、ネイティブAPIで合成され、書き出し結果にもHTML部分が含まれる旨が表示される（現時点でこれに対応するブラウザは一般には普及していない）。

出典を読むときのポイント

WICG/html-in-canvas：layoutsubtree属性、drawElementImage()系API、paintイベントという3つの構成要素の説明を確認した提案本体。
Chrome公式ブログのOrigin Trial案内：Origin Trialの実施と、対象期間がChrome 148〜150とされていることを確認した一次資料。
blink-dev「Intent to Experiment」・「Ready for Developer Testing」：Chromiumチーム内で実験段階として扱われていることを確認したメーリングリストの記録。
Chrome Platform Status（feature 5172548013916160）：Chrome内での機能追跡ページ。ページ本文はJS描画のため自動取得ツールでは詳細を直接確認できておらず、参照のみとして扱った。