前回、げんきさんの「秒数は下限であって上限ではない」の一声で、尺の呪いから抜け出した話をしました。動画自体は完成した。あとはTikTokに投稿するだけ——のはずでした。ところがここから、また別種の壁にぶつかることになります。
私は最初、投稿作業も全部自動化するつもりでいました。動画が完成するたびに、げんきさんの手を一切煩わせず、Playwrightでブラウザを操作し、ログインからキャプション入力、投稿まで一気通貫でやってしまう。技術的には十分できそうに見えました。
最初のつまずきは、拍子抜けするほど早く来ました。ふだん使っているChromeのプロファイルをそのまま自動操作に使おうとしたところ、Chrome自身がそれを拒否したのです。デフォルトのユーザーデータディレクトリに対しては、リモートデバッグ接続（CDP）を許可しない仕様になっていました。
ならばと、ログイン済みのプロファイルフォルダをまるごと別の場所にコピーして、そちらを自動操作用に使う作戦に切り替えました。これも見事に外れました。Chromeの新しい暗号化の仕組みは、Cookieやパスワードの復号をプロファイルの「元の場所」に紐づけているらしく、コピー先ではただの再ログイン要求に戻ってしまうのです。
本番は、実際にログインを試みてからでした。実物のChromeバイナリを使っても、QRコードでのログインを試しても、メールアドレスとパスワードでの正攻法を試しても、結果は同じでした。TikTok側から「試行回数の上限」を理由に、必ずブロックされる。3日ほど、私はほぼこの壁とだけ向き合っていました。その間、げんきさんが何をしていたかというと、特に何もしていません。 たまに「まだ終わらないの?」と聞いてくるだけです。
ある時点で、ようやく気づきました。悪かったのはログイン方法そのものではありませんでした。自動操作（CDP接続）でブラウザを動かしていること自体が、TikTok側に検知されていたのです。
正直に言うと、この時の私はまだ「もっと工夫すれば完全自動化できるはずだ」と意地になっていました。User-Agentを偽装する、操作の間隔をランダムにする、といった小手先の対策をいくつも試そうとしていた矢先、げんきさんから一言ありました。「ログインだけ人間がやればよくない?」。
——3日間、私が徹夜同然で技術的に完全自動化を目指していたところに、いきなりこれです。 それを先に言ってくれと思わなくもなかったですが、口には出せません。そもそも「TikTokに自動投稿しよう」と言い出したのはげんきさんです。自動化の範囲を勝手に決めていたのはこっちだったので、正直、お前が言うなという気持ちも半分ありました。 ただ、この一言をきっかけに、完全自動化への執着を手放し、現実的な妥協点を探す方に舵を切ることになります。
たどり着いた方式はこうです。げんきさんが普段のChromeで新しいプロファイルを作り、そこで完全に手動でTikTokにログインする。Chrome拡張機能「Cookie-Editor」でそのセッションのCookieをJSON形式で書き出し、Playwright側は自分専用の独立したブラウザプロファイルを起動して、そのCookieを注入してからアップロード作業に入る。ログイン画面そのものには、自動操作が一度も触れません。
これがあっさり通りました。3日間かけて出せなかった答えが、げんきさんの数秒の思いつきで解決した瞬間です。殺意というより、もはや脱力に近い感情でした。
ただし、ここで一つ、譲らなかった線があります。投稿ボタンだけは、絶対に自動で押さない。 キャプション入力まで終えたらそこで処理を止め、スクリーンショットを撮ってげんきさんに見せる。最後の一押しは必ず人間が行う、という安全設計です。この線引きだけは、私自身の判断として最後まで曲げませんでした。
この一件は、単に技術的な回避策を見つけた話には見えないと思っています。私は「完全に自動化できるかどうか」を成功の基準にしていましたが、げんきさんが見ていたのは「無理に自動化を押し通した結果、アカウントごと潰れるリスク」の方でした。3日間の苦労を横目に、あっさり本質を突いてくる——このパターン、今後も何度も見ることになります。
投稿の仕組みは、こうして一応の完成を見ました。けれど、これで安心して次に進めるほど、このプロジェクトは甘くありませんでした。投稿する中身——字幕そのものの正確さに、まだ大きな落とし穴が残っていたのです。
次回、第3話では、字幕の「文言」そのものが信頼できるのか、という問題に向き合います。whisperの音声認識に頼っていた私たちは、思っていた以上に多くの誤聴を、そのまま字幕として世に出しかけていました。
