株式会社TOEでは、自社メディア「AIの鬼」の記事をnoteにも展開しています。その投稿作業を半自動化しました。先に結論です。自動化したのはMarkdown変換・品質チェック・画像生成・入稿操作で、ネタ選びと執筆の判断は人に残しました。ただし「公開ボタン」だけは、当初の設計と違って、いまは自動になっています。 この記事は、実際に動いているスクリプトのコードと社内の運用メモを開いて、確認できたことだけを書いています。
線引きの表 — 判断は人、作業は機械
社内の運用メモには、設計方針が一行で書いてあります。「note記事は『判断』を書く媒体なので、判断そのものは自動化しない。自動化したのは、判断以外の手作業＝変換・チェック・画像・投稿操作」。
工程ごとの分担はこうです。
| 工程 | 担当 | 自動化 |
|---|---|---|
| ネタを選ぶ | 人 | 手動（意図的） |
| 執筆 | Claude（編集長プロンプト） | 半自動 |
| 品質チェック | check_note_article.py | 自動 |
| 画像生成 | gen_note_images.py（Flux） | 自動 |
| Markdown→note形式変換 | md2note.py ほか | 自動 |
| note入稿（タイトル・本文・画像） | Playwright（ブラウザ自動操作ツール） | 自動 |
| 公開ボタン | 人 | 手動（意図的）→ 後述の通り現在は自動 |
「全部AIに書かせて全部自動で出す」のではなく、書く価値があるかの判断は人が握ったまま、その前後の単純作業だけを機械に渡す。これがこの仕組みの骨格です。
品質チェッカーが実際に見ているもの
要になっているのが、入稿前に必ず通す検査スクリプト check_note_article.py です。100行に満たないPythonで、冒頭のコメントに方針が書いてあります。「見るのは『後から直すのが高くつく』ものだけ」。
コードを読むと、検査項目は次の通りです。
- 禁止表現11語。「劇的」「圧倒的」「革命」「もう不要」「奪われ」「今すぐ」「いかがでし」「完全に代替」「誰でも簡単」「驚愕」「衝撃」。本文に1つでも含まれると不合格です。AIに執筆を任せると入り込みやすい煽り言葉を、機械的に締め出しています
- 字数。空白を除いた本文が1,800〜2,500字の範囲に収まっているか。少なすぎても多すぎても不合格です
- 構成。見出し（##）が4本以上あるか。箇条書きか表が最低1つあるか。末尾に「自社に当てはめる3つの問い」という決まったコーナーがあるか
- 冒頭の結論。最初の段落が長すぎないか。ここは正直に書くと、コメントには「結論を200字以内で言い切る」とありますが、コードの判定は「空白を除いて250字を超えたらエラー」です。注釈と実装が50字ずれています
- リンクの実在。本文中の ai-oni.com へのリンクが1本以上3本以下か。そして各リンクに実際にHTTPリクエストを送り、15秒以内に正常応答（200）が返るかを確かめます。文面の点検だけでなく、リンク切れを公開前に通信で検出します
1項目でも引っかかると終了コードでエラーを返し、「✗が出たら直す。通るまで入稿しない」が運用ルールです。人間の目視チェックと違って、疲れていても項目を飛ばしません。
noteには表がない — 変換スクリプトの仕事
md2note.py は、編集用のMarkdownをnoteに貼れるHTMLに変換します。地味ですが、ここに手作業だと毎回面倒な処理が詰まっています。
代表が表です。noteには表の機能がありません。そのままコピーすると崩れます。そこでこのスクリプトは、表を検出すると箇条書きに変換します。1列目を太字の見出しにして、残りの列を「列名：値」の形で「／」区切りに連結する、という決め打ちの規則です。
入稿操作の自動化では、運用メモに失敗の記録が残っています。
- 画面を表示しないモード（headless）のブラウザでは、Cmd+Vの貼り付けが効かない。本文が何も入らない
- noteの内部APIに自作のHTMLを直接送ると、不正なパラメータとして拒否される（422エラー）。本文の各要素への識別子付与をnote側の下書き保存処理に任せる必要がある
- 最終的に安定したのは、貼り付けイベントをプログラムから直接発生させて本文を流し込み、「下書き保存」ボタンを押してnote側に正規化させる手順だけ
こうした試行錯誤の結論だけが手順としてスクリプトに固定されているので、2本目以降は同じ穴に落ちません。自動化の価値の半分は、この「ハマりの再発防止」だとうちでは考えています。
公開ボタンは、途中から自動になった
ここが、この記事でいちばん正直に書くべき部分です。
冒頭の表の通り、設計では「公開ボタンは人が押す。意図的に手動」でした。ところが現在の運用メモには、こう書いてあります。「cronが平日07:30に下書きを1本だけ公開する」。番号の若い順に1日1本、決まった時刻に自動で公開ボタン相当の処理が走っています。
実物の auto_publish.mjs を読むと、noteの公開画面をブラウザで操作するのではなく、記事の状態を「公開」に書き換えるリクエストをnoteの内部APIへ直接送る方式でした。ここにも失敗の記録があります。ブラウザ以外からの通信が防御機構（WAF）に弾かれて403エラーになる、著者としてアクセスすると下書き記事でも正常応答が返ってしまい「公開できた」と誤検知する、など。対策として、公開後に記事の状態フィールドを取り直して「published」であることを確認してから、管理ファイルの状態を書き換えるようになっています。
では「判断を人に残す」という設計は破られたのか。うちの読みでは、こう整理できます。公開の判断は、公開ボタンから「下書きの列に入れるかどうか」へ前倒しされた、と。下書きに積まれるのは品質チェッカーを通過した記事だけで、順番も番号で決まっています。人がやめたいときは、cronの該当行をコメントアウトすれば止まります。判断が消えたのではなく、判断する場所が動いた、というのが実態に近いと考えられます。
在庫の補充も自動 — ただし品質ゲート付き
毎朝の公開後には、在庫を確認する処理も走ります。下書きが8本を切っていたら、「AIの鬼」の未使用記事を素材に新しいnote記事を書いて下書きに積む仕組みです。素材は130本以上あるため、当面尽きないと運用メモにあります。
執筆はAIモデル（claude、モデルはsonnet指定）を1本あたり1回呼びます。ここでも歯止めは同じで、品質チェッカーを通ったものだけが入稿されます。書いたが基準に達しない記事は、下書きにすら入りません。使用済みの素材は記録ファイルで管理し、同じ元記事から二重に生成しない仕組みも入っています。
なお、この半自動化で投稿1本あたりの作業時間がどれだけ減ったかは、計測していません。効果を数字で示せないのは弱点として書いておきます。
関連する記録
- APIがない管理画面は自動化を諦めるしかないのか — noteの記事公開とメール追加を「ブラウザごと」無人化した実例
- 経理は13本、マーケは1本 — 27本の自動化ジョブが教えてくれた「AIに任せてよい仕事」の見分け方
まとめ
- 設計の原則は「判断は人、作業は機械」。変換・品質チェック・画像・入稿という手作業だけを自動化した
- 品質チェッカーは「後から直すのが高くつく」ものに絞って検査する。禁止表現11語、字数1,800〜2,500、見出し4本以上、末尾の定型コーナー、リンクの実在をHTTP通信で確認
- noteに表機能がない、headlessで貼り付けが効かない、といったハマりは、解決手順ごとスクリプトに固定して再発を防いだ
- 「人に残す」と決めた公開ボタンは、結局自動化された。ただし判断が消えたのではなく、品質ゲートと下書きの列に前倒しされた、というのがうちの整理
- 線引きは一度決めて終わりではなく、運用しながら動く。動いたことを隠さず記録に残すほうが大事だと考えています
自社の業務でも「どこまで自動化してよいか」の線引きに迷われている場合は、AI導入のご相談として株式会社TOEまでお声がけください。