コードに触れる必要がなくなった
TokiQRの開発は終わった。音声・画像・テキストをQRに変換するエンコーダー、デコーダー、AIアシスタント、設定ページ、モニター、セットアップページ。すべて実装済みで、安定稼働している。
成長フェーズに入っても、パートナーが10社になっても100社になっても、コードは変わらない。QRの生成もデコードもブラウザ内で完結し、AIアシスタントはステートレス。サーバーがないから、スケーリングのためのコード変更も発生しない。
今後コードベースに手を加えるとすれば、エッセイを追加するときだけだ。しかもそれは「コード」ではなく「コンテンツ」の追加にすぎない。
エッセイ追加に必要なもの
エッセイを1本追加するために必要な作業を分解してみる。
- HTMLテンプレートをコピーして、タイトルと本文を書き換える（JA/EN）
- essay-nav.jsにエントリを3箇所追加する（配列・最新・関連）
- essays.htmlとessays-en.htmlにリンクを追加する
- GitHubにpushする
ビルドツールはない。コンパイルもない。テストスイートもない。HTMLファイルをGitHubにpushすれば、GitHub Pagesが勝手にデプロイする。必要なのはテキストエディタとGitだけだ。
そしてこの作業は、Claude無料版で十分に回る。1本のエッセイは5〜10ターンで完成する。1日3本でもFree版のレートリミット内に収まる。
スマホで完結する理由
GitHubにはブラウザからファイルを編集してプルリクエストを作成する機能がある。ターミナルもIDEも不要だ。Claudeにテンプレートを渡して「このテーマでエッセイを書いて」と頼めば、HTML一式が返ってくる。それをGitHubのブラウザエディタに貼り付けてコミットする。
必要な機材はスマホ一台。それも最新機種である必要はない。ブラウザが動けばいい。
Claude（無料版）+ GitHub（ブラウザ）= スマホ一台でプロダクト運用。
極端な話、携帯キャリアの契約すら要らない。必要なのはWi-Fiだけだ。国内ならマクドナルドやスターバックス、コインランドリーにすらWi-Fiがある。海外ならスーパーマーケットやカフェなど、無料Wi-Fiスポットはどこにでもある。Wi-Fiに繋がる端末が一台あれば、世界中どこからでもプロダクトを更新できる。
ローカル環境への依存がゼロ
これはサーバーレス原則の帰結だ。サーバーがないからデプロイスクリプトがない。ビルドツールがないからNode.jsも要らない。フレームワークがないからnpm installも不要。ローカル環境に依存するものが何一つないから、デバイスを選ばない。
開発フェーズではCodec2のWASMビルドやPDF生成にPCが必要だった。しかし運用フェーズに入った今、それらの作業は発生しない。残ったのは純粋なテキスト作業だけであり、テキスト作業にはスマホで十分だ。
一般的なプロダクト運用では、ローカル開発環境の維持自体がコストになる。OSのアップデート、依存パッケージの互換性、ビルドツールのバージョン管理。TokiQRにはそのすべてが存在しない。
運用フェーズで発生する簡単なデバッグや改修も、スマホで完結する。ビルドプロセスが存在しないから、HTMLやJavaScriptの修正はGitHubのブラウザエディタで直接行える。Claudeに症状を伝えれば修正コードが返ってくる。それを貼り付けてコミットすれば、GitHub Pagesが即座に反映する。
AIが運用コストを下げる構造
Claude無料版でエッセイが書けるということは、運用の限界費用がほぼゼロだということだ。テンプレートがあるからHTML構造のミスは起きない。Claudeが本文を生成するから、書く速度はタイピング速度に制約されない。
しかも、この構造自体がTokiQRのAIアシスタントと同じ設計原則に従っている。ステートレスで、サーバーを持たず、ユーザー（この場合は運用者）が自分のアカウントでAIにアクセスする。プロダクトの設計思想と運用手法が一致している。
開発に制約があり、運用にはない
一般的なSaaSは、つくるフェーズは比較的楽だ。フレームワークを選び、クラウドにデプロイすれば動く。しかし運用フェーズに入ると、月額サーバー費用、DevOps人材、監視体制、スケーリング対応と、コストが膨らみ続ける。
TokiQRはこの構造が逆転している。開発フェーズではCodec2のWASMビルド、PDF生成、音声品質の検証にPCが必須だった。制約は確かにあった。しかし運用フェーズに入った瞬間、その制約はすべて消える。サーバー費用はゼロ。DevOpsは不要。監視すべきインフラが存在しない。
場所の制約もない。大企業やコンサルティングファームの本番環境では、指定端末、セキュリティルーム、VPN接続、定期的なパスワード変更、鉄壁のガバナンスが当たり前だ。定期・不定期の多段階承認ワークフローを経なければ、本番環境には触れられない。TokiQRにはその制約が存在しない。本番環境はGitHub Pagesであり、ブラウザからコミットすればそれがデプロイだ。カフェでも空港でも、世界中どこからでも本番に反映できる。
そもそもローカル環境もステージング環境も存在しない。環境間の差異という概念自体がない。コミットした瞬間が本番反映であり、それ以外の経路がない。荒くても公開し、公開しながら精度を上げていく。これは事故ではなく、あらかじめポリシーとして掲げている運用方針だ。
ボタンの色を少し変える、位置を数ピクセルずらす。それだけで数十万円の開発改修見積もりが発生する世界もある。TokiQRにはその構造が存在しない。CSSを一行書き換えてコミットすれば終わる。見積もりも稟議も不要だ。
現場に張り付いて監視する必要もない。サーバーがないからダウンもない。データベースがないから障害復旧もない。GitHub Pagesの稼働率はGitHubが担保し、CDNが配信する。監視対象が存在しないプロダクトに、監視要員は要らない。
データベースがないということは、不本意な操作でデータが消えて戻らないという事故も起こらない。すべてはGitの履歴に残っている。戻したければ切り戻せばいい。それもブラウザからできる。
インシデントレポートを書く必要もない。トラブル報告の電話も、胃がキリキリするような叱咤も起こらない。インシデントが構造的に発生しないプロダクトには、インシデント対応プロセス自体が不要だ。
セキュリティの攻撃対象面も極小だ。サーバーがないからサーバー侵入がない。データベースがないからSQLインジェクションがない。認証システムがないから資格情報の漏洩がない。ユーザーデータを保持しないから、漏洩すべきデータ自体が存在しない。脆弱性診断の対象が静的ファイルの配信のみという、最小のアタックサーフェスだ。
プロダクトバックログもスプリントもプランニングポーカーもカンバンも要らない。開発すべき機能が残っていないプロダクトに、開発プロセスは不要だ。スクラムマスターもプロダクトオーナーもプロジェクトマネージャーも不在で成立する。あるのはエッセイを書くという、ただひとつの作業だけだ。
カスタマーサポート体制も不要だ。エッセイの追加要望があれば問い合わせフォームからメールで届く。それを読み、適宜判断して追加してもいいし、しなくてもいい。SLAも応答時間の保証もない。義務ではなく、裁量で動く構造だ。
総務も人事も財務も不在で成立する。従業員がいないから労務管理がない。オフィスがないから施設管理がない。サーバー費用がないから経費精算がない。バックオフィス機能が丸ごと不要になる。
極論すれば、経営者すら不在で成立する。戦略的な意思決定を要する局面がない。プロダクトは完成し、価格は決まり、チャネルは公開されている。すべての情報が揃っていて、判断すべき変数が残っていない。あるのは世界を観察し、エッセイに残すことだけだ。
社内政治も起こり得ない。コンフリクトも存在しない。関係者が一人しかいない組織に、利害の衝突は構造的に発生しない。合意形成のプロセスが不要だから、意思決定の速度は思考の速度と等しい。
つくるためにPCが要った。届けるにはスマホで足りる。
※本稿は、サーバーレスかつ開発完了済みという特殊な条件下にある自社プロダクトの運用特性を考察するものです。大企業やコンサルティングファームのガバナンス体制、SaaSの運用モデル、アジャイル開発プロセス、組織設計や経営管理の仕組みを批判・否定する意図はありません。それぞれの環境・規模・フェーズには固有の要件と合理性があり、筆者自身もそれらの導入を推奨・提案する立場にあります。本稿で「不要」と記述している要素は、あくまで本プロダクトの現在の運用フェーズにおける事実の記述です。