何を作ったのか

今回作ったのは、Codexに渡した内容からHTML形式のnote記事を作成し、レビューを通して公開ブログへ反映するための仕組みだ。

ポイントは、公開ブログ本体に直接記事を追加しないこと。記事生成の入口を別に用意して、そこにCodexがHTMLを追加する。公開ブログ側は、そのHTMLを静的ファイルとして受け取り、ホスティングと導線だけを担当する。

記事化のトリガーを明確にする

すべての質問を記事化すると、公開したくない相談や一時的なメモまで混ざってしまう。そこで、記事化する条件を明確にした。

• /blog で始まる入力は記事化する。
• 通常の質問は、まず回答する。
• 回答後に記事化するか確認し、明確に承認された場合だけ記事を作る。

このルールにより、Codexを日常的な相談相手として使いながら、公開用の記事生成だけを意図的に切り出せる。

MarkdownではなくHTMLで管理する

今回のnote記事はMarkdownではなくHTMLとして作成する。理由は、図解やレイアウトを記事内に閉じ込めやすく、公開ブログ側でそのまま静的ファイルとして配信しやすいからだ。

記事ファイルの先頭には、タイトル、タグ、日付、slug、公開状態をHTMLコメントとして持たせる。公開ブログ側の同期処理は、このメタデータを使って一覧ページや導線を作れる。

責務を分ける

この仕組みでは、Codex、記事管理、公開ブログ、レビューの責務を分ける。分けておくと、AI生成記事のルールを強めても、公開ブログ本体の実装を壊しにくい。

公開ブログ側で必要なもの

記事管理側にHTMLを追加するだけでは、公開ブログ上で自然に読める状態にはならない。公開ブログ側には、最低限次の設定が必要になる。

1. HTMLの同期先を決める。まずは public/note/ 配下に置くのが扱いやすい。
2. 記事管理側からの通知を受けるGitHub Actionsを用意する。
3. 同期されたHTMLからnote一覧へ辿れる導線を作る。
4. 必要に応じてRSSやsitemapに含める。

最初は、HTMLを静的配信して一覧ページを作るだけで十分だ。既存の通常記事とは別枠のnoteとして扱えば、既存テーマへの影響を小さくできる。

記事作成時のチェック

公開前提の記事をAIに作らせる以上、内容の安全性を作業手順に含める必要がある。

• /blog で明示された内容だけを記事化する。
• 会社内部情報、内部URL、顧客名、個人名、認証情報を含めない。
• 個別事情は一般化して書く。
• 推測は推測として書く。
• 記事にはHTML/CSSの図解を含める。
• 公開してよい内容だけPRをmergeする。

まとめ

今回の仕組みは、Codexを単なる回答生成ではなく、記事作成とPR作成の入口として使うためのものだ。

質問、記事生成、レビュー、同期、公開の責務を分けることで、AI生成記事を扱いやすくしつつ、公開前の判断もPRレビューに集約できる。今後は、公開ブログ側のHTMLホスティング、note一覧、同期PRの自動作成を整えると、日常の整理をそのまま記事として残しやすくなる。