ループエンジニアリングとClaude Codeの/goalコマンド（2026年6月）
今回は、最近話題に上がるループエンジニアリングの考え方と、その文脈で注目されているClaude Codeの/goalコマンドの仕組みと使い方の備忘録です。
/goalコマンド はv2.1.139（2026年5月）で追加された比較的新しい機能です。本記事は2026年6月時点の公式ドキュメントと各種解説記事に基づいており、仕様は今後変わる可能性があります。
この記事のターゲット
Claude Codeの/goalコマンドで何ができるのか知りたい方
エージェントに長時間の作業を任せる仕組みの全体像を知りたい方
プロンプトエンジニアリングからループエンジニアリングへ、という流れを把握したい方
ループエンジニアリングとは
ループエンジニアリングは、人間がエージェントに毎回プロンプトを打つのをやめ、「エージェントにプロンプトを与えるシステム（ループ）自体を設計する」実践を指す言葉として巷で使われています。
きっかけは、Claude Codeの開発責任者であるBoris Cherny氏の発言です。同氏は2026年6月初旬のインタビューで「私はもうClaudeにプロンプトしない。私の仕事はループを書くことだ」と述べ、このクリップが広く拡散しました。同じインタビューでは、直近30日間のプルリクエスト259件がすべてClaude Code製だったことも紹介されています。
この流れは、エージェント活用の抽象度が段階的に上がってきた延長線上にあります。
プロンプトエンジニアリング: 1回の指示の質を高める
コンテキストエンジニアリング: コンテキストウィンドウに何を入れるかを設計する
ハーネスエンジニアリング: 1回のエージェント実行の装備（設定・制約・自動化）を設計する
ループエンジニアリング: 何をいつプロンプトし、結果を受け入れるかをシステムに決めさせる
エージェントが内部で「推論して、行動して、結果を観察する」を繰り返すこと自体は、2022年のReAct論文以来のもので新しくありません。新しいのはその外側の層です。トリガー、検証可能なゴール、作る側とチェックする側の分離、隔離された作業環境、外部化されたメモリといった部品が、自作スクリプトではなく製品の標準機能として揃ったことで、「エージェントが人間の次のメッセージを待たなくなった」状態が現実的になりました。
ループを構成する要素
ループは次の部品で構成されます。
トリガー
定期実行の仕組み、Claude Codeでは/loopコマンド、Hooks、GitHub Actions連携が該当
ワークツリー
エージェントごとに独立した作業ディレクトリを与えて編集の衝突を防ぐ
Skills
ビルド手順や規約といったプロジェクト知識を持つアセット
MCPコネクタ
イシュートラッカーやSlackなど実際のツールとの接続
サブエージェント
コードを書くエージェントと検証するエージェントを分離
永続メモリ
TODO.mdのようにコンテキストウィンドウの外へ状態を保存
コードを書く側と検証する側を分ける理由について、Osmani氏は「コードを書いたモデルは、自分の宿題の採点が甘すぎる」と表現しています。Skillsがなければ、ループは毎サイクル、プロジェクトをゼロから推測し直すことになるとも述べています。巷ではClaudeとセットでOpen AIのCodexを使う組み合わせをよく見かけます。
このうち実践者が一致して強調しているのが検証の設計です。テスト、型チェック、Lintのような「NoGoと言える何か」がループに入っていないと、エージェントが自分の出力に同意し続けるだけのループになってしまいます。
/goalコマンドの仕組み
/goalコマンドは、ループの「完了をどう判定するか」を製品の標準機能として提供するものです。OpenAIのCodex CLIが2026年4月に同種の機能を実験的に先行搭載し、Claude Codeは約1か月後のv2.1.139で追随しました。
基本的な使い方
/goal <条件> で完了条件を設定すると、その条件を指示として1ターン目が始まります。以後、毎ターン終了後に条件の成立が自動で判定され、未成立ならClaudeが次のターンを自動で開始します。条件が成立するとゴールは自動解除されます。
コマンド | 動作 |
| 条件を設定する（最大4,000文字。1セッションにつき1ゴール） |
（引数なし） | 状態を確認する（条件・経過時間・ターン数・トークン消費・直近の判定理由） |
| 途中で解除する |
| 非対話モードで完了まで実行する（CI/cron向け） |
注意点として、/clear で会話をリセットするとアクティブなゴールも消えます。また --resume でセッションを再開するとゴールは復元されますが、ターン数やトークンのカウンタはリセットされます。
完了判定の仕組み
/goalの実体は、セッション単位で設定されるプロンプトベースのStop hookのラッパーです。毎ターン終了時に、条件と会話全体が小型・高速なモデル（既定はHaiku）に送られ、Yes/Noの判定と短い理由が返ります。
「No」の場合、その理由が次のターンへのガイダンスとしてClaudeに渡されます。フックの仕組みに乗っているため、フックを無効化する設定がある環境では使えません。
ここで押さえておきたい仕様として、「判定役のモデルはツールを呼ばない」があります。コマンドの実行もファイルの読み込みもせず、Claudeが会話に表出させた内容だけで判定します。
つまり条件は、「Claude自身の出力で達成が証明できる形」で書く必要があります。この性質は、後述する条件の書き方と運用上の注意点の両方に関わってきます。ちなみに、判定にかかるトークンは小型モデル側に課金され、公式ドキュメントでは「メインターンの消費に比べ通常は無視できる程度」らしいです。
関連機能との使い分け
公式ドキュメントには、類似機能との比較が載っています。
方式 | 次のターンの契機 | 停止条件 |
/goal | 前のターンの終了 | 別モデルが条件成立を確認 |
/loop | 時間間隔の経過 | 手動停止またはClaudeの完了判断 |
Stop hook | 前のターンの終了 | 自作のスクリプト/プロンプトが判断 |
auto mode | （ターン内のツール承認のみ） | なし |
/goalは「検証可能な終了状態がある大きめの作業」向け、/loopは「デプロイ監視のような定期ポーリング」向け、Stop hookは「全セッション横断の恒久ルール」向けという整理です。auto mode（ツール承認の自動化）は競合ではなく相補的な関係で、auto modeがターン内のツール承認を、/goalがターン間の継続を自動化します。
公式が挙げる想定ユースケースは以下のようです。
モジュールのAPI移行（全呼び出し箇所がコンパイルとテストを通過するまで）
設計ドキュメントの実装（全受け入れ基準が成立するまで）
巨大ファイルの分割
ラベル付きissueバックログの消化（キューが空になるまで）
ゴール条件の書き方
条件に含める要素として、公式ドキュメントは次の内容を挙げています。
計測可能な終了状態をひとつ（テスト結果、ビルドの終了コード、ファイル数、空のキューなど）
証明方法（「
npm testがexit 0で終わる」「git statusがクリーン」のように、何をもって達成とするか）達成のために壊してはいけない制約（「他のテストファイルは変更しない」など）
条件文には、「20ターンで停止する」のような上限も含めることが推奨されています。ただしこの上限は機械的に強制されるものではなく、判定役のモデルが会話から判断するものです。
良い条件と悪い条件の差は、実際の報告を見るとわかりやすいです。「npm testとnpm run lintが警告・エラーなしで通る」のような条件は安定して機能した一方、「ダッシュボードを改善する」のような条件では計測対象がなく、進捗のないままトークンを消費し続けるか、判定役が達成を誤認しやすいようです。ちゃんと完成を定義しましょうということなのだと思います。
もうひとつ知られているのが、「測ったものだけが満たされる」という性質です。あるゲーム開発で検証項目（ビルド成功、自動プレイテストの通過など）だけを条件にしたところ、全項目を通過しつつ、画面は「三角形と点と星3つ」というゲームが完成したそうです。チェック方法だけでなく欲しいものを書く、形容詞ではなく参照物（プロトタイプやデザインファイル）に条件を向けるのが望ましいようです。
運用の注意点
auto modeとの併用と隔離
無人で回すには、auto modeとの併用が前提になります。これを設定しないと、最初のツール承認プロンプトでループが止まります。「夜間に走らせたつもりが、1時間で止まっていた」という報告の原因はたいていこれです。
また、実行環境の隔離も推奨されています。新規ブランチか使い捨てのサンドボックスで実行し、結果がおかしければブランチごと捨てる運用です。いきなり夜間の長時間実行に進むのではなく、まず30分ほど監視しながら走らせて、判定役が返す理由を眺めてから段階的に広げるのが現実的です。
「achieved」を信用しすぎない
前述の通り、判定役は会話の内容だけを読んでいて、テストもビルドも自分では実行していません。
そのため「テストは通るはずです」のような自信ありげな要約でも、判定が通ってしまう余地があります。条件に「実際に実行して出力を示すこと」を明記する、達成後は同僚のプルリクエストを見るのと同じやり方で自分で検証する、という運用が推奨されています。
コストには機械的な上限がない
トークンや金額の上限を機械的 に強制する仕組みは/goalにはありません。条件文に書いた「40ターンで停止」も判定役の判断に委ねられるため、強制力は弱めです。
判定そのもののコストは小さく、コストの本体はターン数です。実地報告では、集中したコードタスクは10〜25ターン程度で完了することが多く、恒常的に30ターンを超えるならスコープが大きすぎるシグナルとされています。
対策としては、/goal（引数なし）でターン数とトークン消費を定期的に確認すること、CIや夜間実行ではSDK/非対話モードの --max-turns のような機械的に効く上限を併用することが挙げられています。14時間の夜間実行が週間のトークン上限を使い切ったという事例もあり、「Ctrl+Cを押せる状態でいる」ことが公式・実務の双方で前提とされています。
/goalが向かない作業
公式ドキュメントと各種解説で一致しているのは、次のような場面では/goalを使わないという点です。
「見栄えがよい」「楽しい」のように、完了の判定が人間の主観的な判断に依存する作業
終了条件のない探索的・創造的な作業
定期的なポーリング（/loopが適切）
チーム横断で常に効かせたいルール（設定ファイルのStop hookが適切）
変更を1件ずつレビューしたい場合や、本番クリティカルなコードベース
まとめ
/goalコマンドについて押さえておきたいポイントは次の4つです。
完了条件を設定すると、毎ターン終了後に別の小型モデル（既定はHaiku）が達成を判定し、未達ならClaudeが次のターンを自動で開始する
判定役はツールを実行せず、会話に表れ た内容だけで判定する。条件は「出力で証明できる形」で書く
条件には、計測可能な終了状態・証明方法・制約・ターン上限を含める
トークンの機械的な上限はないため、監視と隔離を前提に段階的に使う
ループエンジニアリングという言葉自体はまだ新しく、命名者のOsmani氏自身が「無人で走るループは、無人でミスをするループでもある」「ループ設計はプロンプトエンジニアリングより難しい」と最も慎重な立場を取っています。
同氏は記事を「Build the loop. Stay the engineer.（ループを作れ。ただしエンジニアであり続けろ）」と締めくくっています。直接プロンプトを打つことが不要になったというより、検証と境界の設計という新しい仕事が増えた、と捉えるのがよさそうです。
