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

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

その制約はもうかなり緩みました。カメラも演算も余裕があります。そこで認識性能をさらに追うかわりに、その余裕を見て気持ちのいいものに使ってみました。QR を置き換えるためではなく、隣にもう一席つくるためのものです。

なぜ今なのか

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

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

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

3 つのタイプ

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

Type Y — 単一キューブ

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

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

Type O — 六角フィールド

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

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

Type A — 三角シルエット

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

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

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

仕組み

何が自由になるのか

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

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

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

スキャナ開発状況

デコーダは開発中です。以下は実機で撮影した写真で測った現在の状態で、合成テストではなく実際のスマートフォンのカメラの結果です。

復号時間がリアルタイム性の体感を左右します。スキャナは約 0.3 秒ごとにフレームを見ますが、1 回の読み取りに数秒かかるとその間のフレームは捨てられ、精度とは無関係に「たまにしか読めない」感覚になります。いまは速度が最優先課題です。

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

中央 QR 変種は QR ブロックが中央ファインダの位置を代わりに占める形です。入口がなくしばらく読めませんでしたが、QR 自身のファインダを基準にする経路を入れて読めるようになりました。

測定 2026-08-11 · 標本はスマートフォンの 3 つのセンサー（超広角・広角・望遠）で撮った写真 9 枚 · 短辺 1440px 基準。標本が小さいので成功率ではなく現在の状態として読んでください。

仕様と実装

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

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