自動投稿で「保存完了」と出たのに中身が空になるとき｜ボタンを押したことは保存の証明にならない理由と、投入直後に開き直して本文・画像を確かめる検証工程

【この記事でわかること】

• 自動投稿の「保存完了」ログや画面の切り替わりが、保存の証明にならない理由
• 投入直後に1件ずつ開き直して、タイトル・本文・画像を確かめる検証工程の組み方
• 「全件完了」と報告する前に確かめる数字と、人の手に戻す判断の目安

ブログやnoteへの下書き投入、LINE公式アカウントの拡張ツールでの一括設定変更など、画面を自動で操作して「保存」まで進める仕組みは、うまく回れば作業時間を大きく減らせます。ところが運用していると、実行ログには「保存完了」と出ているのに、あとで開くと本文が空だった、設定が元のままだった、という状態に出会います。

先に結論を書きます。「保存ボタンを押した」「画面が切り替わった」「ログに完了と出た」は、どれも保存された証明になりません。 自動操作で書き込む仕組みには、次の3点を最初から組み込んでください。

1. 保存のあと、同じ記事・同じ設定をページごと開き直して、中身を実測する（今表示されている画面ではなく、サーバーに残っている値を読む）
2. 確かめる項目を数字で決める（タイトルが入っているか、本文が何字以上か、見出しがいくつあるか、画像が付いているか）
3. 検証は1件ごとに行い、「完了」の件数は検証を通った件数で数える

弊社graciautoは名古屋でホームページ制作とLINE公式アカウント構築、店舗業務の自動化を手がけています。この記事は、自社メディアへの記事の一括投入や、支援先のLINE拡張ツールでの一括設定変更を運用する中で確認した数字をもとに書いています。

なぜ「保存完了」は保存の証明にならないのか

自動操作の仕組みが記録できるのは、自分が何をしたかだけです。「タイトル欄に入力した」「本文を入れた」「保存ボタンを押した」「一覧画面に移った」。これらはすべて操作の記録であって、サーバー側に何が残ったかの記録ではありません。

操作と保存結果がずれる経路は、いくつもあります。

• サービス側の自動保存が別に動いている：noteのように編集中の内容を自動保存するエディタでは、こちらの操作とは別に、サービス側が独自のタイミングで保存を走らせます。こちらの入力や保存ボタンの操作とタイミングが重なると、途中の状態で上書きされることがありえます
• ボタンが押せたように見えて、処理が通っていない：画面上ではボタンをクリックでき、一覧画面にも移ったのに、サーバーには反映されていないことがあります。連続して操作していると、設定用の小窓（モーダル）がうまく開かず、保存が空振りする現象も起こります
• そもそも書き込み処理が実行されていない：スクリプトの実行が途中で中断されたり、割り込まれたりすると、書き込みが走らないまま次の工程へ進むことがあります。処理を実行した「つもり」の報告が、ここで生まれます

どれも、保存ボタンを押した直後の画面だけを見ていても気づけません。画面にはまだ自分が入力した内容が表示されているからです。確かめるには、一度その画面を離れ、改めてサーバーから読み込み直す必要があります。

実際の運用で確認された「保存したはず」の割合

「たまにしか起きないなら気にしなくてよいのでは」と思われるかもしれません。実際の運用で確認された数字を挙げます。

場面	件数	保存されていなかった件数	見た目の状態
noteへの記事下書きの一括投入	30本	2本	ログは「下書き保存完了」・画像付き。開き直すと画像だけでタイトル空・本文0字
LINE拡張ツールでの流入経路の設定書き換え	25件	9件（約36%）	保存ボタンを押し一覧へ移動。再読み込みすると元の設定のまま
WordPressの記事更新（スクリプト経由）	1記事	2回とも未反映	「更新した」と判断したが、サーバー上は旧版のまま

noteの例では、失敗した2本は連続して投入した2本（2分違い）でした。ログ上は「タイトル入力 → 見出し5つ → 下書き保存完了 → アイキャッチ付き」と、正常な記事とまったく同じ流れが記録されています。ログだけを見て「30本完了」と判断すると、2本が空のまま残ります。 原因は、画像アップロード後に走るnote側の自動保存と、本文入力・保存操作が重なったためと推定していますが、確証はありません。原因が確定しなくても、開き直して確かめる工程があれば、空の下書きは確実に見つかります。

LINE拡張ツールの例は、割合が大きいことに注意してください。約350ある流入経路のうち、書き換えが必要な25件を自動操作で変更したところ、9件が保存されていませんでした。同じ作業を人が手で行った12件は、すべて一度で保存できています。自動操作の書き込みは、サービスや画面によっては3件に1件が空振りすることもあるという前提で設計したほうが安全です。

検証工程の組み方：投入直後に1件ずつ開き直す

ここからが本題です。自動で書き込む仕組みには、保存の直後に次の工程を入れます。

1. 保存した対象のIDを控える

記事ならnoteの記事キーやWordPressの投稿ID、設定なら経路IDなど、あとで同じ対象を直接開ける識別子を保存の直後に控えます。一覧画面から「たぶんこれ」と探す方式は、同じタイトルの下書きが複数あると取り違えます。

2. 画面を離れ、同じ対象をページごと開き直す

保存直後の画面をそのまま読んではいけません。表示されているのは入力した内容であって、保存された内容ではないからです。編集画面のURLを改めて開く、またはページを再読み込みしてから中身を読みます。APIが使えるサービスなら、画面ではなくAPIで現在の値を取得するほうが確実です。WordPressなら、REST APIで投稿を編集用の形式（context=edit）で取得し、入れたはずの語が入っているか、消したはずの語が残っていないかを数えます。

