Noah
記事一覧へ戻るAI活用・業務効率化約8分で読めます

AIに任せた長い仕事が途中で止まる人へ|Codex Goalの使い方

AIに大きな仕事を任せたはずなのに、気づけば自分がずっと進行管理している。

途中で止まるたびに「続きをお願いします」「次はテストしてください」「残りも確認してください」と声をかける。
作業の一部はAIへ渡せても、これでは自分の時間は空きません。

僕がこういう状態で先に見るのは、プロンプトの長さやAIの性能ではなく、AIに「仕事の終わり」が伝わっているかです。

どこまで進めれば完了なのか。
何を確認できれば次へ進んでよいのか。
ここが曖昧なままでは、高性能なAIを使っても、人間が指示を出し続けることになります。

CodexのGoalは、一つの目的と確認可能な終了条件を持たせ、作業、検証、修正を複数の工程にまたがって進めてもらうための機能です。

長い指示を書くための機能というより、AIへ仕事の終わり方を渡すための機能だと考えると分かりやすいです。

ただし、何でもGoalにすれば仕事が減るわけではありません。
一問一答や記事一本には通常の依頼、実装と検証を繰り返す長い仕事にはGoalというように、任せ方を分ける必要があります。

この記事では、Goalに向いている仕事の見分け方、完了条件の作り方、実際の設定文まで整理します。

Goalは、AIの「長期運転モード」

通常のチャットでは、一つの依頼に対して、一つの回答や成果物を返すのが基本です。

記事を一本作る、返信文を考える、タイトルを出すといった仕事なら、通常の依頼で十分です。

一方、Goalは複数の工程や会話をまたいでも、一つの目的を維持したまま進めるために使います。

たとえば、次のような仕事です。

  • Webサイトの不具合を調べ、修正し、テストし、表示まで確認する
  • 大量の記事を監査し、優先順位をつけ、修正し、基準を満たすまで検品する
  • 複数ファイルにまたがる仕組みを実装し、エラーを直しながら完成させる
  • 調査、設計、制作、検証を一つの目的として進める

こうした仕事は、一回の回答だけで終わりません。
途中で新しい問題が見つかれば、調べ直しや修正も必要です。

Goalを設定すると、Codexはその場の一つの指示だけでなく、設定された目的を進行中の仕事として保持します。
作業がいったん区切られても、まだ完了条件を満たしていなければ、同じ目的に沿って続きを進められます。

ただし、大切なのは「AIを長時間働かせること」ではありません。

何をもって終わりとするのかを、始める前に決めることです。

短時間で完了するGoalも、失敗ではない

Goalの動作を確かめるために、「Goalの使い方を理解する」と設定すれば、説明が返ってきた時点で短時間でも完了します。

これはGoalが働かなかったのではなく、設定した終了条件をすぐに満たしたということです。

ここから分かるのは、Goalの価値が実行時間の長さで決まるわけではないことです。
一分で終わる目的なら一分で完了し、数時間かかる目的なら必要な工程をまたいで進みます。

機能の確認には短いGoalでも十分です。
一方、実務上の価値を確かめたいなら、一回の回答では終わらず、途中で検証や修正が必要になる仕事を設定する必要があります。

AIが途中で止まる原因は、指示の短さだけではない

AIが途中で止まった時、「もっと詳しいプロンプトを書かなければ」と考える人は多いと思います。

もちろん、必要な情報を渡すことは大切です。
ただ、長い文章を書けば自動的に最後まで進むわけではありません。

むしろ問題になりやすいのは、次のような状態です。

  • 目的はあるが、完了の判定方法がない
  • 作業範囲が広すぎて、どこから手をつけるか決まらない
  • 参考にする資料やファイルが分からない
  • やってはいけないことが決まっていない
  • 「いい感じ」「全部」「完璧に」など、確認できない言葉で終わっている

人へ仕事を頼む時でも、「サイトをいい感じに改善しておいて」だけでは、いつ仕事が終わるのか判断できません。

AIも同じです。
開始の指示だけでなく、終了の判定まで渡して初めて、自分で次の工程へ進みやすくなります。

Goalに向いている仕事の3条件

Goalを使うか迷ったら、次の3つを確認します。

1. 一回の回答では終わらない

調査して終わりではなく、調査結果をもとに実装し、テストし、必要なら直す。

このように複数の工程がつながっている仕事はGoal向きです。

2. 途中で新しい判断が発生する

最初からすべての手順を決められず、作業結果に応じて次の一手が変わる仕事です。

たとえば、不具合修正では、原因を調べるまで修正箇所が分かりません。
修正後も、テスト結果によって追加対応が必要になることがあります。

こうした「進めながら判断する仕事」は、目的を保持できるGoalと相性が良いです。

3. 終了条件を確認できる

最後に、人間とAIのどちらが見ても「終わった」と判断できる仕事です。

たとえば、次のような条件です。

  • 指定したテストがすべて通っている
  • PCとスマホの両方で表示崩れがない
  • 対象記事の警告がゼロになっている
  • 必要な成果物が指定場所にそろっている
  • 本番URLで変更内容を確認できる

Goalは、終わりのない願望を置く場所ではありません。
一つの明確な目的と、停止できる条件を持った仕事に向いています。

Goalにしない方がいい仕事

反対に、次のような依頼は通常のチャットで十分です。

  • 一つの質問に答えてほしい
  • 返信文を一本作ってほしい
  • タイトルを3案出してほしい
  • 渡した文章を要約してほしい
  • 小さな誤字を一か所直してほしい

これらは、一回の応答で完了を判断できます。

