記事公開パイプラインを Claude Code で作った話｜追加して、巻き戻した記録

注意: この記事で紹介する article-writer は、このブログ（my-blog）専用に作ったカスタムスキルです。Claude Code をインストールしただけでは使えません。「同じものを作りたい」場合は、記事末尾の「次は何をするか」セクションを参考にしてください。Claude Code の利用には月額費用（API従量課金）が発生します。

記事を1本公開するのに、何ステップあるか数えたことはあるだろうか。

僕が数えたら6つだった。

テーマを決めて、アウトラインを作って、原稿を書いて、サムネイルを作って、Draft 登録して、公開する。

それぞれに確認作業がある。 毎回、脳内でチェックリストを追いかけながら手を動かしていた。

実は、Claude Code はすでに使っていた。

アウトラインを考えるスキル、原稿を書くスキル、eyecatch を生成するスキル。 それぞれ別のスキルを、毎回自分で起動して使っていた。

ある日、ふと気づいた。

「それぞれのスキルを、親スキルの子スキルとしてつなげれば、全部まとめて動くんじゃないか。」

それが、article-writer というパイプラインを作り始めたきっかけだった。

---

手作業の何が問題だったか

問題は、手順の多さだけじゃない。

抜け漏れだった。

婚活記事は婚活スキルで、AI記事はAIスキルで書いていた。 それぞれのスキルで手順が微妙に違う。

婚活スキルで書いたときに正しかった手順が、AI記事に適用すると抜け漏れになることがあった。 「あれ、embedding 登録したっけ？」「この記事、eyecatch のテンプレートが違う。」

スキルが違えば、正解の手順も変わる。 それを毎回頭で管理しようとしていたのが、そもそもの問題だった。

---

Phase 1〜3 を作った

最初に作ったのは、テーマ受付から原稿保存まで。

「カテゴリ × タイプ」でプロファイルを決めるという設計にした。

婚活記事なら共感型のトーンで、AI実践記事なら実験ログ型で書く。 毎回ゼロから文体を考えなくていい。プロファイルを選べばトーンが決まる仕組みだ。

これを write-profiles という定義ファイルにまとめた。

tomoyasu-voice スキル（※1）は、インライン呼び出し（※2）で適用した。 別スキルを起動するのではなく、ルールを読み込んで原稿生成時に直接使う。

呼び出しは、Claude Code のチャットにテーマを投げるだけ。

「Claude Code で自動化した話を AI実践カテゴリで書いて」

---

Phase 4〜6 を作った

次に、Draft 登録・eyecatch 生成・公開までをつなげた。

ここで設計上の判断が1つあった。

Phase 5（eyecatch 生成）と Phase 6（公開）だけ、確認ポイントを「必須」にした。

eyecatch は Gemini API を呼ぶ有料操作。公開は外部に見えるようになる。 この2つだけは、自動でスキップできない確認を入れた。

それ以外の手順は --skip-review パラメータで省略できるようにした。 速く進みたい日は確認を飛ばせる。慎重に進みたい日はすべて確認する。

---

Phase 6 に embedding 生成を組み込んだ

パイプラインを動かし始めて、気づいたことがあった。

公開後に embedding 未登録の記事が2本あった。

公開はできていた。でも検索インデックスへの登録を忘れていた。

手順を追いかけていたつもりが、抜け漏れていた。

「だったら、公開と同時に embedding を生成する手順をパイプラインに入れればいい。」

Phase 6 の末尾に generate-embeddings.js の実行ステップを追加した。 これで、忘れる余地がなくなった。

人間が注意し続けることで防ごうとしていたけど、構造に組み込んだ方がずっと確実だった。

---

Phase 7 を追加して、1日で巻き戻した

note.com への送客を増やしたくて、記事公開後に note 投稿用の短文を自動生成する Phase 7 を実装した。

実装は完成した。

その後、4機の Explore エージェント（※3）を並列起動してレビューしたところ、高深刻度5件が検出された。

• note 送客効果が未検証なのに自動化していた
• SEO 重複コンテンツリスクがあった

Phase 7 は削除して、article-writer を Phase 1〜6 のクリーンな状態に戻した。

---

やってみてわかった4つのこと

1. 小さく作って、少しずつ拡張する

Phase 1〜3 を作ってから 4〜6 を足した。 最初から全体を設計しなかったから、途中の設計変更が安く済んだ。

2. 確認ポイントは減らしすぎない

有料API実行・公開操作は必ずユーザーが一度止まる設計にした。 全自動にするより、判断できる余白を残しておく方がいい。

3. レビューをプロセスに組み込む

実装完了後すぐにレビューエージェントを走らせると、自分では見えない穴が見える。 ひとりで作っていても、盲点を補える。

4. 自動化の前に、効果を測る

「便利そう」だけで自動化しない。 まず手動でやってみて、効果を確認してから自動化する。

---

次は何をするか

note 投稿は、まず手動で3本やってみる。

クリック数を見て、my-blog への送客が発生しているなら、そこで初めて自動化を考える。 Phase 7 の話は、そこから始まる。

「同じパイプラインを作りたい」場合の入口は次の3ステップだ。

1. Claude Code をインストールし、プロジェクトに CLAUDE.md を配置する（動作指示の起点になる）
2. .claude/skills/ ディレクトリを作り、スキル定義ファイル（SKILL.md）を1つ書く（テーマ受付→原稿生成だけの小さなスキルから始めるのがコツ）
3. スキル同士を呼び出す「オーケストレータ」を1つ書く（子スキルをまとめる親スキルがパイプラインの正体）

Claude Code の公式スタートガイドは claude.ai/code から確認できる。

---

あなたの作業フローにも、毎回同じ確認をしている場面があるかもしれない。

それが、パイプラインを作るサインになる。

---

関連記事

• 「やめる」を決めるための実験設計（Phase 7 を1日で巻き戻した判断の背景にある考え方）

---

※1 tomoyasu-voice スキル: このブログ筆者（ともやす）の文体・語り口を再現するカスタムプロンプト集。Claude Code に読み込ませることで、文体を統一した原稿を生成する。 ※2 インライン呼び出し: 別のスキルを独立起動するのではなく、ルール定義をプロンプトに直接埋め込んで適用する方式。呼び出しのオーバーヘッドがない。 ※3 Explore エージェント: Claude Code の並列実行モード。複数の検討軸を同時に走らせ、見落としをカバーする。