Codex Automationsでコンテンツ運用を毎日回す：Claude Codeとの分担

「毎朝アクセス見て、ネタ決めて、記事直して、公開前に確認して」——この一連を、僕はしばらく手でやっていました。1日30分。たいした時間じゃない、と思っていたんです。

でも、忙しい日は飛ばす。飛ばすと数字を見ないまま記事を増やす。気づけば、PVはあるのにクリックされないページが10本くらい溜まっていました。

そこでCodexの自動化（Automations）に、この「毎日の見回り」を任せることにしました。最初に言っておくと、Codexは記事を量産する道具としてはおすすめしません。向いているのは、同じ手順を毎日きっちり再実行することです。今日はその使いどころと、Claude Codeとの分担を、僕の実例で書きます。

この記事の要点

• Codex Automationsは「記事を書かせる」より「毎日の運用手順を再実行させる」のが得意。アクセス確認→1ページ選定→記事QA→CTA改善→公開確認のループに向く。
• 自動化は下書き・調査・QA・確認に強い。公開判断は人間が1か所だけゲートを残す。
• Codexには2種類ある（Thread Automations / Standalone Automations）。コンテンツ運用の定例にはStandaloneが合う。最新仕様・料金は変わるので必ずOpenAI公式で確認。
• Claude CodeとCodexは敵じゃない。狭く調べる・繰り返すはCodex、リポジトリで深く直すはClaude Code、と分けると事故が減る。
• 量を増やす前に「今日はどのページのどの摩擦を減らすか」を1つ決める。判断軸はPVではなく収益導線。

Codex Automationsって、要するに何をしてくれる？

Codex Automationsは、Codexに「決まった時刻に戻ってきて、この手順をやって」と頼める仕組みです。人間が「ねえ今日の数字どう？」と聞きにいかなくても、向こうから結果を持ってきてくれる。これだけです。

OpenAI公式ドキュメントによると、Automationsには2種類あります。

• Thread Automations: いまの会話（スレッド）にひもづく、心臓の鼓動みたいな定期的な「起こし」。同じ文脈を保ったまま、数分おき・毎日・毎週で戻ってくる。長く走るコマンドの監視や、外部の更新ポーリングに向きます。
• Standalone Automations: スケジュールで毎回まっさらに走って、結果をTriage（処理待ち一覧）に出す。1回ごとが独立していて、複数プロジェクトをまたげる。間隔指定のほか、cron構文も使えます。

公式には、毎日のissueトリアージ、CI失敗の要約、リリースブリーフの作成、バグの自動チェックといった「繰り返すけど大事な雑務」の例が挙がっています。コンテンツ運用の定例は、まさにこの仲間です。

1つ注意。プロジェクトにひもづくローカルの自動化は、そのPCが起きていて、Codexが動いていて、対象プロジェクトがディスクにあるときに走ります。ノートPCを閉じて出かけたら、その回はスキップされる、ということです。クラウドで常時走らせたい話とは別なので、ここは公式の最新状況を見てください。

ちなみに、よく混同される「ChatGPT Tasks」は別物です。あれはChatGPT側で時刻指定のプロンプトを実行する機能で、リポジトリの中で作業を進めるCodexとは守備範囲が違います。混ぜて理解すると運用設計を間違えるので、分けて考えます。

なぜ「量産」ではなく「運用の再実行」なのか

ここが一番伝えたいところです。

AIに毎日記事を書かせると、最初は気持ちいい。本数が増えるから。でも中身は、薄い記事・似たネタ・弱いCTAが積み上がります。CTAというのは call to action の略で、「無料PDFはこちら」「相談はこちら」みたいな、読者の次の一歩を促すボタンや文言のことです。

PVは需要の入口でしかありません。読まれても、次の行動が決まらなければ収益にはならない。AdSenseや教材販売を考えるなら、増やすべきは本数ではなく「読者の次の行動が自然に決まるページ」です。

