YouTube Shorts自動投稿が7日で止まる、原因はOAuth同意画面のテスト

YouTube Shortsへの自動投稿が、Google Cloudの設定1つで止まる事例がnoteで公開されました。
止まった原因は、設定画面の「テスト」の1語です（note）。

OAuth同意画面がテストのままだとトークンは7日で失効

この運営者は、Shortsの台本づくりからアップロードまでをAIエージェントのClaude Codeに任せています。
タスクスケジューラが毎日14時と21時に起動し、1本作って公開する流れです。
この投稿が、9月12日の朝6時45分に止まりました。

止めたのはGoogleです。
YouTubeへアップロードするための認証の鍵にあたるリフレッシュトークンが、発行から7日で失効していました。
OAuth（外部のツールがGoogleアカウントに代わって作業するときに使う承認の仕組み）の設定画面「OAuth同意画面」が「テスト」のままだと、トークンの期限は7日です。
Googleの仕様なので、同じ手順で自動投稿を組んだ人は、7日目に同じことが起きます。

失った投稿は、9月12日の3枠と13日の2枠、あわせて5本です。
1日2本の運用なら、2日半ぶんの枠が丸ごと消えた計算になります。

止まった当日に、機械が失効を先に検知した

投稿は黙って止まりませんでした。
止まった日の朝9時、無人で回る経営会議が「失効は機械が先に知る」と方針を決め、トークンの更新を確かめる小さな検査スクリプト（check_youtube_token.js）を定期実行に組み込みます。

ランナーはClaudeを起動する前にこの検査を通し、トークンが更新できなければ「YouTube再認証待ち」と記録して何もしません。
この結果、記録には5本ぶんのSKIPが理由つきで並び、翌朝7時の点検にも「YouTube再認証が必要」と表示が出ました。

ただし、直す手は人間にしかありません。
Googleアカウントのログイン画面で「許可」を押す作業だけは、機械に任せられないからです。

本番への切り替えには必須項目3つとドメイン確認が要る

9月14日の朝5時前、運営者が復旧に取りかかりました。
再認証そのものは1分で終わります。
時間がかかったのは切り替えの側です。

Google Cloudの画面で「アプリを公開」のボタンが灰色のままで押せません。
先にブランディングの3項目、ホームページURL・プライバシーポリシーURL・承認済みドメインが必須でした。
承認済みドメインは、所有権の確認が済んだものしか通らないため、Search Console（Googleに自分のサイトを登録して管理する画面）でHTMLファイルを置く方式でプロパティを追加します。
ここまで終わってブランディングが保存でき、公開を押して、もう一度再認証。
作業が終わったのは6時過ぎでした。

検査スクリプトの表示は「本番（失効なし）」に変わり、当日14時の枠から投稿が再開しています。

同じ手順で組んだ人は7日目に同じ停止に遭う

原因をつくったのは、設定画面の「テスト」の1語でした。
直すのに要ったのは再認証の1分ではなく、本番に求められる必須項目3つと、ドメインの所有権確認です。

Googleの仕様として、トークンはこちらの都合と関係なく7日で切れます。
自動投稿を組むなら、最初の1回で本番まで済ませておくのが、いちばん手間のかからない順番です。