Codex Automationsの設定方法：ブログ運用を毎日7:00と12:00に回すまでの記録

AI・SE仕事術

Codex Automationsの設定方法：ブログ運用を毎日7:00と12:00に回すまでの記録

「オートメーションはどこで定義しているの？」

Codexでブログ運用の自動化を作っている途中で、この疑問が出てきました。これはかなり大事な問いです。なぜなら、AIに毎日作業してもらう仕組みを作るとき、どこに設定があり、何がリポジトリに残り、何がCodexアプリ側に保存されるのかを理解していないと、後から運用が不安定になるからです。

半農エンジニアラボでは、WordPressブログをCodexで半自動運用するために、毎日7:00にWeb調査と記事案作成、12:00に本文作成とWordPress下書き保存を行う仕組みを作りました。ただし、公開はしません。予約投稿もしません。X投稿もしません。WordPressには必ずdraftで保存し、人間が確認してから公開する運用です。

この記事では、Codex Automationsを使ってブログ運用を自動化する設定方法を、実際の半農エンジニアラボの例をもとに整理します。公式ドキュメントの説明だけでなく、「リポジトリ側には何を置くのか」「Codexアプリ側には何が登録されるのか」「失敗しないためにどこまでルール化するのか」まで、実験ログとして書いていきます。

結論：オートメーション本体はCodexアプリ側、運用ルールはリポジトリ側

最初に結論です。Codex Automationsの本体は、このリポジトリの中にファイルとして保存されるわけではありません。実行時刻、対象フォルダ、実行プロンプト、使用モデル、状態などは、Codexアプリ側のオートメーション設定として登録されます。

一方で、リポジトリ側には、Codexが作業するときに読む前提資料や、WordPress下書き保存スクリプト、記事テンプレート、ログ、調査メモなどを置きます。

つまり、役割分担はこうです。

Codexアプリ側
- 実行時刻
- 対象フォルダ
- 実行プロンプト
- 使用モデル
- 有効/停止状態

リポジトリ側
- AGENTS.md
- docs配下の運用ルール
- WordPress保存スクリプト
- 記事テンプレート
- 調査メモ
- 実行ログ
- 下書き本文バックアップ

この分担を理解しておくと、「チャットが変わっても前提が崩れない」運用に近づけます。Codexアプリ側のオートメーションは作業の起動装置であり、リポジトリ側の資料は作業のルールブックです。

Codex Automationsとは何か

Codex Automationsは、Codexに定期的な作業をバックグラウンドで実行させる機能です。公式マニュアルでは、繰り返しタスクを自動化し、結果をTriageという確認用の受け皿に出す仕組みとして説明されています。

プロジェクトに紐づく自動化の場合、ローカルのCodexアプリが動いていること、対象プロジェクトがディスク上に存在していることが必要です。これは地味ですが重要です。完全な外部サーバー常駐のcronとは違い、ローカルのCodexアプリとプロジェクトフォルダが前提になります。

また、Gitリポジトリでは、ローカルプロジェクトで直接実行するか、別のworktreeで実行するかを選べます。worktreeを使うと、未完了のローカル作業と自動化の変更を分離できます。一方で、今回の半農エンジニアラボでは、調査メモや下書きファイルをこのリポジトリに直接積み上げたいので、ローカルプロジェクトで実行する形にしました。

公式マニュアルでは、自動化をスケジュールする前に、通常のスレッドでプロンプトを手動テストすることも推奨されています。実際、これはかなり大切でした。いきなり毎日実行するのではなく、まず7:00タスクと12:00タスクを手動で流し、WordPress下書き保存、REST APIのタイムアウト、参考URLの扱い、ログの残し方を確認してから自動化しました。

半農エンジニアラボで作った自動化

今回作った自動化は2つです。

  • 毎日7:00：半農エンジニアラボ 7:00 調査
  • 毎日12:00：半農エンジニアラボ 12:00 執筆・下書き

7:00の自動化では、WordPress投稿はしません。X投稿もしません。AGENTS.mdとdocs配下の前提資料を読み、Web調査を行い、記事案を3つ作成します。それぞれの記事案について、タイトル案、狙う検索キーワード、読者の悩み、想定読者、構成案、参考URL、収益化導線、独自体験を入れられるポイント、注意点、優先度を整理します。

12:00の自動化では、7:00の調査メモを読み、優先記事案をもとに本文を作ります。本文は原則5000字以上。HTML形式でdraftsフォルダに保存し、X投稿文案も3パターン作ります。その後、チェックを通してからWordPressへdraftで下書き保存します。

ここで大事なのは、12:00でも公開しないことです。WordPressに保存するのは下書きまで。投稿ステータスは必ずdraft。X投稿も文案まで。公開やSNS投稿は、人間が確認してから行います。

設定前にリポジトリへ用意したもの

Codex Automationsを作る前に、リポジトリ側にはいくつかの前提資料を用意しました。

  • AGENTS.md
  • docs/project-brief.md
  • docs/content-policy.md
  • docs/wordpress-policy.md
  • docs/x-post-policy.md
  • docs/runtime-rules.md
  • docs/wordpress-rest-api-save-flow.md