だから僕は、Codexに書かせるのをやめました。代わりに、こう頼んでいます。

「毎日、数字を見て、直す価値のあるページを1つ選んで、品質と導線を上げて、公開側で確認して、結果を報告して」

書くのは僕（か、別の場面でClaude Code）。Codexは見回りと再実行の係。役割をこう割ると、急に安定しました。

毎日の判断軸はPVじゃない：収益導線で見る

「今日は何を書くか」と考えると、つい新規記事に手が伸びます。でも問いを変えるんです。「今日はどのページの、どの摩擦を減らすか」。

僕がClaudeCodeLabで使っている読み替え表がこれです。Codexの判断基準にそのまま渡しています。

読者のシグナル	起きていること	やること
PVは多いが登録が弱い	検索意図はあるのに導線が弱い	導入文と無料PDFのCTAを直す
滞在は長いがクリックが少ない	読まれているが次の一歩が曖昧	商品比較や関連記事への橋を置く
比較記事に流入している	購入前の検討が始まっている	教材一覧や設定ガイドへつなぐ
初心者記事に流入している	まず安心したい読者が多い	無料PDFを先に出して信頼を作る
研修ページを見ている	自力導入に不安がある	相談対象・成果物・対象外を明確に

この表を渡すだけで、「とりあえず1本書く」という弱い運用から離れられます。計測の作り方はClaude Codeでアクセス解析を実装する手順に書いたので、まだ数字が取れていない人はそちらから。

Claude CodeとCodex、どっちに何を任せる？

「結局どっち使えばいいの」とよく聞かれます。僕の答えは「両方。場面で分ける」です。

ざっくりした使い分けがこれ。

場面	向いているほう	理由
毎日同じ手順を再実行	Codex Automations	スケジュール実行が標準で入っている
1ファイルを狭く調べる・直す	Codex	軽く呼んでサッと返ってくる
リポジトリ全体を深く改修	Claude Code	文脈保持と道具立てが厚い
厳しめの記事QA・品質ゲート	Claude Code	プロジェクト規約を覚えさせやすい
公開判断	人間	ここは自動化しない

どちらも「AIに作業そのものを任せる」点は同じです。だから危険な操作（削除・本番DB・課金・force push）は、最初はどちらでも全部「人間に聞く」に倒します。安全だと分かった操作だけ、あとから自動に格上げする。この順番は両ツール共通の鉄則です。詳しい併用の作業分担はClaude CodeとCodexの使い分けと併用にまとめました。

Codexに渡す日次プロンプト（コピペ可）

まずは短く、でも曖昧さゼロで。作業範囲・収益の優先順位・公開確認・人間レビューを必ず書きます。これをStandalone Automationの本文として登録します。

ClaudeCodeLabの日次コンテンツ運用を実行して。

ゴールの優先順位:
1. 無料PDF登録
2. Gumroad商品のクリック/購入
3. 導入相談

ルール:
- 自分の担当外の変更には触らない
- ビルドと記事チェックが通るまでデプロイしない
- 料金・API・対応プラットフォーム・セキュリティは公式で確認する
- 新規の薄い記事より、検索意図の強い既存ページの改善を優先
- 公開/コミットの前に人間レビューを1か所だけ残す

手順:
1. git status を確認
2. 認証情報があれば7日間のアクセスレポートを実行
3. 収益にレバレッジのあるページ/CTAを1つ選ぶ
4. 実例・落とし穴・内部リンク・次の一歩を足して改善
5. ローカルの記事チェックとサイトビルドを実行
6. 公開URL（またはプレビュー）をモバイル幅で確認
7. 変更点・見るべきKPI・人間が確認すべき点を報告

「公式で確認」とだけ書くのでは足りません。何が変わりやすいかを具体的に名指しします。料金、API、対応プラットフォーム、セキュリティ。今回ならCodex AutomationsとChatGPT Tasksの違いは公式リンクを見て、混ぜて書かせない。