小さな仕事までGoalにすると、目的の設定や状態管理の方が重くなります。
「一回で返せる仕事か」「調査、作業、検証をまたぐ仕事か」で分けると迷いません。

良いGoalに入れたい5つの要素

Goalを設定する時は、次の5項目をそろえます。

1. 目的

何を変えたいのかを書きます。

「サイトを直す」ではなく、「スマホから記事を読む人が、表示崩れなく最後の案内まで読める状態にする」のように、仕事後の状態まで書きます。

2. 対象範囲

どのファイル、ページ、資料、期間を対象にするのかを決めます。

範囲が決まっていないと、AIは必要以上に広く触るか、反対に一部だけを見て終わる可能性があります。

3. 守る条件

触ってはいけない場所、変えてはいけない仕様、必要な承認などを書きます。

たとえば「既存の公開記事は変更しない」「本番反映前にテストする」「削除は行わない」といった条件です。

4. 完了の証拠

何を確認できたら、できたと言えるのかを指定します。

テスト結果、画面表示、件数、ファイル一覧、公開URLなど、後から確かめられるものにします。

5. 終了条件

どこまで終わったら止まるのかを明記します。

Goalが大きい場合は、途中で報告する地点も決めます。
ただし、細かい工程ごとに人間の返事を必須にすると、結局こちらが進行管理から抜けられません。

止める必要がある判断だけを残すのがポイントです。

「いい感じに改善して」ではGoalにならない

たとえば、次のGoalは終わりが曖昧です。

サイトをいい感じに改善してください。

「いい感じ」が何を指すのか分からず、どこまで進めればよいかも判断できません。

次のように書けば、仕事として進めやすくなります。

目的:
スマホで記事を読む人が、途中で表示崩れに邪魔されず、
最後の案内まで読める状態にする。

対象:
記事詳細ページと、そのページで使う共通コンポーネント。

守る条件:
既存記事の本文と公開URLは変更しない。
関係のないページには触れない。

完了の証拠:
対象ページをPCとスマホ幅で確認する。
既存テストとビルドが成功する。

終了条件:
表示崩れが解消され、確認結果と変更内容を報告したら完了。

長いプロンプトに見えますが、細かい作業手順は書いていません。

人間が決めるのは、目的、範囲、境界線、完了条件です。
その間の調査や修正方法は、状況を見ながらAIが選べます。

Goalの基本操作

CodexでGoalを始める時は、入力欄で次のように設定します。

/goal ここに達成したい目的を書く

設定中のGoalを確認する時は、次のコマンドを使います。

/goal

一時的に止める、再開する、解除する時は、それぞれ次の操作です。

/goal pause
/goal resume
/goal clear

Goalの機能がまだ有効になっていない環境では、Codexのコマンドラインで次を実行してから、Codexを再起動します。

codex features enable goals

画面やコマンドは今後変わる可能性がありますが、使い方の中心は変わりません。

一つの目的を設定し、現在のGoalを確認し、必要な時だけ一時停止や解除をする。
そして、AIが完了を判断できる終了条件を最初に渡すことです。

Goalを設定する時のテンプレート

最初は、次の形をそのまま使えます。

/goal

目的:
[仕事が終わった後に、どんな状態を作りたいか]

対象:
[対象ファイル、ページ、資料、期間]

参照するもの:
[仕様書、ルール、過去の成果物、参考URL]

守る条件:
[触らない場所、禁止事項、承認が必要な操作]

完了の証拠:
[テスト、件数、画面確認、公開URLなど]

終了条件:
[何がそろったらGoalを完了にしてよいか]

すべてを細かく書けない時も、目的と終了条件だけは省かないようにします。

この二つが決まるだけでも、AIは「何をするか」だけでなく「いつ止まるか」を判断しやすくなります。

Goalは、仕事を増やすための機能ではない

Goalを使う目的は、AIを長時間動かすことではありません。

人間が何度も続きを指示し、次の工程を決め、終わったかを確認する仕事を減らすことです。

ただし、人間の判断が不要になるわけではありません。
何を達成したいのか、どこまでAIへ任せるのか、何をもって完了とするのかは、人間が決める必要があります。

AIへ渡すのは作業の一覧ではなく、仕事の目的と終わり方です。

そこが決まれば、Codexは一問一答の相手から、複数の工程をまたいで仕事を進める相手へ変わります。

まずは、何度も「続きをお願いします」と言っている仕事を一つ選んでみてください。
そして、次に頼む作業を書く前に「何を確認できたら、この仕事は終わりなのか」を一行で決めます。

その一行が、Goalを使いこなす最初の設計になります。

関連記事: AIに仕事を任せる時は、プロンプトより完了条件を渡す

話せて、出せて、集まっても、決まらなければ売上にはなりません。
AIで空いた時間は、相手との対話に戻してこそ事業の成果につながります。

Practice Program

この記事を実践に変えるプログラム

記事で見えた課題を、知識として読むだけで終わらせず、自分の仕事の仕組みとして実装したい方へ。

Obsidian×Codex/Claude Code 自分専用AI業務システム構築・全5回実践講座

AI活用・業務効率化価格 ¥98,000

ObsidianとCodexまたはClaude Codeをつなぎ、自分の情報・知識・発信・制作・日々の業務をAIと一緒に回せる仕組みを、全5回で実装する実践講座です。

11レッスン総時間 5時間10分
この実践プログラムを見る

この記事をシェア

役立ちそうな方へ、記事のリンクを送れます。

コメントをする

関連記事

まだ他の記事で学びたい方は、今のテーマを一段深める記事からどうぞ。

コメント

まだコメントはありません。

ログインせずに投稿できます。投稿者名は「匿名」と表示されます。

0 / 1,000文字