Codexの自動化を始める：反復作業のプロンプトと予約前の確認

要約： Codexの自動化では実行時刻を決める前に、入力、結果、実行環境、重複防止の基準を設計する必要があります。一度の手動結果を確認してから同じ作業を予約し、最初の数回の結果と次の実行時刻を確認してください。反復確認には以前の比較基準をどこに保存するかと、いつ終了するかも必要です。

1. どの反復業務から始めるか

「プロジェクトを管理して」より、「READMEとdocsで変更された実行コマンドを読み、誤ったパスと文書間の差を根拠とともに報告して」の方が自動化しやすくなります。入力が固定され、結果を確認できるためです。コード修正も含めるなら修正対象と検証条件の追加が必要です。最初は人が次の行動を決められる小さな報告業務が適しています。

OpenAIの公式Scheduled tasks文書によると、予約作業はウェブとデスクトップアプリで作成・管理し、CLI・IDEには同じ予約管理画面はありません。ローカルファイルを使う作業はコンピューターの電源が入り、アプリが実行中である必要があります。ウェブ作業はアップロード資料や接続ツールを使えますが、PCのローカルフォルダーへ直接アクセスする方法とは異なります。

この記事は執筆者の架空の文書確認事例で設定方法を説明します。実際の予約登録や特定プロジェクトの実行レビューではありません。プロンプトのパスと比較基準は自分のプロジェクトに合わせて変え、利用可能な機能は現在のアカウントとワークスペースで確認してください。

業務	自動化に入れる入力	確認可能な結果
文書の変更確認	対象文書、比較コミット、検証範囲	変更要約と誤り候補の根拠箇所
最近のコミットの要約	リポジトリ、ブランチ、正確な期間	テーマごとの変化と関連コミット
CI状態の追跡	対象PR・実行識別子、アクセス可能なツール	新たな失敗・完了・利用者の措置が必要な状態
文書の修正案の作成	修正ファイル、許容変更、完了基準	変更ファイルと実際の検証結果

実行中に空の入力を自動的に探して埋めさせると、別のプロジェクトを読んだり比較範囲を変えたりする可能性があります。プロジェクト、基準、報告先を先に書いてください。接続サービスが必要な作業なら、手動実行で実際にアクセスできるかも確認する必要があります。

2. まず一度の実行を完成させる

手動実行の目的はプロンプトの見栄えより、必要資料を読み、有用な結果を作るか確認することです。下の例の比較コミットは実在する値を入れてください。角括弧が残るなら予約せず、先に入力を完成する方がよいでしょう。

이 프로젝트의 문서 변경을 한 번 점검해 주세요.
프로젝트: [실제 프로젝트 경로]
비교: [실제 기준 커밋]부터 현재 HEAD까지
대상: README.md와 docs 폴더의 변경된 문서
확인: 실행 명령의 설명, 파일 경로, 문서끼리 다른 안내
출력: 비교 기준 / 변경 요약 / 문제 후보 / 근거 / 미확인 사항
명령을 실행하지 않고 읽어서 판단한 내용은 그렇게 표시해 주세요.
파일 수정과 외부 게시 없이 결과를 대화에 작성해 주세요.
변경이 없으면 확인한 비교 범위와 함께 변경 없음을 적어 주세요.

結果の基準コミットと現在のコミットが実際に確認されたか見てください。「リンクは正常」という表現も、リンク文字列を読んだか実際の応答を確認したかを区別する必要があります。外部リンクへの接続が許可されていなければ、文書のURL形式だけを確認した可能性があります。必要な検証範囲を定めると報告の誇張を減らせます。

最初の結果が長く曖昧なら、出力から減らしてみてください。例えば問題候補を最大五つに制限し、各項目に「ファイル位置、理由、影響、確認方法」を求められます。対象文書が多すぎるなら、全プロジェクトではなくインストール案内と実行案内から始めてください。実行周期を増やしても不明確な入力は解決しません。

3. プロジェクトと実行環境を選ぶ

公式のBest practicesは、デスクトップアプリのScheduledでプロジェクト、プロンプト、周期、実行環境を選ぶ流れを案内しています。登録済みプロジェクトが実際の作業フォルダーを指すか先に確認してください。同名が複数あるならパスとリポジトリも併せて確認するとよいでしょう。

