「毎週月曜の朝9時に、Codexが自動で記事の下書きを作ってくれたら便利そう」
そう考える方は多いと思います。僕もnote、WordPress、メルマガ、コミュニティー向けコラムなどの制作を仕組み化する中で、繰り返し作業をスケジュールへ登録しました。
ただし、スケジュールに時刻を登録すれば、その時刻に完成品が届くわけではありません。指定時刻は「作業開始の合図」であり、安定運用には実行条件・重複防止・停止通知まで設計する必要があります。
この記事では、Codexのスケジュール機能で定期作業を自動化する手順と、僕が実際に複数の制作予定を運用してわかった注意点を解説します。
- Codexのスケジュール機能でできること
- 登録前に準備すべき指示書と成果物形式
- PC・アプリ・ローカルファイルに関する実行条件
- 重複実行や時間帯の衝突を防ぐ方法
- 成功・失敗をスマホで受け取る通知設計
Codexのスケジュール機能とは？
Codexのスケジュール機能は、保存した指示を毎日・毎週などの決まったタイミングで実行する仕組みです。実行中の作業や履歴は「スケジュール」画面から確認でき、定期的な調査、レポート作成、ファイル更新などに利用できます。
OpenAI公式資料では、デスクトップアプリのスケジュールタスクはローカルプロジェクトを利用できる一方、ローカルファイルが必要な場合はパソコンを起動し、アプリを実行しておく必要があると説明されています。Webで動くタスクはアップロード済み資料や接続ツールを使えますが、パソコン内のフォルダへ直接アクセスする方式とは条件が異なります。
つまり、同じ「定期実行」でも次の二つを区別する必要があります。
| 方式 | 向いている作業 | 主な条件 |
|---|---|---|
| Web中心 | 接続サービスの確認、公開情報の要約 | 必要資料をWebから参照できる |
| ローカルプロジェクト中心 | フォルダ内の指示書、履歴、成果物を使う制作 | PC起動、アプリ稼働、フォルダが利用可能 |
僕のコンテンツ制作は、各担当フォルダのAGENTS.md、rules、state、過去原稿を使うため、ローカルプロジェクト中心の運用です。
スケジュール登録の前に「手動で成功する工程」を作る
自動化で最も多い失敗は、まだ安定していない作業をそのまま定期実行へ移すことです。スケジュールは曖昧な工程を改善してくれる魔法ではありません。むしろ、曖昧さを毎回繰り返します。
最初に通常の会話で一度実行し、期待する成果物が作られることを確認してください。
登録前には最低限、次の項目を固めます。
- 何を目的に実行するのか
- どのフォルダ・資料を読むのか
- どの順番で担当を動かすのか
- 成果物の保存先とファイル名
- 完了の判定条件
- やってはいけない操作
- 止めてよい条件と通知先
たとえば「AIニュースを調べて記事を作る」だけでは、対象期間、情報源、重複、文字数、画像、投稿状態が決まりません。「72時間以内の公式情報を優先し、過去テーマと重複排除し、下書き保存まで行う」のように、判断可能な条件へ変えます。
CodexをWindowsで始める準備や、最初の小さな作業についてはこちらの記事で解説しています。
Codex Windowsアプリの始め方・使い方を初心者向けに解説。準備、サインイン、画面の見方、プロジェクトフォルダ、…
Codexで定期実行を設定する基本手順
スケジュール登録時は、名前、実行頻度、曜日、時刻、実行内容、対象プロジェクトなどを設定します。画面の名称や選択肢は更新される可能性がありますが、考え方は変わりません。
- タスク名を具体的にする
「記事作成」ではなく「平日9時 note下書き作成」のように、頻度と成果物を含めます。 - 実行先を確認する
同じチャットの文脈を使うのか、保存した指示から毎回始めるのかを決めます。 - 曜日と時刻を設定する
他の重い処理と重ならず、公開確認まで余裕がある時刻にします。 - 指示文に参照先を書く
AGENTS.md、sources、rules、state、前工程の成果物を明示します。 - 終了状態を指定する
公開ではなく下書き、配信ではなく原稿保存など、人の最終確認を残します。
登録後は有効になっているか、次回実行日時が意図どおりかを確認します。曜日やタイムゾーンの認識違いを防ぐため、初回だけは実行時刻の前後に状態を確認できる日に設定すると安心です。
指定時刻は「完成時刻」ではなく作業開始の合図
僕が実際に運用して、最初に認識を改めたのが時間の考え方です。
たとえば9時にnote作成を設定した場合、9時からネタ探し、選定、タイトル、本文、画像、検品、投稿が順番に始まります。最新動画の取得や画像生成、ブラウザの反応に時間がかかれば、完成は9時より後です。
そのため、公開したい時刻から逆算して余白を作ります。夕方に確認したいなら朝から開始し、翌日に配信するメルマガなら前日の午後に下書きを作る、といった設計です。
- 調査・画像生成・ブラウザ操作の時間を含める
- 人の確認時間を確保する
- 締切直前に開始しない
- 失敗通知を受けて再開できる余白を持つ
スケジュールを「締切」ではなく「始業ベル」と考えると、無理のない予定を組めます。
PCを切っていたらどうなる？ローカル実行の条件
ローカルプロジェクトのファイルを使うスケジュールでは、実行時にパソコンが起動し、ChatGPTデスクトップアプリが動作し、対象フォルダへアクセスできる状態が必要です。
パソコンを切っていた日に、必ず後から過去分をすべて自動実行するとは限りません。運用上は「その回が実行されなかった場合、次回は新しい実行として扱う」前提で、履歴と対象期間を設計するのが安全です。
たとえば最新動画を72時間分再走査するルールなら、前日に実行できなくても次回に一定範囲を拾えます。一方で、「昨日だけのデータ」を対象にすると欠落する可能性があります。
ブラウザ投稿を含む場合は、ログイン状態、アップロード可否、CAPTCHAや多要素認証も関係します。ブラウザが使えなければ原稿まで保存し、投稿工程だけ停止するなど、作業全体を失わない分け方が有効です。
stateと実行IDで重複作成を防ぐ
スケジュール運用では、同じテーマや同じ下書きを二重に作らない仕組みが欠かせません。接続が切れた直後に再実行すると、前の処理が途中まで成功している場合があります。
僕の仕組みでは、stateフォルダへ候補ID、タイトル、投稿先、編集URL、完了済み工程を保存します。再開時はこの情報を照合し、同じ仕事なら既存下書きの未完了部分だけを進めます。
- 動画IDや候補IDでネタを重複排除する
- 日付だけでなく媒体とテーマを記録する
- 新規投稿前に既存編集URLを探す
- 本文・画像・保存後検品を別チェックポイントにする
- 成功通知済みかも記録する
「失敗したら最初から再実行」は、スケジュール自動化では危険なルールです。どこまで終わったかを残すことで、二重下書き、画像の重複、通知の連続送信を防げます。
権限設定、停止条件、ブラウザ復旧の詳しい考え方は8記事目をご覧ください。
Codexは安全に使える？サンドボックスや権限設定の基本から、下書き運用、ブラウザ切断時の再試行、チェックポイント、重複…
複数のスケジュールは時間をずらして衝突を防ぐ
僕のプロジェクトでは、note、WordPress、通常メルマガ、SKY通信、Chatworkコラム、Threads投稿案など、複数の定期作業があります。最初は個別に便利な時刻を選んでいましたが、担当が増えると作業時間が重なりました。
特に画像生成やブラウザ操作は時間が読みにくいため、同時刻に詰め込まないほうが安定します。現在は、読者への配信時刻だけでなく、下書き開始、目視確認、公開・予約の時間を分けて考えています。
調整するときは週間表を作り、次の順で優先順位を付けます。
- 公開・配信の締切が決まっている仕事
- 翌日分を前日に準備できる仕事
- 画像やブラウザを使う重い仕事
- テキスト保存だけで完了する軽い仕事
また、同じ最新AI情報を複数媒体が同日に選ばないよう、媒体横断のテーマ履歴も使います。時間の衝突だけでなく、内容の重複もスケジュール設計の一部です。
成功通知と失敗通知を分ける
自動実行は、パソコンの前にいないときこそ価値があります。その一方で、画面を見ていなければ完成したのか、途中で止まったのかわかりません。
そこで、最終状態が確定したときだけ通知します。途中経過を何通も送ると重要な通知が埋もれるため、1実行につき原則1通です。
| 通知 | 含める内容 |
|---|---|
| 成功 | タイトル、保存日時、成果物URL、確認事項 |
| 要確認 | 停止工程、原因、完了済み工程、再開方法 |
| ブラウザ停止 | 再試行回数、最後の編集URL、必要なログイン操作 |
僕はスマホで確認できるよう、メール通知も組み込みました。通知送信に失敗しても、完成済みの下書きを作り直さないことも重要です。「通知の失敗」と「本体処理の失敗」を別々に扱います。
最初は3回テストしてから定期運用へ広げる
スケジュール登録後、すぐ完全放置するのはおすすめしません。最初の数回は、実行時刻にPCとアプリを起動し、成果物とログを確認します。
僕の場合も、画像が入らない、CTAが重複する、ブラウザ接続が切れる、複数媒体で同じネタを選ぶといった問題が、実運用で初めて見つかりました。そのたびに、指示書ではなくrulesとstateへ改善内容を戻しました。
テストでは次を確認します。
- 予定した日時に開始したか
- 正しいプロジェクトと資料を参照したか
- 前回の成果物と重複していないか
- 下書き・ファイルが指定場所に保存されたか
- エラー時に安全に停止したか
- 通知が1回だけ届いたか
3回程度安定したら、曜日を増やす、別媒体へ展開するなど、少しずつ範囲を広げます。自動化は大きく始めるより、壊れ方を理解しながら育てるほうが結果的に早く安定します。
まとめ：スケジュール化は「時刻登録」ではなく運用設計
Codexのスケジュール機能を使えば、毎日・毎週の調査、記事やメルマガの下書き、レポート作成などを定期化できます。ただし、安定させるには時刻を入れるだけでは足りません。
- 通常の会話で成功した工程をスケジュール化する
- 指定時刻は開始時刻として余白を持たせる
- ローカル作業ではPC・アプリ・ファイルの状態を整える
- stateと編集URLで重複作成を防ぐ
- 複数タスクの時間とテーマをずらす
- 成功・停止を一度だけ通知する
- 最初の数回を確認し、失敗をルールへ戻す
まずは週1回、下書き1件を作るスケジュールから始めてみてください。
次の最終記事では、ここまで解説したAGENTS.md、担当分け、安全設計、スケジュールを組み合わせ、僕が実際に構築した「SUGA AI Content Engine」の全体像と作り方を公開します。