Codexでブログ更新を進める｜記事案から公開までの流れ

目次

AIに依頼することと、自分で確認すること

AIを使う前も、記事を公開するまでに必要な作業は同じです。題材を選び、文章や画像を作り、サイトに反映して、公開後の表示を確認します。

このうち、原案の作成や決まった形式への調整をAIに依頼すると、次のような分担になります。

工程	AIを使わずに進める作業	AIに依頼すること	自分で決める・確認すること
記事案	題材を選び、構成を考える	構成の候補を出す	今回書く内容を選ぶ
原稿	本文を書き、読み直す	原案を作り、修正する	経験や記録との一致、表現
サムネイル	画像を作る、または探す	候補画像を生成する	採用する画像、文字、見た目
サイトへの反映	ファイルを配置し、検査する	配置、検査、PR作成	差分、検査結果、実際の表示
公開	PRをマージし、表示を見る	指示後のマージと公開確認	公開する変更とタイミング

事実確認や公開の判断は、もともと必要だった仕事です。AIを使うことで新たに増えるのは、材料や条件を伝え、生成された内容に間違いや余計な変更がないかを確かめ、修正を依頼する作業です。

たとえば、文章としては自然でも、試していない設定が「確認済み」と書かれているかもしれません。記事だけを追加したつもりでも、サイト全体の設定が変わっているかもしれません。自分で入力する量が減る分、何ができたのかを読む時間は必要になります。

この記事では、文章や画像の相談にはChatGPTを、リポジトリ内のファイル操作や検証、PR作成にはCodexを使う流れを紹介します。画像生成やGitHub操作の可否は、使う環境や接続、権限によって変わります。原稿ができたこと、画像ファイルを保存できたこと、サイトへ反映できたことは、それぞれ確認します。

1. 書きたいことを短く伝える

最初から完成した構成を用意する必要はありません。自分が何を試し、何を伝えたいかを渡して、原案を作ってもらいます。

main保護の記事なら、次の情報が材料になります。

• GitHubでブログを1人で運営している
• 作業用のdevと公開用のmainを分けている
• 公開時はPRを使い、検査に成功してから反映する
• 1人運営に合わせて、必要なPR承認数を0人にした
• 実際に設定した内容を、同じように1人で運営する人へ紹介したい

「GitHubの使い方を書いて」よりも、自分の環境や判断を伝えた方が、書きたい内容に近づきます。設定画面や作業の記録があれば、それも原稿の材料になります。

依頼するときは、例えば次のように伝えます。

GitHubでブログを1人で運営しています。main保護の設定を紹介する記事の原案を作ってください。読者は、同じように1人でGitHubを使っている人です。添付した設定と作業記録を基に、不明な設定値や試していない結果は補わないでください。まず本文の原案を作るところまでお願いします。

この段階では、原稿を読んで、今回の記事にどこまで載せるかを決めます。ワークフローの実装まで説明すると長くなるなら、設定手順と実装の話を別の記事に分ける、といった判断は自分で行います。

2. 原案を読み、具体的に直してもらう

原案ができたら、まず自分の経験と食い違っていないかを読みます。特に、設定値や確認結果は、実際の記録と照らし合わせます。

main保護の記事なら、「PR承認0人」と「確認せずに公開できる」は同じ意味ではありません。第三者の承認を必須にしなくても、差分や検査結果は自分で確認します。このように、数字が合っているだけでなく、説明から受ける意味も確かめます。

そのうえで、説明の順番や言い回しを調整します。修正は「自然な文章にして」だけでなく、気になった箇所を示すと進めやすくなります。

冒頭は、私がこのブログにmain保護を設定した話から始めてください。一般的な説明が重複している段落は短くしてください。設定値と手順は変えず、実際に行っていない操作を体験談として追加しないでください。

全文を直してもらった後は、頼んだ箇所以外も読み直します。文章を短くした結果、必要な条件や注意点まで消えていないかを見るためです。

確認しておきたいのは、次の点です。

• 自分が試したことと、一般的な説明が区別されているか
• 設定値、日付、製品名、リンクが元の情報と合っているか
• やっていない操作や、測っていない効果が追加されていないか
• 読者が手順をたどるための前提や注意点が残っているか

AIに原案を作ってもらっても、自分の名前で公開する文章として読み直すところは残ります。

3. サムネイルはサイトの雰囲気も伝える

文章の方向性が固まったら、サムネイルを用意します。ここではChatGPTの画像生成機能などを使います。

main保護の記事では、ブランチの線や盾を使って、変更を確認してから公開するイメージを表せます。ただ、記事の題材が伝わることに加えて、ほかの記事と並べたときの雰囲気も見ておきたいところです。

画像を依頼するときは、テーマに加えて次の条件を伝えます。

• 記事一覧に合う縦横比
• サイトや既存サムネイルの配色、絵柄、余白
• 入れる文字と、その文字量
• スマートフォンでも伝わる構図
• 参考にしたいページや画像

