前回のあらすじ
【第5回】進化編では、Stripe決済、LP制作、自動メール配信と、「売る仕組み」を全部自分で作り上げた話を書いた。
プロダクトは完成し、販売も始まった。しかしここで、技術的な壁にぶち当たる。
GASの限界
影武者システムはGoogle Apps Script（GAS）で動いていた。GASはGoogleが提供する無料のスクリプト環境で、スプレッドシートやカレンダーとの連携が簡単にできる。
最初はこれで十分だった。でも製品として運用するうちに、限界が見えてきた。
- 実行時間制限 ― 1回の実行が6分まで。処理が重くなるとタイムアウトする
- 速度 ― レスポンスが遅い。ユーザーを待たせてしまう
- 同時実行の制限 ― 複数ユーザーが同時にアクセスすると詰まる
- デプロイの複雑さ ― 更新のたびに手動でデプロイが必要
自分だけが使うツールなら問題にならなかった。でも複数のユーザーが使う製品として、これは致命的だった。
「引っ越し」という決断
正直、「Cloudflare Workers」と聞いても何のことかわからなかった。
Claude Codeが説明してくれたのはこういうことだ：
Googleのサーバー1箇所で動く
リクエストが来たらGoogleが処理
距離が遠いと遅い
実行時間6分制限
無料だが制約が多い
世界中300箇所以上で動く
ユーザーに一番近いサーバーが処理
爆速（数ミリ秒）
実行時間の制限が緩い
無料枠が太い
ものすごく簡単に言うと、「1つの店舗（GAS）」から「全国チェーン（Workers）」に引っ越すようなものだ。お客さんは一番近い店舗で対応されるから、待ち時間が激減する。
未経験者がサーバー移行をやる恐怖
これがどれほど怖い決断だったか、伝わるだろうか。
動いているシステムを、まったく別の環境に移す。コードを書いたことがない人間が。一歩間違えれば、既存ユーザーのシステムが止まる。
Claude Codeは移行を5つのフェーズに分けて、段階的に進めてくれた。
Phase 1: API基盤構築
新しいWorkers環境を作り、基本的なAPI（通信の窓口）を整備する。
Phase 2: 認証・セキュリティ移行
ユーザー認証やセキュリティの仕組みをWorkersに移す。
Phase 3: コア機能移行
勤怠管理の中核機能をWorkersで動くように書き換える。
Phase 4: 決済・メール連携移行
Stripe Webhookやメールの仕組みをWorkersに接続する。
Phase 5: GAS完全撤廃
旧環境を停止し、すべてWorkersで動く状態に。
一気にやるのではなく、一つずつ確認しながら進める。新しい環境でテストして、問題なければ切り替える。何かあればすぐ戻せるように、旧環境も残しておく。
プログラミング未経験の自分でも、この「慎重に、段階的に」というアプローチなら恐怖を乗り越えられた。
現在の技術スタック
移行が完了した今、影武者システムはこんな構成で動いている。
| 役割 | 技術 | 何をしてるか（簡単に） |
|---|---|---|
| サーバー処理 | Cloudflare Workers | APIの処理、認証、決済連携 |
| ユーザーデータ | Google Spreadsheet | 勤怠記録の保存（ユーザーのアカウント内） |
| カレンダー連携 | Google Calendar API | 授業予定の読み取り |
| 決済 | Stripe | 月額課金の管理 |
| LP・ブログ | Cloudflare Pages | ウェブサイトのホスティング |
| セットアップ | Google Apps Script | ユーザー環境の自動構築（これだけGAS） |
未経験者が技術選定をするということ
面白いのは、プログラミング未経験の自分が「技術選定」をしているという事実だ。
GASかWorkersか。Firebase HostingかCloudflare Pagesか。REST APIかWebhookか。
これらの判断は、従来ならCTOやテックリードの仕事だ。でもAIがそれぞれの選択肢のメリット・デメリットを説明してくれて、現状の課題に照らし合わせて提案してくれる。
最終決定は自分がする。でも判断材料はAIが揃えてくれる。
これが2026年の開発のリアルだ。
次回予告
【第7回・最終回】現在と未来編 — プログラミング未経験者が作ったSaaSの今。そしてこれからどこに向かうのか。この連載の締めくくり。
家庭教師の勤怠管理、まだ手作業でやってませんか？
影武者システムを見てみる