Codexで定期実行・自動化する方法 — スケジュールタスク・ヘッドレス実行・CI/CD組み込みの使い分け

自動化の3方式 — 何をきっかけに動かすかで選ぶ

Codexの自動化には、大きく3つの方式があります（2026年8月時点）。①スケジュールタスク（アプリの「スケジュール」に登録して定期実行）、②ヘッドレス実行（codex exec コマンドをスクリプトやOSのスケジューラーから呼ぶ）、③CI/CD組み込み（GitHub Actionsなどの開発パイプラインの部品にする）です。違いは「何をきっかけに、どこで動くか」で、それが向き不向きを決めます。

迷ったら①のスケジュールタスクから始めてください。チャットで頼むだけで登録でき、非エンジニアの業務自動化はほぼここで完結します。②と③は「Codexを画面のない部品として使う」ための方式で、スクリプトやCI/CDを扱うチーム向けの選択肢です。

①スケジュールタスク — チャットで頼むだけの定期実行

1つ目は、ChatGPTデスクトップアプリ（Codex）のサイドメニュー「スケジュール」に登録する定期実行です。もともとChatGPTのscheduled tasks（定期実行タスク）とCodexのautomationsという別々の機能でしたが、2026年7月中旬のアプリ統合で「スケジュール」に一本化されました。

この経緯と、登録時に伝える6項目・ローカル実行とクラウド実行の選び方・権限（サンドボックス）の与え方は、定期実行（スケジュール）の登録ガイドで詳しく解説しているので、本記事では要点だけ押さえます。

• 登録はフォームに手入力せず、チャットで頼むのが簡単。いつ何をするか・出力先・繰り返しの周期などを箇条書きで伝えれば、登録までやってもらえる
• 実行場所を先に決める。手元のフォルダを読み書きしたいならローカル実行（パソコンが起動している必要あり）、パソコンを閉じていても動かしたいならクラウド実行
• 載せてよいのは「すでに手動で成功している業務」だけ。手順が固まっていない仕事を自動化すると、使えない成果物が毎週生産され続ける

②ヘッドレス実行（codex exec） — 画面を開かずスクリプトから動かす

2つ目は、対話画面を開かずに1回の指示を実行する非対話モード（ヘッドレス実行）です。CLIの codex exec コマンドで実行すると、作業の途中経過は画面（標準エラー出力）に流れ、最終結果だけが標準出力に出ます。そのため、結果をそのままファイルに保存したり、次のコマンドに渡したりできます。

codex exec "直近10件のコミットからリリースノートを作って" | tee release-notes.md

これをOSの定期実行機能（Macのcron・launchd、Windowsのタスクスケジューラ）と組み合わせれば、①と同じ定期実行を自前で組むこともできます。ただし管理の手間が増えるため、決めた時刻に動かすだけなら①で足ります。②が真価を発揮するのは、既存のスクリプトや業務システムの途中にCodexを部品として挟みたいときです。

権限は既定で読み取り専用 — 必要な分だけ広げる

無人で動く前提のため、codex exec は既定では読み取り専用のサンドボックスで動きます（2026年8月時点）。ファイルの変更が必要な仕事だけ --sandbox workspace-write を付けて、作業フォルダ内への書き込みを許可します。

すべての制限を外す --sandbox danger-full-access は、隔離されたCI環境など影響範囲が閉じた場所以外では使いません。また、破壊的な変更を防ぐためGitリポジトリの中でしか実行できないガードも入っています。

この「狭い権限から始めて必要な分だけ広げる」考え方は、Codexのセキュリティで解説している権限設計と共通です。

結果を機械可読で受け取る — 後続処理につなげる

• --json を付けると、実行中の出来事が1行1件のJSON形式（JSONL）で流れ、何をしたかをプログラムで処理できる
• -o 保存先ファイル で、最終結果だけを指定ファイルに書き出せる
• --output-schema スキーマファイル で、最終結果を指定したJSONの形に固定できる。集計や通知など後続処理の受け取りが安定する
• codex exec resume --last で前回の続きから再開でき、「調査→修正」のような2段階のパイプラインも組める

