AI エージェントを「最後までやり切らせる」 goal-loop という Agent Skill を作った話

Last updated at 2026-06-22Posted at 2026-06-21

こんにちは、AI エージェントに仕事を頼んだのに「途中までやって満足げに止まる」のを何度も見てきたアーキテクトのやまぱん！です 😅
補足コメントや質問、いいね、拡散、ぜひお願いします 🥺！
間違っていたら 優しく 教えてください！

今回は、自作の Agent Skill goal-loop を紹介します。
ざっくり言うと「ゴールに到達するまでエージェントを回し続ける」ための設計を、SKILL.md 本体＋判断基準の参照ファイル群としてまとめた Skill パッケージです。

用語補足：Agent Skill とは、AI エージェントに「この種のタスクではこう動いて」という手順や判断基準を渡す、Markdown ベースの拡張のことです。SKILL.md に書いた内容を、エージェントが必要なときに読み込んで使います。

TL;DR

AI エージェントは賢いのに、「途中で止まる」「やってないのに完了宣言」「同じ失敗を繰り返す」「逆に暴走する」の 4 つでよくコケます
goal-loop は、最初にゴールと完了条件を固定 → 作業を委譲 → テストやビルドの結果（外部シグナル）で検証 → 評価 → 多層の停止条件で打ち切り、という 7 フェーズのループにそれを落とし込んだ Skill です
キモは「自己採点だけで完了にしない」こと。exit code のような外部の合否を一次情報にして回します
巷で「ラルフループ」と呼ばれる素朴な無限ループとは出自は別ですが、結果的に近いところを狙った近縁パターンです
すでに第三者が使ってみたレビュー記事も書いてくれています（shahin0809 さんの記事）。本記事は「作者視点で、なぜこう作ったか」を中心に書きます

先に結論

私がこの Skill で言いたいことは 1 つです。

「やり切る」をエージェントの気分に任せず、止め方と進め方をルール化しよう。

エージェントの能力が足りないのではなく、「どこまでやれば終わりか」「どう進めば前進か」「いつ諦めて人に振るか」が曖昧なまま走っているから、途中で止まったり暴走したりするわけです。
goal-loop は、そこを仕組みで縛るための Skill です。

なぜ作ったか：エージェントがコケる 4 パターン

エージェントに長めのタスクを任せると、私の体感では次の 4 つでよく事故ります。

アンチパターン	ありがちな症状
① 途中で止まる	3 つ直すべきところを 1 つ直して「対応しました！」で終わる
② 自己申告で完了	テストも回さず「動くはずです」と言い切る
③ 同じ失敗の反復	直前と同じ修正を、何回も angle を変えずに試す
④ 暴走	直らないのに延々リトライし続け、トークンと時間を溶かす

面白いのは、これらが逆方向の失敗を含んでいることです。
①②③ は「止まりすぎ・甘く切り上げる」方向、④ は「止まらなさすぎ」方向。
どちらか片方だけ対策すると、もう片方に振れます。だから「進める力」と「止める力」を両方設計しないといけません。
goal-loop は、この 4 つにそれぞれ対策を当てています。

アンチパターン	goal-loop の対策
① 途中で止まる	完了条件（criteria）を最初に固定し、全部 PASS するまで完了にしない
② 自己申告で完了	テスト・lint・ビルドなど外部シグナルの合否を検証の一次情報にする
③ 同じ失敗の反復	試行履歴を台帳に残し、前回と違う打ち手を強制する
④ 暴走	反復上限・停滞検知・振動検知など多層の停止条件で打ち切る

goal-loop の全体像：7 フェーズのループ

goal-loop は、タスクを次の 7 フェーズで回します。
「賢く一発で当てる」タイプではなく、外部の合否を見ながら、前進と停止を判断して回すタイプです。

ポイントは、ループの戻り先がフェーズ②だということです。
同じことをもう一度やり直すのではなく、台帳を見て計画から組み直してから作業に戻ります。これが「③ 同じ失敗の反復」への効き目になります。

ループの心臓部：多層の「止め方」

