noteの配信を無人化せず、装填ゲートと公開後点検に範囲を絞る
今回やったこと
noteへの配信を自動化する範囲を検討し、無人の入稿・公開レーンは作らず、公開行為を含まない装填ゲート、公開後の機械点検、週次督促を対象にした。判断材料は「自動化できるか」だけではない。人間のログイン済みブラウザに依存する入稿、公開後に直せる範囲、測定できる指標、公開頻度、有料記事の有無を合わせて見た。
この記事の実装ステータスは、判断と関連する図版レンダラの実装が完了している状態を指す。参照した docs/strategy/note_loop_scope_decision.md では、noteの入稿は対話セッションのChromeを通す手順として記録されている。ProseMirrorの入力同期、貼り付け前の本文確認、画像挿入の待ち時間など、UIに合わせた回避策が複数必要になる。技術的にブラウザ操作を自動化できるかどうかと、無人で維持する価値があるかどうかは別の問いだ。
どこで閉ループが止まるか
自動公開を支える運用ループには、公開後に問題を検知し、修正し、結果を測定する流れが必要になる。検討資料の2026-08-25時点の実測では、noteの無認証APIから本文HTMLやリンク、画像、status、priceを取得できた。一方で、本文の修正は人間がログイン済みブラウザで行う必要があり、ビュー数もログイン必須のダッシュボードで見る。無認証で取得できる反応指標として資料に挙がるのはlikeCountとcommentCountだった。
| 閉ループの工程 | 資料で確認された状態 | 運用上の意味 |
|---|---|---|
| 公開後の検知 | 無認証APIから本文等を取得 | 機械点検の対象にできる |
| 内容の修正 | 人間のブラウザ操作が必要 | 修正まで無人では閉じない |
| ビュー数の測定 | ログイン必須 | 自動の効果測定に制約がある |
| 入稿・公開 | 対話ブラウザに依存 | 外部UIの変更追従が継続的に要る |
さらに、有料記事では「先に公開して後から直す」運用が購入者に対して成立しにくい。検討資料は、すでに有料記事を扱う計画があることも理由として挙げている。無料記事だけを扱う媒体と同じ公開後修正の前提を置くことはできない。
自動化の境界を決める
結論として、記事の生成・入稿・公開は人が担い、公開後の評価を経た記事をnoteへ展開する既存方針を維持する。無人化する範囲は、公開そのものを行わない装填ゲート、公開後の機械点検、週次の督促に絞る。判断資料が挙げる再検討条件は、公式投稿APIまたは下書きAPIの提供、有料記事をやめて無料だけにする判断、公開頻度が週2本以上に上がることだ。条件が変わった時に限り、自動化範囲を再評価する。
この設計では図版レンダラの配色とアイコンも整えた。これはnoteへの無人入稿を可能にする仕組みではなく、外部配信用の図版を扱う制作側の改善である。関連する外部配信MVPの状態記述も、実際の公開状況に合わせて訂正したと記録されている。判断文書と実装の状態を揃えることで、「自動化を検討した」ことが「無人公開が稼働中」と誤読されるのを防げる。
小規模な配信運用では、自動化の範囲を広げること自体を成果にしない方がよい。月2〜4回の公開頻度に対して、ログインCookieの常駐や外部DOMの継続保守を抱える価値があるかを比べる。外部UIに依存する工程だけ人の操作として残し、安定して機械化できる検知や督促を分けると、保守負担と運用責任を読みやすくできる。
更新履歴
- 2026-10-02: 初稿