Qiita CLI × Claude Code で記事管理を自動化した — トレンド分析・SEO・予約投稿、そして記事IDの罠
Qiita に記事を投稿するたびに、毎回ブラウザで編集していた。Git 管理できない、差分が追えない、SEO 対策は毎回手動——。
この非効率を解消するために、Qiita CLI + Claude Code + GitHub Actions で記事管理を自動化する仕組みを構築しました。
この記事では、構築の全過程に加えて、実際にハマった「記事 ID の重複投稿」問題と、データに基づく投稿時刻の最適化も含めてお伝えします。
解決したかった 3 つの課題
| 課題 | 詳細 |
|---|---|
| 毎回ブラウザで編集 | Qiita のエディタで書く → Git 管理できない、差分が追えない |
| SEO 対策が属人的 | タイトルやタグの最適化を毎回手動で考える |
| 1 日 1 投稿が続かない | まとまった時間に書きたいが、投稿タイミングを分散したい |
構築したシステムの全体像
① たたき台を Claude Code に共有
↓
② /improve-article スキルが自動実行
├── Qiita トレンド分析（毎回最新を取得）
├── SEO 6 点チェック
└── 予約投稿日を自動算出
↓
③ Git で管理（日次ブランチ → PR → main マージ）
↓
④ GitHub Actions が自動実行
├── main マージ時 → 即時投稿 → ID コミットバック
└── 毎日 20:00 JST → 予約日の記事を 1 件投稿Step 1: Qiita CLI で記事を Git 管理する
Qiita CLI は Qiita 公式のコマンドラインツールです。
npm install @qiita/qiita-cli --save-dev
npx qiita init && npx qiita login && npx qiita pullこれだけで、Qiita 上の全記事が public/ ディレクトリに Markdown ファイルとして同期されます。私のアカウントでは 213 記事が一括で取り込まれました。
Step 2: Claude Code で記事改善を自動化
.claude/skills/improve-article.md に記事改善の全手順を定義しました。Claude Code に「この記事を改善して」と伝えるだけで、10 ステップの改善が自動実行されます。
トレンド分析の蓄積型学習
記事を改善するたびに、Qiita のトレンドを分析してメモリに蓄積します。上書きではなく蓄積型にすることで、一時的な流行と恒常的なパターンを区別できます。
実際に蓄積されたパターンの例:
| パターン | 具体例 |
|---|---|
| 感情 + 実用ハイブリッド | 「奥深く、楽しい — 伝わるドキュメントを作る技術」 |
| 数字 + 具体性 | 「8 選」「3 つの原則と 1 つの習慣」 |
| 季節タグの効果 | 4 月は「新人プログラマ応援」がトレンド上位の 4 割で使用 |
Step 3: 予約投稿 — 1 日 1 記事を自動化する
記事のフロントマターで予約日を指定するだけです。
ignorePublish: true # 予約状態
scheduled_publish_date: "2026-04-15" # この日に自動投稿GitHub Actions の cron ジョブが毎日 20:00 JST に実行され、予約日の記事を 1 件投稿します。新規記事作成時、既存の最新予約日 + 1 日を自動算出するので手動で日付を計算する必要はありません。
なぜ 20:00 JST なのか
| 時間帯 | 効果 |
|---|---|
| 朝〜昼（9:00〜12:00） | 初速がつきやすい（仕事中の調べ物） |
| 夜（20:00〜22:00） | 深く読まれやすい（帰宅後のじっくり読み） |
| 土日 | PV が平日の 1/5 以下（娯楽モード） |
さらに、水曜日は Qiita の PV が最大で、複数記事を同時に作成する場合は水曜日の枠に最もバズりやすい記事を配置する運用にしています。
Step 4: 記事 ID の罠 — 同じ記事が 4 回投稿された話
仕組みを構築する中で、記事の重複投稿という問題に直面しました。
Qiita CLI で新規記事を作成すると、フロントマターの id は null です。この状態で main にマージすると qiita publish --all が実行されますが、デフォルト設定には投稿後に Qiita が割り当てた ID をリポジトリにコミットバックする仕組みがありません。
1 回目のマージ → id:null の記事を投稿 → Qiita が ID を割り当て
→ しかしリポジトリには id:null のまま
2 回目のマージ → まだ id:null → また新規投稿される...結果、同じ記事が 4 回投稿されてしまいました。さらに重複記事を Qiita 上で削除後、ローカルに残った削除済み ID のファイルが 404 エラーを引き起こし、ワークフロー全体が失敗しました。
解決策: ID コミットバック
publish.yml に、投稿後の ID 変更を自動コミットするステップを追加しました。
- name: Commit updated article IDs
run: |
git config user.name "github-actions[bot]"
git config user.email "github-actions[bot]@users.noreply.github.com"
if ! git diff --quiet public/; then
git add public/
git commit -m "chore: update article IDs after publish"
git push
fi| 教訓 | 詳細 |
|---|---|
id: null + ignorePublish: false は危険 | マージのたびに新規投稿される |
| ID コミットバックは必須 | Qiita CLI のデフォルトでは ID がリポジトリに反映されない |
| 仕組みの検証は小さく始める | 最初の 1 記事で動作確認してから複数記事を投入すべき |
Step 5: Git 運用 — 日次ブランチの自動化
Claude Code の Hooks を活用して、日次ブランチ運用を自動化しました。
SessionStart Hook: セッション開始時に、前日以前のブランチをコミット & プッシュ → PR 自動作成 → マージ済みブランチを削除してから当日ブランチを作成します。
Stop Hook: セッション終了時に、機密情報スキャン → 変更の自動コミット & プッシュ → SEO チェックを順番に実行します。手動でコミットする必要がありません。
Before / After
| 観点 | Before | After |
|---|---|---|
| 記事の編集 | Qiita ブラウザエディタ | ローカル Markdown + Git 管理 |
| SEO 対策 | 毎回手動で考える | スキルが自動最適化 + Stop Hook でチェック |
| 投稿タイミング | 書いたらすぐ投稿 | 20:00 JST に予約投稿（水曜日戦略） |
| 記事 ID 管理 | 手動（重複投稿リスク） | publish 後に自動コミットバック |
まとめ
仕組みを作る過程で、記事 ID の重複投稿という「仕組み化の落とし穴」にハマりました。しかし、その失敗も含めて仕組みに組み込んだことで、今は安心して予約投稿を運用できています。
「失敗の科学」の記事で書いた通り、最大の失敗は失敗を蓄積しないこと。今回の記事 ID 問題も、教訓として仕組みに反映したからこそ、再発はありません。
関連記事
- 「テスト工程が消滅した」— AI 駆動開発 vs 従来開発を全工程で比較してみた — AI 駆動開発で 3 週間でアプリを作った実績データ
- 「失敗の科学」— すべての失敗を経験するには、人生は短すぎる — 失敗を蓄積・分析する仕組みの重要性
- 「エッセンシャル思考」と「エフォートレス思考」— 何をやるかと、どうやるかの両輪 — 仕組み化による効率化の思想