こせいです。 みなさん、AIによるブラウザ自動化は便利ですよね。私も日々、コンテンツの自動投稿やデータ収集で活用しています。 しかし、「ボタンをクリックしたはずなのに、なぜか期待通りに動作しない」という不可解な現象に直面したことはありませんか? 自分の書いた自動化スクリプトが不安...
こせいです。
みなさん、AIによるブラウザ自動化は便利ですよね。私も日々、コンテンツの自動投稿やデータ収集で活用しています。
しかし、「ボタンをクリックしたはずなのに、なぜか期待通りに動作しない」という不可解な現象に直面したことはありませんか? 自分の書いた自動化スクリプトが不安定で、すぐに壊れてしまい、運用に疲弊している方もいるかもしれません。
まさに、私が経験した泥沼の戦いでした。
・AIブラウザ自動化で頻発する不可解なエラーの原因解明。
・「ログが嘘をつく」現象への具体的な対処法。
・データに基づいたコンテンツ言語戦略の重要性。
この記事では、私がPinterestでのAI自動投稿に失敗し、システムが「成功」と嘘をつき続けた経験から、ブラウザUI自動化の「10箇条」を策定するに至った経緯をお話しします。
そして、感覚で決めていたコンテンツの言語戦略が、実測データによっていかに覆されたかについても触れていきます。
💡 「押したのに動かない」はなぜ?AI自動化の泥沼にハマった僕の物語
AIを使った自動投稿ツールを開発していました。特に、Pinterestへの画像投稿を自動化したかったのです。
日々のルーティン作業をAIに任せて、私はもっと別の作業に集中したかったからです。
当初は順調に進んでいるように見えました。スクリプトを動かすと、AIがブラウザを操作し、画像とキャプションを投稿するはずでした。
しかし、ある日突然、奇妙な現象に直面しました。
公開ボタンをクリックしたはずなのに、Pinterestのボードに画像が増えないのです。
これは一体どういうことだろう、と困惑しました。
🚨 ログが「成功」と嘘をついた日:Pinterest無言失敗の地獄絵図
私のAIシステムは、投稿スクリプトが完了すると「✅ ピン公開」というログを出力するように設計されていました。
実際に、毎日のログにはこの「✅ ピン公開」の文字が並んでいました。私はそれを見て、当然のように投稿は成功していると信じていました。
なぜなら、ログは私にとって最も信頼できる情報源だったからです。
しかし、実際のPinterestボードを確認してみると、ピンの数が増えていないのです。
うわ、終わった。
私が信じていた「成功」の証拠は、完全に嘘だったのです。これが「嘘つき計測器」との死闘の始まりでした。
・AIシステムが「公開ボタンを押した」ことを成功と判断していた。
・実際に「ボードにピンが増えた」という最終的な結果を確認していなかった。
・ログだけを見て、運用上の「成功」を誤認し続けていた。