3. 読み込みが終わるのを待ってから判定する

開き直した直後に判定すると、ページの読み込みが終わる前の空の状態を見て「保存されていない」と誤判定することがあります。実際に、正常に保存されていた記事が、開き直しの直後に読み込み前の画面を見て検証NGになった例がありました。タイトル欄や本文の要素が表示されるのを待ってから判定し、NGが出たら一度だけ読み込み直して再確認します。

4. 数字で合否を決める

「中身が入っているか」を目で見るのではなく、数字で判定します。記事の下書きなら、たとえば次のような基準です。

確かめる項目	合格の基準（例）	見つけられる失敗
タイトル	空でない・元原稿と一致	タイトル未設定のまま保存
本文の文字数	800字以上（元原稿の長さに応じて決める）	本文0字・途中で切れた本文
見出しの数	元原稿の見出し数と一致	本文の一部だけ保存・構造の崩れ
画像	アイキャッチが付いている・想定サイズ	画像の付け忘れ・アップロード失敗

設定の書き換えなら、「新しい値が表示されている」「古い値が残っていない」の2点を、画面の文字として検出します。新しい値が1つ以上、古い値が0になって初めて合格です。

5. NGのものは新規で入れ直し、空の旧データは人が消す

検証に落ちたものは、その場で入れ直します。このとき、空になった旧データを上書きで直そうとするより、新規の下書きとして入れ直し、改めて検証するほうが単純で確実です。空の旧データは、削除を自動化せず一覧に残しておき、人が確認して消します。自動で消す仕組みを作ると、判定を誤ったときに正常なデータまで消すおそれがあるからです。

6. まとめて保存してから一括検証、にはしない

30本を全部投入してから最後にまとめて確かめる方式は避けてください。途中で何が起きたのか追えなくなるうえ、「最後に確かめればいい」という前提は、忙しい日に検証そのものが省かれる原因になります。書き込み1件ごとに、保存 → 開き直し → 判定 → 次への順で進めます。

また、ブラウザを自動で操作する場合は、長く連続して動かすとモーダルが開かない、保存が空振りするといった現象が増えることがあります。20〜30件ごとにタブを開き直すと、状態が戻ることがあります。

「全件完了」と報告する前に確かめること

検証工程を入れても、報告の仕方がずれていれば意味がありません。完了の報告は、次の形にしておきます。

• 「投入30本・検証合格30本」のように、検証を通った件数で報告する。「実行した件数」だけの報告は、保存されたかどうかを何も語っていません
• 検証していないものは「未確認」と書く。一部だけ確かめた場合に、残りも大丈夫だろうと「完了」にまとめない
• 効果を示す数字を先に決めておく。先ほどのLINE拡張ツールの例では、書き換えの対象になった旧設定の適用人数を見ていました。作業が効いていれば減るはずの人数が、12人から35人に増えていたことが、保存漏れに気づくきっかけでした。自己申告の「完了」より、こうした数字のほうが正直です

この「成功と出ても中身を突き合わせる」考え方は、データの取り込みでも同じです。取り込み処理が成功と表示しても明細が消えていた例は「売上データを取り込んだら金額が合わないときの原因」で、自動処理が止まったことに気づく監視の考え方は「自動処理の監視は「最後に成功した時刻」を見る」で解説しています。

人の手に戻したほうがよい場面

最後に、自動化そのものの線引きです。検証工程を入れても空振りが多い画面では、無理に自動操作を続けるより、書き込みは人が行い、確認だけを自動化するほうが結果的に早いことがあります。

先ほどの例でも、自動操作の成功率が約64%だった画面で、人の手作業は12件中12件が一度で通っていました。件数が数十件程度で、しかも本番の設定に直接効く作業なら、速度より確実性を優先してよい場面です。

判断の目安は次のとおりです。

• 自動操作のまま進めてよい：失敗しても下書きや非公開で止まる／開き直しの検証で確実に見つけられる／件数が多く手作業の負担が大きい
• 人の手に戻す：保存の空振りが繰り返し起きる／書き込むとすぐにお客様側へ影響が出る本番設定／件数が少なく手で確実に終わる

そもそも他社サービスの画面をどこまで自動で操作するかという判断は「業務自動化は「どこまでやるか」で決まる」、AIに書かせた記事を公開まで進めるときの承認の組み方は「AIで店舗ブログを自動投稿するなら「下書き→検品→承認→投稿」にする」にまとめています。

まとめ

自動投稿や一括設定の「保存完了」は、保存された証明ではありません。

1. 保存ボタンを押した・画面が移った・ログに完了と出た、はすべて操作の記録。サーバーに残った中身とは別物
2. 保存の直後に同じ対象をIDで開き直し、読み込みを待ってから中身を読む
3. タイトル・本文字数・見出し数・画像（設定なら新しい値が1以上・古い値が0）を数字で判定する
4. NGは新規で入れ直して再検証。空の旧データは自動で消さず、人が確認して消す
5. 検証は1件ごと。報告は「検証を通った件数」で行い、効果を示す数字でも裏を取る

実際の運用では、30本中2本、25件中9件という割合で「保存したはず」が起きていました。どちらも、開き直して確かめる工程があれば、その場で見つけて直せたものです。自動化で浮いた時間の一部を検証に使うだけで、「完了のはずが空だった」という手戻りはなくせます。

弊社では、ブログやSNSの自動投稿、LINE公式アカウントの設定作業など、店舗の業務自動化の設計と見直しをお手伝いしています。「自動化したのに、結局あとから人が全部確かめている」という状態があれば、お気軽にご相談ください。