人間レビューも明示します。自動化は下書き・調査・QA・確認には強い。でも公開判断まで丸投げすると、古い料金や強すぎる売り文句が残ります。僕の実感だと、最後に「この読者に本当に役立つか」「売り込みが先に立っていないか」を見るだけで、記事の信頼感はぜんぜん違います。

コピペで動く：公開前の品質ゲート

ここが事故防止の心臓部です。Codexが「直しました」と言っても、鵜呑みにしません。機械でわかる門番を最後に通します。

下のスクリプトは、対象ファイル1本を受け取って、(1) コードフェンスが偶数か、(2) 本文が規定字数あるか、(3) 内部リンクが2本以上あるか、を機械的にチェックします。1つでも落ちたら終了コード1で止まる。Codexの自動化に、ビルドの前段としてこれを噛ませています。Node.js（v18+）だけで動きます。

// quality-gate.mjs — 記事1本を機械チェックする門番
// 使い方: node quality-gate.mjs path/to/article.mdx
import { readFile } from "node:fs/promises";

const file = process.argv[2];
if (!file) {
  console.error("使い方: node quality-gate.mjs <記事ファイル>");
  process.exit(1);
}

const raw = await readFile(file, "utf8");

// frontmatter（先頭の --- 〜 ---）を本文から外す
const body = raw.replace(/^---\n[\s\S]*?\n---\n/, "");

const problems = [];

// コードフェンス記号（バッククォート3つ）を変数で組み立てる
const fence = "`".repeat(3);
const fenceRe = new RegExp(fence, "g");

// 1. コードフェンスは必ず偶数（開いて閉じる）
const fences = (body.match(fenceRe) || []).length;
if (fences % 2 !== 0) {
  problems.push(`コードフェンスが奇数(${fences}個)。閉じ忘れの可能性。`);
}

// 2. コードブロックを除いた本文の字数（空白・改行は除外）
const blockRe = new RegExp(fence + "[\\s\\S]*?" + fence, "g");
const prose = body.replace(blockRe, "");
const charCount = prose.replace(/\s/g, "").length;
if (charCount < 3800) {
  problems.push(`本文が薄い(${charCount}字)。3800字以上にする。`);
}

// 3. /blog/ への内部リンクが2本以上あるか
const internalLinks = (body.match(/\]\(\/blog\/[^)]+\)/g) || []).length;
if (internalLinks < 2) {
  problems.push(`内部リンクが${internalLinks}本。2本以上にする。`);
}

if (problems.length > 0) {
  console.error(`NG: ${file}`);
  for (const p of problems) console.error(`  - ${p}`);
  process.exit(1); // ここで止まる → ビルド/公開に進ませない
}

console.log(`OK: ${file}（本文${charCount}字 / 内部リンク${internalLinks}本）`);

実行はこれだけ。

node quality-gate.mjs site/src/content/blog/codex-automations-ai-content-ops.mdx

たった数十行ですが、薄い記事・閉じ忘れ・リンク不足が公開前に弾けます。エラーメッセージに「何が・どうダメで・どうすべきか」まで書いているのがポイント。これがあると、Codexが自分で直し始めます。Error: failed とだけ返していた頃は、何も直せませんでした。

ここに「ビルドが通るか」を足せば、運用の前半は固まります。リポジトリにアクセス集計スクリプトがあるなら、ゲートの前にそれを呼んで数字を取り、なければ「数字が取れなかった」と正直に報告させます。嘘のPVやCVRを作らせない。収益運用では、これがいちばん大事です。

Codexに返させる「判断メモ」を構造化する

毎日「どのページを、なぜ選んだか」を残すと、あとで効きます。Codexには次のJSONを返させています。これだとレビューが一瞬で済む。

