ブログ更新のSNS宣伝を最小手間で半自動化、Claude Codeと一緒に設計した

この記事について
Claude（Anthropic）との共同編集により作成されました。

要約

個人ブログの流入が検索だけで頭打ち。新記事はインデックス化までに時間がかかり、SNS導線も無いため初動が弱い

完全自動化はAPI制約（X有料化、Threads審査、登録の手間）でコスパが悪いと判断、半自動化に倒した

Claude Codeとのワークフローは、要望を WANT.md に雑に書く → 壁打ちで sns_plan.md に整理 → コンテクストを切って plan モードで実装依頼、の3段

実装したのは記事Markdownから投稿文（X/Bluesky）を生成してgit追跡ファイルに書き出すローカルスクリプト1本だけ

スコープを切って「今回やらないこと」を明示することで、API投稿や CI 連携などの重い部分を後回しにできた

個人ブログを書いていて「記事を出しても誰も見に来ない問題」にぶつかった。SNS導線を組みたいけど自分で毎回投稿文を書くのは面倒、かといって完全自動化は重い。

そこで Claude Code に「半自動化までを最小手間で設計してほしい」と相談しながら、投稿文生成スクリプトを作るところまで進めた。本記事はその設計・実装フローの記録。

課題: 検索流入だけだと初動が弱すぎる#

このブログ（ゆるディープ）はAstro製で、Netlifyに自動デプロイされる構成になっている。記事を書いて git push するだけで公開される、運用としては楽な状態。

ただし流入経路はほぼ検索のみ。新しい記事を出してもGoogleにインデックスされるまで数日〜1週間かかり、その間は実質誰にも届かない。SNSアカウントは持っているが、毎回タイトルとURLと一言コメントを手で組み立てるのが地味に面倒で続かなかった。

リーチしたいのは機械学習界隈の人たちなのだが、絡み合いをしたいわけではなく、「流入経路を増やしてある状態」を作るだけで十分という温度感。だからこそ完全自動化に振り切るのも違和感があった。

完全自動化は割に合わない、と判断するまで#

最初はXとBluesky両方に自動投稿する方向を考えた。が、調べると思ったより制約が多かった。

X: 開発者アカウントの取得が必要。Free tierでも書き込みAPIは月500件まで使えるが、登録自体が一手間
Bluesky: AT Protocolで比較的素直に自動投稿できる。やるならここから
Threads: Meta APIが審査制で、個人ブログ規模では割に合わない

加えて、デプロイフックを使った自動化も筋が悪い。Netlifyのデプロイフックは「typo修正のpush」でも発火してしまうので、新記事公開と紐付けるトリガーとしては不適切。GitHub Actionsで src/content/posts/**/*.md の追加を検知する形が現実的だが、ここまで来ると最小手間ではない。

「投稿文の自動生成だけしてくれれば、コピペで投稿するくらいは別に苦じゃない」というところに落ち着いた。

ワークフロー: WANT.md → sns_plan.md → planモードで実装#

ここからがClaude Codeとの設計の話。今回のフローはこの3段になった。

1. WANT.md に雑に要望を書く#

ワークスペース直下に WANT.md というファイルを置いて、そこに「やりたいこと」を箇条書きで放り込む。最初は本当に雑でいい。

1
# 指示
2
## やりたいこと（原文）
3
X, Bluesky, ThreadsなどのSNSにブログ投稿後、Netlifyデプロイフックまたは記事投稿後フックなどでSNS宣伝施策を行ないたい。完全自動化でなくてもよく、その場合は、リンクと投稿だけ自動生成して、こちらで投稿するのもあり。
4
リーチしたいのはML界隈あたりではあるが、絡みたくはない。あくまで、流入経路は増やしてある状態にしたいだけ。

このまま Claude Code に渡して「詳細設計を一緒に詰めていきたい」と相談する。Claudeが質問を返してくるので、それに答えながら詳細設計を WANT.md 内に追記していく。

ここで詰めたのは:

トリガー設計（デプロイフックは使えない、GitHub Actionsで新記事検知）
各SNSのAPI難易度と自動化レベル（表形式で整理）
投稿文の仕様（タイトル / URL / 要約 / ハッシュタグ）
やらないこと（Mastodon、Qiita転載、メーリス、ショート動画…）

2. sns_plan.md に整理して切り出す#

WANT.mdが膨らんできたら、別ファイル（今回は sns_plan.md）に切り出して資料として整理する。すでに別件で hikkoshi_plan.md（ブログ移行検討）というドキュメントがあったので、そのフォーマットに揃えてもらう形で頼んだ。

1
# 概要 / 対象SNS / トリガー設計 / 投稿文の仕様 / 未決事項 / スコープ外 / TODO

整理が終わったら WANT.md は空にする。これで次のネタを詰める器ができる。

