1. なぜ「有料体験」なのか
ソフトウェアの世界では無料トライアルが標準だ。14日間、30日間、機能制限つき。ユーザーは気軽に試し、合わなければ離脱する。TokiQRのエンコーダーも同様に、誰でもブラウザ上で音声QRを生成できる。無料で、制限なく。
しかしTokiQRの本質的な体験は、マルチQRにある。無料のシングルQRでは、1枚に収まる範囲でしか記録できない。クレジットを購入すれば、その制約が外れる。品質を落とさずに長時間の音声を記録し、複数のQRに分割して保存する——その体験を経なければ、プロダクトの核心には触れられない。
無料トライアルのフィードバックは「試してみた」という感想だ。有料体験のフィードバックは「使った」という事実だ。
モニタープログラムは、この「使った」というフィードバックを得るために設計された。モニターは通常の購入者と同じフローでクレジットを購入し、TokiQRの全機能を実際に使い、そのうえでフィードバックを返す。
モニター参加者にとって、有料プロダクトに最初から金銭的リスクを負うのは心理的なハードルだ。無料で試してから判断したい、不満があれば返金してほしい——そう考えるのは自然だろう。モニタープログラムでは、正規の決済フローを通しつつ、同額がWise経由で戻ってくる。実質0円で体験できるため、金銭的な不安なく、純粋にプロダクト体験に集中できる。
この構造はギフトエコノミーに通じるものがある。従来の市場取引では、支払いと引き換えにサービスを受け取る。モニタープログラムでは、金銭は循環し、実質的な交換は「体験」と「フィードバック」の間で成立する。モニターはプロダクトを体験し、その価値を公開コメントとして還元する。TokiStorageは信頼のシグナルと改善の手がかりを受け取る。義務ではなく自発的な互恵——それがこのプログラムの根底にある。
類似のモデルは存在する。ミステリーショッパーは正規の購入フローで体験し、費用は全額返還され、レポートを提出する。構造的にはもっとも近い。ただしフィードバックは非公開の内部資料にとどまる。Amazon Vineのようなプロダクトテスティングは公開レビューを伴うが、製品は無料提供されるため購入フローを通らない。「試した」という感想と「買った」という事実は異なる。キャッシュバックプログラムは購入額の一部を返金するが、フィードバック収集ではなくマーケティング施策だ。
TokiQRモニターはこれらの要素を再構成している。正規の購入フローを通り、全額が戻り、フィードバックはWisetag——決済に使ったアカウント名——と紐づけて公開される。匿名レビューとは異なり、「この人は実際に購入した」と第三者が確認できる。さらに、モニターが作成したコンテンツはそのまま手元に残る。気に入ればそのまま使い続けるだけでよく、「無料から有料へ」という転換のステップが存在しない。
スタートアップがプロダクトを作り始めた頃にありがちな行為がある。限られた知り合いに声をかけ、無料にしたり、個別に配慮したりしながらフィードバックをもらう。善意に頼った属人的なやり方だ。モニタープログラムとしてあらかじめ設計しておけば、参加の間口は知り合いに限定されない。条件とフローが明文化されているから、誰でも同じ条件でモニターに参加できる。参加条件はWiseアカウントの作成、PWAのインストール、フィードバックの公開——すべてページ上に明示されている。条件を満たせば、人を選ばない。Wiseは個人でも今日始められる。入金もデビットカード、銀行振込、Apple Payなど複数の手段に対応しており、手続きに迷うことはない。日本のスマートフォン世帯保有率は90%を超え、60代で94%、70代でも84%に達している（2025年、NTTドコモ モバイル社会研究所）。世界全体でも人口の約90%がスマートフォンを保有する。実質、スマートフォンを持っていれば参加できるという条件は、もはやほとんどの人に開かれていることを意味する。これにより、家族、親戚、近隣の人、知人、出会う人すべてにモニターを案内できる。
2. クエストという体験設計
モニターページを開くと、5つのクエストが表示される。「音声を録音してQRを作る」「印刷してスキャンする」「マルチQR100クレジットを購入する」「バルクモードで複数ページを生成する」——といった具合だ。各クエストは、TokiQRの核心的な機能に対応している。
クエストという形式を採用した理由は、自由度の高い「何でもお試しください」ではフィードバックが散漫になるからだ。「何を試せばいいか分からない」「どこまでやればいいのか」——そうした迷いが、結果としてフィードバックの質を下げる。クエストは、モニターが体験すべき核心を明示し、完了条件を示す。
既存の購入フローに乗せる
クレジット購入のクエストでは、モニター専用の決済ロジックを用意しない。モニターは通常の購入者と同じ credit.html のフローで100クレジットを選び、Wiseで送金する。クレジットが有効化された時点で、クエストの達成条件がクリアされる。金額判定や送金目的の識別は不要だ。既存のクレジット有効化イベントがそのまま達成シグナルになる。
モニターの体験はTokiStorageにとっても資産になる。特集ニュースレターの使い勝手に対するフィードバックが得られ、サービスを推薦してくれる人との接点が生まれる。モニターが作成したコンテンツはニュースレターに収録され、アーカイブとして蓄積される。モニター側にも追加の負担はない——購入したクレジットで作った成果物はそのまま手元に残り、気に入ればそのまま使い続けられる。
モニター専用の決済フローを作ると、通常フローとの乖離が生まれる。「モニターとして買った体験」と「普通に買った体験」が異なれば、フィードバックの価値が下がる。同じフローを通ることで、モニターは実際の購入者と完全に同じ体験をする。
ゲーミフィケーションではない
クエストという名前はゲーム的だが、目的はゲーミフィケーションではない。ポイントもバッジもランキングもない。クエストは単に「この順番で試してほしい」というガイドであり、プロダクトの機能を網羅的に体験するための最短経路だ。体験の設計を提供者側が引き受けることで、モニターの負担を最小化する。
3. Wisetagという公開アイデンティティ
モニターは申し込み時にWisetagを登録する。WisetagはWise（国際送金サービス）のアカウント名だ。TokiStorageの決済はWise経由で行われるため、Wisetagはそのまま「この人は実際に決済した」ことの証明になる。
フィードバックはWisetagと紐づけてパブリックに公開される。匿名のレビューではない。決済アカウントと結びついた、検証可能なフィードバックだ。これが信頼シグナルとして機能する。「この声は、実際に買った人の声だ」と、第三者が確認できる。
匿名レビューは量で勝負する。Wisetagレビューは検証可能性で勝負する。
4. GitHubに刻むフィードバック
モニターのフィードバックは、データベースではなくGitHubリポジトリのJSONファイルとして保存される。年ごとに1つのJSONファイル——monitor/voices/2026.json——が作られ、新しいフィードバックが先頭に追記される。
なぜデータベースではなくJSONなのか。TokiQRはPWA（プログレッシブウェブアプリ）であり、バックエンドサーバーを持たない。GitHub Pagesから配信される静的サイトだ。データベースを使えば、サーバーの運用、認証、バックアップ、スケーリングが必要になる。JSONファイルなら、ブラウザからfetchで取得するだけでいい。
排他制御とコミット
フィードバックの書き込みはGoogle Apps Scriptが担う。LockServiceによる排他制御を取得し、GitHub APIで年ファイルを読み取り、新しいエントリを先頭に追加し、mainブランチに直接コミットする。ブランチを作ってプルリクエストを出す方式ではなく、排他制御下での直接コミットだ。
この設計判断は、auto-mergeの競合リスクを排除するためだ。2人のモニターがほぼ同時にフィードバックを送信した場合、プルリクエスト方式ではファイルのコンフリクトが発生しうる。LockServiceが同時実行を直列化し、GitHub APIへの直接コミットがコンフリクトを原理的に排除する。
5. アーカイブローテーション
年ファイルが1000件を超えたらどうするか。答えは、超過分をナンバリングファイルに退避することだ。
閾値は1000件、退避サイズは500件。年ファイルが1000件を超えた時点で、末尾の500件（最も古いエントリ）が 2026-001.json として切り出される。次に超えたときは 2026-002.json。年ファイルは常に最新の500〜1000件だけを保持する。
クライアント側はページングで対応する。年をクリックすると、まずアクティブな年ファイルが表示される。退避ファイルがあれば、ページナビが出現し、古いフィードバックを辿ることができる。
1000年後にファイルが肥大化して破綻しないよう、最初から退避ロジックを組み込んでおく。遡って修正するほうが、はるかに難しい。
6. ニュースレター式ナビゲーション
フィードバックの閲覧画面には、TokiQRのニュースレターと同じ世紀→巻→年のナビゲーション構造を採用した。最初は年ナビだけで十分だが、10年、100年と続けば、年の一覧は長大になる。世紀ごとの折りたたみ、20年ごとの巻——この階層構造が、いつの時代のフィードバックにも辿り着ける導線を提供する。
デフォルト表示は「最新10件」だ。年をクリックすれば、その年のすべてのフィードバックが表示される。過剰設計に見えるかもしれないが、ナビゲーション構造の変更は既存のURLや表示ロジックに影響する。最初から1000年を前提にしておけば、あとは件数が増えるだけだ。
7. 信頼の設計パターン
モニタープログラムは、以下の三層で信頼を構築する。
- 体験層：有料の正規フローを経ることで、フィードバックの根拠を担保する
- 公開層：Wisetagと紐づけたパブリックな声が、匿名レビューにはない検証可能性を提供する
- 永続層：GitHubの静的JSONが、データベース障害やサービス終了による消失リスクを排除する
どの層も、既存のインフラ——Wise、GitHub、ブラウザ——の上に成り立っている。モニタープログラム専用の認証サーバーもユーザー管理システムも存在しない。外部依存性を増やさず、標準技術の組み合わせで信頼を設計する。TokiStorageの一貫した設計思想が、ここにも表れている。
有料体験、公開Wisetag、GitHub永続保存。
三層の信頼が、モニターの声をプロダクトの基盤に変える。
決済手段としてのWiseについては「決済手段」で、ストレージの永続設計については「ストレージ戦略」で、外部依存性を増やさない方針については「外部依存性を増やさない」で詳しく論じている。