AGENTS.mdには、Codexが作業前に必ず読むべきルールを置いています。ブログ名、テーマ、カテゴリ、公開しないこと、秘密情報を直書きしないこと、WordPressはdraft保存までにすることなどです。

docs配下には、詳しい運用ルールを分けています。記事作成ルール、WordPress運用ルール、X投稿文案ルール、REST API保存フローなどです。これにより、チャットが変わっても「前提はどこだっけ？」となりにくくなります。

特に重要だったのが、WordPress REST API保存フローです。最初は、タイトル、長文本文、カテゴリ、タグ、抜粋を一括でPOSTしていました。しかし、長文記事ではタイムアウトしやすいことが分かりました。そこで、短いdraft作成、長文本文更新、タグと抜粋の更新、最後にGET確認、という分割保存方式にしました。

7:00調査タスクのプロンプト設計

7:00タスクのプロンプトでは、やることとやらないことをはっきり分けます。

やることは、前提資料の確認、Web調査、記事案3つの作成、優先記事案の選定、researchフォルダへの保存、logsへの要約追記です。

やらないことは、WordPress投稿、X投稿、本文作成です。7:00は調査だけに絞ります。ここで本文まで書かせると、毎回の負荷が大きくなり、Codexの使用量も増えます。さらに、朝の時点で選んだテーマが本当に良いかを見直す余白もなくなります。

半農エンジニアラボでは、7:00を「種まき」の時間と考えています。今日の記事の候補を見つける。3つ並べる。どれがブログの軸に合うか考える。ここまでで止める。農作業と同じで、毎日いきなり収穫しようとしないのが続けるコツです。

12:00執筆タスクのプロンプト設計

12:00タスクでは、7:00の調査メモを使って優先記事を本文化します。

このプロンプトには、必ず以下を入れました。

  • AGENTS.mdとdocs配下のルールを読む
  • 今日のresearchとlogsを確認する
  • 優先記事案をもとに追加Web調査する
  • 5000字以上のHTML本文をdraftsに保存する
  • X投稿文案3パターンを作る
  • アイキャッチは案までにする
  • scripts/check-article.ps1でチェックする
  • scripts/save-wp-draft.ps1でWordPressへdraft保存する
  • 保存後にGETで確認する
  • 失敗時は繰り返し投稿せず停止する

12:00タスクは、ブログ運用の中で一番重い処理です。だからこそ、プロンプトには安全ルールを多めに入れています。特に「保存失敗や確認不能の場合は繰り返し投稿せず停止する」は重要です。タイムアウト時に同じPOSTを何度も繰り返すと、下書きが重複する可能性があります。

モデルとコストの考え方

今回、7:00と12:00では使うモデルを分けました。

7:00の調査タスクは、軽めのモデルを使います。記事案作成が中心で、本文生成まではしないためです。12:00の執筆タスクは、本文品質が必要なので、少し強めのモデルを使います。

この分け方は、コストを抑えるうえでかなり大事です。毎回すべてを強いモデルで処理すると、使用量が増えます。一方で、本文の品質が必要なところまで軽くしすぎると、後から人間の修正負担が増えます。

つまり、調査と選定は軽く、本文と下書き保存はしっかり。これが今のところの現実的なバランスです。

オートメーション作成時に決めた項目

Codexアプリ側のオートメーションには、主に以下の情報が登録されます。

  • 名前
  • 実行時刻
  • 対象フォルダ
  • 実行プロンプト
  • 実行環境
  • 使用モデル
  • 推論の強さ
  • 有効/停止状態

今回の設定では、対象フォルダは半農エンジニアラボのリポジトリです。実行環境はlocalにしました。これは、自動化がこのローカルフォルダを直接読み書きするという意味です。

Gitリポジトリの場合はworktreeで分離する選択もあります。未完了のローカル作業と自動化の変更を分けたい場合はworktreeが便利です。ただ、今回のブログ運用では、research、drafts、logsを日々同じ場所に積み上げたいので、local実行にしています。

リポジトリに残るもの、残らないもの

ここが、この記事の最初の疑問に戻るポイントです。

オートメーションのスケジュール本体は、リポジトリには残りません。Codexアプリ側に登録されます。なので、Gitでこのリポジトリを見ても、毎日7:00に動く設定そのものは見えません。

一方で、オートメーションが実行した成果物はリポジトリに残ります。たとえば、7:00ならresearchフォルダに調査メモが作られ、logsに要約が追記されます。12:00ならdraftsに本文とX投稿文案が作られ、WordPress下書き保存の結果がlogsに残ります。

さらに、オートメーションが参照するルールはリポジトリに残ります。AGENTS.mdやdocs配下の資料です。この設計にしておくと、「設定はアプリ側、ルールと成果物はリポジトリ側」と整理できます。

PCとCodexアプリの状態に注意する

