CodexでGoalを立てる前に決めること

3行まとめ

Objective

目的。

Scope

範囲。

Evidence

証跡。

Done

完了。

Stop

停止。

長期作業は、始める前に終わり方を決めます。

• CodexのGoalは、長期作業を続けるための目的であり、毎回の細かい依頼や手順そのものではありません。
• Goalを立てる前に、対象範囲、完了条件、証跡、レビュー回数、停止条件、人間へ戻す条件を決めます。
• 進捗報告だけで完了扱いにせず、最後に現在状態を見て、要件ごとの証拠で完了を判断します。

この記事では、OpenAI公式のCodex use cases、Codex app Commands、Automations、Skills、Permissions docsを確認し、2026年6月1日時点の情報として整理しています。Codex appのGoal、Commands、Automations、Skillsは更新され得るため、導入前に最新docsと手元の運用を確認してください。

この記事でわかること

Task

向き不向き。

Gate

確認条件。

Ledger

進捗台帳。

Human

戻す条件。

Goalは継続のための入口で、完了監査まで含めて設計します。

• CodexでGoalにする作業と、単発依頼にする作業の分け方
• 長期作業を始める前に決める完了条件
• 進捗台帳とレビュー証跡の残し方
• blockedや人間確認へ戻す条件
• Commands、Automations、Skillsとの使い分け
• 導入初週に試す小さなGoalの例

OpenAIのCodex use casesでは、Follow a goalとして、Codexに長期作業のdurable objectiveを渡す使い方が紹介されています。長く続く作業、複数stepに分かれる作業、途中で検証や見直しが必要な作業は、単発promptよりGoalとして扱うほうが迷子になりにくいです。

ただし、Goalは「長く動かせば何とかなる」機能ではありません。目的が曖昧なまま始めると、Codexは進捗を作っているように見えても、最終状態が要件に届いていないことがあります。Goalは、完了条件と証跡を伴う作業契約として扱うのが安全です。

Codexで定期実行を作る考え方は、公開済み記事のCodexで定期実行を作る前に決めることでも扱っています。この記事では、定期実行ではなく、長期作業の目的管理に絞ります。

前提知識

項目	内容	見方
Use cases		Goal用途。
Commands		呼び出し。
Automations		定期実行。
Skills		手順化。
Permissions		権限。

Goalを、commandやautomationとは別の作業契約として見ます。

OpenAI公式のCodex use casesでは、Follow a goalが長期作業のdurable objectiveとして説明されています。Goalは、複数turnにまたがって作業を続ける時に、何を達成すべきかを保つための入口です。

Commands docsでは、/goal のようにthread composerからGoalに関わる操作を呼び出せることが示されています。Commandsは入口であり、Goalの中身そのものではありません。

Automations docsでは、Codex appが定期実行やbackground作業を扱えることが説明されています。Skills docsでは、繰り返し作業の手順を固定する考え方が説明されています。Permissions docsでは、filesystemやnetworkの権限をprofileとして管理する考え方が示されています。

公式情報で確認する範囲

確認先	見ること
Codex use cases	Follow a goalの位置づけ
Codex app Commands	Goalを呼び出す入口
Automations	定期実行との違い
Skills	手順化との違い
Permissions	長期作業に渡す権限

注意点

この記事は、Goalを大量に作ることを勧めるものではありません。短い調査、単発の修正、1回で完了する確認は、普通のthreadやcommandで十分な場合があります。

また、Goalは完了判定を人間から奪うものではありません。高riskな作業、外部送信、公開、deploy、顧客影響の判断は、人間確認へ戻す条件を入れます。

まずGoalにする作業を分ける

項目	内容	見方
Batch		複数件。
Migration		段階作業。
Audit		監査。
Research		広い調査。
Not goal		単発依頼。

Goalにするのは、完了まで複数回の確認が必要な作業です。

Goalに向いているのは、複数turnや複数成果物にまたがる作業です。

作業	Goal向きか	理由
100件の記事を作る	向く	対象数、台帳、レビューが必要
1つのtypo修正	向かない	単発で終わる
migrationを段階的に進める	向く	checkpointと検証が必要
PRを1本見る	場合による	大きいPRなら向く
release前QAを複数環境で回す	向く	証跡と停止条件が必要

Goalにする判断は、「長いか」だけではありません。途中で作業が切れても、次に何をすべきか分かるか。完了を証明する証拠が必要か。scopeが広がりやすいか。ここを見ます。

Goalが向く作業

Goalが向くのは、対象数がある作業、複数段階のmigration、継続的なQA、複数repoの棚卸し、長い調査、記事やdocumentの量産、release準備などです。

