ブログの記事を作るとき、本文以外にもやることがあります。前の記事を見直し、関連記事を探し、使わなかったネタを次の日へ残す。こうした周辺作業も、毎回の執筆についてきます。
そこで私のブログでは、Claude Codeに任せる手順を指示書にまとめ、Obsidianのデイリーノートに結果を集める運用にしています。今回は、9月17日の記事作成を例に、ネタ選択から下書き、確認、公開準備までのブログワークフローを紹介します。
## このガイドでわかること
– Claude Codeへ毎回説明する内容を、指示書にまとめる方法
– 下書きと関連記事、翌日のネタを一緒に用意する流れ
– 人が確認する場所と、記事の進み具合を管理する工夫
## 本編
### ステップ1：読む場所・書く場所・作業順を決める
私の運用では、Claude Code向けの指示を `CLAUDE.md` にまとめています。Markdown（見出しや箇条書きをテキストで書ける形式）のファイルで、「どのノートを読み、何を作り、どこへ保存するか」を記載しています。
公式ドキュメントでも、CLAUDE.mdはプロジェクトの指示や作業ルールを伝えるためのファイルと説明されています。ここで紹介する「テンプレート1」などの名前は、私が自分の作業手順につけた呼び名です。[Claude Code公式ドキュメント](https://code.claude.com/docs/en/memory)
ブログ作成で主に使う場所は、次の4つです。
| 場所 | 役割 |
|—|—|
| `CLAUDE.md` | Claude Codeへ伝える作業手順 |
| `Dailies/日付.md` | その日のネタ、下書き、記事本文、ステータス |
| `Research/` | 下書きに使う参考情報 |
| `Inbox/Blog_Internal_Links_ツール名.md` | 関連記事のタイトルやURLの一覧 |
例えば「関連記事を探して」だけでなく、「デイリーノートのツール名を読み、対応する一覧から候補を選び、内部リンク欄へ記入する」と書きます。参照元と保存先まで決めておくことで、依頼の内容を具体的にできます。
なお、指示書に手順を書くだけで、時刻やファイル更新を監視して処理が始まるわけではありません。今回紹介するのは、私が日付とネタを指定して依頼し、その指示に沿って作業を進める流れです。
### ステップ2：選んだネタから、下書きと周辺作業をまとめて進める
デイリーノートには「今日のネタ候補」と「本日選択したネタ」の欄があります。まず、何について書くかを自分で決めます。
今回選んだのは「Claude Codeの記事（ブログワークフローについて）」です。日付とネタを伝える依頼は、例えば次のようになります。
> 9月17日の下書きを、ネタ2の「Claude Codeの記事（ブログワークフローについて）」で作成してください。
この依頼で使う定型手順を、指示書では「テンプレート1」と呼んでいます。まとめて処理する内容は次の5つです。
| 処理 | デイリーノートに残す内容 |
|—|—|
| 前日の投稿済み記事を確認 | 追記・改善できる点の提案 |
| 選んだネタから下書きを作成 | 当日の下書き |
| ツール別の記事一覧を参照 | 関連記事のリンク候補 |
| 使わなかったネタを転記 | 翌日のネタ候補 |
| 未使用ネタが4つ以下なら補充 | 理由付きの新規ネタを加え、合計6つにする |
9月17日のノートにも、下書きだけでなく、前日記事のリライト提案と内部リンク候補が記入されました。未使用ネタは9月18日のノートへ引き継いでいます。
リライト提案は、その場で前日の記事を書き換えるものではありません。追記する価値があるかを後から判断できるよう、候補として残しています。
関連記事を探すときにも、小さな例外がありました。今回参照したClaude Code用の一覧には、まだ記事が登録されていませんでした。そのため、関連先として記載されているObsidian用の一覧から候補を選んでいます。
一覧が空でも、実在する別の記録から探せるようにしておく。今回の内部リンク提案は、その形になりました。デイリーノートを中心にした運用は、[Obsidianシリーズの関連記事](https://hiroro-ailab.com/obsidian-vol-10/)でも紹介しています。
### ステップ3：下書きを読み、方向を直してから公開準備へ進む
下書きができたら、自分で読みます。ここでは文章の言い回しだけでなく、「今回の記事で何を扱うか」を確認しています。
実際、今回の最初の下書きにはブログ以外の制作フローも含まれていたため、ブログワークフローだけに絞るよう修正を依頼しました。タイトルにも「Claude Code」と「ブログワークフロー」を入れるよう伝えています。
下書きの段階で記事の範囲を決めておくと、完成本文に何を残すかが明確になります。
私のブログ運用では、次の5段階で進み具合を記録します。
| ステータス | 状態 |
|—|—|
| 作業前 | ネタは決まっているが、まだ書き始めていない |
| 下書き | 内容を確認・修正する段階 |
| 確認済み | 下書きを確認し、仕上げへ進める段階 |
| 完成 | 記事本文や投稿用の情報がそろった段階 |
| 投稿済み | 公開・投稿が完了した段階 |
確認した下書きはCodexへ引き継ぎ、タイトル、パーマリンク（記事URLの末尾）、本文、ディスクリプション（記事の要約文）、X投稿文を用意する流れにしています。公開前には、内容やリンクを自分で確認します。
AIへ任せる作業と、自分が判断する作業を、このステータスで区切っています。5段階の管理については、[進捗管理を扱った関連記事](https://hiroro-ailab.com/obsidian-vol-12/)にもまとめています。
### 使って気づいた不便さは、ノートの構成にも反映する
9月16日のノートでは、記事のStatus欄が「記事の下書き・執筆」の中にありました。9月17日のノートでは、冒頭に「記事作成ステータス」を置き、そこを参照・更新する形に変えています。
長いノートの途中まで探さなくても、最初に記事の進み具合を確認できるようにするためです。
ただし、9月17日のノートには、本文の完成欄や下部の表にもステータスの表記が残っています。完全に1か所へ統一できたというより、「冒頭の欄を更新先にする」と決めて運用している状態です。
指示書もノートも、使いながら手直ししています。出力を確認して、紛らわしい場所や余計な内容があれば、その都度直す。この確認もワークフローの一部です。
### 公開後の情報は、次の記事を書くために残す
指示書には、公開後の記事から工夫を抽出して `Skills/` に残し、ツール別の記事一覧へタイトル・URL・投稿日・説明を追記する手順も書いています。
ここで「トリガー」と呼んでいるのは、公開済みになったことなどを、次の処理を行う条件として扱う運用ルールです。この記事では、常時監視や定時実行の動作を検証したものとしては扱っていません。
関連記事の一覧があれば、次の下書きを作る際の参照元になります。記事を書いて終わりにせず、その記録を次の執筆に使える形で残すことを意識しています。
## まとめ
今回のブログワークフローでは、Claude Codeに渡す指示に、作業順・参照元・保存先をまとめています。下書きに加えて、リライト提案、内部リンク候補、翌日のネタまで一緒に用意する流れです。
一方で、何を書くか、どこまで扱うか、公開できる内容かは自分で判断します。今回も「ブログワークフローに絞る」という修正を入れてから、仕上げに進みました。
時間削減の効果はまだ計測していません。現時点で紹介できるのは、依頼する手順と結果を残す場所を決め、下書きを読みながら運用を調整している実例です。
