アイデア

Codex `/goal` は開発ループを変えた

Codex `/goal` はエージェント作業をプロンプトごとの操作から、完了条件を事前に定義するゴール駆動ループへと変える。

2026-05-06

ここ数日、Codex の /goal コマンドを掘り下げている。

一見すると別のエージェント機能のように見える。しかし、いつ現れたか・どう表面化したか・どう振る舞うかを追うと、明らかになる：

これは UX の改善ではなく、新しい実行プリミティブだ。

`/goal` が実際にどう表面化し気づかれたか

2026/04/30 Codex CLI v0.128.0 が静かに /goal を導入 -> リリースノートに埋もれ、ハイライトされなかった
同時期 Simon Willison を含む早期のレポートが確認：

/goal は組み込みの Ralph ループのように振る舞う
2026/05/01-06 X、LinkedIn、ブログを横断したソーシャルな広がり：
- "Ralph loop++"
- "何時間・何日も実行できる"
- 長期タスクのデモが現れ始める

これは正式なローンチではなかった。ある能力が公の視野に表面化したようなものだった。

Codex の機能リストでの位置づけ

注目すべきは：

/goal は公式機能に目立って列挙されていない
必要なのは：
- CLI のアップグレード
- 手動のフィーチャーフラグ

これが強く示すのは：

shipped されているが、stable とは宣言されていない

有効化と使い方

1. バージョン確認

codex --version
# >= 0.128.0 である必要がある

2. フィーチャーフラグを有効化

# ~/.codex/config.toml
[features]
goals = true

3. ゴールを開始

/goal build a REST API with tests and docker support

4. ライフサイクルを制御

/goal pause
/goal resume
/goal clear

停止条件

ゴールが達成された
トークンバジェットが枯渇した

"done" が不明確なら、動き続ける。

これは根本的に開発インタラクションモデルを変える

これまでこう動いていた：

プロンプト -> 出力 -> 反復

AI ツールがあっても、人間がループを駆動していた。

/goal では：

ゴール -> エージェントループ -> アーティファクト

ステップをオーケストレーションするのをやめる。終端状態を定義する。

これは本質的に組み込みの Ralph ループだ

スクリプトと DONE フラグで Ralph ループを実装したことがあるなら、このパターンはおなじみだ。

しかし /goal はそれをランタイムに内蔵する：

側面	Ralph ループ	`/goal`
ループ制御	外部	ランタイム管理
状態	ファイル	内部
継続	手動	自動
ライフサイクル	DIY	pursuing / paused / achieved

キーとなるシフト：

ループがインフラからランタイムコントラクトへ移る

現在の状況、現実的に

早期使用とレポートから：

まだフィーチャーフラグの後ろ
ドキュメントが限られている
長期実行が不安定
実世界の統合周りで脆弱
ゴールが曖昧だとトークンを燃やしやすい

なので、これは strong beta であり、まだ production-ready ではない。

本当のシフト：プロンプト -> ゴール

実際に変わるのはツールだけではない。思考だ。

以前：

次に何を聞くべきか？

今：

done とは実際何を意味するのか？

成功は今や以下に依存する：

明確な成果物
境界のあるスコープ
明示的な完了基準

システム観点からこれが重要な理由

私はずっと以下に取り組んできた：

仕様駆動のワークフロー
CI ベースの実行ループ
エージェント + ランナーのオーケストレーション

/goal はほぼ直接マップする：

仕様 -> ゴール -> ループ -> アーティファクト -> デプロイ

以前：

ループは CI とスクリプトの中にあった

今：

ループはランタイムのネイティブ機能

つまり：

/goal は効果的に標準化されたエージェントループランタイム v1 だ

これがどこへ向かうか

shipped されている方法から：

近期：ループを安定させ、フィーチャーフラグを外す
中期：ライフサイクルの可視性とオブザーバビリティを追加
後期：CI とクラウドランタイム統合を接続

その時点で：

自律的なエンジニアリングワークフローのコアプリミティブになる

現在の見解

機能として -> 印象的
プロダクトとして -> 早い
方向性として -> ほぼ必然

これはエンジニアリング作業を会話から実行可能な目標へと変える第一歩のように感じる。

/goal が実際にどう表面化し気づかれたか