自動化プレイブック: 信頼できるブラウザーコンテンツ運用を作る¶
Quick Answer: 信頼できるブラウザー運用では、計画、下書き、人的レビュー、公開、測定を分けて観測可能な段階にします。可視の CDP ブラウザーと明示的な MCP 操作を使い、認証情報はブラウザープロファイルに保持し、結果を検索可能なプロジェクトコンテキストに記録します。自動化は反復操作を減らすためのもので、責任を消すためのものではありません。
ブラウザー自動化を「ページを開く、クリックする、文章を貼り付ける」の繰り返しとして設計すると、承認済みの内容、使用中のアカウント、公開結果、障害後の再開方法が曖昧になります。
ここでは、そのマクロを一時停止、レビュー、再開ができる小さな運用システムに分解します。
ワークフローを一枚で見る¶
| 段階 | システムの責任 | 人の責任 |
|---|---|---|
| 計画 | アイデアキューと状態を管理 | 目的、対象者、公開条件を決める |
| 下書き | 初稿、バリエーション、出典を用意 | 事実、トーン、独自性を確認する |
| レビュー | 未承認の項目を公開キューから止める | 最終文面とメディアを承認する |
| 公開 | 可視ブラウザーを操作し結果を報告する | 認証画面と慎重な外部送信を扱う |
| 測定 | 時刻と結果メトリクスを記録する | 結果を解釈し次の実験を決める |
状態は idea -> draft -> review -> approved -> published -> measured のように明示します。ブラウザー操作の失敗と、内容の却下は別の状態として保存してください。
1. プロンプトより先にコンテンツキューを作る¶
1 件のコンテンツを 1 レコードとして、少なくとも次を持たせます。
- 安定したコンテンツ ID、対象プラットフォーム、アカウントラベル
- テーマ、対象者、期待するアクション
- 下書き、メディア参照、出典
- 承認状態、レビュアー、レビュー時刻
- 予定公開時刻と実際の公開時刻
- 結果メトリクス、観測期間、次のメモ
キューがあれば、ブラウザーが 12 件目で閉じても、次回は approved の項目を検索して続けられます。会話履歴から進捗を推測する必要はありません。
2. 可視で境界のあるブラウザーループを使う¶
ブラウザー処理では、リポジトリが推奨する browser-use CDP 経路を使います。
- 対象プロファイルで可視ブラウザーを起動する。
- CDP で接続する。
- semantic snapshot または必要な本文を読む。
- 可視の操作を 1 つ実行する。
- 期待する状態遷移を待つ。
- ページを読み直し、結果を記録する。
認証画面、アカウント切り替え、最終公開などの慎重な外部送信は人が確認します。自動化を隠す仕組み、身元を変える運用、プラットフォーム制御を避ける設計を作らないでください。操作間隔の調整をコンプライアンスの保証として説明することも避けます。公式 API や承認済みの自動化手段がある場合は、そちらとプラットフォーム規約を優先します。
3. レビューを実際のゲートにする¶
公開処理は、無視されやすいチェックボックスだけに依存させません。最小条件の例は次の通りです。
status == approved
reviewer != empty
media references resolve
target account matches the selected profile
条件を 1 つでも満たさなければ blocked として停止し、安全な次の操作を報告します。チェックを警告だけに下げないことが重要です。これは Harness CLI の最小正解変更ゲートと同じ考え方です。
4. ContextDB には役立つコンテキストだけを保存する¶
ContextDB には、長期的な事実、キューの状態、出典、引き継ぎメモを保存できます。pull-based のフローなら、次の操作に必要な証拠だけを取得し、全履歴を毎回注入せずに済みます。
ContextDB ドキュメントでプロジェクトメモリと検索を確認し、検索実装は ContextDB FTS5/BM25 記事を参照してください。個人情報、認証情報、Cookie、未編集の認証ログを公開成果物に入れないでください。
5. 成果を同じ定義で測る¶
露出、閲覧、いいね、保存、コメント、フォロー、クリック、承認から公開までの時間などを、プラットフォームごとに同じ形式で記録します。観測期間も必ず保存し、公開後 2 時間のデータと 7 日後のデータをそのまま比較しないでください。
Perception は結果の要約を支援できますが、事実を決めたり、次のバリエーションを自動公開したりするものではありません。次の実験には、1 つの仮説、1 つの変更変数、1 つの観測期間を記載します。
中断後の復旧チェックリスト¶
再試行する前に結果を分類します。
blocked: 人の承認、ログイン、または方針判断が必要failed: 内容または要求が無効infra-retry: ブラウザー、ツール、ネットワークの復旧を待てるpublished: 公開を確認済みmeasured: 観測結果を記録済み
最後のページ状態、アカウントラベル、コンテンツ ID、安全な次の操作を引き継ぎメモに残します。
FAQ¶
人のレビューなしで公開できますか？¶
プラットフォーム規約、アカウント所有者の許可、プロジェクト方針が明確に許可する場合に限り検討できます。既定のプレイブックでは、レビューと慎重な外部送信を人が担当します。
最初から複数アカウントを運用すべきですか？¶
まず 1 アカウントでキュー、レビュー、復旧を検証します。状態が観測可能で、プロファイルが分離され、規約に適合してから追加してください。
最小構成は何ですか？¶
コンテンツキュー、1 つの可視 CDP プロファイル、レビューゲート、結果レコードがあれば始められます。量が増えたら ContextDB 検索と Perception の要約を追加します。
ブラウザー自動化で公式 API を置き換えられますか？¶
一律には置き換えられません。公式 API や承認済みの自動化を優先し、ブラウザー処理は許可された範囲で実行してください。認証画面と慎重な操作には人の確認を残します。
公式ドキュメント¶
Getting Started、ContextDB、Use Cases、Troubleshootingから始めてください。