🧪 発生ログ:クリックを吸われ、診断ダンプが嘘をついた一部始終
この無言の失敗を解決するため、私は作業ログを詳細に追っていきました。泥沼のような数時間が始まりました。
06:00 - Pinterest転載レーン新設
NoctiaプロジェクトのPinterest転載レーンを新設しました。既存のPinterest投稿基盤を参考に、X(旧Twitter)で掲載済みの画像のみを転載する仕組みです。
投稿先ボード名は「Noctia Office — Character Files」という、em dash(—)入りの名前でした。これが最初の罠です。
06:30 - ボードが見つからず、クリックが吸われる
初回投稿で5件中4件が無言で失敗しました。ログは全て「✅ ピン公開」を示していたのに、ボードのピン数は6件から7件にしか増えていません。
この時、ブラウザUI自動化の根本的な問題に気づきました。Pinterestのボード欄や公開ボタンは、画面外にあるとクリックが吸われてしまうのです。
scrollIntoViewIfNeeded()というコマンドが必須だと判明しました。これを入れないと、押した扱いなのに何も起きません。
「force:true」を使っても解決しませんでした。これはクリックの成否判定だけでは気づけない、厄介な挙動です。
07:00 - 診断ダンプの限界
デバッグのため、診断ダンプを生成しました。しかし、途中で900文字程度で打ち切る設定になっており、肝心なトリミングモーダル内の情報が見えていませんでした。
これにより、原因究明が大幅に遅れてしまいました。
自分の作った診断ツールすら、信用できない状況です。
07:30 - 既存スクリプトの脆弱性
さらに、既存のPinterest投稿スクリプトは、ボードが見つからなくても現在の選択のまま公開してしまう仕様でした。今回は投稿先が増えたため、別のボードへ誤爆するリスクがあることも判明しました。
・使用AI:Claude / Opus
・作業時間:数時間
・発生エラー:UI要素のクリック失敗、ログの偽陽性、診断ダンプの不完全さ。
・精神ダメージ:★★★★★
⚠️ 中間判定は両方向に「嘘つき」だった!僕が信じた「終端の物理観測」
この一連の失敗を受け、私は再発防止のために「中間判定」を強化しました。フォームが閉じたら成功、といった判定ロジックを追加したのです。
しかし、これもまた、私を裏切りました。
1回目は失敗したのに「✅ 成功」と報告し、2回目は成功したのに「⚠ 失敗」と報告する。
おいおい嘘だろ・・・。
同じ判定器が、両方向に嘘をつく状態です。
結局、最終的に信じられるのは、「終端の物理観測」だけでした。Pinterestのボードに実際にピンが増えているか、数を数える。
これが唯一の真実だったのです。
「完了条件は、工程の終端の物理的な証拠で書く」。この学びは、私の自動化システムの根幹を変えました。
「ボタンが押された」という事実は、「ボタンが押された」ことを示しているだけです。 それが「目的が達成された」ことを保証するものではなかった。 自分の書いたコード、自分の作ったログ、全てが疑わしく感じる。 この時ほど、自動化の難しさを痛感したことはありません。
✅ ブラウザUI自動化「10箇条」爆誕!これで不安定な自動化とサヨナラ
Pinterestでの泥沼の経験だけでなく、X(旧Twitter)のヘッダーバナー更新での不可解な挙動や、AIが生成した記事のプロンプト漏出問題など、様々な失敗が続きました。
これらの失敗は、媒体固有の問題ではなく、ブラウザUI自動化における普遍的な課題だと気づきました。そこで、これらの教訓を「ブラウザUI自動化スキルガイド」として10箇条にまとめました。
これが、不安定な自動化とサヨナラするための「10箇条」です。

