Codex の goal は、長い仕事の頼み方を変える

Codex を長い仕事に使うとき、いちばん難しいのは「賢く答えさせること」ではありません。途中で目的がぼやけないように、最初に何をもって完了とするかを決めることです。

最近、X のブックマークで Codex の goal 機能に関する短いチュートリアルを見ました。表面だけ見ると、隠しコマンドの紹介に見えます。でも、公式ドキュメントと手元の Codex CLI を確認すると、面白い点は別にあります。

これは新しい魔法のボタンではなく、長いタスクを「目標、制約、検証、停止条件」に変換するための作業習慣です。

何が確認できたか

OpenAI の Codex CLI ドキュメントでは、goal は experimental な機能として説明されています。利用するには features.goals を有効にする必要があります。設定した目標は現在のスレッドに紐づき、必要に応じて一時停止、再開、クリアできます。

別の公式ページでは、goal は長時間の作業に向いていると説明されています。たとえばコード移行、大きなリファクタリング、実験、ゲームやサイドプロジェクトのように、一回の返答では終わらず、検証しながら進める仕事です。

手元の Codex CLI でも、goals は experimental で、初期状態では無効でした。つまり、この記事を書いている時点では、安定機能として断言するよりも、試験的な長時間作業の仕組みとして扱うのが正確です。

たとえば、こう頼むことがあります。

「このサイトを改善して」

短いのが問題なのではありません。何が改善なのか、どこを触ってよいのか、どう確認すれば完了なのかが書かれていないことが問題です。

Agent は途中で何かを直し、また別の問題を見つけ、さらに別の修正を始めます。会話が長くなるほど、最初の目的はチャットの流れの中に沈んでいきます。

goal が効くのは、ここです。やることを会話の一文ではなく、スレッドの目標として外に出します。これによって、Agent は毎回「この作業は何のためか」に戻りやすくなります。

向いているのは、成果物と検証方法がある仕事です。

逆に、ただ「よくして」「いい感じにして」「もっと高級にして」のような依頼は向いていません。goal にしても、曖昧な願望が状態欄に移動するだけです。

長いタスクを頼む前に、次の 5 行に分解すると扱いやすくなります。

たとえば、ブログ公開フローを整えるなら、こう書けます。

「ブログ公開フローを再現可能にする。トップページの見た目は変えない。最初に既存の公開スクリプトと直近の公開記録を読む。テスト記事を生成し、ローカル公開、記事ページ、一覧、カバー画像、デプロイ結果を確認する。すべて通ったら公開記録を書いて止まる。」

この文章は長くありません。でも、Agent にとってはかなり違います。目的、禁止事項、読むべきもの、確認方法、終了条件が入っているからです。

goal を使う前に、少なくとも一つは検証方法を決めておきます。

コードならテスト、型チェック、ビルド、スクリーンショット比較。記事なら公開ページ、画像パス、リンク、タグ、公開記録。調査なら一次情報、引用元、未確認事項のリスト。

検証方法がないタスクは、まず goal にする前に小さくする方がよいです。いきなり長時間走らせるより、最初に計画を出させる方が安全です。

goal は実験機能です。バージョンや画面によって挙動は変わる可能性があります。公式ドキュメントは主に Codex CLI を説明しており、デスクトップアプリでの表示や操作が常に同じとは限りません。

また、goal はコストを下げる機能ではありません。長い仕事を任せれば、当然 token も時間も使います。大事なのは、長く走らせることではなく、走らせる前に「どこへ向かうか」を決めることです。

私の理解では、goal の本質は自動運転ではありません。作業の契約です。

Agent に長い仕事を任せるなら、まず目標を短くするのではなく、検証できる形にする。これだけで、途中で散らばるタスクはかなり減ります。