私が一番こだわったのがフェーズ⑥の止め方です。
止め方を 1 種類（例：反復回数の上限だけ）にすると、「上限まで無駄に回す」か「早すぎて諦める」かのどちらかに寄ります。
そこで goal-loop は、複数の停止条件を並べて、状況に応じて出口を変えます。

全条件 PASS → 完了。ここで初めて「やり切った」と言える
前進している → 回し続ける価値あり。計画を更新してループ
停滞・振動（同じ失敗、または直す→壊すの行き来）→ 角度を変えて再計画、それでもダメなら打ち切り
予算切れ・ブロッカー（権限不足、外部要因など）→ 抱え込まず人に振る

「直らないのに回し続ける」も「直せるのに諦める」も、この分岐で減らす狙いです。

状態管理：2 つの台帳（Two Ledgers）

エージェントは放っておくと、さっき何を試したかをすぐ忘れます。
そこで goal-loop では、状態を 2 つの台帳に分けて持たせます。この考え方は Microsoft Research の Magentic-One の Task Ledger / Progress Ledger を下敷きにしています。

台帳	役割	持つ情報
Task Ledger（外側）	ゴールと完了条件を保持する	ゴール、固定した criteria、制約、前提
Progress Ledger（内側）	進捗と試行履歴を追う	サブゴールの状態、各試行の結果、停滞カウント
Attempt 教訓テーブル	失敗から学ばせる	「何を試して」「なぜ失敗し」「次は何を変えるか」

特に Attempt 教訓テーブルが「③ 同じ失敗の反復」のブレーキです。
「前回 A をやってダメだった」と明文化されていれば、次は B を選びやすくなります。

図にすると、外側の Task Ledger が「ゴール」をブレずに保持し、内側の Progress Ledger と教訓テーブルが「毎回の試行」を回す、という二重構造です。

さじ加減：努力量と自律度を変える

すべてのタスクを全力でループさせると、些細な作業まで大げさになります。
そこで goal-loop は、タスクの重さと任せる度合いを切り替えられるようにしています。

観点	軽いとき	重いとき
Effort Scaling（努力量）	検証は最小限、ループも浅く	検証を厚くし、計画・評価を丁寧に回す
Autonomy Mode（自律度）	節目で確認を入れる（Normal）	確認を減らして一気に走らせる（超自律）

ここは「ループ設計＝常に重い」になりがちなところを、現実の運用に合わせて軽くもできるようにした部分です。

Autonomy Mode の使い分けは、ざっくりこんなイメージです。

Normal モード：バックアップを取れる破壊的操作（コミットなど）は自分で進めますが、バックアップが取れない不可逆操作や、完了条件そのものの変更は人に確認します。レビューしながら進めたいときや、影響範囲が読みきれないタスク向けです
超自律モード：確認の差し込みを減らして、止め方（多層の停止条件）に判断を任せ、最後まで通しで走らせます（完了条件の再定義も記録・通知のうえ自分で行います）。やり直しが効く作業や、深夜に放っておきたい長丁場のタスク向けです

迷ったら Normal で始めて、「これは任せて大丈夫」と分かってから超自律に上げるのがおすすめです。

「ラルフループ」との関係

ユーザーから「ラルフループっぽいね」と言ってもらえたので、ここは正直に書いておきます。

ラルフループ（Ralph loop） は、Geoffrey Huntley（ghuntley）さんが 2025 年に名付けた、エージェントの素朴な回し方です（手順をまとめた how-to-ralph-wiggum という playbook も公開されています）。
核心はほぼこれだけです。

while :; do cat PROMPT.md | claude ; done

同じプロンプトを無限ループで投げ続ける
毎回まっさらな文脈で「プランを読む → 1 つだけ実装 → テスト → コミット → 終了」
状態は IMPLEMENTATION_PLAN.md のような 外部ファイル（外部メモリ） で共有する
品質は、テスト・lint・ビルドの失敗が修正を強制する「バックプレッシャー」で担保する

名前の由来はアニメ『ザ・シンプソンズ』の Ralph Wiggum。何度でも全力でやり直すキャラ、というニュアンスです。

