Claude Code で爆速開発してトピック単位で Qiita に流し続けたら API に 429 を食らった話

はじめに

個人開発の電気プラン比較メディア enegent.jp を、ここ 2 週間 Claude Code と二人三脚で改修している。体感で いつもの 5〜10 倍 のペースで機能・記事・調査が進み、副作用として出力物のアウトプット量がインプット量を超え始めた。

副作用の一つが「技術トピックごとに書ける知見がその日のうちに 2〜3 本溜まる」現象で、ブレずに Qiita に投下し続けた結果、Qiita API から 429 Too Many Requests を食らって一時的に投稿不能になった。本記事はその記録。

Claude Code の生産性が上がりすぎて、アウトプット側のサービスのレートリミットが先にサチる というのは、今後増える類のハマりポイントな気がするので、実録として残しておく。

何が起きたか

直近 2 週間の Qiita 投稿履歴（/api/v2/authenticated_user/items）：

2026-04-20T12:39  Next.js 15 個人SEOメディアの PageSpeed Insights モバイル...
2026-04-20T00:30  電気料金 API を 110秒 → 115ms（約1,000倍）に高速化した話
2026-04-20T00:30  テスト 248 件全パスなのに本番で 110 秒でまた止まった話
2026-04-19T10:37  個人開発プロダクトの技術選定を1セッションで返却した話
2026-04-18T08:37  IndexNow + Bing Webmaster Tools + llms-full.txt を...
2026-04-17T16:45  （技術記事）
2026-04-17T10:28  （技術記事）
2026-04-17T10:28  （技術記事）
2026-04-17T10:28  （技術記事）
2026-04-16T00:41  （技術記事）
2026-04-15T10:44  （技術記事）
...

2 週間で 15 本以上。1 日 3 本投稿した日もある。

そして昨日の夜、次の記事を API 経由で投稿しようとしたら：

POST /api/v2/items → 429 Too Many Requests
{
  "message": "サービスの安定運用のため、短時間内の投稿数を制限させていただいております。
              大変お手数の上、しばらく時間をあけてから再度お試しください。",
  "type": "too_many_requests"
}

日付をまたいで 24 時間近く空けても同じ 429。「今日の N 件制限」ではなく累積頻度で判定されている 疑い。

なぜこんなにアウトプットが出るのか：Claude Code の開発ループ

結論から言うと、「1 つの技術的発見 → すぐ記事化」の摩擦がゼロに近い からだ。

典型的な 1 セッションの流れ：

例 1: canonical 事故とその記事化

(1) 開発時間 12:00
    「GSC 見たらインデックス済み 85 件しかない。おかしい」と相談

(2) 12:02〜12:15（13 分）
    Claude Code が URL Inspection API の監査スクリプトを書き、
    全 165 URL を叩き、80 件が代替ページ扱いと判明

(3) 12:15〜12:25
    curl で HTML を覗き、root canonical が全ページ継承されている
    事実を発見。layout.tsx から削除、page.tsx で LP 用に再設定

(4) 12:30〜12:45
    Vercel デプロイ、ハブページ /articles 新設、sitemap 再送信

(5) 12:45〜13:00
    GSC UI から手動 indexing request、監査スクリプトを SA 認証版に
    切り替え、ナレッジファイルに事故記録

(6) 21:30
    再監査で「85 → 158 件 PASS」を確認

(7) 22:00〜22:30
    「これ Qiita 記事になるね」 → 1 セッションで下書き完成

従来なら「監査スクリプトを書く」だけで半日、「事故調査」でまた半日、「記事化」は後日「あのとき何やったっけ…」と思い出しながら書くことになる。

Claude Code だと 発見から記事下書きまで同じセッションで完結する。コードと対話がそのまま記事の素材（時刻・実コマンド・実 HTTP レスポンス）になっているので、記事を書き始めた時点で素材がゼロから集まるフェーズがない。

例 2: パフォーマンス 1,000 倍記事

電気料金 API のコールドスタート 110 秒問題を追ったセッション。cProfile → pstats → 第 1 弾改善 → 再プロファイル → 第 2 弾 → … と 各段階の数値が全部セッションログに残っている。記事化するとき、数値を後から調べ直すオーバーヘッドが発生しない。

結果：1 つのパフォーマンス改善セッションから記事が 2 本 生える。

• 記事 A: 改善の全体像と数値 Before/After
• 記事 B: 途中で発見した副次的な知見（テストは通るのに本番で止まる系の落とし穴）

「記事 2 本書くために 2 日ぶん作業した」のではなく「1 日の改善作業から記事 2 本の素材が同時に落ちた」構造。素材取得コストが共有されているので単価が違う。

結果：アウトプット側がレートリミットにぶつかる