{
  "date": "2026-06-07",
  "candidate": "/blog/claude-code-analytics-implementation/",
  "taskType": "update_existing_article",
  "reason": "流入はあるが、研修CTAへの導線が弱い",
  "primaryKpi": "training_cta_click",
  "secondaryKpi": "free_pdf_signup",
  "humanReviewNeeded": true,
  "doNotTouch": ["担当外のslug", "heroImage", "他の作業者のファイル"]
}

JSONにしておくと判断の根拠が残るので、「なんとなくPVが多いから」という弱い理由で新規記事を増やさずに済みます。動かしたい指標（無料PDF登録・商品クリック・相談CTAクリック）を先に1つ決める。それだけで運用の精度が変わります。多言語の公開手順まで固めたいなら、毎日の公開チェックリストとコンテンツファネル監査も合わせて使ってください。

僕がやらかした失敗3つ

正直に書きます。最初のCodex運用は、けっこう事故りました。

ひとつ目は、古い公式情報を断定したこと。「Automationsもタスクも全部同じスケジュール機能でしょ」と書いたら、Thread / Standaloneの違いも、PCが起きている必要がある話も抜けていました。読者の運用設計を狂わせる。以来、料金・対応状況・APIは、書く前に必ず公式を開きます。

ふたつ目は、文脈を詰め込みすぎたこと（context bloat、つまり情報過多）。長い会話に全部覚えさせれば安全、は嘘でした。むしろ古い料金や別ページ向けの指示が混ざる。いまは自動化の冒頭で「今回の対象slug」「触っていいファイル」「最新の公式リンク」「禁止事項」を短く再提示します。これだけでミスが減りました。

みっつ目は、人間レビューを抜いたこと。「忙しいから今日は自動でいいや」をやった日に限って、強すぎる売り文句のまま公開していました。文字数やリンクは門番が見てくれる。でも「売り込みが先に立っていないか」だけは、いまも僕が見ます。ここは譲らない。

よくある質問

Q. Codex Automationsは無料で使えますか？ A. 利用枠やプランは変わります。本記事で断定はしません。最新の対応範囲・料金はOpenAIのCodex Automations公式ページで確認してください。

Q. PCを閉じていても自動で走りますか？ A. プロジェクトにひもづくローカルの自動化は、PCが起きていてCodexが動いている状態でないと走りません。常時走らせたい場合の最新状況は公式で確認を。寝る前に走らせるなら、スリープ設定に注意です。

Q. Codexだけで記事を全部書かせていい？ A. おすすめしません。下書き・調査・QA・確認は任せて大丈夫。でも公開判断と「実体験の一段落」は人間が入れたほうが、薄い要約記事になりません。

Q. Claude CodeとCodex、片方だけにするなら？ A. 用途次第です。毎日の定例再実行が主ならCodex、リポジトリの深い改修が主ならClaude Code。迷うなら使い分けの記事を先に読むと境界が決めやすいです。

Q. 自動デプロイは怖くないですか？ A. 怖いです。だから「ビルドと記事チェックが通らなければデプロイしない」「担当外の差分があれば止める」を必ず入れます。意図しない公開は、運用の信頼を一回で壊します。

実際に試した結果

Codexを「自動執筆マシン」だと思っていた頃は、本数だけ増えて数字は伸びませんでした。役割を「アクセス確認・記事QA・CTA改善・公開確認の再実行係」に振り直したら、AIに任せる部分と人間が見る部分がきれいに分かれた。古い公式情報、意図しないデプロイ、弱いCTA——どれも公開前に見つかるようになりました。

決め手は、賢いプロンプトより、上の品質ゲート1つです。exit(1) で止まる門番を置いただけで、薄い記事と閉じ忘れが公開ラインまで来なくなりました。

自分のサイトやチームに合わせて組みたいなら、順番はいつも同じです。まず無料のClaude Code クイックリファレンスで基本を固め、テンプレ化は教材一覧で、チーム導入や収益導線の設計は研修・導入相談で具体的に詰める。賢いAIを探すより、転んでもケガしない足場を先に作る。遠回りに見えて、これがいちばん速い、というのが今の実感です。