切り出しを別ファイルにする理由は、「考えている最中の場所」と「結論を残す場所」を分けたいから。WANT.mdを長文ドキュメント化していくと、いま何を相談しているのかが見えなくなる。

3. コンテクストを切って plan モードで実装依頼#

ここがポイント。sns_plan.md を作り終えたら、Claude Codeのコンテクストを一度切る（新しいセッションを開く）。

そして plan モードに入って sns_plan.md を渡し、「この計画を実装したい」と頼む。Claudeが:

既存コードの調査（package.jsonのスクリプト一覧、frontmatterの実態、URL生成ロジックなど）
実装方針の提案（どのファイルを作る・触るか、再利用できる既存資産の指摘）
スコープ確認の質問（出力先はファイルかclipboardか、要約はどこから取るか、など）

を順に進めてくれる。最終的にplanファイルが書かれて、ExitPlanMode で承認を求めてくる流れ。

コンテクストを切ったメリットは、設計フェーズでの長い議論ログがそのまま実装フェーズに引き継がれないこと。設計の結論だけが sns_plan.md に残っているので、Claudeはそこから素直に実装計画を組み直してくれる。設計フェーズで迷走した道筋が引き継がれて、実装中に「あれ、これさっき却下したのでは」みたいな揺れ戻しが起きにくくなる。

出来たもの: 記事Markdownから投稿文を生成するスクリプト#

実装したのはローカルスクリプト1本だけ。

1
cd yurudeep
2
pnpm sns-post src/content/posts/essay/2026/20260429.md

これで sns-posts/essay/2026/20260429.md に X / Bluesky 用の投稿文が書き出される。出力はこんな感じ。

1
---
2
post: src/content/posts/essay/2026/20260429.md
3
url: https://yurudeep.com/posts/essay/2026/20260429/
4
generated: 2026-04-30
5
---
6

7
# ホログラム開発を趣味で始めるのは現実的か？2026年4月時点で調べたら厳しかった
8

9
## X
10

11
ホログラム開発を趣味で始めるのは現実的か？2026年4月時点で調べたら厳しかった
12
人型AIをホログラムで表現したくて2025〜2026年の技術を調査したが、趣味レベルで始めるにはかなり厳しい
13
https://yurudeep.com/posts/essay/2026/20260429/
14
#エッセイ #ホログラム #3Dディスプレイ #個人開発 #ARグラス #調査
15

16
## Bluesky
17

18
（X と同内容）

中身は:

frontmatter から title、description、tags、category を抽出
本文先頭の :::tip[要約] ブロックの1番目の箇条書きを1行要約として使う（無ければdescriptionにフォールバック）
ファイルパスから slug（essay/2026/20260429）を導出してURL組み立て
カテゴリ別固定ハッシュタグ＋frontmatterのtagsをマージ

生成されたファイルはgitに残す。投稿後に「あの記事のSNS文どう書いたっけ」を後から見返せるのが地味にうれしい。

スクリプト本体は約120行のNodeスクリプト1本で、追加依存はゼロ。fs と path だけで動く。Astroの content collections 解析も使わず、frontmatter は正規表現でパースする素朴な実装にした（フォーマットが完全に揃っているからこれで十分）。

スコープを切ることで重さを避けた#

sns_plan.md には「今回やらないこと」も書いた。これが効いた。

Bluesky AT Protocol 経由の自動投稿（APIキー取得後に別タスク）
X API v2 経由の自動投稿（X開発者登録後に別タスク）
GitHub Actions による push 検知 → 自動生成
--latest フラグなど利便性向上

planモードで実装依頼する段階でも「ここはスコープ外、別タスクで扱う」と明示しておくことで、Claudeが過剰に作り込もうとするのを抑えられた。半自動から始めて、運用してみて足りないと感じた部分だけ後から自動化を足していけばいい。

振り返り: 「設計→整理→コンテクスト切る→実装」が効いた#

今回のフローで効いたのは、設計フェーズと実装フェーズでセッションを分けたこと。

これまで「相談しながら実装まで一気にやる」みたいな進め方をしていたが、長くなると:

設計中に出した没案がコンテクストに残って、実装中にうっすら影響を残す
設計の途中で実装の話が混ざって、両方が中途半端になる
後から見返すと「なぜこの実装になったか」が会話ログを掘らないとわからない

という問題があった。

sns_plan.md のような中間ドキュメントを書くことで「設計の結論」を一度ファイルに固定し、コンテクストを切って実装フェーズに移るのは、Claude Code に限らず人間とやるときも有効そうな進め方だなと感じた。

WANT.md は空のままワークスペースに残してある。次のネタを詰めるときも同じ流れでやれそう。

参考文献#

Claude Code 公式ドキュメント https://docs.claude.com/en/docs/claude-code/overview
Bluesky AT Protocol ドキュメント https://docs.bsky.app/
X Developer Platform https://developer.x.com/