プロジェクト選択は「何を読むか」、実行環境選択は「どこで実行するか」です。同じリポジトリでも作業中のローカルフォルダーと別のチェックアウトでは、準備された依存関係やローカル資料が異なる場合があります。文書の変更の比較対象もプロジェクト名だけでは決まらないため、プロンプトに別途書く必要があります。

選択肢	適する状況	予約前に確認すること
ローカルプロジェクト	現在のフォルダーの資料とインストール済みツールが必要	作業中のファイルと予約作業の修正範囲
Git worktree	修正結果を別の場所で確認したい	開始基準、必要な依存関係・設定ファイル
ウェブでアクセスできる資料	アップロードや接続サービスの資料で十分	原本の新しさ、接続権限、結果の保存先

公式のWorktrees文書は、Gitプロジェクトの予約作業は別のworktreeで実行でき、Gitを使わないプロジェクトはプロジェクトフォルダーで実行すると説明しています。文書確認だけでも比較対象が実際にその環境にあるか確認してください。既存ローカルファイルが全て自動コピーされると仮定してはいけません。

Local environments文書のsetup scriptは新しいworktreeの依存関係などの準備に使えます。文書を読むだけで終わる作業に不要なインストールを入れる必要はありません。コマンド検証が必要なら、新環境でも同じコマンドが用意されるか、インストールに必要なネットワークを使えるか先に確認してください。

4. 日程と時間帯を具体的に書く

予約依頼には曜日と時刻だけでなく時間帯も書いてください。「月曜の朝」より「毎週月曜日午前9時、Asia/Seoul基準」とすると意図が明確です。海外チームなら誰の業務開始時刻かも決める必要があります。以下は登録依頼の例で、入力しただけで予約が完了するわけではありません。

방금 확인한 문서 점검을 반복 예약해 주세요.
작업 이름: [프로젝트명] 문서 변경 점검
일정: 매주 월요일 오전 9시, Asia/Seoul 기준
프로젝트: [현재 확인한 프로젝트와 경로]
실행 환경: [로컬 또는 Git worktree]
각 실행 결과는 독립된 검토 보고서로 남겨 주세요.
대상과 검증 범위는 확인한 프롬프트를 사용해 주세요.
새 문제, 해결, 접근 실패처럼 조치가 필요한 변화만 알려 주세요.
종료일: [예: 2026년 10월 30일 오후 6시, 한국 시간]
등록된 일정, 다음 실행 시각, 대상 프로젝트를 알려 주세요.

登録後は表示された次の実行時刻を依頼した時間帯と併せて確認してください。この事例の日付なら最初の月曜日は2026年10月5日です。開始日を遅く設定したり過去の時刻を指定したりすれば、次の実行日は変わり得ます。重要な日程は依頼文と実際の保存日程の両方を確認するとよいでしょう。

電源が切れていた間の実行の扱いが未確認なら、自動で補完実行されると仮定しないでください。ローカルの点検は正常に実行できる時間帯を選び、記録に欠けた区間があれば次の比較範囲へ含めるか決めてください。見逃した期間と変更なしは別の状態です。

5. 同じ会話で続けるか独立実行にするか

公式文書は既存会話の文脈を引き継ぐ予約と、保存プロンプトで始める独立予約を区別しています。進行中のCIを完了まで追うなら同じ会話が便利で、週報を個別に保存するなら独立実行が便利です。方式と結果の場所を依頼に明記してください。

独立実行が以前の報告や比較基準を自動で覚えると仮定してはいけません。以前の状態が必要なら読める記録を指定する必要があります。同じ会話でも基準を日付やコミットで残せば、「前回以降」の意味を確認しやすくなります。

架空の文書点検では、各実行の開始・終了コミットを報告に記し、次の実行は最後に成功した終了コミット以降を読むよう設計できます。状態ファイルは執筆者が提案する運用方法で、Codexが標準で作るファイル機能を意味しません。

상태 기록: [프로젝트 안의 .automation/docs-audit-state.json]
기록 항목: 마지막 성공 비교 커밋, 확인 시각, 기존 문제의 식별 정보
기록이 없으면 지정한 초기 기준부터 비교하고 초기 실행이라고 표시하세요.
기록의 커밋을 찾을 수 없으면 임의로 기준을 바꾸지 말고 알려 주세요.
문서 점검이 성공한 뒤에만 마지막 성공 기준을 갱신하세요.
실패한 실행에서는 기존 기준을 유지하세요.
쓰기 허용 대상은 지정한 상태 파일뿐이며 문서 본문은 수정하지 마세요.

