自動投稿が失敗した話｜止まっていたのは投稿ボタンの手前だった

自動投稿が出ませんでした。原因は投稿文でも設定でもなく、投稿ボタンを押す部屋に鍵がかかっていた——つまりログインが切れていたことでした。 画面が開けることと、投稿できることは別物です。この記事は、その失敗の記録と、同じ形の事故を防ぐ確認手順です。

この記事で分かることは3つ。実際に詰まった場所、原因の見つけ方、同じ事故を防ぐ確認手順です。

投稿が出なかった日に起きたこと

ユタラボでは、決めた内容を自動で投稿する準備をしていました。ところが、予定した時間を過ぎても投稿が見当たりません。

最初に疑ったのは文章でした。文字数が多すぎないか。使えない記号がないか。改行の形がおかしくないか。文章を短くして、記号も減らしました。それでも投稿は出ませんでした。

次に設定を見直しました。投稿先、実行する時刻、保存した下書きの場所を順番に確認しました。目立つ間違いはありません。ここで「自動投稿の仕組みそのものが壊れたのでは」と考えかけました。

しかし、失敗した場所をよく見ると、投稿ボタンを押す処理まで進んでいませんでした。文章を送って失敗したのではなく、その一歩手前で止まっていたのです。

ここで大事な区別がひとつあります。「自動処理が動き出した」と「投稿が完了した」は、別の状態だということです。動き出したのに、途中のどこかで止まる。これが今回の形でした。

振り返ると、調べる順番が逆でした。正しい順番は、①どこまで進んだかを調べる、②なぜそこで止まったかを調べる、③直す場所を決める、の3段です。自分は③から始めてしまいました。文章を直したのは、当てずっぽうの修理だったわけです。当てずっぽうの修理は、当たるまで時間を捨て続けます。先に「止まった場所」を見つければ、直す候補は一気に絞れます。

失敗地点を5段階に分ける

自動投稿は、大ざっぱに分けると5つの工程を順番に通ります。どこで止まったかで、調べる場所がまったく変わります。

止まった場所	よくある症状	先に見るところ
① 起動	記録(ログ)が1行も残っていない	実行する時刻の設定、動かす仕組みそのもの
② ログイン確認	ログイン画面を求められた形跡がある	認証(=ログインの証明)の状態
③ 投稿文の入力	画面は開いたのに文章が入っていない	画面の作りが変わっていないか
④ 投稿ボタン直前	入力まで済んだのにボタンが押されていない	ボタンが押せる状態か、別の表示にふさがれていないか
⑤ 投稿完了	完了の記録はあるのに投稿が見えない	公開の設定、反映の遅れ

使い方は単純です。上から順に「ここまでは成功した」と言える最後の工程を探すだけです。たとえば記録が1行も無ければ、疑うのは①です。この場合、投稿文をいくら眺めても意味がありません。そもそも仕組みが動き出していないからです。逆に「完了」の記録があるのに投稿が見えないなら、⑤の公開設定や反映の遅れを見ます。止まった場所より後ろの工程は、まだ容疑者ですらありません。

「最後に成功した工程」は記録で探す

「最後に成功した工程はどれか」を探すには、記録を見るのが一番の近道です。たとえばブラウザ自動操作の道具 Playwright(プレイライト)には、記録した操作を工程ごとにたどれる Trace Viewer という機能があります。各操作の実行前と実行後の画面、そのときのエラーや通信まで、工程単位で確認できます。「この操作の直前まで画面はこうだった」を、あとから証拠つきで見られるわけです。

自動実行の土台に GitHub Actions(ギットハブ・アクションズ=決めた時刻に処理を動かせる仕組み)を使っている場合も同じです。公式の説明によると、実行が失敗したときは、失敗したステップとそのログを確認できます。ログはジョブ(=仕事のまとまり)ごとに表示・検索・ダウンロードできます。どの道具を使うにしても、「工程ごとの記録を見られる場所」を先に押さえておくと、原因探しが一気に短くなります。

原因は切れていたログイン状態

自分の場合は、投稿先の画面を開いたままにしていました。そのため、ログインも続いていると思い込んでいました。

実際には、画面を開けることと、投稿できることは別でした。以前の画面が残っていても、投稿するためのログイン状態は切れていることがあります。投稿ボタンの近くまで進むと、もう一度ログインを求められる状態になっていました。

ログインし直したあと、同じ文章と同じ設定で試すと、投稿の手前まで正常に進みました。文章を直したことは、解決につながっていませんでした。

これは思い込みではなく、自動化の道具の公式資料にも根拠があります。Playwright の認証の説明では、ログイン済みのブラウザ状態をファイルに保存して使い回せる一方、保存した状態が期限切れになったら、それを削除してログインし直す必要があると案内されています。保存したログイン状態は、いわば合鍵です。合鍵にも有効期限があります。期限が切れたら、古い合鍵を捨てて作り直すしかありません。「一度ログインした状態を保存してあるから大丈夫」ではないのです。有効期間の長さはサービスや設定によって変わるので、使っているサービスの公式案内で確認してください。

もうひとつ、「ボタンの手前で止まる」ことにも理屈があります。Playwright の自動待機の説明によると、自動操作のクリックは、対象のボタンが「1つに定まる」「表示されている」「動きが安定している」「クリックを受け取れる」「有効である」といった条件を確認してから実行されます。条件が制限時間内にそろわないと、時間切れのエラーになります。ログイン画面や読み込み中の表示がかぶさっていれば、ボタンは見えていても押せません。人間なら「あれ、ログイン画面だ」と気づいて手を止めますが、自動操作は条件がそろうのを待ち続け、時間切れで倒れます。文章をいくら直しても、この条件は直らないわけです。

