OpenAIが与えるもの Codex CLI という新しいコマンドを追加した。 /goal。
ゴールを設定すれば、何ラウンドも走り続け、コンテクストを失わず、ゴールにたどり着くまで止まらない。
この機能はCodex CLIバージョン0.128.0でリリースされましたが、まだ実験的なもので、手動でオンにする必要があります。CodexチームのFelipe Couryはこのように説明しています：
“「複数ラウンドにわたってゴールを維持する。到達できなくても止めない。
めどがたつまであきらめない
そして私見ではあるが、実はこの機能の裏にはあるトレンドが隠れている：AIの時代において、プロセスはそれほど重要ではなくなりつつある。
01
Ralph Loop
理解する /goalまずはラルフ・ループについて話す必要がある。
この名前は、ザ・シンプソンズに登場する「無知でしつこく、楽観的な」少年、ラルフ・ウィガムに由来する。開発者のGeoffrey Huntleyは、彼にちなんでエージェントループと名付けました。エージェントにゴールを設定し、それ自体を反復させ、失敗したらゴールに達するまでやり直します。
VentureBeat』は、「ラルフ・ウィガムはいかにしてシンプソンズからAI界で最もホットな名前になったか」という記事まで書いている。
コミュニティのオリジナルの実装では、ラルフ・ループのアプローチはもう少し "暴力的 "だった。各ラウンドの終了時に、エージェントは新しいコンテキスト・ウィンドウをゼロから開始し、gitログとプログレス・ファイルを頼りに記憶を維持する。
シフトが変わるたびに引き継ぎ書を渡すのと同じことだ。
そしてコーデックスの /goal 他方で、彼は別の道を歩んでいる。
それはプロセス内の連続ループこの場合、新しいコンテクストを一から始めることなく、同じセッションでラウンドをまたいでもターゲットはアクティブなままである。
言い換えれば、ラルフ・ループは駅伝のようなもので、バトンごとに新人が入ってくる。
リレー vs マラソン
そしてコーデックスの /goalというより、スタートからゴールまで走り続け、疲れたら一時停止することができるマラソンランナーのようなものだ。
02
使用方法
使い方は簡単だ。
Codex CLIのバージョンが0.128.0以上であることを確認し、設定ファイルの ~/.codex/config.toml 段落を追加する：
●●●
[features]
goals =true
└
開いたら、Codex CLIに入力する：
●●●
/goal 重构所有的数据库查询，添加连接池
└
Codexはこのゴールを目指して作業を開始し、コードを書き、テストを実行し、結果をチェックする。
指示を受ける。
さらに、いくつかの補助コマンドもある：
• /goal pause現在のターゲットを一時停止する
• /goal resume中断していたターゲットの再開
• /goal clearクリアランス目標
Ctrl+Cキーを押して中断すると、ターゲットは自動的に一時停止され、次にスレッドを再開すると自動的に再開される。
実用的なヒントとしては、ゴールの説明が長すぎる場合、それを直接コマンドに書くのは間違っている可能性があるということだ。詳細な指示を .md ファイルを作成し /goal follow instructions.md を実行する。
これは私がずっと前に何度も何度も勧めてきたテクニックで、ファイルに入れることで文脈によって圧縮されず、ディテールが失われないという利点もある。
このバージョンには /side コマンドを使うと、一時的にブランチセッションを開いて、メインラインのターゲットを中断することなく質問をすることができます。終わったらEscキーを押してメインラインに戻り、ブランチセッションは破棄されます。この2つのコマンドは非常によく連動します。
しかし......これは盗作の疑いを避けるためであるはずだ。 Claude クロード・コードは/btw機能を追加した。
03
止まらないけど、バカじゃない。
自動的にループするエージェントの最大の懸念は、意味のないことで空回りしないかということだ。
コーデックスの実施には、一連の保護メカニズムが含まれている。
ツールによる通話抑制はゼロ。もしエージェントが1ラウンドの継続中に何もツールを呼び出さなかった場合（コードが書かれず、コマンドが実行されず、ファイルが読み込まれなかった場合）、システムは「スタック」と判断して自動的にループを停止し、新しい入力があるまでループを再トリガーしません。
予算管理。各ターゲットは設定可能 token 予算と時間の上限。消費量が予算を超えると、システムはモデルにプロンプトを表示する：新しいタスクを開始せず、進捗状況を要約し、ユーザーに明確な次のステップを与える。
3本の鎖につながれたロボット犬
監査プロトコルの完成各走行の開始時に、システムは隠れた開発者コマンドをモデルに注入し、一連の「完了監査」を実行するよう求める：
1.目標を具体的な成果物に分解する
2.チェックリストを作成し、各要件と実際の証拠を対応付ける
3.実際の文書、出力、テスト結果の検討
4.単に「テストに合格した」というだけで、目標が達成されたと考えることはできない。
つまり、このシステムはメカニズム・レベルのモデルでよくある問題を防いでいるのだ：何かを生産した」を「目標を達成した」と勘違いしている。。
テストがパスしたからといって、その機能が完全であるとは限りませんし、コードが書かれたからといって、要件が満たされているとも限りません。この「代理証拠受け入れ」は、エージェント・ループにおける最も陰湿な失敗モードの1つである。
04
ソースコード解析
コーデックスはオープンソースなので、どのように実装されているかは一目瞭然だ。私はコードを更新し、AIに反転させてもらった。
この関数のコアロジックは codex-rs/core/src/goals.rs Rustの場合、約1570行のRustコードだ。
システム全体は3層構造になっている：
永続的なレイヤー： ターゲットの状態はSQLiteデータベースに存在し、プロセスの再起動やスレッドの再開時に失われることはありません。ターゲットには、Active、Paused、BudgetLimited、Complete の 4 つの状態があります。
ツールレイヤー： このシステムは、モデルに対して3つのツールを公開する：get_goal(現在のターゲットを読む）、create_goal(目標の作成）、update_goal(目標ステータスの更新）。
三層アーキテクチャ
ここには重要な設計上の決断がある：モデルはゴールを「完了」とマークするだけで、一時停止や再開はできない。 サスペンドとレジュームはユーザーしかできない。
ソースコードのロジックはこうだ：
●●●
if args.status != ThreadGoalStatus::Complete {
return Err(FunctionCallError::RespondToModel(
"update_goal can only mark the existing goal complete"
));
}
└
なぜそのような設計になっているのか？
これは、モデルが勝手に "怠け者 "になってしまい、もう少しで終わりそうだと思ったときに一時停止してしまうのを防ぐためだ（これは経験ではないだろうか？）.
そこから、あなたがゴールを設定した後、モデルはそれを達成するか、あなたが来てそれをやめるかのどちらかだ。
第3の道はない。
レイヤーを走らせ続ける： これが最も中心的な部分だ。各ラウンドの終わりに、システムは一連のチェックを行う：
1.ターゲット機能が有効かどうか
2.現在アクティブなターゲットの有無
3.他のラウンドが行われているかどうか
4.保留中のメッセージキュー
5.ランの継続が阻害されたかどうか（前のラウンドでツールコールがゼロだったかどうか）
6.現在プランモードかどうか（プランモードではターゲットは無視される）
すべてのパスが終わると、システムは目的、予算使用量、監査を完了するためのプロトコル一式の説明を含む開発者メッセージを注入する。そして新しいラウンドが始まる。
もうひとつ細かいことがある：トークンの計算では、キャッシュされていない入力トークンと出力トークンのみがカウントされる。 キャッシュヒットは予算にカウントされない。つまり、予算は「追加された仕事量」を追跡するものであり、既存のコンテキストの再読み込みに料金はかからない。
この機能の開発者は、PythonのタイプチェッカーであるPyrightの作者であり、フェリペ・クーリーが「毎日一緒に仕事ができるゴアットの一人」と呼ぶエリック・トラウトである。
05
実験機能
もちろんだ。/goal 結局のところ、これはまだ実験的な機能であり、現時点ではいくつかの制限がある。
現在はCLIでのみ利用可能で、Codexデスクトップアプリにはまだ搭載されていない。
また、APIクォータがなくなった場合。/goal リクエストを送り続け、クォータエグゾーストエラーを受け続け、再試行し続ける......これを「エラーのラルフループ」と呼ぶ人もいる。
計画モードでは、目標システムは自動的に無視される。つまり、プランとゴールを同時に設定することはできず、この2つのモードは互いに排他的である。
それは理解できる、目標は良い目標を設定することだ。
しかし、現在のゴール完了判定は、依然として「早期終了」の問題に悩まされている。表面的な作業しか完了していないにもかかわらず、成果物を生成しただけでゴールが完了したと判断してしまうことがある。
06
最も重要なのはゴールだ。
/goal コードの量は少なく、コンセプトも複雑ではない。しかし、おそらくほとんどの『メジャーアップデート』よりも意味のある方向性を表していると思う。
なぜなら、AIが変えるのは能力の境界線ではなく、その能力だからだ。人とAIのコラボレーション・インターフェース。
あなたがあることを言えば、私は別のことをする」から「あなたが目標を設定し、私はすべてのプロセスに責任を持つ」まで。
対話』から『委託』になった。
その背景には、機能そのものよりも、「終わり＝始まり」という考え方の転換がある。
また、今は基本的に、自分のプログラミングで実際にコードを書くプロセスにはあまり関与していない。より多くの時間とエネルギーを費やしているのは、「自分はいったい何を達成しようとしているのか？このゴールが実際に達成されたことをどうやって確認すればいいのか？
どうやって正しい目標を設定するのか、どうやって具体的に何をするのかを考えるのか。これが実は、より試される重要な判断であり、仕事なのだ。
かつての私たちは、まずステップを計画し、それを一歩一歩実行し、すべてのステップを人々が見守るという「プロセス指向」の仕事のやり方に慣れていた。
しかし、AIエージェントはその論理をひっくり返そうとしている：あなたが定義する必要があるのは終点だけで、経路はエージェント自身です。
従来のプログラミングとの違いは、ナビゲーションアプリと手書きの地図の違いのようなものだ。手書きの地図の時代には、自分でルートを計画し、すべての交差点を覚えておく必要があった。ナビゲーションの場合、目的地を入力するだけで、どの道を通るか、渋滞をどう避けるか、どこで右折するか、それがナビゲーションの問題だ。
プロセス志向と目標志向
そしてカルパシーも、先日のAI Ascentの講演で同様の判断を示した。彼は、このトレンドをソフトウェア3.0と要約した（前回の記事を参照：ソフトウェア3.0の時代が到来）：
“「従来のソフトウェアが指定できることを自動化するのに対し、AIは検証できることを自動化する。
3世代のソフトウェア・パラダイムの進化の主な糸は、人間の関わり方の変化である。
How（機械に何をすべきかを伝える）から、Show（機械に何をすべきかを示す）、そしてWhat（機械に何を求めるかを伝える）へ。
著者 → コーチ → 指揮官
/goal これはこのスレッドの最新の脚注のようなものだ。
あなたは、検証可能な最終状態であるゴールを定義します。あなたは結果を検証し、エージェントはプロセスを処理します。
エージェントが自らの進歩を管理し始め、設定した目標を実際に達成できるようになれば、人間に残された仕事はただひとつ：
自分が本当に欲しいものは何かを見極める。
◇ ◆ ◇
- Codex CLI オープンソースリポジトリ: https://github.com/openai/codex
- フェリペ・クーリのオリジナル投稿：https://x.com/fcoury/status/2049917871799636201
- ラルフ・ループ・コミュニティの実現：https://github.com/Th0rgal/open-ralph-wiggum
