ローンチ24日前に必須8項目中6項目を1日で消化した話

1日でdeployを5回。法務文書3本、エラー監視、Free濫用対策、ツールLP、copyright表記統一、Resend DNS認証。これが昨日のSession 93でやったことの全容だ。

「ローンチまでにやること」リストが8項目あって、朝の時点で2項目しか終わっていなかった。それが夜には6項目完了していた。正直、自分でも「今日これだけ進んだのか」と少し驚いた。

---

何に詰まっていたか

PiloTube(パイロチューブ)のローンチ日は決まっている。カウントダウンが始まっているのに、必須項目のリストを眺めるたびに「これ全部終わるのか」という感覚があった。

問題は量よりも「種類の多さ」だった。法務文書(利用規約・プライバシーポリシー・特定商取引法に基づく表記)、インフラ系(エラー監視・DNS認証)、UX系(Free濫用対策・ツールLP)、細かい表記統一(copyright)。ジャンルがバラバラで、ひとつひとつに「判断」が必要だった。

コードを書けばいいだけなら早い。でも法務文書は「この表現でいいのか」という確認が要る。DNS認証は「設定が反映されたか」の待ち時間がある。Freeプランの濫用対策は「どこまで制限するか」のビジネス判断が絡む。そういうタスクが混在していると、作業の切り替えコストが積み上がって進まなくなる。

---

気づき：「並列で動かせばいい」

Session 93の冒頭で、自分はAIチームにこう指示を出した。「今日は必須項目を全部消化する。判断が必要なものはハイキー(自分のAI判断役)に上げて、自分がGOを出す。実装はツクルンが動く。並列で行く」

これが今日の進め方の骨格だった。

Agent並列というのは、複数のタスクを直列(順番に)ではなく並列(同時に)進める構成だ。「法務文書の草案を作りながら、DNS認証の設定手順も出す」という動かし方。自分がGOを出した瞬間に次が動き出す。待ち時間をゼロに近づける。

ひとつ終わってから次を考えるのではなく、「次に何が来るか」を先読みしてAIチームが準備しておく。自分の役割は「判断してGOを出すこと」だけに絞った。

---

実際の壁

並列で動かすのは気持ちいいが、詰まる場面はある。

法務文書は特に慎重に見た。利用規約・プライバシーポリシー・特商法表記の3本を一気に仕上げたが、「この免責条項の書き方はPiloTubeのサービス実態に合っているか」という確認は自分がやるしかない。AIが出した草案をそのまま通すのではなく、一行ずつ「これはうちのサービスに当てはまるか」を見ていった。ここだけは時間をかけた。

Free濫用対策は判断が難しかった。無料プランのユーザーが大量にリクエストを送ってサーバーコストを圧迫するのを防ぐ仕組みだが、「どこで制限をかけるか」はビジネス判断だ。厳しすぎると普通のユーザーが不便になる。緩すぎると意味がない。ハイキーに「このラインが妥当か」を問いかけて、自分が最終的に数値を決めた。

Resend DNS認証は作業自体はシンプルだが、DNSの反映待ちがある。設定を入れたらあとは待つだけ。この「待ち時間」を他のタスクで埋めるのが並列進行の旨みだった。

---

実際にやったこと

Session 93の流れをざっくり書くとこうなる。

午前中は法務文書3本を一気に仕上げた。ツクルンに草案を出させて、自分が確認・修正・承認。特商法表記は事業者情報を正確に入れる必要があるので、ここは特に丁寧に確認した。

昼前後にエラー監視の設定を入れた。本番環境でエラーが起きたときに検知できる仕組み。ローンチ後に何か起きたとき、気づかずにいるのが一番まずい。これは早めに入れておきたかった。

午後はFree濫用対策とツールLPを並列で進めた。濫用対策はロジックの実装、ツールLPはページ構成とコピーライティング。性質が全然違うタスクだが、「ツクルンが実装を進めている間に自分がLPのコピーを確認する」という動かし方ができた。

夕方にcopyright表記の統一とResend DNS認証。細かいが、こういう「表記の揺れ」はローンチ後に気になり始めると止まらない。beforeの段階で潰しておく。

最後にdeployを走らせた。この日だけで5回。

---

何が起きたか

夜にリストを見返したら、8項目中6項目に完了マークがついていた。

残り2項目は「ローンチ直前でないと確認できないもの」と「もう少し検討が必要なもの」で、今日中に終わらせるべきものは全部終わっていた。

deploy 5回というのは、自分にとって1日の記録だ。それぞれのdeployが「何かを本番に出した」という事実で、積み上がっていく感覚がある。

「ローンチまでに終わるのか」という不安が、「あとこれだけ」という手触りに変わった。これが一番大きかった。

---

教訓と持ち帰り

タスクの種類が混在しているときほど、並列設計が効く。

同じジャンルのタスクが並んでいれば直列でも進む。でも「法務・インフラ・UX・表記」みたいに種類がバラバラなときは、切り替えコストが積み上がる。並列で動かすことで、その切り替えコストを「待ち時間」に変換できる。

「判断だけ自分がやる」という役割分担を明示すること。

AIチームに「実装は任せる、判断は自分がGOを出す」と最初に設計しておくと、作業の流れが詰まらない。自分が判断を先送りするたびに全体が止まる。だから「判断の速さ」が今日の進捗を決めた。

ローンチ前の「詰め」フェーズは、1日の密度で決まる。

24日前という数字は、余裕があるようで全然ない。毎日少しずつ進めるより、「今日は全部消化する」と決めた1日のほうが、実際には多く進む。Session 93はそれを証明した日だった。

残り2項目。ローンチまで24日。