逆に、他のコマンドの出力をパイプでCodexに渡すこともできます。ログや実行結果を渡して要約させる使い方は、コマンドラインの日常業務と自然につながります。

npm test 2>&1 \
  | codex exec "失敗したテストを要約して、最小の修正案を出して" \
  | tee test-summary.md

③CI/CD組み込み — 「テストが落ちたら修正案を作る」まで

3つ目は、CodexをCI/CDワークフローの部品として組み込む方式です。GitHub Actionsには公式アクション（openai/codex-action）が用意されており、CLIのインストールとAPIキーの受け渡しを自前で書くよりも安全に組み込めます。

APIキーをジョブ全体の環境変数に置かない設計になっているためで、任意のコードが動くジョブにキーを環境変数として渡すと、テストや依存パッケージからキーを読み取られる恐れがあります。

公式ドキュメントには、「CIが失敗したら、Codexが修正パッチを作り、別のジョブがそのパッチからプルリクエストを開く」という自動修正パターンが例示されています。ポイントは役割の分離です。Codexが動くジョブには読み取り権限しか与えず、書き込み権限を持つジョブにはAPIキーを渡さない——無人でAIが動く仕組みほど、この「1つのジョブに強い権限を集めない」設計が効きます。

なお、プルリクエストごとの自動コードレビューや@codexメンションは、CI/CDを自前で組まなくてもGitHub連携の設定だけで使えます。手軽さではこちらが先なので、CodexのGitHub連携を参照してください。

無人で動かすときの設計原則4つ

どの方式を選んでも、無人実行の設計原則は共通です。人が横で見ている通常の使い方より一段丁寧に、次の4点を押さえておくと安定します。

1. 1まず手動で1回成功させる。自動化してよいのは、すでに手動で品質が安定している業務だけ。手動で1回通すと、必要な権限・参照ファイル・通信先も具体的に分かる。Codexの使い方 — 頼み方3つの型から続く、仕組み化全体に共通する順番
2. 2権限は最小限から始める。読み取り専用→作業フォルダ内の書き込み→個別の許可、の順に、実際に必要だった分だけ広げる。足りないからと一気にフルアクセスへ切り替えない
3. 3結果を必ず残す・報告させる。静かに失敗して数週間気づかない、が無人運用の典型的な事故。ヘッドレス実行なら -o で結果をファイルに残し、スケジュールタスクなら「失敗したら理由を◯◯に報告する」まで指示に書く
4. 4判断基準はAGENTS.mdに書く。自動実行は毎回新しいセッションで動くため、過去の会話を覚えていない。ルール・手順はAGENTS.mdに書いて、毎回そこを読ませる

この4点は、Codexの応用機能まとめで整理している「うまくいっている業務を仕組みに昇格させる」流れの、自動化フェーズにあたります。基礎の頼み方で成功体験を作ってから載せる、という順番を崩さないことが、遠回りに見えて最短です。

非エンジニアはどこまで使えるか

①のスケジュールタスクは、チャットで頼むだけで作成でき、プログラミングの知識は不要です。定期実行と相性がよいのは、毎朝の情報収集、週次のデータ整理、月次レポートの下ごしらえといった繰り返し型の事務業務で、これはエンジニアリングよりむしろバックオフィスや企画職の仕事です。

非エンジニアがCodexを業務基盤にしていく道筋は非エンジニアのCodex活用で整理しています。

②③はコマンドやCI/CDを扱うエンジニア・情シス向けですが、これはClaude Code側でも同じ構図です（対になる整理はClaude Codeの定期実行・自動化）。

一方で、「どの業務を自動化し、どこに人の確認を挟むか」の設計は、ツールの操作方法より一段上の判断です。当社のCodex研修・導入伴走支援では、業務の棚卸しから自動化の設計・運用ルールづくりまでを、貴社の実務に合わせて段階的に伴走しています。