ここで誤解なきように書くと、goal-loop はラルフループを参照して作ったものではありません。
goal-loop の設計根拠は後述の学術文献ベースで、ラルフとは出自が別です。
ただ、「外部シグナルで合否を見ながらゴールまで回す」という発想は結果的に近く、近縁パターンと言えます。

私の整理では、こういう関係です（厳密な定義というより、理解のための対比です）。

	回し方	状態の持ち方	止め方
ReAct	セッション内部で思考→行動を回す	会話文脈の中	タスク完了の自己判断
ラルフループ	セッションを使い捨てで外側からループ	外部プランファイル	主に反復／人の見届け
goal-loop	外部検証つきでゴールまでループ	2 つの台帳 + 教訓	多層の停止条件

補足：ラルフループは厳密な単一仕様があるわけではなく、コミュニティで育っている通称です。実際、ラルフ系の実践でも LLM をジャッジに使うなどの改良が提案されていて、「素朴さ」だけで固定された概念ではありません。なので上の表も傾向の比較として読んでください。

なぜ「スキルで」作りたかったか：goal コマンドとハーネス依存

実は「ゴールまで回す」という発想自体は、まったく新しいものではありません。むしろ強力な既存機能がすでにあります。

OpenAI Codex には Goal mode（/goal）があります。ゴール文が「開始プロンプト」と「完了条件」を兼ねて、Codex が次の行動と完了可否を判断しながら長いタスクを進めます（設定で features.goals = true にして有効化）
GitHub Copilot 側も、CLI の autopilot mode（--max-autopilot-continues で継続回数を指定）や、VS Code の agent mode（完了するまで自己修正して回り、chat.agent.maxRequests などの設定で上限を制御）が、似たことをやってくれます

これらはどれも実用的で強力です。じゃあなぜわざわざスキルを作ったのか。理由は、「回す中核」がだいたいハーネス（エージェントの実行基盤）側の機能だからです。

ループの駆動、反復の上限、サブエージェントの生成、コマンド実行、テストの exit code 取得――こういう「実際に回す」部分は、基本的に基盤側が担います。プロンプトやスキルは「どう判断して、どう進めるか」を指示できても、ループそのものを生み出すのは基盤側、という切り分けです。

余談：Codex は再利用したい振る舞いを SKILL.md ベースの Skills として書く形を用意しています。「再利用したいワークフローはスキルにまとめる」という流れ自体は、各ハーネスで共通してきています。

ここで私が引っかかったのは、特定ハーネスの goal 実装や設定に依存してしまう点でした。「Codex の /goal がある環境じゃないと回らない」「この設定値を上げないと途中で止まる」では、持ち運びが効きません。

そこで goal-loop では、こう割り切りました。

ゴールまで回す段取り（判断ロジック）は SKILL.md 側に寄せる
ハーネス間の継ぎ目には、多くのエージェントが共通して持つサブエージェント委譲を使う

こうすると、「ゴールまで回す」考え方の部分を、特定の /goal コマンドに縛られずに持ち運べます。

正直に書いておくと、「完全にハーネス非依存」にはできません。サブエージェントの生成もコマンド実行も、結局は基盤の機能だからです。狙いは「ゼロ依存」ではなく、「特定の goal コマンド実装への依存を下げる」こと。これなら Copilot でも Claude Code でも Codex でも、同じ SKILL.md で近い動きを期待できる、というのが goal-loop を作った元々の動機です。

逆のアプローチの実例も見ておくと面白いです。oh-my-codex の ultragoal は、Codex の goal mode を積極的に前提にした上で、その上に「ファイルに残す耐久プラン（goals.json）＋追記専用の監査ログ（ledger.jsonl）＋完了ゲート＋dynamic steering」を被せた durable な workflow です。台帳と外部 evidence で完了を縛る考え方は goal-loop とよく似ていて、「ハーネスに乗るか / 依存を下げるか」という向きの違いが見えます。

設計の裏付け（参考にした文献）

「なんとなく良さそう」で作ると後で崩れるので、goal-loop の判断は次の文献を下敷きにしています。
自己修正の有効性は研究の間でも意見が割れているのですが、その両側を踏まえたうえで設計を決めました。

