この記事は約5分で読めます。
筆者プロフィール: ソフトウェアエンジニア。「知った気にならない。いつまでも学び続ける」を信条に、業務と個人開発の両輪で技術を磨いています。AI 駆動開発で複数の個人開発アプリを構築・運用中。
👉 ポートフォリオ: 筆者ホームページ
Qiita に記事を投稿するたびに、毎回ブラウザで編集していませんか？ Qiita CLI と Claude Code を組み合わせることで、記事の作成から SEO 最適化、予約投稿まで Git リポジトリ上で完結する仕組みを構築しました。この記事では、構築中にハマった「記事 ID の罠」も含めて、その全過程を公開します。
この記事の対象読者
- Qiita に定期的に記事を投稿しているが、執筆・投稿フローを効率化したい方
- Claude Code を記事執筆に活用したいが、具体的な構成が分からない方
- 「1日1投稿」を継続したいが、毎日書く時間が取れない方
解決したかった3つの課題
| 課題 | 詳細 |
|---|---|
| 毎回ブラウザで編集 | Qiita のエディタで書く → Git 管理できない、差分が追えない |
| SEO 対策が属人的 | タイトルやタグの最適化を毎回手動で考える |
| 1日1投稿が続かない | まとまった時間に書きたいが、投稿タイミングを分散したい |
これらを Qiita CLI + Claude Code + GitHub Actions で仕組み化しました。
構築したシステムの全体像
① たたき台を Claude Code に共有
↓
② /improve-article スキルが自動実行
├── Qiita トレンド分析（毎回最新を取得）
├── SEO 6点チェック（タイトル・導入文・タグ・見出し・内部リンク・裸URL）
├── 記事の構成・表現を改善（既存の内容は変更しない）
└── 予約投稿日を自動算出
↓
③ Git で管理（日次ブランチ → PR → main マージ）
↓
④ GitHub Actions が自動実行
├── main マージ時 → 即時投稿対象の記事を publish → ID をコミットバック
└── 毎日 20:00 JST → 予約日の記事を 1件 publish
Step 1: Qiita CLI の導入 — 記事を Git 管理する
Qiita CLI とは
Qiita CLI は、Qiita 公式が提供するコマンドラインツールです。記事の作成・プレビュー・投稿をローカル環境で完結できます。
セットアップ
# インストール
npm install @qiita/qiita-cli --save-dev
# 初期化（設定ファイル・GitHub Actions ワークフローが生成される）
npx qiita init
# ログイン（Qiita のアクセストークンが必要）
npx qiita login
# 既存記事の取り込み
npx qiita pull
これだけで、Qiita 上の全記事が public/ ディレクトリに Markdown ファイルとして同期されます。
導入結果
私のアカウントでは 213記事 が一括で取り込まれました。
CreateQiita/
├── public/ # 記事ファイル（Qiita CLI 管理）
│ ├── 36404f9ec9c786cde671.md # 既存記事（記事IDがファイル名）
│ ├── 2026-04-12_ai-driven-dev-3weeks.md # 新規記事（日付プレフィックス）
│ └── ...
├── package.json
├── qiita.config.json # Qiita CLI 設定
└── .github/workflows/
└── publish.yml # main マージ時の自動投稿
基本コマンド
| コマンド | 用途 |
|---|---|
npx qiita new <name> |
新規記事を作成 |
npx qiita preview |
ブラウザでプレビュー（localhost:8888） |
npx qiita publish <name> |
記事を投稿・更新 |
npx qiita publish --all |
全記事を投稿・更新 |
npx qiita pull |
Qiita から最新を同期 |
Step 2: Claude Code で記事改善を自動化 — /improve-article スキル
Qiita CLI で記事を Git 管理できるようになったので、次は 記事の品質向上を自動化 します。
スキルの設計
.claude/skills/improve-article.md に記事改善の全手順を定義しています。Claude Code に「この記事を改善して」と伝えるだけで、以下が自動実行されます。
Step 0: トレンド分析 + キーワードリサーチ
├── Qiita トレンド上位5記事のタイトル・タグ・いいね数を取得
├── タイトルパターン・タグ傾向を分析
└── 分析結果をメモリに蓄積（上書きではなくマージ）
Step 1: 元記事の分析
Step 2: タイトルの SEO 最適化
Step 3: 見出し構成の最適化
Step 4: 導入文の最適化（検索スニペット対策）
Step 5: 本文の改善
Step 6: まとめ・関連記事の強化
Step 7: タグ選定
Step 8: 投稿設定（予約日自動算出 + 水曜日戦略）
Step 9: 最終 SEO 6点チェック
トレンド分析の蓄積型学習
記事を改善するたびに、Qiita のトレンドを分析してメモリに蓄積します。上書きではなく蓄積型にすることで、一時的な流行と恒常的なパターンを区別できます。
メモリ構成:
├── project_trend_analysis.md # トレンドパターンの蓄積（毎回マージ更新）
└── feedback_article_success_pattern.md # 自分の記事の成功パターン
実際に蓄積されたパターンの例:
| パターン | 具体例 | 確認日 |
|---|---|---|
| 感情+実用ハイブリッド | 「奥深く、楽しい — 伝わるドキュメントを作る技術」 | 2026-04-12 |
| 問題提起型 | 「素人バイブコーディング勢に物申す」 | 2026-04-12 |
| 数字+具体性 | 「8選」「3つの原則と1つの習慣」 | 2026-04-12 |
| 季節タグの効果 | 4月は「新人プログラマ応援」がトレンド上位の4割で使用 | 2026-04-12 |
Stop Hook で品質チェックを自動実行
.claude/settings.json に Stop Hook を設定し、記事編集セッションの終了時に SEO 6点チェックが自動実行 されます。
{
"hooks": {
"Stop": [
{
"hooks": [
{
"type": "prompt",
"prompt": "public/ 内の記事を編集した場合、以下をチェック: 1.タイトルSEO 2.導入文 3.タグ具体性 4.見出しキーワード 5.関連記事 6.裸URL"
}
]
}
]
}
}
人間がチェックを忘れても、仕組みが品質を担保します。
Step 3: 予約投稿 — 1日1記事を自動化する
「1日1投稿」を継続したいが、毎日書く時間はない。この問題を 予約投稿 で解決しました。
仕組み
記事のフロントマターで予約日を指定するだけです。
---
title: "記事タイトル"
tags:
- "ClaudeCode"
- "AI駆動開発"
ignorePublish: false # 予約状態（main マージ時にスキップ）
scheduled_publish_date: "2026-04-15" # この日に自動投稿
---
動作フロー
GitHub Actions の cron ジョブが毎日 20:00 JST に実行されます。
毎日 20:00 JST
↓
scripts/scheduled-publish.sh が実行
↓
予約日 <= 今日 かつ ignorePublish: true の記事を検索
↓
最も古い予約日の記事を 1件 投稿
↓
ignorePublish を false に書き換え → コミット & プッシュ
なぜ 20:00 JST なのか
投稿時刻を調査した結果、20:00〜22:00 は帰宅後にじっくり技術記事を読む層が多いことが分かりました。さらに、水曜日は Qiita の PV が最大（データ上31,759PV）で、木曜 05:00 のトレンド更新 → 日曜トレンド → 水曜メルマガという流れに乗りやすい。
そのため、複数記事を同時に作成する場合は水曜日の枠に最もバズりやすい記事を配置する運用にしています。
予約日の自動算出
新規記事作成時、/improve-article スキルが既存の最新予約日 + 1日を自動算出します。手動で日付を計算する必要はありません。
運用例: 週末にまとめて書いて平日に自動投稿
4/12 (土) まとめて4記事作成:
├── 記事A: scheduled_publish_date: "2026-04-12" (即時投稿)
├── 記事B: scheduled_publish_date: "2026-04-13"
├── 記事C: scheduled_publish_date: "2026-04-14"
└── 記事D: scheduled_publish_date: "2026-04-15" (この記事)
4/12 (土) main にマージ
└── ignorePublish: true の記事はすべてスキップ
4/13 (日) 20:00 → 記事B が自動投稿
4/14 (月) 20:00 → 記事C が自動投稿
4/15 (火) 20:00 → 記事D が自動投稿（この記事）
この記事自体が、この予約投稿の仕組みで投稿されています。
Step 4: 記事 ID 管理の落とし穴 — 実際にハマった話
仕組みを構築する中で、記事の重複投稿という問題に直面しました。同じ記事が4回投稿されてしまったのです。ここではその原因と対策を共有します。
何が起きたか
Qiita CLI で新規記事を作成すると、フロントマターの id は null になります。
id: null # まだ Qiita に投稿されていない
ignorePublish: false
この状態で publish.yml（main マージ時に全記事を publish）が実行されると、Qiita CLI は id: null の記事を毎回「新規記事」として投稿します。マージのたびに同じ記事が新規作成され、結果として4重投稿になりました。
根本原因と対策
publish.yml に投稿後の ID コミットバックがなかったことが原因です。publish.yml に投稿後の変更を自動コミットするステップを追加し、解決しました。また、Qiita 上で記事を削除した場合はローカルのファイルも削除する運用ルールを追加しました。
学んだこと
-
id: null+ignorePublish: falseの組み合わせは危険 — マージのたびに新規投稿される -
ID コミットバックは必須 —
publish.ymlに投稿後の変更をコミットするステップを追加する - 仕組みの検証は小さく始める — 最初の1記事で動作確認してから複数記事を投入すべきだった
Before/After — 何がどれだけ変わったか
| 観点 | Before | After |
|---|---|---|
| 記事の編集 | Qiita ブラウザエディタ | ローカル Markdown + Git 管理 |
| SEO 対策 | 毎回手動で考える | スキルが自動で最適化 + Stop Hook でチェック |
| トレンド反映 | 感覚で判断 | 毎回トレンドを取得し蓄積型で学習 |
| 投稿タイミング | 書いたらすぐ投稿 | 予約投稿で1日1記事を 20:00 JST に自動化 |
| コミット | 手動 | Stop Hook で自動コミット & プッシュ |
| 品質チェック | 人間が忘れがち | 仕組みが自動実行 |
| 記事 ID 管理 | 手動（重複投稿のリスク） | publish 後に自動コミットバック |
まとめ — 記事を「書く」から「仕組みで生み出す」へ
| レベル | 何が変わるか |
|---|---|
| 入門 | Qiita CLI で記事を Git 管理し、変更履歴を追えるようになる |
| 中級 | Claude Code のスキルで SEO 最適化・トレンド分析が自動化される |
| 上級 | 予約投稿で「1日1記事」を人間の意志力に頼らず仕組みで継続する |
仕組みを作る過程で、記事 ID の重複投稿という「仕組み化の落とし穴」にもハマりました。しかし、その失敗も含めて仕組みに組み込んだことで、今は安心して予約投稿を運用できています。
記事を「書く作業」から「仕組みで生み出す活動」に変える。 それがこのリポジトリの目的です。
Qiita CLI も Claude Code も、セットアップは数十分で完了します。
「毎回ブラウザで書いている」方は、ぜひ試してみてください。