例えば、次のような依頼です。

mainブランチ保護の記事用に、横長のサムネイルを作ってください。添付した既存記事の画像を参考に、配色と絵柄をそろえてください。ブランチの合流と盾で、変更を確認してから公開するイメージにしてください。文字を入れる場合は「1人でも mainを守る」とし、小さな表示でも読めるようにしてください。

生成した画像は、文字や構図を確認してから採用します。記事一覧と同じくらい小さく表示すると、細かい要素がつぶれていないかも分かります。

採用後は、画像を実ファイルとして保存し、容量、ファイル名、保存先、代替テキストを確認します。チャット上で画像が見えていても、リポジトリに保存され、記事から正しく参照されるまでは、サイト用の画像の準備は終わっていません。

4. 記事と画像を作業ブランチに追加する

原稿と画像が決まったら、Codexにリポジトリへの反映を依頼します。

私のブログでは、最新のdevから記事用の作業ブランチを作り、確認と検査を終えた変更をPRでdevへ集めます。公開するときは、devからmainへのPRを使います。

依頼にも、対象の原稿と画像、作業する場所、どこで止めるかを含めます。

この原稿と採用した画像をブログに追加してください。READMEと既存の記事を確認し、最新のdevから記事用の作業ブランチを作ってください。記事の形式と画像の保存場所を合わせ、検査を実行してください。dev宛てのPRを作成し、変更ファイルと検査結果を報告するところまでお願いします。

このブログでは、記事の本文に加えて、タイトル、説明文、日付、カテゴリ、タグ、要約、サムネイルのパスなどを指定します。公開記事と画像の保存場所は、次の形式です。

• 記事：_posts/YYYY/MM/YYYY-MM-DD-slug.md
• 画像：assets/images/blog/YYYY-MM-DD-short-slug/thumbnail.png

公開日は実際に公開する日時に合わせます。テンプレートの日付をそのまま使うと、意図した日に記事が出ない原因になります。

PRができたら、記事と画像だけでなく、変更ファイルの一覧も確認します。今回の記事と関係のない設定や、ほかの記事が混ざっていないかを見るためです。確認を終えた変更をdevへ反映します。

また、私のリポジトリは公開されています。作業ブランチや_drafts内のファイルも、GitHub上では閲覧可能です。 サイトにまだ載っていないからといって、非公開のメモを置く場所にはできません。

5. 検査結果と差分を見てから公開を決める

このブログでは、公開前にGitHub Actionsで次の検査を行います。

• Publication source：main宛てのPRが、同じリポジトリのdevから作られているか
• Jekyll build and content：記事の必須項目や日付、カテゴリ、タグ、サムネイルの存在を確認し、Jekyllでビルドできるか

検査に成功しても、本文の意味や画像の見た目まで保証されるわけではありません。リンク先が意図したページか、スマートフォン幅で読めるか、といった点は別に確認します。プレビューを開けなかった場合は、表示確認が残っていることも分かるようにします。

公開用のPRでは、devとmainの差分全体を見ます。devに複数の記事や変更が入っていれば、それらもまとめて公開されるためです。このブログでは、1記事ずつ公開し、記事追加とサイト構成の変更を同じ公開に混ぜない運用にしています。

確認済みの変更がそろったら、次のように公開を指示します。

musashistudio.comのブログについて、確認済みの変更を含むdevブランチをmainにマージして、公開して。

実行前にdevとmainの差分を確認し、未確認の変更が含まれる場合や、公開前チェックに失敗した場合は停止して報告してください。問題がなければPRをマージし、GitHub Pagesの公開処理と公開ページの表示を確認して、公開URLを報告してください。

これは、このブログで使っている公開指示の例です。PRのチェックが成功しただけでは公開せず、私が差分を確認して指示することを条件にしています。公開指示の後で変更が加わり、対象のコミットや差分が変わった場合も、改めて確認します。

マージ後は、該当コミットのGitHub Pagesの処理が成功したことに加え、実際の記事ページを開きます。本文、サムネイル、リンク、記事一覧を確認して、今回の更新を終えます。処理が失敗していたり、公開ページを確認できていなかったりする場合は、その工程が残っています。

次回の更新にも使える形にする

記事ファイルの形式、画像の保存場所、ブランチの使い方、公開前の検査は、リポジトリのREADMEにまとめています。次回も同じ文書を確認してもらい、題材と今回固有の条件を渡して進めます。

AIに依頼できる工程が増えても、記事にしたい経験や、読者へ伝えたいことを選ぶのは自分です。生成された文章と画像を確かめ、今回の変更を公開してよいかを決める作業も残ります。

原案づくりやファイルの配置を任せながら、自分が確認する場所を決めておく。この流れで更新を重ね、修正が多かった部分から依頼文や手順を見直していきます。