文献	何を言っているか	goal-loop への効き方
Anthropic "Building effective agents"	Orchestrator-workers / Evaluator-optimizer などのパターン。評価基準が明確なときにループが効く	委譲と評価を分ける構成の土台
Reflexion (arXiv:2303.11366)	失敗の言語的フィードバックを記憶に残し、次の試行へ活かす	Attempt 教訓テーブルの発想
Self-Refine (arXiv:2303.17651)	単一 LLM の生成→自己批評→修正でも改善しうる（肯定側）	自己評価にも一定の価値はある
LLMs Cannot Self-Correct Reasoning Yet (arXiv:2310.01798)	外部フィードバックなしの自己修正は、推論でむしろ精度を下げうる（否定側）	だから外部シグナルを一次情報にする
Magentic-One (Microsoft Research)	Task / Progress の 2 台帳、停滞時の再計画、不可逆操作は人間確認	台帳とエスカレーションの設計

要するに、「自己採点だけ」は万能ではない。
だから goal-loop は、自己評価を完全に捨てるのではなく、テストやビルドの合否という外部の事実を優先しつつ、評価を補助に回す、というバランスにしています。
（この自己修正まわりの偏りについては LLM-as-a-Judge (arXiv:2306.05685) なども参考になります）

使い方

起動のトリガー

goal-loop は、次のような言い回し（代表例）で呼び出すことを想定しています。

「goal-loop で」
「ゴールまで回して」
「必ずやり遂げて」
「loop until done」
「until it actually works」

このあたりを SKILL.md のトリガーとして定義してあり、「最後までやり切ってほしい」という意図が伝わるキーワードで反応します。

ちなみに私は、スキルをスラッシュコマンドとして直接呼べるハーネス（GitHub Copilot など）では /goal-loop で起動しています。これが一番手早いです。ただしスラッシュでスキルを呼べるかはハーネス依存なので、対応していない環境では上のキーワードで呼んでください。

導入

Agent-Skills リポジトリの goal-loop/ を、お使いのエージェントの Skill 置き場に配置すれば使えます。
SKILL.md 本体に加えて、references/ 配下に判断基準を分けて置いてあります。

criteria-agreement：完了条件の固め方
ledger-templates：2 台帳のテンプレート
loop-control：停止条件の判断
evaluation-rubric：評価の採点軸
steering-and-final-gates：軌道修正と最終チェック
design-rationale：設計の根拠（上記の文献まわり）

Skill のインストール方法そのものは、お使いのエージェント（GitHub Copilot / Claude Code など）の Skill 読み込み仕様に従ってください。

おまけ：Agent Skills Ninja で入れると楽

「Skill 置き場ってどこ？」「複数のエージェントに同じスキルを配るの面倒」という人には、以前作った VS Code 拡張 Agent Skills Ninja がおすすめです。GitHub のスキルリポジトリから検索してワンクリックで導入したり、入れたスキルを AGENTS.md などのインストラクションファイルに自動で同期したりできます。

野良スキルのセキュリティリスクを避けるためにも、ソースの素性が見える形で管理できるのは安心材料です（信頼度バッジで「どこ発か」が分かるようにしています）。詳しくは別記事 Skill を管理する "Agent Skill Ninja" を作ってみたにまとめています。

おわりに

goal-loop は、「エージェントが賢いかどうか」よりも「やり切るルールが決まっているかどうか」のほうが、長いタスクの成否を分ける、という体感から生まれました。

ゴールと完了条件を最初に固定する
自己申告ではなく外部の合否で検証する
試行履歴を残して同じ失敗を避ける
止め方を複数用意して、暴走も早すぎる諦めも減らす

このあたりがピンと来たら、よかったらぜひ使ってみてください！
goal-loop は公開しているので、誰でもすぐ試せます。
すでに使ってみた感想を書いてくれた方もいるので、そちらも合わせてどうぞ → goal-loop を使ってみた（shahin0809 さん）。

最後まで読んでいただき、ありがとうございました！
「うちのエージェントはこう止めてる」みたいな話があれば、コメントでぜひ教えてください～！