これは何
「Claude Code でのやり取りを Qiita 記事にして残したい」と思い立ち、その仕組みづくり自体を Claude Code に丸投げしてみた記録です。
最終的に 「ローカルで Markdown を編集して git push すると、GitHub Actions が Qiita へ自動投稿してくれる」 環境が完成しました。会話の流れをほぼそのまま、ハマった点も含めて残します。
環境: Windows 11 / PowerShell / Node.js v22 / Claude Code
Q1. 「Claude Codeのやり取りを記事化したい。どんな方法がある?」
最初はざっくり相談から。返ってきた選択肢は大きく3つ。
- (A) GitHub で記事をバージョン管理 → Qiita へ自動投稿する仕組み
- (B) 会話ログから記事の素材を半自動で抽出する仕組み
- (C) とりあえず手動で1本書く
王道として勧められたのが Qiita 公式の「Qiita CLI」+ GitHub Actions の組み合わせ。記事を Markdown でリポジトリ管理しつつ、push で自動投稿できる。(A) を選択。
Q2. セットアップ開始
リポジトリ作成 & Qiita CLI 導入
mkdir qiita-articles; cd qiita-articles
git init
npm install @qiita/qiita-cli --save-dev
npx qiita init # GitHub Actions 用の publish.yml などが生成される
npx qiita init で以下が自動生成された。
| ファイル | 役割 |
|---|---|
.github/workflows/publish.yml |
main/master への push で Qiita へ自動投稿する Actions |
qiita.config.json |
Qiita CLI 設定 |
.gitignore |
node_modules 等を除外 |
Qiita トークン発行 & ログイン
Qiita → 設定 → アプリケーション → 個人用アクセストークン（スコープ read_qiita + write_qiita）を発行して、
npx qiita login # トークンを貼り付け（対話入力）
npx qiita pull が Successful! を返せば認証 OK。
💡 学び: トークン入力は対話形式。AIエージェントに代行させず、自分のターミナルで打つのが安全。
Q3. 記事の frontmatter を理解する
npx qiita new 記事名 で生成される .md の先頭はこうなっている。
---
title: 記事タイトル
tags:
- ClaudeCode
private: true # true = 限定共有（下書き運用）
updated_at: ''
id: null # 投稿後に Qiita が自動採番して書き戻す
organization_url_name: null
ignorePublish: false # true でこの記事を投稿対象から除外
---
ポイントは id: null で push すると新規投稿され、ID が採番されてこのファイルに書き戻されること。以降は同じファイルを編集して push すれば「更新」になる。新規も更新も同じ操作で済むのが気持ちいい。
Q4. GitHub 連携でつまずいた3点
ここからが本番。実際にハマった所をそのまま残す。
つまずき① gh も winget も PATH に無い
gh auth status を打つと gh は認識されません。winget も同様。
→ 実体を直接叩いて解決。
& "C:\Program Files\GitHub CLI\gh.exe" auth status
gh 自体はインストール済みだった（PATH が通っていなかっただけ）。
つまずき② push が workflow スコープ不足で拒否される
gh repo create ... --push したら、リポジトリは作られたのに push だけ拒否。
! [remote rejected] HEAD -> main
(refusing to allow an OAuth App to create or update workflow
`.github/workflows/publish.yml` without `workflow` scope)
.github/workflows/ 配下を push するには OAuth トークンに workflow スコープが要る、という GitHub のセキュリティ仕様。
gh auth refresh -h github.com -s workflow # ブラウザ認証で1回追加
これで再 push が通った。
つまずき③ 最初の push 時は Secret 未登録で Actions が失敗する
push で発火した1回目の Actions は failure。理由は、その時点で QIITA_TOKEN の Secret をまだ登録していなかったから。
gh secret set QIITA_TOKEN --repo <owner>/qiita-articles # トークンを貼る
Secret 登録後に手動で再実行したら success。
gh workflow run "Publish articles" --repo <owner>/qiita-articles
💡 学び: 「push → Actions失敗」は順番の問題なだけ。Secret を入れてから
workflow runで叩き直せば通る。
できあがった仕組み
ローカルで public/*.md を編集
│ git push（main）
▼
GitHub リポジトリ（private）
│ GitHub Actions「Publish articles」が自動発火
▼ ※ Secret: QIITA_TOKEN で Qiita 認証
Qiita に自動投稿 / 更新
そして実際に、この記事の元になったサンプル記事が Qiita 側に id 付きで登録され、git pull でローカルに ID が書き戻されることまで確認できた。サイクルが一周回った瞬間が地味に感動した。
今後の運用（これだけ）
cd qiita-articles
npx qiita new 記事名 # 新規（任意）
# public/ の .md を編集
git add .
git commit -m "記事更新"
git push # → 自動で Qiita に反映
-
private: trueの記事は限定共有（下書き）。公開時にfalseに変えて push - トークンはチャットやコミットに貼らない。漏れたら失効 → 再発行
まとめ
- Qiita CLI + GitHub Actions で「push したら Qiita に反映」が作れる
- ハマりポイントは
workflowスコープと Secret 登録の順番の2つがほぼ全て - セットアップ自体を AI エージェントに任せても、トークン入力とブラウザ認証だけは自分でやるのが安全
この記事自体も、その仕組みを通して投稿されています。