これらは、途中で「いま何本終わったか」「何を検証したか」「残りは何か」を見失いやすいです。Goalにするなら、台帳や進捗ログを同時に用意します。

Goal化前の確認項目

Goalにする前に、次を確認します。

項目	見ること
対象	何件、どの範囲、除外条件
完了	何をもって終わりか
証跡	どのfile、URL、commandで証明するか
権限	read/write/network/publishの境界
停止	いつ人間へ戻すか

Goalにしない作業

単発で終わる作業、目的がまだ曖昧な相談、選択肢を並べたいだけの調査は、Goalにしないほうがよいです。Goalにすると、まだ固まっていない方向へ作業が進みすぎることがあります。

まず普通のthreadで相談し、scopeが決まってからGoal化します。

完了条件を先に決める

項目	内容	見方
Count		対象数。
Test		検証。
URL		公開確認。
Review		確認回数。
No gaps		残件なし。

進捗ではなく、完了を証明する証拠を先に決めます。

長期作業で一番危ないのは、進んでいるように見えるけれど、完了の証拠がない状態です。Goalを立てる前に、完了条件を決めます。

完了条件	例
件数	100記事を公開済み
品質	各記事3レビュー済み
公開	public URLが200
視覚	アイキャッチと本文ビジュアルあり
検証	site QAがfailedなし
台帳	進捗fileが現在状態と一致

完了の証拠

完了の証拠は、意図ではなく現在状態から取ります。file、command output、公開URL、post ID、test result、QA report、PR stateなどです。

「やったはず」ではなく、「このURLが200で、sitemapにあり、noindexがなく、台帳に反映されている」と言える状態にします。

途中成果との違い

途中成果は大事ですが、完了ではありません。記事を1本公開した、validatorが1つ通った、draftができた、planができた、というのは進捗です。Goalが「100本公開して3回レビュー」なら、100本すべてについて証拠が必要です。

完了監査の粒度

完了監査では、要求を分解します。

要求	証拠
100個	台帳と公開記事数
作成	draft fileとWordPress post
公開	public URLとstatus
3回レビュー	validator、visual validator、public QA
完璧	既知の品質gateと全体scan

広い要求には、広い証拠が必要です。1本の記事の成功で、全体完了を判断しません。

進捗と証跡を固定する

Ledger

件数。

Latest

直近結果。

Failures

失敗。

Evidence

証跡。

長い作業ほど、記憶ではなく台帳と検証結果を見ます。

Goalが長くなるほど、記憶に頼ると崩れます。進捗台帳を置き、各runで更新します。

記録	内容
target	最終目標
completed	完了数
remaining	残数
latestRun	直近の成果
evidence	review、QA、URL、ID
failures	失敗と再試行

台帳

台帳には、最新状態だけでなく、各成果物のURLや証跡を残します。長期作業では、途中で別threadに移ったり、contextが短くなったりします。台帳があると、次のturnで現在状態から再開できます。

台帳は人間が読める形にします。JSONでもMarkdownでもよいですが、対象、状態、証跡、残件が分かることが大事です。

レビュー

レビューは、回数だけでなく種類を分けます。たとえば記事なら、構造validator、ビジュアルvalidator、公開URL QAのように、違う観点で確認します。

review	見ること
1回目	構造、本文、内部リンク
2回目	ビジュアル、レスポンス幅、アイキャッチ
3回目	公開URL、sitemap、noindex、全体QA

同じcommandを3回流すだけでは、3種類のレビューにはなりません。

停止条件と人間確認を決める

1. 1Detect

   詰まりを検出。

2. 2Retry

   再試行。

3. 3Narrow

   範囲確認。

4. 4Ask

   人間へ戻す。

止まる条件を決めておくと、無理な推測で進みにくくなります。

Goalは長く続くため、止める条件も必要です。止まるべき時に進み続けると、後で戻す範囲が大きくなります。

停止条件	対応
権限不足	人間確認へ戻す
外部状態が不安定	再確認する
要件衝突	scopeを確認する
3回同じblocker	blockedとして報告
高risk操作	承認を待つ

blockedの扱い

blockedは、少し難しい時に使う言葉ではありません。同じblockerが続き、外部入力なしには進めない時に使います。途中で失敗しても、別の確認や再試行で進めるなら、Goalは続行します。

長期作業では、「難しいから止める」と「本当に外部入力が必要」を分けます。

scope変更

Goalの途中でscopeが変わることがあります。たとえば、100本の記事という目標に対して、テーマ選定基準や品質gateが追加される場合です。この時は、Goalを小さく言い換えず、追加条件を台帳や運用へ反映します。

