【Claude Code】Qiitaブログの執筆・レビューを自動化してみた
はじめに
技術ブログを書こうとすると、こんな悩みが出てきますよね？
- 「書くネタはあるけど、構成を考えるのが面倒」
- 「書き終わった後のチェックが抜けがちで、公開後に気づく」
- 「コードブロックのラベル忘れや見出し階層のズレをよく指摘される」
これらを Claude Code のカスタムスキル で解決してみたのでワークフローを紹介します。
スキルにチェックリストを持たせることで、Claude が毎回同じ基準でレビュー・草案作成を行えるようになります！
対象読者
- Claude Code を使っている or 興味がある
- Qiita などに技術記事を投稿している
- 記事の品質チェックを自動化したい
動作環境
| 項目 | バージョン |
|---|---|
| OS | Windows 11 Enterprise |
| Claude Code | 最新版（CLI） |
| モデル | claude-sonnet-4-6 |
Claude Code のスキルとは
Claude Code には カスタムスキル という仕組みがあります。~/.claude/skills/<スキル名>/ 配下に Markdown ファイルを置くことで、/スキル名 と入力するだけで Claude がそのスキルの指示に従って動くようになります。
~/.claude/
skills/
write-qiita-blog/
skill.md ← スキルの定義ファイル
スキルファイルには「チェックリスト」「ノウハウ」「Gotchas」を記述します。Claude はこれを読み込んで草案作成・レビューを行います。
write-qiita-blog スキルの中身
今回使用したスキルの主要部分を抜粋します。参考までに以下に抜粋してますが各々のルールを定めてみてください！
チェックリスト（抜粋）
## チェックリスト（公開前に全項目確認）
### タイトル
- [ ] 技術名・ツール名が含まれている（例：`【Rails】`, `【MySQL】`）
- [ ] 何についての記事かひとめでわかる
### 見出し構成
- [ ] 見出しの階層が深くなりすぎていない（`####` 以上は原則使わない）
- [ ] 同列の内容が同じ階層に揃っている
### コードブロック
- [ ] 拡張子 or 言語名を指定している
- [ ] ファイル名または説明をコードブロックのラベルに書いている
- [ ] ログにユーザー名・トークン等の機密情報が含まれていない
### 必要な情報
- [ ] 動作環境が冒頭付近に記載されている
- [ ] 参考リンクが末尾にある
Gotchas（よくある落とし穴）
スキルには「よくある失敗パターン」も記述しています。Claude はレビュー時にこれを参照します。
## Gotchas（よくある落とし穴）
- **目次の基準見出し**: Qiita の目次は最初の見出しの大きさを基準にネストされる。
`##` から始める記事で `#` を混在させると崩れる。
- **ログの機密情報**: エラーログのコピペ時にユーザー名・トークン・パスが混入しやすい。
- **参考リンクがないと信頼性が下がる**: 一次情報（公式ドキュメント等）へのリンクで根拠を示す。
実際の操作手順
1. 下書き Markdown を用意する
記事の下書きを input/ 配下に置きます。フォーマットは自由です。
~/.claude/
input/
iam_roles_anywhere.md ← 今回レビューした記事
2. スキルを呼び出す
Claude Code のプロンプトで次のように入力します。
/write-qiita-blog
iam_roles_anywhere.md を Qiitaブログ向けにレビュー対応してください。
Claude がスキルを読み込み、チェックリストに基づいてレビューを開始します。
3. レビュー結果を受け取る
Claude から改善点が提示されます（次節参照）。
承認すると、出力先をCLAUDE.md 等で定義している場合、修正済みファイルが（例）generate/自動生成されます。
~/.claude/
generate/
20260609_IAMRolesAnywhere記事修正/
iam_roles_anywhere.md ← 修正済みファイル
フォルダ名は yyyymmdd_作業名 形式で自動生成されるようにカスタマイズしています。
レビュー結果の例
実際に iam_roles_anywhere.md（AWS IAM Roles Anywhere の技術記事）をレビューした結果です。
指摘された問題点
1. #### 見出しの使用（チェックリスト違反）
#### パターン 1: クロスアカウント AssumeRole ← ####は使わない
#### パターン 2: SDK の認証情報キャッシュとの組み合わせ
→ ### に格上げ
2. コードではないテキストをコードブロックに入れている
「ロールチェーン制約のまとめ」がコードブロックで囲まれていたため、> 引用形式 + リストに変更。
問題なしと判定された箇所
- タイトル（技術名・目的が明確）
- 見出し構成（
##→###の2階層） - コードブロックの言語指定・ファイルラベル
- 動作環境テーブル
- 参考リンク5件
- 機密情報なし（架空ARN・架空証明書のみ）
このワークフローのメリット
| 従来 | スキル導入後 |
|---|---|
| チェックは記憶頼り | スキルのチェックリストを毎回参照 |
| 指摘基準が毎回ブレる | 同一基準で一貫したレビュー |
| レビュー → 修正 → 確認が複数往復 | 一回の指示で修正済みファイルを生成 |
そもそも自動化できる時点で素晴らしいです…！ブログ執筆がはかどりますね。
まとめ
- Claude Code のスキルにチェックリストと Gotchas を持たせることで、毎回同じ品質基準で技術記事をレビューできる
-
/write-qiita-blogを呼び出すだけで草案作成・レビュー・修正済みファイル生成までが一連のフローになる - スキルファイルは Markdown なので、チームのノウハウを蓄積・共有するドキュメントとしても機能する
もちろん公開までに自分の手で修正は加えていかなければならないですが、
スキル定義自体も育てていくことで、「自分専用の記事品質基準」として磨いていけます！