ブログの下書きができても、公開するまでにはもう少し作業があります。本文を整え、タイトルとURLを決め、記事の要約やX投稿文、アイキャッチを用意する。私のブログでは、この仕上げをCodexに依頼しています。
前編では、[Claude Codeを使ったブログワークフロー](https://hiroro-ailab.com/claude-code-blog-workflow-1)を紹介しました。今回はその続きとして、確認した下書きを公開準備まで進める流れを、9月17日の作成記録を交えてまとめます。
## このガイドでわかること
– デイリーノートを使って下書きをCodexへ引き継ぐ方法
– 本文・投稿用情報・アイキャッチをまとめて用意する流れ
– 仕上げの段階で確認したい、数字・URL・表現のずれ
## 本編
### ステップ1：下書きと執筆ルールを、同じ作業場所で読んでもらう
私の運用では、Obsidianのデイリーノートに下書きを保存しています。確認した内容をCodexに読んでもらい、そのノートの「確認済み・完成後」欄へ仕上げた記事を書き込む形です。
下書きの確認や修正指示は人が行い、作業を進めてよいことを伝えます。9月17日は、記事の範囲をブログワークフローに絞り、タイトルのキーワードを指定したうえで、「9月17日の記事を作成してください」と依頼しました。
短い依頼でも作業を進められる背景には、対象の下書きと執筆ルールがファイルに残っていることがあります。
| 参照するもの | 伝える内容 |
|—|—|
| 当日のデイリーノート | 下書き、選んだテーマ、関連記事の候補 |
| `AGENTS.md` | 初心者向けの文体、実体験を重視する方針、保存先 |
| `Research/Permalink_Description_Rules.txt` | URLと記事要約の作成ルール |
| `Research/X_Posting_Rules.txt` | X投稿文の書き方 |
| `Research/X_Reply_Rules.txt` | 本文とURL入りリプライの組み立て方 |
AGENTS.mdは、Codexへプロジェクトの指示や背景を伝えるためのファイルです。公式ドキュメントでも、その役割が説明されています。[OpenAI公式：AGENTS.md](https://learn.chatgpt.com/docs/agent-configuration/agents-md)
このブログでは、Claude Codeが下書きを担当し、Codexが仕上げを担当する分担にしています。これは私が決めた運用です。引き継ぎに使うのは、デイリーノートに保存した内容と、その時点の修正指示です。
### ステップ2：本文を整え、投稿用の5点をそろえる
Codexにまとめて依頼しているのは、次の5点です。
| 作成するもの | 仕上げで確認すること |
|—|—|
| タイトル | 主要キーワードが入り、本文の内容と合っているか |
| パーマリンク | 記事URLの末尾として使う短い文字列 |
| 記事本文 | 下書きの推敲、根拠の確認、内部リンクの挿入 |
| ディスクリプション | 記事の内容を短く伝える要約文 |
| X投稿文 | 記事の要点を伝える本文と、URL入りのリプライ案 |
9月17日の記事でも、この5点を同じノートへ記入しました。記事本文と告知文を並べておくと、タイトルだけが大げさになっていないか、X投稿文で本文にない効果を言い切っていないかを見比べられます。
仕上げでは、文章を読みやすくするだけでなく、書いてあることと記録が合っているかも確認します。
9月17日の下書きには、月間20〜25時間の削減見込みがありました。しかし実測した数字ではなかったため、完成本文には採用しませんでした。また、指示書の「自動処理」という表現は、実際に依頼して進めた作業の流れが分かる説明へ直しました。
こうした修正を含めて、私のブログでは「仕上げ」としています。
### URLは、作成時の候補と公開後の記録を照合する
パーマリンクには、小文字の英数字とハイフンを使うルールにしています。長い日本語タイトルをそのまま入れず、テーマが分かる短い文字列にまとめます。
今回、前編へのリンクを確認すると、9月17日の完成欄にある候補は `claude-code-blog-workflow`、公開後のURL欄に記録されている末尾は `claude-code-blog-workflow-1` でした。
このため、本記事の前編リンクには公開後のURLを使っています。
公開準備で作った候補と、実際の公開先が一致するとは限りません。関連記事やXのリンクを用意するときは、公開後の記録を確認する必要があると分かる例です。
### 要約文の文字数は、ブログ側のルールとして確認する
ディスクリプションは、日本語120〜140文字を目安にしています。記事の主題と読んで分かることをまとめ、本文にない成果や効果を加えない方針です。9月17日の作成記録では、135文字に収まっていることを確認しました。
この文字数は、私のブログで決めている運用ルールです。Googleはメタディスクリプション自体に長さの上限を設けておらず、検索結果では端末の幅などに応じて表示を省略すると説明しています。また、検索内容によっては記事本文から説明文が作られます。[Google検索セントラル](https://developers.google.com/search/docs/appearance/snippet)
文字数をそろえることと、検索結果で全文が表示されることは別です。作成時は、まず記事を正確に要約できているかを確認します。
### X投稿文は、記事の要点を先に伝える
X投稿は「価値提供」「制作過程」「導線投稿」の観点で考えています。今回のような制作記録なら、何を任せ、どこを自分で確認したかを先に書くと、記事の内容を伝えやすくなります。
9月17日に用意した投稿案も、読むファイル・作業順・保存先を決めたことと、下書きの範囲を自分で確認したことを要点にしました。記事URLはリプライ用として別に用意しています。
ハッシュタグは0〜2個、AI生成画像を添える場合は「AI生成」と明記するのが、このブログの投稿ルールです。本文とURL入りリプライを分ける方法について、リーチが伸びるという効果までは検証していません。
### ステップ3：アイキャッチと保存先までそろえて、公開前に確認する
文章の5点に加えて、Codexの作業内で画像生成ツールを使い、ブログ用のアイキャッチも作成しています。
9月17日の画像は、「Claude Code」「ブログワークフロー」「下書きから公開準備まで」という文字と、ネタ・下書き・確認を表すカードを組み合わせた構成にしました。生成後には、文字が読めるか、記事のテーマと合っているかを確認しています。
画像はブログ用の専用フォルダへ保存し、ファイル名には日付とテーマを入れます。デイリーノートには画像の保存先、ファイル名、生成プロンプトも記録します。
本文だけでなく画像までそろえておくことで、公開時に使うものを確認できる状態にしています。
私の運用では、この段階を「完成」と呼びます。最後に人が、次の点を見てから公開します。
– 本文の体験談や数字が、実際の記録と合っているか
– タイトル・要約・X投稿文が、内容を誇張していないか
– URLが正しい公開先を指しているか
– アイキャッチの文字や構図に不自然な点がないか
公開が済んだら「投稿済み」に変更し、公開後のURLを記録します。この記録が、次の記事で関連記事を紹介するときの参照元になります。
## まとめ
私のブログワークフローでは、確認した下書きをCodexに渡し、本文・タイトル・URL候補・要約・X投稿文とアイキャッチを用意しています。結果はデイリーノートへまとめて保存します。
9月17日の仕上げでは、未計測の数字を省き、指示書の表現を実際の作業に合わせて直しました。今回の前編リンクでは、公開後のURLを確認して使っています。
下書きを読みやすい文章に整え、公開に使う情報がそろっているかを確かめる。これが、私がCodexに任せているブログ記事の仕上げです。