同じ失敗を防ぐ手順と、3つの仕組み

今後は、次の順番で確認します。

1. 投稿先を自分の手で開き、自分のアカウント名など「ログイン中だと分かる表示」を確認する。
2. 新しい画面へ移動し、もう一度ログインを求められないか確かめる。画面が開くだけでは合格にしない。
3. 公開しない下書き保存など、安全な操作で投稿直前まで進めるか試す。
4. 自動投稿を動かしたら、記録を見て「最後に成功した工程」と「最初に失敗した工程」を特定する。
5. 特定できてから、文章・設定・ログインのどれを直すか決める。手当たり次第に直さない。

そのうえで、次の3つの仕組みをひと組にしておくと、事故に強くなります。

1. 実行前のログイン確認。本番の投稿より前に、ログイン状態だけを確かめる小さな確認を入れる。期限切れなら、その場でログインし直してから本番に進む。
2. 工程ごとの記録。工程名・時刻・どこまで成功したか・最初のエラーを残す。凝った仕組みでなくてよく、「07:00 起動OK」「07:00 ログイン確認NG(再ログイン要求)」のような1行ずつのメモでも、5段階のどこで止まったかは分かります。Trace Viewer のような工程単位の記録があれば、あとから証拠で判断できる。
3. 失敗したときの通知。GitHub Actions なら、実行が終わったときにメールなどで結果を知らせる設定ができ、失敗したものだけを通知対象にすることもできます。予定時刻をだいぶ過ぎてから人間が気づく、という遅れを減らせます。通知の形は道具ごとに違うので、使っている仕組みの公式案内で確認してください。

注意点も2つあります。まず、ログイン状態を保存したファイルは秘密のかたまりです。Playwright の公式資料は、この種のファイルには本人になりすませる情報が含まれ得るため、コード置き場(リポジトリ)へ入れないよう警告しています。記事のスクリーンショットやログにも写さないでください。パスワードをそのままの文字で保存する方法も避けます。

次に、結果が分からないまますぐ再実行しないこと。実は投稿が出ていた場合、同じ内容を二重に投稿してしまうおそれがあります。再実行の前に、投稿先を自分の目で確認します。

よくある質問

画面が開けば、ログイン中と考えてよいですか？

いいえ。画面が表示できたことと、投稿する権限を持ったログイン状態であることは別です。アカウント名などの本人だけに出る表示、投稿画面へ進めるか、再ログインを求められないか、といった「ログイン済みでないと通れない地点」で確かめてください。保存したログイン状態にも期限切れがあることは、Playwright の公式資料にも書かれています。

投稿文を直す前に、何を確認すればよいですか？

「最後に成功した工程」と「最初に失敗した工程」です。投稿文を入力するより前で止まっているなら、文章は容疑者から外れます。先に起動・ログイン・画面の部品を調べます。工程ごとの記録は、Trace Viewer のような道具や実行基盤のステップ別ログで確認できます。

投稿ボタンが見えているのに押せないのはなぜですか？

自動操作では、見えているだけでは足りません。Playwright の自動待機の説明にあるとおり、ボタンが有効か、動きが安定しているか、別の表示にふさがれていないか、なども実行の条件です。ログイン要求や読み込み中の表示が上にかぶさっていないかを確認してください。

ログイン情報をファイルへ保存しても安全ですか？

扱いに注意が要ります。保存した認証状態のファイルには、アカウントを操作できてしまう機密情報が含まれ得ます。Playwright の公式資料は、公開・非公開を問わずリポジトリへ入れないことを強く勧めています。ログや画像にも中身を出さないでください。パスワードをそのままの文字で保存する方法も避けます。

失敗に早く気づくにはどうすればよいですか？

実行結果を成功・失敗まで記録し、使っている仕組みが対応していれば失敗の通知を有効にします。GitHub Actions では完了時の通知を設定でき、失敗したものだけ受け取ることもできます。通知が来ない道具の場合は、投稿予定の少しあとに投稿先を目で見る時間を決めておくだけでも、気づくまでの遅れは縮みます。

まとめ

• 自動投稿が出なかった原因は、文章や設定ではなく、切れていたログイン状態だった。画面が開いていても、投稿できる状態とは限らない。まず投稿先を自分の手で開き、アカウント名と再ログイン要求の有無を確かめる。
• 失敗したら手当たり次第に直さず、まず記録を見て「最後に成功した工程」を特定する。5段階の早見表で調べる場所を絞り、工程名・時刻・最初のエラーを1行ずつ残す習慣をつける。
• 仕組みは3つをひと組で入れる。①実行前にログイン状態を確認する、②工程ごとの記録を残す、③失敗したときの通知を設定する。細かい仕様は変わることがあるので、2026-07-26時点の公式案内を確認してから設定してください。

公式一次情報

確認日: 2026-07-26

• Authentication | Playwright: ログイン済みブラウザ状態の保存と再利用、期限切れ時は削除して再認証が必要なこと、状態ファイルに機密情報が含まれ得るための保管上の警告が書かれている
• Auto-waiting | Playwright: クリックの実行前に表示・安定・有効などの条件を確認し、制限時間内に満たされなければ時間切れエラーになる仕組みが書かれている
• Trace viewer | Playwright: 記録した操作を工程ごとにたどり、実行前後の画面・ログ・通信・エラーを確認できる機能が書かれている
• Using workflow run logs - GitHub Docs: 実行が失敗したとき、失敗したステップとそのログ、各ステップの実行時間をジョブ単位で確認できることが書かれている
• Notifications for workflow runs - GitHub Docs: 実行完了時のメール・Web通知と、失敗したワークフローだけを通知対象にできる設定が書かれている