この構造で 2 週間走ると、Qiita 側の「サービス安定運用のための投稿頻度制限」に抵触する。具体的な閾値は公開されていないが、「個人が短期間に同一ジャンルで大量投稿」＝スパムパターンとして学習されている挙動に見える。

エンジニア個人のアウトプットペース（従来想定）
  ≒ 週に 1〜2 本、月に 5〜8 本

Claude Code で書くペース
  ≒ 日に 1〜3 本、週に 10〜15 本

→ Qiita のレート制限の前提より 1 桁速い

他のサービスでも同じことが起きうる：

• note: エディタの AI 連携経由で下書き量産するとスパム判定されやすい
• はてなブログ: 1 日 10 本以上だと検索エンジンからの扱いが雑になる
• Twitter / X: 以前から「連投は分散させろ」は常識
• GSC の Indexing API / URL Inspection API: 2,000/day の明示制限あり

Claude Code で生産性が上がったら、出力先のサービスごとの「人間の常識的ペース」も確認対象になる、というのが今回の学び。

対処法

短期: 投稿頻度を落とす

• 同じ日に連投しない：同日 3 本は明らかにやりすぎだった
• 2〜3 日に 1 本ペースに落とす（今後試す）
• 下書きを溜めて計画投稿する：Claude Code で書いた記事を docs/qiita/ に溜めて、日次で 1 本ずつ投稿する運用へ

中期: アウトプット先の分散

Qiita だけに流さない：

先	向いている内容
Qiita	Next.js / Python などピュア技術
Zenn	Next.js / TypeScript 系、Book 形式で連載可
自社ブログ / note	プロダクト文脈込みの読み物、技術以外
GitHub Discussion	OSS 周辺の知見
llms.txt / llms-full.txt	AI エージェント向けのサイト内ドキュメント（← SEO と別線）

Claude Code の出力は素材性が高いので、1 本の素材から 3 媒体ぶんの派生を作る のが現実的。同じ内容をコピペするのではなく、媒体ごとにトーンと深さを変える。これも Claude Code でやれば数分。

長期: 投稿 API のスケジューラ化

投稿ロジックを API 直叩きから キュー + スケジューラ に変える：

# scripts/post_qiita.py
ARTICLES_QUEUE = Path("docs/qiita/_queue/")

# 日次で 1 本だけ消化する cron
def daily_job():
    pending = sorted(ARTICLES_QUEUE.glob("*.md"))
    if pending:
        post_article(pending[0])
        pending[0].rename(ARTICLES_QUEUE / "_posted" / pending[0].name)

書く速度と公開する速度を分離する。Claude Code で書く速度は最大化したまま、外部サービスへの露出速度だけ人間の常識に合わせる。

補足: Claude Code で「記事を書く」ワークフロー

似たスタイルで運用してみたい人向けに、自分の記事化ワークフローをざっくり書いておく。

1. 開発中の「おっ」ポイントをセッション内に残す

   • 「これ Qiita ネタだ」と思ったら Claude Code に「メモっといて」とナレッジ追加させる
   • ナレッジファイル（knowledge/enegent/*.md）がそのまま後日の記事素材になる

2. セッション終盤で記事化を依頼

   • 「この 3 つの発見を 1 本にまとめて」
   • 「いや、Qiita 読者視点でいうとこれは 2 本に分けたほうが刺さる」と相談
   • タイトル案・構成案・トーンをこの段階で決める

3. 下書きレビュー

   • 「初級者向けすぎないか」「表のマトリクスが薄い」など具体的フィードバック
   • Claude Code が再度検索・補強して厚みを出す

4. 投稿

   • API で直投稿（今回これが詰まった）
   • もしくは下書きに保存して翌日公開

工程 1〜3 で人間側がやるのは 「このネタは記事になるか」の判断 と 「読者視点のトーン微調整」 だけ。執筆・構成・表作成・リファレンス調査は Claude Code に投げている。

まとめ

• Claude Code の個人開発ループは 素材取得と記事化のオーバーヘッドが融合する ため、従来の 5〜10 倍の速度でアウトプットが出る
• 出力先の Qiita API は 1 桁遅い投稿ペースを前提に設計されている ため、短期間で連投すると 429 になる
• 対処は (1) ペース抑制、(2) 媒体分散、(3) キュー化 の組み合わせ
• 生産性を上げたら 出力先のレートリミットが次のボトルネックになる という、新時代的な悩み

「Claude Code で技術記事を量産している個人開発者が、出力先のレート制限で詰まる」は、しばらく増え続ける型の現象だと思う。遭遇した人は「書く速度と出す速度を分ける」方向で設計し直すのがおすすめ。

関連記事：

• 電気料金 API を 110 秒 → 115ms（約 1,000 倍）に高速化した話
• Next.js 15 の Metadata API は「shallow merge」— 継承される設定を全部洗い出したリファレンス（公開予定）