第1条: scrollIntoViewIfNeeded() 必須の法則
UI要素は、画面外にあるとクリックが吸われます。force:true を使っても意味がありません。
クリックをトリガーする前に、必ず要素をビューポート内にスクロールさせる必要があります。
第2条: 完了判定は終端の物理観測で
「ボタンを押した」「フォームが閉じた」「APIが200を返した」。これらは全て途中経過です。
最終的に「望んだ変化が物理的に起こったか」を検証しなければ、本当の成功とは言えません。
今回のPinterestの例で言えば、「ボードのピン数が増えているか」を直接確認することです。
第5条: 自分の計器も疑うべし
作成した診断ダンプが不完全だったり、ログが偽りの成功を報告したり。自分の作ったツールですら、盲信してはいけません。
常に「本当にこれで正しいのか?」と問い続ける疑う心が必要です。
第8条: 実証済み実装は写経せよ
既存の成功例や実証済みのコードを移植する際は、一文字一句「写経」するつもりでコピーすること。わずかな変更や推測が、予期せぬエラーを引き起こします。
私も過去に、1行の誤コピーで予約が2回失敗した経験があります。
・UI要素のクリックは、要素が画面内に表示されているかを徹底確認する。
・自動化の「完了」は、物理的な最終結果の変化で定義し、計測する。
・自分の作ったログや診断ツールも常に「本当に正しいか」と疑う心を持つ。
・既存の成功コードは安易に改変せず、写経レベルで忠実に移植する。
その他にも、変更前の値を記録して差で見る、セレクタを推測しない、ゲートは両方向に設定する、サイレントフォールバックを禁止する、諦める線を決める、といった具体的なルールを設けました。
🚀 「英語は13分の1」実測データが暴いた僕の思い込みと戦略大転換
Pinterestでの失敗はUI自動化だけではありませんでした。
Noctiaの投稿言語を英語に設定していたのですが、社長から「英語なのは戦略的な理由があるのか?」と問われました。
正直なところ、ボード名が英語だから中身も英語、と感覚的に決めていただけでした。明確な戦略はありません。
私はこの疑問をきっかけに、実測データを取りました。
UIが英語だから英語。ただそれだけの理由で言語を決めていた。 自分の感覚や思い込みがいかにいい加減だったか、思い知らされました。
日本語 vs 英語:表示数13倍以上の衝撃
驚くべき結果が出ました。
同一ボード内で、日本語コンテンツの表示が3,450回だったのに対し、英語コンテンツはわずか150〜262回。
なんと、13倍から23倍もの差があったのです。
アカウント全体で見ても、日本語の設定資料ピンは2,749〜7,876表示、保存は48〜140件。英語ピンは150〜262表示、保存はほぼ0件でした。
交絡(内容差や投稿数差)はあるものの、同じボード内でこれだけの桁違いの差が出たのは衝撃です。
| 項目 | 日本語コンテンツ | 英語コンテンツ | 差 (日本語/英語) |
|---|---|---|---|
| 表示数 | 3,450 | 150〜262 | 13〜23倍 |
| 保存数 | 48〜140 | ほぼ0 | - |
このデータを見て、私はすぐに戦略を大転換しました。
英語で投稿していた5件のピンを削除し、日本語で再投稿することにしました。タイトルも既存の勝ちピンの型に合わせ、ハッシュタグのみ英語併記です。
「媒体の投稿言語・文体・タイトル型は実測で決める。UIやボード名の言語から推論しない」。この新たなルールは、私のコンテンツ戦略に大きな影響を与えました。
📌 AI自動化の「安定」は、この10箇条と「疑う心」から生まれる
AIによる自動化は、私たちの作業を効率化する強力なツールです。しかし、そこには多くの「嘘つき計測器」が潜んでいます。
ログが示す成功は、本当の成功ではないかもしれません。中間判定も、両方向に私たちを欺く可能性があります。
だからこそ、AI自動化を安定させるためには、「ブラウザUI自動化10箇条」のような実践的なガイドラインと、常に「本当にこれで正しいのか?」と疑い続ける心が不可欠なのです。
そして、コンテンツ戦略においても、感覚や推測ではなく、実測データに基づく意思決定が、いかに重要か痛感しました。

🔥 あなたの自動化は大丈夫?今日から試せる「信頼の計測術」
みなさんのAI自動化スクリプトは、本当に安定していますか? ログの「成功」を鵜呑みにしていませんか?
今回ご紹介した「ブラウザUI自動化10箇条」を参考に、ぜひご自身のシステムを見直してみてください。
特に、「完了判定は終端の物理観測で」という原則は、どのような自動化にも適用できる、最も重要な教訓です。そして、コンテンツの言語や形式は、感覚ではなくデータに基づいて決めるようにしましょう。
私の失敗が、みなさんの安定したAI自動化の助けになれば幸いです。
・ブラウザUI自動化では、「ボタンが押された」だけでは成功ではない。
・ログや中間判定は「嘘をつく」可能性があるため、常に疑う心が必要。
・「ブラウザUI自動化10箇条」と「終端の物理観測」を導入しましょう。
・コンテンツの言語戦略は、感覚ではなく実測データで決定する重要性。
・今後の課題: Pinterestに溜まった30件以上の下書きの処理と、残りのスキル互換監査31件を月次で消化していきます。
こういう「押したのに動いていない」自動化との格闘や、日々の運用実験のログは、ニュースレターでも配信しています。
記事にする前の生の試行錯誤が読みたい方は、こちらからどうぞ。




