プリミティブの刃

部品表を見れば、驚くほど普通だ

TokiQRの要素技術を分解すると、どれも枯れた技術か公開仕様そのものだ。

• QRコード（1994年発明）
• Base64エンコーディング
• Codec2（オープンソース音声コーデック）
• localStorage
• Service Worker
• Claude API（唯一の外部依存）

独自プロトコルはない。サーバーもない。個々の部品は誰でも手に入る。

しかし「QR1枚に音声30秒」「AIアシスタント完備」「サーバーレスで永続保管」と並べると、先端プロダクトにしか見えない。実際にはプリミティブな技術の組み合わせの設計が独自性のすべてであり、部品そのものに秘密はない。

特性を知らなければ、ここには至らない

「音声をQRに入れる」というゴールに対して、普通はOpusやAACを試す。そして「QRには入らない」で終わる。

Opusで2〜4kbpsを試すと、DTXが沈黙フレームを吐き出す。エントロピーが7.7に達し、DEFLATEが効かない。この特性に実際にぶつかり、限界を体感したからこそ、軍用通信向けのCodec2という選択肢が見えた。450bpsで75バイト/秒。ロボティックだが明瞭。QR Version 40の2953バイトに最大約29秒が収まる。

Claude APIも同じだ。「チャットボットを入れたい」だけなら選択肢は無数にある。しかしサーバーレス原則との両立を考えたとき、ステートレスなAPI呼び出し＋Cloudflare Workerの中継＋localStorageへのキー保存という構成が成立すると判断できたのは、それぞれの技術の境界条件を知っていたからだ。

フレームワークが奪うもの

フレームワークは「考えなくていい」ことを増やしてくれる。同時に「考えられない」ことも増やす。

TokiQRにはReactもなければビルドツールもない。生のHTML/CSS/JavaScriptとWASMだけだ。だからすべてのバイトがどこに行くか見える。QRの2953バイト上限に対して、どのエンコーディングで何バイト使うか、1バイト単位で設計できたのはそのおかげだ。

フレームワーク経由だと「なぜ動くか」は見えても「なぜ動かないか」の原因が抽象化の層に埋もれる。Codec2の450bpsが75バイト/秒になる計算も、Base64urlのオーバーヘッドも、すべて自分で触れるからこそ限界まで詰められた。

逆に言えば、フレームワークに乗っていたらQRに音声を入れるという発想自体が出なかった可能性がある。抽象化は便利だが、物理的な制約と向き合う機会を奪う。制約と向き合えなければ、制約の中での創造もできない。

制約が設計を洗練させる

サーバーレス原則の副産物がここにある。複雑な基盤を持てないからこそプリミティブな技術しか使えず、結果としてプリミティブな技術だけで先端感が出る組み合わせを見つけざるを得なかった。

ヒートマップもオンボーディングツアーもCRMも導入しなかったのは、サーバーサイドの状態保持を前提とするからだ。AIアシスタントだけが例外的に成立したのは、ステートレスな呼び出しで完結するからだ。選択肢を絞ったのではなく、制約が選択肢を絞った。

高レベルなフレームワークだと抽象化の裏に隠れて見えないものが、低レベルだと全部自分で判断しないといけない。それは負担であると同時に、参入障壁でもある。同じ部品は誰でも手に入るが、同じ組み合わせには誰もが至れるわけではない。

プリミティブであることは、弱さではない。刃は、単純であるほど鋭い。