QR はよく読めます。
ただ綺麗だった試しがない

タイプ

どこに載せるかで選んでください。平面タイプはすべて同じデータ契約を共有し、シルエットだけが異なります。True 3D H は Y グループの実立方体拡張で、形式が別になっています。以下のコードにはすべて https://tl.estre.so が入っています。

Type Y — 単一キューブ

3 面がそれぞれ n×n の格子。ひと塊なので看板やグッズに向きます。

n = 13 / 21 / 25 · 正味ペイロード 31 / 98 / 141 B

True 3D H — Y グループの実立方体拡張

実物のキューブの 1…6 面に別々のデータを載せる独自形式です。ジェネレータから回転動画（MP4）・紙の展開図・3D プリント用ファイルも出力できます。

H0…H8 · n = 13…45 · 正味ペイロード 3 面 3…333 B · 6 面 6…666 B（ECC-M・3 トーン）

Type O — 六角フィールド

最も基本の形。中央のファインダを中心に菱形セルが広がります。

k = 6 / 8 / 10 / 12 · 正味ペイロード 18 / 39 / 65 / 97 B

Type C — 3時ノッチの超大容量

3時方向のノッチが、シルエットだけで向きとタイプを確定します。C0〜C3は近距離スキャン専用で、C1以上は近づけるか拡大して読み取ります。

k = 14 / 16 / 18 / 20 · 正味ペイロード 130 / 172 / 220 / 255 B

Type A — 三角シルエット

六角のコアにコーナーパッチを足して正三角形になります。

k = 6 / 8 / 10 · 正味ペイロード 31 / 62 / 101 B

Type K — 六芒星

正三角形とその180°像を合わせた星。同じ k で容量が最大です。

k = 6 / 8 / 10 · 正味ペイロード 43 / 86 / 138 B

正味ペイロードは ECC-M 基準です。H を含むすべてのタイプにフォールバック QR を併記でき、TL コードが読めない環境でも最低限の経路が残ります。H は既定で左上の角に QR を置きます。

なぜ今なのか

QR は当時の最適解でした。白黒の 2 値、正方モジュール、大きなファインダ — どれも性能の限られたカメラでも読めるようにするための選択です。その制約の下では、見た目を諦めるのは合理的でした。

その前提が変わりました。いまのスマートフォンのカメラは当時とは比べものにならず、リアルタイムの映像処理がブラウザの中で動きます。ならばその余裕を密度にではなく、見え方に使ってもいいのではないか — それがこれを作った理由です。

代わりに密度は捨てました。菱形セルは正方モジュールより面積効率で不利です。このフォーマットは密度で競いません。たくさん詰め込みたいなら QR が適しています。

仕組み

何が自由になるのか

単調変換に対して不変です。 全体的な照明の変化・ガンマ・プリンタのトーンマッピングは単調なので、順序を入れ替えられません。順序が保たれれば値は生きます。

レンダラが自由です。 データ契約は「面どうしの順序 + 最小分離幅」だけ。その中で色・質感・面のグラデーション・アニメーションがすべて開いています。この自由度こそがこのフォーマットの核心です。

ただし「自動できれいになる」わけではありません。自由になるのは契約であって結果ではありません。その中で何を描くかは作り手の仕事のままです。

スキャナ改善状況

デコーダは動作します。4 タイプとも実機の写真から読めており、いまは認識率と速度を上げる改善段階です。以下の時間は実機で撮影した静止画 1 枚を 1 回復号した値で、ライブの初回ロック時間や成功率ではありません。

静止画 1 枚を 1 回読む基準です。現在は Type O が最も短く、A・K・Y はその後ろで近い値です。⚠ 以前の掲載で「Type Y が最速」と書いたのは写真 9 枚の標本で、標本を広げて測り直すと順序が逆転しました。ライブの初回ロック時間として読まないでください。

静止画 1 回の復号時間だけではライブの体感を予測できません。試験版の初期実機計測では、1 フレームが速くても成功までに多くのフレームを要すると初回ロックが遅くなり、タイプの順序も静止画の表とは異なりました。まだ 1 台の小さな標本なので、ライブの実用性評価は付けず追加測定中としています。

撮影条件も大きく効きます。実測ではセルあたり 9 ピクセルが復号の下限で、同じ距離でも超広角レンズで撮るとコードが小さく写ってこの線を下回りました（超広角 7.6px 失敗 / 広角 9.1px 成功）。スキャナにレンズ選択を入れているのはそのためです。

中央 QR 変種では QR ブロックが中央ファインダを置き換え、QR のファインダを位置・方向の入口として周囲の TL 本文を復号します。QR は既定ではリーダーリンクのフォールバックで、ペイロード自体は TL 本文に残ります。2026-08-28 以降、Type O・C・A・K のジェネレータ既定は中央TLファインダと、外側の左上の角に置くフォールバック QR です。中央 QR はファインダの選択肢の一つとして残っています。上の表の中央 QR の行は、この変種を測った 2026-08-13 ラウンドの値です。

Type C と True 3D H は上の表に含まれておらず、H の実カメラの認識率や FPS は保証しません。スキャナにはエンジンが 2 つあります。R1 は平面の TL タイプを 1 フレームずつ読み、既定の R2 は Type Y と H を複数のフレームにわたって集めて読みます。H は必要な面が揃い、RS/CRC 検証を通過してから結果を表示します。BarcodeDetector に対応したブラウザでは R2 が通常の QR コードも読み取り、QR コードから読んだリンクは自動では開きません — アドレスを確認してからタップして開きます。

測定 2026-08-27 · 標本 110 枚（各枚を短辺 960 · 1440px の 2 解像度で試行）。⚠ 標本の大半はモニター画面を撮った写真で、印刷物や実配置の数値ではありません。またコーパス 233 枚のうち 123 枚は「今は読めないもの」を意図的に集めた限界・実験フレームなので、性能標本から除いています。中央 QR の行だけ 2026-08-13 の旧ラウンド値です。

仕様と実装

フォーマット仕様とリファレンス実装は Apache License 2.0 で公開しています。バニラ JavaScript、リポジトリ内の Node.js ビルドスクリプト、ランタイム依存 0 — 単一の HTML ファイルで動きます。

デコーダだけの実装でも適合実装とみなします。普及は読む側から始まるからです。