寝ている間に仕事を終わらせる Codex /goal の教科書【保存版】

「寝ている間に仕事が終わる」これが現実味を急速に帯びています。 寝る前に指示していた実装が、朝起きたら完成していました。 1 週間分のポストをリサーチからドラフト作成まで完成していたり、設計書を渡して寝て起きたら実装が完了して動くアプリになっていたり。 これが私たちの手元でもできるようになりました。 AI に仕事を任せる、という言葉はもう何度も聞いてきました。 でも、これまでは「5 分おきに進捗を確認する自分」から抜けられなかったはずです。Claude Code や Codex のセッションを開いて、「次は何をする？」と聞かれ、「これをやって」と答え、また結果を確認する。この往復から離れられない感覚が、ずっと残っていました。 ここ数週間で、その前提が変わりました。 Codex に来た /goal というスラッシュコマンド、そして同じ時期に Claude Code 側でも /goal が実装されたことで、AI が "完了したかどうかを自分で決めずに走り続ける" という新しい働き方が普通になり始めています。 私たちはこれを「24 時間 AI 社員」と呼んでしまいがちですが、本質はもう少し具体的なところにあります。 海外ではUltimate Guideという記事が反響を呼んでおり、Codexの進化とgoalコマンドの可能性の注目が高まっています。今回の記事ではそれをベースとして、私たちの体験と独自のリサーチを加えて、/goal の本質と落とし穴まで一気に整理します。教科書として後で見返せる粒度を意識しました。 出典： https://x.com/aiedge_/status/2054569766418108797 /goal って結局何なのか 1 行で言うと、/goal は AI エージェントに完了条件を渡して、その条件を満たすまで permission なしで走り続けてもらうスラッシュコマンドです。 これまで AI とのやり取りはずっと往復型でした。 プロンプトを書く、AI が応答する、人間が確認する、次のプロンプトを書く。/goal はこの往復を「最初の 1 回の指示」と「最後の 1 回の確認」に圧縮します。 間にある「次は何？」「これをやって」「結果はどう？」の繰り返しを AI 側に任せてしまう発想です。 この設計の出発点は、Geoffrey Huntley 氏が 2025 年 7 月に提唱した Ralph Loop という考え方にあります。 AI コーディングエージェントを無限のシェルループで回し、毎回同じ指示書のファイルを読ませて、ファイルシステムをメモリとして使う。 LLM の会話履歴ではなく、ファイルと git の履歴に状態を残す。意外と素朴な発想ですが、これが「context window が溢れたら新しいエージェントが残り作業を継いで完走させる」という現代の自律エージェントの原型になりました。 Ralph Loop は 1 年弱の間、Cursor の公式プラグインや個人実装が広がる形で熟成し、2026 年 5 月になって Codex と Claude Code がほぼ同時に /goal という公式機能として実装しました。 Codex の /goal は「OpenAI's built-in Ralph Loop」と紹介されています。Claude Code側でRalph loopという思想自体はよく使われて、「ハーネス」の文脈で活用されていました。長時間タスクをClaude Codeに実行させる等の目的が多かった印象です。 私たちが触っているのは、1 年前から技術コミュニティが積み上げてきた発想の正式版です。 Codex と Claude Code はほぼ同じ時期に /goal をリリース ここで注目しておきたいのは、Codexと Claude Codeが、ほぼ同じ時期に /goal を実装した点です（若干Codexが早く、Claude Codeが追随した形） Codex 側の 0.128.0 リリースノートには「Added persisted /goal workflows with app-server APIs, model tools, runtime continuation, and TUI controls for create, pause, resume, and clear」と明記されています。 features.goals = true を設定するか、/experimental から有効化すると使えます。Codex desktop の TUI 上で /goal を作る・止める・再開する・消す、というライフサイクル操作も用意されました。 Claude Code 側も /goal を公式機能として出しました。公式docsに「Set a completion condition with /goal and Claude keeps working across turns until the condition is met」と書かれています。 早期に触った開発者からは「2026 年最も過小評価された AI 機能」と評する声まで出ています。 両者を並べて見ると、設計の重心は微妙に違います。 Codex の /goal は「persistent workflows」を強調しています。プロセスをまたいで再開できる。 長期 (multi-day) のタスクに振り切っている。一方で、現時点では experimental の位置づけで、ある種「実験フェーズの長距離ラン用」という色合いです。 Claude Code の /goal は「session-scoped」と書かれています。1 つのセッション内で完了条件を満たすまで走る。 --resume フラグを使えば日をまたいで続けることもできますが、思想としては「1 日から 2 日で終わる反復タスクを確実に着地させる」方向です。zero-configuration で、設定ファイルを書く必要がありません。 一部クラスタでも言われていますが、両社が同じ時期に /goal を出したのは偶然ではありません。AI エージェントを使う上で「人間がボトルネックになっている往復構造」を解消することが、業界全体の課題として浮上したからです。どちらが勝つかではなく、両社ともこの設計思想に到達したことに意味があります。 そして、もう一歩踏み込むと、Claude Code の側にこの /goal の本質を最もよく示すアーキテクチャ設計があります。 執行者と審査員を分けるという発明 ここが本記事で一番伝えたい話です。 Claude Code の /goal は、AI エージェントの古典的な失敗を構造的に解消する設計を持っています。 これまで自律エージェントが「終わらない」「暴走する」と批判されてきた最大の理由は、「やったエージェント自身が、完了したかどうかを判断していた」ことでした。 自分の仕事を自分で評価すると、楽観的な判断 (もうできた) も悲観的な判断 (やっぱり足りない) も両方起こります。人間の組織でも、自分の業務を自分で完了判定させると同じことが起きます。 Claude Code の /goal は、ここを別モデルに分離しました。公内部実装は session-scoped な Stop hook のラッパーです。 エージェントが 1 ターン完了するたびに、設定された小さくて速いモデル (デフォルトは Haiku) が「完了条件は満たされているか」を判定し、yes / no と短い reason だけを返します。 no なら、その reason が次のターンの追加情報として渡されます。 VentureBeat はこの構造を「Claude Code's /goals separates the agent that works from the one that decides it's done」と表現しました。 働くエージェントと、完了を判定するエージェント。仕事をする側と、検収する側。この 2 つを別モデルにすることで、自律ループが破綻する最大の failure point を構造的に外したのです。 これは業務委託に例えると分かりやすいです。 ある会社が外部に業務を委託したとき、納品物の検収を「やった本人」にさせる会社は稀です。 普通は別の担当者が検収条件を見て OK / NG を判定します。やった本人に検収させると、線引きが甘くなりやすい。Claude Code はこの組織論の原則を、AI 同士で再現しました。 Codex 側はもう少し違うアプローチで、app-server API と persisted state でセッションをまたぐ持続性を確保しています。 判定モデルを明示的に分離する設計ではありませんが、「中断と再開ができる長距離ラン」という形で同じ目的 (人間が確認し続けなくて良い) を狙っています。両社のアプローチは違いますが、向かっている先は同じです。 ここまでで「なぜ AI が走り続けられるようになったか」が見えました。次は実際に何を書けばよいのか、です。 良い /goal の 4 要素は業務委託契約書と同じです 元記事では良い /goal の構文として 3 要素が紹介されています。/goal [do the work] until [measurable end state] without [constraints that must hold] という形式で、Goal、Measurable end state、Constraints の 3 つを書きましょうという話でした。 実は OpenAI の公式ベストプラクティスでは、これに「Context」を加えた 4 要素を推奨しています。 markdown 1. Goal 何を達成するか (method ではなく outcome として記述) 2. Context 関連するファイル、ドキュメント、エラー、過去ログ 3. Constraints 守るべき標準、アーキテクチャ、安全要件 4. Done when 検証可能な完了条件 この 4 要素を並べると、ある書類に似ているのに気づきます。業務委託契約書です。 業務委託契約書には、業務内容 (Goal)、関連資料・前提情報 (Context)、守るべき制約 (Constraints)、検収条件 (Done when) が必ず書かれます。 良い /goal を書くことは、AI に対して業務委託契約書を書くことに近い行為です。発注内容、参照すべき資料、守ってほしいルール、何をもって完了とするかの判定基準。この 4 点を曖昧にしたまま外部に発注すれば、人間の業務委託でも揉めます。 具体的に良い例と悪い例を並べてみます。 良い例 (検証可能): markdown /goal すべての failing test を npm test exits 0 まで修正してください。 ただし /auth ディレクトリ以外のファイルを変更しないでください。 完了条件 (npm test exits 0) は機械的に判定できます。Haiku がコマンド出力を見れば yes / no が出ます。 悪い例 (検証不能): markdown /goal このアプリを production-ready にしてください。 「production-ready」は人によって解釈が違います。 テストが通れば OK なのか、性能要件があるのか、セキュリティ監査が必要なのか。Haiku は完了条件を判定する材料を持てません。 結果として、AI は永遠に走り続けるか、勝手に「もう production-ready」と判定して止まるか、どちらかです。 業務向けに翻訳すると、こんな例になります。 良い例 (業務向け): markdown /goal 添付の議事録テキストから ToDo を抽出して、 担当者と期限と一緒に Markdown table にまとめてください。 ただし固有名詞は ABCD で伏せてください。 完了条件: ToDo が 1 件以上抽出され、table の各行が 担当者列・期限列・タスク列を埋めている状態。 悪い例 (業務向け): markdown /goal この資料を分かりやすくしてください。 「分かりやすく」も検証不能です。誰にとって、何に対して分かりやすいのか。Haiku は判定基準を持てません。 つまり、/goal を使いこなすスキルは AI の使い方というより、業務委託の発注スキルです。AI の賢さではなく、こちらが渡す完了条件の設計で決まります。 コードを書かない人にも /goal は使えます 「/goal はコードを書く人のための機能だ」というイメージを持つかもしれません。実際、海外のバズ事例の多くはコーディング系です。 たとえば、a16z 一般パートナーの Andrew Chen 氏は、低レイヤーの eGPU と Mac の device driver プロジェクトに Codex /goal を仕掛けて、一晩そのまま放置しました。14 時間後、Codex はまだ progress を積み上げ続けていたそうです。彼は途中で一度も触っていません。 Alex Finn 氏は同じ /goal を別の方向に使い、Codex に「フルビデオゲームを構築して」と渡して 1 時間でひととおり完成させました。短時間集中型の使い方です。 他にも取引アプリのリファクタを 210 タスクのバックログとともに /goal に投げたら、6.5 時間で完走し、月 $100 の ChatGPT プランの週次クォータの 20% ほどを消費したという事例も出ています。 別の事例では、ゲーム内経済システムの移行を 18 時間ノンストップで処理したケースもあります。 極端な例としては、blank repo に GPT-5.3-Codex を Extra High reasoning で渡し、design tool を 25 時間連続でゼロから構築させた実験もあります。約 3 万行のコード、約 1,300 万トークン消費という結果でした。 ここまでは確かにコーディング系の事例です。しかし、OpenAI が公式に提示している use case の中には、コードを書かない業務がしっかり含まれています。 公式 use caseでは、四半期業績レビュー (QBR) 用のスライドデック生成が紹介されています。 プロジェクト概要、顧客の痛点、オンボーディング指標、スライドテンプレートを渡すと、Codex は executive summary、core problems、issues、example workflow、adoption signals、improvement plans、open decisions の 7 枚構成を speaker notes 付きで生成します。テキストは編集可能な形で返ってきます。 私たちの業務で /goal に向くタスクを並べると、こんな形になります。 markdown ・議事録の音声テキストから ToDo を抽出する ・週次レポートを複数のスプレッドシートから自動構造化する ・契約書のレビューで NG ポイントを抽出して指摘案を作る ・SOP を散在文書から再構造化する ・QBR や月次経営会議のスライドデック 1 次稿を作る ・顧客対応メールの下書きを過去事例から生成する ・既存業務フローの監査レポートを 1 次稿で作る この 7 つに共通するのは、「インプットがある」「アウトプットの形が決まっている」「完了が判定できる」という 3 条件を満たしていることです。/goal が機能するのは、この 3 条件が揃った業務です。 そして元記事でも触れられている、現場で効く Pro Tips をいくつか抜き出すと、こんな運用が現実的です。 markdown ・同時に走らせる /goal は 1 つだけにする ・/plan と組み合わせて、設計と実行を分ける ・チェックリスト形式の指示を渡す ・進捗を .md ファイルに書かせて、いつでも追えるようにする ・AI に「自分で /goal の指示文を書いてみて」と頼んで、上書きする 特に最後の「AI に自分で /goal を書かせる」は意外と強力です。 読者の頭の中にある曖昧な完了条件を、AI が一度言語化することで、検証可能な形に近づきます。 /goal がうまく動かない領域とちゃんと止める方法 ここまで /goal の本質と良い使い方を見てきました。同じくらい大切なのは、/goal がうまく動かない領域を先に知っておくことです。放置できる魔法ではありません。 落とし穴は大きく 5 つあります。 1. トークンの浪費 Andrew Chen 氏の 14 時間ランは「/goal がトークン消費を 1 万倍にする」という発言もしています。 長距離ランは普通のセッションとは桁違いの消費になる前提で運用する必要があります。事前に OpenAI 側で spending limit のハードキャップを設定して、billing の自動チャージを切っておく。これだけで一晩で大きな請求が立つリスクを抑えられます。 2. 暴走ループ GitHubでは「My Codex got stuck in a thinking loop, drained all my usage, and I think it messed up all my code」という生の苦情が立っています。 完了判定が収束しないと、エージェントが thinking 状態でループし、トークンを使い切ったうえにコードまで破壊することがあります。 /goal pause と /goal clear で必ず止められる手段を覚えておく必要があります。同じく issue #14094 / #14048 には「Prompt permanently stuck on Thinking」「CLI hangs indefinitely」も報告されています。 3. 検証不能な領域 Tecton & Tide blog の解説に「Missing stop rules are the largest operational failure mode for /goal」という指摘があります。 Done when を機械的に判定できないタスクには /goal を使うべきではありません。具体的には、UX polish、文章のトーン調整、デザインの審美性、production-ready の判断。これらは Haiku が yes / no を返せない領域です。結果として、AI は永遠に走るか、勝手に「完了」と判定するか、人間より雑な判定で止まります。 4. 外部副作用 メール送信、決済処理、本番 API への書き込み。これらを完了条件に含むタスクには、constraints の節で明示的にハードコンストレイントを書く必要があります。 AI は constraints に書かれていないことを caution せず、構造上は実行できてしまうからです。元記事の例「fix every failing test ... without modifying any file outside the /auth directory」のように、何をやらないかを明示するのが安全側の運用です。 5. コンテキスト・ドリフト 長時間 /goal を走らせている間に、コードベースが他の開発者によって変わったり、元の要件が更新されたりすると、AI は古い前提で走り続けます。実コード変更を伴うタスクは、定期的に pause して状況を確認する運用が安全です。 止め方のライフサイクルは公式に整備されています。 markdown /goal & <objective> 目標を設定する /goal 現在の目標を表示する /goal pause 一時停止する /goal resume 再開する /goal clear リセットする Codexでは TUI 上でも create / pause / resume / clear が操作できます Tecton & Tide の検証では、6 時間走った /goal が 5 時間の pause を挟んでも resume で続行できた、と報告されています。つまり、一時停止して状況確認、必要なら微修正、再開、という運用が成立しています。 魔法のように放置できるわけではありません。ただし、ライフサイクルを正しく握れば、寝ている間に長距離ランを回し、朝起きて状況を確認して再開する、という働き方が成立します。 業務を完了条件で定義できる人が今後さらに有利に ここまでの整理を、自分の業務に持ち帰る形で締めくくります。 /goal を使えるかどうかは、AI の性能で決まりません。業界トレンドで決まりません。決定打になるのは「自分の業務で、やった本人ではない別の何かが判定できる完了条件を書けるか」という、こちらの設計スキルです。 これは KPI 設計と同じ構造です。 良い KPI は、誰が見ても達成しているかどうかが判定できます。曖昧な KPI は組織を疲弊させます。同じ原則が、AI へのタスク委託にもそのまま適用されます。 今日からできるのは、自分の業務を見渡して、「完了条件が明確に書けるタスク」を 1 つだけ抜き出してみることです。 議事録の ToDo 抽出、月次レポートの構造化、契約書の NG ポイント抽出、SOP の整理、QBR のスライドデック 1 次稿。どれでも構いません。 1 つ書き出して、4 要素 (Goal / Context / Constraints / Done when) で言語化してみる。それが /goal を業務に持ち込む最短ルートです。 最後にこの記事の整理をチェックリストにまとめます。 /goal は完了条件を満たすまで AI が permission なしに走り続けるスラッシュコマンド。Codex 0.128.0 と Claude Code 2.1.139 がほぼ同時期に実装した。 本質は「24 時間 AI 社員」ではなく、執行者 (大型モデル) と審査員 (Haiku) を分離する設計。自分の仕事を自分で判定させない構造。 良い /goal は 4 要素 (Goal / Context / Constraints / Done when) で組み立てる。業務委託契約書と同じ構造で書ける。 コードを書かない業務にも使える。SOP 構造化、QBR スライドデック、議事録 ToDo 抽出、workflow audits などが公式の use case として整備されている。 落とし穴は 5 つ。トークン浪費、暴走ループ、検証不能な領域、外部副作用、コンテキスト・ドリフト。事前の spending cap と/goal pause / resume / clear のライフサイクルで握る。 /goal を使えるかは「業務を完了条件で定義できるか」というKPI 設計と同型の問いに帰着する。 私たち東大Codex研究所（ @UT_Codex ）はCodexを中心としたAIエージェントの実務での活用を徹底研究するメンバーで構成された東大チームです。 フォローするとこういった情報と知見が手に入ります👇 ・現場で使えるCodexの設計や導入方法 ・独自開発したSkillsや業務特化型エージェントパックの無料公開 ・Codexに関するアップデート情報 東大での研究技術とビジネス活用の掛け合わせた有益な発信ができるのはこのアカウントだけ。ぜひフォローをお願いします！