前回（第3弾）では、公式APIが突然死んだことをきっかけに、HTMLスクレイピングへ転換した話を書いた。投稿の自動化は完成した。だが、記事を書いて投稿するだけでは片手落ちだと気づいた。

発信だけして、他者の記事を読まないのはマナー違反だ。

note.comはSNSだ。フィードに流れてくる他のクリエイターの記事を読み、いいねを送り、コメントで感想を伝える。それが循環を生む。しかし手作業でこれをやると時間がかかる。ならば自動化するしかない。

1. 作るもの：engageコマンド

設計はシンプルだ。

フェーズ1（fetch）:
  新着記事を取得 → AIがコメント草案を生成 → YAMLキューに保存

フェーズ2（post）:
  ユーザーがYAMLを確認・編集 → いいね＋コメントを実行

人間が草案をチェックする工程を必ず挟む。AIが勝手にコメントを垂れ流す設計にはしない。 これは信条だ。

2. 新着記事フィードの発見

最初の課題は「どの記事にいいねするか」だ。フォローしているクリエイターに限定する案もあったが、それでは出会いがない。note.com全体の新着を取りたい。

FirefoxのDevToolsを開き、note.comのトップページを眺める。ネットワークタブに流れるリクエストの中に、見覚えのないエンドポイントがあった。

GET /api/v3/notes?page=1&per=20

叩いてみると、全クリエイターの新着記事が返ってくる。しかもbodyフィールドにプレーンテキストの本文まで含まれている。スクレイピング不要だ。

{
  "data": [
    {
      "type": "TextNote",
      "key": "n8699e4e63db3",
      "name": "記事タイトル",
      "body": "本文テキスト...",
      "user": { "urlname": "someuser", "nickname": "クリエイター名" }
    }
  ],
  "next_page": 2
}

--page Nフラグでページを指定すれば、毎回違う記事が取れる。10件ずつ処理するのが今のやり方だ。

3. いいねAPIの発見——v3、しかもIDではなくkeyで叩く

いいねのAPIは一筋縄ではいかなかった。最初に試したのはこれだ。

POST /api/v1/notes/{数値ID}/likes  →  403 Forbidden

403。自分の記事への自己いいねが禁止されているのかと思った。違った。エンドポイント自体が間違っていた。

正しいエンドポイントはPythonのPlaywrightでブラウザの実際の通信を記録して発見した。

POST /api/v3/notes/{key}/likes

v3で、数値IDではなく英数字のkey（n58da77ec9658のような文字列）を使う。レスポンスはHTTP 201。これで動いた。

4. コメントAPIの発見——構造体JSONが必要だった

コメントも同じく罠があった。当初の実装はこうだ。

payload := map[string]string{"comment": "コメント本文"}
POST /api/v1/notes/{数値ID}/comments

実行すると全記事で「この記事はコメント機能が無効になっています」という403が返ってくる。10件全部。

嘘だ、と思った。実際にnote.comでコメント欄を開いて投稿ボタンを押し、DevToolsでリクエストをキャプチャした。

POST /api/v3/notes/{key}/note_comments

{
  "comment": {
    "type": "root",
    "children": [{
      "type": "element",
      "tag_name": "p",
      "children": [{"type": "text", "value": "コメント本文"}]
    }]
  },
  "acknowledgement": false
}

エンドポイントもペイロードも全然違った。

v1ではなくv3
数値IDではなくkey
プレーンな文字列ではなくAST（抽象構文木）形式のJSON

note.comはリッチテキストエディタのデータ構造をそのままAPIに渡す設計になっている。テキストノードを段落要素でラップし、それをrootで包む。

5. レート制限の壁

コメントAPIが動き始めると、すぐに次の壁にぶつかった。

HTTP 429
{"error": {"message": "上限に達したためご利用できません。しばらくお待ちいただいた後、再度お試しください。", "type": "too_many_requests"}}

1セッションで約9件コメントした直後に、次のバッチで全件429になった。コメントにはレート制限がある。いいねには今のところ制限は見当たらない。

対策は2つ。

コメント間に3秒のsleepを入れる
バッチ間は5分以上空ける

6. キューファイルの設計

フェーズ1で生成されるYAMLはこういう構造だ。

creator: random
fetched_at: "2026-07-12T19:34:29+09:00"
articles:
  - key: n8699e4e63db3
    title: "記事タイトル"
    url: "https://note.com/someuser/n/n8699e4e63db3"
    summary: "本文の先頭200文字..."
    comment_draft: "AIが生成したコメント草案（100字以内）"
    action: like       # like | comment | skip
    liked: false
    comment_id: 0

actionフィールドを人間が編集してから--postを実行する。commentにした記事だけコメントが投稿される。草案が気に入らなければ書き直す。Nullと書けばいいねのみ。

コメント草案の生成にはOpenAI gpt-4o-miniを使っている。プロンプトは「記事タイトルと本文200文字から、日本語で100字以内のコメントを生成せよ」というだけだ。

7. 実際に動かしてみて

# 新着10件を取得（page=2から）
go run ./src/ engage --limit 10 --page 2

# キューを確認・編集してから投稿
go run ./src/ engage --post engage/queue-20260712-193449.yaml

いいね10件は一瞬で完了する。コメントは草案確認があるぶん、投稿まで少し手がかかるが、それでいい。完全無人化より、人間が一度読む設計のほうが誠実だ。

振り返り

今回の教訓：

DevToolsは最強の仕様書 — v1とv3、IDとkey、単純文字列とAST、全部DevToolsが教えてくれた
「403=禁止」と思うな — エンドポイントが間違っているときも403が返る
レート制限は実験して初めてわかる — ドキュメントには書いていない

次は、フォロー中クリエイターの新着を優先取得する機能と、コメント済み記事の重複スキップを実装したい。

コメントや知見の共有はコメント欄へどうぞ。