この方法には状態ファイルへの書き込み権限が必要です。完全な読み取り専用報告が目的なら、アクセスできる以前の報告の基準を使うか、毎回固定期間を比較する方法へ変えてください。状態ファイルを作るなら維持するフィールドと修正者も定めるとよいでしょう。

6. 重複した報告と作業を減らす

重複には同じ予約が二つある場合と、一つの予約が同じ問題を繰り返し新しい問題として報告する場合があります。前者は名前だけでなくプロジェクト・目的・周期を比較して探してください。日程変更では既存作業の修正という意図を明記し、変更後に有効な予約が一つか確認します。

기존 [프로젝트명] 문서 변경 점검 예약을 수정해 주세요.
같은 목적의 새 예약을 추가하지 마세요.
요일은 유지하고 시간을 오전 9시에서 오전 10시로 바꿔 주세요.
시간대, 프로젝트, 실행 환경, 기존 프롬프트는 유지해 주세요.
수정 후 활성 작업과 다음 실행 시각을 확인해 주세요.

問題の重複は「同じファイル位置と同じ原因」を基準に管理できます。ファイル名や行番号が変わるだけで必ず新問題と数えると、反復通知が起きます。以前の問題との比較資料がなければ重複判断をしたと報告せず、今回見つけた事実だけを書くよう要求してください。

「文書を修正して」を含む予約なら、修正案が既にあるか先に確認し、同じ変更を再作成しないようにする必要があります。複数の予約が同じ状態ファイルを直すと記録が衝突するため、一つの記録に担当作業を一つ置く方が簡単です。プロンプトの重複禁止だけでファイルのロックや同時実行の衝突防止が保証されるわけではありません。

7. 失敗・完了・終了条件を定める

状態	報告内容	比較基準の処理
点検成功、変更なし	確認範囲と時刻	成功基準を記録する
新しい問題または既存問題の解決	根拠、以前の状態との差	成功基準と問題状態を記録する
資料へのアクセス失敗	失敗対象と必要措置	以前の成功基準を維持する
比較コミットなし	基準が見つからない事実	利用者に新基準を求める
終了日または完了条件を満たした	最終状態と残る問題	予約終了の反映を確認する

長期間同じ状態を追う予約には終了条件が特に役立ちます。CIの完了確認は成功・失敗が確定したときに終え、期間限定の文書点検は終了日に停止するよう頼めます。続ける業務なら終了日の代わりに、一か月後に結果の有用性と周期を再検討する時点を定めてください。

予約は既定のサンドボックス設定を使う無人実行で、組織のポリシーが適用されます。公式のSandbox文書を参照し、必要なファイル・ネットワーク範囲を定めてください。アクセス制限による失敗で全アクセスを一括解除するより、読む対象、必要コマンド、検証範囲を再調整する方がよいでしょう。

終了条件をプロンプトに入れたら、実際の管理画面に停止や完了状態が反映されたかも確認してください。記録保管と予約停止は別の作業です。完了した実行を整理する際は、再確認する報告と必要な変更内容を先に確認してください。

8. 二回の架空の実行で結果を確認する

架空のプロジェクト「実験ノートウェブ」が毎週月曜午前9時に文書変更を点検すると仮定します。初回に開始コミットAと終了コミットB間の変更文書三つを確認し、実行案内の誤ったフォルダー名を一つ見つけたとします。報告には該当文、実際に確認したパス、コマンド実行の有無を併記する必要があります。

二回目はB以降の変更を確認します。同じフォルダーの誤りが残り、新しい誤りがなければ既存問題が未解決と表示します。利用者が名前を修正した変更があれば解決根拠を書きます。アプリが実行されず点検が抜けた場合は成功基準を進めず、最後の成功地点から比較すれば欠落を減らせます。

最初の数回は時刻・プロジェクト・基準・問題状態が正しいか自分で読んでください。通知が多ければ報告する変化の基準を狭め、点検時間が長ければ対象文書を減らしてください。有用な結果が安定するか確認してから修正業務や対象プロジェクトを追加すると、自動化の効果を評価しやすくなります。

公式の出典と確認日： 予約タスク、 ベストプラクティス、 ワークツリー、 ローカル環境、 サンドボックス。2026年10月3日確認。事例・状態ファイル・プロンプトは執筆者の説明用の例です。