TLcube

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

ポスター、パッケージ、名刺 — QR が入らない場所はほとんどありません。けれど何週間もかけたデザインの上に、最後に白黒の四角を置くのはいつも心残りでした。とはいえ QR があの形なのには理由があります。1994 年のカメラと演算で「とにかく読める」ようにした結果なのです。

その制約はもうかなり緩みました。カメラも演算も余裕があります。そこで認識性能をさらに追うかわりに、その余裕を見て気持ちのいいものに使ってみました。QR を置き換えるためではなく、隣にもう一席つくるためのものです。 できあがるのは3Dバーコード——平面に印刷されますが、目には立体に見えます。

なぜ今なのか

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

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

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

タイプ5種

どこに載せるかで選んでください。5 タイプとも同じデータ契約を共有し、シルエットだけが異なります。以下のコードにはすべて https://tl.estre.so が入っています。

Type Y — 単一キューブ

Type Y — 単一キューブ

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

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

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

平面の Type Y とは別形式で、H0…H8 の格子と固有データ面 1…6 面を使います。空き面の画像やループ回転を設定し、glTF、MP4、Minecraft .schem 構造物を出力できます。実物のキューブを作る紙の展開図(SVG・PNG・PDF・直接印刷)と 3D プリント用の 3MF・STL も出力できます。

必要な面が揃い、RS/CRC 検証を通過してから結果を表示します。下の静止写真の測定に H は含まれず、実カメラの認識率や FPS を保証しません。

Type O — 六角フィールド

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 — 三角シルエット

Type A — 三角シルエット

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

k = 6 / 8 / 10 / 12 · 正味ペイロード 31 / 62 / 101 B
Type K — 六芒星

Type K — 六芒星

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

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

正味ペイロードは ECC-M 基準です。5 タイプともフォールバック QR を併記でき、TL コードが読めない環境でも最低限の経路が残ります。

仕組み

1. セル = 3 つの菱形

rhombille タイリングで六角セルを T・L・R の 3 面に分けます。

2. 順序 = シンボル

3 面の輝度に順位をつけると 3! = 6 通り — base-6 の 1 桁です。

3. 3 桁 = 1 シンボル

素体 GF(211) 上の Reed–Solomon で誤りを訂正します。

何が自由になるのか

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

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

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

スキャナ改善状況

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

タイプ実写真の復号静止画 1 回の復号ライブ検証
Type Y — 単一キューブ9 / 16約 1.8 秒追加測定中
Type O — 六角フィールド29 / 48約 1.9 秒追加測定中
Type A — 三角シルエット18 / 19約 2.4 秒追加測定中
Type K — 六芒星18 / 27約 3.1 秒追加測定中
中央 QR 変種(4 タイプ共通) · 2026-08-138 / 9—追加測定中

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

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

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

中央 QR 変種では QR ブロックが中央ファインダを置き換え、QR のファインダを位置・方向の入口として周囲の TL 本文を復号します。ジェネレータは Type O・A・K でこの検証済み経路を標準にしました。QR は既定ではリーダーリンクのフォールバックで、ペイロード自体は TL 本文に残ります。

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

仕様と実装

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

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

サイト役割状態
tlcube.estre.soジェネレータ稼働中
tlscan.estre.soスキャナ稼働中 — 状況 ›
tl.estre.so紹介ハブここ