つくり終えたとき、何が変わるか
プロダクトをつくっている最中は、視線が内側を向いている。コーデックの選定、QRの容量計算、ストレージ戦略、ビルドパイプライン。どれも「どう実装するか」という問いに対する答えだ。
ところが、ある時点を境に問いの質が変わる。「これ、使う人はどこでつまずくだろう？」「初めて開いた人は何をすればいいかわかるだろうか？」。答えるべき相手が、コンパイラからユーザーに変わる。
TokiQRにAIチャットボットを入れようと思ったとき、最初は「面白いからやろう」くらいの気持ちだった。しかし振り返ると、この発想が出てきたこと自体が、開発フェーズの終わりを告げていた。
開発者の視点、利用者の視点
開発フェーズでは「何をつくるか」を考える。運用フェーズでは「どう届けるか」を考える。同じプロダクトなのに、見える風景がまったく違う。
チャットボットの実装自体はchatbot.js 200行程度、コストはほぼゼロだった。技術的には大したことがない。しかし「FAQを読む前に聞ける場所がある」というだけで、利用者の体験は一変する。これは開発者の視点からは出てこない発想だ。
120本超のエッセイを書いてきたのも、振り返れば運用的な行為だった。機能は同じでも、なぜそうなっているかを説明する量が増えていく。エッセイは機能ではなく文脈を提供する。
チャットボットが教えてくれること
チャットボットを全ページに配置して気づいたのは、このツールがナレッジの穴を可視化する可能性を持っていることだ。ユーザーがアシスタントに質問する内容は、既存のFAQやエッセイではカバーしきれていない領域を示唆する。
当初は「よくある質問パターンをログから拾い、それをエッセイ化する」という仕組みを考えた。しかし、それは早すぎる最適化だった。
利用者は式場の担当者であり、開発者ではない。彼らの質問は予測できない。そして予測できないからこそ価値がある。先回りしてエッセイを書いても空振りになるだけだ。問い合わせが来たとき、そこに答えるエッセイがなければ書く。それだけでいい。
フィードバックが先、コンテンツが後。順序を逆にしないこと。
なぜヒートマップもオンボーディングも入れないのか
運用フェーズに入れば、普通はヒートマップ解析、オンボーディングツアー、A/Bテスト、プッシュ通知、CRMなど「運用系ツール」の導入を検討するだろう。しかしTokiQRはどれも入れていない。
理由は単純で、それらはすべてサーバーサイドの状態保持を前提とする。ヒートマップはユーザー行動を外部サーバーに送信し、オンボーディングはユーザーの進捗をデータベースに記録し、プッシュ通知はサービスワーカー経由で配信基盤と接続する。どれも「サーバーなし・月額課金なし」というTokiQRの設計原則と衝突する。
AIアシスタントだけが例外的に成立する。Anthropic Claude APIへのリクエストはCloudflare Workerが中継するだけで、データを保持しない。APIキーはユーザーのlocalStorageに閉じ、サーバー側に状態が残らない。ステートレスな問い合わせが完了すれば、痕跡はどこにも残らない。
つまりAIアシスタントは、唯一「サーバーレス原則を破らずにユーザー体験を向上させる運用ツール」だった。他のツールを排除したのではなく、原則と両立するものがこれしかなかった。選択肢を絞ったのではなく、制約が選択肢を絞った。
フェーズの自覚がもたらすもの
「今、自分はどのフェーズにいるか」を自覚できると、判断基準が明確になる。
- 開発フェーズ: 技術的負債を減らし、機能を固める
- 運用フェーズ: ユーザー体験を磨き、説明を充実させる
- 成長フェーズ: パートナーシップを広げ、ユースケースを増やす
TokiQRは今、運用と成長の境界にいる。コードベースは安定し、音声・画像・テキストの三層保管は設計どおりに動いている。だからこそ視線をユーザーに向ける余裕が生まれ、「AIアシスタント完備」というブローシャの一行が書けるようになった。
エッセイを書き続ける理由
開発フェーズのエッセイは設計判断の記録だった。運用フェーズのエッセイは、なぜそうなっているかの説明になる。そしてこのエッセイのように、プロジェクトが今どこにいるかの定点観測にもなる。
つくることと、つくったものを届けることは、別の技術だ。開発力だけでは足りない。運用の視座を持つこと——それは、プロダクトが成熟した証であると同時に、次のフェーズへの入り口でもある。
つくり終えてから、本当の仕事が始まる。