Codex Automationsは便利ですが、ローカルプロジェクトの自動化には条件があります。

プロジェクトスコープの自動化では、対象マシンが起動していて、ローカルのCodexアプリが動いており、選択したプロジェクトがディスク上に存在している必要があります。PCがスリープしている、Codexアプリが起動していない、リポジトリの場所が変わっている、ネット接続がない、といった場合は、うまく動かない可能性があります。

ここは、普通の外部サーバーcronとは違うところです。個人ブログの半自動運用としては十分便利ですが、「完全に放置しても必ず動く外部サービス」ではないと理解しておく必要があります。

秘密情報はリポジトリに書かない

WordPress REST APIを使う場合、Application Passwordなどの秘密情報が必要になります。ただし、これをリポジトリに直書きしてはいけません。

半農エンジニアラボでは、WP_BASE_URL、WP_USERNAME、WP_APP_PASSWORDなどを.envまたは環境変数で扱う前提にしています。.envは.gitignoreに含め、Git管理しません。

これは地味ですが、ブログ自動化ではかなり重要です。記事本文やプロンプトよりも、認証情報の扱いを間違えるほうが危険です。Codexに作業させるときも、秘密情報の値を表示させない、ログに残さない、docsに書かない、というルールを徹底します。

WordPressはdraft保存までにする

今回の自動化で一番大事な安全線は、WordPressはdraft保存までにすることです。

AIが毎日記事を書けるようになると、つい公開まで自動化したくなります。しかし、半農エンジニアラボではそこまで進めません。理由は、記事には人間の確認が必要だからです。

特にこのブログは、SE、理学療法士、農という複数領域を扱います。デスクワーカーの身体ケアでは医療的な断定を避ける必要があります。家庭菜園や農薬では公式情報やラベル確認が必要です。フリーランス生活や税金では個別判断を断定してはいけません。

だから、AIは下書きまで。公開は人間が読む。これは今後も守るべきルールです。

最初に手動デモをする理由

公式マニュアルでも、自動化をスケジュールする前に通常スレッドでプロンプトをテストすることが勧められています。実際にやってみると、この意味がよく分かりました。

半農エンジニアラボでも、最初に手動で7:00タスクと12:00タスクを流しました。その結果、WordPress REST APIの接続はできるものの、長文記事を一括保存するとタイムアウトしやすいことが分かりました。そこで、保存スクリプトを分割方式に直しました。

もし手動デモをせず、いきなり毎日12:00の自動化を開始していたら、初回から保存失敗していた可能性があります。自動化は、動かす前の小さな実験がとても大事です。

設定後に確認すること

オートメーションを作ったら、あとは待てば動く状態になります。ただし、最初の数回は必ず結果を確認します。

  • 7:00にresearchファイルが作られたか
  • logsに要約が追記されたか
  • 記事案がブログ方針に合っているか
  • 12:00にdraftsへ本文が作られたか
  • WordPress下書きがdraftで保存されたか
  • 公開や予約投稿になっていないか
  • X投稿が実行されていないか
  • Codexの使用量が想定内か

特に最初の1週間は、毎回結果を見るくらいでよいと思います。自動化は作った瞬間が完成ではなく、運用しながら調整していくものです。

半農エンジニアラボでの実際の設定

今回、半農エンジニアラボでは2つのオートメーションを登録しました。

1つ目は、毎日7:00の調査タスクです。これは軽めのモデルを使い、Web調査と記事案作成だけを行います。WordPress投稿はしません。

2つ目は、毎日12:00の執筆・下書きタスクです。これは本文品質が必要なので、7:00より強めのモデルを使います。朝の調査メモをもとに、優先記事を本文化し、チェックを通したうえでWordPressにdraft保存します。

この2つを作ったことで、毎日の流れはかなり見えやすくなりました。朝は調査、昼は下書き。人間は夜や空いた時間に確認して、公開するかどうかを判断する。これは、フリーランスSEとして働きながらブログを育てるには、かなり現実的な形です。

まとめ

Codex Automationsの設定では、オートメーション本体はCodexアプリ側に登録されます。リポジトリ側には、AGENTS.md、docs配下の前提資料、スクリプト、テンプレート、調査メモ、ログなどを置きます。

ブログ運用で大事なのは、ただ自動化することではありません。何を任せるか、どこで止めるか、どこを人間が確認するかを決めることです。

半農エンジニアラボでは、毎日7:00に調査、12:00に下書き保存という形にしました。WordPressはdraftまで。公開しない。予約投稿しない。X投稿しない。秘密情報は.envまたは環境変数で扱う。保存は分割方式にする。

このくらいルールを固めておくと、Codex Automationsはかなり頼れるブログ運用の相棒になります。完全放置ではなく、人間が確認しながら育てる半自動運用。今の段階では、このくらいの距離感がちょうどよさそうです。

参考URL

  • OpenAI Developers: Codex Automations – https://developers.openai.com/codex/app/automations
  • WordPress REST API Handbook: Posts – https://developer.wordpress.org/rest-api/reference/posts/