起きたこと: 2本目までは通り、3本目から全部 429

19:12 / 19:54 — 公開記事 2本は問題なく 201
3本目から 429。60→120→180→240→300 秒バックオフで再試行しても全て 429
private: true(下書き)でも 429。公開フラグは関係なく「記事の作成」自体が止められる
Web UI の /drafts/new をブラウザで開いても /trend にリダイレクトされる

レスポンスに Retry-After も X-RateLimit-* も付かないので、いつ解除されるかは API からは読み取れません。

切り分け: 「作成」だけが塞がれる

操作	結果
`GET /authenticated_user`	✅ 200(トークンは正常)
`GET /users/:id/items`	✅ 200
`POST /items` 公開	❌ 429
`POST /items` 下書き	❌ 429
Web `/drafts/new`	❌ `/trend` へリダイレクト
設定・プロフィール画面	✅ 正常

トークン失効でもセッション切れでもなく、「記事を作成する」という操作だけがアカウント単位でブロックされています。API 経路を変えても Web UI でも同じ壁なので、迂回手段はありません。

先行事例と照合すると

同じ現象の報告はいくつかあります。

閾値は非公開ですが、傾向としては 「短時間の連投」と「新規アカウント」で厳しめに見えます。今回のアカウントは当日作成・メール認証済み・2本目まで正常 —— その条件で3本目が弾かれました。

運用の教訓: 投稿側でペースを守る

制限値を当てにするのではなく、API 側の実績を見てから投稿する設計が安全です。

// 投稿前に「今日何本出したか」を本物の状態から確認する
const items = await fetch(
  'https://qiita.com/api/v2/authenticated_user/items?per_page=20',
  { headers: { Authorization: `Bearer ${token}` } },
).then((r) => r.json());

const today = new Date().toLocaleDateString('sv-SE', { timeZone: 'Asia/Tokyo' });
const postedToday = items.filter((i) => i.created_at.startsWith(today));

const PER_DAY = 1; // 新規アカウントは1日1本が安全圏
if (postedToday.length >= PER_DAY) {
  console.log(`SKIP: 本日 ${postedToday.length} 件投稿済み`);
  process.exit(0);
}

1日1本ペースを上限にする(先行事例・自分の観測ともに連投がトリガー)
429 に Retry-After がないので、解除確認は「翌日に1回試す」程度のポーリングで十分
連続投稿が前提のシステムなら、キューに溜めて翌日枠に送る構造にする — 失敗時リトライより「積まない」方が確実

まとめ

Qiita の新規アカウントは 同日2本投稿後に3本目から 429 で止まった(本件では)
制限は アカウント単位 — API/下書き/Web エディタの全経路で塞がれる
Retry-After なし・解除時刻は不透明。先行事例では最長 ~24h の報告
自動投稿するなら authenticated_user/items で当日実績を数えてから投稿、連投はキューで翌日送り

「API が叩ける = 投稿できる」ではない、ということを知る良い機会になりました。