人間の新しい指示が古い方針と衝突するなら、新しい指示を優先し、現在状態から調整します。

CommandsとAutomationsとSkillsを分ける

項目	内容	見方
Goal		長期目的。
Command		呼び出し。
Automation		定期実行。
Skill		手順。

Goalは目的、Skillは手順、Automationは実行タイミングとして分けます。

Goal、Commands、Automations、Skillsは役割が違います。

仕組み	役割	例
Goal	長期目的	100本公開、migration完了
Command	呼び出し入口	/goal、/status、/review
Automation	実行タイミング	毎日3回実行
Skill	作業手順	公開前QA、release手順

Goalは「何を達成するか」です。Skillは「どう進めるか」です。Automationは「いつ走るか」です。Commandは「どう呼ぶか」です。

Commands

Commandsは、Goalを始めたり状態を確認したりする入口です。Commandsへ長い手順を全部押し込むのではなく、GoalやSkillを呼ぶきっかけとして使います。

Codex Commandsの整理は、CodexのCommandsを増やす前に決めることでも扱っています。

Automations

Automationsは、Goalを継続する実行タイミングとして使えます。ただし、GoalとAutomationは同じものではありません。Goalが「何を達成するか」で、Automationは「いつ作業を起こすか」です。

Skills

Skillsは、Goalの中で繰り返す手順を固定するために使います。たとえば公開前QA、PR review、release準備、記事生成の品質gateなどです。

長期Goalで同じ確認を何度も行うなら、Skill化する価値があります。

導入初週の進め方

1. 1日目

   単純な複数件。

2. 2日目

   台帳を作る。

3. 3日目

   完了監査。

4. 5日目

   停止条件。

5. 7日目

   skill化候補。

最初は完了条件を証明しやすいGoalから始めます。

最初の1週間は、完了条件を証明しやすいGoalから始めます。

日	やること	見ること
1日目	小さな複数件Goalを作る	件数と完了条件
2日目	台帳を作る	current stateと合うか
3日目	完了監査を試す	証拠で判断できるか
5日目	停止条件を追加する	無理に進まないか
7日目	繰り返し手順をskill化する	再利用できるか

初週の成功条件は、たくさん進むことではありません。途中で止まっても、何が終わり、何が残り、何を見れば証明できるかが分かることです。

小さく始める例

最初に試すなら、次のようなGoalが扱いやすいです。

Goal	理由
docsリンクを20件確認する	件数と結果が明確
既存記事を5本更新する	対象が狭い
PRを3本レビューする	証跡を残しやすい
test failureを5件分類する	進捗台帳に向く
release checklistを1本完成させる	完了条件を作りやすい

大規模migrationや本番公開を伴うGoalは、停止条件と人間確認を作ってから始めます。

FAQ

When?

複数turn。

Done?

証拠で判定。

Blocked?

条件を固定。

Skill?

手順化。

迷ったら、Goalが目的なのか手順なのかへ戻ります。

Goalはいつ使いますか？

複数turn、複数成果物、複数レビューにまたがる作業で使います。1回で終わる依頼なら、普通のthreadで十分です。

Goalを立てたら、毎回細かく指示しなくてよいですか？

完全に不要にはなりません。Goalは目的を保つためのものです。途中で新しい制約や品質基準が出たら、それを現在のGoal運用へ反映します。

完了したかどうかはどう判断しますか？

現在状態から証拠を取って判断します。台帳、公開URL、test結果、validator、QA report、PR stateなど、要件ごとの証拠を見ます。

blockedはいつ使いますか？

同じblockerが続き、外部入力や外部状態の変化なしには進めない時です。失敗しても別の方法で進めるなら、blockedではなく再試行や調整をします。

GoalとSkillはどう分けますか？

Goalは目的です。Skillは手順です。たとえば「100本の記事を公開する」はGoalで、「1本の記事を作って3レビューして公開する手順」はSkillに向きます。

次に読むなら

参照した主な情報源

• Codex use cases – OpenAI Developers
• Codex app commands – OpenAI Developers
• Codex app automations – OpenAI Developers
• Skills – Codex – OpenAI Developers
• Permissions – Codex – OpenAI Developers

更新履歴

1. 2026年6月1日

   OpenAI公式Codex docsを確認して初版を作成しました。

導入時には最新のCodex use casesとapp docsを確認してください。

• 2026年6月1日: OpenAI公式Codex use cases、Codex app docs、Skills、Permissionsを確認し、初版を作成しました。