画面では360p・30fpsの映像が流れているのに、ページ内に<video>タグは存在しない。2026年6月12日、SaaS開発者のOm Patel氏がXで紹介した実装は、毎フレームCanvas上の色付き文字を塗り替えるだけで動画のように見せる仕組みです。ブラウザから見ればメディアではなく、ただのJavaScriptによる描画更新に過ぎません。
この記事でわかること
- 動画に見えるCanvas文字描画の基本的な仕組み
- なぜ
<video>を使わずに映像表現ができるのか - 自動再生制限や広告ブロックをすり抜けうる理由
- 同手法を採用したOSSプロジェクトの例と応用先
動画タグなしで映像を再現する仕組み
従来のWeb動画は<video>要素がメディアファイルをデコードし、ブラウザのメディアパイプラインで再生します。一方、今回の手法はHTML5 CanvasのfillText()で文字を描画し、requestAnimationFrameループでフレームごとに画面を更新します。人間の目には連続した映像に見えますが、DOM上の実体はテキスト描画の連続です。
処理の流れは次のとおりです。
- 元映像の各フレームを小さなグリッドに縮小する
- グリッドの各セルから輝度（明るさ）や色を取得する
- 輝度に応じてASCII文字や記号を割り当てる
- Canvas上の対応位置に色付き文字を描画する
- 次のフレームでCanvasをクリアし、手順2〜4を繰り返す
Arve氏のデモプロジェクト「AsciiVID」では、各文字を一時Canvasに描画して輝度を計測し、ルックアップテーブル（LUT）を事前生成する方式を採用しています。再生時はオフスクリーンCanvasに映像フレームを描画し、セルごとの輝度をLUTのインデックスに変換して文字を選びます（参考）。
なぜ「動画に見える」のか
ポイントは、ピクセル情報を文字の集合として表現することです。モノクロASCIIなら輝度の高いセルに#や@、低いセルにスペースを割り当てます。カラー版では各セルに対応する色で文字を塗り、視覚的な解像度を上げます。
GitHubの@phyrex/ascii-canvasは、グリッド解像度のImageDataから輝度でランプ文字を選び、fillTextで出力Canvasに描画する47行のコア関数で実装しています（参考）。フレームワーク非依存のWeb Componentとして、<video>要素や<canvas>を入力ソースにできます。
Om Patel氏の投稿では、360p・30fpsで再生され、ページ上に実際の動画要素がない点が強調されています。文字の密度と色数を上げる「ピクセルモード」では、ASCII文字の代わりに色付きブロックを並べ、360p相当の画質に近づけることも可能です。
ブラウザ制約をすり抜ける理由
この手法が話題になる背景に、ブラウザのメディア制限回避があります。
現代のブラウザは、ユーザー操作なしの<video>自動再生を制限します。広告ブロッカーも<video>タグや動画CDNのURLをブロック対象にします。しかしCanvasへのfillText呼び出しはメディア再生ではなく、通常のJavaScript描画として扱われます。ページ内に<video>が存在しなければ、メディアブロッカーの検知対象から外れる可能性があります。
同様の設計思想を明示しているOSSとして、ASCILINEがあります。
ASCILINEはPythonバックエンド（OpenCV + NumPy）で映像フレームをASCII文字列に変換し、WebSocketでバイナリデータをブラウザへ送ります。フロントエンドはVanilla JSでフレームを受信し、Canvasグリッドに描画します。READMEには「ブラウザから見ればJavaScriptがCanvasを更新しているだけ」と記載され、メディア制限に対して目立たない設計であることが説明されています（参考）。
ASCILINEの主な仕様は次のとおりです。
- ASCIIモード推奨解像度: 横幅200〜240セル、30fps前後
- ピクセルモード: 色付きブロックで360p相当の画質に接近
- 音声はサーバー側でFFmpeg処理し、映像とはマスタークロックで同期
- 適応型フレームコーデックで静止画面ではワイヤ転送量を大幅削減
応用と注意点
開発者向けの応用例は複数あります。ターミナルやIoT端末への低帯域配信、CSSフィルターでネオン発光や影をリアルタイム適用する表現、LLMへの映像要約入力としての文字列化などが挙げられます。ASCILINEは2026年6月時点でGitHubスター数789、フォーク数84と、開発者コミュニティから一定の関心を集めています。
一方で、広告ブロック回避能力は悪用リスクも伴います。ASCILINEはMITライセンスに加え、広告ネットワークによるブロック不能な広告配信を禁止する条項を設けています。技術的に可能であることと、倫理的に許容される用途は別問題として捉える必要があります。
パフォーマンス面では、Canvasからのピクセル読み取り（getImageData）はコストが高く、ブラウザによっては描画が重くなります。AsciiVIDの作者も、頻繁なCanvas読み取りでパフォーマンスが低下しうると注意しています。高解像度のピクセルモードでは、エンコード側のCPU負荷がボトルネックになり、音声との同期ズレが起きることもあります。
開発者が試すなら
Om Patel氏が紹介した実装は、新しいコーデックの登場ではなく、古くからあるASCIIアート技法をCanvas描画で現代化したものです。<video>を使わず文字描画だけで映像体験を再現する発想は、クリエイティブ表現とブラウザ制約の両面で開発者の関心を引きます。自分で試すなら、AsciiVIDやascii-canvasでクライアント側変換を、ASCILINEでサーバー配信型を体験するのが近道です。